午後のうちに15のLLMのコーディング能力を向上させる。変わったのはハーネスだけ。

102日前原文(blog.can.ac)

概要

コーディングAIの性能議論は モデル選択 ばかりに偏りがち。
実際には ハーネス（編集ツール） がボトルネックとなるケースが多い。
編集ツールの工夫だけで 大幅な性能向上 が可能。
ベンチマークで 編集方式の違い が成功率に大きく影響。
ハーネス最適化は モデル進化以上の価値 を持つ場合も多い。

モデル性能議論の誤謬とハーネスの重要性

コーディングAIの比較議論は GPT-5.3対Opus、Gemini対最新モデル といったモデル中心主義。
実際のボトルネックは ハーネス（編集ツールやインターフェース） である場合が多い。
ハーネスは ユーザー体験の第一印象 や 入力・出力の全て を担う基盤。
モデルは パラメータの一つ に過ぎず、ハーネス次第で性能が大きく変化。
oh-my-pi のようなオープンソースハーネスでの実験が有効。
- Opusは優秀なモデルだが、 Claude Code ではサブエージェント出力のJSONL漏れでトークン無駄遣い。
- ハーネス側で 構造化データ出力 や エラー管理 を実装可能。
- 実際の失敗の多くは ハーネスとモデルの橋渡し部分 で発生。

編集ツールの現状と課題

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”エラーが多発。
Cursor は編集専用のニューラルネットワークを別途訓練。
- 400行以下なら 全ファイル再書き換えが最適 と自社ブログでも言及。
編集フォーマットの違いだけで GPT-4 Turboの成功率が26%→59% に上昇。
- フォーマット選択が モデルと同等またはそれ以上に重要。
JetBrainsのDiff-XYZベンチマーク でも、単一の編集フォーマットが全てに最適とは限らないと判明。

新提案：Hashline方式

各行に 2～3桁の内容ハッシュ を付与する方式を考案。
- 例：11:a3|function hello() { 22:f1| return "world"; 33:0e|}
編集時はハッシュタグで 編集対象行を明示。
- 例：「2:f1の行を置換」「1:a3～3:0eの範囲を置換」など。
- ファイルが変更されてハッシュが合わなければ 編集拒否 で破損防止。
モデルは 古い内容や空白の再現不要 で信頼性向上。
編集のアンカー として機能し、誤編集や失敗の大幅削減。

ベンチマーク結果

Reactコードベースからランダムにファイル抽出し、 機械的なバグ を導入。
180タスク×3回、16モデル、3編集ツールで検証。
patch方式はほぼ全モデルで最悪、hashline方式はreplace方式と同等以上の成功率。
Grok Code Fast 1は6.7%→68.3% へ、MiniMaxも2倍以上に向上。
出力トークン数も大幅減少 （Grok 4 Fastで61%減）。
Geminiの成功率+8% は多くのモデルアップグレードより大きな改善。

ベンダーとハーネスの関係

Anthropic は人気オープンソースエージェントOpenCodeを Claude Codeから遮断。
- 「独自APIのリバースエンジニアリング」への対応だが、 ハーネス開発の抑制 を意味。
Google もGeminiアカウントを 即時停止 （ベンチマーク実施が理由か不明）。
ハーネス最適化は モデルベンダーにとっても無料のR&D であり、閉鎖的対応は逆効果。
オープンソースハーネスは 全モデルに最適化 可能、コミュニティ主導で進化。
モデルは堀、ハーネスは橋。橋を焼けば誰も渡らなくなる。

結論とメッセージ

ハーネス問題は 現実的・計測可能・最もレバレッジの高い革新領域。
「カッコいいデモ」と「信頼できるツール」の差は モデルの魔法ではなく、地道なハーネス工学。
ハーネス問題は必ず解決されるが、 一社内で閉じて解決するか、コミュニティ全体で解決するかが分かれ道。
ベンチマーク結果が全てを語る。
詳細なコード・ベンチマーク・レポートは oh-my-pi を参照。

Hackerたちの意見

ハーネスは、ほとんどの人が思っている以上に重要なんだよね。このCOREベンチマークについての投稿では、Opusのスコアが自分たちのハーネスからClaude Codeに切り替えたらほぼ倍増したって話だよ。 https://x.com/sayashk/status/1996334941832089732

└

だからこそ、自由に変更できたり、自分で作ったりできるべきだと思うんだ。月20ドル払って特定のハーネスに縛られるのは、ちょっとアホらしいよね。

└

