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

プロモーション不正利用:クーポンと紹介プログラムの不正を検知して止める方法

プロモーション不正利用とは、1人の運営者が多数の新規顧客になりすます行為です。4件の実際のIPルックアップから、利用元アドレスによってクーポンの処理をどう変えるべきかを示します。

著者GeoIPHub チーム公開日更新日読了時間25 分で読めます
ひとつの光の網に捕らえられたクーポンの形。プロモーション不正利用のリングを表している

プロモーション不正利用とは、1人の運営者が多数の新規顧客になりすまして、クーポン、紹介ボーナス、登録クレジットを集める行為です。偽アカウントも必ずネットワークアドレスから接続するため、利用(リデンプション)の段階で捉えることができます。そしてそのアドレスの種類によって、特典を適用するのか、保留するのか、追加確認を求めるのか、適用しないのかが決まります。この記事では、手口の仕組み、2026-10-23 に調べた実在の利用元アドレス4件に対して私たちが取る対応、IP 不正スコアと allow から block までの区分の背後にあるシグナル、そして IP レイヤーが見えなくなる場所を順に説明します。

自己紹介の不正を表す、ループ状に閉じる紹介の連鎖
紹介のループは自分自身で閉じます。IP シグナルがその場所を示します。

プロモーション不正利用とは何を指すか

この呼び名には6種類の異なる手口が含まれ、それぞれ対応が異なります。

手口仕組み主な標的
新規顧客クーポンのファーミング1人の運営者が「初回」アカウントを繰り返し作り、導入割引を再利用するEC、デリバリー、サブスクリプション
紹介リング(自己紹介)同じ運営者が紹介者と被紹介者を操作するため、偽の登録のたびにボーナスが二重に支払われるマーケットプレイス、フィンテック、ギグ系プラットフォーム
登録・ボーナスのファーミング大量のアカウントを作成してクレジット、ウェルカムボーナス、エアドロップを収穫するフィンテック、iGaming、暗号資産
コードの総当たりボットが推測しやすいバウチャーコードを、有効なものが返るまで試す短いコードや連番コードを使うすべてのサイト
併用と不具合の悪用コードを重ねて使ったり、想定された上限を超えて利用ロジックを悪用したりする小売のチェックアウトフロー
ロイヤルティ・ポイントのファーミング偽または自動化された活動で、交換可能なポイントを積み上げる航空会社、ホテル、小売のロイヤルティ

OWASP は、自動化された手口を Automated Threats プロジェクトで分類しています。OAT-002 Token Cracking は「クーポン番号、バウチャーコード、割引トークンなどの大量の総当たり」(mass enumeration of coupon numbers, voucher codes, discount tokens, etc.)、OAT-019 Account Creation は「その後の悪用のために複数のアカウントを作成すること」(create multiple accounts for subsequent misuse)です。表の6種類のうち5つは、この2つの基本手口の上に成り立っています。併用だけは例外で、本人確認ではなくチェックアウトのロジックを突く手口だからです。

クーポン・紹介不正がいま拡大している理由

クーポン・紹介不正が拡大しているのは、損失額が数十億ドル規模に達し、そのツールがサービスとして販売されているからです。

金額は深刻です。Juniper Research は、デジタル商品の不正が 2025年の104億ドルから2030年には270億ドルへ、162%増加すると予測し、プロモーション不正利用を、合成ID、フレンドリー詐欺と並ぶ3つの主要因のひとつに挙げています(Juniper Research、2025年12月)。失われた1ドルの損失は、1ドルでは済みません。LexisNexis の True Cost of Fraud 調査によると、人件費や間接費を含めた米国の小売・EC事業者の平均コストは、不正1ドルあたり4.61ドルです(LexisNexis Risk Solutions、2025年4月)。

ツールも産業化しています。アカウント作成ボット、アンチ検知ブラウザ、エイリアスのメール、レンタルのプロキシプールによって、1人の運営者が多数の顧客を装えるようになりました。

手口の内側:1人の運営者が多数の新規顧客になる仕組み

どの手口も行き着く先は同じです。多数のアカウントと1人の運営者、そしてその下にある共有インフラです。公開されている2つの事例が両端を示しています。

