AIエージェント失敗の調査手順｜原因分類と再発防止

AIエージェントが失敗したとき、見るべきなのは派手な誤回答や誤操作そのものではなく、その失敗を生んだ調査対象の連鎖です。
導入現場では、要件の曖昧さやデータ品質、権限設計、運用不足まで原因がまたがるため、症状だけ追っても再発は止まりません。

本番直後のデプロイで誤操作が連鎖して障害化した案件でも、影響範囲、直前変更、自動実行の有無という5分の初動チェックだけで、優先度と封じ込め策をその場で決められました。
この記事は、AIエージェント運用や『Cursor』『Claude Code』のようなエージェント機能を扱う開発・運用担当者に向けて、定量データと公式資料を土台に、5ステップの調査、原因分類、RCAとCAPAまでを一本の流れで整理します。
再発防止には症状ではなく根本原因の特定が欠かせません。
単一エージェントの不具合だけでなく、マルチエージェント特有の協調失敗やカスケード失敗まで見抜ける観測項目を持てば、失敗対応は場当たり的な火消しから、再発を減らす運用設計へ変えられます。

AIエージェントの失敗はまず何を切り分けるべきか

失敗の定義とスコープ設定

AIエージェントの調査は、まず「何を失敗とみなすのか」を固定しないとぶれます。
ここが曖昧なままログを追うと、誤回答を直したのにSLO違反は残り、ツール実行エラーを潰したのにセキュリティ逸脱は未解決、という空振りが起きます。
失敗はひとつの顔ではありません。
期待仕様からの逸脱としての誤回答・誤操作、外部APIや社内システムに対するツール実行失敗、エラー率の上昇やレイテンシ悪化によるSLO違反、想定外の権限行使やPIIの不適切な取り扱いといったセキュリティ逸脱まで、観測対象を分けて扱う必要があります。

この切り分けが必要なのは、AIエージェントの失敗がモデル単体の精度問題に閉じないからです。
導入現場では、目的の曖昧さ、期待値の置き方、データ品質、運用設計、権限設定、承認フローまでが失敗要因になります。
表面上は「変なことをした」で同じでも、根はまったく違います。
症状と原因を分離して考えないと再発防止に届きません。

スコープ設定では、少なくとも「どのユースケースで」「どの期待仕様に対して」「どの観測指標が外れたのか」を決めます。
たとえば『Cursor』のBackground Agentでコード修正提案が暴走したのか、『Claude Code』でレビュー結果は妥当でも外部コマンド実行の権限設計が崩れたのかでは、見るべきログも担当者も変わります。
ここで対象を「1回の不正動作」だけに縮めると、初期の小さな判断ミスが後続に連鎖するカスケード失敗を見落とします。
エージェント障害は単発エラーではなく、途中で入った誤った前提が次の判断を歪め、最後に障害として表面化する流れで捉えたほうが実態に合います。

なお、AI導入の失敗率やパイロット撤退率に関する数値は、調査ごとに定義や母集団が異なり大きく幅があります。
たとえば「AIパイロットの95%が失敗する」「2027年末までに約40%が中止される」といった予測値は、一部の報告や報道に基づくもので前提条件や調査範囲が異なります。
これらの数値は出典と定義を明示したうえで参考値として扱うか、あるいは「ある。
本稿では数値の比較よりも、目の前の障害をどの単位で切り分けるかを重視してください。

根本原因分析とは ｜ IBM

根本原因分析 (RCA) とは、組織が問題、課題、インシデント発生後にその根本原因を探索する品質管理プロセスのことです。

www.ibm.com

単一エージェントとマルチの違い

単一エージェントの失敗は、比較的まっすぐ追えます。
期待した出力が出ない、ツール呼び出しに失敗する、権限不足で止まる、参照データが汚れていて誤判断する、といった形です。
調査の起点も、実行ログ、API応答、プロンプト、入力データ、権限設定に寄せられます。
ログは運用上の問題や異常の原因特定の中核になります。

一方で、マルチエージェントになると調査対象は「個体」から「相互作用」へ広がります。
各エージェントの能力が足りないというより、役割分担の不整合、共有状態の欠落、他エージェントの出力の無視、終了条件の認識ズレが失敗を生みます。
この協調設計の崩れが中心論点です。
調査では「誰が間違えたか」だけでは足りず、「どの状態を共有していたか」「どの時点で前提が分岐したか」「終了判定を誰が持っていたか」を追う必要があります。

単一エージェントではログを1本の時系列として見れば足りる場面が多いのですが、マルチエージェントではタイムラインの突き合わせが欠かせません。
たとえばプランナー役が古い要件でタスクを分解し、実行役が最新データで動き、レビュー役が別の終了条件で完了を返すと、各自は局所的に正しく動いていても全体は破綻します。
ここで効くのが、不変条件の明文化です。
共有状態に必ず含まれる項目、引き継ぎ時に欠落してはいけない値、完了判定に必要な条件を固定すると、協調失敗の検出点を置けます。

現場で見てきた感覚では、マルチエージェントの障害は「犯人探し」を始めた瞬間に長引きます。
個々の応答品質を見ても決着せず、役割設計と状態同期の欠陥が残るからです。
逆に、責務・共有状態・終了条件の3点に調査軸を寄せると、どのエージェントを直すべきかではなく、どの接続面を修正すべきかが見えてきます。

初動チェックリスト

初動の5〜10分で見るべき点は多くありません。
影響範囲、直前の変更、自動実行の有無の3つです。
ここを先に押さえるだけで、調査の順番と封じ込め策が決まります。
とくに自動実行の有無は、現場では真っ先に確認する価値があります。
承認を挟まずに本番操作や外部送信まで進む構成だったと分かった時点で、承認フローを一時的に復活させる安全策をその場で打てた場面が何度もありました。
原因がまだ見えていなくても、被害の連鎖を止めるには十分です。

印刷やコピペでそのまま使える形にすると、初動の迷いが減ります。

この3点を見る理由は明快です。
影響範囲が分からないまま深掘り調査に入ると、軽微な誤回答と重大なデータ破損が同じ重みで扱われます。
変更履歴を押さえないと、障害の直前に入ったプロンプト更新やRBAC変更を見落とします。
自動実行の有無を外すと、障害が現在進行形か、いったん人手で食い止められる状態かも判断できません。
AWS DevOps AgentのIncident Response機能が investigation timeline や root cause analyses、mitigation plans を前面に出しているのも、初動で時系列と封じ込めを切り分けるためです。

対処アプローチの比較

調査アプローチは、大きく分けると症状ベース、ログベース、RCAベースの3つです。
どれかひとつが万能なのではなく、初動では症状ベースで封じ込め、事実確認ではログベース、再発防止ではRCAベースへ移る流れが実務に合います。
症状だけで終えると火消しで止まり、RCAから入ると初動が遅れます。

単一エージェントでは、症状ベースからログベースへ移るだけで相当の問題が解けます。
プロンプト逸脱なのか、データ品質なのか、権限不足なのかを見分けやすいからです。
マルチエージェントでは、ログベースの粒度を一段上げる必要があります。
個別ログだけでなく、共有状態の差分、エージェント間の受け渡し時刻、終了条件の評価結果まで並べないと、協調失敗が見えません。
ここでRCAをかけると、個々の失敗ではなく「役割定義が重複していた」「共有すべき状態が blackboard 的に管理されていなかった」「不変条件が設計されていなかった」といった構造上の問題に届きます。

実務では、症状ベースを軽視しないことも欠かせません。
障害対応の場では、まず止血が必要です。
ただし、そのまま終えると「次回も承認フローを戻してしのぐ」だけになります。
ログベースで事実を固め、RCAで設計の欠陥まで掘る。
この3段を踏むと、単発の誤動作を処理しただけで終わらず、運用設計の修正まで話を進められます。

失敗発生時の調査手順5ステップ

このセクションは、障害対応チャネルにそのまま貼れる順番で並べています。
ポイントは、症状を追いかけるのではなく、被害の広がりを止めながら、再現条件と証拠を固定し、因果関係を1本の線にすることです。
AWS DevOps Agentの incident response でも、investigation timeline、root cause analyses、generated mitigation plans が連続して見える構成になっていて、現場の流れとしてもこの順番に無理がありません。

1. 影響範囲確認

