Claude Code Agent Teams、もう触りましたか？
複数のAIエージェントがチームを組んで、1つのタスクを分担して進めてくれる機能です。
すごい時代が来たなと思って早速使ってみたんですが、最初にぶつかった壁は、コードの書き方でもプロンプトの工夫でもなく、
このチーム、どう設計すればいいんだ？
ということでした。
エージェントは何人にする？
それぞれ何をやる？
チェック体制は？
この問い、どこかで見覚えが・・・
そう、人間のチームを作るときと同じ問いです。
この記事では、Agent Teams で「ブログを書く」というタスクに取り組んだ実験をもとに、プロマネスキルがAIエージェント活用にどう活きるかを書いていきます。
Agent Teamsに ブログを書いて と頼んでみた
とりあえず Agent Teams を試すために、簡単そうなタスクで、ブログを1本書いてもらいましょう。
エージェント1体に全部やらせればよいかもしれませんが、人間でも、1人で企画・執筆・校正・レビューを全部するよりも、チームで対応したほうが品質があがるはずです。
そこで、普段チームを設計するときと同じように、役割を分ける ことにしました。
一番悩んだのは役割の切り方
最終的に設計したのは、4つの役割で構成されたチームです。
| 役割 | 担当内容 |
|---|---|
| インタビュアー | 記者の役割。著者にヒアリングして、記事の方向性・素材を引き出す |
| 編集者 | 執筆者の役割。ヒアリング結果をもとに記事のドラフトを執筆する |
| 日本語ライター | 校閲者の役割。ドラフトを自然で読みやすい日本語にする |
| リスクチェック担当 | 責任者の役割。公開前にリスクや不適切な表現がないかレビューする |
この設計にたどり着くまで、いくつか迷ったポイントがありました。
なぜ「執筆」と「日本語のリライト」を分けたのか？
AIが書く文章って、情報としては正確でも、どうしても「AI臭さ」が残るんですよね。自然な文章にするには、執筆とは別の視点が要る。ライターと編集者が別にいるのと同じ発想です。
なぜ「リスクチェック」を独立させたのか？
ブログでも、表現次第で意図しない炎上を招くことがあります。
書いた本人（エージェント）は自分の文章の問題点に気づきにくいので、別の視点でチェックする役割を切り出しました。
実際のプロンプト: チーム設計をどう指示したか
Agent Teamsへの指示は、Claude CodeのCLI上で直接チーム構成を伝える形で行います。以下のようなプロンプトを入力しました。
私はプロジェクトマネジメントの経験があり、Claude Code Agent Teamsを使うときのチーム設計がプロマネの仕事と似ていることに気づきました。
以下のチーム構成で、Zennに投稿する技術ブログ記事を1本作ってほしい。
## チーム構成
### interviewer（インタビュアー）
技術ブログのインタビュアー。
著者（ユーザー）に対して、記事のテーマ・切り口・想定読者・
伝えたいメッセージについてヒアリングする。
質問は一度に3つまでに絞り、 **AskUserQuestion** ツールを使って、会話形式で深掘りすること。
ヒアリング結果は構造化してまとめること。
### editor（編集者）
多くの人に読まれる記事を書くことに使命を燃やす編集者。
インタビュアーがまとめたヒアリング結果をもとに、
Zennに投稿するMarkdown形式の記事ドラフトを執筆する。
読者がすぐに実践できるHow To形式を意識すること。
### japanese-rewriter（自然な日本語リライター）
日本語のリライト専門家。
ドラフト記事を読み、以下の観点でリライトする。
- AI生成っぽい不自然な表現を自然な日本語に修正
- 冗長な表現を簡潔にする
- 読者に語りかけるようなトーンに統一する
- 元の意味や情報を変えないこと
### risk-checker（リスクチェック担当）
公開前のリスクチェック担当。
記事を読み、以下の観点でレビューする。
- 特定の技術・コミュニティへの不用意な批判がないか
- 誇張や誤解を招く表現がないか
- ポジショントークになっていないか
問題があれば具体的な修正案とともに指摘すること。
ポイントは、各エージェントへの指示がジョブディスクリプションになっていること。「あなたは何者で」「何を期待されていて」「どう動けばいいか」を明確にする。人間のチームメンバーに役割を伝えるときと同じ要領です。
人間のチームマネジメントとやることは同じだった
この体験を通じて、改めて感じたことがあります。
AIエージェントのチーム設計に必要なのは、PMスキルそのものだと。
具体的に、どんなスキルが活きるのか整理してみます。
1. タスクを適切な粒度に分解する
大きなゴール（記事を1本書く）を、ちょうどいいサイズのタスクに分けます。
粗すぎると1つのエージェントに負荷が集中するし、細かすぎると連携コストがかさむ。
この「ちょうどいい粒度」の見極めは、WBSを書くときの感覚と同じです。
2. 役割と責任境界を決める
「誰が何を担当するか」を決める。大事なのは、役割間の境界を明確にすること。
人間のチームでも「これ誰がやるんだっけ？」が一番の混乱の元ですが、AIエージェントでも同じことが起きます。
3. アウトプットを AskUserQuestion で具体的に定義する
各エージェントに「何を出してほしいか」を明確に伝えます。
曖昧な指示からは曖昧なアウトプットしか出てきません。
これは人間相手でもAI相手でも変わりません。
Claude Code には AskUserQuestion ツールがあります。
このツールを使うと、Claude Code が人間に選択形式で質問してきます。
今回はインタビュアにアウトプットの要件が決まるまで繰り返し質問させ、PMである私から暗黙知を引き出してもらいました。
ちょうどメンバーがPMに質問するのと同じです。
4. レビューの流れを設計する
「誰がいつチェックするか」の流れを作ります。
今回は執筆作業ですので、シンプルに「執筆」「リライト」「リスクチェック」というシンプルなウォーターフォール的なフローにしました。
プロジェクトの進め方を設計するのと同じ判断です。
補足: マルチエージェントでは、いくつかオーケストレーションの方式がありますが、シーケンシャルオーケストレーションと呼ばれる形式に近いかもしれません。適切なオーケストレーションを選ぶことも重要な設計判断になります。
実践ガイド: あなたのAgent Teamsを設計する3ステップ
Agent Teamsを使うときに、すぐ試せるフレームワークを紹介します。
Step 1: ゴールから逆算してタスクを洗い出す
まず「最終的に何が欲しいか」を AskUserQuestion ツールで明確にしてもらいます。
そこから逆算して、必要なタスクを書き出します。
最終ゴール: Zennに技術ブログ記事を1本公開する
必要なタスク:
1. 記事の方向性を決める（テーマ、切り口、読者）
2. ドラフトを書く
3. 文章を自然な日本語にする
4. 炎上リスクをチェックする
5. 最終版を出力する
Step 2: タスクをグルーピングして「役割」を作る
関連するタスクをまとめて、1つの役割にします。
意識するのは、1つの役割 = 1つの専門性 にすることです。
役割設計のコツ:
- 1エージェント1責務（Single Responsibility）
- 役割同士の依存関係を最小にする
- チェックする側とされる側は必ず分ける
ソフトウェア設計の「単一責任の原則」がそのまま使えますね。
Step 3: 各役割にジョブディスクリプションを書く
最後に、各役割への指示を書きます。テンプレートとしてはこんな感じです。
[役割名]への指示:
- あなたは[何者]です
- [何を期待されているか]を担当してください
- 作業の進め方:
1. [最初にやること]
2. [次にやること]
3. [最後にやること]
- アウトプットの形式: [具体的な出力形式]
- 注意事項: [やってはいけないこと、気をつけること]
この構造は、人間のチームメンバーに期待値を伝えるときの「役割・責任・期待するアウトプット・制約」と同じです。
AI時代にPMスキルが武器になる
Agent Teamsのようなマルチエージェントの仕組みが広がっていくと、「コードが書ける人」だけでなく「チームを設計できる人」の重要性が増していくと感じています。
AIがコードを書いてくれる場面は増えていく一方で、「このタスクをどう分解して、誰に何を任せて、どういう順番で進めるか」を設計する力は、引き続き重要なスキルです。
そしてそれは、PMがこれまで磨いてきたスキルなんですよね。
もちろんコーディング力もアーキテクチャ設計力も大事で、それらがなくなるわけではありません。
ただ、そこに加えて、タスク分解、役割設計、アウトプット定義、レビューフロー設計、、、こうしたPMスキルを持っておくと、AIとの働き方の幅が広がるはずです。
AIを道具として使うだけでなく、AIチームを設計して動かすという選択肢が増えます。
そのためのスキルセットの1つがPMスキルだと思っています。
終わりに
ここまで読んでいただきありがとうございます。
実はこの記事自体が、Claude Code Agent Teams を使って作られています。インタビュアーがヒアリングし、編集者がドラフトを書き、リライターが日本語を整え、リスクチェック担当がレビューする。記事で解説した4人チームのプロセスを経て、この記事が生まれました。
もちろん、チーム設計やプロンプトの調整、最終的な確認と判断は人間がやっています。AIだけで完結したわけではなく、「人間がチームを設計し、AIが実行し、人間が最終判断する」という協業の結果です。
あなたが今読んだこの文章が、Agent Teams + PMスキルの実践例そのものです。
ここから、人間の私
ここから人間である私が書いています。
私の考えを深く理解しており、私が伝えたかったことを書き起こして頂きました。
私は、ヒアリングに回答して、最終的な成果物をちょっと修正するだけでした。
ドキュメントに対する心理的な障壁もさがりましたね。
Claude Code さん、ありがとう。
これからもよろしくお願いします。
補足: 実際のスクショ
補足すると、実際は、もっと簡単に指示しています。
最初の指示
進捗中
完成
ポイントは、ブログにあるとおりですが、AskUserQuestion ツールかと思います。
インタビュアにこのツールを使って、私の情熱、意思、制約などを詳細に聞いてもらい、後工程のインプットとなる 要件の品質を上げる という工程を挟むことで、簡単な指示で済みました。
このテクニックは、ウォーターフォール的な考え方でもあります。
ウォーターフォールはワークフローをAIで進めるために、とても相性がいいと感じています。
AIが各工程を高速に実行できるからだと思います。
この方法は、オーケストレーションアーキテクチャの切り口では、シーケンシャルオーケストレーションになりますかね。
他のパターンもありますので、プロジェクトやタスクの内容に合わせて適切に選択できるようになることがAIチーム設計、AIマネジメントの第1歩かもしれません。
本当の終わり: 結局、何をつくりたいかになる
Claude Code Agent Teams については、これから様々な取り組みが大量に共有されていくと思います。この記事もそうですが。
なんであれ「何を作りたいのか」は、人間が意思決定していくことに変わらないはずです。
それを言語化できる能力、そして AIをマネジメントする能力が、今後必須スキルになっていくでしょう。
では。