Skip to Content
Docs05. 運用インシデント対応
中級incident-responseobservability更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

インシデント対応

この記事の目的

Agent 固有のインシデント — 暴走・コスト急騰・品質劣化・危険な操作 — に対して、検知 → 封じ込め(キルスイッチ)→ 影響特定 → 復旧 → 再発防止 の一連の対応を、インシデントが起きる前に設計できるようになります。特に「デプロイなしで止められる・自律度を下げられる」仕組みの事前準備に重点を置きます。

対象読者

  • Agent の本番運用でオンコール・障害対応に責任を持つエンジニア・SRE
  • 「もし暴走したらどう止めるか」に即答できない状態を解消したいチーム

前提知識

本文

概要: Agent 固有のインシデントの型

型例特徴
暴走無限に近いループ、同一 API への大量呼び出し技術メトリクスに出る。速度が速い
コスト急騰暴走・利用急増・長大コンテキストの常態化気づくのが遅れると請求額に直結
品質劣化モデル・入力分布・依存データの変化による誤答の増加エラーが出ない(静かな失敗エラーを出さずに完走しながら、誤った結果を返す・誤った副作用を残す失敗。技術メトリクスに現れないため、品質シグナルによる検知設計が必要になる。)。検知が最難
危険な操作・情報漏えい誤った書き込み・削除、機微情報を含む応答件数が少なくても影響が重大。セキュリティ起因は Agent の脅威モデル概観 で扱う
外部依存の障害LLM API・ツール先サービスの障害や劣化自システムに原因がない。フォールバックの有無で影響が決まる

通常のシステム障害と違うのは、「正常に動いているように見えるが間違っている」型が多いこと、そして影響が「誤った副作用の蓄積」として残ることです。対応の全体像は次の流れです。

インシデント対応: 概要: Agent 固有のインシデントの型の図インシデント対応: 概要: Agent 固有のインシデントの型の図
インシデント対応: 概要: Agent 固有のインシデントの型の図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

インシデント対応: 概要: Agent 固有のインシデントの型の図インシデント対応: 概要: Agent 固有のインシデントの型の図

詳細: 検知 — 静かな失敗まで拾う

可観測性とトレーシング で設計したメトリクスにアラートを張ります。

シグナル疑うもの
エラー率・タイムアウト率の上昇外部依存の障害、ツールの不具合
ステップ数分布の右シフト迷走・暴走の始まり(平均に出る前に裾に出る)
コストレート(単位時間あたりトークン)の急増暴走、利用の急変
品質シグナルの低下(フィードバック・エスカレーション率・サンプリング判定)静かな品質劣化。遅行指標であることを前提に見る
特定ツールの呼び出し頻度・失敗率の急変ツール先サービスの変化、プロンプト起因の挙動変化

品質劣化はどのメトリクスにも出にくいため、ユーザーからの報告を「個別対応して終わり」にせず、インシデント検知の入力として扱う経路(報告の集約とトリアージ)を作っておきます。

詳細: 封じ込め — キルスイッチは粒度を分けて事前に作る

インシデント対応の速度は、止める手段をどれだけ事前に作ってあるかで決まります。すべてデプロイなしで(フラグ・設定で)発動できることが条件です。

粒度仕組み使いどころ
自動遮断予算・レートの上限による自動停止(コスト管理 の 3 層上限)人間が気づく前の初動
ツール単位の無効化特定ツール(特に書き込み系)だけを外す・失敗を返す誤操作の停止。漏えい型では読み取り専用化・書き込み停止だけでは封じ込めにならない
縮退運転自律度を下げる — 全書き込みを承認必須に(Human-in-the-Loop 設計)、読み取り専用モードに、または Agent を止めて定型応答・人間対応に切り替え書き込み型の被害を抑える。漏えいの疑いがある場合は外部通信・応答も遮断する
テナント・機能単位の停止影響範囲・悪用元だけを止める特定ユーザー・特定機能に限定された事象
外部通信・外部取得の遮断ツールのエグレス、応答中の画像・URL の自動取得を停止読み取りや応答レンダリングを経由する情報漏えい
進行中セッションの停止実行中ジョブ・セッションを終了し、再開を禁止停止設定後も動き続ける処理の封じ込め
資格情報の失効API キー・委任トークンを失効し、必要なら交換漏えい・不正使用が疑われる資格情報(認証・認可)
全停止Agent 機能全体を止め、代替手段(定型応答・問い合わせ窓口)へ原因不明で被害が進行中のとき

