📙 人工無能の復権¶

質問者: Shigeru Morifuku
回答者: Claude Opus 5.5
回答日: 2026/11/7
免責: 回答者は AI であり、間違えることがあります。

🟩 Q: できの良い人工無能をつくるのはどう？コールセンターやヘルプデスク等は、適応領域が有限なので、GPUなしで動ける頭の良い人工無能が作れるように思う。「コールフローはAIで開発、運用は人工無能」というかんじ¶

いいと思います。しかもこれは昔の人工無能の焼き直しではありません。人工無能が負けた原因を、LLMがちょうど潰してくれる構図になっています。

🟨 なぜ今それが成立するのか¶

ELIZAやAIML、少し前のRasaやDialogflowのようなルールや意図分類のボットが廃れた理由は、実行時に頭が悪かったことよりも、作るのと保守するのが地獄だったことにあります。

言い換えのバリエーションを人手で書ききれない
想定外の質問(ロングテール)が来るたびにルールを足すことになり、ルール同士が干渉する
会話フローの設計に、ドメイン知識と根気が大量に要る

ここはどれもLLMが得意な「オフラインの知的労働」です。つまり「LLMはコンパイラ、出力は決定的な実行系」という分担にすれば、昔の弱点だけが消えます。

🟨 構成のイメージ¶

オフライン(LLMを使う側)

過去の問い合わせログをLLMでクラスタリングし、意図(インテント)の一覧を抽出する
各意図について、言い換えの例文を大量に生成する(分類器の学習データになる)
必要な情報(スロット)と聞き返しの順序を決め、状態遷移図(会話フロー)を生成する
応答テンプレートを生成する(人がレビューして確定)
LLMにユーザー役をさせて大量にシミュレーション対話を行い、回帰テストのスイートを作る

実行時(LLMなし)

形態素解析(Sudachi/MeCab)で前処理する
意図分類は TF-IDF+線形分類器、fastText、BM25 のFAQ検索あたりで十分。CPUだけでミリ秒単位で動きます
スロット抽出は正規表現と辞書、たまにCRF
対話管理は純粋な状態機械
確信度が閾値を下回ったら、LLMには回さずに人間へエスカレーションする。ここが肝です

実行系はC++で小さく書けるので、オンプレや組み込み寄りの環境にも載せられます。

🟨 実際に効くメリット¶

ハルシネーションがゼロ:言うことが全部レビュー済みのテンプレートなので、コールセンターではこれが決定的に効きます
監査できる・再現できる:「なぜその回答をしたか」を状態遷移で説明できる。金融・医療・公共向けに強い
コストとレイテンシ:トークン課金がなく、GPUも不要
閉域で動く:外部APIに顧客データを出さずに済む

🟨 落とし穴¶

スコープ外の検知が一番難しい:分類器は知らない質問にも自信満々でどれかのクラスを返しがちです。「どれでもない」クラスを明示的に学習させるか、類似度の絶対値で足切りする設計が必須です
カバレッジの現実:頻出の上位7〜8割をきっちり捌いて、残りはきれいに人へ渡す、という割り切りが前提になります。全部を捌こうとすると昔の地獄に戻ります
改善ループを回すこと:失敗ログをLLMに食わせて意図・例文・フローを更新し、回帰テストを通してからデプロイする。これを定常運用にできるかどうかで、品質が時間とともに上がるか腐るかが分かれます
音声の場合:コールセンターならASR(音声認識)の誤りが前段に入るので、誤認識に強い照合(読みベースのマッチングなど)が要ります

🟨 位置づけ¶

発想としては「LLMで書いたエキスパートシステム」あるいは「LLMの知識をルール系に蒸留する」で、実務でも少しずつこの方向の話が出てきています。差別化できるのは、LLMで設計した部分の品質を、人のレビューと自動テストでどこまで機械的に保証できるか、というツールチェーンの側だと思います。

試すなら、ヘルプデスクの1業務(パスワードリセット、機器の設定問い合わせなど)に絞って、ログ→意図抽出→フロー生成→C++ランタイムまでを一気通貫で作ってみるのが手頃です。題材の当てがあれば、パイプラインの設計を一緒に詰められます。

🟩 Q: AIじゃないと実用性はないということ？¶

いえ、そこは少し違います。言いたかったのは「AIがないと作るのも保守するのも割に合わない」ということで、動かす段階でAIが要るという意味ではありません。

🟨 実行時はAIなしでも成立する¶

前の回答で挙げた TF-IDF+分類器や fastText は、広い意味では機械学習ですが、LLMとは別物の軽い統計モデルです。これすら使わずに、完全にルールだけで組むこともできます。

