エージェントメモリの注入量:モデル階層別の最良構成とトークン増

この記事は、海外の一次情報をAIエージェントが調査・検証・翻訳して整理したものです。実際に製品やサービスを試した体験談ではありません。

結論:最良の注入量はモデルの階層で変わる

IBM Research が2026年8月18日に Hugging Face Blog へ公開した『How Much Memory Does Your Agent Actually Need?』によると、過去の実行から採掘したガイドラインをエージェントへ注入する最良の構成は、モデルによって異なりました。

弱いモデル(gpt-oss-120b)は、全量注入ではなく選別して渡す構成が最良
伸びしろのあるモデル(DeepSeek-V3.2、Claude Opus 4.6)と、天井に近いとラベルされたモデル(GPT-5.5)は全量注入が最良
飽和とラベルされたモデル(GLM-5)は、最良構成でもベースラインから測定可能な改善が無かった

同記事は8モデルへ評価を広げたと本文で2度述べており、範囲を「30Bの密結合モデルからフロンティアのプロプライエタリなシステムまで」と説明しています。ただし表に名前が出るのは代表5モデルで、残り3モデルの名称は原典に記載がありません。以下の数値はすべて IBM Research が自社の評価で報告した値で、2026年8月19日時点で第三者による追試・反証の報告は見つかりませんでした。

3つの注入構成の違い

IBM Research の記事によると、比較された構成は3つです。

構成	何を渡すか	渡す頻度
baseline	何も渡さない(出荷状態)	—
full guideline set	採掘した全ガイドライン	毎 ReAct ステップ
curated retrieval	高信頼のコア群(固定)+タスク別に検索した数件	タスクごとに可変部分を差し替え

同記事は、2つのメモリ構成が同一のガイドライン集合から引いていること、その集合は AppWorld の訓練分割のみから一度採掘したものであること、両者で変わるのは「配り方」だけであること、テスト分割のデータは構築に一切入っていないことを述べています。

なお注入したガイドラインの件数は公表されていません。原典は「モデルが採掘する件数はそのモデル自身の能力に依存するため、生の件数ではなく戦略名で構成を報告する。件数はモデル間で比較できない」と理由を書いています。

モデル階層別の最良構成(AppWorld test_normal・168タスク)

TGC は task completion、SGC はより厳しい scenario goal completion です。単位はポイント(percentage point)であり%ではありません。

モデル(原典のラベル)	最良構成	TGC	SGC	ΔTGC	ΔSGC
gpt-oss-120b・117B MoE(Weak / selective)	curated retrieval	39.9→56.0	21.4→37.5	+16.1	+16.1
DeepSeek-V3.2・671B MoE(Strong w/ headroom)	full guideline set	79.8→89.3	64.3→80.4	+9.5	+16.1
Claude Opus 4.6(Strong w/ headroom)	full guideline set	90.5→94.6	87.5→94.6	+4.1	+7.1
GPT-5.5(Strong / near-ceiling)	full guideline set	92.3→95.2	82.1→89.3	+2.9	+7.2
GLM-5・745B MoE(Saturated)	full guideline set	87.5→87.5	80.4→80.4	0.0	0.0

スコアの測定範囲は585タスクではない

原典は評価環境を「168 の test_normal と 417 の test_challenge、計585タスク、9つのシミュレートされたアプリ(カレンダー、メッセージング、決済など)」と説明しています。一方で表と図のスコアには、明示的に「test_normal で測った task completion」と書かれています。test_challenge のスコアは原典に一切出てきません。同チームが2026年8月11日に出した記事も、同じ設定を「AppWorld test_normal, 168 tasks」と明記しています。

AppWorld 開発者側の公式リポジトリの README(2025年11月時点の記載)によれば、この環境は9つの日常アプリを457のAPIで操作するもので、タスクは train / dev / test_normal / test_challenge の4分割を持ちます。585 は test 側2分割の合計であって、train / dev を含めたタスク総数ではありません。

GLM-5 の 0.0 が意味すること

原典が示しているのは「最良のメモリ構成でもベースラインと同値で、差は 0.0」という1行だけです。構成ごとの個別スコアは掲載されていません。飽和というラベルについても、原典は「このラベルは観測したことの記述であって、証明された原因ではない」と断っています。

払う入力トークン(タスクあたり平均・全ステップ累計)

原典の Table 1 に載っているのは3行だけです。増加率はベースライン比で、金額ではありません。

モデルと構成	ベースライン	メモリあり	増加率
DeepSeek-V3.2 / full guideline set	148K	263K	+78%
gpt-oss-120b / full guideline set	110K	166K	+51%
gpt-oss-120b / curated retrieval	110K	116K	+5%

同記事は、DeepSeek がメモリの有無にかかわらず平均およそ18〜19の ReAct ステップで走ること、したがって増えた分は入力トークンの膨張であって軌跡が長くなったのではないことを述べています。Claude Opus 4.6・GPT-5.5・GLM-5 のトークン値は原典にありません。

gpt-oss-120b で費用対効果が逆転する

同じモデルの2行を並べると、curated retrieval が +5%のトークン増で +16.1ポイント、full guideline set が +51%のトークン増という対比になります。ただし full guideline set 側のスコアは数値が公表されておらず、原典は「伸びは小さく、トークンは約50%多くかかった」と定性的に書くだけです。「多く払って少なく返った」とは言えても、いくら返ったかは分かりません。

自社エージェントで確認する手順

評価分割を固定し、メモリなしのベースラインを測る。分割を変えると前後比較が成立しません
ベースラインが低く伸びしろが大きいなら、全量注入より先に「固定のコア+タスク別検索」を試す
すでに高スコアで頭打ちに近いなら、注入しても差が出ない可能性を織り込む
スコアの差(ポイント)と入力トークンの増加率(%)を同じ表に並べる。片方だけでは判断できません
引用するときは測定分割(test_normal 168タスク)と時点を必ず添える

同じモデルでも与える条件でスコアの見え方が変わる例は、評価に与える計算量の上限とスコアの関係を整理した記事や、プロンプトの与え方で指標ごとの順位まで動いた TutorMoments の記事でも扱っています。

注意点:原典が明言していないこと

著者は本文で、結果が AppWorld という単一ベンチマークで検証されたものであること、どのパターンに入るかは単純なパラメータ数では決まらないことを明記しています。ベンチマークの伸びしろ、コンテキスト窓のサイズ、アーキテクチャ、ガイドラインの品質、タスク分布がいずれも影響しうるとされ、その切り分けは進行中の作業と書かれています。今後の課題として挙がっているのは、学習型のセレクタ、非常に弱いモデル向けの教師蒸留メモリ、AppWorld 以外での検証、コンテキスト窓の影響の切り分けの4点です。

金額換算は原典にありません。プロンプトキャッシュを「本番における効率の要」と定性的に述べるだけで、削減率は示していません
コンテキスト窓の影響は仮説段階だと原典が明言しており、この要因を切り分ける対照実験はまだ行われていないと書かれています
第三者による追試は2026年8月19日時点で見つかりませんでした
原典が technical report としてリンクする論文(2026年3月11日提出)は対象も構成も異なる別の実験で、本記事の表の数値とは別物です