「一晩で15機種のLLMをコーディング性能向上―変えたのはハーネスのみ」

実際に変わったのは編集ツールだけです。そういうことです。

---

0x0: 間違った質問

今現在の会話はほぼ「どのモデルがコーディングに最適か――GPT‑5.3かOpus、Geminiかその他の新登場モデル」について語られています。この枠組みはますます誤解を招きやすく、モデルだけが重要な変数であると捉えてしまいます。実際にはボトルネックの一つはもっと平凡なもの――**ハーネス（仕掛け）**です。

ハーネスはユーザーに最初の印象を与えるだけでなく、すべての入力トークンの源泉であり、出力とワークスペース上の変更とのインターフェースでもあります。

私は「oh‑my‑pi」という小さな“趣味用ハーネス」を維持しています。これは Mario Zechner のオープンソースコーディングエージェント Pi をフォークしたもので、現在まで約 1,300 コミットを行いました。主に痛点を見つけてそこに Rust（N‑API 経由）を埋め込むことで「rg の spawn が不自然だ」という感覚を解消しつつ、段階的な改善を加えています。

どうしてそれが必要なのか？
Opus は優れたモデルですが Claude Code はサブエージェントの出力から生の JSONL を漏らし、数十万トークンを無駄に消費します。私は「やるべきことはこれだ」と言いたいだけです――ツールスキーマ、エラーメッセージ、状態管理―モデルが何を変えるか知っているところと問題が解決するまでの間のすべてです。ここでほぼ失敗が起こります。

モデルに依存しないため、テストベッドとしては最適です。モデルは単なるパラメータに過ぎません。本当に変数なのはハーネス――そこに想像を超える制御力があります。

さて、ここで昨日変更した一つの変数について説明します。その前に、現在の技術水準を理解しておく価値があります。

• Codex は

  apply_patch

  を使います。入力は文字列―実質的には OpenAI 風の diff です。構造化されたスキーマではなく、このブロブが厳格なルールに従うことをハーネスが期待します。OpenAI の人々は間違いなく賢く、トークン選択プロセスは Codex バリアントの GPT でこの構造に合わせてバイアスされていると私は確信しています。JSON スキーマや必須ツール呼び出しなど他の制約も同様です。

• しかし、この手法を他のモデルに与えると、全くそれを知らないためパッチ失敗率が急上昇します。私のベンチマークでは Grok 4 のパッチ失敗率は 50.7%、GLM‑4.7 は 46.2% でした。悪いモデルではなく、単に「言語」を話せないだけです。

• Claude Code（および多くの他社）では

  str_replace

  を使います：正確な古いテキストを見つけて新しいものと差し替えるというシンプルな考え方。しかしモデルは空白やインデントを含め、文字一つでも完全に再現する必要があります。複数一致した場合は拒否されます。「ファイル内で置換対象が見つからない」というエラーは非常に頻繁で、GitHub の問題スレッドに 27 個以上の関連トピックがあります。最適ではありません。

• Gemini は基本的には同じことを行い、さらにわずかな空白マッチングも加えます。

• Cursor は別途ニューラルネットワーク（70B の微調整済みモデル）を訓練し、ドラフト編集を正しくファイルに統合します。ハーネス問題は非常に難解であるため、最も資金力のある AI 企業の一つが別モデルを投入しました。それでもブログ記事では「400 行未満のファイルでは完全再作成が差分より優れている」と言及しています。

• Aider のベンチマークによると、フォーマットだけで GPT‑4 Turbo が 26% から 59% に跳ね上がり、GPT‑3.5 は同じフォーマットで 19% としか得られませんでした。これはモデルの信頼性を維持できなかったためです。フォーマットはモデルと同じくらい重要です。

JetBrains の Diff‑XYZ ベンチマークもこの事実を裏付けています：単一の編集フォーマットがすべてのモデルやユースケースで支配的になることはありません。EDIT‑Bench では、現実的な編集タスクで 60% を超えるパス@1 を達成したのはわずか一つのモデルだけです。

結論として、「何をどう変えるか？」という単純な問題に対して「最高の解決策」が存在しないことが分かります。私の 5c は、これらのツールはいずれもモデルに「変更したい行」を安定的・検証可能な識別子で渡せず、膨大なコンテキストを浪費し、完全再現に頼っている点です。モデルがそれを再現できない場合、ユーザーはその失敗をモデルの責任とします。

---

0x2: ハッシュライン！

ここで想像してみてください：モデルがファイルを読み込むか検索する際、各行に 2〜3 桁のコンテンツハッシュがタグ付けされます。

11:a3 | function hello() {
22:f1 |   return "world";
33:0e | }

モデルは編集時に「行 2:f1 を置換する」「範囲 1:a3 から 3:0e までを置換する」「3:0e の後に挿入する」などとタグを参照します。ファイルが最後の読み込み以降に変更されていれば、ハッシュは一致せず編集が拒否されます。