身元盗用型の端。 2021年5月、マサチューセッツ州の連邦検察は、2019年1月から少なくとも2021年4月まで続いた計画で19人を起訴しました。この計画は、2,000件を超える盗まれた身元を使って配車・デリバリーアプリのドライバーアカウントを開設し、他の偽アカウントを紹介することだけを「唯一の目的」(sole purpose)とする偽アカウントを作り、収入を水増しするために「自動化されたボットと GPS スプーフィング技術」を使っていました(NBC Boston、2021年5月)。2022年には被告のうち2人が、通信詐欺の共謀と加重身元盗用について有罪を認めました。これとは別に、サンディエゴで起訴された5人組のドライバーアカウント・リングは、首謀者の量刑で決着しました。

純粋なマルチアカウント型の端。 トークンのエアドロップは対象ウォレットごとに支払われるため、ファーマーは身元ではなくウォレットを大量に作ります。zkSync は2024年6月のエアドロップの後、シビル対策のフィルタリングについて、これ以上厳しくすると「多くの一般ユーザーを誤ってフラグ付けするおそれがある」(might falsely flag many organic users)と述べて擁護しました(Cointelegraph、2024年6月)。これはすべてのプロモーション担当チームが直面するのと同じトレードオフです。フィルターを厳しくするとファーマーは多く捕まりますが、本物の顧客も多く断ってしまいます。

両者には共通の弱点があります。偽の身元は安く、メールアドレスは無料ですが、アカウントはどこかから必ず接続します。きれいで、互いに異なる一般消費者のネットワーク拠点は、リングが好きなだけ作り出せない唯一の資源です。そのためインフラを使い回し、使い回しはログに現れます。

2026-10-23 に調べた4つの利用元 IP

同じプロモーションでも、アドレスの種類が4つあれば4通りの対応が必要です。そして4つのうち2つでは、不正スコア自体の recommended_action はプロモーションの判断と一致しません。 2026-10-23 の 05:03:02 から 05:03:17 UTC にかけて、クーポンや紹介のエンドポイントが目にする種類を1つずつ代表する4つの公開アドレスに対し、キー不要のルックアップを実行しました。実際の利用リクエストは送っていません。これらは利用元の種類の代表例です。

利用元 IP(種類)fraud_scorerecommended_action発火した検知手法クーポン・紹介フローの対応
45.33.32.156(Linode のサーバー、scanme.nmap.org)10allowdatacenter_ipレビューのため保留。 販売は通常価格で通し、割引は保留キューに入れる
185.213.155.73(Mullvad のサーバー、フランクフルト)100blockknown_vpn_server、wireguard_open、datacenter_with_vpn_proxy、no_ptr_datacenterステップアップ。 特典を適用する前にカードまたは電話番号の確認を求める
104.28.46.99(iCloud Private Relay の出口)9allowrelay_ip適用する。 ただしプレフィックス単位のベロシティルールには数える
185.220.101.1(Tor 出口、ハンブルク)100blocktor_exit、datacenter_blocklisted、no_ptr_datacenter、known_spammer特典を適用しない。 通常価格での販売は通してかまわない

この2つの不一致が要点です。Linode のサーバーはスコア10で allow です。単なるクラウドサーバーは不正ではなく、API、連携、モニタリングは一日中クラウドから動いているからです。しかし、初回注文のクーポンをサーバーラックから請求する正当な理由はありません。Mullvad の出口はスコア100で block です。API が Mullvad 自身のサーバー一覧と照合し、WireGuard サーバーとしてタグ付けされていることを確認したためです。ただし、2026年8月に米国の成人1,008人を対象にした Security.org の 2026年 VPN レポートでは、42%が VPN を使っており、VPN 経由の利用は本物の顧客であることも多いと言えます。カードや SMS の確認は、その顧客には数秒の手間で済みますが、リングにとってはアカウントごとに決済カードか電話番号が1つ必要になります。

ホスティングアドレスのルックアップ結果を省略して示します(保存されている PTR は実際の逆引き DNS と一致しないため除いています)。

