GAN スタイルオーケストレーション スキル

Anthropicの長時間実行アプリケーション開発オーケストレーション設計（2026年3月24日）に着想を得ています

生成と評估を分離し、対抗的フィードバックループを形成する複数エージェント オーケストレーション。単一のエージェントが達成できる水準をはるかに上回る品質を推進します。

コア洞察

自分の仕事の評価を求められると、エージェントは病的な楽観主義者です――凡庸な出力を褒め、真の問題を無視するよう自分を説得します。しかし、独立した評估者を設計し、それを極度に厳格にすることは、生成器に自己批判を教えるよりもはるかに簡単です。

これはGAN（生成対抗ネットワーク）のメカニズムと同じです：生成器は出力を担当し、評估者は批判を担当し、このフィードバックが次のイテレーションを推進します。

適用シーン

• 1行のプロンプトから完全なアプリケーションを構築する
• 高い視覚品質が必要なフロントエンドデザインタスク
• コードだけでなく機能が必要なフルスタックプロジェクト
• 「AI ゴミ」の美学が受け入れられないタスク
• 本番品質の出力を得るために50～200ドルを投資する意思があるプロジェクト

不適用シーン

• 高速な単一ファイル修正（標準 claude -p を使用）
• 予算が限定されたタスク（<10ドル）
• 単純なリファクタリング（代わりにデバッグモードを使用）
• テスト仕様が充実しているタスク（TDD ワークフローを使用）

アーキテクチャ

                    ┌─────────────┐
                    │  プランナー  │
                    │  (Opus 4.6) │
                    └──────┬──────┘
                           │ 製品仕様
                           │ (機能、スプリント、設計方向)
                           ▼
              ┌────────────────────────┐
              │                        │
              │   生成器-評估器        │
              │    フィードバック      │
              │     ループ             │
              │                        │
              │  ┌──────────┐          │
              │  │ 生成器   │--構築-->│──┐
              │  │(Opus 4.6)│          │  │
              │  └────▲─────┘          │  │
              │       │                │  │ ライブアプリケーション
              │    フィードバック     │  │
              │       │                │  │
              │  ┌────┴─────┐          │  │
              │  │ 評估者   │<-テスト─│──┘
              │  │(Opus 4.6)│          │
              │  │+Playwright│         │
              │  └──────────┘          │
              │                        │
              │   5～15回の           │
              │   イテレーション      │
              └────────────────────────┘

3つのエージェント

1. プランナー エージェント

役割： プロダクトマネージャー――短いプロンプトを完全な製品仕様に拡張します。

主要な動作：

• 1行のプロンプトを受け取り、16の機能と複数のスプリントを含む仕様を生成
• ユーザーストーリー、技術要件、ビジュアルデザイン方向を定義
• 意図的に野心的――保守的な計画は凡庸な結果につながる
• 評估者が後で使用する評価基準を生成

モデル： Opus 4.6（仕様拡張に深い推論が必要）

2. 生成器 エージェント

役割： 開発者――仕様に基づいて機能を実装します。

主要な動作：

• 構造化スプリントで作業（または新しいモデルの連続モード）
• コード作成前に評估者と「スプリント契約」を交渉
• フルスタックツールを使用：React、FastAPI/Express、データベース、CSS
• イテレーション間のバージョン管理にgitを使用
• 評估者フィードバックを読み、次のイテレーションで対応

モデル： Opus 4.6（強力なコーディング能力が必要）

3. 評估者 エージェント

役割： QAエンジニア――コードだけでなく、ライブで実行されているアプリケーションをテストします。

主要な動作：

• Playwright MCP を使用してライブアプリケーションと対話
• 機能をクリック、フォームに入力、APIエンドポイントをテスト
• 4つの基準に基づいてスコアリング（カスタマイズ可能）：
  1. デザイン品質 ――一体性のある全体として感じられるか？
  2. 独創性 ――カスタム決定 vs. テンプレート/AI パターン？
  3. 職人技 ――タイポグラフィ、間隔、アニメーション、マイクロインタラクション？
  4. 機能性 ――すべての機能が実際に動作するか？