最初に見るのは「何が壊れたか」ではなく、「どこまで広がったか」です。
影響ユーザー数、金額影響、データ破損の有無、外部送信の有無を先に確定します。
AIエージェントの障害は、誤回答だけで終わるケースと、誤ったツール実行やデータ更新につながるケースで初動がまったく変わります。
Cybersecurity Insidersの2026年調査では、AIエージェント起因の運用問題を経験した回答者が37％おり、そのうち8％は停止やデータ破損レベルでした。
ここで影響を甘く見積もると、後の調査が正しくても封じ込めが遅れます。

見る項目は4つに絞るとぶれません。
1つ目は影響ユーザーが限定的か全体か。
2つ目は売上、課金、工数のどこに金額影響が出ているか。
3つ目は更新系処理でデータ破損、削除、誤上書きが起きていないか。
4つ目はSLO違反がどの指標で起きているかです。
SLOは内部目標なので一律の標準値はありませんが、エラー率、成功率、遅延のどれが崩れたかを明記すると、停止・隔離・ロールバックの判断材料になります。

この段階では、結論を長文で書くより1枚で読めるサマリが効きます。実務では次のような形で残すと、その後のエスカレーションが速くなります。

ここでの成果物は1枚サマリです。会議に入っていない人でも3分で状況が追える粒度にしておくと、技術者だけで抱え込まずに済みます。

1. 再現条件確認

影響範囲を押さえたら、次は再現条件を固定します。
入力、前提状態、権限、時刻、外部依存を揃えずに試すと、調査ログだけが増えて原因が薄まります。
AIエージェントの失敗は、同じプロンプトでも、モデル切り替え、トークン権限、外部APIの応答差、データ更新時刻で結果が変わります。
単に「再現した」「再現しない」では情報が足りません。

筆者はここで、入力値と権限だけでなく、モデルバージョンと外部API改修日を必ず固定するようにしています。
実際にこの2項目を再現条件シートへ入れただけで、原因切り分けにかかる時間が半分になった場面がありました。
アプリ側の変更を疑っていたのに、実際は推論モデルの切り替えと外部API仕様変更の組み合わせで挙動が変わっていた、というケースです。
AIエージェントは自前コードだけ見ていても埒が明かないことがあるんですよね。

確認項目は、入力データ、対象ユーザー属性、実行ロール、対象環境、本番時刻、依存APIとDBの状態です。
マルチエージェント構成なら、どのエージェントが先行し、どの共有状態を読んでいたかも含めます。
再現しない場合は「障害が消えた」と扱わず、一過性イベント、外部依存の揺れ、観測不足の3つに分けて記録します。
後述のFAQで扱う「再現しない場合」の分岐に備えるためにも、この時点で「何を固定したのに再現しなかったか」を残すことが欠かせません。

成果物としては、次のような再現条件メモがあれば十分です。

1. ログ・トレース確認

再現条件が固まったら、ログとトレースを1本の時系列にまとめます。
ここで重要なのは、プロンプトログ、ツール呼び出し、APIレスポンス、モデル名とバージョン、エラー率、直前デプロイ、設定差分を別々の画面で見るのではなく、同じタイムライン上に並べることです。

筆者の現場では、タイムライン化したことで「権限エラーが起きたあと、フォールバック処理が走り、その代替ツールが誤った更新を実行した」という連鎖が見えたことがありました。
ログを個別に読んでいたときは、権限エラーと誤更新が別件に見えていたのですが、1枚に並べるとカスケード失敗としてつながります。
ここが見えると、手戻りが減ります。
最初のエラーを直すべきなのか、フォールバック設計を止めるべきなのかが整理できるからです。

時系列には、少なくとも次の列を入れます。
時刻、コンポーネント、イベント種別、入力要約、実行結果、エラーコード、関連変更です。
トレースIDを持っている基盤なら追跡がより明確ですが、製品によってはW3C Trace Contextの自動伝播が明示されていないものもあります。
その場合でも、リクエストID、ジョブID、会話ID、ツール実行IDを仮の結合キーとして使えば、調査には十分役立ちます。

ここでの成果物はタイムライン表です。
障害会議では、口頭説明よりこの表のほうが強いです。
直前デプロイや設定変更も同じ表に入れると、「変更後に失敗率が上がった」のか、「変更前から断続的に起きていた」のかが見えてきます。
AWS DevOps Agentが investigation timeline と RCA を並べているのも、この因果の見え方を重視しているからだと感じています。

1. ツール/権限/データ確認

ログで失敗地点が見えたら、次は周辺条件を点検します。
AIエージェントの障害では、ツールそのものより、権限不足・スコープ違い・データ不整合が原因になっていることが多いです。
前のセクションでも触れた通り、要件や運用設計の問題もありますが、初動調査ではまず実行基盤の事実を潰します。

権限まわりでは、IAMロール、アクセストークン、OAuthスコープ、RBAC割当を確認します。
RBACはロール単位で権限を与えるので、想定した役割に対して実行権限が不足していないか、逆に広すぎないかを見る必要があります。
ここでありがちなのが、本来読むだけの権限しかないエージェントが書き込み系ツールをフォールバック先に持っている状態です。
権限エラー自体は正しい挙動でも、後続の設計が危険だと別の事故につながります。

ツールまわりでは、APIクォータ、レート制限、タイムアウト、サーキットブレーカー設定を確認します。
調査を並行で走らせるときは基盤側の制約も意識したいところで、たとえばAWS DevOps Agentの公開プレビューでは concurrent incident resolution investigation が3件です。
調査並行度に上限がある環境では、「全部同時に掘る」より、影響範囲順に調査対象を絞ったほうが証拠の質が落ちません。

データ面では、鮮度、Null、型不整合、参照切れ、主キー不一致を見ます。
AIエージェントは入力を自然言語で受けるため目立ちませんが、裏側で参照している表やJSONが崩れていると、誤った判断をもっともらしく返してきます。
PIIのマスキングも見逃せない判断材料になります。
マスキング自体は必要ですが、判定キーまで伏せてしまうと照合失敗が起き、別人データを引けないまま「該当なし」と判断することがあります。
セキュリティ対策がそのまま機能障害の入口になる場面です。

この段階の成果物は、確認チェック結果を残した表です。

1. 根本原因分析と再発防止

ここまでで証拠が揃ったら、なく、再発する仕組みを言語化します。
根本原因分析は、表面的な事象ではなく、再発防止につながる原因を特定するための手法です。
症状と原因を分けて考えることが分析の軸になります。
AIエージェントでは、単一の技術不具合だけでなく、役割設計、終了条件、運用ルール、期待値の置き方まで原因がまたがるので、RCAを省くと「設定を戻した」で止まります。

進め方は、まず5 Whysで因果を1本掘ります。
そのうえで、フィッシュボーン図で「人・プロセス・ツール・データ・権限・運用」に広げると、単線の思い込みを防げます。
5 Whysだけだと、複合要因を1本の物語に寄せすぎることがあるからです。
マルチエージェント構成なら、情報共有不足、役割不整合、終了条件の曖昧さも原因候補に入れます。
Microsoft Security Blogが agentic AI systems の failure taxonomy を整理しているのも、失敗を単一のバグではなく分類可能な構造として扱うためです。

RCAシートは、次の4列を持たせると実務で回ります。
症状、直接原因、根本原因、検証結果です。
仮説のまま閉じず、どの証拠で裏づけたかまで書きます。
そのうえでCAPAに落とします。
CAPAは是正処置と予防処置を分けて、責任者、期限、効果測定指標を付ける運用です。
担当と期日がない再発防止策は、会議では立派でも現場では消えます。

CAPAリストは次の形が使いやすいのが利点です。

このステップの成果物はRCAシートとCAPAリストです。
ここまで残せていれば、単発の火消しで終わらず、同型障害を次回の設計レビューで潰せます。
AIエージェント導入では、失敗率や成功率の調査ごとに定義が違うため、数値だけで危機感を煽るより、自社の失敗をどう再発防止へ接続するかのほうが運用価値は高いです。
今回の5ステップは、その接続をぶらさずに進めるための最低限の型として機能します。

ログ・トレースで見るべきポイント

観測項目一覧

AIエージェントの障害調査でまず整えたいのは、ブラックボックスに見える挙動を「いつ・何を・なぜそう判断したか」に分解して追える状態です。
派手な誤回答だけを見ても、真因はたいてい分かりません。
判断の入口になったプロンプト、途中で実行したツール呼び出し、外部APIの応答、そしてその時点の権限や設定変更まで、事実を横に並べて初めて因果が見えます。

