Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

Cloudflare が Web Search API を beta で公開、AI エージェントに「今の検索結果」を持ち込めるようにした

AI にウェブ検索をさせる話は珍しくありませんが、今回の Cloudflare の発表は少し性格が違います。単に検索機能を足したのではなく、AI Gateway の中に Web Search API を置き、ログ管理や課金、プロバイダー選択までまとめて扱える形にしたからです。生成AIが「知っていること」だけで答えるのではなく、今この瞬間の情報を引いて応答する流れは、実運用ではかなり重要になります。しかも今回は、Cloudflare 側の枠組みを使いながら、複数の検索プロバイダーを選べる点が目を引きます。

Cloudflare の Web Search API でできること

Cloudflare は 2026年10月2日、Web Search API を beta で提供開始したと告知しました。これは AI agents やアプリケーションがインターネットを検索し、その結果をもとに回答を組み立てるための機能です。言い換えると、モデルの学習時点で止まった知識に頼るのではなく、ライブの情報を取り込んで返答できるようにする仕組みです。元記事では、URLを推測したり、学習データの範囲を前提にしたりするやり方より、実際の検索結果を使うほうがよい、と位置づけています。

利用開始時点で選べる検索プロバイダーは Ceramic.ai、Exa、Linkup の3つです。いずれも Cloudflare 経由のリクエストに対して Zero Data Retention をサポートし、さらに Cloudflare の verified bot crawling standards にもコミットしているとされています。ここは、単なる検索機能の寄せ集めではなく、外部プロバイダーとの接続ポリシーまで揃えようとしている部分です。

課金とログの扱いも Cloudflare らしい設計です。Web Search API は AI Gateway 経由で動くため、検索リクエストは gateway logs に記録され、料金は各プロバイダーの list API price をそのまま AI Gateway credits で支払う形になります。Cloudflare は追加の上乗せ料金を取らないとも説明しています。必要なら、利用者が自分の provider API key を持ち込むこともできます。

呼び出し方は REST API でも Worker でも用意されています。REST API では https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/websearch/ に POST し、query、provider、limit、options.gateway.id などを指定します。本文中の例では、Salt Lake City で秋の到来前に何を楽しめるかを尋ねる query を投げ、provider を ceramic にしたり、exa にしたりしています。Worker 側では env.AI.websearch() を使い、gatewayId: "default"、query、provider、limit を渡す形です。最後に、開始手順は “How to use Web Search API” を参照するよう案内されています。

検索を「機能」ではなく「運用」に落としたのがCloudflareらしい

この発表で面白いのは、Web Search API そのものより、Cloudflare がそれをどう包んでいるかです。検索を AI に足すだけなら、他社も似たことはできます。でも Cloudflare は、AI Gateway、ログ、課金、プロバイダー切り替えを一つの流れにして見せている。ここに、この会社の強みがかなりはっきり出ています。個別のAI機能を売るのではなく、運用の摩擦を減らすインフラとして置いているわけです。

これは実務では効きます。AI に外部検索を許すと、まず気になるのは「どこに何を投げたのか」「あとで追えるのか」「請求がどうなるのか」です。モデルの回答品質より先に、監査やコスト管理の話が来る。Cloudflare はそこを先回りして、gateway logs に残ることや、list API price のまま請求されることを前面に出している。派手さはないですが、導入判断にはこの手の条件のほうが効きます。検索精度のデモより、運用のしやすさで選ばれるプロダクトにしようとしているのだと思います。

Zero Data Retention と verified bot crawling standards が意味するもの

Zero Data Retention という言葉は、AI 周りではかなり重いです。検索クエリには、未公開の製品名、社内計画、顧客情報の断片が混ざることがあります。だから「検索できる」だけでなく、「その検索内容がどこまで残るのか」が本当は本丸です。元記事が最初にそこを押し出しているのは、Web Search API を単なる便利機能としてではなく、企業利用を意識したものとして見せたいからでしょう。

もう一つの verified bot crawling standards も地味ですが重要です。検索基盤を使う側からすると、検索元のサイトとの関係が荒れると困ります。クロールの作法が曖昧だと、後で検索結果が不安定になったり、ブロックが増えたりする。Cloudflare は、自社のネットワークやボット制御の文脈に近いところで、プロバイダー選定の安心材料を用意しているように見えます。ここは単なる技術仕様というより、検索を継続運用するための社会的な整備に近いです。

