本文へスキップ
AI-Papers

CarryOnとは?文脈をオブジェクト化しトークンを51.9%削減する新手法

CarryOnとは?文脈をオブジェクト化しトークンを51.9%削減する新手法
  • 長期タスクのAIエージェントの文脈を、履歴の要約ではなく再利用可能な「タスクオブジェクト」として保持する実行時基盤CarryOnが提案されました
  • OSWorld 2.0で部分スコアが43.9%から49.7%に向上し、総トークン量は51.9%、タスク当たりコストは35.9%削減されました
  • 要約圧縮やスライディングウィンドウといった既存の文脈管理手法は精度を落とす一方、CarryOnは精度と削減を同時に達成しています

研究の背景

パソコン操作や長時間のWeb調査を自律的にこなすエージェントは、数百ステップにわたって対話を積み上げます。その過程で入力文脈が膨張し、推論コストと遅延がステップごとに増え続けるという問題を抱えてきました。

これまでの対処は、古い履歴を切り捨てるスライディングウィンドウか、履歴を自然言語で要約して引き継ぐ圧縮が主流でした。しかしどちらも「何をどうやって進めたか」という経緯の記述を残す発想であり、肝心の成果物そのものは文脈の外に置かれたままです。結果として、エージェントは要約を読み直しても自分が既に作ったものを信頼できず、同じ作業をやり直してしまいます。

カリフォルニア大学サンディエゴ校などの研究チームが発表した論文「Pack Light, CarryOn: Building Object-Oriented Context for Long-Horizon Agents」は、この前提を入れ替えます。文脈を履歴の圧縮物ではなく、再利用できる進捗の集合として構造化するオブジェクト指向の文脈ランタイムがCarryOnです。

図1: スライド編集とレポート作成の例。作業中のファイルが完了済みの進捗を担い、未解決の制約だけを明示的に残すことで、能動文脈を42.4Kから14.4Kトークンへ圧縮している
図1: スライド編集とレポート作成の例。作業中のファイルが完了済みの進捗を担い、未解決の制約だけを明示的に残すことで、能動文脈を42.4Kから14.4Kトークンへ圧縮している(論文 Figure 1)

図1は発想を端的に示しています。スライド編集タスクでは、編集済みのプレゼンテーションファイル自体が進捗の担い手になり、文脈に残すのは未達の制約と保存確認だけで済みます。この切り分けによって能動文脈が66.0%減りました。

提案手法

CarryOnは各時点の文脈を3つの構成要素に分けて管理します。中核がcontinuation carrier(継続キャリア)と呼ばれる版管理されたレコードで、安定した識別子を持ち、再利用できる内容や環境中のオブジェクトへの参照を、その利用条件と結び付けて保持します。

キャリアは扱う対象の性質に応じて3種類に分かれます。

  • 外部オブジェクト: 環境に実在するファイル、文書、表計算シート
  • 情報プロダクト: 出典参照付きの主張として保存された調査結果
  • 状況依存状態: 特定のアプリやセッションに紐づく進捗を環境アンカー付きで記録

残る2つは、キャリアで表せない現在の焦点や未処理の義務、有効な制約をまとめた実行文脈と、直近の畳み込み以降の生の対話である live tail です。キャリアと実行文脈が長く残り、live tail だけが入れ替わっていく構成になっています。文脈設計の考え方そのものに関心があればコンテキストエンジニアリングとは?プロンプトとの違いと圧縮・メモリ設計を解説も参考になります。

畳み込みの仕組み

難しいのは、根拠となった履歴を捨てた後もキャリアを有効なまま保つ点です。CarryOnは履歴を畳み込むたびに表現全体を作り直すのではなく、新しい情報の影響を受けたレコードだけを更新し、影響のないレコードはそのまま持ち越します。

図2: CarryOnの全体像。Trackerが候補を追跡し、証拠照合と環境チェックを経てCompilerがキャリアと実行文脈の更新をまとめて生成する
図2: CarryOnの全体像。Trackerが候補を追跡し、証拠照合と環境チェックを経てCompilerがキャリアと実行文脈の更新をまとめて生成する(論文 Figure 2)

