タスク成功率6.7%から68.3%へ: 10倍の差を生んだのはモデルではなくハーネスだった
LangChainのTerminal Bench結果とhashlineフォーマット実験が示したこと。同じモデルでリーダーボードの順位が逆転した理由は、プロンプト・ツール・ミドルウェアの3つにありました。
Grok Code Fastのコーディングベンチマーク成功率は6.7%でした。モデルを変えずに編集フォーマットを一つ切り替えたところ、68.3%になりました。モデルのパラメータには一ビットも手を触れていない結果です。
連休中に自分でエージェントを動かしながら、似たような経験をしました。モデルのリリース速度は目まぐるしいですが、実務で性能を大きく左右したのはモデル自体ではありませんでした。モデルを包むハーネス、つまりシステムプロンプトとツール構成とミドルウェアの組み合わせでした。
同じモデル、異なる順位
LangChainチームが自社のコーディングエージェントでTerminal Bench 2.0を実行しました。GPT-5.2-Codexはそのままに、システムプロンプト・ツール構成・ミドルウェアだけを調整しました。スコアは52.8から66.5に上がり、リーダーボード30位圏外から5位圏内に入りました。モデルの学習にかかったコストはゼロです。
鍵となったのは推論バジェットの配分でした。xhighをすべてのタスクに一律適用すると53.9%にとどまりましたが、タスクの難易度に応じてxhigh-high-xhighに分けると66.5%まで上がりました。タイムアウトで失敗していた問題が、この配分戦略で解決されたのです。同じモデル、同じトークンバジェットで、配分の仕方だけが異なっていました。
編集フォーマットが隠していた実力
あるオープンソースエージェント開発者がhashlineという編集方式を作りました。ファイルを読み込む際に各行へ2〜3文字のハッシュタグを付け、モデルが修正する際はそのタグだけを参照する仕組みです。
従来の方式では、モデルが元のテキストを一字一句正確に再現する必要がありました。スペース一つのミスでも失敗します。コーディングエージェントを実際に使ったことがあれば、“String not found” エラーが繰り返される苦労はご存知でしょう。hashlineはこの問題を構造的に回避します。
結果は劇的でした。Grok Code Fastが6.7%から68.3%に跳ね上がり、Grok 4 Fastは出力トークンが61%削減されました。GPT-4 Turboはフォーマット変更だけで26%から59%になり、Gemini 3 Flashは従来の最高記録を5pp上回りました。モデルの学習コストなしに、編集インターフェースを一つ変えただけです。
検証ループがなければ最初の回答で止まる
最もよくある失敗パターンがあります。エージェントがコードを書き、自分が書いたコードを読み返し、問題ないと判断します。テストを一度も実行せずにそこで終わります。
LangChainチームはエージェントの終了直前に、タスク仕様に対する検証を強制するミドルウェアを組み込みました。同じファイルを繰り返し編集する「ドームループ」も別のミドルウェアで検知し、アプローチの見直しを促します。この二つの仕組みがなければ、スコアの上昇幅はずっと小さかったでしょう。エージェントにディレクトリ構造と利用可能なツールを事前に注入し、時間バジェット警告で検証ステップへの移行を促すことも効果的でした。
安価なモデルほどハーネスへの感度が高い
MiniMax M2.5やKimi K2.5は速度が速く、エージェントのツール利用が得意です。価格も大型モデルと比べてはるかに低コストです。一方で基礎知識は米国の大型モデルに比べて不足しています。MiniMaxはもともとエージェント特化モデルとして学習されている印象が強く、リソースが限られているため汎用ではなく特化モデルを選択したものと思われます。低価格のおかげでOpencalwのようなプラットフォームでの利用が急増しています。
hashlineのベンチマーク結果を見ると、モデルが弱いほどフォーマット変更による性能変動幅が極端に大きくなりました。MiniMaxはhashline適用後に成功率が2倍以上に跳ね上がりました。ベンチマーク全体のコストは約$300でした。
ベンチマークは実務そのものではない
一点、注意すべきことがあります。Terminal Benchであれhashlineベンチマークであれ、制御された環境で計測した数値です。実際のプロダクション環境では、コードベースの規模・依存関係の衝突・曖昧な要件といった変数がはるかに多く存在します。ベンチマークで66.5%を記録したエージェントが、10万行のレガシープロジェクトで同じ性能を発揮できるかどうかはまだ検証されていません。ハーネスの最適化が効果的であることは明らかですが、ベンチマークの順位をそのまま実務の性能に換算するのは危険です。
それでも方向性は明確です。モデルの選択よりもハーネスの設計がROIで上回る局面は確実に存在します。今私たちが目にしているベンチマーク順位のかなりの部分は、モデルの実力ではなくハーネスの品質を反映しています。
ニュースレターに登録
最新のプロジェクト、記事、AIとWeb開発の実験に関する情報をお届けします。