論文解説: Terminal-Universe — エージェントの作業ログを、何度でも使える実行環境に戻す

エージェントの作業ログ（軌跡）に残ったファイル操作をリプレイし、欠けた部分を補完エージェントに埋めさせて実行可能なワークスペースを復元する枠組み。37.3kの環境を作り、Qwen3.5-27BのSFTでTerminal-Bench 2.1を+11.9ポイント改善した。

Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments

録画は1回きり、スタジオは何度でも使える

撮影が終わった映画を考えてください。手元に完成した映像1本しかないなら、できるのは「観る」ことだけです。演技が下手でも撮り直せません。一方、セットと機材が残っているスタジオがあれば、同じ台本を別の役者で撮り直せますし、違う脚本を持ち込むこともできます。

ターミナル上のコーディングエージェントにも同じ対立があります。エージェントの作業記録（軌跡 / trajectory）は公開データセットとして大量に溜まっている一方、実際に動かせる環境（environment）はいつまでも足りません。軌跡は完成映像、環境はスタジオです。

今回読むのは「余っている完成映像から、スタジオの方を復元してしまう」論文です。原題は "Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments"（arXiv:2609.04148、Qwen Team / Alibaba Group ＋ 清華大学、2026年9月3日公開）。

要旨を日本語にするとこうなります。ターミナル型エージェントの普及で軌跡は大規模に蓄積されたが、現実的で実行可能な環境は依然として希少である。しかしポストトレーニングが実際に必要としているのは環境の方だ——環境は何度でも別のタスクに問い直せて実行フィードバックを返すのに対し、軌跡は凍結した1本のデモにすぎない。著者らは、軌跡に残るツール実行履歴が、それが走った環境の構造と内容を露出させている点に着目する。Terminal-Universe は、記録されたファイル操作をリプレイしてエージェントが手を入れる前の状態を復元し（部分的なワークスペース）、補完エージェントが不足ファイルと依存関係を補う。その上で元の意図タスクを再構成し、新しいタスクも合成し、さらに幅（複数コードベースにまたがるクエリ）と深さ（複数ラウンド化）の2軸へ拡張する。公開軌跡から37.3kのタスク十分な環境を生成し、Qwen3.5-27BのSFTで Terminal-Bench 2.1 を11.9ポイント、EvoCode-Bench v2 MT@4 を13.8ポイント改善した。

軌跡と環境は、資源としての格が違う

論文の出発点は明快です（§1）。軌跡は固定された1本の記録で、その品質はそれを生成したポリシーモデルの応答に上限を縛られる。しかも加えられた変更が正しかったのかを後から確かめる手段がない。環境にはその制約がありません。同じタスクをより強いモデルに解き直させられ、結果を自前のテストで検証でき、同じワークスペースにもっと難しいタスクを載せられる。だからスケールさせる価値があるのは環境の方だ、と。

既存手法は3ルートに整理されます（§1, §2）。リポジトリ由来は、実在リポジトリのgit履歴でバグ修正直前までロールバックし、当時のバグ報告をタスク、付随テストを検証器に流用する。摂動は健全なリポジトリにわざとバグを注入して直させる——少数のリポジトリから多数のタスクが作れるが、どれも修理タスクになる。タスク条件付き合成はタスクと環境をゼロから同時生成する。カバレッジは制御できる反面、環境がどの実プロジェクトにも紐づかないため現実味が生成器頼みになり、実際のコードというより小さくて小綺麗なワークスペースが出来がちだ、と論文は指摘します。どのルートも既存環境から出発するか、新規タスクと一体で環境を作るかのどちらかで、軌跡を「環境の観測記録」として使う道は手つかずでした。

発想の転換: ツール呼び出しは環境を漏らしている

軌跡に記録されたツール呼び出しは、環境の中身をすでに暴露しています。Read はファイルの中身を見せ、Write と Edit はワークスペースの変化を見せる（§1）。これだけあれば実行可能なコピーを組み直せる、というのが中心アイデアです。復元は3段階で進みます（§3.1）。

記号を1つずつ。$\tau$ は記録された軌跡。$E$ はその軌跡が実際に走っていた本物の環境で、手元にはありません。$\widehat{E}_{0}$ はリプレイだけで得られる部分的なワークスペース、$\widehat{E}$ は補完後のワークスペースで、これで $E$ を近似します。論文はこの復元が本質的に損失を伴う（lossy）と明言します。アクセスされなかったファイル、暗黙のシステム依存、外部ネットワーク資源は軌跡に痕跡を残さないからです。

Stage 1（決定的リプレイ）は、read / write / edit を時系列に処理し、触れられた各パスについて「軌跡上で最初に観測された版」を集めます。エージェント自身が作ったファイルは除外し、その変更は検証用に別置きする。こうしてワークスペースは未解決の状態から始まることが保証されます。

# 軌跡τのファイル操作を時系列で処理し、「エージェントが触る前」だけを集める
initial = {}
for op in sorted(trajectory.file_ops, key=lambda o: o.time):
    if op.path in created_by_agent:      # エージェントが作ったファイルは入れない
        continue
    if op.path not in initial:           # 最初に観測された版だけを採用
        initial[op.path] = op.content_before
agent_edits = collect_changes(trajectory)  # 後の検証用に別置き

軌跡が見せるのはエージェントが触ったパスだけで、ファイルの一部しか表示されていないことも多い。だから $\widehat{E}_{0}$ は必ず穴だらけになります。

4つの「問い直し」で環境を絞り切る

復元しただけでは環境の潜在能力は使い切れません。論文は再クエリを4種類用意します（§3.2）。Intent Recovery（元タスクの復元）、Single-WS（1ワークスペース内で新タスク合成）、Cross-WS（関連ワークスペースをつなぐ「幅」）、Multi-Round（対話に伸ばす「深さ」）。

このうち Cross-WS の入口が近傍探索です。エージェントが各ワークスペースの技術領域と実装済み能力をプロファイルし、TF–IDF の最近傍探索で候補ペアを引き、LLM判定器が「参照側にあり対象側に欠けている能力」という方向付きの依存辺を認定します。上位に何が来るかは類似度の測り方で変わります。