Claude Code Advent Calendar 2025

Claude Codeで実現する評価駆動開発 - 32個のエージェントが品質を守る仕組み

Last updated at 2025-12-02Posted at 2025-12-02

この記事は Claude Code Advent Calendar 2025 の12月3日の記事です。

「AIが書いたコード、どうなんだろう？」

Claude Codeを使い始めて1ヶ月、毎日このような思いを抱えていました。
コード生成は爆速なんですけど、結局全部人間がレビューしないといけなくて、生成されたコードの中には「...なんでこうなった？？」という謎コードも多々ありました。

そこから約2ヶ月間、試行錯誤して作ったのが EDAF（Evaluator-Driven Agent Flow） です。

結論から言うと、EDAFは大抵の言語・フレームワーク・アーキテクチャーを自動検出して、ソフトウェア開発を5つのフェーズで管理する自己適応型システムです。

Design Gate (設計)
Planning Gate (計画)
Implementation (実装)
Code Review Gate (コードレビュー)
Deployment Gate (デプロイ準備)

各フェーズの役割を簡単に説明します：

Design Gate（設計の品質保証）

やること: Designerエージェントが機能の設計書を作成
チェック項目: 7つの専門エージェントが並列で多角的に評価

一貫性 - 設計に矛盾がないか？
拡張性 - 将来的に機能追加しやすいか？
目標整合性 - 要件を満たしているか？
保守性 - メンテナンスしやすいか？
可観測性 - ログ・監視の設計は適切か？
信頼性 - エラーハンドリングは十分か？
再利用性 - 既存コードを活用できているか？

合格基準: 全評価が7.0/10.0以上
不合格時: Designerが設計を修正 → 再評価（合格まで繰り返す）

Planning Gate（タスク分解の品質保証）

やること: Plannerエージェントが実装タスクに分解
チェック項目: 7つの専門エージェントが並列で検証

明確性 - タスクの内容が明確か？
成果物構造 - 作成するファイル構成は適切か？
依存関係 - タスクの実行順序は正しいか？
目標整合性 - 設計書と一致しているか？
粒度 - タスクが適切な大きさに分割されているか？
責任整合性 - 各タスクの担当が明確か？
再利用性 - 既存の実装パターンを活用しているか？

合格基準: 全評価が7.0/10.0以上

Implementation（専門Workerによる実装）

やること: 4つの専門Workerエージェントがコードを生成

database-worker → データベースモデル・マイグレーション
backend-worker → API・ビジネスロジック
frontend-worker → UI コンポーネント
test-worker → ユニットテスト・統合テスト

特徴: 各Workerは/setup実行時に検出されたプロジェクトの技術スタック（言語・フレームワーク・ORM）を参照して、プロジェクトに適したコードを生成

Code Review Gate（コード品質の保証）

やること: 7つの専門エージェントが生成されたコードを並列でレビュー

品質 - コードの可読性・保守性は十分か？
テスト - テストカバレッジは適切か？
セキュリティ - SQLインジェクション・XSS対策は万全か？
ドキュメント - コメント・型定義は十分か？
保守性 - 将来的な変更に強い設計か？
パフォーマンス - N+1問題などはないか？
実装整合性 - 設計書・タスク計画と一致しているか？

フロントエンド変更時は追加で:

UI/UX検証（ブラウザ自動化でスクリーンショット取得、動作確認）

合格基準: 全評価が7.0/10.0以上
不合格時: Workerがコードを修正 → 再評価

Deployment Gate（本番投入前の最終チェック）※オプション

やること: 5つの専門エージェントがデプロイ準備を検証

準備状況 - 環境変数・設定ファイルは揃っているか？
本番セキュリティ - 本番環境特有のリスクはないか？
可観測性 - ログ・メトリクス・アラートは設定されているか？
パフォーマンス - 負荷試験は実施されているか？
ロールバック計画 - 問題発生時の切り戻し手順はあるか？

