Cloudflare 5秒盾完全ガイド：SEO と UX の課題を解く 3 つの設定テクニック

はじめに

サーバーの CPU 使用率が 100%、サイトのアクセス数が 10 倍に急増——典型的な CC 攻撃です。Cloudflare 管理画面にログインし、「I’m Under Attack」モードをオンにすると、30 秒後にはサーバー負荷が下がりました。

翌日 Google Search Console を開くと、サイトのインデックス数が前日の 1200 件超から 800 件台へ、30% 以上減少していました。調査の結果、5秒盾が検索エンジンのクローラーも遮断していたことが判明しました。

5秒盾をオフにすると攻撃に耐えられず、オンにすると SEO とユーザー体験に響く。この記事では、Cloudflare 5秒盾で攻撃を防ぎつつ、SEO と UX へのダメージを最小限に抑える方法を解説します。

第1章：5秒盾（Under Attack モード）とは何か？

仕組み：あの 5 秒間に何が起きるか

Cloudflare 5秒盾は、サイトと訪問者の間に検証ゲートを置く機能です。アクセス時、Cloudflare は直接入れず、約 5 秒待つ中間ページを表示します。

この 5 秒は単なる待ち時間ではありません。Cloudflare はこの間に 3 つの処理を行います：

ステップ 1：ブラウザが最初のリクエストを自動送信。Cloudflare が __cfduid Cookie を書き込み、一時パスを発行します。

ステップ 2：ブラウザが 2 回目のリクエストを暗号化パラメータ付きで送信。Cloudflare が検証通過後、cf_clearance Cookie を書き込みます。これが本パスで、デフォルト有効期間は 30 分です。

ステップ 3：2 つの Cookie を持ってトップページをリクエスト。Cloudflare がチェックして通過させ、初めてサイトコンテンツが読み込まれます。

この 3 リクエストに加え、Cloudflare はバックグラウンドでも検証を続けます：

• JavaScript 検証：難読化された JS を注入し、ブラウザが正常に実行できるか確認。通常ブラウザは問題なし。単純なクローラーや攻撃スクリプトはここで脱落します。
• ブラウザ指紋：画面解像度、プラグイン、システムフォントなどを収集し、固有の「指紋」を形成。正常ブラウザに偽装した攻撃ツールを識別できます。
• 行動検知：リクエスト頻度、User-Agent、マウス移動などを分析し、人間かどうかを判断します。

他のセキュリティレベルとの違い

Cloudflare には 5秒盾以外にも複数のセキュリティレベルがあります。比較表で整理します：

経験上、平時は Medium で十分です。本当に攻撃を受けたときだけ I’m Under Attack に切り替えましょう。平時から 5秒盾をオンにするのは、防毒マスクを常時着けるようなもの——自分も息苦しいだけです。

5秒盾が防げる攻撃

まず DDoS 攻撃の分類を押さえましょう。ネットワーク攻撃は OSI 7 層モデルで分類され、上層ほどアプリケーション層に近づきます。

5秒盾が主に防ぐのはレイヤー 7 アプリケーション層攻撃、通称 CC 攻撃（Challenge Collapsar）です。正常ユーザーに見える大量アクセスでサーバーリソースを枯渇させます。

UDP Flood や SYN Flood など下位の帯域型 DDoS には効果が限定的で、Cloudflare は別の仕組みで防御します。公式ドキュメントも「最後の手段の一つ」と明記しており、万能薬ではありません。

Cloudflare 公式の説明：「レイヤー 7 DDoS 攻撃の緩和に役立つ追加セキュリティチェックを実行する」。「緩和に役立つ」であり「完全阻止」ではありません。超大規模 DDoS には 5秒盾だけでは不十分で、他の防御策との併用が必要です。

第2章：5秒盾が SEO と UX に与える実際の影響

検索エンジンのクローラーは 5秒盾を通過できるか？

テストした結果、答えは場合によるです。

