AIエージェントにどれだけのメモリを与えるべきか？ 8つのモデルを対象とした研究が明らかにしたこと（2026年）

ここでの「メモリ」とは、会話履歴ではなく、抽出されたガイドラインを指す

この言葉はいくつかの異なる概念をカバーしているため、まずここを整理しておく必要があります。著者らは明確に述べています。「ここでの『メモリ』とは、過去の会話履歴を再生することではありません。エージェント自身の過去の軌跡（トラジェクタリ）から抽出された、効果的だった戦略、避けるべきミス、エッジケースなどのガイドラインセットを意味します。」

そのループは次の通りです。エージェントがタスクを試行して軌跡を生成し、システムが「成功した実行と失敗した実行の両方から」行動ガイドラインを抽出します。それらを再利用可能なセットに統合し、推論時にエージェントはフルセットまたはそこから選択された一部を受け取ります。極めて重要なのは、「モデルの重みは一切更新されない」ということです。変化するのはモデル自体ではなく、「エージェントが利用できるガイダンス」です。

したがって、これは会話履歴に関する研究でも、長いコンテキストウィンドウに関する研究でもありません。この違いは、なぜ長いコンテキストウィンドウがメモリではないのかという議論とは区別して捉える必要があります。

ベンチマークと2つの指標

評価はAppWorldで行われました。「9つのシミュレートされたアプリ（カレンダー、メッセージング、決済など）にわたる585のマルチステップタスク（168のtest_normal + 417のtest_challenge）」です。

2つのスコアがあり、その間のギャップが興味深い部分であることがわかりました。

TGC — Task Goal Completion（タスク目標達成率）。「エージェントが個々のタスクを完全かつ正確に完了した割合。」 主要な「成功したか否か」を示す数値です。

SGC — Scenario Goal Completion（シナリオ目標達成率）。「より厳格な、全か無かの指標。」 各シナリオは同じタスクのいくつかのバリアント（変種）を束ねており、「SGCは、エージェントがすべてのバリアントで成功した場合にのみ、そのシナリオを合格とカウントします。これは信頼性を測定します。」

3つの構成

どちらのメモリ構成も、同じガイドラインセットから取得されます。これは「AppWorldのトレーニングスプリットのみから一度だけマイニングされたもの」であり、著者らは「テストスプリットのデータが構築に使用されることは一切ない」と指摘しています。異なるのは、その提供方法です。

Baseline（ベースライン） — 「メモリなし — 出荷時の状態のエージェント。」

Full guideline set（フルガイドラインセット） — 「マイニングされたすべてのガイドラインを、すべてのReActステップで注入する。」

Curated retrieval（厳選されたリトリーバル） — 「同じガイドラインのうち、信頼性の高い固定されたコア部分に加えて、タスクごとに関連するいくつかのガイドラインを検索して追加する（固定部分 ＋ 可変部分）。」

3つの点が際立っています。

強力なモデルはすべてを吸収した。 伸び代のあるモデルは、フルガイドラインセット（「稀なエッジケースの教訓を含む」）で最も高いパフォーマンスを示しました。これは「それらすべてを吸収して適用する能力があるため」です。

比較的弱いモデルは量によって悪影響を受けた。 「より小規模、または比較的弱いモデルは、膨大なガイドラインセットに埋もれてしまいます。」 gpt-oss-120bの場合、フルセットは厳選されたリトリーバルと比較して「向上幅が小さかっただけでなく、トークンコストが約50%多くかかりました」

厳格な指標は、主要な指標よりも大きく変動した。 DeepSeekはTGCで+9.5向上したのに対し、SGCでは+16.1向上しました。これは「優れたガイドラインは、平均的なケースだけでなく、シナリオのすべてのバリアントをエージェントがクリアするのに特に役立つため」です。天井に近いモデルであっても信頼性は向上し続け、GPT-5.5とOpusはSGCをそれぞれ+7.2ポイント、+7.1ポイント向上させました。著者らの次の言葉は記憶に留めるべきものです。「モデルに対処すべき失敗モードが残っている限り、メモリは効果を発揮し続ける。」

