OpenResearcher を採用する前に読む、96K軌跡データと11Bトークン検索基盤の実際

OpenResearcher が埋めようとしている穴は、検索 API 依存の学習データ生成

長距離のディープリサーチをエージェントに学習させるとき、多くの実装は外部の検索 API を呼び出して軌跡を集める。呼び出し回数がそのまま費用になり、100 ターンを超える軌跡を大量に作ると課金が読めなくなる。OpenResearcher はこの依存を外す方向で設計されている。README によれば、自前で構築した retriever を約 11B トークンの専用コーパス上で動かし、外部 Search API を不要にしたと説明されている。対象読者は、リサーチエージェントの学習データを自前で生成したい研究チームと、その評価を再現したい実務者だ。モデル単体の配布ではなく、データ、モデル、学習手法、評価フレームワークをまとめて公開する点が README の主張の中心にある。

96K 軌跡はどう作られ、どこで学習に回るか

README が示すデータの流れはこうだ。GPT-OSS-120B に native browser tools を持たせ、100 ターンを超える DeepResearch 軌跡を生成する。これが 96K 件のデータセットとして Hugging Face の OpenResearcher-Dataset に公開される。次にこのデータを使い、30B-A3B 構成のモデルを蒸留レシピで訓練し、OpenResearcher-30B-A3B として配布する。評価はリポジトリ内の軽量な DeepResearch evaluation framework で行う。つまり推論モデル、教師データ、訓練手順、評価基盤が一続きのパイプラインとして公開されている。README は BrowseComp-Plus で 54.8% という数値を挙げ、GPT-4.1 や Claude-Opus-4、Gemini-2.5-Pro、DeepSeek-R1、Tongyi-DeepResearch を上回ると記述している。ただしこの数値は配布元の主張であり、本記事では追試していない。

ローカル検索エンジンと Serper API、2つの評価経路

評価の入り口は2つ用意されている。1つは BrowseComp-Plus をローカル検索エンジンで回す経路、もう1つは GAIA を Serper API で回す経路だ。README の見出しには Example 1: BrowseComp-Plus with Local Search Engine、Example 2: GAIA with Serper API (No Local Search Needed) とあり、後者はローカル検索を立てずに済む。ここは設計上の割り切りが表れている。外部 API を排除したのは学習データ生成の工程であって、評価まで完全にオフラインで閉じるわけではない。GAIA を試すだけなら Serper API のキーを用意する方が早い。逆に BrowseComp-Plus を再現するならローカル検索基盤の構築が前提になる。どちらの経路を選ぶかで、必要な作業量が大きく変わる。

セットアップで実際に触るコマンドと設定キー

README の目次には Environment Setup 配下の Installation と Deep Research Benchmarks Preparation、そして Configuration、Quick Start、Benchmark OpenResearcher、Evaluation、Quick Commands が並ぶ。評価を回す流れは、環境構築、ベンチマーク用データの準備、設定、実行、評価という順序になる。README は具体的な設定キーの中身までは本記事で引用できる形で示していないため、どのキーに何を入れるかは Configuration の節とリポジトリ内のファイルを直接確認する必要がある。学習まで進む場合は (Optional) Train Your Own OpenResearcher の節が入口になる。注意点として、この節は README 上で Optional と明示されており、評価だけなら訓練工程を飛ばせる。まず評価経路で挙動を確かめ、必要なら学習に進む順序が素直だ。

ライセンスが未記載であることの意味

提供されたリポジトリ情報では License が unknown となっており、README にもライセンス条項の記述は見当たらない。これは導入判断で最も重い制約になりうる。コード、モデル重み、データセット、コーパスはそれぞれ別の配布物として Hugging Face 上に置かれており、リポジトリのライセンスが不明なままだと、再配布や商用利用の可否を README だけでは判断できない。ここで法務判断を代行はできないが、確認先は明確だ。リポジトリ直下に LICENSE ファイルが存在するか、Hugging Face のモデルページとデータセットページに個別のライセンス表記があるか、この2点を先に見る。社内導入の稟議に通すなら、この確認が終わるまで PoC 止まりにしておくのが現実的である。

外部 API を消す代わりに何を運用することになるか

外部 Search API を排除した設計は、費用の予測可能性を上げる反面、運用対象を自陣に引き寄せる。約 11B トークンのコーパスと、その上で動く retriever を自分でホストすることになる。ストレージ、インデックス構築時間、検索レイテンシは、API 課金とは別の形でコストとして現れる。README は Highly Scalable and Low-Cost と表現し、検索 API 不要で訓練コストを下げると説明しているが、これは API 費用の話であって、計算資源がゼロになるという意味ではない。ローカル検索基盤を持てないチームにとっては、GAIA 用の Serper API 経路の方が現実的な選択になる。ここは用途で分かれる。

同じ課題に対する別解との違い

比較対象として素直なのは、Tongyi-DeepResearch のようなクローズドなディープリサーチモデルだ。README 自身がベンチマーク表で OpenResearcher と並べている。両者の違いは性能差よりも再現性の所在にある。クローズドなモデルは API 越しに呼び出すだけで、学習データも蒸留手順も見えない。OpenResearcher は逆に、96K の軌跡データ、訓練レシピ、評価フレームワークを公開し、自前で回す経路を用意する。この差は、モデルをそのまま使いたい場合には重荷になる。データも検索基盤も自分で抱える前提だからだ。一方で、リサーチエージェントの学習そのものを研究対象にしているチームにとっては、中身が見えること自体が価値になる。どちらが優れているかではなく、何を自分で持ちたいかで選ぶ話である。

導入前に確認すべき3点と、そこから先の進め方

最初に確認するのはライセンスだ。リポジトリの LICENSE ファイルと、Hugging Face 上のモデル・データセットのライセンス表記を突き合わせる。次に、評価だけを回すのか学習まで踏み込むのかを決める。評価だけなら GAIA の Serper API 経路で当たりを付け、BrowseComp-Plus のローカル検索経路は後回しにできる。学習まで進むなら 11B トークンのコーパスと retriever の運用を前提に、ストレージとインデックス構築の見積もりを先に取る。最後に、README が挙げる 54.8% という BrowseComp-Plus の数値は配布元の主張であることを踏まえ、自環境で Evaluation の節に従って再現する。この3点が埋まらないうちは、本番系への組み込みではなく検証環境での試用に留めるのが妥当だ。

編集部の結論

OpenResearcher が向くのは、検索 API の従量課金を避けつつ長距離リサーチの軌跡を自前で生成したい研究・学習チームだ。逆に、ライセンス条件が確定するまで本番系に組み込みたくない組織、あるいは 11B トークン規模のコーパスとローカル検索基盤を運用する余力がないチームには早い。採用前に確認すべきは、リポジトリに LICENSE ファイルが存在するか、Hugging Face 上のモデルとデータセットのライセンス表記がどうなっているか、そして BrowseComp-Plus を動かすのに必要な検索エンジン側のセットアップ手順が README の範囲で再現できるか、この3点である。

公式情報源

1. Issues
2. Project website
3. README
4. TIGER-AI-Lab/OpenResearcher on GitHub