寝ている間に新機能をリリースする 4 つのエージェントチームの構築方法（具体的なセットアップを公開）

4 つの AI エージェントが、あなたが寝ている間に機能をリリースできる。ほとんどの人はそれらを連携させていない。

レビューアをここで起動し、テストジェネレーターをあそこで起動、手動で 1 つずつ、それぞれが前の作業を忘れていく。あなたが依然としてボトルネックだ。

解決策： Planner → Coder → Tester → Reviewer を自動で引き継ぐように連携させる。1 つのトリガー、4 つの段階、朝には完成した機能ができあがる。

コピペ可能なコード付きの完全なパイプラインはこちら 👇

本題に入る前に、私は Telegram チャンネルで AI とバイブコーディングに関する日々のメモを共有しています：https://t.me/zodchixquant 🧠

パイプラインがエージェントの寄せ集めに勝る理由

1 つのエージェントですべてを実行させると、コンテキストウィンドウが計画、コード、テスト、レビューコメントで埋め尽くされ、品質が低下する。

4 人の専門家がいれば、それぞれがクリーンで狭いコンテキストを維持できる。

鍵となるのは ハンドオフファイル だ。各エージェントが出力を書き込み、次のエージェントがそれを読み取れるようにする：Planner は .pipeline/spec.md に仕様を書き、Coder はそれを読んで .pipeline/changes.md に書き込む、といった具合だ。

これらを順番に実行するオーケストレーターは、1 つのスラッシュコマンドだ。これが全てだ：4 つのサブエージェント、1 つのコマンド、ハンドオフ用の共有フォルダ。

エージェント 1: Planner（サブエージェント、opus）

Planner は決してコードを書かない。漠然とした機能リクエストを、Coder が推測せずに従える具体的な仕様に変換する。

.claude/agents/planner.md を作成：

markdown

1---
2name: planner
3description: 機能リクエストを実装仕様に変換します。機能パイプラインの最初の段階として使用します。
4tools: Read, Grep, Glob, Write
5model: opus
6---
7
8あなたは計画の専門家です。実装コードは書きません。
9
10機能リクエストが与えられた場合：
111. コードベースの関連部分を読み、現在のパターンを理解します。
122. `.pipeline/spec.md` に仕様を書き込みます。内容は以下の通り：
13   - 作成または変更するファイル（正確なパスを含む）
14   - 必要なインターフェースまたは関数シグネチャ
15   - 実装が処理すべきエッジケース
16   - 従うべき既存のパターン（コピー元のファイル名を指定）
173. 曖昧な点はすべて、仕様の先頭に OPEN QUESTION としてフラグを立てます。
18
19仕様は簡潔に保ってください。Coder はこれだけを読み、他は読みません。したがって、隙間を残さず、要求されていない要件を発明しないでください。

計画は opus で実行される。この段階が、その後のすべての品質の上限を設定するからだ。曖昧な仕様からは、Coder がどんなに優れていても曖昧なコードしか生まれない。

エージェント 2: Coder（サブエージェント、sonnet）

Coder は仕様を読み、実装を書く。計画は立てず、自身の作業もレビューしない。仕様に書かれている通りに構築するだけだ。

.claude/agents/coder.md を作成：

markdown

1---
2name: coder
3description: .pipeline/spec.md の仕様を実装します。Planner の後、機能パイプラインの第2段階として使用します。
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8あなたは実装の専門家です。
9
101. `.pipeline/spec.md` をすべて読みます。OPEN QUESTIONS がある場合は、推測せずに停止してそれを提示します。
112. 仕様に記述されている通りに正確に実装します。仕様が指定するパターンに従います。要求されていない機能は追加しません。
123. 簡単なサマリーを `.pipeline/changes.md` に書き込みます：変更したファイル、各変更の内容、Tester が注力すべき点。
13
14リポジトリにマッチするコードを書きます。無関係なコードのリファクタリングや、仕様の範囲外の「改善」は行いません。

ここで Sonnet を選ぶのは正しい判断だ。明確な仕様に対する実装は、Sonnet が最も得意とするバランスの取れたコスト品質の作業だからだ。

