メモリ書込の積極度¶

このダイヤルは何か¶

メモリ書込の積極度は、エージェントが対話やタスク遂行の過程で得た情報を、長期メモリにどれだけ積極的に書き込むかを制御するパラメータです。積極度が高ければエージェントはあらゆる情報を即座に記憶しようとし、低ければ明確に確認された重要な事実だけを慎重に記録します。

AI エージェントシステムにおいて、メモリへの書込は「一度入ったら長く影響する」準不可逆的な操作です。データベースへの INSERT と同じ重みで考える必要があります。LLM が生成した推測、ユーザーの曖昧な発言、外部ドキュメントからの未検証情報をそのまま長期メモリに書き込むと、以後のすべてのセッションで「過去に記録された事実」として参照され、誤りが自己強化するループに陥ります。これがメモリ汚染です。

一方で、書込を抑制しすぎるとエージェントは「何も学ばない」存在になり、毎回同じ情報をユーザーに尋ね、過去の対話から得られたはずの知見を活かせません。このバランスを [input_trust] と [failure_cost] の関数として制御するのが本ダイヤルの役割です。

効かなすぎる害 ⇔ 効きすぎる害¶

書込が消極的すぎる場合（効かなすぎ）¶

書込閾値を極端に高く設定すると、以下の問題が生じます。

学習しないエージェント：ユーザーが繰り返し伝えた好み（「コード例は Python で書いてほしい」「技術的に詳しく説明してほしい」）を記憶せず、毎回デフォルトの振る舞いに戻ります。ユーザーは「学習能力がない」と感じます。
反復的な情報収集：過去のセッションで収集済みの情報を再度質問することになります。カスタマーサポートでは「また名前を聞かれた」「また状況を説明しなければならない」という不満に直結します。
パーソナライゼーションの欠如：ユーザーごとの文脈を蓄積できないため、すべてのユーザーに画一的な応答を返します。長期的な関係構築が求められるユースケースでは致命的です。
組織知識の損失：チーム内で共有すべき暗黙知（「この API はこのパラメータを渡すと壊れる」「このクライアントはこの形式を好む」）が蓄積されません。

書込が積極的すぎる場合（効きすぎ）¶

書込閾値を低くしすぎると、以下の害が発生します。

ハルシネーションの永続化：LLM が推測や仮定として述べた情報がそのまま「事実」として記録されます。「おそらく A さんは東京在住でしょう」という推測が長期メモリに「A さんは東京在住」として保存され、以後のセッションで確定事実として扱われます。
プロンプトインジェクションの持続化：悪意あるユーザーや外部ドキュメントに埋め込まれた攻撃的な指示がメモリに書き込まれると、攻撃者は将来のすべてのセッションに影響を及ぼせます。通常のプロンプトインジェクションは1セッション限りですが、メモリに永続化されると「持続型インジェクション」になります。
重複と矛盾の爆発：同じ情報が微妙に異なる表現で何度も書き込まれ、検索時に矛盾する記憶が返ります。「好きな言語は Python」と「Python が好き」が別エントリとして蓄積され、メモリの信号密度が低下します。
プライバシーリスク：ユーザーが意図せず漏らした個人情報（病歴、家族関係、金融情報）がメモリに残ります。ユーザーは「一時的な発言」のつもりでも、エージェントが永続化してしまいます。
メモリの肥大化：取るに足らない情報までメモリに入るため、ストレージコストが増加し、検索精度が低下します。

決め方¶

書込の積極度は主に [input_trust] と [failure_cost] によって決まります。

[input_trust]：入力の信頼度が低いほど、書込を慎重にします。エンドユーザーの自由入力が主なソースである場合、インジェクションや誤情報のリスクが高いため、書込ゲートの閾値を上げます。管理者が入力を管理している場合は、ある程度積極的に書き込めます。
[failure_cost]：誤った記憶が残った場合の影響が大きいほど、書込を抑制します。医療・法務・金融では、誤った事実の永続化が深刻な結果を招きます。社内チャットボットでは、多少の誤記憶は修正すれば済みます。
[accountability]：説明責任が高い場合、書き込んだ情報の出典と確信度を記録する必要があります。「なぜこの情報をメモリに保存したか」を後から説明できるようにします。

書込の判定基準は以下の階層で考えます。

自動書込可：ユーザーが直接的かつ明示的に述べた事実（「私の名前は山田です」「Python を使っています」）
確認後に書込：ユーザーの発言から推測される情報（「コード例を Python で求めることが多いので、Python が好みのようですね」→ ユーザーに確認）
書込禁止：LLM が生成した推測、外部ソースからの未検証情報、一時的な文脈（「今日は寒いですね」）

目安値（出発点）¶

情報の種類	書込基準	`[input_trust]` への依存
ユーザーが直接述べた明示的事実	自動永続化	信頼度に関わらず書き込む（ただし PII フィルタは通す）
反復確認された情報（2 回以上の一致）	自動永続化	低信頼環境では 3 回以上に引き上げる
ユーザーの暗黙的な好み（行動パターンから推測）	隔離→一定期間後に昇格	低信頼環境では人間承認を挟む
LLM が推測した情報	原則書込禁止、作業記憶に留める	—
外部ドキュメントからの抽出情報	ソース検証後に書込	低信頼環境では全件検証
PII・機微情報	マスク後に書込、または書込禁止	規制要件に従う

書込ゲートの具体的な実装については D3 Memory Write Gate を参照してください。

実践的なアドバイス¶

「書くか書かないか」だけでなく「どの確度で書くか」を記録してください。メモリエントリに確信度（confidence）タグを付与し、検索時に確信度の低いエントリはランキングを下げるか、利用時に注意書きを添えます。これにより、書込を完全に禁止しなくても汚染の影響を限定できます。
重複検出を書込パイプラインに必ず組み込んでください。新しいメモリ候補が既存のエントリと意味的に重複していないか（コサイン類似度 0.90〜0.95）をチェックし、重複している場合は上書きまたは棄却します。同一エンティティの同一属性は最新値で上書きするのが原則です。
「忘れる」操作もメモリの一部として設計してください。ユーザーが「さっき言ったことは忘れて」と依頼したときに対応できるように、メモリの明示的削除機能を用意します。また、定期的な「メモリの棚卸し」（ユーザーに保存情報を提示して確認を得る）を設計に組み込むと、長期的な品質が保たれます。
書込ログを監査可能にしてください。いつ・何が・どのソースから書き込まれたかを追跡できるようにします。メモリ汚染が発覚した場合に、原因となった書込を特定して修正するために不可欠です。
環境ごとに書込ポリシーを変えてください。開発・ステージング環境では積極的に書き込んで学習効果を確認し、本番環境では慎重にするという段階的な運用が有効です。