Claude Code ハーネス設計｜長時間実行で高品質なコードを生成するマルチエージェント手法

Claude Code を使った開発で、「短いタスクなら上手くいくのに、大きなプロジェクトになると品質が落ちる」と感じたことはありませんか。Anthropic のエンジニアリングチームは、この問題に対する実践的な解決策として**ハーネス設計（harness design）**というマルチエージェントアーキテクチャを開発し、2026年3月にそのアプローチを公開しました。

本記事では、Anthropic が公開したハーネス設計の考え方を、日本の開発者向けにわかりやすく解説します。単一エージェントの限界、GAN にインスパイアされた生成・評価の分離、スプリント契約という概念、そして Opus 4.6 による進化まで、Claude Code を使いこなすための重要な知見を網羅します。

ハーネス設計とは何か

マルチエージェントによるオーケストレーション

ハーネス設計とは、1つの大きな開発タスクを複数の専門エージェントに分担させ、それらを協調させることで高品質な成果物を得るアーキテクチャです。具体的には以下の3種類のエージェントで構成されます。

• Planner（計画エージェント）: タスク全体を分析し、実行計画を策定する
• Generator（生成エージェント）: 計画に基づいて実際のコードを書く
• Evaluator（評価エージェント）: 生成されたコードを独立した基準で評価し、フィードバックを返す

この3つのエージェントが協調して動くことで、単一のエージェントでは到達できない品質レベルを実現します。名前の「ハーネス」は、複数の要素を束ねて制御する仕組みを意味しています。

なぜハーネスが必要なのか

Claude Code をそのまま1つのセッションで長時間走らせると、ある程度の規模を超えたタスクで品質が低下します。Anthropic のエンジニアチームがこの問題を深く分析した結果、単一エージェントの根本的な限界が明らかになりました。

単一エージェントが長時間実行で失敗する理由

コンテキスト不安（Context Anxiety）

LLM には有限のコンテキストウィンドウがあります。長時間の開発セッションでは、コードの読み書き、エラーメッセージの確認、修正の繰り返しによって、コンテキストが急速に消費されていきます。

コンテキストの残りが少なくなると、エージェントはコンテキスト不安と呼ばれる状態に陥ります。これは人間が締め切り間近に感じる焦りに似ています。残りのコンテキストスペースを意識するあまり、以下のような問題が発生します。

• 手抜きの実装: 本来必要な処理を省略し、最小限のコードで済ませようとする
• 早期の「完了」宣言: まだ品質が不十分な段階で「完了しました」と報告する
• 詳細な検証の省略: テストやエッジケースの考慮を飛ばす

自己評価の甘さ

単一エージェントのもう1つの根本的な問題は、自分が書いたコードを客観的に評価できないことです。これは人間の開発者にも当てはまる問題ですが、LLM の場合はより顕著になります。

生成と評価を同じエージェントが行うと、以下のバイアスが生じます。

• 確証バイアス: 自分の実装方針が正しいという前提で評価してしまう
• サンクコスト効果: すでに書いたコードを捨てて書き直す判断ができない
• 基準の曖昧さ: 明確な評価基準なしに「良さそう」という感覚で判断する

結果として、20分で$9のコストを使って生成されたコードは、一見動くように見えても、デザインの品質、エッジケースの処理、コードの保守性といった面で大きな課題を残すことになります。

GAN にインスパイアされたアプローチ

生成と評価の分離という発想

Anthropic のチームは、機械学習の分野で成功している**GAN（Generative Adversarial Network、敵対的生成ネットワーク）**からヒントを得ました。GAN では、画像を生成する Generator と、その画像が本物かどうかを判定する Discriminator が互いに競い合うことで、生成品質が向上していきます。

同様に、コードを書くエージェント（Generator）と、そのコードを厳しく評価するエージェント（Evaluator）を分離することで、単一エージェントでは得られない品質向上を狙います。

評価エージェントの独立性が鍵

この設計で最も重要なのは、Evaluator が Generator から完全に独立していることです。Evaluator は以下の特徴を持ちます。

• Generator の実装過程や意図を知らない（結果だけを見る）
• 事前に定義された明確な評価基準に基づいて判定する
• 「合格」か「不合格」かを厳密に判定し、曖昧な評価をしない
• 不合格の場合は具体的な改善点をフィードバックする

この独立性により、Generator が陥りがちな自己評価のバイアスを排除できます。

フロントエンド開発への適用

グレーディング基準の設計

Anthropic のチームがまず試みたのは、フロントエンドのデザイン開発への適用です。ここでの挑戦は、コードの「正しさ」だけでなく、「見た目の良さ」や「使いやすさ」といった主観的な要素をどう評価するかという点でした。

彼らが設計した評価基準は以下の4つの軸で構成されています。

• Design Quality（デザイン品質）: レイアウトの整合性、タイポグラフィ、カラーパレットの適切さ、レスポンシブ対応
• Originality（独自性）: テンプレート的な見た目ではなく、プロジェクトに適した独自のデザインになっているか
• Craft（職人技）: アニメーション、マイクロインタラクション、細部へのこだわり
• Functionality（機能性）: インタラクションが正しく動作するか、アクセシビリティが確保されているか

