2026.09.20 / Agent Memories

ツール自動化で効くAI記憶の出典管理｜続きから動ける運用設計

AIがチケット、表計算、CMS、SNSなどの外部ツールを操作する時、成功メッセージだけを記録しても監査には使えません。どの入力を参照し、どの版のルールで、誰の権限を使い、何を一回変更したかが分からなければ、誤更新の原因も戻し方も特定できないからです。

ツール自動化の出典管理は、URLを集める作業ではありません。入力、変換、実行主体、外部write、readbackを一つの因果として結ぶことです。AIの提案と実際の操作を分離し、結果不明後の重複を避けながら、後から同じ判断を検証できる記録を作ります。

一回の自動処理を因果の鎖として記録する

最小単位は「入力Entityを、あるActivityが利用し、出力Entityを生成した」と考えます。入力には正本、対象ID、確認済み事実、指示の版があります。Activityには実行時刻、利用tool、model、担当、authorityを持たせ、出力には更新後state、公開URL、receiptを結びます。

単なる時系列ログと違い、どの入力がどの出力を支えたかを明示します。複数資料を使った場合は、各資料が支えた主張や設定を記録します。検索snippetを公式仕様として扱わず、一次資料、利用者報告、自社観測、推論を別の種類にします。

実行前snapshotで対象と範囲を固定する

外部write前に、対象ID、現在値、件数、版、更新時刻を読みます。たとえば記事更新ならslug、公開状態、本文SHA、画像、一覧、sitemapを比較点にします。対象外のIDも必要に応じて件数やSHAで固定し、一件修正が全体更新へ広がっていないか確認できるようにします。

指示と正本には読取時刻を付けます。実行直前にSHAが変わった場合、古い計画をそのまま使わず再読込します。正本が複数ある、参照先が消えた、決定者が不明という場合は自動選択せず、影響操作を止めて競合として扱います。

提案した主体と実行した主体を分ける

AIが変更案を作り、人が承認し、別のservice accountが実行する場合、それぞれ役割が違います。提案者を承認者として記録したり、実行accountを判断者として扱ったりしません。委任範囲、承認対象、有効期限も由来へ含めます。

credential本文は出典記録へ保存しません。route、account、secret参照名、権限scopeだけを記録し、値は承認済みstoreへ置きます。ログやエラー、コマンドライン、画像メタデータへ秘密が混入しないことを確認します。

tool呼出しと外部反映を別の証拠にする

APIが200を返しても、利用者側に反映されていないことがあります。逆に応答前timeoutでも、外部では成功している場合があります。呼出しreceipt、provider state、利用者側URLまたは取得APIを別々に記録し、三者の対象IDと内容を照合します。

公開物はHTTP 200だけで終えず、canonical、見出し、画像、一覧、sitemap、重複数を確認します。通知なら宛先、message ID、本文版、送信回数を確認します。実行担当の「成功しました」という報告だけを最終証拠にしません。

変換ルールとソフトウェア版を残す

同じ入力でも、prompt、テンプレート、変換script、依存版が違えば出力が変わります。実行に使った設定SHA、script版、model、主要オプションを記録します。自動生成された文章や画像には、参照した事実とclaim境界を結びます。

ただし全環境を巨大なdumpとして保存する必要はありません。再現と原因究明に必要な要素を選び、秘密や不要な個人情報を除きます。変更されやすいaliasだけでなく、確認できる具体版を使い、取得不能な値はUNKNOWNとして推測しません。

retryは元の実行記録を読んでから判断する

timeoutやprocess中断後は、同じpayloadを再送する前に外部stateを読みます。nonce、lock、idempotency key、対象更新時刻、公開面から成功済みかを判定します。成功が確認できれば再実行せず、足りないreadbackだけを完了します。

未実行が確定した場合も、消費済みauthorityや古い入力版を再利用しません。未完了一手を新しいrunへ閉じ、成功済み対象を除外します。結果不明が解消できない一件は隔離し、別対象の正常処理まで止めないことが事業継続につながります。

復旧時は逆向きの由来をたどる

誤更新を見つけたら、出力から実行Activity、使用入力、承認、変換版へ逆にたどります。直前正常版が特定できる場合は対象一件だけを戻し、関係のない公開物やstateを変更しません。戻した操作も新しいActivityとして記録し、事故時の履歴を消しません。

復旧後は、対象機能、対象外差分、滞留、重複、通知を確認します。rollbackが成功しても、自動化のqueueに同じjobが残っていれば再発します。次回自然triggerで正常に一回動くまでをreadbackし、応急処置と恒久対策を別phaseで閉じます。

実行receiptの最小項目

目的、対象ID、対象外、実行時刻、cycle ID。
参照した正本、資料、確認箇所、SHA、確認日。
提案者、承認者、実行主体、account、権限scope。
tool、script、model、設定版、idempotency key。
変更前snapshot、応答、変更後state、利用者側readback。
結果の確実性、未確認事項、rollback、次回trigger。

一次資料で由来の意味を確認する

W3C PROV-Oは、Entity、Activity、Agentと、生成・利用・派生・帰属などの関係を定義します。ツール自動化の入力、処理、主体、出力を因果として表す直接的な参考になります。OpenClawのMemory文書は、workspaceのMarkdown記憶を人が確認・編集できる形で扱う方法を案内し、実行記録から現行正本を分離する設計に使えます。

NIST AI Risk Management Frameworkは、Govern、Map、Measure、ManageでAIリスク管理を整理します。本記事はAI RMF 1.0を参照し、NISTが案内する改訂作業の内容を先取りしません。特定toolの完全な監査性や法的適合を保証するものではなく、契約・規制・組織ルールは最新版を確認してください。

よくある質問

通常のapplication logだけでは足りませんか？

時系列は分かっても、どの正本と承認が出力を支えたか、利用者側へ一回反映されたかが分からない場合があります。因果とreadbackを追加します。

すべての入力本文をreceiptへ保存すべきですか？

必要ありません。再現に必要なSHA、版、対象ID、参照先を残し、secretや不要な個人情報を複製しないようにします。

結果不明なら安全のため再実行すべきですか？

再実行が二重投稿や二重課金を作ります。外部stateと冪等証拠を先に読み、未実行が確定した一手だけを新しいauthorityで行います。