Cloudflare Web Search APIとは​──AIの​回答を、​検索結果と​原文で​確かめる

Cloudflare Web Search APIは、インターネットの検索結果を、AIを使うアプリへ渡すための仕組みです。Cloudflareは2026年10月2日に発表し、10月5日時点の公式ドキュメントではオープンベータとして案内しています。^[1][2]

料金や提供条件を調べるとき、AIには今日の情報を読んで答えてほしいものです。Web検索は、そのための材料を集める入口になります。ただ、出典リンクが付いていることと、回答がその出典に沿っていることは別です。

この記事では、検索結果から元ページへ進み、日付と条件を確かめてから回答に使う流れを整理します。仕様と料金は2026年10月5日に取得した公式資料に基づきます。Web Search APIの実行、回答生成、日本語の検索精度の比較は未実施です。

APIは、プログラムから別のサービスを呼び出すための窓口です。Web Search APIへ調べたい言葉を送ると、検索結果を受け取り、自社のアプリやAIの回答作成に使えます。

2026年10月5日時点では、検索先としてCeramic.ai、Exa、Linkupを選べます。CloudflareのAI Gatewayが問い合わせを中継し、検索先の結果を共通の形式にそろえます。AI Gatewayは、AIへのリクエストや費用、ログなどを管理するサービスです。^[3]

利用経路は、既存のサーバーから呼ぶREST APIと、Cloudflare Workersから呼ぶ方法があります。Workersは、アプリの処理をCloudflare上で実行するサービスです。検索を頼み、結果をAIへ戻す部分は、アプリ側で組み立てます。^[4]

10月2日の発表では、AI Gatewayに組み込む「Server Tools」は今後の提供予定として紹介されています。現行の利用ガイドも、アプリ側で検索ツールを定義し、検索結果をモデルへ渡す例です。検索APIが使えることと、回答までの処理が完成していることは分けて考えます。^[1][4]

社内資料を登録して探す用途は、前回のCloudflare AI Searchの記事で扱いました。今回は、外部Webの情報を探し、判断に必要な条件を確認することが中心です。

標準の検索結果にはURLとタイトルが入り、説明文や画像、最終更新日などは検索先から返された場合に含まれます。説明文は必ず付く項目ではありません。^[3][4]

これらの情報には、それぞれ役割があります。

とくに、最終更新日は発表日と同じとは限りません。以前の発表ページに説明が追加されれば、ページの更新日だけが新しくなる場合があります。「最近見つかったページ」と「最近発表された機能」を混同しないよう、元ページの発表日や変更履歴を読みます。

Cloudflareは、検索先に対して取得元へのリンクを返すことや、サイト側の巡回ルールを尊重することを求めています。これにより情報の取得元をたどれますが、記事の内容やAIの解釈まで正しいと保証する仕組みではありません。^[3]

業務で使う情報では、短い抜粋に入りきらない条件が結論を変えます。たとえば「新機能を提供」という説明だけでは、試験提供なのか正式版なのか、自社の契約で使えるのかまでは分かりません。

確認を進めるなら、次の順序が役立ちます。

1. 検索結果から、確認したい事実に合う公式ページを選ぶ。
2. 元ページで発表日・更新日・適用日を確かめる。
3. 対象プラン、提供地域、事前設定、追加費用を読む。
4. 回答に使う一文を、該当する原文と照合する。

「使えます」という回答なら、その原文が現在の提供を説明しているかを確認します。「今後提供する」「申請を受け付ける」という記述を、すでに使えるという意味へ縮めないためです。

この確認は、回答を長くするためのものではありません。読んだ条件の範囲で答えるための工程です。公式資料を開けなかった項目や、契約によって変わる項目は、確認できていないことを回答に残します。

具体例として、「Cloudflare Web Search APIを仕事用アプリに使うには何が必要か。検索から回答まで自動で作れるか」を考えます。

ここではWeb Search APIを実行した結果ではなく、この記事の制作で公式ページを実際に読み合わせた結果を示します。2026年10月5日時点では、次のように整理できます。^[1][2][4]

この場合、回答は「オープンベータの検索APIをアプリから呼べる。検索結果を使った回答作成は、利用側で組み込む」とまとめられます。自社のアカウントで接続できることは、別途確認が必要です。

実際の業務アプリでは、回答の横に「確認したページ」「条件の該当部分」「確認日時」を表示すると、読む人が原文へ戻れます。日本語の質問から英語の公式資料を読む場合も、翻訳した文章だけで判断せず、対象や時制を原文へ戻って確かめる流れを作れます。

2026年10月5日時点のCloudflareの提供者別ドキュメントには、次の料金とデータ保持の対応状況が掲載されています。^[5]

料金の単位は検索リクエストです。アプリが一つの質問について言葉を変えて検索し直すなら、利用者の質問数と検索リクエスト数は一致しません。

また、検索単価への上乗せがないことと、購入時の手数料がないことは別です。Web Search APIは検索先のAPI単価に追加の上乗せをしないと案内しています。一方、AI GatewayのUnified Billingの説明には、購入するクレジットに5%の手数料がかかると明記されています。^[5][6]

検索先のAPIキーを登録して使うBYOKでは、検索先との契約に基づき検索先から直接請求されます。BYOKは「自分が契約したサービスのAPIキーを使う」方式です。購入クレジットで払う場合と、請求経路を分けて見積もります。^[5]

この表は検索部分の費用です。回答に使うモデルの料金など、アプリ全体の費用は別に積み上げます。今回、日本語での検索品質や処理速度は比較していないため、価格の違いから検索の良し悪しまでは判断できません。

データ保持についても、見る場所が二つあります。表のZero Data Retention（ZDR）は、検索先が問い合わせデータを保持しない扱いに対応しているかという表示です。AI Gateway側のログ設定は別に確認します。公式のログ仕様では、ログは初期状態で有効で、入力・応答などを含み得ると説明されています。^[5][7]

検索先でZDR対応を選んでも、それだけでアプリ全体の保存がゼロになるわけではありません。公開情報の調査なら、まず製品名と確認したい条件だけを検索へ送る形にできます。顧客名や未公開の計画も送る業務では、送信先、ログの保存設定、閲覧できる担当者を確認します。

最初の対象として考えやすいのは、製品の提供条件など、公開された一次資料で確かめられる調査です。質問の範囲を絞れば、必要なページにたどり着けたか、回答に条件が残っているかを見やすくなります。

試す前に、次の四つを決めておきます。

• 調査対象：何を調べ、どの公式資料を優先するか。
• 回答の表示：出典と確認日時、分からなかった項目をどう残すか。
• 確認担当：契約や対外説明に使う回答を、誰が原文と照合するか。
• 費用とデータ：検索の回数、支払い方法、送る情報とログ設定をどう管理するか。

評価では、自然な日本語で答えられたかに加えて、根拠となるページにたどり着けたか、古い情報や提供予定を現在の条件として扱っていないかを見ます。APIが応答することと、業務の判断に使えることを別々に確かめます。

Web Search APIは、AIに外部Webの情報を渡す入口になります。その入口から、元ページを読み、条件を確認し、回答へ反映する流れまで作ると、調査した人が根拠に戻れる仕事の道具になります。