LLMコーディング性能を語るとき、多くの人が「どのモデルが一番優秀か」という議論に終始しがちかもしれません。自分もそうでした。GPT-5.3とClaude Opus、どちらがコードを書くのが上手いか——そんな比較記事を読み漁っていた時期があります。

ところが最近、Hacker Newsで興味深い記事を見かけました。ある開発者が「15個のLLMのコーディング性能を1日で改善した。変えたのはハーネスだけ」と報告していたんですよね。これを読んで、自分の考え方がけっこう変わりました。

そもそも「ハーネス」って何のことなのか

ハーネスというのは、LLMとコードベースの間をつなぐ仕組みのことです。具体的には、モデルへの入力トークンをどう構成するか、モデルの出力をどうやってファイル編集に反映するか、エラーメッセージをどう返すか——こうした「つなぎ」の部分全体を指しています。

たとえば、コーディングエージェントにファイルを編集させる場面を想像してみてください。モデルが「この部分をこう変えたい」と判断しても、その意図を正確にファイル変更に落とし込む仕組みが雑だと、結果もおかしくなってしまいます。逆に、ハーネスが優秀なら、同じモデルでも出力品質がぐっと上がることがあるようです。

編集ツールの設計が性能を左右する仕組み

この開発者が具体的に改善したのは「編集ツール」の部分でした。コーディングエージェントがファイルを変更するとき、一般的にはdiff形式やパッチ形式で変更内容を指定します。しかし、この形式の設計によって、モデルの実力が活きるかどうかが大きく変わってくるみたいです。

たとえばOpenAIのCodexではapply_patchという独自のdiff形式を採用しています。一方で、Anthropicのエージェントは行番号ベースの置換を使っていたりと、各社アプローチが異なります。面白いのは、どの形式を採用するかで同じモデルの成功率が変わるという点です。

実際にこの開発者は、自作のコーディングエージェント「oh-my-pi」で編集ツールを改良したところ、テストしたすべてのモデルでスコアが向上したと報告しています。モデルのパラメータやアーキテクチャには一切手を加えていないわけですから、なかなか衝撃的な結果かなと思います。

なぜハーネスがここまで重要なのか

考えてみると、これは納得のいく話かもしれません。LLMは基本的にテキストの入出力しかできないので、外部世界とのやり取りはすべてハーネス経由になります。つまり、ハーネスの設計がボトルネックになっている場合、どれだけ優秀なモデルを使っても性能が頭打ちになる可能性があります。

もう少し具体的に言うと、以下のような要因が影響しているようです。

  • コンテキストウィンドウの使い方：無駄なトークンを送っていないか
  • エラーハンドリング：失敗時のフィードバックが的確か
  • ツール定義のスキーマ：モデルが意図を正しく表現できる設計か
  • 状態管理：前の操作結果を次の判断にうまく活かせているか

こうした部分は地味ですが、積み重なると大きな差になってきます。あるエージェントでは、サブエージェントの出力が生のJSONLとしてリークしていて、何十万トークンも無駄にしていたケースもあったそうです。

開発者にとっての実践的な示唆

この話から得られる教訓は、わりとシンプルかもしれません。「モデルを変える前に、ハーネスを見直そう」ということです。

最近はオープンソースのコーディングエージェントも増えてきているので、自分でハーネスをカスタマイズできる機会も増えています。たとえば、ツールの出力フォーマットを構造化データに変えるだけで、トークン効率が劇的に改善するケースがあるかもしれません。

また、ハーネスの改善はモデル非依存という点も魅力的です。一度良いハーネスを作れば、将来的にモデルが進化したときにもその恩恵を最大限に活かせるわけですから、投資対効果は高いのではないでしょうか。

モデル競争の裏にある見落とされがちな視点

AIコーディングの話題は、どうしてもモデルのベンチマークスコアに注目が集まりがちです。ただ、実際のプロダクション環境では、モデル以外の要素が結果を大きく左右することがよくあります。プロンプト設計、ツール定義、コンテキスト管理——こうした「周辺部分」をしっかり作り込むことの重要性を、今回の事例は教えてくれている気がします。

自分もこの記事を読んでから、使っているコーディングエージェントのハーネス部分をもう少し意識するようになりました。モデルの新バージョンが出るたびに飛びつくよりも、まずは足元のハーネスを最適化するほうが、手っ取り早く成果が出るのかもしれません。

関連記事として、Apple iOSゼロデイ脆弱性CVE-2026-20700の詳細と今すぐやるべき対策やClaude Opus 4.6 vs GPT-5.3-Codex — 同日リリースの2大AIモデルを実際に使い比べた体験談も参考になるかと思います。また、なぜ「AI人材」は存在しないのか — スキル定義が破綻する構造的理由でも関連する話題を取り上げています。

参考: I Improved 15 LLMs at Coding in One Afternoon (blog.can.ac) / oh-my-pi – GitHub