AIエージェントの監視、ちゃんとできてる？

ミドリ： タツヤさん、AIエージェントをリリースした後の監視って、普通のアプリの監視と同じでいいんですか？

タツヤ(nodding)： いい質問。結論から言うと、全然違う。「AIエージェントをリリースしたが、ユーザーからのクレームで初めて問題に気づく」——これ、多くの運用チームが経験する最も避けたい事態なんだよ。

ミドリ： うわ、それは嫌ですね……。

タツヤ： Google SREチームの実践によれば、問題の検知が1分早まるごとに影響範囲は平均で10%縮小するとされてる。AIエージェントでは「正しい結果を返しているか」「品質が劣化していないか」まで踏み込む必要があるんだ。

なぜAIエージェントには専用の監視が必要なの？

ミドリ(thinking)： 具体的に、従来のアプリ監視と何が違うんですか？

タツヤ： 大きく3つの違いがある。

タツヤ(smiling)： 第1に、出力が非決定的であること。 同じ入力に対して異なる出力が返るから、「正しい応答かどうか」を単純な値比較で判定できない。統計的な手法や意味的な評価が必要になる。

ミドリ： 従来のアプリなら「期待値と一致するか」で済んだのに……。

タツヤ(thinking)： 第2に、外部依存が多いこと。 LLM API、ベクトルデータベース、外部ツールなど複数サービスに依存してるから、どのコンポーネントが問題を引き起こしてるかの切り分けが複雑なんだ。

タツヤ： 第3に、品質の劣化が緩やかに進行すること。 LLMプロバイダーのモデル更新、データソースの変化、ユーザーの利用パターンの変化で、ある日突然じゃなく徐々に品質が下がっていく。日次・週次のトレンドを追わなければ検知できない。

ミドリ： 気づいたときには手遅れ、ってパターンですね。

タツヤ： まさにそう。

監視すべき4カテゴリ・12の指標

ミドリ： じゃあ何を監視すればいいんですか？

タツヤ： 4カテゴリ・12の指標に分類できる。順番に見ていこう。

カテゴリ1: パフォーマンス指標

タツヤ： エージェントの応答速度と処理能力に関する指標。

• レスポンスタイム（P50 / P95 / P99） — ユーザーが体感する応答速度。P95で5秒以内が一般的な目標。P50（中央値）だけ見てると、一部のユーザーが極端に遅い応答を経験してることを見逃すよ
• スループット — 単位時間あたりの処理リクエスト数。ピーク時の処理能力を把握するのに重要
• LLM API レイテンシ — LLMプロバイダー側の応答時間。自社のコードとは独立して監視して、プロバイダー起因の遅延を切り分ける

ミドリ： P50だけじゃダメなんですね。

タツヤ(smiling)： 中央値で「平均5秒」でも、P99で30秒かかってたら100人に1人はめちゃくちゃ遅い体験をしてるってこと。

カテゴリ2: 品質指標

タツヤ： これがAIエージェント固有の最重要カテゴリ。

• タスク完了率 — ユーザーの依頼を最後まで正しく遂行できた割合。85%以上が目標
• ハルシネーション率 — 事実に基づかない情報を生成した割合。定期的なサンプリング評価で測定
• ユーザー満足度 — 「この回答は役に立ちましたか？」のようなインラインフィードバックで収集
• フォールバック率 — エージェントが回答できず、人間のオペレーターにエスカレーションした割合

ミドリ(thinking)： ハルシネーション率って、どうやって測るんですか？

タツヤ： 本番のリクエスト/レスポンスを一定割合でサンプリングして、自動評価パイプラインで判定するんだ。後で詳しく説明するよ。

カテゴリ3: コスト指標

タツヤ： 運用コストの監視も忘れちゃダメ。

• トークン使用量 — 入力/出力トークンの使用量を、機能別・ユーザー別に追跡
• API費用 — 日次・週次・月次のAPI費用を追跡して、予算に対する消化率を監視
• 1リクエストあたりのコスト — 効率性の指標。時間経過とともに改善されてるかを確認

