Claude Code に「ECサイトを作って」と頼むと、最初の30分は順調に進む。でも1時間を超えたあたりから、同じパターンの繰り返しが増えたり、未完成の機能を「完了」と報告してきたり、UIが急に雑になったりする。こんな経験はありませんか？
これは Claude Code が悪いわけではなく、単一エージェントで長時間タスクをこなすというアプローチに構造的な限界があるのです。
Anthropic Labs のエンジニアチームは、この問題を「ハーネス設計」というアプローチで解決しました。GAN（敵対的生成ネットワーク）に着想を得たマルチエージェント構成で、AIの出力品質を劇的に改善した実験結果を公開しています。
この記事では、彼らの研究から得られた知見を整理し、Claude Code ユーザーが実践に活かせる形で紹介します。
単一エージェントが長時間タスクで失敗する2つの理由
まず、なぜ Claude Code に長いタスクを任せると品質が下がるのかを理解しましょう。Anthropic の研究チームは、2つの構造的な問題を特定しています。
問題1：コンテキスト不安（Context Anxiety）
モデルは、コンテキストウィンドウが埋まってくると「そろそろ終わらせなきゃ」と焦り始めます。まだ実装すべき機能が残っているのに、雑にまとめて「完了しました」と報告する。これが「コンテキスト不安」です。
具体的には、こんな兆候が出ます。
- 仕様に書いた機能の一部を省略し始める
- エラーハンドリングが雑になる
- テストを書かずに「テストは後で追加してください」と言い出す
- CSSが急にインライン化される（ファイルを増やしたくないから）
問題2：自己評価が甘すぎる
AIに「自分の書いたコードをレビューして」と頼むと、ほぼ100%の確率で「よくできています」と返ってきます。明らかにバグがあっても、です。
これはデザインのような主観的なタスクで特に深刻です。「このUIは美しいか？」に対して、AIは自分の出力を「十分良い」と判断してしまう。検証可能なテスト（テストが通るか通らないか）があるコーディングタスクでも、AIは自分のコードに対して甘い判断をしがちです。
たとえば、生成したUIに「このデザインを自己レビューして」と頼むと、こんな回答が返ってきます。
全体的に洗練されたデザインになっています。
カラーパレットも統一されており、ユーザビリティも良好です。
特に改善が必要な点はありません。
人間が見れば「また同じ紫グラデーションの白カードか...」と思うレベルなのに、です。
つまり、作る側と評価する側が同じエージェントである限り、品質の天井を突破するのは困難なのです。
GANに着想を得た「生成×評価」パターン
この問題を解決するために、Anthropic のチームは GAN（Generative Adversarial Networks）の構造を応用しました。
GANでは「生成器（Generator）」と「判別器（Discriminator）」が対立しながらお互いを高め合います。同じ考え方で、コードを書くエージェント（生成器） と 品質を評価するエージェント（評価器） を分離したのです。
なぜ分離が効くのか
ポイントは3つあります。
1. 評価者を懐疑的にチューニングしやすい
生成器に「自分のコードに厳しくなれ」と指示しても効果は薄い。でも、独立した評価器に「厳しく採点して、少しでも問題があれば不合格にして」と指示するのは効きます。生成器の自己否定ではなく、外部からのフィードバックだからです。
2. 評価結果が具体的な改善指示になる
「ここがダメ、こう直して」という外部フィードバックがあると、生成器は具体的な修正に集中できます。漠然と「良いものを作れ」よりも、はるかに効率的です。
3. イテレーションが回る
生成 → 評価 → 修正 → 再評価のループが自動で回ります。人間のコードレビューと同じ構造ですが、AIなら24時間回し続けられます。
フロントエンドデザインでの実験
Anthropic のチームは、まずフロントエンドデザインで実験しました。Claude Code は放っておくと、安全だけど退屈なレイアウト——白背景に紫のグラデーション、角丸カード、ストックアイコン——を量産します。いわゆる「AIスロップ」です。
4つの評価基準
チームは、主観的な「デザインの美しさ」を具体的に採点できる4つの基準を作りました。
| 基準 | 内容 | 重み |
|---|---|---|
| デザインの質 | 色、タイポグラフィ、レイアウトが一貫した世界観を作っているか | 高 |
| オリジナリティ | テンプレート的でない独自の判断があるか。AIスロップの兆候がないか | 高 |
| クラフト | スペーシング、色の調和、コントラスト比など技術的な品質 | 低 |
| 機能性 | ユーザーが迷わず操作できるか | 低 |
注目すべきは、デザインの質とオリジナリティを重視している点です。クラフトと機能性は Claude が元々得意な領域。AIの弱点であるデザインとオリジナリティに高い重みを置くことで、「無難だけどつまらない」UIからの脱却を狙いました。
評価ループの実際
実験では、Claude Agent SDK を使って以下のループを回しました。
- 生成器がHTML/CSS/JSのフロントエンドを作成
- 評価器が Playwright MCP でページを実際に操作して確認
- 4つの基準で採点し、詳細なフィードバックを生成
- 生成器がフィードバックをもとに改善
- 5〜15回イテレーション
1回のイテレーションでスコアが上がらない場合は、方向性を完全に変える指示も含まれていました。つまり「微調整」と「ピボット」の両方を選べるようにしたのです。
ある例では、オランダの美術館サイトを作らせたところ、9回目までは洗練されたダークテーマのランディングページでした。ところが10回目で、CSS パースペクティブを使った3Dギャラリー空間に完全に切り替わった。壁に絵画が掛かり、ドアから別の部屋に移動するナビゲーション。単発の生成では絶対に出てこない創造的な飛躍が、フィードバックループから生まれたのです。
面白いのは、スコアの推移が必ずしも直線的ではなかった点です。後半のイテレーションほど全体的に良くなる傾向はあるものの、最終版よりも中間のイテレーションのほうが好ましい場合もあったそうです。また、イテレーションが進むにつれて実装の複雑さも増していき、評価器のフィードバックに応える形でより野心的なソリューションに手を伸ばす傾向も見られました。
さらに興味深いのは、最初のイテレーション時点で、プロンプトなし（ベースライン）よりも明らかに品質が高かったこと。つまり、評価基準そのものが言語として生成器の方向性をガイドする効果があるのです。評価器のフィードバックはさらなる改善を加速しますが、基準を示すだけでも「AIスロップ」からの脱却は始まります。
フルスタック開発への応用：3エージェント構成
デザインでの成功を受けて、チームはフルスタック開発に同じパターンを適用しました。最終的な構成は3つのエージェントです。
プランナー（Planner）
1〜4行のプロンプトを受け取り、詳細な製品仕様書に展開するエージェント。
たとえば「2Dレトロゲームメーカーを作って」という一文から、16機能・10スプリントの仕様書を自動生成しました。スプライトエディタ、レベルエディタ、アニメーションシステム、AI生成機能まで含む野心的な仕様です。
ポイントは技術的な実装詳細には踏み込まないこと。プランナーが「SQLiteのこのテーブル構成で」と指定して間違えると、その間違いが下流に伝播する。仕様は「何を作るか」に集中し、「どう作るか」は生成器に任せる設計です。
ジェネレーター（Generator）
仕様書のタスクを1つずつ実装していくエージェント。スプリント方式で、1回に1機能ずつ作ります。各スプリントの終了時に自己評価をした上で、評価器に引き渡します。
エバリュエーター（Evaluator）
Playwright MCP を使って、実際にアプリケーションを操作してテストするエージェント。UIのクリック、API呼び出し、データベースの状態確認まで行い、発見したバグと改善点をフィードバックします。
各基準に閾値が設定されており、1つでも下回ればスプリントは不合格。生成器は具体的なフィードバックを受けて修正を行います。
スプリント契約：「完了」の定義を事前に合意する
3エージェント構成で特に興味深いのが「スプリント契約」という仕組みです。
各スプリントの開始前に、生成器と評価器が「何を作るか」と「どうやって成功を検証するか」を交渉します。たとえば、レベルエディタのスプリントでは27項目のテスト基準が設定されました。
スプリント3の契約例：
- 矩形フィルツールでドラッグして選択タイルを敷き詰められること
- エンティティのスポーンポイントを選択・削除できること
- アニメーションフレームの並べ替えがAPIで動作すること
これにより、「曖昧な仕様をなんとなく実装して、なんとなくOKと判断する」問題を回避しています。評価器は契約に沿って機械的にテストするので、見落としが減ります。
実際の評価器のログを見ると、発見された問題の具体性がわかります。
| 契約基準 | 評価器の発見 |
|---|---|
| 矩形フィルツールでドラッグして選択タイルを敷き詰められる | 不合格 — ドラッグの開始点と終了点にしかタイルが置かれない。fillRectangle関数は存在するが mouseUp で正しくトリガーされていない |
| エンティティのスポーンポイントを選択・削除できる | 不合格 — Delete キーのハンドラーが selection と selectedEntityId の両方を要求するが、クリック時に selectedEntityId しかセットされない |
| アニメーションフレームの並べ替えがAPIで動作する | 不合格 — PUT /frames/reorder が /{frame_id} より後に定義されている。FastAPIが 'reorder' を整数としてパースしようとして 422 エラー |
ここまで具体的なバグレポートが出てくるのは、評価器が Playwright で実際にアプリを操作しているからです。ただし、Anthropic のチームも認めている通り、評価器のチューニングには相当な労力がかかりました。初期段階では、評価器が問題を見つけても「大した問題ではない」と自分を納得させて合格にしてしまうケースが多発したそうです。
コンテキスト管理：リセット vs コンパクション
長時間のタスクでは、コンテキストウィンドウの管理も重要です。2つのアプローチがあります。
コンパクション
会話の古い部分を要約して、同じエージェントが続行する方式。Claude Code のデフォルトの挙動です。会話の連続性は保たれますが、「コンテキスト不安」は解消されません。エージェントは依然として「もうすぐ限界だ」と感じてしまうことがあります。
コンテキストリセット
コンテキストを完全にクリアし、新しいエージェントを起動する方式。前のエージェントの状態を構造化されたハンドオフ文書として引き継ぎます。
Anthropic のテストでは、Sonnet 4.5 ではコンテキスト不安が強く、コンパクションだけでは不十分でした。リセットが必須だったのです。一方、Opus 4.5 以降ではこの問題がほぼ解消されたため、リセットは不要になりました。
つまり、モデルが進化するとハーネスの必要なコンポーネントも変わるということです。
実際の成果：ソロ vs ハーネス
「2Dレトロゲームメーカー」のプロンプトでテストした結果を比較します。
| 方式 | 所要時間 | コスト |
|---|---|---|
| ソロ（単一エージェント） | 20分 | $9 |
| フルハーネス（3エージェント） | 6時間 | $200 |
コストは20倍以上ですが、品質差は歴然でした。
ソロ実行の問題：
- レイアウトがスペースを無駄に使う
- ワークフローが不親切（操作順序がわからない）
- ゲームのプレイモードが動かない（エンティティ定義とランタイムの配線が壊れている）
ハーネス実行の成果：
- フルビューポートを活用した洗練されたUI
- スプライトエディタ、レベルエディタが充実
- AI統合でプロンプトからゲーム要素を生成可能
- ゲームが実際にプレイできる（物理演算に粗さはあるが動作する）
DAW（音楽制作ソフト）の事例
さらに Opus 4.6 で改良版ハーネス（スプリント構造を廃止、評価器を最後に1回だけ実行）を使い、DAW（デジタルオーディオワークステーション）を作らせた結果が興味深いです。
プロンプトはたった一文。「ブラウザで動くフル機能のDAWを Web Audio API で作って」。
ここから生まれたのが、3時間50分・$124で完成したブラウザベースの音楽制作アプリです。
| エージェント | 所要時間 | コスト |
|---|---|---|
| プランナー | 4.7分 | $0.46 |
| ビルド（1回目） | 2時間7分 | $71.08 |
| QA（1回目） | 8.8分 | $3.24 |
| ビルド（2回目） | 1時間2分 | $36.89 |
| QA（2回目） | 6.8分 | $3.09 |
| ビルド（3回目） | 10.9分 | $5.88 |
| QA（3回目） | 9.6分 | $4.06 |
| 合計 | 3時間50分 | $124.70 |
注目すべきは、ビルドエージェントが2時間以上連続で一貫して動作したこと。Opus 4.5 では必須だったスプリント分割なしで、です。
完成したアプリは、アレンジメントビュー、ミキサー、トランスポートを備えたブラウザ上の音楽制作環境でした。さらに、内蔵AIエージェントがプロンプトからテンポ設定、メロディ作成、ドラムトラック構築、ミキサーレベル調整、リバーブの追加まで自律的に行えました。
それでも評価器は実際のギャップを検出しました。1回目のQAでは「クリップのタイムライン上でのドラッグ移動ができない」「シンセのノブやドラムパッドのUIがない」といった、見た目は良くても操作として成立しない問題を指摘。2回目でも「オーディオ録音がスタブのまま」「エフェクトのビジュアライゼーションが数値スライダーだけでグラフィカルなEQカーブがない」と報告しました。
このように、モデルの能力が上がっても最後の1マイルを埋めるのに評価器は役立ちます。
ハーネスの進化：モデルが良くなったらスキャフォールドを削る
Anthropic チームの重要な洞察は、ハーネスの各コンポーネントは「モデルが単独でできないこと」への仮定をエンコードしているということです。
たとえば、スプリント分割は「モデルが長いタスクを一気にこなせない」という仮定に基づいていました。Opus 4.6 ではこの仮定が崩れたため、スプリントを廃止しても品質が維持されました。
逆に、評価器は依然として有効です。ただし、タスクの難易度がモデルの能力境界を超えている場合に限ってです。モデルが余裕を持ってこなせるタスクでは、評価器はオーバーヘッドでしかありません。
面白いハーネスの組み合わせは、モデルの進化とともに縮小するのではなく、移動する。
これはAIエンジニアリング全般に通じる洞察です。
実践への応用：今すぐ使えるヒント
Anthropic の実験は大規模ですが、Claude Code ユーザーが今日から活かせるエッセンスを3つ紹介します。
1. サブエージェントで「生成×評価」を再現する
Claude Code のサブエージェント機能を使えば、生成と評価を分離できます。
まず feature-a を実装して。
次に別のサブエージェントを起動して、
その実装をレビュー・テストさせて。
見つかった問題があれば修正して。
完全な3エージェント構成ではありませんが、自己評価の甘さを軽減する効果があります。
カスタムサブエージェントを使えば、さらに本格的な構成も可能です。
# .claude/agents/qa-reviewer.md
---
name: qa-reviewer
description: 実装されたコードの品質を厳しくレビューする
---
あなたは厳格なQAレビュアーです。以下の基準で実装を評価してください。
## 評価基準
1. 仕様通りに動作するか（スタブやモックで誤魔化していないか）
2. エッジケースが処理されているか
3. UIが直感的に操作できるか
4. エラー時にユーザーにフィードバックがあるか
少しでも問題があれば「不合格」とし、具体的な修正箇所を指摘してください。
「概ね良い」「小さな問題だから大丈夫」という判断は禁止です。
2. CLAUDE.md に評価基準を書く
Anthropic チームの4基準（デザインの質、オリジナリティ、クラフト、機能性）を参考に、プロジェクトの評価基準を CLAUDE.md に書いておきましょう。
# 品質基準
- UIは一貫した世界観を持つこと（色、タイポグラフィ、レイアウトの統一）
- テンプレート的なAIデザインを避けること（紫グラデーション、白カードの並びはNG）
- 各機能は実際に動作すること（スタブやモックで誤魔化さない）
- エッジケースのハンドリングを忘れないこと
3. Hooks でフィードバックループを自動化する
PostToolUse Hook でテスト自動実行を設定すれば、簡易的な評価ループが回ります。生成器が書いたコードに対して、テストという形で即座にフィードバックが返る。これだけでも品質は大きく変わります。
まとめ
Anthropic Labs のハーネス設計研究から得られる教訓をまとめます。
- 単一エージェントには構造的な限界がある。 コンテキスト不安と自己評価の甘さが品質の天井を作る
- 生成と評価を分離する。 GAN着想の「生成器＋評価器」パターンで、AIの自己評価バイアスを克服できる
- 評価基準を具体化する。 「美しいか？」ではなく「この基準を満たしているか？」に置き換える
- タスクを分解し、スプリント契約で完了条件を合意する。 曖昧な実装を防ぐ
- モデルの進化に合わせてハーネスを更新する。 不要になったコンポーネントを削り、新しい可能性を探る
AIモデルの能力が上がっても、興味深いハーネスの組み合わせは消えない。移動するだけです。その境界を見極め、適切なスキャフォールドを設計するのが、AIエンジニアの腕の見せどころでしょう。