GeoIPHub API
{ "ip": "45.33.32.156", "asn": { "asn": 63949, "org": "AKAMAI-LINODE-AP - Akamai Connected Cloud", "asn_type": "hosting", "connection_type": "datacenter" }, "detection": { "is_proxy": false, "is_vpn": false, "is_tor": false, "is_hosting": true, "is_relay": false, "anonymity_level": "low" }, "threat": { "is_cgnat": false }, "scoring": { "fraud_score": 10, "confidence": 0.25, "recommended_action": "allow", "detection_methods": ["datacenter_ip"] } }

したがって、ルールでは detection.is_hosting と asn.connection_type を直接読む必要があります。block を待つルールでは、このクーポンを支払ってしまうからです。この記事の以前の版では DigitalOcean のドロップレット 104.248.50.21 を使っていました。2026-10-23 の時点で、そのスコアは 12 で、datacenter_ip に加えて fcrdns_mismatch が発火していました。これはクーポンとは無関係の逆引き DNS シグナルなので、サンプルを差し替えました。

リレーの出口はその逆のケースです。

GeoIPHub API
{ "ip": "104.28.46.99", "asn": { "asn": 13335, "org": "CLOUDFLARENET - Cloudflare, Inc.", "user_type": "consumer_privacy_network" }, "detection": { "is_proxy": false, "is_vpn": false, "is_hosting": false, "is_relay": true, "anonymity_level": "medium", "relay_provider": "iCloud Private Relay" }, "scoring": { "fraud_score": 9, "recommended_action": "allow", "detection_methods": ["relay_ip"] } }

is_relay は true で、is_proxy と is_vpn は false です。これは iCloud+ のプライベートリレーを有効にしている Apple ユーザーであり、リレーからの利用が1件あっても、それは1人の顧客です。Tor 出口には anonymity_level: "high" と Spamhaus ZEN への掲載があり、そのため特典を適用しないことの代償は小さくて済みます。

共有アドレスにはブロックではなくベロシティルール

GeoIPHub では設計上、共有アドレスをスコアだけでブロックすることはありません。 キャリアグレードNATのアドレスは上限が50で review の範囲内、iCloud Private Relay のアドレスは上限が60で step_up の範囲内です。どちらかをブロックすれば、その背後にいる本物の顧客全員をブロックすることになります。そのため、そこに隠れたリングはスコアリングではなくカウントで捉えます。

  • IPv4: 1つのプロモーションの利用回数を、/24 ごと、1時間ごとに数えます。出発点としておすすめするのは3回です(これは業界で計測された値ではなく、私たちの提案値です)。同じ /24 からの4回目以降の利用はレビューのために保留し、その後は自社の結果を見て数値を調整してください。
  • IPv6: 完全なアドレスではなく /64 単位で数えます。通常は1人の契約者が /64 全体を保有しているため、その中でアドレスを切り替えるのは無料です。完全なアドレスをキーにすると、1人の行為者が数千人に見えてしまいます。家庭や事業所が /56 や /48 を持っていることも多いので、同じ割り当てから新しい /64 が出続ける場合は、その範囲まで広げてください(IPv6 を /64 でレート制限・ブロックする方法を参照)。
  • リレーと CGNAT: 同じカウンターを使いますが、しきい値は引き上げます。1つのリレー出口やキャリアのアドレスが、正当に多くの顧客を担うからです。

プロモーション不正利用を浮かび上がらせる IP シグナル

プロモーション不正利用を浮かび上がらせる IP シグナルは3つあります。「別人」の顧客にまたがる共有の利用元、ホスティング由来、そして利用の段階に集中する匿名化です。 それぞれが、アカウント単位のチェックでは見逃される連携を明らかにします。

「別人」の顧客にまたがる共有の利用元。 多数の新規アカウントが、1つのアドレス、/24、/64 から同じプロモーションを利用することは、最も単純なシグナルで、上記のベロシティルールがこれを判断に変えます。

消費者がいるはずの場所にあるホスティング範囲。 本物の新規顧客は、自宅のブロードバンドや携帯回線から利用します。クラウドのインスタンス、VPS プロバイダ、ホスティング ASN といったデータセンター IP の範囲からの利用は、そうでないと確認できるまでスクリプトと見なします。GeoIPHub は、厳選した853のホスティング ASN と、10のクラウドプロバイダの公式範囲からホスティングを分類しており、これがプロモーション適用資格に対する最も手軽な一次フィルターになります。