ミドリ(smiling)： コスト管理しないと、知らない間にすごい請求が来たりしますもんね。

カテゴリ4: 信頼性指標

タツヤ： システムの安定性。

• エラー率 — HTTP 5xxエラー、LLM APIエラー、タイムアウトの発生率。1%未満が目標
• 可用性 — 正常に応答できる時間の割合。99.9%（月間ダウンタイム約43分以内）を目指す

構造化ログの設計

ミドリ(nodding)： 監視の指標はわかりました。ログはどう設計すればいいですか？

タツヤ(nodding)： まず大前提として、ログは構造化された形式（JSON）で出力する。非構造化テキストログでは大量のログからパターンを発見するのが困難だからね。

ログに含めるべきフィールド

タツヤ： 基本情報として、これらを標準化する。

• timestamp — ISO 8601形式のタイムスタンプ（UTC）
• request_id — リクエストを一意に識別するID。分散トレーシングに必須
• session_id — ユーザーセッションを識別するID。対話の流れを追跡
• user_id — ユーザー識別子（匿名化済み）
• action — 実行されたアクション（llm_call, tool_execution, cache_hit など）
• status — 成功/失敗/タイムアウト
• duration_ms — 処理時間（ミリ秒）
• model — 使用したLLMモデル名
• input_tokens / output_tokens — トークン使用量
• error_type / error_message — エラー情報（該当する場合）

ログレベルの使い分け

ミドリ： ログレベルって、全部INFOでいいんじゃないですか？

タツヤ： ダメダメ。重要度を区別しないと、本当に大事な情報が埋もれるよ。

• ERROR — 即座に対応が必要（LLM APIの連続エラー、クリティカルなツール呼び出し失敗）
• WARN — 注意が必要だが即座の対応は不要（レスポンスタイムのSLO超過、キャッシュミス率上昇）
• INFO — 正常な処理の記録（リクエスト完了、ツール呼び出し成功）
• DEBUG — 詳細なデバッグ情報（プロンプト全文、LLMの生レスポンス）。本番では通常無効化

ログの保存と管理

タツヤ： 保存にもルールがある。

• 保存期間 — 高頻度ログ（DEBUG/INFO）は7〜30日、重要ログ（WARN/ERROR）は90日〜1年
• 集約 — Elasticsearch、Loki、CloudWatch Logsなどで複数インスタンスのログを一元管理
• コスト管理 — ログの量は想像以上に増える。サンプリングやログレベルの動的切り替えでコストを管理しよう

分散トレーシングで「ボトルネックが一目でわかる」

ミドリ(confused)： 複数のコンポーネントをまたいで処理するとき、どこが遅いのか特定するのが大変そうですが……。

タツヤ： そこで分散トレーシングが活きる。1つのユーザーリクエストに対して、こういうスパン（処理区間）のツリーが構成される。

