コンテンツへスキップ
不正防止

VPN 検出の誤検知:誤ってフラグが立てられるのは誰か、どう対処すべきか

実在の顧客を守る:VPN 検出の誤検知がプライバシー重視のユーザー、企業 VPN、モバイル CGNAT に及ぶ理由と、証拠に基づくスコアリングで不正を捕捉する方法。

著者GeoIPHub チーム公開日更新日読了時間20 分で読めます
ベールをかぶった発光する人影とかぶっていない人影がゲートを通過している。匿名化されていても正当なトラフィックを表している

10 年にわたり、不正対策のルールは単純でした。IP が隠れていればリスクは高い。 VPN にフラグを立て、プロキシをブロックして終わりです。2026 年には、このルールは静かに収益を失わせています。匿名化された IP の背後にいる層が変わったからです。その増加分は、最良の顧客たちです。iCloud Private Relay をオンにした iPhone ユーザー、VPN を使うプライバシー重視の購入者、数千人の隣人と 1 つのキャリアアドレスを共有するモバイルの買い手などです。加盟店の 47% が、誤拒否によって売上を失っていると報告しています。Apple も反対側の立場から、ネットワーク事業者に同じことを伝えています。「IP アドレスに依存する従来型の不正検出は、正当なユーザーに影響が出ないよう調整が必要になる場合があります」(Apple, Prepare your network for iCloud Private Relay)。

一方で、本当に止めるべきトラフィックは逆方向に変わりました。最も危険な攻撃者は、もはや明らかなデータセンターの範囲からは来ません。実在の顧客と見分けがつかない住宅用の IP を経由してやって来ます。つまり、「匿名化されたトラフィックはブロックする」という二者択一の発想は、二重に失敗します。実在のユーザーを罰し、本物の脅威を見逃すのです。両者を見分ける方法を、VPN とプロキシの検出で実際に何が見えるのかから順に見ていきます。

片側に盾、もう片側に顧客を表す点が載った軽量の天秤。VPN 検出の誤検知のコストを表している
誤拒否は、防ぐはずだった不正よりもコストが高くつく。

ブロックする側ではなく、ブロックされた側としてこのページにたどり着いた方は、誤ってフラグを立てられた訪問者にできることをお読みください。

VPN 検出の誤検知はどこから生まれるのか

VPN 検出の誤検知の大半は、ごく普通の理由で IP が隠れていたり共有されていたりする正当な人々から生まれます。匿名化トラフィックのかなりの部分は、不正とは無関係の有料ユーザーです。

  • 一般向け VPN は主流になっています。 Security.org の 2026 年 8 月の調査では、米国の成人 1,008 人のうち 42% が VPN を使っていると答えました。主な理由は一般的なプライバシー(56%)とセキュリティ(51%)で、不正に関わる動機は 1 つもありません。VPN トラフィックをすべてブロックすれば、プライバシーを重視する顧客を設計上締め出すことになります。
  • 企業 VPN と旅行者。 会社の VPN を経由する従業員や、海外から接続する顧客は、「外国」やデータセンターに近い IP から正当にアクセスしてきます。これは毎日起きていることです。
  • CGNAT の背後にいるモバイルユーザー。 キャリアは IPv4 を使い果たして久しく、モバイルネットワークはキャリアグレード NAT(CGNAT)によって、膨大な数の実在の契約者をごく少数の共有アドレスの背後に置いています。1 つのモバイル IP の背後に、数千人の正当な顧客がいることもあります。1 件の不審なセッションを理由にブロックすれば、1 区画分の実在の購入者を丸ごとブロックすることになります。この共有アドレス空間こそが、モバイルプロキシの検出を非常に難しくしている理由です。
  • Cloudflare WARP。 無料の一般消費者向けプライバシーサービスであり、不正用のプロキシではありません。WARP トラフィックの見分け方も参考にしてください。

そして、単純な検出を完全に破綻させるケースがあります。Apple iCloud Private Relay です。

iCloud Private Relay は VPN ではないので、VPN と同じようにスコア化してはいけない

