RustXNGとは何か――ローカル検索エンジンがAIエージェントの経済性を変える可能性

 

RustXNGとは何か――ローカル検索エンジンがAIエージェントの経済性を変える可能性

この投稿の核心は、AIエージェントがWebを検索するたびに発生するAPI従量課金を、ローカルで動く検索基盤によって削減できるのではないかという点です。

単なる検索エンジンの高速化ではありません。DeepSeek Harness、HermesAgent、OpenClawのようなエージェント基盤を複数並列で動かす場合、検索APIの費用とレート制限がボトルネックになります。

RustXNGが注目されるのは、SearXNG互換のインターフェースを維持しながら、Rustによる軽量な実装と検索品質の両立を目指している点です。

ただし、投稿にある「Exaに迫る精度」は現時点では開発者側の主張として扱い、独立したベンチマークで確認する必要があります。

1. 仕組み:検索APIではなくメタ検索エンジン

RustXNGは、ゼロからWeb全体をクロールして検索インデックスを作るGoogle型検索エンジンではありません。

基本構造は次のとおりです。

          AIエージェント
       (DeepSeek / Hermes)
                |
                v
        RustXNG API
         localhost
                |
       +--------+--------+
       |        |        |
       v        v        v
     Bing     Brave    Wikipedia
       |        |        |
       +--------+--------+
                |
                v
          結果を統合
          重複排除
          関連度ランキング
                |
                v
        上位ページ本文取得
                |
                v
          AIに返却

主な特徴は以下です。

機能

内容

実装言語

Rust

検索エンジン

SearXNG由来の226種類

並列検索

複数エンジンを同時実行

API

SearXNG互換

出力

JSON / CSV / RSS

本文取得

上位5ページ、約32,000文字

キャッシュ

繰り返し検索を高速化

セキュリティ

SSRF対策、公開IPへの接続制限

つまり、AIエージェント側から見ると、検索サービスを呼び出すための共通インターフェースになります。[1][2]

2. Exaに迫る精度という主張の意味

ここが技術的に面白いところです。

開発者が公開している100問のベンチマークは次のとおりです。

指標

RustXNG

Exa

Tavily

hit@1

79~83

77

34

hit@5

92~96

91

79

MRR

0.853~0.889

0.840

0.514

費用

$0

有料

$8/1,000回

出典:RustXNG公開README。開発者による評価結果であり、独立検証済みの性能比較ではありません。[1]

指標の意味も重要です。

  • hit@1:正解ページが検索結果の1位に来た割合。

  • hit@5:正解ページが上位5件に入った割合。

  • MRR:正解ページが何位に現れるかを評価する指標。上位ほど高得点。

ただし、この数字だけでExaと同等の検索能力があるとは判断できません。

特に確認したいのは次の点です。

  1. 100問の選定方法に偏りはないか。

  2. 日本語検索でも同等の結果が出るか。

  3. 新着情報・ニュースの検索に強いか。

  4. 正解ページが存在しない検索への対応はどうか。

  5. 検索エンジンの障害やCAPTCHA発生時に品質がどれほど低下するか。

また、Google検索が利用できないビルドでの測定であることも重要です。

3. 本当に検索APIの課金をゼロにできるのか

ここは誤解しやすい部分です。

API利用料を削減できる

ただし、完全な意味での無料Web検索ではありません。

RustXNGは検索先のWebサービスに問い合わせます。

したがって、次のコストは残ります。

  • 検索エンジン側のアクセス制限

  • CAPTCHAや403による検索失敗

  • サーバーの電気代・通信費

  • 自前インデックスを作る場合のストレージとクロール費用

  • 外部サービス側の仕様変更への追従

特に重要なのがプライバシーです。

RustXNG自体はローカルで稼働しますが、通常のメタ検索では検索語が各検索エンジンに送信されます。

つまり、ローカル実行=検索情報が外部に出ない、ではありません。 [3]

4. 実はもっと面白い機能:ローカルインデックス

RustXNGには独自のローカル検索インデックスもあります。

これは通常のメタ検索とは別の仕組みです。

  • Webページを自分でクロールする。

  • ページを全文検索用に索引化する。

  • BM25で関連度を計算する。

  • 外部検索結果にローカル検索結果を追加する。

面白いのは、開発者自身が実験結果から、ローカル検索だけで即答する方式を推奨しなかったことです。

構成

hit@1

hit@5

MRR

外部検索のみ

79

92

0.853

5,000ページ併用

83

96

0.889

ローカル即答

72

82

0.765

つまり、ローカル検索だけでは情報量が不足する一方、外部検索の取りこぼしを補完すると性能が改善したという結果です。[2]

これはRAGの設計にも通じる話です。

5. DeepSeek Harness・HermesAgentとの組み合わせ

