Cloudflare「I'm Under Attack」完全ガイド：SEOとUXを犠牲にしない3つの設定術
はじめに
昨年11月の深夜3時、スマホの通知音で叩き起こされました。サーバーのCPU使用率が100%に張り付き、アクセス数が通常の10倍に急増。典型的なCC攻撃（Challenge Collapsar）でした。
寝ぼけ眼でCloudflareのダッシュボードを開き、右上にある「I’m Under Attack」モードをオンにしました。30秒後、サイトの負荷は嘘のように引き、私は安堵して眠りにつきました。
しかし翌朝、SEOコンソールを見て青ざめました。インデックス登録数が激減し、クロールエラーが急増していたのです。「5秒盾」が攻撃者だけでなく、Googleのクローラーまで締め出していたからでした。
「攻撃は防ぎたいが、SEOも守りたい」。多くの管理者が抱えるこのジレンマ、実は解決策があります。5秒盾は単なるオン/オフのスイッチではありません。正しく設定すれば、攻撃を防ぎつつ、SEOとユーザー体験（UX）へのダメージを最小限に抑えることができるのです。
第1章：「5秒盾（Under Attackモード）」とは何か？
あの「5秒間」に何が起きているのか
Cloudflareの「I’m Under Attack」モードをオンにすると、訪問者はサイトを見る前に「Checking your browser…」という画面で約5秒待たされます。この間に、Cloudflareは以下の検証を行っています：
- 初期リクエスト: ブラウザがアクセスすると、Cloudflareは
__cfduidCookie（一時パス）を発行。 - JavaScript検証: クラウドフレアは難読化されたJSコードを実行させます。単純なボットや攻撃スクリプトはJSを実行できないため、ここで脱落します。
- ブラウザ指紋採取: 画面解像度、フォント、プラグインなどの情報を集め、本物のブラウザかどうか（Headless Chromeなどのツールでないか）を判断します。
- 承認: すべてクリアすると、ブラウザに
cf_clearanceという強力なCookieが付与されます。これがあれば、以降（デフォルト30分間）は検証なしでアクセスできます。
セキュリティレベルの比較
Cloudflareにはいくつかのセキュリティレベルがあります。
| レベル | 検証の厳しさ | ユーザー体験 | 推奨シーン |
|---|---|---|---|
| Low | ほぼなし | ストレスなし | API、テスト環境 |
| Medium | 脅威スコアが高いIPのみ検証 | 通常は無感 | 日常的な推奨設定 |
| High | 過去に問題があったIPを検証 | たまに検証画面 | 小規模な不審なアクセス増 |
| I’m Under Attack | 全員を検証 | 必ず5秒待つ | DDoS攻撃を受けている最中 |
私の経験上、通常時は「Medium」で十分です。「I’m Under Attack」は非常用ボタンであり、常時オンにするものではありません。
何を防げるのか？
これはレイヤー7（アプリケーション層）へのDDoS攻撃、特にCC攻撃に効果絶大です。
逆に、レイヤー3/4（UDP Floodなど）の帯域幅を埋め尽くす攻撃には、この機能は直接関係しません（Cloudflareのエッジネットワークが自動で吸収します）。
第2章：SEOとUXへの深刻な副作用
Googlebotは通過できるのか？
答えは「場合による」です。
Googlebotは最新のChromeベースなのでJSを実行でき、理論上は検証を突破できます。しかし、クローラーのリソースには限りがあります。「5秒も待たされるなら、他のページに行こう」と判断され、クロールバジェット（巡回予算）を浪費します。
私が観測したデータでは：
- クロール頻度: 1日1200回 → 400回に激減
- エラー率: タイムアウトや5xxエラーとして記録されるケースが増加
- インデックス: 新記事のインデックス速度が極端に低下
Baidu（百度）などのJS実行能力が低いクローラーに至っては、完全にブロックされてしまいます。
ユーザー体験の崩壊（直帰率の悪化）
A/Bテストを行った結果、5秒盾をオンにすると以下の数字が悪化しました：
特に深刻なのがAPIとサードパーティ連携です。
- API: スマホアプリやJSから叩くAPIは、検証画面のHTMLをJSONとしてパースしようとしてクラッシュします。
- Webhook: PayPalやStripeからの決済完了通知（Webhook）が届かなくなり、決済トラブルに発展します。
- RSS: RSSリーダーがフィードを取得できなくなります。
第3章：Page Rulesで「必要な場所だけ」守る方法（推奨設定）
全ページで5秒盾をオンにするのは愚策です。Page Rules（ページルール）を使って、守るべき場所だけをピンポイントで防御しましょう。
※無料版でも3つのルールが使えます。これで十分です。
鉄則：ルールの優先順位
Page Rulesは上から順に適用されます。一度マッチすると、それ以降のルールは無視されます。
したがって、「除外設定（APIなど）」を上に、「防御設定（ログインなど）」を下に書くのが基本です。
シナリオ1：ログイン画面と管理画面だけ守る（基本）
攻撃者が狙うのは主にログインページへの総当たり攻撃です。
- URL:
example.com/wp-admin*- Setting: Security Level → I’m Under Attack
- URL:
example.com/wp-login.php*- Setting: Security Level → I’m Under Attack
- URL:
example.com/*（その他全ページ）- Setting: Security Level → Medium
これで、一般読者は快適に閲覧でき、攻撃者が管理画面に来た時だけ5秒盾が発動します。
シナリオ2：APIを除外する
アプリを持っている場合、APIエンドポイントの除外は必須です。
- URL:
example.com/api/*- Setting: Security Level → Low (または Medium)
- Security: Disable Integrity Checks (必要に応じて)
- URL:
example.com/*- Setting: … (お好きな設定)
シナリオ3：静的リソースのパフォーマンス確保
画像やCSSに5秒盾をかける必要はありません。
- URL:
example.com/*.jpg- Setting: Security Level → Low, Cache Level → Cache Everything
達人のPage Rules構成例（WordPressブログの場合）
無料版の3枠を最大限活用するならこれです：
example.com/api/*→ Security Level: Low (APIを守る)example.com/wp-admin*→ Security Level: I’m Under Attack (管理画面をガチガチに守る)example.com/*→ Security Level: Medium (全体は標準防御)
「XML-RPC (xmlrpc.php)」も攻撃されやすいですが、これはWAFルールでブロックするのがスマートです。
第4章：Challenge Passage（検証有効期間）の最適化
一度検証を通過したユーザーを、いつまで「安全」とみなすか。それが Challenge Passage の設定です。
場所：Security → Settings → Challenge Passage
推奨設定：
- 高セキュリティ（銀行など）: 15〜20分
- 標準（EC、SaaS）: 30分（デフォルト）
- メディア・ブログ: 45分〜1時間
ブログの場合、ユーザーは長文を読んだり複数の記事を回遊します。頻繁に検証が入るとストレスなので、私は長めの45分に設定しています。
誤解: 「5分おきに検証させた方が安全」というのは間違いです。一度突破した攻撃者（Cookieを取得したボット）にとって、再検証までの時間は無意味です。むしろ正規ユーザーをイラつかせるだけです。
第5章：7つのベストプラクティス
最後に、失敗しないための運用ルールをまとめます。
- 非常用と割り切る: 全体的な「I’m Under Attack」は、攻撃を受けている最中（数時間〜数日）だけにする。平時は戻す。
- Page Rulesを活用する: 前述の通り、管理画面だけを常時オンにするのが賢い運用。
- カスタムエラーページ: Proプラン以上なら、5秒待機画面をカスタマイズできます。ロゴを入れたり、「セキュリティチェック中です」と日本語で書くだけで、ユーザーの不安は減ります。
- WAFとの併用: 5秒盾は最終防衛ラインです。その前にWAFで「特定の国の怪しいIP」や「悪質なUser-Agent」をブロックしておけば、5秒盾の出番を減らせます。
- クローラーのホワイトリスト化: WAFルールで、User-Agentに
GooglebotやBingbotが含まれる場合は検証をスキップさせる（※偽装に注意。IPアドレス検証も併用するのがベスト）。 - モニタリング: Cloudflareの「Security Events」ログを定期的に見ましょう。どのURLで検証が発動しているかを確認し、誤検知（False Positive）がないかチェックします。
- モバイルアプリ用ドメインの分離: 可能ならWeb用（
www.example.com）とAPI用（api.example.com）でサブドメインを分け、API用ドメインでは5秒盾を無効化するのが安全なアーキテクチャです。
結論
Cloudflareの5秒盾は強力な武器ですが、諸刃の剣です。
「とりあえずオン！」ではなく、**「誰を止め、誰を通すか」**を設計してください。
まずは今すぐダッシュボードを開き、Page Rules で wp-admin（またはあなたのサイトの管理画面）だけを I'm Under Attack に設定しましょう。それだけで数多くの攻撃から枕を高くして眠れるようになります。
Cloudflare 5秒盾の正攻法設定
DDoS攻撃を防ぎつつ、SEOとUXを守るためのPage Rules設定フロー
⏱️ Estimated time: 15 min
- 1
Step1: 現状把握
Cloudflareダッシュボードの「Security」>「Settings」で、現在のSecurity Levelを確認。通常は「Medium」推奨。攻撃中以外は「I'm Under Attack」になっていないか確認。 - 2
Step2: Page Rules設定（重要）
「Rules」>「Page Rules」を開く。
1. API除外ルール作成: URL「site.com/api/*」→ Security Level: Low
2. 管理画面防御ルール作成: URL「site.com/admin/*」→ Security Level: I'm Under Attack - 3
Step3: 検証期間の調整
「Security」>「Settings」>「Challenge Passage」を「30分」または「45分」に設定。ブログなら長めが吉。 - 4
Step4: 動作確認
シークレットウィンドウで管理画面とAPIにアクセスし、それぞれ意図した通りに検証画面が出るか/出ないかを確認する。
FAQ
Googlebotは5秒盾を通過できますか？
APIが動かなくなりました。なぜですか？
攻撃が終わったら設定を戻すべきですか？
5 min read · 公開日: 2025年12月1日 · 更新日: 2026年1月22日
関連記事
Next.js ファイルアップロード完全ガイド：S3/Qiniu Cloud 署名付き URL 直接アップロード実践
Next.js ファイルアップロード完全ガイド：S3/Qiniu Cloud 署名付き URL 直接アップロード実践
Next.js Eコマース実践：カートと Stripe 決済の完全実装ガイド
Next.js Eコマース実践：カートと Stripe 決済の完全実装ガイド
Next.js ユニットテスト実践：Jest + React Testing Library 完全設定ガイド
コメント
GitHubアカウントでログインしてコメントできます