AIエージェントは、1体に何でも任せる時代から、複数体を役割分担させて動かす時代に移りつつあります。
この記事の要点:
- 1体のAIエージェントに営業もCSも経理も抱えさせると、指示が曖昧になり出力品質が落ちる
- Anthropicの「Managed Agents」は、coordinator(司令塔)が専門エージェントに仕事を振り分ける仕組みを標準機能として提供する
- 効くパターンは「並列化」「専門化」「エスカレーション」の3つに整理でき、導入前に権限設計とログ設計の勘所を押さえておく必要がある
対象読者: 生成AIの導入・活用を検討している経営者・情報システム部門・DX推進担当者
読了後にできること: 自社の業務を「1体のAIで足りる仕事」と「複数体に分業させるべき仕事」に仕分けし、社内で導入判断の会話ができるようになります。
「うちのAIエージェントに、何でも聞ける便利な相棒として育てていきたいんです」
AI研修や導入コンサルティングの現場で、非常によく聞くご相談です。問い合わせ対応も、資料作成も、データ集計も、全部1つのチャットボットや1つのエージェントに任せられたら理想的だ、という発想は自然なことです。ところが実際に伴走支援をしていると、1体のエージェントに複数の業務を詰め込んだ結果、指示(システムプロンプト)がどんどん長く複雑になり、「あれもこれも気にしながら中途半端にこなす、器用貧乏なAI」になってしまうケースを何度も見てきました。
この壁にぶつかったとき、多くの企業がたどり着く問いが「1体を鍛え上げるのではなく、複数体に分業させたほうが早いのではないか」というものです。実はこれは個々の企業の工夫にとどまらず、AI開発企業自身が正面から取り組んでいるテーマでもあります。Anthropicが2026年4月に発表し、現在もベータ提供を続けている「Claude Managed Agents」の中核機能のひとつが、まさにこの「複数エージェントの分業」を標準機能として提供する仕組みです。
この記事では、Managed Agentsのマルチエージェント機能(coordinatorが専門エージェントに委任する仕組み)を題材に、「なぜ1人に丸投げする設計が限界を迎えるのか」「業務にとって何が変わるのか」「導入するときにどこでつまずきやすいのか」を、技術仕様の丸写しではなく、経営判断・業務設計の視点で整理します。API仕様そのものに関心がある方は本文中でAnthropicの公式ドキュメントへのリンクも案内しますので、あわせてご確認ください。
1体のAIに”何でも”任せる設計は、なぜ限界を迎えるのか
生成AIエージェントの導入がひと通り進んだ企業でよく起きるのが、「最初はシンプルな1体のエージェントだったのに、気づいたら指示書(システムプロンプト)が数百行に膨れ上がっていた」という状態です。問い合わせ対応用に作ったはずのエージェントに、いつの間にか資料作成、社内規定の参照、簡単なデータ集計まで詰め込んでしまう。担当者からすれば「せっかく作ったのだから、あれもこれも任せたい」という気持ちは自然なのですが、これが品質低下の典型的な入り口です。
顧問先の導入判断に同席していると、最初に聞かれるのは決まって「結局、エージェントは何体用意すればいいんですか」という質問です。この問いに対する実務的な答えは、「1体のエージェントに背負わせる役割の数を、意図的に絞ること」です。1体に責任範囲を詰め込みすぎると、次のような問題が起きやすくなります。
- 指示の衝突: 「丁寧に長く説明する」役割と「簡潔に要約する」役割が同じエージェントに同居し、出力の一貫性が崩れる
- 権限の肥大化: 本来は経理データにアクセスする必要がない業務のためにも、経理システムへのアクセス権を持たせてしまう
- デバッグ困難: 出力がおかしいときに、どの役割の指示が原因かを切り分けにくい
Anthropicも、複数のエージェントを協調させる設計における公式ドキュメントの中で、単一エージェントにあらゆる能力を積み込むのではなく、ドメインに特化したシステムプロンプトとツールを持つエージェントへ処理を振り分けることを、有効なパターンのひとつとして明示しています(Multi-agent sessions | Claude Platform Docs)。「1体に全部」から「役割ごとに複数体」への移行は、一部の先進企業だけの特殊な工夫ではなく、AIエージェントを本格的に業務へ組み込む際に多くの企業が通る道だと考えてよいでしょう。
Managed Agentsが示す答え:coordinator(司令塔)と専門エージェントの”チーム”設計
ではAnthropicは、この「分業」をどう仕組み化しているのでしょうか。Claude Managed Agentsは、自前でエージェントの実行基盤(ループ処理・サンドボックス・監視)を作らなくても、Claudeを長時間稼働する自律型エージェントとして動かせるマネージドサービスです。中核となる概念は次の4つに整理されています(Claude Managed Agents overview)。
| 概念 | 内容 |
|---|---|
| Agent(エージェント) | モデル・システムプロンプト・ツール・MCPサーバー・スキルの組み合わせ。役割ごとに定義する |
| Environment(実行環境) | Anthropicが管理するクラウドサンドボックス、または自社インフラ上のセルフホスト環境 |
| Session(セッション) | 特定の実行環境内で動く、実際に稼働するエージェントのインスタンス |
| Events(イベント) | アプリケーションとエージェントの間でやり取りされるメッセージ(ユーザー発話・ツール実行結果・状態更新) |
このAgentの仕組みの上に、複数エージェントを協調させる「マルチエージェントセッション」が用意されています。設定上は、あるエージェントを”coordinator(司令塔)”として定義し、その配下に委任できる専門エージェントの一覧(roster=名簿)を登録します。coordinatorは会話の流れの中で、必要に応じてrosterの中のエージェントに処理を委任し、結果を受け取って統合します(Multi-agent sessions | Claude Platform Docs)。
AIエージェントの導入戦略を体系的に整理したい方は、まずAIエージェント導入完全ガイドで全体像を押さえたうえで、本記事の「複数体をどう設計するか」という各論に進んでいただくと理解しやすいと思います。
ここで重要なのは、「coordinatorと専門エージェントの間で、何が共有され、何が分離されているか」です。公式ドキュメントによれば、すべてのエージェントは同じサンドボックス・ファイルシステム・vault認証情報(vault credentials)を共有しますが、各エージェントは自分専用の「セッションスレッド」という、会話履歴を持つ独立したイベントストリームの中で動きます。ツール・MCPサーバー・コンテキスト(会話履歴)は共有されません。
| 区分 | 共有される | 共有されない |
|---|---|---|
| 実行環境 | サンドボックス、ファイルシステム、vault認証情報 | ― |
| エージェント設定 | ― | モデル、システムプロンプト、ツール、MCPサーバー、スキル |
| 会話 | ― | 会話履歴(コンテキスト)。各エージェントは自分のセッションスレッドのみ保持 |
つまり「同じ作業場(サンドボックス)で働くが、それぞれ独立した頭(コンテキスト)を持つチーム」というイメージです。これにより、専門エージェントAが受け取った長い会話履歴が、専門エージェントBのコンテキストを圧迫することがなくなります。1体に何でも詰め込む設計で起きがちな「コンテキストの汚染」を、アーキテクチャのレベルで避ける仕組みだと理解すると腑に落ちやすいはずです。
効くパターンは3つだけ ― 並列化・専門化・エスカレーション
「分業させたほうがいい」と分かっても、何でもかんでも複数体に分ければよいわけではありません。Anthropicの公式ドキュメントは、マルチエージェント構成が有効に機能するパターンを3つに整理しています。自社の業務がこの3つのどれに当てはまるかを考えるだけで、導入すべきかどうかの判断はかなりクリアになります。
パターン1: 並列化(Parallelization) ― 独立した作業を同時に振り分ける
複数のソースを同時に調べる、複数のファイルを並行して分析するなど、互いに依存しない複数のサブタスクを同時に実行させ、最後にcoordinatorが結果を統合する使い方です。「1つずつ順番に処理していた作業」を並列化するだけで、体感的な完了時間の短縮が見込めます。
coordinator用のシステムプロンプトは、たとえば次のように「何を・誰に・どう振り分けるか」を明記する形で設計します。
あなたは調査業務のcoordinatorです。
ユーザーから調査依頼を受けたら、対象を独立したサブテーマに分解し、
roster内の調査エージェントへ並列で委任してください。
委任時のルール:
- 各サブタスクには「目的」「出力フォーマット」「参照すべき情報源」を明記すること
- サブタスク同士が互いの結果に依存しないように分解すること
- 全サブタスクの結果が揃ったら、重複や矛盾がないか確認したうえで統合すること
- 不足している情報があれば、作業を始める前に必ずユーザーに質問すること
パターン2: 専門化(Specialization) ― ドメインごとに担当を分ける
セキュリティ専任のエージェント、ドキュメント作成専任のエージェントのように、特定領域に特化したシステムプロンプトとツールを持つエージェントへ処理を振り分け、1体のエージェントにあらゆる能力を積み込むことを避ける使い方です。企業でよく相談されるのは「営業支援」「バックオフィス」「カスタマーサポート」のように、部門ごとに専門エージェントを分ける設計です。
あなたはセキュリティレビュー専任のエージェントです。
対象は、社内で作成されたコード・設定ファイル・外部連携設定に限定してください。
作業ルール:
- 機密情報(認証情報・個人情報・契約金額)を検出したら、内容を本文に引用せず種別のみ報告すること
- 修正提案は必ず理由とセットで提示すること
- 判断がつかない項目は「要人間確認」として明示し、断定しないこと
- 仮定した点は必ず"仮定"と明記すること
あなたはドキュメント作成専任のエージェントです。
対象は、社内向けの手順書・議事録要約・FAQドラフト作成に限定してください。
作業ルール:
- 事実と推測を明確に分けて記述すること
- 数字・固有名詞を記載する場合は、根拠(出典・入力元)を必ず添えること
- 専門用語には初出時に簡単な説明を添えること
- 用語や表記のゆらぎがあれば統一ルールを提示すること
パターン3: エスカレーション(Escalation) ― 難所だけ上位モデルに相談する
通常の処理は比較的軽量なモデルで回しつつ、判断が難しい一部のサブタスクだけ、より高性能なモデルのエージェントに相談する使い方です。すべての処理を高性能・高コストなモデルで賄う必要がなくなるため、コストと品質のバランスを取りやすくなります。
あなたは一次対応エージェントです。標準的な問い合わせは自分で完結させてください。
次の場合のみ、上位エージェント(エスカレーション先)に相談してください。
エスカレーション基準:
- 金額・契約条件など、誤答が実害につながる判断が必要なとき
- 複数の社内規定が矛盾しているように見えるとき
- 過去の類似ケースが見つからず、判断の前例がないとき
相談時は、状況の要約・自分なりの仮の結論・確認したい論点を明記して引き継ぐこと。
自社の業務をこの3パターンに当てはめて考えると、「1体で十分な業務」と「複数体に分けるべき業務」の仕分けがしやすくなります。判断に迷ったときのチェックリストとして、次のテンプレートも活用してください。
【複数エージェント導入 判断チェックリスト】
□ 1つの業務の中に、性質の異なる複数の役割(調査/実行/レビュー等)が混在していないか
□ ある役割に必要な情報量が増えすぎて、別の役割の精度を下げていないか
□ 権限(参照できるデータ・使えるツール)を役割ごとに分けたいと感じているか
□ 一部の判断だけ、より上位のモデル・人間に確認したいと感じているか
上記に2つ以上該当するなら、複数エージェントへの分業を検討する価値があります。
導入前に知っておきたい「5つの勘所」
ここまでの内容だけを見ると「複数体に分ければ万事解決」に思えるかもしれませんが、実際にAnthropicの公式仕様を読み込むと、業務設計に直結する制約がいくつかあります。ここを知らずに導入すると、後から運用ルールを作り直す羽目になります。
1. roster(名簿)は”生き物”ではなく”スナップショット”
coordinatorに登録した専門エージェントの一覧(roster)は、coordinatorを作成・更新した時点の設定でスナップショットされ、固定されます。あとから参照先のエージェント定義を更新しても、rosterの参照は自動的に最新版へ追従しません。新しいバージョンに委任させたい場合は、coordinator側を明示的に更新する必要があります(Multi-agent sessions | Claude Platform Docs)。「一度作ったら放っておいても最新版で動き続ける」という思い込みは禁物です。
2. 委任は1階層まで。深い入れ子構造は組めない
coordinatorが専門エージェントに委任できるのは1階層のみで、そこからさらに孫エージェントへ委任するような2階層目以降の委任は無視されます。組織図のような多段階の指揮系統をそのままAIエージェント構成に持ち込もうとすると仕様上できないため、設計はできるだけ平坦に保つ必要があります。
3. rosterの上限は20体、ただし同じエージェントの複数コピーは可能
1つのcoordinatorに登録できる一意のエージェントは最大20体までです。ただし、同じ専門エージェントを複数コピーして同時に呼び出すことは可能なので、「専門エージェントの種類」は20種類までですが、「同時に働かせる人数」自体はそこで頭打ちにはなりません。
4. 同時に動けるスレッドは最大25まで
セッション全体で同時に稼働できるスレッド(coordinator自身+委任先の各エージェント)は最大25です。大量のサブタスクを一斉に並列化しようとすると、この上限に触れる可能性があるため、バッチ処理量やアーカイブ(不要になったスレッドの解放)の運用設計が必要になります。
5. 権限は「エージェント単位」、認証情報は「セッション単位」
MCPサーバー(外部ツール連携)は各エージェントの定義ごとに個別に紐づく一方、vault認証情報はセッション単位で全スレッドに適用されます。つまり「このエージェントには経理システムへのアクセスを許可しない」という制御はエージェント定義側で絞り込む必要があり、認証情報を渡すだけでは権限を制限したことにはなりません。社内データにAIエージェントを安全に接続する設計については、Claude Managed Agentsセキュリティ解説で詳しく扱っています。
これらの制約は、一見すると技術的な細目に見えますが、実際には「どこまで権限を絞るか」「どう監査ログを残すか」という経営判断・ガバナンス設計に直結します。技術部門任せにせず、導入検討の初期段階で経営層・情シス・現場が一緒に確認しておくべきポイントです。
【要注意】よくある導入失敗パターンと回避策
失敗1: 専門化せず、結局1体に機能を積み増してしまう
❌ 「せっかくコーディネーターの仕組みがあるから」と言いながら、実際には専門エージェントを1体だけ作り、そこにあらゆる役割を詰め込んでしまう。
⭕ 役割ごとにエージェントを分け、システムプロンプトとツールをそれぞれ最小限に絞る。
なぜ重要か: 分業の仕組みだけ導入しても、実際の設計思想が「1体丸投げ」のままでは、コンテキスト分離のメリットを享受できません。
失敗2: rosterを更新し忘れ、古いバージョンのエージェントが動き続ける
❌ 専門エージェントの指示内容を改善したのに、coordinator側のroster参照は古いバージョンのまま放置してしまう。
⭕ 専門エージェントを更新したら、coordinator側の参照も明示的に更新する運用ルールを決めておく。
なぜ重要か: rosterはスナップショット固定という仕様を知らないと、「直したはずなのに直っていない」という混乱が起きます。
失敗3: 全エージェントに全ツール・全MCPサーバーへのアクセスを与えてしまう
❌ 権限管理が面倒だからと、すべての専門エージェントに同じMCPサーバー・同じツールセットを割り当てる。
⭕ エージェントごとに、その役割に本当に必要な範囲だけツール・MCPサーバーを絞り込む。
なぜ重要か: MCPサーバーはエージェント単位で権限が決まる仕様なので、絞り込みを怠ると「経理専任のつもりが顧客データにも触れる」といった過剰権限が生まれます。
失敗4: primary threadのログだけを見て「動いているから大丈夫」と判断する
❌ coordinatorが受け取る要約ログ(primary thread)だけを見て、現場の詳細な判断過程を確認せずに運用を続ける。
⭕ primary threadでは各エージェントの活動の開始・終了・権限確認などの要点しか分からないと理解したうえで、必要に応じて個別のセッションスレッドまで遡って確認する運用を組み込む。
なぜ重要か: 監査や説明責任が求められる業務では、「要約だけ見て済ませる」設計は情報不足によるガバナンスの穴になります。
コストの考え方 ― セッション課金という新しい単位
Managed Agentsは、通常のトークン課金(モデルごとの入出力トークン単価)に加えて、セッションが実際に稼働(runningステータス)している時間に対して課金される「セッション実行時間」という単位が追加されています。料金は1ミリ秒単位で計測され、ユーザーの返答待ちなど「idle(待機)」の時間は課金対象外です(Pricing | Claude Platform Docs)。
| 課金項目 | 内容 |
|---|---|
| トークン課金 | 使用モデルの標準レート(入力・出力トークンの単価)がそのまま適用される |
| セッション実行時間 | 1セッション時間あたり0.08米ドル。runningステータスの時間のみ課金対象 |
| Web検索(ツール利用時) | 1,000回検索あたり10米ドル(標準のトークン課金とは別枠) |
Anthropic公式の試算例では、Claude Opus 4.8を使い、入力5万トークン・出力1.5万トークンを消費する1時間のコーディングセッションの合計コストは0.705米ドルとされています(内訳: 入力トークン0.25ドル+出力トークン0.375ドル+セッション実行時間0.08ドル)。複数エージェントに分業させると、その分だけ同時に走るスレッド数(=セッション実行時間の合算)が増える点は、コスト試算をする際に見落としやすいポイントです。専門エージェントを増やす=品質は上がりやすくなるが、稼働時間ベースのコストも比例して増える、というトレードオフを踏まえて設計してください。料金の詳しいシミュレーションはClaude Managed Agents料金完全解説で複数ケースを試算しています。
公開事例に見る「チーム化」の効果
事例区分: 公開事例
以下はAnthropicが公式に発表している導入事例です。
Anthropicが2026年4月にClaude Managed Agentsを発表した際、先行して本番導入していた企業の一つとして楽天(Rakuten)の事例が紹介されています。楽天は、製品・営業・マーケティング・財務など複数部門にまたがる専門エージェントをそれぞれ1週間以内にデプロイし、SlackやTeamsと統合してスプレッドシートやスライド、簡易アプリの作成などに活用しているとされています(Claude Managed Agents: get to production 10x faster | Claude by Anthropic)。1体のエージェントにすべての部門業務を背負わせるのではなく、部門ごとに専門エージェントを分けてスピーディーに展開したという構図は、本記事で紹介した「専門化」パターンの実例といえます。
Notion、Asana、Sentry、Atlassianといった他の早期導入企業も、コーディングやドキュメント作成、バグ修正PRの自動作成など、それぞれの業務領域に特化した使い方を進めているとAnthropicは紹介しています。具体的な社内活用の広がり方は企業ごとに異なりますが、「1つの巨大なAIに全部任せる」のではなく「業務の切り口ごとにエージェントを分ける」という設計思想は共通しています。
Uravationも実践している「複数AIエージェントの分業」という考え方
この「1体丸投げから複数体の分業へ」という発想は、Uravation自身の社内運用でも実践している考え方です。記事制作、SEOの状態確認、公開後の検証といった一連の業務を、1つの万能AIにまとめて任せるのではなく、それぞれの役割に応じた複数のAIエージェントを役割分担させて動かし、最後に人間が要点を確認する、という運用を社内で組んでいます。
企業向けのAI研修・導入支援の現場でも、最初のご相談は「まず1体、便利なAIアシスタントを作りたい」というものがほとんどです。それ自体は間違いではなく、最初の一歩としては正しい選択です。ただし、業務が広がり、任せたいことが増えてきた段階で「じゃあ次に、この役割は専用のエージェントに分けましょう」と提案できるかどうかが、AI活用を”便利なおもちゃ”で終わらせるか、”業務基盤”に育てられるかの分かれ目になっている、というのが実務を通じた実感です。
よくある質問
Q. Claude Codeの「Agent Teams」機能と何が違うのですか?
A. どちらも複数のAIエージェントを協調させる仕組みですが、動く場所と管理主体が異なります。Claude CodeのAgent Teamsは、開発者のローカル環境(またはCI環境)でClaude Codeのセッションを複数束ねて動かす実験的機能で、2026年7月時点では設定を明示的に有効化する必要がある機能です(Orchestrate teams of Claude Code sessions | Claude Code Docs)。一方、本記事で扱ったManaged Agentsのマルチエージェント機能は、Anthropicが管理するサーバー上でエージェントを長時間・自律的に稼働させるためのホスト型サービスで、自社アプリケーションに組み込む前提の基盤です。「開発者の手元で使う道具」か「自社サービスの裏側に組み込む基盤」かという住み分けで理解すると混同しにくくなります。
Q. 自社のサーバー内で動かすことはできますか?
A. Managed Agentsは、Anthropicが管理するクラウドサンドボックスのほか、自社インフラ上に構築する「セルフホストサンドボックス」という実行環境の選択肢も用意されています(Claude Managed Agents overview)。コンプライアンスやデータ所在地の要件で外部クラウドにデータを出せない企業は、この選択肢の詳細を確認する価値があります。
Q. まずは何から着手すればよいですか?
A. いきなり複数体のエージェントを設計するのではなく、まず現状の1体構成の業務を棚卸しし、本記事の「複数エージェント導入 判断チェックリスト」に当てはめて、分業の必要性が高い業務から1つだけ専門エージェントを切り出してみることをおすすめします。小さく始めて、権限設計とログ確認の運用に慣れてから対象を広げるほうが、後戻りのコストが小さくなります。
まとめ:今日から始める3つのアクション
- 今日: 自社で今動いているAIエージェント(チャットボット・自動化ツール等)が、何種類の役割を1体に抱えさせているかを棚卸しする
- 今週中: 本記事の「並列化・専門化・エスカレーション」の3パターンに、自社の主要業務を当てはめてみる
- 今月中: 権限設計(誰にどのデータ・ツールへのアクセスを許すか)とログ設計(誰が何を確認できるようにするか)の運用ルールを、複数エージェント前提で作り直す
次回予告: 次回は、複数のAIエージェントを実際に社内システムへ安全に接続する際の権限設計・監査ログ設計について、さらに実務的な切り口で深掘りする予定です。
著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。
SoftBank IT連載7回執筆(NewsPicks最大1,125ピックス)。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
参考・出典
- Claude Managed Agents overview — Anthropic公式ドキュメント(参照日: 2026-07-08)
- Multi-agent sessions — Anthropic公式ドキュメント(参照日: 2026-07-08)
- Pricing | Claude Platform Docs — Anthropic公式ドキュメント(参照日: 2026-07-08)
- Claude Managed Agents: get to production 10x faster — Anthropic公式ブログ(参照日: 2026-07-08)
- Scaling Managed Agents: Decoupling the brain from the hands — Anthropic Engineering Blog(参照日: 2026-07-08)
あわせて読みたい:
- Claude Managed Agents料金完全解説 — セッション課金の実コストを4ケースで試算
- Claude Managed Agents活用事例10選 — 本番導入されているユースケースをコード例付きで紹介
AIエージェント実装、Uravationが設計から運用まで伴走
マルチエージェント・Agent Teams・MCP統合まで、貴社の業務プロセスに最適な AIエージェント設計を支援します。
- 100社以上の企業支援実績
- 初回30分無料・即日返信
- 導入後3ヶ月の伴走付き
お問い合わせフォームから24時間以内にUravation担当者がご返信します。