個人的には、ここが最大の注目点です。

          AIエージェント
       DeepSeek / Hermes
                |
         タスク分解
                |
       +--------+--------+
       |        |        |
       v        v        v
     Agent A  Agent B  Agent C
       |        |        |
       +--------+--------+
                |
                v
           RustXNG
                |
       +--------+--------+
       |        |        |
       v        v        v
     ニュース   論文    GitHub
       |        |        |
       +--------+--------+
                |
                v
          情報を統合
                |
                v
          ローカルLLM
                |
                v
          レポート作成

例えば、株式市場の調査エージェントを考えます。

  1. Agent A:企業の決算資料を検索。

  2. Agent B:競合企業のニュースを検索。

  3. Agent C:GitHubで関連技術を調査。

  4. Agent D:論文・特許を検索。

  5. メインエージェント:結果を統合して投資仮説を作成。

このとき検索インフラを共通化できれば、エージェントごとに個別の検索API契約を結ぶ必要がなくなります。

ただし、同時アクセスによる検索先のレート制限は残ります。RustXNG自身にもレート制限やエンジン休止機能があります。[1][3]

6. RX 9070 XT搭載PCで使う価値はあるか

現在のWindows 11環境なら、ローカルLLMとは別の軽量サービスとして動かす構成が考えられます。

項目

構成

OS

Windows 11 + WSL2またはDocker

GPU

RX 9070 XT

RAM

32GB

検索

RustXNG

LLM

ローカルLLMまたはクラウドAPI

接続

localhost:8888

エージェント

HermesAgent等

RustXNGの検索処理自体に高性能GPUは必要ありません。Rust製のCPU中心のサービスです。

したがって、GPUのVRAMをLLMに集中させられます。

注意点として、公開されている導入例にはLinux向けバイナリが中心のものもあるため、WindowsではWSL2/Docker経由をまず検討するのが現実的です。

7. 私の評価:検索APIの代替以上の意味がある

このプロジェクトの本質は、AIエージェントのインフラを分解して再構成することにあります。

従来のエージェント運用では、

  • 推論:LLM API

  • 検索:検索API

  • ページ取得:別のAPI

  • 埋め込み:Embedding API

  • 保存:外部データベース

というように、各機能が独立した従量課金サービスになりがちでした。

RustXNGは、そのうち検索・情報取得層をセルフホスト化しようとしています。

これは、以前から注目しているGPU経済圏の問題とも対照的です。

GPU計算資源の供給が集中・寡占化する一方、検索・情報取得のような周辺インフラはOSSによってコモディティ化する可能性があります。

AIエージェントの競争力は、必ずしも巨大なモデルを所有することではなく、安価な計算資源と情報取得基盤をどれだけ効率よく組み合わせられるかで決まる。

ただし、RustXNGはまだ発展途上のOSSです。100問の検索ベンチマークだけで商用サービスを全面代替できると判断するのは早いでしょう。

確認しておきたい一次資料

  1. RustXNG GitHub(本体・導入方法)

  2. BENCHMARK.md(測定条件・再現方法)

  3. AI-INFRA.md(AIエージェント向け設計思想)

  4. CHANGELOG(2026年11月1日現在の開発状況)

次に掘り下げる価値があるのは、RustXNG+DeepSeek Harness+HermesAgentをWindows 11上で統合し、検索API費用を極小化するローカル・クラウド混成エージェントの設計です。


RustXNGに至るまでの歴史――Web検索からAIエージェントの情報取得基盤へ

RustXNGの誕生を理解するには、Web検索エンジンの歴史を「検索対象の拡大」だけでなく、検索コスト・情報の分散化・AIによる情報取得の自動化という3つの流れから見る必要があります。

以下、技術的な系譜を時系列で整理します。

1. Web検索エンジンの誕生と発展

1. 1990年:Archieの登場

  • インターネット上のFTPファイルを検索する初期の検索システム。

  • Webが一般化する前から、ネットワーク上の情報を索引化する試みが始まっていた。

2. 1993年:ALIWEB

  • Webページを対象とした初期の検索インデックス。

  • Webサイト管理者が自らインデックス情報を登録する方式だった。

3. 1994年:Yahoo! Directory

  • 人間がWebサイトを分類・整理するディレクトリ型検索。

  • 情報量の増加に伴い、人手による分類の限界が明らかになる。

4. 1994年:WebCrawler

  • Webページ全文を検索できる初期の検索エンジン。

  • クローラーによる自動収集と全文検索が本格化する。

5. 1995年:AltaVista

  • 大規模なWebインデックスと高速検索を実現。

  • 検索エンジンがインターネットの主要な情報インフラへ発展する。

