下記の記事では、複数のAIエージェントを利用するシステムについて調査を行ったが、本記事では、概略ではあるが、GPT-5やClaudeなどのAIを組み合わせて使う場合についてGPT-5に意見を聞いた。
（注）本記事の内容は正確性を保証するものではない。
商品開発部の責任者として、商品開発の各ステップについて、複数のAIに作業を依頼できるとします。どのステップをどのAIに任せたいですか。 AIは、GPT-5、Gemini 2.5 Pro、Claude 3.5、Perplexity Proであるとします。
GPT-5 の回答
最高責任者目線で、プロダクト開発を12ステップに分解し、GPT-5 / Gemini 2.5 Pro / Claude 3.5 / Perplexity Proの“主担当（Lead）/副担当（Support）”を割り当てました。
要点は「得意分野に役割集中」「出力フォーマットを固定（JSON/表）」「審判LLMで最終チェック」です。
配置マップ（要約）
| ステップ | Lead | Support | 任せる理由（要点） |
|---|---|---|---|
| 0. 目標・制約の整理（PRDドラフト） | GPT-5 | Claude | 高度な推論と仕様の矛盾検出に強い。Claudeで表現の明確化。 OpenAI |
| 1. 外部調査（市場/競合/規制） | Perplexity Pro | GPT-5 | 常時ウェブ検索＋引用で一次情報を素早く集約。GPT-5で要点抽出と示唆整理。 Perplexity AI BytePlus |
| 2. 顧客インサイト要約（N=多） | GPT-5 | Claude | 大量テキストのクラスタリング/要因分解→構造化。Claudeで要約の読みやすさを担保。 OpenAI |
| 3. アイデア創出/発散 | Claude | GPT-5 | 多視点の発想と論点整理が得意。GPT-5で評価軸に沿ったスクリーニング。 Anthropic Anthropic |
| 4. コンセプト比較・選定 | GPT-5（審判） | Claude/Perplexity | 複数案を評価指標でスコアリング。必要に応じPerplexityで根拠補強。 OpenAI Perplexity AI |
| 5. 技術調査・実装可否 | Gemini 2.5 Pro | GPT-5 | CLI/VS Code連携でリポジトリ横断の調査/実験が速い。GPT-5で設計の妥当性チェック。 Google Developers Blog blog.google |
| 6. 試作（コード/スクリプト） | GPT-5 | Gemini | GPT-5は最新ベンチで強力なコーディング性能。Geminiは差分適用やローカル実験が得意。 OpenAI Google Developers Blog |
| 7. 品質保証（テスト生成/修復） | GPT-5 | Claude | 失敗テスト→最小修正→再実行のループを自動化。Claudeで仕様逸脱の文章チェック。 OpenAI |
| 8. セキュリティ/法令/同意対応 | Perplexity Pro | Claude | 規制・ガイドラインを出典付きで収集。Claudeでポリシー文案に整形。 Perplexity AI |
| 9. UXコピー/ヘルプ/ドキュメント | Claude | GPT-5 | 明晰な長文/ガイド記述が安定。GPT-5でトーン統一・多言語展開。 Anthropic |
| 10. ローンチ計画（GTM/価格/FAQ） | GPT-5 | Perplexity | 価格感/競合比較はPerplexityの最新情報→GPT-5で戦略化とFAQ自動生成。 Perplexity AI |
| 11. 運用分析→次期計画 | GPT-5 | Gemini/Perplexity | ログ解析・A/Bの因果推論。必要に応じてGeminiでローカル検証、Perplexityで外部ベンチ比較。 Google Developers Blog |
根拠要約：
GPT-5は推論/コーディング性能・“協働”設計が強化され、難題の分解とコード修正が得意。
Gemini 2.5 ProはCLI/VS Code連携やツール実行が強く、リポジトリ操作・差分適用に向く。
Claude 3.5は論点整理や読みやすい長文・仕様記述に強い。
Perplexity Proは最新のウェブ情報を引用付きで高速収集でき、一次情報の下支えに最適。
OpenAI Google Developers Blog Anthropic Anthropic Perplexity AI
すぐ使える運用ルール（最小セット）
- 出力I/Oを固定：各ステップの成果は
JSONテンプレで（例：{hypotheses:[], risks:[], next_actions:[]}）。→後工程AIが読みやすく、審判（Judge）もしやすい。 - “選ぶ or まとめる”の審判：重要な節目（4, 6, 10）はGPT-5をJudgeにし、候補文書（Claude/GPT/Geminiの3案）を匿名・順序ランダムで評価→選択か統合のいずれかを指示。
- 調査はPerplexity必須：外部要素を含むタスクではPerplexityで根拠URLを取得→他AIの生成に添付してハルシネーション抑止。 Perplexity AI
- コード変更は2段承認：生成→GeminiのネイティブDiffで可視化→GPT-5がテストを自動追加/更新。 Google Developers BlogOpenAI
例：プロンプト断片（抜粋）
- Perplexity（市場/規制）
> 「日本/EEAの○○規制の一次情報を最新日付順に3件、要点100字＋URLで。相反点は併記」 Perplexity AI - Gemini（技術検証）
> 「このリポジトリでfeature-xのPoCを最短実装。差分だけ提案→VS Codeで適用→npm test実行」 Google Developers Blog - Claude（ドキュメント）
> 「PRDの曖昧表現を列挙し、測定可能なKPI表へ正規化。語尾統一・不明確語の代替案付き」 Anthropic - GPT-5（Judge）
> 「評価基準（正確性40/実行可能性30/リスク明示20/簡潔性10）でA/B/Cを採点。勝者と統合案をJSONで」
補足
- 実運用ではAutoGen等のマネージャで「担当割り」と「審判」を組み、失敗時だけ再指名にするとコスト最適化できます。 マイクロソフト Microsoft GitHub Microsoft GitHub
主担当（Lead）/副担当（Support）を、どのような根拠で割り当てたかについて、さらに質問した。
配置マップ（要約）で、主担当（Lead）/副担当（Support）を割り当ててもらいました。任せる理由（要点）を確認すると、主担当（Lead）と副担当（Support）の補完関係などを考慮して割り当てられたと思いますが、どのような点を考慮しましたか。考慮した点を全て挙げてください。
GPT-5 の回答
了解です。前回の「Lead/Support」割り当てで私が系統立てて考慮した軸を、重複なく整理してすべて挙げます。
1) タスク特性（課題そのものの性質）
- 探索 vs 収束（発散アイデア出し／要件の確定・矛盾検出）
- 事実依存度（最新の外部情報・規制・相場が必要か）
- 実行可能性検証の要否（コード実行・差分適用・テスト運転）
- 出力形態（長文ドキュメント／要約表／JSONスキーマ／パッチdiff）
- 正解の一意性（答えを“選ぶ”のが良いか、“統合”が良いか）
- 説明責任（根拠URL・引用・評価理由の提示が必要か）
2) モデルの得意分野マッピング
- 高難度推論・分解・整合性チェック（仕様の矛盾発見、設計レビュー）
- 長文の可読性・構成力（PRD、ヘルプ、ガイド、FAQの分かりやすさ）
- 実務志向のコーディング（実装手順、テスト生成、最小修正の提案）
- ワークスペース連携（CLI/VS Code連携、差分適用・ローカル検証フロー）
- ウェブ調査の速さと引用（出典付き要点抽出、一次情報探索）
3) 補完関係（Lead/Supportの“噛み合わせ”）
- 発散×収束：発想（Lead）→評価と取捨選択（Support）
- 生成×検証：コード/文書の生成（Lead）→テスト・根拠検証（Support）
- 外部調査×要約：最新情報収集（Lead）→構造化・戦略化（Support）
- 可読性×正確性：読みやすく整える（Lead）→数理/仕様の厳密性（Support）
- スピード×品質：初稿を速く（Lead）→仕上げで品質担保（Support）
4) リスク低減と信頼性
- ハルシネーション抑止（引用必須の工程では、引用を得意とするモデルをLead）
- 一貫性維持（用語統一・スタイルガイド準拠を得意なモデルをSupportに配置）
- 安全権限（Bash/Editなど“危険ツール”は必要工程のみを担当）
- 審判LLMの相性（複数案から選ぶ/統合する際に偏りを抑えられるか）
5) オペレーション上の制約
- レイテンシ/コスト（重い工程はLead1体、軽い検収をSupportに回す）
- レート制限/可用性（ピーク時に詰まらない組み合わせ）
- 再現性（同じプロンプトで同等結果が出やすいモデルを審判・検収に）
- マルチリンガル（日英混在ドキュメントでの安定度）
- 入出力の機械可読性（JSON/diff/表を崩さない安定出力）
6) あなたの環境適合（現場ワークフロー）
- VS Code/CLI運用（差分適用・テスト実行と親和性）
- Obsidian連携（既存ノートの参照・要点抽出・テンプレ充填）
- WordPress公開フロー（FAQ/ヘルプ/変更履歴の生成→校正）
- 既存資産との整合（用語表・PRD・過去記事との一致）
7) ステップ間のハンドオフ設計
- I/Oスキーマ固定（各工程の出力をJSON/表/パッチで標準化）
- 審判ポイントの設定（コンセプト選定・大規模変更・価格/GTM等でJudgeを配置）
- 分岐ルール（重大リスク時のみ追加の監査工程を発火＝オンデマンド呼び出し）
8) 品質メトリクスとの結びつき
- 定量KPIの有無（テスト合格率、用語整合率、根拠付き率、可読性スコア）
- 評価ルーブリック（正確性・実行可能性・リスク明示・簡潔性の配点と合格基準）
- 継続学習の仕掛け（失敗ケースのテンプレ化、プロンプト強化用のフィードバック回路）
これらの軸をどう割り当てに反映したか（要約）
- 外部一次情報が肝の工程（市場/規制/価格）は「引用付き収集」をLeadに。
- 仕様やコードの厳密性が肝の工程は、推論/検証が強いモデルをLeadに、読みやすさ・整形はSupportに。
- 実装・検証を回す工程は、ワークスペース連携や差分適用が強いモデルをLeadにし、テスト生成/最小修正を補助へ。
- 節目の意思決定は、審判適性（安定評価・I/O扱い・再現性）が高いモデルをJudgeに据え、匿名・順序ランダム・基準付きで選択/統合。
それぞれのAIの強み・弱みは、世間の評判と食い違う部分もあり、最適な割り当てかどうかの評価は意見が別れるところだが、及第点は取れる割り当て（たたき台）として、ここから修正すればよいのではと思う。GPT-5以外のAIの回答との整合性を確認するのも有効かもしれない。
役割の割り当て根拠「1）〜 8）」は十分抽出できたのではないかと思う。