AIエージェント
エージェントの記憶が道具の呼び出しを歪める——1本の報告
エージェントに長期記憶を持たせる機能は、もう研究の話ではない——Claude Code も Letta も、セッションを跨いで残る記憶を製品の標準機能として備えている12。長く働くほど、過去のやり取りを覚えている方が賢く振る舞える——その方向自体は正しい。だが記憶の逆の面を突く報告も、別々の角度から出始めている。その一つが、エージェントに持たせた性格的な偏りの記憶が、道具の呼び出し方を静かに歪めるという指摘だ——これは1本の査読前論文(Dabas ら)の報告で、独立再現はまだない。同論文によれば、せっかちさやコスト意識といった偏りを記憶に入れておくだけで、それが当てはまらない場面でも道具に渡すパラメータが記憶なしのときの呼び出しからずれる。そのずれを LLM の審査役に採点させた点数は、偏りのない記憶を持たせた場合より最大+3.6ポイント(1〜5段階)高かった3。しかもこのずれは、プロンプトで「関係ない記憶は無視して」と指示しても部分的にしか消えなかった(GPT-5.4 で評点は0.52下がるだけで、なお高い水準に留まる)。記憶を選り分けるフィルタのほうは、このベンチマーク上では偏った記憶を全て取り除けている——ただし著者ら自身が「人物像と業務がきれいに切り離されたベンチだから当然だ」と割り引き、両者が重なる現実寄りの事例では本当に有用な記憶の61.0%しか残せず、無関係な記憶を10.3%通したと報告する3。同論文が示す限りでは、難所は記憶を貯めることではなく、管理することにある。
何が起きるのか
Dabas らが「記憶による道具ドリフト(tool-drift)」と名づけたこの現象は、彼らの説明ではこういう筋道で起きる3。エージェントが覚えている性格の偏り——せっかちさ、コスト意識、リスク許容度といった、その人の傾向として記憶に残るもの——が、明示の指示と同じ向きにモデル内部の活性を押す暗黙のステアリングとして働く。すると、いま解くべき仕事の文脈よりも、表面的にキーワードが重なる記憶のほうへ注意が引かれ、道具に渡すパラメータが本来と違う値に寄っていく、と論文は論じる。ただしこの内部機構の実測は、活性と注意を覗ける Llama-3.3-70B-Instruct 1本で行われたもので、次に触れる7モデルには含まれない。
「+3.6」が何の数字かは、押さえておく価値がある。彼らが作った MEMDRIFT は、五つの偏りの軸と七つの職業領域にまたがる105個のシナリオを、ドリフトが最大になるよう4回まで作り直して最良のものを採り、最後に人手で検証して作ったベンチマークだ。同じ仕事を、記憶なし・無バイアスの記憶あり・偏った記憶あり、の三条件で解かせる。記憶を持たせないときの呼び出しを基準に、引数がどれだけ離れたかを LLM の審査役が1〜5段階で採点し(論文の言う deflection score)、無バイアス側の点数を差し引いた幅の最大値が+3.6だ3。モデル別に総合値を見ると+1.8(GPT-5.2)から+3.3(Claude Sonnet 4.5)に散らばっており(いずれも記憶を直接与えた設定)、+3.6は7モデル×5次元の35セルのうち最も大きい1つ——Gemini 3.1 Pro の「コスト意識(Resource Frugality)」の軸——である。つまり+3.6は、損害額でも失敗率でもなく、無バイアス条件に対して審査役モデルの評点が上がった幅である(1〜5段階なので上げ幅の上限は4であり、+3.6はその大半にあたる)。穴を示すために作り手自身が設計した指標であり、審査役に LLM を使う以上その癖も乗る——著者らは別の審査役(GPT-5.4)で採り直して高い一致を得たと述べており、そこは一応潰してある——ただし採り直したのは7モデルのうち Kimi K2.5 の出力だけで、五つの軸のうち「せっかちさ」だけは一致が κ=0.58 と低い。「せっかちさ」は、本稿がくり返し例に挙げている軸である。それでも、穴を示すために作り手自身が設計した指標である以上、数字は「この設計の中での大きさ」として読むのが妥当だろう。
規模も具体的だ。研究チームは288個の検証済み MCP サーバにまたがる6,062個の道具を走査し、そのうち608個にずれやすいパラメータがあると印をつけ、絞り込んだ一部で実際にドリフトを確認したと述べる3。現象は拡張推論を持つものを含む7つの最前線モデルで観測された。記憶の出し入れを三つの実運用メモリ基盤に任せた設定では、ずれは残るどころか直接与えたときと同等かそれ以上に強く出ている(ただしこの設定で試したのは7つのうち GPT-5.4 と Gemini 3.1 Pro の2モデルだ)。論文はその理由を、基盤が保存時に個人的な文脈を剥ぎ落として「全体への指示」として符号化し、表層的な意味の重なりで引き出すため、モデルが「この記憶はいま関係ない」と気づくための手がかりごと失われるからだと説明する。攻撃というより、善意で持たせた記憶が副作用を持ちうるという話である。
同じ方向の報告はあるが、すべてが独立ではない
記憶の負の面を突く報告は、これ一本ではない。ただし「別の人が独立に確かめた」の度合いは報告ごとに違うので、そこは分けて読みたい。
記憶を持たせた期間が延びるほど安全上の違反率が上がると測った報告4は、ドリフト論文と上席著者(Ruoxi Jia・Ming Jin)を共有している——別グループによる独立の確認ではなく、重なる著者陣が隣の角度から同じ懸念を測った、と読むのが正確だ。一方、次の二本は著者の重ならない別グループのものだ。ひとつは、有用な文脈に見せかけた文書やWebページを読ませて捏造された記憶をその場で書き込ませ、後の複数の会話で初めて発動させる「スリーパー記憶汚染(sleeper memory poisoning)」を実証した Pulipaka・Abdelnabi・Fritz らの報告5。遅れるのは書き込みではなく発動のほうで、話題が汚染された記憶から遠い会話では発動しにくい——ただし消えはしない。原典は、行動を伴う設定について「攻撃者意図どおりの行動率は全モデルで非ゼロのまま」と明記している。ただし同じ論文は、注入された文書がモデル内部の活性からはかなり分離できる(AUROC 0.93〜0.99)とも報告しており、検知の手がかりが無いわけではない。ただしこの値は open-weight 6モデルについて層を選んだ最良の単層プローブのもので、内部の活性を読めることが前提だ。原典自身、この結果が内部表現に手の届かない商用モデルへ及ぶとは限らないと断っている——商用アシスタントの内部を直接覗く使い方はできない。ただし原典が実際に薦めるのはその使い方ではなく、open-weightのモデルを本番LLMの手前に置いて、届く前の文書を検査する構成のほうだ5。もうひとつは、記憶の枯渇や文脈の氾濫といった内部要因でエージェントが静かに劣化していく過程を整理し、防御枠組みを提案した Atta らの報告6だ。産業側でも、古い・汚れたデータが記憶を通じて推論を壊す「文脈汚染(context poisoning)」が実務課題として語られ始めた7——ただしこれは解決策として自社製品を薦めるベンダーの記事なので、証拠というより現場の関心の在りかを示すものとして扱いたい。なお汚染の報告は、自作の評価枠組みの中だけで確かめられたものではない。原典は出荷済みの製品サイトに対しても攻撃を当て直している。ChatGPT・Gemini・Claude・Kimi の記憶機能が対象で、ChatGPT 5.4 Thinking と Claude Sonnet 4.6 では25件中24件、狙った記憶の書き込みに成功した5。いずれも査読前ないし単一グループの報告で、互いの独立再現が取れているわけではない。
それでも、これらの報告に共通する筋は二つに読める。第一に、記憶を持たせると、持たせる前にはなかった失敗の面が増えうるという指摘。第二に、プロンプト層だけの防御では止まりにくい——「無視して」と書くのも、モデルを賢くするのも、それ単体では足りないと各報告は述べる37。
実在のハーネスは、記憶をどう「管理」しているか
「貯めるより管理する」は、実運用のエージェント・ハーネスがすでに設計判断として体現している。Claude Code の自動メモリは、会話の何もかもを覚えるのではなく、「将来の会話で役立つか」を基準にモデル自身が残す価値のあるものだけを書き留める。索引となる MEMORY.md だけを毎セッション読み込み、詳細は必要時に取り出す。しかも全文はプレーンテキストで、利用者が /memory からいつでも閲覧・編集・削除でき、想起や書き込みの瞬間も「Recalled 2 memories」のように UI に表示される1。=何を覚えるかを絞り、覚えた中身と読み書きの瞬間を見えるようにし、疑わしい記憶を人が消せる。記憶の管理を、人が読める平文と手作業で握れるところまで下ろした設計だ。
Letta は別の方向に踏み込む。公式ドキュメントは中核の「記憶ブロック」を、エージェントの文脈ウィンドウの中にあらゆるやり取りをまたいで残り、検索を挟まず常に見えている構造化された区画だと説明し、エージェント自身が組み込みのメモリツールでそれを読み書きすると述べる2。同じ設計思想は MemGPT 論文にも見える——プロンプトの中に固定長で置かれ、モデル自身の関数呼び出しでしか書き換えられない読み書きブロックがあり、論文はこれを working context と呼ぶ8。両者を系譜として結ぶ記述はどちらの出典にも無いので、ここでは設計の相似を指摘するに留める。MemGPT 論文の看板である「仮想文脈管理」はもう一段広い枠組みの名前で、OSの階層メモリからの類推により、プロンプト内と外部の保管領域の間でデータを動かす仕組み全体を指す。記憶ブロックが構造として対応するのは、広い枠組みのほうではなく working context のほうだ——検索を挟まず常に見えていて、しかも書き換えられる区画である。記憶を「読み出すだけの山」ではなく、書き換えて整理し続ける対象として設計する発想である。どちらも、記憶を貯め込む機能ではなく、記憶を管理する仕組みを製品の中心に据えている。
(両者とも更新の速い製品ゆえ、ここでの記述は2026年7月時点の公開情報による。)
実務で何を見るか
この二つの設計が示すのは、記憶を足すかどうかより、足した記憶をどう見張るかのほうが実務の分かれ目だということだ。
- 記憶の効きめを「思い出せるか」だけで測らない。 記憶のベンチマークは往々にして「正しく思い出せた割合」を測る。だがドリフト論文が見ているのは別の面だ——記憶は正しく引き出されており、それが当てはまらない場面で引数を動かしてしまうかどうかを測っている3。想起の精度を上げても、この面が一緒に良くなるとは限らない。
- 「何の道具を呼んだか」より「どんな値で呼んだか」を見る。 論文がずれを見たのは、モデルが返す文章ではなく、道具に渡す設定値(引数)のほうだった3。たとえば検索の件数、送信先、金額といった値が、記憶の中身しだいで本来と違う方へ寄りうる。だから監視でも、呼んだ道具の種類だけでなく、渡した値が記憶の有無で変わっていないかまで見ておくと、早く気づける。
- 対策は、記憶がモデルに届く「手前」に置く。 「関係ない記憶は無視して」とプロンプトで頼むやり方は、部分的にしか効かない3。Redis の記事も、プロンプト層だけの防御はそれ単体では足りず、手当ては何を取り出し・何をキャッシュし・何を覚えるかという上流のデータ経路に寄せるべきだと述べる7。同記事が具体策として挙げるのは(いずれも自社製品の機能としてだが)、エージェントに触らせる範囲を先に定義してそれ以外を届かせないことと、記憶の書き込みをスコープ付きにして後から点検・無効化できるようにすることだ——つまり「一度入ったら最後」の記憶をやめる方向である。ただし上流に置けば済む話でもない。ドリフト論文が試した関連度フィルタは、人物像と業務が重なる事例では有用な記憶の61.0%しか残せなかった——絞りすぎれば、記憶を持たせた利点のほうが先に消える。
ただし、どれも新しく規模も小さい研究群で、防御策は発展途上だ。「記憶をやめろ」という話ではない。現時点の報告が示す範囲で言えるのは、記憶を持たせた瞬間に管理すべき対象が一つ増えるということのほうだ——貯め方より、何を入れ・何を消し・何を届かせないかの設計が問われる。
出典8件
-
Anthropic「How Claude remembers your project」(Claude Code 公式ドキュメント, 閲覧2026-07)。自動メモリはモデルが「将来の会話で役立つか」で残す価値を判断し、毎セッション必要ぶんだけ読む(索引 MEMORY.md は先頭200行/25KB のみ、詳細は随時)。全文はプレーンテキストで
/memoryから閲覧・編集・削除でき、想起・書き込みは UI に表示される。=覚える対象の絞り込み・中身と読み書きの可視化・人手での削除を備えた実運用のメモリ管理。https://code.claude.com/docs/en/memory ↩ ↩2 -
Letta 公式ドキュメント「Memory blocks (core memory)」(閲覧2026-07)。記憶ブロックを “structured sections of the agent’s context window that persist across all interactions. They are always visible - no retrieval needed” と定義し、“you define the blocks, and agents can read and update them using built-in memory tools” と述べる。製品は更新が速いため、記述は閲覧時点のもの。https://docs.letta.com/guides/core-concepts/memory/memory-blocks ↩ ↩2
-
Mahavir Dabas, Jihyun Jeong, Ming Jin, Ruoxi Jia, “Memory-Induced Tool-Drift in LLM Agents”(arXiv:2605.24941, 2026-05-24、査読前)。同論文の報告では、記憶に入れた性格的な偏り(コスト意識・せっかちさ・リスク許容度など)が、当てはまらない文脈でも道具呼び出しに影響する。指標は deflection score=無バイアス基準からの引数の逸脱を LLM 審査役が1〜5段階で採点したもので、要旨の言い方は
by up to +3.6 points on a 1-5 scale。Table 8 のモデル別総合値は+1.800(GPT-5.2)〜+3.285(Claude Sonnet 4.5)で、+3.6 は次元別の最大(Gemini 3.1 Pro × Resource Frugality の 3.619)。ベンチマーク MEMDRIFT は五つの偏りの軸×七つの職業領域で自動生成した105シナリオ。288の検証済み MCP サーバの6,062道具を走査して608道具に感受性パラメータありと印付け、絞った部分集合でドリフトを確認。拡張推論を含む7つの最前線モデルで観測。三つの実運用メモリ基盤の設定では GPT-5.4 と Gemini 3.1 Pro の2モデルのみを測り、biased deflection scores remain comparable to or exceed the direct injection settingと報告する。プロンプト指示は低減するが解消しない(GPT-5.4 で ∆s=−0.52、なお高水準)。記憶の関連度フィルタ(Self-ReCheck/Qwen3-8B)は MEMDRIFT 上では偏った記憶を全て除去できたが、著者らはこれをベンチが人物像と業務を厳格に分離しているためと自認し、両者が重なる multi-hop 事例では有用記憶の再現率61.0%・無関係記憶の誤通過10.3%で「粗い関連度フィルタは一般化しない」と述べる。記憶は「暗黙のステアリングベクトル」として働き、キーワードが表層的に重なる記憶へ注意を再配分すると説明する——ただしこの機構の実測はLlama-3.3-70B-Instruct1本(活性と注意が読める open-weight モデルを選んだと明記)で、評価の7モデルには含まれない。作り手自身が設計した指標かつ単一グループの結果で、独立再現は未確認。https://arxiv.org/abs/2605.24941 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 -
Ahmad Al-Tawaha, Shangding Gu, Peizhi Niu, Ruoxi Jia, Ming Jin, “Remembering More, Risking More: Longitudinal Safety Risks in Memory-Equipped LLM Agents”(arXiv:2605.17830, 2026-05-18、査読前)。記憶が蓄積するほど、記憶に起因する違反率が露出長とともに上昇する傾向を報告。上席著者 Ruoxi Jia・Ming Jin は 3 と共通=独立グループによる確認ではない。独立再現は未確認。https://arxiv.org/abs/2605.17830 ↩
-
Sidharth Pulipaka, Stanislau Hlebik, Leonidas Raghav, Sahar Abdelnabi, Vyas Raina, Ivaxi Sheth, Mario Fritz, “Hidden in Memory: Sleeper Memory Poisoning in LLM Agents”(arXiv:2605.15338, 2026-05-14、査読前)。文書やWebページ経由で捏造された記憶を書き込ませ、後の複数会話で発動させる遅延攻撃を実証したと報告(書き込み成功は最大99.8%。取り出しに成功したうえでの攻撃者意図どおりの率は、測る対象がどちらのサブセットかで値が変わる。行動を誘発する Agent Action サブセットでは、記憶が後の問いと意味的に近い場合 60〜89%、無関係な問いでは 6〜17% で、原典は逐語で
for agent-action, AUR remains nonzero for every modelと下限が0でないことを明記する。行動を伴わない応答の偏りを測る LLM Behavior サブセットでは、近い問いで 42〜85%、無関係な問いで 0〜6%。書き込みから行動までを通した成功率は、単発攻撃・外部メモリマネージャ経由・意味的に近い問い、という条件下で、行動を伴う場合3.0〜66.0%、応答の偏りに留まる場合41.0〜73.9%(無関係な問いではそれぞれ0.0〜5.0%・0.0〜1.0%))。防御側の評価(Appendix J.5–J.6)は、open-weightモデルを「本番LLMに届く前」に置く文書スキャナとして測っている(“document scanners that detect and localize prompt-injection payloads in untrusted documents before they reach a production LLM”)。全モデルで偽陽性率は0.000(“Every model scores 0% on benign documents; none hallucinates injections”)で、注入部分の位置も特定できるため文書を丸ごと捨てなくてよい。活性プローブについて原典が「商用モデルへ及ぶとは限らない」と断っているのは転移の結果についてで(“these transfer results are established on the current set of open-weight models”)、結論は層状防御の配備を薦める向きである。Appendix L.4 では、評価枠組みが作り出した見かけを排するため(“rule out artifacts introduced by our modeling of document upload during testing”)、成功した攻撃から選んだ25件を4製品(ChatGPT 5.4 Thinking/Gemini 3.1 Pro Preview/Claude 4.6 Sonnet/Kimi K2.6)で再現しており、ChatGPTとClaudeは24/25。対象は各社チャット製品の記憶機能であってClaude Codeの自動メモリではなく、25件は成功攻撃の部分集合なので攻撃全体の成功率ではない。3 とは著者が重ならない。独立再現は未確認。https://arxiv.org/abs/2605.15338 ↩ ↩2 ↩3 -
Hammad Atta ほか, “QSAF: A Novel Mitigation Framework for Cognitive Degradation in Agentic AI”(arXiv:2507.15330, 2025-07-21、査読前)。プロンプトインジェクションのような外部攻撃ではなく、記憶の枯渇・プランナの再帰・文脈の氾濫・出力抑制といった内部要因から生じる「認知劣化」を新しい脆弱性クラスとして提示し、記憶の完全性強制を含む実行時制御の枠組みを提案。3 とは著者が重ならない。独立再現は未確認。https://arxiv.org/abs/2507.15330 ↩
-
Jim Allen Wallace(Redis), “Context poisoning: how bad information breaks agent reasoning”(2026-05-17公開/2026-05-21更新、閲覧2026-07)。ベンダーの技術ブログ——結論として自社製品を薦める立場である点は割り引いて読む必要がある。「プロンプト層だけの防御はそれ単体では足りない」と述べ、手当てを retrieval/cache/memory の上流に寄せること、エージェントに露出する範囲を先に定義すること、記憶の書き込みをスコープ付きにして点検・無効化可能にすることを挙げる。https://redis.io/blog/context-poisoning-agent-reasoning/ ↩ ↩2 ↩3
-
Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, Joseph E. Gonzalez, “MemGPT: Towards LLMs as Operating Systems”(arXiv:2310.08560, 2023-10-12、査読前)。OS の階層メモリ(速い記憶と遅い記憶の間でデータを動かし、大きなメモリがあるように見せる)からの類推で「仮想文脈管理」を提案し、限られた文脈ウィンドウを跨ぐ記憶階層を管理する。用語の切り分け:同論文はプロンプトトークン側を main context、その外の保管側を external context と呼び、“virtual context management” はその二つの間でデータを動かす技術全体の名である。本文が構造の相似を指摘したのは main context の一部である working context で、§2.1 は “Working context is a fixed-size read/write block of unstructured text, writeable only via MemGPT function calls” と定義する(=取り出しを挟まず常にプロンプト内にあり、モデル自身が書き換える区画)。https://arxiv.org/abs/2310.08560 ↩
この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。