🔄

Agent TeamsのAIチームにPDCAを回させる仕組みを作った

に公開
個人開発
PDCA
生成 AI
Claude Code
Agent teams
tech

Claude Codeを個人開発で毎日使っている。前回の記事でAgent Teamsのチーム構成と起動プロンプトについて書いた。今回はその改善編で、「実装して終わり」にならずチームを育てるPDCAの仕組みについて書く。Agent Teamsを使い始めた人、使おうとしている人向け。

https://zenn.dev/ryuka_lucas/articles/62559da2c6a240

結論: 振り返りをタスクとして登録し、retro.mdに記録させる仕組みを入れたら、2回目から明確に改善された。

前提: Agent Teamsの開発フロー

Agent Teamsで開発するとき、自分はこういう流れで回している：

  1. /spec で仕様を書く（WHAT/WHY）
  2. /plan で実装計画とタスクを作る（HOW）
  3. Agent Teamsにspec・plan・tasksを渡して実装させる
  4. 完了したら人が最終確認

Agent Teamsには自然言語で「こういうチームを作って」と指示する起動プロンプトを渡す。自分が使っているテンプレートはこれ：

起動プロンプト（クリックで展開）
以下のspec・plan・tasksに基づいて開発チームを編成し、実装してください。

## チーム構成（4名のteammateを生成）

1. デザイナー（Sonnet） — 色、フォント、余白、視覚的バランスを担当。コード変更はしない。FEへの改善提案をメッセージで送る。
2. UI/UX（Sonnet） — 操作性、ユーザーフロー、フィードバック設計を担当。コード変更はしない。ユーザー視点の改善提案をFEへ送る。
3. FEエンジニア（Opus） — 唯一の実装担当。デザイナー・UI/UXの提案を受けてコードを書く。
4. QA（Sonnet） — テスト作成と動作確認を担当。テストコードのみ変更可。

## ワークフロー

### Phase 1: 実装サイクル
- spec, plan, tasks を全員で読む
- tasksに従ってFEが実装 → デザイナー・UI/UXがレビュー → QAがテスト → FEが修正
- 全タスク完了まで繰り返す
- 完了したら最終成果物をユーザーに報告

## ルール
- あなた（PM）はコードファイルを編集しないこと
- FE以外はコードファイルを直接編集しないこと
- QAはテストファイルのみ変更可

## 入力ドキュメント
- Spec: [specのパス]
- Plan: [planのパス]
- Tasks: [tasksのパス]

この起動プロンプトに「振り返り」を組み込みたかった。実装して終わりじゃなく、次の開発に学びを引き継ぐために。

1回目: 振り返りが実行されなかった

最初のAgent Teams実行では、起動プロンプトに「Phase 2: 振り返り」と書いてあったのに、PMが振り返りを実行しなかった。

何が起きたか：

  1. FEがタスクを「完了」にした
  2. PMが「全タスクcompleted」を見て「終わった」と判断
  3. 自分もそのまま「完了」と思ってチームを削除
  4. retro.mdが存在しないことに後から気づく

PMに「なぜできなかったか」を聞いたら正直に答えてくれた：

  • タスクの「完了」を鵜呑みにした。retro.mdが存在するか検証しなかった
  • 自分で書いたワークフローを自分で守らなかった
  • QAの遅延で焦って「早く片付けよう」モードに入ってしまった

プロンプトに書いてあっても、守られるとは限らない。

対策: 3つの仕組みを入れた

1. 振り返りをタスクとして独立させる

/plan スキルが生成するtasks.mdのテンプレートに、最終Phaseとして振り返りタスクを組み込んだ。

### Phase N+1: 振り返り
- [ ] Task N+1: 振り返りを実施し、retro.mdに記録（良かった点・問題点・次回の改善案）

これでタスクリストに未完了の振り返りタスクが残る。「全タスクcompleted」で終わりにするPMが見落とせなくなる。

プロンプトの指示（読んで忘れる）とタスク（完了するまで残る）の違い。

2. PM完了チェックリスト

起動プロンプトにシャットダウン前のチェックリストを追加した。

## PM完了チェック（シャットダウン前に必ず確認）
- [ ] 全タスクの成果物が実際に存在するか確認（ステータスだけ見ない）
- [ ] Phase 2: 振り返りを実行したか
- [ ] retro.mdが書かれたか

タスク化が本命で、こっちは保険。両方あって損はない。

3. 振り返りの観点を具体化

「振り返りを実施」だけだと「特に問題なし」で終わる可能性がある。何を書くかを明示した。

- 振り返りを実施し、retro.mdに記録
+ 振り返りを実施し、retro.mdに記録（良かった点・問題点・次回の改善案）

3つの観点があると「問題点は...特にないです」とは書きにくくなる。

改善後の起動プロンプト

3つの対策を反映した完成形がこれ：

改善後の起動プロンプト（クリックで展開）
以下のspec・plan・tasksに基づいて開発チームを編成し、実装してください。

## チーム構成（4名のteammateを生成）

