wigoloでAIエージェントにWeb検索を無料で追加する

Claude Code や Cursor にリアルタイムの Web 情報を渡したいとき、真っ先に候補に上がるのが Tavily などの有料検索 API です。
でも「プロトタイプ段階でまだ課金したくない」「API キーの管理を増やしたくない」という場面は意外と多い。

そんなときに試す価値があるのが wigolo です。
ローカルで動く MCP サーバーで、API キーなしに Web 検索・フェッチ・クロールをエージェントに渡せます。

実際に動かしてみて気づいたのは、「無料で動く」という事実よりも「どこまで使えて、どこで限界が来るか」を事前に把握しておくことの大切さでした。
その判断材料を、セットアップの具体的な手順と合わせてまとめます。

wigolo とは何か――API キー不要のローカル MCP 検索サーバー

wigolo は単一の Node.js プロセスとして動く MCP サーバーです。
search / fetch / crawl / extract / cache / find-similar など 10 個のツールを MCP 経由でエージェントに提供します。

「API キー不要」が成立する理由は設計にあります。
ブラウザエンジンとオンデバイスモデルをローカルにダウンロードして動かす構成なので、外部のクラウドサービスに問い合わせる必要がありません。
Tavily のような有料 API は「クラウド上の検索インフラに問い合わせる」モデルですが、wigolo は「自分のマシン上でブラウザを動かして取ってくる」モデルです。
設計思想のレベルで別物と考えると分かりやすい。

ただし、これにはトレードオフが伴います。
初回インストール時にブラウザエンジンとモデルのバイナリを約 1.5 GB ダウンロードします。
その後の検索処理もローカルで走るので、マシンのスペックが低いと遅さを感じる場面があります。
また、research ツールのように「複数ページを横断して回答を合成する」機能は内部で LLM を使うため、LLM のキーを別途設定しないと品質が落ちます（この点は後の節で詳しく触れます）。

公式サイトには「wigolo is free and meant to stay that way」と書かれており、現時点では有料化の予定はないようです。
ただし現在は 公開ベータ の段階なので、仕様変更や不安定な挙動が起きる可能性は念頭に置いておく必要があります。

セットアップ：インストールから MCP 接続設定まで

前提条件は Node.js 20 以上と約 1.5 GB の空きディスクだけです。
macOS・Linux・Windows のいずれでも動きます。

インストールと動作確認

まず以下のコマンドでエンジンをインストールします。
--agents に使っているクライアントを指定すると、MCP 設定ファイルへの書き込みまで自動でやってくれます。

# Claude Code に自動接続する場合
npx wigolo init --agents=claude-code

# Cursor に自動接続する場合
npx wigolo init --agents=cursor

# 複数クライアントを同時に指定する場合
npx wigolo init --agents=claude-code,cursor

インストールが終わったら、公式が案内している health check コマンドでエンジンの状態を確認します。
ブラウザエンジン・オンデバイスモデルそれぞれのステータスが表示されます。
具体的なコマンド名は公式ドキュメントで確認してください（公開ベータ中は変わる可能性があります）。

ここで問題が出るとしたら、Node のバージョンが古いか、ディスク容量が足りていないケースがほとんどです。
node --version で 20 以上になっているかを確認してから実行するのが無難です。

Claude Code への手動接続

--agents=claude-code を指定してインストールすれば自動設定されますが、手動で追加したいときは CLI コマンドを使います。

claude mcp add wigolo --scope user -- npx -y wigolo

--scope user を付けるとユーザー全体に適用されます。
プロジェクトごとに分けたい場合は --scope project に変えてください。

Cursor への手動接続

Cursor は mcp.json に直接記述します。
ファイルの場所はプロジェクトルートの .cursor/mcp.json です。

{
  "mcpServers": {
    "wigolo": {
      "command": "npx",
      "args": ["-y", "wigolo"]
    }
  }
}

これだけです。
Cursor を再起動すると wigolo が MCP サーバーとして認識されます。

実際に使ってみて分かった検索品質の現実

静的な HTML ページへの fetch と search は、想像より素直に動きます。
ドキュメントサイトや GitHub の README、ニュース記事のような「サーバーサイドでレンダリングされたページ」なら、コンテンツをきれいに取ってこられます。
速度も体感的には許容範囲で、単純な fetch なら数秒以内に返ってくることが多い。

一方で、JavaScript に依存した SPA（シングルページアプリケーション）は苦手です。
React や Vue で構築されたダッシュボードや、ログイン後にコンテンツが展開されるようなページは、ブラウザエンジンがレンダリングを待ちきれずに空のボディを返すことがあります。
wigolo はヘッドレスブラウザを使っているので原理的には JS レンダリングに対応しているはずですが、実際には動的なコンテンツの取得精度にムラがあります。
公開ベータという現在地を考えると、ここは今後改善される余地がある部分です。