「書き込み系ツールだけ止める」「承認必須モードに落とす」という中間段階があるかどうかで、インシデント時の選択肢がまるで違います。全停止しか手段がないと、判断が遅れがちです(機能を止める影響が大きいため)。

初手は事象に応じて変えます。

事象初手
暴走・コスト急騰実行中セッションと再試行を止め、予算・レート遮断を発動
誤った更新・削除対象の書き込みを無効化し、操作ログから補償を判断
情報漏えいの疑い外部通信・応答の外部取得と実行中セッションを止め、資格情報を失効

個人データが関わる可能性があれば、技術調査の完了を待たず法務・個人情報管理担当へ即時連絡します。漏えい時の報告・本人通知の確認入口で、当局報告と本人通知の要否・期限を判断します。

詳細: 影響特定と復旧 — 副作用の補償

封じ込めたら、影響範囲をトレースから特定します。「問題の構成(プロンプト・モデルのバージョン)で処理されたセッション」「問題のツールを呼んだセッション」をトレース属性で抽出できることが前提です(バージョニング・デプロイ・モデル更新追従 のバージョン記録)。

Agent 特有の重い作業が副作用の補償です。誤って行われた書き込み・送信・更新を洗い出し、巻き戻すか訂正します。

  • 書き込み操作ログに加え、読み取り(アクセスしたデータ・件数・主体)、モデルへ渡した内容、応答、外部通信(宛先・時刻・送信量)、応答レンダリングの外部取得ログを照合して漏えい範囲を特定します。調査資料はアクセスを制限し、秘密情報を調査ログへ再複製しないようにします
  • 巻き戻せない操作(外部への送信・通知など)は、事後の訂正連絡で対処するしかありません。だからこそ、取り消せない操作は平時から承認ゲートの対象にします(Human-in-the-Loop 設計)

設計判断: 事後 — 再発防止を資産にする

  • 問題を起こした入力・状況を回帰ケースとして追加します(回帰テストと CI 組み込み)。「同じ失敗は二度と静かに起きない」を積み上げます
  • 検知が遅れたなら監視・アラートを、封じ込めが遅れたならキルスイッチの粒度を、復旧が重かったなら操作ログ・補償手段を直します(対応の各段階がそのまま改善対象の一覧になります)
  • ポストモーテム(振り返り)を書き、ランブック(対応手順書)を更新します。キルスイッチは平時に発動演習をしておかないと、本番で「フラグはあるが誰も試したことがない」になります

実務での注意点

アンチパターン

  • 止める手段がデプロイしかない → 封じ込めまでの時間が伸び、その間も被害(コスト・誤操作)が進行する → フラグでの全停止・縮退・ツール単位無効化・自動遮断を事前に実装し、演習しておく
  • エラー率だけを監視する → エラーなく完走する誤動作(静かな失敗)を検知できず、ユーザー影響が長期化する → 品質シグナルとステップ数・コストの分布を監視に加える
  • 書き込み系ツールの操作ログがない → 影響特定が「期間内の全セッションを人手調査」になり、復旧が事実上不可能になる → 操作ログ(対象・内容・時刻)を残し、補償手段(巻き戻し・訂正)を設計しておく
  • 復旧して終わりにする(ポストモーテムなし) → 同じ型のインシデントが再発し、対応も毎回ゼロから → 回帰ケース化・ガード追加・ランブック更新をセットで完了条件にする

チェックリスト

  • 暴走・コスト急騰・品質劣化のそれぞれにアラートがある(分布・品質シグナルを含む)
  • デプロイなしで発動できる停止手段が粒度別(全停止・縮退・ツール単位・テナント単位)にある
  • 予算・レート上限による自動遮断がある
  • キルスイッチの発動演習を実施したことがある
  • トレースから影響セッションを抽出できる(構成バージョン・ツール呼び出しで絞れる)
  • 読み取り・応答・外部通信のログで漏えい範囲を調査でき、書き込みには補償手段がある
  • 外部通信・応答中の外部取得・セッションを停止し、資格情報を失効できる
  • 個人データの漏えいの疑いを法務へ即時連絡し、当局報告・本人通知を判断する導線がある
  • 取り消せない操作が平時から承認ゲートの対象になっている
  • インシデント後に回帰ケース化・ランブック更新を行う運用がある

関連トピック

参考資料

TODO・未確認事項

バージョニング・デプロイ・モデル更新追従デプロイとスケーリング