LLMコーディングハーネス最適化 — モデルではなくハーネスを変えて15モデルの性能向上

概要

「どのLLMがコーディングを一番うまくこなすのか？」

エンジニアリングチームでこの質問が繰り返されるたびに、私たちは重要な変数を一つ見落としています。それはハーネス（harness）です。ハーネスとは、LLMがファイルを読み込み、プロンプトを受け取り、編集を適用するインターフェースレイヤー全体を指します。

2026年2月、Can Bolukが発表した「I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed」は、このハーネス問題を正面から取り上げています。編集フォーマットを一つ変えただけで、15個のLLMのコーディング性能が5〜14ポイント向上し、出力トークンは約20%削減されたというのです。

graph TD
    subgraph 従来の認識
        A["モデルA vs モデルB<br/>どちらが優れているか？"]
    end
    subgraph 実際の性能決定要因
        B["モデル"] ~~~ C["ハーネス"]
        C --> D["編集フォーマット"]
        C --> E["コンテキスト注入"]
        C --> F["ミドルウェア"]
    end
    A -.->|"視点の転換"| C

この記事では、ハーネスエンジニアリングの概念、ベンチマークデータ、そしてEngineering Manager/CTOの観点からの実務適用戦略を整理します。

ハーネス（Harness）とは何か

ハーネスとは、LLMと実際のコードの間にあるすべてのインフラを意味します。

構成要素	説明	例
編集フォーマット	モデルがコードを修正する方式	diff, string_replace, hashline
システムプロンプト	モデルに与えられる指示事項	自己検証ループ、問題解決戦略
ツールインターフェース	モデルが使用するツール定義	read_file, edit_file, run_test
コンテキスト注入	環境情報の事前提供	ディレクトリ構造、評価基準
ミドルウェア	実行フロー制御	ループ検知、完了前検証

核心はこれです：同じモデルでもハーネスによって性能が劇的に変わります。

Aiderベンチマークで編集フォーマットだけを変えた際、GPT-4 Turboの精度が26%から59%へ跳ね上がった事例がこれを証明しています。

3つの編集フォーマット比較

現在の主要AIコーディングツールは、それぞれ異なる編集フォーマットを使用しています。

1. apply_patch（OpenAI Codex方式）

OpenAIがCodexで使用するdiffベースのパッチフォーマットです。モデルが修正内容をunified diff形式で出力し、ハーネスがこれをパースしてファイルに適用します。

メリット：diffに慣れたモデルは安定して動作します。 デメリット：diffフォーマットの学習が不足しているモデルでは高い失敗率を示します。Grok 4は50.7%の失敗率を記録しました。

2. string_replace（Claude Code、Gemini方式）

検索文字列と置換文字列を正確に指定する方式です。Claude Codeのstr_replaceツールが代表的です。

メリット：直感的で実装がシンプルです。 デメリット：スペース一つ、インデント一つでも間違えると「String to replace not found」エラーが発生します。完全な文字列の再現が求められます。

3. hashline（新しいアプローチ）

Can Bolukが提案した方式で、ファイルの各行に2〜3桁のコンテンツハッシュを付与します。

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

モデルはソースコード全体を再現する代わりに、ハッシュタグを参照して修正位置を指定します。「行2:f1を置換」や「3:0eの後に挿入」といった方式です。

メリット：

• 完全な文字列の再現が不要 → エラー削減
• ファイル状態が変更されるとハッシュ不一致で自動検知 → コンフリクト防止
• 出力トークン約20%削減

デメリット：すべてのモデルで同一の効果を保証するわけではありません（GPT-3.5はハッシュの再現自体に困難を示します）。

ベンチマーク結果が示すもの

Can Bolukのベンチマークは、180個のタスクを16モデル × 3編集フォーマットでそれぞれ3回実行した結果です。

モデル	既存フォーマット	hashlineフォーマット	改善幅
Grok Code Fast 1	6.7%	68.3%	+61.6pp
Gemini 3 Flash	—	78.3%	—
Grok 4	低い	向上	出力トークン61%削減
MiniMax	—	2倍向上	—

Grok Code Fast 1のケースが特に衝撃的です。モデル自体は同じなのに、編集フォーマットを変えただけで6.7%から68.3%へ10倍向上したのです。これがハーネスエンジニアリングのポテンシャルです。

Cursorの認識

この問題の深刻さを最もよく示す事例はCursorです。Cursorは編集失敗を修正するために別途70Bパラメータのニューラルネットワークをデプロイしました。編集フォーマットの問題を認め、それを補完するために一つの大規模モデルを追加投入したのです。

ハーネスエンジニアリング実践事例：LangChainのTerminal Bench