Private Relay はプライバシーリレーであり、VPN ではありません。Apple 自身の概要によれば、各接続を 2 つのホップに分けることで、ユーザーと接続先の両方を把握できる当事者が存在しないようにしており、ユーザーが別の国や地域から接続しているように見せることはできません。Apple はデバイスとアカウントのレベルですべての接続を検証し、有料の iCloud+ サブスクリプションを持つ Apple デバイスにサービスを限定しています。そのため、リレー IP を匿名プロキシとしてフラグ付けすれば、検証済みの有料顧客を拒否することになります。iCloud Private Relay と WARP の検出のガイドでは、このトラフィックの見分け方と通し方を解説しています。

悪意ある側:本当の脅威はレジデンシャルプロキシ

では、何が警報を鳴らすべきなのでしょうか。それは、まさに「住宅用 IP は信頼する」という発想を打ち破るために作られたカテゴリー、レジデンシャルプロキシネットワークです。

レジデンシャルプロキシは、ISP が所有し実在の家庭や小規模事業者に割り当てられた IP を経由して、攻撃者のトラフィックを中継します。多くの場合、トロイの木馬化されたアプリや SDKが一般消費者のデバイスを黙って出口ノードとして登録することで集められます。サーバーから見れば、一般的な ISP 上の普通の顧客にしか見えません。それこそが狙いであり、Google の Threat Intelligence Group がそれを防御側にとって深刻な課題と呼ぶ理由です。GTIG が 2026 年 1 月に IPIDEA ネットワークを無力化した際、わずか 7 日間のうちに、550 を超える個別の追跡対象の脅威グループ(中国、北朝鮮、イラン、ロシアに関連する国家系の攻撃者を含む)が、SaaS への侵入、オンプレミスへのアクセス、パスワードスプレー攻撃のために IPIDEA の出口ノードを使っていることが判明しました。

これが従来のルールを破綻させる逆転現象です。データセンターの VPN は大半があなたの顧客であり、「住宅用」の IP こそが攻撃者かもしれません。しかもトラフィックの圧力は現実のものです。自動化されたボットのトラフィックは人間のウェブトラフィックを上回り、2025 年には全リクエストの 53% 超を占めました。AI エージェントという新しいカテゴリーも現れ、正当な自動化と悪用の境界はさらにあいまいになっています。IP によるボットトラフィックの検出のガイドでは、検証済みクローラーからスキャナーまで、その自動化をクラス別に整理し、IP ルックアップでどれを識別できるかを示しています。

匿名化トラフィックを実際のリスク順に並べる

匿名化手段によってリスクは同じではないため、デフォルトの対応は匿名化手段の種類で決めるべきです。最初の大まかな分類は次のとおりです。

匿名化トラフィック典型的なリスクデフォルトの対応
Apple iCloud Private Relay低(検証済みの Apple 顧客)許可。位置情報は概算として扱う
Cloudflare WARP / 一般向けプライバシーサービス低〜中許可し、行動でスコア化する
モバイル / CGNAT 共有 IP低〜中(共有)IP を決してハードブロックしない。ユーザー単位のシグナルを使う
企業 VPN / 一般向け VPN中。用途が混在スコア化し、他のシグナルが重なればチャレンジ
レジデンシャルプロキシ高(回避を目的に構築)強い証拠があればチャレンジまたはブロック
悪用されるデータセンタープロキシ / 既知のボットネット高ブロック

ここでの教訓は「すべてを信頼する」ことでも「すべてをブロックする」ことでもありません。匿名化手段の種類と、それを裏付ける証拠によって判断を決めるべきだ、ということです。

誤拒否が招くコスト

チェックアウト時の誤検知は誤拒否です。IP が匿名化されているように見えたという理由で、実在の顧客が追い返されます。加盟店の 47% が、誤拒否によって売上を失っていると報告しています。誤ってブロックされた Private Relay ユーザー、モバイルの買い物客、VPN を使う購入者の一人ひとりが、失われた売上であり、サポートへの問い合わせであり、多くの場合は二度と戻ってこない顧客です。不正は測定できますが、実在の人をブロックしたせいで成立しなかった販売は目に見えません。だからこそ、一律のブロックは安全に感じられ、実際にはそうではないのです。

実践方針:単一のフラグではなく証拠でスコア化する

