Anthropicは2026年3月24日(米国時間)、エージェンティックコーディングの最前線での性能を左右するハーネス設計に関する技術記事を公開しました。Labsチームの筆者が、Claudeに高品質なフロントエンドデザインを作らせる課題と、人の介入なしに完全なアプリケーションを構築させる課題に取り組み、敵対的生成ネットワーク(GAN)に着想を得て生成エージェントと評価エージェントを分離するマルチエージェント構造を設計。最終的にプランナー、ジェネレーター、エバリュエーターの3エージェント構成で、数時間の自律コーディングセッションからリッチなフルスタックアプリを作り上げた過程を解説しています。

素朴な実装が抱える2つの失敗モード

1つ目は、コンテキストウィンドウが埋まるにつれてモデルが長いタスクで一貫性を失う問題です。一部のモデルは、自分のコンテキスト限界に近づいたと考えると作業を早めに切り上げる「コンテキスト不安」も示します。コンテキストを完全にクリアし、前のエージェントの状態と次のステップを構造化された引き継ぎで渡して新しいエージェントを開始するコンテキストリセットで両方に対処できますが、オーケストレーションの複雑さ、トークンのオーバーヘッド、レイテンシが増えます。会話を要約して同じエージェントが継続するコンパクションでは、まっさらな状態にはならずコンテキスト不安が残り得るとしています。

2つ目は自己評価の問題です。エージェントは自分が作った成果物を評価させると、人間の目には明らかに平凡でも自信を持って称賛する傾向があり、デザインのように検証可能なテストがない主観的タスクで特に顕著です。作業するエージェントと評価するエージェントを分離することが有効な打ち手で、独立した評価者を懐疑的にチューニングする方が、生成者に自分の作品への批判をさせるよりはるかに扱いやすく、外部からのフィードバックがあれば生成者はそれに対して具体的に反復できるとしています。

フロントエンドデザインを採点可能にする4基準

• ▸デザイン品質 — 部品の寄せ集めでなく一貫した全体を感じさせるか。色、タイポグラフィ、レイアウト、画像などが組み合わさって独自のムードと個性を生んでいるか
• ▸独自性 — テンプレートレイアウトやライブラリの既定値、AI生成にありがちなパターンではなく、意図的な創造的判断の証拠があるか。白いカードに紫のグラデーションのようなAI生成の典型は不合格
• ▸技巧 — タイポグラフィの階層、余白の一貫性、色の調和、コントラスト比といった技術的実行力を確認する能力チェック
• ▸機能性 — 見た目と独立した使いやすさ。ユーザーがインターフェースの目的を理解し、主要な操作を見つけ、迷わずタスクを完了できるか

Claudeは技巧と機能性には既定で強かったため、デザイン品質と独自性を重く重み付けして美的なリスクテイクを促しました。評価者は詳細なスコア内訳付きのfew-shot例で調整し、Claude Agent SDK上にループを構築。評価者にはPlaywright MCPを与え、実際のページを自ら操作しスクリーンショットを取って精査してから採点と詳細な批評を書かせ、その内容を次の反復の入力として生成者に戻しました。1回の生成につき5〜15回反復し、フルランは最大4時間に及びました。

スコアは反復とともに改善して頭打ちになる傾向でしたが、常に直線的ではなく、中間の反復の方が好ましい場合もありました。オランダの美術館サイトの例では、9回目まで洗練されたダークテーマのランディングページだったものが、10回目でCSSの遠近法で描いた3D空間の部屋に作品を自由に配置し、ドアで展示室を移動する構成へと全面的に作り直され、単発生成では見たことのない創造的飛躍だったとしています。

フルスタック開発への拡張と3エージェント構成

• ▸プランナー — 1〜4文の簡単なプロンプトを完全なプロダクト仕様に拡張。スコープには野心的に、詳細な技術実装ではなくプロダクト文脈と高レベル設計に集中させ、AI機能を仕様に織り込むよう指示
• ▸ジェネレーター — 仕様から1機能ずつスプリント単位で実装。React、Vite、FastAPI、SQLite(後にPostgreSQL)のスタックで構築し、各スプリント終了時に自己評価してからQAに引き継ぎ。バージョン管理にgitを使用
• ▸エバリュエーター — Playwright MCPで実際にアプリを操作してUI機能、APIエンドポイント、データベースの状態をテストし、発見したバグと、プロダクトの深さ・機能性・ビジュアルデザイン・コード品質の基準で各スプリントを採点。1つでも閾値を下回るとそのスプリントは不合格

各スプリントの前には、生成者と評価者がそのスプリントの「完了」の定義を合意するスプリント契約を交渉し、エージェント間の連絡はファイルの読み書きで行います。Claude Opus 4.5を使った初版では、レトロゲームメーカーの生成でソロ実行が20分・9ドル、フルハーネスが6時間・200ドルと20倍以上高価でしたが、ソロ版はゲーム実行部分の配線が壊れて遊べなかったのに対し、ハーネス版はプランナーが16機能・10スプリントの仕様に拡張し、実際に遊べるゲームとAI統合機能を備えるなど品質差は歴然だったとしています。

評価者を役立つ水準にするには作り込みが必要で、当初は正当な問題を見つけても大したことではないと自分を納得させて承認してしまうなど、Claudeは素のままではQAが不得意でした。ログを読んで判断のずれを見つけ、プロンプトを更新するループを数回繰り返して調整しています。

Opus 4.6でのハーネス簡素化と結果

ハーネスの各構成要素はモデルが単独ではできないことについての仮定を符号化したものであり、モデルの改善で急速に陳腐化するため、構成要素を1つずつ外して影響を確認する方法で簡素化を進めました。計画性や長時間の自律作業が向上したClaude Opus 4.6では、スプリント構造を撤廃して1つの連続セッションで構築させ、評価も最後の一括実行に変更。一方、プランナーがないと生成者は仕様化せずに作り始めて機能の少ないアプリになり、評価者もモデルの能力の限界近くにあるタスクでは実質的な向上をもたらすため、両者は残しました。

簡素化後のハーネスでブラウザで動くDAW(音楽制作ソフト)を生成させたところ、約3時間50分・約124ドルで、2時間を超えて一貫して動き続けたビルドを含む3ラウンドのビルドとQAを実行しました。QAはクリップをドラッグで動かせない、録音機能がスタブのままといった中核機能の欠落を具体的に指摘し続け、最終的にアレンジビュー、ミキサー、トランスポートが動作し、組み込みエージェントがテンポ設定、メロディや、ドラムトラックの作成、ミキサー調整までプロンプトだけで行えるアプリが完成しました。

結論として、モデルが改善するほどスキャフォールドの重要性が下がる場合もある一方、モデルの素の能力を超える複雑なタスクを実現するハーネスの設計余地はなくならずに移動し続けるとし、新しいモデルが出たらハーネスを再点検し、性能に寄与しなくなった部品を外して新しい能力を足すことを推奨しています。