1. デザイナー（Sonnet） — 色、フォント、余白、視覚的バランスを担当。コード変更はしない。FEへの改善提案をメッセージで送る。
2. UI/UX（Sonnet） — 操作性、ユーザーフロー、フィードバック設計を担当。コード変更はしない。ユーザー視点の改善提案をFEへ送る。
3. FEエンジニア（Opus） — 唯一の実装担当。デザイナー・UI/UXの提案を受けてコードを書く。技術的に実現不可能な提案は理由とともに代替案を返す。
4. QA（Sonnet） — テスト作成と動作確認を担当。エッジケースの洗い出し、バグ報告をFEへ送る。テストコードのみ変更可。

## ワークフロー

### Phase 1: 実装サイクル
- spec, plan, tasks を全員で読む
- tasksに従ってFEが実装 → デザイナー・UI/UXがレビュー → QAがテスト → FEが修正
- 全タスク完了まで繰り返す
- 完了したら最終成果物をユーザーに報告

### Phase 2: 振り返り
- PM（あなた）が各メンバーに聞く:「今回うまくいったこと、うまくいかなかったこと、次回の改善案」
- 結果をretro.mdに記録する

## ルール
- あなた（PM）はコードファイルを編集しないこと
- FE以外はコードファイルを直接編集しないこと
- QAはテストファイルのみ変更可
- 修正報告時はコードスニペットと行番号を含めること（「修正しました」だけでは不可）
- デザイナー・UI/UXの提案は2段階で行う: UIタスク実装前に「方針提案」、実装後に「レビュー」

## PM完了チェック（シャットダウン前に必ず確認）
- [ ] 全タスクの成果物が実際に存在するか確認（ステータスだけ見ない）
- [ ] Phase 2: 振り返りを実行したか
- [ ] retro.mdが書かれたか

## 入力ドキュメント
- Spec: [specのパス]
- Plan: [planのパス]
- Tasks: [tasksのパス]

2回目: 改善が確認できた

同じプロジェクトのpersistence（データ永続化）機能をAgent Teamsで実装した。

振り返りが実行された

PMの振り返りから：

前回の失敗を踏まえ、Task 7（振り返り）を独立タスクとしてPMにアサインし、確実に実行できた

タスク化が効いた。

retro.mdの中身が具体的だった

生成されたretro.mdは3セクション構成になっていた：

セクション 内容
プロジェクト固有の学び うまくいったこと・いかなかったこと
テンプレート改善の提案 /spec・/plan・Agent Teamsそれぞれへの具体的な改善案
PM自身の振り返り 自分の行動の反省と次回の改善案

実際の振り返りからいくつかピックアップ：

分類 内容
✅ うまくいった デザイナーがアイコン未インポートのバグ、UI/UXがspec違反を検出。PMが見落としていたものをチームで拾えた
❌ うまくいかなかった FEが先に実装完了 → 後からデザイナー提案が来てアイコン・文言の手戻り発生
❌ うまくいかなかった PMとFEのファイル状態同期ずれ。修正済みなのに「未修正」と指摘する事態が2回
💡 改善提案 修正報告時はコードスニペット+行番号を必須にする。「修正しました」だけでは検証できない

形骸的な「特に問題なし」ではなく、次に活かせる具体的な内容が出てきた。

改善提案をテンプレートに反映した

retro.mdの提案のうち、汎用的に使えるものを起動プロンプトのルールに追加した：

  • デザイナー提案の2段階化 — 実装前の「方針提案」と実装後の「レビュー」を分ける。UIタスクの手戻りを防ぐ

PDCAが回る仕組み

ここまでで、こういうサイクルができた：

ポイントは2つ：

  • retro.mdが機能単位で残る。同じ機能の次バージョンや似た機能を作るとき、過去の反省を参照できる
  • 起動プロンプトのテンプレートが育つ。汎用的な学びはテンプレートに反映されるから、全プロジェクトで改善が効く

1回やるだけじゃわからない。2回目で「前回の反省が活きた」と実感できて、初めてサイクルが回り始める。

コスト対策: Opus/Sonnetの使い分け

Agent Teamsはトークン消費が通常の約7倍。コスト対策として、役割でモデルを分けている。

役割 モデル 理由
PM, FEエンジニア Opus 判断力とコード品質が必要
デザイナー, UI/UX, QA Sonnet レビュー・提案のみ、コード変更なし

QAに確認したらSonnet 4.6で動作していた。コスト削減効果はまだ定量的に測れていないが、全員Opusよりは確実に安い。

まとめ

Agent Teamsは「チームを組んで終わり」じゃなく、振り返りの仕組みを入れてこそ価値が出る。

やったこと 効果
振り返りをタスク化 プロンプトに書いただけでは忘れる → タスクなら見落とさない
PM完了チェックリスト シャットダウン前の最終確認を保険として追加
retro.mdに観点を指定 「特に問題なし」で終わらない具体的な振り返り
改善提案をテンプレートに反映 次回のAgent Teamsが自動的に良くなる

1回目は失敗した。2回目で改善された。3回目はもっと良くなるはず。このサイクルが回り続ける限り、AIチームは勝手に育っていく。

Discussion