合格基準: 全評価が7.0/10.0以上

なぜ7.0/10.0が合格基準なのか？

EDAFでは全フェーズで「7.0/10.0以上」を合格ラインとしていますが、この基準は実運用での試行錯誤を経て設定されました。

スコアの意味:

6.0以下: 明らかな問題あり（設計の矛盾、セキュリティリスク、実装の欠陥など）
- → 必ず修正が必要
7.0-7.9: 実用レベル、改善余地あり
- → プロジェクトの文脈次第で「OK」または「修正」を判断
8.0-8.9: 高品質
- → そのまま次フェーズへ進んで問題なし
9.0以上: 非常に優れている
- → 理想的な状態

なぜ7.0なのか？

当初は8.0/10.0を基準にしていましたが、実際に運用してみると以下の問題がありました：

過剰品質になりがち: 8.0を目指すと、実装に時間がかかりすぎる
完璧主義の罠: 細部にこだわりすぎて、本質的な機能実装が遅れる
プロジェクトの文脈を無視: スタートアップと大企業では求められる品質が異なる

一方で、7.0/10.0を基準にすると：

✅ 実用レベルの品質を保ちつつ、スピードも確保できる
✅ 人間が最終判断する余地がある（7.5でOKにするか、修正を求めるか）
✅ プロジェクトの特性（スピード重視 or 品質重視）に応じて柔軟に対応できる

実際の運用例:

Design Evaluator の評価結果:
- Goal Alignment: 8.5/10 ✅
- Extensibility: 7.2/10 ✅
- Security: 6.8/10 ⚠️  → 修正必要
- Maintainability: 7.5/10 ✅

→ Security が 7.0 未満のため、Designer に修正を依頼
→ 修正後、再評価で 7.3/10 になり、次フェーズへ

この基準により、「完璧」を目指すのではなく「十分に良い」状態で前進するバランスの取れた開発が可能になります。

重要な仕組み:
EDAFは上記のフェーズをスキップせず、全評価エージェントの承認を得てから次に進む厳格なゲート管理により、高品質な開発を自動的に保証します。同時に、要望書駆動開発・仕様駆動開発・対話駆動開発を阻害しない柔軟性も兼ね備えています。

あなたの役割:
各フェーズで生成されたドキュメント（設計書・タスク計画）とエージェントのレビュー結果を読み、プロジェクトの文脈に沿った判断を下す。EDAFと協力して、品質の高いコードを作り上げていくパートナーシップです。

TL;DR（EDAF）

# 1. Git Clone & 事前準備
cd /path/to/your/project
git clone git@github.com:Tsuchiya2/evaluator-driven-agent-flow.git
bash evaluator-driven-agent-flow/scripts/install.sh

# 2. Claude Code起動 & /setup 実行
claude

/setup

# 3. 片付け & Claude Code再起動
rm -rf evaluator-driven-agent-flow

claude

> 「エージェントフローに沿って、〇〇機能を実装して」

/setupコマンドで対話的セットアップ（使用言語・フレームワーク・アーキテクチャーの自動検出、ドキュメント作成に使用する言語の設定、ターミナル出力の言語設定、Docker環境の検出など）が行われます。セットアップ完了後は、「エージェントフローに沿って、」という枕詞を付けて指示を出すだけで、5つのフェーズに沿った開発が自動実行されます。

実行される内容:

✅ 設計 - Designer が作成 → 7つのEvaluatorが多角的に並列レビュー -> 全Evaluatorが 7.0/10.0 以上の評価を出すまで設計の修正を繰り返す
✅ 計画 - Planner が分解 → 7つのEvaluatorが多角的に並列レビュー -> 全Evaluatorが 7.0/10.0 以上の評価を出すまでタスク化の修正を繰り返す
✅ 実装 - 4つのWorkerがコードを生成
✅ コードレビュー - 生成されたコードを7つのEvaluatorが多角的に並列レビュー + UI/UX検証（フロントエンド変更時）-> 全Evaluatorが 7.0/10.0 以上の評価を出すまでコードの修正を繰り返す
✅ デプロイ準備 - 5つのEvaluatorが本番投入前の最終チェック（オプション） -> 全Evaluatorが 7.0/10.0 以上の評価を出すまで問題の修正と再評価を繰り返す