料金体系が「AI の検索コスト」を見えやすくしている

この Web Search API は、使いやすさだけでなく、支払いの見通しが立てやすいのがポイントです。Cloudflare が追加マークアップを載せず、各プロバイダーの list API price のまま AI Gateway credits で請求する、と明示しているからです。AI 機能は後からコストが膨らみやすく、検索のたびに外部APIを叩くとなると、開発者は「どこで金額が跳ねるのか」を気にせざるを得ません。その不安を少しでも減らそうとしているように見えます。

ただ、ここには逆に、コストがシンプルに見えるぶん、使い方の設計責任が開発者側に戻ってくる面もあります。検索の limit をいくつにするか、どのタイミングで検索するか、結果をそのまま全部モデルに流すのか。こうした設計次第で、同じAPIでもかなり費用感が変わるはずです。Cloudflare はその自由度を残しているので、便利ではあるけれど、雑に使うとすぐ高くつく種類の機能でもあります。

AI エージェントの競争は「賢さ」より「接続先の厚み」に移っている

今回の発表を見ていると、AI エージェントの競争軸が少し変わってきたと感じます。以前は、モデルがどれだけ賢いか、どれだけ長く文脈を保持できるかが前に出ていました。けれど実際の業務では、外部情報にどう安全に繋がるか、どのサービスとどう組めるかのほうが大事になる場面が増えています。Web Search API は、その流れにかなり素直に乗った機能です。

しかも Cloudflare は、検索を単独商品として切り出すのでなく、Workers や AI binding とつなげられるようにしている。つまり、検索で拾った情報をそのままエージェントの処理に流し込む道筋を、最初から短くしているわけです。こうなると、強いのは「最高の検索エンジン」より「自分のAI基盤に最も自然につながる検索エンジン」です。Cloudflare はそこを狙っているのではないでしょうか。AI の時代らしい話ですが、結局は接続の地の利がものを言う、というかなりインフラ的な勝ち筋に見えます。

参考: Introducing Web Search API

同じ著者の記事

CloudflareとStripeが、AIエージェントに「アカウント作成から本番デプロイまで」任せる時代を始めた

CloudflareとStripeが、AIエージェント向けの新しい protocol を公開した エージェントが Cloud account の作成、domain の取得、subscription の開始、production への deployment まで行える 支払いと本人確認は Stripe が担当し、デフォルトの月額上限は $100 人間が関与するのは主に「法的・金銭的に重い場面」 便利さは大きいが、間違ったdomain購入や予算超過などのリスクも現実的 Cloudflare と Stripe が、AI agent による “自動 provisioning” を可能にする protocol を公開しました。 ここでいう provisioning は、ざっくり言うと「サービスを使い始めるための初期設定一式を用意すること」です。普通なら人間が dashboard を開いて、アカウントを作り、支払い方法を入れ、API token を発行して、必要なら domain を買って、最後に deploy する。あれを AI agent がまとめてやるわけです。 InfoQ の記事によると、

papoo.work

CloudflareがClefを出した理由は「決定」をAIに任せるためだった

Cloudflareが、少し変わった位置づけのAIモデルを公開した。名前はClefとClef-flash。大規模言語モデルのように文章を長々と生成するのではなく、入力を見て「この案件は急ぎか」「どのチームに回すべきか」といった判断を、速く安定して返すための decision model だ。しかも今回は、単にモデルを出しただけではない。自社で学習したモデルを Workers AI で提供しつつ、開発者が自分のデータでその判断モデルを強化できる新しい reinforcement learning（RL）基盤まで同時に打ち出している。AIが「言葉を作る」段階から「業務の分岐を決める」段階へ少し進んだ、という話として読むと分かりやすい。 元記事は、まず最近注目が集まっている decision model という考え方を説明している。Cloudflareが例に挙げているのは Typesafe AI の Jev System One で、これは従来の classifier model を少し発展させたものだという。こうしたモデルは、曖昧な会話を続けるためではなく、決められた形式の出力を、安く、速

papoo.work

Cloudflareが「次のGit基盤」を募集する理由