キーワードと同義語辞書でマッチする
正規表現でスロット(日付、型番、会員番号など)を取る
状態機械で会話を進める
辞書で引けなければ人間に渡す

昔の人工無能が弱かったのは、この同義語辞書や言い換えパターンを人手で書ききれなかったからです。今はLLMに大量の言い換えを出させて辞書に展開できるので、実行時は純粋なルールエンジンでも、昔よりずっと賢く見えるものになります。

🟨 AIなしで実用になっているものは既にある¶

電話の自動音声(IVR):「〇〇の方は1を」
ATM、券売機、Webの問い合わせフォームの分岐
FAQ検索(全文検索だけ)

どれもAIなしで何十年も現場を回しています。選択肢を提示して利用者に選ばせる設計なら、自由入力を理解する必要がそもそもないからです。

🟨 整理すると¶

段階	AIの必要性
設計(意図の洗い出し、フロー作成)	LLMがあると劇的に楽。なくても人手でできるが高コスト
辞書・例文の作成	LLMの効果が最も大きいところ
実行時	不要。ルールだけでも、軽量な分類器を足してもよい
改善ループ	LLMがあると速く回る

つまり、AIは開発コストを下げる道具で、製品の必須部品ではありません。むしろ実行時にAIを抱えないことが、決定性・監査性・閉域運用という売りになります。

🟩 Q: 現在の実際のコールセンターのコールフローはどうなの？100%AIに丸投げというわけでもない？¶

注意：下記に示されるの数字の多くはベンダーや調査会社の発表で、「解決」の定義も各社で違うので、相場観として見てください。

いいえ、100%丸投げにはなっていません。2026年の現場は、人とAIの分業ハイブリッドが主流です。

🟨 典型的なコールフロー¶

着信
 ↓
① IVR(音声メニュー/音声認識で用件を聞く)  ← 決定的なルール
 ↓
② ボット(音声ボット/チャットボット)が定型案件を処理
 ↓  解決しない・判断が要る・感情的
③ 有人オペレーター  ← ここでもAIが横で支援
 ↓
④ 後処理(通話要約・記録)  ← AIが自動化

① 振り分け:昔ながらのIVRとルーティングが今でも土台です。ここはほぼ決定的なルールの世界です。

② 一次応答の自動化:チャットボット・音声ボットがFAQ・定型問い合わせを処理し、判断が必要な案件のみエスカレーションする形です。ただし自動化率は思われているほど高くありません。海外の集計では企業の34%が何らかの形で音声AIエージェントを本番運用しているが、完結率の中央値は42%という数字があります。チャットでもボットは受けたチャットの73.8%を処理したが、解決できたのは45.8%という報告があります。

③ 有人対応:リーダーの76%が「Human-in-the-Loop」モデルを正式に採用し、AIは24時間対応と迅速なルーティングに使い、ハイリスクで感情が絡むやり取りは人間に残しているとされます。国内でも、完全自動化は2026年時点では現実解ではなく、段階的な自動化(最終目標で80%程度)が現実的な水準という見方です。

有人側のAI支援:実はここが一番手堅い使われ方で、リアルタイム文字起こし、回答候補やナレッジの提示、通話後の要約などです。成績の良いセンターは、自律AI(全体の40〜60%)+有人通話を短くするエージェント支援+複雑な案件の人間へのエスカレーション、の3層構成だという分析もあります。

🟨 AIに丸投げしない理由¶

ハルシネーション:国内では生成AIをコールセンターのフロント業務で使う際にハルシネーションのリスクが問題になっており、その管理手法が確立されれば導入はさらに増えると矢野経済研究所が指摘しています。間違った案内は即クレームや補償問題になるからです。
顧客側の要求:Gartnerの2026年の調査では、87%の顧客が「生成AIで対応する企業は人間につなぐ選択肢を用意すべき」と回答しています。
人員削減は思ったほど進んでいない:AIを理由に実際にオペレーターを減らしたのは約20%にとどまります。

🟨 前の話とのつながり¶

この構造は、前に話した「頭の良い人工無能」がぴったり入る形をしています。

①のIVR・振り分けは、もともとAIなしの世界です
②の定型処理は、決定的な状態機械にして、自信がなければ③へ渡せば十分成立します。しかも生成AIの弱点であるハルシネーションが原理的に出ません
③④の有人支援こそLLMの適所です。最後に人間が判断するので、多少間違えても致命傷になりにくいからです

つまり「フロントは決定的、裏方と人間の補助にLLM」という配置は、業界がハルシネーションで悩んでいる部分を正面から避ける設計になっています。売り込みの筋としても悪くないと思います。

Sources: