論文解説: StateM — モデルの重みを1gも動かさず、Terminal-Bench 2.1で95.3%・実行費15ドルへ

長時間タスクのエージェントは、各ステップを解けるモデルを積んでいても落ちる。StateMは重みを触らず「実行の器」だけを鍛え、Terminal-Bench 2.1で95.3%、最終スコアのAPI費を574.68ドルから約15ドルへ下げたと報告する。ハーネススケーリングという賭けを1から解説する。

StateM: Reaching 95.3% Raw Accuracy, or a \$15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling

一段ずつは解けるのに、通しでやると落ちる

3時間かかるコース料理を思い浮かべてください。「玉ねぎを刻む」「弱火で炒める」「30分煮込む」— 工程を1つずつ取り出せば、料理をしたことがある人なら誰でもできます。それでも初めて通しで作ると、たいてい失敗します。塩を入れたかどうかを忘れる。前回焦がした教訓を思い出さない。店の定番手順を1つ飛ばす。そして「まあこんなものだろう」と早めに火を止める。

この論文が出発点に置いているのは、まさにこの構図です。長時間タスク（long-horizon）のエージェントは、構成要素である各ステップを解けるモデルを積んでいても失敗しうる（概要）。論文が名指しする失敗の型は4つあります。

1. 可変な状態を見失う（mutable state を追えなくなる）
2. 前の実行で得た教訓を再活性化できない
3. 既知の手順を飛ばす
4. 早すぎる段階で止まる

並べてみると、どれも「知識が足りない」種類の失敗ではありません。知っているのに、実行の管理ができていない種類の失敗です。料理人の腕ではなく、厨房の段取りの問題だと言ってもいい。

ここが重要な分岐点になります。もし失敗の原因が知識不足なら、打ち手はモデルを賢くすること — 追加学習、強化学習、より大きなモデル — しかありません。しかし原因が段取りにあるなら、モデルを一切触らずに直せる可能性が出てきます。

ハーネススケーリング: 重みではなく「器」を鍛える

論文はこの賭けをはっきり言葉にしています。原文は "We bet on harness scaling to improve the execution system around an agent without changing its model weights"（概要）— モデルの重みを変えずに、エージェントの周りの実行システムを改善する方に賭ける、と。

ハーネス（harness）とは、モデルを走らせる側の器のことです。エージェントを1回動かすとき、モデルが担うのは「次に何をするか」を1手ぶん決める部分だけで、その外側には必ず人間が書いたコードがあります。ループを何回まわすか、ツールの結果をどう文字列にしてコンテキストへ戻すか、どこで打ち切るか、失敗したらどこからやり直すか。この外側の全部がハーネスです。

「スケーリング」という語がここで効いています。近年のスケーリングは、パラメータ数・データ量・推論時の思考量を増やす話でした。この論文が持ち込むのは4本目の軸 — 器の作り込みを増やすという軸です。しかも器の改善は、原理的にはモデルを差し替えても効き続けます。追加学習は新しいモデルが出るたびにやり直しですが、段取りのルールは持ち越せるかもしれない。論文が実際に測っているのは、まさにその「持ち越せるか」です。

数式で見る: なぜ長い仕事は落ちるのか

ステップ数が増えると何が起きるのか、いちばん素朴な見積もりを置いておきます。

$p$ は1ステップあたりの成功率、$n$ はステップ数、左辺は最初から最後まで通しで成功する確率です。「1手ごとの成功率を、手数ぶん掛け算する」と読んでください。各ステップが独立に成否を決める、という仮定を置いた場合の話です。

この式(1)が意地悪なのは、$p$ が高くても効かない点にあります。$p=0.99$ という腕利きでも、$n=100$ なら $0.99^{100}\approx0.366$。3回に2回は途中で落ちます。$p$ を 0.99 から 0.995 に上げる（誤り率を半分にする）と $0.995^{100}\approx0.606$ まで戻る — つまり長いタスクでは、1手ごとのわずかな信頼性の差が、通し成功率では桁の差になるわけです。

なお式(1)は論文が提示したものではなく、難しさを直感で掴むために本記事が置いた一般的な見積もりです。実際のタスクではステップは独立ではなく、途中で復帰もできます。それでも「手数が増えるほど、器の側の信頼性が指数的に効いてくる」という構図は変わりません。

だからこそ、器の側で「状態を落とさない」「手順を飛ばさない」「早く止まらない」を強制できるなら、モデルを触らなくても通し成功率は動くはずだ — というのがこの論文の立て方です。

StateMの構成: 実行を5つの軸で組織する

論文が導入する StateM は「エージェントネイティブなランタイム」で、実行を次の5つの軸で組織すると述べられています（概要）。

先ほどの4つの失敗と並べると、設計の意図が見えます。状態を見失う→永続する状態。手順を飛ばす→検査付きの遷移とランブック。早く止まる→遷移の検査が「まだ条件を満たしていない」と言えば止まれない。前の教訓を思い出せない→版管理されたプラクティスとして外に置く。失敗の型ごとに、器の側の対策が1つずつ当てられている構図です。

論文はこの性質を一文でまとめています。StateM は「選ばれた事後分析（postmortem）の知見を、永続的で実行可能な事前条件と実践へと変える」（概要）。気づきをドキュメントに書くのではなく、実行時に検査される条件として埋め込む、という言い換えです。arXiv のコメント欄には "Harness Scaling, Semi-Self-Evolving Agent"（半自己進化エージェント）とあり、この蓄積の部分が「半」自己進化にあたると読めます。人が点検できる形で残すから「半」なのでしょう。