本文へスキップ

AI Agent Observabilityの導入

LLM(Large Language Model)を製品に組み込み始めると、従来のAPMでは見えない領域が生じます。推論APIがHTTP 200を返しても応答品質が崩れていることがあり、トラフィックの増加はそのままトークンコストの急増につながります。さらに同じプロンプトでも毎回異なる応答が返るため、再現が困難です。本ガイドでは、AI Agent Observabilityが別のアプローチを必要とする理由と、WhaTap AI Agent Observabilityで構築できる観測の流れを整理します。

LLM機能を本番環境に投入した、あるいは投入予定のバックエンド開発者、SRE、プラットフォームエンジニアを対象とします。本ガイドでは、観点・概念・メニューマップ・活用シナリオを扱い、エージェントのインストール手順やパラメーターの詳細は下位ドキュメントに分離しています。

従来のAPMでは不十分な理由​

HTTP 200の裏に隠れたモデル異常​

LLM推論エンジンは、ハルシネーションや異常応答もHTTP 200として返します。サーバー指標には何の異常も現れないため、別途観測の仕組みがないと障害の検知が遅れます。

見えないトークンコスト​

LLM APIは呼び出しごとにトークン単位で課金されます。1件あたりのコストはモデル・プロンプト長・応答サイズによって大きく変動します。エラーで失敗したリクエストでもトークンは消費されるため、無駄なコストを別途追跡する必要があります。

ユーザー体感の応答遅延​

LLMは従来のAPIより数秒遅くなることがあります。ストリーミング環境での最初のトークン遅延やトークン生成速度の低下は、ユーザーには「止まった」と感じられます。平均値だけでは一部の遅さを捉えきれません。

プロンプトの再現が不可能​

同じプロンプトでも毎回異なる応答が返ります。問題発生時のプロンプト・モデル・パラメーターを保存していないと、再現自体が不可能です。

マルチモデルの比較不足​

1つのアプリケーションで複数のモデル(Claude、GPT、Geminiなど)を併用するのが一般的です。モデル別の性能・コスト・エラー率の比較データがないと、モデル選択の意思決定が客観的な根拠なく行われるようになります。

データの分散​

ログ・メトリクス・コスト・トレースがそれぞれ異なるプラットフォームに分散していると、問題発生時に複数のツールを行き来しながら手動で紐付けする必要があり、原因特定が遅れます。

WhaTap AI Agent Observabilityが提供する観測軸​

表 | AI Agent Observability 観測軸
CategoryDescription
性能応答時間(p50・p95・p99)、ストリーミングの最初のトークン遅延、トークン生成速度
コストモデル・リクエスト・チーム別のトークン使用量、エラーコスト、予算との対比推移
品質・安定性HTTP 200内の異常検知、エラー種別の分類、応答パターンの変化
文脈システムメッセージ・入力プロンプト・モデル応答・ツール呼び出しの原本保存
連結APMトランザクション ↔ LLM呼び出し ↔ GPUインフラのエンドツーエンドトレース

導入ステップ​

ステップ1. エージェント連携​

現在、PythonとJavaに対応しています。Node.jsおよびOpenTelemetry環境への対応は今後予定しています。

ステップ2. ダッシュボードの探索​

エージェント連携が完了したら、LLMダッシュボードメニューで主要指標を確認します。初期は見慣れた指標(リクエスト量・応答時間・エラー率)から確認し、その後LLM固有の指標(トークン使用量・プロンプトパターン)に範囲を広げます。

ステップ3. コストの可視化​

コスト分析メニューとトークントレンドメニューで、モデル別・チーム別・時間帯別のコスト構造を把握します。予算超過リスクを早期に捉えられます。

ステップ4. 品質問題の追跡​

プロンプトログメニューで原本の文脈を保存しておくと、異常応答を発見した際に「その時どのプロンプトだったか」を即座に再現できます。LLM APIトレースメニューでは呼び出しの流れをドリルダウンできます。

活用シナリオ​

新規LLM機能リリースの検証​

  1. ベースラインを記録します。既存モデル基準の応答時間・エラー率・リクエストあたりのトークン数を保存します。
  2. リリース後に同じ指標を比較します。リリース検証シナリオと同じ流れに従います。
  3. 応答品質に異常が出たら、プロンプトログから原本の文脈を再現します。

コストチューニング​

  • 時間帯別のモデル使用量を分析し、軽量モデルに切り替え可能なリクエストを特定します。
  • エラーリクエストのコストを定量化し、リトライロジックとタイムアウトを調整する基準として活用します。
  • 月次コストレポートに反映します。性能レポートシナリオを参照してください。

ユーザー体感低下の原因分析​

  1. LLMダッシュボードメニューでp95・p99応答時間の急増を確認します。
  2. 該当時間帯にどのモデル・どのエンドポイントが遅かったかをドリルダウンします。
  3. プロンプトログとAPMトランザクショントレースを突き合わせ、アプリケーションレベルの問題かモデルレベルの問題かを切り分けます。

GPUインフラとの連動分析​

  • LLMの応答が低下した時点のGPUダッシュボードを同時に確認します。
  • GPU使用率が飽和している場合は、インフラ増設またはリクエスト分散を検討します。

主要メニューとドキュメントマップ​

表 | AI Agent Observability 主要メニュー
MenuPurposeReference
LLMダッシュボード総合状態の確認ダッシュボード
コスト分析トークン・金額の可視化コスト分析
トークントレンド使用量推移の分析トークントレンド
プロンプトログ原本文脈の保存・再現プロンプトログ
LLM APIトレース呼び出しフローのドリルダウンLLM APIトレース
LLMメトリクスカスタム指標の定義LLMメトリクス

次のステップ​

最終修正：