AIアプリに専用DBを即時提供！CloudflareのDurable Objects Facetsを解説
Cloudflareは、AIが生成したアプリケーションごとに専用のデータベースを割り当てることができる新機能「Durable Objects Facets（デュラブル・オブジェクト・ファセット）」をベータ公開した。この機能は、同社が提供する「Dynamic Workers」の仕組みを拡張したもので、動的に生成されたコードに対して、永続的なストレージを安全かつ高速に提供することを目的としている。
従来のサーバーレス環境では、実行時にコードをロードして実行する「動的なサンドボックス」において、データの永続化を管理することが技術的な障壁となっていた。しかし、Durable Objects Facetsの登場により、AIエージェントが作成した小さなツールや個人用アプリが、それぞれ独自のSQLiteデータベースを持ち、状態を保持し続けることが可能になる。
なぜこのアップデートがAI開発の現場において重要なのか、その背景にある「アイソレート」の技術や、新しいストレージの概念について詳しく紐解いていこう。AIが単にコードを書くだけでなく、自律的にデータを管理する「記憶を持つエージェント」へと進化する大きな一歩だと言える。
Dynamic Workersとアイソレートが支える高速な実行環境
Durable Objects Facetsを理解するためには、まずその基盤となる「Dynamic Workers（ダイナミック・ワーカーズ）」について知る必要がある。Dynamic Workersとは、実行時にWorkerのコードをオンデマンドでロードし、安全なサンドボックス内で実行できる機能だ。
コンテナではなくアイソレートが実現する100倍の起動速度
Cloudflare Workersの最大の特徴は、一般的なクラウドサービスが採用している「コンテナ」技術ではなく、「アイソレート（Isolate）」という仕組みを利用している点にある。アイソレートとは、Google Chromeなどのブラウザを支えるV8エンジンが提供する、非常に軽量な実行環境の単位だ。
アイソレートはコンテナと比較して、起動速度が最大100倍速く、メモリ使用量は10分の1程度で済むという。この圧倒的な軽さにより、コードを実行するたびに環境を立ち上げ、終わったら即座に破棄するという「使い捨てのコンピューティング」が可能になった。Dynamic Workersは、このアイソレートの特性を最大限に活かし、AIが生成した数行のコードを即座に実行するセキュアな「eval()」のような役割を果たす。
このデモは、コンテナとアイソレートの構造的な違いを視覚化したものだ。アイソレートの軽量さが、AIによる動的なコード実行を支えている。
AIエージェントによるコード実行の課題
AIエージェントがユーザーの依頼に応じてコードを書き、それを実行する場合、これまでは「一度きりのタスク」として処理されることが多かった。例えば、データの集計や特定のAPI呼び出しなどは、実行後に結果を返せばコード自体を保持し続ける必要はない。
しかし、ユーザーが「自分専用の家計簿アプリを作って」と依頼した場合、AIはUI（ユーザーインターフェース）だけでなく、入力されたデータを保存し続ける「ストレージ」も提供しなければならない。動的に生成されたコードが、どのようにして安全に、かつ自分専用のデータベースにアクセスするかが大きな課題となっていた。
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（ファセット）だ。「Facet」とは「切り口」や「側面」を意味する言葉で、一つのDurable Objectの中に、複数の独立した実行環境とデータベースを持たせる概念を指す。
監視役（Supervisor）と実行役（Facet）の分離
この機能の核となるのは、開発者が書いた「監視役（Supervisor）」のコードの中で、AIが書いた「実行役（Facet）」のコードを動的にロードする仕組みだ。監視役は通常のDurable Objectとして動作し、リクエストを受け取ると、必要に応じてAIのコードをFacetとして呼び出す。
FacetとしてロードされたAIのコードは、自分専用のSQLiteデータベースを与えられる。このデータベースは監視役のデータベースとは論理的に分離されており、AIのコードが監視役の重要なデータ（課金情報や管理ログなど）を読み書きすることはできない。一方で、物理的には同じDurable Objectの一部として管理されるため、パフォーマンスの高さは維持される。
・ログ記録、レート制限
・管理用データベースを保持
・アプリ専用のSQLite DB
・親のDBにはアクセス不可
この図のように、一つのDurable Objectの中に「管理領域」と「AIの自由領域」を共存させるのがFacetの狙いだ。これにより、安全性を確保しながら動的なデータ永続化が可能になる。
親子関係で実現するセキュリティと制御
開発者は、AIが作成できるFacetの数を制限したり、各Facetが使用するストレージ容量を監視したりすることができる。これにより、AIが勝手に大量のデータを保存してコストを増大させるリスクを防げる。また、監視役のコードを通じてネットワークアクセスを制限（globalOutbound: null）することで、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エージェント開発への影響と展望
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プランのユーザー向けにオープンベータとして提供されている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Organizationsベータ版登場！複数アカウントの一元管理とセキュリティ強化の全容
Cloudflare（クラウドフレア）は、大規模なエンタープライズ企業が自社のインフラをより効率的に管理するための新機能「Cloudflare Organizations（クラウドフレア・オーガニゼーションズ）」をベータ版として公開した。この機能は、これまで独立していた複数のCloudflareアカウントを一つの「組織」としてまとめ、一元的な管理を可能にするものだ。
大規模な組織では、数千人規模のユーザーが開発やセキュリティ、ネットワークなどの多岐にわたる業務でCloudflareを利用している。今回のアップデートにより、管理者は個別のログインや設定の繰り返しから解放され、組織全体のアナリティクスやポリシーを一括で制御できるようになる。
なぜこの機能が重要なのか。それは、セキュリティの鉄則である「最小権限の原則」を維持しながら、管理の複雑さを劇的に解消できるからだ。本記事では、Cloudflare Organizationsがもたらす変化とその技術的な背景を詳しく解説していく。
Cloudflare Organizationsが解決する大規模運用の課題
多くのエンタープライズ企業は、セキュリティを担保するために複数のCloudflareアカウントを使い分けている。これは、特定のチームに必要以上の権限を与えないための「最小権限の原則（Principle of Least Privilege）」に基づいた運用だ。
複数アカウントによる管理の断片化
最小権限の原則とは、ユーザーに業務遂行に必要な最小限のアクセス権だけを与える考え方だ。例えば、マーケティングチームが管理する特設サイトの設定と、基幹システムのネットワーク設定は、異なるアカウントで管理するのが望ましい。これにより、万が一ひとつのアカウントが侵害されても、被害を限定的に抑えられるからだ。
しかし、この運用には大きなデメリットがあった。管理者はすべてのアカウントに個別にアクセスし、権限を設定しなければならない。アカウントが増えるほど管理は「断片化」し、誰がどのアカウントに対してどのような権限を持っているのかを把握することが困難になっていたのだ。
運用の煩雑さとヒューマンエラーのリスク
従来、全社的なセキュリティレポートを作成する場合、管理者は各アカウントにログインして個別にデータを収集する必要があった。また、共通のセキュリティポリシーを適用する際も、アカウントごとに同じ設定を手動で繰り返す必要があり、これが設定ミスや漏れといったヒューマンエラーの原因となっていた。
Cloudflare Organizationsは、こうした「セキュリティのためのアカウント分割」が生み出した管理コストを削減するために設計されている。アカウントの独立性を保ったまま、管理レイヤーだけを統合する仕組みだ。
■ アカウントB（本番用）→ 個別にログイン
■ アカウントC（外部用）→ 個別にログイン
※管理者がバラバラに管理する必要がある
├ ■ アカウントB
└ ■ アカウントC
このデモは、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では、特定のアカウントで作成したポリシーセットを、組織内の他のアカウントへ共有できる。
例えば、セキュリティ専門チームが管理する「マスターアカウント」で最新の脆弱性対策ルールを作成し、それを全社のアカウントに一括で適用するといった運用が可能になる。これにより、セキュリティレベルのばらつきをなくし、全社的な防御力を底上げできる。
この仕組みにより、各チームの担当者は自前で複雑なセキュリティ設定を行う必要がなくなり、本来の開発業務に集中できるようになる。
開発の舞台裏とパフォーマンスの改善
このOrganizations機能の実現は、Cloudflareの内部システムにおける大規模な刷新の結果でもある。Cloudflareのチームは、これを単なる新機能の追加ではなく、システム基盤の再構築として取り組んだ。
13万行のコード刷新とインナーソース開発
開発にあたっては「インナーソース（Innersource）」という手法が採用された。これは、オープンソースの開発手法を社内のプロジェクトに適用するものだ。このプロジェクトでは、約133,000行の新しいコードが追加され、32,000行の古いコードが削除された。Cloudflareの権限システム史上、最大級の変更となったという。
この刷新の目的は、古いコードパスを排除し、すべての認可チェックを「ドメインスコープのロールシステム」に集約することだ。これにより、将来的に新しいロールや機能をより迅速にリリースできる強固な土台が完成した。
権限チェック速度が27%向上
この基盤刷新は、ユーザー体験にも直接的なメリットをもたらしている。特に、数千ものアカウントやゾーン（ドメイン）にアクセス権を持つパワーユーザーにおいて、アカウント一覧やゾーン一覧の表示速度が課題となっていた。今回の最適化により、権限チェックのパフォーマンスが27%向上し、大規模環境での管理画面のレスポンスが大幅に改善された。
Organizationsの導入方法と今後の展望
Cloudflare Organizationsは、まずエンタープライズプランの顧客を対象にパブリックベータとして公開されている。今後数ヶ月以内に、Pay-as-you-go（従量課金）プランを含むすべての顧客に拡大される予定だ。
安全な移行プロセス
導入はセルフサービス形式で行われる。エンタープライズアカウントのスーパー管理者であれば、ダッシュボードに招待が表示される仕組みだ。Cloudflare側が勝手に組織を作成することはない。これは、意図しない権限昇格を防ぐための配慮だ。
もし社内の別のユーザーがすでに組織を作成している場合は、そのユーザーから招待を受けるか、自分を組織の管理者として追加してもらう必要がある。このプロセスにより、どのアカウントを組織に含めるかを、各アカウントの管理者が明示的に承認する形が維持されている。
ロードマップに並ぶ強力な機能
Organizationsは、今後一年をかけてさらに進化する予定だ。現在公開されているロードマップには以下の項目が含まれている。
- 組織レベルの監査ログ（Audit Logs）
- 組織レベルの請求レポート
- より詳細なアナリティクスレポートの拡充
- 組織レイヤーでの追加ユーザーロール
- セルフサービスによる新規アカウント作成
独自の分析：なぜ今、Cloudflareは「組織」単位の管理に注力するのか
今回のアップデートは、Cloudflareが単なる「CDNベンダー」から、企業の「統合ネットワークインフラ」へと完全に脱皮したことを象徴している。かつてCloudflareは、個々のドメインを高速化・保護するためのツールだった。しかし現在、企業はアイデンティティ管理（Zero Trust）やサーバーレス開発（Workers）など、ビジネスの根幹をCloudflare上で動かしている。
利用範囲が広がれば、当然ながら管理する単位はドメインから「組織」へとシフトする。Organizationsの導入は、AWS（Amazon Web Services）が「AWS Organizations」を導入した際と同様の進化のプロセスと言えるだろう。
特に、WAFポリシーの共有機能は、セキュリティの民主化を加速させる可能性がある。高度なスキルを持つ中央のセキュリティチームが作成した「盾」を、全社の開発チームが意識することなく利用できる。この「ガードレール」としての役割こそが、現代のプラットフォームエンジニアリングが目指す姿だ。Cloudflareは今回の基盤刷新により、その理想を実現するための強力な武器を手に入れたと言える。
この記事のポイント
- Cloudflare Organizationsにより、複数のアカウントを一元管理できるようになった
- 「組織スーパー管理者」ロールにより、個別のアカウント管理が不要になる
- WAFやGatewayのポリシーを組織全体で共有・一括適用が可能に
- 内部システムの刷新により、権限チェックの速度が27%向上した
- 現在はエンタープライズ向けベータ版で、順次全ユーザーに開放予定
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
500 Tbpsに達したCloudflareのネットワーク網！DDoS防御とAI時代のインフラを徹底解説
Cloudflareのグローバルネットワークが、外部接続容量500 Tbps（テラビット毎秒）という大きな節目を超えた。2010年にパロアルトの小さなオフィスから始まった同社のインフラは、16年の歳月を経て世界330以上の都市に広がる巨大なデジタル基盤へと成長している。
この「500 Tbps」という数字は、単なるピーク時のトラフィック量ではない。トランジットプロバイダーやピアリングパートナー、インターネットエクスチェンジ（IX）などと接続された外部ポートの総容量を指している。この膨大な余剰キャパシティこそが、日々発生する大規模なDDoS攻撃を吸収するための「防御予算」として機能しているのだ。
現代のインターネットにおいて、これほどの規模を持つネットワークがどのように構築され、どのように自律的な防御を実現しているのか。最新の技術スタックと、急増するAIトラフィックへの対応策を含めて詳しく紐解いていく。
500 Tbpsの衝撃〜Cloudflareが到達した巨大ネットワークの現在地
Cloudflareのネットワーク容量が500 Tbpsに達したことは、インターネットの歴史における一つの到達点といえる。2010年の設立当初、同社はたった一つのトランジットプロバイダーと契約し、ネームサーバーを2つ書き換えるだけで利用できるリバースプロキシとしてスタートした。それが今や、全ウェブサイトの20％以上を保護する巨大インフラへと変貌を遂げている。
世界330都市以上に広がる物理インフラの重み
「インターネットはクラウドである」と表現されることが多いが、その実体はケーブルとサーバーが詰まった物理的な部屋の集合体だ。Cloudflareはシカゴ、アッシュバーン、サンノゼ、アムステルダム、東京といった主要都市から始まり、カトマンズ、バグダッド、レイキャビクといった地域まで網羅してきた。
データセンターを一つ開設するごとに、コロケーション契約の交渉、光ファイバーの敷設、サーバーのラッキングといった地道な作業が繰り返される。2018年には、わずか24日間で31都市に拠点を展開するという驚異的なスピードで拡張を続けた。この物理的な拠点の多さが、ユーザーに近い場所でコンテンツを配信し、攻撃を水際で食い止めるための鍵となっている。
外部キャパシティ500 Tbpsが意味するもの
500 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サイクルをほとんど消費することなく、入口で即座に破棄される。アプリケーション層に到達する前に処理が終わるため、サーバーの負荷を極限まで抑えることが可能だ。この仕組みを視覚化すると、以下のようになる。
このデモは、パケットがどのように段階を経て処理されるかを示したものだ。XDPレイヤーでのフィルタリングが、後続のシステムをいかに保護しているかがわかる。
自律分散型の防御システム「dosd」
Cloudflareのすべてのサーバーには「dosd」と呼ばれるDDoS対策用のデーモンが常駐している。各サーバーは流入するトラフィックをサンプリングし、異常な通信パターンを検出すると、その情報を同じデータセンター内の全サーバーにブロードキャストする。
データセンター内のすべてのサーバーが同じデータに基づいて判断を下すため、特定のサーバーに負荷が集中することなく、拠点全体で一貫した防御が可能になる。さらに、決定されたルールは同社の分散型キーバリューストア「Quicksilver」を通じて数秒以内に全世界の拠点へ伝播される。これにより、ある拠点で検知された攻撃手法が、瞬時に地球の裏側の拠点でも通用しなくなる仕組みだ。
ネットワーク自体が開発プラットフォームへ〜Edge Computingの進化
ネットワークを保護するためにすべてのサーバーでコードを実行できる環境を整えた結果、そのリソースを顧客に開放するという自然な流れが生まれた。これが「Cloudflare Workers」の始まりだ。現在では、単なるスクリプトの実行にとどまらず、より複雑なワークロードをエッジで動かすことが可能になっている。
WorkersからContainersへ
2025年、CloudflareはWorkersに「Containers」機能を追加した。これにより、V8アイソレートでは難しかった、より重量級のアプリケーションもエッジで動作させることができるようになった。独自のファイルシステムレイヤーにより、コールドスタート（起動時の遅延）を最小限に抑えつつ、ユーザーのすぐそばで計算リソースを提供する。
開発者が書いたコードは、前述のDDoS防御と同じサーバー上で動作する。つまり、攻撃トラフィックがl4dropによって破棄された直後の、クリーンな環境でアプリケーションが実行されるわけだ。インフラのセキュリティとパフォーマンスを同時に享受できるこの構造は、従来の中央集約型クラウドとは一線を画している。
インターネットの信頼性を担保する〜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は「どのような経路を通ってきたか」を検証するフライトマニフェスト（搭乗名簿）チェックに相当する。
ASPAが普及すれば、設定ミスによるルート漏洩や、悪意のある経路誘導をより確実に防げるようになる。Cloudflareのような巨大ネットワークが先行して導入することで、インターネット全体のエコシステムを健全な方向へ導く狙いがある。
AIエージェントが変えるトラフィック構造〜4％の衝撃
近年、インターネット上のトラフィックに大きな変化が起きている。人間がブラウザでリンクをクリックして発生する通信に加え、AIクローラーや自律型エージェントによるアクセスが急増しているのだ。現在、Cloudflareのネットワークを流れるHTMLリクエストの4％以上が、AI関連の通信で占められている。
ブラウザとクローラーの挙動の違い
AIクローラーは、人間が操作するブラウザとは根本的に異なる動きを見せる。ブラウザはページを読み込んだ後に一時停止するが、クローラーはリンクされたリソースを最大スループットで、休むことなく次々と取得していく。この挙動は、インフラ側から見るとDDoS攻撃と区別がつきにくい場合がある。
Cloudflareは、正規のAIクローラーと悪意のある攻撃を識別するために、TLSフィンガープリントや行動分析を組み合わせた高度な検知システムを運用している。例えば、ブラウザを装いつつもTLSのライブラリが不自然な構成であれば、それをシグナルとして検出し、サイト所有者が適切な判断を下せるようにデータを提供している。
独自の分析〜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クローラーに対し、高度な識別技術で対応している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflareが2029年までの完全量子耐性化を宣言、認証保護の重要性が加速
Cloudflareは、インターネットの安全性を根底から覆す可能性のある「量子コンピュータによる暗号解読」への対策を大幅に加速させている。同社は2029年までに、認証を含むすべてのサービスにおいて完全な量子耐性（Post-Quantum / PQ）を確保する計画を公表した。これは、従来の予測よりも数年早い目標設定となっている。
この背景には、GoogleやOratomicといった研究機関が発表した、量子アルゴリズムとハードウェアの劇的な進歩がある。最新の研究によれば、現在広く使われている楕円曲線暗号（ECC）を解読するために必要な量子ビット数が、当初の想定よりも遥かに少なくて済む可能性が示唆されている。もはやQ-Day（量子コンピュータが現代の暗号を破る日）は、遠い未来の出来事ではなくなったのだ。
本記事では、なぜCloudflareがロードマップを前倒ししたのか、そして量子耐性における「認証」の重要性がなぜ高まっているのかについて、技術的な観点から詳しく解説する。Webサイト運営者やエンジニアにとって、この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つの技術的要因
なぜ、これほどまでに量子コンピュータの実用化が早まっているのだろうか。Cloudflareの分析によれば、量子コンピューティングの進化は「ハードウェア」「エラー訂正」「ソフトウェア」という独立した3つの分野が相互に影響し合うことで、複利的に加速しているという。
中性原子方式などのハードウェアの多様化
量子コンピュータの実現には、超電導方式やイオンラップ方式など、複数のアプローチが競い合っている。近年、特に注目を集めているのが「中性原子（Neutral Atom）」方式だ。この方式はスケーラビリティに優れており、Googleも超電導方式と並行してこの技術を追求し始めている。
中性原子方式は、光格子の中に原子を閉じ込めて制御する技術で、原子同士の結合を柔軟に変更できる特徴がある。この「再構成可能性」が、後述するエラー訂正の効率化に大きく寄与している。すべての方式が成功する必要はなく、どれか一つが壁を突破すれば、暗号解読は現実のものとなる。
エラー訂正技術の劇的な効率化
量子ビットは非常にノイズに弱く、実用的な計算を行うには「エラー訂正」が不可欠だ。従来、1つの論理量子ビット（エラーのない計算ができる単位）を作るには、約1,000個の物理量子ビットが必要だとされてきた。しかし、中性原子方式のような高い結合性を持つアーキテクチャでは、この比率が劇的に改善されることが判明した。
Oratomicの研究によれば、中性原子方式ではわずか3～4個の物理量子ビットで1つの論理量子ビットを構成できる可能性があるという。この効率化により、ハードウェアに求められる物理的な規模が100分の1以下に縮小された。これが、Q-Dayの予測が大幅に前倒しされた最大の技術的要因だ。
このデモは、エラー訂正に必要とされる物理量子ビット数の劇的な減少を視覚化したものだ。※このデモは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は、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対応を含め、証明書管理の自動化を進めるべきだ。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
BPFバックドアのマジックパケットをZ3で自動生成する手法
Linuxマルウェア解析の現場で、手作業による逆アセンブリがボトルネックになっている。特に、Berkeley Packet Filter（BPF）ソケットプログラムに隠された「マジックパケット」待ち受け型のバックドアは、フィルタが数百命令に及ぶこともあり、解析に膨大な時間を要する。
Cloudflareのセキュリティ研究者らはこの課題に対し、シンボリック実行とZ3定理証明器を組み合わせた自動化手法を開発した。これにより、従来は数時間から数日かかっていたマジックパケットの特定を、数秒で完了させられるようになった。本記事では、その技術的アプローチと実装の詳細を解説する。
BPFがマルウェアに利用される理由
Berkeley Packet Filter（BPF）は、ネットワークスタックから特定のパケットを効率的に取り出すためのカーネル内技術だ。tcpdumpなどのツールでおなじみの「クラシックBPF」は、2つのレジスタしか持たないシンプルな仮想マシンで、高速なパケットフィルタリングを実現する。
ユーザー空間から見えなくなる特性
このBPFがマルウェア作者に好まれる理由は、その「不可視性」にある。カーネル深くで動作するBPFプログラムは、特定の条件を満たすパケットだけをユーザー空間のプロセスに渡すことができる。逆に言えば、条件を満たさないパケットは、ユーザー空間のネットワーク監視ツールから完全に隠蔽できる。
これにより、攻撃者は「マジックパケット」と呼ばれる特定のバイト列を含むパケットが到着するまで、バックドアを完全に休眠状態に保てる。通常のポートスキャンでは検出されず、ネットワーク上に痕跡を残さない、極めて隠密性の高い持続的脅威（APT）が実現する。
手動解析の限界
マルウェア対策の研究者がこの種のバックドアを分析する場合、BPFのバイトコードを逆アセンブルし、条件分岐を一つずつ追跡する必要があった。20命令程度の単純なフィルタなら問題ないが、実際には100命令を超える複雑なロジックを持つサンプルが観測されている。
Cloudflare Blogの記事によると、複雑なBPFプログラムの手動解析には「少なくとも1日」を要する場合があったという。この時間的コストが、脅威の早期分析と対策の迅速な展開を妨げるボトルネックとなっていた。
BPFDoorの実例から見るBPFフィルタ
この手法の具体例として、高度なLinuxバックドア「BPFDoor」のBPFフィルタを見てみる。Fortinetが分析したサンプル（ハッシュ値: 82ed617816453eba2d755642e3efebfcbd19705ac626f6bc8ed238f4fc111bb0）の逆アセンブル結果は次の通りだ。
(000) ldh [0xc] ; オフセット12から2バイト読み込み（EtherType）
(001) jeq #0x86dd, jt 2, jf 6 ; 0x86DD（IPv6）なら002へ、そうでなければ006へ
(002) ldb [0x14] ; オフセット20から1バイト読み込み（プロトコル）
(003) jeq #0x11, jt 4, jf 15 ; 0x11（UDP）なら004へ、そうでなければ015（DROP）へ
(004) ldh [0x38] ; オフセット56から2バイト読み込み（宛先ポート）
(005) jeq #0x35, jt 14, jf 15 ; 0x35（DNSポート53）なら014（ACCEPT）へ、そうでなければ015へ
(006) jeq #0x800, jt 7, jf 15 ; 0x800（IPv4）なら007へ、そうでなければ015へ
(007) ldb [23] ; オフセット23から1バイト読み込み（プロトコル）
(008) jeq #0x11, jt 9, jf 15 ; 0x11（UDP）なら009へ、そうでなければ015へ
(009) ldh [20] ; オフセット20から2バイト読み込み（フラグメント）
(010) jset #0x1fff, jt 15, jf 11 ; フラグメントされていれば015へ、そうでなければ011へ
(011) ldxb 4*([14]&0xf) ; インデックスレジスタXに（IHL & 0xF）*4をロード
(012) ldh [x + 16] ; オフセットX+16から2バイト読み込み（宛先ポート）
(013) jeq #0x35, jt 14, jf 15 ; 0x35（DNSポート53）なら014へ、そうでなければ015へ
(014) ret #0x40000 (ACCEPT) ; パケット受理
(015) ret #0 (DROP) ; パケット破棄このフィルタは、IPv6パケットとIPv4パケットの両方の経路でDNSポート（53）へのUDPパケットを待ち受ける。IPv4の経路ではさらに、パケットがフラグメントされていないこと、IPヘッダ長が標準の20バイトであることなどの追加チェックが入る。
ACCEPTに至る2つの経路
上記のコードから、パケットがACCEPT（受理）される条件は2つの経路で満たされることがわかる。
- 経路1（IPv6）: EtherTypeが0x86DD（IPv6）→ プロトコルが0x11（UDP）→ 宛先ポートが0x35（53）
- 経路2（IPv4）: EtherTypeが0x0800（IPv4）→ プロトコルが0x11（UDP）→ フラグメントなし → IPヘッダ長が5（20バイト）→ 宛先ポートが0x35（53）
手動で分析すれば、これらの条件から「DNSポート53へのUDPパケット」がマジックパケットの候補だと推測できる。しかし、より複雑な算術演算やビット演算が絡むフィルタの場合、この推測は困難を極める。
シンボリック実行とZ3による自動化
Cloudflareの研究者らは、この「制約条件を満たす入力値の発見」という問題を、シンボリック実行と定理証明器Z3によって自動化するアプローチを取った。
シンボリック実行の基本概念
シンボリック実行とは、プログラムの入力を具体的な値ではなく「記号（シンボル）」として扱い、実行経路を数学的な制約の集合として表現する手法だ。BPFプログラムの場合、入力となるネットワークパケットの各バイトを未知の変数とみなす。
プログラムが条件分岐（jeqなど）に到達すると、「変数Aが値Bと等しい」という制約が真となる経路と、偽となる経路の両方を探索する。最終的にACCEPT命令に到達する経路において、変数が満たすべきすべての制約を収集する。
Z3定理証明器による制約解決
収集された制約を、Microsoft Researchが開発した定理証明器「Z3」に与える。Z3はこれらの制約を満たす具体的な変数値（つまり、パケットの各バイトの値）を自動的に計算する。
このプロセスは、複数の連立方程式を解くことに似ている。ただし、方程式が単純な等号ではなく、ビット演算、比較、条件分岐を含む複雑な論理式となる点が異なる。
最短経路の探索アルゴリズム
すべてのACCEPT経路を探索する前に、まず最短の経路を見つける。これは、後続のシンボリック実行の計算コストを抑えるためだ。擬似コードで示すと、次のような幅優先探索（BFS）が用いられる。
paths = []
queue = deque([(0, [0])]) # (プログラムカウンタ, 経路履歴)
while queue:
pc, path = queue.popleft()
if pc >= len(instructions):
continue
instruction = instructions[pc]
if instruction.class == return_instruction:
if instruction_constant != 0: # ACCEPTの場合
paths.append(path)
continue # DROPまたはACCEPTでこの経路の探索終了
if instruction.class == jump_instruction:
if instruction.operation == unconditional_jump:
next_pc = pc + 1 + instruction_constant
queue.append((next_pc, path + [next_pc]))
continue
# 条件付きジャンプの場合、真偽両方の経路を探索
pc_true = pc + 1 + instruction.jump_true
pc_false = pc + 1 + instruction.jump_false
queue.append((pc_true, path + [pc_true]))
queue.append((pc_false, path + [pc_false]))
else:
# 逐次実行命令の場合、次の命令へ
queue.append((pc + 1, path + [pc + 1]))このアルゴリズムを先ほどのBPFDoorフィルタに適用すると、より短いIPv6経路（命令000→001→002→003→004→005→014）が最短経路として特定される。
BPFシンボリック実行マシンの実装
最短経路がわかれば、次はその経路上でシンボリック実行を行うマシンを実装する。Cloudflareが開発した「BPFPacketCrafter」クラスの骨格は以下のようになる。
class BPFPacketCrafter:
MIN_PKT_SIZE = 64 # 最小パケットサイズ
LINK_ETHERNET = "ethernet" # イーサネットヘッダから始まる
MEM_SLOTS = 16 # スクラッチメモリM[0]〜M[15]
def __init__(self, instructions, pkt_size=128, ltype="ethernet"):
self.instructions = instructions
self.pkt_size = max(self.MIN_PKT_SIZE, pkt_size)
self.ltype = ltype
# シンボリックなパケットバイト（各バイトが独立した変数）
self.packet = [BitVec(f"pkt_{i}", 8) for i in range(self.pkt_size)]
# シンボリックなレジスタ（32ビット）
self.A = BitVecVal(0, 32) # アキュムレータ
self.X = BitVecVal(0, 32) # インデックスレジスタ
# スクラッチメモリ
self.M = [BitVecVal(0, 32) for _ in range(self.MEM_SLOTS)]ここでBitVecはZ3が提供するビットベクトル（固定長のビット列）型で、パケットの各バイトを8ビットの未知変数として表現する。レジスタAとXも同様に32ビットのビットベクトルとしてモデル化される。
BPF命令のZ3操作へのマッピング
シンボリック実行マシンは、BPFの各命令を対応するZ3の操作に変換しながら実行する。例えば、加算命令（ADD）は次のように処理される。
def _execute_ins(self, insn):
cls = insn.cls
if cls == BPFClass.ALU: # 算術論理演算命令
op = insn.op
src_val = BitVecVal(insn.k, 32) if insn.src == BPFSrc.K else self.X
if op == BPFOp.ADD:
self.A = self.A + src_val # Z3の加算演算でレジスタAを更新比較命令（jeq）の場合は、条件式を制約として記録し、分岐先のプログラムカウンタへ実行を進める。クラシックBPFの命令セットは小さいため、このマッピングは比較的容易に実装できる。
制約の収集とパケット生成
最短経路に沿ってシンボリック実行を進めると、ACCEPT命令に到達した時点で、パケット変数が満たすべき制約の集合が完成する。Z3ソルバーはこの制約集合を解き、各pkt_i変数に具体的なバイト値を割り当てる。
得られた制約の例を、Z3が内部で生成する式の形で示すと以下のようになる。
0x86DD == ZeroExt(16, Concat(pkt_12, pkt_13))
0x11 == ZeroExt(24, pkt_20)
0x35 == ZeroExt(16, Concat(pkt_56, pkt_57))これは、「オフセット12-13の2バイト（ビッグエンディアン）が0x86DD（IPv6）と等しい」「オフセット20の1バイトが0x11（UDP）と等しい」「オフセット56-57の2バイトが0x35（ポート53）と等しい」という3つの制約を表す。
Z3がこれらの制約を満たす解（例えばpkt_12=0x86, pkt_13=0xDD, pkt_20=0x11, ...）を求めると、それを実際のバイト列に変換する。最後に、Pythonのパケット操作ライブラリscapyを使って、このバイト列からネットワークパケットオブジェクトを組み立てる。
###[ Ethernet ]###
dst = 00:00:00:00:00:00
src = 00:00:00:00:00:00
type = IPv6
###[ IPv6 ]###
version = 6
nh = UDP
src = ::
dst = ::
###[ UDP ]###
sport = 0
dport = domain # ポート53生成されたパケットは、分析者がネットワーク上でバックドアの活性化テストを行う際の入力として、または検出用のシグネチャ作成のベースとして利用できる。
ツール「filterforge」と今後の展望
Cloudflareはこの研究成果をオープンソースツール「filterforge」として公開している。このツールを使えば、BPFバイトコードを含むファイルを入力とするだけで、マジックパケットの条件を満たすパケットのスケルトンを自動生成できる。
ツールの公開により、セキュリティコミュニティ全体でBPFベースの脅威に対する分析速度が向上することが期待される。特に、以下のような応用が考えられる。
- マルウェアサンプルの自動分類: 生成されたマジックパケットの特徴から、同一グループによる活動を関連付けられる。
- ネットワーク監視の強化: 生成されたパケットをプローブとして送信し、感染ホストの検出に利用する。
- 教育・研究: 複雑なBPFフィルタの動作を、具体的なパケット例とともに理解する教材となる。
LLMとの組み合わせ可能性
Cloudflare Blogの記事では、LLM（大規模言語モデル）を用いてBPF命令の文脈的説明を生成する取り組みにも言及している。シンボリック実行による自動パケット生成とLLMによる自然言語説明を組み合わせれば、分析者の作業負荷はさらに軽減される。
ただし現状では、LLMだけに複雑なBPFフィルタの解析とパケット生成を任せるには限界がある。Z3を用いた形式的な手法は、その正確性と完全性において依然として重要な役割を果たす。
この記事のポイント
- Linuxマルウェアは、カーネル内で動作するBPFソケットプログラムを利用し、特定の「マジックパケット」が到着するまで休眠する隠密性の高いバックドアを構築する。
- 手動でのBPFバイトコード逆解析は、数百命令に及ぶ複雑なフィルタの場合、数日を要するボトルネックだった。
- シンボリック実行によりBPFプログラムの入力を記号化し、定理証明器Z3で制約を解くことで、マジックパケットを数秒で自動生成できる。
- この手法は、最短経路探索、BPF仮想マシンのシンボリックモデル化、Z3制約ソルバー、scapyによるパケット組み立ての4ステップから構成される。
- Cloudflareが公開したオープンソースツール「filterforge」は、BPFベース脅威の分析速度をコミュニティ全体で向上させる可能性を秘めている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordCamp Asia 2026開催、Kinstaが初のインド進出でコミュニティと交流
WordPressコミュニティのアジア最大級イベント「WordCamp Asia 2026」が、2026年4月9日から11日までインド・ムンバイで開催される。会場はJio World Convention Centreだ。
このイベントには、アジアを中心とした世界中のWebエージェンシー、開発者、マーケター、デジタルプロフェッショナルが集結する。主催者によれば、エネルギーと創造性に満ち、急成長するデジタルエコシステムを抱えるムンバイは、WordPressコミュニティが集うのにふさわしい場所だという。
WordPress向けマネージドホスティングサービスを提供するKinstaは、今回が初のインドでの公式参加となる。同社はブース出展に加え、AIとマーケティングをテーマにしたパネルディスカッションのモデレートも担当する。
WordCamp Asia 2026の概要とKinstaの参加
WordCamp Asiaは、WordPressのオープンソースプロジェクトを支えるグローバルコミュニティが主催する地域カンファレンスの一つだ。アジア太平洋地域のWordPressユーザーや開発者が年に一度集まり、最新の技術動向、ビジネスノウハウ、コミュニティ活動について情報交換を行う。
2026年の開催地であるムンバイは、インドの経済と文化の中心地であり、活気あるスタートアップシーンとIT産業を擁する。この地での開催は、インドおよび南アジア地域におけるWordPressの普及とコミュニティ成長を後押しする大きな契機となる。
Kinstaのブースと担当スタッフ
Kinstaは会場内の409番ブースに出展する。来場者はブースでKinstaのチームと直接対話し、限定グッズを受け取り、WordPressプロジェクトに関する相談ができる。
Kinstaからは2名のスタッフが参加する。アジア太平洋地域のパートナーシップおよびコミュニティマネージャーを務めるAlexander Ando-Michaelsonと、EMEA地域のアカウントエグゼクティブであるSachi Jainだ。両名は、ホスティングプラットフォームの技術的特長だけでなく、地域ごとのビジネスニーズや開発環境についての知見も有している。
初のインド進出が意味するもの
Kinstaのインド初進出は、同地域のデジタル市場に対する本格的なコミットメントを示すものだ。インドは世界有数のIT人材を輩出し、デジタル経済の成長が著しい。WordPressは同国においても、企業のコーポレートサイトからECサイト、メディアプラットフォームまで、幅広く採用されている。
Kinstaのようなグローバルホスティングプロバイダーが直接コミュニティに参加することは、現地の開発者や企業が国際的なベストプラクティスや高性能インフラに触れる機会を提供する。これは、地域のWeb制作・開発の質的向上にも寄与すると見られている。
注目セッション：AIがマーケティング手法を再構築する
カンファレンスのセッションの一つとして、「AIが伝統的および近代的マーケティング手法をどのように再構築しているか」をテーマにしたパネルディスカッションが行われる。このセッションのモデレーターを、KinstaのAlexander Ando-Michaelsonが務める。
パネルの議論内容
パネルでは、AIがSEO、コンテンツ制作、ディスカバラビリティ（発見可能性）をどのように変容させているかに焦点が当てられる。具体的には、キーワードリサーチの自動化、パーソナライズされたコンテンツ生成、ユーザー行動予測に基づく広告配信最適化など、実際のマーケティング業務へのAI導入事例が議論される予定だ。
また、AIの急速な進化に対応して、マーケティングチームの組織構造やワークフローがどのように変化しているかについても検討される。リアルタイムデータ分析やオートメーションツールの普及により、従来の役割分担や意思決定のプロセスが再定義されている現状が共有される見込みだ。
WordPressエコシステムにおけるAIの位置づけ
このセッションの背景には、WordPress自体のAI機能統合の動きがある。ブロックエディタ（Gutenberg）へのAI支援機能の組み込みや、AIを活用したプラグインの増加は、コンテンツ作成の効率化を推し進めている。
一方で、生成AIが生み出すコンテンツの品質管理、SEOへの影響、著作権や倫理的な課題は、サイト運営者やマーケターにとって新たな検討事項となっている。パネルでは、こうした実務上の課題と機会のバランスについても、現場の声が交わされると期待される。
コミュニティ交流を深めるネットワーキングディナー
カンファレンス初日の4月9日（木曜日）には、Kinsta主催の招待制ネットワーキングディナーが会場近くで開催される。このディナーは、デジタル、マーケティング、テクノロジー分野のリーダーを対象とした交流の場だ。
ディナーの目的と過去の実績
Kinstaはこれまで、シンガポール、シドニー、東京などアジア太平洋地域の主要都市で同様のネットワーキングイベントを開催してきた。これらのイベントは、公式カンファレンスとは異なるリラックスした環境で、業界のプロフェッショナル同士が深く対話し、協力関係を築く機会として評価されている。
ムンバイでの開催は、インドのWordPressおよびデジタル業界のキーパーソンと、グローバルなプレイヤーをつなぐ役割を果たす。食事と飲み物を共にしながら、今後のWebの在り方やビジネスチャンスについて率直な意見交換が行われる。
コミュニティ形成における非公式イベントの価値
大規模カンファレンスでは、セッションやブース訪問が中心となり、個人間の深い対話には時間的制約がある。招待制の小規模ディナーは、そうした隙間を埋める。共通の課題や興味を持つ参加者同士が、より具体的なプロジェクトや協業の可能性について話し合える場を提供する。
オープンソースプロジェクトの持続的成長には、コードやドキュメントの貢献だけでなく、人的な信頼関係に基づくコミュニティの結束が不可欠だ。このような非公式交流は、コミュニティの社会的資本を強化する上で重要な役割を担っている。
WordPressホスティング市場と今後の展望
KinstaのWordCamp Asiaへの参加は、単なる企業PRを超えた意味を持つ。高性能なマネージドWordPressホスティング市場が、成熟した欧米から新興のアジア市場へと焦点を移しつつあることを示唆している。
アジア市場の特殊性と対応
アジア地域は、インターネットインフラ、利用デバイス、ユーザーの行動パターンが欧米と異なる。モバイルファーストの環境が主流であり、多様な言語や文字コードへの対応が求められる。さらに、国や地域ごとに異なるデータ保護規制（例えばインドの個人データ保護法）への準拠も必要だ。
ホスティングプロバイダーは、グローバルなサービス水準を維持しつつ、こうした地域固有の要件にどう応えるかが課題となる。現地のコミュニティイベントに参加し、直接フィードバックを得ることは、サービス改善と市場理解を深める有効な手段だ。
オープンソースと商業サービスの共生
WordPressは無償のオープンソースソフトウェアだが、その上で動作する高品質なWebサイトを構築・運営するには、有償のホスティング、テーマ、プラグイン、開発サービスが不可欠だ。WordCampのようなコミュニティイベントは、この「無償のコア」と「有償のエコシステム」が健全に共存し、互いに成長し合うための接点を提供している。
Kinstaのような商業企業がコミュニティに積極的に関わることで、プロジェクトへの資金還元（スポンサーシップ）や、開発者向けの最新技術情報の提供が可能になる。これは、オープンソースプロジェクトの持続可能性を高めるモデルの一つと言える。
この記事のポイント
- WordCamp Asia 2026は4月9日から11日まで、インド・ムンバイのJio World Convention Centreで開催される。
- Kinstaが初めてインドに進出し、409番ブースで来場者と交流する。APAC地域担当のAlexander Ando-Michaelsonが、AIとマーケティングをテーマにしたパネルディスカッションのモデレーターを務める。
- カンファレンス初日には、Kinsta主催の招待制ネットワーキングディナーが開催され、業界リーダー間の交流が図られる。
- この参加は、アジア市場、特にインドにおけるWordPressエコシステムの成長と、高性能ホスティングサービスの需要の高まりを反映している。
- コミュニティイベントは、オープンソースプロジェクトと商業サービスが共生し、互いの発展を促す重要なプラットフォームとなっている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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（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年の監査結果と技術的な透明性
今回の監査プロセスは、数ヶ月にわたる膨大な証拠収集を経て完了した。Cloudflare内の多くのチームが協力し、プライバシー管理が実際に機能していることを外部監査人に示したという。その結果、同社のコアとなるプライバシー保証は変わらず維持されていることが確認された。
ここで重要なのは、同社が「完璧なゼロデータ」を謳っているわけではないという点だ。ネットワークの健全性を保つためには、最低限のデータ利用が必要になる。今回の報告では、そうした例外的な処理についても透明性が確保されている。
プライバシー保証が再確認された意義
監査によって確認された主要なポイントは、DNS問い合わせから取得した情報を、他のCloudflareデータや第三者のデータと結びつけて個人を特定することはないという約束だ。これは、例えば同社の他のサービス（CDNやWAFなど）で得られたデータと、1.1.1.1の利用履歴を照合して「どのユーザーが何を見ているか」を分析することはない、ということを意味する。
Web制作に関わる立場から見れば、クライアントのサイト訪問者のプライバシーを守るためにも、信頼できるDNSインフラを推奨できる根拠が強まったと言えるだろう。
トラブルシューティングとデータ利用の限定範囲
Cloudflareは、ネットワークのトラブルシューティングや攻撃の緩和（DDoS対策など）のために、ごく一部のパケットをサンプリングしていることを公表している。その割合は最大でも全トラフィックの0.05％以下だ。このサンプリングデータにはユーザーのIPアドレスが含まれる場合があるが、あくまでネットワークの正常な運用のためにのみ使用される。
こうした「何を行っていないか」だけでなく「必要最小限で何を行っているか」を明示する姿勢こそが、プロフェッショナルなテックブログとしての信頼感に繋がっている。情報の透明性は、ユーザーとの信頼関係を築くための唯一の手段だと言える。
・広告に利用される懸念
・暗号化されない場合が多い
・独立監査による証明済み
・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を選ぶべき実務的なメリット
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サイトの表示速度向上とプライバシー保護を同時に実現する有効な手段だ。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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（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（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顧客向けのベータ版として提供されており、開発者による自由なロジック実装が可能。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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}`);
},
},
});上記のコード例では、コンテンツの読み取りとメール送信の権限のみを要求している。このプラグインが許可なく外部のネットワークと通信したり、データベースを直接書き換えたりすることは物理的に不可能だ。管理者はインストール時に、そのプラグインが何をしようとしているのかを正確に把握できる。
このデモは、従来のCMSとEmDashにおけるセキュリティ構造の違いを視覚化したものだ。
Astroとサーバーレスがもたらす圧倒的なパフォーマンス
EmDashの内部エンジンには、コンテンツ主導のWebサイト向けフレームワークとして評価の高い「Astro」が採用されている。Astroは必要な部分だけをJavaScriptで動かす「アイランドアーキテクチャ」を得意としており、ブラウザでの読み込み速度を極限まで高めることができる。
また、EmDashはサーバーレス環境での動作を前提に設計されている。具体的にはCloudflare Workers（クラウドフレア・ワーカーズ）のランタイムである「workerd」上で動作し、リクエストがあった瞬間にプログラムが起動する仕組みだ。これにより、アクセスがないときはリソースを消費せず、急激なトラフィック増にも即座に対応できる。
従来のWordPressのように、常にサーバーを起動させておく必要がないため、運用コストの大幅な削減が期待できる。Cloudflareによれば、CPUの計算時間に対してのみ課金されるモデルのため、小規模なサイトから大規模なプラットフォームまで効率的にスケールさせることが可能だという。
テーマ制作も現代的だ。開発者はAstroのコンポーネントやスタイル（Tailwind CSSなど）を使って、使い慣れたモダンな手法でサイトのデザインを構築できる。従来のWordPressテーマのように複雑なPHPの作法を覚える必要はなく、フロントエンドエンジニアにとって親和性の高い環境が整っている。
AI時代を見据えた新しい収益化モデルと開発体験
EmDashが他のCMSと一線を画すのが、AIエージェントによる管理を標準でサポートしている点だ。MCP（Model Context Protocol）サーバーを内蔵しており、AIがサイトのコンテンツ構造を理解したり、プラグインを生成したりするためのコンテキストを直接提供できる。
例えば、CLI（コマンドラインインターフェース）を通じてAIエージェントに指示を出し、メディアのアップロードやスキーマの変更、さらにはWordPressテーマの移植ガイドを生成させることも可能だ。これは「人間が管理画面をポチポチ操作する」という従来のCMSのあり方を、根本から変える可能性を秘めている。
さらに、コンテンツの収益化についても新しい提案がなされている。「x402」というインターネットネイティブな決済プロトコルを内蔵しているのだ。これはHTTP 402エラー（支払いが必要）を活用した仕組みで、AIエージェントなどがコンテンツにアクセスする際、都度少額の支払いを行う「ペイ・パー・ユース」のモデルを簡単に導入できる。
広告収益に頼る従来のWebビジネスモデルが、AIによるスクレイピングなどで脅かされている現状に対し、EmDashは技術的な解決策を提示している。管理画面でコンテンツごとの価格を設定し、ウォレットアドレスを登録するだけで、サブスクリプションに頼らない新しい収益源を構築できるのだ。
WordPressからのスムーズな移行とモダンな認証機能
既存のWordPressユーザーを置き去りにしないための工夫も凝らされている。専用のインポータープラグインを使用することで、記事データやメディアライブラリを数分でEmDashへ移行できる仕組みが用意された。
カスタム投稿タイプについても、EmDashでは管理画面から直接スキーマ（データの構造）を定義できる。WordPressでACF（Advanced Custom Fields）などの外部プラグインを駆使して実現していたような複雑なデータ構造も、標準機能としてよりクリーンに管理することが可能だ。
セキュリティ面では、パスワードを廃止し「パスキー（Passkeys）」による認証をデフォルトとしている。これにより、パスワードの漏洩や総当たり攻撃のリスクを事実上ゼロにできる。もちろん、既存のSSO（シングルサインオン）プロバイダーとの連携も可能だ。
CloudflareはEmDashを単なるWordPressの代替品ではなく、これからの20年を見据えた「Webの新しいOS」のような存在として位置づけている。MITライセンスで公開されているため、特定のプラットフォームに縛られることなく、誰もが自由に拡張や開発に参加できる点も大きな魅力だ。
独自の分析：EmDashがWeb制作の現場に与える影響
EmDashの登場は、Web制作のワークフローを劇的に変える可能性がある。特に注目すべきは、プラグインのライセンス問題からの解放だ。WordPressのプラグインは、その構造上GPLライセンスを継承せざるを得ないケースが多かったが、EmDashではプラグインが完全に独立して動作するため、作者が自由にライセンスを選択できる。
これは、高品質な商用プラグインのエコシステムがより健全に発展することを意味する。また、セキュリティが「信頼」ではなく「技術的な制約」によって担保されるため、マーケットプレイスによる中央集権的な審査を待たずとも、安全に新しい機能を導入できるようになるだろう。
一方で、これまでのPHPベースのスキルセットを持つ開発者にとっては、TypeScriptやAstroへの移行という学習コストが発生する。しかし、サーバー管理の苦労から解放され、AIを活用した高速な開発が可能になるメリットは、そのコストを補って余りあるものになるはずだ。まずはプレビュー版を自身の環境で試し、そのスピードと安全性を体感してみることをお勧めする。
この記事のポイント
- EmDashはCloudflareが開発した、TypeScriptベースの新しいオープンソースCMSだ。
- プラグインを独自のサンドボックスで実行することで、WordPressの脆弱性問題を根本的に解決する。
- Astroとサーバーレス技術を採用し、高い表示速度とスケーラビリティを両立している。
- AIエージェントによる管理や、x402プロトコルによる新しい収益化モデルを標準搭載している。
- パスキーによる認証や、WordPressからの簡単なデータ移行機能も備えている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI時代のキャッシュ設計を再考する——AIクローラーがCDNに与える影響と対策
CDN（コンテンツデリバリネットワーク）のキャッシュ設計が、AIクローラーの台頭によって根本的な見直しを迫られている。Cloudflareのデータによると、同社ネットワーク上のトラフィックの32%は自動化されたトラフィックが占める。検索エンジンクローラーや監視ツールに加え、近年はAIアシスタントが回答生成のためにWebから情報を取得するケースが増加している。
AIエージェントは人間とは異なるアクセスパターンを示す。高頻度の並列リクエスト、人気ページではなく長尾コンテンツへの集中的なアクセス、サイト全体の網羅的なスキャンなどが特徴だ。このような振る舞いは、従来の人間向けに最適化されたキャッシュアルゴリズムを無効化し、キャッシュミス率の上昇とオリジンサーバー負荷の増大を引き起こす。
サイト運営者はAIクローラーへの対応に迫られる。ブロックするか、サービスを提供するかの選択を迫られるが、両者のトラフィックパターンは大きく異なるため、既存のキャッシュアーキテクチャでは一方に最適化するしかない。本記事では、AIトラフィックがCDNキャッシュに与える影響を分析し、新しいキャッシュ設計の方向性を探る。
AIクローラーと人間のトラフィックの根本的な違い
AIクローラーのトラフィックは、人間のブラウジング行動と比較して3つの主要な特徴を持つ。高ユニークURL比率、コンテンツの多様性、クロールの非効率性だ。
高ユニークURL比率と長尾コンテンツへのアクセス
Common Crawlの公開データによると、大規模Webクロールでは90%以上のページがコンテンツ的にユニークだ。AIクローラーは特定のコンテンツタイプに特化する傾向があり、技術文書、ソースコード、メディアファイル、ブログ記事など、目的に応じて異なるコンテンツを対象とする。
人間のユーザーがトップページや人気記事に集中するのに対し、AIクローラーはサイトの奥深くまで探索する。Wikipediaの利用データは、かつて「長尾」とされていたほとんどアクセスされないページが、現在では頻繁にリクエストされるようになったことを示している。これはCDNキャッシュ内のコンテンツ人気度分布そのものを変化させている。
クロールの非効率性と反復ループ
AIクローラーは必ずしも最適なクロールパスをたどらない。人気のあるAIクローラーからのフェッチのかなりの割合が404エラーやリダイレクトで終わる。これはURL処理の不備によることが多い。また、ブラウザ側のキャッシュやセッション管理を人間のユーザーと同じように利用しない。
AIエージェントは検索結果を改良するために反復ループを行うことがある。これはRAG（Retrieval-Augmented Generation）における一般的なパターンだ。この反復ループは、エージェントの精度を高める一方で、一貫して高いユニークアクセス比率（70%から100%）を維持する。つまり、各ループで以前に見たページを再訪するのではなく、常に新しいユニークなコンテンツを取得し続ける。
キャッシュへの直接的な影響
長尾アセットへのこのような反復アクセスは、人間のトラフィックが依存するキャッシュをかき回す。既存のプリフェッチや従来のキャッシュ無効化戦略は、クローラートラフィックの量が増加するにつれて効果が低下する。Cloudflareの単一ノードにおけるキャッシュヒット率は、AIクローラーを含む場合と含まない場合で明確な差が見られる。ヒット率の低下は、LRU（Least Recently Used）アルゴリズムがAIクローラーの反復スキャン行動に対処できていないことを示唆している。
実例から見るAIクローラーのインパクト
AIボットトラフィックの急増は、実際のWebサービスに深刻な影響を与えている。大規模サイトにおける影響と対応策は以下の通りだ。
Wikipedia：マルチメディア帯域幅の50%急増
モデル訓練のための画像一括スクレイピングにより、マルチメディア帯域幅使用量が50%急増した。Wikimediaは最終的にクローラートラフィックをブロックする対応を取った。
SourceHutとRead the Docs：サービス不安定化
ソースコードリポジトリをスクレイピングするLLMクローラーにより、サービス不安定化と速度低下が発生。Read the Docsでは、AIクローラーが大きなファイルを1日に数百回ダウンロードし、帯域幅の大幅な増加を引き起こした。両サービスとも一時的にクローラートラフィックをブロックし、IPベースのレート制限を実施した。
FedoraとDiaspora：人間ユーザーへの影響
Fedoraはパッケージミラーを再帰的にクロールするAIスクレイパーにより、人間ユーザーに対する応答速度が低下。Diasporaソーシャルネットワークは、robots.txtを尊重しない積極的なスクレイピングにより、応答速度の低下とダウンタイムを経験した。両者とも既知のボットソースからのトラフィックを地理的にブロックするなどの対応を取った。
これらの事例が示すのは、AIクローラーを単純にブロックするだけでは根本的な解決にならないということだ。よりスマートなキャッシュアーキテクチャがあれば、サイト運営者はAIクローラーにサービスを提供しつつ、人間ユーザーの応答時間を維持できる。
AI時代に向けたキャッシュ設計の新たな方向性
AIトラフィックの特性を考慮した新しいキャッシュ設計が必要とされている。主なアプローチは2つある。AIを意識したキャッシュアルゴリズムによるトラフィックフィルタリングと、AIクローラートラフィック専用の新しいキャッシュ層の追加だ。
ワークロード対応型キャッシュアルゴリズム
現在広く使用されているLRU（Least Recently Used）アルゴリズムは、汎用状況においてシンプルさ、低オーバーヘッド、有効性のバランスが取れている。しかし、人間とAIボットの混合トラフィックに対しては、別のキャッシュ置換アルゴリズムの選択が有効かもしれない。
初期実験では、SEIVEやS3FIFOといったアルゴリズムを使用することで、AIの干渉の有無にかかわらず、人間トラフィックが同じヒット率を達成できる可能性が示されている。さらに、ワークロードを直接意識した機械学習ベースのキャッシュアルゴリズムを開発し、リアルタイムでキャッシュ応答をカスタマイズする実験も進められている。これにより、より高速でコスト効率の高いキャッシュが実現できる。
トラフィック種別に応じた階層化キャッシュアーキテクチャ
長期的には、AIトラフィック専用の別個のキャッシュ層が最善の道となる。人間とAIのトラフィックをネットワークの異なる層に配置された別個の階層にルーティングするキャッシュアーキテクチャが考えられる。
人間トラフィックは、応答性とキャッシュヒット率を優先するCDN PoP（Point of Presence）のエッジキャッシュから引き続きサービスされる。一方、AIトラフィックのキャッシュ処理はタスクタイプによって変えることができる。
RAGやリアルタイム要約のようなライブアプリケーションを支えるAIクローラーでは、レイテンシが重要だ。これらのリクエストは、より大きな容量と適度な応答時間のバランスが取れたキャッシュにルーティングされるべきである。これらのキャッシュは鮮度を保ちつつも、人間向けキャッシュよりもわずかに高いアクセスレイテンシを許容できる。
訓練セットの構築や大規模コンテンツ収集ジョブに使用されるAIクローラーは、かなり高いレイテンシを許容し、時間的制約がない。これらのワークロードは、到達までに時間がかかる深いキャッシュ階層（オリジン側のSSDキャッシュなど）からサービスできる。あるいは、キューベースのアドミッションやレートリミッターを使用して遅延させ、バックエンドの過負荷を防ぐことも可能だ。これにより、インフラに負荷がかかっている場合にバルクスクレイピングを延期する機会も生まれる。
この記事のポイント
- AIクローラーは全ネットワークトラフィックの約3分の1を占め、そのアクセスパターンは人間のブラウジング行動と根本的に異なる。
- 高ユニークURL比率、長尾コンテンツへの集中アクセス、反復ループによるキャッシュチャーンが、従来のLRUキャッシュアルゴリズムの効果を低下させている。
- WikipediaやFedoraなどの大規模サイトでは、AIクローラーによる帯域幅急増やサービス不安定化が実際に発生し、多くのサイトがクローラーブロックに頼らざるを得なくなっている。
- 根本的な解決策として、SEIVEやS3FIFOなどの新しいキャッシュアルゴリズムの採用と、AIトラフィック専用の階層化キャッシュアーキテクチャの構築が検討されている。
- 今後のCDN設計では、人間トラフィックとAIトラフィックを分離し、それぞれの特性に最適化したキャッシュ戦略を適用することが重要になる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験