中小企業のWebサイトが狙われている——これは単なる危機感ではなく、実務レベルの課題です。サイバー攻撃の43%が中小企業を標的としており、その中でもDDoS攻撃は手軽に実行でき、経営に直結したダメージを与えるため、攻撃者の第一選択肢になっています。
しかし、ここで多くの企業担当者が陥る落とし穴があります。セキュリティを強化しすぎて正当なユーザーまで排除してしまったり、複雑な設定に手をつけられず放置したり、「Cloudflareが落ちるとサイトが繋がらなくなる」という誤解から導入をためらったりするのです。
この記事では、Cloudflareで実現するDDoS対策とセキュリティの実装方法を、無料プランの正しい使い方から有料プランへの段階的拡張まで、即実践できる手順で解説します。 京谷商会の22サイト運用実績（測定期間：過去12ヶ月、対象企業：従業員50名以下の中小企業、測定方法：Cloudflare Analyticsと顧客サポートログ）に基づき、「攻撃を防ぎながら顧客を遮らない」チューニング手順をお伝えします。
DDoS攻撃が中小企業に影響を与える仕組みと防御の必要性
DDoS攻撃は複数の場所から大量のリクエストを同時に送りつけることで、サーバーのリソースを枯渇させてサイトをダウンさせます。 「Distributed Denial of Service」の略で、攻撃者が特別な技術を持つ必要はなく、安価なツールで実行でき、報酬を求めない嫌がらせ目的でも仕掛けられるため、規模の小さい企業が狙われる傾向が強まっています。
DDoS攻撃が危険な理由は、サーバーのスペックではなく「接続数の限界」を突破される点にあります。月間アクセス数が1,000件でも、1秒間に10,000リクエストが殺到すれば、その時点でサイトは応答不可になります。さらに、攻撃者が複数の経路から攻撃するため、単純にアクセス元IPをブロックするだけでは防げません。
CloudflareのようなCDN＆セキュリティプラットフォームが必須になる理由はここです。攻撃トラフィックをCloudflareのエッジサーバーで検出・ブロックすれば、悪質なリクエストは元々オリジンサーバーまで到達しないため、正当なユーザーだけを通す仕組みが実現できます。京谷商会が支援する南河内の中小企業からは「特定のページにアクセスすると毎回Cloudflareの認証が開く」「HTTPエラーでブロックされて顧客が購入できない」といった相談が増えていますが、これはセキュリティの設定が実務ニーズに合っていないケースがほとんどです。
Cloudflareの無料プランでできるDDoS防御と3つのコア機能
Cloudflareの無料プランには無制限のDDoS防御が組み込まれているという事実を知らない企業が意外に多いのです。これは「必ずしも高額なプランが必要ではない」という意味です。
京谷商会が支援する中小企業22社の運用実績から見ると、月間アクセス数が100万件以下の企業であれば、無料プランの標準設定だけで日常的なDDoS攻撃（レイヤー3/4攻撃）はほぼすべて自動ブロックされます。有料プランに移行するのは「顧客接点ページで認証の頻発を避けたい」「レイヤー7のアプリケーション層攻撃を個別に検出したい」という明確な理由がある場合に限定されます。
無料プランの3つのコア機能はこのとおりです。
1. DDoS Protection（自動検出・ブロック） — Cloudflareが検出したDDoS攻撃パターンは自動的にブロックされます。設定は不要で、DNS変更後の数分で有効になります。UDP Floodやスポーフィング攻撃といったレイヤー3/4攻撃を自動遮断します。
2. SSL/TLS暗号化 — HTTPSが自動で設定されるため、通信が盗聴される攻撃を防げます。特に顧客の入力フォーム（ログイン、決済）を保護する際に重要です。
3. WAF基本ルール — Webアプリケーション脆弱性（SQLインジェクション、クロスサイトスクリプティングなど）を自動検出します。ルールはCloudflareが提供元から自動更新されます。詳細はOWASP公式ドキュメントをご参照ください。
これら3つがあれば、90%以上の攻撃シーンに対応できます。問題は「有効化していない」または「正しく設定していない」という企業が圧倒的に多いことです。
プラン選択：月間アクセス数で判定する実装パターン
Cloudflareの選択は複雑に見えますが、月間アクセス数という1つの指標だけで判定できます。
| アクセス規模 | 推奨プラン | 推奨対象の詳細条件 | 導入コスト |
|---|---|---|---|
| 月間10万件以下 | Free | 従業員10名以下、月間トランザクション100件未満の小規模小売業・事業所。DDoS防御とSSL化だけで要件を満たす企業。 | 無料 |
| 月間10万～100万件 | Pro（月額$20） | 従業員10～50名の中堅企業、または月間トランザクション500～2,000件のEC事業者。レイヤー7攻撃検出強化と詳細ログが必要な場合。月額3,000円で顧客認証の頻度が90%削減される企業が大半。 | 月額3,000円 |
| 月間100万件以上 | Business（月額$200） | 従業員50名以上、または月間トランザクション5,000件以上の大規模EC・SaaS企業。DDoS攻撃ログの詳細取得、カスタムWAFルール100個、優先サポートが必要な場合。 | 月額30,000円 |
この表の重要なポイントは、「月額3,000円で顧客離脱を防ぐ」という投資対効果が明確だということです。月間100件の購入があり、平均購入額が5,000円の企業の場合、1件の顧客離脱で5,000円の売上が失われます。Proプランで月1件の離脱を防ぐだけで、月額3,000円のコストは回収できるのです。
具体例：南河内のEC企業A社（月間アクセス50万件、月間購入数200件、平均購入額8,000円）がProプランを導入したところ、ブラウザチャレンジによる購入離脱が月平均4件から0.4件に低下しました。月額収益への貢献度は4件×8,000円＝32,000円の損失回避となり、月額3,000円のコストは初月で回収されました。
Cloudflareで実現するDDoS対策の段階的実装
ステップ1：基本設定で攻撃を自動遮断（初日、所要時間30分）
この設定により、レイヤー3/4のDDoS攻撃（UDP Flood、SYN Floodなど）が自動的にオリジンサーバーまで到達する前にCloudflareで遮断されます。
- Cloudflareにログイン → ドメイン追加
- ネームサーバーをCloudflareに切り替え（DNS設定）
- 「セキュリティレベル」を「高」に設定
- 「DDoS防御」が「有効」になっていることを確認
この時点で、標準的なDDoS攻撃パターンはブロックされます。SSL/TLSも有効になり、すべてのページがHTTPS化されます。設定後1日経過して、ダッシュボードの「分析」→「セキュリティイベント」でブロック件数を記録し、正常値（1日100件以下）であることを確認してください。
ステップ2：ボット・スクレイパー対策で誤検知を最小化（1～2日目、所要時間20分）
この設定により、明らかに悪意のあるボット（スクレイパー、脆弱性スキャナー）はブロックされ、顧客のブラウザアクセスは許可されます。
ダッシュボード「セキュリティ」→「ボット」で以下を設定します。
- Definitely Automated（確実に自動化）：ブロック
- Likely Automated（おそらく自動化）：チャレンジ（認証ページ表示）
- Likely Human（おそらく人間）：許可
この設定で、顧客のブラウザからのアクセスはほぼ全て「Likely Human」と判定され、スムーズに通過します。一方、プロキシサーバーやVPN経由の場合は「チャレンジ」が表示されますが、これは正当なセキュリティです。
ステップ3：WAFルールの誤検知対策（顧客からのクレーム後、所要時間15分）
この設定により、正当なユーザーアクセスパターンまで遮断されていたWAFルールが除外され、購入ページなどの重要ページが正常に機能するようになります。
もし「403エラーが出た」というクレームが来た場合は、ダッシュボード「セキュリティ」→「WAF」→「OWASP ModSecurity Core Rule Set」で、該当ルールを「チャレンジ」に変更します。完全なブロックから「認証ページの表示」に変更することで、正当なユーザーは認証後にアクセス可能になります。
より効果的な対策は、特定URL（例：/shop/buy/）の前でWAFを無効化することです。
よくあるつまずき：正当ユーザーまでブロックされる場合の対策
Cloudflareを導入した企業から「403エラーが出て購入ページに進めない」という相談を受けることが多いのです。原因は単純で、セキュリティルールが強すぎるか、不正な設定になっているため、正当なユーザーアクセスまで排除されている状態です。
ケース1：IPレピュテーション機能の過度な厳格化 — Cloudflareが「疑わしい」と判定したIPアドレスからのアクセスは遮断されますが、その「疑わしい」判定基準は全世界のサイバー脅威情報に基づいています。大企業のプロキシサーバー（複数のセキュリティ会社から「マルウェア配信元」と誤判定されているケースがある）が誤って遮断される可能性があります。
対策：ダッシュボード「分析」→「セキュリティイベント」でブロックされたIPを確認し、「ホワイトリスト」に追加します。顧客企業から「繋がらない」という相談を受けた場合、そのIPアドレスを教えてもらい、除外設定することが即効的な解決方法です。
ケース2：WAFルールが商品説明文にマッチしている — 無料プランのOWASP Core Rule Setには数百個のルールが含まれており、その中には「特定の文字列を含むクエリ文字列をすべてブロック」という汎用ルールが混在します。正当な商品説明（例：「セキュリティソフト」という単語を含む説明）でもこれに引っかかることがあります。
対策：ルールを「ブロック」から「チャレンジ」に変更するか、特定URLを除外ルールに追加します。
これらの対策を実施することで、ブロック件数と顧客クレームのバランスが取れた状態に収束するのは約2週間です。
京谷商会での実装例：脅威インテリジェクト連携による精密なDDoS検出
京谷商会は単なるCloudflareの設定にとどまらず、自社開発の脅威インテリジェンスAPIをCloudflareと統合し、より精密なDDoS検出を実現しています。
仕組みはこうです。
- 脅威インテリジェンスAPIが4時間ごとに新しいサイバー脅威情報を自動取得
- その情報がCloudflareの「カスタムWAFルール」に反映
- 既知の攻撃パターン（特定のバージョンのSSLスキャナー、既知の脆弱性スキャナーからのアクセス）は即座にブロック
- 未知の攻撃パターンはAI層で判定
この仕組みにより、新種のDDoS攻撃にも対応できるようになります。実装コストは月額1,650円（測定期間：過去12ヶ月、対象企業：従業員50名以下の22社、測定方法：月次支援契約のログ分析）ですが、検出・ブロックできた攻撃は月平均47件でした。これを自社で対応すれば、セキュリティ担当者に月5時間程度の負担が発生するため、コスト対効果は明らかです。
ただし、このAPIの導入は京谷商会の支援契約企業向けの実装例であり、一般的な中小企業が必ず導入すべき内容ではありません。 月間アクセス数100万件以下であれば、Cloudflareの無料プランまたはProプランで十分に対応できます。
セキュリティと利便性を両立させるチューニング手順
現状把握フェーズ（設定後1週間運用）
設定後1週間は、何もしないで数字を見る期間です。ダッシュボード「分析」セクションで以下を記録します。
- 1日あたりのブロック件数
- チャレンジ（認証）表示回数
- キャッシュ率（Cloudflareが返したコンテンツの割合）
このデータがないまま設定変更すると、「施策の効果が不明」という状態になります。データを持つことで、以降の判断が数字に基づきます。
改善判断フェーズ（2週目以降）
「チャレンジ」表示が1日100件以上、かつ顧客からクレームがないの場合、防御は十分で正当ユーザーは許可されているため、現状維持が最適です。
「チャレンジ」表示が1日50件以下、顧客からのクレームなしの場合、セキュリティレベルを「中」から「高」に上げるか、IPレピュテーションを「厳格」に設定することでルールをより厳しくできます。
顧客から「403エラーが出た」というクレームが来た場合、即座に「セキュリティ分析」でそのIPアドレスを確認し、ホワイトリスト追加します。同時にWAFルールの過度な厳格化を確認します。
DDoS対策時に確認すべきこと：Cloudflareダウンのリスクについて
ユーザーの声で「Cloudflareが落ちるとサイトが繋がらなくなる」という誤解をよく目にします。これは正確には半分正しく、半分間違っています。
正しい部分：Cloudflareが提供するDNS解決が一時的に失敗すると、ユーザーのブラウザがあなたのサーバーのIPアドレスを取得できず、一時的にアクセス不可になります。ただしこれは「数分程度」で解決します。
間違っている部分：Cloudflareの「キャッシュ」機能により、Cloudflareサーバーが既にあなたのコンテンツを保持しているため、オリジンサーバーがダウンしていても、キャッシュ内容は配信され続けます。つまり、Cloudflareのデータセンター故障とオリジンサーバー故障は別の事象です。
京谷商会の22サイト運用実績では、過去12ヶ月でCloudflareのサービス断障は0件です。ただしDNS応答が若干遅延した（応答時間が100msから150msに増加）ケースが1回あり、ユーザーには体感できない程度でした。一方、オリジンサーバー（AWS、GCP）のダウンは年1～2回発生していますが、Cloudflareのキャッシュ機能により、顧客への影響はほぼゼロです。つまり、DDoS対策としてCloudflareを入れることで、逆に可用性が向上するのです。
中小企業が実装すべき3段階DDoS対策の全体像
実装時間と効果のバランスから見ると、段階的な導入が最適です。
フェーズ1（初日、30分）：基本的なDDoS防御を有効化 — Cloudflareの初期設定だけで、レイヤー3/4攻撃の90%はブロックされます。投資額は無料です。
フェーズ2（1週間後、1時間）：WAFルールを正当ユーザー向けに調整 — 顧客からのクレーム有無を確認し、必要に応じてホワイトリスト追加。投資額は自社スタッフ1時間分（人件費のみ）です。
フェーズ3（1ヶ月後、必要に応じて）：Proプランへの移行検討 — 顧客の認証頻度が高い、またはレイヤー7攻撃の詳細ログが必要な場合に限定。投資額は月額3,000円です。
この3段階で、セキュリティの水準は段階的に向上し、不要な過投資は発生しません。
よくある質問
Q1. Cloudflareの無料プランでは、DDoS攻撃を完全には防げないのでは？
A. 無料プランでも、日常的なDDoS攻撃（レイヤー3/4）は完全に防げます。有料プランが必要になるのは、「レイヤー7（アプリケーション層）の高度な攻撃を詳細ログで記録したい」「カスタムWAFルールを複数追加したい」という明確な理由がある場合だけです。月間アクセス100万件以下の中小企業なら、無料プランで十分です。
Q2. 認証ページ（One more Step）が何度も出現するのは、Cloudflareの設定が間違っているのでは？
A. ほぼそうです。セキュリティレベルが「厳格」すぎるか、不正なIPをホワイトリスト化せずに除外ルールに追加されていない可能性があります。ダッシュボード「分析」でブロック理由を確認し、「ブラウザチャレンジ超過」の場合はセキュリティレベルを「中」に下げてください。
Q3. 自社のサーバーがCloudflareの背後にあると、攻撃者に場所を特定されないのか？
A. その通りです。Cloudflareを経由することで、オリジンサーバーのIPアドレスが隠ぺされます。これはDDoS攻撃を受けるリスクを大幅に低減します。ただし、「Always Use HTTPS」を有効にしないと、http接続でサーバーIPが露出するため、必ず有効化してください。