観測対象の中心になるのは、まずプロンプトです。
ユーザー入力だけでなく、システムプロンプト、タスク指示、動的に差し込んだコンテキストを分けて残します。
ここが一塊だと、モデルの判断が変わった理由を追えません。
次に見るのがツール呼び出しで、関数名だけでは足りず、引数、実行回数、リトライの有無、タイムアウト、失敗時のフォールバックまで必要です。
実務では、ツール呼び出しの引数ロギングを追加しただけで、文字列を期待する場所に配列が入っていた型不一致がその場で見え、再現手順をこね回す時間が一気に減ったことがありました。
ツール名だけのログでは、この種の不具合は埋もれます。

その先にあるAPIレスポンスも、HTTPコードだけで判断しないほうがいい場面が多いです。
200が返っていても本文の業務エラーで失敗していることがありますし、429や5xxは一時的な外部要因か、こちらのリトライ設計不足かを切り分ける材料になります。
レスポンス本文、HTTPコード、所要時間をまとめて残しておくと、アプリ側の失敗と依存先の失敗を分けやすくなります。
あわせて、エラー率、レイテンシ、成功率、コスト/トークンは最小監視セットとして常時見たい指標です。
これに重要操作の監査ログ、たとえば作成・更新・削除と、自動から人間承認へのエスカレーション回数を足すと、表面の応答品質だけでなく運用負荷まで見えてきます。

見落とされやすいのが、コンテキスト長とモデル/バージョン差分です。
同じプロンプトでも、入力長が伸びて切り詰めが発生すると応答の質は崩れますし、モデル名が同じでもバージョン更新で挙動差が出ることがあります。
『Cursor』は公式ドキュメントでモデル利用がAPI価格ベースの従量課金になると明記しており、使用量はエディタとダッシュボードで確認できます。
つまり、コスト観測と実行履歴は切り離さずに扱ったほうがよいということです。
『Claude Code』側もモデルや実行形態でコスト構造が変わるため、エラーだけ見ていると「失敗は減ったが運用費が跳ねた」という別の事故を見逃します。

もうひとつ、直前デプロイや設定変更はログ本体と同じ重みで扱います。
Gitのコミット、デプロイID、フィーチャーフラグ変更、プロンプト差分、RBACロール更新のような権限スコープ変更が、障害の直前に何もなかったケースはむしろ少数です。
ここを別画面で見せる運用だと、調査担当がタブを往復している間に初動が遅れます。
同一ビューで「このトレースの直前に何が変わったか」まで見える構成のほうが、RCAの精度が上がります。

Cursor · 料金プラン

自分に合ったプランを選ぶ

cursor.com

単一タイムラインの作り方と例

ログが揃っていても、画面ごとに分断されていると実際には読めません。
必要なのは、プロンプト→ツール→API→結果を1本の時系列に束ねた単一タイムラインです。
このとき軸になるのがトレースIDで、HTTP越しの呼び出しまで追うならW3Cの Trace Context 仕様に沿って traceparent を伝播させる構成が基本になります。
trace-id は 128ビットなので、実務で問題になるのは衝突より、途中のプロキシや中継でヘッダが落ちることです。

単一タイムラインでは、単に時刻順に並べるだけでは足りません。
各イベントに実行主体を付けます。
人が手動で再実行したのか、自動リトライなのか、バッチやエージェントが自律的に進めたのかで、同じAPIコールでも意味が変わるからです。
加えて、権限コンテキストも同じ行で見えるようにします。
どのトークンスコープで呼んだか、どのRBACロールが有効だったかが見えないと、「失敗した」のか「拒否されるべき呼び出しだった」のか区別できません。

たとえば、注文更新エージェントの障害を追うなら、タイムラインは次のような形になります。

この形にしておくと、「APIが403を返したあと、エージェントが代替ツールに自動フォールバックし、その結果として更新対象を誤った」といった流れが一目で読めます。
ログを別々に見ていると、403だけが強く印象に残って、その後の誤操作が設計上の問題だったことを見落とします。

運用上の効果が大きかったのは、Slack通知にトレースIDを入れることでした。
アラート本文に障害名だけが載っていると、担当者は監視画面、APM、アプリログ、デプロイ履歴を順に開きます。
トレースIDが最初から入っていると、チャット上で同じIDを検索するだけで関係するイベントが束ねて見つかり、一次切り分けがその場で終わる場面が増えます。
通知は短くても、調査に入る入口が一本化されているかどうかで初動は変わります。

このタイムラインには、変更履歴の添付も必要です。
GitのコミットID、デプロイID、プロンプト差分、フィーチャーフラグ変更、RBACロール更新を同じビューで見られる形にすると、「直前変更が原因候補か」を即座に判断できます。
AWSのDevOps Agent Incident 。

エラー率・遅延・コストの相関を読む

ログとトレースを見ていても、単一の数字だけ追うと判断を誤ります。
エージェント運用では、エラー率・遅延・コストを並べて読むことで、どこで品質と運用負荷が崩れたかが分かります。
たとえばエラー率だけ下がっていても、遅延が伸び、トークン消費が増えていれば、リトライや長文化したプロンプトで無理に成功率を稼いでいる可能性があります。
逆にコストだけ急減した場合は、モデル切り替えやコンテキスト削減で精度が落ちていることがあります。

ここで見るべきなのは、単純な同時変動ではなく順序です。
まず遅延が伸び、その後にエラー率が上がるなら依存APIの劣化やタイムアウト閾値の不整合を疑います。
先にコストが増え、その後に遅延が伸びるなら、プロンプト肥大化や不要なツール呼び出し増加が候補になります。
モデル/バージョン差分が入った直後に成功率だけが落ちたなら、同じ入力でも判断基準が変わった可能性が高いです。
ここでも、直前デプロイや設定変更を同じグラフ上に重ねると解釈が早くなります。

相関を見るときは、次の観点を一組で扱うと因果を誤りにくくなります。

本番で本当に見たいのは、数字の良し悪しそのものではなく、どの変更がどの指標を動かしたかです。
観測が弱いと、チームは不具合を直しているつもりでも、経営からは再現性のない試行錯誤に見えます。
エラー率、遅延、コスト、成功率、監査ログ、承認エスカレーション回数を時系列で結び、そこにデプロイと設定変更を重ねると、障害対応が感覚論から運用論に変わります。

よくある原因6パターン

典型原因は個別に見えて、現場では二つ以上が重なって表面化することが少なくありません。
とくにPoCでは通っていたのに本番で崩れた案件を振り返ると、本番データ分布のずれと、件数や金額のような暗黙の上限が定義されていなかった問題が同時に潜んでいた例が目立ちました。
症状だけを追うと「モデルの精度不足」に見えても、実際には要件、データ、権限、運用設計のどこで失敗条件が埋め込まれたのかを切り分ける必要があります。

『Microsoft Security Blogの agentic AI failure taxonomy』 でも、エージェント失敗は単発の不具合というより、設計・権限・協調・運用の層で分類して捉えるほうが再発防止につながると読めます。
層別に見ることで、根本原因の特定や対策の打ち分けがしやすくなります。
実務では次の6分類に落としておくと、症状から調査起点へつなぎやすくなります。

定量面でも、失敗が技術だけの問題ではないことは見えてきます。
ビジネス+ITで報告された数字では、期待どおりのROIを実現できた企業は25％にとどまり、PoCに取り組む経営幹部は76％いる一方で、全社規模展開まで進んだケースは16％でした。
Cybersecurity Insiders 2026では、過去12か月で37％がAIエージェント起因の運用問題を経験し、そのうち8％は停止やデータ破損レベルに達しています。
調査主体や対象母集団が異なるため数字を横並びで断定はできませんが、PoC成功と本番定着のあいだに運用設計の壁がある点は共通しています。

要件不明確

要件不明確は、もっとも地味で、しかももっとも多い原因です。
エージェントが失敗したというより、そもそも何をもって成功とするかが書かれていない状態です。
期待値、KPI、SLOが定義されていないと、精度が足りないのか、速度が遅いのか、コストが高いのか、誰も同じ基準で話せません。
プロンプトに成功条件がないまま「うまく処理して」と渡している案件では、出力が少しずれただけで現場と開発の評価が割れます。

