エージェントチームのプロンプトテンプレート

問題: エージェントチームが有効で、「私のプロジェクトを手伝うチームを立ち上げて」と頼むと混乱した結果になります。優秀なチームとトークンの無駄遣いの違いはプロンプトの形にあります。生産的なチームは具体的なロール、明確なファイル境界、定義された完了条件を持っています。悪いチームには3人のレビュアーが重複した作業をします。

すぐ使えるヒント: まず並列コードレビュープロンプト（以下のパターン#1）を試してください。最も幅広く使えるエージェントチームパターンで、どのコードベースでも動きます。3人のレビュアー、3つのレンズ、1つの統合されたレビュー。数分で出力が得られ、単一のレビュアーが見落とすものを捉えます。

これはエージェントチームの概要の付録です。最初のチームをまだセットアップしていない場合はそちらから始めてください。コントロールと設定については高度なコントロールに進んでください。以下の10のプロンプトは、能動的な調整を伴う並列実行が直列作業より優れるワークフローをカバーします。

コードチームパターン

1. 並列コードレビュー

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings. Use delegate mode so the
lead synthesizes a final review without doing its own analysis.

なぜ機能するか: 1人のレビュアーは一度に1種類の問題に向かいます。基準を独立したドメインに分割することで、セキュリティ、パフォーマンス、テストカバレッジがそれぞれ同時に完全なパスを受けられます。リーダーはすべてを1つのレビューにまとめ、単一のレビュアーが落とす問題を捉えます。3人のレビュアーチームは、単一パスレビューが落とす問題を一貫して発見します。単一セッションレビューの約2〜3倍のトークンコストを見込んでください。カバレッジのために価値があります。

デリゲートモードは重要です。これがなければ、リーダーは自分でレビューを実行し、チームメートの結果に不格好に混ぜ込もうとします。デリゲートモードをオンにすると、リーダーは調整と統合に完全に集中します。

2. 競合仮説によるデバッグ

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk
to each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

なぜ機能するか: ディベート構造がアンカリングバイアスを打ち負かします。逐次調査は最初のもっともらしい理論で行き詰まり、それを確認しようとします。互いの理論を積極的に反証しようとする複数の独立した調査官は、生き残った理論が真の根本原因に近いことを意味します。

このパターンは予期しない関連も発見します。チームメート#3がメモリリークを発見し、チームメート#1がタイムアウト動作を追っているとき、直接つなげることができます。中間のリーダーなし。この直接チャンネルがエージェントチームをサブエージェントパターンと区別するものです。

3. フルスタック機能実装

Create an agent team to implement the user notifications system.
Spawn four teammates:
- Backend: Create the notification service, database schema, and API endpoints
- Frontend: Build the notification bell component, dropdown, and read/unread states
- Tests: Write integration tests for the full notification flow
- Docs: Update the API documentation and add usage examples

Assign each teammate clear file boundaries. Backend owns src/api/notifications/
and src/db/migrations/. Frontend owns src/components/notifications/.
Tests own tests/notifications/. No file overlap.

なぜ機能するか: ファイルレベルの境界がマージ競合をなくします。各チームメートはどのディレクトリを所有するか知っており、共有タスクリストが全員を同じページに保ちます。バックエンドチームメートが API コントラクトを提供した瞬間、フロントエンドチームメートが受け取ります。両方が同じリストを見ています。

明示的な境界がなければ、2人のチームメートが同じファイルを編集してぶつかります。ディレクトリレベルの所有権は実装プロンプトで最も重要な詳細です。このパターンは、上流のコントラクトが並列エージェント起動プロンプトに流れ込むワークフローガイドのウェーブ実行モデルに直接対応します。

4. アーキテクチャ決定レコード

Create an agent team to evaluate database options for our new analytics feature.
Spawn three teammates, each advocating for a different approach:
- Teammate 1: Argue for PostgreSQL with materialized views
- Teammate 2: Argue for ClickHouse as a dedicated analytics store
- Teammate 3: Argue for keeping everything in the existing MongoDB

Have them challenge each other's arguments. Focus on: query performance
at 10M+ rows, operational complexity, migration effort, and cost.
The lead should synthesize a decision document with the strongest arguments
from each side.

なぜ機能するか: 審議が単一エージェントによる選択肢評価を打ち負かします。各チームメートは1つのポジションにコミットし、他のポジションの欠陥を探します。リーダーは挑戦を生き残った議論だけをまとめます。

これは、すべての選択肢に本物のトレードオフがあり、明確な勝者がない決断に特に有用です。単一セッションは早期に1つを選んで答えに合理化する傾向があります。対立構造がすべての代替案の真の評価を強制します。

5. ボトルネック分析

