セルフホステッド型ディープリサーチシステム：12のツール比較

ディープリサーチ（Deep Research）は、もはや検索ボックスに向かせたモデルというわけではなく、独自のソフトウェアのカテゴリとして確立しつつあります。本記事では、12のセルフホスト型システムとその背後にあるリサーチアーキテクチャを比較します。

実際に重要なのは、製品が「ディープリサーチ」とラベルされたボタンを搭載しているかどうかではなく、最初の検索（レトリーバル）ラウンドの後で何が起きるかです。本物のシステムは、自分の計画が不完全であったことに気づき、新たに発見された手がかりを追跡し、矛盾するソースを重み付け、その後にのみレポートを書き出します。

以下では、このループを異なる方法で実装している12のオープンソースおよびセルフホスト型プロジェクトを比較します。再帰的リサーチツリー、プランナーとサブエージェントの設計、エビデンスギャップによるループ、視点駆動型の質問生成、モデル駆動型のエージェント検索などです。各プロジェクトについて、アーキテクチャ、ローカルLLMのサポート、RAGまたはプライベートドキュメントへのアクセス、デプロイの複雑さ、セルフホスト時に実際に継承されるライセンスを解説します。システムが完全な製品でもある場合（Open WebUI、Vaneなど）は、リサーチの方式に焦点を当て、インストールや設定については専用のガイドへのリンクを掲載します。ディープリサーチは、AIシステムの中でも特に要求の厳しい応用ワークロードの1つです。それは単一のレイヤーではなく、検索、計画、多段階オーケストレーションを同時に負荷かけます。

ディープリサーチとは何か？

従来のAIウェブ検索ワークフローは、主に線形です。複数の検索が実行される場合でも、モデルは関連するクエリを作成し、ドキュメントを取得し、発見した内容を要約するだけなのが通常です：

Question
  |
Search
  |
Retrieve pages
  |
Summarize
  |
Answer

ディープリサーチは1つのレイヤーを加えます：リサーチプロセス自体が適応的になるのです。最初のパスの後、システムは分岐し、再確認し、エビデンスが十分になるまで継続することができます。

この区別は重要です。5回検索するシステムが必ずしもディープリサーチを実行しているとは限りません。より強力なシステムは、1つの質問から開始し、予期せぬ実装の詳細を発見し、それを中心に新しいリサーチブランチを開き、一次情報源と二次情報源を比較し、元の仮説を修正します。検索とディープ検索とディープリサーチのより広範な違い、およびクラウドサービスがこの同じアイデアをどのように枠組するかについては、2026年における検索、ディープ検索、ディープリサーチの違いを参照してください。

ディープリサーチのアーキテクチャに1つの正解はありません。現在のセルフホスト型実装は、一般的に次の5つのグループに分類されます：

1. 再帰的リサーチツリー。
2. プランナーとサブエージェントのアーキテクチャ。
3. エビデンスギャップ駆動型のリサーチループ。
4. 視点と質問駆動型のリサーチ。
5. エージェント型反復検索。

最初の4つは、より明示的なリサーチ構造を提供します。5つ目は、強力な推論とツール呼び出しモデルと組み合わせることで驚くほど深く調査できますが、戦略の多くはモデル自体に委ねられています。特にエビデンスギャップループは、Self-RAGスタイルのパイプラインで使用される自己省察的検索のシステムレベルの親戚であり、再検索を行うべきかどうかを決定し、関連性を判断し、回答前にドラフトを批判するものです。そのパターンをレトリーバルパイプラインレベルで詳しく見るには、高度なRAG: LongRAG、Self-RAG、GraphRAGを参照してください。

セルフホスト型ディープリサーチシステムの比較

下表は主要なシステムを要約したものです。「再帰的深度」とは、複数のウェブ検索が可能であることを意味するのではなく、中間の調査結果から追加の調査を導出する何らかのメカニズムがシステムにあることを意味します。

