AIに「チームで考えさせる」という発想をClaude Codeでやってみた
こんにちは。
リテールアプリ共創部で事業企画を担当しているかめだです。
事業企画として日常的にClaude Codeを使って仕事をしています。マーケティング戦略を考えたり、競合調査をしたり、議事録から論点を整理したりと、日々大活躍しています。
ただ、一つ不満がありました。
Claude Codeに質問すると、1つの視点しか返ってこない。
事業企画の仕事は「多角的に考えること」です。顧客課題、競合動向、技術実現性、リスク。これらを同時に考えて、意思決定の材料を揃えたい。でも1つのセッションに全部やらせるとコンテキストが混ざって出力がぼやけてしまいます。かといって4回に分けて質問すると、前の回答に引きずられて独立した視点が得られないです。
AIに1つ質問して、返ってきた回答に物足りなさを感じたことはないでしょうか。「悪くはないけど、もう少し別の角度からも考えてほしかった」と思ったことはないですか？
この記事は、そんな不満を「AIチームの設計」という方法で解消しようとした、非エンジニアの試行錯誤の記録です。
1. AIに「チームで考えさせたい」
直近で、アパレル業界のアプリ機能を検討する必要がありました。アパレル業界の競合アプリを調べて、機能比較の星取表を作り、どの機能がMust Haveかを判断したいというものでした。
普通にClaude Codeに「アパレルアプリの機能を比較して」と聞くと、それなりの回答は返ってきます。ただ、ほしいのは「比較表」だけではありません。ユーザーレビューから見える本音、競合の網羅的な機能リスト、そしてそもそもこの検討自体に穴がないかの批判的検証。これらを独立した視点で、同時に考えてほしかったのです。
たとえるなら、会議室に同じ人を呼んで4回話すのと、4人の専門家を同時に呼んで並列に議論するのでは、出てくるものがまったく違いますよね。前者だと2回目以降は「さっき自分が言ったこと」に引きずられてしまう。後者なら、それぞれが独立した知見を持ち寄ってくれます。
私がほしいのは、後者の「専門家チーム」でした。
2. きっかけ
この記事の内容は衝撃的でした。tmuxで複数のClaude Codeを同時に動かし、将軍→家老→足軽という階層構造でエージェントを管理する。YAMLファイルでエージェント間通信を行い、tmuxの send-keys コマンドでイベント駆動させる。
技術的な詳細は半分くらいしか理解できませんでしたが、考え方に強く共感しました。
「AIを賢く使う」ではなく「AIチームを設計する」。
1つのAIに全部やらせるのではなく、役割を分けた複数のAIを並列に動かす。これは、エンジニアの開発タスクだけじゃなく、事業企画の思考プロセスにも使えるのではないかと考えました。
3. 固定Agentで5並列→そして失敗
最初にやったのは、5つの固定Agentを定義することでした。
- customer ：顧客課題の専門家
- market ：市場分析の専門家
- strategy ：戦略の専門家
- line ：LINE技術の専門家
- critic ：批判的検証者
各Agentのペルソナファイルを作り、ターミナルで ./bin/start-all.sh を叩くことで、5つのClaude Codeを同時に動かすことができました。tmuxセッション「agents」に5つのウィンドウが立ち上がり、全員が並列で考え始めました。
でも、結果は微妙でした。出力が「一般的な分析」になってしまったのです。customerが出してきたのは「会員登録の煩雑さ」「レジでの待ち時間」みたいな、アパレル業界の一般的なペインポイント。marketは「アパレル市場のトレンド」を語り始める。私が本当にほしかったのは「ユニクロ、ZOZOTOWN、GUなどの機能を横並びで比較した星取表」なのに、誰もそれを作ってくれません。
つまり、固定ペルソナだとテーマに合わない役割が生まれてしまったのです。「アパレルの星取表を作りたい」というテーマに対して、「顧客課題の専門家」という役割は広すぎました。
4. Plan.md中心のテーマ駆動型に改修
第1弾の失敗から学び、設計を根本的に変えました。
固定AgentをやめてPlan.md中心の設計にしました。Plan.mdというファイルに、テーマごとにAgent構成を自由に定義できるようにしました。Plan.mdから ### agent: 名前 という行を自動検出して、その数だけtmuxウィンドウを立ち上げてClaude Codeを起動しました。
アパレル星取表テーマではPlan.mdは、以下のような構成になりました。
## Agent定義と指示
### agent: competitor-apps
役割: アパレル大手10社のアプリ機能を網羅調査
問い: アパレル大手10社以上のアプリにはどんな機能があるか？
出力フォーマット: 機能×企業の星取表（○×△のマトリクス）
### agent: user-reviews
役割: App Store/Google Playのレビュー分析
問い: ユーザーが高く評価している機能と不満を持っている機能は何か？
出力フォーマット: 評価ランキングTOP5（テーブル形式）
### agent: must-have-analysis
役割: 星取表からMust/Should/Could/Wontを導出
問い: なくてはならない機能は何か？
出力フォーマット: MoSCoW分類表
### agent: critic
役割: 調査の前提に穴がないかを検証
問い: この調査の前提に穴はないか？
出力フォーマット: リスクマトリクス
ターミナルで ./bin/start-all.sh を叩くことで、4つのAgentを同時に動かすことができます。
テーマが変われば、Agent構成も自由に変えられます。次に「営業戦略の検討」をしたければ、Plan.mdを書き換えるだけです。固定ペルソナの縛りがなくなったことで、テーマに最適化したチームを毎回設計できるようになりました。
ちなみにPlan.mdにはAgent定義だけでなく、以下の要素も書きます。
- テーマ ：何を検討するか
- 判断基準 ：数値ルールで定義（例: 「10社中8社が実装していたらMust Have」）
- 失敗条件 ：この結論が出たらダメ（例: 「全部必要という結論」）
- Phase定義 ：Agentの依存関係と起動順序
- 出力フォーマット ：テーブルの列名レベルまで具体的に指定
つまりPlan.mdは単なるAgent一覧ではなく、「チームの設計書」です。この設計書の精度が、後述するように出力品質を大きく左右します。
5. 苦労したポイント
出力品質の問題
個人的に、これが最大の学びだったと思います。
最初のPlan.mdでは「出力期待値: 星取表」としか書いていませんでした。するとAgentが自由に解釈してバラバラな出力になるのです。あるAgentは箇条書きで、あるAgentは文章形式で、あるAgentはテーブルだけど列の定義が違う。
そこで、出力フォーマットを以下のように具体的に指定するようにしました。
出力フォーマット:
- テーブル形式
- 列 = 企業名10社
- 行 = 機能カテゴリ15項目
- セル = ○×△（△の場合は注釈を付ける）
- 集計行を設ける
これだけで品質が劇的に向上しました。リアルのチームでも「レポートを書いて」より「A4で2枚、表紙なし、結論を最初に、根拠をテーブルで」と言ったほうが良いアウトプットが出てくるのと同じですね。
出力フォーマットを具体的に指定することが、並列AIワークフローで最も重要だった。
Phase分けの必要性
今回設定した、must-have-analysisは、competitor-appsとuser-reviewsの出力を前提にしています。でも全Agent同時起動だと、must-have-analysisが参照すべきデータがまだ存在しません。そこでPlan.mdにPhase定義を書くようにしました。
## Phase定義
- **Phase 1**（並列）: `competitor-apps`, `user-reviews` → 調査系を先行
- **Phase 2**（Phase 1完了後）: `must-have-analysis` → 調査結果を使って分析
- **全Phase共通**: `critic` → 最初から最後まで検証
./bin/start-all.sh がこのPhase定義を読み取って、Phase 1のAgentを先に起動し、出力ファイルの生成を10秒ごとに確認して、全員の出力が揃ったらPhase 2のAgentを自動で起動してくれます。Phase定義がなければ従来通り全Agent一斉起動です。
依存関係のあるタスクは順番を設計する必要がある。これも、事業企画としてのプロジェクト設計に似ているなと感じました。
「判断基準」と「失敗条件」を入れるようにした
Plan.mdに数値ルールと失敗条件を明記するようにしました。「競合10社中8社以上が実装していたらMust Have」「全部必要という結論になったら失敗」「根拠なく"すべき"と書いていたら失敗」。
これでAgentの出力品質の下限が担保されるようになりました。「全部大事です」みたいな当たり障りのない結論が出てこなくなったのです。判断基準を数値で定義するだけで、AIの出力がここまで変わるというのは、正直驚きでした。
6. 結果
- CursorのPlanモードで「アパレルの星取表を作りたい」とテーマを伝える
- CursorがPlan.mdを自動生成（Agent構成、判断基準、失敗条件、Phase定義を含む）
- ターミナルで
./bin/start-all.sh→ Phase定義に従ってAgentが順次起動 - 15分待つ →
./bin/collect-output.shで完了確認 output/を読んで、自分の判断で結論を出す
Claude Code 1つで1時間かけるより、4つで15分並列のほうが、独立した視点からの材料が揃います。1つのセッションだと前の回答に引きずられますが、並列だと各Agentが完全に独立して考えるので、視点の多様性が担保されました。
ちなみに、Plan.mdを書く行為自体が思考の整理になるということに気づきました。「誰に何を考えさせるか」を設計する過程で、自分の中でテーマの構造化が進みます。
一方で、課題も残っています。Plan.mdの設計に時間がかかること。良い問いの分解は難しいのです。最初は30分くらいかかりました。ただ、慣れてくるとパターンが見えてきて、Cursorに「このテーマでPlan.md作って」と頼めば自動生成してくれるようになりました。
また、Claude Codeのweb検索能力には限界があります。競合アプリの機能調査は、Agentの知識ベースに依存する部分が大きく、最新情報や細かい仕様の正確性には限界がありました。
そして、もちろんのこと結論を出すことは人間がやる必要があります。4つのAgentの出力を読んで、最終的に「Must Have機能はこれだ」と判断するのは人間の仕事です。AIに材料を揃えさせて、判断は人間がする。そして、他の人を巻き込む。それこそが事業企画という仕事かなと思ってます。
7. おわりに
今回の体験で一番伝えたいのは、並列AIワークフローの品質はPlan.mdの品質で決まるということです。Agent構成、問いの設計、出力フォーマットの指定、判断基準の数値化、失敗条件の明示。これらをどれだけ具体的に書けるかが、全てでした。
逆に言えば、Plan.mdさえ良ければ、あとはスクリプトが勝手にやってくれます。
おしおさんの記事から得た最大の学びは、「AIを使う」から「AIチームを設計する」への発想転換でした。プロンプトエンジニアリングではなく、チームアーキテクチャの設計。これはエンジニアだけの話ではなく、PMM、PdM、事業企画など「複数の視点で物事を考える必要がある仕事」全てに当てはまるのではないでしょうか。
と、ここまで書いていたら、Claude Codeのアップデートで「Agent Teams」がVer4.0になって、同じようなことができるらしいです。
こちらも試してみよっと。
では、おつかめ！
