背景
株式会社Acompany プラットフォーム部エンジニアの平岡です。
OpenAIやGoogleのDeep Researchを使うと、数十分で驚くほど整理されたレポートが出てきます。便利な反面、エンジニアとしては「中で何が起きているのか」が気になるところです。これらはAI Research Agentと呼ばれるシステムで、人間の調査員のように自律的にWeb検索・情報収集・分析・レポート作成を行います。従来のチャットボットが「ユーザーの指示待ち」なのに対し、AI Research Agentは「目標（Goal）」を与えられると、計画立案→調査→評価→修正のループを自律的に回し、最終的に構造化されたレポートを生成します。
しかし、OpenAIの「Deep Research」やGoogleの「Gemini Deep Research」といった商用サービスは、内部アーキテクチャが公開されていません。OpenAI Deep Research System CardやGoogle ResearchのTTD-DR論文から一部の仕組みは推察できるものの、詳細な実装は不明です。
一方、オープンソースのAI Research Agentも複数公開されており、コードレベルで内部の動作原理を確認できます。本ドキュメントでは、4つのOSS実装を対象に、その設計パターンと内部構造を比較分析しました。
対象プロジェクト:
| プロジェクト | 開発元 | フレームワーク |
|---|---|---|
| GPT-Researcher | Assaf Elovic（個人開発者） | LangChain + LangGraph |
| Open Deep Research | LangChain | LangGraph |
| STORM | Stanford大学 | DSPy |
| Open Deep Research HF | Hugging Face | smolagents |
下記は、Geminiによって出力された本記事に関するインフォグラフィックです（かなり要点を抑えていてすごい、、、！）。
1. エージェントアーキテクチャの設計パターン
概要比較
| 項目 | GPT-Researcher | Open Deep Research | STORM | Open Deep Research HF |
|---|---|---|---|---|
| 協調パターン | パイプライン型 | Supervisor-Worker型 | 対話シミュレーション型 | Manager-Worker型 |
| 制御フロー | 事前定義（固定） | 動的（Supervisorが判断） | 対話ターン制御 | コード生成（動的） |
| 並列実行 | asyncio.gather | max_concurrent_research_units | ThreadPoolExecutor | サブエージェント委譲 |
協調パターンの違い
4つのプロジェクトはすべて「マルチエージェント」ですが、協調の仕方が異なります。
- パイプライン型（GPT-Researcher）: ワークフローが事前に固定。各エージェントが順番にバトンを渡す
- Supervisor-Worker型（Open Deep Research）: Supervisorがツール呼び出しでWorkerを起動。各ステップで判断し直す
- 対話シミュレーション型（STORM）: 上位→下位の指示ではなく、質問者↔回答者の対話で情報収集
- Manager-Worker型（Open Deep Research HF）: Managerがコード生成でWorkerを制御。ループや条件分岐を1回で記述可能
協調パターンのトレードオフ
| パターン | 強み | 弱み |
|---|---|---|
| パイプライン型 | シンプルで予測しやすい、並列実行で高速 | 途中で方針変更できない |
| Supervisor-Worker型 | 状況に応じた動的判断が可能 | 各ステップでLLM呼び出しが必要 |
| 対話シミュレーション型 | 多角的な視点で情報収集 | 対話のオーバーヘッド、制御が難しい |
| Manager-Worker型 | 複雑な制御フローを一度に記述可能 | コード生成の品質がLLMに依存 |
2. 計画と検索の関係
各プロジェクトは「計画」と「検索」の関係が異なります。明確に分離しているものと、融合しているものがあります。
| 項目 | GPT-Researcher | Open Deep Research | STORM | Open Deep Research HF |
|---|---|---|---|---|
| 計画と検索 | 分離（一方向） | 分離（検索結果を見て追加計画） | 融合（対話の中で同時進行） | 分離（定期的に再計画） |
| 計画手法 | サブクエリ生成 | リサーチブリーフ + タスク委譲 | ペルソナ生成 | コード生成 |
| 計画の更新 | なし（事前確定） | Supervisorが動的に判断 | 対話の流れで決定 | 4ステップごとに再計画 |
- GPT-Researcher: 計画（サブクエリ生成）→ 検索（並列実行）の順次実行。計画確定後は変更しない
- Open Deep Research: 計画と検索を往復。Supervisorが検索結果を見て追加の検索を判断
- STORM: 計画と検索が融合。対話シミュレーションの中でWikiWriterの質問に応じてTopicExpertが検索を実行。明示的な計画フェーズはなく、ペルソナ生成が暗黙的な計画となる
- Open Deep Research HF: 計画（コード生成）→ 検索（コード実行）の順次実行。ただし4ステップごとに計画を見直す
計画アプローチのトレードオフ
| アプローチ | 強み | 弱み |
|---|---|---|
| 事前確定（GPT-Researcher） | 効率的、並列実行しやすい | 想定外の発見に対応できない |
| 動的判断（Open Deep Research） | 検索結果に応じて深掘り可能 | 判断コストがかかる |
| 融合（STORM） | 自然な探索、網羅性が高い | 終了条件の制御が難しい |
| 定期再計画（Open Deep Research HF） | バランスが取れている | 再計画タイミングが固定的 |
3. メモリ管理アーキテクチャ
収集した情報をどのように保持・管理するかの比較です。GPT-ResearcherのみRAGパターンを採用し、他の3プロジェクトはPythonオブジェクトとして情報を保持します。
| 項目 | GPT-Researcher | Open Deep Research | STORM | Open Deep Research HF |
|---|---|---|---|---|
| 保存形式 | VectorStore | Pythonオブジェクト | Pythonオブジェクト | Pythonオブジェクト |
| データ構造 | ベクトル化されたチャンク | フラットな状態オブジェクト | 対話履歴 + 情報リスト | 時系列リスト |
| 取得方法 | 類似度検索 | フィールド参照 | イテレーション | 順次参照 |
GPT-Researcher: VectorStore
- 保存場所: 外部ストレージ（Chroma, FAISS, Pinecone等）
-
データ構造: LangChainのDocumentオブジェクトをベクトル化して保存
Document( page_content="AIエージェントとは自律的に...", # チャンク分割されたテキスト metadata={"source": "https://example.com/ai-agent"} ) - データの追加: スクレイピング結果をチャンク分割 → Embedding変換 → VectorStoreに格納
- データの取得: クエリをベクトル化 → 類似度検索 → 上位N件のDocumentを取得
- VectorStoreを使う理由: 大量のWebページから関連部分を後から検索するため
Open Deep Research: State-based
- 保存場所: メモリ上のPythonオブジェクト（LangGraphのTypedDict）
-
データ構造: 処理結果を格納するフラットなフィールド群
class AgentState(MessagesState): research_brief: Optional[str] # 調査概要 raw_notes: Annotated[list[str], ...] # 生のメモ notes: Annotated[list[str], ...] # 整理されたメモ final_report: str # 最終レポート - VectorStoreを使わない理由: 収集時点でLLMが要約するため、後から検索する必要がない
STORM: KnowledgeBase
- 保存場所: メモリ上のPythonオブジェクト
-
データ構造: ペルソナごとの対話履歴（DialogueTurn）と、収集した情報（Information）を保持
class DialogueTurn: agent_utterance: str # WikiWriter（質問者）の発言 user_utterance: str # TopicExpert（回答者）の発言 search_queries: List[str] # 検索に使用したクエリ search_results: List[Information] # 検索結果 class Information: url: str # 情報源のURL snippets: list # 引用スニペット title: str - VectorStoreを使わない理由: 対話構造に沿って整理済みのため、ベクトル検索が不要
Open Deep Research HF: 会話履歴
-
保存場所: メモリ上のPythonオブジェクト（
agent.memory.steps） -
データ構造: エージェントの各ステップを時系列で記録したMemoryStepのリスト
agent.memory.steps = [ MemoryStep(model_input_messages=[...], ...), # Step 1 MemoryStep(model_input_messages=[...], ...), # Step 2 ... ] - VectorStoreを使わない理由: 1回のタスクで扱うデータ量が少なく、履歴で十分
メモリ管理のトレードオフ
| 方式 | 強み | 弱み |
|---|---|---|
| VectorStore | 大量のWebページから関連部分を後から検索できる | セットアップとEmbedding処理のコストがかかる |
| Pythonオブジェクト | シンプルで軽量 | 大量の生データを保持するには向かない |
4. コンテキスト圧縮の仕組み
LLMのコンテキスト長制限に対処するため、各プロジェクトは異なる圧縮戦略を採用しています。
| 項目 | GPT-Researcher | Open Deep Research | STORM | Open Deep Research HF |
|---|---|---|---|---|
| 圧縮手法 | Embedding類似度フィルタ | LLMによる要約 | 単語数制限 + 切り詰め | ビューポート分割※ |
| タイミング | スクレイピング後 | 各Researcher完了時 | 会話コンテキスト構築時 | ページ読み込み時 |
※ビューポート分割: 長いWebページを固定サイズ（5120文字）の表示領域に分割し、PageUp/PageDownで移動しながら読み進める方式
コンテキスト圧縮のトレードオフ
| 手法 | 強み | 弱み |
|---|---|---|
| Embedding類似度フィルタ | クエリに関連する情報だけを抽出できる | 類似度の閾値設定が難しい |
| LLMによる要約 | 文脈を理解した圧縮ができる | LLM呼び出しのコストがかかる |
| 単語数制限 + 切り詰め | シンプルで高速 | 重要な情報が切り捨てられる可能性 |
| ビューポート分割 | 長いページを段階的に処理できる | 全体を一度に把握できない |
まとめ：設計トレードオフ
4つのOSS AI Research Agentを比較した結果、いくつかの共通点と相違点が見えてきました。
共通点: すべてのプロジェクトが「計画→検索→レポート生成」という基本的な流れを持ち、複数のエージェント（または役割）が協調して動作します。また、LLMのコンテキスト長制限に対処するため、何らかの情報圧縮の仕組みを備えています。
相違点: 協調パターン、計画の柔軟性、メモリ管理方式において、各プロジェクトは異なるアプローチを採用しています。これらの違いは「どちらが優れている」というものではなく、それぞれの設計思想やユースケースに応じた選択の結果です。
アーキテクチャ選択の指針
| 観点 | 選択肢 |
|---|---|
| 協調パターン | パイプライン型（シンプル）↔ Supervisor/Manager型（動的制御） |
| 計画と検索 | 分離（明確なフェーズ）↔ 融合（対話の中で同時進行） |
| メモリ管理 | VectorStore/RAG（後から検索）↔ Pythonオブジェクト（構造化保持） |
| 計画の更新 | 事前確定（予測可能）↔ 動的判断（柔軟） |
各プロジェクトの設計特性
GPT-Researcher: 「大量収集 → 精密抽出」
GPT-Researcherの設計思想は「まず広く集めて、後から必要な情報を精密に取り出す」というものです。パイプライン型アーキテクチャで処理の流れを事前に固定し、並列スクレイピングで大量のWebページを一気に収集します。収集した情報はVectorStoreに格納され、レポート生成時に類似度検索で関連部分だけを取り出します。計画を途中で変更しない代わりに、RAGによる後処理で情報の取捨選択を行うアプローチです。
- 強み: シンプルで予測しやすく、並列実行で高速。大量の情報を扱える
- 弱み: 調査途中で方針を変更できないため、想定外の発見に対応しづらい
Open Deep Research: 「調査しながら方針を調整」
Open Deep Researchは「検索結果を見てから次の行動を決める」という適応的なアプローチを取ります。Supervisorが各ステップで状況を判断し、必要に応じて追加の調査を指示します。収集した情報はその場でLLMが要約するため、VectorStoreを使わずに状態オブジェクトで管理できます。事前に完璧な計画を立てるのではなく、調査を進めながら方針を柔軟に調整していく設計です。
- 強み: 検索結果に応じて深掘りや方向転換が可能
- 弱み: 各ステップでLLMの判断を挟むため、パイプライン型より処理時間がかかる
STORM: 「多角的な対話で深掘り」
STORMは「複数の専門家が議論すれば、より良い記事が書ける」という考えに基づいています。WikiWriter（質問者）とTopicExpert（回答者）の対話シミュレーションを通じて情報を収集するため、計画と検索が明確に分離されません。質問が出るたびに検索が走り、その回答がまた次の質問を生む—この対話の流れ自体が調査プロセスとなります。異なるペルソナを設定することで、単一視点では見落としがちな情報も拾い上げることができます。
- 強み: 複数のペルソナによる多角的な視点で、網羅性の高い情報収集ができる
- 弱み: 対話シミュレーションのオーバーヘッドがあり、処理の流れが予測しづらい
Open Deep Research HF: 「コードで制御フローを記述」
Open Deep Research HFは「エージェント自身に制御フローを書かせる」というアプローチです。Manager（CodeAgent）がPythonコードを生成し、ループや条件分岐を含む複雑な処理を1回の出力で記述できます。ツール呼び出しを1つずつ判断するのではなく、「この条件ならAを実行、そうでなければBを実行」といったロジックをコードとして表現します。4ステップごとの再計画で軌道修正しつつ、コード生成による柔軟性を活かした設計です。
- 強み: コードで複雑な制御フローを一度に記述でき、表現力が高い
- 弱み: 生成されるコードの品質がLLMに依存し、デバッグが難しい
AI Research Agentの実装において「正解」となるアーキテクチャは存在しません。重要なのは、自身のユースケースに応じて適切なトレードオフを選択することです。本ドキュメントで紹介した4つのOSS実装は、それぞれ異なるアプローチでこの課題に取り組んでおり、新たにAI Research Agentを構築する際の参考になるはずです。
Discussion