ハーネス最適化の実際の効果を示すもう一つの事例があります。LangChainチームはTerminal Bench 2.0でモデルを交換せずハーネスのみを最適化し、52.8%から66.5%へ13.7ポイント向上させました。リーダーボードのTop 30からTop 5へ躍進したのです。

彼らが使用したハーネス最適化手法は3つでした：

graph TD
    subgraph ハーネス最適化3層
        A["システムプロンプト<br/>自己検証ループの強調"]
        B["コンテキスト注入<br/>環境情報の事前提供"]
        C["ミドルウェア<br/>ループ検知、完了前検証"]
    end
    A --> D["52.8% → 66.5%"]
    B --> D
    C --> D

1. 自己検証ループ

エージェントは最初のもっともらしいソリューションですぐに終了しようとする傾向があります。LangChainは「ビルド-検証-修正」ループをシステムプロンプト、コンテキスト注入、ミドルウェアの3層すべてで強制しました。

2. 推論コンピュート配分戦略（“Reasoning Sandwich”）

すべてのステップに均一に高い推論を割り当てる代わりに、戦略的に配分しました：

• 計画フェーズ：最高レベル（xhigh）
• 実装フェーズ：高い（high）
• 検証フェーズ：最高レベル（xhigh）

この「サンドイッチ」戦略が均一なxhigh推論よりより良い結果を出しました。タイムアウト制約の中で推論リソースを賢く配分したのです。

3. 環境オンボーディング

エージェントに対して新入エンジニアに接するように環境情報を事前提供しました：

• 使用可能なツール一覧
• ディレクトリ構造
• 評価基準
• 時間制限

このようにすることで、エージェントが環境を探索するために時間を浪費することを防げます。

EM/CTOが注目すべき3つの示唆

1. モデル交換よりハーネス最適化のROIが高い可能性がある

新しいモデルがリリースされるたびにベンダーを切り替えるよりも、現行モデルのハーネスを最適化する方がコスト対効果が大きい可能性があります。モデル交換はAPIキー、プロンプトフォーマット、トークン制限などすべてを再調整する必要がありますが、ハーネス最適化は既存インフラの上で段階的に改善可能です。

2. オープンソースハーネスがベンダーロックインより優れている可能性がある

Can Bolukの核心的な主張の一つ：オープンソースハーネスはコミュニティの多様なモデルユーザーがそれぞれ遭遇する失敗を修正するため、特定ベンダー専用ハーネスより汎用的により良い性能を発揮します。

一方、AnthropicがOpenCodeをブロックし、Googleが著者のGeminiアカウントを無効化した事例は、ベンダーロックインのリスクを示しています。

3.「クールなデモ」と「信頼できるツール」の間のギャップ

“The gap between ‘cool demo’ and ‘reliable tool’ isn’t model magic. It’s careful, rather boring, empirical engineering at the tool boundary.” — Can Boluk

CTOとしてAIコーディングツールを評価する際、デモで見せる華やかなコード生成よりも実際の編集成功率、リトライ比率、トークン効率を測定すべきです。

実務適用ガイド

チームレベルで実行できること

1. 編集成功率の測定：AIコーディングツールの編集試行に対する成功率を追跡します。「String not found」エラーが頻発するならハーネスの問題です。

2. ミドルウェアの導入：ループ検知、完了前検証、コンテキスト自動注入などのミドルウェアを追加します。

3. 推論戦略の分化：計画-実装-検証の各フェーズに異なる推論レベルを割り当てます。

4. トレースベースのデバッグ：LangSmithのようなツールでエージェントのすべてのアクション、遅延、トークン消費を追跡し、体系的に改善します。

HNコミュニティで共有された実務ツール

ツール	用途	アプローチ
Serena	コードインテリジェンス	ASTベースの構造分析
RepoMapper	コードベースマッピング	ディレクトリ構造の可視化
Tilth	編集ツール	ラインハッシュ + セマンティックセクション（17〜25%コスト削減）
Tree-sitter統合	AST認識編集	ラウンドトリップの大幅削減

まとめ

2026年のAIコーディングツール競争で勝敗を分けるのは「どのモデルを使うか」だけではありません。そのモデルの上にどのようなハーネスを構築するかが実質的な性能差を生み出します。

• 編集フォーマット一つで6.7% → 68.3%（10倍向上）
• ハーネス最適化だけでTop 30 → Top 5（13.7ポイント）
• 出力トークン20〜61%削減

Engineering ManagerとしてチームのAIコーディング生産性を高めたいのであれば、次のモデルリリースを待つ前に現行ハーネスの編集成功率から測定してみましょう。その数字が意外と多くのことを教えてくれるはずです。

参考資料

• I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed — Can Boluk
• Harness Engineering for Agentic Coding Systems — ZenML
• Hacker News Discussion
• Addy Osmani’s LLM Coding Workflow 2026