あなたの役割: 各フェーズで生成されたドキュメントとEvaluatorのレビュー結果を読み、プロジェクトの文脈に沿った判断を下す。EDAFと協力して、品質の高いコードを作り上げていくパートナーシップです。

重要: EDAFは「AIが全て自動でやる」ツールではありません。**「人間とAIが協力して品質を作る」**新しい開発スタイルの提案です。

1. EDAFの特徴

「エージェントフローに沿って、〇〇を実装して」

この一言だけで、以下が自動実行されます：

Designerエージェントが設計書を作成
設計書に対して7つの専門サブエージェントが設計を多角的に並列レビュー
Plannerエージェントがタスクを分解
タスクに対して7つの専門サブエージェントがタスクを多角的に並列検証
4つのWorkerエージェント（データベース・バックエンド・フロントエンド・テストコード）がコードを生成
7つの専門サブエージェントがコードを品質・セキュリティ・パフォーマンス・可読性など多角的に並列レビュー
ブラウザ自動化でUI/UXを実際に検証（UIに関して変更がある場合）

あなたの役割: Claude Codeが生成したドキュメントや専門サブエージェントのレビュー内容を読み、プロジェクトの文脈に沿った判断を下す。コードレビューの負荷は大幅に軽減されますが、最終的な意思決定は人間が行います。

これが EDAF (Evaluator-Driven Agent Flow) - AIと人間の協調による品質保証フレームワークです。

2. なぜ作ったのか

この記事の冒頭にも書きました「AIが書いたコード、どうなんだろう？」という思いを抱えていた際に、10/17(金)にAIエージェントユーザー会（AIAU）主催で開かれた Claude Code Meetup Tokyoで聞いたkuuさんの"Context Engineering を意識して Claude Code を最大限活用しよう"発表に刺激を受け、EDAFは動き始めました。

「親エージェントから子エージェントにタスクを委譲して、子エージェントは孫エージェントに実装を委譲し、孫エージェントの成果物を子エージェントが評価・フィードバックをして孫エージェントに返すサイクルをぐるぐる回して、最終的な成果物を親エージェントが評価...」

確か...こんな話をされていたかと思います。正直、話を聞いたときは「えっ!?AI使った開発って今そんな感じなの!?」と衝撃を受けたのを今でも覚えています。

早速社内の主プロジェクトで親エージェント・子エージェント・孫エージェントの3層構造を試してみたんですが...親から子へは上手く伝播するんですが子から孫への伝播に悪戦苦闘しました。Claudeにそもそもそんなことが可能なのかを訪ねたり、自分で公式ドキュメントを読んだりした結果、3層構造は諦めてしまいました...

ただその悪戦苦闘する中で、メインClaude Codeから専用のサブエージェントにタスクを委譲し、その成果物を評価専門のサブエージェントにレビューさせるという「評価駆動」のアイデアが生まれました。（評価駆動という言葉が適切かはまだ自分の中でも迷いはありますが...一旦そう言わせてください🙇）

Claude Code Meetup Tokyoから約2週間、以下のEDAFプロトタイプのプルリクエストをチームに提出し、CTOからGOサインをもらって主プロジェクトに導入しました。

■ EDAFプロトタイプ概要
実行エージェント（designer/planner/worker/reviewer）と評価エージェント（design-evaluator/planner-evaluator/review-evaluator）が連携し、評価エージェントが品質判定を行ってフィードバックサイクルを回しながらフロー全体を駆動する点が最大の特徴です。

フローは以下の4フェーズで構成しました。

