Web 検索 API と Web 取得 API の仕組みと $0.01 の内訳

主要なサーバー側 Web 検索ツールは、どれも 1 回 $0.01 である。しかし、請求で本当に見るべきなのはそこではない。実測では、検索 1 回につき 1,500〜3,100 token の結果がリクエストへ追加され、その token はルーティング先モデルの単価で課金された。次のターンの挙動は、多くのチームが見落としているプロトコル設計の違いで決まる。検索結果を次のターンへ引き継ぐ endpoint もあれば、結果を暗黙に破棄し、モデルが再検索して追加料金が発生する endpoint もある。Synthorai の synthorai:web_search と synthorai:web_fetch を 4 つのモデル系統で計測し、Anthropic と OpenAI が公開している自社ホスト型検索の料金と比較した。

TL;DR

• Synthorai、Anthropic、OpenAI はいずれも検索 1 回 $0.01 で、課金明細には $0.0100 として計上される。
• 検索 1 回で 1,500〜3,100 token の結果が追加され、モデルの入力単価で課金される。低価格モデルでは検索手数料が大半を占めるが、高価格モデルでは token 料金が最大で半分を占める。
• max_uses は上限であり、割り当て回数ではない。10 を許可してもモデルは 3 回で停止した。料金は実行された検索回数に比例する。
• 2 ターン目の挙動は endpoint によって異なる。/v1/messages は結果を再送するため、約 3,900 token が課金される一方、新しい検索料金は発生しない。/v1/chat/completions は結果を破棄するため、証拠が必要な follow-up では新たな検索が走る。

モデルに Web 検索と Web 取得が必要な理由

モデルの知識は学習時点で止まるが、本番環境で扱う質問の多くはそうではない。価格、リリースノート、為替レート、スポーツの結果、ユーザーが今貼り付けた URL の内容は、どれもモデルの重みに含まれていない。それでも確信を持って答えると、最新情報を装った hallucination がユーザーへ返る。Web 検索は、答えがどこにあるか分からない場合の発見を担う。Web 取得は、ページが特定できており、その内容を読む場合に使う。検索 API、scraper、tool-calling loop を組み合わせて自前で実装することもでき、実際にそうしているチームもある。サーバー側ツールが存在するのは、この loop が差別化につながらない基盤処理だからだ。provider 内で実行すれば、往復通信、parse 処理、運用対象を減らせる。しかも、実際の手数料はどこも同じだった。

サーバー側 Web 検索の実際の仕組み

仕組みの要点は、loop 全体が 1 回の API request 内で完結することにある。client-side tool では、モデルがアプリケーションコードへ検索を要求し、コードが結果をモデルへ返す。そのたびに会話全体も再送される。server tool では、この中継コードが不要になる。tools に {"type": "synthorai:web_search"} を指定すると、モデルが query を生成し、gateway が専用の検索 provider へ送信する。返された結果はモデルの context に追加され、モデルが読み取って回答する。必要なら max_uses の範囲内で再検索する。入力は 1 request、出力は 1 response で、引用と請求情報も含まれる。

通常の request に 1 行加えるだけで使える。loop のコードも callback も不要だ。

curl https://synthorai.io/v1/chat/completions \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash-0731",
    "messages": [{"role": "user", "content": "What is one AI news headline from this week? Name the source."}],
    "tools": [{"type": "synthorai:web_search", "max_uses": 1}]
  }'

Web 取得も宣言方法は同じで、type だけが異なる。message に URL を入れると gateway がページを取得する。

"messages": [{"role": "user", "content": "Fetch https://example.com/pricing and summarize the tiers."}],
"tools": [{"type": "synthorai:web_fetch", "max_uses": 1}]

この図は、deepseek-v4-flash-0731 で計測した上記の検索 request をそのまま示している。メーターは input 2,059 token、output 169 token、合計 $0.0104 だった。input の内訳は、30 token の質問と約 2,000 token の検索結果である。料金は検索手数料 $0.01 と、約 $0.0004 の token 料金に分かれる。課金イベントはこの 2 つだけだ。検索実行時の手数料と、通常のモデル入力単価で計算される検索結果 token である。Web 取得も課金方法は同じで、snippet の代わりに取得ページが追加される。

宣言自体は無料である。tool を宣言しても検索しなければ、手数料はゼロだ。また、この tool は catalog 内のどのモデルでも使える。ここが first-party の選択肢との構造的な違いである。Anthropic のホスト型検索は Claude モデル向け、OpenAI の検索は OpenAI モデル向けだが、gateway-level tool はルーティング先を問わない。

検索 1 回の実際の料金

料金は $0.01 の手数料と token 料金の合計であり、モデルが高価になるほど支配的な項目が逆転する。同じニュース検索の質問を 4 系統のモデルで各 3 回実行した。tool を使わない baseline から各モデルの正確な token 単価を求め、残差を手数料として計算した。