Google クローラー（Googlebot）は JavaScript を実行できるため、理論上は 5秒盾を通過できます。ただしクローラーの時間は限られています。人間のように 5 秒待つことはなく、他サイトを先にクロールし、後で戻ってくる傾向があります。

5秒盾オン後の Google Search Console データで、次の傾向を確認しました：

1. クロール頻度の大幅低下：1 日 1200 回 → 400〜600 回
2. クロールエラー増加：「タイムアウト」「サーバーエラー」が大量発生
3. インデックス速度の低下：新記事のインデックスが 1〜2 日 → 4〜5 日

Baidu クローラーは JavaScript 実行能力が弱く、5秒盾でほぼクロール失敗します。中国語サイト運営者から、3 日間 5秒盾をオンにしたらインデックスが 2000 超 → 1000 台前半に減った、という話も聞きました。

Bing は中間的。通過できるが遅く、インデックス数 15〜20% 減少の可能性があります。

ユーザー体験の実データ

理論だけでなく、データを見ましょう。5秒盾オン前後の A/B テストでユーザー行動の変化を記録しました：

直帰率の急増：

• オン前：35%
• オン後：62%
• 増加率：77%

新規訪問 10 人中 6 人が、5 秒待機ページを見てそのまま離脱。PC でもこの数字で、モバイルは 75% まで上昇します。

平均滞在時間の低下：

• オン前：3 分 15 秒
• オン後：1 分 48 秒
• 減少率：45%

コンバージョン半減：
登録・購入などのコンバージョン目標があるサイトなら、5秒盾で半減を想定すべきです。ユーザーは期待してクリックしたのに、先に 5 秒待たされ、熱が冷めます。

EC サイト運営者から、攻撃時に 5秒盾をオンにしたら注文数が 60 件/日 → 22 件/日に落ちた、という話も。攻撃は防げたが、ビジネスも失った、とのことです。

分析ツールのデータ歪み

こちらはより隠れた落とし穴です。Cloudflare 公式ドキュメント：「中間ページの表示と通過には JavaScript が必要なため、JavaScript 依存の分析ツールへの干渉は想定内の挙動」。

具体的には：

Google Analytics のデータ減少：

• 5 秒待機ページに GA トラッキングコードがない
• 離脱ユーザーは計測されない
• 表示データは「検証通過者」のみ。実際のアクセス数はもっと多い

ヒートマップツールが完全に機能しない：
Hotjar や Crazy Egg などは、5 秒待機ページ上のユーザー行動を記録できません。全員がスムーズに入站したと思い込んでいるが、実際は半数が入口で離脱している、という状態です。

広告トラッキングの失明：
Google Ads や Facebook 広告を回している場合、5秒盾後はコンバージョントラッキングがほぼ機能しません。Facebook Pixel や Google Ads コンバージョンタグが読み込めず、広告費だけかかってデータが取れません。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

API とサードパーティサービスの災害

Web アクセスへの影響は我慢できるとしても、API には致命的です。

問題 1：API リクエストが全失敗
API 呼び出しはプログラム間通信。JavaScript を実行せず、5 秒も待ちません。即エラーです。

最悪の事例：開発者が Cloudflare 保護下の API を使うモバイルアプリを運営。うっかり全サイト 5秒盾をオンにし、5 万超のアクティブユーザーのアプリが一瞬で全滅。問い合わせ電話が鳴り止みませんでした。

問題 2：サードパーティ連携の切断
多くのサイトがサードパーティサービスと連携しています：

• 決済コールバック（PayPal、Stripe）
• Webhook 通知（GitHub、Slack）
• RSS 購読
• サイト監視（Uptime Robot）

これらは 5秒盾検証を通過せず、すべて遮断されます。決済コールバック失敗は最悪——ユーザーは支払ったのにサイト側が通知を受け取れず、注文ステータスが更新されません。

