Niklaus Harness LeaderboardがKimi Code、Hermes、Pi、Claude Code、Codexをブランド順位の枠を超えて検証
Joël Niklausは28,849回の試行を通じて9種類のコーディングエージェント用ハーネスを比較し、モデルを選べば性能の問題が解決するという考え方に疑問を投げかけた。Niklaus harness leaderboardは、基盤となるモデルと推論設定を制御しつつ、モデルの作業を指揮するソフトウェアを評価する。初期結果では、よく知られた複数のツールがほぼ同じ精度帯に位置しており、効率と再現性の差が単純な勝者の決定を難しくしている。
比較対象にはKimi Code、Hermes Agent、Pi、Claude Code、Codex、OpenCode、mini-swe-agent、Qwen Code、OpenClawが含まれる。ハーネスとは、AIモデルへの指示、ツール、実行ループを管理するソフトウェアである。この比較では、その周辺ソフトウェア自体が検証対象となる。
中心的な緊張関係は、製品の評判と、特定のテスト構成で示される挙動との間にある。これらの結果は、Claude CodeやCodexがデフォルトモデルで常に優れた性能を発揮することを示すものではない。制御された条件下で、異なるハーネスが選定されたオープンモデルを動かした場合に何が起こるかを検証しており、より限定的である一方、開発者にとって実務上の影響を持つ問いである。
Niklaus Harness Leaderboardが実際に比較しているもの
この実験は、すべてのコーディング製品を切り離せない一体的なパッケージとして扱うのではなく、周辺のエージェントソフトウェアを分離している。
Niklausはリリース説明で、ハーネスを変更しながら、モデル、プロバイダー、推論の努力量を固定して比較すると述べている。各タスクには3回の試行が与えられる。初期評価では、Terminal-Bench 2.1とDeepSWEを用い、GLM-5.3-Flash、DeepSeek-V4.1-Flash、Flintを対象とした。
この設計が重要なのは、通常の製品比較では複数の変数が同時に変わることが多いためだ。開発者がコーディングアシスタントを切り替える際には、モデル、指示、利用可能なツール、権限、実行挙動が一度に変化し得る。そのため、性能差の原因を特定することが難しくなる。
リリース説明によると、mini-swe-agentの3モデルにわたる平均解決率は51.4%で、OpenClawの27.3%を上回った。Niklausはさらに、ほかの4つのハーネスが統計的には首位の結果と同等だと述べている。これらの数値は恒久的なランキングではなく、初回リリース時点の結果を示す。
モデル別の結果を見ると、この総合平均はさらに複雑になる。Niklausによれば、GLM-5.3-Flashではmini-swe-agent、DeepSeek-V4.1-FlashではHermes Agent、FlintではKimi Codeが首位となった。したがって順位は、開発者がどのモデルを動かすつもりかに依存する。
直接的な示唆は限定的だが、重要である。あるモデルで良好に機能するハーネスが、別のモデルからも同じ相対的な性能を引き出すとは限らない。総合スコアは候補の特定には役立つ一方、実際の導入で重要となる組み合わせを隠してしまう場合がある。
Terminal-Benchは、ソフトウェアがコマンドを実行しファイルとやり取りするターミナル環境で、エージェントがタスクを実行する能力を評価する。DeepSWEは別個のソフトウェアエンジニアリング評価を提供する。両方を用いることで比較の範囲は広がるが、結果を統合しても、タスク集合があらゆる開発ワークフローを代表することにはならない。
この実験の結論には、日付も付記する必要がある。この記事のために確認した時点で、ライブアプリケーションにはバージョンv0.1.2が表示されていた。現在の説明では、初回リリース時の固定プロバイダーという表現を単に繰り返すのではなく、同等のプロバイダーを確認していることに言及している。
この違いは注目に値する。ベンチマークは最初の発表後に進化する可能性があるからだ。新しいハーネスのバージョン、追加試行、制御条件の改訂によって、スクリーンショットの意味が変わり得る。ローンチ時の数値は、現在のボードが異なる順位を示していても、ローンチ時点の構成に関する証拠であり続ける。
元のRedditの議論に触れた読者にとって、不可欠な修正はその範囲に関するものだ。これは、選定されたハーネスとモデルの組み合わせの比較である。列挙された製品名に関連する、すべての機能、サブスクリプション体験、デフォルト構成を包括的に検証したものではない。
コーディングエージェントベンダーに、構成全体の説明を求める圧力
この結果は、エージェントの性能を基盤モデルだけに帰する主張に説明を求める圧力となる。
ハーネス開発者にとって、この比較は実装上の選択をより可視化する。指示、ツールのインターフェース、再試行の挙動、停止の判断はいずれも、モデルが行う作業を形作る。強力なモデルであっても、それを指揮するソフトウェアによって摩擦に直面し得る。
モデルプロバイダーにとっても、この実験は原因帰属の問題をもたらす。特定のエージェント内で期待外れの結果が出たとしても、モデルだけが原因だとは言えない。逆に、好結果が出たとしても、その重みを使用するすべてのアプリケーションで再現されることを証明するものではない。
企業の購入担当者にとっては、有意義な評価に何を記載すべきかが変わる。構成上の選択が結果に影響する場合、モデル名とアシスタント名だけでは不十分だ。購入者は、テストされた組み合わせを理解し、自らの業務に関係する挙動を再現できるだけの情報を必要とする。
仮想的な保守タスクを考えると、この違いは具体的になる。エージェントはリポジトリを調査し、失敗しているテストを特定し、関数を修正し、その変更を検証する必要があるかもしれない。各段階は、ハーネスが情報をどう提示し、一連の行動をどう管理するかに左右される。
関連するテストを実行せず、編集後にエージェントが停止すれば、もっともらしいパッチでも未検証のままとなる。成果のないコマンドを繰り返し発行すれば、完了までの時間は長くなり、必要なリソースも増える。基盤モデルが変わらなくても、これらは運用上の差異である。
これは、特定のリーダーボード結果をどの実装が引き起こしたかを示すものではない。それを判断するには、実行記録を調べ、介入をテストする必要がある。モデルランキングだけでは答えられない有用な問いを、制御された比較が投げかけている理由を説明するものだ。
ローンチ時の結果は、よく知られたClaude CodeとCodexの議論にも境界を設ける。これらの製品名は、特定のモデルファミリーを中心に構築された完全な体験を指すことが多い。選定したオープンモデルでそのハーネスをテストすることは、その完全な体験同士を比較することとは異なる問いである。
この実験で順位が低かったとしても、製品のデフォルトサービスの性能が低いことを示すものではない。順位が高かったとしても、コードレビュー、インタラクティブな共同作業、組織固有のワークフローにおける優位性を示すものではない。こうした主張には、それらの活動を直接測定する評価が必要である。
Kimi Code benchmarkの結果にも同じ制約がある。Flintでの報告された首位は、テスト条件下でその組み合わせを詳しく調べる根拠となる。しかし、無関係なモデルやリポジトリ全体における一般的な優位性を示すものではない。
ベンダーにとって建設的な対応は、構成を公開し、結果に影響する変更を説明することだ。そうすれば購入者は、モデルのアップグレードとハーネスの改善を区別できる。性能に関する主張は評価しやすくなり、失敗も調査しやすくなる。
この圧力は、交換可能なエージェントソフトウェアを通じてオープンモデルを運用するチームにとり、特に重要である。彼らの購買判断には実行レイヤーも含まれる。認知度の高い製品名だけに頼るのではなく、そのレイヤーが何をもたらすのかに関する証拠を必要としている。
類似した精度が異なる運用挙動を隠す可能性
精度が僅差でも、リソース使用量、レイテンシー、一貫性には意味のある差が残り得る。
現在のボードは、精度を完全な答えとして示すのではなく、複数の測定値を分けている。その評価方法では、モデル使用量の外部測定を説明し、モデルの処理時間とエージェントの実行時間を区別している。こうした区別は、似た解決率でも異なる運用体験につながる理由を理解する助けとなる。
ボードは精度とコストの関係も図示し、表示された両方の指標で競合に劣らない選択肢の集合であるパレートフロンティアを特定している。これにより読者は、最高精度が常に望ましいとは限らないと理解した上で、競合する利点を検討できる。
この枠組みは、組織のワークロードとリソースが限られている場合に重要となる。監督を最小限に抑える必要がある難しいタスクでは、わずかな精度上の優位が価値を持ち得る。一方、日常的な保守作業全体で大幅に長い実行時間を要するなら、同じ優位の魅力は低下する可能性がある。
効率の結果にも解釈が必要である。支出が低いからといって、エージェントがより効果的に推論しているとは限らない。試行回数の少なさ、早期終了、短い出力、ツール使用パターンの違いを反映している可能性がある。実行記録は、生産的な抑制と早すぎる失敗を区別する助けとなる。
同様に、実行時間が長いからといって無駄だとは言えない。エージェントは、パッチの確認や失敗したアプローチからの回復に追加の労力を費やしているかもしれない。重要なのは、その追加作業がチームにとって実際に価値のある結果を改善するかどうかである。
このため、試行あたりのリソース使用量と成功結果あたりのリソース使用量を報告することは、異なる問いに答える。安価でも失敗した試行は失敗である。人間による復旧作業がワークフローの大部分を占める状況では、より負荷の高い成功試行のほうが依然として適切な選択となり得る。
これらは評価上の考慮事項であり、ボード上のすべてのハーネスについて確立された説明ではない。グラフは調査すべきパターンを示すことができる。しかし、それだけで、そのパターンを生んだ指示やツールの挙動を特定することはできない。
原理上、その仕組みは単純である。エージェントは情報を受け取り、行動を選択し、結果を観察し、次に何をするかを決める。ハーネスは、利用可能なツールや、その応答がどのようにモデルへ届くかを含め、このループの重要な部分を制御する。
環境上の問題によってビルドが失敗する仮想的なリポジトリを考えてみよう。アプリケーションコードを繰り返し編集するエージェントは、原因に対処せずにリソースを消費する可能性がある。別の構成では、環境問題を認識し、調査の方向を変えるかもしれない。
この差は、生のモデル知識ではなくタスク実行に関するものとなる。その説明を確立するには、観察された挙動と結果を対応付ける必要がある。その検証なしに、特定のハーネスが「より賢い」と述べることは、証拠を超えてしまう。
したがってNiklaus harness leaderboardは、単一の勝者というラベルが示唆するより具体的な比較を可能にする。開発者は、自らのワークロードで支えられる方法でリソースを使いながら、許容できる精度を達成する組み合わせはどれかを問うことができる。その答えは、インタラクティブな開発と無人運用で異なる可能性がある。
これは、Kimi Code benchmarkの見出しを読む際の視点も変える。モデル固有の首位は、さらなる評価に向けた有用なシグナルである。失敗した試行、実行時間、スコアを生んだ挙動についての情報がなければ、それだけでは不完全である。
同じ理由から、Claude CodeとCodexの比較ではテスト文脈を維持すべきである。これらの名称は理解の手がかりを与えるが、結果が実際に何を示すかは構成によって決まる。
再現可能な成功は、時折の成功とは異なる結果である
タスクを断続的に解決するエージェントは、一貫して解決するエージェントとは異なる導入上の判断をもたらす。
Niklausはその後、繰り返し試行した場合の信頼性に注目した。彼の信頼性の内訳によると、mini-swe-agentは1試行あたり平均51.4%のタスクを解決した。3回の試行では少なくとも1回解決できた割合は68.6%だったが、すべての試行で解決できた割合は33.0%だった。
これらの測定値は、それぞれ異なる運用上の問いを表している。平均値は試行全体での性能を捉える。少なくとも1回の成功は、繰り返し機会を与えれば最終的に解決へ到達するかを示す。毎回の成功は、測定された試行内での一貫性を示す。
この区別は、誰かがエージェントの作業を見守る場合に重要になる。開発者は失敗した試行を確認し、指示を変更したり、もう一度実行する価値があると判断したりできる。人間の監督により断続的な成功も有用になり得るが、監督に費やす時間もワークフローの一部である。
無人のプロセスには異なる制約がある。周辺システムが実際に代替試行を実行し、その品質を認識できない限り、成功する別の試行が存在するとは前提にできない。繰り返し試行には、選択方法、実行予算、未解決の失敗を処理する手段が必要になる。
このため、たまに成功するというスコアは、一貫性の測定値の代替としては不適切である。これは、ある構成が特定の条件下で解決策に到達できることを示し得る。しかし、その構成が要求時にその解決策を確実に提供することまでは立証しない。
Niklausによれば、引用された比較では5つのハーネスが、すべての試行で32.0%から33.3%のタスクを解決した。彼はこれらの結果を優劣をつけるには近すぎると説明している。これは、先頭グループ内で精密な勝者を主張することを避ける根拠となる。
信頼性の数値にも限界を付記する必要がある。3回の試行は、その実験内での再現性に関する証拠を提供する。しかし、変化するリポジトリ、依存関係、権限、ユーザー指示にまたがる本番環境の失敗率を確立するものではない。
また、ベンチマークでの失敗が自動的に本番環境での有害な操作へ結び付くわけでもない。評価器が測定するのは、タスクが成功基準を満たすかどうかである。運用上の影響は、エージェントがアクセスできる対象と、その作業を取り巻く承認や検証に左右される。
エンジニアリングマネージャーにとっての示唆は、能力と信頼できるデリバリーを分けて考えることだ。ある構成は、正しいパッチを時折生成できるほどの能力を持ちながら、無人ワークフローには適さない場合がある。その隔たりには、より強いマーケティング表現ではなく、追加の検証が求められる。
仮想的な依存関係更新は、この違いをよく示す。エージェントはある実行ではパッケージの更新に成功してテストにも通過する一方、別の実行では関連する設定変更を見落とすかもしれない。時折の成功は、見出しの割合が示唆するほど無人運用への準備状況を証明しない。
そのワークフローを評価するチームは、再現可能な完了と明確な失敗処理を重視する。また、結果として生じる変更がレビュー担当者にとって理解可能かどうかも重視する。これらの側面は、ベンチマークの検証器が最終状態を受け入れるかどうかとは別のものである。
リーダーボードの繰り返し試行の視点は、この区別を公開比較に持ち込む。読者に対し、1つの成功軌跡を製品の完全な説明として扱うのではなく、エージェントが再び作業しなければならない場合に何が起こるかを問うよう促している。
ベンチマークのバージョンと公開記録は勝者の主張を限定する
公開された結果は検証可能な証拠だが、ベンチマークのバージョン、構成、検証の完全性によって制約される。
Terminal-Bench自体が、バージョンラベルが重要である理由の明確な例を示している。2.1改訂版では、前版の89タスクのうち28件にあった問題が修正された。メンテナーは、これらの修正後に代表的なエージェント・モデルのスコアが変化したと報告している。
この経緯により、ベンチマークのバージョンは主張の一部となる。Terminal-Bench 2.0のスコアを、2.1のスコアと単純に同一視することはできない。表示される指標の名前が同じでも、タスクと評価条件は変化している。
同じ原則はハーネスにも当てはまる。結果は、テストされたソフトウェアのバージョンと設定に属する。更新によって指示、ツール実行、または終了動作が変われば、以前のスコアは以前の実装を説明するものになる。
これは、急速に展開する公開討論にとって課題を生む。ボードが変更された後もグラフが拡散され、コメントではそのグラフが現行のものとして扱われ続けることがある。読者には、その画像がなお何を示せるのかを判断するため、元の構成と測定日が必要である。
プロジェクトの公開実行記録は、こうした詳細を確認する手段を提供している。記録が利用可能であることは透明性の利点だ。その公開は、すべての結果がすでに独立した再現や完全な手作業レビューを受けたことを意味しない。
独立した再現には、指定された構成を実行し、関連する傾向が維持されるかを確認することが必要となる。記録を読むことは、報告された計算や個々の挙動の監査を支援できる。これらの活動は異なる種類の証拠を提供する。
因果に関する問いは、依然として特に難しい。スコア差は、統制された条件下における構成と結果の関連を特定できる。その差を説明するには、失敗を調べ、提案された変更がそれらを変えるかを検証する必要がある。
たとえば、タイムアウト問題が疑われる場合は、他の関連条件を維持したままタイムアウトを変更してテストすべきである。情報損失問題が疑われる場合は、どの情報が失われたのか、そしてそれを保持すると結果が改善するのかを調べる必要がある。どちらの説明も、低い順位から自動的に導かれるものではない。
ベンチマークへの慣れは、不正行為を前提とせずに調査する価値のある別の懸念をもたらす。公開タスクに対して最適化されたシステムは、そのタスク分布で改善しても、他の領域で同程度に改善するとは限らない。未知のタスクからの証拠は、その改善がどの程度広く転移するかを示す助けになる。
タスク範囲には別の限界がある。リポジトリの保守には、組織上の慣行、曖昧な要求、人間によるレビューへの期待が含まれ、固定されたベンチマークではそれらを完全に捉えられない。ベンチマークは、こうした導入上の問いを未解決のまま残しつつも有用であり得る。
実務的な対応は、証拠を意思決定に見合う水準に保つことだ。公開結果は、候補の絞り込みや対象を限定した試行を正当化できる。チームの開発ワークフローを置き換えるには、そのチームの実際の責務に似た作業から得られる追加の証拠が必要となる。
構成、失敗例、レビュー判断をまとめて保管すれば、比較を後から見直しやすくなる。検索可能なナレッジベースは、テスト中に使用した技術文書とともに、その評価履歴を保存する助けとなる。
検証の隔たりは、実験の価値を消し去るものではない。それは、結果が現在裏付ける範囲と、それを強化するために必要な追加作業を定義する。すべての順位を文字どおり受け入れることと、比較全体を退けることのいずれよりも、こちらの読み方の方が有用である。
次のテストでは更新、再現、無人作業を追跡すべきである
最も強力な追跡証拠は、バージョン変更を初期比較を超えた作業における再現可能な改善へ結び付けるものになる。
最初に注目すべきシグナルは、明確なバージョン履歴を伴う更新後のハーネス性能である。開発者が実行ソフトウェアを変更した場合、比較可能な再実行により、正確性、効率、または一貫性が変化したかを示せる。以前の構成を保存することで、その比較に意味が生まれる。
繰り返し測定にわたる改善は、ハーネスエンジニアリングが結果に実質的な影響を与えるという主張を強める。比較可能な再実行で消える結果は、主張された改善への信頼を弱める。どちらの結果も、更新された勝者バッジより多くの情報をもたらす。
これはベンダーにとっても建設的な対応手段となる。失敗パターンを特定し、関連する実装変更を説明し、結果に関する証拠を公開できる。読者はその後、製品の評判から品質を推測するのではなく、具体的なエンジニアリング上の主張を評価できる。
2つ目のシグナルは、対応する統制条件を用いた独立再現である。別の評価者は、モデル、プロバイダー条件、推論設定、タスクのバージョン、ハーネスのバージョンを文書化すべきである。差異は、見かけ上同一のスコアにまとめられるのではなく、見える形で残す必要がある。
独立した結果が大まかな順位やモデル固有の傾向を維持するなら、比較への信頼は高まる。結果が乖離するなら、より詳しい検討が必要な条件を示唆する。プロバイダーの挙動、実行設定、測定詳細は、都合のよい説明ではなく研究課題となる。
再現では、すべての数値が完全に一致する必要はない。重要なのは、妥当な反復測定において結論が維持されるかどうかである。近い結果は、それらを区別する追加の証拠がない限り、近いままであるべきだ。
3つ目のシグナルは、明示的な無人成功基準を伴う未知の作業での性能である。これは、エージェントが要求されたタスクを完了し、結果を検証し、失敗を適切に処理するかを確認することを意味する。人間の介入は、「自律的な完了」が何を意味するかを変えるため、記録すべきである。
その作業で一貫した改善が見られれば、リーダーボードの発見が実務上持つ重要性は強まる。改善が既知のベンチマークタスクに限定されるなら、その関連性は狭まる。この区別は、総合平均におけるもう一つの小さな変動よりも、導入にとって重要である。
現在ソフトウェアを選ぶチームにとって、この証拠は実際の組み合わせの水準で比較することを支持している。Kimi Code、Hermes Agent、Pi、Claude Code、Codex、mini-swe-agentは、チームが利用を意図する構成で評価する価値がある。名称だけで結果を決めることはできない。
Niklausのハーネスリーダーボードは、公開された出発点として、ローンチ時の結果、繰り返し試行、アクセス可能な記録を提供している。その永続的な貢献は、それらの測定がエージェントの挙動を説明し改善する助けとなるかにかかっている。
コーディングワークフローを変更する前に、候補に絞った組み合わせを、代表的な保守作業で既に信頼している設定と比較してほしい。正確な構成、完了の証拠、レビュー担当者の作業量、介入を必要とする失敗を記録する。成功した検証手順なしには、もっともらしいパッチだけでは不十分なタスクも含めること。意味のあるハーネス更新後に比較を見直し、変更を理解できるよう以前の結果を保存する。公開ボードをその意思決定の証拠として扱いつつ、最終的な判断は自らのワークフローに委ねるべきである。答えるべき問いは具体的だ。実際に提供できる監督のもとで、チームが検証し、繰り返し、受け入れられる作業を届けるのは、どのテスト済みの組み合わせなのか。