Design Gate（設計ゲート）: 設計書の品質保証
Implementation Gate（実装ゲート）: タスクリスト作成と実装の品質保証
Review Gate（レビューゲート）: セキュリティ・UI/UX含むコードレビュー（Chrome DevTools MCP使用）
Deployment Ready（デプロイ準備完了）: 最終報告とドキュメント化

このプロトタイプでは、社内のメンバーの特徴も踏まえて以下のような工夫をしました。

設計書をしっかり書いてからAIに投げる派：Claude Codeに設計書のあるパスを渡すと、自動でEDAFのフローが開始される
とりあえずAIに投げて動いたらOK派：「エージェントフローに沿って、」の枕詞を付けると、自動でEDAFのフローが開始される
エージェントフローを使うまでもない簡単なタスク：通常のClaude Codeとして動作可能
新人さん向け：コードベース探索・類似コード検索・依存関係追跡をカスタムスラッシュコマンド、詳細調査用専門エージェントを内包。

これがEDAFの前身でした。ここから他のプロダクトにも展開できたら...生成されるドキュメントの言語が選べたら...ターミナルに出力される言語も指定できて...勝手にプロジェクトの言語・フレームワーク・アーキテクチャーを検出してくれたら...など、色々なアイデアが湧いてきて、最終的に現在のEDAFに落ち着きました。

3. EDAFの革新性

3-1. Self-Adapting機能（苦労した部分）

EDAFは32個のエージェントファイルで構成されてるんですが、
ハードコードされたコードテンプレートが1つもありません。

「え、どういうこと？」って思いますよね。

つまり：

TypeScriptプロジェクト → TypeScriptのコードを生成
Goプロジェクト → Goのコードを生成
Pythonプロジェクト → Pythonのコードを生成

でも、設定ファイルに「言語：TypeScript」とか書いてないんですよ。

/setup コマンド実行時に、勝手にプロジェクトを読み取って適応してくれます。

検証状況と動作実績

現在の検証状況:

EDAFは以下の環境で動作確認済みです：

言語/FW	検証状況	備考
Ruby + Rails	✅ 本番運用中	自社サービスプロダクトに導入して1ヶ月運用中
Python + Django	✅ 本番運用中	自社サービスプロダクトに導入して完成、運用開始中
Go	✅ 本番運用中	個人開発で活用中、ラズパイで本番運用中
TypeScript + Next.js	✅ 検証済み	自社サービスプロダクトで検証済み、対応可能を確認
PHP + Laravel	✅ 検証済み	自社サービスプロダクトで検証済み、対応可能を確認
TypeScript + NestJS	📋 未検証	検証予定
その他	📋 未検証	フィードバック募集中

全ての技術スタック・プロジェクト構成で完全検証できているわけではありませんが、Ruby/Python/TypeScript/PHP/Go系のWeb開発スタックで実際に運用・検証を進めています。

Self-Adaptingの仕組み:

/setup コマンド実行時に以下を自動検出：

言語: package.json、go.mod、requirements.txt等から判定
フレームワーク: 依存関係から使用FWを特定
ORM: データベースライブラリから判定
テスティングFW: テスト構成ファイルから検出
アーキテクチャパターン: ディレクトリ構造・既存コードから学習

検出結果は .claude/CLAUDE.md に記録され、全32個のエージェントがこれを参照してプロジェクトに適したコードを生成します。

もし未対応のスタックを使用している場合:

/setup が対話的に質問して設定を補完
.claude/edaf-config.yml で手動設定も可能
GitHub Issues でご報告いただければ対応を検討します

3層の自動適応システム

すべての自動適応は /setup コマンド実行時 に行われます。

Layer 1: 自動検出（/setup が実行）
  ├─ package.json/go.mod/requirements.txt などを読む
  ├─ 使用言語・フレームワーク・ORMを特定
  ├─ 既存コードパターンを学習
  └─ .claude/CLAUDE.md に検出結果を書き込む

Layer 2: 設定ファイル（必要に応じて）
  └─ .claude/edaf-config.yml で明示指定

