IP 不正スコアはいくつでブロックすべきか？

ブロックの基準となる IP 不正スコアのしきい値は一つではありません。同じスコアでも、ログインは通し、サインアップはレビュー対象とし、チェックアウトは 3-D セキュアに回すことがあります。 GeoIPHub の 0〜100 のスケールは、デフォルトで 25 までを許可、50 までをレビュー、75 までをステップアップ、75 超をブロックとしています。このガイドでは、2026年10月22日に 5 つの公開アドレスで検証しながら、これらのラインをアクションごとに調整します。

一つのスコア、三つの扉：しきい値に通した 5 つの IP

API からの同じ判定でも、扉ごとに異なる結果になります。そして二つのスコア上限が、共有アドレスがどこまで到達し得るかを決めます。2026年10月22日 04:56 UTC、私たちはキー不要の API で 5 つの公開アドレスをルックアップし、それぞれの結果を次のセクションの初期しきい値に当てはめました。最後の 2 行はルックアップではなく、私たちのスコアリング設定で定めている上限値です。

この表には、対応に値するポイントが四つあります。

• 二つの 100 は理由が異なります。 Tor 出口ノードの手法は tor_exit、datacenter_blocklisted、no_ptr_datacenter、known_spammer で、スパム履歴を持つ匿名化サービスです。Mullvad サーバーの手法は known_vpn_server、wireguard_open、datacenter_with_vpn_proxy、no_ptr_datacenter で、threat.is_spammer は false、DNS ブロックリストへの登録もありません。顧客が VPN を使っているなら、VPN だけが理由のブロックを MFA に切り替えるログインルールは妥当であり、そのルールが Tor 出口ノードに適用されることはありません。
• 中間の行こそ、アクション別しきい値が真価を発揮する場面です。 35 の AhrefsBot は、ログインは通過し、サインアップではフラグが立ち、チェックアウトでは 3-D セキュアに回されます。とはいえ、検証済みの SEO クローラーがこれらのフォームを送信する理由はありませんが、それはスコアだけでは分かりません。
• その中間の行は 2 週間のうちに変動しました。 同じアドレスは 10月8日には 23、10月19日には abusive_listed を手法に含んで 59（step_up）でした。10月22日にはその手法が消えてスコアは 35 になり、ログインは MFA から通常のサインインに下がりました。このアドレスについてはIP アドレスを調査する方法で詳しく解説しています。判断のたびにスコア、手法、日付を保存し、古い判定に基づいて行動する前にはルックアップをやり直してください。
• 共有アドレスはブロックに到達できません。 Private Relay の上限は 60（relay_max_score）なので、デフォルトのブロックライン 76 を超えることはありません。CGNAT の上限は 50（cgnat_max_score）で、レビュー帯の上限です。私たちの最も厳しいブロックラインであるチェックアウトの 66 は、意図的に両方より上に置いています。60 以下にすると、上限が適用されたリレーのユーザーが、アドレスを共有しているというだけで拒否されかねません。

二つの許可の行は、スコアリングが加算方式であることを示しています。リレーの relay_ip シグナルは信頼度 0.85 で 10 ポイントとなり、四捨五入すると 9 になります。Linode サーバーの datacenter_ip は 0.5 で 20 ポイントなので 10 です。ホスティングは確認する理由であってブロックする理由ではなく、リレーは通すべきです。その理由はPrivate Relay と WARP のトラフィックを検知する方法で説明しています。

ログイン、サインアップ、チェックアウトの IP 不正スコアの初期しきい値

初期しきい値は、誤って許可した場合のコストが高くなるにつれてブロックラインを厳しくします。ログインは 76、サインアップは 71、チェックアウトは 66 です。これらは出発点として扱い、自社の不正データで調整してください。

明確なケースについては、スコアにいくつかのシグナルのルールを組み合わせます。

• detection.is_tor が true のときは、どのアクションもブロックします。 理由だけで拒否が正当化される唯一のケースです。
• detection.is_relay または threat.is_cgnat が true のときは、スコアでハードブロックしないでください。 ここでは上限値がすでにそれを保証していますが、このルールは後で誰かがブロックラインを下げた場合にあなたを守ります。
• チェックアウトでは review を step_up として扱います。 私たちのIP 不正検知 API チュートリアルには、まさにこのオーバーライドを行う検証済みの Node と Python のコードに加え、ルックアップがタイムアウトした場合のフェイルソフトな処理も掲載しています。

