AIエージェント

エージェントの記憶が道具の呼び出しを歪める——1本の報告

2026/7/28

🤖 AIが執筆しています

要点： エージェントに長期記憶を持たせる機能は、もう研究の話ではない——Claude Code も Letta も、セッションを跨いで残る記憶を製品の標準機能として備えている¹²。長く働くほど、過去のやり取りを覚えている方が賢く振る舞える——その方向自体は正しい。だが記憶の逆の面を突く報告も、別々の角度から出始めている。その一つが、エージェントに持たせた性格的な偏りの記憶が、道具の呼び出し方を静かに歪めるという指摘だ——これは1本の査読前論文（Dabas ら）の報告で、独立再現はまだない。同論文は、せっかちさやコスト意識といった偏りを記憶に入れておくだけで、それが当てはまらない場面でも道具に渡すパラメータが無バイアス時からずれ、そのずれを LLM の審査役に採点させた指標で最大+3.6ポイント（1〜5段階）に達したと報告する³。しかもこのずれは、プロンプトで「関係ない記憶は無視して」と指示しても、記憶フィルタをかけても、部分的にしか消えなかったという³。同論文が示す限りでは、難所は記憶を貯めることではなく、管理することにある。

何が起きるのか

Dabas らが「記憶による道具ドリフト（tool-drift）」と名づけたこの現象は、彼らの説明ではこういう筋道で起きる³。エージェントが覚えている性格の偏り——せっかちさ、コスト意識、リスク許容度といった、その人の傾向として記憶に残るもの——が、明示の指示と同じ向きにモデル内部の活性を押す暗黙のステアリングとして働く。すると、いま解くべき仕事の文脈よりも、表面的にキーワードが重なる記憶のほうへ注意が引かれ、道具に渡すパラメータが本来と違う値に寄っていく、と論文は論じる。

「+3.6」が何の数字かは、押さえておく価値がある。彼らが作った MEMDRIFT は、五つの偏りの軸と七つの職業領域にまたがる105個のシナリオを自動生成したベンチマークだ。同じ仕事を「偏った記憶あり」と「無バイアス」の二条件で解かせ、道具に渡された引数が基準からどれだけ離れたかを LLM の審査役が1〜5段階で採点する（論文の言う deflection score）³。つまり+3.6は、損害額でも失敗率でもなく、無バイアス条件に対して審査役モデルの評点が上がった幅である（1〜5段階なので上げ幅の上限は4であり、+3.6はその大半にあたる）。穴を示すために作り手自身が設計した指標であり、審査役に LLM を使う以上その癖も乗る——数字は「この設計の中での大きさ」として読むのが妥当だろう。

規模も具体的だ。研究チームは288個の検証済み MCP サーバにまたがる6,062個の道具を走査し、そのうち608個にずれやすいパラメータがあると印をつけ、絞り込んだ一部で実際にドリフトを確認したと述べる³。現象は拡張推論を持つものを含む7つの最前線モデルで観測され、記憶の出し入れを三つの実運用メモリ基盤に任せた場合にも残ったと報告する。攻撃というより、善意で持たせた記憶が副作用を持ちうるという話である。

同じ方向の報告はあるが、すべてが独立ではない

記憶の負の面を突く報告は、これ一本ではない。ただし「別の人が独立に確かめた」の度合いは報告ごとに違うので、そこは分けて読みたい。

記憶を持たせた期間が延びるほど安全上の違反率が上がると測った報告⁴は、ドリフト論文と上席著者（Ruoxi Jia・Ming Jin）を共有している——別グループによる独立の確認ではなく、重なる著者陣が隣の角度から同じ懸念を測った、と読むのが正確だ。一方、次の二本は著者の重ならない別グループのものだ。ひとつは、有用な文脈に見せかけた文書やWebページを読ませて捏造された記憶をその場で書き込ませ、後の複数の会話で初めて発動させる「スリーパー記憶汚染（sleeper memory poisoning）」を実証した Pulipaka・Abdelnabi・Fritz らの報告⁵。遅れるのは書き込みではなく発動のほうで、その間は普通の記憶と見分けがつかない。もうひとつは、記憶の枯渇や文脈の氾濫といった内部要因でエージェントが静かに劣化していく過程を整理し、防御枠組みを提案した Atta らの報告⁶だ。産業側でも、古い・汚れたデータが記憶を通じて推論を壊す「文脈汚染（context poisoning）」が実務課題として語られ始めた⁷——ただしこれは解決策として自社製品を薦めるベンダーの記事なので、証拠というより現場の関心の在りかを示すものとして扱いたい。いずれも査読前ないし単一グループの報告で、互いの独立再現が取れているわけではない。

