Anthropicのエージェントメモリアーキテクチャ：4層、dreaming、413ファイルの失敗（2026年11月）

Anthropicは何を公開したのか

2026年11月6日、AnthropicはLance Martinによるリサーチ記事The components of agent memoryを公開しました。テーマは、Claudeがセッションをまたいで知識をどう持ち越すかです。製品発表ではありません。Claude Codeの内部ですでに動いているメモリスタックの説明で、設計と同じくらいの分量を「何がうまくいかないか」に割いています。

記事はまず境界線を引きます。メモリと呼ばれるがメモリではないものが3つあります。モデルの学習済み重み、1つの会話の中で起きるインコンテキスト学習、そして長いセッションをコンテキストウィンドウに収める要約処理、compaction（コンパクション）です。Anthropicの定義によるエージェントメモリとは、エージェントが実際の作業中に自分で書き留めると決め、後から別のセッションで自力で読み返す知識を指します。

メモを書くとは、次に何が起きるか分からないうちに「もう一度役に立つはずだ」と賭けることです。

なぜ何でも書き留めるとClaudeのPokemon攻略は悪化したのか

AnthropicはPokemon Redの2つのプレイを約10,000ステップまで比較しています。

Sonnet 3.7はほぼすべてを記録しました。野生のバトルごとに1ファイル、拾ったアイテムごとに1ファイル、ノンプレイヤーキャラクターとの会話ごとに1ファイルという具合です。ステップ10,000の時点で、413個のメモリファイルが225個のフォルダに分散し、得たジムバッジは1個でした。

Fable 5は逆をやりました。2つのフォルダに9ファイル、加えてglobal.mdというトップレベルのファイルが1つだけです。バッジは4個。後のOpus 5.5は、目標と次の手順を追う小さなフォルダを保ち、メモをその場で書き換え、ゲームをクリアしました。

413ファイルのプレイは、容量が足りなくなったわけではありません。ステップ10,000あたりで4つ目のトップレベルメモリフォルダを開き、続く17ステップの間に6ファイルを作成し、別の9ファイルを削除し、ゲーム内では何も行動していません。エージェントは、すでに過ぎ去った世界についてのメモを整理し直していました。

動いている環境についてのメモは、書いているそばから陳腐化します。古くなったメモはどれも、いま画面に映っているものと注意を奪い合います。メモリは無料の資産ではありません。

1つの誤ったメモが、なぜ3回連続でプレイを壊したのか

無駄はまだ軽い失敗です。深刻なのは、単純に間違ったメモです。書いたセッションより長く生き残るからです。

Pokemon Redでは、Mt. Moonに一方通行の段差があります。Claudeはポケモンセンターが洞窟の東にあると記録しました。外に出た後、そのメモを確定事項として扱い、洞窟は終わったと判断して完了にし、入口に落とされる段差から飛び降りました。

ナビゲーションツールは高低差を認識できなかったため、Claudeは西へ大きく行き過ぎたと結論づけ、その結論を以前より自信を持って書き留めました。新しいセッションは両方の誤りを引き継ぎました。Anthropicによると、3つの別々のプレイが同じ段差を越えてしまいました。1つは、ループを続けるより止まるとClaudeが書き残し、Pewter Cityへ歩いて行き、Cerulean Cityには到達しないまま終わりました。メモリが修正されていたプレイは、まっすぐ洞窟へ戻って目的地に着きました。

たった1行の誤りで、以降のすべてのセッションが確認もせずにそこから出発します。

残す価値のある事実とノイズを分けるものは何か

Anthropicは世界を「変わるもの」と「保たれるもの」に分けます。「これは重要か」と問うより、役に立つ分け方です。

一時的な事実は絶えず変わります。NPCがどのタイルに立っているか、ポーションが何個残っているか、少し前の画面がどう見えたか。読み直すのは安く、保存するのも安く、保存したコピーは書いた瞬間に誤りになります。メモリストアから古い座標を引っ張り出すのは、画面をもう一度見るより悪い選択です。

