本連載「AgentOps」では、AIエージェントを本番運用するための7つの要素——評価・可観測性・コスト・メモリ・権限・デプロイ・インシデント——を、一つずつ掘り下げてきました。本稿はその第七要素であり、連載の完結編にあたります。テーマはインシデント運用、つまり「エージェントが期待どおりに動かなくなったとき、どう気づき、どう止め、どう学び直すか」という規律です。
従来のシステム運用は、暗黙のうちに「基本的には正しく動く」「落ちるときは分かりやすく落ちる」という前提の上に成り立ってきました。しかしLLMを核に据えた非決定的なエージェントでは、この前提が崩れます。エージェントは“落ちない”のではなく、“落ちたことに気づきにくい”かたちで壊れるのです。本稿では、その特殊性を出発点に、SRE／AgentOpsの視点からインシデント運用の設計を組み立てていきます。
想定読者は、AIエージェントやLLMアプリケーションを本番投入している、あるいは投入を控えているSRE・プラットフォームエンジニア・プロダクト責任者です。可用性やレイテンシといった従来のSLOは運用してきたが、「エージェント固有の壊れ方」をどう定義し、どうオンコールに載せるかで悩んでいる——そうした方に向けています。
なぜエージェントのインシデントは“特殊”なのか——非決定性・揮発性・自律連鎖
エージェントのインシデントを設計する前に、まず「なぜ既存のインシデント運用がそのままでは通用しないのか」を整理します。理由は大きく3つ、非決定性・揮発性・自律連鎖に集約されます。
非決定性：同じ入力が同じ結果を生まない
従来のバグは、再現性を足がかりに調査できました。「この入力を与えるとこのエラーが出る」を固定できれば、原因は追い込めます。ところがLLMは、同じプロンプト・同じ設定でも出力が揺れます。温度パラメータをゼロに寄せても、モデル更新・コンテキストの微差・ツール応答の順序で結果は変わり得ます。
この結果、インシデントの判定基準そのものが揺らぎます。「一回失敗した」は異常なのか、確率的なばらつきの範囲内なのか。単発のエラーではなく“分布の変化”として捉える——正常時の成功率や品質スコアの分布を持っておき、そこからの逸脱で異常を判断する発想が必要になります。
たとえば、あるカスタマーサポート用エージェントの回答正確率が、平常時は95%前後で安定していたとします。ある日これが82%に落ちたとき、従来型の監視では何も鳴りません。サービスは稼働しており、エラーも出ていないからです。異常として捉えられるのは、「正常時の分布」を基準に持ち、そこからの統計的な逸脱を監視している場合だけです。非決定性への対処とは、突き詰めれば“確率的な正常”を定義し、そこからのズレを異常と見なす基盤を持つことに他なりません。
揮発性：状態が痕跡を残さず消える
エージェントの「思考過程」は、多くの場合その場限りのコンテキストウィンドウの中にしか存在しません。何を根拠にどのツールを呼び、どう判断したのか——その連鎖は、明示的にトレースとして記録しない限り、応答が返った瞬間に失われます。従来のシステムがログとスタックトレースを自然に残すのに対し、エージェントは“何も残さずに壊れる”のが既定動作です。
だからこそ、インシデント運用は可観測性の設計と一体でなければ成立しません。プロンプト・ツール入出力・中間判断・トークン消費を構造化トレースとして残しておくこと自体が、事後調査の前提条件になります。可観測性については本連載の可観測性の回（③）で詳述していますが、インシデントの文脈では「調査可能性（investigability）を運用開始前に作り込む」ことが要点です。
自律連鎖：一つの誤りが増幅して広がる
エージェントは自ら計画し、ツールを呼び、その結果を受けて次の行動を決めます。この自律性は価値の源泉であると同時に、障害の増幅器でもあります。一度の誤った判断が次の入力を汚染し、それがさらに誤った行動を呼ぶ——人間が介在しないまま、誤りが指数的に連鎖していきます。
従来システムの障害が「壊れた部品で止まる」のに対し、エージェントの障害は「壊れたまま走り続ける」性質を持ちます。だからインシデント運用では、検知の速さと同じくらい“いかに速く走行を止めるか”（封じ込め）が重視されます。
エージェント固有のインシデント分類とSEV定義
特殊性を踏まえたうえで、次に「どんな壊れ方があるのか」を分類します。汎用的な障害（インフラ停止・API障害・レイテンシ悪化）はもちろん残りますが、ここではエージェント固有の5つの障害モードに絞ります。
エージェント固有の5つの障害モード
| 障害モード | 何が起きるか | 主なシグナル | 直接的リスク |
|---|---|---|---|
| 無限ループ／暴走 | 同じ計画・ツール呼び出しを終了条件に到達せず反復する | 1タスクあたりのステップ数・ツール呼び出し回数の急増 | レイテンシ悪化、コスト増、下流システムへの負荷 |
| コスト暴走 | トークン消費・API呼び出しが想定を超えて膨張する | 単位タスクあたりトークン数・課金額の分布逸脱 | 予算超過、レートリミット到達による全体停止 |
| 品質崩壊 | 可用性は保たれたまま、回答の正確性・妥当性だけが劣化する | 評価スコア・タスク成功率の低下、ユーザー是正率の上昇 | “静かな”誤情報提供、信頼低下、意思決定の汚染 |
| ツール連鎖障害 | あるツール／外部APIの不調が、エージェントの誤判断を通じて連鎖する | 特定ツールのエラー率上昇と、それに続く再試行・迂回行動 | 副作用のある操作の誤実行、部分的な整合性破壊 |
| メモリ汚染波及 | 誤った情報がメモリ／知識ベースに書き込まれ、以後の判断に伝播する | 複数セッションにまたがる同種の誤り、根拠不明の主張の再出現 | 時間差で広がる品質崩壊、原因特定の困難化 |
ここで重要なのは、可用性（落ちる／落ちない）だけを見ていると、品質崩壊とメモリ汚染波及は完全に見逃すという点です。エージェントは200 OKを返し続けながら、中身だけが静かに壊れていきます。従来型の死活監視では、このクラスの障害を捉えられません。
重大度（SEV）の定義
障害モードを分類したら、それを重大度（SEV）に対応づけ、オンコールの動き方を事前に決めておきます。エージェントでは「サービスは生きているが品質が壊れている」状態を明示的に高いSEVとして扱えるよう、可用性だけでなく品質・コスト・副作用の観点を重大度に織り込むのが要点です。
| 重大度 | 状態の目安 | 対応 |
|---|---|---|
| SEV1 | 副作用のある誤操作が進行中、または広範なコスト暴走・全体停止 | 即時オンコール招集、キルスイッチ発動、経営・関係部門へエスカレーション |
| SEV2 | 品質崩壊やメモリ汚染が疑われ、ユーザー影響が拡大しつつある | オンコール対応、該当機能の縮退（サーキットブレーカー）、原因調査を並行 |
| SEV3 | 局所的な品質低下・軽微なコスト逸脱で、影響が限定的 | 通常勤務時間内で対応、監視強化、ポストモーテムは任意 |
セキュリティのインシデントレスポンスとの棲み分け：本連載のセキュリティ側の回で扱った「インシデントレスポンス＆フォレンジック」は、攻撃を検知した後の証拠保全・原因追跡に主眼があります。本稿が扱うのは、攻撃に限らない非決定システムの運用インシデント全般——品質崩壊やコスト暴走、障害の連鎖に対するSRE的な運用規律です。攻撃が疑われる事象は、本稿のトリアージからセキュリティ側のフローへ引き継ぐ、という接続関係で捉えてください。
インシデントライフサイクル：検知→トリアージ→封じ込め→復旧
SEVを定義したら、実際の流れに落とし込みます。エージェントのインシデントライフサイクルは、従来の「検知→トリアージ→復旧」に“封じ込め”を独立した工程として明示的に挿入する点に特徴があります。自律連鎖を止める工程を、復旧とは切り離して先に置くのです。
検知：可用性ではなく“分布の逸脱”で気づく
検知の主役は、死活監視ではなく振る舞いの逸脱検知です。単位タスクあたりのステップ数・トークン消費・ツール呼び出し回数・評価スコア・ユーザー是正率——こうした指標について正常時の分布を持っておき、そこからの逸脱をアラート条件にします。「落ちた」ではなく「いつもと違う」で気づく設計です。
障害モードごとに、着目すべきシグナルは異なります。無限ループ／暴走なら1タスクあたりのステップ数やツール呼び出し回数の急増、コスト暴走なら単位タスクあたりのトークン数・課金額、品質崩壊なら評価スコアの低下とユーザー是正（回答のやり直し・訂正）率の上昇、メモリ汚染波及なら複数セッションにまたがる同種の誤りの再出現です。これらを個別のしきい値でも、機械学習ベースの異常検知でも構いませんが、いずれにせよ「正常時のベースラインを継続的に更新し続ける」ことが前提になります。モデル更新やプロンプト変更のたびにベースラインは動くため、逸脱検知は一度作って終わりにはできません。
トリアージ：影響範囲と“副作用の有無”を最優先で見る
アラートを受けたら、まず「どの障害モードか」「副作用のある操作をすでに実行したか」「影響がセッションを越えて波及しているか」を判定します。とりわけ副作用（外部への書き込み・課金・通知など不可逆な操作）が進行中か否かは、封じ込めの緊急度を決める分岐点です。ここで攻撃の兆候が見えれば、前述のとおりセキュリティ側のフローへ引き継ぎます。
封じ込め：走行を止める（キルスイッチ／サーキットブレーカーは“参照”）
封じ込めの目的は、原因究明より先に被害の拡大を物理的に止めることです。手段としては、該当エージェント／ツールのキルスイッチによる即時停止、負荷や失敗率に応じて自動で機能を切り離すサーキットブレーカー、そして安全側に倒す縮退運転（フォールバック）があります。
キルスイッチとサーキットブレーカーの実装そのものは、本連載の可観測性の回（③・検知トリガー）、権限の回（⑥・発動権限の設計）、デプロイの回（⑦・巻き戻し経路）で扱いました。本稿ではそれらをインシデント運用の中でいつ・誰が・どの権限で発動するかという運用面から参照するに留めます。重要なのは、封じ込め手段が「事故のときに慌てて用意するもの」ではなく、SEV定義と一体で事前に配線され、オンコールが権限をもって即座に引ける状態にあることです。
復旧・巻き戻し：状態を安全な地点へ戻す
走行を止めたら、影響を受けた状態を安全な地点へ戻します。エージェント特有の難しさは、コードだけでなくメモリ・知識ベースの巻き戻しが必要になり得る点です。メモリ汚染波及が起きていれば、汚染された書き込みを特定して除去・修正しなければ、復旧後に同じ誤りが再燃します。復旧は「サービスを戻す」だけでなく「汚染を除去する」までを含む、と定義しておきます。
| 工程 | 問い | 主なアクション |
|---|---|---|
| 検知 | いつもと違うか？ | 分布逸脱アラート、品質・コスト・ステップ数の監視 |
| トリアージ | どの障害モードで、副作用は進行中か？ | SEV判定、影響範囲の切り分け、攻撃兆候ならセキュリティへ引き継ぎ |
| 封じ込め | どうすれば今すぐ止まるか？ | キルスイッチ、サーキットブレーカー、縮退運転（いずれも事前配線） |
| 復旧 | どこまで戻せば安全か？ | デプロイ巻き戻し、メモリ／知識ベースの汚染除去、段階的な再開 |
非決定システムのオンコールとランブック自動化
ライフサイクルを回すのは人とランブックです。ここでは非決定システムに特有のオンコール設計と、その負荷を下げるランブック自動化を扱います。
オンコール設計：判断を要する呼び出しに絞る
エージェントのアラートは、確率的なばらつきに引きずられて誤検知（ノイズ）が増えやすいという課題があります。単発のエラーで人を叩き起こす設計は、すぐにアラート疲れを招きます。原則は「機械的に対処できるものは自動化し、人には“判断”を要する呼び出しだけを渡す”」ことです。
具体的には、分布逸脱が一定時間・一定件数継続した場合にのみ通知を昇格させる、SEVごとに通知経路と応答期待時間（例：SEV1は即時、SEV3は翌営業日）を分ける、といった設計で、オンコールの持続可能性を確保します。オンコール担当が最初に見るべき情報——直近のトレース、逸脱した指標、発動可能な封じ込め手段——を1画面に集約しておくことも、初動を速くします。
ランブックの自動化：定型対応はコード化する
ランブックは「事象→確認手順→対処手順」を明文化したものですが、エージェント運用ではこれを可能な限り自動実行可能なかたちに寄せます。たとえば「コスト暴走を検知したら、該当エージェントを自動で縮退運転に切り替え、オンコールにはSEV2として通知する」といった一次対応は、人の判断を待たずに実行させます。人間は、自動化された一次封じ込めの後で、原因究明と恒久対策という判断業務に集中します。
ここで注意したいのは、自動対応そのものが新たなインシデント源になり得ることです。自動縮退が過剰に発火して正常機能まで止める、といった事故を避けるため、自動ランブックにも発動条件・上限・手動オーバーライドを設け、その動作自体を可観測対象に含めます。
ゲームデー：封じ込めが本当に効くかを平時に確かめる
キルスイッチやサーキットブレーカーは、いざというときに一度も引いたことがなければ、本番で確実に効く保証はありません。SREの実践に倣い、ゲームデー（意図的な障害注入訓練）を平時に組み込むことをおすすめします。ステージング環境で無限ループやコスト暴走をわざと起こし、検知が鳴るか、封じ込めが効くか、オンコールが手順どおり動けるかを検証します。とりわけ品質崩壊やメモリ汚染波及は、実際に注入してみないと「そもそも気づけるのか」が分からない障害です。訓練を通じてMTTDや封じ込め時間を実測し、ランブックの穴を平時に潰しておくことで、本番での初動は大きく速くなります。
MTTD／MTTR とエラーバジェット——可観測性（③）と接続する
インシデント運用は「回したら終わり」ではなく、指標で測って改善し続けるものです。ここで従来のSRE指標を、エージェント向けに読み替えます。
指標の定義：品質を時間軸に載せる
| 指標 | 意味 | エージェントでの読み替え |
|---|---|---|
| MTTD（平均検知時間） | 異常発生から検知までの時間 | 品質崩壊・メモリ汚染など“静かな障害”をどれだけ速く捉えられたか |
| MTTR（平均復旧時間） | 検知から復旧までの時間 | 封じ込め＋汚染除去まで含めた、安全な状態への回復時間 |
| 封じ込め時間 | 検知から走行停止までの時間 | 自律連鎖を止めるまでの速さ。エージェント固有の重要指標 |
とりわけMTTDと封じ込め時間は、エージェント運用で従来以上に効いてきます。品質崩壊やメモリ汚染は放置するほど被害が時間差で広がるため、「速く気づき、速く止める」ことの価値が、可用性障害よりも大きいからです。
エラーバジェット：“落ちる前提”を定量的に運用する
本稿の入口で述べた「“落ちない前提”を捨てる」を、運用に落とし込む具体策がエラーバジェットです。エージェントには「一定割合の失敗・品質逸脱は起こり得る」という前提を置き、その許容量を予算として明示します。品質やタスク成功率にSLOを定め、逸脱の累積がバジェットを食い潰したら、新機能の投入を止めて信頼性の回復に振り向ける——という判断を、感覚ではなく数値で回します。
エラーバジェットとその土台となるSLO・品質メトリクスの取得は、可観測性の回（③）と密接に接続します。インシデント運用の側から見れば、エラーバジェットは「どこまでのインシデントを許容し、いつ開発の手を止めるか」という意思決定の共通言語として機能します。
ブレームレス・ポストモーテムを“評価ケース”へ——評価フライホイール（②）へ還流する
インシデント運用の最終工程は、学び直しです。ここが本連載の第一の要素である評価と円環をなす、連載完結編ならではの要点になります。
ブレームレスの原則：個人ではなく仕組みを問う
ポストモーテム（事後検証）は、ブレームレス（非難しない）を原則とします。「誰がミスをしたか」ではなく「なぜその仕組みでは事故が起き得たのか」を問う姿勢です。とりわけエージェントのインシデントは、非決定性ゆえに「特定の誰かの操作ミス」に帰着しないことが多く、犯人探しは本質的に無意味です。問うべきは、検知が遅れた理由、封じ込めが効かなかった理由、そしてその障害が評価で事前に捕まえられなかった理由です。
ポストモーテムを評価データセット化する——フライホイールの完成
ここが本稿の核心です。エージェント運用では、ポストモーテムの成果物を文書で終わらせず、再発防止のための“評価ケース”に変換して評価スイートへ組み込むことを標準工程にします。今回すり抜けた壊れ方を再現する入力・期待される振る舞い・不合格の条件をテストケース化し、以後のデプロイで自動的に検査されるようにするのです。
これにより、本番のインシデントが評価を鍛え、鍛えられた評価が次のデプロイでの再発を防ぐという循環——連載②で述べた評価フライホイール——が回り始めます。インシデントは損失であると同時に、二度と同じかたちでは壊れないための最良の学習データです。ポストモーテムの締めくくりを「ドキュメント公開」ではなく「評価ケースのマージ」と定義しておくことで、この還流は運用に定着します。
連載総括：7要素を1枚のライフサイクルに閉じる
ここまでで、インシデント運用が単独で完結するものではなく、他の6要素と配線されて初めて機能することが見えてきたはずです。連載の締めくくりとして、7要素を1枚のライフサイクルとして俯瞰します。
| 要素 | 役割 | インシデント運用との接続 |
|---|---|---|
| ② 評価 | 期待される振る舞いを定義し、継続検査する | ポストモーテムを評価ケース化して還流（フライホイール） |
| ③ 可観測性 | 振る舞いを構造化トレースで見えるようにする | 分布逸脱検知・MTTD・エラーバジェットの土台 |
| ④ コスト | トークン消費・課金を管理する | コスト暴走の検知と予算による封じ込め判断 |
| ⑤ メモリ | 状態・知識の保持と更新を制御する | メモリ汚染波及の検知と、復旧時の汚染除去 |
| ⑥ 権限 | エージェントが取れる行動の範囲を制限する | 副作用リスクの抑制と、封じ込め発動権限の設計 |
| ⑦ デプロイ | 安全に変更を出し、戻せるようにする | 巻き戻し経路の確保と、エラーバジェット連動のリリース判断 |
| ⑧ インシデント | 壊れたときに気づき・止め・学び直す | 本稿。6要素を運用時に束ね、評価へ還流して円環を閉じる |
7つの要素は独立した項目ではなく、評価から始まり、インシデントを経て再び評価へ戻る一つの円環です。可観測性がなければインシデントに気づけず、権限とデプロイの設計がなければ封じ込めも巻き戻しもできず、そしてインシデントを評価へ還流しなければ同じ壊れ方を繰り返します。AgentOpsとは、この円環を止めずに回し続ける運用規律そのものだと言えます。
まとめ——“落ちない前提”を捨てることから始める
AIエージェントの運用は、長らく「うまく動かすこと」に関心が集中してきました。しかし本番でエージェントを支えるのは、うまく動かなくなったときに、静かな崩壊にいち早く気づき、自律連鎖を止め、学びを評価へ還流するという地味な規律です。
本稿の要点は3つに集約されます。第一に、エージェントの障害は非決定性・揮発性・自律連鎖ゆえに“静かに壊れ、走り続ける”ため、可用性だけでなく品質・コスト・副作用を重大度に織り込む必要があること。第二に、検知と復旧のあいだに“封じ込め”を独立工程として置き、キルスイッチやサーキットブレーカーを事前配線しておくこと。第三に、ブレームレス・ポストモーテムを評価ケースへ変換して還流させ、インシデントを評価フライホイールの燃料に変えることです。
“落ちない前提”を捨て、“落ちる前提で運用する”——この発想の転換こそが、非決定的なエージェントを本番で信頼して使い続けるための出発点です。全7要素を1枚の円環として設計したとき、AgentOpsははじめて完成します。長きにわたった本連載にお付き合いいただき、ありがとうございました。
Q&A
Q1：可用性の監視（死活監視）だけでは、なぜ不十分なのですか？
エージェントの品質崩壊やメモリ汚染は、サービスが正常応答（200 OK）を返し続けたまま、回答の中身だけが劣化するかたちで進行します。死活監視はこのクラスの“静かな障害”を捉えられません。評価スコアやタスク成功率、ユーザー是正率といった品質指標の分布を監視対象に加える必要があります。
Q2：SEVは可用性障害と同じ基準で決めてよいですか？
そのままでは不十分です。エージェントでは「サービスは生きているが品質が壊れている」「副作用のある操作を誤実行しつつある」といった状態を高いSEVとして扱えるよう、可用性に加えて品質・コスト・副作用の観点を重大度定義に織り込むことをおすすめします。
Q3：キルスイッチやサーキットブレーカーは、この記事の範囲ですか？
実装そのものは可観測性・権限・デプロイの各回で扱っており、本稿では「インシデント運用の中でいつ・誰が・どの権限で発動するか」という運用面から参照しています。要点は、これらを事故時に急ごしらえするのではなく、SEV定義と一体で事前配線しておくことです。
Q4：セキュリティのインシデントレスポンスとは何が違うのですか？
セキュリティ側は「攻撃を検知した後の証拠保全・フォレンジック」に主眼があります。本稿は攻撃に限らない「非決定システムの運用インシデント全般」——品質崩壊・コスト暴走・障害連鎖——をSRE的に扱います。トリアージで攻撃の兆候が見えた事象は、セキュリティ側のフローへ引き継ぐ関係です。
Q5：ポストモーテムを“評価ケース化する”とは具体的に何をするのですか？
すり抜けた壊れ方を再現する入力、期待される振る舞い、不合格の条件をテストケースとして記述し、評価スイートへ組み込みます。以後のデプロイで自動検査されるようになり、同じ障害の再発を防ぎます。ポストモーテムの完了条件を「文書公開」ではなく「評価ケースのマージ」と定義するのがコツです。
参考リンク
- Google SRE Book / SRE Workbook（SLO・エラーバジェット・ポストモーテムの標準的な考え方）
- OWASP LLM Top 10（LLMアプリケーションのリスク分類）
- NIST AI Risk Management Framework（AIシステムのリスク管理フレームワーク）
関連記事
- AgentOps②：評価フライホイール——エージェントの品質を継続的に鍛える
- AgentOps③：可観測性——非決定システムを構造化トレースで見える化する
- AgentOps⑥：権限設計——エージェントの行動範囲をどう絞るか
- AgentOps⑦：デプロイ——安全に出し、確実に戻す
本記事は2026年9月時点の公開情報および標準的な運用フレームワーク（SRE等）に基づく一般的な情報提供であり、特定の製品・構成における安全性や可用性を保証するものではありません。また、法的助言ではありません。実際の運用設計にあたっては、自社の要件・リスク許容度に応じてご判断ください。
コメント