解決策は、「匿名化のフラグが立っているか」ではなく、「この IP について証拠は何を示しており、どの程度確信できるか」に答える検出です。実際には次のようにします。

  • 単に「匿名」と見なすのではなく、匿名化手段の種類を特定する:Private Relay、一般向け VPN、企業 VPN、レジデンシャルプロキシ、ホスティング。リスクは大きく異なります。
  • 免責シグナルを使う:当社のモデルでは、住宅用 ISP や検証済みクローラーはスコアを下げ、Private Relay のような既知のプライバシーサービスには上限が設けられ、ブロックに達することはありません。いずれも、それ単体でリスクを上げてはいけません。
  • 共有インフラには上限を設ける:CGNAT やモバイルキャリアの範囲を、1 件の不審なセッションでハードブロックしてはいけません。その背後には数千人の実在のユーザーがいます。
  • 検出の鮮度を重みづけする:1 時間前にプロキシプールで確認された IP と、証拠が 6 か月前の古いものだけの IP とでは、まったく意味が異なります。
  • 段階的に対応する:低リスクは許可し、中間では追加の認証を求め、確度の高い不正だけをブロックします。

これがまさに、GeoIPHub の 0〜100 の不正スコアの作り方です。免責シグナルを第一級の要素として扱い、住宅用 ISP は点数を減らし、検証済みクローラーはさらに減らし、CGNAT の範囲には上限を設けるため、正当なプライバシートラフィックのスコアは低いままです。各ルックアップは、接続タイプ、プロバイダーの帰属、is_residential_proxy フラグ(ASN に基づく大まかな推定なので、証明ではなくヒントとして扱ってください)、作動した detection_methods を返します。これにより、対応し、かつその判断を説明できます。ブロックされたチェックアウトが、ブラックボックスであってはなりません。

壁ではなく、段階的な対応

2026 年 10 月 12 日に実行した 3 件の実際のルックアップを、省略して示します。最初は Apple iCloud Private Relay の出口アドレス 172.224.226.1 です。

GeoIPHub API
{ "ip": "172.224.226.1", "asn": { "org": "AKAMAI-AS - Akamai Technologies, Inc.", "connection_type": "datacenter" }, "geo": { "country_code": "GB", "city": "London" }, "detection": { "is_vpn": false, "is_proxy": false, "is_tor": false, "is_relay": true, "is_anonymous": false, "relay_provider": "iCloud Private Relay" }, "scoring": { "fraud_score": 24, "recommended_action": "allow", "detection_methods": ["datacenter_ip", "no_ptr_datacenter", "relay_ip"] } }

2 件目は Tor 出口ノードの 185.220.101.1 です。

GeoIPHub API
{ "ip": "185.220.101.1", "asn": { "org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit", "connection_type": "datacenter" }, "geo": { "country_code": "DE", "city": "Hamburg (Hamburg-Nord)" }, "detection": { "is_vpn": false, "is_proxy": false, "is_tor": true, "is_relay": false, "is_anonymous": true, "anonymity_level": "high" }, "threat": { "is_spammer": true, "threat_types": ["spammer", "tor"] }, "scoring": { "fraud_score": 100, "recommended_action": "block", "detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"] } }

どちらのアドレスもデータセンターのネットワーク上にあり、どちらもユーザーの自宅 IP を隠しています。Private Relay のアドレスはリレーとして識別され、匿名とはマークされず、スコアは 24 で allow です。Tor 出口はさらにスパムのブロックリストにも載っており、スコアは 100 で block です。同じルックアップでも、証拠が違うので結果は正反対になります。

3 件目は、多くの VPN ルールが誤りやすいケースである、マルメの Mullvad VPN サーバー 45.83.220.7 です。

GeoIPHub API
{ "ip": "45.83.220.7", "asn": { "org": "ESAB-AS - 31173 Services AB", "connection_type": "datacenter" }, "geo": { "country_code": "SE", "city": "Malmö" }, "detection": { "is_vpn": true, "is_hosting": true, "is_anonymous": true, "vpn_provider": "Mullvad (31173 Services)", "vpn_confidence": 85 }, "threat": { "is_abusive": false, "is_spammer": false, "threat_types": ["vpn"] }, "scoring": { "fraud_score": 46, "recommended_action": "review", "detection_methods": ["known_vpn_server", "datacenter_ip"] } }

この VPN は高い信頼度で名前まで特定されていますが、レコード内に悪用を示す他の証拠がないため、スコアは 46 にとどまり、対応は block ではなく review です。「is_vpn ならブロック」という二者択一のルールなら、このユーザーを拒否していたでしょう。段階的なポリシーなら、リスクの低い操作は通し、リスクに見合う場面でのみ追加の認証を求めます。レジデンシャルプロキシのフラグも同様に慎重に扱うべきです。GeoIPHub は ASN データからレジデンシャルプロキシの状態を大まかに推定しているだけなので、他の最近の証拠が裏付ける場合にのみ、チャレンジやブロックの根拠とすべきです。

