タグアーカイブ Cloudflare

AIエージェントに最適化されたWebサイトとは?Cloudflareが提唱するAgent Readinessスコアの全容

AIエージェントに最適化されたWebサイトとは?Cloudflareが提唱するAgent Readinessスコアの全容

Webサイトのあり方が、人間がブラウザで閲覧するものから、AIエージェントが自律的に情報を収集し処理するものへと劇的に変化している。かつてWebサイトが検索エンジンに最適化(SEO)されたように、これからはAIエージェントが理解しやすい形に最適化される必要がある。

Cloudflare(クラウドフレア)は、自社サイトがどの程度AIエージェントに対応できているかを測定するツール「isitagentready.com」を公開した。これは、AIがサイトをクロールし、内容を理解し、さらには決済まで行える状態にあるかを数値化する指標である。

現在、インターネット上の主要な20万ドメインを調査した結果、AIエージェントへの最適化が進んでいるサイトは極めて少ないことが判明した。しかし、これは早期に対応することで、競合他社よりもAIによる情報提供やサービス利用の面で優位に立てる可能性があることを示唆している。

AIエージェント向けのWeb最適化指標であるAgent Readinessとは

AIエージェント向けのWeb最適化指標であるAgent Readinessとは

Agent Readiness(エージェント・レディネス)は、WebサイトがAIエージェントという新しい「訪問者」をどれだけ歓迎し、効率的に情報を渡せるかを示す新しい概念である。Cloudflareが提供を開始した「isitagentready.com」では、URLを入力するだけで、そのサイトの対応状況をスコア化できる。

このスコアは、単に「AIを拒否していないか」を確認するだけのものではない。AIがサイト内を迷わずに移動できるか、情報を処理する際のコスト(トークン数)を削減できているか、そしてAIが自律的にアクションを起こせるかといった多角的な視点で評価される。

評価を構成する4つの主要な軸

Agent Readinessスコアは、主に以下の4つのカテゴリに基づいて算出される。それぞれの要素は、AIエージェントがサイトを訪れた際の「体験」を向上させるために不可欠なものだ。

  • ディスカバリー(発見しやすさ):AIがサイトの構造を即座に把握し、必要なページへたどり着けるか
  • コンテンツの最適化:AIが理解しやすい形式(Markdownなど)でデータを提供しているか
  • 制御とセキュリティ:AIの行動範囲を適切に制限し、信頼できるAIかどうかを認証できるか
  • インタラクション(相互作用):AIがAPIを介してツールを操作したり、決済を行ったりできるか

Cloudflare Radarの調査によれば、現在インターネット上の主要なサイトの約78%が「robots.txt」を設置しているが、そのほとんどは従来の検索エンジン向けに書かれたものである。AIエージェントに特化した設定を行っているサイトは、まだ全体の数パーセントに過ぎない。

AIエージェントに情報を届けるための新規格と実装方法

AIエージェントに情報を届けるための新規格と実装方法

AIエージェントがWebサイトを巡回する際、最大の障壁となるのが「HTMLの複雑さ」である。人間向けの装飾や広告が含まれるHTMLは、AIにとってノイズが多く、処理に多くのトークンを消費させる。これを解決するための新しい標準規格が登場している。

llms.txtによる「AI専用のお品書き」の提供

「llms.txt」は、Webサイトのルートディレクトリに配置するプレーンテキストファイルである。これは、AI(大規模言語モデル)に対して、サイトの概要や重要なコンテンツへのリンクをリスト化した「読書リスト」のような役割を果たす。サイトマップをAIが読みやすい言葉で書き直したものと考えると分かりやすい。

