Cloudflare を日本のエンタープライズで採るならどこから入るか — JCB、JAL、三菱ガス化学事例と ISMAP 登録後の現在地
Cloudflare の日本市場での立ち位置が、ここ 2 〜 3 年で明確に変わってきています。2020 年 7 月の東京オフィス開設・初代日本法人代表の任命以降、JAL や JCB、DeNA、Sansan、Money Forward、三菱ガス化学、鴻池運輸、ライオン、GMO、ZIPAIR、BASE のような企業が、CDN / WAF にとどまらず Zero Trust、メールセキュリティ、Workers / R2 にまで採用領域を広げてきました。2025 年 12 月 22 日付の ISMAP 登録(2026 年 1 月 15 日に発表)で、公共・金融セクターの選択肢としても具体性が出てきました。
本記事は、こうした公開事例を横断的に整理して、「自社で Cloudflare を採るならどの入口から入るのが効くか」「ISMAP 登録後に何が変わったか」「採用前にどんなリスクを織り込むべきか」をまとめるものです。情報源は主に Cloudflare の公式導入事例、各企業の公式発信、および日本市場に関する独立リサーチレポートを参考にしています。
どの入口から始めるかで、導入後の世界がだいぶ変わる
公開事例を眺めると、Cloudflare の日本エンタープライズ導入は概ね 4 つの入口パターンに分類できます。
- Zero Trust と VPN 置換(DeNA、三菱ガス化学、クラスメソッド)
- メールセキュリティ(JAL、鴻池運輸)
- WAF と Bot Management、CDN 統合(Money Forward、Sansan、ZIPAIR、JCB、ライオン、Sony Music Group、GMO)
- Workers / R2 と開発者プラットフォーム(BASE、ユニークビジョン、Soracom、GMO)
それぞれで「どんな課題に効くか」「どこまで広げると ROI が出るか」が違うので、自社の課題が今どこに偏っているかでまず入口を選ぶことになります。
flowchart LR
A[自社の課題] --> B{どこに偏っているか}
B -->|VPN 障害、ハイブリッドワーク| C[入口 1: Zero Trust]
B -->|フィッシング、なりすまし| D[入口 2: Email Security]
B -->|Web 攻撃、Bot、CDN コスト| E[入口 3: WAF / Bot / CDN]
B -->|エッジ実行、S3 エグレス、マルチテナント| F[入口 4: Workers / R2]
C --> G[Cloudflare One 共通制御プレーンへ]
D --> G
E --> G
F --> G
入口 1: Zero Trust と VPN 置換 — DeNA、三菱ガス化学、クラスメソッド
最も即効性が高く、定量的な ROI が出やすいのが Zero Trust 経由の VPN 置換です。
DeNA は 2023 年に VPN 接続障害が深刻化し、ヘルスケアやゲームの社内リソースに業務時間中アクセスできない事態が頻発していました。Cloudflare Access と WARP で VPN を段階的に置換し、SASE 基盤上で Device Posture Management と URL Filtering を組み合わせた結果、VPN 関連障害の平均復旧時間を 82% 短縮、月 400 時間超の生産性ロスを回収 したと報告されています。
三菱ガス化学 は本社が Netskope、グループ会社が Zscaler という別ベンダー運用で、コストと運用の複雑性が肥大化していました。さらに、グローバル Egress IP を発行できないプロバイダ構成だったため、IP 制限のある SaaS や社内サーバーにリモートからアクセスするには「無保護の自宅回線」「セキュリティを一時オフ」「出社する」のいずれかを強いられる、という構造的な不便がありました。Cloudflare One への移行で、PoC から 7 ヶ月で本社とグループ会社の統合が完了、リモート接続コストを 75% 削減、月最大 40 時間の経路調査作業を解消 という結果になっています。Dedicated Egress IPs と DEX による可視化が、移行成立の前提として効いています。
クラスメソッド は 2021 年後半、リモートワーク化を契機に Cloudflare Zero Trust を導入。Microsoft Entra ID(旧 Azure AD)連携による ZTNA と DNS Filtering を同一ダッシュボードで実現し、MDM 配布の単一クライアントでアプリアクセスとインターネット保護を統合しました。週 3,700 万件のインターネットリクエストのうち約 4,000 件を危険サイトとしてブロック、韓国オフィス新設時にもネットワークアクセスを早期に用意できたと報告されています。
ここでの教訓をまとめると、Zero Trust の ROI は「セキュリティ強化」よりも「ユーザー / 運用エンジニアの工数削減」で説明したほうが、社内の意思決定が動きやすい、という構造になっています。VPN サポートチケットの月間件数、リモート接続の平均レイテンシ、グローバル Egress IP の有無あたりが、社内に持ち込みやすい KPI です。
入口 2: メールセキュリティ — JAL と鴻池運輸
メールセキュリティはもう 1 つの「成果が分かりやすい入口」です。
日本航空(JAL) は 35,000 人超の従業員を抱える社会インフラ事業者として、メール製品の変更タイミングで Cloudflare Email Security を採用しました。6 ヶ月で約 22,000 通の悪意あるメール(クレデンシャル収集、ブランドなりすまし、フィッシング)をブロック したと報告されています。以前は、不審メールのダイジェストが定期配信されてユーザー側が個別に判別する運用だったところを、自動検出の精度向上によって「ユーザーは迷惑メールフォルダを確認するだけ」のシンプルな運用に切り替えた点も重要です。
鴻池運輸 は連結 24,000 人、海外 33 拠点を抱える物流企業。Emotet や BEC 攻撃の頻発と、海外子会社横断の多言語運用(タイ語、中国語、スペイン語、タガログ語ほか)が課題でした。Cloudflare Cloud Email Security で月 8 万件程度の悪性メールをブロック、メール関連の問い合わせを月 30 件超から 1 件以下に減少(97% 減) したとされています。
「グループ単一テナント → ドメイン単位マルチテナント」へ段階移行し、子会社ごとに独立した管理コンソールを持ちつつ中央のメール基盤を共有するモデルが、グローバル展開している製造・物流業のメール統合パターンとして参考になります。
入口 3: WAF と Bot Management、CDN 統合 — Money Forward、Sansan、ZIPAIR、JCB、ライオン
Web / API 防御からの入口は、エンタープライズ事例で最も母数が多いカテゴリです。共通点は「単体 WAF や単体 CDN を入れる」のではなく、Cloudflare を全社共通のセキュリティ / 配信プレーンとして使う設計 になっている点です。
Money Forward は法人サービス有料顧客 34 万超、Money Forward ME のユーザー基盤 1,600 万超のフィンテック / SaaS。月初・月末のトランザクション急増時に既存 WAF が破綻気味で、ドメインと TLS 証明書の管理負荷も課題でした。Cloudflare WAF と Advanced Certificate Manager、API / Terraform Provider、Transform Rules を組み合わせて IaC で運用し、月 336 万件のファイアウォールイベントを自動検知・軽減 しています。三井物産セキュアディレクション(MBSD) の SOC チームが独自カスタムルールで補完する、日本らしい「マネージド型運用」モデルである点もポイントです。
Sansan は「Sansan」「Eight」「Bill One」「Contract One」など複数 SaaS を抱え、従来は各サービス部門が個別に WAF を契約してコスト構造もバラバラでした。VM、コンテナ、サーバレスが混在するマルチクラウド全体に Cloudflare WAF を全社展開した結果、主要サービスを 6 ヶ月で移行、月 4,520 万件の攻撃を検知、総運用コストを約 90% 削減。Bot Management の JA3 / JA4 フィンガープリントで全トラフィックの約 10% が Bot 由来であることを可視化し、Logpush で複数部門のログを SIEM に統合しています。
ZIPAIR Tokyo(JAL 完全子会社の中長距離 LCC)は予約サイトのスクレイピングや不正予約が深刻化し、一部フライトで Bot がトラフィックの最大 90% を占めるという凄まじい状態でした。Akamai からの比較 PoC を経て Cloudflare に切替後、予約ページの約 70% をエッジ配信、転送量を約 35% 削減、Bot 検知・遮断を Akamai 比で 26% 向上、応答時間を約 20% 改善 という、ビジネス影響の大きい数字が公開されています。
JCB は会員 1.4 億人、加盟店 3,900 万店規模で、月間 PV 2,000 万超の Web サイトをキャンペーン期のスパイクに耐えるよう Cloudflare へ移行しました。Argo Smart Routing によって応答速度 65% 向上、Log4j 脆弱性公表直後に Cloudflare 側で対応完了メールを発行した運用も決め手になったと報告されています。
ライオン は約 100 系統のブランド / キャンペーンサイトを保有し、ガバナンス欠如が経営リスクになっていました。2019 年 12 月に三井情報(MKI) 経由で導入。自社データセンター宛トラフィックを前年同月比 90% 以上削減(≒ 90% 超がエッジキャッシュから配信)し、回線帯域を縮小してインフラ維持コストを下げた ところまで踏み込んでいます。「WAF だけを各事業部に強制する」のではなく「CDN による表示高速化」というベネフィットをセットで提供したことで、各事業部門が自発的に Cloudflare 配下に入るインセンティブを形成した、というガバナンス設計の話も実務的に参考になります。
Sony Music Group(日本) は 20 社のグループ会社の 500 超サイト全体に Cloudflare WAF で一貫したルールを適用し、ある 1 サイトで 1 日 400 件超の攻撃を遮断していると報告。GMO インターネットグループ は外部委託型 WAF を Cloudflare に集約しつつ Workers でエッジロジックを実行する構成です。
ここでの教訓は、Cloudflare の WAF / Bot / CDN を「点の置換」ではなく「全社共通プレーンへの寄せ」として位置付けること で、運用工数削減という形で ROI が出やすい構造になっている、ということです。
入口 4: Workers / R2 と開発者プラットフォーム — BASE、ユニークビジョン、Soracom、GMO
開発者プラットフォームとしての Workers、R2、D1、Workers AI も、AI / SaaS スタートアップから見ると無視できない入口になってきています。
BASE は 2025 年にショップページの表示速度改善を目標に、全ショップへ Cloudflare を導入しています。SSL for SaaS で独自ドメイン対応の SSL 証明書を自動発行し、Cloudflare Workers で X-Webapp-Version ヘッダによる世代管理キャッシュを実装。CloudFront + Lambda@Edge との比較で「証明書管理の柔軟性」「Workers KV の取り回し」を理由に Cloudflare を採用したと公開されており、マルチテナント型 SaaS が独自ドメイン対応をするときの設計パターンとして参考になります。
ユニークビジョン(Beluga シリーズ) は Amazon CloudFront + S3 構成のエグレス料金が課題だった動画配信を R2 に移行してエグレス料金 0 円化 し、AWS SDK がそのまま使えたため移行工数を最小化したと Findy Tools のインタビュー で報告しています。
Soracom は IoT プラットフォームの Soracom Lagoon で「自社の技術的ニーズを満たした唯一のプラットフォームが Cloudflare Workers だった」(プリンシパルソフトウェアエンジニア Christian Inkster 氏)と公式事例にコメントしており、新サービス Soracom Flux もエッジで初期処理しています。
ISMAP 登録で、金融・公共セクターの選択肢に入った
2026 年 1 月 15 日に発表された Cloudflare の ISMAP 登録(登録日: 2025 年 12 月 22 日)は、日本のエンタープライズ採用にとって質的な転換点です。CDN / WAF / DDoS / Rate Limiting / API Shield / Bot Management / Turnstile / DNS / Load Balancing / Waiting Room / Magic Transit / Network Firewall / Spectrum / Access / Tunnel / Browser Isolation / CASB / Gateway / Workers が、Cloudflare for Public Sector として政府調達対象になりました。
組み合わせとして重要なのが Data Localization Suite です。Regional Services でトラフィックの復号化・処理を日本のコロケーションに限定でき、Geo Key Manager でプライベート SSL / TLS 鍵を日本国内のみに保存できます。
ただし、留意点もあります。FISC 安全対策基準 に関する Cloudflare の対応文書は、AWS / Azure / GCP のような公開リファレンスではなく、Trust Hub 経由で NDA ベースの提供にとどまっています。金融機関 / 医療機関で採用するには、コンプライアンス部門との事前協議とパートナー(MBSD のような SOC 含む)連携が前提になる場合があります。
デジタル庁認定のガバメントクラウド(IaaS 層: AWS、Azure、GCP、Oracle、さくらインターネット)とは別レイヤーに位置付けられる点も重要で、Cloudflare は「CDN / セキュリティ / SASE 層として並行採用可能」という関係になります。
採用前に踏まえておくべきリスク
ここまでは導入の追い風を整理してきましたが、見過ごせない論点もまとめておきます。
2025 年に起きた 2 件の大規模グローバル障害
2025 年 11 月 18 日 には、Bot Management のフィーチャーファイル肥大化が原因で約 5 時間 46 分(11:20 〜 17:06 UTC)の障害が発生し、X や ChatGPT をはじめ多数のサービスが断続的に利用不可になりました。さらに同年 12 月 5 日 には、WAF 内部テストツールを無効化する設定変更が一括伝播し、旧 FL1 プロキシの潜在バグを露呈、約 25 分間で 全 HTTP トラフィックの約 28% に影響 が出ています。
単一 CDN 依存のリスクが現実化した出来事で、Mission-Critical な業務では Cloudflare + Akamai / Fastly のマルチ CDN 構成や、DNS レベルでのフェイルオーバー設計をどこまで詰めるか、を改めて議論する余地があります。
自社の入口をどう設計するか
ここまで整理してきた事例を、自社で採用判断するときのチェックリストとして再構成すると、こんな形になります。
第 1 段階(検証 〜 1 ヶ月以内)
- 主要ドメインを Cloudflare Free プラン または Pro に乗せて、CDN / WAF / DDoS のベースライン効果を測る
- マルチテナント型 SaaS を持っているなら、Cloudflare for SaaS と SSL for SaaS を BASE 型アーキテクチャで PoC する
- 月間 S3 + CloudFront エグレスが月 20 〜 30 万円規模になっていれば、R2 への部分移行(動画、画像、ログ)を即検討する
- Workers + Hono で API Gateway 層を試作し、デプロイ時間や起動時間のベースラインを取る
第 2 段階(1 〜 3 ヶ月)
- セキュリティ運用負荷が課題なら、NRI セキュアテクノロジーズか MBSD のマネージド SOC を組み合わせる
- VPN 関連サポートチケットが月 100 件を超えていれば、Cloudflare Zero Trust(Access + Gateway + WARP)への置換を上申する
- DeNA 事例の月 400 時間生産性回復、三菱ガス化学事例の月 40 時間運用工数削減を、社内向け ROI のベンチマークとして使う
第 3 段階(3 〜 12 ヶ月)
- 金融 / 公共セクター向けに新規プロダクトを計画している場合は、ISMAP 登録済みの Cloudflare for Government を提案に組み込む(JCB、JAL、Money Forward 事例を業界レファレンスとして活用)
- AI / エージェント開発の核として Workers AI + AI Gateway + Vectorize を採用検討
- Mission-Critical 業務では、マルチ CDN 構成(Cloudflare + Akamai / Fastly)の費用対効果を試算する
- スタートアップ群に向けては Cloudflare for Startups のクレジット(R2 / Cache Reserve 各最大 1 万ドル、Workers AI 最大 5 万ドル)を活用してハンディキャップを解消する
入口を選ぶときの判断基準は、結局のところ「定量的な ROI が短期間で説明できるか」に集約されます。
まとめ — 「導入の入口」を間違えなければ、Cloudflare は日本でも十分実務的
公開事例を横断して見えてくるのは、Cloudflare の日本エンタープライズ採用が、CDN / WAF の点ではなく、Zero Trust、メール、Web / API 防御、開発者プラットフォームを共通制御プレーンに寄せる動き として広がってきていることです。
そして定量効果は、防御精度よりも 「運用 / サポート / ヘルプデスク工数の削減」「マルチベンダー統合によるコスト削減」「インフラ帯域削減」 で説明されるケースが圧倒的に多い。これは社内の意思決定者と話すときの説明軸として、極めて重要なポイントだと考えています。
ISMAP 登録によって金融・公共セクターの選択肢に入ったこと、そして 2025 年の障害という採用前に踏まえるべきリスクが顕在化したこと。この 2 つを同時に視野に入れたうえで「自社のどの課題から入るのが効くか」を設計することが、今やるべき仕事だと思います。
以上、社内外で Cloudflare 採用の判断軸を組み立てている、現場からお送りしました。