「AIに開発を任せる」と言うとき、多くの人は1つのAIに全部やらせるイメージを持つ。 企画も実装もテストも同じ会話の中で進めて、最後に「できました」と言われる形だ。
これでやっていて気づいたのは、同じAIに実装と評価をさせると、評価が甘くなるということだった。 自分が書いたコードを自分でレビューするのだから当然で、人間のチームで 実装者とQAを分けるのと同じ理由が、AIにもそのまま当てはまる。
そこで、役割の異なる3つのサブエージェントを定義して、スプリント開発のパイプラインを組んだ。
全体像
[アイデア] → Planner → [仕様書] → Generator → [実装 + 自己評価]
↓
Evaluator
↓
合格 → 次のスプリントへ
不合格 → Generator に差し戻し
メインの会話は司令塔に徹する。自分では企画も実装も評価もせず、 各エージェントの成果物を次のエージェントに引き継ぎ、要所で人間（私）の承認を取る。
Planner：技術に踏み込ませない企画屋
Planner の仕事は、1〜4行の雑なアイデアを仕様書に膨らませることだ。
- プロジェクト概要（名前・ビジョン・ターゲット・課題）
- 機能一覧（10〜20機能、各機能にユーザーストーリーと受入基準）
- スプリント計画（6〜12スプリント、各スプリントに完了基準）
- 優先度マトリクス（Must / Should / Nice to Have）
ここで重要なルールが1つ。Planner には技術的な実装詳細を絶対に決めさせない。 DB設計、API設計、ライブラリ選定に踏み込ませると、実装フェーズの手を縛って かえって品質が落ちる。企画は「何を作るか」と「何ができたら完成か」だけを定義する。
Generator：1スプリントずつしか進めない実装者
Generator は仕様書を受け取ってコードを書く。ここでのルールは3つ。
- 1回に1スプリントだけ実装する。先走って複数スプリントを作らない
- 実装前に必ず既存コードを読む
- 完了時に自己評価レポートを出す。閾値を下回った項目は正直に申告する（盛らない）
「1スプリントずつ」の制約が特に効く。AIは放っておくと一気に全部作ろうとして、 後半になるほど雑になり、統合されていない半端な機能が量産される。 スコープを強制的に区切ることで、各機能が「動く状態」で積み上がっていく。
自己評価レポートには、テスト対象のURL、操作手順、既知の問題を必ず書かせる。 これが次の Evaluator への引き継ぎ資料になる。
Evaluator：実装者の自己申告を信用しない検査官
Evaluator は Playwright（ブラウザ自動操作）で実際にアプリを動かして評価する。 コードレビューだけの評価は、動かないバグを平気で見逃すからだ。
- Generator の自己評価スコアに引きずられず、独立に採点する
- バグは再現手順付きで報告する
- コードは書き換えない。 フィードバックだけ返す（修正は Generator の仕事）
- Critical バグが1件でもあれば無条件で不合格
不合格なら Generator に差し戻し。ただし修正は最大3回までで、 3回直しても合格しない場合は人間に判断を仰ぐ（スキップか、仕様変更か、中止か）。 この上限がないと、直しては壊しのループで無限にトークンが溶ける。
人間はどこにいるのか
このパイプラインで人間がやるのは承認だけだ。承認ポイントは4つに固定している。
- Planner の仕様書が完成したとき
- 各スプリントの実装が完了したとき（Evaluator に進めるか）
- Evaluator が合格を出したとき（次のスプリントへ進むか）
- 不合格が出たとき（修正するか、スキップするか）
逆に言うと、それ以外の場面では口を出さない。 実装の細部に人間が介入し始めると、AIに任せる意味が薄れていく。
実際に完走させてみた
このパイプラインで、ブラウザで動く5v5のMOBA風ゲームのプロトタイプを作った。 純粋な Canvas + JavaScript で、チャンピオン3体、AI操作の敵味方、ミニオン、 タワー、ショップ、スコアボードまで、6スプリントを完走している。
途中、Evaluator が2回差し戻しを出したスプリントもあった。 「タワーの攻撃範囲判定が仕様と違う」という、自己評価では「問題なし」と 申告されていたバグを、実際にブラウザを動かした Evaluator が拾った。 実装と評価を分離した効果がそのまま出た場面だった。
運用して分かった勘所
- 役割分離の本質は「利害の分離」。 実装者に評価をさせない、評価者に修正をさせない
- エージェント間の引き継ぎは成果物ベースで。 仕様書・自己評価レポート・差し戻し理由という「文書」を介すと、文脈の劣化が起きにくい
- 異常系を先に決めておく。 3回ルール、ブラウザが起動しないときのフォールバック、仕様の矛盾を見つけたときの挙動。決めていないとAIは勝手に解釈して進む
- 評価基準はエージェント定義に一元化する。 複数の場所に閾値を書くと必ずズレる
1人のAIを頑張って調教するより、凡庸な役割を複数組み合わせた方が成果が安定する。 これはAIに限らず、組織設計の古典がそのまま通用した、という話なのかもしれない。