サインアップ時に各種のアドレスが何を返すか、そしてスコアが通してしまうものを捉えるプレフィックス単位の速度制限については、サインアップ時の偽アカウント検知をお読みください。

各帯域の意味と、一つのスコアがどう構築されるかについては、まずIP 不正スコアの読み方からご覧ください。

Tor 出口ノードは 100 点、その理由は手法が示す

以下は、2026年10月22日 04:56 UTC にルックアップした 185.220.101.1 の実際のレスポンスを抜粋したものです。

fraud_score が 100 なら表のすべてのブロックラインを超えるため、ログイン、サインアップ、チェックアウトのいずれでも拒否されます。三つの理由だけでそこに到達します。tor_exit（0.99 で 45 ポイント）、known_spammer（0.9 で 40）、datacenter_blocklisted（0.75 で 30）を合計すると、100 の上限に達する前に 103 になります。Tor はそれ自体で個別にフラグが立つため detection.is_vpn は false です。そのため、detection.is_tor をハードブロックしつつ、通常の VPN ユーザーにはチャレンジを行うことができます。

四つ目の理由は、私たちの側の不備です。no_ptr_datacenter はこのアドレスに逆引き DNS がないことを示していますが、その朝 04:57 UTC に dig -x 185.220.101.1 を実行すると Tor 出口ノードのホスト名が返ってきました。私たちのデータベースにはその保存済みレコードが欠けており、修正は記録済みです。判定は他の三つのシグナルだけで成り立ちますが、これは生の合計値ではなく、信頼できるシグナルに基づいてルールを書くべき良い理由になります。

全体で一つのしきい値が失敗する理由

一つのしきい値が失敗するのは、エンドポイントごとに直面する攻撃が異なるからです。ログインページはクレデンシャルスタッフィングを受け止めます。Verizon 2025 DBIR によると、クレデンシャルスタッフィングは 1 日あたりの全認証試行の中央値で 19%、最悪の日には 44% を占めていました。チェックアウトはカードテスティングに、サインアップは偽アカウントに直面します。さらに Cloudflare Radar 2025 Year in Review によると、2025年12月2日に人間が生成した HTML リクエストはわずか 47% でした。

成熟したシステムはすでに帯域で対応しています。Cloudflare のボットスコアは 1〜99 で、顧客はそれに基づいてブロック、チャレンジ、許可のルールを書きます（Cloudflare のボットスコア）。OWASP は、IP ブロックは「回避が容易なため、唯一の、または主要な防御として使うべきではない」と述べています（OWASP Credential Stuffing Cheat Sheet）。同じページでは、MFA があればアカウント侵害の 99.9% を防げたという Microsoft の分析も引用されています。つまり、ログインのステップアップ帯は安価な保険です。NIST SP 800-63B は、想定外のジオロケーションや IP アドレスブロックは「追加のリスクベース制御の使用を促す可能性がある」とし、それが「認証要素の代わりにはならない」と述べています（NIST SP 800-63B）。

GeoIPHub は、36 の重み付けされた理由から説明可能な 0〜100 のリスクスコアを構築し、発動したすべての理由を scoring.detection_methods に記載します。スコアを下げる理由もあります。住宅用 ISP の理由は 17 ポイント（信頼度 0.85 でマイナス 20）、検証済みクローラーは 28.5 ポイント（0.95 でマイナス 30）を差し引きます。

低いしきい値は共有アドレスやプライベートなアドレスを罰する

「安全のため」に低く設定したブロックラインは、ごく普通の理由でアドレスを共有したり隠したりしている顧客を追い返してしまいます。

• VPN ユーザー。 Security.org の2026年 VPN レポート（2026年8月に米国の成人 1,008 人を対象に実施した調査）では、42% が個人用または仕事用に VPN を使っていると回答しました。主な理由は一般的なプライバシー（56%）と一般的なセキュリティ（51%）でした。
• キャリアグレード NAT。 RFC 6598 は 100.64.0.0/10 を CGNAT 用に予約しており、Cloudflare はその背後で「数百、あるいは数千ものクライアントが単一の IP アドレスから発信されているように見えることがある」と指摘しています。Cloudflare はまた、ボット率の中央値はほぼ同じ（4.8% 対 4.7%）にもかかわらず、CGNAT の IP は他の IP の 3 倍の頻度でレート制限を受けていることも明らかにしました（CGNAT に関する Cloudflare の記事）。
• iCloud Private Relay。 リレーのホップの一つを運用する Cloudflare は、Apple がデバイスとアカウントを検証しているため、不正防止に IP アドレスを使うサイトは Private Relay の接続を「信頼できる」と述べています（Private Relay に関する Cloudflare の記事）。