最も安いモデルでは、検索手数料が call 全体の 97% を占めた。高価格モデルでは、追加 token が請求額の半分を占める。手数料は推測値ではない。課金明細には、tool の料金が 1 call あたり正確に $0.0100 の独立した項目として記録されている。別項目には tool が追加した token 数も記載される。実際の取得 call では、input 3,836 token のうち 3,454 token が tool による追加分だった。実測した検索 1 回の総額は、利用モデルに応じて $0.010〜0.012 に収まった。予算はこの上限で見積もればよい。サーバー側検索を低価格モデルと組み合わせると、料金の中心は検索そのものになり、モデル料金はほぼ無視できる。

Token 料金を決める 3 つの要素

検索回数、結果の長さ、ページの重さで決まり、それ以外は端数にすぎない。どれも直接計測でき、3 つのうち 2 つは利用側で直接設定できる。

1 つ目は検索回数。 max_uses は目標値ではなく上限である。5 社の価格を比較する質問で、検索を 1 回、2 回、3 回まで許可したところ、請求額はそれぞれ $0.0106、$0.0216、$0.0319 だった。実行された検索 1 回につき $0.01 が直線的に加算される。上限を 5 回、さらに 10 回にしても料金は変わらなかった。モデルが自律的に 3 回で停止したためだ。未使用分は無料であり、reasoning model で計測した thinking budget と同じである。default は 3、hard cap は 10 だ。未設定のまま検索が多く必要な質問を投げた場合、最悪で 3 回分の手数料と 3 回分の結果 token が課金される。単一の事実を取得する route では max_uses: 1 に固定するとよい。

2 つ目は検索結果の長さ。 追加される token 数は偶然ではなく、質問の広さに左右される。deepseek-v4-flash-0731 で単一検索を 12 回実行した結果は次のとおりである。

範囲を絞った質問では検索結果も小さくなる。比較型の質問では結果が広がり、単一の事実を聞く場合より約 45% 重かった。予算上は、検索 1 回あたり 2,000 token に 20% の幅を持たせれば、今回の全ケースをカバーできる。一般的なモデル単価では、検索 1 回の token 料金は $0.01 の手数料に対して 20 分の 1 から半分程度になる。

3 つ目は取得ページの重さ。 Web 取得の手数料は変わらず、残りはページのサイズで決まる。同じモデルで計測した結果は次のとおりである。

低価格モデルなら、長い Wikipedia 記事でも 1.5 セント程度で済む。同じページを 100 万 token あたり $2 のモデルへ送ると 6.5 セントになり、手数料の 5 倍に達する。予算策定では、同じページでもモデル系統によって token 数が変わる点にも注意が必要だ。データ量の多い記事は DeepSeek で 5,196 token、qwen3.8-max で 5,508 token だった。tokenizer による 6% の上乗せで、言語別の token 密度計測 と一致する。

次のターンで検索結果はどう扱われるか

2 つの API protocol には設計上の違いがあり、それが follow-up の請求額を左右する。/v1/messages protocol では、assistant turn を content block の配列として定義する。そのため、server tool の処理も turn の正式な記録に含まれる。response には server_tool_use、web_search_tool_result、text の順で入り、次の turn ではこれらの block を返すことが protocol 上求められる。証拠となる検索結果は設計どおり input token として引き継がれる。/v1/chat/completions protocol では、assistant message は単一の content string であり、server tool の結果を格納する場所がない。追加結果は server-side で吸収され、履歴に入るのはユーザーから見える回答だけなので、証拠は失われる。

claude-sonnet-5 で同じ検索と follow-up の組み合わせを、両方の surface から実行した。/v1/messages では follow-up の input が 3,911 token、料金は $0.0109 で、すべて token 料金だった。検索結果が残っているため、新しい検索は実行されなかった。/v1/chat/completions では follow-up が $0.0204 となり、結果の再送より高かった。モデルには自身が生成した 1 行の要約しか残っておらず、新たに検索したためだ。新しい $0.01 の手数料と、新しい検索結果 token が加わった。ただし、再検索は必ず起こるわけではなく、モデルの判断で決まる。以前に deepseek-v4-flash-0731 で同じ形式の follow-up を実行した際は、要約だけで回答し、input は 460 token、料金は $0.00009 だった。結果を吸収する方式では、follow-up の請求額が二極化する。要約だけで足りればほぼ無料だが、モデルが Web 情報を再び必要と判断すると、手数料と結果 token が新たに発生する。

