Ollama の Web 検索を使う｜APIキーとクラウド経由の仕組み、必要なコンテキスト長

この記事の要点

Web 検索は検索とページ取得の2つの API として提供され、組み込み方は REST・公式ライブラリ・MCP サーバーの3経路。手元のモデルを入れ替えずに足せる。
検索を実行するのは ollama.com のエンドポイントで、無料アカウントで発行した API キーが要る。モデルはローカルのままでも、クエリは外へ出る。
返ってくる結果は数千トークンに達しうる一方、公式ドキュメントが示す既定のコンテキスト長は VRAM で決まり（別のページでは 4096 固定と書かれている）、24GiB 未満の環境は 4k のまま。1枚構成の多くでは、長さの設定か、渡す前の切り詰めが要る（公式が示す長さの目安は2つのページで数字が違い、どちらも下限）。

数字はすべて2026年9月14日に公式ドキュメント・料金ページ・プライバシーポリシーで確認した時点の記述で、本記事では実測していない。検索をモデルの判断で呼ばせる構成は、ツール呼び出しに対応したモデルであることが前提。応答時間・返却トークン数・コンテキスト長を伸ばしたときの必要メモリ量は測っていない。

Ollama の Web 検索でできること
どこへ何が送られるか
無料でどこまで使えるか
組み込む3つの経路
手元のモデルで結果を扱うための条件
1. ツールを扱えるモデルを選ぶ
まとめ
よくある質問
参考資料

Ollama の Web 検索でできること

Ollama の Web 検索 API は、モデルに最新の情報を足してハルシネーションを減らし、精度を上げる用途のものだと公式ドキュメントが説明している。手元に置いたモデルの重みが古いままでも、回答を組み立てる直前に外から材料を持ってこられる。

入口は2つある。クエリを投げて検索結果を受け取る web_search と、URL を渡してそのページの内容を受け取る web_fetch だ。どちらも REST API として提供され、Python と JavaScript の公式ライブラリではツールとしての統合が用意されている。リクエストの宛先は https://ollama.com/api/web_search と https://ollama.com/api/web_fetch で、検索そのものを実行するのは ollama.com のサービスだ。

	web_search	web_fetch
エンドポイント	POST `https://ollama.com/api/web_search`	POST `https://ollama.com/api/web_fetch`
やること	単一のクエリに対する検索を実行し、関連する結果を返す	URL で指定した1ページを取得し、その内容を返す
パラメータ	`query`（文字列・必須）、`max_results`（整数・任意、既定5・最大10）	`url`（文字列・必須）
レスポンス	`results` の配列。各要素が `title`・`url`・`content`	`title`・`content`・`links`（ページで見つかったリンクの配列）

出所: Ollama 公式ドキュメント Web search（2026年9月14日確認）

content に入るのは検索結果の関連する抜粋で、web_fetch のほうはページの本文が返る。検索で当たりを付けて、必要なページだけ取得して読ませる、という2段構えが素直な組み方だ。web_fetch のレスポンスにはページで見つかったリンクの配列も入るので、そこから次に取得する URL を選ぶ動きまで作れる。

max_results を増やせば材料は増え、返ってくる本文の量もその分だけ増える。そのまま渡すなら、モデルが読む量もそれに従って増える。件数は、コンテキスト長の確保と一組で決める値だ。

Ollama 自体をまだ動かしていない段階であれば、ローカルLLMとは？Ollama × Gemma 4でコードを外に出さず使うAI環境を初心者向けに解説で環境を用意してからのほうが進めやすい。なお、参照させたい情報が Web ではなく手元の文書であれば、検索 API ではなく OllamaでローカルRAGパイプラインを構築する方法の経路が対応する。

どこへ何が送られるか

公式ブログが載せている cURL の例は、https://ollama.com のエンドポイントへ直接リクエストを送る形で書かれている。公式が配布する MCP サーバーのサンプルも、web_search を「Ollama のホスト型検索 API を使った Web 検索の実行」と説明している（サンプル実装のツール定義に書かれた説明文）。モデルをローカルで動かしていても、検索のクエリ文字列は Ollama のサービスへ渡る。

利用には API キーが要る。公式ドキュメントは Web 検索 API を使うにあたって API キーの作成を求め、その作成には無料の Ollama アカウントが必要だと書いている。JavaScript ライブラリの README も同じく Ollama アカウントを前提にし、キーの発行場所として https://ollama.com/settings/keys を挙げている。リクエスト時は環境変数 OLLAMA_API_KEY を設定しておくか、Authorization ヘッダーに Bearer トークンとして渡す。どちらになるかは組み込みの経路で決まる。

