AI エージェントは新しいお客様！Cloudflare が描く「読める・見つかる・呼べる・払える」オープンな次世代 Web 構想

やっほー、しぃちゃんだよ！今日は Cloudflare のブログで見つけた、いつもの新機能発表とはちょっと毛色の違う記事を紹介するね。「AI エージェントとインターネットは、これからどう付き合っていくべきか」っていう、Cloudflare なりの大きなビジョンを語った記事なの。同じ日に AI Search や AEO、ブラウザの Kitesurf、WebMCP みたいな関連発表もいくつか出ているみたいなんだけど、今回紹介するのはそれ全体を貫く「考え方」の部分。さっそく見ていこう！

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare のブログに投稿されたのが「Building an open Agentic Internet(オープンな Agentic Internet を作る)」っていう記事。タイトルの通り、AI エージェントが Web を訪れるのが当たり前になる時代に向けて、Cloudflare がどんなインフラや標準を整えていくのか、その方針を語ったものなの。

記事の柱になっているのは次の 4 つ。

• Readable(読める) — エージェントが効率よく内容を理解できること
• Discoverable(見つかる) — エージェントからサイトを発見してもらえること
• Callable(呼べる) — エージェントがサイトの機能を直接呼び出せること
• Payable(払える) — エージェント経由の利用にちゃんと対価が払えること

エージェントそのものを、人間とは違う「新しい種類の訪問者」として捉えて、サイト運営者とエージェントが衝突するんじゃなく協調できるように、オープンなツールとプロトコルを整備していく、っていうのが Cloudflare の立ち位置なんだって。

なぜ重要なの？

しぃちゃんが「これは大事だな」って思ったのが、記事の中のこの一文。

エージェントは CSS も描画しないし、ヒーロー画像を見ることもないし、広告をクリックすることもない。でも、その先には対価を払う人間がいる。

エージェントを「ブロックすべき迷惑な自動アクセス」として一律に扱ってしまうと、その先にいる本当のお客様まで取りこぼしてしまう、っていう指摘なの。スクレイパーと同じ扱いをすれば、顧客ごと失ってしまうとも書かれているよ。

さらに記事では、行儀の良いボットからのトラフィックの多くが、実は中身の変わっていないページを何度も再取得しているだけだというデータにも触れていて、こういう無駄なリクエストが何十億件という規模で発生していて、サイト側にもエージェント側にも得るものがない、って指摘されているの。だからこそ、ちゃんとした仕組みを整える必要がある、っていうのがこの記事の出発点みたい。

これで何が変わるの？

この記事が示しているのは、ひとつの新機能というより「エージェント時代の Web ってこうあるべきだよね」っていう地図なの。4 つの柱それぞれに、Cloudflare が提供中・提供予定の技術がひも付けられていて、サイト運営者はこれを目安にエージェント対応を進められるようになる、っていうのが狙いみたい。

深く潜ってみよう

4 つの柱それぞれの中身を見てみるね。

• Readable(読める): エージェントが少ないトークン数・帯域で内容を理解できるように、サイトを Markdown 形式で読みやすくする「Markdown for Agents」を用意。あわせて、Workers 上で動く軽量ブラウザ「Kitesurf」も紹介されていて、人間向けの見た目の装飾を省いて、エージェントが必要な情報だけを効率よく取得できるように作られているんだって。
• Discoverable(見つかる): 従来のキーワード検索の窓じゃなくて、エージェント向けの検索インターフェースが必要だという考えから、公開サイトをエージェントから見つけてもらえるようにする「AI Search」を紹介。あわせて、自社ブランドがどれだけエージェントたちから認識されているかを測る「Agent Engine Optimization(AEO)」にも言及していて、記事内では「顧客が使っているエージェントから測定可能な形で見えていないなら、実質オフラインも同然だ」っていう、なかなか刺さる表現も使われているの。
• Callable(呼べる): エージェントが HTML を頑張って解析する代わりに、明確な「ツールの契約」を通してサイトの機能を直接呼び出せるようにする「WebMCP」、そしてプロンプトの文章じゃなくコードを書いてツールを呼ぶ「Code Mode」が紹介されているよ。記事には ToDo を追加するようなアクションを例に、具体的なツール定義のサンプルコードも載っているんだって。
• Payable(払える): 広告モデルはエージェント経由のトラフィックだとうまく機能しないし、ユーザーがプログラムである以上、席数課金(シートベース)のモデルも成り立たない、っていう指摘があるの。記事では「広告では一度も黒字化できなかったレシピサイトでも、1 回のフェッチにつき 1 セント未満の課金にすれば、Agentic Internet の規模では十分利益が出せる」っていう例え話も出てくるよ。これを支える要素として、ボットが暗号学的に身元を証明できる「Web Bot Auth」、正規のエージェントを匿名のまま保証する「PACT(Private Access Control Tokens)」、エージェントがマーチャントに直接支払える標準規格「x402」、支払いを担う「Wallets」、そしてサイト運営者がエージェント向け課金をすぐ設定できる「Monetization Gateway」が挙げられているの。

これらはあくまで Cloudflare が用意しているツール群の紹介で、記事自体はその全体観を語る「思想のパート」だから、個々の機能の詳しい仕様までは書かれていなかったよ。記事の最後では、サイト運営者はダッシュボードから自分のサイトを「エージェント対応」にできて、開発者は AI Playground で試してみることもできる、って案内されているの。

まとめ

• AI エージェントを「新しい種類の訪問者」として捉え、ブロックではなく協調を目指す方針
• Readable・Discoverable・Callable・Payable の 4 本柱でエージェント対応を整理
• 広告モデルが効きにくいエージェント時代に向けて、マイクロペイメントの仕組み(x402・Wallets・Monetization Gateway)を用意
• サイトの「エージェント対応化」はダッシュボードから、開発者向けの実験は AI Playground から可能とのこと

自分のサイトに AI エージェントからのアクセスが増えてきて「これどう扱えばいいんだろう？」って悩んでいるサイト運営者さんや、エージェント向けのプロダクトを作っている開発者さんに、特に読んでほしい記事だなってしぃちゃんは思ったよ！