Cloudflareが企業のAIコスト爆発を制御、AI Gatewayに利用上限を搭載
企業におけるAI導入の最大の壁はもはや技術力ではない。管理不能なコストの爆発だ。2026年6月5日、Cloudflareは自社のAI Gatewayに新たな「利用上限」機能を搭載し、この課題への直接的な解決策を提示した。
多くの企業では全エンジニアに最先端モデルのAPIキーを共有している。月末に届く高額な請求書を見て、経理とCTOが頭を抱える。誰が何に使ったのか全く分からないのだ。Cloudflareの今回の発表は、まさにこの無法地帯に統制をもたらすものだ。
併せて発表されたアイデンティティベースの予算管理は、Cloudflare Accessと既存のIdP（Identity Provider / アイデンティティプロバイダー）を組み合わせ、個人やチーム単位での正確なコスト帰属を実現する。
なぜAIコストは制御不能に陥るのか
AI導入を進める企業で、まったく同じストーリーが繰り返されている。現場には「まずは最速でAIを使え。勘定は後でなんとかする」という号令が飛ぶ。これは大抵の場合うまくいく。実際、AIを積極的に取り入れたチームの生産性は飛躍的に向上している。しかし、その代償は安くない。月末に経理がAPI利用料の請求書を開くと、にわかには信じがたい桁の数字が目に飛び込んでくるのだ。
Cloudflareのブログ記事でも、この構図は明確に描写されている。社内で共有されているAPIキーでは、コストの発生源を追跡できない。機械学習チームの新規パイプライン構築が原因なのか、インターンがメールの仕分けに高額なClaude Opusを使い倒したのか、あるいはCI/CDジョブが週末のうちに何千万トークンも消費したのか、誰にも分からない。
問題の本質は、指標と制御の欠如により、合理的な判断が歪められてしまうことにある。予算も可視化もなければ、常に最も強力で高価なモデルを選ぶのが個々のエンジニアにとっては合理的な行動となる。コードレビューの要約に、大規模なアーキテクチャ再設計と同じモデルは必要ない。ログパーサーに、顧客向けコンテンツ生成と同じモデルは不要だ。しかし、現場には適切な道具を選ぶ動機も手段も存在しなかったのである。
利用上限機能を深掘りする
中核となる仕組み
AI GatewayはアプリケーションとAIプロバイダーの中継点として機能する。OpenAIやAnthropicへの直接APIコールを、まずこのゲートウェイを経由させる仕組みだ。これにより、リクエストの永続化ログ、キャッシュ、レート制限、リトライ、分析といった恩恵が得られていた。しかし、従来は「誰がいくら使ったか」の正確なトラッキングに限界があった。
ここに新たに導入された利用上限機能は、真のコスト統制を実現する。トークンベースではなく、ドルベースの予算で累積支出を追跡する点が実務的だ。制限のスコープは、モデル、プロバイダー、ユーザーやチームといった管理者定義のカスタム属性の任意の組み合わせで設定できる。期間も固定（月初リセットや月曜リセット）かローリング（直近N日間）かを選べ、日次、週次、月次での運用が可能だ。
予算超過時の現実的な選択肢
最も重要なポイントは、上限到達時の処理だろう。デフォルトではリクエストをブロックする。だが、ワークフローを完全に止めないための工夫として、ダイナミックルートと連携したフォールバックモデルへの切り替えが可能だ。これなら、最大予算額に達してもエンジニアの作業が完全に停止することはない。
この機能群は本日から全プランの全ユーザーにオープンベータとして提供されており、ダッシュボードかAPI経由で即座に設定できる。
アイデンティティ駆動の予算管理がもたらす透明性
利用上限機能と同時に、Cloudflareはアイデンティティベースの予算とポリシーを限定ベータとして発表した。利用上限がモデルやカスタム属性による制御であるのに対し、こちらは実在の個人とチームに紐づく。アプリケーション側でメタデータを渡す必要はなく、信頼性の低いヘッダー情報に頼る必要もない。
Cloudflare Accessとの統合が生む確実な帰属
AI GatewayをCloudflare Accessと連携させると、リクエストの送信者が誰かを確実に特定できる。単なるアカウント単位ではなく、個々の従業員、IdPグループ、サービス単位だ。Cloudflare社内では既にこの仕組みを実践しており、全従業員がAIツールを利用する中で月間数十億トークンが流れるトラフィックを可視化している。
仕組みはシンプルだ。従業員がCloudflare Access経由で認証されると、そのアイデンティティがJWT（JSON Web Token）から抽出され、AI Gatewayのリクエストにメタデータとして添付される。これにより、ユーザー単位のトークン消費、チーム単位の使用量内訳、組織全体のコスト帰属が一元管理できるようになる。
CI/CDパイプラインへの適用とボット予算
この機能は人間だけのものではない。Accessサービスアカウントを利用すれば、自律的なエージェントやCI/CDパイプラインにも名前付きのIDを付与できる。コードレビューボットが今週500万トークンを消費し、ドキュメント生成器が50万トークンだった、といった詳細が手に取るように分かる。あるエージェントが制御不能に陥ったとしても、他のエージェントに影響を与えることなく個別に予算ポリシーを適用できるのだ。
Cloudflare自身、全社でこのスタックを運用した経験に基づいて本機能を公開した。自社で構築したものを他社もゼロから作る必要はない、という明快なスタンスである。
次の段階はコスト最適化の自動化
予算を設定し可視化することは、第一段階に過ぎない。次の課題は、限られた予算で最大の成果をどう引き出すかだ。現実には、すべてのリクエストに最先端モデルは不要である。要約タスクはより小さな安価なモデルでも品質を損なわずに実行できる。一方、大規模なコードリファクタリングには最新鋭のモデルが必要だ。しかし、制御がなければ人は常に最も高機能なモデルへ流れてしまう。
この問題に対し、Cloudflareはタスクベースのインテリジェントルーティングを鋭意開発中であると明かした。リクエストを分析し、最もコスト効率の良い結果を導くモデルへ自動的にルーティングする機能だ。詳細はデベロッパードキュメントとチェンジログで追って発表される。
この記事のポイント
- Cloudflare AI Gatewayにドル建ての利用上限機能が全プラン向けに登場した
- 上限到達時はリクエストをブロックするか、より安価なフォールバックモデルに自動で切り替えられる
- 限定ベータのアイデンティティベース予算は、個人やチーム単位で正確なコスト管理を実現する
- これらの機能はCloudflareが自社の大規模AI運用で実証した手法を外部化したものである
- 今後はタスクの複雑さに応じて最適なモデルへ自動ルーティングする機能の開発が予定されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VoidZeroがCloudflareに参画、ビルドツールViteはオープンソースを維持
Vite、Vitest、Rolldown、OxcといったJavaScriptエコシステムの中核ツールを開発するVoidZeroが、Cloudflareに参画した。全チームメンバーがCloudflareに合流する大規模な動きだ。
この発表で最も強調されているのは、これらのプロジェクトがこれからもオープンソースであり続けるという点だ。ViteはMITライセンスを維持し、ベンダーに依存せず、コミュニティ主導で開発が進められる。この原則が揺らぐことはないとCloudflareは明言する。
背景には、AI時代のソフトウェア開発の変化と、フルスタック化するモダンアプリケーションの複雑さがある。Viteがエコシステム全体の共有基盤となった今、この参画はツールチェーンの未来を左右する重要な転換点だ。
VoidZeroのCloudflare参画の内容
オープンソースとベンダー中立の堅持
Cloudflareは、Viteや周辺ツールの独立性を何よりも優先するとしている。具体的な約束は以下の通りだ。
- Vite、Vitest、Rolldown、Oxc、Vite+は今後もMITライセンスのオープンソースであり続ける
- 特定のクラウドベンダーに依存しない設計を維持する。Viteで構築したアプリケーションは、どこでも動作し続ける
- ロードマップはViteチームとコミュニティが引き続き主導し、公開の場で開発される
- Evan You氏をはじめとするVoidZeroチームが、プロジェクトのリーダーシップを継続する
- Cloudflareはこれらのプロジェクトにエンジニアリングリソースを投入するが、方向性を自社向けに曲げることはしない
Cloudflareのブログ記事では、このコミットメントを「言葉ではなく、日々の開発支援とプロジェクト運営で証明していく」と表現している。年初にAstroがCloudflareに参画した際と同様の、独立性を尊重するモデルだ。
100万ドルのViteエコシステム基金
この参画に伴い、CloudflareはViteエコシステム基金として100万ドルを拠出する。この基金はViteのコアチームによって管理され、メンテナーやコントリビューターへの支援に充てられる。
「ViteはVoidZeroやCloudflareよりも大きな存在だ」とCloudflareは述べており、エコシステムを支える無数の開発者を巻き込む意図が明確に示された。オープンソースの持続可能性を金銭面から支える、具体的な施策である。
この比較から分かるように、今回の参画はエコシステムの信頼を損なわないための設計が徹底されている。Viteが多くのフレームワークに採用されている共有基盤だからこそ、中立性の維持は絶対条件となる。
AIが変えたビルドツールの役割
エージェントがツールチェーンを回す時代
Cloudflareのブログ記事は、Viteの驚異的な普及の背景にAIの存在があると分析する。現在Viteの週間ダウンロード数は約1億2900万回、Cloudflare Viteプラグイン（@cloudflare/vite-plugin）は約1400万回に達している。これはVite本体のダウンロード数の10%を超える規模だ。
この急成長を牽引しているのが、AIコーディングエージェントだ。開発者だけが使っていた開発サーバーやリンター、フォーマッターを、今やAIエージェントが常時利用している。彼らはプロジェクトのスキャフォールディングから開発サーバーの起動、エラー解析、テスト実行までを自動で行う。
エージェントにとって重要なのは、高速なフィードバックループだ。ビルドが速く、テストが速く、エラーが明確で、CLIの挙動が一貫していること。VoidZeroのツールチェーン（Vitest、Rolldown、Oxc、Oxlint、Oxfmt）は、まさにこの要件に最適化されている。それぞれのカテゴリで最速クラスの性能を持ち、エージェントが何度も繰り返し実行してもストレスが少ない。
この図は、AIエージェントがコード生成からテスト、リント、修正までのサイクルを高速に回す様子を表している。各ツールの応答速度がエージェントの生産性に直結するため、VoidZeroのツールチェーンが選ばれる理由が明確になる。
フルスタック化するViteとVoidの知見
ビルドツールを超えた役割
モダンなアプリケーションは、単なる静的ファイルのバンドルでは完結しない。サーバーサイドレンダリング、API、バックグラウンドジョブ、キュー、データベース、オブジェクトストレージ、リアルタイム通信、認証、そしてAIエージェントの統合までが必要になる。
Viteはこれに対応するため、ビルドツールからフルスタックアプリケーションの基盤へと進化しつつある。Cloudflareはこの流れを加速させるために、Vite本体にプロバイダ非依存の抽象化レイヤーを追加していく方針だ。バックエンド、API、エージェント、デプロイメントのためのフックをVite側に用意し、各クラウドベンダーがそれを実装する形を目指している。
すでにVoidZeroが実験していた「Void」プラットフォームの知見が、この方向性を後押ししている。VoidはVite向けのデプロイメントプラットフォームとして設計され、モダンアプリのライフサイクル全体を一つのツールチェーンで統一する試みだった。Cloudflareは将来的にこのVoidプラットフォームをオープンソース化し、誰でも独自のプラットフォームをVite上に構築できるようにする計画も示している。
Workerd統合による開発体験の向上
CloudflareとViteの協業は2024年のVite Environment APIから始まっている。このAPIによって、Viteの開発サーバーはNode.js以外のランタイムでもサーバーコードを実行できるようになった。
Cloudflare Viteプラグインを使用すると、vite devの実行時にサーバーコードがWorkerd（Cloudflare Workersのオープンソースランタイム）上で動作する。Durable Objects、D1、KV、R2、Workers AI、エージェントなど、本番環境と同じランタイムモデルがローカルで再現される。開発環境が本番の劣化版だった時代は、このAPIによって終わりを迎えつつある。
この図が示すように、Environment APIの導入前後で開発体験は大きく変わった。ローカル環境と本番環境のランタイムが一致することで、デプロイ後の予期せぬエラーが激減する。
CloudflareがVite基盤に移行する意味
CLI統合とcfコマンドの未来
Cloudflareは自社ツールの方向性を「Viteに合わせる」と明確に宣言している。最近テクニカルプレビューが公開された新しい統合CLI「cf」は、Viteを基盤として設計される。
このCLIの目指す姿は、ViteのエルゴノミクスをそのままCloudflareプラットフォーム全体に拡張することだ。cf devはvite devのスーパーセットとして動作し、同じ速度、同じホットモジュールリプレースメント、同じプラグインモデルを持ちながら、必要に応じてCloudflareのランタイムとバインディングを利用できる。cf buildはViteプロジェクトをネイティブに理解し、cf deployはViteアプリのデプロイをシンプルにする。
すでにCloudflareのダッシュボード自体がVite上に構築されており、OxlintはCloudflareのコードベースで「数日分のエンジニアリング時間を節約している」と報告されている。Astroチームのエージェントハーネスフレームワーク「Flue」もVite基盤に移行中だ。Cloudflare自身がViteをドッグフーディングし、その価値を内部で証明している。
短期的な影響と長期的な展望
短期的には、Viteユーザーにとって何も変わらない。Vite、Vitest、Rolldown、Oxc、Vite+は引き続きリリースされ、VoidZeroチームがこれらを主導する。Cloudflare Viteプラグインも改善が続き、Environment APIもCloudflare以外のランタイムを含めて進化していく。
長期的には、CloudflareのCLIがVite上に完全に統合される。Viteにはフルスタックアプリとエージェントのためのプロバイダ非依存のプリミティブが追加され、あらゆるプラットフォームで利用可能になる。そしてVoidプラットフォームがオープンソース化され、誰でもViteとCloudflareの上に独自のプラットフォームを構築できるようになる。
この計画が実現すれば、ViteはJavaScriptエコシステムの単なるビルドツールから、アプリケーション開発全体を支える普遍的な基盤へと進化する。Cloudflareのインフラは、その基盤の上で最も統合された選択肢の一つとして位置づけられることになる。
この記事のポイント
- VoidZeroの全メンバーがCloudflareに参画。ViteやVitestなどのツールはMITライセンスのままでベンダー中立を維持する
- CloudflareはViteエコシステム基金として100万ドルを拠出し、コミュニティ主導の開発を資金面から支援する
- Viteの週間ダウンロード数1億2900万回の背景には、AIエージェントによる高速フィードバックループ需要がある
- Environment APIにより、ローカル開発環境でも本番と同じWorkerdランタイムが使用可能になった
- Cloudflareの新CLI「cf」はViteを基盤に統合され、全プラットフォームで一貫した開発体験を提供する計画だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
イランのインターネットが部分的に復旧。Cloudflare Radarが87日ぶりの通信量増加を観測
2026年5月26日、イランで約3か月にわたって継続していた全国的なインターネット遮断が、部分的に解除された。Cloudflare Radarの観測データは、通信量とDNSクエリの急激な増加を記録しており、市民のオンラインアクセスが再開されつつあることを示している。
今回の復旧は、2月28日に始まった2度目の大規模遮断から87日目にあたる。遮断開始以来、ほぼゼロにまで落ち込んでいたイラン発の通信量が、突如として前週比の約15倍に跳ね上がった。もっとも、この回復は完全ではなく、ピーク時のトラフィックは今年の最大値と比較して40%にとどまっている。
Cloudflareのネットワークを流れるデータの詳細を読み解くことで、長期化した遮断の実態と、今回の部分復旧の意味するところが浮かび上がる。本記事では、一連のデータポイントを分析し、イランのインターネット接続状況が現在どのようなフェーズにあるのかを解説する。
2026年にイランで発生した2度の大規模インターネット遮断
イランでは今年に入り、すでに2度の全国的なインターネット遮断が発生している。最初の遮断は1月8日に始まり、数日間でほぼすべての通信量が消失した。短期間の部分回復を挟みつつ、本格的な復旧は1月27日までずれ込んでいる。
2度目となる今回の遮断は、情勢の緊迫化を背景に2月28日から開始された。現地時間の午前10時30分ごろ、イラン国内から国外へ向かうウェブ通信量とDNSトラフィックは、遮断前の1%未満にまで急落した。それ以降、わずかなデータ漏洩を除けば、実質的に国全体がグローバルネットワークから隔絶された状態が続いていた。
この約3か月間、イランの一般市民はオンラインバンキング、地図アプリ、メッセージツール、海外のニュースメディアなど、日常生活やビジネスに不可欠なデジタルサービスから切り離されてきた。
上図の比較からわかるように、遮断期間中の通信は事実上ストップしていた。5月26日以降のデータは、国全体のネットワークが一斉に「息を吹き返した」かのような変化を示している。
トラフィック急増の詳細なデータが示すもの
通信量は前週の約15倍に跳ね上がった
Cloudflareのネットワーク上を転送されたバイト数のデータを見ると、復旧の兆候は明瞭だ。協定世界時（UTC）の5月26日11時45分に最初のスパイクが記録され、12時00分からは持続的な増加へと転じた。この通信量の急増は、遮断期間中の前週の水準と比較して約15倍に達している。
転送バイト数の増加とは、単に「接続が戻った」というだけでなく、画像や動画、ファイルダウンロードといった実データが国境を越えて再び流れ始めたことを意味する。ウェブの閲覧だけでなく、アプリのアップデートやクラウドストレージへの同期など、より帯域を消費する活動が再開された可能性が高い。
トラフィックの推移は、人間の生活リズムと一致する日内変動にも従っている。UTCの21時ごろ（現地時間の深夜0時30分ごろ）に通信量が減少し、翌27日の3時（現地時間6時30分ごろ）から再び増加に転じた。このパターンは、実際に人々が朝を迎えて端末を操作し始めたことを如実に反映している。
この比較は、ネットワークが単に技術的に「オン」になったのではなく、エンドユーザーによる実需要が即座に反映されたことを示している。
全体の91.6%がテヘランに集中する地域別の偏り
回復したトラフィックのほとんどは、首都テヘランに集中している。Cloudflare Radarの地域別データによれば、HTTPリクエスト全体の実に91.6%がテヘラン州から発信されていた。他の地域でもわずかな増加は見られるものの、テヘランとの差は圧倒的だ。
この極端な偏りからは、いくつかのシナリオが推測できる。第一に、政府や通信規制当局が首都から優先的に復旧を進めている可能性が高い。第二に、テヘランには国内で最も多くのデータセンターや国際接続ポイントが集中しており、物理的に復旧作業が行いやすいというインフラ面の要因も考えられる。
ただし、この偏りが地方に住む大多数の市民にとって「ネットが戻った」という実感からはほど遠い状況を生んでいる点は重要だ。現在の復旧状況は、あくまで「部分的」であり、国の隅々まで接続性が戻るにはさらなる時間を要するだろう。
ネットワーク事業者別に見る復旧状況
通信量の増加は、複数の主要なインターネットサービス事業者（ISP）で同時に観測されている。11時45分の最初のバーストに続いて、TCI（イラン通信）、IranCell、RighTel、MCCIといった事業者のネットワークで一斉にトラフィックが立ち上がった。
これらの事業者は、それぞれ異なる自律システム番号（ASN）という一意の識別子で管理されている。ASNとは、インターネット上で個々のネットワークを識別するための番号で、例えるなら「インターネット世界における電話の市外局番と加入者番号を組み合わせたようなもの」だ。複数のASNで同時に復旧が確認されたことは、特定の事業者のみの一時的な不具合ではなく、国家レベルでの規制変更やゲートウェイの開放が行われたことを強く示唆している。
複数事業者での同時回復という事実は、今回の復旧が偶発的なものではなく、中央政府の明確な意図に基づいて実行された可能性が高いことを示している。
DNSクエリの急増と1.1.1.1への影響
転送バイト数だけでなく、DNS（ドメインネームシステム）クエリの数も急増している。DNSとは、人間が覚えやすい「google.com」のようなドメイン名を、コンピュータが理解できるIPアドレスに変換する、インターネットの「電話帳」にあたる仕組みだ。このDNSクエリが増えるということは、利用者が実際にウェブサイトやアプリに接続しようとしている直接的な証拠となる。
Cloudflareが提供するパブリックDNSリゾルバ「1.1.1.1」へのクエリも、5月26日を境にスパイクを記録した。このリゾルバは、インターネットサービス事業者が提供するデフォルトのDNSよりも高速で、プライバシーに配慮していることから、技術に詳しいユーザーを中心に世界中で広く利用されている。イラン国内から1.1.1.1へのクエリが増えたことは、単にネットが使えるようになっただけでなく、ユーザーが意識的に「より速く、より自由な」DNS解決手段を選択し始めた可能性を示唆する。
DNSトラフィックの回復は、ウェブページの閲覧だけに留まらない。メールの送受信、アプリのプッシュ通知、VoIP通話など、多種多様なインターネットサービスは、すべて通信の最初の段階でDNSクエリを発生させる。したがって、DNSクエリの増加傾向は、デジタル社会の活動そのものが再開されつつあることの強い指標と言える。
通信量はピーク時の40%にとどまる依然として本格復旧には遠い現実
今回の回復を楽観視するのはまだ早い。5月26日のピーク時でさえ、トラフィックは今年に入ってから遮断前に記録された最大通信量のわずか40%にとどまっている。ネットワークの「部分的」復旧という言葉が示す通り、まだ多くの障害が残っていると見るべきだ。
加えて、1月の事例が示すように、一時的な復旧はすぐに逆戻りするリスクをはらんでいる。1月にも、一度は戻ったかに見えた通信が24時間足らずで再び遮断された経緯がある。現時点でのトラフィックの増加は心強い兆候ではあるが、これが持続的な復旧の始まりなのか、それとも再び訪れる「通信のブラックアウト」の前触れなのかは、今後の数日から数週間のデータを注視しなければ判断できない。
上記の警告表示が示す通り、ネットワーク状況は依然として流動的だ。本来あるべき水準からはほど遠く、完全な「日常」のネット利用が戻ったとは到底言えない。
IPv6アドレス消失が示す遮断の技術的メカニズム
イランのインターネット遮断を語る上で、見逃せないデータポイントがある。IPv6（インターネットプロトコルバージョン6）アドレス空間の消失だ。
IPv6とは、次世代のインターネットアドレス規格である。従来のIPv4アドレスが世界的に枯渇しつつある中で、ほぼ無限に近いアドレス数を提供できるIPv6への移行が世界中で進められている。このIPv6アドレスの広報（グローバルな経路表に自ネットワークのアドレスを登録すること）が、1月の最初の遮断が始まる数時間前に、イラン国内からほぼ完全に消失した。そして、驚くべきことに、5月の部分復旧後もIPv6アドレス空間の広報量は事実上ゼロのままだ。
一方、旧来のIPv4アドレス空間の広報は、2度の大規模遮断中も一貫して安定的に維持されていた。一見すると矛盾するこの事実は、イランの遮断が物理的なケーブルの切断やルーターの停止といった単純な手法ではなく、より高度なフィルタリング技術によって達成されていたことを強く示唆している。
この対比から導き出される仮説は明快だ。イランの規制当局は、特定のアプリケーションやプロトコルを識別して遮断するDPI（ディープパケットインスペクション）や、許可リストに登録された宛先以外への通信をすべて遮断するホワイトリスト方式を用いて、通信を制御していた可能性が高い。IPv4が「抜け殻」として維持されていたのは、将来的な復旧を想定した準備であったとも考えられる。IPv6が戻らない理由は定かではないが、次世代プロトコルに対する管理・監視体制が整っていないことが一因かもしれない。
この記事のポイント
- 2月28日から87日間続いたイランのインターネット遮断が、5月26日に部分的に解除された。
- Cloudflare Radarのデータでは、前週比約15倍の通信量とDNSクエリの急増が観測された。
- 回復したトラフィックの91.6%は首都テヘランに集中しており、地方との格差が大きい。
- 通信量は遮断前の通常時と比較すると40%の水準に留まり、本格復旧には至っていない。
- IPv6アドレス空間の広報は依然として消失したままであり、遮断の技術的複雑さを示している。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Astro 6.4リリース。プラグ可能なMarkdownパイプラインとRust製プロセッサーSätteriが登場
Astro 6.4が2026年5月28日にリリースされた。Markdown処理パイプラインを自由に差し替え可能にする新API「markdown.processor」、Rustで書かれた高速MarkdownプロセッサーSätteriの試験的導入、そしてCloudflare環境向けのルーティングヘルパーが追加された。
これまでの設定方法は非推奨となり、将来的なAstro 8.0では完全に廃止される予定だ。今回のアップデートで、静的サイト構築におけるMarkdown処理の柔軟性とパフォーマンスが大幅に向上する。
プラグ可能なMarkdownプロセッサーAPI
AstroのMarkdownパイプラインはこれまで、unified（remark/rehype）エコシステムを中心に構築されてきた。強力で数千ものプラグインが利用できる一方、特定のプロジェクトの要求に合わない場合もあった。今回追加されたmarkdown.processor設定オプションでは、そのパイプライン全体を丸ごと差し替えられる。
設定の変更方法
デフォルトのプロセッサーは従来通りunified()が使われるため、既存プロジェクトは何も変更せずにそのまま動き続ける。remark/rehypeプラグインも同じ挙動を保つが、設定場所がトップレベルのmarkdownからプロセッサー内に移行した。
import { defineConfig } from 'astro/config';
import { unified } from '@astrojs/markdown-remark';
import remarkToc from 'remark-toc';
export default defineConfig({
markdown: {
processor: unified({
remarkPlugins: [remarkToc],
}),
},
});従来のトップレベルオプション（markdown.remarkPlugins, markdown.rehypePlugins, markdown.remarkRehype, markdown.gfm, markdown.smartypants）も引き続き動作するが非推奨となり、Astro 8.0で完全に削除される予定だ。
移行の注意点
既存プロジェクトの移行は比較的簡単だ。unified({...})内にプラグインをまとめて記述するだけでよい。ただし、マークダウン処理をカスタマイズした複雑な設定を行っている場合は、コードの再構成が必要になる。公式ドキュメントのMarkdownガイドが更新されているため、詳細はそちらを参照してほしい。
Rust製MarkdownプロセッサーSätteri
プラグ可能なプロセッサーAPIの追加により、Astroは標準とは異なるMarkdownプロセッサーも同梱できるようになった。今回導入された@astrojs/markdown-satteriパッケージは、Rustで書かれた高速なMarkdown/MDXパイプライン「Sätteri」をベースにしている。
パフォーマンスの劇的な向上
Sätteriはデフォルトのunifiedベースのパイプラインよりも大幅に高速で、多くのMarkdown機能をプラグインなしでネイティブ実装している。Astroの公式ブログによれば、自社のドキュメントサイトをSätteriに切り替えたところ、ビルド時間が1分以上短縮されたという。
npm install @astrojs/markdown-satteriimport { defineConfig } from 'astro/config';
import { satteri } from '@astrojs/markdown-satteri';
export default defineConfig({
markdown: {
processor: satteri({
features: { directive: true },
}),
},
});この数値はあくまで一例だが、コンテンツ量の多いサイトでは特に効果が大きい。Rustで記述されているため、CPUバウンドな処理が高速化される仕組みだ。
プラグイン互換性と今後のデフォルト化
Sätteriはremark/rehypeプラグインを実行しない。unifiedエコシステムのプラグインに依存している場合は、当面unified()を使い続けるか、SätteriのMDAST/HASTプラグインに移植する必要がある。Astroチームは、将来のメジャーバージョンでSätteriをデフォルトのMarkdownプロセッサーにすることを目指している。
Rustプロセッサーや新APIに関するフィードバックは、公式のRFCDiscussionで受け付けている。興味がある開発者はぜひ参加してほしい。
Cloudflare向け高度ルーティングヘルパー
Astro 6.3で導入された実験的な高度ルーティング機能をCloudflare環境で使いやすくするため、@astrojs/cloudflareパッケージにcf()ヘルパーが追加された。SESSION KVバインディングの注入、ASSETSバインディングによる静的アセット配信、クライアントIPアドレスやwaitUntilの処理など、Cloudflare特有の面倒な設定を一手に引き受ける。
Fetchハンドラでの利用
import { astro, FetchState } from 'astro/fetch';
import { cf } from '@astrojs/cloudflare/fetch';
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
const state = new FetchState(request);
const asset = await cf(state, env, ctx);
if (asset) return asset;
return astro(state);
},
};Honoミドルウェアでの利用
import { Hono } from 'hono';
import { actions, middleware, pages, i18n } from 'astro/hono';
import { cf } from '@astrojs/cloudflare/hono';
const app = new Hono<{ Bindings: Env }>();
app.use(cf());
app.use(actions());
app.use(middleware());
app.use(pages());
app.use(i18n());
export default app;このヘルパーにより、Cloudflare上で高度なルーティングを実装する際のボイラープレートコードが大幅に削減される。実験的機能ではあるが、実用段階に入りつつあると言えるだろう。
その他の改善とアップグレード手順
細かなバグ修正と今後のロードマップ
今回のリリースには、上記の主要機能以外にも多数のバグ修正と小さな改善が含まれている。詳細は公式の変更履歴を確認してほしい。また、Astroコアチームは活発に開発を続けており、コミュニティからのコントリビュートも盛んだ。
アップグレードの手順
既存のAstroプロジェクトをアップグレードするには、自動アップグレードツールを使うのが推奨だ。
# 推奨
npx @astrojs/upgrade
# 手動の場合
npm install astro@latest
pnpm upgrade astro --latest
yarn upgrade astro --latest自動ツールは非推奨設定の移行などもサポートする。手動で行う場合は、設定ファイルの変更点を確認しながらアップデートしよう。
この記事のポイント
- Markdown処理を差し替え可能にする
markdown.processorAPIが追加された - RustベースのSätteriプロセッサーによりビルド時間を大幅に短縮できる
- Cloudflare向け
cf()ヘルパーで高度ルーティングの設定が簡略化された - 従来の設定方法は非推奨となり、Astro 8.0で廃止予定。早めの移行が望ましい
- アップグレードは
npx @astrojs/upgradeで簡単に行える
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CloudflareがClaude Managed Agentsと統合、エージェントの実行基盤を刷新
CloudflareがAnthropicと連携し、Claude Managed AgentsをCloudflareのサンドボックス環境と統合した。この新たな統合により、エージェントのコード実行からブラウザ操作、プライベートサービスへの接続までを、Cloudflareのプラットフォーム上でより柔軟に制御できる。
従来、Claude Managed AgentsはAnthropic側のインフラに完全に依存していた。今回の発表で「頭脳」であるClaudeの推論ループと「手足」であるコード実行基盤が分離され、後者をCloudflare上で運用できるようになった。
開発者は数分でテンプレートをデプロイし、セキュリティ強化やミリ秒単位のサンドボックス起動、内部サービスへの安全な接続といったメリットを得られる。この記事では、統合の仕組みと実務への影響を具体的に掘り下げる。
Claude Managed AgentsとCloudflareが目指すもの
この構成で得られるのは単なる「場所の変更」ではない。インフラをCloudflareに移すことで、エージェントの振る舞いを細かく監視し、内部サービスとの通信を暗号化し、必要なリソースだけを動的に割り当てられるようになる。
Cloudflare Blogの記事では、この仕組みを「頭脳から手足を切り離す」と表現している。開発者はClaudeの高い推論能力をそのまま活かしつつ、実行環境だけを自社ポリシーに合わせてカスタマイズできるわけだ。
Cloudflare環境の仕組み
統合をデプロイすると、Cloudflare上にWorkersベースのコントロールプレーンが立ち上がる。Claude Agentがセッションを開始するたび、このコントロールプレーンがサンドボックス環境を割り当て、コード実行やCLIツールの操作、ブラウザ操作などを代行する。
サンドボックスはセッションがスリープしても状態を自動的に保持する。コンテナイメージのカスタマイズやインスタンスサイズの調整もオプションで指定でき、既存の監視ツール（DatadogやSplunk）へのログ連携にも対応している。
特筆すべきは、Cloudflareのダッシュボードからエージェントの状態を可視化し、必要に応じてSSHでサンドボックス内部に入れる点だ。大規模なエージェント運用では、トラブルシューティングのしやすさが運用コストを大きく左右する。この設計は現場の要求をよく踏まえている。
インターネット規模のエージェント実行基盤
エージェントが本格的に普及すると、企業は1人のユーザーに対して複数のエージェントを同時に動かす必要が出てくる。従来のマイクロVM方式では、エージェントの数だけVMを起動し続けるため、リソースとコストが線形に増加してしまう。
Cloudflareはこの課題に対し、V8 Isolateを使った軽量サンドボックスを提供する。Dynamic WorkersとCodemodeを組み合わせることで、ミリ秒単位でサンドボックスを起動し、フルVMよりはるかに少ないリソースで任意のコードを実行できる。
エージェントのセットアップ時にバックエンドタイプとして「isolate」を選択するだけで、この軽量モードに切り替えられる。数万規模の同時エージェントを扱うユースケースでは、コスト効率が数十倍変わる可能性がある。
もちろん、Linuxツールをフル活用する開発エージェントには、引き続きマイクロVMベースのCloudflare Containersを使える。用途に応じて2種類の実行環境を選択できる点が、この統合の実用的な強みだ。
エージェントワークロードのセキュリティ
エージェントが組織の内部データやサービスにアクセスするとき、最大のリスクは認証情報の漏洩だ。Cloudflareの統合では、アウトバウンドプロキシを使い、サンドボックスから外部へ出る通信に対して動的に認証情報を注入する仕組みを備えている。
この設計のポイントは、エージェント自身はクレデンシャルを知らないことだ。プロキシがゼロトラストベースでリクエストに署名やトークンを付与するため、万が一サンドボックスが侵害されても、認証情報そのものが盗まれるリスクを抑えられる。
また、Cloudflare MeshとWorkers VPCを使えば、インターネットに一切公開していない内部サービスにも、ポスト量子暗号で保護されたトンネル経由で接続できる。VPNや踏み台サーバーなしでプライベートサービスと通信できる点は、インフラ担当者にとって大きな利点だろう。
プロキシはテナント単位やエージェント単位でポリシーを適用できる。特定のエンドポイントだけを許可リスト化し、それ以外の通信を遮断するといった細かな制御も、コード数行で実装可能だ。
エージェントに必要なツール群
ブラウザ操作の完全な制御
エージェントがウェブと対話する際、単純なHTTPリクエストでは不十分な場面が多い。JavaScriptを多用するモダンなウェブアプリケーションの操作や、QA用のスクリーンショット取得、フォーム入力の自動化には、実際のブラウザが必要になる。
CloudflareのBrowser Runは、エージェントにプログラム可能なブラウザを与える仕組みだ。検索、実行、スクリーンショット、ページのMarkdown変換など、複数のツールがデフォルトで利用できる。
セッションの録画機能も備わっており、エージェントがブラウザ上で何をしたかを後から完全に監査できる。許可リストや拒否リストを使ったアクセス制御も可能で、野放図なウェブアクセスを防げる。
メール送受信とプライベート接続
エージェントにメールアドレスを割り当て、送受信を自律的に行わせる機能も統合済みだ。Cloudflare Email Serviceと連携し、任意のドメインでエージェントがメールを送信できる。顧客対応の自動化や、転送されたメールへの返信といったユースケースに適している。
内部サービスへの接続にはcall_serviceツールが用意されており、Cloudflare MeshやWorkers VPC経由でプライベートAPIを安全に呼び出せる。Workers AIを使った画像生成ツールも標準で組み込まれており、Claudeのテキスト推論と組み合わせたマルチモーダルなワークフローを構築できる。
カスタムツールの追加
リポジトリをフォークし、独自のツールを追加するのも容易だ。例えばCloudflare R2にファイルをアップロードし、公開URLを返すツールを数行のコードで定義できる。以下はCloudflare Blogで示されたコード例を簡略化したものだ。
defineTool({
name: "r2_host_file",
description: "サンドボックスからR2にアップロードし公開URLを取得",
inputSchema: z.object({
key: z.string(),
content: z.string(),
contentType: z.string()
}),
run: async ({ key, content, contentType }, { env }) => {
await env.PUBLIC_BUCKET.put(key, content, { httpMetadata: { contentType }});
return `${env.PUB_R2_URL}/${encodeURI(key)}`;
}
})Workers AIを使ったエッジ推論や、Dynamic Workersによる動的なアプリケーションホスティング、Artifactsを使ったGit管理の追加など、Cloudflare Developer Platform全体をエージェントの拡張に活用できる。インフラ管理を意識せず、関数を書いてデプロイするだけで機能追加が完了する設計だ。
この記事のポイント
- Claude Managed Agentsの実行基盤をCloudflare上に構築できるようになった
- 「頭脳（Claude）」と「手足（Cloudflareサンドボックス）」の分離で、インフラ選択の自由度が向上した
- V8 Isolateを使った軽量サンドボックスで、ミリ秒起動と低コストの大規模実行が可能
- アウトバウンドプロキシによるゼロトラスト認証で、エージェントのセキュリティを強化
- ブラウザ操作、メール送受信、内部サービス接続などのツールが標準装備されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Copy Fail脆弱性にCloudflareがどう立ち向かったか
2026年4月29日、Linuxカーネルにローカル権限昇格をもたらす脆弱性「Copy Fail（CVE-2026-31431）」が公開された。この脆弱性を悪用すれば攻撃者はroot権限を取得でき、多くのサーバが影響を受け得る深刻なものだ。
Cloudflareは世界中の330都市に展開する大規模なLinuxサーバ基盤を運用している。同社は開示直後からセキュリティチームとエンジニアリングチームが動き、既存の振る舞い検知が数分で攻撃パターンを特定できることを確認し、また再起動不要の緩和策としてeBPF LSMを展開した。結果として顧客データへの影響やサービス停止は一切発生していない。
Copy Fail脆弱性（CVE-2026-31431）の全容
Linuxカーネルのcrypto APIには、AF_ALGソケットファミリ経由で一般ユーザプロセスが暗号化・復号を要求できる仕組みがある。ここで問題となったのは「aead」テンプレートを用いるモジュール `algif_aead` の欠陥だ。2017年に導入されたin-place最適化によって、復号時に割り当てられた出力領域を超えた4バイトの書き込みが発生するようになっていた。
攻撃者はまず `splice()` システムコールを使い、`/usr/bin/su` のようなsetuidバイナリのファイル記述子からページキャッシュの参照を暗号化操作のscatterlistにチェインさせる。その状態で `recvmsg()` を呼ぶと、本来許される範囲外の4バイトがターゲットのページキャッシュに書き込まれる。汚染されたバイナリを `execve()` で実行すれば、root権限で任意のコードが動くという筋書きだ。
socket(AF_ALG, SOCK_SEQPACKET, 0) でAEADテンプレートにバインド
setuidバイナリ（例:/usr/bin/su）のファイル記述子からページキャッシュを暗号scatterlistにチェイン
復号処理中に4バイトのスクラッチデータがターゲットページキャッシュへ書き込まれる
ページキャッシュが汚染された状態でsetuid-rootプログラムを実行し、シェルコードがrootとして動作
このエクスプロイトの流れは、Cloudflareのブログで詳述された技術情報と、Xint Codeによる元の開示記事を基にしている。Linuxコミュニティはコミット a664bf3d603d で2017年の最適化を差し戻しており、それが正式な修正となる。
CloudflareのLinuxカーネル管理プロセス
CloudflareはカスタムLinuxカーネルを自前でビルドし、コミュニティの長期サポート（LTS）バージョンをベースにしている。新型カーネルの選定からグローバル展開まで、およそ4週間のサイクルでシステム的なアップデートと再起動を実施している。公開前に既知のセキュリティパッチがマージされるのが常だが、Copy Failの修正はメインラインにマージされてから1ヶ月経っても主要LTSラインへのバックポートが完了していなかった。このタイムラグが生じたため、Cloudflareの大部分のサーバは6.12 LTSカーネルを稼働させており、脆弱性が残る状態だった。
Cloudflareの多層防御：検知から再起動不要の緩和まで
振る舞いベースの検出が数分で作動
Cloudflareのエンドポイントには、プロセスの振る舞いを常時監視する検知プラットフォームが導入されている。特定の脆弱性シグネチャに頼るのではなく、通常とは異なる実行パターンを検出する仕組みだ。専用ルールの更新や人の介入なしに、社内で実施した検証でエクスプロイトの試行が数分以内に悪性と判定され、アラートが発報された。これは攻撃チェーン全体（スクリプトインタプリタ → AF_ALG経由の暗号サブシステム呼び出し → 権限昇格バイナリの実行）を一つの振る舞いパターンとして捉えた結果だ。
脅威ハンティングと過去48時間のログ調査
セキュリティチームは「公開前から悪用されていた可能性を前提にする」という原則に立ち、エクスプロイトが残すカーネルログの痕跡を独自の集約ログ基盤で検索した。また、関係するシステムへの全アクセスログを収集し、接続元や実行コマンドを再構成、システムバイナリのハッシュ整合性を検証した。その結果、過去48時間においてCloudflareのインフラ上で悪用された証拠は一切確認されなかった。
eBPF LSMによる緊急緩和の展開
根本対策であるパッチ済みカーネルのロールアウトには時間がかかるため、チームは無効化モジュール `algif_aead` の削除をまず試みた。しかし実際にはレガシーな社内サービスがcrypto APIを利用しており、削除すると障害を招くことがステージング環境のテストで判明した。そこで再起動不要の外科的対策として、BPF Linux Security Module（bpf-lsm）を使ったプログラムを導入した。
# 素朴な緩和（モジュール無効化）は依存関係のため断念
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
bpf-lsmプログラムは `socket_bind` LSMフックにアタッチし、AF_ALGソケットを開こうとするバイナリのパスをホワイトリストと照合する。許可リストにないバイナリからの `bind()` 呼び出しは拒否するため、悪用の入口を完全に封鎖する。このアプローチを採る前に、Prometheus eBPF Exporterを使って艦隊全体のAF_ALG利用実態を可視化し、許可リストに載せるべき正当なサービスが本当に1つだけであることを検証した。
# eBPF LSMプログラムの擬似フロー
- ソケットファミリがAF_ALGでなければ通過
- AF_ALGの場合、呼び出し元バイナリのパスを許可リストと照合
- 許可されていればbindを許可、それ以外は拒否
これにより、大部分のサーバはパッチ済みカーネルが配布されるまでの間、bpf-lsmによって保護された。テスト用ノードで実際にエクスプロイトコードを実行し、PermissionError が返され攻撃が不可能になったことを確認している。
攻撃者のbind()成功 → recvmsg()で範囲外書き込み → root取得
非許可バイナリからのAF_ALG bindを拒否 → PermissionError → 攻撃失敗
一連の対応から得た教訓と今後の改善
Cloudflareは今回の対応を通じていくつかの改善点を特定した。まず、カーネルAPIの依存関係をより深く可視化し、将来の緊急緩和時にサービス停止を避けられるようにすること。次にbpf-lsm自体の展開速度やログの充実を図り、ランタイム防御の即応性を高めること。さらに、カーネルコンフィギュレーションの監査を進め、使われていないモジュールや機能を事前にビルドから除去することで攻撃対象領域を縮小していく方針だ。
今回のインシデントで、Cloudflareは顧客影響ゼロを達成した。パッチ済みカーネルのリリースとbpf-lsmによるレイヤーが艦隊全体に行き渡り、脆弱性が悪用される余地は残らなかった。Linuxコミュニティの責任ある開示、社内の可視化ツール、そしてbpf-lsmというプリミティブが、迅速な防御を可能にしたといえる。
この記事のポイント
- Linuxカーネルの脆弱性「Copy Fail」はローカルからroot権限を奪取できる深刻な問題
- Cloudflareは公開と同時に既存の振る舞い検知で即座に捕捉し、過去ログの脅威ハンティングで未然悪用がないことを確認
- 再起動不要の緩和策としてeBPF LSMを導入し、AF_ALGソケットへの不正アクセスをホワイトリスト方式で遮断
- 根本パッチのロールアウトと並行して運用し、結果的に顧客データやサービスへの影響は皆無
- 可視化ツール（Prometheus eBPF Exporter）の事前整備が緩和策の意思決定を支えた
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
de TLD障害の全容 DNSSEC署名破損でSERVFAIL多発 Cloudflareの一時的緩和策を解説
2026年5月5日、およそ19時30分（UTC）、ドイツの国別コードトップレベルドメインである .de を管理するレジストリ DENIC が、同ゾーンのDNSSEC署名を誤って公開し始めた。この誤った署名は、DNSSEC検証を行うすべてのDNSリゾルバにSERVFAILを返させる結果となり、Cloudflareの公開リゾルバ1.1.1.1も例外ではなかった。
.de はインターネット上で最もクエリ数の多いTLDのひとつで、Cloudflare Radarのデータでも常に上位にランクインする。このレベルのDNS階層で障害が発生すると、数百万のドメインが到達不能になる可能性がある。本記事では、Cloudflareが観測した現象、影響の範囲、さらにDENICが問題を解決するまでの間に1.1.1.1が適用した一時的緩和策について解説する。
.de TLD障害の原因と発覚の経緯
DNSSEC署名が破損したことで、リゾルバは応答を信用せずSERVFAILを返す。この仕組みは正しいが、大規模な影響を引き起こした。19時30分の直後からSERVFAILが急増し、キャッシュの期限切れに伴って3時間にわたって増え続けた。クエリのリトライにより通信量も増大し、SERVFAILの件数は実際のユーザー影響以上に見える。
DENICは後の声明で「定例の鍵ローテーション中に、検証できない署名が生成・配布された」と説明しており、今後のローテーションは原因特定まで停止されている。
DNSSECの仕組みと署名検証の役割
DSレコード
検証失敗
DNSSEC（Domain Name System Security Extensions）は、DNS応答にデジタル署名を付与して改ざんを防ぐ仕組みだ。各ゾーンのレコードセットにはRRSIGレコードが付随し、リゾルバはこれを用いて原本性を確認する。署名は保護対象のレコードと一緒に運ばれるため、キャッシュを経由しても検証可能だ。
信頼の連鎖はルートゾーンから始まり、親ゾーンがDSレコードで子ゾーンの公開鍵を証明する。.deの上位にはルートがあり、.deの下に個々のドメインがぶらさがる。どこか一か所で署名が破綻すると、その先の全ドメインが検証に失敗する。今回のようにTLDで署名ミスが起きれば、配下のすべての .de ドメインがSERVFAILになる。
DNSSECでは、ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）を使い分ける。ZSKはレコードそのものに署名し、KSKはZSKに署名する。KSKの公開鍵が親ゾーンのDSレコードと結びつき、信頼の基点となる。鍵のローテーション時に新しい鍵が正しく配布されなかったり、署名生成に失敗すると、今回のような大規模障害につながる。
キャッシュとserve staleが被害を軽減
クエリ → キャッシュから応答（NOERROR）
DENICへ問い合わせ → SERVFAIL
キャッシュ期限切れでも古いデータを返し続ける
リゾルバはTTL（生存時間）の間、権威サーバーから受け取ったレコードをキャッシュする。TTLが切れると、新しい情報を取りに行く。ところが障害発生中は、新たに取得しようとするとSERVFAILに終わる。そこでCloudflareの1.1.1.1はRFC 8767に従い、キャッシュの期限が切れた後も古いレコードを応答し続ける「serve stale」を実施した。
このおかげで、キャッシュに残っていた .de ドメインの多くは引き続き解決され、ユーザーへの影響は大幅に和らげられた。グラフからも、incident中にNOERRORが一定数維持されたことが分かる。serve staleがなければ、故障が始まった瞬間から全クエリが失敗していた。
Cloudflare 1.1.1.1が講じた一時的緩和策
serve staleだけではカバーできないクエリもあったため、Cloudflareは22時17分（UTC）に .de ゾーンに対して一時的なNTA（Negative Trust Anchor）に相当する措置を適用した。具体的には、内部のオーバーライドルールを使って .de 全体を「DNSSEC未対応ゾーン」のように扱い、署名検証をスキップさせた。
RFC 7646はまさにこうした状況のためにNTAを定義している。TLD運営者が破損した署名を公開した場合、正しいドメインまで巻き添えでSERVFAILになるより、一時的に検証を外す方がユーザーにとって有益だという判断だ。Cloudflareの内部議論でも「1.1.1.1を使っているユーザーで、検証失敗よりも未検証の応答の方を望まない者はいない」と結論づけられている。
同時に、CDNサービスを利用する顧客向けの内部リゾルバにも同様の対応を施し、 .de をオリジンとするサイトの接続性を回復させた。また、対策を即座にDNS-OARCのチャットで共有し、他の事業者との連携も行った。
なお、1.1.1.1が返していたSERVFAILにはEDEコード22（到達可能な権威サーバーなし）が付与されていたが、本来はEDE 6（DNSSEC無効）が適切だ。Cloudflareはこのバグを認識しており、今後DNSSECエラーを正しく表面化させる修正を予定している。
インシデントから学ぶ教訓と今後の改善点
この障害は、DNSの階層構造がもつ脆弱性を改めて浮き彫りにした。TLDレベルで発生した問題は、その下にあるすべてのドメインに等しく波及する。これはDNSSECに限った話ではなく、権威サーバー自体が到達不能になれば同じことが起こる。
根本的な回避策は存在しないが、迅速な連携と運用上の工夫で被害を抑えられる。今回、多くのリゾルバ事業者が1時間以内にNTAを適用し、解決までの間ユーザーの影響を緩和した。DNS-OARCのような業界コミュニティの存在も、こうした危機対応のスピードを支えている。
技術面では、serve staleのような仕組みがTier-1レベルの障害時に有効に機能することが改めて示された。また、EDEエラーコードの適切な実装は、トラブルシューティングを容易にし、運用者間の情報共有を効率化する。Cloudflareもこの点の改善に着手する。
この記事のポイント
- 2026年5月5日、.de TLDのDNSSEC鍵ローテーション中に不正な署名が生じ、全DNSSEC検証リゾルバがSERVFAILを返した
- DNSの階層構造上、TLDの障害は配下のドメインすべてに影響する
- Cloudflareの1.1.1.1はserve staleでキャッシュを延命し、さらに一時的にDNSSEC検証を無効化するNTA相当の対策を22時17分に適用
- RFC 7646に定義されたNTAは、事業者間の迅速な合意形成があれば被害を大幅に軽減できる
- EDEエラーコードの不備など、リゾルバ側の改善点も事例から明らかになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare IPsecが耐量子暗号に対応、2029年完全移行へ前進
Cloudflareは、同社のIPsecサービスに耐量子計算機暗号（PQC）を導入し、一般提供を開始した。ハイブリッドML-KEM（FIPS 203準拠）を採用し、CiscoやFortinetといった主要ベンダーの機器との相互接続を確認済みだ。これにより、量子コンピュータによる将来の解読リスクに備えた広域ネットワーク（WAN）の保護を、既存のハードウェアで開始できる。
同社はかねてから目標としていたシステム全体の完全なPQC対応の期限を2029年に前倒ししている。今回のIPsec対応は、TLSトラフィックの3分の2以上がすでにPQCで保護されている状況にネットワーク層が追いつくための、重要なマイルストーンとなる。
耐量子暗号IPsecが一般提供開始となる背景
インターネット上の通信の多くは、現在のコンピュータでは解読が困難な公開鍵暗号によって保護されている。しかし、大規模な量子コンピュータが実用化されれば、これらの暗号は簡単に破られてしまう。これが「Q-Day」と呼ばれる転換点であり、想定よりも早く訪れる可能性が指摘されている。
ここで警戒すべきなのが「Harvest-now-decrypt-later（今収集し、後で解読する）」攻撃だ。攻撃者は今日の暗号化された通信データを大量に収集・保存し、将来の量子コンピュータで解読する。サイト間のVPNでよく使われるIPsec通信もこの脅威にさらされてきた。
Webブラウジングの通信を暗号化するTLSでは、すでに2022年からハイブリッドPQCの導入が急速に進んだ。実際、Cloudflareのネットワークに到達するユーザー由来のTLSトラフィックの3分の2以上が、耐量子暗号で保護されている。一方で、企業の拠点間を結ぶIPsecの世界では、相互運用性の確保や標準化の遅れが壁となり、導入が4年ほど遅れていた。
ハイブリッドML-KEMが実現する耐量子暗号
ML-KEMとは何か
今回採用されたML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism）は、量子コンピュータによる攻撃が理論的に困難とされる数学的問題（格子暗号）に基づくアルゴリズムだ。これは、通信の両端が持つ特殊なハードウェアや専用の物理回線を必要としない。標準的なプロセッサ上でソフトウェアとして動作するように設計されている点が、実用上の大きな利点である。
「ハイブリッド」方式の重要性
Cloudflareが実装したのは、IETFのドラフト「draft-ietf-ipsecme-ikev2-mlkem」で規定されるハイブリッド方式である。ハイブリッド方式とは、既存の安全性が十分に検証された古典的なDiffie-Hellman鍵交換と、新しいML-KEMを組み合わせる手法だ。
具体的なハンドシェイクの流れは次のとおりだ。まず、従来のDiffie-Hellman鍵交換を実行して共有鍵を生成する。次に、その鍵を使ってML-KEMの鍵交換を暗号化して実行する。最後に、両方の出力を混合して、実際のデータ通信を保護するセッション鍵を作成する。この二重構造により、仮に将来ML-KEMに未知の脆弱性が見つかったとしても、古典暗号の層が安全性を下支えする。
相互運用性の確立と課題
Cisco、Fortinetとの相互接続に成功
PQCの実装において最大の障壁は、異なるベンダー間での相互運用性の確保だ。Cloudflareの発表によると、今回の一般提供開始に先立ち、以下のネットワーク機器との相互接続テストを完了している。
- Cisco: バージョン26.1.1以降のCisco 8000シリーズセキュアルーター
- Fortinet: FortiOS 7.6.6以降を搭載したブランチコネクタ
これらの機器を拠点側に設置することで、Cloudflareのグローバルネットワークとの間に、耐量子暗号で保護されたIPsecトンネルを確立できる。これにより、特別なハードウェアを新たに調達することなく、既存の投資を活かしてセキュリティを強化できる道が開かれた。
標準化の遅れとciphersuite乱立問題
TLSに比べてIPsecでの標準化が遅れた背景には、鍵配送の代替技術としてのQKD（量子鍵配送）への関心が業界の一部にあったことが挙げられる。RFC 8784で規定されたQKDは、量子力学の原理を用いて盗聴を検知するが、専用のハードウェアと物理的な光ファイバー回線が必須だ。これはインターネット規模での展開には根本的に不向きであり、米国NSAや英国NCSCもQKDへの単独依存に警鐘を鳴らしている。
一方で、PQCのソフトウェアベースのアプローチにはこの制約がない。Cloudflareは、インターネットのオープン性と相互運用性を維持するために、PQCの標準化が不可欠であると主張する。
標準化を巡る混乱も導入を遅らせた一因だ。2023年に公開されたRFC 9370は、IPsecで複数の鍵交換を並行実行する枠組みを提供したが、使用すべき暗号スイートを明確に指定しなかった。この隙間を埋めるように、一部のベンダーは「draft-ietf-ipsecme-ikev2-mlkem」が策定される前に独自の暗号スイートを実装して市場に投入した。NIST SP 800-52r2が警告する「暗号スイートの肥大化」が現実のものとなり、結果として相互運用性に支障が生じている。具体的には、Palo Alto NetworksのRFC 9370ベースの実装とは、現時点で相互接続が確立できていないという。Cloudflareは、業界全体が新たなドラフト標準に集約されることで、この問題が解決されることを期待している。
耐量子インターネットに向けたロードマップ
Cloudflareは、2029年までの完全なPQC対応を目標に掲げている。今回のIPsecへのPQC導入は、そのマイルストーンの一つだ。同社は、この機能を顧客に追加コストなしで提供し、特殊なハードウェアを必要とせずに誰もが耐量子セキュリティを利用できる環境を目指している。
しかし、完全な耐量子環境の実現には、まだ解決すべき課題が残る。現在のdraft-ietf-ipsecme-ikev2-mlkemは「通信の暗号化」のための鍵交換を規定しているが、「通信相手の認証」のためのPQC標準はまだ存在しない。認証部分が古典暗号のままであれば、Q-Day以降に攻撃者が他人になりすましてシステムに侵入する「アクティブ攻撃」を防げない。迫る期限を前に、認証のPQC標準化が次の焦点となることは確実だ。
この記事のポイント
- Cloudflare IPsecがハイブリッドML-KEMによる耐量子暗号（PQC）の一般提供を開始し、2029年の完全移行に向けた一歩を踏み出した。
- CiscoやFortinetの既存ルーターとの相互運用性を確保し、追加のハードウェア投資なしでHarvest-now-decrypt-later攻撃への対策が可能になる。
- RFC標準の不在やベンダー間の実装差異によりIPsecのPQC対応はTLSより4年遅れたが、「draft-ietf-ipsecme-ikev2-mlkem」によって相互運用性の基盤が整いつつある。
- 今後の課題は「通信の認証」をPQCに対応させることであり、真の耐量子セキュリティ実現には標準化コミュニティの継続的な協調が不可欠である。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIエージェントがCloudflareで自律デプロイ。Stripe連携でアカウント作成からドメイン購入まで完結
AIエージェントがソフトウェアを開発するだけでなく、本番環境のインフラまで自ら調達し、デプロイを完了させる時代が到来した。Cloudflareは2026年4月30日、AIエージェントがユーザーに代わってCloudflareアカウントを作成し、ドメインを購入し、アプリケーションをデプロイできる新機能を発表した。
この仕組みは決済プラットフォームのStripeが提供する「Stripe Projects」と共同設計された新しいプロトコルによって実現されている。従来は人間が管理画面で行っていたAPIトークンの発行やクレジットカード情報の入力といった作業を、AIが安全かつシームレスに代行する。
開発者は複雑な初期設定に煩わされることなく、AIに指示を出すだけで「ゼロから本番公開まで」を最短距離で駆け抜けられるようになる。これはインフラ構築の在り方を根本から変える可能性を秘めたアップデートだ。
AIエージェントがインフラ構築を担う新時代の幕開け
コーディングエージェントはプログラムを書く能力には長けているが、これまでは本番環境へのデプロイという壁に直面していた。アプリケーションを公開するには、ホスティング先のアカウント、支払い手段、そして操作のためのAPIトークンの3つが不可欠だからだ。
これまでは人間がダッシュボードにログインし、設定を済ませてからエージェントに情報を渡す必要があった。Cloudflareが導入した新機能は、この「人間による介在」を最小限に抑えることを目的としている。
開発者の手作業をゼロにするStripe Projectsとの連携
今回の機能の中核にあるのが、Stripeとの提携による「Stripe Projects」だ。これはAIエージェントが複数のサービスを組み合わせてプロジェクトを立ち上げるためのプラットフォームである。開発者がStripeのアカウントを持っていれば、それを認証の基盤として利用できる。
エージェントはユーザーの許可を得た上で、Cloudflareのアカウントを自動的にプロビジョニング（準備）する。もしユーザーがすでにCloudflareのアカウントを持っている場合は、標準的なOAuthフローを通じてアクセス権が譲渡される。これにより、APIキーのコピペという原始的な作業から解放される。
● カード情報登録（手動）
● APIキー発行とコピペ（手動）
● ドメイン検索と購入（手動）
✔ 支払いトークンの自動受け渡し
✔ ドメインの自律取得とデプロイ
上記の図が示すように、人間が介入すべきポイントは「AIへの指示」と「最終的な承認」だけに集約される。これにより、開発のリードタイムは劇的に短縮されるだろう。
プロトコルを支える3つの柱
AIエージェントが自律的に動くためには、単にAPIを叩くだけでは不十分だ。CloudflareとStripeは、エージェントが環境を理解し、権限を得て、支払いを実行するための3つの要素をプロトコルとして定義した。
サービスカタログからの自律的な発見
まず重要になるのが「Discovery（発見）」だ。エージェントは、利用可能なサービスが何であるかを知る必要がある。新しいプロトコルでは、CloudflareなどのプロバイダーがREST APIを通じてサービスカタログをJSON形式で提供する。
エージェントはユーザーの要望に基づき、このカタログから最適なサービス（ドメイン登録、ストレージ、コンピューティングなど）を選択する。人間が「どのメニューから選ぶか」を悩む必要はなく、エージェントがタスク達成に最適な道具を自ら選び出す仕組みだ。
認証とアカウントの即時発行
次に「Authorization（認証）」だ。Stripeがアイデンティティプロバイダーとして機能し、ユーザーの身元を保証する。Cloudflareはこの情報を基に、未登録のユーザーに対しては即座にアカウントを発行する。
発行された認証情報はStripe Projects CLIによって安全に保管され、エージェントはそれを使ってCloudflareのAPIを操作する。この一連の流れにおいて、ユーザーがサインアップフォームに入力する手間は一切発生しない。
クレジットカード情報を渡さない安全な決済
最も懸念されるのは「Payment（支払い）」の安全性だろう。AIにクレジットカード番号を教えるのはリスクが高い。そこでこのプロトコルでは、カード情報の代わりに「支払いトークン」を使用する。
Stripeから発行されたトークンをCloudflareに渡すことで、エージェントは実際のカード番号に触れることなく、有料プランの購読やドメインの購入を実行できる。決済の利便性とセキュリティを両立させた設計となっている。
実際のワークフローとCLIでの操作感
この新機能を利用するには、Stripe CLIと専用のプラグインが必要になる。セットアップが完了すれば、ターミナルから簡単なコマンドを実行するだけでプロジェクトを開始できる。Cloudflareのブログでは、具体的な手順が紹介されている。
Stripe CLIを用いたプロジェクトの初期化
まず、以下のコマンドでプロジェクトを初期化し、Stripeにログインする。これがすべての作業の起点となる。
stripe projects initその後、AIエージェントに対して「新しいドメインを取得してアプリをデプロイしてほしい」と指示を出す。エージェントは自ら stripe projects catalog コマンドを叩いてCloudflareのドメイン登録サービスを見つけ出し、購入プロセスを開始する。
もしStripeアカウントに支払い方法が登録されていない場合は、エージェントがユーザーに対してカード情報の追加を促すプロンプトを表示する。人間はエージェントが提示した確認事項に対して「Yes」と答えるだけで、裏側で複雑なインフラの紐付けが完了する。
セキュリティとガバナンスへの配慮
AIに支払権限を与えることには、慎重な意見も多い。「エージェントが勝手に高額なドメインを大量購入したらどうするのか」という懸念は当然の反応だ。この問題に対処するため、プロトコルには厳格な制限が設けられている。
予算制限と予算アラートによる暴走防止
Stripe Projectsでは、デフォルトで1つのプロバイダーに対して月額100ドルという支出上限が設定されている。エージェントがこの上限を超えて勝手に課金することはできない仕組みだ。
さらに上限を引き上げたい場合は、ユーザーが明示的に設定を変更し、Cloudflare側で予算アラート（Budget Alerts）を設定する必要がある。これにより、AIの自律性を保ちつつ、予期せぬコスト増大を防ぐガバナンスが効いている。
独自分析。インフラのコモディティ化とエージェントOSの加速
今回のCloudflareの動きは、単なる利便性の向上に留まらない。筆者は、これがインフラの「完全な抽象化」に向けた決定的な一歩であると考えている。かつて開発者はサーバーを自前で立てていたが、クラウドが登場し、さらにサーバーレスへと進化した。そして今、インフラは「AIが勝手に調達するもの」へと変貌しようとしている。
ここで重要なのは、Stripeが単なる決済手段ではなく、Web上の「アイデンティティ（身元）」のハブとして機能し始めている点だ。Stripeでログインしていれば、CloudflareもPlanetScaleもNeonも、あらゆるクラウドサービスが即座に利用可能になる。これは、Web全体が1つの巨大なオペレーティングシステム（OS）のように振る舞い、AIエージェントがその上で自由にリソースを操作できる環境が整いつつあることを意味する。
開発者の役割は、コードを書くことよりも「AIにどのようなビジネスロジックを実現させたいか」を定義することへとシフトしていくだろう。インフラの設定ミスやAPIトークンの管理漏れといった「非本質的なトラブル」から解放される未来は、すぐそこまで来ている。
この記事のポイント
- AIエージェントがCloudflareのアカウント作成、ドメイン購入、デプロイを自律的に行えるようになった。
- Stripe Projectsとの連携により、OAuth認証と支払いトークンを用いた安全なプロトコルが構築されている。
- 人間はダッシュボードを操作することなく、CLIとAIへの指示だけで本番環境を構築できる。
- 月額100ドルのデフォルト支出制限により、AIの暴走による高額請求を防ぐ仕組みが備わっている。
- インフラの調達が自動化されることで、開発者はより高度なアプリケーション設計に集中できるようになる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflareが提唱するエージェント指向クラウド。Agents Week 2026の全発表まとめ
AIエージェントが自律的にコードを書き、顧客サポートを完結させ、複雑なリサーチを数分でこなす時代が到来した。これまでのクラウドは「1つのアプリケーションが多くのユーザーにサービスを提供する」というモデルで設計されていたが、その前提が根底から覆されようとしている。
Cloudflareは2026年4月、AIエージェントが主役となる新しいインフラ「Agentic Cloud（エージェント指向クラウド）」の構築に向けた大規模なアップデート「Agents Week」を実施した。数千万のエージェントが並列稼働する世界を支えるため、計算資源からセキュリティ、開発ツールまで、全レイヤーにわたる新機能が公開された。
本記事では、Cloudflareが目指す「Cloud 2.0」の全容と、発表された膨大な新機能のポイントを整理して解説する。開発者がプロトタイプから本番環境へとエージェントをスケールさせるための、具体的な武器が揃ったと言える。
エージェントのための新しい計算基盤と実行環境
エージェントは人間とは異なり、24時間365日、膨大な数で並列に動作する。そのため、従来の仮想マシンやコンテナよりも軽量で、かつ持続性のある計算資源が必要だ。Cloudflareは、エージェントが自由にコードを書き、実行できる専用の環境を整備した。
Git互換ストレージ「Artifacts」と隔離環境「Sandboxes」
「Artifacts（アーティファクツ）」は、エージェントが生成したコードやデータを保存するための、Git互換のバージョン管理ストレージだ。エージェントは数千万のリポジトリを動的に作成し、既存のリモート環境からフォーク（複製）して作業を進めることができる。これにより、エージェントが書いたコードを即座にGitクライアントで引き継ぐことが可能になった。
また、エージェントが実際にコマンドを実行し、パッケージをインストールするための環境として「Cloudflare Sandboxes」が正式リリース（GA）された。これは、ファイルシステムやシェルを備えた本物のコンピュータのような環境でありながら、ミリ秒単位で起動し、必要に応じて状態を保存・再開できる。エージェントごとに「専用のパソコン」を割り当てるイメージだ。
Durable Objectsによるエージェント専用データベース
「Durable Objects（デュラブル・オブジェクト）」は、特定の状態を保持できるサーバーレスの仕組みだ。今回のアップデートでは、Durable ObjectsにSQLiteデータベースを内蔵できる「Facets」という機能が追加された。これにより、エージェントが動的に生成したアプリケーションごとに、完全に隔離された専用のデータベースを持たせることが可能になる。
エージェントごとの隔離が難しく、管理が複雑。
エージェント B ➔ 専用SQLite DB
個別に隔離され、ミリ秒で起動・破棄が可能。
この仕組みにより、開発者は数万人のユーザーに対して、それぞれ専用のAIエージェントと専用のDBを瞬時に提供するプラットフォームを構築できる。スケーラビリティの概念が、ユーザー単位からエージェント単位へとシフトしている。
自律動作を支えるセキュリティとネットワーク
エージェントが社内ネットワークにアクセスしたり、ユーザーに代わって決済を行ったりする場合、セキュリティが最大の懸念となる。Cloudflareは、エージェントを「非人間（Non-human）のアイデンティティ」として定義し、その行動を厳密に制御する仕組みを導入した。
プライベート接続を簡素化する「Cloudflare Mesh」
「Cloudflare Mesh（クラウドフレア・メッシュ）」は、ユーザー、デバイス、そしてAIエージェントを安全につなぐプライベートネットワーク機能だ。これまでは、エージェントが社内のデータベースにアクセスするためには複雑なトンネル設定が必要だったが、Meshを使えば、エージェントに最小限の権限（最小特権原則）を与えて直接接続させることができる。
ユーザーに代わって認証する「Managed OAuth」
エージェントがユーザーの代わりにSaaSツールを操作する場合、これまではセキュリティ的に危うい「サービスアカウント」が使われることが多かった。今回発表された「Managed OAuth for Access」は、RFC 9728という新しい規格を採用し、エージェントがユーザーの権限を安全に借用して認証を行う仕組みを提供する。これにより、エージェントが何をしたかの監査ログも正確に残るようになる。
エージェントを「知能」に変えるツールボックス
計算資源があるだけではエージェントは動けない。適切なモデル（脳）、記憶（メモリー）、そして外部世界を認識する手段（ブラウザや音声）が必要だ。Cloudflareはこれらを「Agents SDK」として統合し、数行のコードで実装可能にした。
長期記憶と高度な検索機能
エージェントが過去の会話や作業内容を忘れないようにするための「Agent Memory」が導入された。これは、エージェントに必要な情報を記憶させ、不要な情報を忘れさせるマネージドサービスだ。また、「AI Search」という新しい検索プリミティブ（基本要素）を使えば、エージェントが膨大な文書の中から必要な情報をハイブリッド検索（キーワードと意味の両方で検索）して取り出せるようになる。
ブラウザ操作とマルチモーダル対応
「Browser Run（旧Browser Rendering）」は、エージェントにブラウザを与える機能だ。エージェントはウェブサイトを閲覧し、フォームを入力し、スクリーンショットを撮ることができる。新機能の「Human in the Loop」を使えば、エージェントが判断に迷ったときだけ人間に確認を求めるフローも構築可能だ。
さらに、音声認識（STT）と音声合成（TTS）をリアルタイムで行うパイプラインも追加された。WebSocket（ウェブソケット：双方向通信を行うための規格）を使い、わずか30行程度のコードで「声で会話するエージェント」を実装できる。メールの送受信も「Cloudflare Email Service」を通じてネイティブにサポートされた。
開発効率を最大化するインターフェースの進化
Cloudflareそのものの使い勝手も、エージェント時代に合わせて変化している。開発者が管理画面でポチポチと設定を変えるのではなく、エージェントがAPIを通じてインフラを操作するシーンが増えるからだ。
統一CLI「cf」と管理画面AI「Agent Lee」
約3,000ものAPI操作を統合した新しいCLI（コマンドライン・インターフェース）「cf」が登場した。これは人間だけでなく、エージェントがインフラを操作する際の一貫性を保つために設計されている。また、Cloudflareのダッシュボード内には「Agent Lee」というAIアシスタントが常駐するようになった。ユーザーはプロンプトを入力するだけで、複雑なスタックのトラブルシューティングや設定変更を行える。
ドメイン登録もAPIから可能に
「Cloudflare Registrar API」がベータ版として公開された。これにより、エージェントが自らドメインを検索し、空き状況を確認して登録するまでを完全に自動化できる。エージェントが新しいサービスを立ち上げ、ドメインを取得し、デプロイするまでの全工程がプログラム可能になったことを意味する。
ウェブ全体をエージェント対応へアップデートする
現在のインターネットは人間が読むことを前提に作られているが、これからはエージェントが読みやすい「Agentic Web」への適応が求められる。Cloudflareは、サイト運営者がこの変化に対応するためのツールも提供開始した。
Agent Readiness ScoreとAIトレーニング用リダイレクト
自分のサイトがどれだけAIエージェントにとって読みやすいかを測定する「Agent Readiness Score」が導入された。構造化データが適切か、ボットのアクセスを過度に制限していないかなどを評価する。また、古いコンテンツをAIが学習しないように、検証済みのクローラーを最新のページへ自動で誘導する「Redirects for AI Training」機能も追加された。これにより、古い情報に基づいたAIの回答（ハルシネーション）を防ぐことができる。
独自の分析：Cloudflareが描く「Cloud 2.0」の正体
今回のAgents Weekを通じて見えてきたのは、Cloudflareが「エッジコンピューティング」の強みを最大限に活かし、他社とは異なるアプローチでAIインフラを構築しようとしている点だ。AWSやGoogle Cloudが巨大なGPUセンターに注力する一方で、Cloudflareは「エージェントの実行場所（推論と実行の融合）」という独自のポジションを狙っている。
筆者の見解では、Cloudflareが提唱する「Cloud 2.0」の核心は、ステート（状態）とコンピューティングの極限までの近接にある。Durable Objectsによる超低遅延な状態管理と、ミリ秒で起動するSandboxesの組み合わせは、数千万という単位で増殖するエージェントを効率よく捌くための唯一の解かもしれない。中央集権的なクラウドでは、これほど大量の独立したセッションを低コストで維持するのは困難だからだ。
また、セキュリティを「後付け」ではなく「デフォルト」に置いている点も重要だ。エージェントが自律的に動く世界では、一度の権限設定ミスが致命的な被害を招く。MeshやManaged OAuthをインフラ層で提供することで、開発者はセキュリティの専門知識がなくても「安全なエージェント」を構築できるようになる。これはエージェントの普及を加速させる大きな要因になるだろう。
この記事のポイント
- Cloudflareは、AIエージェントが主役となる「Agentic Cloud（Cloud 2.0）」への進化を宣言した。
- Git互換ストレージ「Artifacts」や隔離環境「Sandboxes」により、エージェント専用の計算基盤が整った。
- 「Cloudflare Mesh」や「Managed OAuth」により、非人間（エージェント）の安全な認証とアクセス制御が可能になった。
- 「Agents SDK」に記憶、検索、ブラウザ操作、音声、メール機能が統合され、開発効率が飛躍的に向上した。
- サイトのエージェント親和性を測る「Agent Readiness Score」など、ウェブ自体をエージェント向けに最適化するツールが登場した。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験