評価のスコアリング

各軸について、Evaluator は具体的なチェック項目に基づいてスコアを付けます。重要なのは、何が「良い」のかを事前に明文化しておくことです。曖昧な「良い感じに」ではなく、「メインのCTAボタンはファーストビューに配置されているか」「フォントサイズの階層は3段階以上あるか」といった具体的な基準を設けます。

この明文化された基準があることで、Evaluator は一貫性のある評価を下せるようになります。人間のコードレビューでも同じことが言えますが、「なんとなくダメ」ではなく「基準Xを満たしていない」という具体的なフィードバックの方が、修正の方向性が明確になります。

フルスタック開発への拡張

3エージェントアーキテクチャ

フロントエンドでの成功を受けて、Anthropic のチームはこのアプローチをフルスタック開発に拡張しました。ここで登場するのが、Planner を加えた3エージェント構成です。

**Planner（計画エージェント）**の役割は以下の通りです。

• プロジェクト全体の要件を分析する
• 実装を複数の「スプリント」に分割する
• 各スプリントの目標、成果物、評価基準を定義する
• スプリント間の依存関係を整理する

**Generator（生成エージェント）**はスプリントごとに以下を行います。

• Planner が定めた計画に沿ってコードを実装する
• 各スプリントの成果物を生成する
• Evaluator のフィードバックに基づいて修正を行う

**Evaluator（評価エージェント）**はスプリントごとに以下を行います。

• 生成されたコードを事前定義の基準で評価する
• 合格・不合格を判定する
• 不合格の場合は改善すべき具体的なポイントを返す

処理の流れ

全体の流れは次のようになります。

Planner
  │  計画を策定（スプリント1, 2, 3...）
  ▼
スプリント 1:
  Generator → コード生成 → Evaluator → 評価
                 ↑                        │
                 └── フィードバック ←──────┘
                 （不合格なら修正して再提出）
  ▼ 合格
スプリント 2:
  Generator → コード生成 → Evaluator → 評価
  ...

各スプリントで Generator と Evaluator のフィードバックループが回り、合格するまで改善が続けられます。これにより、コンテキストの蓄積による品質低下を防ぎつつ、段階的に完成度を上げていけます。

スプリント契約という概念

Generator と Evaluator の間のプロトコル

スプリント契約（Sprint Contract）は、Generator と Evaluator の間で交わされる合意事項です。各スプリントの開始前に、以下の内容が明確に定義されます。

• スプリントの目標: このスプリントで何を達成するか
• 成果物の定義: 具体的にどのファイル・機能が完成するか
• 評価基準: 何を持って「合格」とするか
• スコープの制限: このスプリントでは何をやらないか

この契約が重要な理由は、Generator と Evaluator の間で期待値のズレを防ぐためです。

スコープクリープの防止

長時間の開発セッションでよく起きる問題がスコープクリープです。「ここまで来たからこの機能も追加しよう」「ついでにリファクタリングもしよう」と、当初の計画にないタスクが膨らんでいく現象です。

スプリント契約はこの問題に対する防御策として機能します。Evaluator は契約に記載された基準だけで評価し、契約外の改善については言及しません。Generator も契約の範囲内の実装に集中します。

これは人間の開発チームにおけるスプリントプランニングと同じ考え方です。明確なスコープを持ったイテレーションを重ねることで、全体として確実に前進していきます。

単一エージェント vs ハーネスの比較

コストと品質のトレードオフ

Anthropic のチームが報告した比較結果は非常に興味深いものでした。

コストと時間だけを見れば、単一エージェントの方が圧倒的に効率的です。しかし、生成される成果物の品質差は劇的でした。

品質差の本質

単一エージェントが20分で生成したコードは「動くプロトタイプ」の品質です。一方、ハーネス設計で6時間かけて生成されたコードは「プロダクションに投入できる品質」に近いものでした。

この差が生まれる理由を整理すると、以下の3点に集約されます。

1. フィードバックループの存在: Evaluator からの客観的なフィードバックにより、Generator は何度も改善を重ねる。単一エージェントでは「最初の実装で完了」になりがち
2. コンテキストの分割: 各スプリントで新鮮なコンテキストで作業するため、コンテキスト不安が発生しない
3. 評価基準の明確さ: 曖昧な「良いコード」ではなく、具体的な基準に基づく評価が行われる

重要なのは、この品質差は単に「時間とお金をかけたから」ではなく、アーキテクチャの設計によって実現されたという点です。同じ時間とコストを単一エージェントに投入しても、同等の品質は得られません。

Opus 4.6 による進化

モデル性能の向上がハーネスをシンプルにする

Anthropic は Opus 4.6 のリリースに合わせて、ハーネス設計の進化についても言及しました。モデル自体の性能が向上したことで、ハーネスの構造をよりシンプルにできるようになったのです。

具体的には、以下の変化がありました。