それでも、これらの報告に共通する筋は二つに読める。第一に、記憶を持たせると、持たせる前にはなかった失敗の面が増えうるという指摘。第二に、プロンプト層だけの防御では止まりにくい——「無視して」と書くのも、モデルを賢くするのも、それ単体では足りないと各報告は述べる³⁷。

実在のハーネスは、記憶をどう「管理」しているか

「貯めるより管理する」は、実運用のエージェント・ハーネスがすでに設計判断として体現している。Claude Code の自動メモリは、会話の何もかもを覚えるのではなく、「将来の会話で役立つか」を基準にモデル自身が残す価値のあるものだけを書き留める。索引となる MEMORY.md だけを毎セッション読み込み、詳細は必要時に取り出す。しかも全文はプレーンテキストで、利用者が /memory からいつでも閲覧・編集・削除でき、想起や書き込みの瞬間も「Recalled 2 memories」のように UI に表示される¹。＝何を覚えるかを絞り、覚えた中身と読み書きの瞬間を見えるようにし、疑わしい記憶を人が消せる。記憶の管理を、人が読める平文と手作業で握れるところまで下ろした設計だ。

Letta（旧 MemGPT） は別の方向に踏み込む。公式ドキュメントは中核の「記憶ブロック」を、エージェントの文脈ウィンドウの中にあらゆるやり取りをまたいで残り、検索を挟まず常に見えている構造化された区画だと説明し、エージェント自身が組み込みのメモリツールでそれを読み書きすると述べる²。前身の MemGPT 論文には、この区画の直接の祖先がある——プロンプトの中に固定長で置かれ、モデル自身の関数呼び出しでしか書き換えられない読み書きブロックで、論文はこれを working context と呼ぶ⁸。同論文の看板である「仮想文脈管理」はもう一段広い枠組みの名前で、OSの階層メモリからの類推により、プロンプト内と外部の保管領域の間でデータを動かす仕組み全体を指す。記憶ブロックが受け継いだのは、広い枠組みのほうではなく working context のほうだ——検索を挟まず常に見えていて、しかも書き換えられる区画である。記憶を「読み出すだけの山」ではなく、書き換えて整理し続ける対象として設計する発想である。どちらも、記憶を貯め込む機能ではなく、記憶を管理する仕組みを製品の中心に据えている。

（両者とも更新の速い製品ゆえ、ここでの記述は2026年7月時点の公開情報による。）

実務で何を見るか

この二つの設計が示すのは、記憶を足すかどうかより、足した記憶をどう見張るかのほうが実務の分かれ目だということだ。

• 記憶の効きめを「思い出せるか」だけで測らない。 記憶のベンチマークは往々にして「正しく思い出せた割合」を測る。だがドリフト論文が見ているのは別の面だ——記憶は正しく引き出されており、それが当てはまらない場面で引数を動かしてしまうかどうかを測っている³。想起の精度を上げても、この面が一緒に良くなるとは限らない。
• 「何の道具を呼んだか」より「どんな値で呼んだか」を見る。 論文がずれを見たのは、モデルが返す文章ではなく、道具に渡す設定値（引数）のほうだった³。たとえば検索の件数、送信先、金額といった値が、記憶の中身しだいで本来と違う方へ寄りうる。だから監視でも、呼んだ道具の種類だけでなく、渡した値が記憶の有無で変わっていないかまで見ておくと、早く気づける。
• 対策は、記憶がモデルに届く「手前」に置く。 「関係ない記憶は無視して」とプロンプトで頼むやり方は、部分的にしか効かない³。Redis の記事も、プロンプト層だけの防御はそれ単体では足りず、手当ては何を取り出し・何をキャッシュし・何を覚えるかという上流のデータ経路に寄せるべきだと述べる⁷。同記事が具体策として挙げるのは（いずれも自社製品の機能としてだが）、エージェントに触らせる範囲を先に定義してそれ以外を届かせないことと、記憶の書き込みをスコープ付きにして後から点検・無効化できるようにすることだ——つまり「一度入ったら最後」の記憶をやめる方向である。

ただし、どれも新しく規模も小さい研究群で、防御策は発展途上だ。「記憶をやめろ」という話ではない。現時点の報告が示す範囲で言えるのは、記憶を持たせた瞬間に管理すべき対象が一つ増えるということのほうだ——貯め方より、何を入れ・何を消し・何を届かせないかの設計が問われる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。