mcp-searxng を採用する前に読む: SearXNG 経由で AI に検索させる MCP サーバー
Private web search for AI assistants via SearXNG — supports Claude, Cursor, and any MCP client
ひと目でわかる
- これは何？
- Claude や Cursor などの MCP クライアントに SearXNG 経由の検索と URL 読み取りを追加する Node.js 製サーバー。検索ベンダーの API キーを必要としない代わりに、SearXNG インスタンスの運用と、キャッシュや SSRF 対策といった設定項目を自分で把握しておく必要がある。
- 誰に向いている？
- 採用を検討すべきなのは、SearXNG インスタンスを自分で運用しているか、信頼できる運用元のインスタンスを指定できるチームである。検索ベンダーの API キーを管理したくない、あるいは検索クエリを外部ベンダーに渡したくないという動機が明確な場合に噛み合う。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このサーバーが埋めるのは「検索ベンダーを選ばない」という一点
AI アシスタントに検索させようとすると、通常は検索ベンダーの API キーを取得し、その利用規約とログ保持方針を受け入れることになる。mcp-searxng はその部分を SearXNG に置き換える。SearXNG は複数の検索エンジンの結果を集約するメタ検索エンジンで、自前でホストできる。README の比較表は 2026-07-29 時点の Brave MCP、Exa MCP、Firecrawl MCP と自プロジェクトを並べ、自ホスト可能かつ検索ベンダーの API キーが不要なのは mcp-searxng だけだとしている。ただし表の注記にもある通り、無料なのは MCP サーバー側であって、その下で動く SearXNG インスタンスは自分で運用するか、誰かのものを選ぶ必要がある。対象読者は、社内や個人で SearXNG をすでに動かしている人、あるいは検索クエリの経路をベンダーに預けたくない人である。
プロセス分離された MCP サーバーという構成
README の「How It Works」は、mcp-searxng をスタンドアロンの MCP サーバー、つまり AI アシスタントが検索のために接続する別の Node.js プロセスだと説明している。アシスタント側に検索機能が組み込まれるのではなく、MCP クライアントが設定ファイルに書かれたコマンドを起動し、そのプロセスとツール呼び出しでやり取りする。ツールとしては検索、URL 本文の読み取り、SearXNG の /autocompleter を使ったサジェスト、/config からのインスタンス能力の取得が用意されている。検索は一般・ニュース・記事のクエリに対応し、ページネーション、時間範囲、言語、セーフサーチのフィルタ、min_score による関連度足切りを指定できる。応答形式は呼び出しごとの response_format か、運用側の既定値 SEARXNG_DEFAULT_RESPONSE_FORMAT で整形テキストと生 JSON を切り替える。
セットアップは JSON 1 ブロックから始まる
導入手順は README の Quick Start にある通り、MCP クライアントの設定（例として claude_desktop_config.json）に次のブロックを足すところから始まる。command に npx、args に ["-y", "mcp-searxng"] を指定し、env の SEARXNG_URL に自分の SearXNG インスタンスの URL を入れる。SEARXNG_URL にはセミコロン区切りで互換レプリカを複数書ける。既定では順番にフェイルオーバーし、SEARXNG_FANOUT を設定すると健全なレプリカすべてに並列で問い合わせて結果をマージする。クライアント別の設定例は docs/client-configurations.md に、Claude Desktop、Claude Code、Codex CLI、Cursor、VS Code、Windsurf、Cline、OpenCode 向けのレシピとしてまとまっている。調査用途の進め方は docs/research-workflow.md、プロセスの CPU とメモリの目安は docs/deployment-profiles.md にある。
公開インスタンスが JSON を拒む場合の逃げ道
SearXNG の公開インスタンスには format=json を拒否する設定のものがある。この場合の選択肢として README は HTML フォールバックを挙げている。結果一覧の HTML ページを解析して検索結果を取り出す機能で、オプションとして有効化する。つまり JSON API が使えるインスタンスを選べるなら不要だが、使えないインスタンスしか当てにできない場合はこの経路に頼ることになる。読み取り側では Content-Type を意識した Markdown 変換が行われ、PDF のテキスト抽出も範囲を限定して行う。ページネーション、セクション絞り込み、段落範囲の指定、見出し抽出に対応する。検索結果と URL 本文の両方はメモリ上にキャッシュされ、TTL と LFU ベースの退避で重複リクエストを減らす。
ブラウザソルバー連携は「取得できる URL」を広げるが、失敗の形も増やす
静的 URL 検証と HEAD によるサイズ事前チェックを通過した未キャッシュ URL について、任意で FlareSolverr や Byparr からブラウザセッションを取得し、返された user-agent とスコープ付き cookie を URL リーダーに引き渡して再取得する。両方を設定した場合、FlareSolverr が常に第一候補で、Byparr は第一候補がビジーか一時的に利用不可のときだけ試される。README は FlareSolverr 3.5.0 と Byparr 2.1.0 を 2026-07-30 に検証したとし、linux/amd64 のイメージをマニフェストのダイジェスト付きで示している。注意点も同じ節に書かれている。クライアントがキャンセルするとローカル処理は速やかに止まるが、リモートのブラウザは HTTP クライアントが切断した後も、プロバイダ側に設定されたタイムアウトまで動き続ける可能性がある。ブラウザソルバーを足すほど、検索経路の構成要素と監視対象が増える。
SSRF ブロックと HTTP トランスポートは運用側の設計判断
web_url_read はすべてのトランスポートモードで、既定によりプライベートおよび内部向け URL とリダイレクトをブロックする。AI に任意の URL を読ませる構成では妥当な既定だが、社内ドキュメントの URL を読ませたい場合にはそのままでは弾かれる。HTTP トランスポートは任意で有効化する MCP SDK v2 の Streamable HTTP モードで、ハードニング、レート制限、ステートレス互換の範囲を指定できる。サーバーレスや水平スケールの配置を想定した作りである。コンテキストの小さいローカルモデル向けには、ツールスキーマを最小限にした Lite Tools Mode がある。検索と URL 読み取りの通信には、グローバルまたはツール単位で HTTP/HTTPS プロキシを指定できる。
「プライバシー」が意味する範囲を読み違えない
このプロジェクトの利点として最も誤解されやすいのがプライバシーの部分である。README 自身が、プライバシーは SearXNG の配備方法に依存すると書いている。運用者が管理するインスタンスなら第三者の検索事業者を信頼せずに済むが、公開インスタンスはクエリを受け取り、ログに残す可能性がある。そして SearXNG とこの MCP 統合それ自体は匿名性を提供しない、と明記されている。つまり mcp-searxng を入れただけで検索が秘匿されるわけではない。検索ベンダーの API キーが不要で、クエリの経路を自分で選べるという話であって、匿名検索の話ではない。ここを取り違えると、導入後の期待値がずれる。
向いている構成と、別の道具を選ぶべき構成
代替として README の比較表が挙げているのは Brave MCP、Exa MCP、Firecrawl MCP である。表の読み方で差が出るのは自ホストの列と API キーの列だ。Brave MCP と Exa MCP は自ホスト不可、Firecrawl MCP は部分対応とされている。URL 読み取りの列では Brave MCP が非対応、Exa MCP と Firecrawl MCP が対応する。つまり検索とページ取得をマネージドなサービスに任せ、SearXNG インスタンスの面倒を見たくないなら、この構成を選ぶ理由は薄い。逆に、すでに SearXNG を運用していて、検索結果の取得経路をベンダーに依存させたくないなら、設定は JSON 1 ブロックで済む。ライセンスは MIT で、npm パッケージとして配布され、Docker イメージも公開されている。MIT なので改変や再配布の制約は緩いが、同梱・再配布時の表示義務など具体的な条件は配布物の LICENSE を確認する必要がある。ここは法的助言ではない。バージョンは v2.0.0、v2.1.0、v2.2.0 と短い間隔で上がっており、追従にはそれなりの頻度で設定とドキュメントを見直す前提が要る。
編集部の結論
採用を検討すべきなのは、SearXNG インスタンスを自分で運用しているか、信頼できる運用元のインスタンスを指定できるチームである。検索ベンダーの API キーを管理したくない、あるいは検索クエリを外部ベンダーに渡したくないという動機が明確な場合に噛み合う。逆に、SearXNG を立てる手間をかけたくない、あるいは公開インスタンスをそのまま使うつもりの場合は、この構成の利点はほとんど残らない。導入前に確認すべきは、対象インスタンスが format=json を受け付けるかどうか、SEARXNG_URL にセミコロン区切りで複数レプリカを書いた場合のフェイルオーバー順、そして web_url_read の SSRF ブロックが自分の用途で邪魔にならないかである。README には公開インスタンスがクエリを記録しうるという但し書きがあり、SearXNG とこの統合自体は匿名性を提供しないと明記されている。
コミュニティノート