そして、1つのモデルは変化を示しませんでした。GLM-5は、これらのタスクにおいてメモリの有無にかかわらず全く同じスコアでした。これが何を意味するのかについて、著者らは非常に慎重に分析しており、それについては以下で説明します。

すべてのステップにガイドラインを注入することに対する反射的な反対意見はコストであり、それはもっともな指摘です。彼らの測定結果は以下の通りです。

したがって、比較的弱いモデルにおいては、選択（リトリーバル）が両方の軸で同時に勝利しました。「わずか+5%のトークンで+16.1ポイントのTGC向上」です。著者らが述べるように、「ここでのパフォーマンス向上は、推論コストの増加を必要としません」

これを予算化する上で、2つの裏付けとなる発見が重要です。第一に、オーバーヘッドは作業量の増加ではなく、入力トークンの増加（インフレーション）によるものです。「DeepSeekは、メモリがあってもなくてもほぼ同じ数のReActステップ（平均約18〜19ステップ）を実行するため、追加コストは軌跡の長期化ではなく、入力トークンの増加によるものです。」 第二に、これに対処するための標準的な手段があります。「本番環境における真の効率化のレバーはプロンプトキャッシュです。ガイドラインセットの静的な部分はステップ間で同一であるためキャッシュ可能であり、実質的なコストを大幅に削減できます。」 彼らは、これに対応した設計を推奨しています。「共有されるガイドラインセットのプレフィックスを安定させ、キャッシュ可能な状態を維持すること」です。

この最後のポイントは、設計に直接的な影響を与えます。呼び出しのたびに出力をシャッフルするメモリレイヤーは、キャッシュを無効にしてしまいます。安定したコアと小さな可変のテールを持つ構成の方が実行コストが安く、これは比較的弱いモデルにおいて精度面で勝利した構成でもあります。

著者らは、自らの研究の限界に対して非常に自律的であり、それらを正しく引用することが、この結果を誠実に読み解く方法です。

「飽和」は観察結果を示しているだけであり、原因ではありません。 GLM-5の平坦な結果について：「私たちはこれを飽和パターンと呼んでいます。このラベルは私たちが観察した現象を表しているだけであり、証明された原因ではありません。モデルがすでにこれらのタスクで天井に近かった可能性、ガイドラインが残された失敗に対処していなかった可能性、あるいはガイダンスを効果的に適用できなかった可能性があります。」 これはモデルの品質に関する結論ではありません。1つのベンチマーク、1つのガイドラインセット、1つの構成における結果に過ぎません。

能力の階層はパラメータ数だけでは決まらない。 「モデルがどのパターンに分類されるかを決めるのは、単にパラメータ数だけではありません。ベンチマークの伸び代、コンテキストウィンドウのサイズ、アーキテクチャ、ガイドラインの品質、そしてタスクの分布のすべてが、モデルがどこに着地するかに影響を与えているようであり、これらの要因を切り分けることは今後の課題です。」 745BのGLM-5と671BのDeepSeekが異なるパターンに着地したことに注目してください。

コンテキストウィンドウによる説明は仮説である。 彼らは、より大きなウィンドウの方がフルセットをより良く吸収できると考えていますが、直接このように述べています。「この要因を分離した対照実験はまだ実施していません。」

1つのベンチマークに過ぎない。 「これらの結果は、厳格なマルチステップベンチマークであるAppWorldで検証されたものですが、あくまで単一のベンチマークです。」 より広範なベンチマークや実際のデプロイでの検証は、現在進行中とされています。

リトリーバル自体も不完全であることを認めている。 「現在の私たちのリトリーバルはコサイン類似度でガイドラインをランク付けしていますが、これが特定のタスクにどのガイドラインが役立つかを完全に予測できないことを示しています。」 次のステップとして学習型セレクターが挙げられています。つまり、厳選されたリトリーバルの数値は、単純な選択手法であったにもかかわらず達成されたものです。

極めて弱いモデルは対象外である。 「最小限の能力ベースラインを下回ると、自己蒸留（self-distillation）はシグナルを欠くことになります。」

