AIモデルは、どんどん賢くなっています。
Claude であれば、現在は Claude Opus 5 のような非常に強力なモデルが利用できます。
すると、こんな疑問が出てきます。
「一番賢いモデルを選べば、それでAIエージェントは完成なのでは？」
実は Anthropic の公式資料を追っていくと、もう少し違った景色が見えてきます。
この記事では、最近よく聞くようになった 「ハーネス（Harness）」 という考え方を、AI初心者でも理解できるように対話形式で説明します。
先に結論を書くと、本記事では AI エージェントの実力を次のように整理します。
AIエージェントの実力 ＝ モデル × ハーネス
これは理解しやすくするための本記事での整理であり、Anthropic がこの数式そのものを公式に掲げているわけではありません。
対象読者
- Claude Code や AI エージェントを使い始めたばかりの人
- 「結局どのモデルが一番強いのか」を気にしている人
- サブエージェントや Skills を組んでみたが、どこまで作り込むべきか迷っている人
「Opus 5 を使えば最強ですよね？」
新人
「Claude Code を使い始めたんですが、モデルは Opus 5 にしておけばいいんですよね？」
先輩
「モデル選びは大事。でも、それだけでエージェントの性能は決まらない」
新人
「一番賢いモデルなのにですか？」
先輩
「たとえば、めちゃくちゃ優秀なエンジニアを一人採用したとする。でも仕様書は渡さない。開発環境もない。テストもない。GitHub にもアクセスできない。レビューする人もいない」
「それで最高の仕事ができると思う？」
新人
「無理ですね」
先輩
「AI も同じ話なんだ」
モデルは頭脳、ハーネスは仕事の仕組み
ここで出てくるのが Agent Harness（エージェント・ハーネス） です。
Anthropic は公式記事「Demystifying evals for AI agents」の中で、Agent Harness を「モデルがエージェントとして行動できるようにするシステム」と説明しています。入力を処理し、ツール呼び出しを調整し、結果を返す仕組みのことです。
そして評価の話が重要で、Anthropic はエージェントを評価するとき モデル単体ではなく「Harness と Model が一緒に動くシステム」を評価している と書いています。
さらに、Claude Code 自体も flexible agent harness の例 として挙げられています。
新人
「ちょっと待ってください。Claude Code そのものがハーネスなんですか？」
先輩
「そう。モデルが頭脳だとすれば、Claude Code はその頭脳にファイル操作やターミナルやツールを使わせるための実行基盤。そう考えるとしっくりくる」
「エージェントチーム ＝ ハーネス」ではない
新人
「最近、複数の AI に役割を与えるエージェントチームも聞きます。あれがハーネスですか？」
先輩
「近いけどイコールじゃない」
構造としてはこうなります。
ハーネス
├─ エージェント構成
│ ├─ Planner
│ ├─ Developer
│ ├─ Reviewer
│ └─ QA
│
├─ Skills / Prompt
├─ Tools / MCP
├─ Context / Memory
├─ タスクの実行順序
├─ テスト
├─ レビュー
└─ ガードレール
つまり エージェントチームは、ハーネスを構成する方法のひとつ です。エージェントを増やさなくてもハーネスは成立しますし、逆にエージェントだけ増やしてもハーネスにはなりません。
Anthropic 自身も「3体のAIチーム」を組んでいる
2026年3月、Anthropic の Labs チームの Prithvi Rajasekaran 氏が「Harness design for long-running application development」という記事を公開しています。
そこで組まれているのが、GAN（敵対的生成ネットワーク）に着想を得た 3エージェント構成 です。
Evaluator は合格・不合格の二値ではなく、機能性・デザイン・作り込み・独創性といった観点にスコアリングの基準を持たせています。「このデザインは良いか？」という主観的な問いを、採点可能な形に落とし込むところが設計の肝になっています。
新人
「人間の開発チームとほぼ同じ形ですね」
先輩
「1体に全部やらせるんじゃなくて、役割を分けて、評価結果を次の改善に回している。コードレビューと QA が果たしている役割と構造的には同じだよ」
同じモデルでも、ハーネスの有無で結果が変わった
同じ記事の中で、Anthropic は単独エージェントと Planner / Generator / Evaluator を組んだフルハーネスの比較もしています。
フルハーネス側はトークンコストもレイテンシも明らかに増えます。それでも、単独モデルでは届かなかった完成度と技術的な正しさに到達しました。
ここで押さえておきたいのは、どちらも同じ Opus 4.5 だった ことです。違ったのはモデルではなく、そのモデルをどう働かせたかでした。
16体の Claude に C コンパイラを書かせた話
もっと極端な実験もあります。
2026年2月、Anthropic の Safeguards チームの Nicholas Carlini 氏が、Opus 4.6 を使って 16体の Claude を並列で動かし、Rust 製の C コンパイラをゼロから作らせる 実験を公開しました。
- 約2週間、約2,000回の Claude Code セッション
- 入力20億トークン、出力1.4億トークン、API コスト約2万ドル
- 完成したのは約10万行のコンパイラ
- x86 / ARM / RISC-V で Linux 6.9 をビルド可能
- QEMU、FFmpeg、SQLite、PostgreSQL、Redis もコンパイル可能
面白いのは、途中で「16体全員が同じ Linux カーネルのバグを直そうとして上書きし合う」という詰まり方をしている点です。これを解決した方法が地味に効いていて、カーネルの大半のファイルは GCC でコンパイルし、ランダムに選んだ一部だけを Claude 製コンパイラでコンパイルするようにしました。壊れたら原因は Claude が担当した範囲にある、と絞り込める。1個の巨大な問題が、並列化できる小さな問題群に変わったわけです。
Claude を16体並べただけでは、この実験は成立していません。タスクの分担、Git による同期、テスト、CI、フィードバック、コンテキスト管理、専門エージェントへの役割分担。こうした「Claude が自律的に仕事を続けられる環境」の設計こそがハーネスです。
新人
「じゃあ AI を増やせばいいわけでもない？」
先輩
「そう。16人の優秀なエンジニアを集めても、全員が同じバグを同時に直していたら意味がない。誰が何を担当するか、どう成果を共有するか、何をもって正解とするか。そこまで含めて設計するのがハーネス」
では、ハーネスは複雑なほど強いのか
新人
「わかりました。エージェントを10体20体に増やして、レビューも何重にもして、ルールも大量に書けば最強ですね」
先輩
「それも違う」
Anthropic は 2024年の「Building effective agents」の時点から、まず可能な限りシンプルな解決策を探し、必要な場合にだけ複雑性を足す という方針を示しています。
モデルが賢くなると、昔のハーネスが邪魔になる
ここが、現在の AI エージェント開発で特に重要なポイントです。
Anthropic は「ハーネスの各部品には、モデル単体ではここまでできない、という仮定が埋め込まれている」と書いています。そしてモデルは進化する。つまり その仮定は賞味期限切れになる。
具体例が出ています。
Claude Sonnet 4.5 には、コンテキスト上限が近づくと作業を早めに切り上げようとする挙動がありました。いわゆる context anxiety（コンテキスト不安） です。対策として、状態を引き継ぎつつコンテキストを完全にクリアする「コンテキストリセット」をハーネスに組み込んでいました。
ところが同じハーネスを Claude Opus 4.5 で動かしたところ、その挙動自体が消えていた。リセット機構は dead weight（死荷重） になっていた、と表現されています。
参考: Scaling Managed Agents: Decoupling the brain from the hands
新人
「ハーネスは一度作ったら完成、じゃないんですね」
先輩
「むしろ逆。モデルが上がるたびに『この仕組みはまだ必要か？』を棚卸ししないと、過去の対策がそのまま技術的負債になる」
このあたりは CLAUDE.md や AGENTS.md が肥大化していく現象とまったく同じ構図だと思っています。昔のモデルのために書いた回避策が、いつのまにか効かないどころか邪魔になっている。
そして Opus 5
Anthropic は2026年7月24日に Claude Opus 5 を発表しました。長時間・複数ステップのエージェント作業と、自分の作業を検証して粘り強く直す能力が強化されています。
ここで注目したいのが2点あります。
1つ目。Anthropic 自身が Opus 5 の Frontier-Bench v0.1 評価を、mini-SWE-agent harness 上で実施している と脚注に明記しています。Opus 5 になっても、モデルを harness から切り離して性能を語ってはいません。
2つ目。公開されている事例のひとつが、トレーディング企業のエンジニアが新規取引所のマーケットデータフィードを1セッションで構築した話です。検証に使えるライブフィードが存在しなかったため、Opus 5 が自分で test harness を書いて、自分のコードが取引所のデータを正しくパースできているか検証しました。
モデルがハーネスを作る側に回り始めている、という話でもあります。
「Opus 5 ならハーネスは不要」は逆
新人
「Opus 5 がそこまで賢いなら、いずれハーネスは要らなくなるんでしょうか」
先輩
「なくなるというより、役割が上にずれていく」
弱いモデルでは、人間側が細かく手順を書く必要がありました。
これをやる
↓
次にこれをやる
↓
確認する
↓
失敗したら戻る
モデルが強くなると、この部分は AI 自身に任せられます。代わりに人間が考えるのはこちらです。
どんなツールを渡すか
誰に何を任せるか
何を正解とするか
どこまで自動化するか
どう検証するか
どこで止めるか
手順書を書く仕事から、システムを設計する仕事に移る、ということです。
この解釈部分は各公式記事から筆者が導いたもので、Anthropic がこう言い切っているわけではありません。
会社に例えると
| 要素 | 会社に例えると | 具体例 |
|---|---|---|
| モデル | 優秀な社員の頭脳 | Claude Opus 5 / Claude Sonnet 5 |
| Tools / MCP | 社員が使える道具 | GitHub、ブラウザ、DB、社内システム |
| Skills / Instructions | 業務マニュアル、専門知識 | Claude Code Skills、CLAUDE.md
|
| Context / Memory | 仕様書、過去の経緯、社内知識 | 設計ドキュメント、過去チケット |
| Agent Team | 役割分担されたチーム | Planner / Developer / Reviewer / QA |
| Test / Evaluation | 品質基準、テスト工程 | CI、E2E、Evaluator エージェント |
| Harness | これらを組み合わせた仕事の仕組み全体 | Claude Code、独自の自動化パイプライン |
大事なのは「どの AI を使うか」だけではない
これまでは「GPT と Claude はどっちが賢い？」「Opus と Sonnet はどっちを使う？」というモデル選びに注目が集まりがちでした。もちろんモデル選びは大事です。
ただ、エージェント時代にはもうひとつ問いが増えます。
そのモデルを、どんな仕組みで働かせるのか？
同じモデルでも、どんなツールを渡すか、どんな情報を渡すか、どんな役割を持たせるか、どう検証するか、他のエージェントとどう協力させるかで成果は変わります。Anthropic の実験がまさにそれを示しています。
AIエージェントの実力 ＝ モデル × ハーネス
最後に
新人
「最強のモデルを探すことばかり考えていました」
先輩
「それも大事。でも、その頭脳が力を出せる仕事環境を作るほうがもっと効く」
新人
「モデルを選んだら終わりじゃなくて、そこからが設計なんですね」
先輩
「そういうこと」
モデルはこれからも進化します。Opus 5 の次には、さらに強いモデルが出るでしょう。
そのたびに、モデルを入れ替えるだけで終わらせずに、
- 今のモデルなら、どこまで自分でできるのか
- 何をハーネス側で支援すべきなのか
- 逆に、何を削除できるのか
を見直す。地味な棚卸しですが、これをやるかどうかで手元のエージェントの出来は変わります。AI エージェントを「使う」側から、AI エージェントの能力を「引き出す」側へ進むための重要な視点だと思います。