1つの点が際立っています：UIの高度化とリサーチの深度には直接的な関係がないことです。Open WebUIやVaneは洗練されたインターフェースを提供しますが、GPT ResearcherやSTORMはリサーチアルゴリズムに焦点を当てています。逆に、OnyxやUnsloth Studioは、強力なユーザー体験と実質的なリサーチワークフローの両方を提供しようと試みています。これらのシステムの多くは、LLMホスティングガイドで紹介されている同じローカル推論バックエンドに対して動作します。

ディープリサーチのアーキテクチャ

個々の製品を比較する前に、アーキテクチャの違いを理解することが役立ちます。

これらのカテゴリは重なり合っています。Local Deep Researchは複数のリサーチ戦略を提供し、DeerFlow 2.0はリサーチ専用アプリケーションではなく、リサーチを実行できる汎用のエージェントプラットフォームです。しかし、システムを選ぶ際にこの区別は依然として有用です：再帰的に分岐するリサーチャーと、単にsearch_webツールを持つだけのチャットインターフェースでは、挙動が異なります。Webと共にプライベートドキュメントを取得するシステムは、[RAGクラスタ](https://www.glukhov.org/ja/rag/ “検索拡張生成（RAG）システム: アーキテクチャ、埋め込み、リランキング、チャンキング、ベクトルストア。"}に記載されている同じレトリーバルパターンに依存しています。

ライセンス比較

システムが内部プラットフォーム、商業サービス、再配布製品の一部分になる場合、ライセンスは特に重要です。

プライベートなセルフホスティングの場合、これらのどのライセンスも通常の使用を妨げるものではありません。違いは、ソフトウェアを変更し、他のユーザーに提供し、別の商業アプリケーションに組み込み、または派生製品を再配布する場合に重要になります。MITとApache-2.0は、統合に対して一般的に最もシンプルな選択肢です。AGPL-3.0は、ネットワークにアクセス可能な変更を加えたデプロイメントに対してより慎重なレビューが必要です。また、Open WebUIの現在のライセンスは独自のブランディング条件を追加しています。

GPT Researcher

GPT Researcherは、Assaf Elovic氏とコントリビューターによって開発され、包括的なオンライン調査に特化した自律リサーチエージェントです。これは、「ディープリサーチ」という用語がユーザーインターフェース機能ではなくアルゴリズムを指す場合に何を含むのかを示す、最も明確な参照実装の1つです。

その最大の強みは、明示的なbreadth（横の広がり）とdepth（縦の深さ）です。Deep Researchモードはdeep_research_breadth、deep_research_depth、並列性などのパラメータを公開し、1つの調査が複数のブランチを生成し、それらのブランチが追加のリサーチを生成できるようにします。これにより、固定された検索クエリのコレクションではなく、本物のリサーチツリーが作成されます。

このアプローチにもコストがあります。再帰的展開は多くのレトリーバルおよびLLM操作を生成し得て、最終結果の品質は、モデルが有用なリサーチ質問を構築し、エビデンスを抽出し、弱い仮説をより深いレベルに伝播させない能力に大きく依存します。GPT Researcherは、Open WebUIやUnsloth Studioのようなアプリケーションよりも、リサーチエンジン志向です。

インストールは自明というよりは中程度です：プロジェクトはPythonを使用しWebアプリケーションを同梱していますが、有用なデプロイには適切なモデルと検索プロバイダーも必要です。現在のプロジェクトメタデータはMITライセンスを宣言しています。明示的なリサーチ深度、設定可能な再帰、リサーチファーストのアーキテクチャが、汎用ローカルAIワークステーションよりも重要である場合にGPT Researcherを選択してください。

Unsloth Studio

Unsloth Studioは、Unslothチームによって、より広範なUnslothエコシステムの一部として開発されています。もともと効率的なモデルファインチューニングで最も良く知られていましたが、UnslothはStudioを推論、チャット、ツール、RAG、モデル管理、そして今やディープリサーチのためのローカルAI環境として拡大しました。

Studioの興味深い側面は、リサーチがローカルモデルの動作とどれほど緊密に統合されているかです。そのDeep Researchワークフローには、計画段階、計画レビュー、エビデンス収集、レポート生成、ドキュメント処理、およびリサーチステップがエビデンスを収集できない場合の障害処理が含まれます。すでにGGUF或其他のローカルモデルを実行しているユーザーにとって、これは個別のリサーチフレームワーク、推論サーバー、フロントエンドを組み立てるよりはるかに便利になります。

Studioは、GPT Researcherのような単純なbreadth/depthリサーチツリーの抽象化を公開していません。ワークフローの多くは、任意の再帰的展開ではなく、リサーチ計画とエビデンス収集を中心に組織されており、機能は一部の専用リサーチプロジェクトよりも新しいです。ローカルリサーチの品質もまた、コンテキスト長、出力制限、ツール使用、選択したモデルの推論品質に対して依然として敏感です。

Unslothが現在主要プラットフォーム全体でStudioおよびデスクトップ向けのワークフローを提供しているため、インストールは比較的親しみやすいですが、高度なローカルデプロイメントではGPUやモデルの設定が依然として実質的になり得ます。StudioコンポーネントはAGPL-3.0、コアのUnslothパッケージはApache-2.0のままです。Deep Researchが独立したリサービサービスではなく、より広範なローカルモデルワークステーションの一部であるべき場合にUnsloth Studioを選択してください。

Local Deep Research

Local Deep Researchは、LearningCircuitとコントリビューターによって保守される、プライバシー重視のオープンソースリサーチアシスタントです。その明示的な目標は、Webソース、学術データベース、プライベートドキュメント、ローカル言語モデルを使用して体系的なリサーチを行うことです。

その主要な利点はアーキテクチャの柔軟性です。1つのリサーチアルゴリズムを強制するのではなく、Local Deep Researchはパイプライン指向の戦略に加えて、モデルが何を検索するか、どの専門ソースを使用するか、十分なエビデンスが収集されたかを決定できるLangGraphエージェント戦略をサポートします。arXiv、PubMed、Semantic Scholarなどの学術ソースや他の検索メカニズムは、技術的および科学的リサーチにとって特に魅力的です。

柔軟性の落とし穴は複雑さです。異なる戦略は大幅に異なる挙動を示すことができ、結果を1つの単純な「depth」パラメータで特徴づけるのが難しくなります。また、従来のチャットUIよりも動く部品が多く、素早いAI支援Web回答のみを求めているユーザーには不必要に洗練されていると感じさせるかもしれません。

このプロジェクトはローカル動作をサポートし、基盤となるリサーチエンジンを中心に実質的なアプリケーションを開発しました。そのライセンスはMITです。プライバシー、ローカル推論、複数のリサーチ戦略、学術情報ソース、リサーチプロセスの制御が、最小限の設定よりも重要である場合にLocal Deep Researchを選択してください。

STORM と Co-STORM

STORMは、Stanford OVALによって開発され、Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking（検索と多視点の質問を介したトピックアウトラインの統合）を意味します。一般的なAIチャットではなく、ナレッジキュレーションと長文レポート生成を念頭に置いて設計されました。

STORMの独自テクニックは、視点駆動型のリサーチです。主題に関する異なる視点を発見しようと試み、アウトラインと記事を書く前に、収集される情報を広げるために質問をします。Co-STORMはこの概念を、協力的な人間とAIのナレッジキュレーションへと拡張します。これにより、従来のキーワード検索リストが見落とす可能性のあるトピックの次元を明らかにできます。

STORMは、一般的なローカルAIフロントエンドとしてそれほど適していません。そのワークフローは、構造化されたWikipediaのような記事の研究と作成に強く向いており、プロジェクト自身のドキュメントは、生成された出力を自動的に公開準備ができていると見なすべきではないと指摘しています。したがって、Open WebUIの代替品としてではなく、専門的なリサーチおよびナレッジキュレーションエンジンとして理解されるのがより適切です。

インストールはPython志向であり、パイプラインは異なるモデルやレトリーバーでカスタマイズできます。STORMはMITライセンスを使用しています。目標が幅広いトピックの探索、視pointsの発見、構造化されたアウトライン、長文のナレッジ統合である場合に選択してください。

DeerFlow

DeerFlowは、ByteDanceとDeerFlowコミュニティによって開発されています。その名前は元々Deep Exploration and Efficient Research Flowを意味していましたが、現在、元の1.xのDeep ResearchフレームワークとDeerFlow 2.0の間には重要な区別があります。

DeerFlow 1.xは、特定のDeep Research围绕して設計されていました。DeerFlow 2.0は、サブエージェント、メモリ、サンドボックス、ツール、スキルをオーケストレートできる、より一般的なSuperAgentハーネスへの根本からの書き直しです。リサーチに関して言えば、このアーキテクチャは強力です。なぜなら、コーディネーターが問題の異なる部分を別々のエージェントに委譲し、後でそれらの調査結果を統合できるためです。これは、マルチエージェントオーケストレーションパターンで扱われるのと同じ、プランナーとサブエージェントの分解です。

トレードオフは、DeerFlow 2.0がもはや狭く最適化されたリサーチエンジンではないということです。それは、研究がコーディング、成果物生成、その他のタスクの中の1つのワークロードである、より一般的な長期的エージェントプラットフォームに近いものです。要件が小さな専用リサービサービスであれば、この追加のマシンリーは不要かもしれません。

したがって、デプロイは単純な検索UIよりも関与が大きくなりますが、アーキテクチャはカスタマイズと拡張により多くの余地を提供します。DeerFlowはMITライセンスです。Deep Researchがより広範なマルチエージェント自動化環境内の1つの能力になることが期待される場合にDeerFlowを選択してください。

Onyx

Onyxは、元々Danswerとして知られ、DanswerAIによって開発され、組織のためのセルフホスト可能なAIアプリケーションレイヤーとして位置づけられています。チャット、エージェント、Web検索、RAG、MCP統合、多くのエンタープライズデータコネクタ、そして専用のDeep Research機能を組み合わせます。

Onyxが際立っているのは、リサーチがパブリックWebと実質的なプライベートナレッジ環境の両方をまたぐことができるためです。そのDeep Research実装は、単なる検索結果の要約器ではなく、本物の多段階リサーチフローであり、プロジェクトはDeepResearch Benchの結果と実行ログを発表しています。内部ドキュメント、インデックスされたアプリケーション、外部ソースにわたるリサーチが必要な組織にとって、これは特に強力な組み合わせです。

それらの機能のコストはインフラストラクチャの複雑さです。OnyxはGPT Researcherや軽量なローカルリサーチプロジェクトよりも大きなプラットフォームであり、その強みの多くは、コネクタ、インデックス作成、認証、ドキュメントストア、組織データが実際に使用されている場合にのみ重要になります。

Onyxはセルフホストでデプロイでき、制限された環境も含みます。主要リポジトリのほとんどはMITライセンスですが、eeディレクトリ以下のコードはOnyxエンタープライズライセンスを使用し、別個のonyx-fossリポジトリは完全にMITライセンスのバリアントとして保守されています。Deep Researchが真面目なエンタープライズRAGと組織ナレッジレトリーバルと共存させなければならない場合にOnyxを選択してください。

Open Deep Research

Open Deep Researchは、LangChainによって開発された、設定可能なDeep Researchエージェントのオープン実装です。計画、リサーチ、レポート生成、複数のモデルプロバイダー、検索ツール、MCP統合をLangGraphを使用して組み合わせます。

そのアーキテクチャは、開発者にとって特に興味深いものです。リサーチ作業を分解し並列化できるため、プランナー-リサーチャー-統合者の設計のための有用な参照になります。プロジェクトがモノリス的なUIではなくLangGraphを中心に構築されたため、カスタムリサーチエージェントを構築するための実装パターンとして研究することも容易です。

新規デプロイメントには1つの大きな問題があります：LangChainは2026年8月21日にリポジトリをアーカイブし、現在読み取り専用です。コードは依然として有用ですが、アーカイブされた参照プロジェクトを中心に本番システムを開始することは、明らかなメンテナンスリスクを生み出します。

プロジェクトはPythonベースで、MITライセンスを使用しています。今日では、アーキテクチャの研究、実験、または実装アイデアのソースとして、新しい長寿命インストールのデフォルトの基盤としてではなく、主に選択してください。

Open WebUI

Open WebUIは、ローカルおよびリモートLLMのための最も人気のある汎用セルフホスト型インターフェースの1つです。その最近のエージェント型ツールアーキテクチャは、モデルにWeb検索、URL取得、ナレッジベース、ファイル、メモリ、コード実行、その他のツールへのアクセスを与えます。インストール、RAG設定、完全な機能セットについては、Open WebUIガイドを参照してください。

Open WebUIのリサーチモデルは興味深いもので、リサーチループが主に言語モデルによって制御されるためです。ネイティブエージェントモードでは、モデルは検索し、スニペットを検証し、完全なページを取得し、欠落した情報を特定し、新たに発見されたURLを追跡し、ソースをクロスチェックし、回答を生成する前にそのプロセスを繰り返すことができます。強力な推論とツール呼び出しモデルと組み合わせることで、専用の固定リサーチツリーなしで、本物の調査的挙動を生成できます。

制限は、まさにこの構造がモデル駆動型であるという点にあります。Open WebUIはGPT Researcherのような明示的なbreadth/depthリサーチトポロジーを提供しておらず、独立したブランチがどれくらい探索されるかの決定論的な制御は少なくなります。弱いツール呼び出しモデルは早すぎることなく停止し、悪く検索し、または重要な手がかりを追跡し逃す可能性があります。

インストールはこの比較の中で最も容易なものの1つで、特にすでにOllama、llama.cpp、vLLM、または別のOpenAI互換推論サーバーを実行しているユーザーにとってそうです。現在のリリースはOpen WebUI Licenseを使用し、実質的な寛容な特性を保持しつつブランディング制限を追加しています；プロジェクトの以前の部分にはMITとBSD-3-Clauseの履歴があります。優れたローカルLLM統合と、リサーチが多くのエージェント機能の1つである一般的なAIインターフェースを求めている場合にOpen WebUIを選択してください。

Khoj

Khojは、セルフホスト可能なパーソナルAIと「第二の脳」として開発されています。ローカルまたはクラウドの言語モデルを、Webレトリーバル、パーソナルドキュメント、セマンティック検索、カスタムエージェント、オートメーション、実験的な/researchモードと組み合わせます。

その最強の使用ケースは、パブリック情報とユーザーの既存ナレッジベースの境界をまたぐリサーチです。質問は、PDF、Markdownファイル、ノート、オフィスドキュメント、または接続された情報のコンテキストで調査でき、すべてのタスクを最初からのWebリサーチとして扱う必要はありません。これはKhojを継続的なパーソナルまたはチームのナレッジワークに有用にします。

Khojは、可視的な再帰的リサーチツリー围绕して主に設計されていません。そのリサーチ機能は、より大きなパーソナルナレッジシステム内での自律的な調査として理解するのがより適切です。明示的なbreadth/depth制御や専用のリサーチエンジンAPIを求めるユーザーは、GPT ResearcherやLocal Deep Researchを好むかもしれません。

セルフホスティングはサポートされており、Llama、Qwen、Gemma、Mistralファミリーを含むローカルモデルと動作できます。KhojはAGPL-3.0-or-laterの下でライセンスされています。Deep Researchが切り離されたWebリサーチジョブとしてではなく、長寿のパーソナルナレッジベースと密接に統合されるべき場合に選択してください。

SurfSense

SurfSenseは、NotebookLMスタイルのナレッジシステムから、エージェント志向のオープンWebリサーチプラットフォームへと進化したオープンソースのリサーチワークスペースです。検索可能なナレッジベースを、Webおよびプラットフォーム固有のデータコネクタ、レポート、オートメーション、MCPアクセス、ローカルモデルサポートと組み合わせます。

SurfSenseの独自の利点は、そのデータサーフェスです。これは、普通のWebページや検索結果だけでなく、Reddit、YouTube、Googleマップ、その他のライブ情報サービスなどのソースにも構造化されたアクセスを与えるよう設計されています。リサーチ結果は、アップロードされたドキュメントや以前に収集されたナレッジと同じ環境内に残すことができます。

それはGPT ResearcherやSTORMほど純粋にリサーチアルゴリズムに焦点を当てていません。SurfSenseの価値の大きな部分は、明示的な再帰的に拡張されるリサーチグラフではなく、レトリーバルインフラストラクチャ、コネクタ、ナレッジ管理、下流の成果物から来ています。

セルフホスティングはDocker指向のインストールを通じてサポートされており、ローカルモデルは一般的なローカル推論インターフェースを通じて接続できます。現在のリポジトリはApache-2.0ライセンスです。リサーチの困難な部分が、多くの異なるデータソースから情報を取得し、構造化し、保持し、再利用することである場合にSurfSenseを選択してください。

Vane, 旧Perplexica

Vane、旧称Perplexicaは、セルフホストされたPerplexityのような検索ファースト製品の代替品として設計されたオープンソースのAI回答エンジンです。AIチャットインターフェース、検索バックエンド、引用、ローカルモデルサポート、アップロードされたファイルに対するセマンティック検索を組み合わせます。Dockerクイックスタート、SEARXNG_API_URLの配線、Ollama/llama.cppセットアップについては、Ollamaとllama.cppによるVane (Perplexica 2.0) クイックスタートを参照してください。

Vaneは検索と回答の体験に優れています。質問を分類し、Webリサーチを行い、有用な情報を取得し、洗練されたインターフェースを通じて引用付きの応答を生成します。ほとんどのデプロイは、検索レイヤーとしてSearXNGでバックアップします。主にSearXNGとローカルモデルでバックアップされたプライベートなAI検索エンジンを求めているユーザーにとって、大きな汎用エージェントプラットフォームよりもるかに焦点を絞った体験を提供します。

この比較におけるその制限は、リサーチの深度です。システムはリサーチ操作を実行できますが、そのアーキテクチャはまだ主に回答エンジンのものであり、再帰的に分岐するディープリサーチフレームワークではありません。したがって、両方が応答前に複数の検索を実行できるという理由だけで、GPT Researcherと同等と扱うべきではありません。

VaneはDockerでデプロイするのが比較的簡単で、一般的なモデルプロバイダーとローカル推論システムをサポートしています。MITライセンスです。主要な要件が長い自律的な調査ではなく、引用付きの高品質なセルフホスト型AI検索である場合にVaneを選択してください。

Deep Research by lukeswade

lukeswade/deep-researchプロジェクトは、小さなセルフホストされたリサーチシステムですが、この比較の中でより興味深いワークフローの1つを実装しています。クラウドモデルと、llama.cpp、LM Studio、Ollama、vLLM、MLXを含むローカルのOpenAI互換エンドポイントの両方をサポートします - そのエンドポイントのサーバー側については、CLIとサーバーによるllama.cppクイックスタートを参照してください。

そのリサーチループは明示的にギャップ駆動型です。実行は質問を対象とする検索に分解し、関連するページを読み、エビデンスを含むソースごとのノートを生成し、次に何を検索すべきかを決定する前に、何がまだ不明であるかを分析します。より高いdepth設定は、複数のラウンドと漸進的に大きなソース予算を許可し、飽和検出は、新しい検索が有用な情報を生成しなくなった場合に研究を早期に停止できます。

それはOnyx、Open WebUI、Unsloth Studioのようなエコシステム、組織コネクタ、または汎用AIワークステーションの機能を持っていません。それは1つのことを行うことにるかに狭く焦点を当てています：質問を深く調査し、結果のリサーチを検索可能なローカルライブラリに保存すること。

その焦点は、デプロイを比較的理解可能にします。システムにはWeb UIがあり、ローカルのOpenAI互換モデルサーバーに特に親しみやすいです；ドキュメントは強力なモデルを推奨し、高量のノート処理に小さな高速モデルを使用することをサポートしています。MITライセンスです。ローカル推論、透明なエビデンス収集、情報ギャップ駆動型のリサーチが、大きな周囲のプラットフォームよりも重要である場合に選択してください。

どのディープリサーチシステムを選択すべきか？

勝者は1つではありません。これらのシステムは少し異なる問題を解決しているためです。

理解可能な深度制御を持つ明示的なリサーチアルゴリズムのために、GPT Researcherは依然として最も明確な出発点の1つです。そのbreadth/depthモデルは、リサーチがなぜ拡張され、実行がどれほど高価になり得るかを推論することを容易にします。

強力なローカルワークフローのために、Local Deep ResearchとUnsloth Studioは特に魅力的です。Local Deep Researchはより多くのリサーチ戦略の柔軟性を提供し、Unsloth Studioはリサーチをモデル管理、推論、RAG、より広範なローカルモデルワークフローと統合します。

長文のナレッジキュレーションのために、STORMは依然として異常に興味深いものです。なぜなら、その多視点の質問生成テクニックは、多くのリサーチシステムが無視する問題にアプローチするからです：元のユーザーが問いかけることを知らなかった質問を発見すること。

マルチエージェントシステムのために、DeerFlowは異なる方向を表しています。専門的なリサーチループを構築する代わりに、研究をサブエージェント間で委譲でき、ツール、メモリ、コード実行、他の機能と組み合わせられる長期的なエージェントタスクとして扱います。

組織のために、OnyxはDeep Research、RAG、Web調査、エンタープライズナレッジコネクタの組み合わせの中で最も強力なものの1つを持っています。内部情報ソースがパブリックWebと同じくらい重要である場合、その重いインフラストラクチャは正当化されます。

既存のローカルAIインストールのために、Open WebUIがすべてに必要な場合もあります。十分に強力なネイティブツール呼び出しを持つローカルモデルは、別個のリサーチエンジンをインストールせずに、繰り返し検索し、ページを読み、リンクを追跡し、情報を検証し、ギャップを埋めることができます。

最後に、lukeswade/deep-researchは、まさにその小ささゆえに見守る価値があります。そのギャップ駆動型ワークフローは概念的にクリーンで、OpenAI互換エンドポイントを通じて直接llama.cppをサポートし、高価な計画と統合を高量のソースごとの処理と分離します。

本物のディープリサーチと繰り返し検索を見分ける方法

これらのシステムを評価する最も有用な方法は、「Deep Research」とラベルされたボタンを持つかどうかを尋ねることではありません。代わりに、最初の情報が収集された後で何が起きるかを検査してください。

本物のリサーチシステムは、元の計画が不完全であったことを発見できるはずです。それは矛盾、欠落したソース、予期せぬ実装の詳細、または新たに関連するサブトピックを認識し、それに応じてその後の調査を変更すべきです。それが、洗練されたレトリーバルとリサーチを分ける線です。

セルフホスティングにとって、エコシステムは現在十分に広く、選択肢はクラウドのDeep Researchサービスと自作のスクリプトの間のもはや単純なものではありません。専用の再帰的リサーチャー、学術的なナレッジキュレーションシステム、エンタープライズリサーチプラットフォーム、ローカルモデルワークステーション、汎用エージェントフレームワーク、軽量なギャップ駆動型ツールがあります。

したがって、正しい選択は、どのプロジェクトが最も多くの機能を宣伝するかよりも、あなたが運営したいリサーチアーキテクチャ - 明示的な再帰、マルチエージェント委譲、エビデンスギャップ分析、視点の発見、またはモデル駆動の自律検索 - に依存します。

参考資料

• GPT Researcher
• Unsloth Studio
• Local Deep Research
• STORM / Co-STORM
• DeerFlow
• Onyx
• Open Deep Research
• Open WebUI
• Khoj
• SurfSense
• Vane (旧Perplexica)
• lukeswade/deep-research
• 2026年における検索、ディープ検索、ディープリサーチの違い
• マルチエージェントオーケストレーションパターン