Private Relay や VPN エンドポイントを含め、あらゆるアドレスがどうスコア化されるかは、無料の VPN とプロキシの検出テストと IP 不正スコアチェッカーで確認できます。スコアの算出方法を詳しく知りたい方は、検出方法論と完全な API リファレンスをご覧ください。

レジデンシャルプロキシは捕捉し、iPhone の顧客は決済まで通す

匿名化されたインターネットは、それ自体がもはや不正のシグナルではありません。Apple Private Relay、WARP、企業 VPN、モバイル CGNAT によって、実在の顧客が「隠れた」IP の背後にいる一方で、本物の攻撃者は正当に見えるよう設計された住宅用の範囲に潜んでいます。2026 年でも通用する検出は、IP が匿名化されているかどうかを問いません。どの種類なのか、どれだけ最近のことか、どんな裏付けがあるのかを問い、それに見合った対応をします。レジデンシャルプロキシの不正は捕捉し、iPhone の顧客はチェックアウトさせましょう。

よくある質問

VPN 検出の誤検知はなぜ起きるのですか?

隠蔽された IP や共有された IP をすべて不正とみなすルールが原因です。このルールは、一般向け VPN を使うプライバシー重視の購入者、企業 VPN 経由の従業員、旅行者、CGNAT で 1 つのキャリア IP を共有するモバイルユーザー、Apple iCloud Private Relay のユーザーにフラグを立てます。その大半は正当な顧客であるため、IP だけを根拠にブロックすると、そうした顧客を締め出すことになります。

iCloud Private Relay をブロックすると誤検知が起きますか?

はい。Private Relay は VPN ではありません。Apple は各接続を 2 つのホップ経由で中継し、有料の iCloud+ サブスクリプションを持つ Apple デバイスにサービスを限定しており、ユーザーが別の国から接続しているように見せることもできません。Apple のネットワーク事業者向けガイダンスは、IP アドレスに依存する従来型の不正検出は、正当なユーザーに影響が出ないよう調整が必要になる場合があると警告しています。リレー IP は低リスクとして扱い、不正対策のルールはアカウントとセッションのシグナルで運用してください。

実際に危険な匿名化トラフィックはどれですか?

本当に高リスクなのはレジデンシャルプロキシネットワークです。トロイの木馬化されたアプリ経由で集められた、ISP 所有の実在する家庭の IP を通じて攻撃者のトラフィックを中継するため、正当なユーザーに紛れ込みます。Google は 2026 年 1 月に IPIDEA ネットワークを無力化した際、わずか 1 週間のうちに 550 以上の追跡対象の脅威グループがその出口ノードを使っていることを確認しました。市販の VPN や Private Relay は大半が正当な利用ですが、レジデンシャルプロキシが正当であることはまれです。

VPN とプロキシのトラフィックをすべてブロックするのが悪い考えなのはなぜですか?

その大部分が実在の顧客だからです。米国の成人のおよそ 3 分の 1 が VPN を使っており、その目的は不正ではなく圧倒的にプライバシーとセキュリティです。またモバイルユーザーは CGNAT によって 1 つのキャリア IP を日常的に共有しています。こうした IP をハードブロックすると誤拒否が発生し、加盟店の 47% が誤拒否によって売上を失っていると報告しています。目指すべきは一律のブロックではなく、段階的なリスクスコアリングです。

GeoIPHub はどのように誤検知を避けていますか?

フラグが立っているという事実だけでなく、証拠に基づいてスコアを付けます。0〜100 の不正スコアには免責シグナルが含まれ(住宅用 ISP は点数を減らし、検証済みクローラーはさらに減らし、CGNAT の範囲には上限が設けられます)、各ルックアップは接続タイプ、プロバイダーの帰属、検出の鮮度(last_seen)、作動した detection_methods を返します。そのため、本当にリスクの高いものにはチャレンジを課し、実在の顧客は通すことができます。

執筆者

GeoIPHub チーム

GeoIPHub API を支えるチーム

GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。

この記事をシェア
その他の記事

関連 記事