潜在的なルールは1コマでは見えてきません。この洞窟を出たら右側の段差から飛び降りてはいけない。並行するAPI呼び出しの前にはロックを取る。この種のエラーは、環境変数が欠けていることを意味します。こうしたものは、失敗した試行も含め、セッションをまたいだ繰り返しの試行から得られます。

長期メモリに入れるべきなのは2つ目のカテゴリだけです。1つ目のカテゴリは、もう一度観測する価値があります。

モデルが記録してよい内容を制限するルールを書くべきか

多くのチームが試しています。「座標は記録しない」「失敗だけを記録する」といったプロンプトは品質管理のように見えますが、Anthropicが長いタスク向けに作ったメモリのベンチマーク、CL-Benchによれば、強いモデルでは逆効果になります。

失敗だけを記録するよう指示すると、Opus 5もOpus 4.7も、メモリが与えていた性能向上の多くを失いました。モデルはルールに従い、本来必要だったものを書き留めるのをやめました。

逆方向のほうが興味深い結果でした。Sonnet 4.6に「まずメモリを読み、見つけた仮説を検証する」よう伝えると、ベンチマークスコアはほぼ2倍になりました。Sonnet 5は、指示がまったくなくても10回のうち9回は回答前にメモリを読みました。メモリフォルダがあると伝えるだけで、Opus 4.7とOpus 5のスコアは上がりました。

何が重要なのかの見極めは、許可する話題を手で列挙したリストより、強いモデル自身のほうがうまくやります。アーキテクチャがモデルに提供すべきは、安全に書ける場所、後から修正する手段、そしてメモリが何のためのものかという明確な説明です。

4つの層とは何か

スタックは、最下層の完全なログから、最上層の薄いインデックスまで積み重なっています。プロンプトを後付けした1つのベクトルデータベースではありません。

トランスクリプト。 完全な記録です。会話のターン、引数付きのツール呼び出し、その結果、環境からのフィードバックが入ります。ロスレスで、キーワードでも全文でも検索でき、要約で消されることはありません。この上に積んだものがすべて間違っていたと分かったとき、戻るべきファイルはこれです。

メモリノート。 実行中に、何か重要に見えるものがあるとエージェントが書くものです。1つのタスクで得た教訓を短いMarkdownにしたもので、多くの場合タグと日付が付きます。

メモリ表現。 wikiやそれに類する構造です。ノートを溜め込む代わりに、オフラインのパスが重複を統合し、繰り返し現れるものを抽象化し、ページ同士を相互リンクして、エージェントがたどれる地図にします。

注入コンテキスト。 セッション開始時に読み込まれる数行です。エージェントがどの領域の知識を持ち、詳細がどこにあるかを示すだけで、詳細そのものはほとんど含みません。

Anthropicは3番目の層の価値を、Stainlessという実在のコードベースで測りました。約350,000ファイル、およそ4.2億トークン。評価に使ったのは25問です。dreamingは128セッションかけてwikiを構築しました。これを2セッションから128セッションに増やすと、評価基準を満たした割合は13%から48%へ上がりました。検索だけなら53%です。検索とwikiの併用は、wikiが育つにつれて54%から61%へ上がり、質問あたり約20,000トークンを節約しました。

wikiは単独では勝ちませんでした。効いたのは検索と組み合わせたときです。各回答が1つの文書に収まるタスクでは、wikiに明確な効果はなかったと記事は書いています。別のタスクでは、wikiは圧縮するはずの元文書より大きくなりました。

dreamingとは何か

dreamingとは、誰もエージェントに問い合わせていない間に使う計算資源のことです。名前は睡眠研究に由来します。海馬は徐波睡眠とレム睡眠の間にその日の経験を再生し、ノイズを削り、生き残ったものを長期記憶へ書き込みます。

エージェントの場合、オフラインのパスがログとノートをまとめて読み、食い違いを探します。トランスクリプトに照らしてノートを書き換え、繰り返し重要であり続けるものを昇格させ、同じことを説明する2つのページを統合し、誰も作っていないページを指すリンクを見つけることもできます。

