- 複数のLLMを同一条件でテストした結果、コード修正ツールを変えるだけでも性能が大きく向上
- 従来のPatch・Replace方式の代わりに、各コード行へハッシュタグを付与する「Hashline」フォーマットを適用し、修正精度を向上
- Hashlineは16モデル中14モデルで従来方式より高い精度を示し、平均20〜30%のトークン削減効果も確認
- 特にGrok Code Fast 1モデルは成功率が6.7%から68.3%へ急上昇し、単純なハーネス変更だけで10倍改善
- この研究は、モデル自体より**「ハーネス(harness)」が実際の性能のボトルネック**であることを示し、オープンソース生態系での協調の必要性を強調
コード編集ベンチマーク概要
- 実験はPatch、Replace、Hashlineの3つの編集フォーマットを比較する形で実施
- 16モデルを対象に同一のコード修正課題を実行
- 各モデルはReactコードベースでランダムに選ばれたファイルのバグを修正する形でテスト
- Hashlineフォーマットは14モデルでPatchより優れた結果を示し、平均で20〜30%のトークンを節約
- 最大の改善はGrok Code Fast 1モデルで、成功率が6.7%から68.3%に上昇（+61.6pp）
- Gemini 3 Flashは5.0pp、Claude Sonnet 4.5は1.6pp改善
ハーネス(harness)問題
- 現在の議論は主に「どのモデルが最もコーディングに強いか」に集中しているが、実際のボトルネックはモデルではなくハーネス
- ハーネスは入力トークンを管理し、モデル出力とワークスペース変更をつなぐ中核インターフェース
- 失敗の大半はモデルではなく、ハーネスの構造的限界から発生
- 著者はオープンソースのコーディングエージェントPiをフォークした個人プロジェクトoh-my-piを通じて約1,300件のコミットを行い、改善を試みた
- この環境はモデルに依存せず、ハーネスだけを変数として実験可能
既存の編集ツールの限界
- **Codexの
apply_patch**方式はOpenAI専用のdiffフォーマットを使うため、他モデルでは失敗率が高い
- 例: Grok 4のパッチ失敗率は50.7%、GLM-4.7は46.2%
- **Claude Codeの
str_replace**方式は文字列の完全一致が必要なため、空白やインデントの違いでエラーが発生
- 「String to replace not found in file」エラーがGitHubで多数報告
- Cursorは別の70Bモデルを訓練してマージを処理しているが、400行以下のファイルでは全体再書き換え(full rewrite)のほうが良い結果を示す
- JetBrainsのDiff-XYZ、EDIT-Bench研究でも、編集フォーマットによって性能が大きく変わることが確認
Hashline方式の原理
- 各コード行に2〜3文字長のコンテンツハッシュを付与し、モデルが修正対象を明確に指定できるようにする
- 例:
22:f1| return "world";
- モデルは「replace line 2:f1」のようにハッシュを基準に修正を要求
- ファイルが変更されてハッシュが一致しない場合は修正を拒否し、破損を防止
- この方式ではモデルが既存内容を再現する必要がないため、空白・インデントの誤りを減らし、安定した修正が可能
ベンチマーク結果
- テストは180件のバグ修正課題、3回反復、4つのツール(read, edit, write, etc.)で構成
- 結果としてPatchフォーマットはほぼすべてのモデルで最悪、HashlineはReplaceと同等またはそれ以上
- モデルが弱いほど改善幅が大きい
- Grok 4 Fastは出力トークンが61%減少し、MiniMaxは2倍以上改善
- **Geminiの成功率+8%**は一般的なモデルアップグレードより大きな改善幅であり、追加学習なしで達成
ベンダー方針とオープンソース生態系
- AnthropicはオープンソースのコーディングエージェントOpenCodeによるClaude Codeへのアクセスを遮断
- 理由は「非公開APIのリバースエンジニアリング」だが、結果として「自社ハーネスだけを使え」というシグナルと受け取られている
- Googleは著者のアカウントを停止し、Geminiへのアクセスを遮断
- Hashline適用によりGemini 3 Flashの性能が78.3%に向上したベンチマーク直後に発生
- 著者はこうした措置がモデル改善の機会を遮断する逆行的な行為だと指摘
- ハーネス最適化は特定モデルだけでなく、すべてのモデルの品質を高める公共的研究に当たる
- 「モデルは堀、ハーネスは橋」という表現で、閉鎖的アプローチが生態系の発展を妨げると強調
結論
- ハーネスの問題は測定可能で、実際の性能に直接影響する要因であることが確認された
- 単純なフォーマット変更だけでも、モデルアップグレードに匹敵する改善効果を得られる
- 今後の発展の方向性は単一企業による閉鎖的改善ではなく、コミュニティベースの公開協調であるべき
- すべてのコード、ベンチマーク、実行結果はGitHubリポジトリoh-my-piで公開
3件のコメント
モデルがおかしいのに、なぜまたプロンプトエンジニアリングを……
ハーネスとプロンプトエンジニアリングは、まったく別の話です。
Hacker Newsの意見
この記事は本当に興味深く読んだ。著者はまさに核心を突いていると思う。
今あるモデルでさえ、エージェント・ハーネス（harness） をどう設計するかによって、はるかに効率的にできる余地が大きい。
私は「AI」を単なるLLMそのものとしてではなく、LLMとハーネスがフィードバックループで結ばれたサイバネティック・システム全体として見るのが正しいと思う。
モデルとハーネスは互いを強化しながら共進化する構造なので、どちらも等しく重要だ。
こうした視点は単なる性能向上にとどまらず、生成AIをニューロシンボリック（neurosymbolic） なプロジェクトとして再解釈させてくれる
実際、私は2023年版のGPT-4でコーディングエージェントを作った。
古いモデルで作業するとシンプルさを保たなければならないので、むしろ問題を別の見方で捉えるようになる。
たとえばPythonでは、
grep -r def .のような単純なsemantic compressionが不可欠だ。Claude Codeのようなツールにこうした簡単なフックを追加すれば、トークンを浪費せずにコード構造をすぐ把握できる
わずか数時間のプロンプト調整と応答処理コードだけでも、小さなローカルモデルの出力品質は驚くほど改善する
GitHubリンク
OpenAIはGPT-5.3-Codexの初期版で自社の訓練プロセスをデバッグし、デプロイを管理した。
Claude Codeは1日に20件を超えるPRをすべて自前のコード生成だけで提出している
実際、どのモデルが優れたコンテキストエンジニアリングに敏感なのかすら、まだよく分かっていない。
ただ、低いところにぶら下がった果実（low hanging fruit） がまだたくさんあるという点には同意する
この技術は興味深いが、過大評価されている感じがある。
筆者は自分が作った単純なfind/replaceベンチマークで5%の改善を見て、まるで全体性能が14ポイント上がったかのように語っている。
実際には、全体のトークン効率で見れば1%未満の改善にすぎない可能性が高い。
しかも、記事の大げさな口調とChatGPT特有の文体が信頼性を下げている
この記事は、ハーネスのレベルでどれほど改善の余地が大きいかをよく示している。
エージェントは編集、サンドボックス、ツール呼び出し間のデータ受け渡しなどで大量のトークンを無駄にしている。
コンテンツベースのアドレッシング + 行番号付けの組み合わせは実用的で美しい
初期開発は楽になるが、不必要に巨大なモデルを呼ぶことになって非効率だ
CCでは
/costコマンドでセッションごとの費用を確認できるので、こうした指標でプラグイン効率を評価するのがよいハーネスの重要性は、多くの人が思っているよりはるかに大きい。
たとえば、OpusのCOREベンチマークのスコアは、自前のハーネスからClaude Codeに切り替えたところほぼ2倍になった
関連リンク
TerminalBenchの最高スコアはTerminus 2ハーネスのおかげだったと説明している
月額20ドルのサブスクリプションのせいで特定のハーネスに縛られるのは不合理だ
私はtilthというツールを作って、ハッシュベースの読み取り/編集方式を実装した。
npmとcargoでインストールでき、Claude CodeやCursorのようなエディタと連携する。
GitHubリンク
目標は、LLMがツールをより効率的に使い、トークンの無駄を減らすことだ
私も似た方法を独自に考案したが、抽象化への依存のために断念した。
その代わり、Damerau-Levenshtein距離を使って編集類似度を計算し、一定のしきい値以上なら修正を通すようにした。
こうすると、モデルが置き換えるソーストークンを明示的に出力することになり、精度が高まる
コード例
肝心なのはエラーメッセージが具体的であることだ — 「Content mismatch. Reread the file」のように復旧指示を含んだエラー処理が重要になる。
この方式は4Bモデルでもうまく動作し、ツールコールをサポートしないモデルに対してはシステムプロンプト注入ハックで対処している
関連コード
以前のモデルでもかなり正確な結果を得ることはできた。
核心は、モデルを**「正しく扱うこと」だった。
この記事は、モデルが単なるテキストではなくソースコードの構造表現（AST）** を直接扱えれば、さらに大きな成果が得られることを示唆している。
たとえばOpenRewriteは、コードの型、フォーマット、依存関係の情報をすべて含んだLossless Semantic Treeを使っている。
こうした構造をモデルが活用できれば、不必要なトークン消費なしに非常に正確な修正が可能になる。
結局のところ、「Vim vs Emacs」論争の答えが「IntelliJ」になるのと同じで、構造的情報は強力な武器だ。
もしモデルがコードと文書、そして構文/意味木を一緒に学習するなら、本当の意味でのニューロシンボリックなコーディングモデルになるだろう
私はEmacsのgptelでLLMを試していて、LLMがUnixのpatchツールでコード修正するのが苦手だと気づいた。
そこでEmacsのtree-sitterを活用して、gptel用のツールを自作した。
tree_sitter_list_nodes、tree_sitter_update_nodesのようなコマンドでASTノードを直接修正させたところ、完璧に動作したCodexの
apply_patchは、実際には制約付きサンプリングスキーマを使っている。関連コード
筆者はこれを知らずに単純比較をしているので、より現実的なベンチマークはこのスキーマを有効にした状態で行うべきだ
この記事の引用の中で、とくに印象的だった部分がある。
「モデルが問題を理解していないのではなく、表現が不安定なのだ。着陸装置の問題をパイロットのせいにするな。」
「モデルはmoat、ハーネスはbridgeだ。」
「優れたデモと信頼できるツールの違いは、魔法ではなく地味だが精密なエンジニアリングだ。」