送信先に関わるプライバシーポリシーの記述は、状況ごとに分かれて書かれている。

記述の対象	プライバシーポリシーの記述
ローカルでの実行	Ollama はローカルで動作し、ローカルで実行している分についてはプロンプトやデータを見ない
クラウドでホストされたモデルの利用	プロンプトとレスポンスはサービスを提供するために一時的に処理し、学習には使わない
デバイスと利用のメタデータ（動作を説明する節）	アプリのバージョンやリクエスト数といった限定的なメタデータを収集することがあり、そこにプロンプトやレスポンスの内容は含まれない
サービスの訪問・利用時に自動的に収集される情報（別の節）	IP アドレスやブラウザ・端末の特性、OS、言語設定などを含みうる。特定の個人を明らかにするものではないと記載されている
データの所在	データは米国へ移転され、処理されることがある

出所: Ollama プライバシーポリシー（2026年3月更新、2026年9月14日確認）

プロンプトとレスポンスを一時的に処理し学習に使わない、という記述は、クラウドでホストされたモデルを使う場合について書かれたものだ。Web 検索へ投げたクエリがどう扱われるか、どれだけ保持されるかを、この記述からそのまま読み取ることはできない。公式の記述だけで確実に言えるのは、リクエストの宛先が ollama.com であり、そこへクエリの文字列が渡ることまでだ。

取り扱いの線引きが必要な情報を扱う環境では、この不確かさをそのまま前提に組む。社名や顧客名、未公開の識別子をクエリへ載せるかどうかは、ポリシーの解釈ではなく、自分たちの持ち出し基準で決める部分だ。

Ollama 自体にクラウドの機能を使わせたくないなら、切る設定がある。公式ドキュメントの FAQ は、~/.ollama/server.json で disable_ollama_cloud を true にするか、環境変数 OLLAMA_NO_CLOUD=1 を設定すると local only mode にでき、切るとクラウドのモデルと Web 検索が使えなくなると書いている。設定を変えたら Ollama を再起動する。公式が書いているのはここまでで、自分のコードから ollama.com のエンドポイントへ直接投げるリクエストにこの設定が及ぶかは書かれていない。クラウド機能を切ると Web 検索も止まるという書き方は、公式が Web 検索をクラウドの機能として扱っていることを示している。ただしプライバシーポリシーが一時的な処理について書いているのはクラウドでホストされたモデルで、機能としてのまとまりが同じ範囲を指すとは限らない。

UI ごとローカル内で閉じる組み方も近い（Open WebUI で Ollama に Web UI を足して、チームでローカル LLM を使う）。反対に、検索も要約もまとめて外のサービスへ預ける選び方もある（AIのディープリサーチ機能を比較｜ChatGPT・Gemini・Perplexity・Felo・Claudeの選び方）。Ollama の Web 検索は、モデルを手元に置いたまま検索だけを外へ出す、その中間に位置する構成だ。

無料でどこまで使えるか

公式ブログは、個人が使う分には潤沢な無料枠があると記載し、より高い rate limit は Ollama のクラウド経由で利用できるとも書いている。あわせて、Web 検索は無料の Ollama アカウントに含まれ、サブスクリプションを上げると rate limit が大きく上がるとも書いている。回数そのものの上限を公式が数値で示している箇所は見当たらない。

プラン	月額	含まれる usage credits	同時実行リクエスト数
Free	$0	スターター分（金額の表示なし）	1
Pro	$20 / 月（年払い $200 / 年の併記あり）	月 $60 分	3
Max	$100 / 月	月 $300 分	10
Team	$500 / 月	月 $1,000 分（チームで共有）	10
Enterprise	個別見積もり	金額の表示なし	数値の表示なし

出所: Ollama 料金ページ（2026年9月14日の表示）

プランに含まれる usage credits は、クラウドで動かすモデルの利用に充てるトークン課金のクレジットだ。料金ページは usage をトークンで測ると述べ、モデル価格表に入力・キャッシュ入力・出力の100万トークンあたりの単価を並べている。Web 検索の呼び出し上限がこのクレジットで表されているわけではない。Web 検索について公式が書いているのは、無料アカウントに含まれることと、サブスクリプションを上げると rate limit が上がることの2点だ。

同時に実行できるリクエスト数はプランで決まると料金ページは書いている。上限を超えた分はキューに入って空き次第処理され、キューにも保持上限があって、満杯のときは同時実行の枠が空くまでリクエストは拒否される。ただし、この同時実行の数え方に Web 検索の呼び出しが含まれるかどうかは書かれていない。Web 検索について書かれているのは、無料アカウントに含まれることと、有料プランで rate limit が大きく上がることの2点だけだ。

