2026.09.10

WAFとCDNは自社サイトに入れるべきか？導入判断の基準と、入れた時に起きること

【AIによる要約】
– WAFはWordPress等の標準CMSなら基本オンが推奨で、静的な案内サイトのみオフでも許容範囲です。
– CDNは表示速度や海外アクセスが課題のときだけ入れ、ECや会員サイトではキャッシュ設計が前提になります。
– どちらも導入直後に誤検知や更新不具合が起きるため、切り戻せる体制を作ってから入れるのが安全です。

「入れたほうがいいらしい」で入れていませんか

「レンタルサーバーの管理画面にWAFの設定がある。これは有効にすべき？」
「表示速度が遅いからCDNを入れたほうがいいと言われた。でも入れて不具合が出たら怖い」

Webサイトの相談現場で、この2つは定番の質問です。どちらも正しい機能ですが、「入れる・入れない」より「入れた後に何が起きるか」を予測しているかのほうが重要です。当社カジヤは業界歴10年以上で300社以上のサイト運用に携わり、WAF誤検知での「保存できない」相談も、キャッシュ事故の復旧も、両方を何度も経験してきました。この記事では判断基準を表で言い切り、副作用の実態も含めて解説します。

まず結論：WAFは基本オン、CDNは課題があってから

結論から言います。

• WAF：WordPressやEC-CUBEなどのCMSサイトなら、基本「有効」にします。 無料で防御の底上げになるので、理由がないならオフにする選択肢はありません
• CDN：「表示速度が遅い」「海外アクセスが多い」「直近でアクセス集中が予想される」のどれかに当てはまる場合だけ入れます。 悩んでいる段階では入れません

「セキュリティも速度も強化できるらしい」という理由で両方入れるのが、実は一番事故が多いパターンです。順に根拠を示します。

WAFの判断基準表

WAFは、サイトへの通信を監視して攻撃パターンを遮断する防御装置です。IPAの「情報セキュリティ10大脅威」でも、Webサイトへの攻撃は毎年上位にランクインしています（出典：IPA「情報セキュリティ10大脅威」）。防御が必要なのは明らかですが、「どのサイトなら必須か」には差があります。

サイトの状況	WAF	理由
WordPress・EC-CUBE等のCMS	入れる（基本オン）	脆弱性は運用中に常に出る。WAFは更新が届くまでの時間を買う装置
独自システム・古いPHPのサイト	入れる（必須級）	更新で直せない欠陥をWAFが覆い隠す役割。外すと丸裸
静的な案内サイト（更新は月数回）	オフでも許容	攻撃を受ける入力箇所が少ない。ただしオンのままで害はない
個人情報・決済を扱うEC	入れる＋ログ監視	事故時の説明責任を考えると「入れていない」が説明できない

ポイントは1行目です。CMSサイトのWAFは「攻撃を完全に防ぐ装置」ではありません。プラグインに脆弱性が出て、修正版が公開されるまでの空白期間を埋める役割です。だから「更新をちゃんとしているから要らない」ではなく、「更新と更新の間も守るから要る」と考えます。

CDNの判断基準表

CDNは、世界中に置かれた配信サーバーからサイトの画像やHTMLを代理で配信する仕組みです。速度改善と負荷分散が効果ですが、すべてのサイトに効果があるわけではありません。

サイトの状況	CDN	理由
表示速度が遅いと計測されている	入れる（画像配信から）	静的ファイルの配信を外に出すと効果が大きい
海外からのアクセスが多い	入れる	物理的な距離の問題はCDNでしか解決しない
キャンペーン等でアクセス集中が予想される	入れる（事前に設計）	負荷を吸収する。当日入れても間に合わない
会員ログイン・カートがあるEC	設計してから入れる	キャッシュ設定を誤ると他人のページが見える事故になる
表示速度に不満がない国内向けサイト	入れない	メリットより運用の手間と事故リスクが勝つ

4行目が最重要です。当社は自社でもECを運営していますが、CDNやキャッシュの設定ミスは「他人のカート情報が別の人に表示される」という、売上より重い事故につながります。速度の数字は良くなっても、事故1回で信頼は戻りません。ECや会員サイトでCDNを入れるなら、「どのページをキャッシュし、どのページを絶対にキャッシュしないか」の設計が先です。キャッシュプラグインでの事故の仕組みは、表示速度改善のために入れたWordPressキャッシュプラグインで事故が起きる理由｜他人のカート情報が見える・更新が反映されないで詳しく解説しています。

入れた時に起きること（副作用の実態）

導入判断で「メリットの表」だけを見る会社が落ちます。以下は、当社が実際に対応した副作用です。

WAFで起きること

• 誤検知：記事本文にコード片を書いて保存しようとしたら403で弾かれる。正規の更新が攻撃と同じ形をしているため起きます。対処法は【WordPress】WAFの誤検知で管理画面が保存できない時の対処法｜止めない・消さない・正しく除外するにまとめています
• 「保存できないから」とWAFを丸ごとオフにして放置するケース。これが一番危険です。防御を外したままの期間が長いほど攻撃が素通りします
• 管理画面ログインへの不正アクセスが激減して「当たり前」になる。良すぎて気づかない効果です

CDNで起きること

• 更新が反映されない：記事を直したのに古い表示のまま。キャッシュの残り時間が原因で、「直したのに直っていない」と誤診するトラブルが非常に多い
• キャッシュ事故：ログイン後の個別ページがキャッシュされ、別の人に表示される
• 障害がCDN側に波及する：CDN自体の障害で自サイトが表示できなくなる事例もあり、依存度が上がると切り分けも複雑になります

つまりWAFもCDNも、導入は「設定を終える」ことが完了ではなく「誤検知・不具合と付き合う運用」の始まりです。

導入前に用意すべきこと

• 切り戻しの前提：WAF・CDNとも、設定を元に戻す手順と担当者を決めてから入れる
• テストの実施：本番に入れた直後に、記事の更新・保存、問い合わせ送信、ECなら会員ログインと購入テストを必ず実機で行う
• 監視の発注先：誤検知やキャッシュ事故に自分で対応できるか。できないなら保守管理の契約とセットにする

当社の保守管理では、WAF誤検知の除外設定やキャッシュ事故の復旧も日常対応の範囲です。代理店を挟まない直接取引で、社内の専任エンジニアが調査から設定修正まで一貫して行います。

まとめ：判断基準の再掲

• WAF：CMSサイトなら基本オン。オフにする理由がない
• CDN：速度・海外アクセス・アクセス集中の課題があってから入れる。EC・会員サイトはキャッシュ設計が前提
• どちらも導入後に誤検知・不具合が起きる。切り戻し手順と実機テストを用意してから入れる
• 運用を自分で抱えられないなら、対応範囲に含まれる保守管理とセットにする

「今のサーバーのWAF設定はどうなっているか分からない」「CDNを入れるべきか判断に迷っている」段階のご相談も歓迎です。現状の構成を見たうえで、導入・見送りの基準を一緒に整理します。

Webサイト保守管理サービス