Agent に「今日何が起きたのか」と聞かれたとき、モデルの学習カットオフは役に立たない。難しいのは検索ボックスを追加することだけではない。プロバイダー API を接続し、リアルタイムの結果を処理し、リクエストを記録し、コストを管理し、どのページが回答の根拠なのかをモデルに伝える必要がある。
Cloudflare は現在、この一連のエンジニアリング作業を1つの入口にまとめている。2026年10月2日、Cloudflare は Web Search API が beta に入ったと発表した。開発者は AI Gateway 経由で検索リクエストを送り、Ceramic.ai、Exa、Linkup から選択して、リアルタイムのインターネット結果を Agent に渡せる。解決するのは接続とガバナンスの問題であり、新しい検索エンジンを作ることではない。
これはウェブ接続型 Agent を開発するチームにとって実用的だ。プロバイダーを変更しても、呼び出し箇所や周辺のガバナンス処理をすべて書き直す必要はない。ただし、「統一 API」は「3社の検索結果が同じ」という意味ではない。本番投入前には、結果の形式、リクエストごとの料金、データ保持方針が要件に合うかを確認する必要がある。
検索を Agent のツール呼び出しにする
Cloudflare による Web Search API の公式な位置づけは明確だ。AI Agent やアプリケーションがインターネットを検索し、リアルタイム情報で回答を支えられるようにする。URL を推測したり、モデルの学習カットオフだけに頼ったりする必要がなくなる。リクエストは AI Gateway を経由するため、検索呼び出しは Gateway のログに記録され、選択したプロバイダーの公開 API 料金に基づいて AI Gateway credits から課金される。追加の上乗せ料金はない。
開発者にとっての変化は、「検索」という動作そのものではなく、その周辺の境界がまとめられた点にある。これまでは Ceramic.ai、Exa、Linkup の SDK、キー、エラー処理、請求を個別に管理する必要があったかもしれない。これからはプロバイダー選択をリクエストのパラメーターにし、検索呼び出しを1つの Gateway で観測できる。
この抽象化は、チームに交換可能な電話回線をつないだ交換台を置くようなものだ。外からは同じ番号にかけられるが、どの回線が最適かを交換台が判断するわけではなく、検索結果を自動的に事実へ変えることもない。Cloudflare の公式発表が示しているのは統一された入口であり、検索品質の統一ではない。
この点には注意が必要だ。製品はまだ beta で、Cloudflare は検索品質、ランキングの安定性、回答の正確性に関する指標を公開していない。したがって、リアルタイムのインターネットに接続できることを、そのまま「Agent が信頼できる形で事実を検証できる」と読み替えることはできない。
REST と Workers の両方に対応、コードより先に設定を確認する
Agent が自分のバックエンドで動いているなら、REST API を直接呼び出せる。エンドポイントは POST /client/v4/accounts/{account_id}/ai/websearch/ で、リクエストボディには少なくとも query が必要だ。provider、limit、AI Gateway ID も指定できる。
Cloudflare のドキュメントではパラメーターの範囲が明確に定義されている。query の長さは1〜1024文字、limit のデフォルトは10で、指定できる値は1〜10。provider は ceramic、exa、linkup から選べ、省略時は Ceramic.ai が使われる。
つまずきやすいのは権限だ。REST リクエストで使う Cloudflare API Token には、アカウントレベルで Workers AI Read と AI Gateway Read の両方の権限が必要になる。さらに、アカウントに default という名前の Gateway があるか、自分で Gateway を作成し、AI Gateway credits またはプロバイダーのキーを用意しておく必要がある。パラメーターとレスポンスの定義は How to use Web Search API を参照してほしい。
Agent がすでに Cloudflare Worker 上で動いているなら、接続はさらに短くなる。Worker に AI binding を設定して、env.AI.websearch() を呼び出せばよい。標準の Response オブジェクトが返るので、response.json() で結果を読み取る。REST と Workers の違いは主に実行場所であり、別々の検索機能というわけではない。
最小限の呼び出しは次のようになる。
const response = await env.AI.websearch({
gatewayId: "default",
query: "本週影響供應鏈的最新事件有哪些？",
provider: "exa",
limit: 5,
});
const results = await response.json();
レスポンスに謎めいた「最終回答」が入っているわけではない。中心となるのは items と metadata だ。各結果には通常 url、title、description が含まれ、メタデータにはクエリ、リクエスト ID、レイテンシーなどが含まれる場合がある。ソースをどう絞り込むか、結果をどうモデルに渡すか、回答に引用を残すかは、引き続きアプリケーション側のロジックになる。
3社の違いは、モデルにどう結果を渡すかに表れる
共通パラメーターはシンプルだが、プロバイダーは同じものとして置き換えられるわけではない。Cloudflare のプロバイダードキュメントが挙げる違いは、まずインデックス、返されるテキスト、検索方式、料金にある。
| プロバイダー | 結果の特徴 | 向いているワークフロー | 公開価格 / 1,000回 | Zero Data Retention |
|---|---|---|---|---|
| Ceramic.ai | ページの説明は最大8,000文字 | 高頻度・低コストの検索 | $0.25 | Yes |
| Exa | キーワードと embedding による検索、highlights を返す | 関連箇所をそのままコンテキストに入れる | $7.00 | No |
| Linkup | fast 検索、元の結果とテキストスニペットを返す |
出典付きの結果をすばやく取得する | $5.00 | Yes |
デフォルトのプロバイダーは Ceramic.ai だ。Cloudflare のドキュメントによれば、Agent や大規模言語モデルのアプリケーション向けに、400億ページを超える独立したウェブインデックスを維持している。低レイテンシー、低コスト、比較的長いページ説明を重視している。1つのタスク中に何度も検索する Agent なら、デフォルトで選ぶことには明確な予算上の利点がある。ただし、自分の分野に必ず最適とは限らない。
Exa は「最も関連性の高い数段落をモデルに渡す」方向に寄っている。従来のキーワード検索と embedding 検索を組み合わせ、Web Search API では Exa の auto 検索タイプを使い、ページ内でクエリに最も関連する highlights を説明として返す。コンテキストウィンドウに余裕がない場合、長いページ説明よりも関連箇所のほうが扱いやすい可能性がある。その代わり、公式の公開価格はかなり高く、ドキュメント上の Zero Data Retention は No となっている。
Linkup は fast の検索深度を使い、元の検索結果とテキストスニペットを返す。こちらで回答を生成することはない。結果を取得し、出典を残し、後処理は自分のツールチェーンに任せるという、すばやい Agent のツール呼び出しに近い。公開価格は Exa より低く Ceramic.ai より高い。公式には Zero Data Retention をサポートすると記載されている。
ここでよくある誤解に注意したい。表の価格はプロバイダーの公開 API 料金であり、完全な請求額ではない。AI Gateway credits で支払う場合、Cloudflare は追加の markup を加えないとしている。BYOK、つまり既存のプロバイダー API key を Gateway に保存する方式では、プロバイダーが契約に基づいて直接請求する。プラン、税金、リトライ、上位モデル、アプリケーションの実行コストをこの表から推測することはできない。
統一された入口がソースを検証してくれるわけではない
Web Search API が返すのは検索結果のリストであり、すでに検証済みの結論ではない。Agent が古いページ、マーケティング文句、互いに矛盾する報道をそのまま使って回答を生成しても、統一 Gateway が自動的に信頼できる事実へ変えてくれるわけではない。
そのため、接続時には「検索」と「回答」を分けて考える必要がある。検索ツールが取得するのは URL、タイトル、説明、リクエストのメタデータだ。原文を取得するか、複数ソースの相互確認を求めるか、信頼度の高いドメインを指定するか、最終回答に引用を表示するかは、アプリケーション側で決めなければならない。
この構成で価値のある層の1つがログだ。リクエストが AI Gateway を通れば、検索呼び出しは Gateway のログに現れ、返された requestId とレイテンシー情報は Agent のタスクを追跡するのに役立つ。ただし、ログが示すのはリクエストで何が起きたかだけであり、業務側の評価に代わるものではない。たとえば、ある質問から有効なソースがいくつ見つかったか、モデルが結果を正しく使ったか、といった点は別途評価する必要がある。
データ方針も、「Cloudflare が接続を統一する」という言葉だけで判断してはいけない。Cloudflare の発表では、3社すべてが Cloudflare 経由のリクエストで Zero Data Retention をサポートすると説明されている。一方、プロバイダーのページの表では各社の状態が分けて記載され、Exa は現在 No、Ceramic.ai と Linkup は Yes となっている。自分のアカウント、リクエスト経路、契約に適用される最新の規約を、本番接続前に確認すべきだ。
BYOK には、見落としやすいキー管理上の挙動もある。リクエストで byokAlias を指定したのに、そのエイリアスが Gateway に設定されていない場合、呼び出しはそのまま失敗する。AI Gateway credits に自動でフォールバックすることはない。キーの無効化をきっかけに課金方式が気づかないうちに切り替わるのは防げるが、設定ミスに対して明確なアラートを用意しなければならない。
タスクに合わせてプロバイダーを選び、切り替えるか判断する
慎重に試すなら、まずデフォルトの Ceramic.ai で一連の処理を動かし、同じ現実の質問セットで3社の結果を比較するとよい。比較の基準は「見つかったか」だけではない。結果をそのままモデルに渡せるか、ソースを表示に適しているか、レイテンシーがユーザー体験に影響するか、ログとコストが十分に透明かも記録する。
Agent が1つのタスク中に頻繁にウェブを調べるなら、低価格と低レイテンシーがより重要になる。短く関連性の高い原文の断片をコンテキストに入れたいなら、Exa の highlights が扱いやすいかもしれない。出典付きの高速な結果を取得し、後処理は自分のツールチェーンで行いたいなら、Linkup の返却形式がそのワークフローに近い。これは用途との対応関係であり、Cloudflare が性能を保証するものではない。
接続前に、次の3つをレビュー項目に入れておくとよい。
- 必要なのは長いページ説明、関連する highlights、それともスニペット付きの元の結果か。
- このリクエストは AI Gateway credits と BYOK のどちらを使うか。公開価格以外にどのようなアプリケーション層のコストがあるか。
- Agent のクエリと返却内容にはどのデータ保持方針が適用され、プロバイダーの規約を定期的に確認する担当者は誰か。
今回の Cloudflare のリリースの価値は、プロバイダーの切り替えや Gateway 接続に伴うエンジニアリング上の摩擦を減らすことにある。ただし、接続すれば信頼できる回答が出る機械ではなく、観測可能で切り替え可能な検索基盤として捉えるほうがよい。まずプロバイダー間の違い、課金の境界、ソース検証をシステム設計に組み込み、そのうえで beta API を実トラフィックで検証する。それが、現時点でこの機能をより確実に使う方法だ。
参考資料
- Introducing Web Search API：Cloudflare 公式発表、2026年10月2日
- How to use Web Search API：Cloudflare 公式利用ドキュメント
- Providers：Cloudflare 公式のプロバイダー、料金、データ保持に関する説明
- AI Gateway unified billing：Cloudflare AI Gateway の統一課金ドキュメント