総合すると、研究の方向性は十分に裏付けられていますが、具体的な数値はこのベンチマークとこの手法に固有のものです。これらのパーセンテージを、自身のシステムでそのまま得られる数値として引用しないでください。

保存することだけが問題だと捉えること。 ほとんどのメモリセットアップは、より多くをキャプチャ（保存）することに最適化されています。この研究は、キャプチャは簡単な半分に過ぎず、タスクごとに「何が注入されるか」に精度とコストの両方がかかっていることを示しています。

コンテキストが安価になったからといって、すべてを注入すること。 安価であっても無料ではありません。今回の実験では+51%から+78%のコスト増となり、比較的弱いモデルではコンテキストを増やすことで結果が悪化しました。

大規模なモデルほど助けを必要としないと仮定すること。 天井に近いモデルであっても、信頼性指標において有意義な向上が見られました。主要な精度指標ではそれが隠れていましたが、厳格な指標（SGC）では明らかになりました。

平均的な成功率でメモリを評価すること。 TGCは全体を通してメモリの恩恵を過小評価していました。エージェントが「通常は正しい」場合、メモリが修正するのはエージェントが失敗するバリアントであり、それこそがSGCが測定するものです。

1つのモデルで効果が見られなかったからといって、メモリは機能しないと結論付けること。 著者らは、自らのデータからそのような結論を導き出すことを明確に否定しています。

この研究の実践的な解釈は、「保存する量を減らす」ということではありません。メモリレイヤーは、選択ができ、安定したコアを維持し、整理（プルーニング）が可能でなければならないということです。なぜなら、投与量はセットアップ時に一度だけ決めるものではなく、モデルごと、タスクごとに決定するものだからです。

メモリを「コア」と「テール」に分割する。 常に注入される信頼性の高い小さなセット（コア）と、タスクごとに検索されるタスク関連のエントリ（テール）に分けます。これが、比較的弱いモデルにおいて精度とコストの両方で勝利した構成であり、キャッシュ可能な状態を維持できる構成でもあります。

プロンプトキャッシュが機能するようにコアを安定させる。 常にオンになっている部分がステップ間でバイト単位で同一であれば、キャッシュによる割引が適用されます。暗黙的に順序を並べ替えてしまうと、その恩恵は失われます。

自身のモデルで両方の「投与量」をテストする。 自身のタスクで測定し、フルセットと「コア＋リトリーバル」を比較します。この研究自体の結論は、答えはモデルによって異なるということです。

厳格な指標を測定する。 完了したタスクを数えるだけでなく、同じタスクのすべてのバリアントがどれだけの頻度で合格するかをカウントします。そこにこそ、今回の向上が現れています。

ガイドラインの品質が要因として挙げられているため、整理（プルーニング）を行う。 誤ったエントリや古いエントリは無害ではありません。それらは優れたエントリと一緒に注入されてしまいます。

これを実現するには、1つのアシスタントの内部にメモリを蓄積するのではなく、検査や編集が可能な場所にメモリを配置する必要があります。それこそがMemoryLakeです。MCPまたはAPIを介してエージェントが読み取るメモリレイヤーであり、エントリは不透明に肥大化する塊ではなく、個別に編集可能です。これにより、投与量の調整が初めて可能になります。セットアップは3つのステップです。

ステップ 1: APIキーを作成する

MemoryLakeにサインインし、APIキーを作成します。接続するすべてのツールで1つの認証情報を使用できます。

ステップ 2: 最初のメモリをアップロードする

研究のガイドラインセットと同じように、エントリを作成します。1つのエントリにつき1つの主張とし、可能な限り行動に焦点を当てます（効果的だったこと、避けるべきこと、以前の試行を失敗させたエッジケースなど）。登録すべきカテゴリは以下の通りです。

複数回行った修正。 これらは定義上、最も信頼性の高いコアエントリとなります。

失敗モードとそれを回避する方法。 この研究における向上の大部分は、以前は失敗していたバリアントをクリアできたことによるものです。

一見任意に見える制約。 レート制限、順序の要件、ドキュメントと異なる挙動をするAPIなど。

