2026.10.31 / Agent Memories

トラブル対応で効くAI記憶の停止線｜続きから動ける運用設計

障害対応中のAIに「危ないので止めて」と伝えた結果、調査も代替運用も進まなくなる。逆に「復旧して」と頼んだだけで、状況が分からないまま再送や再実行へ進んでしまう。どちらも、止める対象が操作の単位で決まっていないことが一因です。トラブル対応の記憶には、禁止事項だけでなく、安全に続けられる仕事と再開を判断する証拠を残します。

最初に被害が増える操作を名指しする

メール送信サービスで重複配信が疑われるなら、止める対象は該当キャンペーンの追加送信です。ログの閲覧や配信先一覧の照合まで止める理由にはなりません。データ破損の疑いなら、上書きを伴う処理と、原本を変更しない調査を分けます。サービス名だけで禁止すると、必要な復旧作業まで巻き込んでしまいます。

記録には対象、危険な操作、理由、続行できる操作、判断者を短く書きます。たとえば「対象リストへの新規送信を保留。既送信の確認と未送信の抽出は続行。再送の判断は担当責任者」とすれば、次のAIも動ける範囲を理解できます。秘密情報の漏えいや進行中の被害がある場合は、関係する操作を直ちに止め、組織の緊急対応規則に従ってください。

事実と疑いを同じ色に塗らない

監視通知が来た段階では、通信失敗、処理遅延、実際の失敗が区別できないことがあります。「応答がなかった」は観測事実ですが、「送信されていない」はまだ推測かもしれません。AIの記憶には観測時刻と確認先を付け、未確認の結論を確定情報として保存しないようにします。

架空の例で、外部サービスへの書き込み後に画面が固まったとします。受付番号、対象レコード、更新時刻を先に照合し、処理済みなら二回目を送らないでください。結果を確認できるまでは、同じ対象への変更だけを保留します。原因調査や別対象の安全な整理まで止めず、結果を判定するための証拠集めを続けます。

応急処置に有効期限と次の判断を付ける

緊急時には一時的な制限が必要でも、そのまま恒久運用にすると別の損失が生まれます。対象機能の停止で受け付けられなかった依頼、積み残した作業、重複を避けるために保留した処理を把握します。制限を設けた時点で、誰が、どの情報を見て、いつ見直すかを決めてください。

「原因が完全に分かるまで全部停止」という表現は、復旧の条件が測れません。危険な経路を隔離し、確認済みの範囲だけ再開できるかを検討します。ただし権限、法令、契約で定められた確認を省略する意味ではありません。暫定運用で残るリスクと、恒久修正で解消する課題を別にし、暫定措置の終了条件を残します。

再開前の確認を処理の前後で対にする

操作前には対象と入力版、実行権限、戻せる範囲を確認します。操作後には意図した結果と、対象外の差分、重複の有無を確認します。実行ログが「成功」と言っていても、利用者の画面が古いままなら必要な機能は戻っていません。逆に通知の送信だけ失敗していて、本体処理は完了している場合もあります。

1. 対象一件の現在状態を読み取る。
2. 実行済みの工程と未実行の工程を分ける。
3. 既存の正規手順で未実行の一手を実行する。
4. 成果と対象外の状態を直接確認する。
5. 滞留分を重複なく扱い、次の通常運転を確認する。

復旧用だけの別経路を急造すると、本来の検査や重複防止を抜ける恐れがあります。通常の実行経路と同じ確認を使い、必要な修正を正規の手順へ反映します。障害対応メモは、便利な抜け道の集積ではなく、再開の根拠を示す記録にしてください。

AIへ渡すのは命令の山ではなく状態の差

長い会話を丸ごと渡すと、発生直後の「全面停止」と、その後の「一部再開」が同時に残ります。引き継ぎでは現在有効な制限を先に示し、解除した条件は過去の判断として分けます。変更時刻、判断者、確認した成果を付ければ、どの指示が現行かを判断しやすくなります。過去の警戒をなかったことにせず、今の操作へ誤適用させない工夫です。

対応中の担当も一人に定めます。複数のAIが同じ復旧対象へ書き込むと、片方の確認結果がもう片方の操作で古くなります。調査を分担する場合も、実行する担当と成果を受け取る担当を分け、書き込み直前に状態を再確認します。前の担当の処理が結果不明なら、新担当はまず受け付けと出力の有無を読み取ります。

停止判断が適切だったか振り返る

事故後には、止めたことで防げた被害と、止めたことで増えた滞留の両方を見ます。確認に必要な資料がどこにあるか分からず復旧が遅れたなら、AIの慎重さではなく参照導線の改善が必要かもしれません。判断者の不在が原因なら代理や連絡条件を組織内で決めます。同じ警告文を増やすだけでは、次回も同じ場所で詰まります。

代表的な失敗を検証環境で再現し、対象操作だけを止められるか、安全な調査が続くか、解除後に通常運転へ戻れるかを試します。検証用データを使い、本番へ二重送信して試験しないでください。復旧が一度成功したことと、次回の担当が同じ根拠で再開できることを分けて評価します。

障害の疑いがあれば何もしてはいけませんか？

影響のある変更を限定して保留し、許可された読み取りや原因調査を続けます。秘密情報の扱いなど、調査にも適用される境界は守ります。

再開をAIだけで判断してよいですか？

事前に認められた操作と確認条件に従います。公開や権限など人の判断が必要な範囲を、復旧の名目で拡大しません。

保留した依頼はいつ処理しますか？

再開時に既処理分と未処理分を照合して回収します。受付順や期限も考慮し、放置と重複の両方を防ぎます。

参考にした枠組みと適用の限界

NIST AI RMFはGovern・Map・Measure・ManageでAIリスク管理を整理しています。本稿の操作単位の停止はその枠組みを踏まえた実務提案で、NISTが個別の復旧を承認するものではありません。W3C PROV-OはEntity、Activity、Agentを用いて由来を表現します。OpenClaw Memoryはファイルに記憶を残す仕組みを説明しており、障害時も現在の判断を明示する設計の参考になります。

引き継ぐ情報の選び方は会話履歴とは違う記憶、現行条件の指定は正本を教える、解除理由の保存は判断理由を残すも参考にしてください。実際の事故対応は組織の規則と担当者の判断を優先します。