AIエージェントの障害対応｜復旧までの5手順

はじめに

AIエージェントを本番業務へ入れると、障害対応はサーバーの再起動だけでは終わらない。回答が不正確でも外部システムは正常に動き、メール送信やCRM更新だけが完了していることがある。反対に、画面では失敗に見えても、裏側では登録済みかもしれない。

必要なのは、モデル、ツール、データ、承認、処理後の状態を分けて確認する手順である。本記事では、誤送信、誤更新、権限外参照、同じ処理の重複実行などを想定し、初動から再開までを5手順で整理する。

AIエージェントの障害対応が通常システムと違う理由

従来のシステム障害では、エラー率、応答時間、CPU使用率などから異常を見つけやすい。AIエージェントでは、技術的には成功していても業務上は失敗という状態がある。たとえばAPIが200を返しても、対象顧客を取り違えた更新は成功ではない。

Microsoft FoundryのAgent Evaluatorsは、最終結果だけでなく、指示への準拠、ツール選択、入力パラメータ、ツール結果の利用、ツール呼び出しの成否を分けて評価している。障害対応でも同じ分解が必要だ。

「AIの回答が変だった」でまとめると、どの層を直すべきか分からない。まず事象を分解し、その後に影響範囲を確定する。

復旧までの5手順

1．止める単位を選び、被害の拡大を防ぐ

最初に決めるのは原因ではなく、どこまで止めるかである。全機能停止しか選べない設計では、軽微な不具合でも業務全体が止まる。一方、停止範囲が狭すぎると誤処理が続く。

停止単位は少なくとも次の4段階を用意する。

1. 特定のツールだけを無効化する
2. 外部書き込みだけを止め、検索と下書きは残す
3. 特定顧客・業務・利用者の処理だけを止める
4. エージェント全体を止める

誤送信の疑いがあるなら、メール送信を止めても下書き作成は続けられる。権限外参照なら、対象コネクタを切り離し、会話の継続も慎重に判断する。機密情報が応答に含まれた場合は、単なる品質問題ではなく情報管理のインシデントとして扱う。

停止判断表には「条件」「自動か手動か」「停止対象」「決定者」「解除権限」を書く。AIエージェントの停止条件も合わせて事前に仕様化しておくと、事故時の議論を減らせる。

2．証跡を保全し、再実行を止める

次に、調査に必要な証跡を保全する。ログを集める前に同じ処理を再実行すると、二重送信や二重登録が起き、元の状態も分かりにくくなる。

最低限、次を同じインシデントIDへ結びつける。

• 利用者の依頼と会話履歴
• エージェント、モデル、プロンプト、ルールの版
• 参照したファイル、検索結果、レコードIDと取得時刻
• 呼び出したツール、入力、応答、再試行回数
• 承認者、承認対象、承認時刻
• 外部システムで確認した処理後の状態

認証情報や個人情報を無制限にログへ残してはいけない。調査に必要なIDとマスク済みの値を中心にし、閲覧権限と保管期限を決める。監視項目の作り方はAIエージェント運用で残す5つのログで整理している。

また、タイムアウトを「未実行」とみなさない。外部システムの対象IDや、同じ論理操作を識別するキーを使って読み戻し、実行済みか未実行かを確定する。結果不明のまま新しい処理として再送しない。

3．影響範囲を「会話」ではなく「変更」で確定する

一つの会話が失敗したように見えても、影響範囲は会話数と一致しない。一回の依頼で複数のメール、タスク、CRMレコードを更新することもあるからだ。

影響調査は、次の順に進める。

1. 異常が始まった版と時刻を特定する
2. その期間に同じルール、モデル、ツールを使った実行を抽出する
3. 外部書き込みの対象IDを一覧にする
4. 正常、誤更新、重複、結果不明へ分類する
5. 個人情報、金銭、契約、外部送信の有無で重大度を決める

重大度は、件数だけで決めない。1件でも機密情報の漏えいや誤った契約処理なら高い重大度になる。反対に、社内下書きの表記揺れが100件あっても、外部影響は限定的かもしれない。

影響一覧には「元に戻せるか」も記録する。削除して作り直すしかないのか、履歴を残して訂正できるのか、相手への連絡が必要かで復旧手順は変わる。

4．切り戻しと訂正を分ける

復旧でありがちな失敗は、アプリを旧版へ戻しただけで完了とすることだ。旧版への切り戻しは今後の誤処理を止めるが、すでに送ったメールや更新済みデータは戻らない。

復旧計画を二つに分ける。

• 実行系の復旧：モデル、プロンプト、ルール、ツール設定を安全な版へ戻す
• 業務データの復旧：誤更新の訂正、重複削除、送信先への連絡、監査記録の保存を行う

業務データは、正常な変更まで一括で戻さない。対象IDごとに現在値を読み、期待値との差分を作り、承認後に訂正する。削除や上書きより、履歴が残る訂正処理を優先する。

復旧操作そのものも再実行に耐える必要がある。同じ対象へ二回適用しても二重訂正にならないか、途中で失敗した場合に成功済みと未完了を分けられるかを確認する。

5．再開条件を試験し、段階的に戻す

原因らしき箇所を直しただけでは再開できない。再開条件を、修正内容、回帰試験、監視、責任者の4点で判定する。

OpenAIの評価ガイドも、タスクを評価として定義し、テスト入力で実行し、結果を分析して改善する流れを示している。再開判定では、本番で失敗した入力を回帰データへ追加し、修正前後を比較する。詳細な受入条件はAIエージェントの受入テストも参考になる。

再開は、読み取り専用、社内下書き、承認付き書き込み、自動書き込みの順に段階を上げる。各段階で対象件数と期間を制限し、問題があれば前段階へ戻せるようにする。全機能を一度に戻すと、どの変更が効いたのか再び分からなくなる。

障害対応手順を仕様書へ入れる

事故が起きてから担当者の経験だけで対応すると、停止判断も復旧判断も遅れる。開発時点で、次の成果物を用意しておきたい。

• 停止条件と停止単位
• 連絡先と重大度別の判断者
• 証跡の項目、保存先、保管期限
• 影響範囲を抽出する検索条件
• 切り戻し手順と業務データ訂正手順
• 回帰データと再開判定表
• 再開後に強化する監視項目

これらは運用マニュアルだけに閉じず、要件、業務フロー、権限、テストケースと結びつける。業務変更で承認経路が変わったのに、障害対応だけ古いままという状態を防ぐためだ。AI業務整理ツール「Kakusill」のように業務フローと仕様をつなげて管理すれば、平常時の変更が停止・復旧手順へ与える影響も確認しやすい。

まとめ

AIエージェントの障害対応では、技術エラーと業務上の失敗を分け、停止、証跡保全、影響調査、切り戻し、再開判定を順に進める。特に重要なのは、タイムアウトを未実行と決めつけないこと、旧版へ戻す作業と業務データの訂正を分けること、再開を段階的に行うことである。

本番運用の安全性は、モデルの精度だけでは決まらない。異常が起きたときに被害を止め、現在状態を確認し、根拠を持って再開できることまで含めて、AIエージェントの仕様である。