これなに
Fable が無料開放されていた6月から7月頭くらい、何をやってもらうか悩んでいるうちに7月中旬からは従量課金になるということでちょっと残念に思っていました。
そんな中、先日クレジット100ドルがProプランでも配布されたので、「じゃあー今後の個人開発とかお仕事用のために自分専用の開発チーム軍団でも作っておこうかなあ」と考えて、Fableに依頼してみました。
やったこと
Claude Code のサブエージェント機能を使って、7 つのロール（Product Manager / Project Manager / Solution Architect / Designer / Developer / Quality Assurance / EM Support）を定義し、プロジェクトを開始から完了まで自律的に回せる体制の構築を依頼しました。
自分は基本的には正社員でのお仕事をしつつ、たまに個人開発とか業務委託で、EM や PM、Developer、Scrum Master みたいなことをやることが多いので、どの現場でも使い回せるように、エージェント定義はプロジェクト非依存のテンプレートを作成しようと思ったという背景です。
なぜサブエージェントで「チーム」なのか
みなさんご存知かとは思いますが、Claude Code は単体でもかなり動いてくれるのですが、1セッションにすべてを任せるといろいろと面倒があります。
- コンテキストが膨れて精度が落ちる
- 「設計者」と「実装者」が同一だと、仕様の曖昧さを自分で都合よく解釈して進めてしまう
- 品質チェックを実装者自身がやっても形骸化する
などなど、あげたらキリがないかと思います。
人間のチーム開発で役割分担するのと同じ理由で、AI にも分業させたほうがアウトプットの質が上がる。（と、Anthropic Academy の資料にも書いてあった気がする）
ということで、それを実現するためにチームを作ってみたというわけです。
体制図
人間（EM / PM / 開発者）
│
├── 相談（プロジェクト外・独立）
│ └── em-support (Opus)
│
└── /run-project（メインセッション = オーケストレーター）
├── product-manager (Opus)
├── project-manager (Opus)
├── solution-architect (Opus)
├── designer (Opus)
├── developer (Sonnet)
└── quality-assurance (Sonnet)
モデルの使い分けとして、判断・設計系は Opus、実行系（Developer / QA）は Sonnet にしてコスト効率を取っています。
Anthropic が出している各モデルと特徴は以下の通りですが、モデル選定はこれまで ClaudeCode を使ってきた感覚値で決めました。選定に特に明確な理由はないです。
設計上のポイントとなるオーケストレーションをどうするか？
Claude Code のサブエージェントには「互いに直接対話できない」という制約があるようで、すなわち Project Manager が Developer を呼んだり Developer が QA に検証を依頼したりはできないようでした。
この前提をもとに、以下のような設計となりました。：
- Project Manager は「頭脳」。どのロールを、どの順で、何を入力に動かすかという計画を文書として出力する
- メインセッションは「手足」。PjM の計画に従って、各ロールを Task ツールで順次起動する
- 受け渡しはすべてファイルベース。各ロールはワークスペースに成果物を書き、次のロールはそれを読む
.claude/documents/projects/{yyyy-mm-dd}_{slug}/
├── 00_request.md # 人間の依頼（原文）
├── 10_product_brief.md # PdM
├── 20_project_plan.md # PjM
├── 30_architecture.md # SA
├── 40_design_brief.md # Designer
├── 50_implementation.md # Developer
├── 60_qa_report.md # QA
└── 90_completion.md # PjM（完了報告）
番号がパイプラインの順序を示しています。小規模な修正なら 00 → 20 → 50 → 60 → 90 に短縮できるようになっています。
なお、ファイルベースにした利点は3つ:
- コンテキスト分離: 各ロールは必要な文書だけ読むのでトークン効率が良い
- 再開容易性: セッションが切れても成果物ファイルが残っているので途中から再開できる
- 監査可能性: 人間がいつでも中間成果物を見てレビューできる
各ロールの設計方針
エージェント定義の共通フォーマット
全ロール、frontmatter（name / description / model / allowed-tools）に続けて以下のセクションを持つようにしました:
- Role: 一文での役割定義
- Responsibilities: 具体的な責務
- Inputs / Outputs: 何を読み、何を書くか
- Collaboration Protocol: 他ロールとの連携ルール
- Escalation: 人間に判断を仰ぐ基準
- Style: 言語・フォーマットの指定
Product Manager
プロダクトビジョンと戦略を持ち、人間の依頼を MoSCoW で優先度づけした Product Brief に変換する。重要なのは受け入れ基準を「QA が客観的に検証できる形」で書くこと。
Project Manager
- プロジェクトの計画・進行・完了判定を担う。前述の通りオーケストレーターの頭脳役で、dispatch plan（どのロールを・どの順で・何を入力に起動するか）を文書で出力する。
- 実際の起動はメインセッションがやる。
Solution Architect
- Product Brief と Project Plan をもとにアーキテクチャを設計する。
- ADR（Architecture Decision Record）で技術選定の根拠を残すのがポイント。
- 「既存アーキテクチャの進化を優先し、置き換えは最終手段」というルールも入れてあります。
Designer
- 実際のビジュアルデザインは
claude.ai/designで人間がやる前提で作成。 - このエージェントは、その前段となるデザイン基盤（レスポンシブ方針、タイポグラフィ、デザイントークン、グラウンドルール）を策定し、claude.ai/design に貼り付けるプロンプトを生成するためのもの。
Developer (Sonnet)
- 計画・アーキテクチャ・デザインに沿って実装する。コスト効率のため Sonnet を割り当てています。
- 重要な制約:
- 品質ゲート（format / lint / typecheck / test）を自分で実行し、結果を原文のまま報告するようにしています。（失敗を隠して完了報告することを明示的に禁止しています）
- git の書き込み操作（commit / push）は禁止。人間が実行するようにしています。（変なコミットを作って欲しくないので）
- アーキテクチャと現実が食い違った場合、勝手に別の設計で進めず、差異を報告に記録するようにしました。
Quality Assurance (Sonnet)
- 実装の独立検証。Developer の報告を信用せず、受け入れ基準を根拠（コマンド出力）付きで検証する役割を担います。
- コードは読み取り専用。どんなに軽微な修正でも自分では直さず、報告書に書いて Developer に差し戻すようにしました。
- 差し戻しは最大2回。超えたら人間にエスカレーション（無限ループ防止）としています。
EM Support
- プロジェクトパイプラインには参加しない、独立した EM の相談相手。
- 正社員や業務委託のお仕事で発生しうる組織計画、育成、フィードバック、評価の壁打ちに使うためのサブエージェント。
- パイプライン非参加を明示し、人事情報がプロジェクト文書に混入するのを防ぐようにしています。
人間ゲートとエスカレーション
自律実行を原則にしていますが、以下は必ず人間が判断するようにしました:
| タイミング | 内容 |
|---|---|
| ゲート 1（計画承認） | スコープ・見積・リスクの承認後に着手 |
| ゲート 2（完了承認） | 完了報告の確認。git commit/push は人間 |
| 随時 |
STATUS: NEEDS_HUMAN_INPUT で即停止 |
全ロール共通のエスカレーション基準:
- プロダクト戦略の判断
- 不可逆な操作（削除・課金・公開）
- 新規有償サービス・クレデンシャルの追加
- 見積り 150% 超過
- QA 差し戻し2回超過
- エージェント間の成果物矛盾
品質の仕組み
品質は「Developer が頑張る」ではなく、構造で担保するようにしています。
- Developer は品質ゲートを自ら実行し、結果をそのまま貼る（ごまかし禁止）
- QA は Developer の報告を読まず、独立して同じチェックを実行する
- QA は PASS / FAIL を根拠付きで出す。FAIL なら Developer に差し戻し
- 2回直しても通らなければ人間が介入する
実装者と検証者を分けることにより、セルフチェックだけの場合より抜け漏れが減ることを期待しています。
既存のガードレールとの関係
この体制は自分が作っていた既存のセキュリティ層の上に載る形に整備しています:
-
CLAUDE.mdで git 書き込み禁止・本番デプロイ禁止・secrets 不可侵を定義 -
guard.sh（PreToolUse hook）で危険コマンドをブロック -
settings.jsonの deny リストで禁止ツールを指定
エージェント定義側でこれらを緩めることはしないようにしています。
他リポジトリへの展開
エージェント定義はプロジェクト非依存に作ってあるので、展開手順は以下の通り:
-
.claude/agents/の 7 ロールと.claude/skills/run-project/をコピー - 展開先の
CLAUDE.mdにエージェント表とスキル表を追記 - 品質ゲートのコマンド（test / lint 等）を展開先
CLAUDE.mdに定義
プロジェクト固有の情報（技術スタック・コマンド・規約）はエージェント定義ではなく、展開先の CLAUDE.md や .claude/rules/ に書くようにしています。これによって、自分がよく使う Flutter や Laravel プロジェクトでも同じエージェント定義がそのまま使える形にしました。
考慮した点
- サブエージェントからの Task ネスト起動は環境差があるため、PjM 直接オーケストレーションは採りませんでした。将来ネストが安定したら移行可能な設計にはしてあります
- claude.ai/design との連携は API 連携なし、Designer が生成するプロンプトを人間が貼り付ける手動運用にしました（軽微だけれども、お金ないので便利とコストを天秤にかけて手動にしています）
- 人事情報の混入防止のため、em-support のパイプライン非参加を明示しています
所感
正直AIに関する進化というか新しい情報が多すぎて学習というか身につけるのが非常に難しいなと感じていました。
ドキュメントを読んで理解していっても、新しい情報が毎日のように出てくるので追いきれない。
なので、今回せっかくだから Fable を使ってハーネス設計の支援をしてもらったというわけでした。
まだ実プロジェクトでの運用は始まっていないので実際どう動いていくのかは検証できていませんし、正直これが正解なのかも、自分の認知しているAIやハーネスの考え方やらモデル選定やらは合っているのかも正直わかりません。まずは個人開発の中で回してみて調整していこうかなあと思っています。おわり。