グローバルに決済を受け付ける SaaS にとって、不正利用（盗難カード）の被害は売上の損失だけでは済みません。チャージバックが発生するたびに紛争手数料が上乗せされ、チャージバック率が高くなると Stripe のアカウント審査、最悪の場合は凍結につながります。Radar は Stripe 内蔵の機械学習ベース不正検知エンジンです。本記事では、基本設定のスイッチからプラン選び、そのままコピーして使えるカスタムルールのコード、そしてフロントエンド側の防御策まで、すぐに使える設定プレイブックをお届けします。
一、基本設定
Stripe ダッシュボードの Settings → Radar を開き、まず 2 つの基本スイッチを確認します：
-
Use Radar on payment methods saved for future use（保存カードのスクリーニング）
-
推奨：オンのまま維持（デフォルトでオン。Turn off は押さない）。
-
効果： ユーザーがカード登録・確認のみを行う場合（SetupIntents API 経由、即時課金なし）にも Radar のスクリーニングが作動します。攻撃者は課金が発生せず気づかれにくいカード登録エンドポイントを「カードテスティング」に悪用しがちで、このスイッチがその抜け道を塞ぎます。
-
-
Subscription fraud screening（サブスクリプションの不正スクリーニング）
-
推奨：
Manage screeningをクリックして微調整。 -
効果： サブスクリプションや定期課金があるビジネスでは、**「連続 2〜3 回の決済成功後はスクリーニングをスキップ」**に設定するのがおすすめです。何度も正常に更新している既存ユーザーのリスクは極めて低く、スキップすることで Radar の従量課金を節約でき、誤検知による突然の更新失敗も防げます。
-
二、コアルールの設定（Radar → Rules）
ブロックや検証の具体的なルールは Radar → Rules ページで設定します：
カスタムルール（Custom Rules）の追加には Radar プランのアップグレードが必要で、Plus プランを推奨します。
なぜ Plus なのか？
機能一覧を見ると、Plus はカスタムルールをサポートする最も安いプランであり、コストパフォーマンスも最良です。核心となる機能は Write and backtest custom rules（カスタムルールの作成とバックテスト）。アップグレードすれば、後述の 3DS 強制、CVC ブロック、越境 IP ブロックなどのルールを追加できるようになります。
プラン比較
注：スクリーンショットの料金はアカウント地域の関係で香港ドル（HK$）表示です。実際の料金は国・地域によって異なりますが、比較の結論は変わりません。
プラン | 料金 | 適したケース |
Plus ⭐ （第一候補） | HK$0.60 / 件 | 自分でルールを書きたいなら、これで十分。カスタムルール、取引ごとのリスクスコア、動的 3DS などに対応。 |
Pro | HK$0.80 / 件 + HK$0.04 / スクリーニング対象ユーザー | 深刻な不正利用問題（ボットによる無料トライアルの大量取得、API の自動悪用など）を抱える大規模 SaaS のみ向け。 |
Standard（デフォルト） | HK$0.00 / 件 | Stripe AI の自動ブロックのみに依存。ルールの手動追加・編集は一切不可。 |
課金モードについて
ページ左上で Pay as you go（取引ごとの従量課金）と Pay monthly（月額固定）を切り替えられます：
-
取引量が少ない / 立ち上げ期： デフォルトの
Pay as you goが最もお得。取引が発生したときだけ課金されます。 -
取引量が非常に多い：
Pay monthlyの上限付き月額の方が安くならないか試算してみましょう。
デフォルトの高リスクブロックルールを有効化
アップグレード後、Rules ページに戻り、まず Stripe 標準の高リスクブロックルールを有効にします：
-
Block if :risk_level: = 'highest'→ 【必須】Stripe AI が「最高リスク」と判定した不正取引を直接ブロックします。これが最低ラインのルールです。
-
Block if CVC verification fails based on risk score→ 【推奨】リスクがあり、かつセキュリティコード（CVC）の検証に失敗した取引をブロックします。
-
Request 3DS if 3D Secure is supported for card→ 【必要に応じて】カードが 3DS に対応していれば常に検証を要求します。安全性は最高——3DS 通過後はチャージバックの責任がカード発行銀行に移ります——が、コンバージョンはわずかに低下します。転換率を重視するビジネスは、下記カスタムルール 1 で代替できます。
コアとなるカスタムルールを追加
右上の + Add rule をクリックし、以下の 4 つのルールを順に追加します：
ルール 1：中〜高リスク取引に 3DS を強制（安全性とコンバージョンのバランス）
低リスクの正常なユーザーには何も要求せず、リスクが「elevated」と評価された取引にのみ 3DS 検証を求めます。検証を通過すれば、チャージバックの賠償責任はカード発行銀行に移ります。
-
Action：
Request 3DS -
ルールコード：
Request 3D Secure if :risk_level: = 'elevated'
ルール 2：CVC 検証失敗を直接ブロック（ハードブロック）
正規のカード保有者が CVC を間違えることはほとんどありません。CVC の失敗は、リスト型攻撃かカードテスティングとほぼ断定できます。
-
Action：
Block -
ルールコード：
Block if :cvc_check: = 'fail'
ルール 3：IP の国とカード発行国の不一致 + 中リスク以上のスコア
VPN・プロキシ経由の越境不正利用の大半をブロックします（例：米国発行のカードなのに、リクエスト IP が別の国で、リスクスコアも高め）。IP 不一致だけを条件にすると旅行者や海外出張のユーザーを誤爆するため、リスクスコア条件を重ねています。
-
Action：
Block -
ルールコード：
Block if :ip_country: != :card_country: AND :risk_score: >= 65
ルール 4：高リスクスコアを直接ブロック
:risk_score: は Stripe の機械学習モデルが各取引に付ける不正確率スコア（0〜100）です。75 点以上は、その取引がほぼ確実に不正であることを意味します。
-
Action：
Block -
ルールコード：
Block if :risk_score: >= 75
三、カードテスティングに対するフロントエンド防御
サイトが自動化されたカードテスティング攻撃を受けた場合、Radar だけに頼るとスクリーニング費用が膨らみます——Radar はブロックした取引にもスクリーニング料金が発生するからです。ゴミリクエストは Stripe に届く前に止めましょう：
-
決済・カード登録ページに Cloudflare Turnstile または reCAPTCHA を設置する。
-
決済関連の API エンドポイントに IP レート制限（Rate Limiting） を設定する。
四、設定チェックリスト
最後にチェックリストで確認：
-
✅ 保存カードのスクリーニング（SetupIntents）はオンのまま
-
✅ サブスクスクリーニングは連続 2〜3 回成功後にスキップ
-
✅ Radar Plus にアップグレードし、カスタムルールを解禁
-
✅ デフォルト高リスクルール 3 つ + カスタムルール 4 つを有効化
-
✅ フロントエンドに CAPTCHA + API レート制限
設定完了後は、数週間ごとに Radar → Insights でブロック状況を確認し、実際のトラフィックでしきい値（65 / 75 点）の調整が必要かバックテストすることをおすすめします。