Create an agent team to identify performance bottlenecks in the application.
Spawn three teammates:
- One profiling API response times across all endpoints
- One analyzing database query performance and indexing
- One reviewing frontend bundle size and rendering performance

Have them share findings when they discover something that affects
another teammate's domain (e.g., slow API caused by missing DB index).

なぜ機能するか: クロスドメインコミュニケーションがエージェントチームをサブエージェントより優れたものにします。データベースアナリストが API チームメートの遅いエンドポイントを説明するインデックス不足を発見したとき、直接伝えます。サブエージェントにはそれができません。サブエージェントはメインセッションにのみ報告し、互いに話しません。

パフォーマンスハントは共有タスクリストからも恩恵を受けます。各チームメートが重大度評価付きで問題を記録するにつれ、リーダーはリアルタイムで全体像が形成されるのを見て、最悪の問題に向けて努力をリダイレクトします。

6. 在庫分類

Create an agent team to classify our product catalog. We have 500 items
that need categorization, tagging, and description updates.
Spawn 4 teammates, each handling a segment:
- Teammate 1: Items 1-125
- Teammate 2: Items 126-250
- Teammate 3: Items 251-375
- Teammate 4: Items 376-500

Use the classification schema in docs/taxonomy.md. Have teammates
flag edge cases for the lead to review.

なぜ機能するか: データ並列作業はチームメート数に比例してスケールします。各自が独立してスライスを処理し、曖昧なアイテムを人によるパスのためにフラグを立てます。125アイテムずつ処理する4人のチームメートは、500アイテムを処理する1つのセッションより約4倍速く完了します。

同じパターンはあらゆる一括操作に適合します。サポートチケットのタグ付け、ドキュメントページの分類、データベースレコードの正規化、CSV ファイルの処理。重要なのは、機能ではなくデータ境界で分割することです。

コード以外のチームパターン

エージェントチームはコードだけのものではありません。並列の視点と密接な調整から恩恵を受けるものはすべて対象です。以下のプロンプトはリサーチ、コンテンツ、キャンペーン戦略をカバーします。

7. キャンペーンリサーチスプリント

Create an agent team to research the launch strategy for [product].
Spawn three teammates:
- Competitor analyst: study competitor ad copy, positioning, and pricing
- Voice of customer researcher: mine reviews, Reddit threads, and forums
  for pain points and language customers actually use
- Positioning stress-tester: take findings from both teammates and
  pressure-test our current positioning against what they discover

Have them share findings and challenge each other. The lead synthesizes
a strategy document with positioning recommendations.

なぜ機能するか: 競合リサーチャーが市場のギャップを見つけます。ボイスオブカスタマーチームメートが実際のバイヤーがそのギャップを気にしているかどうかを確認します。ポジショニングストレステスターは両方の入力を取り、それを使ってメッセージを壊そうとします。3つのレンズ、1つの統合、各チームメートの出力が他に流れ込みます。

3つの独立したリサーチセッションと比較してください。3つの独立したレポートが得られ、手作業でクロスリファレンスする時間を費やします。エージェントチームはエージェント間メッセージングを通じて自動的にクロスリファレンスを行います。

8. 逆説的レビューによるランディングページビルド

Create an agent team to build the landing page for [offer].
Spawn three teammates:
- Copywriter: develop messaging, headlines, and body copy
- CRO specialist: design conversion structure, CTA placement, and flow
- Skeptical buyer: review everything as a resistant prospect, flag
  weak claims, missing proof, and friction points

Require plan approval before any implementation.

なぜ機能するか: 計画承認が悪い方向が無駄なサイクルを消費する前にそれを捉えます。逆説的レビュアーがビルダー中心のチームメートが見落とす穴を見つけます。実際のバイヤーは懐疑的です。チームもそうあるべきです。

計画承認がここで最も重要なのは、ランディングページのコピーは書き直しにコストがかかるからです。アウトラインの段階で弱い価値提案を捉えるのは数分かかります。完全なビルド後に捉えると数時間かかります。

9. 広告クリエイティブの探索

Spawn 4 teammates to explore different hook angles for [product].
Each teammate develops one direction with headline variations,
supporting copy, and a rationale for why the angle works.
Have them debate which direction is strongest.
Update findings doc with consensus and runner-up options.

なぜ機能するか: 単独で探索する1つのエージェントは最初のまともなアイデアに固執します。互いをアウトパフォームしようと積極的に取り組む4つのエージェントは実戦でテストされたクリエイティブを生み出します。ディベート構造により、勝つ角度は単一セッションの内部独話ではなく、本物の挑戦を生き残ります。

このパターンは単一セッションが探索しなかった角度を生み出します。チームメート#2がチームメート#1のアプローチに反論するとき、チームメート#1は諦める代わりに自分の角度をより強いものに磨くことが多い。競争圧力が品質の底上げをします。

10. コンテンツ制作パイプライン

