AIが思ったように動かないとき、わりと自然な反応はこれです。
モデルを替える。
Reasoningが微妙？
もっと強いモデルにしよう。
コードがちょっとアホ？
Pro版にしよう。
Agentが変な動きをする？
きっとモデルがまだ賢くないんだ。
API代？
……それは未来の自分が考えることです。
でも最近の研究を見ると、少し嫌な可能性が見えてきます。
最初にアップグレードすべきなのは、モデルではないかもしれません。
エンジンが強くても、畑をちゃんと耕せるとは限らない
500馬力のトラクターを買ったとしましょう。
エンジンは最強。
最新技術。
TractorBenchでは世界1位。
でも、
ハンドルが曲がっている。
プラウの取り付けも間違っている。
運転手から畝が見えない。
道を外れても誰も教えてくれない。
さて、どうする？
700馬力のトラクターを買おう。
ちょっとアホっぽいですよね。
でもAIでは、似たようなことをかなり頻繁にやっています。
AI Agentは、modelだけでできているわけではありません。
その周りには、context、tools、retrieval、memory、permissions、state、retry、validation、feedback loop、toolの呼び出し方、失敗したときのrecoveryなどがあります。
このモデルを取り囲むシステムを、まとめて harness（ハーネス） と呼びます。
2026年の Harness-Bench は、106のtask、合計5,194のexecution trajectoryを使って、複数のmodel–harness構成を比較しました。
結果はかなり面白くて、completion rate、efficiency、process quality、さらに「どう失敗するか」まで、modelとharnessの組み合わせによって大きく変わりました。
著者らは、Agentのcapabilityをbase modelだけの性能として見るのではなく、model–harness configuration全体として評価すべきだと述べています。
簡単に言えば、
Modelはエンジン。Harnessは、その馬力を実際の仕事に変える仕組みです。
面白いのは、小さいモデルが大きいモデルに勝つこともある
AutoHarness には、かなり分かりやすい例があります。
研究チームが分析したchessデータでは、Gemini 2.5 Flashの敗北の78%がillegal moveに関連していました。
Reasoningをあと20step増やせば解決する……
という話ではありません。
そもそも、
ルール違反の手を指している。
そこで研究チームは、Gemini 2.5 Flash自身にactionを制御するcode harnessを作らせました。
生成されたharnessは145のTextArena gameでillegal moveを防ぎ、実験では Gemini 2.5 Flash + harness が、より大きなGemini 2.5 Proを上回りました。
つまり、ときにはこういうことです。
50馬力でも正しい畝を走るトラクターのほうが、200馬力で隣の畑を耕しているトラクターより強い。
しかも、これはbenchmarkだけの話ではない
Better Harnesses, Smaller Models は、もっと直接的に「コスト」を扱っています。
研究チームはbusiness task上でsmall language model向けにharnessを最適化しました。
failure modeに合わせて、instructions、tools、orchestration loopなどを調整します。
その結果、
21のtask–modelペアのうち16でperformanceが有意に改善。
さらに7ケースではsmall modelがlarge LLMとのperformance gapを埋めました。
最も良いケースでは、
large modelの89.7%のperformanceを、わずか4%のcostで達成しています。
でも、このpaperで一番面白いのは「4%」という数字ではありません。
もっと重要なのは、この考え方です。
taskの難しさの一部は、modelからharness側へ移すことができる。
全部をmodelに覚えさせる代わりに、better memoryを用意する。
APIの使い方をmodelに推測させる代わりに、分かりやすいtool interfaceを作る。
database全部をcontextに突っ込んで祈る代わりに、必要な情報だけretrievalする。
Agentが一度ミスしたあと、さらに12step自信満々で間違え続ける代わりに、feedbackとrecovery loopを用意する。
2024年の SWE-agent でも、適切な Agent-Computer Interface を設計することで、language model agentがrepositoryを探索し、fileを編集し、testを実行する能力が大きく変わることが示されています。
では、次にAgentがアホなことをしたら？
いきなり、
「もっと強いmodelが必要だ」
と決めつける前に、少しだけ確認してみましょう。
Retrievalは本当に必要な情報を取れている？
Toolはmodelにとって使いやすい？
Contextは必要な情報なのか、それともゴミだらけ？
Agentは直前のactionが失敗したことを認識できる？
失敗したあとに戻って修正できる？
そもそも、どこで死んでいるのか分かるevalはある？
強いmodelはもちろん重要です。
でも、
強いmodelを使ったからといって、自動的に強いsystemになるわけではありません。
700馬力のトラクターを買う前に、
まず確認したほうがいいかもしれません。
そのハンドル、本当にタイヤにつながっていますか？
References
- Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows — 2026.
- AutoHarness: improving LLM agents by automatically synthesizing a code harness — 2026.
- Better Harnesses, Smaller Models: Building 90% Cheaper Agents via Automated Harness Adaptation — 2026.
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — 2024.