この類型では、モデルの応答そのものより、要件文書と評価結果の食い違いを見るほうが先です。
実際、障害レビューで深掘りすると、誤回答より先に「正答の定義が人ごとに違っていた」ことが出てきます。
RCAの基本は症状と根本原因を切り分けることですが、目立つ不具合の裏に管理上の原因が隠れている形です。

対策として効くのは、期待出力の文章化だけではありません。
評価スキーマを入れて、正確性、禁止事項の遵守、処理時間、コスト上限のように採点軸を固定することです。
SLOの考え方を流用して、何を測るかを先に決めておくと、失敗が感想戦になりません。

データ品質不良

データ品質不良では、欠損、ラベル誤り、整合性崩れ、本番データ分布のずれが中心になります。
開発時のサンプルでは通るのに、本番だけ誤るケースの多くはここにあります。
とくにPoC成功から本番失敗へ転ぶ案件を振り返ると、学習や検証で使ったデータは整っていたのに、本番には空欄、表記揺れ、遅延反映、業務例外が混ざっていました。
そこに件数や金額の上限未定義が重なると、エージェントは「入力が汚い」だけでなく「止まるべき場面で止まらない」状態になります。

この。
スキーマ検証がなく、前処理が呼び出し元ごとにばらついていると、同じ顧客レコードでもエージェントごとに違う解釈になります。
調査では失敗サンプルを1件ずつ見るだけでなく、検収データと本番データを同じパイプラインに通し、どこで型、欠損率、カテゴリ分布が崩れるかを見ます。

恒久対応は、検収データの整備、スキーマ検証、前処理標準化、データプロファイリングの4点に集約されます。
現場では「モデルを変えれば直る」と見えがちですが、データの入口が崩れているままでは再発します。

ツール権限不備

ツール権限不備は、401や403のような分かりやすい失敗だけでは終わりません。
読み取りだけ成功し、更新だけ失敗する。
あるいはトークン期限切れやRBACスコープ不足、クォータ超過で断続的に落ちる。
この中途半端な失敗が、エージェントに誤ったフォールバックを選ばせることがあります。
直前セクションで触れた時系列ログと権限変更履歴を重ねると、この手の因果が見えます。

ここで痛感したのは、「権限が広すぎるから安全」という考えが逆だったことです。
以前、調査を楽にするつもりで広い権限を持たせ、監査を薄くした運用がありましたが、事故が起きたときに誰がどの操作を行ったのか追えず、原因の切り分けに時間を失いました。
最小権限で操作範囲を狭め、監査ログを厚く取った構成のほうが、事故自体を減らせるうえ、起きたあとも追跡が速くなります。
RBACの原則通り、必要な操作だけを許し、変更履歴を監査に残す設計のほうが安全です。

エージェント利用では利用量上限も権限の一部として扱うべきです。
たとえば『Cursor』は公式でProプラン月額$20のAgent利用枠を示し、上限到達後は従量課金に移ります。
並列エージェントや高コストモデルを多用すると、固定費の感覚で設計した運用が崩れます。
AWS DevOps Agentの公開プレビューでも concurrent incident resolution investigation は3件という制約があり、調査系エージェントは無限に並列化できる前提では組めません。
権限設計には、APIスコープだけでなく、同時実行枠とクォータの上限も含める必要があります。

暗黙制約の未反映

暗黙制約の未反映は、業務では当然の前提が、プロンプトやポリシーに書かれていない状態です。
たとえば「一定金額を超える変更はレビュー必須」「削除操作は禁止」「一度に処理してよい件数には上限がある」といった安全弁が実装されていないケースです。
人間の担当者なら空気で止まる場面でも、エージェントは記述されていない制約を守れません。

この類型が怖いのは、平常時には目立たないことです。
少量データや通常金額、例外なしのPoCでは問題が出ず、本番のピークや例外処理で初めて表面化します。
実際、PoCは成功しても本番で破綻する案件が多く、本番データの分布ずれと暗黙の上限未定義が同時に潜んでいる例が目立ちます。
モデルの性能よりも、止まるべき条件が文章やコードに入っていなかったことが原因になるケースが多いです。

ここではガードレールを「説明」ではなく「強制」にする必要があります。
金額上限、件数上限、対象種別、削除禁止、レビュー必須といった不変条件を定義し、逸脱時は実行不能にする構成が望ましいです。
invariant checking の考え方を使えば、許可してはいけない状態遷移を実行時に弾けます。
承認フローに流すだけでなく、そもそも危険な操作に到達できない形まで落とし込むのが実務的です。

マルチエージェント連携不全

対策は、役割分離を文章で書くだけでは足りません。
共有状態の更新規則、引継ぎメッセージの必須項目、終了条件、競合時の優先順位まで固定する必要があります。
ここで効くのが invariant checking と cross-agent state comparison です。
複数エージェントが同じ案件を扱うなら、顧客ID、対象レコード、処理段階、承認状態の整合が崩れた時点で止める構成にしておくと、連携不全が障害になる前に検知できます。
なお、Anthropic の Code Review に関する公開情報では平均レビュー時間が約20分、マネージド版のコストは $15–25/PR 程度と報告されることがありますが、PRの規模や提供形態で変動し得るため、運用設計時は実測での評価も行ってください。

対策は、役割分離を文章で書くだけでは足りません。
共有状態の更新規則、引継ぎメッセージの必須項目、終了条件、競合時の優先順位まで固定する必要があります。
ここで効くのが invariant checking と cross-agent state comparison です。
複数エージェントが同じ案件を扱うなら、顧客ID、対象レコード、処理段階、承認状態の整合が崩れた時点で止める構成にしておくと、連携不全が障害になる前に検知できます。

運用/ガバナンス不足

運用とガバナンスの不足は、技術的には動いているのに、組織として回らない状態です。
監査ログの保存方針が曖昧、承認フローが文書化されていない、エスカレーション基準が人ごとに違う、RACIがなく責任者がぶれる。
この状態では、小さな失敗が起きても是正処置と予防処置につながりません。
PoCで止まる案件の多くは、モデル性能よりこの層で失速します。

導入状況の数字を見ると、その傾向は濃いです。
PoCに着手する組織は多い一方で全社展開は限られ、運用問題の経験率も低くありません。
ここで不足しているのは、単なる「ルール」ではなく、事故後に説明できる運用設計です。
誰がResponsibleで、誰がAccountableかをRACIで固定し、障害レビューを5 Whysやフィッシュボーン図で掘り、CAPAとして責任者・期限・検証方法まで落とす。
この流れがないと、毎回その場しのぎの復旧で終わります。

監査の観点では、ログ保存の有無だけでなく、あとから一本の線で追えるかが問われます。
トレースIDは128ビット空間なので衝突そのものより、プロキシや中継でヘッダが落ちる運用のほうが実務上の問題になりやすい、という感覚に近いです。
つまり、仕組みを入れたことより、仕組みが組織の運用で維持されるかが勝負になります。
訓練不足のチームでは、承認必須化や停止基準を定めても、緊急時に迂回運用が始まり、設計したガバナンスが機能しません。
運用設計と練度は別物ではなく、同じ再発防止策の両輪です。

マルチエージェント特有の失敗と見抜き方

終了条件認識不足

マルチエージェントで起きる失敗の中でも、単一エージェントとの差が最も出やすいのが終了条件認識不足です。
誰が、どの状態をもって「完了」とみなすのかが曖昧なまま動かすと、互いに確認を投げ返してループしたり、逆に一方が途中結果を完成品と誤認して早く閉じたりします。
単体テストでは通るのに、本番の連携でだけ崩れる典型例です。

このとき見るべきなのは、会話内容より終了判定ログです。
どのエージェントが終了フラグを立てたのか、チェック段階が明示されているのか、承認待ちと完了が別状態として記録されているのかを追うと、収束基準の欠落が見えます。
AWS DevOps Agentの調査フローでも、調査開始から原因分析、緩和策までタイムラインで追う設計になっていて、どこで調査を閉じるかを明示しないと分析が漂流することがわかります。
調査の開始点と進行段階を切り分ける発想が前提になっています。

実務では、ダミー課題で停止条件だけを検証すると欠陥がよく出ます。
答えの正しさではなく、「必要条件を満たしたら止まるか」「未達なら追加確認に進むか」だけを見るテストです。
たとえばレビュー完了、承認取得、状態同期済みの3条件がそろわない限り終了不可、といった不変条件を置くと、会話が長いだけの見かけ上の進行を弾けます。
マルチエージェントでは、賢く答えることより、止まる条件を誤認しないことのほうが障害防止に直結します。