Mt. Moonの修正は分かりやすい例です。dreamingはノートを移動ログと照合し、記録された経路が東へ進んで落下していることを見て取り、ノートを「洞窟に戻って北へ進む」という指示に置き換えました。修正されたプレイはCerulean Cityに到達し、修正されなかったプレイは到達しませんでした。

構造の修復もします。Anthropicの契約分析テストでは、最初のパスが、重要だった57個の事実のうち41個（72%）をカバーする要約を作りました。複数のエージェントが共有テーブルを上書きし、契約条件を曖昧に言い換えていました。直し方は手順の変更でした。契約ごとに1ページ、契約ごとに1エージェント、条件は一字一句引用する。その要約は基準の100%を満たしました。後のdreamingのパスでは、存在しないページを指す9本のリンクを見つけて向き先を変え、インデックスを含む3つの新しいページを追加しました。

dreamingの出力は、いま実行中のセッションでは利用できず、計算資源も無料ではありません。

Claude Codeは注入する層をどう小さく保つのか

Claude Codeは、セッション開始時にMEMORY.mdの先頭200行、または25 KBだけを読み込みます。読み込まれるのはそこまでで、メモリディレクトリの残りはディスクに置いたままです。

先頭のこの部分が、注入されるインデックスです。どの領域の知識を持ち、ファイルがどこにあるかをモデルに伝えます。特定のルールが必要になったとき、エージェントは下の層を検索するか、その時点で読みます。

Anthropicは2つの理由を挙げています。注入されるメモリは毎ターン、コンテキストとして課金されます。指示ファイルを長くするほど、モデルがそれに従う度合いも測定できるほど下がります。たまたま答えを含む長いメモリブロックは、確実にそこを指す短いインデックスに劣ることがあります。

実運用ではどこが難しくなるのか

トレードオフが3つあり、どれも計算資源の話です。

いつ書くか。注目すべき出来事をその場で記録すれば詳細は残りますが、書く行為がタスクとコンテキストを奪い合います。オフラインで書けばセッションはきれいに保てますが、後になるまで何も届きません。

どう新鮮さを保つか。メモは正しかった条件より長く生き残るため、メモリはずれていきます。dreamingで修正できますが、常に確認すると節約分と同じだけのコストがかかります。必要なのは、実行周期と対象リストです。変わりやすいメモリと、一度読まれたうえで矛盾が見つかったメモリです。

メモリ表現をどこまで作るか。トランスクリプト検索は堅実な土台で、保守も不要です。wikiは検索と組み合わせれば役立ちますが、正確さを保つには計算資源が要り、保守されないwikiは自信満々の誤りがもう1層増えるだけです。

ここから何を持ち帰れるのか

Anthropicの数値はAnthropicのタスクから出たものです。それでもいくつかの設計判断は他でも通用すると考えられるので、測定結果ではなく設計上の助言として並べます。

• 生のログは一字一句そのまま保持します。その上に載る要約はすべてキャッシュであり、元を置き換えず、元を指すだけにします。
• ログ、ノート、合成したページは別々のものとして保存します。寿命が異なり、壊れ方も異なります。
• 小さなインデックスを注入し、詳細はモデル自身に取りに行かせます。メモリディレクトリ全体をプロンプトに詰め込んで期待するのはやめます。
• 修正のパスをスケジュールし、実際に計算資源を割り当てます。ノートを見直さないエージェントは、最初の誤りを永久に抱え続けます。
• コストを追跡するのと同じように鮮度の劣化を追跡します。最後に検証した日付、読まれた回数、矛盾が見つかった回数です。ノートの数は健全性の指標ではありません。

セッションが5ターンで終わり、毎回ゼロから始まるなら、この話はどれも元が取れません。この設計は、足元で変化し続ける世界に対して数千ステップ動き続けるタスクを前提にしています。