Attributed Memory
エージェントが記憶する内容を、匿名のテキストの塊としてではなく、そのオリジン（発生元）、削除権限を持つオーナー、および有効期間を保持するレコードとして保存します。メモリは、単発の攻撃を、将来の無関係なタスクで再トリガーされる攻撃へと変えてしまう要因です。アトリビューション（属性定義）こそが、それを可逆的なものにします。
定義
Attributed Memoryとは、永続的なエージェントメモリのすべてを、プロバナンス（その主張がどこから来て、誰の権限を伴っていたか）、削除可能な指名されたオーナー、および有効期限を持つレコードとして書き込むプラクティスです。これにより、誤った事実を追跡して削除することができ、それが叶わなくても自然に消滅させることができます。
課題
永続メモリに自由形式のテキストを書き込むエージェントは、後からどの記憶が指示されたものか、どの記憶が見知らぬ人のウェブページから読み取ったものか、そしてどの記憶を自身で推論したのかを区別できません。その結果、1つの汚染された書き込みが、それを植え付けた会話とはまったく関係のないタスクにおいて、信頼できるコンテキストとして再浮上することになります。
適用対象
作成されたセッションよりもメモリが長生きするあらゆる場所で使用します。設定を記憶するアシスタント、プロジェクトの状態を蓄積するエージェント、エージェント自身が書き込む検索ストアなどです。保持期間が長くなり、エージェントが作成したコーパスの割合が増えるほど、メモリはノートブックではなくレコードストアである必要があります。
解決策
匿名の書き込みを拒否します。すべてのレコードは、その主張がどこから来たのか（セッションとターン、ツールまたはドキュメント、外部からの場合はURL）を、テキスト内の文章としてではなく、構造化されたフィールドとして保持します。
その主張が誰の権限を伴っていたかを記録します。オペレーターが設定した事実、エンドユーザーが主張した事実、エージェントがサードパーティのページで読み取った事実は、それぞれ異なる3つの主張です。検索パスがそれらに重み付けをし、レビュー担当者が分類できるように、クラスを明示的に維持します。
すべてのレコードに有効期間を設定し、デフォルトは短くします。期限切れにならないメモリは誰もレビューすることはありません。汚染された書き込みの半減期こそが、攻撃の影響がどれだけ長く続くかを決定します。
指名されたオーナーを伴う第一級の操作として削除を定義し、それを伝播させます。埋め込み（embedding）、キャッシュされた要約、または派生したプロファイルに主張が残っている場合、レコードを削除するだけでは不十分です。
書き込みパスをアクションとして扱います。メモリの書き込みは将来の動作を変更するため、保存先がたまたまファイルであるからといって裏口から行うのではなく、他の書き込みと同様の認可とログ記録を経由させます。
検索されたメモリを指示（instruction）としてプロンプトに再入力させてはなりません。それはオリジンが添付されたデータとして到達し、オリジンがサードパーティであるレコードは、そのサードパーティからの信頼できない入力とまったく同じように扱われます。
コンポーネント
メリット
- メモリ汚染を可逆的なものにします。書き込みを特定し、その発生元を確認し、そこから派生したすべてのものを削除できます。
- 「このエージェントは私について何を信じているのか？」という問いを、人間が読める回答が存在する質問に変えます。
- テキストがどれほど自信ありげに書かれているかではなく、そのオリジンに基づいて主張に重み付けをして検索できるようにします。
- 個人に関して永続化されたあらゆるデータに適用される保持および消去の義務を、後から別の仕組みを継ぎ接ぎすることなく満たします。
リスク
- プロバナンス・シアター（形だけのプロバナンス）：オリジンフィールドが常に「agent」となっており、何も記録していないにもかかわらず、コントロールが機能しているように見せかけること。
- コンパクション・ロンダリング（要約による属性ロンダリング） — アトリビューションが失われる最も一般的な原因。属性付きの10個のレコードを1つの段落に要約すると、属性のない主張が生成され、それが合意事項のように見えてしまいます。
- 部分的な削除：プライマリレコードは削除されるものの、ベクトルが残り、その主張が検索され続けること。
- 過剰な期限切れによってメモリが存在していた目的である連続性が破壊され、結果として期限切れ設定を完全に無効化するようになってしまうこと。
非推奨のケース
- 永続性のないシングルセッションのエージェント：属性を付与すべきメモリが存在せず、形式的な手続きによるメリットがありません。
- ストアが、すでにガバナンスが効いている自社のシステム・オブ・レコード（SoR）のキャッシュである場合。派生した行ごとではなく、ソースシステムに対して一度だけ属性を付与します。
- オーバーヘッドのせいでオペレーターが実際のメモをシステムの外部に保管するようになる場合。これは、システム内に不完全なレコードを保持するよりも明らかに悪質です。
テクノロジー
事例
- 「メートル法を好む」と書き込むアシスタント。レコードにはセッションIDとユーザーがそれを発言したターンが保持されるため、誤った設定を原因となった文まで追跡して削除できます。
- サードパーティのページを読み込み、事実としてではなく「そのURLで、その日付に観測された」というタグ付きで主張を保存する調査エージェント。数ヶ月後に同じ主張が検索されたとき、そのオリジンも一緒に取得されます。
- デフォルトでメモリレコードが90日後に期限切れになるサポートエージェント。人間が明示的に確認したエントリのみ有効期間が延長されるため、レビューされていない大部分は期限切れとなり、レビュー済みの少数が残ります。
KPI
- 属性付き書き込みの割合
- 機械可読なオリジンを保持しているメモリレコードの割合。これが100%未満の場合、ストアは主張がどこから来たのかを回答できず、コントロールとしての意味をなしません。
- レコード年齢の中央値
- 実際に使用されているメモリの古さ。削除が行われずに中央値が上昇している場合、ストアがキュレーションされることなく蓄積されていることを意味します。
- 削除伝播の遅延
- レコードが削除されてから、すべての派生アーティファクトからその主張が検索できなくなるまでの時間。削除された主張が依然として機能してしまう期間を指します。
- 予定通りに期限切れとなった割合
- 有効期限に達し、実際に削除されたレコードの割合。有効期間が単なる宣言ではなく、実際に機能している証拠となります。
観察された失敗パターン
- 遅延型汚染：ある会話で植え付けられた誤った事実が、数週間後に無関係なタスクで浮上し、コンテキストのどこにもエージェントがそれを信じる理由が説明されていない状態。
- 要約の残存：レコードは削除されたものの、それを吸収した圧縮要約が削除されず、主張がその情報源よりも長生きしてしまう状態。
- シャドウインデックス：削除されたレコードの埋め込み（embedding）が検索可能なまま残っているため、監査人が確認したすべての場所では削除が成功しているように見えても、重要な場所では機能していない状態。
- アイデンティティの漏洩：メモリのキー設定が緩いため、あるユーザーのレコードが別のユーザーのために検索されてしまい、メモリ設計の欠陥が情報漏洩につながる状態。
得られた教訓
- アトリビューションは書き込み時には低コストですが、後から再構築することは不可能です。主張が存在する前に、フィールドが存在していなければなりません。
- すべての圧縮ステップはアトリビューションの境界です。要約処理がオリジンを引き継ぐことができない場合、それは情報源のない新しい主張を生み出していることになります。
- 誰も実行されたのを見たことがない有効期限は、ポリシーであってコントロールではありません。
- 削除の完全性は、忘れてしまった派生アーティファクトの存在によって左右されます。
FAQ
- これは単に、手順を増やしたデータ保持ポリシー（retention policy）ではないのですか？
- 保持ポリシーはデータがいつ消えるかを決定します。アトリビューションは、主張がどこから来て、誰がそれを削除できるかを決定します。これは、メモリが単に古いだけでなく、誤りであることが判明した瞬間に必要となるものです。この2つは相互補完的です。有効期限がなければアトリビューションは蓄積し続け、アトリビューションがなければ有効期限は理解していなかった証拠を削除してしまいます。
- エージェントが自身のメモリを書き込む場合、それらは誰の権限を伴うのですか？
- エージェント自身の権限であり、それこそが定義する価値のあるクラスです。エージェントが推論した主張は、オペレーターが設定したものよりも弱く、そのように検索されるべきです。そうでなければ、モデル自身の推測が、後から設定と区別がつかない状態で戻ってくることになります。
- 要約処理を通じてプロバナンスを維持するにはどうすればよいですか？
- 要約がそのソースのオリジンの和集合を保持するか、あるいは置き換えたレコードを指し示す新しいエージェント推論レコードとして書き込まれるかのいずれかです。避けるべきなのは、要約がいつの間にか情報源のない事実になってしまうことであり、それこそが汚染が永続化するステップだからです。