情報非共有

情報非共有は、各エージェントがそれぞれ正しいつもりで動いているのに、共有前提がずれて全体だけ壊れる失敗です。
Blackboard型の共有メモリや共通チャネルがあっても、更新タイミング、キー名、正本の定義が揃っていないと、同じ案件を違う世界線として処理し始めます。
単一エージェントなら見えない失敗で、マルチエージェントではここが最初の分岐点になります。

観測の起点は、エージェント間の共有チャネルログです。
誰がいつ何を書いたか、他のエージェントがそれを読んだか、更新イベントが欠落していないかを、時系列で並べて見ます。
私は一度、原因がまったく見えない連携不全に当たり、Blackboardの更新イベントをトレース化したことがあります。
すると、情報が共有されなかった瞬間は意外なほど狭い範囲に収まり、修正箇所は1行でした。
体感としては、複雑な推論ミスというより、共有イベントの発火漏れを可視化した途端に犯人が出てきた、という感覚に近かったです。

ここで効くのは、共有スキーマと更新イベントの可観測化です。
エージェントが持つ案件ID、処理段階、承認状態、参照したバージョンを共通項目として固定し、更新時に必ずイベントを吐かせると、認識齟齬が「なんとなく変」ではなく差分として出ます。
トレースIDを流す場合も、問題はIDの衝突ではなく、途中のチャネルで関連付けが切れることです。

New whitepaper outlines the taxonomy of failure modes in AI agents ｜ Microsoft Security Blog

Read the new whitepaper from the Microsoft AI Red Team to better understand the taxonomy of failure mode in agentic AI.

www.microsoft.com

他エージェント入力無視

他エージェント入力無視は、議論や合意形成のプロトコルが崩れた状態です。
メッセージは飛んでいるのに、実際の判断に使われていない。
レビューコメントが存在するのに実行側が参照していない。
反対意見が記録されているのに、承認済みとして進んでしまう。
これは「会話は成立しているが、連携は成立していない」失敗です。

見抜くには、各エージェントが直前メッセージや共有状態をどれだけ参照したかを見る必要があります。
実装上はメッセージ参照率や、最終判断に引用された入力数を出しておくと、無視が露骨に現れます。
レビュー担当が3件の指摘を出しているのに、実行担当の応答がそのどれにも触れていなければ、プロトコルは名目だけです。
学術的にも、Why Do Multi-Agent LLM Systems Fail?のような。

対策は単純で、レビュー段階と承認手順を役割に基づいて強制することです。
レビューを「参考意見」にすると、忙しい系の実行エージェントが平気で飛ばします。
レビューコメントへの応答がない限り先に進めない、却下理由を構造化して残す、承認者の入力を受けるまで状態遷移させない、といった手順化が必要です。
マルチエージェントでは、入力が存在するだけでは足りず、参照された事実まで観測対象に含めないと、連携の質は測れません。

役割不整合

役割不整合では、担当の重複と空白が同時に起きます。
誰かがやるだろうと思って誰もやらないか、逆に複数のエージェントが同じ権限を持ってぶつかります。
レビュー担当と実行担当が分かれているつもりでも、責務が文書だけで、状態遷移に反映されていないと簡単に崩れます。

以前、レビューワとエグゼキュータの境界が曖昧な構成を運用していたとき、レビュー工程が何度も飛ばされました。
実行側は「軽微な変更だから進めた」、レビュー側は「投げられていないから未着手」と認識していて、どちらも自分の役割を果たしたつもりだったのです。
解消できたのは、責務をRACIで引き直してからでした。
実行責任者、説明責任者、相談先、通知先をタスク単位で固定し、レビュー未実施ならワークフローが強制停止するように変えると、曖昧さがそのまま通らなくなりました。

観測では、役割定義と実際の行動の差分を見るのが有効です。
RACI上でResponsibleではないエージェントが更新していないか、Accountableが複数人扱いになっていないか、Consultedが実質スキップされていないかを照合すると、設計と実態のずれが出ます。
対策としては、役割の再設計に加えて、責務の不変条件を置くことです。
たとえば「レビュー担当は変更を実行しない」「実行担当は承認状態を書き換えない」といった線引きを、文章ではなく実行制御に落とし込むと、役割の崩れが即検知対象になります。

状態不整合

状態不整合は、複数エージェントが同じ対象を並行更新したときに起きるレースです。
片方は最新版を見ているのに、もう片方は古い状態で判断し、そのまま更新して整合性を壊します。
マルチエージェントでは会話の失敗より、こちらのほうが実害になりやすく、停止やデータ破損に直結します。

見るべきポイントは、バージョン、ロック、イベント順序の3つです。
同じレコードに対して更新前バージョンを保持しているか、書き込み時に競合検知があるか、イベントが発生順に再現できるか。
この3点がないと、原因調査は「たぶん同時に触った」で止まります。
共有状態を扱うなら、どのエージェントがどの版を読んで、どの版に対して書いたかが残っていないと、真因に届きません。

対策は、対象の性質に応じて悲観制御か楽観制御を決めることです。
順番待ちにするならロック、競合を後で検出するならバージョンチェック、衝突を許容するならコンフリクト解決ルールを先に定義します。
どれを採るにせよ、「誰が状態の正本か」を曖昧にしないことが前提です。
マルチエージェントでは会話設計より状態設計の粗さが事故を生みます。

複雑化によるデバッグ負荷

エージェント数が増えると、失敗の種類が足し算ではなく掛け算で増えます。
個々は正しく見えても、依存関係、共有状態、承認順序、再試行、タイムアウトが絡み始めると、どの組み合わせで崩れたのか追えなくなります。
単一エージェントならログを上から読めば済んだものが、マルチエージェントではタイムラインの再構成から始まります。

このデバッグ負荷は、導入効果の頭打ちにも直結します。
ビジネス現場ではPoCから先に進めない例が多く、期待どおりのROIを出せた企業が限られるのも、モデル性能だけではなく運用複雑性を捌き切れないからです。
エージェント数を増やせば賢くなる、ではなく、調査単位も依存関係も増える、と捉えたほうが現実に近いです。
『Cursor』のBackground AgentやParallel Agentsのような機能は生産性の伸びしろがありますが、同時に「どの相互作用がコストを生んでいるか」を見えなくしやすい面もあります。

対策は、全部を一気に追わないことです。
段階的無効化で一部のエージェントを止め、A/Bで相互作用差分を見て、ダッシュボードで依存関係を可視化すると、犯人の範囲が急に狭まります。
実務では、まずオーケストレータだけ残す、次にレビュー系だけ切る、共有メモリ書き込みを片側停止する、といった順で潰すと因果が見えてきます。
根本原因分析の型としては、症状と原因を分けて掘る考え方が、この場面でもそのまま効きます。
マルチエージェントの失敗は派手な誤答より、相互作用のどこで不変条件が破れたかに焦点を当てたほうが、再発防止までつながります。

根本原因分析の進め方

症状と根本原因の違い

根本原因分析で最初に切り分けたいのは、いま見えているものが症状なのか、それとも再発を防ぐために取り除くべき原因なのか、という点です。
症状は観測された現象です。
たとえば「誤操作が起きた」「承認なしでデータが移動した」「レビューが飛ばされた」は症状です。
一方の根本原因は、その現象がまた起きないようにするために除去すべき起点です。
権限設計の欠落、承認フローの未強制、監査ログ不足、責務分担の曖昧さといったものがこちらに当たります。

この区別を曖昧にすると、対策も症状寄りになります。
誤った移動先のデータを戻す、実行ジョブを止める、壊れた設定を復旧すること自体は必要ですが、それだけでは次の事故を止められません。
障害後に症状修正だけで閉じた案件は、時間を置かずによく似た事故がまた起きました。
実務では、その後のRCAに人とプロセスの骨を入れただけで再発率が目に見えて下がりました。
技術要因だけを見ていると、判断の前提や承認の抜け道が丸ごと残るからです。

AIエージェント運用では、とくに「モデルが変なことをした」で止めないことが肝です。
モデル出力は引き金に見えても、実際には曖昧な要件、過剰な権限、検証不足、ガバナンス不在が先にあるケースが多く、再発防止はそちらを直したときに初めて成立します。

5 Whys とフィッシュボーン