• スコアと具体的な問題を含む構造化フィードバックを返す
• 極度に厳格に設計――凡庸な仕事を褒めることはありません

モデル： Opus 4.6（強力な判断 + ツール使用能力が必要）

評価基準

デフォルトは4つの基準、各スコア 1～10：

## 評価基準

### デザイン品質（重み：0.3）
- 1～3点：テンプレート化された、典型的な「AI生成」美学
- 4～6点：合格だが平凡、慣例的なデザインに従う
- 7～8点：ユニークで一貫性のあるビジュアルアイデンティティ
- 9～10点：プロのデザイナーの作品と同等

### 独創性（重み：0.2）
- 1～3点：デフォルトのカラーパレット、テンプレートレイアウト、個性的ではない
- 4～6点：部分的にカスタマイズされた選択肢、全体的には従来のパターン
- 7～8点：明確なクリエイティブな思考、ユニークなデザインアプローチ
- 9～10点：驚きと喜び、真に新しい

### 職人技（重み：0.3）
- 1～3点：レイアウトの混乱、状態の欠落、アニメーション効果なし
- 4～6点：機能的だが粗い、間隔が不均一
- 7～8点：洗練された流れ、スムーズなトランジション、レスポンシブデザイン
- 9～10点：ピクセル完璧、喜びのあるマイクロインタラクション

### 機能性（重み：0.2）
- 1～3点：コア機能が破損または欠落
- 4～6点：メインフロー可能、エッジケース処理失敗
- 7～8点：すべての機能が動作、優れたエラーハンドリング
- 9～10点：完璧、すべてのエッジケースに対応

スコアリング

• 加重スコア = 合計（基準_スコア * 重み）
• 合格閾値 = 7.0（カスタマイズ可能）
• 最大イテレーション回数 = 15（カスタマイズ可能、通常 5～15 回で十分）

使用方法

コマンドラインから

# 完全な3エージェントオーケストレーション
/project:gan-build "Build a project management app with Kanban boards, team collaboration, and dark mode"

# カスタム設定を使用
/project:gan-build "Build a recipe sharing platform" --max-iterations 10 --pass-threshold 7.5

# フロントエンド設計モード（プランナーなし、生成器+評估者のみ）
/project:gan-design "Create a landing page for a crypto portfolio tracker"

Shell スクリプトから

# 基本的な使用方法
./scripts/gan-harness.sh "Build a music streaming dashboard"

# オプション付き
GAN_MAX_ITERATIONS=10 \
GAN_PASS_THRESHOLD=7.5 \
GAN_EVAL_CRITERIA="functionality,performance,security" \
./scripts/gan-harness.sh "Build a REST API for task management"

Claude Code から（手動）

# ステップ1：計画
claude -p --model opus "You are a Product Planner. Read PLANNER_PROMPT.md. Expand this brief into a full product spec: 'Build a Kanban board app'. Write spec to spec.md"

# ステップ2：生成（イテレーション1）
claude -p --model opus "You are a Generator. Read spec.md. Implement Sprint 1. Start the dev server on port 3000."

# ステップ3：評价（イテレーション1）
claude -p --model opus --allowedTools "Read,Bash,mcp__playwright__*" "You are an Evaluator. Read EVALUATOR_PROMPT.md. Test the live app at http://localhost:3000. Score against the rubric. Write feedback to feedback-001.md"

# ステップ4：生成（イテレーション2 ――フィードバックを読む）
claude -p --model opus "You are a Generator. Read spec.md and feedback-001.md. Address all issues. Improve the scores."

# モデルが合格するまでステップ3～4を繰り返す

モデル能力の進化に伴う展開

オーケストレーションはモデルの改善に伴い簡素化すべきです。Anthropicの進化経路に従う：

ステージ1 ――より弱いモデル（Sonnet レベル）

• スプリント分解が完全に必要
• スプリント間のコンテキストリセット（コンテキスト不安を回避）
• 最少2エージェント：初期化エージェント + コーディングエージェント
• モデル制限を補う大量のスキャフォルディング

ステージ2 ――能力型モデル（Opus 4.5 レベル）

