Cloudflare は Web 検索 API ベータ版を AI ゲートウェイに追加しました。これにより、エージェントと AI アプリケーションは、モデル トラフィックにすでに使用されているのと同じゲートウェイ層を通じてライブ インターネットを検索する方法が提供されます。この機能は新しく、表面積が狭く、まだベータ版ですが、より大きな変化を示しています。検索は、単なるアプリケーション側の統合ではなく、課金対象の AI ツールになりつつあります。
同社は 2026 年 10 月 2 日にベータ版を発表しました。開始時に、Cloudflare は選択可能な検索プロバイダーとして Ceramic.ai、Exa、Linkup をリストします。開発者は、AI Gateway を通じて検索リクエストを送信し、それらのリクエストをゲートウェイ ログに表示させ、AI Gateway クレジットを通じて各プロバイダーのリストにある API 価格で支払いを行うことができます。 Cloudflareは、追加のマークアップは追加していないと述べている。チームは、サポートされている場合、Bring-Your-Own-Key プロバイダー認証情報を使用することもできます。
この組み合わせは、ツールのルーティング、可観測性、課金という、別々に処理されることが多い 3 つの問題を結合するため重要です。検索強化エージェント、リサーチアシスタント、サポートボット、または自動販売ワークフローを構築する開発者にとって、問題はもはやどのモデルが答えを生成したかだけではありません。また、どの検索プロバイダーが、誰の資格情報で、どのような価格で呼び出されたか、また、結果として生じた支出を顧客、チーム、プロジェクト、または API キーに結び付けることができるかどうかも決まります。
何が変わったのか
最近まで、AI ゲートウェイの多くの議論は、OpenAI 互換エンドポイント、プロバイダー フェイルオーバー、トークン アカウンティング、レイテンシ、キャッシュ、リクエスト ログなどのモデル呼び出しに集中していました。 Cloudflare の Web Search API ベータ版は、そのコントロール プレーンに別の種類のトランザクションを追加します。検索呼び出しはモデル応答をサポートする場合がありますが、それ自体はモデル推論リクエストではありません。異なる価格設定、異なるプロバイダーのセマンティクス、および異なるガバナンスの問題があります。
Cloudflare のリリースにより、検索プロバイダーは、ハードコーディングされたアプリケーションの依存関係ではなく、構成可能なゲートウェイの選択肢になりました。開発者は、リストされたプロバイダーの中から選択し、AI ゲートウェイを介して通話をルーティングし、他の AI トラフィックと並べて確認できます。顧客が Cloudflare 管理の請求を使用する場合、料金は AI Gateway クレジットに対して実行されます。顧客がプロバイダー キーを持参した場合、ゲートウェイは引き続きルーティングとログのパスに存在できます。
これは意味のある製品境界です。検索は、エージェント フレームワークの背後に隠された目に見えないヘルパーではなくなりました。ゲートウェイ記録では第一級のイベントとなる。チーム用 マルチモデル API ゲートウェイ の場合、これが「エージェントのコストが高かった」と「このワークフローはモデル トークン、キャッシュされたコンテキスト、および 6 回のライブ検索呼び出しに費用を費やした」の違いです
ゲートウェイ チームが注意すべき理由
当面の対象者は、すでに Cloudflare AI Gateway を使用している開発者、特に最新の情報を必要とするアプリケーションを構築している開発者です。検索はライブ データの応答を追跡するのに役立ちますが、別のコスト単位とプロバイダー依存性の別の原因も生じます。サポート エージェントがドキュメントを検索したり、コンプライアンス アシスタントが現在のポリシー ページをチェックしたり、市場監視ワークフローが Web を繰り返しスキャンしたりする場合、トークンの使用量が控えめに見えても、検索料金が運用上重要になる可能性があります。
これは、エージェント インフラストラクチャ全体で現在発生しているのと同じパターンです。ホストされたシェル ツール、ブラウザの使用、コード レビュー エージェント、取得サービスはすべて、モデルに関する従量制の操作に変わりつつあります。トークンは依然として重要ですが、もはやトークンが台帳全体ではありません。使用可能なゲートウェイでは、最終的な完了だけでなく、ワークフロー全体にわたる支出を説明する必要があります。
企業の場合、チャージバックとマージンに影響します。リセラーまたは社内プラットフォーム チームは、検索費用をプロバイダーの定価で渡すか、マークアップするか、プランにバンドルするか、デフォルトでブロックするかを決定する必要がある場合があります。財務チームは、プロンプトの増加、出力トークンの増加、キャッシュ動作、Web 検索量の増加によって顧客の請求書が増加したかどうかを知りたい場合があります。製品チームは、バックグラウンドのエンリッチメントとユーザーに表示される生成を区別する使用状況レポートを必要とする場合があります。
これにより、より強力な 統合 AI API 請求が可能になります。請求モデルは、トークン、キャッシュされたトークン、およびツール呼び出しを、単一の曖昧な「AI 使用量」の線に平坦化することなくカバーする必要があります。そうしないと、顧客はエージェント システムのどの部分がコストを引き起こしているのかを知ることができません。
開発者の影響
開発者は、Web 検索を単にプロンプトの機能強化としてではなく、アプリケーションの API 設計の一部として扱う必要があります。検索プロバイダーは構成に表示される必要があります。資格情報の範囲を指定する必要があります。ログには、不要な機密データを保持せずに、プロバイダーの動作と顧客の支出をデバッグするのに十分な情報が保存される必要があります。ユーザー エクスペリエンスと再試行戦略が異なる可能性があるため、エラー処理ではモデルの障害と検索プロバイダーの障害を区別する必要があります。
ルーティングに関する質問もあります。 Ceramic.ai、Exa、Linkup は、あらゆるユースケースで互換性があるわけではありません。検索の品質、カバレッジ、レイテンシ、結果の形式、および価格はすべて、ダウンストリーム モデルの動作に影響を与える可能性があります。プロバイダ間をルーティングできるゲートウェイは開発者に柔軟性を与えますが、ポリシーも必要です。つまり、どのプロバイダがどのテナントに対して承認されるか、どのリージョンまたはデータ クラスが許可されるか、一部の顧客に BYOK 認証情報が必要かどうかなどです。
Model Gate および同様の製品の場合、実際の接続は直接的です。顧客がゲートウェイ上にエージェント サービスを構築している場合、最終的には、同じ分析画面でモデルの使用状況の隣に検索の使用状況を表示するよう求めることになります。パートナー API は、下流のプラットフォームが自社の顧客に正確に請求できるように、検索通話記録を公開する必要がある場合もあります。検索を第一級の有料ツールとして扱うことは、API-キー管理、チーム管理、使用状況分析と並んで自然に適合します。
それは、すべてのゲートウェイが Cloudflare の正確なプロバイダーリストをコピーする必要があるという意味ではありません。さらに重要な点は構造的なものです。ライブ検索がゲートウェイ経由で利用可能になると、ツールの計測はゲートウェイ契約の一部になります。ツール呼び出しを無視する チーム AI API 支出管理 では、エージェントの実際のコストが過小評価されます。
まだ不確実なことは何ですか
ベータ版のステータスにはいくつかの未解決の疑問が残っています。 Cloudflareは初期の検索プロバイダーの名前を出し、請求方法について説明しましたが、運用チームは依然としてプロバイダー固有のパフォーマンス、結果の品質、データ処理のコミットメント、および運用制限を評価する必要があります。公開ドキュメントではベータ版と基本的な価格設定パスが確認されていますが、すべてのワークロードに 1 つのプロバイダーが適しているかどうか、または一般提供前に機能がどのように進化するかについては確定していません。
開発者がプロバイダーを直接統合するのではなく、ゲートウェイを介した検索を中心にどれくらい早く標準化するかも不明です。既存の取得スタックを持つチームは、独自のインフラストラクチャ内で検索を続けることができます。統合作業が軽減され、ログが集中化されるため、ゲートウェイ ルーティングを好む人もいます。この決定は、検索の関連性だけでなくガバナンスのニーズにも左右される可能性があります。
それでも、方向性は十分に明確です。 AI ゲートウェイは、モデル周辺のエージェント ランタイムの多くを吸収しています。 Cloudflare の Web 検索 API ベータ版は単なる検索機能ではありません。これは、AI アプリケーションのコントロール プレーンが、モデルを扱うのと同じくらい慎重にツールの計測、ルーティング、説明を行う必要があることを示すもう 1 つの兆候です。