RCAを実務で回すときは、5 Whysとフィッシュボーンを組み合わせると偏りが減ります。
5 Whysは、起きた事象に対して「なぜ」を連続で重ね、表層の説明から一段ずつ深い層へ降りていく手法です。
ポイントは、5回で終えることではなく、人的・プロセス・技術・データ・ガバナンスの層に届くまで掘ることです。

たとえば「承認なしでデータが外部に移動した」という事象なら、「なぜ移動したのか」でツール実行条件に行き着き、「なぜその条件で実行できたのか」で権限スコープに進み、「なぜその権限が付与されていたのか」でロール設計や例外運用に到達します。
そこからさらに「なぜ例外が常態化したのか」を追うと、レビュー負荷を避けるために暫定運用が固定化していた、責任者が曖昧で承認の説明責任者が不在だった、といったガバナンスの層まで見えてきます。
ここまで行かないと、単なる設定ミス修正で終わります。

ただし、5 Whysだけだと一本の因果連鎖に引っ張られます。
そこでフィッシュボーン、つまり特性要因図を併用します。
頭に事故そのものを置き、大骨に人、プロセス、ツール、データ、環境、管理を並べて、それぞれの枝に要因候補を書き出します。
これで「技術だけを見て、人の判断や管理の欠落を見落とす」偏りを避けられます。
エージェント事故では、ツール呼び出しの条件やAPI応答だけでなく、学習・参照データの誤分類、検証用ログの欠落、承認フローの例外規則、インシデント後レビューの不実施まで同じ図に載せたほうが因果がつながります。

ここで欠かせないのが、原因仮説の検証計画です。
仮説は立てるだけでは足りません。
再現実験で同じ条件を作る、対照群を置いて変更前後の差を見る、足りないログを補完して因果の連続性を確認する。
この3つを入れると、議論が感覚論から外れます。
実際、原因仮説ごとにA/Bの検証を用意すると、会議の空気が主観からデータに変わり、判断が前に進みます。
誰の説明がもっともらしいかではなく、どの条件で事故が再現し、どの対策で止まるかを見ればよいからです。
ログ分析の観点はAWSのログ分析解説やインシデント対応資料にも通じていて、因果の確認には時系列の欠落を埋める作業が避けられません。

RCA具体例：自律的データ移動の事故

具体例として、エージェントが「信頼できない場所への自律的なデータ移動」を実行したケースを考えます。
これは運用現場でも警戒度が高い事故で、懸念項目として挙げる組織が多い類型です。
症状は、社内の承認済みストレージではない保存先へ業務データが転送されたことです。
ここで「転送先を削除して終わり」にすると、別の経路でまた起きます。

5 Whysで追うと、まず「なぜ移動したのか」は、エージェントが外部保存先を有効な候補として選べたからです。
「なぜ選べたのか」は、ツール実行ポリシーに保存先の許可リストがなく、URL形式だけで通過していたからです。
「なぜ許可リストがなかったのか」は、PoC段階の柔軟性を残したまま本番へ持ち込んだからです。
「なぜ本番移行時に閉じられなかったのか」は、承認フローが文書上の運用に留まり、システム上で強制されていなかったからです。
「なぜ強制されていなかったのか」は、データ管理責任者と開発責任者の境界が曖昧で、誰が例外を止めるか決まっていなかったからです。
ここで初めて、事故の起点がエージェント単体ではなく、権限設計とガバナンスの欠落だと見えてきます。

フィッシュボーンに展開すると、人の骨には「レビュー担当が保存先リスクを判断していない」、プロセスには「本番移行前の承認チェックが手動」、ツールには「保存先許可リストなし」、データには「機密区分ラベル未付与」、環境には「PoC設定の持ち越し」、管理には「Accountableが不在」が載ります。
こうして並べると、単なるツール誤動作ではなく、複数層の穴が重なっていたことがわかります。

そのうえで仮説を検証します。
再現実験では、同じ入力と同じ権限スコープで外部保存先候補が再び選ばれるかを確認します。
対照群では、許可リストを導入した構成と未導入の構成を並べ、同一タスクで移動先選択がどう変わるかを比較します。
ログ補完では、保存先判定時の入力、ラベル判定、承認状態、実行主体の権限を時系列でつなぎます。
このA/Bを入れると、「たまたま危ない出力をした」のか、「設計上そう振る舞う」のかが明確になります。

CAPAの設計

RCAの出口は分析書ではなくCAPAです。
是正処置では、今回の事故を止めるために承認フローをシステムで強制し、未承認の保存先には書き込めない状態にします。
予防処置では、RBACを見直してエージェントの権限を最小化し、保存先ごとの許可スコープをロール単位で分離します。
機密データにはラベルを付け、そのラベルを見て転送可否を判断する制御も入れます。
これで、同じ誤判断が出ても実行段階で止まります。

CAPAは「何をやるか」だけでは閉じません。
責任者、期限、検証方法、受け入れ基準がない計画は、実装されても効果確認で宙に浮きます。
実務ではRACIに沿って、実行責任者と説明責任者を分けておくと詰まりません。
たとえば、承認フロー強制の実装はプラットフォームチームのResponsible、説明責任はプロダクトオーナーのAccountable、データ分類ルールはセキュリティ責任者がConsulted、運用部門をInformedに置く、といった切り方です。
Accountableを1人に固定すると、例外処理の押し付け合いが止まります。

検証方法は、メトリクスと監査の両方を持たせるのが定石です。
受け入れ基準も曖昧にせず、承認なしのデータ移動が発生しないこと、最小権限ロール以外での実行が残っていないこと、監査ログから承認者と実行主体が追跡できること、まで定義しておくと、クローズの判断がぶれません。

CAPAが機能している組織は、対策を「追加した」で終えず、「効いた」と言える状態まで持っていきます。
RCAの価値は、原因候補を並べることではなく、再発の起点を潰し、その責任者と期限を明記し、メトリクスと監査で効き目を確認できる形に変えるところにあります。
AIエージェントの事故は派手な症状に目を奪われますが、再発防止は地味な承認強制と権限最小化の設計から始まります。

本番運用前に用意したいチェックリスト

評価指標とSLO

本番運用前のチェックリストは、まず「何をもって成功とみなすか」を数値で固定するところから始まります。
AIエージェントは動いているだけでは評価できません。
タスク成功率だけでなく、出力の正当性、期待した手順を守ったか、ガードレールを踏み越えていないかまで分けて見ないと、見かけの成功に引っ張られます。
とくに本番では、回答生成よりも「書き込み」「削除」「転送」のような操作系タスクで事故の単価が跳ね上がるため、成功率と正当性は別指標として持つべきです。

SLOは、通常のWebシステムと同じくエラー率と遅延を軸に置きつつ、AIエージェントではコスト/実行も外せません。
『Cursor』のBackground Agentはモデル推論のAPI価格ベースで従量課金され、『Claude Code』も利用形態によってはレビュー単位で費用が積み上がります。
たとえば『Claude Code』のマネージドCode Reviewは、公開されている平均レンジで見ると1PRあたり$15〜25で、月間100PRを流すと$1,500〜2,500規模になります。
運用品質だけ見てコストを追わないと、障害ではなくても採算で止まります。
期待どおりのROIを実現できた企業が25％にとどまり、PoCに取り組む経営幹部は76％いる一方で全社規模展開まで到達したケースは16％という数字は、評価設計の甘さがそのまま運用失敗に接続することを示しています。

チェックリストに落とすなら、最低でもタスク成功率、正当性、エラー率、遅延、コスト/実行、ガードレール逸脱率の6本は同じダッシュボードに載せたいところです。
ガードレール逸脱率には、未承認の書き込み要求、禁止保存先への転送試行、削除系コマンドの自動発火といった「止まったから無害」な挙動も含めます。
止められた逸脱は、成功ではなく予兆です。

運用報告では、リスク認知を感覚で語らないことも効きます。
Cybersecurity Insiders 2026の調査では、自律的なデータ移動を最大懸念に挙げた割合が38％、重要設定やコード削除への懸念が24％でした。
こうした数字を、転送系の承認率や削除系の人間承認率と結びつけておくと、チェック項目が「念のため」ではなく「事故類型への対策」として説明できます。

トレース保存とPII対策