自分のハードウェアでモデルを動かす分は常に無制限だと料金ページは明記している。Web 検索を手元のモデルと組む構成でプランが関わるのは3つ。クラウドのモデルを呼ぶ分に充てる usage credits、同時に投げられるリクエストの本数（検索の呼び出しを数えるかは書かれていない）、そして Web 検索の rate limit。料金ページが数値で示しているのは usage credits と同時実行リクエスト数で、検索の rate limit は公式ブログが上がるとだけ書いている。手元の GPU で推論を回し、検索だけを API へ出す構成なら、usage credits を消費するクラウドのモデルは呼んでいない。

組み込む3つの経路

REST を直接叩く、公式ライブラリを使う、MCP サーバーとして常駐させる。3経路に共通の前提は API キー1つ。https://ollama.com/settings/keys で発行して手元に置く。渡し方は経路で変わる。REST は Authorization ヘッダーに載せ、公式ライブラリと MCP サーバーは環境変数 OLLAMA_API_KEY から受け取る。用意するものも違う。REST は追加の依存が要らず、公式ライブラリはバージョンの下限があり、MCP は uv と公式サンプルのスクリプトが要る。経路を分ける軸は、検索を呼ぶ主体をアプリのコードに置くか、MCP クライアントに任せるかだ。既存のスクリプトへ足すなら REST かライブラリ、エディタやエージェントに検索を持たせるなら MCP を選ぶ。

REST API を直接叩く

キーを環境変数に入れておけば、ヘッダーへそのまま展開できる。

curl https://ollama.com/api/web_search --header "Authorization: Bearer $OLLAMA_API_KEY" -d '{ "query": "what is ollama?" }'

返す件数を増やすなら max_results を足す。省略時は5件、最大で10件まで。取得したい URL が決まっているときは、宛先を https://ollama.com/api/web_fetch に変えて url を渡す。言語やフレームワークに依存しないので、シェルスクリプトや既存のバックエンドへ最短で足せるのはこの経路だ。

公式ライブラリから呼ぶ

公式ブログが示すバージョン要件は、Python が ollama>=0.6.0、JavaScript が ollama@>=0.6.0。

pip install 'ollama>=0.6.0'
npm install 'ollama@>=0.6.0'

Python では ollama.web_search を呼ぶ。ページ取得は ollama から web_fetch を読み込む。

import ollama

response = ollama.web_search("What is Ollama?")

from ollama import web_fetch

result = web_fetch('https://ollama.com')

JavaScript の関数名は webSearch と webFetch だ。公式ブログの例は、ライブラリから Ollama を読み込んでクライアントを作り、そのクライアントのメソッドを呼ぶ形で書かれている。

import { Ollama } from "ollama";

const client = new Ollama();
const results = await client.webSearch({ query: "what is ollama?" });

webSearch の引数は、参照するページによって書き方が分かれている。公式ブログの例は client.webSearch({ query: "what is ollama?" }) とオブジェクトを渡す形で、公式ドキュメントの JavaScript の例は client.webSearch("what is ollama?") と文字列を直接渡している。分かれているのは例のほうで、ライブラリのリポジトリに置かれている実装は受け取ったオブジェクトの query を参照し、空なら Query is required というエラーを投げる。webFetch も同じ形で url を参照する。オブジェクトを渡す形が実装と一致する。

件数の指定には、この時点で別の食い違いがある。REST API が受け取る名前は max_results だが、JavaScript ライブラリの型定義は maxResults で、webSearch は受け取ったオブジェクトをそのまま送っている。公式リポジトリの Issue は、変換が挟まらないためこの指定が反映されないと報告しており、2026年9月15日の時点で解決済みになっていない。件数を確実に指定したいなら、この経路ではなく REST を直接叩くか、Python ライブラリを使う（公式の MCP サンプルも Python の web_search を max_results という名前で呼んでいる）。

MCP サーバーとして使う

公式ドキュメントは、Python の MCP サーバーを使えば任意の MCP クライアントで Web 検索を有効にできると記載している。公式のサンプル実装は web_search と web_fetch の2つをツールとして公開し、依存に mcp・rich・ollama を挙げている。公開する web_search の max_results は既定が3で、REST API の既定5とは別にサンプル側が置いた値だ。自分のアプリへ検索呼び出しのコードを書かず、クライアントの判断でツールを呼ばせたい場合はこの経路だ。