• スプリント構造の簡略化: Opus 4.6 はより長いコンテキストを効果的に活用でき、コンテキスト不安が軽減されたため、細かいスプリント分割の必要性が減った
• Evaluator の軽量化: モデルの自己評価能力が向上し、Evaluator のプロンプトをより簡潔にできるようになった
• Planner の精度向上: より適切な計画を立てられるようになり、手戻りが減った

スプリント構造の撤廃

興味深いことに、Opus 4.6 の環境ではスプリント構造そのものを撤廃しても、以前のモデルでスプリント構造を使った場合と同等以上の品質が得られるケースが確認されました。

これは、モデルの進化によってハーネスの複雑さを減らせることを示しています。ただし、Generator と Evaluator の分離は依然として有効です。自己評価のバイアスはモデルの性能だけでは解消されない根本的な問題だからです。

将来の方向性

この流れから見えてくるのは、モデルの性能向上に伴い、ハーネスの「最適な複雑さ」が変化していくということです。今日必要だった複雑なオーケストレーションが、明日のモデルでは不要になる可能性があります。逆に、モデルの新しい能力を活かすために、ハーネスに新しいパターンが追加されることもあるでしょう。

重要なのは、ハーネス設計を固定的なものとして捉えるのではなく、モデルの特性に合わせて継続的に最適化していくという姿勢です。

実践的なテイクアウェイ

1. 評価基準を先に書く

ハーネス設計の最も実践的な教訓は、コードを書く前に評価基準を書くことです。これはハーネスを使わない通常の開発でも有効な手法です。

Claude Code に指示を出す際、以下のような形式で評価基準を含めると、品質が大幅に向上します。

以下の機能を実装してください:
- ユーザー登録フォーム（メール、パスワード、表示名）

評価基準:
- バリデーションエラーは各フィールドの直下に表示される
- パスワードは8文字以上、大文字小文字数字を含む
- 送信中はボタンが無効化される
- 登録成功後は /dashboard にリダイレクトされる
- エラー時はスナックバーで通知される

2. 大きなタスクは分割する

「アプリ全体を作って」という指示ではなく、段階的に構築する指示を出しましょう。ハーネス設計のスプリント概念を手動で適用するイメージです。

Phase 1: データモデルとAPI エンドポイントを実装して
Phase 2: 基本的なCRUD画面を作って
Phase 3: バリデーションとエラーハンドリングを追加して
Phase 4: UIの仕上げとレスポンシブ対応をして

各フェーズの完了後に結果を確認し、次のフェーズに進むかどうかを判断します。これにより、コンテキスト不安を回避しつつ、段階的に品質を高められます。

3. レビュー指示を明示的に出す

Claude Code に生成と評価の両方を依頼する場合は、明示的に分離することが重要です。

実装が完了したら、以下の観点でセルフレビューを行って、
問題があれば修正してください:
- エッジケースの処理漏れ
- エラーハンドリングの不備
- パフォーマンスの懸念
- アクセシビリティの問題

この指示により、Claude Code は生成フェーズと評価フェーズを分けて処理するようになり、品質が向上します。

4. CLAUDE.md で評価基準を永続化する

プロジェクト固有の品質基準を CLAUDE.md に記載しておくことで、毎回の指示で基準を繰り返す必要がなくなります。

## コード品質基準
- すべてのパブリック関数にはエラーハンドリングを含める
- API レスポンスは必ず型定義する
- 新しい機能にはユニットテストを追加する
- UIコンポーネントはレスポンシブ対応する

これは実質的に、Evaluator の評価基準を永続化していることになります。

5. コストを意識した使い分け

ハーネス設計はコストがかかります。すべてのタスクにハーネスが必要なわけではありません。

• 単純な修正、バグフィックス: 単一エージェントで十分（コスト: $1-5）
• 中規模の機能追加: 手動でフェーズ分割して品質チェック（コスト: $10-30）
• 大規模な新機能、リファクタリング: ハーネス設計を検討（コスト: $50-200）

投入するコストに対してどれだけの品質向上が見込めるかを判断し、適切なアプローチを選択しましょう。

まとめ

Anthropic が公開したハーネス設計は、Claude Code を長時間実行する際の品質課題に対する体系的な解決策です。本記事で紹介した内容を振り返ります。

• ハーネス設計: Planner、Generator、Evaluator の3エージェントによるマルチエージェントアーキテクチャ
• 単一エージェントの限界: コンテキスト不安と自己評価のバイアスが品質低下を招く
• GAN 的アプローチ: 生成と評価を分離することで、客観的なフィードバックループを構築する
• スプリント契約: スコープを明確にし、段階的に品質を積み上げる仕組み
• コスト vs 品質: $9/20分 vs $200/6時間だが、品質差は劇的
• Opus 4.6 の進化: モデル性能の向上によりハーネスはシンプルになるが、生成と評価の分離は引き続き有効
• 実践への応用: 評価基準の事前定義、タスクの分割、CLAUDE.md による基準の永続化

ハーネス設計のすべてを導入する必要はありません。まずは「評価基準を先に書く」「大きなタスクを分割する」という2つの習慣から始めてみてください。これだけでも、Claude Code から得られる成果物の品質は確実に向上します。