スライド1枚に画像を差し込む作業を思い浮かべてみよう。AIエージェント（自ら複数のステップを踏んで仕事を片づけるAI）は、画像を入れたプレゼンファイルをすでに保存してある。ところが次の作業を始めるとき、そのファイルを開き直すことはない。代わりに「画像をどう差し込んだか」をやり取りした会話ログから読み直す。
作業が長引くほど、このログは雪だるま式に膨らんでいく。遅くなり、高くつき、昨日確定したことを少しずつ違う形で覚え始める。成果物はファイルにちゃんと残っているのに、である。
CarryOnの発想はシンプルだ。完成した成果物は環境にそのまま置いておき、AIには「それがどこにあり、どんな条件で再び使えるか」だけを引き継ぐ。
従来の手法はコンテキスト（AIが一度に参照する情報全体）を減らしはするが、成果物と少しずつずれていく。大きく二つの流れがある。一つはログを管理する側だ。要約したり、古いものを切り落としたり（スライディングウィンドウ：直近のいくつかだけ残して古いログを捨てる方式）、必要な部分だけ検索して取り出す。もう一つは状態を外部化する側だ。進捗を別のメモや構造へ書き写す。
二つの弱点は同じだ。要約にせよ書き写した状態にせよ、結局は「元を圧縮した説明」である。AISが実際に開いて直す成果物と少しずつ滑っていく。この滑りをドリフト（drift）と呼ぶ。
CarryOnは圧縮した説明を持ち歩かない。完成品は環境にそのまま置き、その位置と再利用条件だけを引き継ぐ。効果は目に見える。論文の図1のスライド編集の例では、一度に参照する情報量は4万2,400トークンまで膨らむが、CarryOnを適用すると1万4,400トークンまで減る（66.0%減）。レポート作業では5万8,400から2万3,500へ（59.7%）減る。ここでトークンとは、その情報の量を数える単位だ。
ある時点で立ち止まってみると、手元にあるのは三つだ。すでに画像が入ったプレゼンファイル、「表紙ロゴは差し替え待ち」「本文フォントは11ptを維持」といった残りの要求とルール、そしてたった今やり取りしてまだ整理していない生の会話。CarryOnはこの三つを、次の担当者へ渡す引き継ぎ書のように扱う。
完成品のファイル自体は環境にそのまま置いたまま、この引き継ぎ書だけが渡っていく。
キャリアが指す「成果」は、必ずしもファイルとは限らない。三つの形がある。再び開けるファイル（外部オブジェクト）、ファイルとしては残らない発見（情報プロダクト）、特定のアプリ・セッションの中でだけ有効な画面状態（状況的ステート）だ。
| 形 | 何か | 例 | キャリアが記すもの |
|---|---|---|---|
| 外部オブジェクト（External Objects） | 環境に独立して残り、再び開いて直せる作業物 | コードファイル、ドキュメント、スプレッドシート | オブジェクトの位置、含まれる進捗、再利用条件 |
| 情報プロダクト（Information Products） | やり取りから得た、ファイルとしては残らない発見 | 統合した情報、問題解決の結論 | 発見内容と根拠の出典、再利用条件 |
| 状況的ステート（Situated State） | 特定のアプリ・セッションの中でだけ有効な進捗 | 開いたままの画面の状態 | 戻る画面や環境、確立した状態、有効範囲 |
CarryOnの鋭いところはここにある。「何を成果物と認めるか」が、そのまま「いつログを捨てられるか」を決める。
まず動き方を見よう。ライブテールが一定量たまると、CarryOnはそれを畳み（この整理の過程を折りたたみ（fold）と呼ぶ）、キャリアと実行コンテキストへ移して、畳んだ区間の元ログを片づける。毎回すべてを書き直すわけではない。変わったログだけ直し、検証を通ればまとめて反映し、失敗すれば既存のログをそのまま残す。
折りたたみには一つのルールが埋め込まれている。成功した整理は、キャリアを必ず1か所以上は書き換えなければならない。実行コンテキストだけをいじっても、元ログは片づけられない。一見ささいなこのルールが実務でどう働くのか、承認された案が差し替えられる状況を最後まで追ってみよう。
色の案のうちA案が「モバイルで読みやすい」という根拠で承認された。キャリアには「現在の確定＝案v1、再利用条件＝A案・モバイル可読性」と記される。画像を何番目にどんな順で入れたかは、ファイルさえあれば捨ててよい。だが「なぜA案なのか」、つまり承認の条件はファイルを見ただけでは分からないので、キャリアに残す。翌日、デザイナーが案をv2に差し替える。こうなるとファイルのバージョンが入れ替わったので、v1に付いていた承認はもう有効ではない。
問題はここで分かれる。キャリアの「確定＝A案」という荷札がファイルの差し替えに合わせて更新されないと、エージェントは無効になった承認をまだ生きていると信じ込み、v2を確定版のように進めてしまう。だからキャリアの再利用条件は、「どのファイルバージョンに対する承認なのか」と「そのバージョンが変われば承認は無効」の両方を含まなければならない。ただし先の「キャリアを最低1か所は書き換える」というルールは、この更新まで保証してくれるわけではない。折りたたみは別のキャリアを書き換えるだけでも成立し、確認されていない候補を飛ばして別の候補だけをいじることもあり得る。バージョン・承認の荷札がファイルの差し替えに合わせて適時に更新されるようにすることは、ルールが強制するものではなく整理モジュールが負うべき責務であり、だからこそ後で見る「条件を誤って記す危険」が残る。
結局、成果物の境界をどこに引くかが、ログをいつ捨てるかを決める。狭く取れば捨てきれないログが積み上がり、広く取れば承認根拠のような微妙な情報まで成果物に押し込まなければならない。どこに引くかは、結局のところ設計者の仕事だ。
OSWorld 2.0はコンピュータを直接操作する課題集だ。同じモデルにCarryOnを付けた場合と付けない場合を、課題をどこまでやり遂げたかと、課題あたりに使ったトークン・コストで比較した。スコアは二種類ある。二値スコアは課題を最後までやり遂げた割合、部分スコアは途中までどれだけ進んだかだ。
| 指標（OSWorld 2.0全体） | ベースライン | CarryOn |
|---|---|---|
| 部分スコア | 43.9% | 49.7%（+5.8%ポイント） |
| 二値スコア | 15.7% | 19.4%（+3.7%ポイント） |
| 課題あたり総トークン | 4,010万 | 1,930万（51.9%減） |
| 課題あたりコスト | $36.8 | $23.6（35.9%減） |
「課題あたり総トークン」は一度に読む量ではなく、作業全体で読み書きした量の合計だ。CarryOnの$23.6は、エージェントが実際の作業に使った$20.51に、コンテキストを整理するのに使った$3.11を足した値であり、総トークン1,930万のうち整理分は69万だ。管理コストを足してもなお、トークンは半分に、コストは3分の1以上減った。
設定メモ：本体エージェントと、CarryOnの整理モジュール（Tracker・Compiler）には、いずれもClaude Opus 4.7を使った。課題あたり最大500ステップを許容し、スコアは公式の方式どおり部分・二値を併せて報告する。効率はエージェントが使った量だけでなく、整理の呼び出しが追加で使った量まで併せて数えた値だ。
検索課題でも精度は上がり、トークン・コストは減る。BrowseComp-Plus（ランダム100問、Qwen3-32Bモデルが公式基準で採点）では精度が49.0%から56.0%へ（+7%ポイント）上がり、総トークンは22.9%、総コストは7.1%減った。コスト削減幅がOSWorldより小さい理由ははっきりしている。検索課題は課題あたりのトークン規模そのものが小さく（ベースライン156万に対し4,010万）、整理の呼び出しが占める比重が相対的に大きいのだ。
削減は作業が長引くほど積み上がる。論文の図3では、ベースラインのコンテキストは作業の間じゅう伸び続けて20万トークンを超えるが、CarryOnの平均入力コンテキストはおよそ6万5,000トークンで止まる。コスト曲線は最初こそ整理の呼び出しのぶん多くかかるが、やがてベースラインと交差し、ターン500では整理コストまで含めた累積コストを34.1%削減する。
同じ成果物中心の原理を、要約の中にだけ入れるのと、作業の間じゅう維持・管理するのとでは、結果が違う。40課題の共有セットで五つの方式を突き合わせた。
| 方式 | 折りたたみ後のテキスト長（k文字） | 二値（%） | 部分（%） |
|---|---|---|---|
| ベースライン | – | 22.50 | 50.32 |
| スライディングウィンドウ | 12.08 | 15.00 | 37.41 |
| 一般要約（GS） | 17.60 | 15.00 | 44.94 |
| CarryOn式ガイド要約（CGS） | 23.94 | 20.00 | 50.93 |
| CarryOn | 21.54 | 22.50 | 55.93 |
「折りたたみ後のテキスト長」は一度整理した直後に残った分量で、先の「総トークン」（作業全体で読み書きした量）とは別の数値だ。このセットのベースラインスコアも、全体ベンチマークとは母集団が異なるため、上の主要結果と直接比較してはならない。
観測された結果はこうだ。ログを積極的に圧縮するスライディングウィンドウと一般要約はコンテキストを最も短く保つが、必要な情報まで一緒に捨ててしまい、スコアがベースラインを下回る。成果物中心の原理を要約テキストにだけ適用したCGSは、部分スコアを50.93%まで上げた。ところがその構造を作業の間じゅう維持した完全なCarryOnは55.93%とさらに高く、整理直後に残った分量はむしろ短かった（21.54k文字に対し23.94k文字）。
設計上の違いがここから生まれる。CGSは折りたたむたびに要約を丸ごと書き直して差し替える。CarryOnは同じ成果物のログを複数回の折りたたみにまたがって「維持」しながら、変わった部分だけを直す。実際、検証を経て反映された整理の前後で、キャリアのログの80%がそのまま維持されるか更新される。
解釈は慎重に行うべきだ。スコアが上がったのは、毎回書き直す過程での情報損失を減らせたからかもしれないが、この設計はドリフトを直接測ってはいない。成果物中心が要約より滑りにくいという主張は、課題スコアで間接的に裏づけられるにすぎない。確かめるには、エージェントが先の結果を探し直したり制約を取りこぼしたりする頻度を別に数えてみる必要がある。
キャリアと実行コンテキストは互いの代わりにはならない。片方ずつ切ってみると分かる。実行コンテキストを隠すと、二値スコアが22.50%から17.50%へ、部分スコアが55.93%から44.00%へ下がる。エージェントの呼び出し回数はほぼそのままだ。完成した成果物は依然として見えるのに、目標・制約・残りの要求が消えて作業を締めくくれない。
キャリアを隠すと逆に動く。部分スコアが44.62%まで下がり、呼び出しが23.8%、コストが22.3%増える。すでに積み上げた進捗にすぐ届かず、先の結果を取り戻すか作り直すかしているように見える。それが「取り戻し」なのか「作り直し」なのかは、この数値だけでは判別できない。
折りたたみ1回は四つの段階で回る。
ONTLEは小規模事業者と一人起業家の反復業務を軽くするAI PM派遣型サービスだ。AI PMが「3日がかりの新製品紹介ページ制作」のように何日もかかる課題を担うと、先のスライドの問題がそのまま再現される。確定した文言のファイルは開き直さず、間延びした過去の会話だけを読み返す、という具合だ。CarryOn式なら、確定文言・公開した案・承認された色設定がそれぞれキャリアとなって引き継がれ、修正の過程は畳まれて抜ける。
入れるかどうかは二つで見極める（まだ適用前の仮定だ）。
一つめ、ファイルが差し替わるとき、承認条件も併せて更新されるか。先に見た案の差し替えがそのまま業務で起こる。古い承認が新しいファイルに誤って貼りついてしまえば、削減は品質を削る。
二つめ、やり直しと総コストが実際に下がるか。PMがすでに終わったことをやり直したり守るべき制約を取りこぼしたりすることが導入の前後で減り、整理コストまで足した総コストが下がらなければならない。
検討する人が自ら投げかける問いは三つに絞られる。自分の作業は再び開ける成果物を残すのか、それとも全部が会話の中だけで生きているのか。その成果物が「どんな条件で有効か」までキャリアに記されるか。そしてこの作業は、折りたたみのコストを取り戻せるだけ長いか。
いまの実装では、成功した折りたたみは直近のログ全体を一度に覆う。一部だけ畳む戦略はこの論文の範囲外だ。
いいえ。この検証は整理の過程が矛盾したり根拠のない内容で汚染されたりするのを防ぐ装置にすぎず、課題の正解かどうかは見ない。課題レベルの検証は別に用意しなければならない。
情報プロダクトのキャリアに、発見内容と根拠の出典、再利用条件を記しておく。整理のとき、記した内容が元の出典と合うかを確認する段階を経る。