1. 短い作業記録では、「調べて、判断して、直す」流れが学べない

ターミナルエージェントとは、コマンドラインを操作して、ファイルの編集、プログラムの実行、結果の確認を自分で進める AI である。abstract は、こうしたエージェントが手元の操作を超えて、実際の専門業務を仕上げる方向へ進んでいると書く。[1]

仕事を任せるなら、必要になるのは個々のコマンドの使い方だけではない。まず状況を調べて手がかりを集める。集めた手がかりから判断する。結果を見て進め方を変える。途中の成果を、最終的な成果物にまとめる。著者らは、短い作業記録（trajectory）ではコマンドや道具の呼び出しは示せても、この一連の流れまでは十分に示せないと指摘する。

そこで長い作業記録を学習データにしたい。ところが、長い作業を練習させる環境（課題と、作業に使うファイルや道具の一式）を自動で作ると、別の問題が起きる。環境を作る段階で、本来エージェントがやるはずだった肝心の作業が、先に済まされたり単純にされたりしてしまう。そうなると探索も実装も検証も要らない課題になり、長い記録を集めても、学ばせたかった行動は入っていない。abstract が問題にしているのはこの点である。

2. 提案の芯は「環境が先に片づけた作業を、実行して見つけ出す」こと

TerminalHorizon は、長い作業をこなすターミナルエージェント向けの学習データを、全自動で作る仕組みだとされる。出発点は、実際の専門業務である。

この記事では、仕組みの芯を「独立した実行による点検」と見る。作った環境で、別に課題を実行してみる。すると、環境を作る途中で抜け落ちた作業や、先に済まされてしまった作業が見えてくる。その証拠をもとに、環境を作り直す。課題文を読んで難しさを推し量るのではなく、実際に動かして、やるべき仕事が残っているかを確かめる設計である。

もう一つの工夫は、課題の段階的な拡張である。同じ目標のまま、前の段階の結果を土台にした新しい要求を足していく。新しい要求は、さらに調べ直したり、作ったものを改めたりしないと満たせないように作られる。これによって、調べる・判断する・直すという行動の型を、一つの課題の中で何段にもわたって続けさせる、というのが著者らの説明である。独立した実行を、どのモデルが、どの手順で担うのかは、abstract の範囲では示されていない。

3. abstract の範囲で示されたこと

読むときに注意したい点がある。「大きな性能向上」は abstract の言葉であり、向上の幅、比較の相手、ベンチマークの名前は書かれていない。比較の相手が微調整前の同じモデルなのか、ほかの学習データで微調整したモデルなのかで、この結果の意味は大きく変わる。事例研究についても、成功をどう判定したか、何件のうち何件で起きたかは示されていない。

4. 具体例で見る ── 「集計表を最新データで作り直す」課題

長い作業の課題を自動で作るとき、どこで肝心の作業が抜け落ちるのか。製薬の実務に近い一例で見る。作業環境には臨床試験の集計プログラムと元データが置かれ、課題は「最新のデータで集計表を作り直し、前回版との違いを説明する文書をまとめよ」というものとする。

肝心の作業が先に済んだ環境

環境を作る段階で、データ形式の違いはすでに整えられ、集計プログラムも新しいデータで動くように直されている。エージェントはプログラムを実行して表を出力するだけで課題を終えられる。記録は長くならず、仮に長くなっても、調べる・判断する・直すという行動は含まれない。

独立した実行で点検し、作り直した環境

課題を別に実行した結果、「形式の違いを見つけて直す」作業が残っていないことが分かる。環境は、形式の違いが残った状態に作り直される。エージェントはまずデータを調べ、プログラムが失敗する原因を突き止め、直してから集計する。次の段階では、前回版との違いを説明するという新しい要求が足される。

これは TerminalHorizon の考え方を当てはめた説明用の例であり、論文が実際にこの種の課題を扱ったかどうかは abstract の範囲では分からない。示したいのは、課題文が同じでも、環境の側に作業が残っているかどうかで、集まる作業記録の中身が変わるという点である。

5. 何が新しくないか、どこに限界があるか

