AIエージェントは、増やすほど賢くなる?~Anthropicが示す「マルチエージェントから単一エージェントへ」という設計思想の変化~

はじめに
AITCセンター長の深谷です。
皆さんは、AIエージェントを開発するとき、どのような構成を考えるでしょうか?
例えば、企業の業務をAIに任せるために、次のようなエージェントを作ることを考えたとします。
- ユーザーの質問を分析するエージェント
- 必要な情報を検索するエージェント
- 検索結果を分析するエージェント
- 回答の正しさを検証するエージェント
- それらを統括するエージェント
それぞれが専門的な役割を担当し、連携しながら仕事を進める。人間の組織で考えれば、とても自然な構成です。
実際、AIエージェントの開発では、こうした「マルチエージェント」という考え方が広く使われてきました。
しかし、最近の高性能なAIモデルを使う場合、本当にここまでエージェントを分ける必要があるのでしょうか?
2026年10月22日、Anthropicが非常に興味深い記事を公開しました。
この記事では、複数の企業でのAIエージェント導入事例を踏まえ、複数のエージェントに分割していた処理を、単一のエージェントに統合することで、回答品質、処理速度、コストが改善する場合があると報告しています。
この発表には単なる技術的な改善を超えた意味があると感じています。それは、企業がAIエージェントをどのように設計し、企業固有の知識をどのように蓄積・活用していくべきか、という問題です。
今回は、Anthropicの記事を紹介しながら、これからの企業AIの設計について考えてみたいと思います。
AIエージェントを増やせば、業務が高度化するとは限らない
例えば、ある企業で営業活動を支援するAIエージェントを開発するとします。
顧客から次のような質問があったとしましょう。
「A社に対して、過去の商談内容、現在の契約状況、類似顧客への提案実績を踏まえて、提案方針を整理してください」
この質問に答えるためには、過去の商談履歴、契約情報、類似顧客への提案資料、社内の商品情報など、複数の情報が必要です。
従来のマルチエージェント構成では、例えば次のように役割を分けます。
| エージェント | 役割 |
|---|---|
| 営業情報エージェント | 過去の商談履歴を検索 |
| 契約情報エージェント | 現在の契約状況を確認 |
| 提案支援エージェント | 類似顧客への提案実績を調査 |
| 分析エージェント | 各エージェントの結果を統合・分析 |
| 統括エージェント | 処理全体を管理し、回答を生成 |
一見すると合理的な構成ですが、ここには問題があります。
それぞれのエージェントは独立したコンテキスト、つまりAIが処理する情報や会話の文脈を持っています。
例えば、営業情報エージェントが「A社は価格よりも導入後のサポート体制を重視していた」と判断したとしても、その結論に至る経緯や細かな条件が、次のエージェントへ十分に引き継がれるとは限りません。
エージェント間で情報を要約して受け渡すたびに、重要な情報が抜け落ちる可能性があります。
さらに、エージェントを増やせば、AIモデルの呼び出しや処理が増え、コストや応答時間にも影響します。
Anthropicが紹介した企業事例では、従来のマルチエージェント構成を単一エージェントに変更した結果、実行時間がおよそ2倍高速になったケースも報告されています。
つまり、エージェントを細かく分割することが、必ずしも回答品質や処理効率の向上につながるわけではないのです。
AIモデルの進化によって、エージェントの設計思想が変わり始めた
なぜ今、このような議論が出てきたのでしょうか?
大きな理由は、AIモデルそのものの能力向上です。
これまでのAIモデルでは、複雑な業務を一度に処理することが難しい場合がありました。そのため、処理を細かなステップに分割し、各ステップを専門エージェントに担当させるアプローチが有効でした。
しかし、最近の高性能なAIモデルは、自ら計画を立て、必要なツールを選び、結果を確認しながら次の処理を判断できるようになってきました。
先ほどの営業支援の質問であれば、単一のエージェントが次のように処理できます。
- 質問を分析し、必要な情報を判断する
- 商談管理システムから過去の商談履歴を取得する
- 契約管理システムから現在の契約情報を取得する
- 社内ナレッジから類似提案の実績を検索する
- 取得した情報を比較し、不足があれば追加調査する
- 根拠を整理して提案方針を回答する
ポイントは、これらの処理を、同じAIモデルが同じコンテキストを共有しながら進められることです。
途中で新しい事実が見つかれば、最初に立てた計画を修正することもできます。Anthropicは、このような構成を「Single Agent Loop」、つまり単一のエージェントが判断とツール実行を繰り返す構成として説明しています。
ただし、単一エージェントにすれば、すべてをAI任せにしてよいというわけではありません。アクセス権限や承認が必要な操作、実行回数やコストの上限などは、システム側で確実に制御する必要があります。
”AIモデルが柔軟に判断する部分と、システム側で確実に制御する部分を分ける”、これが、単一エージェントを実用化するうえで重要になります。
単一エージェントに、すべての情報を詰め込むわけではない
ここまで読むと、次のような疑問が出てくるかもしれません。
「一つのエージェントで多くの業務を担当するなら、膨大な業務知識やツールの使い方を、すべてAIに教える必要があるのでは?」
確かに、あらゆる業務手順、社内規程、ツールの定義を最初からAIに渡してしまえば、コンテキストが肥大化します。
AIモデルのコンテキスト長が大きくなっているとはいえ、大量の情報を与えれば必ず正しい回答が得られるわけではありません。入力トークン数が増えれば、APIコストや処理時間にも影響します。
そこで重要になるのが、Anthropicが推奨する”Progressive Disclosure(段階的開示)”という考え方です。
これは、AIに最初からすべての情報を渡すのではなく、必要な情報だけを、必要になったタイミングで読み込ませる方法です。
例えば、企業内に100種類の業務手順があるとしても、AIがすべての手順を最初から詳しく知っている必要はありません。
まずは、どのような業務手順が存在するのかを簡潔に把握しておき、実際に必要になったときだけ詳細な手順を読み込みます。
Know Narratorの「業務ナレッジ」で、必要な情報だけをAIに提供する
そして、この考え方を企業固有の情報の活用という観点で実現するのが、まさにKnow Narratorの「業務ナレッジ」です。
Know Narratorでは、例えば「営業ナレッジ」「契約・法務ナレッジ」「製品・技術ナレッジ」「品質管理ナレッジ」といった形で、企業内の情報を業務単位で整理・管理できます。
AIエージェントは、最初からすべての業務文書を読み込む必要はありません。
ユーザーの質問や業務の目的に応じて、必要な業務ナレッジを利用し、その中から関連する情報を検索・取得すればよいのです。
さらに、Know Narrator AgentSourcingの「マルチ業務ナレッジエージェント」を活用すれば、複数の業務ナレッジを横断し、必要な情報を組み合わせた回答も可能です。
先ほどの営業提案の例であれば、過去の提案実績は営業ナレッジから、商品仕様は製品ナレッジから、契約条件は契約・法務ナレッジから取得する、といった活用が考えられます。
つまり、企業内の膨大な情報をAIのコンテキストに詰め込むのではなく、必要なときに必要な業務ナレッジへアクセスする構成です。
また、企業で利用するうえでは、誰がどの情報を利用してよいかというアクセス制御も欠かせません。
Know Narratorでは、業務ナレッジごとに利用可能なユーザーやグループを設定し、所有者やメンバーなどの権限を管理できます。こうした仕組みによって、企業の情報を業務単位で整理し、適切な権限のもとでAIに活用させることができます。
”このような最初からすべてをAIに渡さず、必要な情報だけを動的に取得する”という設計思想は、回答品質の向上だけでなく、コンテキストの肥大化やAPIコストを抑えるうえでも重要です。
Skills・Tools・業務ナレッジを分けて、企業のAI資産を育てる
今回のAnthropicでは、専門エージェントが担っていた役割を、再利用可能なSkillsやToolsとして整理するという考え方も書かれています。
企業AIを設計する際には、次の3つを分けて考えると分かりやすいと思います。
| 要素 | 役割 | 企業での具体例 |
|---|---|---|
| Skills | 業務の進め方や判断手順 | 提案書作成手順、契約レビュー手順、品質評価プロセス |
| Tools(MCP等) | 外部システムからの情報取得や操作 | CRMの商談検索、契約管理システムの照会、ERPのデータ取得 |
| 業務ナレッジ | 判断の根拠となる企業固有の情報 | 過去の提案書、社内規程、製品仕様書、トラブル対応履歴 |
例えば、AIに「このお客様への提案方針を考えてほしい」と依頼したとします。
まず、AIは営業提案の進め方を定義したSkillを読み込みます。
続いて、MCPなどのToolsを使って、CRMや契約管理システムから最新の顧客情報を取得します。
さらに、RAGを使って過去の提案資料や営業ノウハウといった業務ナレッジを検索し、提案方針を整理します。
ここで重要なのは、”Skillsは「どう仕事を進めるか」、Toolsは「何を取得・実行できるか」、業務ナレッジは「何を根拠に判断するか」”という役割の違いです。
このように分離しておけば、業務手順が変更された場合はSkillを更新し、新しい業務システムを導入した場合はToolを追加し、過去の成功事例が増えた場合は業務ナレッジを更新できます。
エージェント全体を作り直す必要はありません。
また、これらを特定のAIエージェントに依存しない形で管理できれば、異なるAIモデルやエージェントから再利用しやすくなります。
企業の業務ノウハウを、個別のエージェントの中に閉じ込めず、共通のAI資産として蓄積する。
私は、これが今後の企業AIにおいて重要な考え方になると思います。
では、マルチエージェントはもう不要なのか?
ここは誤解してはいけないところです。
Anthropicは、すべてのマルチエージェント構成を廃止すべきだと言っているわけではありません。
特に、次のようなケースでは、サブエージェントを分けるメリットがあります。
一つ目は、コンテキストが大きくなりすぎる場合です。
単一エージェントで扱う情報が増え、実際に回答品質が低下する場合には、処理を分割する意味があります。
二つ目は、独立した処理を並列実行したい場合です。
例えば、複数の市場や技術分野について、それぞれ独立した調査を並列に進め、最後に結果を統合するケースです。
三つ目は、ツールや指示の競合が発生する場合です。
異なる業務のルールが複雑に絡み合い、単一エージェントでは適切なツール選択や処理判断が難しい場合には、エージェントを分けた方がよいことがあります。
つまり、今後の設計では、「業務が違うからエージェントを分ける」という考え方だけでは不十分です。
コンテキストを分離する必要があるのか。並列処理によるメリットがあるのか。品質やコストの改善につながるのか。こうした観点から判断し、評価結果に基づいて構成を選ぶことが重要です。
企業が育てるべきものは、エージェントの数ではなく、企業固有の知識である
ここからは、私自身が特に重要だと考えている点です。
以前、AITCのコラムで、AIを活用する企業が、自社の業務知識をどのように育て続けていくべきかについて書きました。
その中でお伝えしたかったのは、AIを導入しただけでは、企業の知識が自動的に増えていくわけではないということです。
例えば、AIに営業提案を考えてもらったとき、必要な情報が不足していることが分かったとします。過去の提案が成功した理由が記録されていない。顧客が重視した条件が残っていない。社内で使われている判断基準が明文化されていない。こうした不足に気づいた現場の担当者が、情報を追加・整備していかなければ、いくら高性能なAIを導入しても、企業固有の知識は十分に蓄積されません。
そして、これはAIエージェントの設計でも同じことが言えます。
各部門が独立したエージェントを開発し、そのプロンプトの中に業務ノウハウや判断ルールを埋め込んでいくと、知識が個々のエージェントに閉じ込められてしまう可能性があります。
一方、業務手順をSkillsとして、システム連携機能をToolsとして、判断根拠を業務ナレッジとして整理しておけば、さまざまなAIエージェントから再利用できます。
そして、業務を進める中で不足している知識が見つかった場合は、現場の担当者が適切なSkillsや業務ナレッジに反映していく。
例えば、営業担当者が新しい提案の成功要因を業務ナレッジに追加すれば、同じ情報を参照できる他の担当者やAIエージェントも活用できるようになります。
また、設計部門で新しい判断基準が確立された場合は、それをSkillや業務ナレッジとして整備することで、次の設計レビューにも生かせます。
一人何百体ののAIエージェントを活用しようなど、AIエージェントを増やすことだけに注力するのではなく、AIが利用できる企業固有の知識や業務ノウハウを、企業自身が継続的に育てていく。
これが、企業AIを高度化するための重要な条件だと考えています。
Know Narratorが目指す企業AIの姿
私たち電通総研が開発・提供している「Know Narrator」では、企業固有の知識をAIが継続的に活用できる仕組みを重視しています。
Know Narrator Searchでは、企業内のさまざまな業務文書を業務ナレッジとして管理し、RAGによって必要な情報を検索できます。
また、Know Narrator AgentSourcingのマルチ業務ナレッジエージェントでは、複数の業務ナレッジを横断して情報を活用できます。
さらに、コネクターエージェントを通じて外部の業務システムと連携すれば、社内文書だけでなく、業務システムが保有する情報もAI活用の対象にできます。
ここで私たちが重視しているのは、特定のAIモデルやエージェントだけに、企業の知識を閉じ込めないことです。
例えば、企業が利用するAIモデルを変更した場合でも、企業固有の業務ナレッジを引き続き活用できる。複数の部門で異なるAIエージェントを利用していても、共通の業務ナレッジを参照できる。そして、現場で新しい業務知識が生まれたときには、担当者自身が情報を追加・更新し、AIが活用できる知識を増やしていける。
今後は、Skillsのような業務手順や判断ルールについても、同様に再利用・管理できる仕組みが重要になっていくと思います。
今回のAnthropicの発表は、こうした企業AIの方向性を考えるうえでも、非常に参考になる内容でした。
私たちも、RAG、AIエージェント、MCPなどの技術を組み合わせながら、お客様の業務に適したAI活用を考えていきたいと思います。
まとめ
これまで、AIエージェントの進化というと、複数のエージェントが役割を分担し、連携することで、より高度な業務を実現するという方向に注目が集まっていました。
しかし、AIモデルそのものの能力が向上する中で、その設計思想も変わり始めています。
今回Anthropicが示したのは、複数のエージェントに分けていた処理を、必要に応じて単一エージェントに統合し、SkillsやToolsを動的に活用することで、品質や効率を改善できるという考え方でした。
そして、私はこの変化を、企業がAIを育て続けるための仕組みを見直す機会だと捉えています。
これから重要になるのは、AIエージェントをいくつ作ったかではありません。
業務手順や判断ルールがSkillsとして整理されているか。業務システムの情報をToolsによって活用できるか。そして、企業固有の知識が業務ナレッジとして継続的に蓄積・更新されているか。
こうした仕組みがあれば、AIモデルが進化したときにも、その能力を企業の業務に取り込みやすくなります。
逆に、企業固有の知識や業務ノウハウが個別のエージェントに閉じ込められている状態では、エージェントを増やしても、企業全体のAI活用はなかなか高度化しないかもしれません。
「AIエージェントを増やす」から、「AIエージェントが活用できる企業の知識を増やす」へ。
今回のAnthropicの発表を通じて、私は、この方向性がこれからの企業AIにとって、ますます重要になると感じました。
筆者
AITC センター長
深谷 勇次
