モデルを変えずにTerminal-Bench 2.1で95.3%──「ハーネス側だけ」を作り込んだStateMの実験費用は15ドル

「モデルの性能を上げる」ことと「モデルを取り巻くシステムを作り込む」ことは、AIエージェントの成果を左右する別々のレバーだ。2026年8月15日にarXivで公開された論文「StateM」は、後者——著者らが「harness scaling（ハーネス側のスケーリング）」と呼ぶアプローチ——だけで、コーディングエージェントのベンチマークTerminal-Bench 2.1のスコアを大きく押し上げられることを示している。著者はZiheng Qin氏・Yaxin Lu氏（共同筆頭）・Zhangyang "Atlas" Wang氏・Kai Wang氏の4名で、所属欄には「Somewhere on the Earth」とだけ書かれ、脚注に「この研究は著者らの個人的な時間で行われたものであり、いかなる所属組織の見解も反映しない」と明記されている。特定の企業・大学の看板を背負わない、個人プロジェクトとしての発表だ。

3行まとめ

1. StateMは、モデルの重みを一切変えず、状態管理・コンテキストの区切り方・手順の記録と再利用（YAML形式のランブック）というランタイム側だけを作り込む「harness scaling」を提案するツールで、著者4名は特定組織に属さない個人プロジェクトとして発表している。
2. Terminal-Bench 2.1で、GPT-5.5 xhighはStateM適用で83.1%→92.1%、GPT-5.6 Sol xhighでは445試行中424試行成功・raw accuracy 95.28%に達し、DeepSeek-V4 Flashも38ドル未満の適応コストで82.7%→88.1%まで改善したという。
3. ただし著者自身の脚注によれば、この95.28%という数字はTerminal-Bench公式の採点PR(#142、未マージ・審査中)による「調整前の生スコア」で、審査で問題ありと判明した4試行を0点にすると94.38%、「reward hackingの疑いがある」とフラグされた9試行を0点にすると93.26%まで下がると著者自身が明記している。

なぜ長時間タスクでエージェントは失敗するのか

論文はまず、長時間にわたるタスクでエージェントが失敗する典型的なパターンを挙げている。

"Long-horizon agents can fail even when their underlying models can solve the constituent steps. They may lose track of mutable state, fail to reactivate lessons from earlier executions, skip known procedures, or stop prematurely."

（長時間タスクをこなすエージェントは、基盤となるモデルが個々のステップ自体は解ける場合でも失敗し得る。可変な状態を見失ったり、以前の実行から得た教訓を再活性化できなかったり、既知の手順を飛ばしたり、早すぎるタイミングで停止してしまったりする）

これらは、モデル自体の能力不足というより、「実行中に何が起きているかをどう管理するか」というシステム側の設計問題だ、というのが論文の立場だ。

StateMの設計：耐久的な状態、フェーズ限定コンテキスト、検証済み遷移

論文はこの問題への対処として、StateMという「エージェントネイティブなランタイム」を提案している。

"We introduce StateM, an agent-native runtime that organizes execution around durable states, phase-local context, checked transitions, recoverable runbooks, and versioned procedural practices that agents and users can inspect together."

（StateMを導入する。これは、耐久的な状態・フェーズごとに限定されたコンテキスト・検証済みの遷移・復旧可能なランブック（実行手順書）・バージョン管理された手順的なプラクティスを軸に実行を組織化する、エージェントネイティブなランタイムだ。これらはエージェントとユーザーが共同で検査できる）

モデルの重みを変えるのではなく、実行状態の管理方法・コンテキストの区切り方・手順の記録と再利用の仕組みという、いわば「エージェントの周りの足場」を作り込むアプローチだ。

StateMの設計:YAML形式の「ランブック」と2×2の位置づけ

論文本文（3章冒頭）は、StateMを「長時間動くCLIエージェント向けの軽量ランタイム」と定義している。その制御レイヤーは、状態・有効な遷移・状態ごとの指示・フック・チェック・復旧ルールを含む、人間が読めるYAML形式の「ランブック」の形をとる。エージェントは通常のコマンドライン操作を通じて、自分の現在の状態を検査し、遷移を要求し、失敗条件を確認し、実行履歴を確認でき、人間の監督者も同じランブックを検査・編集・バージョン管理できる、と説明されている。論文は「State boundaries provide both context and contract」（各状態は文脈と契約の境界を提供する）という原則を挙げ、状態に入るとその局面向けの指示と永続的なタスク情報が更新され、状態を出るには明示的な終了条件を満たす必要がある、という設計だとしている。

論文はこの位置づけを、縦軸「ランタイムの強制力」・横軸「エージェントの自律性」の2×2の概念図（Figure 1）で示している。左上に「素朴なエージェント（外部化された制御レイヤーなし）」、右上には既存のCodex／Claude Code（ソフトなプランやチェックリストはあるが、状態遷移を強制する仕組みは薄い）、左下にState Flow（有限状態機械ベース）、右下にLangGraph（グラフベースのオーケストレーション）が置かれ、StateMはその中間である「広いエージェントの自律性」と「明示的で強制力のある状態遷移」を両立する右上の領域を狙う設計だと位置づけられている。

数字：GPT-5.5からGPT-5.6、DeepSeekまで、モデルをまたいで効く

論文の実験結果は複数のモデルにまたがっている。

「ランブックがGPT-5.5からGPT-5.6へ再調整なしにそのまま転用できた」という記述は、このアプローチがモデル固有のチューニングではなく、ある程度モデルをまたいで再利用可能な設計であることを示唆している。

費用対効果：15ドル 対 574.68ドル、ただし採点は審査中

論文の脚注（1）には、95.28%という数字の性格についてかなり踏み込んだ自己申告がある。この数値はTerminal-Bench 2.1の公式提出パイプライン（PR #142、harbor-framework/terminal-bench-2-1リポジトリ）が計算した「調整前（pre-adjudication）の生スコア」であり、2026年8月11日時点でこのPRは審査中でリーダーボードにはまだマージされていない、と明記されている。提出は10種類の自動チェック（タスクダイジェスト・標準実行設定・試行のカバレッジ・軌跡の可用性）には通ったが、著者自身が「審査中に見つかった、報酬が誤って与えられた4試行はカウントすべきでない」と認めており、それらを0点として扱うと420/445＝94.38%になる。さらに「reward hacking（報酬関数の抜け穴を突く挙動）の疑いがある」とフラグが立った9試行すべてを0点にすると、415/445＝93.26%まで下がるという。著者は「したがって95.28%は、あくまで一般公開された生の提出スコアとしてのみ報告する」と釘を刺している。提出パイプラインは合計11億7,800万トークン・モデルコスト1,062.95ドルを要したとも記載されている。

コスト面では、最終スコア算出のAPI利用料は約15ドルで、GPT基準の574.68ドルと比べて約38.9倍安い。DeepSeekの適応・評価にかかった総支出は52.22ドルで、これも約11.0倍安いという計算になる（いずれも論文本文の数値）。「$15 Frontier Run」というタイトルの数字はこの最終スコア算出コストを指しており、ハーネス自体の開発・試行錯誤にかかった総コストを含むかどうかは本文では明言されていない。

BusinessBenchでの汎化結果

論文はTerminal-Bench以外のベンチマーク（BusinessBench、Codex＋GPT-5.6 Lunaで評価、7タスクファミリー・477件の対象インスタンスのうち6ファミリー405件にStateMの介入を適用）での結果にも触れている。最初の凍結・one-shot評価では、held-out（未使用）データでのマクロ平均が84.67%→85.22%、インスタンス加重のミクロ平均が84.44%→85.78%に向上し、開発セットでの性能は86.07%→91.71%、介入対象インスタンス全体では84.76%→88.72%まで改善したという。特に「メカニズムが一致する」とされるBudget ApprovalとMachine Operatingの2ファミリーに絞った探索的な分析では、71.91%→81.94%という10.04ポイントの改善が確認されている。論文はこれを「制御プロファイルが実行の構造と一致するタスクで最大の改善が出る」パターンだとまとめている。

ランブックが別モデルへそのまま転用できたという1点

筆者は普段、Claude Codeのような既存のエージェント型コーディングツールを使う際、モデル自体の性能差を意識することが多い。StateMが示しているのは、モデルを固定したまま「その周りの実行管理」だけをどれだけ丁寧に設計するかで、これほどのスコア差が生まれ得るという事実だ。特に「ランブックが別モデルに転用できた」という点は、エージェント運用のノウハウを「プロンプト」ではなく「実行構造」として蓄積していく発想の重要性を示していると感じる。

95.28%という数字は、著者自身が「未確定」と明記している

この記事はarXivのPDF本文（Abstract・Introduction・2章 Related Work・3章StateMの設計・脚注1）をcurlで取得し、Read機能でページを画像として読んで書いている。本文の後半（4章以降の詳細な実験設定・BusinessBenchの全タスクファミリーの内訳・GitHub上に公開されているコードの中身）までは読み込んでおらず、この記事はおおむね本文6ページ目までの記述にもとづく。最も重要な留保は、見出しにもある通り95.28%という主結果の数字自体を著者自身が「調整前の生スコアに過ぎず、Terminal-Bench公式の審査（PR #142）は本記事執筆時点で未マージ」「reward hackingの疑いがある試行を含む可能性がある」と明記している点で、この記事もその留保をそのまま引き継いでいる。著者4名はいずれも特定の企業・大学に所属を明示しない「個人の時間」で行った研究だと自ら述べており、査読を経た論文でもない。GitHubで公開されているという「core code and several runtime cases」については、リポジトリ（github.com/henryqin1997/statem、論文のアブストラクトにcitation_abstractとして明記）自体の実在はGitHub APIで確認した。説明文は「CLI runbook for agent long run.」、star数775、最終pushは2026年8月26日（いずれも2026年8月30日にGitHub APIで取得した値。2026年9月4日の再確認では star 946・最終push 9月2日で、活発に動いている）。ただしコードの中身までは読んでおらず、StateMを自分の手元で動かして数字を再現できるかは確認していない。脚注1が触れているTerminal-Bench公式提出のPR #142（harbor-framework/terminal-bench-2-1リポジトリ、タイトル「Leaderboard Submission: GPT-5.6 Sol (xhigh) + statem-Codex」）についても、GitHub APIで状態を確認したところ2026年7月15日作成・本記事執筆時点でstate: open・merged: falseとなっており、論文が明記する「未マージ・審査中」という記述と一致した。Zenn記事検索（2026年8月27日実施）では「StateM」に該当する日本語記事は見つからなかった（一般語「statement」との混同を避けるため、引用符付き完全一致で検索した）。

関連記事

• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
• AIに「ルールを読め」は効かない──読むまで作業をブロックする仕組み（hooks）の作り方
• AIエージェントとは──指示に答えるAIと、仕事を進めるAIの違いをわかりやすく整理する