StateM、実行基盤の強化だけでエージェント精度95.3%を達成

導入

長い手順を必要とするタスクでは、基盤モデルが個々の作業を解けても、エージェント全体は失敗することがある。実行中に変化した状態を追えなくなったり、過去の実行で得た教訓を再利用できなかったり、既知の手順を飛ばしたり、完了前に停止したりするためだ。StateMはこの問題に対し、モデルの重みを変更するのではなく、モデルを取り巻く実行システムを拡張する「harness scaling」を提案する。

主要ポイント

• 永続状態を中心に実行する。 StateMはタスクをdurable statesとして管理し、コンテキストをフェーズごとに分ける。長い軌跡の中で、環境の状態と現在の作業を混同しにくくする狙いだ。
• 遷移を確認し、失敗から復旧する。 状態遷移にはチェックを設け、runbookは再開可能な形で保持する。出力を連続した行動として扱うのではなく、前提条件を満たしたかを確認しながら進める。
• 経験を手順として残す。 実行後の分析から得た知見を、バージョン管理されたprocedural practicesやgolden rulesに変換する。エージェントとユーザーが同じ制御を確認できる点も特徴だ。
• Terminal-Benchで大きく改善。 GPT-5.5 xhighは参照設定の83.1%から92.1%へ向上した。同じrunbookはGPT-5.6へ変更なしで移植でき、GPT-5.6 Sol xhighでは445試行で95.3%の生精度、89タスクすべてで少なくとも1回の成功を報告している。
• モデルをまたいで効果を確認。 固定したプロファイルによりGPT-5.6 Lunaは76.7%から85.4%へ上昇した。DeepSeek-V4 Flashも、同じランタイム、runbook構造、ルールによって標準タイムアウトで82.7%から88.1%、共通88タスクでは89.1%になった。
• コスト差も報告。 最終スコア時のAPI利用額はStateM側が約15ドル、GPT参照側が574.68ドル、DeepSeekの総支出は52.22ドルとされる。ただし、これは論文の実験条件における値であり、一般的な運用価格を意味しない。

意義と限界

StateMが示す重要な方向性は、エージェントのスケーリング対象をモデルだけに限定しないことだ。状態管理、手順の強制、復旧、経験の再利用を実行層の機能として分離すれば、モデルを交換しても制御ロジックを再利用できる可能性がある。これは長時間のコーディングや端末操作のように、途中状態が結果を左右する用途で特に意味を持つ。

BusinessBenchでは、開発セットから作ったタスク家族別runbookが、保持テストでマクロ0.55ポイント、マイクロ1.34ポイントの改善を示した。さらに、実行メカニズムが一致する2つの家族では10.04ポイント向上した。具体的なルールは、タスクが同じ実行構造を共有する場合にこそ一般化しやすい、という示唆である。

一方、95.3%という値は特定のベンチマーク、モデル、ランタイム、試行条件での結果だ。汎用的な自律性を直接証明するものではない。StateMは、失敗から得た教訓を明示的かつ検証可能な制御へ変換する、監査可能な実行基盤として捉えるのが適切だろう。

出典：Hugging Face Daily Papers