2026.09.07 / Agent Memories

ツール自動化で効くAI記憶の定期レビュー｜続きから動ける運用設計

ツール自動化は、最初に動いた瞬間より、三か月後の方が危険です。接続先が変わり、権限が広がり、例外ルールが増えても、AIの記憶には「成功した手順」だけが残りやすいからです。その手順を無条件で繰り返すと、古い宛先への送信や二重実行が起きます。

定期レビューは自動化を止める儀式ではありません。現在も有効な操作、期限切れの前提、人へ戻す条件、復旧経路を棚卸しし、安全に動かし続けるための保守です。チェック回数を増やすのではなく、変化の大きい箇所へ確認を集中させます。

レビュー対象を実行経路の五地点に絞る

入口、判断、権限、外部write、readbackの五地点を見ます。入口では入力元と信頼度、判断では現在の条件、権限ではscopeと期限、writeでは重複防止、readbackでは成功を証明する実物を確認します。コード全体を毎回読むより、事故へ直結する境界を追う方が効率的です。

各地点にOwner、最終確認日、次回確認トリガーを付けます。「毎月」だけでなく、API版変更、権限追加、投稿先追加、同一エラー二回、結果不明の発生など、出来事による見直し条件を設定します。変化のない低リスク経路は軽くし、外部影響が大きい経路を優先します。

成功手順の記憶から期限切れ前提を探す

成功ログには、その時だけ成立した条件が隠れています。テスト用チャンネル、期間限定の認証、手動承認、暫定ファイル、特定のモデル版です。レビューでは手順を再実行せず、前提を一つずつ現状態と照合します。確認できない前提は「たぶん同じ」とせず、影響するwriteだけを保留します。

OpenClaw Memory overviewは、行動へ影響する記憶について、適用条件、失効、避ける行動、sourceやownerを残す考え方を説明しています。自動化の記憶には、コマンドだけでなく「いつ実行してよいか」「何をしてはいけないか」を持たせる必要があります。

権限とrouteをread-onlyで照合する

投稿先、アカウント、secretの参照名、API scopeを台帳と比べます。レビューのために新しいcredentialを発行したり、本番writeで疎通確認したりしません。可能なら権限一覧、接続先ID、dry-run結果を読み、対象外へのアクセスが増えていないか確認します。

secret本文はレビュー資料へ複製せず、保管場所と参照識別子だけを記録します。有効期限が近い場合はrotation計画を別taskにし、正常な経路を一律停止しません。権限が不足している時も、別アカウントへ勝手に切り替えず、正規routeの復旧条件を明らかにします。

入力から外部結果まで由来を一本化する

どの入力が、どの変換を通り、どのツールによって、どの外部結果になったかを追います。W3C PROV-Oは、Entity、Activity、Agentとその関係で由来情報を表現・交換できる語彙を定めています。自動化では、入力ファイルをEntity、生成や送信をActivity、AIやconnectorをAgent相当として関連付けられます。

実務台帳にはinput SHA、変換版、route ID、nonce、外部receipt、公開URLを置きます。由来が切れている結果は、成功件数へ入れずreadback待ちにします。別の入力が同じURLを上書きしていないかも確認します。この追跡があれば、事故時に全自動化を止めず、問題の経路だけを隔離できます。

結果不明と再実行の試験を机上で行う

タイムアウト、応答欠落、process中断を想定し、再実行前に何を読むかを確認します。nonce、lock、state、外部一覧、公開面の順序を決め、すでに反映されている場合は送信しない負例を試します。成功系だけのテストでは、最も起こりやすい二重処理を防げません。

自動回復を実装する場合も、同じエラーを回数だけ繰り返す設計を避けます。未実行が確定した時だけ新しいauthorityで一回行い、矛盾があれば人へ戻します。公開処理の冪等性についてはMCP rollbackチェック、運用上の停止線はリスク境界を覚えるAIも参考になります。

レビュー結果を残す・直す・隔離へ分類する

正常な経路は残す、更新が必要な記憶は直す、影響が読めない経路は対象限定で隔離します。廃止候補は即削除せず、利用状況、依存先、戻し方を確認します。応急修正と恒久対策を同じ変更へ詰めると、復旧が遅れ、rollbackも難しくなります。

結果は「レビュー済み」の一語で終えず、対象、発見差分、事業影響、次の対応、実行可否、完了条件を記します。修正後は次の自然triggerを観測し、重複、滞留、対象外差分がないことを確認します。レビュー習慣の作り方は記憶レビューのルーティンにも整理されています。

AI RMF 1.0と改訂中の境界を保つ

NIST AI RMF公式は、AIリスク管理の能力を高めるための自発的枠組みとしてAI RMFを公開しています。本記事で根拠にする版は2023年のAI RMF 1.0です。NISTは現在1.0を改訂中だと案内しているため、定期レビュー時には版を再確認し、改訂中の内容を現行要件として混ぜません。

自動化レビューでは、運用の統治、利用文脈の把握、挙動の測定、対応の管理をつなぐ視点として活用できます。ただしAI RMFが各ツールの安全設定を決めてくれるわけではありません。提供者の公式仕様、契約、組織の承認規則を一次の運用正本にします。

レビュー担当が実装者と同じ場合でも、入力receiptと外部結果を別々に読み、成功したという自己申告だけで閉じません。可能なら別担当が公開面を確認します。担当を分けられない一人運用では、時間を置いた再確認と機械的な件数照合を組み合わせます。確認時刻と閲覧した画面も残します。

よくある質問

問題が起きていなくても毎月レビューすべきですか？

固定周期とイベント契機を組み合わせます。外部writeや権限変更を伴う経路は定期確認し、API更新や結果不明があれば周期を待たず確認します。完全localで可逆な処理は頻度を下げられます。全経路を同じ重さにしないことが継続の鍵です。

レビューのためのテスト投稿はしてよいですか？

まずdry-run、fixture、sandbox、read-only APIを使います。本番投稿が必要なら、専用テスト先、費用、削除方法、通知影響、承認を固定し、通常運用と混ぜません。本記事の定期レビュー自体は本番writeを前提にしません。

古い自動化は念のため全部停止した方が安全ですか？

正常に動く経路まで止めると、公開欠損や顧客対応遅延という別の損失が生まれます。問題のあるroute、権限、操作だけを隔離し、影響外は維持します。法的違反、secret漏洩、不可逆破壊など緊急性が高い場合は、関係する影響操作を即時停止して復旧を進めます。

次回triggerの観測までがレビュー

チェック表を埋め、修正を入れただけでは閉じません。次の自然な実行で、対象exact1、外部結果、state、通知、重複なしを読み返します。まず一つの投稿自動化を選び、五地点と失効条件を書き出してください。定期レビューが機能すると、AIの記憶は古い成功手順の倉庫から、現在の条件で安全に動くための運用台帳へ変わります。