どちらか一方の endpoint が常に安いわけではない。コストが発生する場所が異なる。block 方式は turn ごとに予測可能な token 料金を払い、すでに持っている証拠を買い直さない。吸収方式は follow-up で証拠が不要なことに賭け、必要になったときだけ新しい検索料金を払う。turn 数が多く follow-up が浅い chat には /v1/chat/completions が向く。source を何度も検証する research agent には /v1/messages が向く。引き継がれた検索結果にも、ほかの大きな context と同様に prompt cache の階層化 を適用できる。

Anthropic と OpenAI の料金と実行環境

比較は単純である。どの provider も検索 1 回 $0.01 で、その後は利用モデルの token 単価が加わる。Anthropic は検索 1,000 回あたり $10 で、検索結果は input token として課金される。Web 取得は手数料なしで、token 料金だけが発生する。OpenAI も 1,000 call あたり $10 で、token の扱いはモデル tier によって異なる。手数料は同じであり、差が出るのは 1,500〜3,100 token の追加結果に適用されるモデルの入力単価だ。

3 社の本質的な違いは、料金表ではなく tool の実行場所にある。first-party server tool は各 vendor の agent stack 向けに作られており、その vendor の surface 内でしか動かない。Anthropic のドキュメントによれば、Web 検索は Amazon Bedrock では利用できない。Google Cloud で使えるのは基本検索だけで、Microsoft Foundry では Anthropic-hosted deployment が必要になる。Web 取得は Bedrock と Google Cloud のどちらでも使えない。OpenAI の検索は Responses API に紐づいている。workload を別の cloud やモデル系統へ移すと、first-party tool は付いてこない。gateway がこれらの tool を pass-through しない理由も同じで、traffic の移動に追従できないためだ。gateway-level tool は逆の設計を採る。宣言を 1 つに統一し、モデルを変更しても platform を移しても使い続けられる。

FAQ

Web 検索 API は request 1 回あたりいくらかかりますか？

実行された検索 1 回につき $0.01 で、課金明細に独立した項目として記録される。これに、検索結果として追加された 1,500〜3,100 token が利用モデルの入力単価で加算される。tool を宣言しても検索しなければ手数料は発生しない。一般的なモデルでは、検索 1 回の総額を $0.010〜0.012 と見積もればよい。非常に安いモデルでは、手数料が合計の 97% を占める。

検索結果は後続の会話 turn で再課金されますか？

endpoint による。/v1/messages では結果 block が履歴とともに再送され、実測で turn ごとに約 3,900 input token が課金されたが、新しい検索手数料は発生しなかった。/v1/chat/completions では turn 終了後に結果が吸収される。モデルが要約だけで回答できれば、follow-up はほぼ無料である。実測では $0.00009 だった。一方、再検索すると新しい手数料と結果 token が発生し、別の実測では $0.0204 だった。Anthropic の first-party search では、結果の再送が標準動作として明記されており、turn ごとに結果が再課金される。

request ごとの Web 検索費用に上限を設定するにはどうすればよいですか？

max_uses を使う。モデルが超えられない hard limit であり、default は 3、cap は 10 である。料金は実際に実行された検索回数にだけ比例し、未使用分は無料だ。単一の事実を取得する route では、max_uses: 1 とすれば最悪でも手数料 1 回分と検索結果 1 回分に抑えられる。

Web 検索ではなく Web 取得を使うべきなのはどのような場合ですか？

URL が分かっていてページ全体を読みたい場合は Web 取得を使う。情報の所在を探す必要がある場合は Web 検索を使う。gateway 経由ではどちらも 1 回 $0.01 だが、Web 取得はページ全体を追加する。今回の計測では、最小ページの 209 token から長い記事の 27,380 token まで幅があった。Web 検索は複数 source の snippet を追加する。Claude モデルでページを取得して要約する pipeline に限れば、Anthropic の Web 取得 tool は手数料がかからないため、そちらの方が安い。

2026-08-10 に Synthorai gateway 経由で計測した。deepseek-v4-flash-0731、gpt-5.6-luna、qwen3.8-max、claude-sonnet-5 に対して synthorai:web_search と synthorai:web_fetch を使用。モデル別の token 単価は、tool なしの 2 点 baseline から算出した。検索手数料は、請求総額から token 料金を引いた残差として計測し、各モデル n=3 とした。このほか、max_uses の段階試験、query 種別ごとの検索結果量の比較（4 種類を各 3 回）、同一質問を使った両 endpoint の follow-up turn 検証、5 ページの取得試験（自社ページ 3 件、最小構成の外部ページ 1 件、長文記事 1 件）を実施した。手数料は合計額だけから推測せず、call 単位の tool charge と tool-injected-token が記録された課金明細でも確認した。Anthropic と OpenAI の数値は、公開時点の公式ドキュメントに基づく。図中の数値は、実測した 1 call を編集せず掲載したものだ。料金と挙動は変更される可能性があるため、自身の利用明細でも確認してほしい。

← ブログに戻る