Create a team for this week's content calendar.
Spawn three teammates:
- Researcher: identify search intent gaps and competitive opportunities
- Writer: draft content based on research findings
- Quality reviewer: run each piece through clarity, proof, and SEO checks

Chain tasks so the researcher finishes before the writer starts,
and the reviewer checks each piece before marking it complete.

なぜ機能するか: 並列リサーチと順次品質ゲート。リサーチャーとライターは異なるピースで重複でき、レビュアーは何かが公開される前に問題を捉えます。独立したレビュープロセスなしの組み込み QA。

タスクチェーンが重要な詳細です。これがなければ、3人のチームメートが同時にスタートし、ライターはリサーチなしに下書きします。共有タスクリストを通じた明示的なタスク依存関係が正しい実行順序を強制します。タスクをエージェント間でチェーンする方法については、非同期ワークフローを参照してください。

3週間のオンランプ

エージェントチームに初めて取り組む場合、シンプルから始めて積み上げていきましょう。5人のチームメートによる実装プロンプトに直接飛び込むのは混乱のもとです。この3週間の進行はチームが価値を追加するときとオーバーヘッドを追加するときの直感を養います。

第1週: リサーチとレビュー

レビューが必要な PR を選びます。エージェントチームを有効にして、次を実行します：

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

3人のレビュアー、3つのレンズ、1つのレビュー。チームメートがタスクリストを処理し、発見を交換し、結果を届けるのを見ます。低リスク、高学習。最悪の場合、手動で完成させる不完全なレビューが得られます。

第2週: ディベートによるデバッグ

バグレポートを取り上げて、競合仮説パターンを実行します：

Users report intermittent 500 errors on the checkout endpoint.
Spawn 3 teammates to investigate different hypotheses:
- One checking database connection pooling
- One investigating race conditions in the payment flow
- One analyzing server resource limits
Have them share findings and challenge each other's theories.

これによりエージェント間コミュニケーションが実際にどのように機能するかを学びます。チームメートが証拠を共有し、弱い理論に反論し、コンセンサスが形成される様子を見てください。共有タスクリストがほとんどの調整が可視化される場所です。

第3週: 実装

調整パターンが自然に感じられたら、明確なファイル境界での機能ビルドを試みます：

Create an agent team to build the webhook system.
Assign directory-level ownership to prevent conflicts.
Use delegate mode for the lead.

3週目までには、チームが費用対効果を発揮するときと、単一セッションまたはサブエージェントアプローチが良い選択であるときの感覚がつかめます。ほとんどのデベロッパーは、少なくともいくらかのクロスドメインコミュニケーションを伴う3つ以上の独立した作業ストリームが必要なタスクにチームが最も効果的だと感じます。

実際に機能すること

数十回のエージェントチームセッションの後、これらのパターンはすべてのワークフローで機能し続けています：

ロールについて具体的に: 「1人はセキュリティ、1人はパフォーマンス」は「レビュアー」より優れています。曖昧なロールは曖昧な作業を生みます。
ファイル境界を定義する: ディレクトリレベルの所有権がマージ競合をなくします。実装タスクでは交渉の余地がありません。
成功基準を含める: 「結果を報告する」または「決定ドキュメントを更新する」が各チームメートにゴールラインを与えます。
純粋な調整にはデリゲートモードを使用: リーダーが自分で作業をしないようにします。リーダーの仕事は統合であり、制作ではありません。
リスクの高い作業には計画承認を要求: 悪い方向がトークンを消費する前に捉えます。クリエイティブと実装タスクに重要です。
チームメートに議論させる: 摩擦が合意より優れています。ディベートパターンはコンセンサスを求めるものより一貫して優れています。
チームサイズを3〜5に保つ: チームメートが多いほど調整のオーバーヘッドとトークンコストが増加します。5人を超えると、通信量が並列処理の利益を食い潰します。
パターンをタスクに合わせる: データ並列作業（分類、処理）はデータ境界で分割。機能的作業（機能実装）はドメインで分割。評価的作業（アーキテクチャ決定、クリエイティブ）は視点で分割。
ファストモードでリーダーをスピードアップ: リーダーのファストモードをオンにして、チームメートが標準速度で実行する間、コスト削減しながらよりスピーディな調整を。

ベストプラクティス、トラブルシューティング、既知の制限については、エージェントチームベストプラクティスを参照してください。表示モード、トークンコスト管理、品質ゲートフックについては、高度なコントロールを参照してください。

これらのプロンプトは、エージェントチームが有効な Claude Code ユーザーならそのまま使えます。今週はコードレビュープロンプトから始めてください。オーバーヘッドは低く、上記のすべてのプロンプトは、すでに実行しているワークフローのテスト済みの出発点です。

エージェントチームのプロンプトテンプレート

On this page