クロール深度にも現実的な限界があります。
複数ページをたどって情報を集める crawl ツールは、ページ間のリンク構造が複雑だったり、ページ数が多かったりすると途中で止まることがあります。
「サイト全体を丸ごとインデックスする」用途には向いていません。

キャッシュ挙動は便利な面もあります。
一度取得したページは内部でキャッシュされるので、同じ URL への繰り返しアクセスは速くなります。
ただし、キャッシュが古い情報を返してくることもあるので、鮮度が重要な調査には注意が必要です。

もう一点、正直に書いておきたいのが research ツールの品質です。
research は複数ページの情報を横断して LLM が回答を合成する機能ですが、LLM のキーを設定していない状態では合成品質が大きく落ちます。
「ページを取ってくる」部分は API キーなしで動きますが、「取ってきた情報をまとめて答えを作る」部分には LLM が必要です。
キーなしで research を試すと、断片的な情報の羅列になりがちです。

Gemini キーを足して research ツールを使う

research ツールの品質を上げる最も手軽な方法は、LLM の API キーを1つ設定することです。
公式ドキュメントでは Gemini の無料キーが「最大の品質向上策」 として推奨されています。
Google AI Studio でアカウントを作れば、無料枠で Gemini のキーを取得できます。

キーの設定方法は、プロバイダーとキーの2つをセットで指定する形です。
具体的な環境変数名や設定ファイルのキー名は公開ベータ中に変わる可能性があるため、実際に設定する際は公式の設定ガイドを参照してください。

Cursor などの mcp.json で管理する場合は、mcpServers の該当エントリに env ブロックを追記してプロバイダーとキーを渡す形になります。
設定例のひな形はこうなります。

{
  "mcpServers": {
    "wigolo": {
      "command": "npx",
      "args": ["-y", "wigolo"],
      "env": {
        "（プロバイダー指定の変数名）": "gemini",
        "（キー指定の変数名）": "your-gemini-api-key-here"
      }
    }
  }
}

変数名の正確な綴りは公式ドキュメントで確認してから埋めてください。

Gemini 以外にも Anthropic・OpenAI・Groq を選べます。
すでに持っているキーがあればそちらを使えばいい。

完全にオフラインで使いたい場合は Ollama が選択肢に入ります。
Ollama をローカルで起動した状態でプロバイダーを ollama に設定すれば、外部ネットワークに一切依存しない構成が作れます。
ただし、Ollama で動かせるモデルの品質は商用 API に比べると落ちるので、research ツールの精度も相応に下がります。

キーを足す前後で research ツールを同じクエリで試してみると、回答の密度がはっきり変わります。
「無料キーを1つ追加するだけ」でここまで変わるなら、設定しない理由はほとんどありません。

wigolo で十分なケースと、有料 API に切り替えるべきケース

「最初は wigolo で試して、精度が足りなければ切り替える」という段階的なアプローチが現実的です。
セットアップコストが低いので、まず動かしてみて判断するのが一番早い。

wigolo が向くケース：

コストをかけずに Web 検索機能を試したい（プロトタイピング・個人開発）
静的サイトやドキュメントサイトが主な調査対象で、JS ヘビーなページはほとんど出てこない
オフライン環境や閉じたネットワーク内でエージェントを動かしたい（Ollama 構成）
API キーの管理を増やしたくない、あるいは外部サービスへのデータ送信を避けたい

有料 API（Tavily など）が向くケース：

調査精度が成果物の品質に直結する業務用途で、検索の失敗が許容できない
JavaScript で動的に生成されるページや SPA が調査対象に多く含まれる
本番のエージェントに組み込んで安定稼働させたい（SLA や再現性が重要）
チームで使う場合に、動作の一貫性や管理のしやすさを優先したい

「どちらか一方に決める」必要はありません。
たとえば、開発中のエージェントは wigolo で動かして検証し、本番リリース時に Tavily に切り替えるという使い方は理にかなっています。
MCP の設定を差し替えるだけなので、移行コストも低い。

wigolo はまだ公開ベータです。
「今は荒削りだけど、コスト 0 で試せる」という価値と、「精度・安定性は有料 API に劣る」という現実を両方踏まえた上で、自分の用途に合う方を選んでください。

株式会社ホコサキは山口県宇部を拠点に、Web 制作・業務システム開発・AI 活用支援を手がけています。
AI エージェントの実装や MCP を使ったツール連携など、実務に近い相談も受け付けています。
気になることがあればお問い合わせページからどうぞ。