AIエージェントの失敗をどう検知するか — 運用監視の設計思想

AIエージェントの本番稼働は急速に広がっている。LangChainが2025年末に実施した「State of Agent Engineering」調査（1,300名超を対象）によれば、57.3%の組織がAIエージェントを本番環境で運用しており、従業員1万人超の大企業では67%に達する。しかしその拡大に、監視体制の整備が追いついていない。同調査で本番稼働している組織の94%が何らかの可観測性を実装する一方、詳細なトレーシングまで実施しているのは71.5%にとどまる。「動いている」と「正しく動いている」は別の話であり、その差を埋める監視設計が、AIエージェント運用の次の経営課題として浮上している。

AIエージェントの失敗には、従来のシステム監視では捉えられない特性がある。サーバーは正常稼働し、APIのレスポンスも200を返し、処理は完了している。しかし出力されたデータが事実と異なるか、本来踏むべき承認ステップを素通りしているか、あるいは無意味なループが延々と続いているかは、ログを見ただけでは分からない。SELF株式会社の調査が整理するように、AIエージェントの監視対象は「業務成果」「回答・判断の品質」「運用品質」「リスク」の4領域に分かれ、それぞれ異なる指標と閾値の設計が必要になる。サーバー死活監視とプロセス完了率だけに頼る運用体制は、表面上は問題がないように見えながら実際には誤った判断を積み上げ続けるリスクを内包している。

失敗のパターンを類型化すると、実務上は5種類に収束する。第一は「誤実行」で、本来不要な更新・送信・検索が発生するケースだ。第二は「承認フロー逸脱」で、顧客データの変更や金額確定の場面で確認を飛ばす。第三は「ループ・過剰再試行」で、同じtool callが連打される状態。第四は「コスト急増・遅延悪化」で、品質は保ちながらAPI費用や応答時間が想定を大幅に超える。第五は「挙動変化」で、成功率や経路選択の分布がベースラインから外れ始めるパターンだ。これらの多くは単独では致命的でないが、複合することで業務上の損害が顕在化する。初期段階では「高リスクtool callの呼び出し回数」「承認ステップのスキップ率」「同一toolの連続呼び出し回数」の3指標だけを計測するだけでも、主要な異常の多くを捕捉できる。

「観測（Observability）」と「評価（Evaluation）」は目的が異なるため、設計を分離することが重要だ。ObservabilityはAgentの本番稼働中にリアルタイムで逸脱を検知する仕組みであり、Evaluationはデプロイ前にゴールデンデータセットで品質を測定する仕組みである。LangChainの調査では組織の89%がObservabilityを導入している一方、Evaluationの実施は52.4%にとどまる。「出した後に見る」だけで「出す前に測る」体制が欠けている状態は、本番で発覚した問題を後追いで修正するサイクルに陥りやすい。Uravation社の調査では、観測ツールを導入しているチームは非導入チームと比べて品質低下の検知速度が10〜30倍速いとの報告があり、検知の速度差が障害の影響範囲を左右することを示している。

アラートの設計は「重みの階層化」が要点になる。「情報通知」（軽微な遠回りの増加）・「要注意」（コストのトレンド上振れ）・「要エスカレーション」（高リスク操作の発生）・「即停止」（誤送信や権限逸脱）の4段階を事前に定義し、それぞれのアクションオーナーを明示しておくことが前提となる。閾値を厳しく設定しすぎると通知が氾濫してアラート疲れを生み、緩く設定しすぎると本質的な逸脱が埋もれる。業界標準の方向性として、OpenTelemetry（OTel）がLLM・エージェントのトレーシング仕様の事実上の共通基盤として収束しつつあり、主要な観測ツールの多くが2026年末までにこのスキーマに対応すると見込まれている。監視ツールの選定よりも、何を閾値とするかを業務側が決める意思決定が先行すべきであり、この順番が逆になっているプロジェクトが多い。

経営層が問うべき問いは「誰が監視体制の設計を決めるか」だ。エージェントが扱う業務が顧客対応・審査・発注といった外部影響の大きな領域に踏み込むほど、技術部門だけで閾値を決める体制は機能しなくなる。「承認を要する操作の範囲はどこまでか」「品質の許容水準は何%か」「異常が検知された際に誰がどの権限で止めるか」は、経営判断を必要とする問いであり、設計フェーズで事業部門と合意しておかなければ、問題が起きた後に帰属の議論が始まる。当社では、AIエージェントの権限境界と監視設計を経営意思決定として位置づけ、運用開始前に「承認境界の設計書」を明示化することを推奨している。これはITガバナンスの文書でなく、事業リスクの管理文書として扱うべきものだ。

AIエージェントの運用監視は、エンジニアリング課題ではなく経営管理の課題として設計するべきだ。サーバーが止まっているかどうかを監視するのではなく、エージェントが正しい判断をしているかどうかを継続的に問い続ける仕組みが必要となる。当社はヘルスケア経営の現場で、判断の誤りが即座に患者リスクに転化する環境でこの設計を実装・検証してきた。「現場で確認できていないことは提案しない」という規律のもとで積み上げた実装知見を、大企業・中堅企業のAIエージェント導入支援に展開している。AIエージェントの運用監視設計、承認境界の策定、品質評価指標の構築についての経営層ブリーフィングをご希望の場合は、https://fujii-consulting.jp/contact よりご相談ください。