Layer 3: 対話的質問（フォールバック）
  └─ 検出できない場合のみ質問

結果、TypeScript/React から Go/Clean Architecture、Python/Django まで一切の設定変更なしで動作します。

具体例:

# Next.js + Prisma のプロジェクトで /setup を実行
→ 自動検出: TypeScript, React, Next.js, Prisma, Jest
→ 生成コード: Next.js の App Router パターン、Prisma スキーマ

# Django + PostgreSQL のプロジェクトで /setup を実行
→ 自動検出: Python, Django, Django ORM, pytest
→ 生成コード: Django のクラスベースビュー、マイグレーションファイル

# 設定ファイル変更は一切不要！

対応技術スタック

言語（11種類）:
TypeScript, JavaScript, Python, Java, Go, Rust, Ruby, PHP, C#, Kotlin, Swift

フレームワーク（50+）:

Backend: Express, FastAPI, Spring Boot, Gin, Django, Flask, NestJS, Rails, Laravel
Frontend: React, Vue, Angular, Svelte, Solid, Next.js, Nuxt, SvelteKit
ORM: Sequelize, TypeORM, Prisma, Django ORM, SQLAlchemy, Hibernate, GORM, ActiveRecord
Testing: Jest, pytest, JUnit, Go test, RSpec, PHPUnit, Playwright, Cypress

/setup コマンド完了後の構成

.claude/
├── CLAUDE.md                    # 自動生成された設定
├── edaf-config.yml             # プロジェクト設定
├── settings.json               # 通知フック設定
├── agents/
│   ├── designer.md             # Designer Agent
│   ├── planner.md              # Planner Agent
│   ├── workers/                # 4 Workers
│   └── evaluators/             # 26 Evaluators
├── commands/
│   └── setup.md                # /setup コマンド
├── scripts/
│   ├── notification.sh         # 通知スクリプト
│   └── verify-ui.sh           # UI検証スクリプト
└── sounds/                     # 通知音

3-2. UI/UX検証の自動化

従来のUI検証って...以下もしくはE2Eテストを書いて検証する感じですよね？

Code生成 → ブラウザ開く → 手動でクリック → スクショ撮る → 目視チェック
           ↑             ↑                ↑             ↑
        めんどくさい    時間かかる      忘れがち    見落とす

私はあまりメインでフロントエンド開発に携わることは少ないんですが、それでも**UI変更があるたびにこの作業をやるのは思った以上に時間を取られるな...**と思っていました。

まだ試作段階ですが、MCP chrome-devtools を使えば、この辺りも楽になるのでは？と思い、EDAFのフローに組み込みました。

自動UI検証フロー

自動検出: フロントエンドファイル（.tsx/.vue/.jsx等）の変更を検知
ブラウザ自動化: MCP chrome-devtools でブラウザを制御
スクリーンショット: 実際の画面を自動撮影
コンソールチェック: JavaScriptエラーを自動検出
検証レポート: docs/reports/phase3-ui-verification-{feature}.md に自動生成

4. 実際の動作例（Before/After）

ケーススタディ: ユーザー認証機能の実装

従来の開発（Claude Code単体）:

あなた: 「ユーザー認証機能を実装して」
           ↓
Claude: コード生成
           ↓
あなた: 全コードを人間がレビュー
        - セキュリティは大丈夫？
        - パスワードハッシュ化してる？
        - SQLインジェクション対策は？
        - テストは十分？
           ↓
結果: 疲弊 & 見落としのリスク

EDAFを使った開発:

あなた: 「エージェントフローに沿って、ユーザー認証機能を実装して」
           ↓
【Design】
Designer: 設計書作成
7 Evaluators: 多角的レビュー
  - ✅ Goal Alignment: 8.5/10 - 要件を満たしている
  - ✅ Security: 9.0/10 - パスワードハッシュ化、トークン管理が適切
  - ⚠️  Extensibility: 6.5/10 - OAuth対応を考慮すべき