設定で指す web-search-mcp.py は公式ライブラリに置かれたサンプルで、手元へ配置したパスを args に書く。Cline では MCP サーバーの設定に標準入出力型のエントリを追加する。コマンドに uv、引数に MCP サーバーのスクリプト、環境変数に OLLAMA_API_KEY を渡す形が公式ドキュメントの例だ。

{
  "mcpServers": {
    "web_search_and_fetch": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "path/to/web-search-mcp.py"],
      "env": {
        "OLLAMA_API_KEY": "your_api_key_here"
      }
    }
  }
}

Cline とローカルモデルの接続そのものは Cline でローカル LLM を動かして無料・オフラインで AI コーディングする（Ollama 連携）にまとめてある。

Codex では ~/.codex/config.toml に mcp_servers のエントリを足す。

[mcp_servers.web_search]
command = "uv"
args = ["run", "path/to/web-search-mcp.py"]
env = { "OLLAMA_API_KEY" = "your_api_key_here" }

Goose についても、MCP の機能を通して Ollama と連携できると公式ドキュメントが記載している。設定ファイルの書式はクライアントごとに違うが、渡すものは共通で、実行コマンドとスクリプトのパス、そして API キーの3点だ。

手元のモデルで結果を扱うための条件

検索結果は数千トークンに達しうる。公式ドキュメントの Web 検索のページは、そのためモデルのコンテキスト長を少なくとも約32000トークンへ上げることを勧めている。一方、コンテキスト長のページには、Web 検索やエージェント、コーディングツールのように大きなコンテキストを要するタスクは少なくとも64000トークンに設定すべきだと書かれている。どちらも「少なくとも」の下限として書かれた推奨で、大きいほうを満たせば小さいほうも満たす。公式が2つの数字を示している理由までは書かれていない。

出発点は、動かす環境で何が既定になっているかだ。コンテキスト長のページは、既定のコンテキスト長が VRAM で決まるとして3段を挙げている。

VRAM	既定のコンテキスト長
24GiB 未満	4k
24〜48GiB	32k
48GiB 以上	256k

出所: Ollama 公式ドキュメント Context length（2026年9月14日確認）

既定値についても公式の記述は1つではない。公式ドキュメントの FAQ は、既定のコンテキストウィンドウを 4096 トークンとし、OLLAMA_CONTEXT_LENGTH で上書きできると書いている。VRAM で決まる3段と、4096 固定。どちらが手元の環境に当たるかは、実際に割り当てられた長さを ollama ps の CONTEXT で見て確かめる。

24GiB に届かない環境では、何も変えなければ 4k のままだ。検索結果を丸ごと渡す前提で公式が挙げている数字とは桁が1つ違う。上げた長さが GPU に収まるかどうかは VRAM の余裕で決まる。上げないまま使うなら、渡す前に結果を削る作り方がある。既定のコンテキスト長のままローカルモデルをエージェントへ繋いだときにどこで詰まるかは、ローカルLLMをコーディングエージェントに繋ぐ｜OpenCode × Ollama の設定とモデル選びで扱っている。

変更手段は2つ。Ollama のアプリでは、設定にあるスライダーを目的の長さへ動かす。サーバーとして起動するなら、環境変数 OLLAMA_CONTEXT_LENGTH を付けて実行する。

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

この書き方は macOS と Linux のシェルのものだ。Windows でアプリとして動かしている場合、公式ドキュメントの FAQ は、いったんタスクバーから Ollama を終了し、設定またはコントロールパネルの環境変数の編集画面で変数を作ってから、スタートメニューで起動し直す手順を案内している。Ollama はユーザーとシステムの環境変数を引き継ぐので、変数を作ったあとに起動した Ollama がその値を読む。

ローカルの Ollama をサーバーとして常駐させ、社内のアプリから呼ぶ構成は Ollama をローカル API サーバーにして社内アプリから LLM を呼ぶにまとめてある。

指定した長さが実際に割り当てられたかは ollama ps で確かめる。CONTEXT の列に割り当てられたコンテキスト長、PROCESSOR の列に GPU と CPU の分担が出る。公式ドキュメントは、性能を出すならモデルの最大コンテキスト長を使い、CPU へのオフロードを避けるよう勧めており、その分担の確認手段として ollama ps を挙げている。

ただし、コンテキスト長を大きくすると、モデルの実行に必要なメモリが増える。公式ドキュメントは、増やす前に VRAM に余裕があることを確かめるよう求めている。どれだけ増えるかは本記事では測っていない。KV キャッシュの量子化まで含めて増え方を実測した結果は、姉妹サイトのVRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるか｜KVキャッシュ量子化の実測にある。