利用の段階に集中する匿名化。 通常の閲覧での VPN や Tor のフラグは、弱い証拠です。しかし同じフラグが紹介の送信やコードの利用で急増している場合は別です。運営者が共有の利用元チェックをかわすために、出口を切り替えているのです。

共有 IP は普通のことなので、これらは「より詳しく見る理由」として扱います。 Cloudflare は、CGNAT の IP は他の IP より3倍多くレート制限されているものの、ボット率の中央値はほぼ同じ(4.8% 対 4.7%)であることを明らかにしました(Cloudflare、2025年10月)。CGNAT のフラグは、対応を強めるのではなく和らげるために使うべきです。

IP レイヤーが見えなくなる場所:住宅用プロキシとクリックファーム

IP ルックアップでは、住宅用プロキシ経由の利用や、本物の自宅・携帯回線上にあるクリックファームの端末からの利用は見えません。 それらの接続は一般消費者向け ISP のアドレスから来ており、本物の新規顧客とまったく同じに見えます。GeoIPHub は住宅用プロキシを検知しません。自宅の ISP アドレスには、スコアを20下げる住宅 ISP シグナルが付くこともあります。

住宅用の出口を借りているリングは、ネットワークチェックをかわすために対価を払っているので、証拠は別の場所から得る必要があります。

  • アカウントグラフ上のベロシティ。 IP に関係なく、1人の紹介者に数時間のうちに多数の被紹介者が計上される状況です。
  • 端末の重複。 アドレスが異なっていても、同じ端末フィンガープリントを共有するアカウントです。
  • 決済情報・連絡先の重複。 複数の「新規」顧客の背後に、1枚のカード、1つの銀行口座、1つの電話番号があるケースです。
  • コホートの質。 2回目の購入をしない利用者です。

レンタルした住宅用の出口がなぜ最も判断しにくい利用元なのかについては、住宅用プロキシ詐欺と、信頼できる IP がいまやリスクになる理由を参照してください。この問題の一般的な形については、マルチアカウント検知で、1人のユーザーがどのように50人になるのかを説明しています。

今週出せる検知プレイブック

検知がうまく機能するのは、3つのイベントをスコアリングし、特典に対して対処し、アカウントではなくリングをレビューするときです。

  1. 1つではなく3つのイベントを計測する。 登録、紹介の送信、利用の各時点で、IP とそのシグナルを記録します。多くのチームは登録しかスコアリングしていませんが(そのチェックは偽の登録を止める方法で扱っています)、不正は利用の段階に集中します。
  2. 紹介者と被紹介者の両方をスコアリングする。 自己紹介のループでは、両側が同じ運営者です。勧誘した相手が1つの /24、1つの ASN、1つの VPN プロバイダに集中している紹介者は、リング自身の帳簿だと言えます。
  3. プロモーションごとに /24 と /64 単位でベロシティを測る。 上述のとおり、全体ではなくキャンペーンごとに数えます。
  4. 購入ではなく、プロモーションの適用資格をゲートする。 利用の段階でホスティング由来、Tor 出口、過去の不正履歴が見つかった場合は、通常価格での販売は進めつつ割引を見送ります。これで利益を断ちながら、サポート問い合わせを生まずに済みます。
  5. 中間の区分は確認に回す。 スコアが26から75の場合、またはスコアに関わらず VPN フラグが立っている場合は、カード、電話番号、チャレンジのステップを求めます。考え方は操作ごとの不正スコアしきい値と同じです。
  6. アカウントではなくクラスターをレビューする。 IP、プレフィックス、端末を共有するグループをキューに入れ、リングをまとめて判断します。1つのアドレスの証拠の読み方は、そのクラスターに対処する前にIP アドレスを段階的に調査する方法で確認できます。
  7. コホートの質を測る。 キャンペーンごとに、利用から2回目の購入までの率を追跡します。利用者が二度と戻ってこないプロモーションは、予算がどこに消えたかを示しています。

まず利用時のチェックを組み込む

