GrafanaやDatadogといったAPM（アプリケーションの性能を監視する仕組み）を、LLM（大規模言語モデル）を使ったAIエージェント機能にもそのまま流用している設計は、意外と多いのではないでしょうか。監視ダッシュボードは緑色なのに、ユーザーからは「AIの回答がおかしい」という苦情が来る。そんな状況に心当たりがあるなら、この記事が判断材料になれば幸いです。
何が起きるか: グリーンなダッシュボードの裏で起きる機能不全
AIエージェントが搭載されたシステムでは、レスポンスタイムが800ミリ秒で安定し、HTTPエラー率もゼロ、トークン消費量（LLM APIの課金対象となる処理単位）も予算内、という状態でも、実際には深刻な問題が起きていることがあります。
具体的には、エージェントが事実と異なる内容を生成する「ハルシネーション」、呼び出すべきツールを間違える誤選択、同じ処理を繰り返す無限ループ、そしてユーザーの意図とずれた回答の生成です。
これらはいずれもHTTPステータスコードのエラーにならず、レイテンシのスパイクも起こさず、システムアラートも発報しません。従来のAPMが監視している指標のどれにも引っかからないまま、ユーザー体験だけが劣化していきます。
影響範囲はエージェント機能を持つプロダクト全般です。カスタマーサポートのチャットボット、社内ナレッジ検索、コード生成アシスタントなど、LLMが「判断」や「推論」を担う箇所すべてが対象になります。
なぜ起きるか: 監視対象のレイヤーがそもそも違う
原因を分解すると、APMツールとAIエージェントの間には構造的なミスマッチがあります。段階的に見ていきます。
第一に、APMは「インフラ層」と「アプリケーション層」の健全性を測る設計です。CPU使用率、メモリ、レスポンスタイム、エラーレートといった、数値化しやすく閾値を引きやすい指標が中心になります。
第二に、AIエージェントの品質問題は「推論層」で起きます。エージェントがどんな理由でどのツールを呼び、どんな中間ステップを経て最終回答に至ったか、という思考のプロセスそのものが問題の発生源になります。この部分はHTTPリクエスト1本には収まらず、複数回のLLM呼び出し、ツール実行、条件分岐が連鎖する「トレース」として捉える必要があります。
第三に、品質の良し悪しはセマンティック（意味論的）な評価でしか判定できません。レスポンスタイムのように「200ms以下ならOK」という機械的な閾値が引けず、生成された文章の妥当性、事実の正確性、ユーザーの意図との一致度を評価する仕組みが別途必要になります。
第四に、プロンプト（LLMへの指示文）がアプリケーションコードに直書きされ、コードと一緒にバージョン管理されているケースが多く見られます。プロンプトの文言を1行変えるだけでも、コードレビューとデプロイのフルサイクルが必要になり、A/Bテストや改善のサイクルが著しく遅くなります。
これらを整理すると、APMは「動いているか」を見る仕組みであり、AIエージェントに必要なのは「正しく判断しているか」を見る仕組みだという違いに行き着きます。この2つは補完関係にあり、どちらかがもう一方の代替にはなりません。
自分のプロジェクトが該当するか確認する
以下の観点でチェックしてみてください。該当項目が多いほど、専用の観測基盤を検討する優先度が上がります。
- LLM呼び出しがアプリケーションコード内から直接行われ、呼び出し履歴が構造化ログとして残っていない
- プロンプトの文言がソースコード内にハードコードされている（
.pyや.tsファイル内に文字列として埋め込まれている） - エージェントが複数のツール（外部API、DB検索、計算処理など）を連鎖的に呼び出す設計になっている
- 「なぜこの回答になったか」をユーザー問い合わせから遡って調査した際、ログだけでは再現できない
- プロンプトを変更した際、品質が改善したか劣化したかを定量的に比較する手段がない
コードベースを調べる際は、リポジトリ内で openai.chat.completions や anthropic.messages.create のような LLM API 呼び出し箇所を検索し、呼び出し前後にトレース情報（入力・出力・中間ステップ）を記録する仕組みがあるかを確認するとよいでしょう。何も出てこなければ、推論プロセスは現状ブラックボックス化している可能性が高いです。
対策の手順: LLM観測基盤を既存監視に足す
この領域を埋めるオープンソースの選択肢として、LLMOps（LLM運用を専門にする領域）に特化したLangfuseのようなプラットフォームがあります。既存のAPMを置き換えるのではなく、その上にもう1層足す形で導入を検討する手順を示します。
ステップ1: トレーシングの導入
Python／JS・TS向けの公式SDKが提供されており、LLM呼び出し箇所にトレーシング用のラッパーを挟むことで、入力プロンプト・出力・中間ステップ（ツール呼び出しの連鎖）を構造化して記録できます。Java／Spring環境向けにも公式クライアント langfuse-java が用意されており、JVM系のバックエンドでも同様の仕組みを組み込めます。
# Python SDKの導入例(公式ドキュメント準拠)
pip install langfuseステップ2: プロンプトのコードからの切り離し
プロンプトをアプリケーションコードではなくプラットフォーム側で管理し、production や staging といったラベルで環境ごとの配信を制御します。これにより、プロンプトの文言修正だけであれば、再デプロイなしに反映できるようになります。バージョン管理も自動で行われるため、劣化が起きた際に直前のバージョンへ即座に戻せます。
ステップ3: トレースとプロンプトバージョンの紐付け
生成結果をどのプロンプトバージョンが作ったか記録できる設計にしておくと、A/Bテストの精度が上がります。バージョン間で品質・コスト・レイテンシを客観的に比較できるようになり、「感覚的に良くなった気がする」から「数値で改善を確認した」へ判断根拠を変えられます。
ステップ4: 導入コストの見積もり
クライアント側でプロンプトのキャッシュを行う設計になっているため、追加のネットワーク往復による体感レイテンシの増加は小さく抑えられる想定です。ただし本番導入前には、負荷試験環境でレイテンシとエラーハンドリングの挙動を必ず検証してください。
導入前に確認すること
AIエージェントの品質問題は、既存のAPMダッシュボードには決して現れません。まず自社のLLM呼び出し箇所を洗い出し、トレースが残っているかを確認するところから始めてみてください。
プロンプトがコードに埋め込まれている場合は、切り離しの設計変更が最初の一歩になります。切り離せれば、プロンプト改善のサイクルタイムが大きく短縮されるはずです。
最後に、APMとLLM観測基盤は競合ではなく併用が前提です。インフラの健全性はAPMで、推論の妥当性は専用ツールで、という役割分担を設計段階で決めておくと、技術的負債の蓄積を防げます。