6. 1998年:Google

  • PageRankによってリンク構造を利用したランキングを導入。

  • 単純なキーワード一致から、Web上の関係性を使った関連度評価へ進化した。

7. 2000年代:検索プラットフォームの寡占化

  • Google、Yahoo!、Bingなどが検索市場を形成。

  • 大規模クローリング、インデックス、ランキングの構築には膨大な設備投資が必要になった。

2. メタ検索と分散型検索の登場

8. 1995年:MetaCrawler

  • 複数の検索エンジンに同時に問い合わせ、その結果を統合するメタ検索の代表例。

  • 自前で巨大な検索インデックスを持たず、既存の検索サービスを組み合わせる発想。

9. 2000年代:メタ検索の普及

  • Dogpileなどが複数の検索エンジンを横断する検索を提供。

  • 検索サービスごとの得意分野や検索結果の違いを活用する方向へ進んだ。

10. 2009年:DuckDuckGoの登場

  • プライバシー重視の検索サービスとして成長。

  • 単一の検索サービスへの依存を避ける選択肢が広がる。

11. 2014年:Searxの登場

  • オープンソースのメタ検索エンジン。

  • 複数の検索エンジンを横断し、ユーザー自身が検索環境を管理できる設計。

  • 検索サービスのセルフホストという考え方を普及させた。

12. 2021年:SearXNGへの発展

  • Searxのフォークとして開発が進む。

  • メンテナンス、検索エンジン対応、セキュリティ、設定管理などを改善。

  • 現在もセルフホスト型メタ検索の代表的なOSSの一つ。

3. AIエージェント時代と検索インフラの再設計

13. 2015年:Rust 1.0安定版

  • Mozillaが支援していたRustが安定版として公開される。

  • メモリ安全性と実行性能を両立するシステムプログラミング言語として普及。

  • 後のRustXNGがRustを採用する技術的背景の一つ。

14. 2020~2022年:RAGにつながる技術の発展

  • ベクトル検索、Embedding、意味検索が発展。

  • 単純なキーワード検索だけでなく、文書の意味的な近さを利用する検索が普及。

  • 外部知識をLLMに与えるための技術的基盤が形成される。

15. 2022年:ChatGPT登場

  • LLMが一般ユーザーにも普及。

  • しかし、モデル内部の学習データだけでは最新情報や個別の事実を十分に扱えないという問題が顕在化。

  • Web検索とLLMを組み合わせる必要性が高まる。

16. 2023年:Tool UseとAIエージェントの発展

  • LLMが検索、ブラウザ、コード実行などの外部ツールを利用する仕組みが広がる。

  • 検索は人間が一度実行する操作から、AIがタスクの途中で何度も実行する処理へ変化。

  • 検索APIの料金とレート制限がエージェント運用上の問題になる。

17. 2023~2024年:Tavily・ExaなどのAI向け検索サービスの台頭

  • 従来型検索結果を返すだけでなく、AIが理解しやすい形式で検索結果や本文を返すサービスが成長。

  • 検索結果のランキング、本文抽出、情報のグラウンディングが重要になる。

  • 一方、API利用回数に応じた課金が発生する。

18. 2024~2025年:自律型エージェントの普及

  • マルチエージェント、Deep Research、コード実行型エージェントが発展。

  • 1回の質問に対して数十回、場合によってはそれ以上の検索を行う構成が一般化。

  • 検索APIの従量課金が、エージェントの運用コストを左右するようになる。

19. 2025~2026年:セルフホスト型AIインフラへの関心

  • ローカルLLM、Ollama、MCP、RAG、ローカルデータベースなどの組み合わせが進展。

  • 推論だけでなく、検索・情報取得・記憶・ツール実行も自前で管理する方向へ。

  • 検索サービスについても、API依存を減らす必要性が高まる。

4. RustXNGの誕生と急速な進化

20. 2026年10月18日:RustXNG 0.1.0公開

  • SearXNGの動作をRustに移植するプロジェクトとしてスタート。

  • !engine、:langなどの検索構文、結果の重複排除、ランキングなどを実装。

  • SearXNG互換のメタ検索エンジンを単一バイナリで動かす構想が出発点。[1]

21. 2026年10月18日:SearXNG互換性の強化

  • JSON、CSV、設定ファイルの形式を上流に合わせる。

  • SearXNGの既存クライアントとの互換性を重視。

  • 既存の検索インフラから移行しやすい基盤を整備。

22. 2026年10月24日:226種類のエンジン移植完了

  • 上流SearXNGの352エントリーに対応する226種類のエンジンを実装。

  • ニュース、画像、学術論文、動画、開発者向け検索などに対応。

  • 単なるRust製の検索プロトタイプから、幅広い検索用途を扱う基盤へ発展。[1]