クーポンと紹介の不正は、マーケティング予算に向けられたマルチアカウントです。まず利用時に1回のルックアップを行い、is_hosting、is_vpn、is_relay、is_tor、scoring.detection_methods を読み取り、それを「適用」「保留」「ステップアップ」「適用しない」に対応づけ、プレフィックス単位のカウンターを加えてください。無料プランでは、すべてのフィールドを含めて1日1,500回のルックアップを利用できます。また、IP 不正スコアチェッカーを使えば、コードを書かずに1つのアドレスの同じスコアと理由を確認できます。スコアの仕組みは不正防止の概要で説明しています。

同じシグナルは隣接する領域も守ります。匿名化レイヤーはVPN とプロキシの検知の仕組み、アカウントのセキュリティはアカウント乗っ取りとクレデンシャルスタッフィングの検知、誤検知を避ける運用は本物の顧客をブロックせずに匿名化トラフィックを検知する方法で扱っています。まず利用時のチェックを組み込んでください。報奨金のようになっているプログラムを、再び成長のための予算に戻す最も安価な場所です。

よくある質問

プロモーション不正利用とは何ですか?

プロモーション不正利用(promo abuse)とは、新規顧客向けクーポン、紹介ボーナス、登録クレジット、ロイヤルティポイント、無料トライアルなどのマーケティング上の特典を、本来の対象ではない人が悪用することです。初回注文の割引を再利用するために2つ目のメールアドレスを作る個人から、紹介ボーナスや特典予算を使い果たすために数千の偽アカウントを運用する組織的なリングまで、幅広い手口があります。

プロモコードの不正利用は違法ですか?

多くの場合は犯罪ではなく利用規約違反であり、そのためプラットフォームの大半は検知とアカウント停止で対処しています。身元の盗用、偽造書類、大規模で組織的な欺罔が絡むと犯罪になります。2021年に米国マサチューセッツ州の連邦検察は、配車・デリバリーのドライバーアカウントを巡る計画で19人を起訴しました。この計画では2,000件を超える盗まれた身元が使われ、他の偽アカウントを紹介することだけを目的とした偽アカウントも作られていました。被告のうち2人は2022年に、通信詐欺の共謀と加重身元盗用について有罪を認めています。

紹介プログラムはどのように悪用されますか?

中核となる手口は、マルチアカウントによる自己紹介です。同じ運営者が紹介者と「新規顧客」の両方を操作するため、偽の登録が1件増えるたびにボーナスが支払われます。リングはこれを、エイリアスのメールアドレス、アンチ検知ブラウザ、端末ファーム、VPN、レンタルした住宅用プロキシで拡大します。IPルックアップでは、住宅用プロキシの出口と本物の自宅利用者を区別できないため、そうしたアカウントはベロシティ、端末、決済情報の重複から見つける必要があります。

プロモーション不正利用を示すIPシグナルは何ですか?

最も強いネットワークシグナルは、「別人」のはずの多数の新規アカウントが、同じIPv4 /24 または同じIPv6 /64 プレフィックスから同一のプロモーションを利用すること、一般消費者なら自宅や携帯回線から来るはずの場面でホスティング範囲から利用されること、そして VPN や Tor のフラグが利用の段階に集中することです。いずれも文脈が必要です。キャリアグレードNATや iCloud Private Relay では多くの実在ユーザーが1つのアドレスを共有するため、GeoIPHub は CGNAT のスコアを50、リレーのスコアを60に制限しており、これらのアドレスはブロックではなくベロシティルールで処理します。

本物の顧客をブロックせずにプロモーション不正利用を止めるには?

アカウントではなく、プロモーションの適用資格に対して対処します。リスクシグナルが発火したときは、登録や購入を拒否するのではなく、割引やボーナスを保留または見送ります。低リスクの利用は通常どおり適用し、ホスティング由来の利用はレビューに回し、VPN 経由の利用には決済または電話番号の確認でステップアップを求め、Tor 出口からの利用では特典を適用しません。紹介者と被紹介者の両方をスコアリングし、共有アドレスはブロックではなくプレフィックス単位のベロシティ制限で扱います。

執筆者

GeoIPHub チーム

GeoIPHub API を支えるチーム

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

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

関連 記事