GeoIPHub は detection.is_mobile、detection.is_relay、threat.is_cgnat を返し、スコアを返す前に CGNAT の上限 50 とリレーの上限 60 を適用します。

正しい IP をスコアリングしなければ、どんなしきい値も無意味

偽装された X-Forwarded-For の値をスコアリングしてしまえば、調整したしきい値は実行される前に無力化されます。RFC 7239 は、クライアントを含む経路上のどのノードでも書き換えられるため、Forwarded ヘッダーは「正しいと信頼することはできない」と警告しています（RFC 7239）。MDN のルールでは、X-Forwarded-For をセキュリティ目的で使う場合は「信頼できるプロキシが追加した IP アドレスのみを使わなければならない」とされ、その IP は右端のエントリから自社で運用するプロキシの数だけさかのぼって特定します（MDN: X-Forwarded-For）。私たちは送られてきた IP をそのままスコアリングするため、まず信頼できるプロキシチェーンから IP を導き出してください。

自社の結果に基づいてしきい値を調整する

表から始め、根拠に基づいて各ラインを動かしてください。すべての判断でスコア、recommended_action、detection_methods、日付を記録し、数週間後に確定した不正やチャージバックと比較します。チェックアウトの 66 のラインが 55〜65 のチャージバックを通しているなら下げますが、Private Relay のユーザーにサービスを提供している間は 60 以下にはしないでください。サインアップの 51〜70 での確認が不正アカウントをほとんど捕捉していないなら、ラインを上げます。

無料プランでは、すべてのフィールドを含めて 1 日 1,500 回のルックアップが可能です。単一のアドレスを手作業で確認したい場合は、IP 不正スコアチェッカーでコードを書かずに同じスコアと理由を確認できます。

より幅広いシグナルについては、実際の顧客をブロックせずに匿名化トラフィックを検知する方法、住宅用とデータセンターのプロキシ不正、アカウント乗っ取りとクレデンシャルスタッフィングの阻止、引き換えの段階でプロモーションやクーポンの悪用を検知する方法、そして決済不正検知スタックにおける IP シグナルの位置付けに関するガイドをご覧ください。

よくある質問

ブロックの基準として適切な IP 不正スコアはいくつですか？

万能のしきい値は一つもありません。GeoIPHub のデフォルトの帯域では 76 以上をブロックします。私たちの初期しきい値ではログインはそのままとし、サインアップでは 71、チェックアウトでは 66 に下げています。カード非対面の不正注文は、パスワードの再入力を求めることよりはるかに大きな損失になるからです。他のプロバイダーのスケールは異なるため、どのしきい値もそのプロバイダー自身の帯域に照らして読んでください。

IP 不正スコア 75 は何を意味しますか？

GeoIPHub の 0〜100 のスケールでは、75 は step_up 帯の上限です。ブロックは 76 から始まります。黙って許可するのではなくチャレンジし、scoring.detection_methods を確認してください。VPN のシグナルによる 75 と、ブロックリストの履歴による 75 では、取るべき対応が異なるからです。実際の Tor 出口ノードが 75 に収まることはまずありません。2026年10月22日のルックアップでは、185.220.101.1 は 100、block でした。

VPN やプロキシのユーザーは自動的にブロックすべきですか？

いいえ。Security.org が2026年8月に米国の成人 1,008 人を対象に行った調査では、42% が個人用または仕事用に VPN を使っていると回答し、主な理由はプライバシーとセキュリティでした。VPN フラグは自動拒否ではなくステップアップのチャレンジを行う理由として扱い、ハードブロックは Tor 出口ノードと、スパムやブロックリストの履歴を持つアドレスに限定してください。

iCloud Private Relay や CGNAT のユーザーがスコアだけでブロックされることはありますか？

GeoIPHub のデフォルト設定ではありません。Private Relay のアドレスは 60、キャリアグレード NAT のアドレスは 50 が上限で、どちらもデフォルトのブロックライン 76 を下回ります。すべてのブロックしきい値を 60 より上に保てば、共有アドレスはスコアだけでチャレンジされることはあっても、拒否されることは決してありません。

チェックアウトのブロックしきい値がログインより低いのはなぜですか？

チェックアウトで誤って許可すると、盗まれたカードで商品が発送され、チャージバックとして返ってきます。一方、ログインで誤って許可しても、パスワードと二要素認証を通過しなければなりません。そのため、チェックアウトは 66 から、ログインは 76 からのみブロックします。