図2が処理の流れです。Tracker が候補キャリアを追跡し、準備が整うと編集を要求します。情報プロダクトは出典と突き合わせて検証され、環境中のオブジェクトに紐づく候補は Grounder が読み取り専用で環境を確認し、支持、矛盾、不明のいずれかを返します。

その上で Compiler がキャリアの編集案と、live tail 全体から導いた実行文脈の改訂を同時に生成します。識別子、版、証拠の裏付け、出力制約の検査を通れば更新が原子的に確定し、対象となった対話が能動文脈から外れます。検査に失敗すれば以前の状態が保たれるため、壊れた状態が残りません。ただしこの検査が確かめるのは一貫性であり、タスクとしての正しさを保証するものではないと論文は明記しています。

実験結果

評価にはパソコン操作タスクのOSWorld 2.0と、深いWeb調査を要するBrowseComp-Plusが使われました。エージェント、Tracker、Compilerのすべてに Claude Opus 4.7 を用い、追加学習は行っていません。

指標

ベースライン

CarryOn

OSWorld 2.0 二値スコア

15.7%

19.4%

OSWorld 2.0 部分スコア

43.9%

49.7%

OSWorld 2.0 総トークン

40.10M

19.30M(-51.9%)

OSWorld 2.0 タスク当たりコスト

$36.83

$23.62(-35.9%)

BrowseComp-Plus 正答率

49%

56%

BrowseComp-Plus 総トークン

1.56M

1.20M(-22.9%)

OSWorldでは平均入力文脈が65Kトークン付近で安定したのに対し、ベースラインは200Kを超えて伸び続けました。CarryOnは畳み込み処理の分だけ初期にコストが上乗せされますが、500ターン時点では累積コストが34.1%低くなり、投資が回収されています。

既存の文脈管理手法との比較では差がはっきり出ました。40タスクの共通サブセットでスライディングウィンドウと汎用要約はいずれも二値スコアを22.50%から15.00%へ落とし、CarryOnの原則を文章要約の形で適用した手法でも20.00%にとどまりました。CarryOnは22.50%を維持しつつ部分スコアを55.93%へ伸ばしており、圧縮の仕方ではなく何を残すかという単位の違いが効いていると読めます。

切除実験も設計を裏付けています。キャリアを取り除くとエージェントの呼び出し回数が23.8%、コストが22.3%増え、過去の結果を再導出する振る舞いが観測されました。実行文脈を外した場合は部分スコアが大きく下がります。494回の確定した畳み込みでは、キャリア観測の80%が新規追加ではなく維持または更新であり、レコードが実際に長く使い回されていることが示されました。

まとめと今後の展望

CarryOnは、長期タスクのエージェントで「履歴をどう圧縮するか」という問いを「進捗をどの単位で保持するか」に置き換えた手法です。成果物を文脈の一級市民として扱い、影響を受けたレコードだけを証拠と環境チェックで更新する設計により、精度とコストのトレードオフを緩めました。

一方で評価規模には注意が必要です。比較と切除実験はOSWorldの40タスク、BrowseCompは100問にとどまり、分散や有意差の検証は報告されていません。全実験が Claude Opus 4.7 単一系列で行われているため、他モデルでの再現性は未検証です。TrackerとCompilerのプロンプトも長く詳細で、プロンプト設計への感度は分析されていません。それでも、エージェントの運用コストが実務上の制約になっている現状に対し、文脈の構造そのものを見直す方向性を具体的に示した研究といえます。

論文情報: "Pack Light, CarryOn: Building Object-Oriented Context for Long-Horizon Agents"(Yuchen Lu, Julian McAuley, Lei Zhang, 2026) arXiv:2610.18784, CC BY 4.0

本記事の図(図1〜図2)とサムネイルは上記論文より引用しています(縮小・形式変換あり)。

シェア:

投稿には GitHub アカウントが必要です。投稿内容は公開され、利用規約に反するものは予告なく削除します。