はじめに
IBMのメディア「IBM Think」が2026年3月9日に報じた記事をもとに、複数のAIモデルが連携して動く「マルチエージェントAI」の仕組みと、実用上の可能性および未解決のセキュリティ課題について解説します。Perplexity Computerの登場を軸に、研究者や実務家の見解を交えながら整理します。
参考記事
- タイトル: When one AI model isn’t enough
- 著者: Sascha Brodsky
- 発行元: IBM Think
- 発行日: 2026年3月9日
- URL: https://www.ibm.com/think/news/when-one-ai-model-isnt-enough
要点
- 単一モデルの限界（速度とコンテキストウィンドウ）を克服するため、複数の専門AIエージェントが並列で作業するマルチエージェントシステムへの関心が高まっている
- Perplexity Computerは複雑なタスクを分割し、クラウド上の専門エージェントに振り分けて同時実行する仕組みを採用した
- 複数エージェント構成にはデバッグのしやすさや処理速度の向上というメリットがある一方、製品説明が実態を上回る可能性も指摘されている
- マルチエージェントシステムには「破壊的な権限付与」「プロンプトインジェクション」など、まだ十分に解決されていないセキュリティリスクが存在する
- 導入を検討する組織には、測定可能な価値に紐づけて段階的に進めることと、既存業務の知識を失わないことが重要とされている
詳細解説
マルチエージェントAIとは何か
AIをめぐる議論は長らく「いかに1つのモデルを大きく、賢く、速くするか」が中心でした。しかし近年、別の方向性が注目を集めています。1つの優秀なモデルに頼るのではなく、それぞれ得意な処理を持つ複数のAIモデルが連携して動くアーキテクチャ、いわゆる「マルチエージェントAI」という考え方です。
IBM Thinkの記事では、その代表例としてPerplexity Computerが紹介されています。このシステムは複雑なタスクを細かく分解し、各部分を専門の「AIエージェント」（自律的に判断・行動するソフトウェア）へと割り振ります。エージェントたちは通常クラウド上で同時並行に処理を進め、完了後に結果を報告する仕組みです。
こうした構成が注目される背景には、単一モデルが抱える2つの根本的な限界があります。1つは速度です。1つのモデルが長い複雑なタスクを処理する場合、手術室でひとりの外科医がすべての役割をこなすように、作業は必然的に逐次的になります。もう1つはメモリ（コンテキストウィンドウ）の制約です。コンテキストウィンドウとは、AIモデルが一度に保持できる情報量の上限のことで、この限界を超えると、モデルは以前の指示を忘れたり、エラーが積み重なったりしはじめます。
ニューヨーク大学のEugene Vinitsky助教授はIBM Thinkの取材に対し、「タスクを並列化できるよう適切に調整すれば、Nエージェントは単一エージェントのN倍の速さでタスクを完了できる。入力が長くなるにつれてエージェントの性能は低下するため、専門的な役割を持つサブエージェントに処理を委ねることが効果的だ」と述べています。
モジュール化という設計思想
ストーニーブルック大学のNiranjan Balasubramanian准教授は、マルチエージェント構成には計算効率やモジュール性のほかに、診断上の利点もあると指摘しています。単一モデルが長いタスクの途中でミスを犯した場合、その原因を見つけることは難しくなります。一方、役割が分散された構成では問題の範囲が絞り込まれ、デバッグが容易になるといいます。「エージェント間で役割を分担することで、障害の分析と対処が効率的になる。マルチエージェントシステムへの移行は、即時の計算・モジュール化のメリットにとどまらず、AIをサービスとして構築していくという方向性そのものだ」と述べています。
この設計思想は、ソフトウェア工学において数十年にわたって重視されてきた「モジュール性」の原則と重なります。複雑なシステムは、それぞれ1つのことをうまく行う小さな独立したパーツから構築するほうがうまく機能する、という考え方です。複雑なワークフローを構築するうえで、専門的なAIモデルが連携する構成はこの要求を自然に反映していると言えます。
なぜ「今」注目されたのか
IBMのAIオープンイノベーション担当チーフアーキテクトであるGabe Goodhartは、エージェントシステムが広く注目されるようになったきっかけとして、技術的なブレイクスルーではなく、forループ（処理を繰り返す基本的なプログラム命令）とcronジョブ（決まった時刻に自動実行されるスケジュール命令）の組み合わせを挙げています。これによりAIシステムに「自己改善的な側面」と「ペルソナ（個性）」が生まれ、長時間動作するエージェントとは異なる形で人々の想像力を刺激したといいます。
IBMのAaron Baughman特別エンジニアは、マルチエージェントシステムの基盤には、最適なエージェント選択のための深層学習フレームワークや、複数エージェントを調整するマネージャーエージェントの理論など、長年にわたる学術的な研究の蓄積があると説明しています。一方で、その研究基盤があっても製品が過度な約束をすることは避けられないとも述べており、「完全自律的なプロジェクト管理」を謳うPerplexityの表現についても、現実との乖離に注意が必要と示唆しています。
解決されていないセキュリティリスク
マルチエージェントシステムの能力が高まるにつれ、新たなセキュリティリスクも生じています。Goodhartは3種類の脅威を挙げています。
1つ目は、エージェントがユーザーのコンピューターやファイルに無制限でアクセスするリスクです。クラウド型のアーキテクチャはエージェントをデバイスから切り離すことでこの問題に対処しています。
2つ目は、破壊的な権限の付与です。メールの削除やファイルの消去といった操作をエージェントに許可した場合、クラウド上でサンドボックス（隔離された実行環境）内で動作していても、誤った判断によってそれらの操作が実行されるリスクは残ります。「サンドボックス化されていても、削除権限があれば実行できる。その部分は軽減されていない」とGoodhartは述べています。
3つ目は、おそらく最も見落とされがちなリスクであるプロンプトインジェクションです。これは、エージェントが読み込むコンテンツの中に悪意のある指示を隠し込むことで、エージェントの動作を乗っ取る攻撃手法です。Goodhartは、AIエージェントが再利用可能なツールを集めたリポジトリ「skill.sh」のような審査済みのライブラリを用いることで、一定のリスク低減が可能だと述べています。ただし、ウェブ上でのプロンプトインジェクションは依然として未解決の課題です。「エージェントがウェブをスクレイピングする場合、どのウェブページがメタデータにプロンプトインジェクションを仕込んでいても、それを防ぐ手段はまったくない。現時点でこの問題に取り組んでいるシステムはないと思う」とGoodhartは指摘しています。
なお、「オープン対クローズド」という対立構造ではなく、「信頼の連鎖を構築できるか」が本質的な問いだとGoodhartは強調しています。オープンなエコシステムでもクローズドなエコシステムでも、信頼の連鎖を適切に設計することが重要と言えます。
組織が導入を検討する際の視点
現在注目を集めているPerplexity Computerと、オープンソースのエージェントフレームワークOpenClawは、アーキテクチャ上の選択として対照的な位置にあります。Perplexity Computerはクラウド上で承認済みの統合のみを使用する制限された環境で動作するのに対し、OpenClawはユーザーの自分のマシンと広いスキル・ツールのエコシステムへのアクセスを提供します。制御の範囲とリスクのトレードオフが異なります。
研究者たちは、組織が焦って導入することが失敗の大きな要因の一つだと指摘しています。Vinitsky氏は「測定可能な価値に紐づけ、代替指標ではなくその価値を直接測定しながら、素早く反復することが重要だ」と述べています。またBalasubramanian氏は、テクノロジー自体よりも重要なリスクとして、既存プロセスの組織知識を失うことを挙げています。「盲目的に既存業務を覆すのではなく、その知識を土台として構築することが最も重要だ」という指摘は、AI導入を検討する組織にとって参考になると思います。
経済面についてはBaughman氏が補足しており、AIの推論コストが下がる一方、エージェント間を行き来するメッセージ量が増えることでネットワークコストが上昇し、経済的な構造が変化することにも注目する必要があると述べています。さらにGoodhartは、AIのメモリやユーザーコンテキストがプラットフォームをまたいで移植できるよう、相互運用性（インターオペラビリティ）に向けた動きが進んでいると述べており、特定のプラットフォームへのロックインが将来的に緩和される可能性があります。
まとめ
マルチエージェントAIは、単一モデルの速度・メモリの限界を克服するための有力なアプローチです。一方で、過大な製品説明やプロンプトインジェクションをはじめとするセキュリティ課題はまだ十分に解決されていません。導入を検討する際は、測定可能な価値への紐づけと既存知識の保全を意識することが重要と思います。