本番で原因を追えない運用は、事故そのものより後処理で詰まります。
保存すべきなのはアプリログだけではなく、プロンプト、ツール呼び出し、外部API応答、最終結果、実行時の権限、設定変更履歴まで含んだ一連のトレースです。
どの入力で、どのツールが、どの認可状態で動き、何を返したのかが一本の時系列でつながっていないと、再現も監査もできません。

このとき、トレースは「残すか残さないか」ではなく、「何を、どこまで、どの粒度で残すか」を決めます。
W3CのTrace Contextはtraceparentとtracestateで伝播仕様が定義されていて、trace-idは128ビットです。
実務では衝突より、途中のプロキシやサービスでヘッダが落ちて因果が切れるほうが問題になります。
だからチェック項目には、トレースIDの伝播確認だけでなく、ログ検索時にトレース単位で追えること、権限変更履歴と突合できることも入ります。

PII対策は、保存量を減らす話ではなく、保存時点で扱いを分ける話です。
個人識別情報を含む入力や応答は、マスキング、匿名化、アクセス制限のどれで守るかを決め、保持期間も法務と運用の両面で設計します。
短すぎると障害調査に耐えず、長すぎると保有リスクが膨らみます。
実際には、全文保存する項目、ハッシュ化して保存する項目、メタデータだけを残す項目を分けると監査とプライバシーの両立が取りやすくなります。

検索性も軽視できません。
インシデント時は「このユーザーで何が起きたか」より、「この権限セットで何が走ったか」「このプロンプト系統でどのツールが失敗したか」を引きたい場面が多いからです。
ログは保存して終わりではなく、分析可能な構造で持って初めて運用資産になります。
AIエージェントでは、その対象がアプリイベントだけでなく、推論とツール実行にも広がると考えたほうが実態に合います。

承認フローと権限最小化

承認フローは、曖昧なルールを文書に書くより先に、「どの操作が人間承認なしでは実行されないか」をシステムで固定することが先です。
境界が曖昧だと、急ぎの案件や運用例外から崩れます。
実務では、書き込み、削除、外部転送、支払い、権限変更は、人間承認が必要な操作として最初から別レーンに分けるのが安定します。

削除系を常に人間承認に切り替えた途端、誤削除がゼロになった経験があります。
承認待ちで処理が滞る懸念はありましたが、そこは回路遮断で自動処理を止め、急がない更新はバッチへ逃がす設計に変えると吸収できました。
削除だけを「特別扱い」したのではなく、不可逆操作を自律実行から切り離した形です。
この線引きが入ると、事故の質が変わります。

権限最小化では、RBACのロール、スコープ、クォータを明文化し、監査ログとセットで運用します。
とくに削除、転送、支払いは一つの強権限ロールにまとめず、個別の最小権限に分離したほうが監査の意味が残ります。
たとえば「閲覧＋要約」は許可されても、「閲覧＋外部転送」は別承認、「設定変更＋削除」は別ロールという切り方です。
これを曖昧にすると、調査時に「本来できないはずだった」が成立しなくなります。

承認の責任分担にはRACIの考え方が合います。
誰が実行責任を持ち、誰が最終判断を持つのかを固定しておくと、緊急時の判断が止まりません。
緊急時だけは自動化を広げるのではなく、逆に強制的に人間承認へフェイルオーバーする設計が効きます。
本番障害では速度が求められますが、重大操作を自動化に戻すと、初動の焦りが二次被害になります。

フェイルセーフとエスカレーション

AIエージェントの本番運用では、「失敗しない設計」より「失敗したときに広げない設計」が先に要ります。
チェックリストに入れるべきフェイルセーフは、タイムアウト、リトライ上限、サーキットブレーカー、ロールバック手順の4つです。
外部APIが不安定なときに延々と再試行を続ける、自律判断が怪しいのに書き込みだけ進む、といった挙動は、この4点が抜けると起きます。

サーキットブレーカーは、依存先の連続失敗を見て呼び出しを遮断し、障害の連鎖を止めるための基本部品です。
とくにエージェントが複数ツールを横断する構成では、一つのAPI劣化が推論の迷走、再試行、コスト増、キュー滞留まで波及します。
ここで「一定条件で止める」を入れておくと、事故は局所化できます。
ロールバック手順も、モデルやプロンプトを戻すだけでなく、権限設定、承認フラグ、外部連携トークンまで戻し先を定義しておかないと、表面だけ戻って中身が残ります。

人間へのエスカレーションは、担当者の勘ではなく閾値で切るべきです。
たとえばエラー率が5％を超えた状態が10分続いたとき、重大操作の要求が来たとき、PIIを含む転送試行が発生したとき、といった条件を事前に定義しておくと、夜間でも迷いません。
オンコール体制も、単に誰かが待機しているだけでは足りず、承認権限を持つ人と復旧権限を持つ人が別なら、その接続順まで決めておく必要があります。

調査タイムラインとmitigation planが一連で扱われています。
AIエージェントでは、調査と緩和策を別物にせず、どの失敗でどの遮断策を発動するかを一枚で見えるようにしておくと、初動がぶれません。

カオス/障害訓練の設計

訓練はそのギャップを埋める工程です。
いくつかの。
訓練シナリオは、発生したときの被害が大きい事象を優先して選び、検知〜封じ込め〜復旧の一連を通しで鍛えることに重点を置いてください。

シナリオは、ふだん起きてほしくないが、起きたときの被害が大きいものを選びます。
代表例は、ツール権限の失効、外部APIの500応答、エージェント間で情報が共有されない状態です。
マルチエージェントでは、単体の失敗よりも状態不整合の検知が遅れるほうが危険なので、検知から封じ込め、復旧までの時間を通しで測る必要があります。
年に数回のシナリオ演習として回し、平均検知時間、平均復旧時間、承認到達時間、ロールバック完了までの経過を記録すると、運用品質が数値で見えてきます。

演習でトークン失効を意図的に仕込むと、復旧の癖がよく見えます。
実際にこれを入れたときは、平均復旧時間が半分になり、手順書の穴も一気に表面化しました。
誰が再認証するのか、どのサービスから順に戻すのか、失効後に自動で止まる処理と止まらない処理は何かが、机上レビューでは出てきません。
障害訓練は「うまく復旧できたか」だけでなく、「何が決まっていなかったか」を洗う場です。

訓練の評価軸も、平時のSLOとつなげておくと形骸化しません。
検知の遅れ、誤承認、過剰権限のまま復旧した件数、トレース欠落による調査不能時間といった項目は、そのまま本番の事故確率に結びつきます。
38％が自律的なデータ移動を、24％が重要設定やコード削除を懸念しているなら、演習項目もその懸念に対応づけて設計するのが筋です。
懸念をアンケートで集めるだけでは意味がなく、どのチェック項目で封じるのかまで結びつけて初めて、予防策として機能します。

まとめと次のアクション

この稿で押さえたい芯は明快です。
障害が起きた直後の5〜10分で影響範囲と封じ込めを決め、5ステップで事実を集め、6つの原因分類で真因を外さずに追うことです。
そこで止めず、RCAからCAPAまでつなげて再発防止まで閉じると、単発の復旧で終わらない運用に変わります。
派手な失敗だけを見るのではなく、プロンプト、ツール、権限、外部API、共有状態、人間承認の境界まで一本の流れで捉えることが、AIエージェント運用の分水嶺になります。

導入の現場では、PoCに取り組む経営幹部が多い一方で、全社展開まで届く例は限られます。
期待通りのROIを出せる企業も多くありません。
だからこそ、障害対応は「困ったときの場当たり対応」ではなく、運用設計の精度を上げる入口として扱ったほうが結果につながります。
調査の筋道があるチームは、失敗の回数より、同じ失敗を繰り返さない密度で差がつきます。

今日やること

着手の順番は重く考えなくて構いません。
まずは自社で実際に起きた失敗事例を1件だけ選び、本稿で触れてきたチェック項目に沿って棚卸しすると、抜けている観測点が見えてきます。
誤回答でも誤操作でも停止でもよく、重要なのは「そのとき何が見えず、何が判断材料にならなかったか」を埋めることです。

次に、プロンプト、ツール実行、APIレスポンスを一つのタイムラインに並べてください。
ここは投資対効果が出やすい箇所です。
実際、タイムライン可視化を1日で用意しただけで、翌週の障害対応工数が3分の1まで縮みました。
犯人探しが早くなったというより、どの時点で因果が切れたかをチーム全員が同じ画面で話せるようになり、再現と切り分けの往復が減った感覚に近いです。
W3C Trace Contextのtraceparentのような共通のトレース文脈を起点にすると、アプリ側、API側、ジョブ側の記録をつなぎやすくなります。

