IBMが示したのは「記憶は用量」という考え方
過去の仕事から学ばせて次に活かす。エージェンティックメモリの発想はそれだけ聞けば単純で、経験が増えるほど成績も上がりそうに思えます。IBM Research が8モデルへ評価を広げて得た結論はそこからずれていました。記憶はオンオフする機能ではなくモデルごとに合わせる用量。それが今回の要点です。
記憶の中身は過去の軌跡から抽出したガイドライン
ここでいう記憶は過去の会話ログをそのまま再生することではありません。エージェント自身の過去の軌跡から蒸留したガイドライン集を指します。うまくいった戦略、避けるべき失敗、例外的な状況への対処。それらを再利用できる形にまとめたものです。
この仕組みの名前は ALTK-Evolve。手順は4段階です。エージェントがタスクに挑んで軌跡を残す。成功と失敗の両方から行動指針を抽出する。抽出した指針を再利用可能な集合へ統合する。推論時に全部または一部をエージェントへ渡す。モデルの重みは1つも更新されません。 変わるのはエージェントが受け取る指示の中身だけです。導入が安く8つのモデルへそのまま持ち運べたのはこの設計のおかげだと同社は説明しています。
""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."(Learning happens around the model, not inside it 節)— IBM Research より公式情報を見る →
配り方は3種類を比べた
比較されたのは3つの構成です。何がコンテキストに入っているかを先に押さえておくと以降の数字が読みやすくなります。
| 構成 | エージェントのコンテキストに入るもの |
|---|---|
| ベースライン | 記憶なし。出荷状態のエージェント |
| 全部入り | 抽出したガイドラインを全件、ReAct(考える→道具を使う→結果を見るを繰り返す進め方)の各ステップで毎回注入 |
| 厳選検索 | 確度の高い固定のコア+タスクごとに検索した少数の関連ガイドライン |
2つの記憶構成は同じガイドライン集から引いています。違うのは配り方だけで作り方は共通です。しかもガイドラインは AppWorld の訓練分割からのみ抽出され、テスト分割のデータは1件も混ざっていません。モデルが抽出するガイドラインの本数は実力によって変わるため件数ではなく戦略として比較されています。
"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."(The three configurations we compare 節)— IBM Research より公式情報を見る →
モデルの実力で最適な量が変わる
評価環境は AppWorld です。カレンダー・メッセージ・決済など9つの模擬アプリにまたがる585件の多段タスク(通常168件、難関417件)で構成されます。採点は2種類。個々のタスクを完遂できたかを見る TGC と、同じ場面のあらゆる派生をすべて通せたかを見る SGC です。厳しいのは全か無かで判定する SGC のほうです。
8モデルの比較から抜き出した代表例(AppWorld の通常セット test_normal。TGC・SGC は%、Δ はポイント)
| モデル | パターン | ベースライン TGC / SGC | 最良構成 TGC / SGC | 最良の配り方 | Δ TGC | Δ SGC |
|---|---|---|---|---|---|---|
| gpt-oss-120b (117B MoE(MoE=必要な部分だけを動かす方式)) | 弱い・選別型 | 39.9 / 21.4 | 56.0 / 37.5 | 厳選検索 | +16.1 | +16.1 |
| DeepSeek-V3.2 (671B MoE) | 強く余力あり | 79.8 / 64.3 | 89.3 / 80.4 | 全部入り | +9.5 | +16.1 |
| Claude Opus 4.6 | 強く余力あり | 90.5 / 87.5 | 94.6 / 94.6 | 全部入り | +4.1 | +7.1 |
| GPT-5.5 | 強い・天井付近 | 92.3 / 82.1 | 95.2 / 89.3 | 全部入り | +2.9 | +7.2 |
| GLM-5 (745B MoE) | 飽和 | 87.5 / 80.4 | 87.5 / 80.4 | 全部入り | 0.0 | 0.0 |
"When we scaled the evaluation to eight models — from a 30B dense model to frontier proprietary systems — one finding stood out:"/"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)."(Results Across the Spectrum 節)/"AppWorld tasks are graded by two metrics, both reported as percentages (higher is better):"/"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."(Appendix: Understanding the Metrics 節)/"Figure 1. Representative models in the three observed patterns. Bars show TGC on AppWorld test_normal for baseline vs. the best-memory configuration"(The three patterns, in one view 節・代表例の表と同じ掃引に基づく図の注記)— IBM Research より公式情報を見る →
強いモデルは全部入り、弱いモデルはコアと検索
余力のある強いモデルはまれな例外への対処まで含めたガイドライン全件を欲しがりました。全部を吸収して適用できるだけの容量があるからです。DeepSeek-V3.2 は自ら掘り出したガイドラインを全件与えたときにタスク完遂率が9.5ポイント上がりました。
反対に小さいモデルや弱いモデルは大きなガイドライン集に溺れます。こちらは確度の高い小さなコアにタスクごとの関連ガイドラインを数本足すやり方が最良でした。 gpt-oss-120b はこの選別型で16.1ポイント上がり、全部入りでは上げ幅が小さいうえトークンが約50%多くかかっています。
天井際でも効果は消えません。TGC で天井に近い GPT-5.5 と Claude Opus 4.6 も厳しいほうの SGC ではそれぞれ7.2ポイントと7.1ポイント伸びています。残っている失敗の型を狙える限り記憶は効き続けます。
"Memory keeps paying off as long as a model has a remaining failure mode to target."/"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."/"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."/"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."(The Key Insight/Results Across the Spectrum 節)— IBM Research より公式情報を見る →
「飽和」は観測されたラベルであって原因ではない
3つ目のパターンが飽和です。GLM-5 は記憶を与えても TGC・SGC ともに動きませんでした。ここで原典の書きぶりに注意が要ります。飽和というラベルは観測した現象を指すもので、原因が証明されたわけではないと明記されています。 すでにこれらのタスクで天井に近かった可能性、ガイドラインが残る失敗に効いていなかった可能性、指針をうまく適用できなかった可能性が並列に挙げられています。
どのパターンに入るかはパラメータ数だけでは決まりません。ベンチマーク上の伸びしろ、コンテキストウィンドウの大きさ、アーキテクチャ、ガイドラインの質、タスクの分布。これらが影響しているように見えるものの、要因の切り分けは継続中の課題だとされています。原典が飽和したモデルに示す処方は「追加の文脈を割かない」ですが、これは無期限の結論ではありません。残っている失敗の型がもっとよく分かるまでは割かない、という条件つきの判断です。
"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 より公式情報を見る →
安いやり方が最も効く場合がある
記憶の話で見落とされがちなのが費用です。ガイドラインを毎ステップ入れ直す方式は入力を毎回膨らませます。実測はこうなりました。
タスク1件あたりの平均トークン使用量(エージェントの全ステップ累計)
| モデル | 構成 | ベースライン | 記憶あり | 増加率 |
|---|---|---|---|---|
| DeepSeek-V3.2 | 全部入り | 148K | 263K | +78% |
| gpt-oss-120b | 全部入り | 110K | 166K | +51% |
| gpt-oss-120b | 厳選検索 | 110K | 116K | +5% |
"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."(表の注記)— IBM Research より。上表の3行(148K→263K/110K→166K/110K→116K と各増加率)は、この Table 1 に各セルとして掲載されている公式情報を見る →
厳選検索は+5%のコストで+16.1ポイント
弱いモデルでは精度で勝つやり方がそのまま費用でも勝ちました。gpt-oss-120b は厳選検索でタスク完遂率を16.1ポイント上げながら、トークン増加はわずか5%。性能を上げるために推論コストを積む必要が無かったという珍しい形です。
費用が増える理由も切り分けられています。DeepSeek は記憶ありでも ReAct のステップ数がほぼ変わらず、平均で18〜19回程度でした。つまり増えているのは入力トークンであって、思考の往復が長引いたわけではありません。
"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 Cheapest Memory Strategy Can Also Be the Best 節)— 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 より公式情報を見る →
無料ツール文字数カウントテキストの文字数・単語数・行数をリアルタイムでカウント。レポートやSNS投稿に。今すぐ使ってみる →
まとめ
AIエージェントの記憶は貯めた経験を全部渡せば賢くなるという性質のものではありませんでした。IBM Research が8モデルを AppWorld で比べた結果は3つの処方に分かれます。強く余力のあるモデルには全部入り、弱いモデルにはコア+タスク別検索、飽和したモデルには残る失敗の型が分かるまで追加の文脈を割かない。厳選検索はトークン増5%で16.1ポイントという結果を出し、安い選択肢が最良になる場面があることも示しました。ただしこれは AppWorld という単一ベンチマークでの検証であり、より広い環境での確認は進行中だと同社自身が断っています。 手元のエージェントに当てはめるならまず量を変えて測る。話はそこからです。



