コマンドを一つ実行する。赤いエラーが出る。原因を突き止めてコードを一行直す。もう一度実行する。今度は別のところで引っかかる。ログをさかのぼって設定を変え、また走らせる。開発であれデータの整理であれ、実際の仕事はたいてい、この「確認して直してまた実行する」の繰り返しで最後までたどり着く。
こうしたことがすべて起きる画面がターミナルだ。文字でコマンドを打ち込んでコンピュータを操作する画面である。そして、コマンドと結果と次のコマンドが次々と連なっていくこの作業の記録全体を「軌跡（trajectory）」と呼ぶ。人でいえば、問題を解いている間に書きためた作業日誌に近い。
アリババAMAPと中国科学技術大学（USTC）の研究チームは、この軌跡に注目した。ターミナルで働くAIエージェントを、短いデモを超えて数時間規模の実務までこなせるようにするには、何を変えればいいのか。彼らの答えはこうだ。エージェントを教えるうえで大事なのは「どんな課題を解けたか」ではなく「どんな軌跡を見て学んだか」である。ところが、いま公開されている学習用の軌跡はたいてい短すぎる。そこでチームは、長い軌跡を自動的に生み出すエンジン、TerminalHorizonを作った。
まずはっきりさせておきたいことがある。記録が長いからといって、学ぶものが多いわけではない。
短い軌跡は、コマンドを打ってツールを呼ぶやり方は見せてくれる。だが、エージェントが仕事を実際にどうやり遂げるかまでは収められない。手がかりを集め、判断を下し、フィードバックを受けて戦略を立て直し、中間の成果を最終的な成果物へと変えていく過程のことだ。長い作業では、こうした振る舞いが一つ二つのステップではなく、幾段にもわたって現れる。
とはいえ、長ければすべて良いわけでもない。軌跡が長くなる理由は二つに分かれる。一つは無駄な再試行だ。同じミスを繰り返したり、迷ったりして記録ばかりが膨らんだ場合である。もう一つは本物の依存だ。前の段階で観測したものが次の判断を変えるために、段階どうしが噛み合って長くなった場合だ。前者は取り除くべきノイズであり、後者こそエージェントに学ばせたい能力そのものである。
もっと厄介な落とし穴もある。環境を自動で作っていくと、肝心のエージェントが解くべき核心の作業を、環境が先に解いてしまうのだ。たとえば「注文ごとの返金額を合算する関数を実装せよ」という課題を出したとしよう。ところが環境の中にすでにその合算関数が入っていると、エージェントがやることは数値定数を一つ書き換える程度にまで縮んでしまう。見た目は複雑でも、意図していた探索も実装も検証も起きない。軌跡が長く見えても、中身がないのだ。
だからデータを見るときに投げかけるべき問いは「この軌跡は長いか」ではなく「なぜ長くなったのか」だ。本物の依存のためなのか、それとも環境が作り込まれていなかったか、エージェントが迷ったためなのか。TerminalHorizonは、この区別をデータを作る段階から強制する。
問題を出した本人は、自分の問題の穴が見えにくい。もう答えを知っているからだ。試験問題を作った教師は、「これは問題文を見ただけで答えが出てしまうな」と思えるような設問を、自分では弾けない。その穴は、問題を知らない人に先に解かせてみて初めて露わになる。
TerminalHorizonは、このやり方をそのまま使う。課題を作った側ではなく、その課題をはじめて見る第三者のエージェント（「独立チャレンジャー」）に実際に解かせてみる。そして「あまりに簡単に解けてしまった」区間を逆向きにたどり、環境を作り直す。エンジンは二つの段階を回る。先ほど取り上げた返金合算関数の課題を、最後まで追ってみよう。
まず課題を一つ作る。三つのエージェントが順に手を加える。プランナーが、まだ扱われていない振る舞いを引き出せるテーマを決める。ディープリサーチエージェントが、実際のドキュメントやコードリポジトリ、イシューを漁って、現場の要求と制約、そして「何をすれば完了とみなすか」の根拠を集める。構築エージェントが、それを実行可能な課題へと組み立てる。組み立てられた課題には、公開される指示文、エージェントが操作する実行環境、参照用の正解解法、そして表には見えない採点器（正解かどうかを自動で判定する仕組み）が含まれる。エージェントは公開された部分だけを見て、環境を手探りしながら解く。
課題を作ったあとは、正解解法も採点器も隠したまま、独立チャレンジャーに公開された指示文だけを渡して解かせてみる。その解法の記録をもとに問い詰める。エラーが出たか、見せてはいけない情報が漏れたか、採点が意図とずれていないか。そして最も重要なのは、そもそも意図した核心の作業が課題の中に生き残っているか、である。
返金合算関数に戻ろう。チャレンジャーが関数を自分で書かずに通過してしまったなら、それは環境がすでにその関数を提供しているというサインだ。研究チームはこうして「あまりに簡単に解けてしまった区間」がどこから来たのかを洗い直す。最初に敷いておいた資料のせいなのか、あらかじめ作っておいたツールの挙動のせいなのかを追跡するのだ（論文はこの作業を「ホライズン間隙分析」と呼ぶ。ホライズンとは一つの作業を終えるまでの長さ、つまり作業の息の長さを指す）。
ここで二つの場合を混同してはいけない。エージェントが効率よくうまく解いて短く終わったものは、そのままにしておく。環境が先に解いてしまって、やることが消えたものだけを選んで直す。返金関数でいえば、環境が抱え込んでいた完成済みの関数を取り除き、エージェント自身に書かせてデバッグさせる。ただし、その作業をするための公開仕様は残す。直した課題はふたたびチャレンジャーに解かせ、よみがえらせた作業が今度は実際の解法過程に入ってくるかを確認する。
通過した課題は終わりではなく、出発点だ。進化エージェントが、同じ目標を保ったまま課題を育てる。ルールは一つ。新しく付け足した要求が、既存の解法でそのまま通過してはいけない。必ず追加の分析か実装、検証を呼び込まなければならない。
返金合算関数をもう一度取り出そう。第1段階を通過したその関数に、例外入力の処理を要求として上乗せする。返金額が空だったり、負の数のように範囲を外れた値が混ざった注文だ。先に書いた解法は正常な入力しか処理していないので、そのままでは通過しない。エージェントは先に書いた関数を走らせてみて、例外入力で落ちる箇所を目で確認したうえで、どこを直すかを決める。先の実行結果が次の修正を決めるのだ。
育てる方向は四つあり、どれもこの関数一つで描いてみせることができる。
どの方向であれ、追加の作業が先の作業に寄りかかるように設計する。実行するたびに扱う値が変わるようにすることもある（論文はこれを「インスタンス変異」と呼ぶ。暗記した答えが通用しないようにする仕掛けだ）。こうして同じ振る舞いのパターンが、一つの軌跡の中で幾段にもわたって続く。通過した拡張課題は、ふたたび次の拡張の親になる。
流れは四段階だ。課題を生成し → そこから出た解法の記録をふるいにかけて選び → その記録でモデルを学習させ → ベンチマークで性能を評価する。
学習には、強い「教師モデル」の解法を選び、より小さな「ベースモデル」にそのまま真似させる教師あり学習（SFT、模範解答を見せながら真似させる最も基本的な学習）を使った。こうして大きなモデルの解法を小さなモデルに移し替えるやり方を「蒸留」と呼ぶ。その成果物がTerminalHorizon-27Bである。
課題ごとに軌跡を二つずつ取り、三つのフィルター（付録F）にかけて最終的に2,852個を残した（名前はTerminalHorizon-3K）。学習の前には、評価用の問題が学習データに混ざらないようにふるい分ける汚染除去も行った。
データが実際に長く多様であることは、数字に表れる。領域はチップ・物理・天文を含む25の専門分野を、一つのターミナル形式に収めた。長さはどうか。いくつかのオープンソースの合成手法から課題を300個ずつ取り、同じ教師・同じ設定で走らせて比較したところ、TerminalHorizonの軌跡の平均インタラクション長は52.8ターン、上位10%は98ターンと、比較群を大きく上回った。ターミナルのフィードバックに途切れず続いた「最も長い連続行動の鎖」の中央値は25ターンだった。長く進む間、行動とフィードバックが細切れにならず噛み合っていたということだ。
結論から見よう。このデータで学習したTerminalHorizon-27Bは、12個のベンチマークすべてでベースモデルのQwen3.5-27Bを上回った。とりわけターミナルを直接扱うコーディング課題で幅が大きかった。Terminal-Bench 1.0・2.0・2.1でそれぞれ+8.7、+14.2、+13.85ポイント上がった。長い軌跡で学んだことが、ターミナル課題そのものをより上手に解かせたというサインだ。
一方で実務の自動化は事情が違う。AutomationBenchの通過率は5.5%から17.2%へ跳ね上がった。上がり幅は確かに大きい。だが、上がりついた先が17.2%だという点はそのまま受け止めるべきだ。この課題を最初から最後まで完遂する割合は依然として低い。長い実務作業がそれだけ難しいということであり、向上幅だけを見て「もう使える」と言える段階ではない。
推論力は削られなかった。MATH-500、GSM8K、AIME、KOR-Benchのいずれも下がらず、むしろ小幅に上がった。エージェントの能力を伸ばしながら、基本の推論を犠牲にしなかったのだ。ただしMATH-500とGSM8Kはベースのスコアがすでに天井に近く、上がり幅自体の意味は小さい。
データ量を他の手法と突き合わせると、絵柄がさらにはっきりする。同じベースモデル、同じ実行枠組みを使うTerminal-Universe-27BはTerminal-Bench 2.0で52.8%、TerminalHorizon-27Bは55.8%と3.0ポイント上回る。ところが学習に使った軌跡の数が違う。Terminal-Universeは32.0k、TerminalHorizonは2,852個で、10分の1にも満たない。
ここで観測できるのは「少ない軌跡でより良いスコアが出た」までだ。それ以上は慎重に読む必要がある。軌跡の数だけでは、学習量全体やデータ制作コストまでは比較できない。だから「とにかく少なくてよい」ではなく、「長い軌跡の密度が、軌跡の数をかなりの部分まで肩代わりした」くらいに読むのが妥当だ。
まとめると、この実験ではっきり言えることは一つだ。長い軌跡を選んで真似させたら、ターミナル課題の性能が上がり、基本の推論は保たれた。まだ切り分けられていないことも明らかだ。このモデルは強い教師の解法をふるって真似た蒸留モデルなので、スコアが上がった手柄をデータ設計と教師の実力のどちらに帰すか、きれいに分けられない。長さが押し上げたのか、行動の多様性が押し上げたのか、教師の品質が押し上げたのかも、まだ切り離せていない。これを切り分けるには、同じ教師で作った短い軌跡と並べて比べる追加の対照が必要だ。
著者たちが挙げた限界に加えて、読む側として押さえておく点がある。
合成環境は、どれほど精巧でも現実の雑多さをすべて写し取れるわけではない。独立チャレンジャーで穴を埋める設計は賢いが、課題を出す教師も、それをはじめて解いてみる独立チャレンジャーもLLMだ。ただし成否を分ける採点器は、課題ごとに別々に付く非公開の検証器で、正解かどうかを自動で判定する仕組みにすぎず、LLMではない。軌跡を覗き込むLLM審査者（付録F）はさらに別物で、最終的な報酬も成否も入力として受け取らない。それでも、課題を作って解いてみるこれらのLLMが同じ盲点を共有すれば、その盲点はふるい落とされずデータにそのまま残る。おまけに「実行と採点が可能でなければならない」という制約そのものが、採点器できれいに判定できる種類の問題の側へデータを偏らせかねない。ベンチマーク全般の均等な向上が、本当に「長い軌跡の経験」が移った結果なのか、それとも高品質・高難度のデータなら当然ついてくる効果なのかも、さらに問い詰めなければ切り分けられない。
スコアでは測れないものもある。ベンチマークは決まった課題の束での成功を測るだけで、実運用の果てしない変奏や長時間の安定性までは保証しない。その隙間を埋めようとする仕掛けがRSI（再帰的自己改善）の事例だ。課題ごとに12時間の研究時間を与え、モデルが最初に思いついた解法にとどまるのか、それとも実験を続けて手法を直していくのかを見る。付録の「2048戦略最適化」のように、スコアを最後まで引き上げなければならない課題がここで使われる。
ここで見るべきは「何回やり直したか」ではない。核心は、先の結果が次の行動を実際に変えたか、だ。単なる再試行は、同じ戦略を条件だけ少し変えてまた走らせることだ。フィードバックに基づく修正は、前の実行から出たスコアや失敗のサインを読み、それを根拠に戦略そのものをひねって次の実行に反映することだ。両者は見た目の長さが似ていても、性格が違う。平均スコアには還元されないこの「長く働く能力」を定性的に見ようとする仕掛けなので、解釈も定性的に受け取るのが妥当だ。
一つの場面に絞って見てみよう。小さな会社の社長がONTLEのAI PMに任せる。「先月の仕入先の精算内訳と自社モールの注文データが合わないんだけど、原因を見つけて合わせてくれ」。コマンド一行で終わる話ではない。二つのシステムからデータをそれぞれ取り出して洗い、どこでずれているのか仮説を立て、突き合わせのスクリプトを書いて走らせ、数字がおかしければ元データに戻って掘り、合わせた結果を社長が開いて読めるレポートに仕上げる。幾段もの段階が噛み合った長い作業だ。
この業務の核心は途中で起きる。突き合わせのスクリプトを走らせたら、ある仕入先の3月の精算額が注文合計より大きく飛び出している。よく学んだエージェントなら、ここで止まらない。そのずれた数字が、次に何を調べるかを変える。返金分が精算に反映されているか、日付の境目で注文が二か月にまたがったか、単位が混ざっているかを新たに掘り下げる。ずれた数字を見つけた結果が、次の調査対象を決める——これこそ論文がいう「本物の依存」だ。
ONTLEのAI PMは、すでにこうした多段階の業務を引き受けてこなしている。ここから持ち込むのは結果モデルではなく、方法だ。だから試行として検証してみる問いを最初に定めておく。「短い軌跡で学習したモデルは、こうした異常のサインをより頻繁に見逃すのか」。これを確かめるには、評価の目を最終的な数字から過程へと移さなければならない。精算の突き合わせのように中間の結果が次の段階を左右する業務では、エージェントが異常のサインに出くわしたとき、その根拠を実際に確認したか、そして必要なら判断を変えたかまでを記録で見る必要がある、ということだ。
ただし「途中で何かを修正したか」を数えるだけでは足りない。それでは一度で効率よくうまく解いた場合まで「修正しなかったから悪い」と削られてしまう。この落とし穴は論文の第1段階の区別とそっくり同じだ。だから最初の試行は、精算の突き合わせという一つの業務に絞る。課題を投げて「通過／失敗」だけを見る代わりに、その課題をはじめて見る別のエージェントにまず解かせてみて「どこで簡単に解けすぎたか」を逆向きにたどる手順を、評価パイプラインに組み込むことから始める。
学習方式を最も単純な側に固定したからです。SFTは「模範解答をそのまま真似た」結果だけを残します。強化学習のように学習の途中で自ら戦略を変える要素を外したわけで、学習手法そのものの賢さが性能に紛れ込む余地を減らします。ただしSFTを使ったからといって「データの質」という変数一つだけがくっきり切り離して観察できるわけではありません。教師の品質、軌跡の長さ、データの構成、学習トークン量がまとめて絡み合っており、この論文の実験もそれらを分離して立証してはいません（本文の「結果」「どこまで信じられるか」で指摘した限界のとおりです）。SFTの固定は「学習手法」という一つの軸を単純に束ねておくだけで、データ側の変数まで覆い隠してくれるわけではありません。
長い軌跡は一件あたりに処理するトークンが多く、件あたりのコストが余計にかかります。この論文の反論は、件数を減らしたという側です。件あたりのコストが大きくなる代わりに、件数が10分の1以下に減って相殺する余地がある、というわけです。ただし学習量全体や制作コストまで公開して比較されたわけではないので、実際の損得は自分の環境で検討する必要があります。
原理は、環境を自動生成するどんな作業にも移せます。ただし、前提が一つあります。課題が実行され、自動で採点されうることです。そうであってこそ独立チャレンジャーに解かせてみて「簡単すぎるところ」を選り分けられます。採点が曖昧な領域（たとえば文章の品質）では、同じ枠組みをそのまま使うのは難しいです。