# サイト名
> サイトの短い説明文
## 主要ドキュメント
- [導入ガイド](https://example.com/docs/intro.md)
- [APIリファレンス](https://example.com/docs/api.md)

このファイルを設置することで、AIは数千ページあるサイトの中から、どのページを優先的に読むべきかを瞬時に判断できる。これにより、AIエージェントの回答精度が向上し、ユーザーが求める情報にたどり着くまでの時間が短縮される。

Markdownコンテンツ・ネゴシエーションによる軽量化

コンテンツ・ネゴシエーションとは、クライアント(訪問者)の要望に合わせて、サーバーが最適な形式のデータを返す仕組みである。AIエージェントがHTTPヘッダーに Accept: text/markdown を含めてリクエストを送った際、サーバーがHTMLではなくMarkdown形式を返すように設定することが推奨されている。

HTMLからMarkdownへの切り替えは、AIが消費するトークン数を最大で80%削減できるというデータがある。トークンの削減は、AIの処理速度を上げ、運用コストを下げることに直結する。以下のデモは、HTMLとMarkdownでどれほど情報の密度が異なるかを視覚化したものである。

従来のHTML表示(人間向け)
最新ニュース
投稿日:2026年4月17日
WebサイトのAI最適化が始まりました。これにより… [続きを読む]
※タグやスタイルなどの装飾データが大量に含まれる
AI向けMarkdown表示
# 最新ニュース
WebサイトのAI最適化が始まりました。
[詳細](https://example.com/news/1)
      
※純粋なテキストのみ。トークン消費を大幅に抑制

このデモのように、AIにとっては構造化されたテキストのみの方が扱いやすく、誤認のリスクも低い。Cloudflareでは、URLの末尾に /index.md を付与することで、動的にMarkdownを返す仕組みを推奨している。

AIエージェントの制御とセキュリティの新基準

AIエージェントの制御とセキュリティの新基準

すべてのAIエージェントにサイトを解放するのが正解とは限らない。コンテンツの無断学習を拒否したい、あるいは特定の信頼できるエージェントにのみアクセスを許可したいというニーズがある。これに対応するための規格が「Content-Signal」と「Web Bot Auth」である。

Content-Signalによる詳細な意思表示

従来の robots.txt では、アクセスを許可するか拒否するかという二択しかできなかった。新しい「Content-Signal」ディレクティブを使うと、AIによる学習(ai-train)、推論への利用(ai-input)、検索結果への表示(search)を個別に制御できる。

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

例えば、上記の記述では「AIの学習には使わせないが、AIがユーザーの質問に答える際の参考資料(RAG)としての利用や、検索結果への掲載は許可する」という柔軟な設定が可能になる。これにより、著作権を守りつつ、AIを介したトラフィックを確保できる。

Web Bot Authによるエージェントの身元確認

悪意のあるボットがAIエージェントを装ってアクセスしてくるリスクに対し、「Web Bot Auth」という認証規格が提案されている。これは、エージェントがリクエストにデジタル署名を付与し、サイト側がその署名を公開鍵で検証する仕組みである。

これにより、サイト運営者は「このアクセスは確かにOpenAIの公式エージェントからのものだ」と確信を持ってアクセスを許可できるようになる。匿名のスクレイパーと、正当なAIサービスを明確に区別するための重要なインフラとなるだろう。

自律的なアクションを可能にするAPIと決済の統合

自律的なアクションを可能にするAPIと決済の統合

AIエージェントの真の価値は、情報の閲覧だけでなく、ユーザーの代わりに「行動」することにある。買い物、予約、データの処理といったタスクをAIが自律的にこなすためには、WebサイトがAI向けの「窓口」を備えていなければならない。

MCP(Model Context Protocol)の活用

MCPは、AIモデルが外部のデータソースやツールと接続するためのオープン標準である。サイト側が「MCPサーバー」を用意し、その機能(ツール)を記述した「サーバーカード」を /.well-known/mcp/server-card.json に配置することで、AIはどのような操作が可能かを理解できる。

例えば、ドキュメント検索ツールや在庫確認ツールをMCP経由で公開すれば、AIエージェントは自らそのツールを呼び出し、ユーザーの複雑な要求に応えることができるようになる。これは、AIが「サイトを読む」段階から「サイトを使う」段階への進化を意味する。

HTTP 402によるマシン間決済の復活

AIエージェントが有料の情報を取得したり、商品を購入したりする場合、人間向けのクレジットカード入力画面は機能しない。そこで注目されているのが、長らく使われてこなかったHTTPステータスコード「402 Payment Required」の活用である。

「x402」と呼ばれるこの新しい決済フローでは、AIがリクエストを送ると、サーバーが402エラーとともに「支払い条件」を機械読み取り可能な形式で返す。エージェントはその条件に従って決済を行い、再度リクエストを送ることでコンテンツを取得できる。人間を介さない、マシン間の経済圏を支える技術である。

Cloudflare ドキュメントに見るAI最適化の実践事例

Cloudflare ドキュメントに見るAI最適化の実践事例

Cloudflareは自社の開発者向けドキュメントにおいて、これらの規格をいち早く導入している。その結果、AIエージェントによる回答速度が66%向上し、消費トークン数が31%削減されたという。具体的にどのような工夫がなされているのかを見てみよう。

URL書き換えによる動的なMarkdown提供

Cloudflareは、既存のHTMLページをわざわざMarkdownで書き直すのではなく、エッジコンピューティング(Cloudflare Rules)を活用して動的に変換している。URLの末尾に /index.md を付けると、オリジナルのHTMLからタグを取り除き、Markdownとして配信する仕組みだ。

これにより、メンテナンスコストを増やすことなく、人間向けとAI向けのコンテンツを両立させている。また、大規模なサイトでは llms.txt が巨大になりすぎるため、ディレクトリごとに分割した llms.txt を用意し、ルートからそれらをリンクする階層構造を採用している。

古い情報をAIに学習させないためのリダイレクト

Webサイトには、歴史的な理由で残されている古いドキュメント(非推奨のツールなど)が存在する。人間は「非推奨」という警告バナーを見て判断できるが、AIクローラーはテキストをそのまま飲み込んでしまい、古い情報をユーザーに教えてしまうことがある。

Cloudflareでは、AI学習用クローラーを識別し、古いページから最新のページへと強制的にリダイレクトさせる処理を行っている。これにより、AIが常に最新かつ正確な情報のみを学習するように制御している。これは、AI時代の新しいコンテンツ管理の形と言えるだろう。

独自の分析:Webサイトは「読むもの」から「使われるもの」へ

独自の分析:Webサイトは「読むもの」から「使われるもの」へ

Agent Readinessの普及は、Webサイトの設計思想を根本から変える可能性がある。これまでのWebデザインは、いかに人間の視線を誘導し、クリックさせるかという「UI/UX」が中心だった。しかし、AIエージェントが主役となる世界では、いかに機械が迷わず、低コストで目的を達成できるかという「DX(Developer Experience)ならぬAX(Agent Experience)」が重要になる。

特に注目すべきは、AIエージェントが「ブラウザ」を介さずに直接サーバーと対話するようになる点だ。これは、Webサイトが「情報の展示場」から「プログラム可能なインターフェース」へと進化することを意味している。APIが公開されていない小規模なサイトでも、llms.txt やMarkdown配信を導入することで、AIという強力な力を味方につけることができる。

今後、Googleなどの検索エンジンも、Agent Readinessスコアが高いサイトを「AIフレンドリーな良質なソース」として優遇する可能性がある。SEOの次のステージとして、この「AI最適化」への取り組みは、企業のデジタル戦略において避けて通れない課題となるだろう。

この記事のポイント

  • Agent Readinessスコアの登場:WebサイトがAIエージェントにどれだけ最適化されているかを測定する新しい指標が公開された
  • llms.txtとMarkdownの重要性:AI専用の案内図(llms.txt)と軽量なデータ形式(Markdown)が、AIの回答精度向上とコスト削減に直結する
  • 詳細なアクセス制御:Content-Signalにより、学習は拒否しつつ検索や推論への利用を許可するなど、柔軟な意思表示が可能になる
  • マシン間経済の加速:MCPによるツールの公開や、x402による自動決済など、AIが自律的にアクションを起こすためのインフラが整いつつある
  • 早期対応のメリット:現状では対応サイトが少ないため、今すぐ対策を始めることでAI経由のトラフィックや利便性において大きなアドバンテージを得られる
AIアプリに専用DBを即時提供!CloudflareのDurable Objects Facetsを解説

AIアプリに専用DBを即時提供!CloudflareのDurable Objects Facetsを解説

Cloudflareは、AIが生成したアプリケーションごとに専用のデータベースを割り当てることができる新機能「Durable Objects Facets(デュラブル・オブジェクト・ファセット)」をベータ公開した。この機能は、同社が提供する「Dynamic Workers」の仕組みを拡張したもので、動的に生成されたコードに対して、永続的なストレージを安全かつ高速に提供することを目的としている。

従来のサーバーレス環境では、実行時にコードをロードして実行する「動的なサンドボックス」において、データの永続化を管理することが技術的な障壁となっていた。しかし、Durable Objects Facetsの登場により、AIエージェントが作成した小さなツールや個人用アプリが、それぞれ独自のSQLiteデータベースを持ち、状態を保持し続けることが可能になる。

なぜこのアップデートがAI開発の現場において重要なのか、その背景にある「アイソレート」の技術や、新しいストレージの概念について詳しく紐解いていこう。AIが単にコードを書くだけでなく、自律的にデータを管理する「記憶を持つエージェント」へと進化する大きな一歩だと言える。

Dynamic Workersとアイソレートが支える高速な実行環境

Dynamic Workersとアイソレートが支える高速な実行環境

Durable Objects Facetsを理解するためには、まずその基盤となる「Dynamic Workers(ダイナミック・ワーカーズ)」について知る必要がある。Dynamic Workersとは、実行時にWorkerのコードをオンデマンドでロードし、安全なサンドボックス内で実行できる機能だ。

コンテナではなくアイソレートが実現する100倍の起動速度

Cloudflare Workersの最大の特徴は、一般的なクラウドサービスが採用している「コンテナ」技術ではなく、「アイソレート(Isolate)」という仕組みを利用している点にある。アイソレートとは、Google Chromeなどのブラウザを支えるV8エンジンが提供する、非常に軽量な実行環境の単位だ。

アイソレートはコンテナと比較して、起動速度が最大100倍速く、メモリ使用量は10分の1程度で済むという。この圧倒的な軽さにより、コードを実行するたびに環境を立ち上げ、終わったら即座に破棄するという「使い捨てのコンピューティング」が可能になった。Dynamic Workersは、このアイソレートの特性を最大限に活かし、AIが生成した数行のコードを即座に実行するセキュアな「eval()」のような役割を果たす。

従来のコンテナ方式
OS全体を仮想化するため重い。起動に数秒かかることがあり、リソース消費も大きい。
Cloudflare アイソレート方式
JavaScriptエンジン内で環境を分離。ミリ秒単位で起動し、数千の環境を同時に動かせる。

このデモは、コンテナとアイソレートの構造的な違いを視覚化したものだ。アイソレートの軽量さが、AIによる動的なコード実行を支えている。

AIエージェントによるコード実行の課題

AIエージェントがユーザーの依頼に応じてコードを書き、それを実行する場合、これまでは「一度きりのタスク」として処理されることが多かった。例えば、データの集計や特定のAPI呼び出しなどは、実行後に結果を返せばコード自体を保持し続ける必要はない。

しかし、ユーザーが「自分専用の家計簿アプリを作って」と依頼した場合、AIはUI(ユーザーインターフェース)だけでなく、入力されたデータを保存し続ける「ストレージ」も提供しなければならない。動的に生成されたコードが、どのようにして安全に、かつ自分専用のデータベースにアクセスするかが大きな課題となっていた。

Durable Objectsがもたらす超低遅延ストレージの仕組み

Durable Objectsがもたらす超低遅延ストレージの仕組み

この課題を解決するための強力な武器が「Durable Objects(デュラブル・オブジェクト)」だ。これはCloudflare Workersの中でも特殊な種類で、世界中で一意の名前を持つインスタンスを作成し、その状態を永続化できる仕組みを指す。

SQLiteをローカルディスクに持つ特殊なWorker

Durable Objectsの最大の特徴は、各インスタンスが自分専用のSQLiteデータベースを持っていることだ。しかも、このデータベースはDurable Objectsが動作している物理マシンの「ローカルディスク」上に配置される。通常のデータベースのようにネットワークを介してリクエストを送る必要がないため、データアクセスにおける遅延は実質的にゼロとなる。

CWV(Core Web Vitals / コアウェブバイタル)などの指標を気にするWeb制作の現場においても、この「ネットワーク遅延がないストレージ」は非常に魅力的だ。ユーザーに近い場所(エッジ)で計算と保存が完結するため、極めてレスポンスの速いアプリケーションを構築できる。

動的なコードとストレージの「相性の悪さ」

しかし、Durable ObjectsをDynamic Workersと組み合わせるには問題があった。通常、Durable Objectsを使用するには、開発者が事前にクラスを定義し、設定ファイル(wrangler.jsonc)で名前空間を宣言し、CloudflareのAPIを通じてプロビジョニング(利用準備)を行う必要がある。AIがその場で生成した未知のコードに対して、この一連の手順を動的に行うことは困難だった。

また、セキュリティ上の懸念もある。AIが生成したコードに、無制限にデータベースを作成する権限を与えてしまうと、リソースの乱用や管理不能なデータの増殖を招く恐れがある。開発者は「AIが書いたコードを実行しつつ、その裏側でストレージやログを適切に管理する」という、監督者のような役割を必要としていた。

新機能「Durable Objects Facets」による解決策

新機能「Durable Objects Facets」による解決策

そこで登場したのが、Durable Objects Facets(ファセット)だ。「Facet」とは「切り口」や「側面」を意味する言葉で、一つのDurable Objectの中に、複数の独立した実行環境とデータベースを持たせる概念を指す。

監視役(Supervisor)と実行役(Facet)の分離

この機能の核となるのは、開発者が書いた「監視役(Supervisor)」のコードの中で、AIが書いた「実行役(Facet)」のコードを動的にロードする仕組みだ。監視役は通常のDurable Objectとして動作し、リクエストを受け取ると、必要に応じてAIのコードをFacetとして呼び出す。

FacetとしてロードされたAIのコードは、自分専用のSQLiteデータベースを与えられる。このデータベースは監視役のデータベースとは論理的に分離されており、AIのコードが監視役の重要なデータ(課金情報や管理ログなど)を読み書きすることはできない。一方で、物理的には同じDurable Objectの一部として管理されるため、パフォーマンスの高さは維持される。

親: 監視役 (AppRunner)
・AIコードのロード管理
・ログ記録、レート制限
・管理用データベースを保持
内包 (Facet)
子: AIアプリ (Facet)
・AIが生成したロジック
・アプリ専用のSQLite DB
・親のDBにはアクセス不可

この図のように、一つのDurable Objectの中に「管理領域」と「AIの自由領域」を共存させるのがFacetの狙いだ。これにより、安全性を確保しながら動的なデータ永続化が可能になる。

親子関係で実現するセキュリティと制御

開発者は、AIが作成できるFacetの数を制限したり、各Facetが使用するストレージ容量を監視したりすることができる。これにより、AIが勝手に大量のデータを保存してコストを増大させるリスクを防げる。また、監視役のコードを通じてネットワークアクセスを制限(globalOutbound: null)することで、AIが生成したコードが外部にデータを送信するのを遮断することも可能だ。

これは、大規模なAIプラットフォームを構築するエンジニアにとって非常に重要な制御機能となる。ユーザーごとに異なるAIアプリを動かしても、インフラ側での統制が容易になるからだ。

実装例から見るAIアプリのプラットフォーム構築

実装例から見るAIアプリのプラットフォーム構築

実際に、どのようにしてこの仕組みを構築するのか、Cloudflareが公開したコード例を基に解説しよう。ここでは、AIが生成した「アクセス回数をカウントするアプリ」を動的にロードする例を考える。

コードの動的ロードとクラスのインスタンス化

まず、監視役となる AppRunner クラスを作成する。このクラスは this.ctx.facets.get() という新しいメソッドを使い、AIのコードをFacetとして取得する。もしFacetがまだ存在しない場合は、コールバック関数内でDynamic Workerをロードし、その中からAIが定義したクラスを取り出す。

// 監視役のコード例
export class AppRunner extends DurableObject {
  async fetch(request) {
    // "app" という名前のFacetを取得。なければ作成する。
    let facet = this.ctx.facets.get("app", async () => {
      // AIのコードをロード
      let worker = this.#loadDynamicWorker();
      // コード内から "App" という名前のクラスを取得
      let appClass = worker.getDurableObjectClass("App");
      return { class: appClass };
    });

    // リクエストをFacet(AIアプリ)に転送
    return await facet.fetch(request);
  }
}

注目すべきは、AIが書いたコード側でも extends DurableObject を使っている点だ。AIは通常のDurable Objectを書くのと同じ感覚でコードを生成でき、特別なFacet用の記法を覚える必要はない。

データベースの分離と永続化の管理

AIアプリ(Facet)が this.ctx.storage.kv.put() などのメソッドを使ってデータを保存すると、それはそのFacet専用のSQLiteデータベースに書き込まれる。監視役の AppRunner も自身のストレージを持っているが、これらは完全に別のファイルとして管理される。

この構造により、例えばあるユーザーのAIアプリがバグでデータを壊したとしても、監視役が持っている管理データや、他のユーザーのアプリには一切影響が及ばない。マルチテナント(複数のユーザーが一つのシステムを共有すること)な環境を構築する上で、この分離は極めて強力な防御壁となる。

今後のAIエージェント開発への影響と展望

今後のAIエージェント開発への影響と展望

Durable Objects Facetsの登場は、AIエージェントのあり方を大きく変える可能性を秘めている。これまでは「指示を聞いて答えるだけ」だったエージェントが、ユーザー固有のデータを蓄積し、それを基にパーソナライズされた体験を提供する「自律的なアプリケーション」へと進化するからだ。

「使い捨て」から「自律的な成長」へ

これまでのAI生成コードは、実行が終われば消えてしまう「刹那的」なものだった。しかし、専用のデータベースを持つことで、AIアプリは前回の実行時の状態を覚えていることができる。例えば、ユーザーの好みを学習し続けるレコメンドエンジンや、過去の対話履歴を構造化して保存する秘書アプリなどが、AI自身の手によって構築・運用されるようになるだろう。

Cloudflareの著者であるCarlo Daniele氏によれば、これは「Vibe-coded(雰囲気で書かれた)」個人用アプリを、セキュアな環境で永続化するための最適な解決策だという。プログラミングの知識がなくても、AIとの対話を通じて自分専用のツールを作り、それをクラウド上で安全に動かし続けることができる時代の到来だ。

開発者が考慮すべきコストとガバナンス

一方で、この技術を活用する開発者には、新たな責任も生じる。動的にデータベースが増えていくため、リソースのライフサイクル管理が不可欠だ。使われなくなったFacetをいつ削除するのか、バックアップはどうするのかといった、データガバナンスの設計が重要になる。

幸い、Durable ObjectsはCloudflareのインフラによって高度に抽象化されており、運用負荷は低い。しかし、AIが生成するコードの品質やデータの正当性をどう保証するかという点は、依然として人間(プラットフォーム開発者)が設計すべき領域として残っている。Durable Objects Facetsは、そのための「管理ツール」を開発者に提供したと言えるだろう。

この記事のポイント

  • Durable Objects Facetsは、AI生成コードごとに専用のSQLiteデータベースを割り当てる新機能である。
  • アイソレート技術により、コンテナよりも圧倒的に高速かつ軽量に動的なサンドボックスを起動できる。
  • 監視役(Supervisor)がAIのコードを制御することで、セキュリティと管理性を両立させている。
  • AIエージェントが「記憶」を持つことが可能になり、パーソナライズされたアプリ開発が加速する。
  • 現在はWorkers Paidプランのユーザー向けにオープンベータとして提供されている。
Cloudflare Organizationsベータ版登場!複数アカウントの一元管理とセキュリティ強化の全容

Cloudflare Organizationsベータ版登場!複数アカウントの一元管理とセキュリティ強化の全容

Cloudflare(クラウドフレア)は、大規模なエンタープライズ企業が自社のインフラをより効率的に管理するための新機能「Cloudflare Organizations(クラウドフレア・オーガニゼーションズ)」をベータ版として公開した。この機能は、これまで独立していた複数のCloudflareアカウントを一つの「組織」としてまとめ、一元的な管理を可能にするものだ。

大規模な組織では、数千人規模のユーザーが開発やセキュリティ、ネットワークなどの多岐にわたる業務でCloudflareを利用している。今回のアップデートにより、管理者は個別のログインや設定の繰り返しから解放され、組織全体のアナリティクスやポリシーを一括で制御できるようになる。

なぜこの機能が重要なのか。それは、セキュリティの鉄則である「最小権限の原則」を維持しながら、管理の複雑さを劇的に解消できるからだ。本記事では、Cloudflare Organizationsがもたらす変化とその技術的な背景を詳しく解説していく。

Cloudflare Organizationsが解決する大規模運用の課題

Cloudflare Organizationsが解決する大規模運用の課題

多くのエンタープライズ企業は、セキュリティを担保するために複数のCloudflareアカウントを使い分けている。これは、特定のチームに必要以上の権限を与えないための「最小権限の原則(Principle of Least Privilege)」に基づいた運用だ。

複数アカウントによる管理の断片化

最小権限の原則とは、ユーザーに業務遂行に必要な最小限のアクセス権だけを与える考え方だ。例えば、マーケティングチームが管理する特設サイトの設定と、基幹システムのネットワーク設定は、異なるアカウントで管理するのが望ましい。これにより、万が一ひとつのアカウントが侵害されても、被害を限定的に抑えられるからだ。

しかし、この運用には大きなデメリットがあった。管理者はすべてのアカウントに個別にアクセスし、権限を設定しなければならない。アカウントが増えるほど管理は「断片化」し、誰がどのアカウントに対してどのような権限を持っているのかを把握することが困難になっていたのだ。

運用の煩雑さとヒューマンエラーのリスク

従来、全社的なセキュリティレポートを作成する場合、管理者は各アカウントにログインして個別にデータを収集する必要があった。また、共通のセキュリティポリシーを適用する際も、アカウントごとに同じ設定を手動で繰り返す必要があり、これが設定ミスや漏れといったヒューマンエラーの原因となっていた。

Cloudflare Organizationsは、こうした「セキュリティのためのアカウント分割」が生み出した管理コストを削減するために設計されている。アカウントの独立性を保ったまま、管理レイヤーだけを統合する仕組みだ。

従来の管理(Before)
■ アカウントA(開発用)→ 個別にログイン
■ アカウントB(本番用)→ 個別にログイン
■ アカウントC(外部用)→ 個別にログイン
※管理者がバラバラに管理する必要がある
Organizations導入後(After)
組織(Organization)レイヤー
├ ■ アカウントA
├ ■ アカウントB
└ ■ アカウントC
※一つの画面から全アカウントを統制可能

このデモは、Organizationsがアカウントの階層構造をどのように整理するかを視覚化したものだ。

Organizationsの主要機能と新しい管理ロール

Organizationsの主要機能と新しい管理ロール

Cloudflare Organizationsの導入により、新しい管理権限の仕組みが導入された。その中心となるのが「Org Super Administrator(組織スーパー管理者)」というロールだ。

「Org Super Administrator」の役割

これまで、管理者は各アカウントの「Super Administrator」として登録される必要があった。しかし、Organizationsでは組織レベルで管理者を任命できる。この組織スーパー管理者は、組織に紐づけられたすべてのアカウントに対して、自動的に最高権限を持つことになる。

特筆すべきは、この管理者が個別のアカウントのユーザーリストに表示されない点だ。これにより、アカウント内の一般ユーザーが誤って管理者を削除してしまうといった事故を防ぐことができる。また、新しくアカウントが組織に追加された際も、管理者は即座にそのアカウントを制御できるため、オンボーディングのスピードが向上する。

複数アカウントを横断するダッシュボード

Organizationsのもう一つの大きな特徴は、アカウントを跨いだ情報の集約だ。ベータ版ではまず、HTTPトラフィックのアナリティクスが提供される。これにより、組織全体のトラフィック傾向や、特定のドメインでの異常なアクセス増加を一つの画面で監視できるようになった。

今後は、監査ログ(Audit Logs)や請求レポート(Billing Reports)も組織レベルで統合される予定だ。これにより、誰がいつ、どのアカウントで設定を変更したのかを組織全体で追跡できるようになり、コンプライアンスの強化にもつながる。

セキュリティと効率を両立する共有ポリシー

セキュリティと効率を両立する共有ポリシー

エンタープライズ企業にとって、セキュリティ基準を社内全体で統一することは至上命題だ。Cloudflare Organizationsは、この課題に対して「共有ポリシー」という強力な解決策を提示している。

WAFやGatewayポリシーの一括適用

これまでは、WAF(Web Application Firewall / ウェブアプリケーションファイアウォール)のルールを更新する場合、各アカウントにログインして同じ作業を繰り返す必要があった。しかし、Organizationsでは、特定のアカウントで作成したポリシーセットを、組織内の他のアカウントへ共有できる。

例えば、セキュリティ専門チームが管理する「マスターアカウント」で最新の脆弱性対策ルールを作成し、それを全社のアカウントに一括で適用するといった運用が可能になる。これにより、セキュリティレベルのばらつきをなくし、全社的な防御力を底上げできる。

共有ポリシーの仕組み
マスターポリシー(WAFルール等)
↓ 配布 ↓
■ アカウント1:適用済み
■ アカウント2:適用済み
■ アカウント3:適用済み
セキュリティチームが一度更新するだけで全アカウントに反映

この仕組みにより、各チームの担当者は自前で複雑なセキュリティ設定を行う必要がなくなり、本来の開発業務に集中できるようになる。

開発の舞台裏とパフォーマンスの改善

開発の舞台裏とパフォーマンスの改善

このOrganizations機能の実現は、Cloudflareの内部システムにおける大規模な刷新の結果でもある。Cloudflareのチームは、これを単なる新機能の追加ではなく、システム基盤の再構築として取り組んだ。

13万行のコード刷新とインナーソース開発

開発にあたっては「インナーソース(Innersource)」という手法が採用された。これは、オープンソースの開発手法を社内のプロジェクトに適用するものだ。このプロジェクトでは、約133,000行の新しいコードが追加され、32,000行の古いコードが削除された。Cloudflareの権限システム史上、最大級の変更となったという。

この刷新の目的は、古いコードパスを排除し、すべての認可チェックを「ドメインスコープのロールシステム」に集約することだ。これにより、将来的に新しいロールや機能をより迅速にリリースできる強固な土台が完成した。

権限チェック速度が27%向上

この基盤刷新は、ユーザー体験にも直接的なメリットをもたらしている。特に、数千ものアカウントやゾーン(ドメイン)にアクセス権を持つパワーユーザーにおいて、アカウント一覧やゾーン一覧の表示速度が課題となっていた。今回の最適化により、権限チェックのパフォーマンスが27%向上し、大規模環境での管理画面のレスポンスが大幅に改善された。

Organizationsの導入方法と今後の展望

Organizationsの導入方法と今後の展望

Cloudflare Organizationsは、まずエンタープライズプランの顧客を対象にパブリックベータとして公開されている。今後数ヶ月以内に、Pay-as-you-go(従量課金)プランを含むすべての顧客に拡大される予定だ。

安全な移行プロセス

導入はセルフサービス形式で行われる。エンタープライズアカウントのスーパー管理者であれば、ダッシュボードに招待が表示される仕組みだ。Cloudflare側が勝手に組織を作成することはない。これは、意図しない権限昇格を防ぐための配慮だ。

もし社内の別のユーザーがすでに組織を作成している場合は、そのユーザーから招待を受けるか、自分を組織の管理者として追加してもらう必要がある。このプロセスにより、どのアカウントを組織に含めるかを、各アカウントの管理者が明示的に承認する形が維持されている。

ロードマップに並ぶ強力な機能

Organizationsは、今後一年をかけてさらに進化する予定だ。現在公開されているロードマップには以下の項目が含まれている。

  • 組織レベルの監査ログ(Audit Logs)
  • 組織レベルの請求レポート
  • より詳細なアナリティクスレポートの拡充
  • 組織レイヤーでの追加ユーザーロール
  • セルフサービスによる新規アカウント作成

独自の分析:なぜ今、Cloudflareは「組織」単位の管理に注力するのか

独自の分析:なぜ今、Cloudflareは「組織」単位の管理に注力するのか

今回のアップデートは、Cloudflareが単なる「CDNベンダー」から、企業の「統合ネットワークインフラ」へと完全に脱皮したことを象徴している。かつてCloudflareは、個々のドメインを高速化・保護するためのツールだった。しかし現在、企業はアイデンティティ管理(Zero Trust)やサーバーレス開発(Workers)など、ビジネスの根幹をCloudflare上で動かしている。

利用範囲が広がれば、当然ながら管理する単位はドメインから「組織」へとシフトする。Organizationsの導入は、AWS(Amazon Web Services)が「AWS Organizations」を導入した際と同様の進化のプロセスと言えるだろう。

特に、WAFポリシーの共有機能は、セキュリティの民主化を加速させる可能性がある。高度なスキルを持つ中央のセキュリティチームが作成した「盾」を、全社の開発チームが意識することなく利用できる。この「ガードレール」としての役割こそが、現代のプラットフォームエンジニアリングが目指す姿だ。Cloudflareは今回の基盤刷新により、その理想を実現するための強力な武器を手に入れたと言える。

この記事のポイント

  • Cloudflare Organizationsにより、複数のアカウントを一元管理できるようになった
  • 「組織スーパー管理者」ロールにより、個別のアカウント管理が不要になる
  • WAFやGatewayのポリシーを組織全体で共有・一括適用が可能に
  • 内部システムの刷新により、権限チェックの速度が27%向上した
  • 現在はエンタープライズ向けベータ版で、順次全ユーザーに開放予定
500 Tbpsに達したCloudflareのネットワーク網!DDoS防御とAI時代のインフラを徹底解説

500 Tbpsに達したCloudflareのネットワーク網!DDoS防御とAI時代のインフラを徹底解説

Cloudflareのグローバルネットワークが、外部接続容量500 Tbps(テラビット毎秒)という大きな節目を超えた。2010年にパロアルトの小さなオフィスから始まった同社のインフラは、16年の歳月を経て世界330以上の都市に広がる巨大なデジタル基盤へと成長している。

この「500 Tbps」という数字は、単なるピーク時のトラフィック量ではない。トランジットプロバイダーやピアリングパートナー、インターネットエクスチェンジ(IX)などと接続された外部ポートの総容量を指している。この膨大な余剰キャパシティこそが、日々発生する大規模なDDoS攻撃を吸収するための「防御予算」として機能しているのだ。

現代のインターネットにおいて、これほどの規模を持つネットワークがどのように構築され、どのように自律的な防御を実現しているのか。最新の技術スタックと、急増するAIトラフィックへの対応策を含めて詳しく紐解いていく。

500 Tbpsの衝撃〜Cloudflareが到達した巨大ネットワークの現在地

500 Tbpsの衝撃〜Cloudflareが到達した巨大ネットワークの現在地

Cloudflareのネットワーク容量が500 Tbpsに達したことは、インターネットの歴史における一つの到達点といえる。2010年の設立当初、同社はたった一つのトランジットプロバイダーと契約し、ネームサーバーを2つ書き換えるだけで利用できるリバースプロキシとしてスタートした。それが今や、全ウェブサイトの20%以上を保護する巨大インフラへと変貌を遂げている。

世界330都市以上に広がる物理インフラの重み

「インターネットはクラウドである」と表現されることが多いが、その実体はケーブルとサーバーが詰まった物理的な部屋の集合体だ。Cloudflareはシカゴ、アッシュバーン、サンノゼ、アムステルダム、東京といった主要都市から始まり、カトマンズ、バグダッド、レイキャビクといった地域まで網羅してきた。

データセンターを一つ開設するごとに、コロケーション契約の交渉、光ファイバーの敷設、サーバーのラッキングといった地道な作業が繰り返される。2018年には、わずか24日間で31都市に拠点を展開するという驚異的なスピードで拡張を続けた。この物理的な拠点の多さが、ユーザーに近い場所でコンテンツを配信し、攻撃を水際で食い止めるための鍵となっている。

外部キャパシティ500 Tbpsが意味するもの

500 Tbpsという数字は、すべての外部接続ポートの合計値だ。日常的なトラフィックのピークは、この数字のほんの一部に過ぎない。残りの広大な帯域は、DDoS攻撃が発生した際にその衝撃を和らげるためのバッファとして確保されている。

かつては国家レベルのリソースがなければ対抗できなかったような大規模な攻撃も、この巨大なパイプラインの中では「日常的なイベント」として処理される。ネットワークの規模そのものが、セキュリティにおける最強の武器となっているのだ。

攻撃を呼吸するように受け流す〜31.4 TbpsのDDoSを防ぐ仕組み

攻撃を呼吸するように受け流す〜31.4 TbpsのDDoSを防ぐ仕組み

2025年、Cloudflareのネットワークは秒間31.4 Tbpsという猛烈なDDoS攻撃を検知し、わずか35秒で完全に無害化した。この攻撃には、感染したAndroid TVなどで構成された「Aisuru-Kimwolf」と呼ばれるボットネットが関与していた。驚くべきは、この規模の攻撃に対してもエンジニアが呼び出されることなく、システムが自律的に対処した点だ。

eBPFとXDPによる超高速パケット処理

この自律的な防御を支えているのが、Linuxカーネル内で動作する「eBPF(extended Berkeley Packet Filter)」と「XDP(eXpress Data Path)」という技術だ。パケットがネットワークカード(NIC)に到着した瞬間、OSの通常のネットワークスタックを通過する前に、XDPプログラムがそのパケットを評価する。

これにより、不正なパケットはCPUサイクルをほとんど消費することなく、入口で即座に破棄される。アプリケーション層に到達する前に処理が終わるため、サーバーの負荷を極限まで抑えることが可能だ。この仕組みを視覚化すると、以下のようになる。

1. ネットワークカード (NIC)
パケットが物理的に到着する入口
2. XDP / eBPF フィルタリング
不正なパケットを即座に破棄(ここで31.4 Tbpsを処理)
3. アプリケーション層 (Workers等)
正常なリクエストのみが到達し、処理される
防御の要となるレイヤー  通常の処理レイヤー

このデモは、パケットがどのように段階を経て処理されるかを示したものだ。XDPレイヤーでのフィルタリングが、後続のシステムをいかに保護しているかがわかる。

自律分散型の防御システム「dosd」

Cloudflareのすべてのサーバーには「dosd」と呼ばれるDDoS対策用のデーモンが常駐している。各サーバーは流入するトラフィックをサンプリングし、異常な通信パターンを検出すると、その情報を同じデータセンター内の全サーバーにブロードキャストする。

データセンター内のすべてのサーバーが同じデータに基づいて判断を下すため、特定のサーバーに負荷が集中することなく、拠点全体で一貫した防御が可能になる。さらに、決定されたルールは同社の分散型キーバリューストア「Quicksilver」を通じて数秒以内に全世界の拠点へ伝播される。これにより、ある拠点で検知された攻撃手法が、瞬時に地球の裏側の拠点でも通用しなくなる仕組みだ。

ネットワーク自体が開発プラットフォームへ〜Edge Computingの進化

ネットワーク自体が開発プラットフォームへ〜Edge Computingの進化

ネットワークを保護するためにすべてのサーバーでコードを実行できる環境を整えた結果、そのリソースを顧客に開放するという自然な流れが生まれた。これが「Cloudflare Workers」の始まりだ。現在では、単なるスクリプトの実行にとどまらず、より複雑なワークロードをエッジで動かすことが可能になっている。

WorkersからContainersへ

2025年、CloudflareはWorkersに「Containers」機能を追加した。これにより、V8アイソレートでは難しかった、より重量級のアプリケーションもエッジで動作させることができるようになった。独自のファイルシステムレイヤーにより、コールドスタート(起動時の遅延)を最小限に抑えつつ、ユーザーのすぐそばで計算リソースを提供する。

開発者が書いたコードは、前述のDDoS防御と同じサーバー上で動作する。つまり、攻撃トラフィックがl4dropによって破棄された直後の、クリーンな環境でアプリケーションが実行されるわけだ。インフラのセキュリティとパフォーマンスを同時に享受できるこの構造は、従来の中央集約型クラウドとは一線を画している。

インターネットの信頼性を担保する〜RPKIとASPAの重要性

インターネットの信頼性を担保する〜RPKIとASPAの重要性

ネットワークの規模が大きくなるほど、ルーティングの安全性に対する責任も増大する。BGP(Border Gateway Protocol)の脆弱性を突いたルートハイジャックは、インターネットの通信を誤った方向へ誘導し、大規模な障害やセキュリティ侵害を引き起こす原因となる。Cloudflareはこれらのリスクを低減するため、最新のプロトコル採用を強力に推進している。

ルートハイジャックを防ぐRPKI

RPKI(Resource Public Key Infrastructure)は、IPアドレスの所有者が誰であるかを証明するための仕組みだ。Cloudflareは早期からRPKIを導入し、無効なルートからのトラフィックを拒否する設定を徹底している。現在、グローバルなルーティングテーブルのうち、86万7,000件以上のプレフィックスが有効なRPKI証明書を持っており、10年前のほぼゼロに近い状態から劇的に改善された。

パスの正当性を検証するASPA

次に同社が注力しているのが「ASPA(Autonomous System Provider Authorization)」だ。RPKIが「誰が所有しているか」を検証するパスポートチェックだとすれば、ASPAは「どのような経路を通ってきたか」を検証するフライトマニフェスト(搭乗名簿)チェックに相当する。

従来のチェック(RPKIのみ)
「このアドレスの所有者はAさんで間違いないな」
※途中の経路で偽装されても気づけない
次世代のチェック(RPKI + ASPA)
「所有者も正しく、通ってきた経路も承認されたものだ」
※ルート漏洩や不正な経路誘導を完全にブロック

ASPAが普及すれば、設定ミスによるルート漏洩や、悪意のある経路誘導をより確実に防げるようになる。Cloudflareのような巨大ネットワークが先行して導入することで、インターネット全体のエコシステムを健全な方向へ導く狙いがある。

AIエージェントが変えるトラフィック構造〜4%の衝撃

AIエージェントが変えるトラフィック構造〜4%の衝撃

近年、インターネット上のトラフィックに大きな変化が起きている。人間がブラウザでリンクをクリックして発生する通信に加え、AIクローラーや自律型エージェントによるアクセスが急増しているのだ。現在、Cloudflareのネットワークを流れるHTMLリクエストの4%以上が、AI関連の通信で占められている。

ブラウザとクローラーの挙動の違い

AIクローラーは、人間が操作するブラウザとは根本的に異なる動きを見せる。ブラウザはページを読み込んだ後に一時停止するが、クローラーはリンクされたリソースを最大スループットで、休むことなく次々と取得していく。この挙動は、インフラ側から見るとDDoS攻撃と区別がつきにくい場合がある。

Cloudflareは、正規のAIクローラーと悪意のある攻撃を識別するために、TLSフィンガープリントや行動分析を組み合わせた高度な検知システムを運用している。例えば、ブラウザを装いつつもTLSのライブラリが不自然な構成であれば、それをシグナルとして検出し、サイト所有者が適切な判断を下せるようにデータを提供している。

独自の分析〜500 Tbps時代に企業が備えるべきインフラ戦略

独自の分析〜500 Tbps時代に企業が備えるべきインフラ戦略

Cloudflareが500 Tbpsという驚異的な容量を確保したことは、一企業のリリースの枠を超えた意味を持っている。これは、インターネットが「物理的な限界」を技術と規模で克服しつつあることを象徴している。しかし、インフラが強力になる一方で、攻撃の質も変化している点には注意が必要だ。

「防御の自動化」が企業の必須条件になる

31.4 Tbpsという攻撃を人間が介在せずに防いだという事実は、もはや「人間がログを見て遮断ルールを書く」という旧来の運用が通用しないフェーズに入ったことを示している。今後の企業インフラには、eBPF/XDPのようなカーネルレベルでの高速処理と、AIを活用した自律的なパターン認識が欠かせなくなるだろう。

エッジシフトとセキュリティの統合

Cloudflareの事例が示すように、これからは「セキュリティ対策」と「アプリケーション実行環境」を切り離して考えるべきではない。攻撃を捨てる場所でコードを動かすという「エッジコンピューティング」の思想は、パフォーマンス向上だけでなく、攻撃の爆風をアプリケーションに届かせない最強の盾となる。企業は、中央集約的なサーバー構成から、分散型のエッジインフラへの移行を真剣に検討すべき時期に来ているといえる。

この記事のポイント

  • Cloudflareの外部ネットワーク容量が500 Tbpsの大台を突破した
  • eBPFとXDPを活用し、31.4 Tbpsもの巨大DDoS攻撃を自動的に無害化している
  • 世界330以上の都市に分散された拠点が、ユーザーに近い場所でセキュリティと計算リソースを提供している
  • RPKIやASPAといった次世代プロトコルの導入により、ルーティングの安全性を世界規模で向上させている
  • トラフィックの4%を占めるようになったAIクローラーに対し、高度な識別技術で対応している
Cloudflareが2029年までの完全量子耐性化を宣言、認証保護の重要性が加速

Cloudflareが2029年までの完全量子耐性化を宣言、認証保護の重要性が加速

Cloudflareは、インターネットの安全性を根底から覆す可能性のある「量子コンピュータによる暗号解読」への対策を大幅に加速させている。同社は2029年までに、認証を含むすべてのサービスにおいて完全な量子耐性(Post-Quantum / PQ)を確保する計画を公表した。これは、従来の予測よりも数年早い目標設定となっている。

この背景には、GoogleやOratomicといった研究機関が発表した、量子アルゴリズムとハードウェアの劇的な進歩がある。最新の研究によれば、現在広く使われている楕円曲線暗号(ECC)を解読するために必要な量子ビット数が、当初の想定よりも遥かに少なくて済む可能性が示唆されている。もはやQ-Day(量子コンピュータが現代の暗号を破る日)は、遠い未来の出来事ではなくなったのだ。

本記事では、なぜCloudflareがロードマップを前倒ししたのか、そして量子耐性における「認証」の重要性がなぜ高まっているのかについて、技術的な観点から詳しく解説する。Webサイト運営者やエンジニアにとって、この2029年という期限は無視できない指標となるだろう。

Q-Dayが2029年に前倒しされた衝撃:研究が示す新たな脅威

Q-Dayが2029年に前倒しされた衝撃:研究が示す新たな脅威

これまで、量子コンピュータがRSA-2048やP-256といった現代の主要な暗号を解読できるようになるのは、2035年以降になると考えられてきた。しかし、2026年に入り、この予測を覆す重要な発表が相次いだ。特にGoogleが発表した、楕円曲線暗号を解読するための量子アルゴリズムの劇的な改善は、業界に大きな衝撃を与えている。

GoogleとOratomicによる技術的ブレイクスルー

Googleは、従来のアルゴリズムを大幅に高速化し、暗号解読に必要なステップ数を削減することに成功したと発表した。この発表ではゼロ知識証明が用いられ、具体的なアルゴリズムの詳細は伏せられつつも、その実現性が証明されている。これは、軍事機密や国家レベルのデータ保護に関わる深刻なリスクを意味する。

さらに、Oratomicという研究組織が発表したリソース見積もりも驚異的だ。中性原子量子コンピュータ(Neutral Atom Computer)を用いれば、P-256暗号をわずか10,000量子ビットで解読できる可能性が示された。従来、数百万人規模の物理量子ビットが必要とされていた予測と比較すると、必要とされるハードウェアの規模が数桁も小さくなったことになる。

加速する各社の移行タイムライン

これらの進展を受け、Google自身も量子耐性への移行期限を2029年に設定した。IBM Quantum SafeのCTOも、高価値なターゲットに対する「量子ムーンショット攻撃」が2029年にも発生する可能性を否定できないとの見解を示している。Cloudflareがロードマップを2029年に設定したのは、これら業界リーダーたちの動向と一致している。

量子コンピュータの研究は、かつては公共の場で活発に議論されていたが、現在は機密保持の傾向が強まっている。専門家の間では、すでに公開されている以上の進歩が水面下で起きているのではないかという懸念も広がっている。Q-Dayへの準備は、もはや「もしも」の備えではなく、「いつ」起きても対応できるようにするための緊急課題となったのだ。

量子コンピュータの進化を支える3つの技術的要因

量子コンピュータの進化を支える3つの技術的要因

なぜ、これほどまでに量子コンピュータの実用化が早まっているのだろうか。Cloudflareの分析によれば、量子コンピューティングの進化は「ハードウェア」「エラー訂正」「ソフトウェア」という独立した3つの分野が相互に影響し合うことで、複利的に加速しているという。

中性原子方式などのハードウェアの多様化

量子コンピュータの実現には、超電導方式やイオンラップ方式など、複数のアプローチが競い合っている。近年、特に注目を集めているのが「中性原子(Neutral Atom)」方式だ。この方式はスケーラビリティに優れており、Googleも超電導方式と並行してこの技術を追求し始めている。

中性原子方式は、光格子の中に原子を閉じ込めて制御する技術で、原子同士の結合を柔軟に変更できる特徴がある。この「再構成可能性」が、後述するエラー訂正の効率化に大きく寄与している。すべての方式が成功する必要はなく、どれか一つが壁を突破すれば、暗号解読は現実のものとなる。

エラー訂正技術の劇的な効率化

量子ビットは非常にノイズに弱く、実用的な計算を行うには「エラー訂正」が不可欠だ。従来、1つの論理量子ビット(エラーのない計算ができる単位)を作るには、約1,000個の物理量子ビットが必要だとされてきた。しかし、中性原子方式のような高い結合性を持つアーキテクチャでは、この比率が劇的に改善されることが判明した。

Oratomicの研究によれば、中性原子方式ではわずか3~4個の物理量子ビットで1つの論理量子ビットを構成できる可能性があるという。この効率化により、ハードウェアに求められる物理的な規模が100分の1以下に縮小された。これが、Q-Dayの予測が大幅に前倒しされた最大の技術的要因だ。

従来の超電導方式(1000:1)
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
= 物理量子ビット1個。1つの論理ビットに膨大な物理ビットが必要
最新の中性原子方式(4:1)
■■■■
= 物理量子ビット1個。わずか4個で論理ビットを構成可能

このデモは、エラー訂正に必要とされる物理量子ビット数の劇的な減少を視覚化したものだ。※このデモはCSSの概念を視覚化したイメージである。

「認証」の保護が急務となった理由:なりすましの脅威

「認証」の保護が急務となった理由:なりすましの脅威

これまで、量子耐性暗号(PQC)の議論は主に「今盗んで、後で解読する(Harvest Now, Decrypt Later / HNDL)」攻撃への対策に集中していた。これは、現在暗号化された通信をキャプチャしておき、将来強力な量子コンピュータが完成した時に解読するという手法だ。Cloudflareはこれに対抗するため、2022年からすべてのサイトで量子耐性暗号化をデフォルトで有効にしてきた。

しかし、Q-Dayが数年以内に迫っているとなれば、話は変わる。暗号化の保護だけでなく、「認証(Authentication)」の保護が最優先事項となるのだ。認証が破られるということは、攻撃者がサーバーになりすましたり、偽のアクセス資格情報を偽造したりできることを意味する。

認証の失敗は致命的なシステム侵害を招く

暗号化が破られた場合、漏洩するのは「データ」だが、認証が破られた場合は「システムそのもの」の制御を奪われる。例えば、ソフトウェアアップデートの署名が偽造されれば、攻撃者は任意のマルウェアを世界中のデバイスに配布できる。また、APIキーやルート証明書が偽造されれば、正規のユーザーとしてシステムにログインし、永続的なバックドアを設置することも可能だ。

量子コンピュータが普及し始めた初期段階では、その計算リソースは非常に高価で希少なものになる。そのため、攻撃者は費用対効果の高い「高価値なターゲット」を狙う。長期間有効なルート証明書や、企業の基幹システムにアクセスできるAPIキーがその筆頭だ。一度認証を突破されれば、攻撃者は発見されるまで、あるいは鍵が失効するまで、自由自在にシステム内を探索できてしまう。

移行にかかる数年単位の依存関係

認証システムの量子耐性化は、暗号化のアップグレードよりも遥かに困難だ。なぜなら、証明書の発行元(CA)、サーバー、クライアント(ブラウザやアプリ)のすべてが新しい規格に対応する必要があるからだ。この依存関係の連鎖をすべて解決し、古い脆弱な暗号を完全に無効化するまでには、数ヶ月ではなく数年単位の時間が必要となる。

また、単に新しい暗号をサポートするだけでは不十分だ。攻撃者が通信を操作して、意図的に古い脆弱な暗号アルゴリズムを使わせる「ダウングレード攻撃」を防ぐ必要がある。これを実現するには、PQ HSTS(Post-Quantum HTTP Strict Transport Security)のような新しい仕組みの導入や、証明書の透明性(Certificate Transparency)の確保が不可欠だ。

Cloudflareのロードマップと今後の対策

Cloudflareのロードマップと今後の対策Cloudflareは、2029年までに認証を含む全製品スイートで完全な量子耐性を実現することを目指している。同社は10年以上前からこの問題に取り組んできたが、今回のロードマップ更新により、取り組みをさらに一段階引き上げた形だ。具体的には、中間目標を設定し、段階的に認証システムの移行を進めていくとしている。企業や組織が今すぐ取り組むべきことCloudflareを利用している一般のユーザーは、特別な操作を行う必要はない。同社はこれまで通り、量子耐性セキュリティをデフォルトで有効化し、追加費用なしで提供する方針だ。しかし、企業が管理する内部システムや、サードパーティの依存関係については注意が必要だ。まず、新規でソフトウェアやサービスを導入する際の要件に「量子耐性(PQC)への対応」を含めることが推奨される。また、ソフトウェアを常に最新の状態に保ち、証明書の発行を自動化しておくことも重要だ。自動化されていれば、将来新しい量子耐性証明書への切り替えが必要になった際、迅速に対応できるからだ。政府や規制当局への提言Cloudflareは、政府機関に対しても、明確なタイムラインを設定して移行を主導するよう求めている。規格の断片化を避け、国際的な標準規格(NISTが策定しているPQCアルゴリズムなど)を採用することが、インターネット全体の安全性を高める鍵となる。パニックに陥る必要はないが、自信を持って移行を推進するリーダーシップが求められている。最終的に、量子耐性への移行は「すべての秘密情報のローテーション」を伴う巨大なプロジェクトになる。かつてのSSLからTLSへの移行、あるいは無料SSLの普及がインターネットを暗号化したように、無料の量子耐性暗号が次世代のインターネットを守る基盤となるだろう。Cloudflareはそのための環境を、2029年までに整えるとしている。独自の分析:移行の「ラストワンマイル」とレガシーの壁Cloudflareが2029年という野心的な目標を掲げたことは、業界全体への強力なメッセージだ。しかし、技術的な観点から分析すると、最大の関門は「古い規格の切り捨て」にある。新しいアルゴリズムを追加するのは比較的容易だが、古いアルゴリズムを無効化しなければ、ダウングレード攻撃のリスクは残り続けるからだ。特にWebブラウザの世界では、古いOSや古いデバイスを使っているユーザーが一定数存在する。これらのレガシーな環境を維持しつつ、最新のセキュリティを強制することは、利便性と安全性のトレードオフを伴う。Cloudflareのようなインフラ企業がデフォルトでPQを有効にすることは、この「レガシーの壁」を突破するための大きな推進力になるだろう。また、量子耐性認証への移行は、単なる技術的なアップデートに留まらず、企業の信頼性そのものを定義し直すプロセスになる。2029年という期限は、私たちが思っているよりもずっと近い。今からシステムの棚卸しを行い、どの鍵が「長寿命」で「高価値」なのかを特定しておくことが、Q-Dayを無事に乗り越えるための唯一の道だと言える。この記事のポイント

Cloudflareは、2029年までに認証を含む全製品スイートで完全な量子耐性を実現することを目指している。同社は10年以上前からこの問題に取り組んできたが、今回のロードマップ更新により、取り組みをさらに一段階引き上げた形だ。具体的には、中間目標を設定し、段階的に認証システムの移行を進めていくとしている。

企業や組織が今すぐ取り組むべきこと

Cloudflareを利用している一般のユーザーは、特別な操作を行う必要はない。同社はこれまで通り、量子耐性セキュリティをデフォルトで有効化し、追加費用なしで提供する方針だ。しかし、企業が管理する内部システムや、サードパーティの依存関係については注意が必要だ。

まず、新規でソフトウェアやサービスを導入する際の要件に「量子耐性(PQC)への対応」を含めることが推奨される。また、ソフトウェアを常に最新の状態に保ち、証明書の発行を自動化しておくことも重要だ。自動化されていれば、将来新しい量子耐性証明書への切り替えが必要になった際、迅速に対応できるからだ。

政府や規制当局への提言

Cloudflareは、政府機関に対しても、明確なタイムラインを設定して移行を主導するよう求めている。規格の断片化を避け、国際的な標準規格(NISTが策定しているPQCアルゴリズムなど)を採用することが、インターネット全体の安全性を高める鍵となる。パニックに陥る必要はないが、自信を持って移行を推進するリーダーシップが求められている。

最終的に、量子耐性への移行は「すべての秘密情報のローテーション」を伴う巨大なプロジェクトになる。かつてのSSLからTLSへの移行、あるいは無料SSLの普及がインターネットを暗号化したように、無料の量子耐性暗号が次世代のインターネットを守る基盤となるだろう。Cloudflareはそのための環境を、2029年までに整えるとしている。

独自の分析:移行の「ラストワンマイル」とレガシーの壁

Cloudflareが2029年という野心的な目標を掲げたことは、業界全体への強力なメッセージだ。しかし、技術的な観点から分析すると、最大の関門は「古い規格の切り捨て」にある。新しいアルゴリズムを追加するのは比較的容易だが、古いアルゴリズムを無効化しなければ、ダウングレード攻撃のリスクは残り続けるからだ。

特にWebブラウザの世界では、古いOSや古いデバイスを使っているユーザーが一定数存在する。これらのレガシーな環境を維持しつつ、最新のセキュリティを強制することは、利便性と安全性のトレードオフを伴う。Cloudflareのようなインフラ企業がデフォルトでPQを有効にすることは、この「レガシーの壁」を突破するための大きな推進力になるだろう。

また、量子耐性認証への移行は、単なる技術的なアップデートに留まらず、企業の信頼性そのものを定義し直すプロセスになる。2029年という期限は、私たちが思っているよりもずっと近い。今からシステムの棚卸しを行い、どの鍵が「長寿命」で「高価値」なのかを特定しておくことが、Q-Dayを無事に乗り越えるための唯一の道だと言える。

この記事のポイント

  • Cloudflareは2029年までに認証を含む完全な量子耐性(PQ)化を目指す。
  • 最新の研究により、量子コンピュータによる暗号解読の必要リソースが激減している。
  • 暗号化だけでなく「認証」の保護が急務。認証が破られるとなりすましやシステム乗っ取りが可能になる。
  • 中性原子方式の進化により、エラー訂正効率が従来の1,000:1から4:1程度まで改善される見込み。
  • 企業は今後の調達要件にPQ対応を含め、証明書管理の自動化を進めるべきだ。
Cloudflareの1.1.1.1が独立監査を完了。プライバシー保護の信頼性を再確認

Cloudflareの1.1.1.1が独立監査を完了。プライバシー保護の信頼性を再確認

Cloudflare(クラウドフレア)が提供するパブリックDNSサービス「1.1.1.1」が、第三者機関による独立したプライバシー監査を完了した。今回の監査は大手会計事務所(いわゆるBig 4の一角)によって実施され、同社が掲げる「ユーザーの個人データを収集・保持しない」という公約が技術的に守られていることが改めて証明された。

1.1.1.1は2018年4月1日のサービス開始以来、世界最速級のスピードと強固なプライバシー保護を両立させることを目標としてきた。2020年に続く2度目の大規模な独立監査を終えたことで、同社はインターネットのインフラを担う企業としての透明性をさらに強化した形だ。

DNSは「インターネットの電話帳」とも呼ばれる重要な仕組みだが、多くのユーザーはその背後でデータがどのように扱われているかを知る機会が少ない。今回の監査結果は、Webサイト運営者や一般ユーザーが安心してインフラを選択するための重要な指標となるだろう。

パブリックDNS「1.1.1.1」が目指すプライバシーの標準

パブリックDNS「1.1.1.1」が目指すプライバシーの標準

DNS(Domain Name System / ドメイン・ネーム・システム)とは、ブラウザに入力された「example.com」のようなドメイン名を、コンピュータが理解できる「192.0.2.1」のようなIPアドレスに変換する仕組みを指す。私たちがWebサイトを閲覧する際、必ず最初に行われるのがこのDNSへの問い合わせだ。

通常、このDNSサービスは契約しているインターネットサービスプロバイダー(ISP)が提供している。しかし、ISPのDNSは必ずしも高速ではなく、場合によってはユーザーがどのサイトを訪れたかという履歴を収集し、広告配信などに利用する懸念が指摘されてきた。こうした背景から、Cloudflareは「プライバシー第一」を掲げた1.1.1.1を立ち上げた経緯がある。

DNSリゾルバーとは何か

DNSリゾルバーとは、ユーザーからの問い合わせを受け取り、適切なIPアドレスを探し出して回答するシステムの総称だ。1.1.1.1はこのリゾルバーとして機能する。Cloudflareによれば、同社のシステムはユーザーのIPアドレスをディスクに書き込まず、24時間以内にすべてのログを削除するように設計されている。

これは、たとえ政府機関や第三者からデータの開示請求があったとしても、そもそもデータが存在しないために提供できない状態を作ることを意味する。技術的に「見ることができない」状態を構築することが、同社のプライバシー戦略の核心だ。

独立監査を継続する理由

企業が「プライバシーを守っている」と主張するのは簡単だが、それをユーザーが検証するのは難しい。Cloudflareは自社の言葉を裏付けるために、外部の専門家による監査を定期的に受けている。2020年の初回監査に続き、今回の2026年の報告書(2024暦年の運用を対象としたもの)でも、同社の主張が事実であることが確認された。

Cloudflareのブログによれば、他の主要なパブリックDNSプロバイダーの中で、このように独立したプライバシー監査を公に受けている企業は、同社が把握する限り存在しないという。この姿勢は、単なる機能提供を超えた「信頼」という付加価値を市場に提示している。

2026年の監査結果と技術的な透明性

2026年の監査結果と技術的な透明性

今回の監査プロセスは、数ヶ月にわたる膨大な証拠収集を経て完了した。Cloudflare内の多くのチームが協力し、プライバシー管理が実際に機能していることを外部監査人に示したという。その結果、同社のコアとなるプライバシー保証は変わらず維持されていることが確認された。

ここで重要なのは、同社が「完璧なゼロデータ」を謳っているわけではないという点だ。ネットワークの健全性を保つためには、最低限のデータ利用が必要になる。今回の報告では、そうした例外的な処理についても透明性が確保されている。

プライバシー保証が再確認された意義

監査によって確認された主要なポイントは、DNS問い合わせから取得した情報を、他のCloudflareデータや第三者のデータと結びつけて個人を特定することはないという約束だ。これは、例えば同社の他のサービス(CDNやWAFなど)で得られたデータと、1.1.1.1の利用履歴を照合して「どのユーザーが何を見ているか」を分析することはない、ということを意味する。

Web制作に関わる立場から見れば、クライアントのサイト訪問者のプライバシーを守るためにも、信頼できるDNSインフラを推奨できる根拠が強まったと言えるだろう。

トラブルシューティングとデータ利用の限定範囲

Cloudflareは、ネットワークのトラブルシューティングや攻撃の緩和(DDoS対策など)のために、ごく一部のパケットをサンプリングしていることを公表している。その割合は最大でも全トラフィックの0.05%以下だ。このサンプリングデータにはユーザーのIPアドレスが含まれる場合があるが、あくまでネットワークの正常な運用のためにのみ使用される。

こうした「何を行っていないか」だけでなく「必要最小限で何を行っているか」を明示する姿勢こそが、プロフェッショナルなテックブログとしての信頼感に繋がっている。情報の透明性は、ユーザーとの信頼関係を築くための唯一の手段だと言える。

通常のDNS
・ISPが履歴を収集
・広告に利用される懸念
・暗号化されない場合が多い
1.1.1.1
・ログを24時間で消去
・独立監査による証明済み
・DoH/DoTで通信を暗号化

このデモは、一般的なDNSと1.1.1.1のプライバシーの扱いの違いを視覚化したものだ。

独自のインフラ刷新とセキュリティの進化

独自のインフラ刷新とセキュリティの進化

2020年の監査から現在に至るまで、Cloudflareの技術スタックは大きく進化している。同社は1.1.1.1を支えるプラットフォームを完全に刷新し、よりスケーラブルで複雑な要求に応えられる体制を整えた。この新プラットフォームにおいても、当初のプライバシー公約が厳格に適用されているかどうかが、今回の監査の大きな焦点だった。

技術の規模が拡大すれば、それだけデータの管理は難しくなる。しかしCloudflareは、技術的な手段によって「そもそも追跡できない」仕組みを維持し続けている。これは、システムの設計段階からプライバシーを組み込む「プライバシー・バイ・デザイン」の好例だ。

新プラットフォームへの移行

新しいプラットフォームでは、1.1.1.1だけでなく他のDNS関連システムも統合されている。これにより、世界中のエッジサーバーでの処理速度が向上した。DNSの応答速度が上がることは、Webサイトの最初の読み込み時間が短縮されることを意味し、結果としてSEOやユーザー体験(UX)の向上に寄与する。

監査では、この新しい複雑なインフラにおいても、個人を特定可能なデータが適切に処理・破棄されていることが確認された。技術が進歩しても、ユーザーとの約束は変わらないというメッセージが強調されている。

匿名化データの活用とCloudflare Radar

Cloudflareは、匿名化されたトランザクションデータやデバッグログを、インターネットのトレンドを分析する「Cloudflare Radar」などの研究目的に活用している。Radarは世界中のトラフィックパターンやサイバー攻撃の動向を可視化するツールだが、ここでも個人のプライバシーに影響を与えないよう配慮されている。

2020年の監査時と比較して、こうしたデータの活用方法は進化しているが、監査報告によれば「個人情報の保護」という観点での影響はないと結論付けられている。匿名化されたビッグデータとして扱うことで、個人の特定を避けつつ、インターネット全体の安全性向上に役立てているわけだ。

ユーザーが1.1.1.1を選ぶべき実務的なメリット

ユーザーが1.1.1.1を選ぶべき実務的なメリット

Web制作やサイト運営に携わる立場として、なぜ1.1.1.1を推奨、あるいは利用すべきなのか。その理由は「速度」と「プライバシー」の2点に集約される。特に近年、プライバシー保護は法的・倫理的な観点だけでなく、ユーザーがサービスを選ぶ際の重要な基準となっている。

1.1.1.1を利用することで、ISPによるブラウジング履歴の収集を防げるだけでなく、フィッシングサイトやマルウェアを配布するドメインへのアクセスをブロックする機能(1.1.1.1 for Familiesなど)も選択できる。これは、組織のセキュリティレベルを底上げする安価で効果的な手段だ。

速度とプライバシーの両立

DNSの応答速度は、サイトの表示速度に直結する。Cloudflareは世界中に広がる自社のエッジネットワークを活用し、世界最速級のDNSレスポンスを実現している。プライバシーを重視するために速度を犠牲にする必要がない点は、プロフェッショナルな環境で選ばれる大きな理由だ。

また、DoH(DNS over HTTPS)やDoT(DNS over TLS)といった暗号化プロトコルに対応していることも重要だ。これにより、公共のWi-Fiなどを利用している際でも、DNSクエリの内容を第三者に盗み見られるリスクを大幅に軽減できる。

設定方法の簡便さ

1.1.1.1の導入は驚くほど簡単だ。PCやスマートフォンのネットワーク設定でDNSサーバーのアドレスを「1.1.1.1」に変更するだけで完了する。また、専用のモバイルアプリ(WARP)を利用すれば、ワンタップで設定を適用できる。この導入のしやすさは、技術に詳しくないクライアントや従業員に推奨する際にも大きなメリットとなる。

企業がDX(デジタルトランスフォーメーション)を進める中で、インフラのセキュリティとプライバシーを確保することは避けて通れない。1.1.1.1のような透明性の高いサービスを基盤に据えることは、長期的なリスク管理の第一歩と言えるだろう。

この記事のポイント

  • Cloudflareの「1.1.1.1」は、大手会計事務所による2度目の独立プライバシー監査を完了した。
  • ユーザーのIPアドレスを保持せず、個人を特定しないという同社の公約が技術的に証明された。
  • ネットワーク運用のためのサンプリングは全トラフィックの0.05%以下に制限されている。
  • 新しいプラットフォームへの移行後も、プライバシー・バイ・デザインの原則が維持されている。
  • 1.1.1.1の利用は、Webサイトの表示速度向上とプライバシー保護を同時に実現する有効な手段だ。
Cloudflare、eBPFでDDoS対策を自作できるProgrammable Flow Protectionを発表

Cloudflare、eBPFでDDoS対策を自作できるProgrammable Flow Protectionを発表

Cloudflareは、Magic Transitの利用者向けに、独自のDDoS緩和ロジックを実装できる「Programmable Flow Protection」を発表した。このシステムは、ユーザーが記述したeBPFプログラムをCloudflareのグローバルネットワーク全体にデプロイし、パケットレベルでの精密な制御を可能にするものだ。

2026年3月31日に公開された情報によると、この新機能は特にUDPをベースとした独自の通信プロトコルを利用するサービスにおいて、これまでにない柔軟な防御手段を提供する。現在はベータ版として、Magic Transit Enterpriseプランのユーザー向けに追加オプションとして提供が開始されている。

従来のDDoS対策システムでは対応が難しかった「未知のプロトコル」に対し、インフラ側が中身を理解するのではなく、ユーザーが「正しいパケット」の定義を教え込むというアプローチが採用された点が、今回のアップデートの核心だ。

UDPプロトコル保護の難しさと従来の限界

UDPプロトコル保護の難しさと従来の限界

ネットワーク通信において、UDP(User Datagram Protocol)は速度とリアルタイム性を重視する場面で多用される。オンラインゲームや音声通話(VoIP)、動画ストリーミングなどがその代表例だ。しかし、このUDPの特性が、DDoS対策においては大きな障壁となってきた。

コネクションレスというUDPの性質

UDPはTCP(Transmission Control Protocol)とは異なり、通信の開始時に「ハンドシェイク」と呼ばれる接続確認の手順を踏まない。パケットが順番通りに届く保証もなく、状態を持たない「コネクションレス」なプロトコルである。このシンプルさが高速な通信を実現する一方で、送信元を偽装した攻撃パケットを見分けることを難しくしている。

DNSやNTPといった標準的なプロトコルであれば、パケットの構造が世界共通であるため、Cloudflareのようなプラットフォーム側で「異常なデータ」を検知しやすい。しかし、独自のゲームエンジンや社内システムで使われるカスタムプロトコルの場合、パケットの中身が暗号化されていたり、独自のヘッダー構造を持っていたりするため、外部の防御システムからは単なる「意味不明なデータの塊」にしか見えないのだ。

従来の「レートリミット」が抱えるジレンマ

これまでのDDoS対策では、こうした未知のUDPプロトコルに対して「レートリミット(帯域制限)」という手段が主に使われてきた。特定のIPアドレスやポート番号からの通信が一定量を超えた場合に、一律で遮断や制限をかける方法だ。しかし、これには大きな欠点がある。

レートリミットは「良い通信」と「悪い通信」を区別しない。攻撃が激しくなると、正規のユーザーの通信も制限に巻き込まれ、ラグや切断が発生してしまう。これは、攻撃者の目的である「サービスの停止」を、防御システム自らが手助けしてしまうような結果を招く。また、ユーザーごとに期待される通信量は異なるため、一律の基準値を設定すること自体が非常に困難であった。

Programmable Flow Protectionの仕組みとeBPFの活用

Programmable Flow Protectionの仕組みとeBPFの活用

Programmable Flow Protectionは、前述した「中身がわからない」という課題を、ユーザーにロジックを記述させることで解決する。ここで重要な役割を果たすのが「eBPF(extended Berkeley Packet Filter)」という技術だ。

eBPFによるパケットレベルの制御

eBPFとは、OSのカーネル(中枢部)の機能を、カーネル自体を書き換えることなく安全に拡張できる仕組みだ。最近のシステム開発では、ネットワークの監視やセキュリティ対策で急速に普及している。Programmable Flow Protectionでは、ユーザーがC言語などで記述したeBPFプログラムをCloudflareにアップロードする。

アップロードされたプログラムは、Cloudflareのネットワークに届くすべてのパケットに対して実行される。プログラム内で「パケットの32バイト目にある特定のトークンが正しいか」といった独自の条件をチェックし、合致しなければその場でパケットを破棄(ドロップ)する。これにより、アプリケーションサーバーに届く前に、エッジ(利用者に近い拠点)で攻撃を食い止めることが可能になる。

ユーザー空間での安全な実行環境

通常、eBPFはOSのカーネル内で動作するが、Cloudflareのこのシステムでは「ユーザー空間(アプリケーションが動く領域)」で実行される。これにより、特定のユーザーのプログラムが原因でシステム全体が不安定になるリスクを排除しつつ、高度な柔軟性を確保している。

また、プログラムは実行前に「ベリファイア(検証器)」によってチェックされる。メモリ操作に問題がないか、無限ループに陥らないかなどが厳密に確認されるため、安全性が担保されている。Cloudflareの既存のDDoS緩和システムが動作した後にこのカスタムロジックが適用されるため、標準的な攻撃は従来通り自動で防がれ、その網をすり抜けるような特殊な攻撃だけを自作ロジックで仕留めるという二段構えの構成が可能だ。

具体的なユースケース:オンラインゲームの独自プロトコル

具体的なユースケース:オンラインゲームの独自プロトコル

この技術が最も威力を発揮する場面の一つが、オンラインゲームの運営だ。独自のゲームエンジンを使用している場合、攻撃者は正規のパケットに似せたデータを大量に送りつけることで、ゲームサーバーをダウンさせようとする。

カスタムヘッダーによるパケット検証

例えば、あるゲームがUDPの207番ポートを使用しており、パケット内の特定の場所に「認証トークン」を含めているとする。Cloudflare側はこのトークンの構造を知らないが、ゲームの開発者はそれを熟知している。Programmable Flow Protectionを使えば、以下のようなロジックをデプロイできる。

// C言語によるeBPFプログラムのイメージ(一部抜粋)
uint64_t cf_ebpf_main(void *state) {
    // パケットヘッダーの解析
    struct cf_ebpf_parsed_headers headers;
    if (parse_packet_data(ctx, &p, &headers) != 0) return CF_EBPF_DROP;

    // ポート207以外はドロップ
    if (ntohs(udp_hdr->dest) != 207) return CF_EBPF_DROP;

    // 独自ヘッダー内のトークンの末尾が「0xCF」かチェック
    uint8_t *last_byte = app->token + token_len - 1;
    if (*last_byte != 0xCF) {
        return CF_EBPF_DROP; // 不正なパケットを破棄
    }

    return CF_EBPF_PASS; // 正当なパケットのみ通過
}

このように、プロトコルの仕様に基づいた「門番」をCloudflareのエッジに配置することで、ランダムなデータを送りつける攻撃(UDPフラッド)を効率的に排除できる。

リプレイ攻撃を防ぐステートフルな追跡

さらに高度な攻撃として「リプレイ攻撃」がある。これは、過去に送信された正当なパケットを攻撃者が記録し、それをそのまま大量に送り直す手法だ。パケットの構造自体は正しいため、単純なヘッダーチェックだけでは防げない。

Programmable Flow Protectionは、単なるフィルターに留まらず、通信の「状態(ステート)」を保持する機能を持っている。これを利用して、未知の送信元IPアドレスに対して「チャレンジ(暗号的な問いかけ)」を送り、正しく応答できたIPアドレスだけを一定期間「許可リスト」に登録するといった運用が可能だ。スクリプトで動いている攻撃者のツールはこうしたチャレンジに応答できないため、リプレイ攻撃を無効化できる。これは、Webサイトでいうところの「CAPTCHA」や「Cookie確認」を、UDPパケットのレベルで実現しているようなものだ。

開発者視点でのメリットと実装の柔軟性

開発者視点でのメリットと実装の柔軟性

このシステムの真価は、Cloudflareが提供する強力なインフラを、自社のエンジニアが自由にプログラミングできる点にある。従来のハードウェアベースのファイアウォールや、固定的な設定しかできないクラウドサービスとは一線を画す柔軟性だ。

高度なヘルパー関数の提供

eBPFプログラムをゼロから書くのは骨が折れる作業だが、Cloudflareは開発を支援するための「ヘルパー関数」を多数用意している。例えば、パケットデータの解析、送信元IPアドレスごとの状態保存、暗号学的な検証、チャレンジパケットの生成といった複雑な処理を、APIを通じて簡単に呼び出すことができる。

これにより、開発者は「パケットをどう処理するか」というビジネスロジックに集中でき、ネットワークスタックの深い知識がなくても高度な防御機能を構築できる。また、プログラムはCloudflareの全世界のデータセンターに数秒で反映されるため、新しい攻撃パターンが出現した際も即座に防御コードをアップデートできるというスピード感も大きなメリットだ。

エッジでの実行によるレイテンシ削減

通常、高度なパケット検証を自前のサーバーで行おうとすると、攻撃トラフィックがサーバーにまで到達してしまい、帯域を圧迫したりCPU負荷を増大させたりする。Programmable Flow Protectionは、世界中に分散されたCloudflareのエッジ拠点で処理を行うため、攻撃トラフィックはユーザーのインフラに届く前に消滅する。

結果として、サーバー側のリソースを節約できるだけでなく、正規ユーザーの通信に対する遅延(レイテンシ)を最小限に抑えることができる。特にオンラインゲームのようにミリ秒単位の遅延が致命的となるサービスにおいて、この「エッジでの精密なフィルタリング」は非常に強力な武器となるだろう。

独自の分析:エッジコンピューティングとセキュリティの融合

独自の分析:エッジコンピューティングとセキュリティの融合

今回のProgrammable Flow Protectionの登場は、セキュリティのあり方が「プラットフォーム任せ」から「プラットフォームとの共同作業」へとシフトしていることを象徴している。これまでは、DDoS対策ベンダーがいかに多くの攻撃パターン(シグネチャ)を知っているかが重要だった。しかし、インターネット上の通信が多様化し、独自のプロトコルが増え続ける中で、ベンダー側ですべてを把握することには限界がある。

Cloudflareは、防御のための「計算資源」と「ネットワーク帯域」を提供し、その上で動かす「知能(ロジック)」をユーザーに開放した。これは、WAF(Web Application Firewall)におけるカスタムルールの作成を、より低レイヤーなL3/L4(ネットワーク・トランスポート層)で実現したものと言える。開発者がインフラの挙動をコードで制御する「Infrastructure as Code」の概念が、DDoS対策の領域でも完全に定着しつつある。

今後、この仕組みはDDoS対策だけでなく、ネットワークトラフィックのルーティングや、エッジでのデータ変換など、より幅広い用途に応用されていく可能性がある。セキュリティエンジニアには、単なる設定作業だけでなく、eBPFのような低レイヤー技術を駆使して「防御をプログラミングする」スキルがますます求められるようになるだろう。

この記事のポイント

  • CloudflareがMagic Transit向けに、eBPFでDDoS対策をカスタマイズできる新機能を発表。
  • UDPベースの独自プロトコルなど、従来の自動防御では対応が難しかった通信を精密に守れる。
  • eBPFを活用することで、パケットの中身を検証したり、ステートフルに接続を追跡したりできる。
  • 攻撃パケットをエッジで破棄するため、オリジンサーバーの負荷軽減と正規ユーザーのラグ防止に直結する。
  • 現在はEnterprise顧客向けのベータ版として提供されており、開発者による自由なロジック実装が可能。
Cloudflareが新CMS「EmDash」発表。プラグインのセキュリティ問題を隔離技術で解決

Cloudflareが新CMS「EmDash」発表。プラグインのセキュリティ問題を隔離技術で解決

Cloudflare(クラウドフレア)は、WordPressの精神的な後継を謳う新しいオープンソースCMS「EmDash(エムダッシュ)」を発表した。これは現在のWeb環境に合わせてゼロから設計されたもので、TypeScriptをベースに構築されている。

EmDashは、WordPressが長年抱えてきたプラグインに起因するセキュリティ脆弱性を、独自の隔離技術によって根本から解決することを目指している。さらに、最新のフロントエンドフレームワークであるAstro(アストロ)をエンジンに採用し、圧倒的なパフォーマンスを実現した。

現在はプレビュー版であるv0.1.0が公開されており、GitHubからコードを入手できる。Cloudflareのインフラだけでなく、Node.jsが動作する環境であればどこでもデプロイ可能だ。なぜ今、新しいCMSが必要なのか、その詳細を解説する。

プラグインのセキュリティ問題を隔離技術で解決する

プラグインのセキュリティ問題を隔離技術で解決する

WordPressのサイトで発生するセキュリティ問題の約96%は、プラグインが原因だと言われている。従来の仕組みでは、プラグインはPHPスクリプトとして動作し、サイトのデータベースやファイルシステムに直接アクセスできてしまう。これが、一つの脆弱性がサイト全体の崩壊を招く要因だった。

EmDashはこの問題を「Dynamic Workers(ダイナミック・ワーカーズ)」と呼ばれる隔離環境(サンドボックス)で解決した。各プラグインは「Isolate(アイソレート)」という独立した実行単位で動作するため、他のプログラムやシステムの中核に勝手に干渉することができない。

プラグインが何らかの操作を行うには、マニフェストファイルで必要な権限(ケイパビリティ)を明示的に宣言する必要がある。例えば、コンテンツを読み取る権限やメールを送信する権限など、許可された範囲内でのみ動作が保証される仕組みだ。これはスマートフォンのアプリがカメラや位置情報へのアクセス許可を求める挙動に近い。

import { definePlugin } from "emdash";

export default () =>
  definePlugin({
    id: "notify-on-publish",
    version: "1.0.0",
    capabilities: ["read:content", "email:send"],
    hooks: {
      "content:afterSave": async (event, ctx) => {
        if (event.collection !== "posts" || event.content.status !== "published") return;

        await ctx.email!.send({
          to: "editor@example.com",
          subject: `新着記事:${event.content.title}`,
          text: `「${event.content.title}」が公開されました。`,
         });

        ctx.log.info(`エディターに通知を送信しました:${event.content.id}`);
      },
    },
  });

上記のコード例では、コンテンツの読み取りとメール送信の権限のみを要求している。このプラグインが許可なく外部のネットワークと通信したり、データベースを直接書き換えたりすることは物理的に不可能だ。管理者はインストール時に、そのプラグインが何をしようとしているのかを正確に把握できる。

WordPressのモデル
プラグインがシステム全体にアクセス可能。一つの穴が命取りになる。
EmDashのモデル
プラグインは隔離された箱の中。許可された操作以外は一切できない。

このデモは、従来のCMSとEmDashにおけるセキュリティ構造の違いを視覚化したものだ。

Astroとサーバーレスがもたらす圧倒的なパフォーマンス

Astroとサーバーレスがもたらす圧倒的なパフォーマンス

EmDashの内部エンジンには、コンテンツ主導のWebサイト向けフレームワークとして評価の高い「Astro」が採用されている。Astroは必要な部分だけをJavaScriptで動かす「アイランドアーキテクチャ」を得意としており、ブラウザでの読み込み速度を極限まで高めることができる。

また、EmDashはサーバーレス環境での動作を前提に設計されている。具体的にはCloudflare Workers(クラウドフレア・ワーカーズ)のランタイムである「workerd」上で動作し、リクエストがあった瞬間にプログラムが起動する仕組みだ。これにより、アクセスがないときはリソースを消費せず、急激なトラフィック増にも即座に対応できる。

従来のWordPressのように、常にサーバーを起動させておく必要がないため、運用コストの大幅な削減が期待できる。Cloudflareによれば、CPUの計算時間に対してのみ課金されるモデルのため、小規模なサイトから大規模なプラットフォームまで効率的にスケールさせることが可能だという。

テーマ制作も現代的だ。開発者はAstroのコンポーネントやスタイル(Tailwind CSSなど)を使って、使い慣れたモダンな手法でサイトのデザインを構築できる。従来のWordPressテーマのように複雑なPHPの作法を覚える必要はなく、フロントエンドエンジニアにとって親和性の高い環境が整っている。

AI時代を見据えた新しい収益化モデルと開発体験

AI時代を見据えた新しい収益化モデルと開発体験

EmDashが他のCMSと一線を画すのが、AIエージェントによる管理を標準でサポートしている点だ。MCP(Model Context Protocol)サーバーを内蔵しており、AIがサイトのコンテンツ構造を理解したり、プラグインを生成したりするためのコンテキストを直接提供できる。

例えば、CLI(コマンドラインインターフェース)を通じてAIエージェントに指示を出し、メディアのアップロードやスキーマの変更、さらにはWordPressテーマの移植ガイドを生成させることも可能だ。これは「人間が管理画面をポチポチ操作する」という従来のCMSのあり方を、根本から変える可能性を秘めている。

さらに、コンテンツの収益化についても新しい提案がなされている。「x402」というインターネットネイティブな決済プロトコルを内蔵しているのだ。これはHTTP 402エラー(支払いが必要)を活用した仕組みで、AIエージェントなどがコンテンツにアクセスする際、都度少額の支払いを行う「ペイ・パー・ユース」のモデルを簡単に導入できる。

広告収益に頼る従来のWebビジネスモデルが、AIによるスクレイピングなどで脅かされている現状に対し、EmDashは技術的な解決策を提示している。管理画面でコンテンツごとの価格を設定し、ウォレットアドレスを登録するだけで、サブスクリプションに頼らない新しい収益源を構築できるのだ。

WordPressからのスムーズな移行とモダンな認証機能

WordPressからのスムーズな移行とモダンな認証機能

既存のWordPressユーザーを置き去りにしないための工夫も凝らされている。専用のインポータープラグインを使用することで、記事データやメディアライブラリを数分でEmDashへ移行できる仕組みが用意された。

カスタム投稿タイプについても、EmDashでは管理画面から直接スキーマ(データの構造)を定義できる。WordPressでACF(Advanced Custom Fields)などの外部プラグインを駆使して実現していたような複雑なデータ構造も、標準機能としてよりクリーンに管理することが可能だ。

セキュリティ面では、パスワードを廃止し「パスキー(Passkeys)」による認証をデフォルトとしている。これにより、パスワードの漏洩や総当たり攻撃のリスクを事実上ゼロにできる。もちろん、既存のSSO(シングルサインオン)プロバイダーとの連携も可能だ。

CloudflareはEmDashを単なるWordPressの代替品ではなく、これからの20年を見据えた「Webの新しいOS」のような存在として位置づけている。MITライセンスで公開されているため、特定のプラットフォームに縛られることなく、誰もが自由に拡張や開発に参加できる点も大きな魅力だ。

独自の分析:EmDashがWeb制作の現場に与える影響

独自の分析:EmDashがWeb制作の現場に与える影響

EmDashの登場は、Web制作のワークフローを劇的に変える可能性がある。特に注目すべきは、プラグインのライセンス問題からの解放だ。WordPressのプラグインは、その構造上GPLライセンスを継承せざるを得ないケースが多かったが、EmDashではプラグインが完全に独立して動作するため、作者が自由にライセンスを選択できる。

これは、高品質な商用プラグインのエコシステムがより健全に発展することを意味する。また、セキュリティが「信頼」ではなく「技術的な制約」によって担保されるため、マーケットプレイスによる中央集権的な審査を待たずとも、安全に新しい機能を導入できるようになるだろう。

一方で、これまでのPHPベースのスキルセットを持つ開発者にとっては、TypeScriptやAstroへの移行という学習コストが発生する。しかし、サーバー管理の苦労から解放され、AIを活用した高速な開発が可能になるメリットは、そのコストを補って余りあるものになるはずだ。まずはプレビュー版を自身の環境で試し、そのスピードと安全性を体感してみることをお勧めする。

この記事のポイント

  • EmDashはCloudflareが開発した、TypeScriptベースの新しいオープンソースCMSだ。
  • プラグインを独自のサンドボックスで実行することで、WordPressの脆弱性問題を根本的に解決する。
  • Astroとサーバーレス技術を採用し、高い表示速度とスケーラビリティを両立している。
  • AIエージェントによる管理や、x402プロトコルによる新しい収益化モデルを標準搭載している。
  • パスキーによる認証や、WordPressからの簡単なデータ移行機能も備えている。
Cloudflare Client-Side Securityが全ユーザーに開放。GNNとLLMを融合した最新の検知技術を解説

Cloudflare Client-Side Securityが全ユーザーに開放。GNNとLLMを融合した最新の検知技術を解説

Cloudflareは、ウェブサイトの閲覧者側で実行される悪意のあるスクリプトを検知・遮断する「Client-Side Security」の大幅なアップデートを発表した。これまでエンタープライズ向けに提供されていた高度なセキュリティ機能が、セルフサービスを利用するすべてのユーザーに開放される。1日あたり35億ものスクリプトを評価する同社のネットワークが、より広範なウェブサイトを保護する体制を整えた。

今回の更新で最も注目すべきは、AIを用いた新しい検知システムの導入だ。グラフニューラルネットワーク(GNN)と大規模言語モデル(LLM)を組み合わせることで、誤検知を劇的に減らしつつ、未知の攻撃を高い精度で特定できるようになった。従来のシグネチャベースの防御では防ぎきれない、高度に難読化された攻撃への対策が強化されている。

クライアントサイドを標的とした攻撃は、サイトの表示を崩すことなくデータを盗み出すため、運営者が気づきにくいという特徴がある。Cloudflareはこの課題に対し、最新のAI技術を統合することで、運用の手間を最小限に抑えながら強固な防御を提供することを目指している。本記事では、その技術的な仕組みと実戦での成果について詳しく解説する。

Cloudflare Client-Side Securityの進化と新展開

Cloudflare Client-Side Securityの進化と新展開

Cloudflareは、強力なセキュリティ機能を営業担当者との交渉なしに利用可能にすることを基本原則として掲げている。その一環として、これまで「Page Shieldアドオン」と呼ばれていた機能を「Client-Side Security Advanced」へと統合し、セルフサービスプランのユーザーでも即座に導入できるようにした。

全ユーザーへの門戸開放と無料化の意義

今回のアップデートにより、ドメインベースの脅威インテリジェンスがすべての顧客に無料で提供される。2025年には、Magentoなどのプラットフォームを利用する中小規模のECサイトが、クライアントサイドからの攻撃により数週間にわたって被害を受け続ける事例が多数報告された。こうしたリソースの限られたサイト運営者でも、ダッシュボード上のトグルを切り替えるだけで、既知の悪意のあるドメインとの通信を可視化できるようになった。

PCI DSS v4への対応とコンプライアンス

Client-Side Security Advancedには、コードの変更を継続的に監視する機能が含まれている。これは、クレジットカード業界のセキュリティ基準である「PCI DSS v4」の要件11.6.1を満たすために不可欠な要素だ。EC事業者はこのツールを導入することで、法規制や業界基準への準拠を容易に進めることができる。また、コンテンツセキュリティポリシー(CSP)に基づいたプロアクティブなブロックルールの運用も可能となっている。

攻撃をあぶり出す仕組み:ASTとブラウザレポーティング

攻撃をあぶり出す仕組み:ASTとブラウザレポーティング

クライアントサイドのセキュリティ管理は、膨大なデータを扱う極めて困難な課題だ。一般的なエンタープライズサイトでは、平均して2,200もの固有のスクリプトが動作している。さらに、これらのスクリプトの約3分の1は30日以内に更新される。これらを手動で承認していては、開発パイプラインが停止してしまうため、自動化された高度な分析が必要となる。

レイテンシゼロで監視するアーキテクチャ

Cloudflareのシステムは、ブラウザレポーティング(Content Security Policyなど)を利用して信号を収集する。これにより、サイトにスキャナーを導入したり、アプリケーションに特別なコードを埋め込んだりする必要がない。ユーザーのブラウザからの報告をCloudflareのプロキシ経由で受け取る仕組みのため、ウェブアプリケーションの表示速度に一切の影響を与えないのが大きな強みだ。

難読化を突破するAST解析の威力

攻撃者は検知を逃れるために、コードの変数を意味のない文字列に書き換えたり、構造を複雑にしたりする「難読化」を行う。Cloudflareはこれに対抗するため、スクリプトを「AST(Abstract Syntax Tree / 抽象構文木)」に分解して解析する。ASTとは、プログラムの構造を樹状図のような形式で表現したものだ。コードの見かけ上の書き方が変わっても、論理的な構造や挙動(インテント)を抽出できるため、悪意のある意図を正確に特定できる。

以下のデモは、難読化されたコードがどのようにAST的な構造として捉えられるかを視覚化したイメージだ。

難読化されたコード
var _0x1a2b = ["\x63\x6F\x6F\x6B\x69\x65"];
function _0x3c4d(){
send(_0x1a2b[0]);
}
AST解析による構造特定
VariableDeclaration
└─ Identifier: “cookie”
CallExpression
└─ Action: “Data Exfiltration”

このデモは難読化されたコードが解析され、データの持ち出しという構造が特定される過程を視覚化したイメージである。

GNNとLLMを組み合わせた「二段構え」の検知システム

GNNとLLMを組み合わせた「二段構え」の検知システム

Cloudflareが導入した最新の検知システムは、2つの異なるAIモデルを連携させる「カスケード型」のアーキテクチャを採用している。これにより、広大なインターネット上に存在する無限に近いバリエーションのスクリプトを、効率的かつ正確に処理することが可能になった。

構造を捉えるGNNの役割と限界

第1段階として、すべてのスクリプトはグラフニューラルネットワーク(GNN)によって評価される。GNNはASTの構造を学習し、変数の名前が変更されていても、実行パターンの特徴から悪意のある挙動を検知する。GNNは処理が高速であり、未知の脅威(ゼロデイ攻撃)を見逃さない「高い再現率」を持っている。しかし、その一方で、複雑な広告用スクリプトや難読化された正当なライブラリを誤って「攻撃」と判定してしまう「偽陽性」が課題となっていた。

Workers AIによるLLMの「セカンドオピニオン」

GNNが「疑わしい」と判定したスクリプトのみ、第2段階として大規模言語モデル(LLM)に送られる。ここで使用されるのは、Cloudflareの「Workers AI」上で動作するオープンソースのLLMだ。LLMはコードの意味的な文脈を深く理解しており、開発者がよく使う記述パターンやフレームワーク特有の動作を識別できる。LLMが「これは怪しいが見た目は無害なコードだ」と判断すれば、GNNの判定を上書きして誤検知を防ぐ。この二段構えにより、独自の評価では偽陽性を約3分の1にまで削減することに成功した。

実戦での成果:ルーターを標的にした「core.js」の検知事例

実戦での成果:ルーターを標的にした「core.js」の検知事例

この新しい検知システムは、すでに実際の攻撃を特定する成果を上げている。最近検知された「core.js」という悪意のあるスクリプトの事例は、AIによる構造・意味解析の有効性を証明するものとなった。

高度な難読化とゼロデイ攻撃の正体

「core.js」は、特定の地域でXiaomi製のOpenWrtベースのホームルーターを乗っ取ることを目的としたスクリプトだった。このスクリプトは、ルーターのWAN設定(DHCP、スタティックIP、PPPoEなど)を動的に照会し、DNS設定を書き換えてトラフィックをハイジャックしようとする。さらに、管理パスワードを密かに変更して、正当な所有者を締め出す機能まで備えていた。この攻撃はウェブサイトを直接改ざんするのではなく、侵害されたブラウザ拡張機能を通じてユーザーのセッションに注入されていた。

偽陽性を劇的に減らす精度の向上

このスクリプトは高度に圧縮・難読化されており、従来のシグネチャベースの防御システムでは検知が困難だった。しかし、CloudflareのGNNは難読化の奥にある悪意のある構造を暴き出し、Workers AI上のLLMがその意図を「ルーターのAPIを悪用する攻撃である」と確信を持って判定した。全体的なトラフィックにおける偽陽性率は約0.3%から0.1%へと低下し、固有のスクリプト単位では、偽陽性率が1.39%から0.007%へと約200倍も改善されたという。これにより、運用担当者はアラート疲れに陥ることなく、真の脅威に集中できるようになった。

独自の分析:クライアントサイドセキュリティが不可欠になる理由

独自の分析:クライアントサイドセキュリティが不可欠になる理由

今日のウェブ制作において、サードパーティ製スクリプトの利用は避けて通れない。広告、アクセス解析、チャットボット、SNS連携など、1つのサイトで数十の外部サービスが読み込まれることは珍しくない。しかし、これは「サプライチェーン攻撃」のリスクを常に抱えていることを意味する。自社のサーバーをどれだけ堅牢に守っても、読み込んでいる外部のJavaScriptが侵害されれば、ユーザーの個人情報や決済データは簡単に盗まれてしまう。

Cloudflareの今回の取り組みが画期的なのは、AIを「検知の高速化」だけでなく「運用の現実化」に活用した点だ。これまでのクライアントサイドセキュリティは、厳格に設定すれば誤検知が増えてビジネスを阻害し、緩く設定すれば攻撃を見逃すというジレンマがあった。GNNで広く網を張り、LLMで賢く精査するというアプローチは、膨大かつ変化の激しい現代のウェブエコシステムにおける現実的な解といえる。

特に、Workers AIを活用して自社ネットワーク内でLLMを完結させている点は、プライバシーとレイテンシの両面で合理的だ。セキュリティ製品が「導入するとサイトが重くなる」というこれまでの常識を覆し、パフォーマンスを維持したまま高度なAI防御を適用できるようになった意義は大きい。今後は、さらにLLMの判定基準を最適化することで、よりアグレッシブな検知設定が可能になり、未知の攻撃に対する防御力はさらに高まっていくと指摘されている。

この記事のポイント

  • Cloudflare Client-Side Security Advancedがセルフサービスプランの全ユーザーに開放された
  • ドメインベースの脅威インテリジェンスが無料化され、中小規模のサイトでも導入が容易になった
  • GNNによる構造解析とLLMによる意味解析を組み合わせた二段構えの検知システムを導入した
  • Workers AIを活用することで、サイトの表示速度に影響を与えずに高度なスクリプト解析を実現した
  • ルーターを標的とした「core.js」のような、従来のシステムでは見逃されやすいゼロデイ攻撃の検知に成功した
Cloudflare Gen13サーバーの設計思想 192コアAMD EPYCで2倍のスループットを実現

Cloudflare Gen13サーバーの設計思想 192コアAMD EPYCで2倍のスループットを実現

Cloudflareが第13世代サーバー「Gen13」の設計詳細を公開した。192コアのAMD EPYC Turin 9965プロセッサを搭載し、前世代比で最大2倍のスループットを実現している。

Gen13は768GBのDDR5-6400メモリ、24TBのPCIe 5.0 NVMeストレージ、デュアル100GbEネットワークインターフェースを備える。特に注目すべきは、Rustで書き直された新リクエスト処理層「FL2」への移行により、大容量L3キャッシュへの依存を解消した点だ。これによりコア数を2倍に増やしながら、レイテンシの増加を抑えることに成功した。

この記事では、Cloudflare Blogの記事を基に、Gen13サーバーの各コンポーネント選択の背景と設計思想を解説する。

CPU設計の転換:キャッシュからコアへ

CPU設計の転換:キャッシュからコアへ

Gen13の最大の特徴は、AMD EPYC Turin 9965プロセッサの採用だ。192コア/384スレッドを備え、前世代のGen12(96コア)からコア数を2倍に増やしている。

L3キャッシュ依存からの脱却

興味深いのは、コア数が2倍になった一方で、コアあたりのL3キャッシュ容量が83.3%減少している点だ。Gen12のAMD EPYC Genoa-X 9684Xはコアあたり12MBのL3キャッシュを持っていたが、Gen13のTurin 9965はコアあたり2MBしかない。

この一見逆行するような選択の背景には、Cloudflareのソフトウェアスタックの根本的な変化がある。Cloudflareはリクエスト処理層をFL1からFL2へ移行した。FL2はRustで書き直された新アーキテクチャで、大容量L3キャッシュへの依存度が大幅に低減されている。

Cloudflare Blogの記事によると、FL2ワークロードはコア数に対してほぼ線形にスケールする特性を持つ。このため、コア数を増やすことが直接的なスループット向上につながる。L3キャッシュ容量の減少による潜在的なパフォーマンス低下は、FL2の効率的なメモリ使用によって相殺された。

3つの候補から9965を選んだ理由

Cloudflareのエンジニアチームは、Gen13のCPU候補として3つのAMD Turinプロセッサを評価した。128コアの9755、160コアの9845、そして192コアの9965だ。

評価の結果、9965が選ばれた理由は明確だ。生産環境でのテストにおいて、9965の192コアは最高の総合リクエスト処理性能を示した。さらに、500WのTDP(熱設計電力)における性能/ワット効率も優れており、ラックレベルでの総所有コスト(TCO)が最も低くなると判断された。

運用面でも、192コアという高密度構成はメリットがある。同じ計算能力を提供するために必要なサーバー台数が減るため、プロビジョニング、パッチ適用、監視にかかる運用オーバーヘッドを削減できる。

メモリとストレージの拡張

メモリとストレージの拡張

12チャネルDDR5-6400で帯域幅33%向上

CPUコア数が2倍になったことで、メモリサブシステムにもより高い要求が課せられた。Gen13は12個のDDR5-6400メモリチャネルすべてを活用する構成を採用している。

各チャネルに64GB DIMMを1枚ずつ配置する「1DIMM per channel」構成で、合計768GBのメモリ容量を実現。ピークメモリ帯域幅はソケットあたり614GB/sに達し、Gen12から33.3%向上した。

すべてのチャネルを均等に使用する構成は、メモリインターリーブの観点から重要だ。AMD Turinプロセッサは、同じDIMMタイプ、同じ容量、同じランク構成のメモリチャネル間でインターリーブを行う。インターリーブにより、連続したメモリアクセスが単一のチャネルではなくすべてのチャネルに分散され、実効的なメモリ帯域幅が向上する。

コアあたり4GBの「適正容量」を維持

メモリ容量の決定において、Cloudflareは「コアあたり4GB」という比率を維持することを選択した。Gen12でも同じ比率が採用されており、実績のあるバランスだ。

設計初期には、コアあたり4GBから6GBの範囲が検討された。192コアの場合、768GBから1152GBに相当する。実際のDIMM容量の粒度を考慮すると、選択肢は12x48GB(576GB)、12x64GB(768GB)、12x96GB(1152GB)の3つだった。

12x48GB構成は容量が不足し、メモリを多く消費するワークロードを飢餓状態にするリスクがある。一方、12x96GB構成はコアあたり50%の容量増加となるが、電力消費の増加とコストの大幅な上昇(現在のメモリ価格は1年前の10倍)が問題だ。

12x64GBの768GB構成は、コアあたり4GBという実績のある比率を維持しつつ、サーバーあたりの総容量をGen12の2倍に拡大する。FL2はFL1と比べてメモリ使用効率が大幅に向上しており、ソフトウェアスタックの移行によって生じた余剰容量が、今後数年間のCloudflareの成長を支えるヘッドルームとなる。

ストレージ:PCIe 5.0と容量50%増

ストレージサブシステムも大幅に強化された。Gen13はPCIe Gen 5.0 NVMeドライブを採用し、レイテンシの改善と増大するストレージ帯域幅要求に対応する。

物理的なストレージ容量も、3台のNVMeドライブにより24TBに拡張された。Gen12サーバーは4つのE1.Sストレージスロットを備えていたが、実際に使用されていたのは2スロットのみだった。Gen13では同じ4スロット設計を維持しつつ、3スロットに8TBドライブを実装している。

3台目のドライブ追加により、サーバーあたりのストレージ容量は16TBから24TBへ50%増加した。これはCDNキャッシュ性能の維持・向上に加え、Durable Objects、Containers、Quicksilverサービスなどの成長予測を支えるためだ。

さらにGen13シャーシには、最大10台のU.2 PCIe Gen 5.0 NVMeドライブを収容できるフロントドライブベイが追加された。この設計により、同じシャーシをコンピュートプラットフォームとストレージプラットフォームの両方で使用できる柔軟性が生まれる。必要に応じてコンピュートSKUをストレージSKUに変換することも可能だ。

ネットワークと電源の刷新

ネットワークと電源の刷新

8年ぶりのネットワークアップグレード:25GbEから100GbEへ

Gen13で最も大きな変化の一つが、ネットワークインターフェースの刷新だ。8年以上にわたりCloudflareフリートの基盤となってきたデュアル25GbEから、デュアル100GbEへと移行する。

この変更の必要性は明白だ。192コアという高性能CPUがより多くのリクエストを処理できるようになると、ネットワーク帯域幅がボトルネックになる。実際、世界中のコロケーション施設から収集した1週間分の本番データによると、Gen12ではポートあたりのP95帯域幅が利用可能帯域幅の50%を一貫して超えていた。

Gen13ではサーバーあたりのスループットが2倍になるため、NIC帯域幅が飽和するリスクが高まる。100GbEへの移行は、このボトルネックを解消するための必然的な選択だ。

50GbEではなく100GbEを選んだ理由は、産業界の経済性にある。50GbEトランシーバーの市場規模は依然として小さく、サプライチェーン上のリスクが高い。デュアル100GbEポートによりサーバーあたり200Gb/sの集約帯域幅を実現し、今後数年間のトラフィック成長に対応できる将来性も確保した。

電源:800Wから1300Wへ拡張

コンピュート能力とネットワーク能力の向上に伴い、サーバーの電力エンベロープも自然に拡大した。Gen13は必要な電力を供給するため、より大型の電源装置を搭載する。

Gen12ノードは800W 80 PLUS Titanium CRPS(共通冗長電源装置)で十分に動作していたが、Gen13では1300W 80 PLUS Titanium CRPSを選択した。

Gen13の通常動作時の電力消費は850Wに達する。Gen12の600Wから250Wの増加だ。主な要因は、TDPが400Wから500Wに上がったCPU、メモリ容量の2倍化、追加のNVMeドライブである。

1000Wではなく1300Wを選んだ理由は、現在のPSUエコシステムに1000Wの高効率オプションがほとんどないためだ。サプライチェーンの信頼性を確保するために、産業界標準の次の階層である1300Wに移行した。

EU Lot 9規制は、欧州連合に展開するサーバーが、負荷10%、20%、50%、100%において規制で指定された効率率閾値を満たす電源装置を備えることを要求する。この閾値は80 PLUS Power Supply認証プログラムのチタニウムグレードPSU要件と一致する。Gen13ではEU Lot 9に完全準拠するためチタニウムグレードPSUを選択し、欧州のデータセンターをはじめとする全世界での展開を可能にした。

セキュリティと管理の継続性

セキュリティと管理の継続性

Project Argus DC-SCM 2.0の継承

Gen13では、Gen12で導入された管理機能とセキュリティ関連コンポーネントをマザーボードから分離するアーキテクチャを維持する。これらは「Project Argus」データセンターセキュアコントロールモジュール2.0(DC-SCM 2.0)に集約されている。

DC-SCMモジュールには、サーバーのセキュリティの中枢となる重要なコンポーネントが収められている。

  • 基本入出力システム(BIOS)
  • ベースボード管理コントローラ(BMC)
  • ハードウェアルートオブトラスト(HRoT)とTPM
  • 冗長性のためのデュアルBMC/BIOSフラッシュチップ

このアーキテクチャをGen13でも継続する決定は、前世代で実証されたセキュリティ上の利点に基づく。管理機能を専用モジュールにオフロードすることで、以下のメリットを維持できる。

迅速な回復機能は、デュアルイメージ冗長性により、偶発的な破損や悪意のある更新が検出された場合にBIOS/UEFIおよびBMCファームウェアをほぼ瞬時に復元できる。

物理的耐性については、Gen13シャーシでは侵入検知メカニズムをシャーシの平坦な端からさらに遠ざけ、物理的な傍受を難しくしている。

PCIe暗号化は、Gen10プラットフォームから有効化されていたCPUとメモリ間の暗号化(TSME)に加え、AMD Turin 9965プロセッサがPCIeトラフィックにも暗号化を拡張する。これにより、システム内のすべてのバスを通過するデータが転送中も保護される。

運用的一貫性も重要だ。Gen12管理スタックを維持することで、セキュリティ監査、展開、プロビジョニング、運用標準手順が完全に互換性を保つ。

ドロップインアクセラレータサポートの強化

フリートのモジュール性維持は、Cloudflareのサーバー設計における中核的な要件だ。この要件により、Cloudflareは2024年にGPUを世界中の100以上の都市に迅速に改造・展開できた。

Gen13では、高性能PCIeアドインカードのサポートを継続する。Gen13の2Uシャーシレイアウトは更新され、より要求の厳しい電力と熱要件をサポートするように構成されている。Gen12がシングル幅GPU1枚に制限されていたのに対し、Gen13アーキテクチャはダブル幅PCIeカード2枚をサポートする。

この記事のポイント

  • Cloudflare Gen13サーバーは192コアAMD EPYC Turin 9965を採用し、前世代比最大2倍のスループットを実現
  • FL2(Rust製新リクエスト処理層)への移行により、大容量L3キャッシュへの依存を解消。コア数増加による性能向上を可能にした
  • メモリは12チャネルDDR5-6400構成で768GBを実装。帯域幅33%向上とコアあたり4GBの適正容量を維持
  • ネットワークは8年ぶりに刷新。デュアル25GbEからデュアル100GbEへ移行し、帯域幅ボトルネックを解消
  • セキュリティはProject Argus DC-SCM 2.0アーキテクチャを継承。PCIe暗号化を追加し、データ転送中の保護を強化