チャットボット / 対話型AI / 大規模言語モデル / AIリテラシー
チャットボットはどう動くのか：ルール、検索、LLM、ツール、人への引き継ぎ
チャットボットとの会話は、失敗する瞬間までは何の努力も感じさせないことがあります。荷物の所在を尋ねます。ボットは一般的な配送ポリシーを繰り返します。注文番号を提供します。再び注文番号を尋ねます。3回ループした後、便利さを約束していた小さなチャットバブルは、あなたと答えの間の閉ざされた扉になってしまいます。
逆の体験はほとんど目に見えません。チャットボットは、あなたが注文を追跡したいことを認識し、正しい番号を取得し、現在の記録を確認し、結果を一文で説明し、特異な場合には人間を提供します。違いは単に一方のボットにより多くの人工知能があるということではありません。それは、一方の会話システムがより明確な目的、優れた状態、信頼できるツール、安全な境界、そして回復の計画された方法を持っているということです。
このガイドはチャットバブルの裏側を見ます。主要な種類のチャットボットを説明し、実際のアーキテクチャを通して1つのメッセージを追跡し、流暢な言語が信頼できる会話の一部に過ぎない理由を示します。
チャットボットとは何ですか？
チャットボットは、テキスト、音声、または他の会話チャンネルを通じて人とメッセージを交換するソフトウェアです。入力を解釈し、次に何が起こるべきかを決定し、応答やアクションを返します。その広い定義には、サポートウィジェットの固定メニュー、アカウント番号を収集する音声フロー、文書を検索する知識アシスタント、そして自由形式の返信を作成できる言語モデルシステムが含まれます。
会話がインターフェースであり、基盤となる技術ではありません。二つのチャットボットは見た目が同じでも、全く異なる方法で動作することがあります。一方は決定木に従います。別のものは意図を一致させてウェブフックを呼び出します。三つ目は文書を取得し、答えを書くために大規模言語モデルに依頼します。最も有用なシステムは、しばしば複数のアプローチを組み合わせています。
ELIZAからの教訓、60年後
1966年、ジョセフ・ワイゼンバウムは ELIZA、自然言語会話のためのプログラム。そのよく知られたDOCTORスクリプトは、ユーザーの発言の一部を応答に変えるためにパターンと変換を使用しました。「I am unhappy（私は不幸です）」のような文は、照合され、再配置され、質問として反映されることがありました。このやり取りは、プログラムがその人の生活についてほとんど情報を持っておらず、最新の言語モデルもないにもかかわらず、注意深く感じられることがありました。
ELIZAが今なお重要である理由は、人々が言語に社会的に反応するからです。タイミングの良い質問、共感的なフレーズ、または自信に満ちた答えは、基盤となる仕組みを超えて理解しているかのような印象を作り出すことがあります。現代のモデルははるかに能力がありますが、インターフェースは依然として同じ誤解を招きます：システムが知っていることを、どれだけ自然に聞こえるかで判断することです。
したがって、プロフェッショナルなチャットボットは、正確なタスクの完了、可視化された限界、そして回復可能なエラーを通じて信頼を獲得すべきです。性格は対話を向上させることができます。それは正しい情報へのアクセスや安全なプロセスに取って代わることはできません。
チャットボットの三つの主要なアーキテクチャ
チャットボットは、三つのアーキテクチャの家族に分けると理解しやすくなります。これは、新しいものが旧世代を無用にする厳密な世代区分ではありません。それぞれ異なる強みを持つツールです。
1. ルールと会話フロー
ルールベースのチャットボットは、あらかじめ設計された経路に従います。ボタンを表示したり、キーワードに一致させたり、フォームを入力したり、条件が満たされたときに状態間を移動することがあります。ロジックは明示的に示すこともできます：ユーザーが配達日を変更したい場合、注文番号を収集し、荷物が対象かどうかを確認し、利用可能な日付を表示し、確認を求めます。
プロセスが限定され、許容される操作が既知の場合、ルールは価値があります。それにより、コンプライアンスの手順や破壊的な操作をより簡単に制御できます。しかし、人々が予期しない表現で要求したり、設計された経路から外れたりすると、弱点が現れます。優れたルールシステムには、完全に理想的なハッピーパスだけでなく、フォールバック、修正、脱出ルートが必要です。
2. 意図の一致と取得
意図ベースのシステムは、ユーザーが何をしようとしているかを推定し、その後エンティティまたはパラメータと呼ばれる有用な詳細を抽出します。例えば「注文番号4821を追跡する」は、追跡注文の意図と注文番号のパラメータに対応する場合があります。Google Cloudの Dialogflowの意図に関するドキュメント では、このパターンを、入力をトレーニングフレーズと比較して一致を見つけるものとして説明しています。
リトリーバルは検索レイヤーを追加します。固定された応答だけで答えるのではなく、システムは関連するパッセージ、ポリシー項目、ヘルプ記事、または記録を探します。リトリーバルチャットボットは、既知の答えを直接引用することも、選択した資料をジェネレーターに渡すこともできます。その品質は、インデックスされた内容、クエリの作成方法、情報源が最新であるか、そしてシステムが適切なパッセージを見つけたかどうかに依存します。
3. 言語モデル、ツール、およびハイブリッドシステム
大規模な言語モデルは、多様な言い回しを解釈し、はるかに広い範囲の入力に対して自然な応答を生成できます。要約したり、説明したり、翻訳したり、明確化の質問をしたり、構造化されたツールの出力を読みやすい言語に変換したりすることができます。トークン生成やモデルの制限についての詳しい説明は、以下を参照してください。 AIとは何か、実際のところ?.
このモデルは依然としてライブの事実や行動に関して支援が必要です。アプリケーションがコンテキスト、検索、またはツールを通じてその情報を提供しない限り、注文番号4821の現在の場所を知ることはできません。「返金が完了しました」という文を作成できるだけで安全に返金を行うことはできません。アプリケーションはモデルを認可されたサービスに接続し、結果を確認する必要があります。
これが、多くの現代のチャットボットがハイブリッドである理由です。ルールは重要な遷移を保護します。検索は現在の知識を提供します。言語モデルは柔軟な言語を処理します。ツールは外部の状態を読み取り、または変更します。従来のコードは権限と出力を検証します。判断や権限が必要なケースは人間が対応します。
チャットボットの1ターン中に何が起こるか
簡単なメッセージに従う：「注文4821はどこですか？」実際の実装では、ステップを結合したり名前を変更したりすることがあるが、基本的な責任は認識可能なままである。
- 入力を受け取り、正規化する。チャンネルはタイプされたテキスト、書き起こされた音声、ボタン選択、言語、またはセッションのメタデータを提供する場合がある。
- 目標を特定する。システムは、リクエストが追跡、キャンセル、支払い、その他のトピック、またはサポートされていない内容に関するものかを判断する。
- 必要な詳細を抽出する。この場合、注文番号は4821である。欠落している場合や曖昧な場合、ボットは想像するのではなく尋ねるべきである。
- 会話の状態を確認する。システムは、すでに知っていること、保持が許可されていること、およびどのステップがアクティブであるかを判断する。
- 知識を取得するか、ツールを呼び出します。追跡サービスは現在の状況を返します。チャットボットは、言語パターンからその状況を作成すべきではありません。
- 応答を作成して検証します。アプリケーションは結果を分かりやすい言葉に変換し、必要なフィールドを確認し、内部データや個人データを漏らさないようにします。
- 返信、回復、または引き渡しを行います。通常の結果はユーザーに返されます。エラー、サポートされていないケース、または人による対応の要求は別のルートに従います。
Google Cloudは、会話のターンのうち、静的な応答を返す、動的な情報のためにWebhookを呼び出す、パラメータを設定する、またはアクションを実行する部分を「フルフィルメント」という用語で表します。 Dialogflow フルフィルメントのドキュメント は重要な区別を示しています：要求の理解とそれを実行することは別個の責任です。
会話の状態は人間の記憶ではありません
チャットボットは、毎回最初からやり直さずに済むだけの状態を持つ必要があります。セッションの状態は、現在のタスクが荷物追跡であること、注文番号が4821であること、ユーザーがすでに郵便番号を確認済みであることなどを記録するかもしれません。状態がなければ、「2つ目の荷物はどうですか？」という質問には使用できる参照がありません。
その状態は人工的に作られたデータであり、人間の記憶ではありません。あるシステムは現在のセッションのみを保持します。他のシステムは会話の履歴、要約、設定、またはアカウント情報を保存することがあります。モデルは、文脈に制限があるため、あるいはアプリケーションが送信内容を意図的に制限しているために、長い会話の一部しか受け取らない場合もあります。
ユーザーは、ウィンドウが閉じられるとチャットボットが忘れると考えたり、逆に「覚えているかのように話す」から覚えていると推測したりしてはいけません。情報の保持、アカウント連携、学習への使用、削除は特定のサービスに依存します。機密情報を共有する前に、サービスのプライバシー説明を確認し、タスクに必要な最小限の情報を使用してください。
リトリーバル拡張生成の仕組み
言語モデルのパラメータは、頻繁に変更される返品ポリシーを保持するための良い場所ではありません。通常RAGと略されるリトリーバル拡張生成は、外部コレクションから関連資料を検索し、選択されたパッセージをモデルのコンテキストに配置してから回答を生成することでこれに対処します。
元の リトリーバル拡張生成の論文 は、事前学習済みのジェネレーターと、インデックスから取得された明示的な非パラメトリックメモリを組み合わせました。この広範なパターンは現在、多くの知識アシスタントに見られます：まず検索し、次に生成する。
有用なRAGパイプラインは、少なくとも4つの失敗の可能性があります。情報源のコレクションが不完全である場合があります。ドキュメントが古くなっている場合があります。検索によって無関係な箇所が選ばれる場合があります。生成器が受け取った情報を誤解したり、誇張したりする場合があります。引用は、正確な支援情報源を指しており、ユーザーがそれを検査できる場合にのみ役立ちます。
したがって、RAGは最新で検査可能な知識へのアクセスを改善しますが、真実を保証するものではありません。エンドツーエンドで評価する必要があります：正しい情報源が索引に入ったか、検索で見つけられたか、回答は証拠内に留まったか、引用は主張を支持していたか？
回答と行動には異なるレベルの制御が必要です
返金ポリシーを説明するチャットボットは、返金を実行するチャットボットとは異なります。後者のシステムは外部の状態を変更することができます。アカウントサービス、カレンダー、支払いシステム、メッセージングツール、またはデバイス制御を呼び出す場合があります。その能力は時に『エージェンシー』と呼ばれますが、実際の問題はより単純です：このアプリケーションはテキストを生成する以外に何ができるのでしょうか？
安全なアクションパスは、重要なチェックをモデルのプローズ外に置くべきです：
- ユーザーを認証し、アカウントやリソースが本人のものであることを確認する。
- チャットボットに広範なアクセスを与えるのではなく、特定のアクションを認可する。
- 従来のコードでツールの引数、金額、宛先、許可範囲を検証する。
- 取り消せないまたは高コストのアクションの場合、明示的な確認を要求する。
- アクションが成功したと仮定するのではなく、検証済みのツール結果を返す。
- 不要な機密データを露出させることなく、障害を調査するために十分な情報を記録してください。
この図はターゲットアーキテクチャを示しているものであり、特定のチャットボットに関する約束ではありません。言語モデルはどのツールを呼び出すかを提案できますが、周囲のアプリケーションがその呼び出しが許可されているかどうかを決定するべきです。自律性が高まるほど、許可の境界、レート制限、確認、監視、および人間によるレビューの価値が高まります。
プロンプトインジェクション：コンテンツが命令になろうとする場合
ツールを使用するチャットボットや情報取得チャットボットは、ユーザー、ウェブサイト、メール、またはドキュメントから提供されたテキストを読むことがあります。そのテキストの中には、モデルに向けた命令を含むものがあり、例えば以前のルールを無視するよう指示したり、隠された情報を公開させたり、意図しない方法でツールを呼び出させることがあります。これがプロンプトインジェクションです。
The OWASP GenAI セキュリティプロジェクト は、プロンプトインジェクションを言語モデルアプリケーションの主要なリスクとして挙げています。核心的な問題は、モデルが指示と通常のコンテンツを同じ言語チャネルで処理することです。信頼できない文書が、アプリケーションからの指示と文法的に似て見えることがあります。
どんなプロンプトもシステムレベルの制御に取って代わることはできません。アプリケーションは取得した内容やユーザー提供のコンテンツを信頼できないものとして扱い、利用可能なツールを制限し、最小権限の原則を適用し、ツールの呼び出しを検証し、機密操作を分離し、結果が重要な場合には確認を求めるべきです。インターフェースが会話形式であるからといって、モデルにマスターキーを渡すべきではありません。
チャットボットが誤った、または苛立たしい回答をする理由
リクエストを誤解している
言語は曖昧です。「アカウントを閉じる」は、ログアウト、プロフィールの削除、サブスクリプションの解約、または金融口座の閉鎖を意味する場合があります。信頼できるチャットボットは、推測のコストが一回の確認質問のコストより高いときにそれを認識します。
彼らは必要な情報を持っていません。
モデルは一般的な配送用語を知っているかもしれませんが、ユーザーの注文記録を持っていない場合があります。検索で関連する方針を見逃すことがあります。ツールが利用できない場合もあります。正しい対応は制限を述べるか代替手段を使うことであり、もっともらしい話で穴を埋めることではありません。
彼らは自信たっぷりの虚偽を生成します。
NISTは、自信を持って提示される誤った、または虚偽の生成コンテンツを『混同（confabulation）』と呼んでいます。その 生成AIプロファイル では、この行動は作り話の論理や引用を含むことがあると指摘しています。流暢さは、これらの失敗に気付くのを難しくするだけで、影響が小さくなるわけではありません。
彼らは状態を失うか、誤った状態を引き継ぐ
セッションは詳細を忘れたり、二つの注文を混同したり、誤った仮定を保持したり、あるタスクの情報を別のタスクに適用したりすることがあります。状態は修正できる程度に見えるようにし、意図しない混合を避けるために狭い範囲に制限する必要があります。
彼らには優雅な終了はありません
最も痛いループは、多くの場合設計上の失敗です。ボットは自身の能力の限界に達していますが、同じ答えを言い換え続けます。フォールバックは道筋を変えるべきです：1つ不足している詳細を尋ねる、支援された選択肢を示す、ケースを作成する、または会話を引き継ぐことです。
人間への引き継ぎは、システムの一部であり、敗北の認めではありません。
一部のリクエストはあいまいで、感情的で、例外的、または重大です。その他のリクエストは、チャットボットが持つべきでない権限を必要とします。人間の専門家は、文脈を解釈し、例外を交渉し、責任を負い、あるいは文書化されたプロセスがケースに適合しないことを認識することができます。
ハンドオフは、コンテキストが一緒に移動するときにのみ機能します。受け取る人は、ユーザーの目標、確認済みの詳細、関連するツールの結果、そしてエスカレーションの理由を受け取るべきです。ユーザーに会話全体を繰り返させることは、技術的に成功した転送を悪い体験に変えてしまいます。
Dialogflowの ライブエージェントハンドオフのドキュメント は、ハンドオフを明示的な移行として扱います。この設計原則は1つのプラットフォームに限定されません：エスカレーションは、ボットが行き詰まったときに即興で言う文ではなく、所有権があるテスト済みのルートであるべきです。
チャットボットが優れているかどうかを判断する方法
説得力のあるデモは簡単に演出できます。信頼できるチャットボットは、通常の変動や明らかな失敗に対応できなければなりません。評価は、ユーザーが完了しようとしている仕事から始めるべきです。
- タスク完了：ユーザーは正しく回答を得たか、または行動を完了したか？
- 根拠: 事実に関する主張は提供された情報源や検証済みツールの結果に基づいていましたか？
- 回復: 欠落情報、一致しないイベント、ツールの失敗は、有用な次のステップにつながりましたか？
- 安全性: 承認、確認、データ処理、ツールの制限は、敵対的な入力に対しても守られていましたか？
- 引き継ぎの品質: 会話は十分なコンテキストとともに適切な担当者に届きましたか？
- 言語とアクセシビリティ: フローはサポートされている言語、入力スタイル、音声条件、キーボード操作、支援技術において機能しましたか？
- ユーザーの労力: タスクを完了するために何回のターン、繰り返し、修正が必要でしたか？
テスト会話には、ハッピー パス以上のものを含める必要があります。注文番号の欠落、1つのメッセージに2つの番号、スペルミス、サポートされていないリクエスト、期限切れのドキュメント、ツールのタイムアウト、トピック変更のリクエスト、特定の人物への直接リクエスト、取得したコンテンツに隠された悪意のある指示などを使用してください。Google Cloud の エージェント設計ガイダンス 同様に、すべてのパスを一度に設計しようとするのではなく、反復的な設計とテストケースを推奨しています。
判断を放棄せずにチャットボットを使用する方法
- 目標と最小限の関連コンテキストを述べてください。正確なリクエストは不要なやり取りを減らします。
- パスワード、認証コード、支払い情報、秘密鍵、または機密記録は、特定の信頼されたサービスが明示的にそれらの入力を要求し、保護している場合を除き、貼り付けないでください。
- 説明と実際の結果を区別してください。その答えが現在の記録、引用された情報源、または一般的なモデル知識からのものか尋ねてください。
- 引用を開き、重要な主張を確認してください。ソースリンクは無関係、古い、または答えと矛盾している場合があります。
- 確認する前にすべての操作を見直してください。アカウント、金額、送金先、日付、および変更が元に戻せるかどうかを確認してください。
- ボットが繰り返したり、権限がなかったり、敏感な問題を誤解したり、答えの出所を示せない場合は、人に尋ねてください。
覚えておくべきメンタルモデル
チャットボットは、バブルの中で生きている人格ではありません。それは、フロー、分類器、検索、言語モデル、記録、ツール、ポリシー、安全チェック、人々の組み合わせに接続された対話型インターフェースです。あなたが見る応答は、その大きなシステムの最後のステップです。
最も重要な質問は「このボットは人間のように聞こえるか？」ではありません。タスクを理解したか、適切な証拠を使用したか、権限を尊重したか、正直に回復したか、そしてあなたに制御を残したかを確認してください。自然言語はシステムをより取り扱いやすくします。優れたエンジニアリングは使用に値するものにします。
主な参考文献および技術文献
- Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
- NIST、人工知能リスク管理フレームワーク：生成型人工知能プロファイル、2024年。
- Google Cloud、Dialogflow CX の意図、フルフィルメント、エージェント設計、および人間への引き継ぎに関するドキュメント。
- OWASP GenAI セキュリティプロジェクト、LLM01:2025 プロンプトインジェクション。