GitHubのような仕組みは、人間がコードを書き、ブランチを切り、レビューして取り込む世界を前提にしてきた。ところがCloudflareは、これからのソフトウェア開発はAI agentが主役になると見ている。しかもそのagentは、補助的な存在ではなく、修正、機能追加、テスト、レビュー、依存関係の更新まで担う。そこで同社は、そうした世界に合う“次のGitプラットフォーム”をCloudflare上で作ってほしいと呼びかけた。単なる製品発表というより、開発の土台そのものを誰がどう設計するかを問う企画だ。 元記事でCloudflareがまず置いている前提は、開発の中心が人間からagentへ移りつつある、という見方だ。いまのGitHubは、人間同士がリポジトリを共有し、ブランチやコミット、issue、pull requestで協業するための仕組みとして育ってきた。しかし、これからは数百、あるいは数千のagentが同じコードベースに同時に触るかもしれない。そうなると、従来の前提だけでは足りない。ほかのagentが何をしているのかをどう把握するのか、変更が衝突したらどうするのか、レビューをどう回す

papoo.work

CloudflareがOHTTP Gatewayを閉鎖型ベータで公開、Privacy GatewayはOHTTP Relayへ改称

Cloudflareが、OHTTPを使った新しいゲートウェイ機能を閉鎖型ベータとして始めると発表した。あわせて、これまでの「Privacy Gateway」は「Cloudflare OHTTP Relay」に名前を変える。単なる名称変更ではなく、OHTTPの仕組みを前面に出して、RelayとGatewayの役割分担を分かりやすくする狙いがある。プライバシー保護をアプリの外側ではなく、通信の土台に組み込もうとしている点がこの発表の核心だと思う。 元記事が伝えているのは、Cloudflareが「Cloudflare OHTTP Gateway」を新しく閉鎖型ベータで提供し始める、という案内だ。これはCloudflareのZoneに対する有料の追加機能として使えるようになり、利用者は少ない手順でOHTTPトラフィックを受け取れるようになる。記事では、利用希望者向けに waitlist への登録フォームも案内している。公開範囲をいきなり広げるのではなく、まずは招待制に近い形で顧客を受け入れる流れだ。 背景にあるのは、オンラインプライバシーの負担が利用者側に偏っている、というCloudflare

papoo.work

Cloudflareが見た「安全なAIモデル」の実力：Mythos Previewは何がすごくて、何がまだ足りないのか

Cloudflareは、セキュリティ用途のLLMを自社インフラ上の実コードに当てて検証している Anthropicの Mythos Preview は、単にバグを見つけるだけでなく、複数の弱点をつないで実際に悪用できる形にするのが強い PoC（proof of concept） まで作るので、「怪しい」ではなく「本当に再現できる」段階まで持っていける ただし、モデルの拒否（refusal） は一貫しておらず、同じ内容でも言い方次第で結果が変わる いちばん大きな課題は、AIそのものよりも運用の形。単発チャットではなく、複数の役割を持つharness（実行基盤） が必要 人間が読む前の自動判定では、ノイズをどう減らすか が超重要になる Cloudflareが公開したこの記事は、AIを使った脆弱性調査の「現場感」がかなり濃いです。 しかも単なる未来予想ではなく、実際に自社の50以上のリポジトリに Mythos Preview を当ててみた結果がベースになっています。 率直に言うと、この記事の面白さは「AIがバグを見つけました」で

papoo.work

CloudflareがAIエージェント向けに「仮のアカウント」を用意した話

Cloudflareが、AIエージェント向けに Temporary Cloudflare Accounts を提供し始めました。ざっくり言うと、AIが「コードを書いたあと、すぐにデプロイまで進みたい」ときに、人間向けの面倒な登録作業を飛ばせる仕組みです。 これ、地味に見えてかなり大きいです。AIはコードを書くのは得意でも、そのあとに出てくる「ブラウザでログインして」「OAuthを通して」「API tokenをコピペして」「2段階認証を入れて」みたいな壁で止まりがちでした。Cloudflareはその壁を、かなり正面から壊しにきた、という印象です。 AIエージェントが、Cloudflareにすぐデプロイできるようになった `wrangler deploy --temporary` で、60分だけ使える仮アカウントを作れる その場でデプロイして、結果を確認し、何度でも修正できる 気に入ったら、あとからその仮アカウントを自分の正式なアカウントとして引き取れる 何もしなければ60分で自動削除される CloudflareはStripeやWorkOSとも組んで、エージェントの「登録の面倒」を

