AIエージェントのメモリは最適量がモデルで異なる、IBMが8モデルで検証

IBM ResearchのAppWorld検証、8モデルのAIメモリ比較

IBM Researchは2026年8月18日に、AIエージェントのメモリを8モデルで比較した検証を公開しました。結論として、メモリは切り替えて使う機能ではなく、モデルに合わせて量を調整するものだと述べています。 対象は、全体を毎回動かす30B(300億)級の密モデルから最先端の独自モデルまでの8つです。

評価に使ったのはAppWorldです。9つの模擬アプリ(カレンダー・メッセージ・決済など)にまたがる、585件の多段タスクで構成されます。内訳は通常セット168件と難関セット417件です。

採点は2種類あります。TGC(Task Goal Completion)は、個々のタスクを最後まで完遂できたかを確認する指標です。SGC(Scenario Goal Completion)はより厳しい指標で、同じ依頼のデータや言い回しを変えた派生を1つでも落とすと不合格になります。

"When we scaled the evaluation to eight models — from a 30B dense model to frontier proprietary systems — one finding stood out:"/"Agentic memory is not a feature you switch on. It's a dose you calibrate to the model."/"We evaluated on AppWorld — 585 multi-step tasks (168 test_normal + 417 test_challenge) across 9 simulated apps (calendars, messaging, payments, and so on). Tasks are scored two ways: whether the agent fully completes each task (TGC — Task Goal Completion) and whether every variant of a scenario passes (SGC — Scenario Goal Completion, a stricter, all-or-nothing bar)."/"SGC — Scenario Goal Completion. A stricter, all-or-nothing metric. Each scenario bundles several variants of the same task (the same request with different data, phrasing, or edge conditions). SGC counts a scenario as passing only if the agent succeeds on every variant."(Results Across the Spectrum 節/Appendix: Understanding the Metrics 節)— IBM Research より
公式情報を見る →

IBMのAI記憶は重みを更新せずガイドラインを与える

ここでいうメモリは、過去の会話をそのまま読み込ませるものではなく、エージェントが過去に残した軌跡(試行の記録)から作ったガイドライン集で、モデルの重みは更新されません。 ガイドラインには、うまくいった戦略・避けるべき失敗・例外的な状況への対処方法が入ります。作るのはALTK-Evolveという仕組みで、手順は4段階です。

  • エージェントがタスクに挑み、軌跡を残す
  • 成功と失敗の両方から、行動指針を抽出する
  • 抽出した指針を、再利用できる集合へ統合する
  • 推論時に、全部または一部をエージェントに読み込ませる

モデルそのものは変わらず、変わるのはエージェントが受け取る指示の中身だけです。そのためIBM Researchは、導入が安く、試した8モデルのどれにもそのまま使うことができると述べています。

比較した構成は次の3つです。ReAct(考える→ツールを使う→結果を調べる、という手順を反復する進め方)の各ステップで、エージェントのコンテキストに入るものが構成ごとに異なります。

構成 エージェントのコンテキストに入るもの
ベースライン メモリなし。手を加えていない素のエージェント
全部入り 抽出したガイドラインを全件、ReActの各ステップで毎回注入
厳選検索 確度の高い固定のコア+タスクごとに検索した少数の関連ガイドライン

2つのメモリ構成は同じガイドライン集を使い、異なるのは渡し方だけです。ガイドラインはAppWorldの訓練分割だけから1回作り、テスト分割のデータは1件も混ぜていません。モデルが抽出する本数は実力で変わるため、IBM Researchは件数ではなく構成ごとに結果を報告しています。

""Memory" here doesn't mean replaying a past transcript. It means a guideline set — strategies that worked, mistakes to avoid, and edge cases — distilled from the agent's own prior trajectories."/"No model weights are updated. The learning loop changes the guidance available to the agent, not the underlying model — which is exactly why it's cheap to adopt and portable across the eight models we tested."/"The agent attempts tasks and produces trajectories. ALTK-Evolve extracts behavioral guidelines from both its successful and unsuccessful runs. It consolidates those guidelines into a reusable set."/"Both memory configurations draw from the same guideline set, mined once (via the loop above) from AppWorld's training split only. What changes between them is only how that one set is delivered — the full guideline set injects all of it every step, while curated retrieval delivers a selected subset — never how the guidelines were produced, and no test-split data ever goes into building it."/"The number of guidelines a model mines depends on its own capability, so we report configurations by strategy — "full guideline set" vs. "curated retrieval" — rather than by raw counts, which aren't comparable across models."(Learning happens around the model, not inside it 節/The three configurations we compare 節)— IBM Research より
公式情報を見る →

AppWorldのReActエージェントは強いモデルほど全部入りで伸びる

