- Anthropicは、フロントエンドのデザイン品質向上と長時間の自律コーディングという2つの課題を同時に解決するため、GANに着想を得たマルチエージェント構造を開発
- **ジェネレーター（generator）と評価器（evaluator）**を分離する構造により、主観的なデザイン品質を具体的な基準で採点できるようにし、エージェントの自己評価バイアスの問題を解決
- プランナー・ジェネレーター・評価器からなる3エージェントアーキテクチャにより、複数時間にわたる自律コーディングセッションでフルスタックアプリケーションを完成させ、スプリント契約の交渉やPlaywrightベースのQAも含む
- Opus 4.5からOpus 4.6への移行により、スプリント分割なしでも2時間以上一貫したコーディングが可能になり、ハーネスの複雑さを下げつつ性能を維持
- モデル性能が向上しても、興味深いハーネスの組み合わせ空間は縮小せず移動するのであり、AIエンジニアの中核課題は新しい組み合わせを見つけること
単純な実装が限界にぶつかる理由
- 以前の実験では、初期化エージェントが製品仕様をタスクリストに分解し、コーディングエージェントが機能を1つずつ実装した後、アーティファクトを通じてセッション間のコンテキストを受け渡す方式を使用
- 開発者コミュニティでも、**「Ralph Wiggum」**方式のように、フックやスクリプトでエージェントを持続的な反復ループに維持する類似のアプローチが登場
- 複雑なタスクでは、エージェントが時間の経過とともに軌道を外れる問題が続き、2つの共通する失敗モードが観察された
- 1つ目の失敗モード: コンテキストウィンドウが埋まるにつれてモデルが一貫性を失い、一部モデルでは**「コンテキスト不安（context anxiety）」**により、自身のコンテキスト限界に達したと判断すると作業を早めに切り上げようとする傾向が発生
- コンテキストリセット（コンテキストウィンドウ全体を空にし、前のエージェント状態と次のステップを含む構造化ハンドオフで新しいエージェントを開始）が、この2つの問題をどちらも解決
- これは、会話の前半を要約して同じエージェントが継続する**コンパクション（compaction）**とは異なるアプローチで、コンパクションは連続性を維持する一方でクリーンスレートを提供しないため、コンテキスト不安が残る可能性がある
- Claude Sonnet 4.5ではコンテキスト不安が強すぎて、コンパクションだけでは長期タスク性能を保証できなかったため、コンテキストリセットがハーネス設計の中核要素となった
- 2つ目の失敗モード: **自己評価（self-evaluation）**の問題で、エージェントが自分で作った成果物を評価すると、品質が明らかに平凡でも自信満々に褒める傾向がある
- とくにデザインのような主観的タスクで深刻であり、検証可能なソフトウェアテストに相当する二値チェックが存在しない
- 作業エージェントと評価エージェントを分離することが強力なレバーとなり、独立した評価器を懐疑的にチューニングするほうが、ジェネレーターを自己批判的にするよりはるかに扱いやすい
フロントエンドデザイン: 主観的品質を採点可能にする
- 介入なしでは、Claudeは技術的には機能するものの、視覚的には平凡な安全で予測可能なレイアウトをデフォルトで生成
- 2つの重要な洞察がハーネス設計を導いた
- 美しさそのものを完全に点数化することはできないが、デザイン原則と好みを符号化した採点基準によって改善できる — 「このデザインは美しいか？」よりも「これは良いデザイン原則に従っているか？」のほうが一貫した採点に向く
- フロントエンドの生成と採点を分離することで、ジェネレーターをより強い成果物へ導くフィードバックループを作る
- ジェネレーターと評価器の両方に与えた4つの採点基準:
- デザイン品質（Design quality）: 色、タイポグラフィ、レイアウト、画像などが組み合わさって、明確な雰囲気とアイデンティティを持つ一貫した全体になっているか
- 独創性（Originality）: カスタムな意思決定の痕跡があるか、それともテンプレートレイアウト、ライブラリのデフォルト、AI生成パターンに見えるか — 紫のグラデーションの上に白いカードのようなAI生成の兆候があれば失格
- 完成度（Craft）: タイポグラフィの階層、余白の一貫性、配色の調和、コントラスト比などの技術的実装 — 創造性ではなく力量の検査
- 機能性（Functionality）: 美しさとは独立した使いやすさ — ユーザーがインターフェースの役割を理解し、主要なアクションを見つけられるか
- デザイン品質と独創性を、完成度と機能性よりも高く重み付け — Claudeは完成度と機能性では元々高得点だった一方で、デザインと独創性では平凡な結果を出していたため
- 基準が非常に一般的な**「AIスロップ」**パターンを明示的に減点し、モデルに美的なリスクテイクを促した
- Claude Agent SDKでオーケストレーションを構築し、ジェネレーターがHTML/CSS/JSフロントエンドを生成し、評価器がPlaywright MCPでライブページと直接対話してスクリーンショットを撮り、実装を精査したうえで採点と詳細な講評を作成
- 生成ごとに5〜15回反復し、各反復で評価器の講評に応答しながら、ジェネレーターがより独自性の高い方向へ進む
- 実行全体では最大4時間かかる
- ジェネレーターには各評価後に戦略的判断を下すよう指示: スコア傾向が良ければ現在の方向を改善し、アプローチが機能していなければまったく異なる美学へ切り替える
- 基準の文言はジェネレーターに予想外の影響を与えた — **「最高のデザインはミュージアム品質」**のような表現が特定の視覚的収束を誘発し、基準と結びついたプロンプティングがアウトプットのキャラクターを直接形作った
- スコアは一般に反復を通じて向上したが、常に線形ではなく、最終反復よりも中間反復が好まれる場合も頻繁にあった
- 実装の複雑さは反復を重ねるごとに増える傾向があり、評価器フィードバックに応じて、より野心的な解決策を追求した
- 初回反復の時点で、プロンプトなしのベースラインより明らかに良い結果が出ており、基準と関連言語そのものが、評価器フィードバック以前からモデルを一般的なデフォルトから外へ導いていた
- オランダ美術館のWebサイト事例: 9回目の反復までは洗練されたダークテーマのランディングページを作っていたが、10回目の反復でアプローチを全面的に破棄し、CSSパースペクティブでレンダリングした3Dルーム、チェッカーボードの床、壁に自由に掛けられた作品、ドアを通じたギャラリー間ナビゲーションという空間体験へ再構成 — 単発生成では見られなかった種類の創造的飛躍
フルスタックコーディングへの拡張
アーキテクチャ
- 以前の長時間実行ハーネスでは、初期化エージェント、機能ごとのコーディングエージェント、セッション間のコンテキストリセットにより、一貫したマルチセッションコーディングを実現
- Sonnet 4.5のコンテキスト不安のためコンテキストリセットが重要だったが、Opus 4.5ではこの挙動がほぼ解消され、コンテキストリセットなしで単一の連続セッションとして全体ビルドを実行
- Claude Agent SDKの自動コンパクションがコンテキスト増加を処理
- 3エージェントシステムを構成:
- プランナー（Planner）: 1〜4文の短いプロンプトを完全な製品仕様へ拡張 — 詳細な技術実装よりも製品コンテキストと上位レベルの技術設計に集中するようプロンプト化。細かい技術事項を事前指定すると誤りが下流へ伝播するおそれがあるため
- AI機能を製品仕様に**織り込む（weave）**機会を探すよう指示
- ジェネレーター（Generator）: スプリント単位で仕様から機能を1つずつ取り上げ、React/Vite/FastAPI/SQLite（後にPostgreSQL）スタックで実装し、各スプリント終了時に自己評価後QAへハンドオフし、gitでバージョン管理
- 評価器（Evaluator）: Playwright MCPで動作中のアプリケーションを実ユーザーのようにクリック操作して、UI機能、APIエンドポイント、データベース状態をテスト — 製品の深さ、機能性、視覚デザイン、コード品質の基準で採点し、基準ごとのハードしきい値を下回るとスプリント失敗
- 各スプリント前に、ジェネレーターと評価器がスプリント契約（sprint contract）を交渉 — コードを書く前に、その作業チャンクにおける「完了」の定義に合意する
- 製品仕様が意図的に高レベルだったため、ユーザーストーリーとテスト可能な実装の間のギャップを埋める段階
- コミュニケーションはファイルベースで処理 — 片方のエージェントがファイルを書き、もう片方がそれを読んで応答
ハーネス実行結果: レトロゲームメーカー
- **「レベルエディタ、スプライトエディタ、エンティティの挙動、プレイ可能なテストモードを含む2Dレトロゲームメーカーを作れ」**というプロンプトでテスト
- ソロエージェント: 20分 / $9 vs フルハーネス: 6時間 / $200 — ハーネスは20倍以上高価だったが、成果物の品質差は即座に明確だった
- ソロ実行の結果: 初期画面は期待に沿っていたが、クリックしていくと問題が露呈 — レイアウトは空間を無駄に使い、ワークフローは硬直的で、スプライトとエンティティを先に作る必要があるのにUIがそれを案内せず、肝心の実際のゲームが動作しない（エンティティは画面に現れるが入力に反応せず、エンティティ定義とゲームランタイムの配線が切れている）
- ハーネス実行の結果: プランナーが1文のプロンプトを10スプリントにまたがる16個の機能仕様へ拡張 — スプライトアニメーションシステム、行動テンプレート、効果音と音楽、AI支援スプライト生成器とレベルデザイナー、共有可能リンクによるゲーム書き出しを含む
- フロントエンドデザインのスキルを読み取り、アプリの視覚デザイン言語も仕様の一部として生成
- キャンバスはビューポート全体を活用し、パネルサイズは合理的で、仕様のデザイン方針に従う一貫した視覚的アイデンティティを持つ
- スプライトエディタはより豊富で完全な機能を備え、ツールパレットはより整理され、カラーピッカーはより良く、ズーム操作も使いやすい
- AI統合により、プロンプト経由でゲームのさまざまな部分を生成してワークフローを加速
- プレイモードでの決定的な違い: ソロ実行ではゲームが動かなかったが、ハーネス実行では実際にエンティティを動かしてプレイ可能 — 物理エンジンにはやや粗さ（プラットフォームとキャラクターの重なり）や、AIレベル構成の限界（跳べない大きな壁）はあったものの、中核機能は動作した
- 評価器が実装を仕様に沿わせる役割を果たした — Sprint 3だけでも、レベルエディタについて27個の基準をカバーする細かな契約があった
- 発見された問題の例: 長方形塗りつぶしツールがドラッグ開始/終了地点にしかタイルを置かない、エンティティ削除キーのハンドラに条件分岐ミス、FastAPIルート順序の問題で
reorderを整数として解釈して422エラーを返す
- 評価器のチューニングには相当な労力が必要 — 初期状態のClaudeは粗雑なQAエージェントで、妥当な問題を見つけても自分で自分を説得して「大した問題ではない」と承認しがちで、表面的なテストで微妙なバグを見落とした
- 評価器ログを読み、判断が分岐する事例を探してQAプロンプトを更新する開発ループを何度も繰り返した末に、ようやく妥当な採点に到達
ハーネスの反復改善
- 初期結果は有望だったが、大きく、遅く、高価だったため、性能を落とさずにハーネスを単純化することが次の段階となった
- ハーネスの各構成要素は、モデルが単独ではできないことについての仮定をコード化しており、そのような仮定はストレステストする価値がある — モデルの向上で急速に陳腐化する可能性があるため
- **「可能な限り単純な解決策を見つけ、必要なときだけ複雑さを増やす」**という原則
- 急進的な単純化の試みでは元の性能を再現できず、どの要素が実際に負荷を支えているのか把握しにくかったため、一度に1要素ずつ取り除く系統的アプローチへ移行
- Opus 4.6のリリースもハーネス複雑度削減の追加動機となった — より慎重に計画し、エージェント的タスクをより長く維持し、大規模コードベースでも安定して動作し、自身のミスを見つけるコードレビュー/デバッグ能力が向上し、長いコンテキスト検索も大幅に改善されたため
スプリント構造の削除
- スプリント構造を完全に削除 — Opus 4.6の能力向上により、モデルが分解なしでも作業を一貫して処理可能になった
- プランナーと評価器は維持 — プランナーがないと、ジェネレーターはスコープ不足になり、生のプロンプトだけで仕様なしにビルドを始め、機能の少ないアプリケーションになってしまう
- 評価器はスプリントごとの採点から、実行終了時の単一パスへ移行
- タスクがモデル単独の能力範囲に収まるなら評価器は不要なオーバーヘッドになるが、モデル能力の境界にあるタスクでは依然として実質的な改善をもたらす
- したがって評価器は固定的な要否ではなく、現在のモデルが単独で安定実行できる範囲を超えるときにコストに見合う
- AI機能のビルド改善に向けたプロンプティングも追加 — ジェネレーターに、アプリ自身の機能をツール経由で駆動する適切なエージェントを構築させるには相当な反復が必要だった。関連知識が新しく、Claudeの学習データでのカバーが薄かったため
更新後ハーネスの結果: ブラウザDAW
- **「Web Audio APIを使って、ブラウザ上でフル機能のDAWを構築せよ」**というプロンプトでテスト
- 合計約4時間、$124.70を要した
- プランナー 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
- ビルダーはスプリント分解なしで2時間以上一貫して実行
- QAエージェントの初回フィードバック: デザインの忠実度、AIエージェント、バックエンドは優秀だが、機能の完全性が主な失敗点 — タイムラインでクリップをドラッグ/移動できない、楽器UIパネル（シンセノブ、ドラムパッド）がない、視覚エフェクトエディタ（EQカーブ、コンプレッサーメーター）がない
- QAの2回目フィードバック: 音声録音はスタブのまま、クリップのリサイズと分割は未実装、エフェクト可視化はグラフィックではなく数値スライダーになっている
- 最終アプリはプロ向け音楽制作ソフトには及ばず、エージェントの作曲能力にも改善の余地がある。Claudeは実際に音を聞くことができないため、QAフィードバックループは音楽的センスの面では効果が薄い
- それでも、動作するアレンジメントビュー、ミキサー、トランスポートを含み、機能する音楽制作プログラムの中核要素を備えている
- プロンプティングだけで短い楽曲スニペットを作成可能 — エージェントがテンポとキーを設定し、メロディを配置し、ドラムトラックを作り、ミキサーレベルを調整し、リバーブを追加
今後の展望
- モデルが改善すれば、より長く、より複雑なタスクを実行できるようになると見込まれ、一部ではモデルを取り巻くスキャフォールドの重要性が下がり、次のモデルを待つだけで特定の問題が自然に解決する可能性もある
- 一方で、モデルが良くなるほど、ベースラインを超える複雑なタスクを達成するハーネスを開発できる空間も広がる
- 重要な教訓:
- 対象モデルを使って実験し、現実的な問題でトレースを読み、望む結果に合わせて性能をチューニングすることは常によい実践
- より複雑なタスクでは、タスクを分解し、各側面に特化したエージェントを適用することで余地を生み出せる
- 新モデルが出たらハーネスを見直し、もはや性能を支えない部分を削除し、以前は不可能だったより大きな能力を達成するための新しい部分を追加するのがよい実践
- モデルが向上しても、興味深いハーネスの組み合わせ空間は縮小せず移動するのであり、AIエンジニアの課題は次の新たな組み合わせを見つけ続けること
まだコメントはありません。