Cloudflare が AI Gateway に Web Search API を追加。Exa / Linkup / Ceramic.ai をマージン無しで中継し、エージェントへ最新のWebコンテキストを供給
Cloudflare が Birthday Week 2026 の3日目に、AI Gateway 経由の Web Search API を公開した。学習データのカットオフに縛られないリアルタイム検索の結果を、推論呼び出しへ直接注入できる。呼び出し経路は REST API と Workers Bindings の2つが提供済みで、AI Gateway 内の Server Tools は近日。検索プロバイダーは Ceramic.ai / Exa / Linkup の3社で、Cloudflare は全社に Verified bots への準拠、robots.txt の尊重、検索結果でのソース帰属表示を条件として課した。課金は AI Gateway のクレジットを消費し、価格はパートナーのリスト価格そのまま、Cloudflare の上乗せマージンは無い。既存契約を持ち込む BYOK と、Zero Data Retention 対応パートナーの識別表示にも対応する。AI Gateway の統合ログとプロバイダー単位のアクセス制御が、モデル呼び出しと同じ面で検索にも効く。
ニュース原文を読む ↗要約
Cloudflare が AI Gateway 経由の Web Search API を公開しました。Birthday Week 2026 の3日目の発表です。
解こうとしている問題は単純です。 LLM は学習データのカットオフ以降を知りません。エージェントに「今の情報」を扱わせるには、Web 検索の結果を推論へ注入する必要があります。その配線を、既に多くの組織が AI の管理面として使っている AI Gateway の中に引いた、というのが今回の発表です。
注目すべきは、Cloudflare が自前の検索エンジンを作らなかった点です。 初期パートナーは Ceramic.ai、Exa、Linkup の3社で、Cloudflare は中継役に回りました。そして価格はパートナーのリスト価格そのままで、上乗せマージンを取らないと明記しています。
この価格設定は、意図の表明として読めます。 検索の売上で稼ぐのではなく、AI の呼び出しが集まる管理面としての AI Gateway の価値を上げることが目的です。検索を挟んでもゲートウェイ経由のコストが増えないなら、「とりあえず AI Gateway を通しておく」という選択の障壁が下がります。
もう1つ、クロールされる側への条件付けが入っています。 Cloudflare は3社すべてに対し、Verified bots の定義への準拠、robots.txt の尊重、検索結果でのソース帰属表示を求めました。Cloudflare は 2025年以降、AI クローラーの制御を一貫して推し進めてきた会社です。自社が検索の供給側に回るときに、同じ基準を調達条件として課したという筋の通し方になっています。
何が変わったか
- AI Gateway から Web 検索を呼べるようになった。 認証は AI Gateway のトークンをそのまま使う
- 呼び出し経路は3つ。 (1) REST API(直接HTTP)、(2) Workers Bindings(Workers から1行で統合)、(3) Server Tools(AI Gateway 内の組み込みツール、近日提供)。前2つは提供済み
- 検索プロバイダーは Ceramic.ai / Exa / Linkup の3社。 AI Gateway 側でプロバイダー単位のアクセス制御ができる
- 課金は AI Gateway クレジット。価格はパートナーのリスト価格、Cloudflare の上乗せは無し
- BYOK に対応。 既に Exa などと直接契約がある組織は、そのキーを持ち込める
- Zero Data Retention(ZDR)対応のパートナーが識別表示される
- 検索の利用ログが AI Gateway の統合ログに乗る。 モデル呼び出しと同じ画面で追える
- 全パートナーに Verified bots 準拠・robots.txt 尊重・ソース帰属表示を義務づけ
業務インパクト(一般企業向け)
まず効くのは、契約と請求の整理です。 社内で RAG やエージェントを動かしていると、モデルの契約、検索APIの契約、ベクトル検索の契約がそれぞれ別になりがちです。請求もログも別の場所にあり、「先月の AI 関連費用」を出すだけで手作業が発生します。AI Gateway に検索が入ると、この一部が1つの請求・1つのログに寄ります。
マージン無しという点が、稟議では効きます。 「中間に1レイヤー挟む」提案は、通常「その分高くなるのでは」という問いを呼びます。リスト価格そのままなら、この問いに数字で答えられます。 中継を挟むコストがゼロで、ログとアクセス制御が付いてくる、という説明になります。
アクセス制御の粒度は確認が要ります。 プロバイダー単位での制御が可能とされていますが、「どのチームがどの検索プロバイダーを使ってよいか」を分けたい場合、AI Gateway 側の権限設計と、2026-10-02 に発表されたリソース単位の RBAC を組み合わせる形になります。導入前に、自社の分離要件が現在の粒度で満たせるかを確かめてください。
ZDR の表示は、法務・情シスの判断材料として実用的です。 「検索クエリに社内情報が混ざる可能性があるが、プロバイダー側に残らないか」は、RAG 案件でほぼ必ず出る論点です。プロバイダーごとに ZDR 対応が識別表示されるなら、この確認が調達フェーズで片付きます。 従来は各社のポリシーページを個別に読む必要がありました。
一方で、検索プロバイダーが3社に限られる点は制約です。 社内標準の検索APIが別にある場合、BYOK で持ち込めるかどうかが分かれ目になります。BYOK は「既存組織向け」と説明されていますが、対象が3社のキーに限るのか、他社も通せるのかは公式記述からは読み取れません。ここは実機で確認すべき箇所です。
副業・個人活用視点
小さく始める構成として、組み合わせが良くなりました。 Workers Bindings で1行、という統合コストの低さは、個人開発では実質的な差になります。検索プロバイダーと個別契約し、APIキーを管理し、レート制限を自前で扱う工程がまるごと消えます。
提案の材料としても使えます。 「社内文書だけでなく最新の外部情報も参照するエージェント」は、中小企業向けの提案で頻出のテーマです。従来はこの構成を見積もるのが面倒でした。 検索単価、モデル単価、ベクトル検索単価がバラバラで、どれも利用量次第だからです。AI Gateway に寄せると、クレジット消費という1つの軸で説明できます。
ただし「マージン無し=安い」ではありません。 パートナーのリスト価格がそのまま乗るので、検索自体の単価は3社の価格に依存します。 大量検索を伴う構成では、まず3社の単価を比較してから設計すべきです。Cloudflare が無料にしたのは中継手数料であって、検索そのものではありません。
ソース帰属表示の義務づけは、納品物の品質に関わります。 生成結果に出典を付ける要件は、企業案件では当たり前に出てきます。検索結果に帰属情報が含まれることが保証されているなら、出典付き回答の実装が素直に書けます。 「出典を出せるか」を提案時に即答できることは、小さいようで効く差別化です。