長いタスクを任されたAIエージェントがいる。ツールを何十回も呼びながら働くうち、記録を置く場所が足りなくなり、ここまでの経緯を短い要約に圧縮する。ところが圧縮した途端、たった今失敗したばかりのそのコマンドを、まったく同じようにもう一度実行してしまう。
なぜだろうか。要約は「何をしたか」という大きな流れは残す。しかし二つのものをこぼす。一つは「そのコマンドがなぜ失敗したのか」だ。もう一つは「この結論がどの資料から出てきたのか」、つまり主張と根拠をつなぐ糸である。前者を失えばエージェントは同じミスを繰り返す。後者を失えば、報告書にもっともらしい文章を書きながらも、出典を見当違いな場所に貼り付けてしまう。
REMORYはこの二つの穴を狙う。圧縮するその瞬間、元の記録とその要約を一緒に読み込み、「補助メモリ」を一つ作る。人が読む要約はそのまま残し、その隣にモデルだけが読むメモリを付け足す。だから流れはこうなる。元の記録 →(人用の要約 + モデル用の補助メモリ)→ 次の行動。
結果から言えば、答えは二つに分かれる。同じコマンドを再び呼んだり同じ失敗を繰り返したりする無駄が減った。そして報告書の中で主張を正しい出典へつなぐ力が上がった。逆に、なかった内容を新たに見つけ出してくれるわけではなかった。メモリは「もっと見つける」ではなく「ちゃんとつなぐ」のを助けたのだ。
長いタスクほど、観察結果、ツール出力、決定が積み上がる。コンテキストウィンドウ(モデルが一度に見られる入力の空間)は決まっている。そのため、どこかで過去を押し込まなければならない。Claude CodeやCodex CLIの/compactコマンドがその役目を果たす。それまでの対話をテキスト要約に変えて場所を空け、その要約が続きの作業のチェックポイントになる。
だから入力の長さはノコギリの歯のように動く。積み上がり、圧縮時にストンと落ち、また積み上がる。問題はその谷、つまり圧縮の直後に生まれる。要約は大きな流れは守るが、これから下すすべての決定を支えてくれる保証はない。しかも、いま重要な情報が一時間後にも重要かどうかは、その時になってみなければわからない。
ここにこの研究の前提がある。「要約にこの三文だけ足せばいい」といった事前の選別は通用しない。何が役に立つことになるのかを前もって選べない状況を扱っているのだ。
長い文脈を扱う既存の手法は大きく二つある。一つは過去を人が読める文章として保存しておき、必要なときに検索して取り出す方式。もう一つは長い文章を、モデルだけが読む数値の束に押し込む方式だ。
REMORYはこの二つを重ねる。テキスト要約と検索には手を付けない。その上に、要約と元の記録を一緒に見て作った数値のメモリを一枚かぶせる。正確な過去がどうしても必要なら、エージェントは今まで通りファイル検索のような普通のツールで取り出す。REMORYが埋めるのは、検索を呼ぶ前、モデルが次の一手を打つまさにその瞬間だ。検索をなくそうというのではなく、検索まで行かなくても済む分を前もって埋めておく。
このメモリの正体を押さえておこう。ネットワークが出すのは単語ではなく、モデルが入力としてそのまま読む数値の束(連続ベクトル)だ。過去を文章として書き直すのではなく、モデルの入力の位置に数値の形で置かれる。
ルールが一つある。実際に働くタスクモデルには触らない。そのモデルの中の学習済みの値(重み)はそのまま残し、メモリを作るネットワークだけが学ぶ。学習は固定されたタスクモデルを通してメモリ側へだけ流れる。
学習は二段階だ。第1段階は復元の練習である。原文のある一節をメモリに置き換えても、その一節を復元できるように教える。メモリが元の情報を抱えるようにするためだ。第2段階は役割を分ける。要約とメモリだけを持つ側が、記録全体を見た側と同じ次の応答を出すように合わせる。要約はすでに与えられているので、メモリは自然と、要約が埋められなかった空白の方へ向きを定める。だからメモリは要約と内容が重なってもいいし、抜けた事実をすべて復元する必要もない。要約がすでに与えている情報まで、メモリが抱え込む理由はないからだ。名前の「RE」はここから来ている。要約の上に「差分」だけを乗せる、という意味だ。
- 圧縮単位: 最大1,024個の元位置からなるブロック一つが、64個のソフトメモリトークンを作る。階層的圧縮で最終メモリを4,096スロット以下にまとめつつ、元の順序は保存する。 - タスクモデルに渡すときは、要約の後ろにソフトメモリトークンを続けて連結する(concatenation)。gated cross-attentionは、メモリネットワークがメモリを生成する際に要約を参照するのに使われる。 - アーキテクチャ: Qwen3.8-27BにはDFlashを、GLM-5.3-FlashにはグループダイナミックコンボリューションをつかうDFlash-2を適用した。メモリネットワークの学習パラメータはそれぞれ1.94B、1.502Bだ。 - 第1段階のデータ: MMFineReason-Full-2.3Mのテキストフィールド。教師には原文をそのまま言うよう指示し、生徒はその一節をソフトメモリに置き換えて同じ予測をさせる。 - 第2段階のデータ: 推論・コーディングの軌跡。Open-PerfectBlendのプロンプトと事前計算された要約、Qwenが生成した応答を含み、先行文脈の長さ順に並べたカリキュラムに従う。 - 最適化: 生徒→教師の逆方向KL。全履歴を見た教師の次トークン分布を、要約とメモリだけを持つ生徒が真似るように合わせる。損失は全語彙と応答全体にかかり、前方の位置をわずかに強く重みづけする。メモリパラメータだけが更新される。
実験は二つの問いを分ける。メモリは要約がこぼした情報を本当に学ぶのか。そして、ただ場所を余分に与えたから良くなっただけではないのか。
出典の結びつけはSummHayで測る。長い文書の山から質問に合う洞察を見つけ出し、その出典をつなぐ力を見るベンチマークだ。四つを比べる。全文脈(raw)、要約のみ、要約に同じ分量のテキストを足したsummary++、そして要約+REMORYである。
鍵はsummary++だ。REMORYが余分に使う分の場所を、まったく同じだけ「生成したテキスト」で埋めた条件だ。「場所を余分に与えたから良くなっただけでは」という反論を、この条件が封じる。
エージェント性能はBrowseComp、Terminal-Bench 2.1、AutomationBench、JobBenchで見る。比較ごとに、同じタスクモデルの中で実行環境、プロンプト、ツール、予算、生成設定、圧縮ポリシーをすべて固定し、メモリの有無だけを変える。どちらも正確な過去を検索でき、唯一の介入は圧縮時に最大4,096スロットを足すことだけだ。差が出れば、その原因をメモリに絞り込める。
- SummHay: 十個のコレクションの92クエリすべてをQwen3.8-27Bで評価。回答生成にはツール・検索がなく、正解の洞察と引用は採点にのみ使う。採点はGPT-5.6-Sol。カバレッジと総合スコアは621個の全参照洞察に、引用F1は回収された洞察に対して平均する。 - コンテキストウィンドウ: Qwen 262,144位置、GLM 100万位置。 - 課題数・実行: BrowseComp 1,266個・Terminal-Bench 89個は両アクターとも1回、AutomationBench 600個・JobBench 65個はQwenで5回実行。 - 判定: Terminal-Bench・AutomationBenchは課題検証器、BrowseComp・JobBenchはGPT-5.6-Sol判定者。 - 費用基準: 2026年9月の非キャッシュ供給価でアクターと要約トークンに値を付け、残差位置を入力として数えた数値。元特徴のエンコード、メモリネットワークの実行、ツール費用は抜けている。つまりトークン価格基準の生成費用であって、総実行費用ではない。
まず行動だ。四つのベンチマークでスコアがすべて上がり、その改善はより強いタスクモデルとより大きなコンテキストウィンドウでも維持された(GLM-5.3-Flashはコンテキストウィンドウ100万、320B規模だ)。
| ベンチマーク | タスクモデル | スコア変化 | 実行 |
|---|---|---|---|
| AutomationBench | Qwen | 35.5 → 45.3 (+9.8) | 5回平均 |
| JobBench | Qwen | 33.4 → 41.0 (+7.6) | 5回平均 |
| Terminal-Bench | Qwen | 71.9 → 76.4 (+4.5) | 1回 |
| BrowseComp | Qwen | 74.0 → 77.0 (+3.0) | 1回 |
| Terminal-Bench | GLM | 84.3 → 87.6 (+3.3) | 1回 |
| BrowseComp | GLM | 84.9 → 89.0 (+4.1) | 1回 |
さらにはっきりしているのは「どう」上がったかだ。一つの課題の中で、同じツールが同じ出力をまた出す繰り返しは17.9〜29.8%減った。失敗したコマンドやツールエラーは25.3〜49.7%減った(繰り返しは計画・ポーリングを除いて数えた値、エラーは失敗コマンドと明示的なツールエラーを数えた値だ)。圧縮で過去を失ったエージェントは、たった今やった呼び出しをまたやったり同じ失敗を繰り返したりしやすいのだが、その無駄が目に見えて減った。費用もJobBench($3.09→$3.21)一つを除けば、報告されたすべての比較で下がった。
圧縮直後の「最初の一手」だけを切り取って見た比較もある。100個のQwen BrowseComp記録から取り出した488個のペアになった次の行動を、要約と常駐指示を固定したまま審判モデルが比べたところ、メモリ側が345勝(70.7%)、21分、122敗だった。ただし、これは「提案した次の一手」に対する選好であって、その一手が実際に生んだはずの結果の測定ではない。
次に出典の結びつけだ。ここがこの研究の本当の発見である。SummHayで要約のみのときと要約+REMORYを比べると、こうなる。
| 何を測るか(要約単独 → 要約+REMORY) | 変化 |
|---|---|
| 内容の回収(カバレッジ) | +0.40 — 事実上そのまま |
| 出典の結びつけ(引用F1) | +4.04 |
| 総合スコア | +3.55 |
読み方は単純だ。メモリはなかった洞察を新たに見つけてくれなかった。代わりに、すでに見つけた主張を正しい根拠にきちんとつないでくれた。両方の要約条件で回収された洞察553個だけに絞って見ても、引用F1は57.31から61.41へ上がった。
では場所を余分に与えたから良くなったのか。違う。同じ場所を生成テキストで埋めたsummary++は、要約のみのときとほぼ並んでいた。
| 表現 | 総合スコア | 平均入力位置 |
|---|---|---|
| 全文脈(raw) | 43.41 | 96,872 |
| 要約単独 | 39.84 | 1,393 |
| summary++ | 39.78 | 要約単独 + 追加テキスト |
| 要約+REMORY | 43.39 | 5,024 |
同じ空間でも、普通のテキストで埋めれば実りがなく、学習済みのメモリで埋めてはじめて出典の結びつけが上がった。しかも要約+メモリは、全文脈が使う入力位置の5.2%しか使わずに、総合スコアでrawにぴたりと迫った。
まず結果が語ってくれないことから。第1段階の学習の目標は原文をそのまま復元することで、第2段階の目標は次の行動に役立つ情報を残すことだ。すべての事実を復元することと、いま次の一手に必要な事実だけを残すことは違う。いまの数値が示している信号は後者、つまり行動と出典の結びつけが良くなったという結果だ。
この区別が重要だ。導入で「失敗の理由を埋める」と言ったが、実際に測定されたのは失敗が減ったという「行動」であって、メモリの中にその失敗の理由が入っているという「証拠」ではない。両者を分けるには、もう一歩踏み込む必要がある。圧縮前の記録の「失敗の原因」のような情報がメモリに生き残ったかを直接開けて見るか、その情報をわざと隠したときに圧縮直後の行動がどう変わるかを見る、といった具合だ。性能が良くなったことと、その中身がどう回っているかの間には、まだこれだけの隔たりがある。
著者たちが示した線もある。図1のフロンティアのスコアは、もともとの実行環境と規約で公表された参考値であって、統制された比較ではない。先の「最初の一手」の選好結果は提案に対する選好であって実際の結果ではなく、費用はトークン生成価基準なのでメモリネットワークを回す値は抜けている。
適用条件も甘くない。この手法はタスクモデルごとに1.94B・1.502B規模のメモリネットワークを別途学習しなければならず、その学習がタスクモデルを通る必要がある。そのため、中身をいじれない完全なブラックボックスAPIの上にそのまま乗せるのは難しい。重みを直接サービングする側に有利な設計だ。すべての数値が特定の二つのタスクモデル、特定のベンチマークから出ている以上、他のモデル・ドメインへ広がるかどうかは、まだ開かれた問いだ。
まず線を引こう。ONTLEのモデルはほとんどが外部API(Vertex経由のGemini、Claude)の上で動く。重みへのアクセスを前提にしたこの技法をそのまま乗せることはできない。だから以下は、いますぐ付ける機能ではなく、ONTLEで試してみる設計判断を一つ挙げるものだ。核心はこうだ。圧縮するときに失ってはいけない業務の状態を、要約と分離して別に保存する。
出典がずれるとすぐに表に出る仕事から見よう。ONTLEのAI PMが競合のランディングを十箇所見て回り、その資料で提案書を書くとする。「この価格ポリシーはA社のページから、あの特典の文言はB社のページから」というように、主張ごとに出典が正確に付いていなければならない。ところが圧縮が一度走ると、要約は「競合10社を調査、提案書の下書きを作成」という流れは残すが、どの文がどのページから来たのかは曖昧になる。まさにこの研究が改善した点だ。
繰り返しの方も同じだ。同じPMが予約投稿APIを呼んでいて失敗したのに、圧縮がその失敗メッセージをこぼしたとしよう。直後に同じ呼び出しを同じ理由でまた試みる。人手の足りない小企業の反復業務を代わりに回す製品で、この無駄な呼び出し一回は、そのまま遅延でありコストだ。
だからONTLEが試すべきは、研究の技法の再現ではない。私たちは繰り返しの無駄を招く情報が何かをすでに知っている。終えたURL、失敗した呼び出しとその原因だ。問いは一つに絞られる。この「すでにやったこと」を要約と分離して別に持っていくことは、見合うだけの価値があるのか。
実験はこう組む。終えたURLと失敗した呼び出し・原因を、圧縮とは無関係に別チャンネルで残す経路を作る。そして同じ作業を、この別記録があるときとないときに分けて回す。見る指標は四つだ。繰り返しの呼び出し、エラーの再発、作業の成功率、総費用。場所を余分に与えたことで生まれた効果と分けるために、その場所をただ普通のテキストで埋めた条件を一緒に回して対照群に置く。費用はトークン価と全実行価を別々に書いてこそ、比較が公平になる。
判断基準は先に釘を刺しておこう。作業の成功率を保ちながら繰り返しの呼び出しと総費用が減れば、外部APIの上でも「すでにやったこと」チャンネルが値をすることの根拠になる。そういう改善が見えなければ、結論は「要約一つで十分」ではない。「今回選んだ記録と提供方式では効用を確認できなかった」までだ。別の記録、別の方式の余地はそのまま開いている。
いいえ。ブロックを階層的にまとめ直して、最終メモリを4,096スロット以下に保つ。元の順序は保存しつつ、総量には上限がある。
必要ない。全記録を見た教師は、学習時に正解の役をするだけだ。実際の運用では、要約とメモリだけで次の応答を出す。
コンテキストウィンドウを広げると、過去を原文のままもっと多く持っていくことになり、入力の位置をたくさん使う。REMORYははるかに少ない入力位置で、似た総合スコアに届いた。場所を増やすアプローチではなく、少ない場所で過去の役立ちだけを残すアプローチだ。