Open Deep Wide Research: 大規模情報収集のための汎用エージェント連携アーキテクチャ
2025年10月26日Ollie @puppyone
概要
新しいAI研究のパラダイムとして、各ユーザーセッションに専用のクラウド仮想マシンを割り当て、その中で複数の汎用エージェントを並列実行させてサブタスクを処理する手法が登場しています。これにより、広範な情報収集タスク（例：数百のエンティティにまたがる横断的調査）の自動化が実現します。このアーキテクチャは、チューリング完全な実行環境と、役割を固定しないマルチエージェント協調メカニズムに依存しており、高い柔軟性を備えています。しかし、レイテンシ制御、リソーススケジューリング、コスト予測可能性の面では、依然として技術的な課題が残されています。
問題の背景
従来の検索拡張生成（RAG）システムは、通常「ユーザー入力 → 検索 → 生成」という線形的なフローを採用しています。この設計は単一の質問応答には有効ですが、多数の異種ソースからの情報収集、複数回の検証、あるいは構造化された比較を必要とするタスク（例：「世界のトップ50大学のコンピュータサイエンス学科における博士課程卒業生の進路分析」）に直面すると、その能力は著しく制限されます。主なボトルネックは以下の通りです。
- 検索フェーズに、能動的な探索やタスク分解の能力が欠けている
- 生成フェーズで、動的な計画やバックトラックができない
- フロー全体が中断不能・拡張不能で、長時間の実行タスクをサポートしにくい
これらの制約を乗り越えるため、新世代のシステムでは大規模なリサーチタスクを分散エージェント連携問題としてモデル化しています。
アプローチの概要
中心的な設計思想は、各ユーザーセッションに専用のクラウド仮想マシン（VM）を割り当てることです。このVMは、完全なオペレーティングシステム、ネットワークアクセス権、実行環境を提供し、チューリング完全なサンドボックスを構成します。この基盤の上で、システムは複数のサブエージェントを動的に起動します。各サブエージェントは、特定の役割（例：「研究者」や「検証者」）をあらかじめ設定されたものではなく、機能的に完全な汎用インスタンスであり、以下の能力を備えています。
- 独立してHTTPリクエストを送信したり、外部APIを呼び出したりする
- スクリプトを実行してウェブページ、PDF、表などの非構造化データを解析する
- 内蔵のツールチェーン（ヘッドレスブラウザ、ドキュメント抽出ツールなど）を呼び出す
- 他のサブエージェントと中間結果を交換する
タスクの分解は、メインコントローラーによって動的に生成されます。例えば、「生成AIツールエコシステムの調査」というタスクに対して、システムは自動的に次のように分解する可能性があります。
- 複数のプラットフォーム（GitHub、Product Hunt、公式サイトのまとめページ）からツールのリストを取得する
- 各ツールについて、ドキュメント、バージョン履歴、ユーザーレビューを並行して収集する
- 主要な指標（オープンソースの状態、APIサポート、価格モデルなど）を抽出する
- エンティティを整理し、構造化された比較表を出力する
すべてのサブエージェントが同じ実行環境を共有し、汎用的な能力を持つため、タスクのロジックが事前に定義された役割に縛られることがなく、汎化性が大幅に向上します。
主要な技術詳細
1. 実行ユニットとしての仮想マシン
- 各セッションは、軽量なLinux VM（FirecrackerのようなマイクロVM技術に基づく可能性が高い）を専有する
- 一般的なランタイム（Python、Node.js）、解析ライブラリ（BeautifulSoup、PyPDF2）、ブラウザ自動化ツールがプリインストールされている
- ネットワーク出口はプロキシプールを通じてローテーションされ、クローリング対策のリスクを低減する
- すべての操作は隔離された環境で完了し、セキュリティとデータ境界を保証する
2. マルチエージェントの通信とスケジューリング
- サブエージェントは、共有メモリや軽量なメッセージミドルウェア（Redis Pub/Subなど）を介してデータを交換する
- 中間結果は構造化形式（JSONやJSON-LDなど）で永続化され、後の集約や検証を容易にする
- メインコントローラーはタスク依存関係グラフ（DAG）を維持し、動的なスケジューリング、失敗時のリトライ、結果のキャッシュをサポートする
3. データ処理パイプライン
「フォーチュン500企業分析」を例にすると、以下のようになります。
- 発見フェーズ：検索エンジンや公開データベースを呼び出して企業リストを取得する
- 収集フェーズ：各サブエージェントがいくつかの企業を担当し、公式サイト、年次報告書PDF、プレスリリースを収集する
- 解析フェーズ：ルールマッチング、OCR、またはマルチモーダルモデルを使用して、主要なフィールド（収益、従業員数、CEOなど）を抽出する
- 突合フェーズ：統一された識別子（株式コードなど）に基づいてエンティティ解決を行い、標準化されたナレッジテーブルを構築する
このプロセスは非常にI/O集約的であり、VMの並行処理能力とネットワーク帯域幅に高い要求を突きつけます。
限界とスケーラビリティの課題
現在の限界
- 応答時間が制御不能：タスクの完了時間は最も遅いサブタスクに依存し、タイムアウトやサーキットブレーカー、部分的な結果を返す仕組みが欠けている
- リソースコストが不透明：タスクの規模に基づいたリソース消費モデルが提供されておらず、ユーザーがコストを予測するのが難しい
- 単一ノードのスケーリングにおけるボトルネック：すべてのサブエージェントが同一のVM上で実行されるため、CPU/メモリの競合がパフォーマンスの揺らぎを引き起こす可能性がある
- パブリックインターネットへの強い依存：プライベートなナレッジベースやイントラネットのデータソースに直接アクセスできない
大規模展開における課題
- コールドスタートの遅延：VMの作成と初期化には通常数秒から数十秒かかり、ユーザー体験に影響を与える
- 並行スケジューリングのオーバーヘッド：多数のサブタスクが同時に実行されると、プロセス管理と通信がボトルネックになる可能性がある
- ストレージコスト：中間結果が適時にクリーンアップされない場合、大量の一時データが蓄積される
- セキュリティとコンプライアンス：任意のコードを動的に実行するサンドボックスは、特に企業環境において厳格な監査が必要となる
改善の方向性
- 深さ・幅の制御パラメータの導入：ユーザーが最大並列度（幅）と推論ステップ数（深さ）を明示的に制限できるようにする
- 階層的な実行戦略の採用：価値の高いサブタスクを優先的に処理し、優先度の低いタスクはダウングレードまたはスキップ可能にする
- ハイブリッドなデータソース接続のサポート：公開ウェブのクローリングとプライベートなベクトルストア検索を組み合わせる
- コスト見積もりAPIの提供：過去のタスク統計に基づいて、現在の構成でのリソース消費を予測する
もし、実用的でセルフホスト可能、かつきめ細やかな制御が可能なAgentic RAGソリューションをお探しなら、puppyoneがすぐに使える実装パスを提供します。MCPプロトコルをベースに構築されたpuppyoneは、深さと幅の動的な調整、複数モデルバックエンドの切り替え、プライベートナレッジベースとのシームレスな連携をサポートし、カスタマーサポートのQ&Aからエンタープライズレベルのインテリジェント分析まで、多様なシナリオに対応します。https://www.puppyone.ai/にアクセスして、制御可能な独自のリサーチエージェントをわずか数分でデプロイする方法をご覧ください。
FAQ
Q1: このアーキテクチャは、従来のマルチエージェントシステムとどう違うのですか？
A: 従来のシステムは、あらかじめ定義された役割（例：「プランナー」「エグゼキューター」）に依存します。一方、このアーキテクチャでは、すべてのサブエージェントが汎用インスタンスであり、自律的に行動パスを決定できるため、タスク構造がより柔軟で、汎化能力も高くなります。
Q2: このようなシステムをローカルやプライベートクラウドにデプロイできますか？
A: 可能です。ただし、仮想化のスケジューリング、ネットワークプロキシ、サンドボックスのセキュリティ、タスクの協調といった問題を自力で解決する必要があります。軽量な代替案としては、完全なVMの代わりにコンテナ（Dockerなど）を使用し、メッセージキューを介してエージェント間の通信を実現する方法が考えられます。
Q3: 高い並行性が求められるシナリオでの主なパフォーマンスボトルネックは何ですか？
A: 主なボトルネックは、VMのコールドスタート遅延、サブタスクスケジューラのスループット能力、エージェント間通信のシリアライゼーションオーバーヘッドなどです。最適化手法としては、ウォームプール、非同期タスクキュー、中間結果のキャッシュ再利用などが挙げられます。