• 完全な3エージェント オーケストレーション：プランナー + 生成器 + 評估者
• 各実装ステージ前にスプリント契約
• 複雑なアプリケーションを10のスプリントに分解
• コンテキストリセットは依然有用だが重要ではない

ステージ3 ――フロンティア モデル（Opus 4.6 レベル）

• 簡素化されたオーケストレーション：単一計画、連続生成
• 評価は単一の最終評価に簡素化（モデルがより知的）
• スプリント構造は不要
• コンテキスト増加の自動処理

重要な原則： オーケストレーションのすべてのコンポーネントは、モデルが独立して完了できないことについての仮説をエンコードしています。モデルが改善されるにつれて、これらの仮説を再テストしてください。もう必要ないパーツを削除してください。

設定

環境変数

変数	デフォルト値	説明
GAN_MAX_ITERATIONS	15	生成器-評估者ループの最大回数
GAN_PASS_THRESHOLD	7.0	合格に必要な加重スコア（1～10）
GAN_PLANNER_MODEL	opus	プランナーエージェントのモデル
GAN_GENERATOR_MODEL	opus	生成器エージェントのモデル
GAN_EVALUATOR_MODEL	opus	評估者エージェントのモデル
GAN_EVAL_CRITERIA	design,originality,craft,functionality	コンマ区切りの基準
GAN_DEV_SERVER_PORT	3000	ライブアプリケーションのポート
GAN_DEV_SERVER_CMD	npm run dev	開発サーバーを起動するコマンド
GAN_PROJECT_DIR	.	プロジェクト作業ディレクトリ
GAN_SKIP_PLANNER	false	プランナーをスキップ、仕様を直接使用
GAN_EVAL_MODE	playwright	playwright、screenshot または code-only

評価モード

モード	ツール	最適な用途
playwright	ブラウザ MCP + ライブインタラクション	UI付きフルスタックアプリケーション
screenshot	スクリーンショット + ビジュアル分析	静的ウェブサイト、純粋なデザイン
code-only	テスト + コード検査 + ビルド	API、ライブラリ、CLIツール

アンチパターン

1. 評估者が寛容すぎる――評估者が最初のイテレーションですべてを通す場合、スコアリング基準が寛容すぎます。スコアリングを厳しくし、一般的なAIパターンに明確なペナルティを追加してください。

2. 生成器がフィードバックを無視――フィードバックはファイル形式で渡されるべき、インラインではありません。生成器は各イテレーション開始時に feedback-NNN.md を読むべき。

3. 無限ループ――常に GAN_MAX_ITERATIONS を設定してください。生成器が3イテレーション後にスコアのプラトーを突破できない場合、停止して手動レビュー用にマークしてください。

4. 評估者のテストが表面的――評估者はスクリーンショットだけでなく、Playwright を使用してライブアプリケーションと対話する必要があります。ボタンをクリック、フォームに入力、エラー状態をテストしてください。

5. 評估者が自分の修正を褒める――評估者が修正を提案した後、それらを評価することを許可しないでください。評估者は批判を担当；生成器は修正を担当。

6. コンテキスト枯渇――長時間セッションの場合、Claude Agent SDK の自動圧縮を使用するか、主要ステージ間でコンテキストをリセットしてください。

結果：期待される効果

Anthropicが発表した結果に基づく：

メトリック	単一エージェント	GAN オーケストレーション	改善
時間	20分	4～6時間	12～18倍長い
コスト	9ドル	125～200ドル	14～22倍多い
品質	かろうじて使用可能	本番対応	質的変化
コア機能	欠陥あり	すべて動作	該当なし
デザイン	通常のAIゴミ	ユニークで精緻	該当なし

トレードオフは明白： 約20倍の時間とコストで、出力品質の質的飛躍を得られます。品質が重要なプロジェクトに適用できます。

参考

• Anthropic：長時間実行アプリケーションのオーケストレーション設計 ― Prithvi Rajasekaranによる原論文
• Epsilla：GAN スタイルエージェントループ ― アーキテクチャ解体
• Martin Fowler：オーケストレーション エンジニアリング ― より広い業界背景
• OpenAI：オーケストレーション エンジニアリング ― OpenAIの並行作業