最近、複数のAIエージェントを備えたシステムに関するYouTube動画などが見られるようになったので、網羅的ではないが、Claude CLIのsubagents機能の調査を手始めに、複数エージェントを備えたシステムについて調べた。
（注）本記事の内容は正確性を保証するものではない。
Claude CLIのsubagents機能について教えてください
GPT-5 の回答（抜粋）
以下は「Claude CLI（Claude Code）」のsubagents（サブエージェント）機能の要点と、最短で使い始める手順です。
何ができる？
- 特化エージェントを作成して、特定タスク（例：コードレビュー、テスト修復、デバッグ、データ分析）を自動で肩代わりさせられます。
- 各サブエージェントは独立したコンテキスト（別メモリ）で動き、使えるツールの権限も個別に制御可能。メイン会話を汚さず、役割ごとの精度を上げられます。 (Anthropic)
使い方（最短レシピ）
- 管理画面を開く
REPL中に/agentsを実行 → 「Create New Agent」を選択（プロジェクト限定 or ユーザー全体）。 Anthropic+1 - 役割・権限を設定
説明文（いつ使うか/何をするか）、ツール権限（空ならメインの全ツールを継承）、必要ならシステムプロンプト編集（e）。
MCPのツールも継承可能です。 Anthropic - 呼び出し
- 自動委譲：タスク説明とサブエージェントの
descriptionがマッチすると自動で任せる - 明示呼び出し：自然言語で「
Use the test-runner subagent to …」のように指定できます。 Anthropic
実戦向けベストプラクティス
- 役割は一点特化（「テスト実行と失敗修復」「ログ解析デバッガ」など）
- プロンプトは具体的に（手順・チェックリスト・制約を明記）
- 権限は最小限（必要なツールだけを
tools:で許可） - 共有したい設定はプロジェクト側にコミットしてチーム利用。 Anthropic
複数の特化エージェントを設定して、それぞれに専門処理を依頼するメリットは何ですか。それぞれの特化エージェントは独立したコンテキスト（別メモリ）を有し、他の特化エージェントのコンテキストが混ざらないので、役割ごとの精度が上がるということですか。
GPT-5 の回答（抜粋）
はい、その理解でだいたい合っています。複数の特化エージェント（サブエージェント）を分けて使う主なメリットは次のとおりです。
なぜ分けると有利なのか
- コンテキストの汚染防止 → 精度向上
各サブエージェントは独立した文脈（別メモリ）で動きます。レビュー用の「厳しめルール」や、デバッグ用の「深入り手順」など、役割ごとの前提・few-shot・チェックリストを混ぜずに保持できるので、迷走や役割衝突が起きにくいです。 - トークン効率・速度
1つの巨大な”何でも屋”に長大な履歴を読み込ませるより、役割ごとに必要最小限の前提だけを読み込むほうがトークン消費と応答時間を抑えられます。 - 権限の最小化（安全性）
サブエージェントごとに使えるツールを限定できるため、誤操作や過剰権限を避ける設計がしやすいです（例：テスト実行ボットだけがBashを使える等）。 - 再現性・評価のしやすさ
「このレビューは“code-reviewer”で回した」と明確になり、A/Bテスト、品質監査、ログの追跡が容易。振る舞いを固定しやすく、“前回と同じ結果” を狙いやすくなります。 - 責務分割と拡張性
役割を追加/差し替えできるため、チーム・ワークフローのモジュール化が可能。必要に応じて並列化もしやすいです。 - 情報の境界とプライバシー
プロジェクトや顧客ごとにエージェントを分ければ、機密や内部事情が不要に伝搬するリスクを下げられます。
ただし、分け過ぎのデメリットも
- 全体像の見失い：サブエージェント間で前提を共有しないと、重複作業や方針不一致が発生。
- 受け渡しの手間：エージェント間のハンドオフ（引き継ぎ）設計が必要。
→ 対策は「中央ブリーフ（共通前提）＋成果物の明確なI/O契約（スキーマ）＋最小限の共有アーティファクト」。
導入チェックリスト（迷ったらこれ）
- そのタスクは明確な評価基準（テストが通る/静的解析0件など）があるか？
- 専用の前提・few-shot・ガイドラインを常時持たせたいか？
- 必要ツールが限定できるか？（=安全性と再現性を上げられる）
- その役割の結果は機械可読な成果物（JSON/表/パッチ）にできるか？
→ 3つ以上YESなら、サブエージェント化の価値が高いです。
まとめ
- はい、独立コンテキスト化は役割ごとの精度を上げる主要因です。
- さらに、権限の最小化・トークン効率・再現性向上・安全性といった副次効果も大きいです。
- デメリット（分断）には、中央ブリーフ＋I/Oスキーマ＋明確な権限設計で対応しましょう。
複数のAIエージェントを用いる理由の概略は回答されたが、複数のAIエージェントによって処理が順次実行される場合ではなく、処理中にAIエージェント同士が情報交換を行う具体的な事例について質問した。
複数のエージェントを用いる場合であって、エージェントAの出力をエージェントBに渡し、エージェントBの出力をエージェントCに渡すというように、順次、処理を行うのであれば、3つのエージェントを最初から立ち上げておく必要はなく、いずれかのエージェントの処理中に、必要に応じて、他のエージェントと、何らかのやり取りを行うような課題の場合に有効であると思いますが、このような場合とは、どのような課題の場合ですか。具体的に教えてください。
GPT-5 の回答（抜粋）
いい着眼点です。「順次パイプライン」よりも“必要になった時だけ他エージェントを呼ぶ”ほうが効く課題は、ざっくり言うと結果次第で分岐が起こる・計測が必要・権限/コストを最小化したいタイプです。具体例を挙げます。
こういう課題で有効（具体例）
ファームウェアの不具合調査（Arduino/PlatformIO）
A: ログ解析 → エラー種別を特定。
（致命的I²C例外の時だけ）B: 配線/センサー判定ヘルパ を呼び、該当センサーのデータシート要件を抽出。
必要なら C: 修正パッチ提案（限定ファイルに対する diff）。
→ 軽微なら B/C を呼ばずに終了。重い分岐だけオンデマンド。
記事制作（Obsidian→WordPress）
A: 叩き台作成（要旨・見出し）
引用不足や用語ブレが見つかった時だけ B: 一貫性チェッカー（過去ノート検索→用語統一案）。
画像を多用する記事だけ C: 画像最適化ガイド（LCP/INP 観点での指針挿入）。
→ 全記事で B/C を走らせず、必要時のみ呼ぶから速く安定。
Cookie 同意 / 法令対応（EEA 向け）
A: サイト設定の静的解析（現状のタグ / Consent 実装の有無）。
実装不足の時だけ B: 実装案作成（テーマ / プラグインに応じたパッチ）。
変更後だけ C: E2E 確認（ヘッドレスで地域 / 同意フローをシミュレーション）。
→ 影響がない場合は B/C を呼ばない。
性能チューニング（ゲーム / PC）
A: 収集ログ解析（フレームタイム / ドライバ / 設定）。
GPU 依存が強いパターンの時だけ B: ドライバ整合チェック。
CPU ボトルネック時だけ C: 設定レコメンド（スレッド / FG / DirectStorage 切替案）。
→ 症状別のオンデマンド診断。
大規模リファクタ
A: 影響範囲推定（参照 / シンボルの依存グラフ）。
破壊的変更が含まれる時だけ B: 移行ガイド自動生成。
変更後だけ C: テスト増補＆自動修正
セキュリティ＆依存関係監査
- A: SAST/依存CVEスキャンの要約
- 重大度が閾値超えの時だけ B: 回避戦略作成（ピン留め/代替ライブラリ/一時パッチ）
- 公開前だけ C: ライセンス整合レビュー
→ リスクが低ければ追加コストゼロ。
データ基盤のガバナンス
- A: スキーマ変更検知
- 破壊的変更の時だけ B: ダウンストリーム影響評価
- 影響確定時のみ C: バックフィル計画＋コスト見積
→ 変更の性質により深掘りをオンデマンド化。
なぜ“必要時呼び出し”が効くのか（利点）
- 分岐対応：Aの結果でB/Cの要否が変わるタスクに強い
- コスト最適化：重い（検索/テスト/E2E）処理を条件付きでだけ使う
- 権限最小化：危険な権限（Bash/Edit/外部API）は必要時のエージェントだけに付与
- レイテンシ短縮：常駐3体より、1体＋オンデマンド2体の方が待ち時間が短いことが多い
- 監査性：いつ・なぜ・誰（どのエージェント）を呼んだかがログに残しやすい
迷ったらこの判断基準
- Aの結果によって後工程の要否が変わるか？
- 後工程が重い/高権限/高コストか？
- 後工程に別スキル（レビュー/法務/E2E）が必要か？
→ 2つ以上YESなら、“必要時に他エージェントとやり取り”する設計が有利です。
複数のAIエージェントにを備え、処理中にAIエージェント同士が情報交換を行う具体的な事例について質問したが、GPT-5は、当初、「結果次第で分岐が起こる」というタイプの事例しか回答しなかった。非同期で情報を交換し合うタイプの事例をもっと挙げて欲しかった。別記事「複数のAIを備えたシステムに関する調査（Perplexity Pto編）」では、同様の質問をPerplecity Proに行い、私が回答して欲しい内容に近い回答が得られている。
複数のエージェントに同じ課題を与え、それらの回答を、1つのAIに入力して、いずれかの回答を選ぶ、またはそれらの回答をまとめるというようなイステムが発表されています。どのようなものがあるか調査し説明してください。
GPT-5 の回答（抜粋）
了解しました。ご質問の「同じ課題を複数エージェントに解かせ、最後に“審判AI”が最良解を選ぶ／統合する」タイプの研究・実装は大きく次の系統に分かれます。代表例と要点を簡潔にまとめます。
代表的な方式と事例
1) Self-Consistency（自己一貫性）系：多解探索→多数決
1つのモデルから多様な思考経路（CoT）を複数サンプルし、最も整合する答えを選ぶ“ベスト・オブ・N”の原型。算数・常識推論ベンチで大幅改善を報告しています。arXiv
2) Multi-Agent Debate（討論）系：エージェント同士が議論→審判が選ぶ
複数エージェントが主張と反駁を交互に提示し、人間やLLM審判が勝者を決める枠組み。初期の理論は「AI Safety via Debate」からで、近年はMAD（Multi-Agent Debate）が汎用タスクで有効性を実証（ただし限界の指摘もあり）。arXiv+1ACL Anthology
3) LLM-as-a-Judge（LLM審判）系：審判をLLMが担当
複数回答をLLMが評価・採点・選択する方式。MT-Bench / Chatbot Arenaでは強力なLLM審判が人間嗜好と80％超の一致を示すなど、コスト効率の高い選好推定手段として定着。ただし位置・冗長性・自己増強バイアスなどの偏りがあり、順序の無作為化や匿名化が推奨されます。arXivNeurIPS
4) Tree-of-Thoughts（思考の木）系：分岐探索→自己評価で枝刈り/選択
思考を「木」として分岐させ、自己評価で有望な枝を残す探索枠組み。複数案からの選択・統合が中核で、難問で大きな性能向上を報告。arXiv+1GitHub
5) Mixture-of-Agents（MoA）系：層状に生成→上位層が改稿/統合
第1層で複数エージェントが独立生成→第2層がそれらを参照して改稿…を重ね、最後に統合する方法論。異種LLMの長所を合成できるのが売り。arXiv
6) Prompt Ensemble / Boosting 系：複数プロンプトの弱学習器を重み付き合成
異なるプロンプトで得た回答群を重み付きで選択・統合する“ブースティング”的手法。学習無し/少量監督で強化できるのが利点。arXiv
7) ルーティング／動的アンサンブル系：入力量に応じ最適経路を選ぶ
どのエージェントに回すか／どの回答を採るかを方策として学習し、計算資源を抑えつつ性能を最大化する試み。arXivResearchGate
8) フレームワーク（実装基盤）
AutoGen（Microsoft）は、複数エージェント＋グループチャット／マネージャのパターンを提供し、最終回答の選定や統合を自動化できます。研究/実務両面で広く使われています。Microsoft GitHub マイクロソフト
使い分けの目安（選ぶ？ まとめる？）
- 「正解が一意」：Self-Consistency／LLM審判の選択が効きやすい（算数、事実照合など）。arXiv
- 「複数観点の折衷が必要」：MoA／ToT／Prompt Ensembleで統合（要件定義、仕様策定、文案作成など）。arXiv arXiv
- 「誤り説明や説得が重要」：Debate＋人間/LLM審判（説明責任や安全性が重要な場面）。arXiv
- 「計算コスト制約」：動的ルーティング/DERで必要な時だけ他エージェントを呼ぶ。arXiv
注意点（落とし穴と対策）
- 審判バイアス：回答順や冗長さで審判LLMが影響を受ける → 順序の無作為化・匿名化・短縮版での再評価を。arXiv
- 討論の自己強化バイアス：MADが既存バイアスを強める可能性の指摘。多様性確保やメタ審判を併用。OpenReview
- 「議論＝常に真実」ではない：議論の勝敗と正しさは一致しないケースが報告。外部検証と根拠参照を義務化。arXiv
- レイテンシ/コスト：多重サンプリング・多エージェントは重い → 早期打ち切り、分岐実行、キャッシュを。arXiv
最小実装イメージ（審判型）
- 3つのエージェント（または同一モデルの異なるプロンプト/温度）で回答A/B/Cを生成
- 審判LLMに「評価基準（正確性/根拠/一貫性/簡潔さ）」を与えて匿名化・順序ランダム化したA/B/Cを提示
- 審判は
- select: 勝者1つ＋理由
- synthesize: A/B/Cの優点を統合要約（必要なら引用/根拠付き）
— この流れはAutoGenのGroupChat＋マネージャや、任意のCLI/スクリプト（Claude/Gemini）で容易に再現できます。Microsoft GitHub
「同じ課題を複数エージェントに解かせ、最後に“審判AI”が最良解を選ぶ／統合する」タイプについて質問することによって、このタイプに関する回答が得られたが、どの方法論・枠組みを適用するかの判断が容易ではなく、AIに相談しながら選択することになるだろうが、そこに人のノウハウ・知恵が入り込む余地はありそう。