サポートエージェントは、2要素認証のリセットに関するユーザーのリクエストに対し、存在もしない手順で回答してしまいました。回答は自信に満ちているように見え、HTTPリクエストは 200 OK を返し、レイテンシは正常で、すべてのモニタリングチャートは「グリーン（正常）」を示していました。

AI駆動のサポートエージェントがハルシネーション（幻覚）を起こしたのは、エラーを検知すべき内部チェックが一度も実行されなかったためです。エンジニアが頼りにしているダッシュボードは完璧な動作を報告していましたが、その裏でエージェントは静かに、でっち上げた解決策を提示していました。

なぜ従来のダッシュボードではAIのハルシネーションを見逃してしまうのか

ほとんどのオブザーバビリティ（可観測性）スタックは、AIエージェントを他のマイクロサービスと同様に扱います。つまり、単一のインバウンドリクエストと単一のアウトバウンドレスポンスとして扱います。それらはHTTPステータス、レスポンスタイム、エラー数をログに記録します。しかし、リクエスト内部で行われる隠れたステップ――外部ドキュメントの検索（retrieval）、大規模言語モデル（LLM）への呼び出し、補助ツールの使用、そして出力を検証するガードレール・ロジックなどはログに記録しません。

検索ステップが空の結果を返すと、モデルはしばしば「空白を埋める」ように、もっともらしいテキストを生成してしまいます。モニタリングシステムの視点では、クラッシュも発生せずステータスコードも200のままなので、呼び出しは成功したとみなされます。ハルシネーションは不可視のまま、唯一の症状として「誤った回答がユーザーに届く」という事象だけが発生します。

ブラックボックスを読み取り可能なツリーに変える

信頼性の高いデバッグへの第一歩は、エージェントを単一のモノリシックな呼び出しとして扱うのをやめ、各内部操作をトレーステーブルの個別の行として可視化することです。一般的な実行プロセスは、以下のように分解されます：

  • 最上位のエージェント呼び出し
  • 関連ドキュメントを取得する検索ステップ
  • 取得したデータを処理するすべての言語モデル推論
  • 各ツール呼び出し（例：データベース検索、APIリクエスト）
  • 事実性やポリシー遵守を強制するガードレール・チェック

各行には、タイムスタンプ、成功フラグ、およびそのステップを通過したペイロードが記録されます。この構造により、実行プロセスは最終的な出力から推測するものではなく、一行ずつ詳細に検証できる「ツリー」になります。

すり抜けてしまったバグ

問題が発生したサポートのやり取りにおけるトレースは、以下のようでした：

  1. **検索（Retrieval）**は実行されたが、ドキュメントが返されなかった。
  2. 次のステップがそのまま進行し、空のコンテキストがモデルに渡された。
  3. モデルは、不足している情報をでっち上げた手順で埋めるような回答を生成した。
  4. パイプライン内で例外が発生しなかったため、システムは 200 を返した。

このハルシネーションは言語モデル自体の欠陥ではなく、検索ステージと生成ステージの間にガードレールが欠けていたことが原因でした。エージェントは、回答の根拠となる情報が何もない状態でも回答してしまったのです。

ハルシネーションを防ぐシンプルなガードレール

以下の2つの具体的な変更によって、問題は解消されました：

  • 検索結果が空の場合は中断する – ドキュメントストアから何も返されない場合、エージェントは生成プロセスに進むのではなく、「必要な情報を見つけることができませんでした」と回答しなければなりません。
  • グラウンディング（根拠）チェック – モデルが回答を生成した後、すべての事実に関する主張が取得したコンテンツに含まれているかを確認します。チェックに失敗した場合は回答を拒否し、「回答できません」というレスポンスにフォールバックします。

より迅速なデバッグのための実践的なワークフロー

  1. すべての内部呼び出しをトレースする – 各検索、モデル推論、ツール使用が永続的なログに一行ずつ書き込まれるように、エージェントにインストルメンテーション（計測コードの埋め込み）を施します。
  2. 失敗した実行を保存する – ユーザーが「誤り」と報告したやり取りの完全なトレースを保存します。ストレージ節約のためにこれらを削除してしまうと、デグレ（退行）を見つけるために必要なデータが隠れてしまいます。
  3. 実行にバージョン情報をタグ付けする – 各トレースの行に、リリース識別子やフィーチャーフラグの状態を含めます。これにより、新しいバグと最近のコード変更を関連付けることができます。
  4. 速度だけでなく品質をスコア化する – 回答が指示に従っているか、また取得したコンテンツに基づいている（グラウンディングされている）かを測定するメトリクスを追加します。回答が間違っていれば、スループットが高くても意味がありません。
  5. 失敗を毎日レビューする – 保存された失敗事例を短時間で定期的にレビューすることで、（例：特定の種類のクエリが常に空の検索結果を返すなど）多くのユーザーに影響が及ぶ前にパターンを発見できることがよくあります。

「グリーン（正常）」を「検証済み（verified）」へと変えることで、チームはハルシネーションを早期に発見し、ユーザー体験の信頼性を維持できるようになります。

内部的な失敗を無視することの代償

ダッシュボードがHTTPレイヤーでの成功のみを報告している場合、組織は一見信頼できるように見えて、実際には定期的に誤ったガイダンスを提供するエージェントを運用することになってしまいます。

次に注目すべきこと

それらが一般的になるまでは、すべての内部操作を観測可能（observable）として扱い、エビデンスが欠けている場合には即座にエラーを出す（fail fast）ことが最も安全なアプローチです。

要点: ダッシュボードが緑色であることは、システム基盤が機能していることを示しているに過ぎず、回答が正しいことを保証するものではありません。各検索、モデル呼び出し、およびガードレール・チェックをトレースすることで、隠れたハルシネーションを、ユーザーに届く前に修正可能な「可視化された失敗」へと変えることができるのです。