23. 2026年10月26~29日:検索品質の測定と改善

  • SearXNGとの互換性を実測。

  • Tavilyなどの商用検索APIとの比較を開始。

  • AIエージェント向けに検索結果の件数制限、ドメイン指定、本文取得機能を追加。

  • 20問の評価セットを使ったベンチマークを整備。

24. 2026年10月30日:ランキングアルゴリズムの改善

  • 公式ドメインや正規ページを優先するランキングを追加。

  • ミラーサイトやトップページが具体的なドキュメントより上位に来る問題を改善。

  • 20問の測定でExaを一部指標で上回る結果を記録。

25. 2026年10月31日:Yahoo! JAPAN検索の追加

  • 日本語検索に強いYahoo! JAPANを独自エンジンとして追加。

  • 日本語検索の精度改善に取り組む。

  • 英語中心の検索エンジンを束ねるだけではなく、日本語環境に合わせた独自開発へ進む。

26. 2026年10月31日:自前の全文検索インデックスを実装

  • rustxng-indexを追加。

  • クロール、インデックス作成、ローカル検索を実装。

  • 外部検索エンジンに依存しない検索経路を実験的に構築。

  • BM25による全文検索を導入。

27. 2026年10月31日:ローカル検索と外部検索の統合

  • 自前インデックスを外部検索と統合する方式を検証。

  • 5,000ページのインデックス併用でhit@1が79から83、hit@5が92から96に改善したと報告。

  • ただし、インデックスを増やせば精度が単調に上がるわけではないことも判明。

28. 2026年10月31日:検索エンジンの休止・復旧機構

  • 403、429、CAPTCHA、タイムアウトなどに対応。

  • 応答しない検索エンジンを一時休止する仕組みを追加。

  • 一部エンジンへのプロキシ設定も可能にする。

  • 多数の検索先を束ねることによる運用上の問題を改善。

29. 2026年11月1日:AIエージェント向け基盤への転換

  • SSRF対策を強化。

  • 検索結果から取得するページ本文について、公開IPアドレスへの接続制限を実装。

  • READMEの位置づけを「SearXNGのRust版」から「ローカルAIエージェントの検索・Grounding層」へ変更。

  • Dockerイメージの公開を開始。[1][2]

5. 技術史として見たRustXNGの位置

ここまでの歴史を整理すると、検索技術は次のように進化してきました。

世代

代表的技術

中心的な課題

第1世代

Archie、WebCrawler

情報を発見する

第2世代

Google、Yahoo!

巨大な情報をランキングする

第3世代

MetaCrawler、SearXNG

複数の検索源を統合する

第4世代

Exa、Tavily

AIが利用できる情報を取得する

第5世代

RustXNG

AIの情報取得基盤をセルフホストする

6. 最も重要な歴史的転換

私が注目するのは、検索エンジンの競争軸が変わってきたことです。

かつての検索エンジンの価値は、人間に最適な検索結果を表示することでした。

しかしAIエージェントでは、検索結果を人間が読む必要はありません。

必要なのは、

  1. 検索結果を機械可読形式で返す。

  2. 正しいページを上位に配置する。

  3. ページ本文を自動取得する。

  4. 情報の出典を保持する。

  5. 何十回検索してもコストが膨らみにくい。

  6. エージェントが悪意あるURLを取得しないよう保護する。

という機能です。

ここでRustXNGの登場は象徴的です。

Googleが人間のために最適化した検索インフラを、AIエージェントが直接利用する情報取得インフラへ再構成する動きと捉えられます。

ただし、RustXNGはGoogleやExaのような独自の巨大Webインデックスを持つ検索企業ではありません。外部検索エンジンを統合しつつ、自前インデックスを補助的に利用するOSSです。

また、API利用料を抑えられる可能性はありますが、外部検索エンジンの利用規約、アクセス制限、通信コストは残ります。

参考資料

さらに一段深い論点は、検索インフラのコモディティ化です。 LLMの推論能力が高まるほど、競争優位はモデル単体から、安価な検索・取得・記憶・検証を組み合わせるエージェント・オーケストレーションへ移る可能性があります。RustXNGは、その情報取得層をOSS化する試みと位置づけられます。

コメント

このブログの人気の投稿

Too Big To Fork:AI時代のLinuxとデジタル公共財の終焉 #TooBigToFork #Linux #AI #七18 #1991九17LinuxとOSSプロジェクト_平成IT史ざっくり解説

複数のRSSFeedを一つのURLにまとめる・統合する方法 #士30 #1999RSS_RDF・SiteSummary_平成IT史ざっくり解説

#INVIDIOUSを用いて広告なしにyoutubeをみる方法 #士17 #2018INVIDIOUSとOmarRoth_令和IT史ざっくり解説