「どの AI モデルが一番賢いか」——ここ数年、AI 業界の話題はこの問いを中心に回ってきました。ただ、AI が人に代わって長時間手を動かす「エージェント」として使われ始めた今、この問いだけでは各社の実力を測れなくなっています。同じモデルでも、その周囲をどう作り込むかで、やり遂げられる仕事の水準が大きく変わることが、数字で見えるようになってきたためです。
その鍵を握るのが「harness （ハーネス）」と呼ばれる層です。もとは馬具を指す言葉で、力はあるが自分ではそれを発揮できない馬を、意図どおりに走らせる道具一式を指します。
harness とは何か
LLM を「頭脳」だとすると、ハーネスは「その頭脳に実際に仕事をさせるための仕組み」にあたります。
実際の中身は地味です。モデルに何を見せるか、どの外部ツールを使わせるか、仕事をどう分割するか、成果を誰に検証させるか、いつ「完成」と判断するか。こうした運用上の判断を設計として組み込んだものがハーネスです。同じ AI 基盤モデルでも、単純なプロンプトで動かす場合と、計画 → 実装 → テスト → 動作確認 → エラー解析 → 別エージェントによる検証、という流れで動かす場合とでは、達成できる仕事の難易度がまったく違ってきます。
ベンチマーク上の差は歴然
これを数字で示す例が出てきました。サンフランシスコの研究ラボ Intology は、「科学的発見そのものを自動化する」Artificial Scientist（人工科学者）の開発をかかげ、文献調査から仮説立案、実験、結果の分析までを AI に自律的に行わせる「 Locus 」というハーネスを開発しています。同社の Locus の性能をテストする際に、AI 研究の自動化能力を測る PostTrainBench で評価した結果、Anthropic の基盤モデル（Opus 5）を通常のエージェントとして動かしたスコアは 34.1 でしたが、同じ Opus 5 を Locusのハーネスに組み込むと 44.7 に上がりました。モデルは同じで、変えたのは周囲の仕組みだけです。
コーディングでも同じ現象が確認されています。同じ Claude Opus 4.5 を SWE-bench Pro で測ったところ、ベンチマーク側が用意した標準の実行環境（ SEAL scaffold ）では 45.9 %、ハーネスが組み込まれている Claude Code 上で動かすと 55.4 % という差が出ました。
いずれも、モデルそのものを強化したのではなく、働かせ方を変えただけで10ポイントの差が出たのです。
Anthropic：作る担当と評価する担当を分ける
Anthropic はハーネスの設計そのものが性能を左右することに早くから気づき、その設計を重視してきました。
例えば、長時間のアプリ開発では単一のエージェントに任せず、計画役・実装役・評価役の 3 つのエージェントに分ける構成を採っています。背景にあるのは、エージェントは自分が作ったものを自分で評価させるとうまくいかない、という経験則です。実装を担当したエージェントは自らの成果物を過大に評価する傾向があるため、作る側と評価する側を分けたほうが結果が良くなると報告されています。その 3 つのエージェントをうまく働かせるためにハーネスが周辺で機能しています。
一方で、複雑なハーネスほど良いとは限りません。Anthropic は、Opus 4.5 の時点では実際の使い勝手に効いていたハーネスが、Opus 4.6 にモデルが強化された時に、一部不要になったとしています。強いモデルを古い仕組みで動かせば、処理は遅くなりコストも増えます。ハーネスの設計は仕組みを増やせばいいだけでなく、その時点のモデルの能力と特性に合わせて、苦手な部分だけを外から補ってあげる、という微調整が常に必要になるということを示唆しています。
OpenAI：harness を全社の共通基盤にする
OpenAI もこの層に本腰を入れています。同社にはハーネスエンジニアリングの専任チームがあり、責任者はモデルの能力を最大限に引き出す手段がハーネスだと説明しています。同社ではコーディングを行う Codex のハーネスは Codex 専用ではなく、ChatGPT Work など他製品も同じ基盤の上で動く共通部品として設計されました。さらに OpenAI はこのハーネスをオープンソースとして公開し、外部の開発者が自分で開発したツールに組み込んで使えるようにしています。非公開の Claude Code とは対照的ですが、これはオープンソースにすることで、外部の開発者による積極的な改良を促し、自社のハーネス設計の出遅れを取り戻そうとしている、とも見えます。
Google：マルチエージェントという別の攻め方
Google はそもそもコーディングエージェントの分野で出遅れ、現在、Antigravity という専用アプリを打ち出して巻き返しを図ろうとしています。Antigravity は開発当初からマルチエージェントを基本とし、最大 16 体のエージェントを同時に走らせる設計となっています。そうした根本的に優れたマルチエージェント構造（技術）を前面に押し出しつつ、Google 社内に大量に抱えるプログラマーを使って社内レビューを続け、ハーネスの充実を図ろうとしています。
ただし現場の評価は、まだあまり高くなく、Antigravity が優位に立つのは主に価格面だけ、という辛辣な評価が目立ちます。プレビュー段階ゆえの粗さも指摘されています。エージェントを 16 体を並べられること設計自体は強力ですが、1 体あたりの完遂率と手戻りの少なさが伴わなければ、確認する人間の負担が増えるだけになってしまう点も指摘されています。
現場の評価を分けているもの
主要 3 社はいずれもハーネスの重要性を理解し、それぞれのやり方で鎬を削っていますが、それでも現時点で現場のコーダーの評価は圧倒的に Claude Code に集まっています。それは、モデルが一段賢いからというより、どこで検証させ、どこで人間に確認を取り、文脈が溢れたときに何を捨てるかといった細部の調整を、実際の開発現場のフィードバックを受けながら積み上げてきた差だとみるのが自然です。
ハーネスは派手な技術ではありません。効くかどうかは長時間動かしてみないと分からず、モデルが更新されればその最適解も変わります。Anthropic はこの地道なノウハウの蓄積を当初から行なってきており、それがそのまま使い勝手の差として表れています。
まとめ
ここまでハーネスについて見てきましたが、ここまででわかるのは、今後は AI の性能を単純な基盤モデルの優劣（例えばGemini と Claude のどちらが賢いか）ではなく、「 Claude + Claude Code 」「 GPT + Codex 」「 Gemini + Antigravity 」のように、モデルとハーネスの組み合わせで見る必要があるということです。
もう 1 つは、タスクが長くなるほどハーネスの比重が増すことです。数分で終わる質問応答なら影響は小さいですが、10 時間かかる作業になると、モデルの地頭よりも、記憶の管理、作業の分割、失敗からの復帰、検証の設計のほうが結果を左右します。今後、AI がビジネスの現場に入っていき、エージェントが複雑な実務作業を担当して行く時、ハーネスの重要性はさらに増していくものと思われます。
そして現在、次の段階として、ハーネスそのものを AI に設計・改良させる動きがあります。現在は Anthropic が先行している状況に見えますが、AI が速度を上げてハーネスの設計・改良を担当し、それがうまく回り始めた場合、Anthropic の優位がこのまま続くかどうかは未知数です。現在は、ハーネスの重要性に気づいた各社が開発競争をようやく始めたところ、ともいえ、まだまだ競争は始まったばかりです。ハーネスという観点からも、引き続き各社の動きに注目していきたいと思います。