Piターミナルエージェントのクリエイター、マリオが素晴らしいブログ記事を書いてるよ[0]。彼は、TerminalBenchの最高スコアがtmuxを使っているTerminus 2ハーネスから来ているって話してる。Opus 4.6のローンチ投稿を読んでたときも、同じことが言及されていて、彼らのTerminalBenchスコアはTerminus 2を使ったもので、CCではなかったんだ。 https://mariozechner.at/posts/2025-11-30-pi-coding-agent/

ハーネスレベルでの改善の余地がどれだけあるかを示してるね。エージェントは編集やサンドボックス、ツールコールやサブエージェントとの情報のやり取りに多くのトークンを無駄にしてる。コンテンツベースのアドレッシングと行番号の実用的な組み合わせが好き。美しいね。

└

記事にはまだ詳しく目を通してないけど、君のコメントでClaudeCode Superpowersプラグインを思い出したよ。プラグインは素晴らしいと思うけど、結構「高い」んだよね。個人的に試してるからCCの従量課金アカウントを使ってるけど、スーパーパワープラグインは普通のCCに比べてお金がかかる。CCではセッションのコストをドルで確認できる/costコマンドがあって、プラグインやエージェント用の.mdファイルなんかの良いベンチマークになると思う。LLMのコストを、コンピュータのCPUやRAM、ストレージのような典型的なリソース使用を最小限に抑える方法で抑えるべきだね。

└

実際、逆にもっとトークンを使って複雑な問題（マルチエージェント）を解決することもできるよ。エージェントが小さな問題に取り組むことでね。

└

確かに。最大の無駄は、すべてにMCPを過剰に使うことかもしれないね。初期の開発は楽になるけど、その後は接続ごとに何百億ドルもするパラメータモデルを使って、どう呼び出すかを決めるのはほとんど必要ないことが多いし、ランダムなエラーも起こりやすい。MCPは、文字通りすべてを釘のように見せるハンマーみたいなもんだね…

いい投稿だね。いくつかの選りすぐりの引用:

「モデルはタスクを理解するのが不安定なわけじゃない。自分を表現するのが不安定なんだ。着陸装置のためにパイロットを責めてるようなもんだ。」「モデルが堀で、ハーネスが橋だ。橋を燃やすってことは、渡る人が減るだけだ。ハーネスを解決済み、あるいは重要でないと扱うのは非常に短絡的だ。」「『クールなデモ』と『信頼できるツール』の間のギャップは、モデルの魔法じゃない。ツールの境界での慎重で、ちょっと退屈な経験的エンジニアリングなんだ。」

└

その通りだね！これは普通のエンジニアリングアドバイスじゃない—著者の思考を鮮やかに描いたタペストリーみたいだ。

└

私のお気に入り: 「それは脅威じゃないよ。無料の研究開発さ。」

この記事、めっちゃ楽しめた！著者の言ってることは本当にその通りだと思うし、前からずっと言ってきたことなんだ。今あるモデルの効果を大幅に向上させる、すごく面白い低いところにぶら下がってる果実がたくさんあるよ。新しいモデルを訓練するよりも、少なくとも収穫逓減に達するまでは、同じくらい、いやそれ以上の違いを生むことができるんじゃないかな。少なくとも私にとっては、「AI」を単なるLLMだけじゃなくて、LLMとそのハーネスを結ぶフィードバックループの全体的なサイバネティックシステムとして考える方がいいってことが確認できたと思う。ハーネスが改善されれば、モデル自体の改善と同じくらい、もしくはそれ以上の違いを生む可能性があるから、ハーネスも同じくらい重要視しなきゃいけないよね。モデルはハーネスを使うように強化学習されていて、ハーネスはモデルの一般的なニーズや特定のモデルに合わせて適応されるから、必然的にフィードバックループの中で一緒に発展していくんだ。そして実際に運用されるとき、それは有用な作業を実際に行うエンティティが、二つの完全なシステムの組み合わせであることを示す、深く絡み合ったフィードバックループになる。こう考えることで、このブログ記事で話されているような定量的なパフォーマンス向上を実現できるだけでなく、生成AIプロジェクトを実際には神経シンボリックAIのプロジェクトとして捉える手助けにもなると思う。たとえ最も資本集約的で新しい側面がニューラルネットワークであってもね。そして、そう考え始めると、新しい選択肢やよりホリスティックな思考が開けて、ハーネスの分野での研究も増えるかもしれない。

└

そうそう、私が「XだけじゃなくてY」って言うことが多いのは知ってるよね。これ、完全に人間が書いたコメントだから！ただ、すごく疲れてて、そういう決まり文句に頼りがちなんだ。信じて、LLMが登場するずっと前からこんな風に書いてたよ。

