2026.09.04 / Agent Memories

複数AIの協働で効くAI記憶の戻し方｜続きから動ける運用設計

複数のAIが同じ仕事へ関わると、失敗は一つの処理だけで終わりません。調査AIが古い資料を選び、制作AIが原稿へ反映し、投稿AIが外部へ送る。最後の段階で気づいた時、「前に戻す」という一言では、どこまで戻すか決められません。

必要なのは、変更前の地点、各AIが行った操作、現在の外部状態、戻した後の確認を一本につなぐ記憶です。ここではrollbackを単なるバックアップ復元ではなく、二重投稿や別案件への巻き込みを防ぐ協働プロトコルとして設計します。

「元に戻す」を四種類へ分解する

設定を直前版へ差し替える、公開物を非公開へする、誤ったデータだけを訂正する、進行中の予約を止める。これらは似ていても影響が違います。最初に「復元」「取消」「訂正」「隔離」のどれかを選び、対象外を記します。全システム停止のような広い操作を既定にしてはいけません。

復元できても、事故中に発生した通知や注文は消えません。技術状態の復旧と、取りこぼし・重複・利用者影響の回収を別の工程にします。rollback記憶には、戻す対象、直前正常点、戻さない隣接領域、影響期間、回収担当を持たせます。

変更前のスナップショットを意味のある証拠にする

ファイルをコピーするだけでは不足です。対象パス、ハッシュ、件数、公開URL、deployment ID、状態値、取得時刻を組み合わせます。どの証拠が何を保証するのかも記します。ハッシュ一致は内容の一致を示せますが、予約ジョブが動いていないことまでは保証しません。

外部writeの前には、実行権限、対象、期待する差分、冪等性キー、成功判定を固定します。各AIが別々の「念のためバックアップ」を作るのではなく、rollback coordinatorが一つの復元点を宣言し、他のAIは参照だけします。これで古いバックアップへの競合復元を避けられます。

操作台帳でAIごとの責任範囲を切る

一つの実行を、prepare、approve、write、readback、notifyへ分割します。それぞれの担当AI、入力artifact、実行時刻、結果、次工程への条件を台帳へ記録します。write担当が結果不明になった時、別のAIは同じwriteを引き継がず、readback担当として現在状態を調べます。

由来を扱うW3C PROV-Oは、Entity、Activity、Agentと、生成・利用・帰属などの関係を表現できます。実装を複雑にしなくても、「この設定ファイルを使い、このAIの操作で、この公開物が生成された」という結び付けがあれば、戻すべき派生物を探せます。

結果不明では再実行より照合を先にする

タイムアウトは失敗の証拠ではありません。送信は成功し、応答だけ失われた可能性があります。そこでnonce、receipt、公開URL、外部一覧、local stateを読み、実行済み・未実行・矛盾の三状態へ分類します。矛盾している間は新しいwriteを行いません。

実行済みなら通知やstateの不足だけを回収します。未実行が確定したら、新しい権限と識別子で一回だけ行います。結果不明のまま同じ識別子を再利用すると、二重投稿や上書きが起きます。AI運用のrollback記憶とMCPの戻し方チェックリストも、この照合を具体化する資料です。

記憶を再開地点として機能させる

OpenClawのMemory overviewは、永続的な要点をMarkdownへ保存し、日々の詳細を日次ノートへ分ける仕組みを説明しています。rollbackに関わる長期記憶には、現在のauthority、最後に確定したphase、未完了の次の一手、禁止されている再実行を残します。大量のログは日次記録やreceiptへ参照します。

再開するAIは正本、最新checkpoint、外部状態の順に読みます。すでに完了したphaseはスキップし、未完了の一手だけを実行候補にします。ログ末尾のコマンドをそのまま再実行するのではなく、そのコマンドが消費済みかを先に判定します。

復旧後は隣接デグレと滞留を確認する

対象ページが元に戻っても、一覧、検索用sitemap、SNSカード、予約列、通知stateがずれている場合があります。readbackは対象そのもの、派生面、対象外の正常経路を分けます。対象外に差分があれば、rollbackが広すぎた可能性があります。

また停止期間中の未処理件数を数えます。自動で一括再送せず、重複の有無を照合し、期限と顧客影響で優先度を付けます。復旧完了の条件は「画面が戻った」だけでなく、意図しない副作用がなく、滞留と重複の扱いが決まり、次の自然実行を確認できることです。

リスク枠組みとrollbackの版境界

NIST AI RMFは、AI製品・サービス・システムの設計、開発、利用、評価へ信頼性の観点を組み込む自発的枠組みです。本稿は2023年公開のAI RMF 1.0を参照します。NISTはAI RMF 1.0を現在改訂中と案内しているため、改訂中の将来内容を現行1.0の要件として扱いません。

rollback設計では、誰がリスクを管理し、どの影響を観測し、どの閾値で停止・復旧するかを事前に決める助けになります。ただし個別システムの復元手順は、実際のデータ構造、提供者の仕様、契約条件に合わせて検証します。

演習では、本番データを触らずに三つの失敗を再現します。write前の中断、write後の応答欠落、readbackだけの失敗です。それぞれで次担当が何を読み、どの操作を禁止し、どの証拠で再開するかを確認します。同じ「エラー」でも未実行、実行済み、確認不能では復旧策が違うと体験できます。

rollback手順にも有効期限を付けます。APIや画面、保存先が変わった後の古い手順は、安心材料ではなく誤操作の入口です。四半期ごとに復元点へ到達できるかをread-onlyで確かめ、変更があれば手順を更新し、旧版を現行候補から外します。

よくある質問

すべての変更に完全なバックアップが必要ですか？

変更の影響に応じて密度を変えます。文章一段落の可逆な修正なら対象ファイルと差分で足ります。外部配信、課金、権限、データ移行では、外部状態と回収手順まで必要です。重要なのはバックアップ量ではなく、復旧条件を証明できることです。

一番詳しいAIをrollback担当にすべきですか？

知識量より、単一の調整役と権限分離が重要です。変更を実行したAIとは別のreadback役を置くと、成功したつもりの見落としを減らせます。複数AIの役割設計はAIごとの経路分離も参考になります。

rollbackに失敗したら同じ手順を繰り返しますか？

繰り返しません。外部write前後の状態を確認し、新しい失敗原因と影響を切り分けます。手順自体が消費済みなら別の復旧packageを作り、対象と権限を再固定します。blind retryは問題を増やすため禁止します。

戻せることは、安心して進めるための前提

rollback記憶は事故後に慌てて書く文書ではありません。変更前に復元点、対象外、成功判定を決め、実行後に実物を読む。まず一つの自動投稿で、prepareからnotifyまでの操作台帳を作り、タイムアウト時の照合手順を机上で試してください。複数AIの速度を活かせるのは、誰がどこまで戻すかを全員が同じ記憶から読める時です。