Cloudflare Agents SDK に web_search ツールが追加。Web Search API（ceramic.ai / Exa / Linkup）がエージェントの標準ツールとして呼べるようになった

要約

Cloudflare Agents SDK に web_search ツールが追加されました。モデルがクエリと最大件数を指定すると、Cloudflare Web Search API 経由で公開 Web を検索します。

「Web Search API はもう出ていたはずだ」と思った人は正しいです。 だからこそ今回の変更の意味を、順番に分けて見る必要があります。

1つ目の段階は 2026-10-02 でした。 Cloudflare が Birthday Week に AI Gateway 経由の Web Search API を公開しました。検索プロバイダーは ceramic.ai / Exa / Linkup の3社で、Cloudflare はマージンを上乗せせずパートナーのリスト価格そのままで中継し、課金は AI Gateway のクレジットを消費する、という設計でした。呼び出し経路は REST API と Workers Bindings の2つで、**AI Gateway 内の Server Tools は「近日」**とされていました。

2つ目の段階が今回です。 その検索が、Agents SDK のツール定義として最初から用意された状態になりました。開発者が OpenAPI 的なツールスキーマを自分で書いてモデルに渡す必要がなくなります。

つまり変わったのは能力ではなく、能力の置き場所です。 検索自体は10日前からできました。今回入ったのは「エージェントを作るときの既定の部品として並んでいる」という状態です。

結果の形式は意図的に軽くなっています。 返るのはタイトル・URL・切り詰めた説明文の短い番号付きリストです。本文は返りません。これは文脈長を食わないための設計で、本文が必要なら同時に追加された web_fetch ツールで読むという分担になっています。

実際、2つを併せて渡すと、モデルへの指示自体が変わります。 公式は「web_fetch も渡した場合、web_search が返したページを web_fetch で読むようモデルに指示される」と書いています。「検索 → 選ぶ → 読む」という2段構成が、ツール定義の側に埋め込まれていることになります。

導入は Pi Durable harness が正式な案内です。

import { webSearchTool } from "agents/websearch/pi";

// PiHarness の harness コールバック内
this.registry.install({
  name: "web-tools",
  tools: [webSearchTool({ binding: this.env.AI, provider: "exa" })],
});
return Harness.open(storage, { models, registry: this.registry }, context);

AI SDK と TanStack AI 向けのアダプタも同梱されています。 またモデルを介さずに検索だけしたい場合——定期ジョブで情報を集めるような用途——には agents/websearch の createAIWebSearch() / createHTTPWebSearch() が使えます。

必要バージョンは Agents SDK v0.27.0 以降です。

公式 changelog に書かれていないことを明示します。 出ているオプションは binding と provider の2つだけで、設定項目の全量とエラーハンドリングは docs 側に委ねられています。価格・課金の記載もありません。 Web Search API 本体の課金（AI Gateway クレジット、マージン無し）に従うと読むのが自然ですが、changelog 上の明記はありません。

何が変わったか

• Agents SDK に web_search ツールが追加された
• 検索は Cloudflare Web Search API 経由。バックエンドは ceramic.ai / Exa / Linkup、例では provider: "exa"
• モデルが渡すのはクエリと最大件数
• 結果はタイトル・URL・切り詰めた説明文の番号付きリスト（本文は返らない）
• web_fetch を併せて渡すと、検索結果のページを web_fetch で読むようモデルへ指示される
• 導入は Pi Durable harness（agents/websearch/pi の webSearchTool を registry.install() で登録）
• AI SDK / TanStack AI アダプタ同梱
• モデル不要の検索関数 createAIWebSearch() / createHTTPWebSearch() も提供
• 必要バージョンは Agents SDK v0.27.0 以降
• changelog 上のオプションは binding と provider のみ。価格・課金の記載は無い

業務インパクト（一般企業向け）

最初に、この変更が節約するものを具体的に言います。

社内でリサーチ系・RAG 系のエージェントを作ると、最初の2週間はだいたい「検索の調達」で消えます。 検索 API をどこから買うか（Bing は終了、Google は制限、Exa / Brave / Serper を比較）、契約と請求をどう通すか、レート制限をどう扱うか、返ってきた HTML をどう本文だけ抜くか。AI の部分ではない作業です。

