Kubernetesの1行修正で年600時間を削減——Cloudflareが直面したPVマウントの罠
Kubernetesの設定ファイルをたった1行書き換えるだけで、年間600時間ものエンジニア工数を削減した事例がある。Cloudflare（クラウドフレア）のインフラチームが直面したこの問題は、システムの規模が拡大するにつれて静かに忍び寄る「デフォルト設定の罠」を浮き彫りにした。
原因は、ストレージの権限管理を行うKubernetesの標準的な振る舞いにあった。数百万ものファイルを抱えるボリュームにおいて、再起動のたびに30分ものダウンタイムが発生していた事態を、彼らはどのように特定し、解決したのだろうか。
本記事では、CloudflareのエンジニアであるBraxton Schafer氏が公開したデバッグの過程と、大規模なKubernetes運用において見落としがちなパフォーマンスのボトルネックについて詳しく解説する。
Atlantisの再起動がなぜか「30分」もかかる謎
Cloudflareでは、Terraform（テラフォーム）によるインフラ管理の自動化ツールとして「Atlantis（アトランティス）」を利用している。Terraformはコードでインフラを定義するツールだが、Atlantisを導入することで、GitHubやGitLabのプルリクエスト上で実行計画（Plan）の確認や適用（Apply）が可能になる。
AtlantisはKubernetes上で「StatefulSet（ステートフルセット）」として動作しており、リポジトリの状態を保持するためにPV（Persistent Volume / 永続ボリューム）を使用している。StatefulSetとは、Pod（ポッド）の再起動後もデータの永続性を保証するための仕組みだ。
頻繁な再起動がエンジニアの時間を奪う
問題は、このAtlantisを再起動するたびに発生していた。新しいプロジェクトの設定を読み込ませたり、認証情報を更新したりするために、Cloudflareでは月に約100回ほどの再起動を行っていた。しかし、再起動を開始してからPodが正常に立ち上がるまで、毎回30分もの時間がかかっていたという。
この間、エンジニアはインフラの変更を行うことができず、作業が完全にブロックされてしまう。月100回の再起動で毎回30分待機が発生すれば、月間で50時間、年間では600時間もの時間が「ただの待ち時間」として消えていく計算だ。これは、一人のエンジニアが数ヶ月間フルタイムで働く時間に匹敵する大きな損失である。
「inode不足」がきっかけで表面化した問題
この遅延が決定的な問題として認識されたのは、ストレージの「inode（アイノード）」が枯渇した際だった。inodeとは、ファイルシステム上でファイルやディレクトリの情報を管理するためのデータ構造だ。ファイルが大量に作成されると、ディスク容量が残っていてもinodeが足りなくなり、新しいファイルが作成できなくなる。
Cloudflareの環境では、ファイルシステムを拡張することでしかinodeを増やせない仕様だった。拡張を反映させるにはPodの再起動が必要となり、そのたびに30分のダウンタイムが発生する。チームは当初、アラートの通知設定を調整して「見かけ上の問題」を回避することも検討したが、根本的な原因の調査に乗り出すことを決めた。
Kubernetesのログを深掘りして見えてきたボトルネック
調査を開始したBraxton Schafer氏は、まずkubectl rollout restartコマンドを実行し、新しいPodが立ち上がる様子を観察した。Pod自体はすぐにスケジュールされるものの、ステータスが「Init（初期化中）」のまま30分間も停止していることが判明した。
Podのイベントログを確認しても、イメージのプルが開始されるまでに不可解な空白時間があることしかわからなかった。そこで氏は、より低レイヤーのログを確認するため、各ノードで動作するコンポーネント「kubelet（クブレット）」のログを調査した。
kubeletのログに隠された「空白の時間」
kubeletは、各ノードでPodの実行を管理し、ボリュームのマウントなどを制御する重要なエージェントだ。システム管理ツールであるKibana（キバナ）を使ってログを分析したところ、PVのマウント自体は成功しているものの、その直後にタイムアウトエラーが発生し、リトライを繰り返している様子が記録されていた。
ログには「context deadline exceeded（処理時間の制限を超過した）」というメッセージが並んでいた。何らかの処理が異常に時間を要しており、Kubernetesの監視機構がそれを「失敗」とみなして処理を中断、再試行するというループに陥っていたのだ。
数百万個のファイルが引き起こす権限変更の罠
さらに詳細なログを追うと、決定的なメッセージが見つかった。そこには「Setting volume ownership（ボリュームの所有権を設定中）」という記述があった。実はこれが、30分もの時間を浪費させていた真犯人だった。
Kubernetesには、Pod内のプロセスがボリュームにアクセスできるように、マウント時に所有権を自動で調整する機能がある。具体的には、PodのsecurityContextで指定されたfsGroupのIDに合わせて、ボリューム内の全ファイルに対して再帰的にchgrp（グループ変更）を実行する。Atlantisのようなツールは運用期間が長くなるほど管理するファイル数が増大し、Cloudflareの環境では数百万個ものファイルが蓄積されていた。高速なストレージであっても、数百万個のファイルに対して一つずつ権限を確認・変更していく処理には膨大な時間がかかるのは必然だ。
わずか1行の修正でパフォーマンスが劇的に改善
原因が「再帰的な権限変更」であると特定できれば、解決策は非常にシンプルだった。Kubernetes 1.20以降、この振る舞いを制御するための新しい設定項目が追加されている。それがfsGroupChangePolicy（エフエスグループ・チェンジ・ポリシー）だ。
デフォルトでは、このポリシーはAlways（常に実行）に設定されている。つまり、Podが起動するたびに、すでに権限が正しく設定されていようがいまいが、すべてのファイルをスキャンして権限を上書きしようとする。これが大規模なボリュームにおいて致命的な遅延を引き起こす。
fsGroupChangePolicyの設定とは
解決策は、このポリシーをOnRootMismatch（ルートディレクトリが不一致の場合のみ実行）に変更することだ。この設定にすると、Kubernetesはまずボリュームのルートディレクトリの権限を確認する。もしルートの権限がすでに正しく設定されていれば、配下のファイルに対する再帰的なスキャンをスキップする。
spec:
template:
spec:
securityContext:
fsGroupChangePolicy: OnRootMismatchこの1行をマニフェストファイルに追加するだけで、権限変更のプロセスが大幅に簡略化される。Cloudflareのケースでは、これまで30分かかっていた再起動時間が、わずか30秒にまで短縮された。実に60倍の高速化だ。
30分から30秒へ、驚異的な短縮効果
この修正により、エンジニアがデプロイの待ち時間に拘束されることがなくなった。また、再起動が長引くことによって発生していた「Podが正常に起動しない」という偽のアラートに、オンコール担当者が夜中に叩き起こされることもなくなったという。技術的には極めて単純な変更だが、組織全体の生産性に与えたインパクトは計り知れない。
大規模システムにおける「デフォルト設定」の落とし穴
今回の事例から学べる最も重要な教訓は、Kubernetesの「安全なデフォルト設定」が、規模の拡大とともに牙を向く可能性があるということだ。fsGroupによる自動的な権限変更は、初心者が権限エラーに悩まされないようにするための親切な機能として設計されている。
しかし、エンタープライズレベルの運用において、数テラバイトのデータや数百万のファイルを扱うようになると、その「親切心」がシステムの可用性を損なう要因へと変わる。これは、小規模なプロジェクトでは決して表面化しない問題だ。
小規模なら問題ないが、スケールするとボトルネックになる
多くのインフラエンジニアは、マウントが遅い場合にネットワークやストレージ装置の性能を疑う。しかし、今回のケースのように「OSレベルのファイル操作」がバックグラウンドで走っていることに気づくには、深いオブザーバビリティ（観測性）が必要だ。Braxton Schafer氏が、Kubernetesのイベントログだけでなく、kubeletのシステムログまで掘り下げたことが早期解決の鍵となった。
SRE的視点での教訓
SRE（Site Reliability Engineering / サイト信頼性エンジニアリング）の観点では、「なぜシステムはこのように振る舞うのか？」という問いを持ち続けることの重要性が再確認された。30分の待ち時間を「そういうものだ」と受け入れてしまえば、年間600時間の損失は永遠に解消されなかっただろう。
もし読者の環境でも、特定のPodの起動が異常に遅かったり、ボリュームをマウントする際にInitコンテナで止まっていたりする場合は、securityContextの設定を見直してみる価値がある。特に、大量の静的ファイルを保持するCMSや、データベースのバックアップファイルを扱うPodなどは、同様の問題を抱えている可能性が高い。
この記事のポイント
- 原因の特定: Atlantisの再起動に30分かかっていたのは、Kubernetesがマウント時に全ファイルの所有権を再帰的に変更していたため。
- 1行の修正:
fsGroupChangePolicy: OnRootMismatchを設定することで、不要な権限変更をスキップできる。 - 劇的な改善: Cloudflareはこの修正により、再起動時間を30分から30秒に短縮し、年間600時間の工数を削減した。
- 教訓: 安全のためのデフォルト設定が、大規模環境では深刻なパフォーマンス低下を招くことがある。
- 推奨アクション: 大容量PVを使用するPodでは、
securityContextの設定を監査し、不必要な再帰処理を避ける設定を検討すべきだ。
出典
- Cloudflare Blog「A one-line Kubernetes fix that saved 600 hours a year」（2026年3月26日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Workflowsの可視化技術——ASTを活用したコードから図への変換プロセスを解説
Cloudflare Workflowsでデプロイされたすべてのワークフローに対し、ダッシュボード上で完全な視覚的図解（ダイアグラム）を表示する機能が追加された。この機能は、YAMLやJSONのような宣言的な設定ファイルからではなく、実際に記述されたJavaScript/TypeScriptのコードを直接解析して生成される点が最大の特徴だ。
開発者が記述したコードを「oxc-parser」を用いてAST（Abstract Syntax Tree / 抽象構文木）へと変換し、静的解析によってステップ間の依存関係や並列処理を抽出している。これにより、複雑なループや条件分岐を含む動的なワークフローであっても、その構造を一目で把握することが可能になった。
AIエージェントによるコード生成が増加する現代において、人間がコードの全容を即座に理解するための補助ツールとして、この可視化技術は極めて重要な役割を果たす。本記事では、難解な最小化済みコードからどのようにして意味のある図を導き出しているのか、その技術的な裏側を詳しく見ていく。
Cloudflare Workflowsの可視化機能とその背景
なぜ「コードからの可視化」が必要なのか
従来のワークフロー構築ツールの多くは、ドラッグ＆ドロップのビジュアルエディタや、YAML/JSONによる宣言的な定義をベースにしていた。これらは図解しやすい反面、複雑なロジックを記述する際の柔軟性に欠けるという弱点がある。
対してCloudflare Workflowsは「コードがすべて」というモデルを採用している。Promise.allによる並列実行、複雑なforループ、条件分岐などが通常のJavaScriptとして記述できる。しかし、自由度が高い反面、コードが複雑になると全体の流れを把握するのが難しくなる。記事によれば、特にAIが生成したコードを人間が確認する際、その「形状（shape）」を視覚的に理解できるメリットは大きいという。
動的実行モデルという技術的ハードル
Workflowsは「動的実行モデル」に従っている。これは、ランタイムがコードを実行中にステップ（step.do）に遭遇するたびに、制御をエンジン（Durable Object）に渡す仕組みだ。エンジンは実行されたステップの結果を保存するが、次にどのステップが来るかを事前には知らない。
図を作成するには、実行前（デプロイ時）に全体の構造を知る必要がある。しかし、エンジンが実行時にしかステップを把握できないのであれば、静的な図を作ることはできない。そこで、Cloudflareのチームはデプロイ時にスクリプトを解析し、コードの構造を「読み解く」アプローチを選択した。
AST（抽象構文木）を用いたコード解析の仕組み
最小化されたJavaScriptという難問
デプロイされるコードは、通常esbuildやrspack、viteなどのツールによって「最小化（Minify）」されている。変数名はaやbに書き換えられ、改行は消え、人間には解読不能な1行の巨大な文字列となる。この状態からワークフローのステップを抽出するのは容易ではない。
AST（Abstract Syntax Tree / 抽象構文木）とは、プログラミング言語の構文構造を樹木構造で表現したデータ形式だ。コードをトークンに分解し、どの関数がどの引数で呼び出されているかを構造的に把握できる。Cloudflareは、このASTを利用して最小化されたコードのジャングルからstep.doやstep.sleepといった特定の呼び出しを特定している。
高速な解析を実現するoxc-parserの採用
解析エンジンには、Rust製の高速なJavaScriptツールチェーンである「OXC（JavaScript Oxidation Compiler）」のoxc-parserが採用された。当初はコンテナ上でRustを動かしていたが、最終的にはWebAssembly（Wasm）を介してCloudflare Workers上で動作するRust Workerへと移行されたという。
このRust Workerが最小化されたJSをASTに変換し、定義されたノードタイプ（LoopNode, ParallelNode, IfNodeなど）にマッピングしていく。以下に、コードがどのようにASTを経て図の要素へ変換されるかの概念図を示す。
step.do('task', ...)このデモは、ソースコードがAST解析を経て、最終的にダッシュボード上の視覚的なステップノードへとマッピングされる流れを視覚化したものだ。
複雑なロジックをグラフ構造にマッピングする手法
並列処理を表現する「開始」と「解決」のインデックス
Workflowsにおいて最も表現が難しいのが、並列処理だ。JavaScriptではawaitを付けずにステップを呼び出すと並列に実行され、Promise.allでそれらをまとめて待機できる。これを図にするため、Cloudflareのチームは各ノードにstartsとresolvesというフィールドを持たせた。
解析中にawaitされていないPromiseに遭遇すると、そのノードに「開始（starts）」のインデックスを付与する。その後、awaitに遭遇した時点でインデックスを増やし、「解決（resolves）」として記録する。この数値の重なりを見ることで、どのステップが垂直方向に並ぶべきか（＝並列か）、どのステップが完了を待って次に進むべきかを正確に判定している。
制御構文（ループ・分岐）のパターン網羅
単なる直線的なフローだけでなく、実務では多様な構文が使われる。著者のAndré氏とMia氏は、以下のような多岐にわたるパターンをASTから抽出できるように設計したと述べている。
- ループ:
for...of,while,items.map,forEach - 分岐:
switch/case,if/else, 三項演算子 - エラーハンドリング:
try/catch/finally - 関数呼び出し: ステップをラップした関数の追跡
特に、関数の中に隠れたステップの追跡は工夫が必要だ。ある関数が直接ステップを呼び出していなくても、その中で呼び出している別の関数がステップを含んでいる場合、その依存関係をグラフに含める必要がある。記事によれば、関数ごとのサブグラフを作成し、最終的にステップを含まない「葉」の部分をトリミングすることで、ノイズのない図を実現している。
開発体験（DX）における可視化の価値と今後の展望
デバッグ効率を劇的に高めるリアルタイム追跡
この可視化機能は単なる「清書された図」ではない。Cloudflareは、これをフルサービスのデバッグツールへと進化させる計画だ。具体的には、実行中のワークフローが今どのノードにいるのかをグラフ上でリアルタイムに追跡できるようにするという。
エラーが発生した場所の特定、人間による承認待ちの状態確認、あるいはテスト目的での特定ステップのスキップなど、ビジュアルインターフェースを通じて操作できる未来を目指している。さらに、ローカル開発環境での可視化も視野に入れているとのことで、開発サイクル全体での利便性向上が期待される。
独自の分析：コードを「正解」とするアプローチの意義
今回のCloudflareの取り組みで特筆すべきは、「ビジュアルエディタで作ったものをコードに書き出す」のではなく、「コードからビジュアルを逆生成する」という方向性を徹底している点だ。これは、エンジニアにとっての真実の源泉（Source of Truth）が常にコードであることを尊重している。
このアプローチの利点は、Gitによるバージョン管理やコードレビューといった既存の開発フローと完全に共存できることにある。図を作成するために特別な設定ファイルを書く必要がなく、普段通りにコードを書くだけで、非エンジニアのステークホルダーにも共有しやすい図が手に入る。これは、開発組織におけるコミュニケーションコストを大幅に下げる可能性を秘めている。
また、AST解析という「枯れた」技術を、最小化されたJSという「汚れた」実データに適用し、それをWasmでエッジ上で高速実行するという構成は、非常にCloudflareらしい合理的でパワフルな解決策だと言えるだろう。
この記事のポイント
- コードから図を自動生成: Cloudflare Workflowsは、JS/TSコードを解析して視覚的な図を自動作成する。
- AST（抽象構文木）の活用: 最小化された難解なコードも、AST解析によって構造的に理解し、ステップを抽出する。
- oxc-parserによる高速処理: Rust製の解析器をWasmで動かすことで、デプロイ時の高速な図解生成を実現した。
- 並列処理の可視化:
startsとresolvesというインデックスを用いて、複雑な並列実行の関係を正確に図示する。 - デバッグツールへの進化: 今後はリアルタイムの実行追跡や、図からの操作機能も追加される予定だ。
出典
- Cloudflare Blog「How we use Abstract Syntax Trees (ASTs) to turn Workflows code into visual diagrams」（2026年3月27日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIエージェント実行を100倍高速化。Cloudflare Dynamic Worker Loaderの革新性
AIエージェントが自らコードを書き、それを実行してタスクを完結させる「コード実行型」のワークフローが注目を集めている。しかし、AIが生成したコードを安全に動かすには、メインのシステムから隔離された「サンドボックス」が不可欠だ。
Cloudflareは2026年3月24日、このサンドボックスをオンデマンドで、かつ従来のコンテナ技術より100倍高速に起動できる「Dynamic Worker Loader」のオープンベータ公開を発表した。V8 Isolate技術を基盤とすることで、ミリ秒単位の起動と圧倒的なリソース効率を実現している。
この記事では、Dynamic Worker LoaderがなぜAIエージェントのスケールにおいて重要なのか、そしてエンジニアがどのようにこれを活用できるのかを詳しく解説する。
AIエージェントの安全性を支える「サンドボックス」の課題
AIエージェントがAPIを呼び出す際、単なる「ツール呼び出し（Tool Calling）」ではなく、コードを生成して実行させる手法は、トークン消費量を大幅に削減できることが分かっている。記事によれば、TypeScript APIを使用することで、トークン使用量を最大81%削減できた例もあるという。
なぜAI生成コードの直接実行は危険なのか
AIが生成したコードをアプリケーション内で直接実行（evalなど）することは、セキュリティ上の致命的なリスクとなる。悪意のあるユーザーがプロンプトを通じて脆弱性を注入し、システムの機密情報にアクセスしたり、不正な操作を行ったりする可能性があるからだ。
そのため、コードを実行する場所は、アプリケーションや他の環境から完全に隔離された「サンドボックス（砂場）」でなければならない。サンドボックスとは、特定の権限やリソースのみにアクセスを制限した実行環境のことだ。
既存のコンテナ技術が抱える「重さ」の壁
これまで、サンドボックスの構築にはDockerなどのLinuxコンテナが一般的に使われてきた。しかし、コンテナには大きな弱点がある。起動に数百ミリ秒から数秒かかり、メモリ消費量も数百MB単位と「重い」ことだ。
数百万人のユーザーがそれぞれAIエージェントを動かすようなコンシューマー規模のサービスでは、コンテナを都度立ち上げるコストは無視できない。かといって、セキュリティのためにコンテナを使い回さず、リクエストごとにクリーンな環境を用意しようとすると、パフォーマンスとコストの両面で限界に突き当たる。
Dynamic Worker Loader：V8 Isolateによる100倍速の革新
Cloudflareが提供する「Dynamic Worker Loader」は、この「重さ」の問題を根本から解決する。その鍵となるのが、Google Chromeでも採用されているJavaScript実行エンジン「V8」の「Isolate（アイソレート）」という仕組みだ。
起動時間は数ミリ秒、メモリ消費も最小限
Isolateは、OSレベルの仮想化であるコンテナとは異なり、プロセス内でメモリを論理的に分離する。これにより、起動時間はわずか数ミリ秒、メモリ消費も数MB程度に抑えられる。著者のKenton Varda氏らは、これが一般的なコンテナと比較して「100倍高速で、10〜100倍メモリ効率が良い」と指摘している。
この軽量さにより、1つのリクエストごとに新しいサンドボックスを生成し、実行が終わったら即座に破棄するという運用が現実的になる。同時並行で数百万のリクエストが発生しても、Cloudflareのインフラ上でシームレスにスケール可能だ。
世界数百拠点でのゼロレイテンシ実行
Dynamic Worker Loaderで生成されたワーカーは、通常、それを作成した親ワーカーと同じマシン、あるいは同じスレッド上で動作する。そのため、遠くのサーバーにある「ウォーム状態のコンテナ」を探しに行く必要がない。
Cloudflareが世界中に持つ数百の拠点すべてで動作するため、ユーザーに最も近い場所で、遅延（レイテンシ）をほぼ感じさせることなくAIコードを実行できるのが強みだ。
TypeScript RPCによる効率的なAPI連携
AIエージェントが外部のAPIと通信する際、従来はOpenAPI（REST）などの定義ファイルが使われてきた。しかし、Dynamic Worker Loaderでは、より簡潔な「TypeScript」による定義を推奨している。
OpenAPIより優れたトークン効率
OpenAPIの定義ファイルは冗長になりがちで、LLM（大規模言語モデル）に読み込ませる際のトークン消費が激しい。一方、TypeScriptのインターフェース定義は非常にコンパクトだ。AIにとっても理解しやすく、少ないトークン数でAPIの仕様を正確に伝えられる。
Dynamic Worker Loaderは「Cap’n Web RPC」という技術を使って、サンドボックス内のエージェントと親ワーカーの間で高速な通信を行う。エージェント側からは、あたかもローカルライブラリを使っているかのように、型安全なメソッド呼び出しが可能になる。
認証情報の注入とセキュアな外部接続
セキュリティ面でも、このRPCモデルは有利に働く。例えば、外部サービスへの認証トークンをエージェントに直接教える必要はない。エージェントがHTTPリクエストを送る際、親ワーカー側でリクエストをインターセプト（傍受）し、そこで認証ヘッダーを付与する「Credential Injection（認証情報の注入）」が可能だからだ。
これにより、万が一AIが生成したコードに悪意があったとしても、生の認証情報がエージェント側に漏洩するリスクを最小限に抑えられる。
AI開発を加速させる3つの公式ヘルパーライブラリ
Cloudflareは、Dynamic Worker Loaderをより使いやすくするために、3つの強力なヘルパーライブラリを提供している。これらを組み合わせることで、高度なAIエージェント環境を短期間で構築できる。
コード実行を簡略化する「Code Mode」
@cloudflare/codemodeは、LLMが生成したコードの実行を管理するライブラリだ。コードの正規化（フォーマットエラーの修正）や、fetch()の挙動制御を簡単に行える。完全に隔離された状態（ネットワークアクセス禁止）から、特定のプロキシ経由の通信まで、柔軟に設定可能だ。
ランタイムでのバンドルを可能にする「Worker Bundler」
Dynamic Workerは、依存関係が解決された「バンドル済み」のモジュールを必要とする。@cloudflare/worker-bundlerを使えば、実行時にnpmパッケージを含むソースコードをバンドルできる。例えば、Honoなどの軽量フレームワークをAIエージェントに使わせることも容易だ。
仮想ファイルシステムを提供する「Shell」
@cloudflare/shellは、サンドボックス内に仮想的なファイルシステムを提供する。エージェントはファイルの読み書き、検索、置換、diffの取得などが可能になる。ストレージの実体はSQLiteやR2（Cloudflareのオブジェクトストレージ）に保存されるため、実行を跨いでファイルを永続化させることもできる。
実務への応用とコストパフォーマンスの分析
Dynamic Worker Loaderの導入は、AIアプリケーションのアーキテクチャに大きな変革をもたらす。筆者の分析によれば、特に以下の3つの分野で大きなメリットがある。
第一に、「Tool Calling」のオーバーヘッド削減だ。従来のように、AIが1つずつツールを呼び出して結果を待ち、次のアクションを決めるループを繰り返すと、その都度コンテキストが膨らみ、レイテンシも増大する。Dynamic Workerを使えば、AIが「一連の処理をまとめたスクリプト」を一度に書き、それを実行するだけで済む。これは、大規模なAPIセットを持つシステムほど効果が高い。
第二に、コスト効率の劇的な向上だ。Dynamic Workerの料金は、ロード1回につき0.002ドル（ベータ期間中は無料）に、通常のCPU使用料が加算される仕組みだ。これはLLMの推論コストと比較すれば微々たるものだ。重いコンテナを常時起動させておく「ウォームスタンバイ」のコストから解放される意味は大きい。
第三に、プロトタイピングの高速化だ。Ziteなどの企業がすでに導入しているように、ユーザーの要望に応じてその場でCRUDアプリや自動化ロジックを生成し、即座にデプロイして動かすような「AIネイティブなPaaS」の構築が容易になる。
この記事のポイント
- 100倍の高速化: V8 Isolateにより、コンテナより圧倒的に速く軽量なサンドボックスを実現。
- セキュアな隔離: AI生成コードをメインシステムから分離し、安全にオンデマンド実行できる。
- 高いトークン効率: TypeScript RPCを活用し、冗長なOpenAPI定義を避けてコストを削減。
- 充実のライブラリ: コード実行、バンドル、ファイル操作を支援する公式ツールが提供されている。
- スケーラビリティ: Cloudflareのグローバルネットワーク上で、数百万のリクエストに即座に対応可能。
出典
- Cloudflare Blog「Sandboxing AI agents, 100x faster」（2026年3月24日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VPNからCloudflare Oneへ——レガシー環境を安全にSASEへ移行するための戦略的ロードマップ
ネットワークエンジニアにとって、既存のVPN環境を新しいアーキテクチャへ切り替える週末は、キャリアの中でも最もストレスのかかる48時間になりかねない。数万人規模の組織が、千を超えるレガシーアプリケーションを断片化されたVPNから新環境へ一斉に移行しようとすれば、そのリスクは計り知れないものになる。
設定ミス一つで基幹サービスが停止し、業務が停滞する恐怖は、多くの組織がZero Trust（ゼロトラスト）への移行を躊躇する最大の要因だ。ゼロトラストとは「何も信頼しない」ことを前提に、すべてのアクセスを検証するセキュリティモデルを指す。本記事では、Cloudflareが提唱する「ビッグバン」を避けた、安全でアジャイルなSASE移行の戦略について解説する。
SASE（Secure Access Service Edge / サシー）は、ネットワーク機能とセキュリティ機能をクラウド上で統合して提供する枠組みだ。この記事を読むことで、レガシーなインフラを抱える企業が、いかにしてダウンタイムなしに最新のセキュリティポスチャ（セキュリティの状況や姿勢）へと進化できるかが理解できるだろう。
なぜレガシーVPNからの脱却は「ビッグバン」ではいけないのか
従来のネットワーク移行でよく見られる失敗は、ネットワークを単なる「配管」として扱ってしまうことだ。元記事の著者であるWarnessa Weaver氏は、多くの組織がアプリケーション間の複雑な依存関係を理解せずに、数百のアプリを一斉に移動させる「リフト・アンド・シフト」の罠に陥っていると指摘している。
ネットワークを単なる「配管」と捉えるリスク
多くの企業において、ネットワークは単にデータを運ぶ土台ではなく、アプリケーションやデータベースが密接に絡み合ったエコシステムとなっている。ある公共部門のプロジェクトでは、4,000以上のアプリケーションのうち500個を一度に移行しようとした結果、システム全体に深刻なサービス中断が発生したという。これは、バックエンドの依存関係を精査せずに移行を強行した典型的な失敗例だ。
依存関係の把握不足が招くサービス停止の連鎖
VPN（Virtual Private Network）は、一度認証されるとネットワーク全体へのアクセスを許可する「境界型セキュリティ」に基づいている。これに対し、SASEへの移行は、アプリケーションごとにアクセス権限を細かく設定する「最小権限の原則」への移行を意味する。事前の調査なしにこの制限を適用すると、本来必要だった内部APIの呼び出しやデータベース接続が遮断され、アプリが正常に動作しなくなる。エンジニアは、移行を「配管の交換」ではなく「アプリケーションの近代化プロジェクト」として捉える必要がある。
Cloudflare Accessによるレガシーアプリケーションの「ラッピング」
移行のリスクを抑えるための鍵は、既存のアプリケーションを書き換えることなく、最新のセキュリティ層で「包み込む（ラッピングする）」ことだ。これには、Cloudflare Accessというツールが活用される。
コードを書き換えずにMFAを導入する仕組み
多くの古い（レガシーな）社内アプリには、多要素認証（MFA / Multi-Factor Authentication）の機能が備わっていない。MFAとは、パスワードだけでなく、スマホの承認や物理キーなど複数の手段で本人確認を行う仕組みだ。通常、これらを導入するにはアプリのコード修正が必要だが、Cloudflare Accessを使えば、アプリの前段に認証ゲートウェイを設置できる。これにより、アプリ自体は古いまま、最新のSSO（Single Sign-On）やMFAを強制することが可能になる。
Cloudflare Tunnelで外部からの攻撃面を最小化する
さらに、Cloudflare Tunnelという技術を組み合わせることで、セキュリティはより強固になる。これは、社内サーバーからCloudflareのネットワークに向かって「外向き」の接続を確立する仕組みだ。サーバーにパブリックIPアドレスを割り当てる必要がなくなるため、インターネット上からサーバーの存在自体を隠すことができる。攻撃者がスキャンしても入り口が見つからない状態、つまり「攻撃面（アタックサーフェス）」がほぼゼロになるのだ。
成功率を高めるための「4つの事前監査」とティア分け
移行を開始する前に、ITリーダーは環境の「建築的準備」を整える必要がある。CDWのセキュリティエグゼクティブであるEric Marchewitz氏によれば、十分な準備なしに最小権限アクセスを適用すると、多くのレガシーアプリが動作しなくなる可能性があるからだ。
IDプロバイダーと依存関係の徹底的な洗い出し
まず最初に行うべきは、アイデンティティ（ID）とアーキテクチャのアセスメントだ。Oktaのようなクラウド型IDプロバイダーを利用しているアプリと、古いローカルディレクトリを使っているアプリを仕分ける。同時に、バックエンドのデータベースやAPIの依存関係をマップ化する。このデータがあれば、切り替え時にどのAPIコールが切断されるかを事前に予見し、対策を講じることができる。
アプリケーションの複雑度に応じた4段階のティア管理
元記事では、アプリケーションをその技術的複雑さに応じて4つの「ティア（階層）」に分類することを推奨している。これにより、現実的な移行スケジュールを立てることが可能になる。
| ティア | 説明 | 推定移行工数 |
|---|---|---|
| ティア 0 (モダンSaaS) | SAML/OIDC対応。CloudflareがIDプロバイダーとして機能する | 1アプリあたり1〜3時間 |
| ティア 1 (内部Webアプリ) | 標準的なWebプロトコル。Cloudflare Tunnelでリバースプロキシ化 | 1アプリあたり3〜6時間 |
| ティア 2 (非Webアプリ) | 特定のポートや厚いクライアントが必要。専用クライアントを使用 | 1アプリあたり4〜8時間 |
| ティア 3 (レガシー基幹) | P2Pや双方向通信が必要。WANデプロイメントなどの補完が必要 | 1アプリあたり1〜3日 |
段階的な移行を実現する「3フェーズ」のロードマップ
レガシーハードウェアからの「脱出速度」を得るために、CDWとCloudflareは、一斉置換ではなく「共存」を優先する段階的なロールアウトを提案している。
戦略策定からパイロット導入までのステップ
第1フェーズでは、戦略チームと実装チームを分離して組織する。第2フェーズでは、少数の従業員グループ（パイロットグループ）に対してCloudflare Oneクライアントを導入する。ここで重要なのは、セキュリティ強化による「遅延（レイテンシ）」がユーザー体験を損なわないかを確認することだ。Cloudflareは世界中にエッジ拠点を持っているため、多くの場合はVPNよりも高速な接続が期待できるが、実環境での検証は欠かせない。
VPNとCloudflare Oneを併用する「デュアルクライアント」期間
第3フェーズの生産スケールでは、既存のVPNとCloudflare Accessを一時的に併用する「デュアルクライアント」期間を設ける。これにより、万が一新環境で問題が発生しても、すぐに旧環境へロールバックできる安全策を確保する。ユーザーは徐々に新しいアクセス手法に慣れていくことができ、IT部門のサポート負担も分散される。このアプローチは、日本の企業における慎重なシステム移行プロセスとも非常に相性が良いと言えるだろう。
パフォーマンスと将来性——セキュリティを高速化の武器にする
セキュリティを強化すると動作が重くなる、という考えはもはや過去のものだ。Cloudflareのシングルパス・アーキテクチャは、すべてのセキュリティチェックを同時に実行するため、効率的なデータ処理が可能だ。
シングルパス・アーキテクチャによる遅延の解消
従来のセキュリティ対策では、ファイアウォール、ウイルススキャン、DLP（データ漏洩防止）などの各装置をデータが順番に通過するため、その都度遅延が発生していた。Cloudflareのアーキテクチャでは、これらをクラウド上の1回のパスで処理する。Cloudflare One GTM責任者のAnnika Garbers氏は、この「接続クラウド」への移行が、セキュリティチームがボトルネックになるのを防ぎ、運用速度を劇的に向上させると述べている。
ポスト量子暗号への対応と将来の脅威への備え
さらに、このプラットフォームは将来の脅威にも備えている。量子コンピュータが実用化されると、現在の暗号技術の多くが突破されるリスクがある。Cloudflareは既に「ポスト量子暗号（PQC / Post-Quantum Cryptography）」に対応した基盤を構築しており、今移行することは、将来的な脅威に対する防御を先行して手に入れることを意味する。一度クラウドベースのSASEに移行してしまえば、こうした最新技術の恩恵を、ハードウェアの買い替えなしに受け続けられるのが大きなメリットだ。
この記事のポイント
- ビッグバン移行を避ける：一斉切り替えはリスクが高すぎるため、段階的な「共存」モデルを採用すべきだ。
- ラッピングで近代化：レガシーアプリのコードを直さず、Cloudflare AccessでMFAやSSOを追加できる。
- 徹底した事前監査：IDプロバイダーの確認とアプリのティア分けが、移行の成功率を左右する。
- パフォーマンスの向上：シングルパス・アーキテクチャにより、セキュリティ強化と高速化を両立できる。
- 将来への備え：クラウド型SASEなら、ポスト量子暗号などの最新機能を即座に利用可能だ。
出典
- Cloudflare Blog「From legacy architecture to Cloudflare One」（2026年3月13日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflareが「Custom Regions」発表。データ処理の地理的境界を自在に定義、ISMAP対応も拡充
Cloudflare（クラウドフレア）は2026年3月18日、同社の「Regional Services（リージョナル・サービス）」の大幅なアップデートを発表した。今回の更新では、特定の国や地域を自由に組み合わせてデータ処理の境界を定義できる「Custom Regions（カスタム・リージョン）」が導入された。
また、日本政府のセキュリティ評価制度である「ISMAP」への対応を含む、新しい管理リージョンの追加も行われている。これにより、企業はグローバルなDDoS防御の恩恵を受けつつ、各国の法規制やコンプライアンスに基づいた厳格なデータ局所化が可能になる。
データ主権（データ・ソブリンティ）への要求が世界的に高まる中、今回の機能拡張はインフラ構成の柔軟性を大きく向上させるものだ。記事によれば、従来の固定された地域選択から、個別のビジネスニーズに合わせた「独自の境界線」を引くフェーズへと移行したことが示唆されている。
Regional Servicesの仕組み：防御とコンプライアンスの両立
Cloudflareが提供するRegional Servicesは、グローバルネットワークの規模を活かしたセキュリティと、特定の地域内でのデータ処理という、一見相反する要素を両立させる仕組みだ。一般的なソブリンクラウド（主権クラウド）が特定の地域にインフラを隔離するのに対し、Cloudflareはネットワーク全体で攻撃を防ぎつつ、データの「中身」を扱う場所だけを限定する手法をとる。
グローバルなDDoS防御とローカル処理の共存
トラフィックの処理フローは、大きく4つの段階に分かれている。まず、ユーザーに最も近い世界各地のデータセンターでトラフィックを受け入れ、L3/L4（ネットワークおよびトランスポート層）レベルでのDDoS防御を即座に実行する。DDoS防御とは、大量の不要なデータを送りつけてサイトをダウンさせる攻撃を防ぐ仕組みであり、これを世界規模のネットワークで受けることで、攻撃を効率的に分散・無効化できる。
次に、パケットのメタデータを検査し、指定されたリージョン外のデータセンターに届いた場合は、Cloudflareのプライベートバックボーンを経由して指定リージョン内のデータセンターへと転送される。ここで重要なのは、この段階ではまだデータの復号（暗号化の解除）が行われていない点だ。
データの復号、つまりTLS（Transport Layer Security）の終端と、WAF（Web Application Firewall）によるL7（アプリケーション層）の検査、およびCloudflare Workersによるロジックの実行は、必ず指定されたリージョン内のデータセンターで行われる。これにより、機密性の高いデータの解析や処理を特定の地理的境界内に閉じ込めることが可能になる。最終的に、処理されたリクエストは再度暗号化され、オリジンサーバーへと送られる。
Custom Regionsによる柔軟なデータ制御
2020年の提供開始以来、Regional Servicesは欧州、英国、米国などの固定されたリージョンを提供してきた。しかし、各国の規制は複雑化しており、単一の国や特定の組み合わせでのデータ処理を求める声が強まっていた。これに応える形で登場したのがCustom Regionsだ。
独自の地理的境界を定義する「式」の活用
Custom Regionsでは、リストから地域を選ぶのではなく、開発者が「式（Expression）」を用いて処理場所を定義する。例えば、ISOコード（国コード）を使用して、特定の国を含める、あるいは除外するといった柔軟な設定が可能だ。記事では、以下のような定義例が示されている。
- 単一の国のみ（例：トルコのみ）
- 複数の国の組み合わせ（例：ドイツ、フランス、オランダ）
- 特定の国を除外（例：北米以外すべて）
この定義はCloudflareのインフラ全体に配布され、各データセンターが「自分はこのカスタムリージョンに含まれるか」を即座に判断する。インフラが拡張され、新しいデータセンターが稼働した場合も、条件に合致すれば自動的にリージョンに組み込まれるため、運用負荷が低いのも特徴だ。
実務における具体的な活用シナリオ
Custom Regionsの柔軟性は、法規制対応以外の場面でも威力を発揮する。著者のAndrew Berglund氏らは、早期アクセスユーザーによる活用例として、AI推論のリージョン化を挙げている。大規模言語モデル（LLM）へのプロンプトや応答を特定の国々に留めることで、パフォーマンスの最適化とデータ局所化の義務を同時に果たしているという。
また、政府機関との契約に基づいた特定の境界設定や、企業の組織構造（EMEA、APACなど）に合わせたガバナンスの適用にも利用されている。温度単位に華氏を使う国々（米国、バハマなど）といった、極めて特殊なグループ化さえも理論上は可能であり、ビジネス要件に合わせた「境界の設計」が可能になったと言える。
技術的アーキテクチャの深掘り
Custom Regionsがどのようにして最適なパフォーマンスと信頼性を維持しているのか、その裏側にはCloudflare独自のルーティング技術がある。単にデータを転送するだけでなく、リアルタイムのネットワーク品質を考慮した動的な決定が行われている。
最適なインレジョン・ルーティングの算出
リクエストがリージョン外のデータセンターに届いた際、どのリージョン内データセンターに転送すべきかの判断は、2段階のプロセスで行われる。まず、定義されたリージョンのメンバーセット（どのデータセンターが対象か）を特定する。次に、流入地点から見て最もパフォーマンスが高い転送先のリストを作成する。
このランキングは物理的な距離だけでなく、遅延（レイテンシ）、パケットロス、タイムアウトなどのネットワーク品質指標、さらには各拠点のキャパシティや負荷状況、稼働ステータスを基に算出される。この情報は「Quicksilver」と呼ばれるCloudflare独自の分散キーバリューストアを介して、エッジネットワーク全体に瞬時に共有される仕組みだ。
境界の強制とエラーハンドリング
Regional Servicesの設計思想において、レジリエンス（回復力）と境界の強制は最優先事項だ。ルーティング時には複数の候補地が考慮され、特定の拠点がダウンしている場合は、リアルタイムで次善の候補へとフェイルオーバー（切り替え）が行われる。ネットワークの監視データが不十分な場合は、新しいルーティング情報の更新を停止するなどの安全策も講じられている。
特筆すべきは「フェイル・クローズ（Fail-close）」設計だ。もし有効なリージョン内の転送先が一つも見つからない場合、リージョン外で処理を継続するのではなく、接続をエラーとして遮断する。これにより、意図しない場所でデータが復号されるリスクを物理的に排除している。
日本のISMAP対応と管理リージョンの拡大
今回のアップデートでは、Custom Regionsだけでなく、Cloudflareが定義・管理する「Managed Regions」も拡充された。新たにトルコ、アラブ首長国連邦（UAE）、オーストラリアのIRAP、そして日本のISMAPに対応したリージョンが追加され、合計で35のリージョンが利用可能となっている。
ISMAP（Information System Security Management and Assessment Program）とは、日本政府がクラウドサービスのセキュリティを評価するための制度だ。政府機関がクラウドを採用する際の基準となるものであり、民間企業にとっても信頼性の高いサービスの指標となっている。CloudflareがISMAP対応リージョンを明示したことは、日本の公共セクターや厳格なコンプライアンスを求める金融、インフラ企業にとって、導入の大きな後押しとなるだろう。
これらの管理リージョンは、Cloudflareの管理画面（ダッシュボード）やAPIから標準的な手順で有効化できる。一方で、独自の定義が必要なCustom Regionsについては、現時点ではセルフサービス形式ではなく、アカウントチームとの連携による個別設定が必要となる。将来的なセルフサービス化に向けた技術開発も継続されているとのことだ。
独自の分析：データ主権時代のインフラ戦略
Cloudflareの今回の発表は、エッジコンピューティングの役割が「高速化」から「統治（ガバナンス）」へと進化していることを象徴している。かつてのCDN（Content Delivery Network）は、いかにコンテンツを速く届けるかが主眼であったが、現代のWebインフラには「どこでデータを扱うか」という法的な正確性が求められている。
Custom Regionsが提供する「式による境界定義」は、コードによるインフラ管理（IaC）の流れを汲むものだ。地理的な境界をソフトウェア的に定義できるようになったことで、国境という物理的な制約を、アプリケーションのロジックと同じ柔軟さで扱えるようになった。これは、GDPR（欧州一般データ保護規則）などの地域特有の規制と、インターネットのボーダレスな利便性を橋渡しする重要な技術的解決策と言える。
特に日本市場においては、ISMAP対応の明文化が大きな意味を持つ。国内のレンタルサーバーやクラウドから、グローバルなエッジサービスへの移行を検討する際、最大の懸念事項であった「セキュリティ基準の適合」と「データの所在」がクリアされたからだ。今後は、グローバルなDDoS耐性を維持しつつ、日本の法域内で全ての重要処理を完結させる構成が、エンタープライズWebサイトの標準となっていくのではないだろうか。
この記事のポイント
- Cloudflareが「Custom Regions」を導入し、国単位でデータ処理の境界を自由に定義可能になった。
- 世界規模のDDoS防御を維持しつつ、TLS終端やWAF検査などのL7処理を指定地域内に限定できる。
- 日本政府のセキュリティ評価制度「ISMAP」に対応した管理リージョンが追加された。
- 独自のルーティング技術により、リージョン内での最適なパフォーマンスと、フェイル・クローズによる安全性を両立している。
- データ主権の確保とグローバルなセキュリティ対策を、一つのプラットフォームでシームレスに実現できる。
出典
- Cloudflare Blog「Introducing Custom Regions for precision data control」（2026年3月18日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Pingora OSSの脆弱性とリクエストスマグリング対策——Cloudflareが修正した3つの欠陥
Cloudflareは2026年3月9日、オープンソースのプロキシフレームワーク「Pingora（ピンゴラ）」に複数の脆弱性が存在することを公表した。対象となるのはPingoraをイングレスプロキシとして独自にデプロイしている環境だ。修正版となるPingora 0.8.0が同日にリリースされている。
発見された脆弱性は、HTTP/1.xにおける「リクエストスマグリング」に関連するものが中心だ。これはプロキシサーバーとバックエンドサーバーの間で、リクエストの終端解釈が食い違うことで発生する。最悪の場合、セキュリティ制御の回避や他ユーザーのセッション奪取につながる恐れがある。
Cloudflareの調査によれば、同社のCDNサービスや顧客トラフィックへの影響は確認されていない。Pingoraは同社ネットワーク内で広く利用されているが、インターネットからの直接的なトラフィックを受けるイングレスプロキシとしては使用されていないためだ。しかし、Pingoraを独自に公開サーバーとして運用しているユーザーは、速やかなアップデートが求められる。
Pingora OSSで発見された3つの脆弱性とリクエストスマグリングの脅威
今回のアップデートで修正されたのは、CVE-2026-2833、CVE-2026-2835、CVE-2026-2836の3件だ。これらはいずれも、HTTP/1.xの通信においてリクエストの境界を誤認させる「リクエストスマグリング（Request Smuggling）」を可能にする欠陥である。
リクエストスマグリングとは何か
リクエストスマグリングとは、1つのTCP接続の中で複数のHTTPリクエストを送る際、サーバー間で「どこまでが1つ目のリクエストか」の認識がズレる攻撃手法だ。例えるなら、レストランの注文票で「ハンバーグ1つ。あと、隣のテーブルの会計を私につけて」と巧妙に書き込み、店員に2つの指示を1つとして誤認させるような行為に近い。
プロキシサーバーが「これは1つのリクエストだ」と判断して通したデータの中に、バックエンドサーバーだけが「これは2つ目のリクエストだ」と解釈するデータが含まれている場合に発生する。これにより、プロキシ側のセキュリティチェックを素通りした不正なリクエストが、バックエンドで実行されてしまう。
独自展開のPingoraに潜むリスク
PingoraはRustで書かれた高速なプロキシフレームワークであり、Nginxの代替として注目されている。しかし、今回の脆弱性は、Pingoraをインターネットの窓口（イングレスプロキシ）として直接配置している場合に牙をむく。
攻撃が成功すると、攻撃者はPingoraのアクセス制御（ACL）を回避したり、共有バックエンドから取得したキャッシュを汚染したりすることが可能になる。また、他人の通信に自分のリクエストを割り込ませる「デシンク（非同期）攻撃」により、他ユーザーの認証情報を盗み出すリスクも指摘されている。
脆弱性1：101レスポンスを待たない不適切なプロトコル移行
1つ目の脆弱性（CVE-2026-2833）は、HTTPの「Upgrade」ヘッダーの処理に関するものだ。通常、WebSocketなどのプロトコルに切り替える際、クライアントはUpgradeヘッダーを送信し、サーバーが「101 Switching Protocols」を返した時点で切り替えが完了する。
Upgradeヘッダーの誤用によるバイパス
修正前のPingoraは、バックエンドからの「101」レスポンスを確認する前に、後続のデータを「アップグレード後のストリーム」としてそのまま流し込む（パススルーする）挙動を示していた。
GET / HTTP/1.1
Host: example.com
Upgrade: foo
GET /admin HTTP/1.1
Host: example.comこのコードのように、Upgradeリクエストの直後に別のリクエストを連結して送信すると、Pingoraは最初の部分だけを解析し、残りを「アップグレードされた通信」と見なしてバックエンドに丸投げする。たとえバックエンドがアップグレードを拒否して「200 OK」を返したとしても、Pingoraはすでに通信を素通しするモードに入ってしまっている。
バックエンドとの同期ずれ（Desync）の仕組み
この挙動により、プロキシとバックエンドの間で「Desync（デシンク / 同期ずれ）」が発生する。プロキシは1つの通信だと思っているが、バックエンドは「拒否したはずのアップグレードの後に、なぜか別のGETリクエストが届いた」と認識する。
結果として、プロキシ側のWebアプリケーションファイアウォール（WAF）や認証チェックを一切受けずに、`/admin` などの機密性の高いパスへのアクセスがバックエンドに到達してしまう。これは、検問を「工事車両です」と偽って通過し、ゲートが開いた瞬間に後ろに隠していた別の車を侵入させるような手口だ。
脆弱性2：HTTP/1.0とTransfer-Encodingの不適切な解釈
2つ目の脆弱性（CVE-2026-2835）は、古い規格であるHTTP/1.0のリクエストに「Transfer-Encoding: chunked」が含まれていた場合の処理に起因する。HTTP/1.0は本来、チャンク形式の転送をサポートしていない。
リクエストボディの終端判定ミス
Pingoraの従来のロジックでは、HTTP/1.0リクエストにTransfer-Encodingが含まれている場合、ボディの終端を「コネクションの切断（close-delimited）」で判断していた。しかし、最新のRFC（仕様書）では、リクエストボディにおいてコネクション切断を終端判定に使うことは明確に禁止されている。
攻撃者が以下のようなリクエストを送信した場合、問題が顕在化する。
GET / HTTP/1.0
Host: example.com
Connection: keep-alive
Transfer-Encoding: chunked
Content-Length: 29
0
GET /admin HTTP/1.1
X:Pingoraはこれを「1つの長いボディを持つリクエスト」と誤認するが、バックエンド（Node.jsやuvicornなど）は「チャンク形式の終わり（0）」でリクエストが終了したと判断する。その結果、後ろに続く `/admin` へのリクエストが、次にそのコネクションを利用する別ユーザーのリクエストとして処理されてしまう。
RFC準拠の厳格化による修正
Cloudflareはこの問題に対し、PingoraのHTTP解析ロジックを大幅に強化した。具体的には、HTTP/1.0とTransfer-Encodingの組み合わせを拒否し、無効なContent-Lengthを持つリクエストも遮断するように変更されている。
RFC（Request for Comments）とはインターネット技術の標準仕様書であり、これに厳格に従うことがセキュリティの基本となる。Pingoraはこれまで、レガシーなシステムとの互換性のために一部の仕様を緩く解釈していたが、今回の修正で「安全な厳格さ」へと舵を切った形だ。
脆弱性3：デフォルトCacheKeyによるキャッシュ汚染のリスク
3つ目の脆弱性（CVE-2026-2836）は、Pingoraのアルファ版機能である「プロキシキャッシュ」のデフォルト設定に関するものだ。キャッシュの識別子となる「CacheKey（キャッシュキー）」の生成ロジックが不十分であった。
URIパスのみに依存するキャッシュキーの危険性
修正前のデフォルト実装では、キャッシュキーの生成に「URIパス」のみを使用していた。ここにはホスト名（Hostヘッダー）や通信プロトコル（HTTPかHTTPSか）が含まれていなかった。
これにより、例えば `site-a.com/index.html` と `site-b.com/index.html` が、同じキャッシュとして扱われてしまう。攻撃者が自分の管理するドメインで不正なコンテンツをキャッシュさせれば、同じサーバーを共有する全く別ドメインの利用者にその不正コンテンツを表示させることが可能になる。
現在、Pingoraはこの「不完全なデフォルト設定」自体を削除している。利用者は自身のアプリケーションの特性に合わせ、ホスト名やスキームを含めた適切なキャッシュキーを明示的に設計する必要がある。
独自の分析：Rust製プロキシにおけるRFC準拠と「寛容さ」のトレードオフ
今回の脆弱性公表は、Rustというメモリ安全な言語で開発されていても、プロトコルの解釈という論理的なレイヤーでの脆弱性は避けられないことを改めて示した。PingoraはCloudflareが数千台のサーバーで運用する実績あるコードだが、それでもなお、リクエストスマグリングのような古典的な攻撃手法が有効な隙間が存在していた。
モダンなスタックでも避けられないHTTPの複雑性
HTTP/1.1は1990年代から続く仕様であり、長年の拡張によって解釈の余地が非常に多い。プロキシ開発者は「どんなに壊れたリクエストでも、可能な限りバックエンドに届ける」という「寛容さ」と、「不正なリクエストを厳格に弾く」という「安全性」の板挟みにあう。
今回の事例では、Pingoraがレガシーなクライアントをサポートするために持たせていた「解釈の柔軟性」が、攻撃者に悪用される結果となった。Cloudflareのような巨大なインフラを支える技術であっても、OSSとして一般公開され、多様な環境（イングレスプロキシとしての利用など）に置かれることで、新たなリスクが浮き彫りになる点は興味深い。
今後のプロキシ開発においては、Rustによるメモリ安全性だけでなく、仕様（RFC）への「形式的な厳格さ」をいかに自動テストや静的解析で担保するかが、次なるセキュリティの焦点となるだろう。
この記事のポイント
- Pingora 0.8.0がリリースされ、3つのリクエストスマグリング脆弱性が修正された。
- 脆弱性は、不適切なUpgrade処理、HTTP/1.0の誤認、不十分なキャッシュキー生成に起因する。
- CloudflareのCDNサービス自体には影響がなく、独自にPingoraを構築しているユーザーが対象となる。
- 攻撃を受けると、セキュリティ制御のバイパスや他ユーザーのセッション奪取の恐れがある。
- Pingoraを運用しているエンジニアは、速やかに最新版へのアップグレードを推奨する。
出典
- Cloudflare Blog「Fixing request smuggling vulnerabilities in Pingora OSS deployments」（2026年3月9日）
- GitHub「cloudflare/pingora Release v0.8.0」（2026年3月2日）
- CVE MITRE「CVE-2026-2833 / CVE-2026-2835 / CVE-2026-2836」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WAFの「ログかブロックか」を卒業。Cloudflareが提唱するAttack Signature Detectionの革新性
WAF（Web Application Firewall / ウェブ・アプリケーション・ファイアウォール）の運用において、セキュリティ担当者を長年悩ませてきた「ログモードかブロックモードか」という二者択一に、終止符が打たれようとしている。
Cloudflareが発表した「Attack Signature Detection（アタック・シグネチャ・デテクション）」は、検知と遮断のアクションを分離することで、防御性能を維持しながらトラフィックの完全な可視化を実現する技術だ。
この新機能は、従来のWAFが抱えていた「遮断を優先すると、他の攻撃シグネチャがどう反応したかのデータが失われる」という構造的な欠陥を解消する。
WAFの課題「検知か遮断か」のジレンマを解消する新アプローチ
従来のWAF運用では、新しいアプリケーションを公開する際、まず「ログ専用モード」で数週間稼働させることが一般的だった。
これは、WAFが正規の通信を誤って攻撃と判断してしまう「誤検知（False Positive）」を防ぐための調整期間だ。
ログモードとブロックモードの壁
ログモードでは攻撃を防げず、ブロックモードでは誤検知によってビジネス機会を損失するリスクがある。
さらに深刻なのは、ブロックモードで特定のルールがリクエストを遮断した場合、その時点で処理が終了してしまう点だ。
これにより、他のシグネチャ（攻撃のパターンを定義した識別子）がそのリクエストをどう評価したかという貴重なインサイトが得られなくなる。
多角的な防御策を講じる上で、この「可視性の欠如」は防御の最適化を妨げる大きな要因となっていた。
検知とアクションを分離する「常時稼働」モデル
Attack Signature Detectionは、このトレードオフを「検知の常時稼働」という概念で解決する。
リクエストが届いた際、まず全ての検知シグネチャを走らせてリッチなメタデータを付与し、その後に実際の遮断アクションを行うかどうかを判定する仕組みだ。
これにより、たとえリクエストをブロックしたとしても、背後でどのシグネチャが反応していたかを全て記録に残すことが可能になる。
Attack Signature Detection：常時稼働する高精度な検知エンジン
Attack Signature Detectionは、Cloudflareのマネージドルールセットと同じ高度なヒューリスティック（経験則に基づいた分析手法）を利用している。
SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）といった代表的な攻撃から、最新のCVE（Common Vulnerabilities and Exposures / 共通脆弱性識別子）まで、700以上のルールがリアルタイムで適用される。
信頼度（Confidence）による分類
各シグネチャには「カテゴリー」と「信頼度」というタグが付与されている。
信頼度は、そのシグネチャが正規の通信を誤検知する可能性の低さを示す指標だ。
- High（高信頼度）: 誤検知が極めて少なく、即座にブロックモードでの運用が推奨される。
- Medium（中信頼度）: トラフィックの特性によっては誤検知の可能性があるため、事前の分析が推奨される。
運用者はこれらの指標を基に、「信頼度が高いシグネチャに一致した時だけブロックする」といった柔軟なポリシーをノーコードで作成できる。
パフォーマンスへの影響を最小限に抑える設計
「全てのシグネチャを常時稼働させると、通信速度が低下するのではないか」という懸念が生じるのは自然なことだ。
しかし、このフレームワークは効率性を極限まで高めている。
特定の検知に基づいた遮断ルールが設定されていない場合、検知処理はリクエストがオリジンサーバー（Webサイトの本体が稼働しているサーバー）へ送信された「後」に実行される。
この非同期処理により、検知そのものがユーザーの体感速度に影響を与えることはない。
Full-Transaction Detection：レスポンスまで見通す次世代の防御
Attack Signature Detectionのさらに先を行く進化として開発されているのが、「Full-Transaction Detection（フル・トランザクション・デテクション）」だ。
従来のWAFは、ユーザーからの「リクエスト（問いかけ）」の内容だけを見て攻撃を判断していた。
しかし、Full-Transaction Detectionは、サーバーからの「レスポンス（回答）」も含めた一連のやり取り（トランザクション）を分析対象とする。
「攻撃の成否」を判断する重要性
例えば、URLの末尾にSQLインジェクションのコードが含まれていたとする。
リクエストだけを見れば攻撃だが、サーバーが「500 Internal Server Error」や「404 Not Found」を返していれば、その攻撃は失敗したと判断できる。
一方で、サーバーが「200 OK」を返し、かつレスポンスボディにユーザーのパスワード一覧のような機密データが含まれていた場合、それは「攻撃が成功した」ことを意味する。
このように、レスポンスを相関分析することで、誤検知を劇的に減らし、真に危険なイベントだけを抽出することが可能になる。
データ漏洩と設定ミスの検知
この技術は、外部からの攻撃だけでなく、内部の設定ミスや意図しないデータ露出の検知にも威力を発揮する。
例えば、管理者が誤って公開設定にしてしまったElasticsearch（検索エンジン）のインターフェースや、Apacheの機密エンドポイントへのアクセスを検知できる。
また、正規のAPIリクエストであっても、レスポンスに数千件のクレジットカード番号が含まれているような異常な事態（データエクスフィルトレーション / データ持ち出し）を即座に特定できる点は、従来のWAFにはない強みだ。
セキュリティ運用を劇的に変える分析とルールのカスタマイズ
Attack Signature Detectionがもたらす最大の価値は、セキュリティ運用の「データ駆動型」への転換だ。
Security Analytics（セキュリティ・アナリティクス）のダッシュボードを活用することで、専門家でなくても自社サイトがどのような攻撃にさらされているかを詳細に把握できる。
Security Analyticsによる可視化
ダッシュボードでは、どのCVEを狙った攻撃が多いか、どのエンドポイント（URL）が標的になっているかがグラフ化される。
例えば、特定のAPIパス（`/api/v1/`など）に対して執拗に攻撃を繰り返しているIPアドレスを特定し、その場で遮断ルールを作成するといったアクションがスムーズに行える。
また、過去のトラフィックデータに対して「もしこのルールを適用していたらどうなっていたか」というシミュレーションを行うことも可能だ。
柔軟なルールエンジンの活用
検知されたメタデータは、Cloudflareの「Edge Rules Engine」で自由に利用できる。
「信頼度がMediumのシグネチャに一致した場合は、即座にブロックせず、Managed Challenge（人間であることを確認する認証画面）を表示する」といった、ユーザー体験を損なわない防御策も容易に実装できる。
こうした「多層防御」の構築が、複雑なスクリプトを書くことなくGUI上で行える点は、リソースの限られた中小企業のWeb担当者にとっても大きなメリットとなるだろう。
独自の分析：Web制作現場におけるWAF運用のパラダイムシフト
これまでのWeb制作や保守運用の現場では、WAFは「導入して終わり」か、あるいは「誤検知が怖いからオフにする」という極端な運用に陥りがちだった。
しかし、Attack Signature Detectionの登場により、WAFは「静的な壁」から「動的なセンサー」へと進化したと捉えるべきだ。
筆者の分析では、この技術が普及することで、以下の3つの変化が起こると予測している。
第一に、WAF導入の心理的ハードルが下がる。
「とりあえず検知だけさせてデータを貯める」というスモールスタートが、パフォーマンスへの影響なしに可能になるからだ。
第二に、インシデント対応の迅速化だ。
リクエストとレスポンスの両面から攻撃の成否が可視化されるため、ログを数時間かけて解析しなくても、どの脆弱性が突かれたのかが瞬時に判明する。
第三に、開発とセキュリティの融合（DevSecOps）が加速する。
開発者はWAFの検知データをフィードバックとして受け取り、コードレベルでの修正が必要なのか、WAFでの対応で十分なのかをデータに基づいて判断できるようになる。
もはやセキュリティは、開発の足を引っ張る存在ではなく、安全なリリースを支える強力なインフラへと変貌を遂げている。
この記事のポイント
- WAFの課題だった「検知（ログ）か遮断（ブロック）か」の選択を、機能を分離することで解消した。
- Attack Signature Detectionは常時稼働し、リクエストに詳細なメタデータを付与して可視性を高める。
- Full-Transaction Detectionにより、レスポンスまで分析して攻撃の成功・失敗を正確に判別できる。
- 非同期処理の導入により、高度な検知を行いながらもユーザーの通信速度に影響を与えない設計を実現した。
- 専門知識がなくても、信頼度に基づいた柔軟なセキュリティポリシーの運用が可能になった。
出典
- Cloudflare Blog「Always-on detections: eliminating the WAF “log versus block” trade-off」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
エンドポイントからAIプロンプトまで——Cloudflare Oneが描く統合データセキュリティの現在地
企業のセキュリティ対策は、ネットワークの境界防御からデータそのものの保護へと重心が移っている。機密データが存在する場所、アクセスする人物、不正な移動経路を可視化し制御することが、現代のセキュリティプログラムの核心的な課題だ。
Cloudflareは2026年3月6日、同社のSASE（Secure Access Service Edge）プラットフォーム「Cloudflare One」におけるデータセキュリティの統合ビジョンを発表した。このビジョンは、データが移動するあらゆる経路——転送中、保存時、利用時、さらにはAIプロンプトへの入力時までを単一のモデルで追跡することを目指す。従来のサイロ化した制御ではなく、データの流れに沿ってポリシーを適用するアプローチである。
今回の発表では、ブラウザベースのリモートデスクトッププロトコル（RDP）におけるクリップボード制御、SaaSアプリ内操作の詳細なログ記録、エンドポイントでのデータ損失防止（DLP）、Microsoft 365 Copilot向けのAIセキュリティスキャンなど、複数の新機能が公開された。これらの更新は、データがツールや製品の境界を越えて高速に移動する現代の環境において、セキュリティポリシーがデータそのものに追随する必要性を具現化するものだ。
データ移動の最終関門——ブラウザRDPのクリップボード制御
クラウド環境や外部協力者との作業が一般化する中、ブラウザを通じたリモートアクセスは一般的なワークフローとなった。Cloudflare OneのブラウザベースRDP機能は、管理されていない端末やクライアントソフトがインストールされていない環境からのアクセスを可能にする。しかし、ブラウザ内で完全なRDP体験を提供する際、データがどこへ移動できるか、特にクリップボードを介した移動をどの程度細かく制御できるかが課題となる。
生産性とセキュリティのトレードオフを解消する
クリップボード制限は、生産性とセキュリティのバランスを象徴する問題だ。ユーザーがコピー＆ペーストできないと、スクリーンショットの撮影、データの手打ち、管理外ツールへの作業移行など、制御を迂回する方法を探し始める。完全なブロックは実用的ではない。
Cloudflare Oneが追加した新機能は、このジレンマを解消する。セキュリティ管理者は、ローカルデバイスとブラウザ内RDPセッション間のコピー・ペーストを、方向性と文脈に応じて細かく制御できるようになった。例えば、顧客情報を含むサポートポータルにアクセスするセッションでは、作業効率化のためにセッション内へのペーストは許可しつつ、機密データが管理外の端末に流出するのを防ぐためにセッション外へのコピーはブロックする、といった設定が可能だ。
具体的な適用シナリオと設定
この機能は、Cloudflare Oneのダッシュボード内、ブラウザベースRDPアプリケーション用のアクセスアプリケーションポリシーに新設された設定項目から構成できる。ポリシーは「双方向許可」「ローカルからリモートのみ許可」「リモートからローカルのみ許可」「すべて禁止」の4つのプリセットから選択する。これにより、契約者やパートナー企業からのアクセスなど、端末管理が行き届かないシナリオでも、データの意図しない持ち出しリスクを低減できる。
従来のVPNや専用RDPクライアントに比べ、ブラウザベースのアクセスは導入ハードルが低い。Cloudflare Oneはこの利便性を維持しつつ、セッション境界でのデータ制御という追加の防御層を提供する。このアプローチは、ゼロトラストセキュリティの原則——「決して信用せず、常に検証せよ」——をリモートアクセス領域に具体化した一例と言える。
可視性の深化——操作マッピングによるログの強化
適切な制御を設計するには、ユーザーがSaaSアプリ内で実際にどのような操作を行っているかを理解する必要がある。しかし、生のHTTPログや監査ログだけでは、個々のリクエストがビジネス上のどのアクションに対応するのか、解釈が困難な場合が多い。
「操作」としてのログ解釈
Cloudflareは「操作マッピング」と呼ばれるプロセスを用いてこの課題に対処する。このプロセスは、HTTPリクエストの様々な要素（パス、メソッド、パラメータなど）を解釈し、それを単一のビジネス操作（例：ChatGPTにおける「SendPrompt」）に変換する。さらに、類似のアクションを行う複数の操作を「アプリケーションコントロール」（例：「共有」や「アップロード」）というグループにまとめる。これまで、このマッピングはポリシー作成の簡素化に主に活用されてきた。
ログ分析とフォレンジックの高速化
今回の更新で、この操作マッピングがログイベントにも適用されるようになった。追加設定なしに、Cloudflare Oneの操作マップと互換性のあるSaaSアプリケーションのトラフィックについて、ログ詳細に「アプリケーションコントロール」と「特定の操作」の両方が表示される。
調査担当者は、生のURLやメソッドを解読する代わりに、「ユーザーがSalesforceでレコードをエクスポートした」や「Google Driveでファイルを共有した」といった直感的な情報を即座に把握できる。これにより、インシデント調査やポリシーチューニングにかかる時間が短縮され、ユーザー体験を不必要に損なうことなく、リスクの高い行動を特定しやすくなる。
この機能は、単なるログの装飾ではない。セキュリティ運用における根本的な課題——「何が起こっているのかを文脈を持って理解する」——を解決する。可視性が向上すれば、防御策は事後対応から事前予防へとシフトできる余地が生まれる。
エンドポイントでの最終防御——Cloudflare One ClientによるDLP
管理されたSaaSアプリケーションから、クリップボードを経由して管理外のコンテキストに機密情報が移動するリスクは日常的に存在する。リスクはファイルの組織外流出だけではない。独自コードの断片や顧客レコードが、許可されていない大規模言語モデル（LLM）や個人用ツールに貼り付けられる可能性もある。
転送中・保存時から利用時への保護拡張
Cloudflare Oneは既に、ゲートウェイとDLPによる転送中のデータ保護、CASB（Cloud Access Security Broker）とAPI連携による保存時の可視性と制御を提供している。今回、エンドポイントDLPの適用範囲を「利用時」のデータに拡大する。その第一歩として、Cloudflare One Client（旧WARPクライアント）にクリップボードの移動といったハイシグナルのワークフローに対するDLP適用機能が追加された。
これにより、保護されたSaaSアプリからコピーされた機密データが、OSのクリップボードに到達した瞬間に「ポリシーの適用外」のコンテンツになることを防ぐ。組織は、別のエージェントを導入したり複雑な連携を構築したりすることなく、ユーザーの手元までデータ保護を拡張できる。
エージェント統合の利点と「エンドポイントからプロンプトまで」の問題
既にCloudflare One Clientをゼロトラストネットワークアクセスに利用している組織にとって、エンドポイントDLPは自然な機能拡張である。単一の軽量エージェントが、ネットワークセキュリティとデータセキュリティの両方の役割を担う。これが「エンドポイントからプロンプトまで」の問題を解決する鍵となる。機密データがローカルでコピーできるなら、それはAIアシスタントに同じくらい簡単に貼り付けられる。利用時のデータを保護することで、この連鎖の最初の一歩を封じる。
このアプローチは、データセキュリティを単なる「チェックボックスを満たす活動」から、「実際のデータフローに沿った継続的な適用」へと進化させる。エンドポイントは、データがデジタル世界から物理世界（例えば、スクリーンショットや印刷）へと移行する可能性のある最後の関門の一つだ。ここでの制御は、防御層を実質的に強化する。
AI時代の可視性——M365 Copilot向けAPI CASBスキャン
AIアシスタントの業務利用が拡大するにつれ、新しいブラインドスポットが生じている。従業員がMicrosoft 365 Copilotなどのツールに機密データを入力しても、従来のDLPやCASBではそのやり取りを検知できない場合があった。AIとの対話は、新しいデータ移動経路を生み出した。
AIプロンプトとアップロードのスキャン
Cloudflare OneのAPI CASBは、SaaSアプリをAPI経由でスキャンし、一般的かつリスクの高いセキュリティ問題を検出する。今回、この機能がMicrosoft 365 Copilotのアクティビティ分析に対応した。具体的には、DLP検出プロファイルに一致するチャット内容やアップロードファイルをスキャン対象とする。
検出された結果は、ファイル参照、プロファイル一致内容、対話メタデータなどの豊富な文脈情報と共に表示される。これにより、セキュリティチームは生の監査ログから手作業で情報を抽出する代わりに、迅速にトリアージを行える。
設定と今後の展開
M365 Copilotの検出機能は、既存のMicrosoft 365連携の一部としてデフォルトで利用可能となる。既に連携を設定しているユーザーは、Cloudflare Oneダッシュボードの「統合」セクションでMicrosoft 365接続を更新するだけでCopilotの検出を開始できる。新規ユーザーは、テナントを接続することでCopilotの使用状況と関連するデータセキュリティ上の発見を可視化できる。
Cloudflareは、AI製品の拡散が続く中、2026年を通じて他のAIアシスタントや主要SaaSプラットフォームへの対応を大幅に拡大する計画を示している。これは、データセキュリティの適用範囲を、単なる従来型のアプリケーションから、AIという新しいインターフェースへと積極的に拡張する姿勢を示すものだ。
統合データセキュリティの未来像
過去数年間、企業セキュリティはSaaS、管理外エンドポイント、リモートアクセスパターン、そして現在はAIアシスタントへと適用範囲を広げてきた。しかし、その目的——機密データの保護——は変わらない。今回発表された一連の更新は、転送中、保存時、利用時、プロンプト時における一貫した可視性と適用を実現するという単一の方向性を反映している。ポリシーが製品の境界ではなく、データそのものに追随する世界だ。
Cloudflareのビジョンは、「データセキュリティ製品内のデータセキュリティ機能」という枠を超えている。同社は、時間の経過とともに、あらゆるCloudflare One製品がデータセキュリティをより意識したものになり、データ指向の設定可能性、可視性、制御、ガードレールが、アクセス、ゲートウェイ、エンドポイント適用、SaaS連携といった既存のワークフローに直接組み込まれると述べている。
目標は明確だ。ユーザーがどこで作業し、データがどこに移動しようとも、Cloudflare Oneは何が起こっているかを説明し、それを制御する手助けができるべきである。モダンペリメーターがアプリケーション、ブラウザ、エンドポイント、AIプロンプトにまたがって広がる中、点のソリューションを継ぎ接ぎすることは、運用を困難にし、回避を容易にする。Cloudflare Oneにデータセキュリティを直接構築し、これらのレイヤーを統合し続けることで、同社は企業がエンドポイントからプロンプトまでのデータリスクとデータセキュリティ体制を、より明確かつ完全に把握することを支援しようとしている。
この記事のポイント
- Cloudflare Oneは、データの移動経路（転送中、保存時、利用時、AIプロンプト時）を単一モデルで追跡・保護する統合ビジョンを発表した。
- ブラウザベースRDPにクリップボードの方向制御機能を追加。生産性を維持しつつ、セッション境界でのデータ流出を防止する。
- 操作マッピングをログに適用し、SaaSアプリ内のユーザー行動を「ビジネス操作」として可視化。調査とポリシーチューニングを高速化する。
- Cloudflare One ClientにエンドポイントDLPを導入。クリップボードを介したデータの管理外ツールへの移動を阻止する。
- API CASBがMicrosoft 365 Copilotのスキャンに対応。AIプロンプトやアップロードファイルに含まれる機密データを検出する。
出典
- Cloudflare Blog “From the endpoint to the prompt: a unified data security vision in Cloudflare One” (2026年3月6日)
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験