9月15日、Telerikが「Agent Observability Gap: Why AI Agents Need More Monitoring」と題した記事を公開した。この記事では、AIエージェントを本番環境で動かす際に従来の監視ツールでは捕捉できない障害モードと、それに対応するための可観測性の実装方針について詳しく紹介されている。以下に、その内容を紹介する。
「HTTP 200」が返っても、エージェントは壊れている
AIエージェントの可観測性が難しい理由は、失敗が「成功のふりをする」点にある。
プレイグラウンドでは、Prompt → LLM呼び出し → レスポンス というシンプルな流れで動作する。ところが本番環境の同じリクエストは、次のように展開する。
ユーザーリクエスト → 検索（Retrieval） → ツール呼び出し → 推論 → トークン消費 → 出力
このとき、検索ステップが古いコンテキストを返しても、ツール呼び出しが意味的に誤った処理をしてHTTP 200を返しても、最終的なレスポンスは「正常」に見える。ステータスコードは200、エラーログは空白——しかしエージェントの動作品質は劣化している。これが記事の言う「可観測性ギャップ（Observability Gap）」だ。
従来のAPM（アプリケーションパフォーマンス監視）はステートレスなHTTPアプリケーション向けに設計されており、「サービスが応答したか」は教えてくれる。しかし「エージェントが途中で正しい判断をしたか」は教えてくれない。
従来のロギングが捕捉しにくい5つの障害パターン
記事では、エージェント特有の障害モードとして以下の5つを挙げている。
1. 検索の失敗（Retrieval Failure）
RAGパイプラインが古い・不正確・無関係な情報を返しても、ベクターDBへのクエリは「成功」として記録される。モデルはその誤った文脈から自信を持って回答を生成する。
2. ツール呼び出しの失敗（Tool-call Failure）
エージェントが誤ったツールを選択したり、不正なパラメーターを渡したりしても、ステータスコードが200であればAPMは問題を検知できない。デバッグには「どのツールが選ばれたか」「なぜ呼ばれたか」「何を受け取り何を返したか」の可視性が必要だ。
3. レイテンシスパイク
p50（中央値）が正常でも、p99が12秒に達していることがある。マルチステップのエージェントでは、単一の遅い検索やツール呼び出しが全体の体験を引き下げる。リクエスト単位のメトリクスだけでは、どのステップで時間が費やされたかを特定できない。
4. コストの爆発（Cost Blowouts）
推論ループが1リクエストで数万トークンを消費することがある。従来のインフラダッシュボードはCPUやメモリを監視するが、トレースあたりのコスト・ユーザーあたりのコスト・ステップあたりのトークン消費といった概念には別次元の計装が必要だ。
5. 出力ドリフト（Output Drift）
最も検知が難しい障害。モデルのアップデート、プロンプト変更、検索データの更新により、アプリケーションは「動いている」のに出力品質が静かに変化する。技術的エラーは一切発生せず、ユーザーが最初の「監視システム」になってしまう。
エージェント可観測性の7つの柱
記事は、AIエージェントに必要な可観測性スタックを7領域に整理している。
| 領域 | 目的 |
|---|---|
| トレース | 全ステップの実行グラフを可視化 |
| 評価（Evals） | LLM-as-a-judgeやゴールデンデータセットで品質を定量化 |
| コスト | モデル・ユーザー・ステップ単位でトークン消費を帰属 |
| レイテンシ | スパン単位でp50/p95/p99を計測 |
| ドリフト検出 | 行動変化をユーザーより先に検知 |
| リプレイ＆デバッグ | 問題のあるトレースを再現し、ステップ単位で修正を試せる |
| ガードレール | プロンプトインジェクション、機密データ漏洩、ポリシー違反を実行中に検知 |
実装ロードマップ：何から始めるか
記事は「全部一度に実装しなくていい。順序が重要」として、以下の段階的アプローチを示している。
Week 1：エージェントグラフを可視化する
OpenTelemetry互換のスパンを使い、すべてのLLM呼び出しとツール呼び出しを計装する。プロンプト・レスポンス・ツール名・引数・ステータスを各スパンでキャプチャし、「過去1時間で最も遅いトレース」が一覧できる基本ビューを作る。
Month 1：レイテンシとコストを帰属させる
スパンにモデル・テナント・アプリケーションのタグを付与する。LLMスパン単位でトークンコストを追跡し、総支出ではなく異常なスパイクにアラートを設定する。「このリクエストが高かった」から「このモデルを使ったこの推論ステップがコスト増の原因」へ診断精度が上がる。
Month 3：品質のリグレッションを捕捉する
小さなゴールデンデータセットを構築し、自動評価をデプロイパイプラインに組み込む。スコアの分布を継続監視し、問題のある本番トレースを選んでステップ単位で再実行できるリプレイ機能を追加する。
現状の成熟度を測る5つの問い
記事は、自チームの可観測性成熟度を評価する問いとして以下を示している。
- すべてのエージェントステップをトレースできるか？
- 障害がどこで起きたかを正確に特定できるか？
- ステップ単位のレイテンシとコストを確認できるか？
- 時系列でエージェントの実行を比較できるか？
- ユーザーより先にドリフトを検知できるか？
5問すべてにYesなら成熟した可観測性カバレッジがある。3〜4問Yesならほとんどのインシデントはデバッグ可能だが、一部の障害クラスは手動調査に頼ることになる。0〜2問Yesなら基盤から整備が必要だ。
詳細はAgent Observability Gap: Why AI Agents Need More Monitoringを参照していただきたい。