papoo.work

Cloudflare TurnstileがWebGLの“指紋”を要求してくる話

CloudflareのTurnstileが、一部のブラウザで無限ループして先に進めなくなった 原因は、WebGLの情報を使った fingerprinting（端末の識別）を要求していること 筆者はこれを、「人間かどうかの確認」ではなく、実質的な追跡のためだと批判している WebKit系ブラウザではこの種の fingerprinting が長くブロックされており、その結果 WebKitGTK 系ブラウザが締め出される形になっている Firefoxでも、fingerprinting 防止の設定まわりに微妙なズレがあると指摘されている この記事が扱っているのは、Cloudflareの Turnstile という仕組みです。 これはサイト側が「あなたは人間ですか？」を確認するための device verification、つまりボット対策の一種です。 ただ、筆者の環境ではこの Turnstile がずっと回り続けて終わらない状態になってしまい、結果としていくつものWebサイトにアクセスできなくなったそうです。 これ、地味にかなり痛

papoo.work

Cloudflare が Python Workers を正式公開した意味

Cloudflare が、Workers 上で Python を本格運用できる「Python Workers」を一般提供に切り替えました。これまでも試せはしたものの、今回は「実験」から「正式な選択肢」へ格上げされた形です。TypeScript だけでなく Python でも、Cloudflare のエッジ実行基盤にそのまま乗せられるようになったのが大きい。しかも D1、R2、Workers AI など周辺サービスとも JavaScript の接着コードなしでつなげる、と Cloudflare は強く打ち出しています。 元記事が伝えているのは、Cloudflare が Python Workers を generally available、つまり一般提供にしたという発表だ。Python Workers は、Cloudflare Workers の実行環境の中で Python アプリを動かす仕組みで、Cloudflare によれば、これで Python は Developer Platform の「first-class」、つまり最初からきちんと支える言語になった。単に Python が

papoo.work

CloudflareがK2を出した理由は、「落ちないイベントの通り道」を作るためだった

Cloudflareが、サーバーレスの event streaming サービス「K2」を public beta として公開した。Kafka のような仕組みを連想すると分かりやすいが、K2 はクラスタ運用を前提にした製品ではなく、Cloudflare の Developer Platform 上で動く“耐久性のあるログ”として設計されている。記事の中心にあるのは、送信側と受信側の速度や稼働状況をそろえなくても、イベントを失わずに受け渡しできるようにする、という発想だ。Cloudflare はこれを自社の Pipelines 向けに必要になった機能として説明していて、単なる新製品紹介というより、同社のストレージや処理基盤の組み合わせ方を示す話でもある。 元記事がまず問題にしているのは、従来の RPC 型の構成では、送信側と受信側が同じ速度で動いていないとイベントを失いやすい、という点だ。たとえば送信元が大量のデータを吐き出したのに、受け手や下流サービスが追いつかなければ、処理しきれない分が落ちる。しかも受信側が複数あると、analytics 系と fraud detection 系のよ

papoo.work

Deno が Cloudflare に合流する意味

Deno が Cloudflare に入る、というニュースは、単なる企業買収の話ではない。JavaScript の runtime と hosting をどう組み合わせるか、そしてそれを AI 時代のサーバー基盤にどうつなげるか、という流れの話だ。元記事を書いた Ryan Dahl は、Deno を「より簡単にサーバーソフトを作るための試み」として積み上げてきたが、その延長線上にある次の舞台として Cloudflare を選んだ。Deno を使ってきた人には影響が大きい一方で、Web の実行基盤がどこへ向かうのかを示す出来事でもある。 元記事は、Deno がここまで何を目指してきたかを振り返るところから始まる。JavaScript でサーバーソフトを書くとき、モジュールの配り方はどうあるべきか、runtime はどこまで安全性を保証できるのか、ツールチェーンはどこまで一体化できるのか、そしてアプリを独立した実行ファイルとして配布しやすくできるのか。Deno チームはそうした問いを重ねてきたという。Node.js との互換性も、その過程で重要になった。利用者は Deno の改善を求めつつ

papoo.work