もしモデルが疑似ランダムなタグを記憶できるなら、何を編集中か知っている可能性が高くなります。その場合、古いコンテンツや空白まで再現する必要がなくなり、信頼できる「アンカー」を持つ形で変更を表現できます。

---

0x3: ベンチマーク

実際のパフォーマンスに焦点を当てたため、以下の手順でテストデータを生成しました：

1. React コードベースからランダムなファイルを選択。
2. バグ（演算子交換、ブールフリップ、オフバイワンエラー、optional チェーン除去、識別子のリネームなど）として変異を挿入。逆操作が期待できる編集を行います。
3. 問題の説明を英語で生成。

平均的なタスク記述例：

1 # useCommitFilteringAndNavigation.js のバグ修正
2
3 早期リターン（ガード節）が削除されている。
4 問題は useCommitFilteringAndNavigation 関数にある。
5 ガード節を復元せよ（if 文で early return）。

100% 成功率は期待できません。モデルが独自の解決策を提示する可能性もあります。しかし、バグは機械的なので、多くの場合修正は挿入した変異を取り消すことです。

• タスクごとに 3 回実行、1 実行あたり 180 タスク。
• 各実行で新しいエージェントセッションを作成し、4 つのツール（read, edit, write）を使用。
• 一時ワークスペースを渡しプロンプトを与え、エージェントが停止したら元ファイルと整形後ファイルを比較。

16 のモデル、3 の編集ツールで結果は明確です：patch はほぼすべてのモデルで最悪のフォーマット。hashline は replace を上回るか同等に機能し、弱いモデルほど改善効果が大きくなります。Grok Code Fast 1 は 6.7% から 68.3% に飛躍的向上（パッチ失敗率の劇的低下で実際のコーディング能力を明らかに）。MiniMax は倍以上に成長。Grok 4 Fast の出力トークンは 61% 減少し、再試行ループでの消費が減少しました。

---

0x4: 何が得られた？

Gemini の成功率を +8% 改善することは、多くのモデルアップグレードよりも大きな成果です。しかも、トレーニング計算量はゼロ――数百ドル（約 $300）でベンチマーク実行しただけです。

多くの場合、モデル自体がタスクを理解することに不安定さはありません。「表現方法」が不安定なのです。あなたはパイロットに着陸装置の責任を押し付けているようなものです。

---

0x5: ベンダーについて少し

Anthropic は最近、非常に人気のあるオープンソースコーディングエージェント OpenCode が Claude をサブスクライブ経由で利用できないようにしました。Anthropic の主張は「OpenCode が非公開 API を逆解析した」というものです。表面上は妥当ですが、実際の意図は「ハーネスを作るな、自社のやつを使え」と言っているのではないでしょうか。

Google も同様に、Gemini を完全にブロックしました――レート制限も警告もなく。ベンチマークを走らせたためです。そのベンチマークで Gemin 3 Flash は 78.3% の達成率を示し、独自手法で同社の最良試行より 5.0pp 上回っています。何故ブロックされたかは分かりません。

これは逆説的です。私は別の編集フォーマットが彼ら自身のモデルを 5〜14 ポイント改善し、出力トークンを約20%削減することを示しました。脅威ではなく、無料 R&D として歓迎すべき成果です。

競合他社のモデルにハーネス最適化を行う企業はほとんどありません。Anthropic は Grok をチューニングしません。xAI は Gemini をチューニングしません。OpenAI は Claude をチューニングしません。しかし、オープンソースのハーネスはすべてに対応します。貢献者が自分のモデルで直面した失敗を修正していくからです。

モデルは防波堤です。ハーネスは橋です。橋を燃やせば、通過しようとする人は減ります。ハーネスを「解決済み」または「重要でない」と見なすのは短絡的です。

私はゲームセキュリティの背景があります。チートはエコシステムに甚大な被害を与えます。追跡・禁止・訴訟を受けることもありますが、最終的には「どうやって回避したか」を教えてくれるという秘密があります。そして防御側はそれを採用します。

API を改ざんし、多数のフォロワーを集めたツールを持つ人に対する正しい対応は「もっと詳しく教えてほしい」であり、単なる大量ブロックではありません。

ハーネス問題は実在し、測定可能で、今最も高いレバレッジポイントです。 “クールなデモ” と “信頼できるツール” のギャップはモデルのマジックではなく、ツール境界での慎重かつ退屈な実証工学によって解決されます。

ハーネス問題は解決されるでしょう。
質問は、それが一社のプライベートプロジェクトとして解決されるのか、あるいはコミュニティ主導でオープンにすべてのモデルへ拡張されるのかです。

---

全コード・ベンチマーク・実行レポート：oh‑my‑pi