あなた: 「OAuth対応は後回しでOK」→ 次へ
           ↓
【Planning】
Planner: タスク分解
  1. User model + migration
  2. Authentication API (login/logout/register)
  3. JWT middleware
  4. Unit tests
7 Evaluators: 計画検証
  - ✅ All passed (7.0+)
あなた: 確認してOK → 次へ
           ↓
【Implementation】
4 Workers: コード生成
  - Database Worker: User model作成
  - Backend Worker: 認証API実装
  - Frontend Worker: ログインフォーム作成
  - Test Worker: テスト作成
           ↓
【Code Review】
7 Evaluators: 品質チェック
  - ✅ Quality: 8.0/10
  - ✅ Security: 8.5/10
  - ⚠️  Testing: 6.8/10 - エッジケースのテスト不足
           ↓
Workers: テスト追加
Evaluators: 再評価 → ✅ 7.2/10
あなた: スクリーンショット確認 → OK
           ↓
結果: 品質保証済み

向上した品質:

セキュリティチェック: 人間の見落とし → 7つの観点で自動チェック
テストカバレッジ: 不十分 → Evaluatorが指摘して改善
ドキュメント: 設計書・タスク計画が自動生成

5. 技術的詳細（エンジニア向け）

5-1. なぜClaude Code専用なのか？

EDAFは残念ながらClaude Code専用です。

理由は**Agentシステム（Task Tool）**があるからです。

Claude CodeにはTask Toolという、subagentを起動できる機能があります。
これのどこが良いかといいますと、

Task Tool で designer を起動
  → 独立したAIエージェントとして動作
  → 設計書を作成して返す
  → 同時に複数のEvaluatorも並列起動できる

つまり、独立したAIエージェントとして動作するため、メインClaude Codeのコンテキスト汚染が起きないのが大きいです。

（コンテキスト汚染が起きると俗にいう「AIが頓珍漢な回答をし始めた」とかが起きやすくなります）

6. おわりに

正直に言うと、EDAFはまだまだ発展途上です。

でも、実際にEDAFを入れてみて気づいたのは、
**「AIに全部任せる」んじゃなくて「AIと一緒に作る」**という新しい開発体験ができることでした。

私個人の開発だけで言えば、自分の中に無い視点や知識をAIが補完してくれるので、自分一人で開発するよりも圧倒的に品質が上がりました。

また、チーム開発においてもそれぞれのメンバーの特性に合わせて柔軟に対応できるだけでなく、
EDAFのフローに沿って進めることで、共通の品質基準を保ちながら開発が進められると感じています。

新しいメンバーが加わっていくなかでも Claude Code + EDAF でドメイン知識やチームの開発スタイルを継承しつつ、高品質な開発を続けられそうだと感じています。

今回の記事執筆とEDAF公開の背景

先程も言いましたが、EDAFは正直まだまだ粗削りです。

ドキュメント、もっと分かりやすく書きたい
ゼロからサービスを立ち上げる際にも活用できるようにしたい
インフラ構築フェーズにも対応したい

いろいろやりたいことは山ほどありますし、至らないところも多分にあります。

でも、「AIコード生成 × 品質保証」の新しいアプローチとして、何か参考になればと思って公開しました。

よかったら試してみてください

もしあなたも「AIが書いたコード、レビューめんどくさいな...」って思ってたら、ぜひEDAF試してみてください。

TL;DRに記載した手順を行って、「エージェントフローに沿って、○○機能を実装して」の一言で動きます。

フィードバック、めちゃくちゃ欲しいです。

「こういう機能欲しい」
「ここバグってる」
「こうした方がいいんじゃない？」

全部、GitHub Issues で待ってます！🐱

一緒に、もっと良い開発体験を作っていきましょう 🚀

リンク集:

この記事が役に立ったら、GitHub に ⭐️ お願いします！

（Starもらえると、めっちゃ嬉しいです！）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up