Cloudflare Account Abuse Protection時代の不正対策アーキテクチャ設計
アカウント不正は「セキュリティ課題」ではなく「プロダクト信頼性課題」
近年のアカウント不正は、単なるログイン試行の増加にとどまりません。クレデンシャルスタッフィング、ボットによる大量登録、クーポンや紹介制度の悪用、使い捨てアカウントの連鎖利用などが、事業KPIを直接ゆがめます。とくに問題なのは、偽アカウントがレコメンドやスコアリングの学習データを汚染し、後続施策の精度まで落とす点です。
CloudflareがAccount Abuse Protectionを前面に出したことは、重要な潮流を示しています。つまり不正対策は「個別実装の裏方」から「プラットフォームで制御すべき中核機能」へ移っている、ということです。
単一ゲートではなく信頼ティアで守る
実運用で効くのは、以下のような信頼ティアモデルです。
- Tier 0（未知）: 新規端末・新規ネットワーク・履歴なし
- Tier 1（観察中）: アカウントはあるが信頼根拠が弱い
- Tier 2（信頼）: 行動履歴が安定し正当利用が確認できる
このティアを、登録だけでなく次の高価値導線にも適用します。
- サインアップ
- ログイン
- パスワード再設定
- クーポン適用
- 紹介リンク発行
- 支払い手段追加
登録だけ厳しくして、特典導線や回復導線が穴になる、という失敗は非常に多いです。
検知精度を上げるシグナルの選び方
IPレピュテーション単体では限界があります。以下を組み合わせて「証拠の束」で評価するのが現実的です。
- 単位時間あたりの試行速度
- ASN・地域の揺れ方
- User-Agentとブラウザ特性の整合性
- セッション継続性（Cookie/Tokenの連続性）
- 入力タイミングの人間らしさ
- チャレンジ通過品質（通過/失敗だけでなく過程）
重要なのは、検知結果を白黒判定にしないことです。信頼スコアを段階的に下げ、追加検証へ誘導する設計にすると、誤検知時のダメージを抑えられます。
ルート単位ではなくリスク単位で摩擦をかける
推奨されるレスポンス階段は次の通りです。
- Allow（許可）
- Observe（許可しつつ観測強化）
- Soft Challenge（軽い追加確認）
- Strong Challenge + Throttle（強い確認＋一時抑制）
- Deny + Cooldown（拒否＋一定時間の再試行制限）
このとき、守りのKPIだけでなく体験KPIも同時に追うべきです。
- 登録導線の誤検知率
- 決済完了率への影響
- 再設定成功率
- 攻撃変化を検知するまでの時間
「ブロック数が増えた=成功」とすると、プロダクト価値を壊しがちです。
実装はエッジ判定とアプリ判定を分離する
運用しやすい構成は、エッジ側で一次判定し、アプリ側で業務判断する二層モデルです。
- エッジでリスクラベルと根拠を生成
- アプリへ不正コンテキストをヘッダで伝達
- アプリが業務アクション（許可・保留・追加確認・審査）を決定
- 結果をイベントとして蓄積し、次回判定に反映
この分離により、業務ルールをアプリコードとしてレビュー可能に保ちつつ、検知ロジックの改善速度も上げられます。
攻撃波への即応は「緊急モード」を事前定義する
不正急増時に手作業の場当たり運用をすると、誤設定を招きます。事前に以下を定義しておくと安定します。
- Mode A: Tier 0登録のみ厳格化
- Mode B: 高価値操作にセッション証明を追加
- Mode C: 特定ASN/地域を期限付き抑制
各モードには、必ず以下を持たせます。
- オーナー
- 発動条件
- 解除条件
- サポート向け案内テンプレート
これだけで、インシデント時の意思決定速度と説明責任が大きく改善します。
まとめ
2026年の不正対策で重要なのは「もっと強くブロックする」ことではありません。正当ユーザーの体験を守りながら、成長指標の健全性を維持することです。Account Abuse Protectionを導入するなら、セキュリティ機能としてではなく、信頼性工学の対象として計測・改善し続ける設計が必要です。
