モデルの重みを変えずにTerminal-Bench 2.1の正答率を9ポイント上げる──StateMがDeepSeek-V4 Flashで再現した392/445のログを開けた

3行まとめ

1. StateMは、モデルの重みを一切変えずに「実行システム」側をスケールさせる思想のエージェント向けランタイムで、論文はTerminal-Bench 2.1でGPT-5.6 Sol xhighの正答率を95.3%（445試行）まで引き上げたと報告している。今回GitHubに公開されたのは、その同じrunbookをDeepSeek-V4 Flashに適用した再現用アーティファクトのリリース。
2. 論文のAbstractによれば「同じランタイム・runbook構造・golden rulesを使い、$38未満の適応でDeepSeek-V4 Flashを82.7%から88.1%（標準タイムアウト）、88タスクの共通コアでは89.1%まで引き上げた」。GitHub Releaseの公開アーティファクトでは392/440の生パス数（88.09%を89タスク・445試行の分母で計算した値）が確認できる。
3. コストは「Final-scoreのAPI利用は約$15、GPT参照実装の$574.68に対して」、DeepSeekの総支出は$52.22と論文は明記している。GitHub Releaseのアーティファクトには、54ファイルのタスク注入済みソース一式のSHA-256マニフェスト、440件の匿名化済みトラジェクトリ、認証情報を含まないプロバイダ設定テンプレートが含まれる。

StateMとは何をするランタイムか

Hugging Face Papersに掲載されている論文「StateM: Reaching 95.3% Raw Accuracy, or a $15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling」の要旨は、StateMを「持続的な状態（durable states）、フェーズローカルなコンテキスト、検査済み遷移（checked transitions）、復旧可能なrunbook、バージョン管理された手順的プラクティスを中心に実行を組み立てる、エージェントネイティブなランタイム」と定義している。前提となる問題意識は、長期タスクを実行するエージェントが、たとえ各ステップを個別に解けるモデルであっても、可変状態を見失ったり、過去の実行から得た教訓を再活性化できなかったり、既知の手順を飛ばしたり、早期に停止してしまったりする、というものだ。論文は「モデルの重みを変えず、エージェントを取り巻く実行システムをスケールさせる（harness scaling）ことに賭けた」と表現している。

GPT系での結果

論文のAbstractは、Terminal-Bench 2.1でGPT-5.5 xhighをStateMが83.1%（参照値）から92.1%へ引き上げ、GPT-5.6 Sol Ultraの91.9%も上回った、その同じrunbookはGPT-5.6にそのまま移植でき、GPT-5.6 Sol xhighではStateMが445試行across89タスクで95.3%のraw accuracyに達し、全89タスクで少なくとも1回は成功した、と報告している。凍結したプロファイル（設定を固定した版）でもGPT-5.6 Lunaを76.7%から85.4%へ引き上げ、Sol xhigh参照値の84.9%を上回った。

DeepSeek-V4 Flashでの再現──今回のGitHub Release

今回GitHubに公開されたのは、このrunbookをDeepSeek-V4 Flashに適用した際の再現用アーティファクトだ。論文Abstractは次のように説明している（原文引用と訳）。

Using the same runtime, runbook structure, and golden rules, less than $38 of adaptation raises DeepSeek-V4 Flash from 82.7 to 88.1% under standard timeouts and to 89.1% on an 88-task common core. Extending only the remaining latency-sensitive task matches the reported 88.8% GPT-5.6 Sol max result. Final-score API usage is about $15 versus $574.68 for the GPT reference; total DeepSeek expenditure is $52.22.

（同じランタイム・runbook構造・golden rulesを使い、$38未満の適応でDeepSeek-V4 Flashを標準タイムアウト下で82.7%から88.1%へ、88タスクの共通コアでは89.1%まで引き上げた。残る1つの遅延に敏感なタスクだけを拡張すると、報告されているGPT-5.6 Sol maxの88.8%という結果に一致する。Final-scoreのAPI利用は約$15、GPT参照実装の$574.68に対して。DeepSeekの総支出は$52.22）

つまり「88.8%」という数字は、DeepSeek自身の最終スコアそのものではなく、DeepSeekが1タスクだけ拡張設定にした場合に一致する「GPT-5.6 Sol maxの参照結果」を指している点には注意が要る。DeepSeek-V4 Flash自身の標準タイムアウトでの数字は88.1%（445試行の分母）ないし89.1%（88タスク共通コア）だ。

GitHub Release本文が明記する、公開アーティファクトの実測値は次の通り。

姉妹記事で見つけた重要な留保:フラッグシップ結果の「95.3%」は審査中の生スコア

同じStateM論文をarXivのPDF本文（脚注1）まで遡って確認したところ、タイトルにもなっているGPT-5.6 Sol xhighの「95.3%」という数字について、著者自身が重要な留保を明記していることが分かった。この数字はTerminal-Bench 2.1公式の提出パイプライン（PR #142、harbor-framework/terminal-bench-2-1リポジトリ）が計算した「調整前（pre-adjudication）の生スコア」であり、2026年8月11日時点でこのPRは審査中でリーダーボードにはまだマージされていない。著者は「審査中に見つかった、報酬が誤って与えられた4試行はカウントすべきでない」と認めており、それらを0点として扱うと420/445＝94.38%になる。さらに「reward hacking（報酬関数の抜け穴を突く挙動）の疑いがある」とフラグが立った9試行すべてを0点にすると、415/445＝93.26%まで下がるという。

この記事が扱うDeepSeek-V4 Flashの88.1%／89.1%という数字自体には、論文中に同様の「reward hacking疑い」の注記は見当たらなかった。ただし、同じ論文のフラッグシップ結果（GPT-5.6 Sol xhighの95.3%）に上記の留保が付いている以上、DeepSeek側の数字についても、Terminal-Bench公式の審査を経て確定した値ではなく、著者チームによる自己報告の生スコアである可能性を念頭に置いて読む必要がある。著者4名（Ziheng Qin・Yaxin Lu・Zhangyang "Atlas" Wang・Kai Wang）は、論文中で「この研究は著者らの個人的な時間で行われたものであり、いかなる所属組織の見解も反映しない」と明記しており、特定の企業・大学の看板を背負わない個人プロジェクトだ。

論文とリリースの対応

コスト内訳について確認できていないこと

本記事はHugging Face Papersのsummary欄・GitHub Releaseの本文に加え、論文のPDF本文（1〜6ページ、Abstract・Introduction・3章StateMの設計・脚注1のスコア調整に関する記述）をRead機能で画像として取得して書いている。ただし本文の後半（4章以降の詳細な実験設定）までは読み込んでおらず、「$38未満の適応」が具体的に何を指すか（API費用のみか、人件費相当を含むかなど）の内訳は、今回参照した範囲の記述には無い。GitHub Security Advisories的な第三者による独立再現も見つけられていない。筆者は公開されたアーティファクトを実際にダウンロードして中身を検証してはいない（54ファイルのソース一式・440件のトラジェクトリという規模のダウンロードは本記事の執筆ルール上見送っている）。DeepSeek-V4 Flashの88.1%／89.1%という数字自体にreward hackingの疑いが指摘されているかどうかは、今回読んだ範囲の本文には明記がなく、フラッグシップ結果（GPT-5.6 Sol xhigh）と同水準の審査を経ているかは確認できていない。Zenn記事検索で「StateM」はヒットするが、中身は無関係な「Statement」関連の記事ばかりで、本記事が扱う意味でのStateMを扱った日本語記事はこの記事作成時点で見当たらなかった。

関連記事

• LLMベンチマークの読み方
• 中国勢・オープンウェイト2026年上半期