伸びしろの残る強いモデルは、まれな例外への対処を含むガイドライン全件を使いこなせるため、全部入りが最良でした。 DeepSeek-V3.2(671B)は、自分で抽出したガイドライン全件を与えると、タスク完遂率が9.5ポイント上がりました。TGCの伸びしろが小さいGPT-5.5とClaude Opus 4.6でも、厳しいSGCではそれぞれ+7.2ポイントと+7.1ポイントの上積みが出ています。

IBM Researchが公開した8モデルの結果から代表5モデルを抜き出すと、結果は次のとおりです。数値は割合で、高いほど良い結果です。

代表5モデルの結果(AppWorldの通常セットtest_normal。TGC・SGCは%。MoE=必要な部分だけを動作させる方式のモデル)

モデル ベースラインTGC / SGC 最良構成TGC / SGC 最良の渡し方
gpt-oss-120b (117B MoE) 39.9 / 21.4 56.0 / 37.5 厳選検索
DeepSeek-V3.2 (671B MoE) 79.8 / 64.3 89.3 / 80.4 全部入り
Claude Opus 4.6 90.5 / 87.5 94.6 / 94.6 全部入り
GPT-5.5 92.3 / 82.1 95.2 / 89.3 全部入り
GLM-5 (745B MoE) 87.5 / 80.4 87.5 / 80.4 改善なし

表の値を比較すると、DeepSeekはTGCが+9.5ポイントだったのに対し、SGCは+16.1ポイント上がっています。IBM Researchは、まだ克服していない失敗の型がモデルに残っている限り、メモリの効果は続くとしています。

"Strong models with headroom want the full guideline set — every guideline, including rare edge-case lessons. They have the capacity to absorb and apply all of it. DeepSeek-V3.2 (671B MoE) climbed +9.5 percentage points in task completion when given its full self-mined guideline set."/"And the effect doesn't disappear at the top of the range: GPT-5.5 and Opus, both near the ceiling on TGC, still gain +7.2 and +7.1pp SGC respectively."/"Memory keeps paying off as long as a model has a remaining failure mode to target."/"Figure 1. Representative models in the three observed patterns. Bars show TGC on AppWorld test_normal for baseline vs. the best-memory configuration"(The Key Insight: Dosage Depends on Capability 節/The three patterns, in one view 節)— IBM Research より
公式情報を見る →

弱いモデルのAI記憶は厳選検索が最良、トークン費用も最小

小さいモデルや弱いモデルは大きなガイドライン集を使いこなせないため、確度の高い小さなコアにタスク別の検索を組み合わせる厳選検索が最良でした。 gpt-oss-120bは、この方式でタスク完遂率が16.1ポイント上がっています。全部入りは上げ幅が小さいうえに、トークンが約50%多くかかりました。

費用は渡し方で大きく変わります。全部入りはガイドラインを毎ステップ再送するため、ReActでは各ステップの入力が膨らみます。タスク1件あたりの平均トークン使用量は次のとおりです。

タスク1件あたりの平均トークン使用量(エージェントの全ステップ累計。メモリなしのベースラインと比較)

モデル 構成 ベースライン メモリあり 増加率
DeepSeek-V3.2 全部入り 148K 263K +78%
gpt-oss-120b 全部入り 110K 166K +51%
gpt-oss-120b 厳選検索 110K 116K +5%

gpt-oss-120bは厳選検索で、トークンの増加を5%に抑えて完遂率を16.1ポイント上げました。精度の高い方式が、費用面でも有利だったことになります。

全部入りで増えるのは入力トークンです。DeepSeekはメモリありでもReActのステップ数がほぼ変わらず、平均で約18〜19回でした。軌跡が長くなったのではなく、毎回のガイドライン再送が費用を押し上げています。

"Smaller or weaker models get drowned by a large guideline set. For these, a tight, high-confidence core plus a handful of task-relevant guidelines retrieved per task works best. gpt-oss-120b (117B MoE) gained +16.1pp with this selective approach — while the full guideline set gained less and cost ~50% more tokens."/"A practical concern: injecting a full guideline set inflates every ReAct step's input, because the guidelines are re-sent each turn."/"Table 1. Average token use per task, accumulated across agent steps, measured against the no-memory baseline."/"Curated retrieval keeps cost near baseline. For weaker models, where selection wins on accuracy, it also wins on cost — the best of both worlds (+16.1pp TGC at only +5% tokens for gpt-oss-120b). Better performance here does not require more inference cost."/"Memory doesn't blow up the reasoning loop. DeepSeek runs about the same number of ReAct steps with memory as without (≈18–19 on average), so the added cost is input-token inflation, not longer trajectories."(The Key Insight: Dosage Depends on Capability 節/The Cheapest Memory Strategy Can Also Be the Best 節)— IBM Research より
公式情報を見る →

IBM ResearchのAppWorldで飽和したGLM-5は伸びず