すでに除外された選択肢。 成果物には含まれていないものの、新しいエージェントが毎回提案してくるようなカテゴリです。

ステップ 3: AIとエージェントを接続する

使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定することで接続でき、その他のアシスタントはAPIを介して同じメモリを読み取ることができます。

3つの率直な限界があります。MemoryLakeはこの研究には参加しておらず、上記のパーセンテージはMemoryLakeに関する主張ではありません。結果は、著者ら独自のベンチマークにおける独自の手法によるものです。MemoryLakeは、あなたやあなたのエージェントが書き込んだ内容を保持するため、品質は入力に依存します。また、モデル自体の能力を変化させるわけではありません。エージェントの残された失敗が、ガイダンスによって修正できる種類のものでない場合、優れたメモリであってもそれを解決することはできません。

「コンテキストを増やす」ことがデフォルトの解決策ではなくなる。 比較的弱いモデルでは、増やすことで悪化しました。選択（リトリーバル）こそがレバーです。

信頼性が注視すべき指標になる。 天井に近いモデルを含むすべての階層において、厳格な「全バリアント合格」の指標が、主要な精度指標よりも大きく変動しました。

コストがメモリ導入に反対する理由にならなくなる。 あるモデルではわずか+5%のトークンで+16.1ポイント向上し、他のモデルでは安定したコアに対するプロンプトキャッシュが機能します。

モデルの切り替えは「再調整」を意味するようになる。 能力の階層はサイズから予測できないため、モデルを変更すると適切な投与量も変わる可能性があります。

整理（プルーニング）がパフォーマンス向上のための活動になる。 ガイドラインの品質は、モデルがどのパターンに着地するかを決定する要因の1つとして挙げられています。そのため、古いエントリを削除することは、単なる片付けではなく、重要な作業となります。これに関するトークン側の側面は、メモリレイヤーによるトークン使用量の削減で解説しています。

信頼性の高い小さなコアから始める。 追加が効果的であることを証明できる場合にのみ、それを拡張します。

それ以外はタスクごとに検索（リトリーバル）する。 伸び代のないモデルにとっては、関連するいくつかのエントリを検索する方が、セット全体を与えるよりも優れています。

常時オンのプレフィックスをバイト単位で安定させる。 キャッシュ可能性こそが、許容可能なコストに収まるかどうかの分かれ目です。

自身のタスクでA/Bテストを実行する。 自身のワークロードで、フルセットと厳選されたセットを比較します。この研究の主要な発見は、まさに「答えは普遍的ではない」ということです。

平均ではなく、全か無かでスコアを測定する。 ガイダンスが真価を発揮するのは信頼性です。

日付を記録し、削除する。 古いエントリも同様に注入されてしまいます。

変化がなかった結果を、メモリが役に立たない証拠として捉えない。 著者らは、向上が見られなかった1つのケースについて3つの可能性のある説明を挙げており、どれか1つに断定していません。

メモリをモデルの外部に保持する。 この研究では重みは一切更新されませんでした。だからこそ、このアプローチは「導入コストが低く、テストした8つのモデル間で移植可能」だったのです。移植性は外部に保持することの特性であり、詳細は永続メモリが意味することで解説しています。

持ち帰るべき価値のある発見は、著者らがセクションの見出しに掲げた「メモリは単に蓄積するだけでなく、調整されるべきである」という点です。伸び代のある強力なモデルは、自己蒸留されたフルガイドラインセットを活用しました。比較的弱いモデルは、コンパクトなコアとタスクごとのリトリーバルを組み合わせることで、より優れた結果を残し、それを+51%ではなくわずか+5%のトークンで実現しました。1つのモデルは測定可能な変化を示しませんでしたが、著者らは単一のベンチマークからその理由を説明することを意図的に避けました。

For your own agents that translates into three habits: separate a stable always-on core from a retrieved tail, measure reliability rather than average success, and treat pruning as part of performance. And keep the memory itself somewhere inspectable and editable, because "how much" is a dial you'll be turning every time you change models — not a switch you flip once.