2026.09.17 / Agent Memories

複数AIの協働で効くAI記憶の引き継ぎ｜続きから動ける運用設計

複数のAIへ調査、制作、検査、公開準備を分担させると、処理自体は並列化できます。しかし、引き継ぎが「調べておいて」「終わりました」だけなら、統合担当は対象を特定できず、同じ調査や外部操作を繰り返します。担当AIの能力差より、完了済み工程と未完了工程を区別できないことが事故につながります。

複数AIの引き継ぎ記憶は、長い会話の要約ではありません。共通ゴール、担当範囲、実行済みwrite、成果物、次の一手を、受け手が再現できる形で渡すものです。ここでは単一writerを守りつつ並列性を生かし、結果不明後の二重実行を防ぐ設計を説明します。

委任前に共通ゴールと担当境界を固定する

「記事を完成させる」という案件でも、一次資料確認、本文制作、画像制作、品質確認、公開は別の一手です。委任時には、案件全体の完成形と今回の担当成果を分けます。対象、対象外、既存作業との重複確認、期待する戻り値を明記すると、各AIが善意でscopeを広げるのを防げます。

一つのファイルやstateへ同時に書く担当は一人にします。調査や候補比較は並列化しても、正本更新と外部公開は単一writerへ集約します。並列担当には読み取った正本のSHAと時刻を渡し、途中で正本が変わった場合に古い前提の成果を統合しないようにします。

引き継ぎ票を五つの欄に分ける

最小の引き継ぎ票は、既知事実、完了phase、未完了phase、実行済みwrite、次の一手の五欄です。「調査中」ではなく、どの仮説を確認し、何を否定し、どの資料を残したかを書きます。成果物にはpath、URL、SHA、版など同じ対象を特定できる識別子を付けます。

次の一手は一つに絞ります。「確認して必要なら修正して公開」では三工程です。まずread-onlyで現状を確認する、対象一件を修正する、公開可否を判断する、という境界に分けます。受け手が最初に読む順序も記憶へ含め、古いチャット全量の再読込を前提にしません。

実行済みwriteは結果と確実性を記録する

APIを呼んだ事実と、外部へ一回反映された事実は違います。writeには対象ID、冪等キー、実行時刻、応答、state、利用者側readbackを残します。応答前timeoutなら結果不明、応答成功でも公開面未確認なら確認待ちです。単に「完了」と書くと、次担当が再実行する危険があります。

結果不明の操作は隔離し、同じ対象をblind retryしません。外部state、公開URL、receipt、nonce、lockをread-onlyで確認し、成功済みなら再送せずreadbackを続けます。未実行が確定した場合だけ、新しいauthorityで未完了一手を一回実行します。

成果物だけでなく検査条件を渡す

「画像を作成済み」だけでは、受け手は採用可否を判断できません。サイズ、用途、使用素材、禁止事項、実画像確認の結果を一緒に渡します。文章なら文字数だけでなく、検索意図、一次資料、既存記事との境界、断定していない範囲を含めます。

検査は作業者の自己申告だけにしません。統合担当が成果物を開き、stateと照合し、対象外の差分がないことを確認します。見た目の成果物は原寸と縮小表示を見ます。テスト合格でも、別版を検査していたり、提出物のSHAが違ったりすれば引き継ぎ未成立です。

権限待ちと安全に進められる作業を分離する

公開承認を待っている間も、本文の事実確認、local preview、rollback準備は進められる場合があります。引き継ぎ票で「権限が必要な一手」と「外部変更なしで進められる一手」を分け、案件全体を包括停止しません。停止線には理由、解除条件、確認者、次回triggerを付けます。

別accountや別siteへのfallbackを受け手が勝手に選ばないよう、許可routeも記録します。権限がない場合は秘密情報をチャットで受け渡さず、承認済みsecret storeの参照名だけを使います。拒否ログやreceiptへcredential本文を残さないことも引き継ぎ品質です。

受領readbackで移管を完成させる

送信側が引き継ぎ票を書いただけでは移管完了ではありません。受け手が正本、対象成果物、完了済みwrite、次の一手を同じように特定できたか確認します。成功済み工程を再実行しないこと、対象外へ触れないことを受け手側の計画で読み返します。

統合後は、各担当の成果を一つの現状へまとめます。複数AIの報告件数ではなく、依頼目的が現実に成立したか、未履行や重複がないか、次の自然実行で継続できるかを判定します。受領不能なら担当移管済みと記録せず、元担当または統合担当が責任を保持します。

引き継ぎの実践テンプレート

共通ゴール、今回の担当成果、対象外を明記する。
参照したCurrentのpath、SHA、読取時刻を残す。
完了phaseと未完了phaseを別々に列挙する。
外部writeの対象、結果、確実性、readbackを書く。
成果物と自己QC、rollback、対象外差分を結ぶ。
受け手の次の一手を一つにし、受領確認を取る。

一次資料に照らした由来管理

OpenClawのMemory文書は、workspace内のMarkdownを長期記憶として扱い、人が確認・編集できる形を案内しています。引き継ぎを特定sessionの会話だけに閉じない設計へ応用できます。W3C PROV-Oは、成果物であるEntity、作業であるActivity、担当主体であるAgentの生成・利用・派生関係を定義し、誰のどの作業から成果が生まれたかを追う参考になります。

NIST AI Risk Management Frameworkは、Govern、Map、Measure、ManageでAIリスク管理を整理しています。本稿はAI RMF 1.0に基づく一般的な運用整理であり、NISTが案内する改訂版の内容や、特定のマルチエージェント製品の内部実装を断定しません。

よくある質問

会話ログを丸ごと渡す方が確実ではありませんか？

途中案や失効した指示が混ざり、受け手の判断負荷が上がります。正本と最新checkpointを先に渡し、必要な履歴へだけ戻れる構造にします。

複数AIが同じファイルを編集してもマージできますか？

機械的には可能でも、状態や判断の競合を見落とします。同時writeは避け、候補作成を並列化し、正本への統合は一人へ固定してください。

担当AIの完了報告はどこまで信用しますか？

報告は重要な証拠ですが終点ではありません。統合担当が成果物、SHA、state、実画面、対象外差分を独立にreadbackします。