GLM-5(745B)は、メモリを与えても測定できる改善が出ない飽和のパターンに入りました。 代表5モデルの表のとおり、メモリありでもなしでもTGCは87.5でSGCは80.4と同じ値です。

IBM Researchは、飽和は観測された結果の呼び名で、原因が証明されたわけではないと述べています。考えられる原因は次の3つで、どれが正しいかは分かっていません。

  • これらのタスクでは、もともと伸びしろが小さかった
  • ガイドラインが、残る失敗に対応していなかった
  • モデルが指針をうまく適用できていなかった

どのモデルがどのパターンに入るかは、パラメータ数(モデルの規模を表す数)だけでは定まりません。ベンチマーク上の伸びしろ・コンテキストウィンドウ(一度に読み込める文章量)の大きさ・アーキテクチャ(モデルの設計)・ガイドラインの質・タスク分布が影響しているように見えると、IBM Researchは述べています。

どの要素がどれだけ影響するかの切り分けは、まだ研究が続いている段階です。飽和したモデルについては、残る失敗の型がよく分かるまで追加のコンテキストを入力しないのが良いとのこと。

"Already-saturated models show no measurable gain. We call this the saturated pattern — the label describes what we observed, not a proven cause. The model may already have been near its ceiling on these tasks, the guidelines may not have addressed its remaining failures, or it may not have applied the guidance effectively. GLM-5 (745B MoE) sat here in our runs."/"What puts a model into one pattern rather than another isn't simply parameter count. Benchmark headroom, context-window size, architecture, guideline quality, and task distribution all appear to shape where a model lands, and separating those factors is ongoing work."/"spending no extra context until their remaining failure modes are better understood"(The Key Insight: Dosage Depends on Capability 節)— IBM Research より
公式情報を見る →

全部入りのトークン費用はプロンプトキャッシュで抑える

全部入りで増えるトークン費用への対策として、IBM Researchはプロンプトキャッシュの活用を勧めています。また、全部入りではDeepSeek-V3.2で+78%、gpt-oss-120bで+51%トークンが増えました。

IBM Researchは、ガイドライン集の静的な部分はステップをまたいで同一なのでキャッシュでき、実効コストを大きく削れると述べています。ガイドライン集の先頭部分を固定してキャッシュされたままにする設計にも、取り組む価値があるとしています。

"The real efficiency lever in production is prompt caching: the static portion of the guideline set is identical across steps and can be cached, cutting effective cost substantially. Cache-aware prompt design — keeping the shared guideline-set prefix stable so it stays cacheable — is worth engineering for."(The Cheapest Memory Strategy Can Also Be the Best 節)— IBM Research より
公式情報を見る →

AIエージェントのメモリはモデルの強さに応じて量を変える

AIエージェントのメモリは、ガイドラインを全部与えればどのモデルでも性能が上がるわけではなく、最適量がモデルごとに異なります。 IBM Researchが8モデルをAppWorldで比較した結果をまとめると、モデルに応じた渡し方は次の3つです。

  • 伸びしろの残る強いモデルには、ガイドラインを全件与える方式(全部入り)
  • 小さいモデルや弱いモデルには、確度の高いコアとタスク別検索の併用
  • 飽和したモデルには、残る失敗の型が分かるまで追加のコンテキストを入力しない

費用は、gpt-oss-120bの厳選検索でトークン増加が+5%、DeepSeek-V3.2とgpt-oss-120bの全部入りで+51〜78%でした。ただし、検証に使ったのはAppWorldという1つのベンチマークだけです。他のベンチマークや実運用での検証は進行中だと、IBM Researchも述べています。

メモリに何をどれだけ入れるかは、コンテキストの組み方の話でもあります。与える情報を削る側から考える方法は「コンテキストエンジニアリングでClaude Codeの指示を80%削減」にまとめています。複数のエージェントを並べたときに何が壊れるかは「マルチエージェントAIが失敗する3つの型とAnthropicの設計対策」にまとめました。

FAQ

AIエージェントのメモリを増やせば性能は上がりますか?
増やすほど上がるわけではありません。IBM Researchはエージェンティックメモリを切り替えて使う機能ではなく、モデルごとに量を調整するものだと結論づけています。モデルの実力に合った量を与えたときに、最も効果が出ました。
メモリを足すとトークン費用はどれくらい増えますか?
渡し方で大きく変わります。ガイドラインを毎ステップ全部入れる方式では、DeepSeek-V3.2で+78%、gpt-oss-120bで+51%でした。コアと検索を組み合わせる方式では、gpt-oss-120bで+5%に収まっています。
この結果はどのベンチマークで測ったものですか?
AppWorldという単一のベンチマークです。9つの模擬アプリにまたがる585件の多段タスクで構成されます。IBMも、より広いベンチマークと実運用での検証は進行中だと述べています。