何が変わったのか

Cloudflareは2026年10月9日、cf.appsec.request.failed_detections をルールで利用できると発表しました。セキュリティ検査が失敗を報告した際に、その情報を条件に使えるようにする変更です。発表日を攻撃の発生日や自分のサイトの障害発生日と混同しないでください。

WAFはWeb通信を点検して保護する仕組みです。今回の変更は、失敗した検査を自動修復する機能でも、検査結果を安全判定に置き換える機能でもありません。既存の検出動作そのものを変えず、報告された失敗をどう扱うか設計するための材料を提供します。

「検査失敗」と「攻撃検出」を分ける

荷物を調べる検査装置を例にすると、「問題のある荷物を見つけた」と「検査装置が調べきれなかった」は別の状態です。後者を、問題のある荷物がなかった証拠にはできません。この例は当サイトの説明用のたとえで、Cloudflare内部の実装を表すものではありません。

公式仕様として確認した内容は、検査失敗を報告した検出機能のIDが配列に入ることです。カスタムルール評価前の報告を扱い、重複IDは除かれます。並び順は保証されません。フィールドの原資料

当サイトの運用上の評価として、見るべきものは「防いだ件数」だけでなく「必要な検査を実施できなかった可能性」です。ただし、失敗情報だけで侵害や原因を断定せず、対象と前後の状態を確認します。

空の配列でも、全検査の成功ではない

値が [] の場合、公式の意味は「検査失敗の報告がない」です。「すべての検出機能を有効にして検査が成功した」「その通信は安全」「攻撃されていない」という意味へ広げないでください。

例えば、利用していない機能や契約に含まれない機能について、空の配列を根拠に動作を確認したことにはできません。まず自分が何を検査する設計なのかを把握します。記録の不足を安全と同一視しない考え方は、ログ点検の記事とも共通します。

どの機能・ルールで使えるか

公式資料には、コンテンツスキャン、WAF攻撃スコア、攻撃シグネチャ、漏えい認証情報の検出などのIDが記載されています。AIプロンプト関連の検出IDも含まれますが、この記事の主題はWeb保護の運用です。

対応するルールは、ゾーン・アカウントのカスタムルールとレート制限ルール、ゾーンのRequest Header Transform Rulesです。フィールドは全プランで利用できますが、未契約の検出機能やルール機能が追加で使えるようになるわけではありません。 個々の検出機能、アクション、利用条件は契約と公式資料で別に確認します。

読み取り専用の確認から始める手順

以下は当サイトの運用例です。実際の設定画面で操作した手順ではなく、保守担当と対応を決めるための確認順です。

  1. 対象を固定する：正しいアカウント・ドメインと、守りたいWeb機能を確認する。検証環境と本番を分ける。
  2. 現状を読む：有効な検出機能、契約で使えるルール、既存の適用範囲・順序・例外を確認する。仕様にない検査を実施済みとしない。
  3. 方針を決める：検査失敗時に何を確認し、誰が判断するか、業務側と決める。重要な操作と一般閲覧を同じ条件で扱わない。
  4. 承認された検証で確かめる：対象を限定し、正常な閲覧・申込・連携が設計どおり動くか、記録と戻し方も含めて確認する。
  5. 変更後に見直す：適用内容、日時、確認範囲、業務への影響、未確認事項を残す。異常時に戻せる担当と手順を明らかにする。

公式の条件式例 len(cf.appsec.request.failed_detections) gt 0 は、報告された失敗が一つ以上ある条件です。条件式だけでブロックや通知が自動設定されるわけではありません。選ぶアクションと範囲の設計は別の作業です。本記事は、この式を読者の本番へ一律に投入することを勧めていません。

架空例：申込フォームでどう役立つか

架空の申込サービスAで、入力内容の検査が必要な操作と、案内ページの閲覧があるとします。検査失敗を把握できれば、保守担当が対象操作を確認するきっかけになります。利用者への案内、受付の代替経路、再開条件を用意すると、保護と業務継続を一緒に検討できます。

一方、失敗条件に合う通信を無条件ですべて遮断すると、正当な申込や連携まで止める可能性があります。逆に、失敗時に保護を外して通すだけでは、必要な確認ができていない状態を見逃します。安全性と可用性のどちらをどこで優先するかを、担当者が明示的に判断します。特定の製品で全状況に適用できる一律の答えではありません。

点検記録の見本と注意点

  • 対象：申込サービスAの受付処理。実URLや顧客データは見本に使わない。
  • 必要な確認：有効な検査、契約上の機能、既存ルールの範囲と作用。
  • 方針：失敗時の確認担当、業務への案内、変更の承認・戻し方を決める。
  • 結果：公式仕様は確認済み。正常な申込・失敗時の処理は検証待ち。
  • 次の作業：保守担当が承認された環境で実施し、結果を業務責任者へ共有する。

秘密値や入力された本文、個人情報をそのままログ・ヘッダー・公開の質問欄へコピーしないでください。通知や監視への取り込みも個別設計であり、このフィールドが標準ログに必ず出るとは未確認のまま断定しません。

今回、当サイトのCloudflare防御設定は変更していません。導入の有用性は、失敗の報告を対策へ結び付けられる点にあります。侵害の有無や検査の完全性を保証するものではなく、公開システムの棚卸し・更新・アプリ側の認証と権限点検を置き換えるものでもありません。