「動いた」は完成ではない
AIエージェントを構築した企業の多くは、初めてエージェントが意図通りに動作した瞬間を完成点だと感じる。その感覚は理解できる。プロンプト設計に何週間もかかり、ツール連携でバグを潰し続け、ようやく期待通りの出力が出たときの達成感は本物だ。
だが、それは出発点に過ぎない。
本番環境に展開したAIエージェントは、時間とともに静かに劣化する。モデルがアップデートされる。社内文書の内容が変わる。エージェントが扱う入力の分布が少しずつずれていく。誰も気づかないまま、品質は2週間かけてゆっくりと下がっていく。エラーログには何も出ない。ユーザーは「なんかAIの精度が下がった気がする」と思いながら、他の問題に追われて放置する。
このパターンを「品質ドリフト」と呼ぶ。AIエージェントを本番運用した企業の32%が品質問題を主要な課題として挙げており（出典: Digital Applied Survey, 2026年）、その多くがドリフトの発見が遅れたことを原因に挙げている。
本記事では、AIエージェントの本番運用で起きる典型的な問題パターンを整理した上で、監視・評価・改善のサイクルを設計するための実践的なフレームワークを解説する。
本番AIエージェントで起きる7つの問題パターン
問題を把握していなければ、対策は設計できない。本番稼働するAIエージェントで記録された典型的な障害を7つに分類する。
1. ツール誤使用（本番障害の31%）：正しいツールを選ばない、ツールに渡す引数が不正、「ツールを呼んだふり」をして実際には何もしないケース。これが最多の障害原因だ（出典: Trantor Inc Research, 2025年）。特に問題なのが「ゴーストアクション」——エージェントがツールを呼び出したと報告するが、実際のAPI呼び出しは発生していないケース。ログがなければ検知できない。
2. 品質ドリフト（最も検知が遅れる）：前述の通り、エラーなしに精度が漸進的に低下する。「回答は返ってくるが、微妙に的外れ」という状態が数週間続く。モデルのアップデート、入力分布の変化、参照する社内文書の変化が主因。
3. 目標ドリフト：特にマルチターンの会話エージェントで起きる。エージェントが複数のやり取りを経るうちに、元の目的から外れた方向に動き始める。最初は正しい方向に進んでいたのに、途中から関係ない話題に引き込まれたり、不要なサブタスクを増殖させる。
4. 無限ループとコスト爆発：自己修正エージェントが修正のためにサブエージェントを召喚し、それがさらにサブエージェントを召喚するカスケードが発生する。1つのタスクで想定の10〜50倍のAPIコストが発生することがある（出典: Braintrust Research, 2025年）。月次請求が届いてはじめて気づく企業が続出している。
5. プロンプトインジェクション：ユーザー入力や外部データに含まれた悪意のある指示がエージェントの動作を乗っ取る。エージェントが外部コンテンツを取得・処理するほど、このリスクは高まる。
6. 静かなハルシネーション増幅：単独クエリでの幻覚は小さくても、エージェントが複数ステップで処理するとその誤りが後段で増幅・拡散する「カスケード幻覚」が発生する。初期エージェントの0.5%のエラーが、5段階の処理を経ると2〜3%に増幅することがある。
7. マルチエージェントの連鎖障害：エージェントAの出力がエージェントBに渡り、Bの出力がCに渡る構造で、Aで発生した問題がC時点で大きな誤りとして顕在化する。問題の発生源の特定が難しく、デバッグに時間がかかる。
なぜ従来のシステム監視では足りないのか
ここで立ち止まって考えたい問いがある。「従来のシステム監視（サーバーの稼働率、APIのエラー率、レスポンスタイム）を入れれば十分ではないか？」
答えは否だ。AIエージェントの障害の多くは、システムとしては正常に動作しながら、意味的に間違っているという形で発生する。
APIはHTTP 200を返している。レスポンスタイムは正常範囲内だ。エラーログには何も記録されていない。にもかかわらず、エージェントは「自信を持って間違った回答」を出し続けている。これを「Well-formed but wrong（形式的には正しいが内容が間違っている）」な障害と呼ぶ。
従来のシステム監視はこれを検知できない。必要なのは、意味的な正しさ（Semantic Correctness）を評価する仕組みだ。これがAIエージェント固有の監視設計を必要とする理由だ。
図1: AIエージェント監視の3層構造。Layer 3（意味的評価）がAIエージェント固有の追加要素。
監視で計測すべき具体的メトリクス
AIエージェントの監視では、従来のシステムメトリクスに加えて、エージェント固有のメトリクスを計測する必要がある。
オペレーショナルメトリクス（Layer 1 + 2）
まず基本的なインフラ・オペレーション指標:
- タスク完了率（Task Completion Rate）：エンドツーエンドでタスクが成功した割合。最も基本的な健全性指標
- ステップあたりのレイテンシ：各処理ステップの実行時間。急増は異常のサインになる
- トークン使用量：入力・出力トークン数の推移。先週比150%超は要調査
- ツール呼び出し成功率：外部ツール・APIへの呼び出しが正常に完了した割合
- コスト/タスク：1タスクあたりのAPIコスト。バジェットエンベロープの逸脱を検知する
品質メトリクス（Layer 3）
意味的な品質を評価する指標:
- 引数正確性（Argument Correctness）：ツールに渡した引数が意味的に正しかったかの評価
- ツール選択正確性：文脈に対して正しいツールを選んだかの評価
- タスク関連性（Task Relevancy）：出力がタスクの目的に沿っているかのスコア
- 回答の正確性（Answer Accuracy）：LLM-as-Judgeで評価する正確性スコア
- ユーザー満足度（CSAT）：利用者からの直接フィードバック（単純な👍👎でも有効）
参考値として、2025年のカスタマーサービスエージェントの業界平均はタスク完了率70〜75%（世界クラスは85%以上）、CSAT 78%（上位10%は90%超）となっている（出典: Master of Code Research, 2025年）。
監視スタックの選択と構成
ツールの選択は「何を最優先で監視したいか」で決まる。2026年時点の主要ツールを用途別に整理する。
| ツール | 強み | 最適なチーム |
|---|---|---|
| LangFuse | 完全オープンソース・自己ホスト可能・ゼロライセンスコスト | コスト・データ所在を優先するチーム（最初の1ツールとして推奨） |
| LangSmith | LangChain/LangGraphとの深い統合・ノード別の状態差分確認 | LangChain系のスタックを使っているチーム |
| Arize Phoenix | 埋め込みベクトルの分析・ドリフト検知に特化 | ドリフト検知を最優先にするチーム |
| Braintrust | 評価ループとCI/CD統合・自動最適化 | 継続的な評価改善サイクルを回したいチーム |
| Weights & Biases Weave | マルチエージェントの親子関係トレーシング・実験管理 | 研究寄りの開発・マルチエージェント構成 |
重要なのはツールを選ぶより先に「何を計測するか」を決めることだ。ツールを先に導入すると、計測したいものではなくツールが取れるデータを計測するようになる。
アラート設計：何が起きたら誰に通知するか
監視データを取っていても、アラートの設計が甘いと気づくのが遅れる。実践的なアラート設計の5パターンを示す。
図2: 本番AIエージェントの5種アラート設計。優先度に応じてルーティング先を分ける。
評価フレームワーク：何をどう評価するか
アラートは「おかしい」という信号だ。何がおかしいのかを判断するには、体系的な評価フレームワークが必要になる。
シングルターン vs マルチターンの違い
評価指標は、エージェントの動作モードによって異なる。重要な区別がある: 「マルチターン」のカウントは、ユーザーとの実際のやり取り回数で計測する。エージェント同士の内部連携のターン数ではない。
シングルターン（1回の入力で完結するタスク）で見るべき指標:
- タスク完了 — 成功/失敗の判定
- 引数正確性 — ツールに渡した引数の意味的正確さ
- ツール選択正確性 — 適切なツールを選んだか
マルチターン（会話・複数回のやり取りを要するタスク）で見るべき指標:
- 会話完結率 — 全体の目標がやり取りを通じて達成されたか
- ターン関連性 — 各返答が会話の目的と関連しているか
- 一貫性 — 複数ターンにわたって矛盾が生じていないか
LLM-as-Judge（AIを使った評価）の活用
人間がすべての出力を評価することは、本番スケールでは現実的でない。LLM-as-Judge（別のLLMを使って出力を評価する手法）を組み合わせることで、自動評価の範囲を広げられる。
有効な用途:
- 回答の関連性・正確性スコアリング（0〜1のスコアで数値化）
- 有害コンテンツ・ポリシー違反の検知
- 回答が参照文書に基づいているかの検証（RAG評価）
注意点: LLM-as-Judgeは評価精度に限界がある。人間レビューと組み合わせることが前提で、100%の精度を期待してはいけない。ただし、問題のある出力を80〜90%の確率でフラグできるだけで、人間の確認工数を大幅に削減できる。
Lat91での実装と得た教訓
私たちは社内業務を自動化する10体のAIエージェントを本番運用しています。SEO記事生成、X投稿自動化、モーニングブリーフィング、フォーム営業の送信管理——これらを複数のAIエージェントが日次で処理しています。
最初の1年間、私たちはほぼ監視なしで運用していました。エラーが出ていないから大丈夫、という判断でした。それが間違いだったと気づいたのは、SEO記事エージェントの品質が2週間かけて静かに劣化していたとき。外部指摘で発覚しました。
その後、以下の3つを実装しました。
第一に、全エージェントのトレースログ化（LangFuse使用）。各エージェントが何を入力として受け、何を出力として返し、どのツールをどの引数で呼び出したかを全件記録するようにしました。これで「いつ、何が変わったか」の遡及調査が可能になりました。
第二に、週次サンプリング評価。各エージェントの出力から週10〜20件をランダム抽出し、担当者が15〜30分で評価する仕組みを作りました。評価基準は簡単なルーブリック（正確性・関連性・完結性の3軸、5段階）に統一。スコアの推移を見ることで、劣化を2週間以内に検知できるようになりました。
第三に、コスト/タスクのアラート。週平均から50%超のコスト増が発生した場合に自動通知する設定を入れました。実際に1度、自己修正ループが暴走したとき、このアラートで10倍コストが出る前に気づいて停止できました。
これらの設定に要した時間は合計で2〜3日。費用はLangFuseの自己ホスト運用コストが月数千円程度。投入コストに対して、問題の早期発見で節約できたデバッグ時間と評判リスクは、これを大きく上回りました。
実装のロードマップ：3段階で構築する
「完璧な監視システムをいきなり構築しなければ」と考えると動けなくなる。段階的に実装することを推奨する。
Day 1（最小限から始める）:
- LLM呼び出しとツール呼び出しをトレースする（LangFuse導入）
- エラーを全件記録し、全実行を可視化する
- コスト/タスクをトラッキングし始める
Week 1（文脈を広げる）:
- 推論ステップをトレースに追加する
- コスト/タスクを計測し始め、ベースラインを確立する
- 初期の失敗事例を評価データセットとして保存する
Week 2以降（本番化する）:
- 評価ゲートをCI/CD（または定期実行）に組み込む
- 異常検知アラートをSlack/Webhookに接続する
- 週次サンプリング評価のルーティンを確立する
Amazonのエージェント開発チームが共有した教訓が参考になる: 「エージェントが何かをした理由を説明できない場合、そのエージェントを制御しているとは言えない」（出典: AWS Machine Learning Blog, 2025年）。トレースは「説明責任」のインフラだ。
企業規模別の導入実績から見えること
大企業での導入事例を見ると、監視・評価の設計がROIに直結していることがわかる。
JPMorgan Chaseは450以上のAIユースケースを本番運用しており、契約インテリジェンスシステム（COiN）では年間36万時間の弁護士業務が自動化された。この規模の運用が可能になったのは、全システムに統一された評価・監視フレームワークが存在するからだ。ヒューマンレビューの配置も、ツールレベルではなくシステム設計レベルで決定されている（出典: JPMorgan Annual Report, 2025年）。
一方、Klarnaのケースは別の教訓を提供する。853人分の相当業務をAIエージェントに置き換えることで6,000万ドルの節約を達成したが、感情的に高度なクエリで品質問題が顕在化し、その後AIのみ対応から人間との組み合わせ対応に戦略を修正した（出典: Klarna Annual Report, 2025年）。「監視して修正できたこと」が失敗ではなく、むしろ健全な運用のサイクルだ。
2026年の調査では、AIエージェントのデプロイメントで平均171%のROIが報告されており、ROIを1年以内に達成した企業が74%に上る（出典: Digital Applied ROI Research, 2026年）。このROIを実現している企業に共通するのは、監視・評価・改善のサイクルを最初から設計している点だ。
2028年のエージェント運用
AIエージェントの自律度は今後3年で大幅に高まる。2028年には、現在の「アシスタント型」エージェント（人間が確認しながら進める）から、「自律型」エージェント（人間の承認なしに長時間のタスクを実行する）へのシフトが加速すると予測している。
このシフトに伴い、監視・評価の重要性はさらに高まる。自律度が上がるほど、問題が顕在化するまでの「距離」が伸びる。人間が途中で気づくチェックポイントが減るため、発見が遅れた問題の被害も大きくなる。
「まずはエージェントを動かす、監視は後で」というアプローチは、2024〜2025年の初期段階では通用した。2026年以降、本番稼働するエージェントの数が増えるにつれ、監視なしの運用は技術的負債ではなくビジネスリスクとして扱われるようになる。早めに設計に組み込むことを強く推奨する。
まとめ：AIエージェントは「育てる」もの
AIエージェントの本番運用は、ソフトウェアを「デプロイして終わり」にするのとは根本的に異なる。モデルが変化し、入力が変化し、世界が変化する中で、エージェントは継続的に「育てる」必要がある。
本記事のポイントを整理する:
- 本番AIエージェントの障害は7種類あり、31%はツール誤使用から発生する
- 「形式的には正常だが意味的に間違っている」障害は従来の監視では検知できない
- 3層（インフラ監視・トレース観測・意味的評価）を組み合わせて初めて網羅的に検知できる
- Day 1はトレース記録とコスト監視から始める。完璧を目指さず段階的に拡張する
- 週次サンプリング評価と5種のアラート設計が最低限のベースライン
「エージェントが何をやっているかわかっているか？」——この問いに自信を持って「はい」と答えられる状態が、AIエージェントの本番運用の到達点だ。
Lat91では、AIエージェントの設計・導入から本番運用・監視体制の構築まで、一気通貫でサポートしています。
「AIエージェントを本番展開したいが、監視・評価の設計が不安」という方は、まずは無料相談からお気軽にどうぞ。