問題 3：モバイルアプリがアクセス不能
iOS/Android アプリが Web API でサーバーと通信している場合、5秒盾オンはアプリを事実上無効化します。ユーザーは Loading のまま、最終的に「ネットワークエラー」。

API、モバイルアプリ、重要なサードパーティ連携があるなら、絶対に全サイト 5秒盾をオンにしないでください。Page Rules でこれらのパスを除外する必要があります。次章で設定方法を詳述します。

第3章：特定パスだけ 5秒盾をオンにする（Page Rules 設定実践）

Page Rules とは

Page Rules は Cloudflare の「条件ルール」機能です。URL パスごとに異なるセキュリティレベル、キャッシュ戦略などを設定できます。

例：

• example.com/api/* アクセス時 → Security Level: Low（遮断なし）
• example.com/admin/* アクセス時 → Security Level: I’m Under Attack（厳格検証）
• その他 → Medium

「精密防御」——保護が必要な場所だけ守り、他は UX に影響を与えません。

ただし悪いニュース：Cloudflare は 2024 年 6 月、Page Rules を段階的に廃止し、Configuration Rules や Cache Rules など新システムへ移行すると発表しました。良いニュースは、既存ユーザーの Page Rules は引き続き利用可能で、移行は Cloudflare が担当。手動作業は不要です。

無料版は現在 3 本の Page Rules。個人サイトなら十分。Pro は 20 本、Business は 50 本です。

URL マッチルール：ワイルドカード * の正しい使い方

Page Rules の核心は URL マッチルール。最もよく使うのはワイルドカード * です。

基本ルール：

• * は任意の文字列（空文字列含む）にマッチ
• URL の任意位置で使用可能
• 複数の * も可

よく使うパターン：

example.com/api/*
→ example.com/api/users にマッチ
→ example.com/api/posts/123 にマッチ
→ example.com/apiv2/users には非マッチ（api の後にスラッシュ必須）

example.com/*.jpg
→ example.com/logo.jpg にマッチ
→ example.com/images/banner.jpg にマッチ（サブディレクトリも）
→ example.com/logo.png には非マッチ

example.com/*admin*
→ example.com/wp-admin にマッチ
→ example.com/admin/users にマッチ
→ example.com/myadmin にマッチ（URL に admin を含めば OK）

優先順位ルール（超重要）：
Page Rules は上から順に実行。最初にマッチしたルールのみ適用、以降は無視されます。

つまり：

1. 具体ルールを上、ワイルドカードを下
2. 順序が逆だとワイルドカードが全リクエストを「飲み込み」、具体ルールは永遠に実行されない

誤った例：

ルール 1: example.com/* → Security Level: I'm Under Attack
ルール 2: example.com/api/* → Security Level: Low

この設定ではルール 2 は永遠に効きません。全リクエストがルール 1 に捕捉されます。

正しい順序：

ルール 1: example.com/api/* → Security Level: Low （具体パスを先に）
ルール 2: example.com/* → Security Level: I'm Under Attack （ワイルドカードを後）

シナリオ 1：ログインページと管理画面のみ保護

最も一般的なニーズです。攻撃者はログインページへの総当たりを狙うため、ここを重点保護します。

WordPress の場合：

ルール 1：wp-admin ディレクトリ保護

• URL マッチ：example.com/wp-admin*
• 設定：Security Level → I’m Under Attack

ルール 2：ログインページ保護

• URL マッチ：example.com/wp-login.php
• 設定：Security Level → I’m Under Attack

ルール 3：その他 Medium

• URL マッチ：example.com/*
• 設定：Security Level → Medium

この設定なら、管理画面とログインページのみ 5秒盾が発動。一般読者の記事閲覧は影響なし。SEO も損ないません。

シナリオ 2：API インターフェースを除外

API があるサイトでは、5秒盾で API を遮断してはいけません。

ルール 1：API パス Low

• URL マッチ：example.com/api/*
• 設定：Security Level → Low

ルール 2：モバイルアプリ API 専用ドメイン

• URL マッチ：api.example.com/*
• 設定：Security Level → Low

ルール 3：その他 High

• URL マッチ：example.com/*
• 設定：Security Level → I’m Under Attack

順序に注意。API ルールは必ず最上位です。

API に複数バージョンがある場合：

example.com/api/v1/*
example.com/api/v2/*

ルール数を消費します。より賢い方法：

example.com/api*

/api で始まる全パスにマッチします。

シナリオ 3：動的ページを保護、静的リソースを通過

画像、CSS、JS ファイルに 5秒盾は不要。遮断するとページ読み込みが不完全になります。

ルール 1：画像ファイル通過

• URL マッチ：example.com/*.jpg
• 設定：Security Level → Low, Cache Level → Cache Everything

同様に他の静的ファイルも：

• example.com/*.png
• example.com/*.css
• example.com/*.js

ただしルール数を大量消費します。より良い方法は CDN 専用サブドメインに静的リソースを置くこと：

• cdn.example.com/* → Security Level: Low

ルール 2：動的ページ高防御

• URL マッチ：example.com/*
• 設定：Security Level → I’m Under Attack

HTML は 5秒盾で保護、画像・スタイルシートは正常読み込み。UX が大幅改善します。

完全設定手順（ステップバイステップ）

ステップ 1：Cloudflare Dashboard にログイン
cloudflare.com にアクセスし、アカウントにログイン。設定するドメインを選択。

ステップ 2：Page Rules 設定へ
左メニュー Rules → Page Rules
（新版 Dashboard では Rules → Page Rules (Legacy) の場合も）

ステップ 3：最初のルール作成
Create Page Rule をクリック。
If the URL matches に URL パターンを入力：

example.com/api/*

下にスクロールし、+ Add a Setting → Security Level → Low。
Save and Deploy で保存。

ステップ 4：他ルールも作成
ステップ 3 を繰り返し。ルール順序が重要です。

ステップ 5：優先順位調整
ルール一覧で各ルール左の「三本線」アイコンをドラッグ。具体ルールを上、ワイルドカードを下へ。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

ステップ 6：テスト検証
シークレットモードで各パスにアクセスし確認：

• API パス → 5秒盾非発動 ✓
• 通常ページ → 5秒盾発動 ✓
• 静的リソース → 正常読み込み ✓

無料版 3 本ルールの最適活用

無料版は 3 本のみ。計画的に使いましょう。推奨構成：

ルール 1：最重要入口を保護

example.com/wp-admin*
Security Level: I'm Under Attack

ルール 2：API と静的リソースを通過

example.com/api*
Security Level: Low

ルール 3：その他 Medium

example.com/*
Security Level: Medium

重要エリアを保護しつつ、日常使用に影響しません。攻撃を受けていなければ、安易に I’m Under Attack に変更しないでください。

第4章：Challenge Passage（検証有効期間）のベストプラクティス

Challenge Passage とは

前述の通り、初回 5秒盾通過後、Cloudflare はブラウザに cf_clearance Cookie を保存します。この Cookie は「一時パス」で、有効期間中は他ページでも再検証不要です。

Challenge Passage は、この「パス」の有効時間です。

デフォルト 30 分。通過後 30 分間はサイト内を自由に閲覧でき、5秒盾ページは再表示されません。30 分後 Cookie 失効、次回アクセスで再検証。

技術的な詳細：
クロック偏差バッファ：Cloudflare はクライアントとサーバーの時刻ずれ防止のため、数分の余裕を追加します。

XmlHTTP リクエストの特殊処理：Ajax リクエストには追加で 1 時間の猶予。短命キャッシュの SPA が頻繁に失効するのを防ぎます。

セキュリティレベルの継承：Interactive Challenge（最も厳格な CAPTCHA）を通過した Cookie はあらゆるレベルのチャレンジを通過できます。低レベル検証のみ通過した場合、高レベルチャレンジでは再検証が必要です。

Challenge Passage の設定場所

Cloudflare Dashboard：
Security → Settings → Challenge Passage

編集アイコンでタイムアウト（分単位）を変更。Cloudflare 推奨範囲は15〜45 分。

ドメイン全体のグローバル設定。特定パスごとの個別設定は不可です。

シーン別推奨値

実践経験から、サイトタイプ別の推奨設定：

高セキュリティ（金融・決済・機密データ）：15〜20 分

• 適用：ネットバンキング、決済、企業 OA
• 理由：セキュリティ最優先。滞在時間短く、頻繁な再検証は許容
• UX：15 分ごとに再検証。煩わしいが理解可能

バランス型（EC・企業サイト・SaaS）：30 分（デフォルト）

• 適用：大多数の商用サイト
• 理由：安全と体験の両立。1 回の購入・閲覧に 30 分で十分
• UX：大多数は 30 分以内に完了。二次検証に遭遇しない

UX 優先（コンテンツ・ブログ・メディア）：40〜45 分

• 適用：ニュース、技術ブログ、動画プラットフォーム
• 理由：長時間閲覧・ページ回遊が多い。再検証が頻繁だと読書体験を損なう
• UX：長文を数本読んでも中断されない

私の技術ブログは 40 分。読者は複数記事を連続閲覧するため、30 分では足りないことがあります。

3 つのよくある誤解

誤解 1：Challenge Passage が短いほど安全
5 分に設定すれば 5 分ごとに検証、最も安全——という錯覚。

5秒盾の核心は人間と機械の区別であり、同一人物の再訪防止ではありません。真人ユーザーが通過後、5 分ごとに再検証しても、イラつかせるだけで意味がありません。

真の攻撃トラフィックは、初回で 5秒盾に止められる（Cookie 取得不可）か、高度ツールで検証を迂回する（5 分でも 30 分でも同じ）かのどちらかです。

誤解 2：数時間に設定すれば UX が向上
「2 時間にすれば UX 最高では？」——Cookie 有効期間が長いとセキュリティが大幅に低下します。

シナリオ：

1. ユーザーがカフェの公共 WiFi で 5秒盾通過
2. 離席するが Cookie は有効
3. 同じ WiFi の他者（または攻撃者）が Cookie を取得する可能性
4. 2 時間、攻撃者が Cookie で自由通行

Cloudflare が推奨上限 45 分に理由があります。勝手に延長しないでください。

誤解 3：全ルールに適用される
私もこの落とし穴にハマりました。Challenge Passage を設定しても、一部ルールで頻繁に再検証が発生。

調べた結果、Challenge Passage は Rate Limiting Rules には適用されません。

Rate Limiting でリクエスト頻度を制限している場合、Challenge Passage をいくら設定しても、レート制限に引っかかれば再検証が必要です。

設定が適切かどうかの判断

設定後、感覚だけでなくデータで確認。通常観察する指標：

1. ユーザーからの苦情
「いつも 5 秒待たされる」と言われたら、Challenge Passage が短すぎる可能性。典型的な閲覧パターンを確認し、適切な値に調整。

2. Security Events ログ
Dashboard Security → Events で日次チャレンジ発動回数を確認。同一 IP が短時間に何度も検証を受けているなら、Challenge Passage が短すぎる可能性。

3. 直帰率と滞在時間
直帰率急上昇、平均滞在時間低下——閲覧中に二次検証が発生し、離脱している可能性。

設定後 1 週間観察し、データに基づいて微調整。最初から極端な値は避けましょう。

WAF 併用のテクニック

全サイト 5秒盾 + 高頻度再検証が不要なケースも多い。WAF（Web Application Firewall）併用で効果向上：

1. WAF で明らかな悪性トラフィックをフィルタ
   • 既知の悪性 IP 帯をブロック
   • 異常 User-Agent を遮断
   • リクエスト頻度を制限
2. 5秒盾は重要パスのみ
   • Page Rules でログイン、登録、決済ページのみオン
   • その他は Medium または High
3. Challenge Passage は適切な値
   • 極端に短い周期を追求しない
   • 30 分で大多数のサイトに十分

この構成なら、90% の攻撃トラフィックを WAF がフィルタし、残り 10% の疑わしいトラフィックのみ 5秒盾検証。安全と UX を両立できます。

第5章：5秒盾運用の 7 つのベストプラクティス

実践 1：全サイト常時オン禁止

初心者が最も犯しやすいミス。攻撃を見て慌てて 5秒盾をオンにし、攻撃停止後も忘れて数ヶ月オン放置。

正しい運用：

• 明らかな攻撃時のみ一時的に有効化
• 攻撃終了後（通常 1〜3 日）、Medium または High に降格
• UptimeRobot などの監視ツールで定期チェック
• カレンダーで週 1 回セキュリティレベル確認

私は 5秒盾オン後、スマホに 48 時間アラームを設定。必ず再評価するルールです。

実践 2：Page Rules で精密保護を優先

全サイト 5秒盾は最も粗暴な方法。泥棒対策で全ドアを溶接するようなもの。重要なドアだけ施錠するのが賢明です。

重点保護パス：

1. ログインページ（/login, /wp-login.php）
2. 登録ページ（/register, /signup）
3. 管理画面（/admin, /wp-admin）
4. 決済（/checkout, /payment）
5. フォーム送信（/contact, /comment）

必ず除外するパス：

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

1. API（/api/*, /rest/*）
2. 静的リソース（/*.jpg, /*.css, /*.js）
3. RSS（/feed, /rss.xml）
4. robots.txt と sitemap.xml
5. ヘルスチェック（/health, /status）

技術ブログの理想構成：

ルール 1: example.com/wp-admin* → I'm Under Attack
ルール 2: example.com/xmlrpc.php → I'm Under Attack （WordPress 特有の攻撃対象）
ルール 3: example.com/* → Medium

実践 3：カスタム検証ページで UX 向上

デフォルトの 5秒盾ページは英語のみ。日本語ユーザーには不親切。Cloudflare 有料版でカスタマイズ可能。

カスタマイズ方法：
Custom Pages → 5-Second Shield でカスタム HTML をアップロード。

含める要素：

• サイト Logo と名称（ブランド認知）
• 日本語説明：「ブラウザの安全性を確認しています。しばらくお待ちください…」
• カウントダウンアニメーション（待ち時間を軽減）
• 簡潔な理由：「サイトを攻撃から保護するため、実在ユーザーの確認が必要です」
• 連絡先（問題発生時）

最高の事例では、5 秒待機を星集めミニゲームにして、UX を大幅改善していました。

実践 4：WAF ルールと併用

5秒盾は最終防衛線。全圧力を担わせるべきではありません。WAF が事前に大量の悪性トラフィックをフィルタできます。

推奨 WAF ルール：

ルール 1：既知の悪性 IP 帯をブロック

(ip.geoip.country in {"CN"} and cf.threat_score > 30)
→ Action: Block

（注意：例示のみ。実際はターゲットユーザーに合わせて設定）

ルール 2：異常 User-Agent を遮断

(http.user_agent contains "curl" or http.user_agent contains "python")
→ Action: Challenge

ルール 3：API リクエスト頻度制限

(http.request.uri.path contains "/api/" and rate > 100/1m)
→ Action: Block for 1h

ルール 4：ログイン保護

(http.request.uri.path eq "/wp-login.php" and rate > 5/5m)
→ Action: Challenge

これらの WAF ルールで 90% の攻撃トラフィックを事前遮断。5秒盾は少数の疑わしいトラフィックのみ処理。

実践 5：検索エンジンクローラーのホワイトリスト

SEO 問題を大幅改善。Google クローラーは理論上通過できますが、スムーズなクロールの方が常に良い。

方法 1：WAF でクローラー User-Agent を識別
WAF Custom Rule：

(http.user_agent contains "Googlebot" or
 http.user_agent contains "Bingbot" or
 http.user_agent contains "Baiduspider")
→ Skip: Security Level for this request

クローラーアクセス時に 5秒盾検証をスキップ。

方法 2：既知クローラー IP 帯のセキュリティレベルを下げる
Google、Bing などはクローラー IP 帯を公開。IP Access Rule でホワイトリスト化。

Google 公式クローラー IP リスト：
https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot

注意：
攻撃者がクローラー User-Agent を偽装する可能性。IP アドレスと User-Agent の両方検証、または DNS 逆引き検証がより安全。

実践 6：モニタリングと調整

設定は一度きりではありません。継続的なモニタリングと最適化が必要。

週次チェックリスト：

1. Security Events 確認
   • パス：Security → Events
   • 注目：遮断回数、ルール発動、ソース IP 分布
   • 判断：誤検知はないか？ルール調整は必要か？
2. Analytics 確認
   • トラフィック推移
   • 直帰率の異常
   • 平均滞在時間の低下
3. Google Search Console 確認
   • クロール統計：頻度低下はないか？
   • カバレッジ：インデックスへの影響は？
   • クロールエラー：タイムアウト・403 増加は？
4. ユーザーフィードバック
   • サポート/メールで「アクセス困難」の報告は？
   • SNS でユーザーからの不満は？

私の習慣：
毎週月曜 10 時、15 分で上記データを確認し Excel に記録。異常があれば即設定調整。

実践 7：モバイルアプリ用専用ドメイン

モバイルアプリ（iOS/Android）があるなら、API 用サブドメインを分離することを強く推奨。

アーキテクチャ：

• www.example.com — サイトフロント。5秒盾可
• api.example.com — API サービス。5秒盾オフ
• admin.example.com — 管理画面。5秒盾 + 追加検証

セキュリティ戦略：

• API ドメインは API Key または JWT Token 認証
• WAF でリクエスト頻度制限
• IP ホワイトリストでモバイルアプリ出口 IP のみ許可

メリット：

1. モバイルアプリ UX に影響なし
2. サイトフロントは安心して 5秒盾をオン可能
3. API とフロントの分離で保守容易
4. ドメインごとに異なる CDN 戦略

クライント事例：サイトは頻繁に攻撃されるが、モバイルアプリは 20 万 DAU。専用 API ドメイン導入後、攻撃時にサイト 5秒盾をオンにしてもアプリは完全無影響。

結論

要点は 3 つ：

1. 5秒盾は非常用武器であり、日常の盾ではない
車の緊急ブレーキのように、危機時に救命するが常時踏み続けるものではない。平時は Medium + WAF、攻撃時のみ I’m Under Attack。

2. Page Rules が精密制御の鍵
全サイト 5秒盾は割に合わない。Page Rules でログイン、登録、決済など重要パスのみ保護。他は低侵襲性を維持。無料版 3 本で十分な設計が可能。

3. 安全と体験のバランスは継続調整が必要
永続的に有効な設定はない。サイトタイプ、ユーザー行動、攻撃状況に応じてデータをモニタリングし、パラメータを微調整。Challenge Passage 30 分は良い出発点だが、最終的には自分のデータで判断。

アクションリスト：

• 即確認：Cloudflare の現在のセキュリティレベルは？I’m Under Attack なら本当に必要か評価
• Page Rules 設定：第 3 章のシナリオに基づき、最低 2 本のルールで精密防御
• Challenge Passage 設定：サイトタイプに合わせ 15〜45 分を選択
• テスト検証：シークレットモードで各パスを確認
• モニタリングリマインダー：週 1 回 Security Events と Analytics を確認

この記事が DDoS 攻撃と戦うサイト運営者の助けになれば幸いです。Cloudflare 5秒盾に関する経験や質問があれば、コメント欄で交流してください。