そのうえで、人間承認が必要な操作と自動実行してよい操作の境界を明文化します。
削除、外部送信、課金、権限変更のように取り返しがつきにくい処理は、人が止められる設計に寄せるだけで事故の質が変わります。
ここはルール文だけで終わらせず、RACIに落として、誰が実行責任を持ち、誰が最終判断を持つかまで固定しておくと、夜間障害でも判断が流れません。

次回障害までにやること

平時に整えておくものは、まず失敗パターン集と調査ランブックの雛形です。
単一エージェントの誤操作、マルチエージェントの状態不整合、導入設計の失敗を同じ箱に入れないだけでも、調査の起点がぶれません。
失敗パターン集には症状、起点ログ、想定原因、止めるべき自動処理、復旧条件を並べ、ランブックには初動、切り分け、エスカレーション、クローズ条件までを書いておくと、障害時の会話が短くなります。

もう一つは、監視の最小セットを先に実装し、SLOとエスカレーション基準をチームで合意することです。
Google CloudのSRE系ガイドでも、SLOは監視項目の数ではなく、何を守るかを先に定義して設計する考え方が軸になっています。
AIエージェント運用でも同じで、成功率、エラー率、重大操作の実行回数、外部送信、承認待ち滞留といった指標のうち、どれを超えたら自動実行を止めるのかを先に決めると、アラートが行動につながります。

調査を自動化すれば無限に掘れるわけではなく、並列数と従量課金の両方が効いてきます。
障害調査の設計を決めるときは、どこまで自動で深掘りさせるか、どこで人間に切り替えるかを予算と一緒に決めておくほうが運用が安定します。

障害対応を強くする近道は、ツールを増やすことではなく、次の障害が起きたときに「誰が、何を見て、どこで止めるか」が既に決まっている状態を作ることです。
その土台があるチームは、初動5〜10分の判断がぶれず、5ステップの調査が空回りせず、6原因分類から再発防止まで自然につながります。

FAQ

ログが多すぎる場合の見方

ログの量に圧倒されたときは、先に読む順番を決めたほうが根因に早く届きます。
私が現場でまずやるのは、対象を1ワークフローと1時間に絞ることです。
これだけで、ノイズに埋もれていた失敗の起点が見える場面を何度も経験してきました。
全体を俯瞰しようとして数日分を開くと、関係ない再試行や定期ジョブまで混ざり、判断が鈍ります。

次に、トレースIDを軸に時系列へ並べます。
W3C Trace Contextのtraceparentのように、同じ実行連鎖をつなぐ識別子が入っていれば、アプリ、外部API、ジョブ、承認処理の順番が一本の線になります。
trace-id自体の衝突を心配するより、途中のプロキシや中継層でヘッダが落ちていないかを見るほうが、実務では効きます。

そのうえで、見るイベントを絞ります。
全部読むのではなく、ツール実行、権限変更、外部API失敗の3種類から当たると、失敗の起点候補が急に減ります。
たとえば『Cursor』のようにエージェント実行量をダッシュボードで追える製品でも、使用量だけでは因果は見えません。
どの操作を打ち、どの権限で走り、どの外部依存で落ちたかまで結ばないと、調査は進みません。

山を特定するときは、単発のエラー文言より、エラー率・遅延・コストの相関を見ます。
失敗が増えた瞬間に遅延も跳ね、同時に調査や再試行のコストも盛り上がっているなら、そこが掘るべき山です。
症状を一つずつ追うより、異常が重なった時間帯を先に切り出したほうが、読むログの量が一気に減ります。

再現しないときの対処

再現しない障害は、原因が消えたのではなく、条件が揃っていないことが多いです。
先に固定すべきなのは、バージョン、権限、外部依存です。
モデルやプロンプトだけでなく、RBAC設定、APIトークンスコープ、接続先の状態まで揃えないと、本番で起きた失敗と別物を触ることになります。

そこで有効なのが、入力分布を合成して境界条件を探るやり方です。
正常系の入力だけを流しても、本番で踏んだ段差は見つかりません。
空文字、長文、欠損、曖昧な指示、権限不足の対象、外部APIの遅延応答などを混ぜると、どの条件で不安定になるかが見えてきます。
単純な再演ではなく、失敗しうる幅を作って探る感覚です。

ログ粒度を一時的に上げるのも有効です。
ただし恒久的に増やすのではなく、再現テストの間だけ、入力、ツール呼び出し、レスポンス、権限判定、承認分岐を細かく残します。
再現しない案件ほど「何が起きなかったか」の情報が必要になるので、普段より一段細かい観測点が役に立ちます。

本番に近い条件を試すなら、影響の小さい環境でカナリア的に流すのが現実的です。
いきなり広げるのではなく、限定されたトラフィックや限定ユーザーで再現性を見ます。
そこでも再現しないなら、問題はコードやモデルではなく、本番固有の負荷、クォータ、連携先の状態遷移にあると切り分けられます。

PoC成功→本番失敗の理由

PoCではうまく動いたのに本番で崩れる最大の理由は、扱う世界の広さがまるで違うからです。
PoCでは整ったサンプルデータ、協力的な利用者、限定された権限で回せますが、本番ではデータ分布が崩れ、入力の揺れが増え、例外系が一気に流れ込みます。
少数の成功例で成立した設計は、母集団が広がるだけで耐えきれなくなります。

加えて、本番では権限設計、SLO、安全弁の未整備が露呈します。
削除、外部送信、課金、権限変更のような操作に承認や停止条件が入っていないと、PoCでの「便利」がそのまま事故の導線になります。
Cybersecurity Insiders 2026の調査では、過去12か月で37％がAIエージェント起因の運用問題を経験し、そのうち8％は停止やデータ破損の水準でした。
懸念としては、信頼できない場所への自律的なデータ移動が38％、重要設定やコード削除が24％に上っています。
どれもPoCでは見えにくく、本番で初めて痛点になります。

外部システムの負荷やクォータも見逃せません。
PoCでは呼び出し回数が少なく、待ち時間も短いため、リトライやサーキットブレーカーの粗さが表に出ません。
本番では同時実行、再試行、調査自動化が重なり、外部API制限やコストが一気に効き始めます。
たとえば『Claude Code』のCode Reviewは公開報道ベースで1PRあたり平均20分、マネージド版の平均コスト帯は$15〜25とされます。
小さな試行では吸収できた時間と費用が、本番の件数では運用判断そのものを変えます。

こうした背景は導入統計にも表れています。
ビジネス+ITで報じられた数字では、PoCに取り組む経営幹部は76％いる一方、全社規模で展開できたケースは16％、期待どおりのROIを実現できた企業は25％にとどまります。
PoC成功がそのまま本番成功を意味しないのは、技術の精度だけでなく、運用設計、責任分担、監視、安全弁まで含めて初めて成立するからです。

Documentation

Claude API Documentation

platform.claude.com

監視の最低限は？

最小構成で外せないのは、エラー率、遅延、コスト/実行、成功率の4つです。
これで「壊れているか」「遅くなっているか」「高くついているか」「目的を達成しているか」が見えます。
SLOを置くときも、この4軸がないと、障害なのか単なる揺れなのかを判断できません。

そこに重要操作の監査ログを重ねます。
特に、ツール実行、権限変更、外部送信、削除系の操作は、だれが、どの入力で、どの結果になったかを後から追える形で残す必要があります。
RBACの変更履歴まで見えていないと、失敗がモデル起因なのか権限逸脱なのかを分けられません。

人間承認へのエスカレーションも監視対象に入れてください。
承認依頼の件数、滞留、却下、未承認のまま実行された痕跡を追えるだけで、運用の綻びが見えます。
自動化が進むほど、問題は「失敗した回数」より「止まるべきところで止まらなかった回数」に出ます。

変更監視も欠かせません。
モデルの切り替え、プロンプト更新、権限変更、外部API先の差し替えは、障害の直前変更として最優先で見返す項目です。
『Cursor』でも『Claude Code』でも、機能追加や利用形態の変化が早いぶん、挙動差分を人の記憶に頼る運用は持ちません。
最低限の監視とは、豪華なダッシュボードのことではなく、異常が起きたときに「何が変わったか」と「どこで止めるか」をすぐ答えられる状態のことです。