何が起きたか
Nimbleが企業向けの検索基盤「Web Search Agents」を公開しました。同社は以前からVentureBeatに、複数のAIエージェントで企業向けWeb検索を再構築する企業として取り上げられてきた、ニューヨーク拠点のスタートアップです。今年前半には4,700万ドルのシリーズBを実施し、ライブWebを機械可読な構造化データに変える基盤として「Agentic Search Platform」を投入していました。今回はその上に、ドメイン特化の検索エージェントを載せた形になります。
公表されている性能は、主要なAI検索の代替手段と同等タスクで比較して「精度21%向上・トークン消費51%削減」。ただし、ベンチマークの具体的な方法も、比較対象となった競合の名前も開示されていません。この点は読む側で割り引く必要があります。
提供形態はAPI・SDK・Model Context Protocol（MCP）で、オーケストレーションのフレームワークを問わず使えるとされます。インフラを持たずNimble APIから直接動かすこともでき、大企業向けにはMicrosoft、Oracle、Snowflakeと組み、自社インフラ内へのデプロイも用意すると説明しています。
なぜ重要か——ボトルネックが「推論」から「検索」に移った
Nimbleの主張の核心は、汎用検索APIの構造的な非効率にあります。汎用APIは幅広いファイル群を返し、どれが関連するかの判断を言語モデルに丸投げする。結果として検索を何度も繰り返し、余計な推論が走り、トークンが積み上がる。つまりモデルが考え始める前の段階でコストとレイテンシが膨らんでいる、という指摘です。
これは「基盤モデルが賢くなるほど、勝負どころが検索・オーケストレーション・メモリ・可観測性・ガバナンスに移る」という業界全体の流れと一致します。Nimbleが自らをChatGPT Deep ResearchやGoogle Gemini Deep Research、Perplexity、AlibabaのTongyi DeepResearch、Sakana Marlinと同じ土俵ではなく、その一段下のインフラ層に置いているのはそのためです。実際の競合はOpenAIやGoogleの研究アシスタントではなく、ExaやTavilyといった開発者向け検索インフラだと記事は整理しています。
「Harness as a Tool」と自己学習の仕組み
今回の目玉としてNimbleが打ち出したのが「Harness as a Tool」という概念です。検索API、ブラウザ自動化、抽出パイプライン、検証ロジック、メモリ、オーケストレーションのコードを、マネージドな一つのインターフェースの裏側にまとめる。何を検索するかを決め、通常のインデックスで足りなければページを操作し、情報を抽出し、結果を検証し、後続エージェントが使える形式で最終コンテキストを返す——これらを利用側が組まずに済ませるという設計です。
CEO兼共同創業者のUri Knorovich氏は「一つの汎用検索モデルではなく、顧客のドメインごとに特化した検索モデルを作る」と述べ、最適化は顧客側のセットアップなしに「2回目の検索から始まる」と説明しています。1社で数百のエージェントを動かし、それぞれが固有のドメイン知識・ガードレール・目的・検索アルゴリズムを持つ形です。同氏が「最大の研究上のブレークスルー」と呼ぶのが、セマンティックメモリとキャッシュ層の追加でした。
ガバナンス面では、設計上ゼロデータ保持であり顧客のクエリを自社環境に保存しない、セマンティックメモリと自己学習モデルの知識は顧客自身のテナントに残る、と明言しています。エンタープライズ導入の実務では、この一文が精度の数字より効くことが少なくありません。
数字の読み方
同社はインフラがFortune 500やAI-native企業を含めて1日9,000万件超の検索を支えているとしています。Roxが報告したトークンコスト20分の1という数字は目を引きますが、詳細なワークロード計測も再現可能なベースラインも開示されていません。21%・51%と同様、ベンダー提示値として扱うのが妥当です。
用途としては、投資銀行のアナリスト業務、プロダクトマネージャー向けの競合調査エージェント、GTMリサーチ、報道モニタリング、保険、ライフサイエンス、サプライチェーン最適化などが挙がっています。手作業で保守するスクレイピングのロジックではなく、自然言語の記述でカスタム検索エージェントを組める点も特徴とされます。
💼 事業会社視点：これは自社にどう効くか
日本企業にとっての実務的な論点は「精度21%」より「トークン51%削減」の側です。AI機能を載せたSaaSやECの事業責任者が直面しているのは、原価が使用量に連動して膨らみ粗利が読めない構造で、その膨張の大半はモデルの推論ではなく、関連しないページを何度も取りに行く検索工程で発生しています。まずは自社エージェントのトークン消費を「検索・取得」と「推論」に分解して計測することを勧めます。分解できていなければ、どのベンダーの数字も評価できません。
受託開発・SIerにとっては、スクレイピングと抽出パイプラインの構築・保守という受注領域が、マネージドな基盤に吸収されていく方向の話です。工数で売る発想から、顧客ドメインごとの検証ロジックや業務要件の設計で売る発想への転換が要ります。
一方で、Nimbleの21%・51%もRoxの20分の1も、方法論と比較対象が非開示です。稟議に生の数字を持ち込むのは危険で、自社の代表的なクエリ50件程度で現行構成と並走比較し、月2,500ドルからのマネージド契約が自社の検索量で回収できるかを検証してから判断すべきです。MCP対応なので、既存構成を壊さず差し替え評価しやすい点は追い風になります。