エージェント用の課題環境を自動で合成し、そこで集めた作業記録で微調整するという流れ自体には、すでに多くの研究がある。同じ週に公開された ProgramGym も、リポジトリから検証できる訓練環境を作る仕組みを提案している。[3] 実行して確かめた結果を環境づくりに戻す発想も、テストを走らせて課題の質を確かめる手法として使われてきた。ターミナル作業の評価でも、Terminal-Bench のように、実際の業務から取った課題ごとに環境と自動テストを用意するベンチマークがある。[4] ただし、TerminalHorizon の評価に使われた 12 のベンチマークに何が含まれるかは、abstract には書かれていない。この論文の寄与は、「環境が肝心の作業を先に片づけてしまう」という失敗の形を名指しし、それを独立した実行で見つけて作り直す手順と、同じ目標のまま課題を段階的に広げる手順を組み合わせた点にあると読める。

限界は abstract の範囲でもいくつか見える。第一に、性能向上の大きさと比較の相手が示されていない。第二に、12 のベンチマークの内訳が分からないため、学習データの課題と評価の課題がどれだけ近いかを判断できない。両者が同じ種類の業務なら、向上の一部は課題の近さで説明できてしまう。第三に、独立した実行が「抜け落ちた作業」をどの程度正しく見つけるのか、見落としはどのくらいあるのかが示されていない。

第四に、事例研究は能力の例示であって、成功の頻度を示す評価ではない。第五に、データやモデルを公開するかどうかも abstract には書かれておらず、収集時点では GitHub のリポジトリも登録されていなかった。再現できるかどうかは、現時点では確かめようがない。

6. この主題はなぜ束になっているか ── 「訓練環境をどう作るか」への関心

この記事が拠る選定の仕組みでは、同じ問いに対して独立した論文が短い期間に重なって出てくる「束」を、主題が立ち上がった目印として重く見る。今回の束の大きさは 2 で、もう一本は ProgramGym である。[3]

束を作ったキーワードは、long-horizon（長い作業）、environments（環境）、scaling（規模の拡大）、training（学習）などである。ProgramGym は、参照となるプログラムを調べてから一から作り直す課題を対象に、検証できる訓練環境をリポジトリから大量に作るとしている。対象はターミナル作業とプログラムの再現で違うが、どちらも「長い作業を学ばせたいが、それに見合う訓練環境が足りない」という同じ問いに答えようとしている。モデルそのものの改良ではなく、モデルを鍛える環境の作り方に関心が向いている、という読み方ができる。

Hugging Face の Daily Papers での upvote は 132 だった。[2] これは研究者の目に留まったことを示す数字であり、主張が正しいことや、結果が再現されたことを示すものではない。束も 2 本と小さく、主題として育つかどうかは今後の追随を見る必要がある。

7. 製薬・規制の現場から見ると

製薬の現場にも、ターミナルやスクリプトを使う長い作業は多い。臨床データの集計プログラムの改修、解析環境の更新、当局へ提出するデータ一式の整備などは、調べて、判断して、直して、最後に成果物にまとめるという流れそのものである。こうした作業をエージェントに任せるなら、そのエージェントがどんな課題で鍛えられたかは、性能の数字と並んで確かめるべき情報になる。

この論文が名指しした失敗の形は、評価する側にもそのまま当てはまる。社内でエージェントを試すとき、試験用の課題を作った人が前処理を済ませてしまえば、エージェントは肝心の作業をしないまま合格する。導入前の確認では、課題の中に「本当にやらせたい作業」が残っているかを、課題を作った人とは別の人が実行して確かめる必要がある。コンピュータ化システムのバリデーションで、試験の作成者と確認者を分ける考え方と同じ方向を向いている。

もう一つの論点は、長い時間をかけて自分で実験を続け、方法を改めるという振る舞いである。研究の探索には役立ちうるが、GxP の範囲で使うなら、いつ、何を、なぜ変えたかを後から追える記録が前提になる。abstract は、効いた改善を最終成果物に残せると書くが、その過程をどう記録するかには触れていない。導入を考える側は、成果物だけでなく、過程の記録の形を先に決めておく必要がある。