Web開発の現場では、セキュリティ対策をどこまで、どのように実装するかが常に問題になります。予算の制約がある地方中小企業のなかには、セキュリティ対策を後回しにしたり、実装方法を誤解したりするケースが少なくありません。Cloudflareは、DDoS防御からWAF（ウェブアプリケーションファイアウォール）まで、エンタープライズレベルのセキュリティ機能を無料で提供するセキュリティプラットフォームです。ネットワークエッジでのトラフィック制御、ルールエンジンによる悪質リクエスト判定、アプリケーション層の脅威検出という3層構造を持ち、これらを正確に設定することで初めて正当なユーザーをブロックしない堅牢なセキュリティが実現します。しかし、その機能を正しく理解し、設定値を適切に調整しなければ、かえってサイトへのアクセス遮断につながる可能性があります。本記事では、Cloudflareを活用したWeb開発のセキュリティ対策の実装方法と、現場で陥りやすい落とし穴を、京谷商会の実践事例に基づいて解説します。
Cloudflareのセキュリティ層が3つに分かれている理由と、各層の役割
Cloudflareのセキュリティ対策は、第1層のDDoS防御、第2層のルールエンジン、第3層のWAFという3つの層で構成され、これらが協調することで初めて多層防御が機能します。第1層のDDoS防御はネットワークエッジで大量のリクエストからサーバーを守り、第2層のルールエンジンは特定パターンの悪質トラフィックを自動判定し、第3層のWAFはSQLインジェクションやクロスサイトスクリプティング（XSS）といった既知の攻撃をブロックします。
Cloudflareの無料プランであっても、DDoS防御とWAFの基本機能は有効化されています。しかし初期設定では、ルールが過度に厳しい場合があります。京谷商会で運用する22サイトのうち、導入初期に「403エラーが頻発する」という相談があったケースは、ルール感度の調整で解決しました。実際、Cloudflareのセキュリティルールは段階的に強度を変更でき、事業の特性に合わせた微調整が可能です。
各層が何を守っているかを理解することが重要です。第1層のDDoS防御は、一般的なビジネスサイトでは月間トラフィック全体の0.5～1.5%程度の攻撃リクエストをフィルタリングします。第2層のルールエンジンは、ボットによる自動スクレイピングやブルートフォース攻撃を検出し、チャレンジ画面（人間確認画面）の表示やブロック判定を実施します。第3層のWAFは、既知の脆弱性パターンに基づく攻撃を防ぎます。これらが協調することで、初めて多層防御が機能するのです。
セキュリティレベルを過剰に設定した製造業A社が直面した、顧客信頼の喪失
Cloudflareの初期設定でよく起きる失敗が、セキュリティルール感度の過剰設定です。特にWAFの「Challenge」モード（人間確認画面の表示）や「Block」モード（完全遮断）の設定値を調べずに有効化すると、スマートフォンから申し込みフォームにアクセスした顧客が、いきなり「人間であることを確認してください」という画面を見せられることになります。
Cloudflareを導入した直後、既存取引先の企業担当者が問い合わせフォームを使おうとした際にチャレンジ画面が出現し、「このサイトは怪しいのではないか」と不信感を持たれた事例があります。製造業A社では、WAF感度が「High」に設定されており、特定のユーザーエージェント（モバイルブラウザの古いバージョンなど）や地域からのアクセスが自動的に疑わしいと判定されていました。その結果、月間で正当な営業問い合わせが5～10件程度フィルタリングされ、ビジネスチャンスの喪失につながっていました。
このような失敗を防ぐには、Cloudflareのセキュリティレベルを段階的に上げることが重要です。以下の表は、Cloudflareのセキュリティ設定とそれぞれの影響範囲を比較したものです。
| セキュリティレベル | 説明 | ユーザーへの影響 | 推奨用途 |
|---|---|---|---|
| Essentially Off | DDoS防御のみ有効 | 影響なし | テスト環境、開発サーバー |
| Low | 基本的なボット検知のみ | ほぼなし | ブログ、コンテンツサイト |
| Medium | 簡易的なチャレンジ画面が表示される可能性 | 稀に表示 | 商用サイト、BtoB営業サイト |
| High | より多くの疑わしいトラフィックをブロック | 誤検知が増加 | 金融機関、医療機関向けAPI |
| Under Attack | 全てのアクセスにチャレンジ | 高確率で表示 | DDoS攻撃中の緊急対応 |
一般向けWebサイトやEコマース、申し込みフォームを持つBtoB営業サイトであれば、初期値は「Low」または「Medium」に設定し、実アクセスのブロック状況を監視したうえで「High」への引き上げを判断すべきです。 急いで最強の防御を導入しても、顧客を遠ざけては本末転倒なのです。
WAFルールの個別理解を怠った小売業B社が経験した、月200件の検索機能放棄
次に多い失敗が、WAFの個別ルールを理解しないまま「すべて有効化」してしまうケースです。Cloudflareには100個を超えるWAFルールが用意されており、各ルールはOWASPの既知脆弱性パターンに対応しています。しかし、ルールの粒度は非常に細かく、特定の業種や機能に固有のルールもあります。
小売業B社では、商品検索フォームで複雑な検索条件を許可していました。「SQLインジェクション検出ルール」を最大感度で有効化したところ、ユーザーが「品名 AND 価格範囲」といった複数キーワード検索を試みるたびに、正当な検索クエリが遮断されてしまいました。この誤検知は、月間で約200件のユーザーが検索機能を放棄してサイトを離脱する原因になっていました。実装改善後、除外ルールを設定することで離脱率は70%低下し、月間で約140件の検索が復活しました。
正しい対策は、事業に不要なルールを無効化し、事業上必要なトラフィックパターンをホワイトリスト登録することです。Cloudflareではカスタムルール（ファイアウォールルール）機能を使い、「このIPアドレスからのアクセスはWAFを除外」という設定ができます。加えて、「このURLパターンへのアクセスにはSQLインジェクション検出ルールを適用しない」という柔軟な除外設定も可能です。Cloudflare WAFルール設定ガイドを参考に、自社の業務フロー別に除外ルールを段階的に追加することが現実的です。
セキュリティ設定の効果を検証する3つの指標
セキュリティ対策の効果を検証することは、実装と同じくらい重要です。Cloudflareのダッシュボードから「Security」タブを開き、脅威検出数・チャレンジ表示回数・ブロック数の3つを毎週確認することで、設定の過不足を検出できます。
Cloudflareの「Analytics」→「Security」セクションでは、過去7日間の脅威検出数、チャレンジ画面の表示回数、ブロックされたリクエスト数がグラフで表示されます。京谷商会では、この数字を毎週確認し、異常値が出ていないかチェックしています。具体的には、「チャレンジ画面の表示が急増した」場合は、最近のルール追加や感度変更を確認し、根拠のない誤検知がないかを調査します。一方、「脅威検出数がゼロに近い」場合は、設定が弱すぎる可能性があります。京谷商会の実装経験に基づけば、一般的なビジネスサイト（BtoB営業サイト、小売業向けEコマース）では月間のブロックトラフィックが全体の1～3%程度が目安となります。これは社内ネットワークからの管理アクセスや既知の脅威IPをフィルタリングした上での数字です。
ダッシュボードのブロック理由の内訳（DDoS、ボット、WAFルール別）を確認し、「どのルールが最も多く検出しているか」を把握することが次のステップです。このデータから、そのルールが事業に必要かどうかを判断します。不要なルールは無効化し、必要なルール内での誤検知を減らすというアプローチが現実的です。Cloudflare DDoS防御の仕組みに関する詳細については公式ドキュメントを参照してください。
Cloudflareセキュリティ設定の実装チェックリスト
Cloudflareを導入した直後に確認すべき設定項目は以下の通りです。これらを段階的にチェックすることで、誤検知による顧客喪失を防ぎながら、セキュリティレベルを適切に調整できます。
- セキュリティレベルの初期値確認：ダッシュボード「Security」→「Settings」で現在の設定値を確認。Webサイトの属性に応じて「Low」「Medium」「High」を使い分ける
- WAFルール感度の調査：有効になっているWAFルールの一覧を取得し、事業上不要なルールをリスト化。無効化の判断を経営判断で行う
- セキュリティダッシュボードの定期監視：週1回以上、ブロック数・チャレンジ表示数の推移を確認。異常値が出た場合は即座に原因調査
- ホワイトリスト設定：VPN、社内ネットワーク、取引先企業など、恒常的にアクセスする正当なIPアドレスをホワイトリストに登録
- カスタムルールの活用：一般ユーザーと管理者のアクセスを分離する場合、管理画面へのアクセスをIP制限するカスタムルールを設定
これらのチェック項目を実装することで、Cloudflareのセキュリティ機能を事業の阻害なく運用できます。
よくある質問
CloudflareのチャレンジスクリーンとWebサイトの脅威は関係があるのでしょうか？
いいえ、Cloudflareのチャレンジスクリーン（「人間であることを確認してください」という画面）が表示されたからといって、そのWebサイトが詐欺や脅威を配信しているわけではありません。これはセキュリティ機能が、正当なユーザーからのアクセスをボットと区別するためのチェック機能です。むしろ、チャレンジスクリーンが表示される仕組みが備わっていることは、セキュリティ対策が実装されている証拠であり、サイトの安全性が高いと判断できます。ただし、チャレンジスクリーンの頻出は、セキュリティ感度が過度に高い可能性を示しているため、サイト運営者に改善を求める根拠になります。
HTTP 403エラーが表示された時、ユーザー側でできることはありますか？
HTTP 403エラーは、リクエストがサーバーに到達したものの、アクセス権限がないという意味です。Cloudflareの場合、このエラーは通常、WAFルールまたはセキュリティルールによってリクエストがブロックされたときに表示されます。ユーザー側でできることは①キャッシュをクリア、②ブラウザを変更、③VPN経由でアクセス、といった方法を試すことです。複数の方法を試してもエラーが続く場合は、サイト運営者に問い合わせてください。
Cloudflareの無料プランのセキュリティ機能は、有料プランと比べてどの程度劣っているのでしょうか？
Cloudflareの無料プランでも、DDoS防御、基本的なWAFルール、レート制限機能は有効です。有料プランとの主な違いは、WAFルール数の制限（無料は約100ルール、Pro以上は200ルール以上）、カスタムルールの作成上限（無料は5ルール、Pro以上は20ルール以上）、ページルール（リダイレクト・キャッシュ制御）の数です。大多数の地方中小企業のWebサイトであれば、無料プランのセキュリティ機能で十分対応可能であり、わざわざ有料化する必要はありません。むしろ、無料プランの機能を完全に使いこなすことが先決です。