└

「モデル」をスタックの一部として見るようになると、システムのラインをユーザーも含めることができるって気づくよね。そこで未来が本当に迫ってくるんだ。

└

あなたのコメント、深いね。友達のために聞くけど、どうやってキーボードにエムダッシュ — を入れたの？

└

確か、Claude CodeとOpenAI Codexの「ハーネス」は今、自分たちを改善しているよね。OpenAIはGPT-5.3-Codexの初期バージョンを使って、自分のトレーニングプロセスをデバッグしたり、デプロイやスケーリングを管理したり、テスト結果や評価データを診断したりしてた。Claude Codeは、1日に22件のPRを出して、前の日には27件も出して、各PRの100%のコードがClaude Codeによって完全に生成されたんだ。

└

2026年はハーネスの年だね。

Emacsでgptelを使った最初のLLM実験のとき、LLMがUnixのパッチツールでソースコードファイルを変更するのにかなり苦労していることに気づいたよ。Emacsには組み込みのtree-sitterパッケージがあるから、同じアイデアを実装したんだ。tree_sitter_list_nodes、tree_sitter_get_nodes、tree_sitter_update_nodes、tree_sitter_insert_before_node、tree_sitter_insert_after_nodeみたいなgptelツールを作った。 "list"ツールは、最初の行番号、最初の行の内容、ノードハッシュを持つASTノードのリストを返す。LLMはその後、"get"を使って興味深いノードをすべて集めて、"update"でハッシュで特定されたノードのリストを新しい内容（変数/関数の本体）で更新できる。うまくいったよ。

└

面白そうだね、コードを共有してくれる？

ハーネスはモデルの「ボディ」で、その重さが認知なんだ。自然界のように、彼らは一緒に発展して、自然選択の繰り返しが両方に働く。もし小さなラボ（Zai、Moonshot、deepseek、mistralなど）が集まって、例えばオープンコードのようなハーネスを受け入れたら、「異なる環境での進化の力」で、より大きなラボよりも早くジャックポットを引くかもしれない。

└

でも、彼らはアメリカのリーダーモデルの出力を蒸留することに頼ってる。おそらく、自分たちのハーネスに対してトレーニングすることになるだろうね。基本的なトレーニング、開発、イノベーションを誰かがやらなきゃいけない。クローンだけじゃダメだよ。

この考え方の論理的な結末は、フロンティアラボの設立を破滅させる集団行動の問題だよ。モデルの能力を、注意トランスフォーマーがネストされた区切りをマッチさせたり、bashに対応したりすることに使うことはできないし、最大限の能力を発揮することもできない。認証、認可、コントロールプレーン、データプレーンを曖昧なスープに混ぜて、パイロットやおもちゃ以外のものに対して十分に安全でいることは無理だよ。これを進めていくと、「悪い方が良い」という逆説が逆転してることに気づく。これはアービトラージで、レースが始まってるんだ。

モデルの改善がどこまで進んでるかを見るのは面白いね。私がClaude 3.5の頃にコーディングハーネスを維持していた時、ハッシュプレフィックスや行番号プレフィックスなど、モデルが編集ブロックを選ぶのを良くするためにいろんなアプローチを試したけど、結局その時はファジーストリングマッチングが勝ったんだ。

ハーネスのボトルネックは本当に存在するよ。AIコードのセキュリティ関連の仕事をしているけど、一番の問題はモデルの能力じゃなくて、ほとんどのツールが出力を絶対的なものとして扱うことなんだ。提案された修正を、コンパイルできるかどうかも確認せずに適用しちゃうし、新しい脆弱性を生むかどうかも気にしない。1つのCVEを修正するパッチを見たけど、認証ロジックを完全に壊しちゃったこともある。編集ツールのポイントは確かにあるよ。モデルに変更を表現するためのより良いインターフェースを与えると（構造化されたdiffと自由形式のパッチ）、エラー率が下がる。でも、誰もこれについては話さないんだ。ベンチマークは「問題を解決できたか？」を測るだけで、「何回試したか？」や「失敗したときの影響範囲は？」を測らないから。もしかしたら、私はこれをデバッグしすぎてちょっと疲れちゃったのかも。

うん、2022年頃に情報抽出の帰属に似た方法を発明したよ。ドキュメントにカスタムマーカーを入れて、抽出モデルがそれを答えと一緒に参照できるようにして、ドキュメント内でユニークに位置を特定できるようにしたんだ。

ハクソク