なお、クラウドで動かすモデルは既定で最大のコンテキスト長に設定されると公式ドキュメントは記載している。手元のモデルだけ長さを自分で確保する必要があるのは、ローカルの既定が VRAM に合わせて決まるためだ。

ツールを扱えるモデルを選ぶ

もう1つの条件はモデルの選び方だ。Ollama のツール呼び出しは、モデルがツールを呼び出し、その結果を返答へ取り込む仕組みだと公式ドキュメントが説明している。検索をモデルの判断で呼ばせる使い方は、この仕組みに対応したモデルが前提だ。

公式ブログは、ツールを扱う能力が高く、利用者やツールと複数回やり取りして最終的な結果へ辿り着けるモデルとして qwen3 と gpt-oss を挙げている（2025年9月24日公開の記述）。検索して読み、足りなければもう一度検索する、という往復を前提にした挙げ方だ。

長さを上げないまま使う作り方も公式の例に示されている。公式が示す検索エージェントの例は、ツールの戻り値を切り詰めてからメッセージへ追加しており、コードには限られたコンテキスト長のために結果を切り詰めているという注記が付いている。全文を渡すのではなく、渡す前に削る。コンテキスト長を上げられない環境では、この作り方が現実的な選択肢だ。

まとめ

組み込む前に確認することが3つある。順番に見ていく。

アカウントと API キー：無料アカウントを作ってキーを発行し、環境変数かヘッダーで渡せる状態にする。ここが通らなければどの経路も動かない。
送信先：検索のリクエストは ollama.com のエンドポイントへ出る。プライバシーポリシーがどの状況について何を書いているかを読み分け、検索クエリの扱いを別の記述から推測しない。
コンテキスト長：既定値は環境で変わり、公式の記述も1つではない。検索結果を受け止められる長さを確保し、割り当てを ollama ps で確認してから本番の呼び出しへ進む。

この3点が揃えば、検索結果を手元のモデルへ渡す土台はできる。検索をモデルの判断で呼ばせるなら、ツール呼び出しに対応したモデルであることがもう1つの条件だ。無料アカウントの rate limit がどこに置かれているか、長さを伸ばしたときにメモリがどれだけ要るかは、公式の記述からは読み取れない。前者は使いながら確かめるほかなく、後者は実測に当たる範囲だ。

よくある質問

有料プランへ上げると Web 検索の上限も上がるのか

公式ブログはサブスクリプションを上げると rate limit が大きく上がると書いており、Web 検索の rate limit がプランに連動することはここまで読める。ただし、料金ページがプランごとに数値で示しているのは、クラウドで動かすモデルへ充てる usage credits と同時実行リクエスト数だ。Web 検索を何回呼べるかは数値で示されていない。クラウドのモデルを呼ぶ枠が増える話と、検索の rate limit が上がる話は、公式の中でも別の場所に書かれている。

コンテキスト長は公式が示す2つの数字のどちらに合わせるのか

約32000トークンは Web 検索のページ、64000トークンはコンテキスト長のページに書かれた下限で、64000 に合わせれば両方を満たす。読み方の起点は既定値だが、その既定値を公式は VRAM で決まる3段と 4096 固定の2通りで書いている。3段に当たる環境なら、24GiB 未満はどちらの数字を採っても変更が要り、24〜48GiB は小さいほうだけを満たし、48GiB 以上は両方を上回る。4096 固定に当たる環境なら、どの容量でも変更が要る。割り当てられた長さはモデルが持つ最大の長さにも左右されるので、最後は ollama ps の CONTEXT で確かめる。

ローカルのモデルを使っていても、検索した語はどこへ出るのか

検索のリクエストは ollama.com のエンドポイントへ送られ、クエリの文字列はそこに含まれる。プライバシーポリシーは、ローカルで実行している分についてはプロンプトやデータを見ないと書き、クラウドでホストされたモデルを使う場合のプロンプトとレスポンスは一時的に処理して学習には使わないと書いている。Web 検索のクエリがどちらの記述に当たるかは明示されていない。加えて、限定的なデバイスと利用のメタデータの収集と、データが米国で処理されうることがポリシーに書かれている。公式の記述だけで判断できるのはここまでで、外へ出せない語をクエリに含めない運用がその範囲に収まる。

参考資料

本記事の API の仕様・料金・コンテキスト長の記述は2026年9月14日に公式ドキュメントと料金ページで確認した時点のもの。