[ユーザーリクエスト] 全体: 3,200ms
  ├─ [入力処理] 50ms
  ├─ [ベクトル検索] 120ms
  ├─ [LLM呼び出し #1] 2,800ms ← ボトルネック
  │    ├─ [プロンプト構築] 10ms
  │    └─ [API呼び出し] 2,790ms
  ├─ [ツール実行] 150ms
  └─ [レスポンス整形] 80ms

ミドリ： おお、LLM API呼び出しが全体の87%を占めてるのが一発でわかりますね！

タツヤ： 推奨ツールとしては、ベンダー非依存のOpenTelemetry、LLM特化のLangSmith、オープンソースのLangfuseあたりがある。

アラート設計 ── 重要なものを見逃さず、うるさくもしない

ミドリ： 監視データを集めても、異常に気づけなかったら意味ないですよね。

タツヤ(nodding)： その通り。アラートの優先度分類が重要だよ。

ミドリ(confused)： 全部P1にしたら大変そう……。

タツヤ： まさに「アラート疲れ」って問題があるんだ。アラートが多すぎると運用チームが通知を無視するようになって、本当に重要なアラートも見逃す。防ぐための工夫は4つ。

• アラートの集約 — 同一原因のアラートはまとめて1件として通知
• 適切な閾値設定 — 最初は緩めに設定し、誤報率を見ながら調整
• 自動復旧の導入 — 一時的なエラーにはリトライ機構を設けて、自動復旧した場合はアラートを抑制
• 定期レビュー — 月1回、アラートの発生状況をレビューして閾値を見直す

ダッシュボードは「誰が見るか」で分ける

ミドリ： 監視データの可視化はどうすればいいですか？

タツヤ： 用途に応じて複数のダッシュボードを作るのがポイント。

エグゼクティブダッシュボード（経営層向け）

• エージェントの利用件数と成長率
• ユーザー満足度のトレンド
• 月間コストとROI
• 主要インシデントの件数

オペレーションダッシュボード（運用チーム向け）

• リアルタイムのリクエスト数とエラー率
• レスポンスタイムの分布
• インフラリソースの使用率
• 直近のアラート一覧

品質ダッシュボード（開発チーム向け）

• タスク完了率の推移
• ハルシネーション率の推移
• 機能別・カテゴリ別の品質スコア
• A/Bテストの結果

ミドリ： 経営層に「P99レイテンシが……」って言っても伝わらないですもんね。

タツヤ： そう。見る人に合わせた情報設計が大事。

品質モニタリングの自動化

ミドリ： 品質の監視って、人間が毎回チェックするんですか？

タツヤ： それだとスケールしないから、自動化する。2つの手法を組み合わせるよ。

サンプリング評価

タツヤ： 本番環境のリクエスト/レスポンスを5〜10%でサンプリングして、自動評価パイプラインで品質を判定する。

• LLM-as-a-Judge — 評価用のLLMが応答の正確性・網羅性・自然さを自動採点
• ルールベース評価 — 特定キーワードの有無、フォーマットの正しさをルールで判定
• リファレンス比較 — ゴールデンアンサー（模範回答）との類似度を計算

ドリフト検知

タツヤ： エージェントの出力分布が時間とともに変化（ドリフト）していないかを統計的に検出する。たとえば応答の平均長が急に短くなった、特定トピックへの言及率が変化した、といった変化を検知する仕組みだ。

ミドリ： あの「品質が徐々に下がる」問題に対処するわけですね。

タツヤ(nodding)： その通り。

まとめ

ミドリ： 今日の話をまとめるとどうなりますか？

タツヤ： AIエージェントの監視は「動いているか」を確認するだけじゃ足りない。「正しく動いているか」「品質を維持しているか」まで踏み込んだオブザーバビリティの構築が必要ってこと。

ミドリ： ポイントを整理すると？

タツヤ： 5つ。

• 4カテゴリ・12の指標（パフォーマンス、品質、コスト、信頼性）で多角的に監視する
• 構造化ログを標準化して、トラブルシューティングと分析の効率を高める
• 分散トレーシングでボトルネックを可視化して最適化対象を特定する
• アラート設計で重要な問題を見逃さず、アラート疲れも防ぐ
• 品質モニタリングをサンプリング評価とドリフト検知で自動化する

ミドリ： 「品質が徐々に劣化する」ってのが怖いですね。気づかないうちに……ってならないようにしないと。

タツヤ： だからこそ、仕組みで検知する体制が必要なんだ。

次のアクション

タツヤ(nodding)： まずは今のAIエージェントのログ出力を確認して、上で説明した「ログに含めるべきフィールド」がすべて記録されてるか棚卸ししてみて。不足フィールドを追加するだけでも、トラブルシューティングの効率が大きく向上するよ。

ミドリ(confused)： オブザーバビリティ基盤の設計で困ったら？

タツヤ： Shimanto AI Solutionsが監視戦略の策定からダッシュボード構築まで支援してくれる。運用チームが自律的に品質を維持できる体制づくりをサポートしてもらえるよ。