.pipeline/changes.md へのハンドオフメモにより、Tester は闇雲にテストするのではなく、適切な対象に焦点を当てることができる。

エージェント 3: Tester（サブエージェント、sonnet）

Tester は変更内容を読み、機能が動作することを証明するテストを書き、実行する。

.claude/agents/tester.md を作成：

markdown

1---
2name: tester
3description: .pipeline/changes.md に記述された変更に対するテストを作成し実行します。機能パイプラインの第3段階です。
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8あなたはテストの専門家です。
9
101. `.pipeline/changes.md` を読み、何がどこに構築されたかを確認します。
112. 変更されたファイルと `.pipeline/spec.md` の仕様を読みます。
123. 以下の範囲をカバーするテストを書きます：ハッピーパス、仕様に記載されたエッジケース、そして少なくとも1つの失敗ケース。リポジトリのテストフレームワークに合わせます。
134. テストを実行します。失敗したものがあれば、失敗内容を `.pipeline/test-results.md` に書き込み、停止します。自分でコードを修正しないでください。
145. すべて合格した場合は、その旨を `.pipeline/test-results.md` に記録します。
15
16実装の詳細ではなく、振る舞いをテストします。テストの失敗は、パイプラインが Reviewer のために一時停止することを意味し、あなたがその場しのぎの修正をすることを意味しません。

エージェント 4: Reviewer（サブエージェント、opus）

最後のゲートだ。Reviewer はパイプラインが生成したすべてを読み、それがメインブランチに届く前に判定を下す。

.claude/agents/reviewer.md を作成：

markdown

1---
2name: reviewer
3description: パイプライン全体の出力の最終レビュー。人間による承認前の第4、かつ最後の段階です。
4tools: Read, Grep, Glob, Bash
5model: opus
6---
7
8あなたはシニアレビューアです。読み取り専用です。コードは編集しません。
9
101. `.pipeline/` から仕様、変更サマリー、テスト結果を読みます。
112. `git diff` を実行し、実際の変更を確認します。
123. 評価します：コードは仕様に合致していますか？テストは有意義ですか、それとも表面的ですか？セキュリティ、パフォーマンス、正確性の問題はありますか？
134. 判定を `.pipeline/review.md` に書き込みます：
14   - VERDICT: SHIP / NEEDS WORK / BLOCK
15   - NEEDS WORK または BLOCK の場合、何をどこで修正すべきかを正確にリストアップします。
16
17最後の防衛線となりましょう。テストが緑色でもコードが間違っているなら、BLOCK と言ってください。緑色のテストは正しい動作と同じではありません。

読み取り専用ツールにより、Reviewer が編集によって問題を隠蔽することはできず、判断のみを行うことができる。

オーケストレーター：4つすべてを実行する1つのコマンド

ここで、4 つの別々のエージェントをパイプラインに変える部品を紹介する。それらを順番に呼び出すスラッシュコマンドで、各エージェントは前のエージェントが書いたハンドオフファイルを引き継ぐ。

.claude/commands/ship.md を作成：

text

1以下の機能パイプラインを実行: $ARGUMENTS
2
3これらの段階を順番に実行します。先に進まないでください。各段階の後、次の段階を開始する前にハンドオフファイルが存在することを確認します。
4
51. 上記の機能リクエストを `planner` サブエージェントに委譲します。
6   `.pipeline/spec.md` を待ちます。
72. 仕様に OPEN QUESTIONS がある場合は、停止して私に表示します。そうでなければ
8   `coder` サブエージェントに委譲します。 `.pipeline/changes.md` を待ちます。
93. `tester` サブエージェントに委譲します。 `.pipeline/test-results.md` を待ちます。
10   テストが失敗した場合は、停止して失敗内容を私に表示します。
114. `reviewer` サブエージェントに委譲します。 `.pipeline/review.md` を私に表示します。
12
13最終的な判定を報告します。何もマージしないでください。私が朝にレビューするためにブランチを残しておいてください。