今回の変更は、この部分を既定の部品に置き換えます。 検索は Cloudflare 経由で3社のどれかに繋がり、課金は AI Gateway に寄り、ツール定義は SDK が持っています。稟議で通す契約が1本減るのは、技術的な利点より先に効く点です。

次に、注意すべき点を3つ挙げます。

1つ目は、検索プロバイダーの選択が設定値になったことです。 provider: "exa" のようにコードの1行で切り替わります。 これは柔軟さですが、同時に**「どのプロバイダーを使っているか」が構成管理の対象になる**ことを意味します。プロバイダーによって検索結果の性質は違い、結果が変われば回答も変わります。 評価用のテストセットを持っていない状態で provider を切り替えると、品質の変化に気付けません。どのプロバイダーで評価したかを記録する運用が要ります。

2つ目は、情報の経路が増えたことです。 エージェントが公開 Web を検索し、その結果を読むようモデルへ指示される——これは外部のテキストがモデルの文脈に入る経路です。プロンプトインジェクションの観点では、検索結果の説明文も、web_fetch で読むページ本文も、信頼できない入力です。公式は web_fetch 側で許可ホストを制御できると書いていますが、検索から来る URL は事前に分からないため、許可ホストで縛る設計と検索の自由度は原理的に衝突します。エージェントに権限のある操作（社内 API の更新、メール送信）を持たせている場合、検索結果を読ませる設計は別途審査すべきです。

3つ目は、課金の見通しです。 changelog には価格の記載がありません。Web Search API 本体は AI Gateway のクレジットを消費し、マージン無しという発表でした。ただしエージェントがツールとして呼ぶようになると、呼び出し回数は人が押すボタンの数ではなくモデルの判断の数になります。 リサーチを1回させると検索が5回走る、という状況は普通に起きます。上限を決めずに本番へ出さないのが実務上の結論です。モデルが渡す「最大件数」も、コスト側のパラメータとして扱ってください。

実務としてやることは2つです。 (1) 既に Exa / Brave などと個別契約している場合、契約を1本に寄せられるかを試算する。(2) 検索結果を読ませるエージェントの権限棚卸しを先に行う。読むだけのエージェントと、書き込み権限のあるエージェントで、同じ設計を使わないと決めるだけで事故の種類が減ります。

副業・個人活用視点

この変更が個人開発に効くのは、「作り始めるまでの距離」が短くなる点です。

リサーチエージェントを作ろうとすると、最初に止まるのは検索 API の契約です。クレジットカードを登録して、無料枠を確認して、レート制限を読む。ここで熱が冷めます。Agents SDK に最初から入っていれば、その日に動くものが作れます。

案件として受けやすい形も見えます。 「社内の調べ物を自動化したい」という相談は多く、最も多い失敗は、調べた結果の出典が追えないことです。今回の構成では検索結果が URL 付きで返り、web_fetch で読んだページの最終 URL と HTTP ステータスもモデルに渡ります。 つまり出典を残す作りが標準で用意されているので、「どこから取った情報か」を成果物に残す提案がしやすくなります。これは納品物の信頼性に直結する差別化点です。

単価の付け方としては、「検索の品質管理」を切り出すのが現実的です。

provider が1行で切り替わるということは、切り替えて比較できるということです。顧客の業務で使う実際のクエリ20本で ceramic.ai / Exa / Linkup を比較し、どれが向いているかを記録した表を作る——これは誰でもできるが、誰もやらない作業です。公式は3社を並べているだけで、どれが何に向くかは書いていません。公式に書かれていない情報は、自分で測れば資産になります。

コンテンツの題材としても使えます。 「検索 API の選び方」という記事は多いですが、**「エージェントのツールとして呼ぶときに何が変わるか」**は手薄です。呼び出し回数がモデルの判断で決まる、結果の形式が文脈長を前提に設計されている、検索結果がインジェクションの経路になる——実際に動かさないと書けない論点が揃っています。

注意点を1つ。 価格が changelog に明記されていません。個人の検証でも上限を決めてから回してください。 モデルが検索を何回呼ぶかは、書いた本人にも事前には分かりません。