不正防止偽の新規登録を止める方法：IP タイプ別の偽アカウント検知
IP タイプ別に偽の新規登録を止めます。2026年11月2日の7件のライブルックアップ、それぞれに対する登録時の対応、自社コードで使える /24 と /64 のベロシティ制限を紹介します。
Okta Threat Intelligence は、無料トライアルに偽の新規登録の試みが殺到した AI 動画サービスの事例を紹介しています。ある顧客のログには「2026年6月1日から7月1日までの間に、ボットに関連すると思われる251の異なる IP から、10万5,000回を超える総当たりの新規登録試行が記録されている」（Between June 1, 2026, and July 1, 2026, logs show over 105,000 brute force attempts to sign up from 251 distinct IPs likely connected to bots.）とあります。その登録は「プロキシプロバイダと VPN に結びついていた」（were tied to proxy providers and VPNs）といいます。Okta の数字から GeoIPHub が計算すると、1か月で1アドレスあたり約418回、1日あたり約14回です。そのため、IP ごとに1時間あたり数件という制限では、一度も発動しないかもしれません。
難しいのは、偽の新規登録と本物の顧客が同じネットワークを共有していることです。本物の人も VPN やクラウドデスクトップを使いますし、iCloud Private Relay、モバイルキャリア、キャリアグレード NAT のように、本物の人が共有するアドレスは、性質上、多忙に見えます。ブロックするだけのルールは、プールを入れてしまうか、顧客を締め出してしまうかのどちらかになります。
以下では、登録の発信元になりうる7つのアドレスについて、2026年11月2日に GeoIPHub の IP ルックアップ API が返した結果と、フォームでの対応、共有アドレスをスコアだけで拒否してはいけない理由、テスト済みのコードを使ったベロシティ制限、そして IP には見えないものを順に説明します。
偽アカウント検知が登録時に確認するものと、必ず手元にある1つのシグナル
偽アカウントの検知は、新しい登録をネットワーク、ベロシティ、メール、電話、端末、行動にわたってスコアリングします。フォームが POST された時点で、これらのうちユーザーに何も尋ねずにサーバーが必ず持っているのは IP だけです。そのため、IP 不正スコアが通常の最初のチェックになります。
OWASP はこの攻撃を OAT-019 Account Creation と名付けています。「アプリケーションのアカウント登録プロセスを使った、アカウントの一括作成、場合によってはプロフィールの一括入力」（Bulk account creation, and sometimes profile population, by using the application’s account sign-up processes.）です。偽アカウントの作成が目的そのものであることはまれで、プロモーションや紹介のファーミング、利用停止を回避する1人の運営者による多数のアカウント、あるいはクレデンシャルスタッフィングの準備のための土台になります。
新規登録詐欺は、備えておくべきほど一般的です。Auth0 プラットフォームのデータに基づく Okta の Customer Identity Trends Report 2025 は、こう述べています。「2024年には、Auth0 プラットフォーム全体の登録試行の平均46%が新規登録攻撃と判定された」（In 2024, an average of 46% of all registration attempts across the Auth0 platform were identified as signup attacks.）。Stripe は2026年4月29日の Sessions 2026 の発表で、自社ネットワークの数字を次のように示しました。「Stripe 上で動く AI サービス全体で、試みられた新規登録の6件に1件が悪意ある者によるものである」（Across AI services running on Stripe, one in six attempted sign-ups is made by a bad actor.）。
各層が必要とするものと、IP ルックアップで答えられる層を整理します。
| 層 | 例 | IP ルックアップで見えるか |
|---|---|---|
| ネットワーク | Tor 出口、VPN サーバー、クラウドサーバー、リレー、モバイルキャリア | 見える |
| ベロシティ | 1時間または1日あたりの、アドレス、プレフィックス、ネットワークごとの登録数 | キーだけ。数えるのは自社のコード |
| メール | 使い捨てドメイン、プラスアドレスとドット違いのバリエーション | 見えない |
| 電話 | VoIP 番号、再利用された番号 | 見えない |
| 端末 | アカウントをまたいで繰り返されるブラウザやハードウェアの特徴 | 見えない。端末フィンガープリントを参照 |
| 行動 | フォームの入力速度、コピーペースト、マウスの動き | 見えない |
端末の行は別のツールの領域です。端末フィンガープリントと IP データの比較で、両者の組み合わせ方を解説しています。
7つの登録元 IP、7つの判断：2026年11月2日に GeoIPHub が返した結果
GeoIPHub は、2026年11月2日の 04:51 から 04:52 UTC にかけて、登録の発信元になりうる7つのアドレスを調べました。スコア、理由、そして GeoIPHub の不正スコアの出発点となるしきい値の登録の行を使った、フォームでの対応を示します。最後の2行はルックアップではなく、スコアリング設定のルールです。
| アドレス | 種類 | スコア、アクション | detection_methods | 登録時の対応 |
|---|---|---|---|---|
| 185.220.101.1 | Tor 出口。zen.spamhaus.org にも掲載 | 100, block | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer | 拒否 |
| 185.213.155.73 | VPN サーバー。vpn_provider が Mullvad を示す | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | 既定では拒否。ユーザーが VPN を使い、乱用の理由が発火していなければ確認に回す |
| 45.83.220.7 | Mullvad VPN のネットワークアドレス。vpn_provider は "Mullvad (31173 Services)" | 46, review | known_vpn_server, datacenter_ip | 作成し、制限し、フラグを付ける |
| 45.33.32.156 | scanme.nmap.org。Linode のクラウドサーバー | 10, allow | datacenter_ip | 許可。ホスティングネットワーク単位で数える |
| 104.28.46.99 | iCloud Private Relay の出口 | 9, allow | relay_ip | 許可。緩いベロシティ制限 |
| 66.249.66.1 | 確認済みの Googlebot（crawler.operator は Google） | 0, allow | datacenter_ip, verified_crawler | アカウントは作らない。クローラーは登録しない |
| 162.142.125.10 | Censys のインターネットスキャナー（is_scanner が true） | 0, allow | 理由は返されない | アカウントは作らない |
| 任意の CGNAT アドレス | ルックアップではなく、スコアリング設定のルール | 上限50 | 上限が外れるのは、そのアドレス自身の VPN、プロキシ、Tor、プロトコル、ボットネット、不正利用の証拠がある場合だけ | スコアだけで拒否しない |
| 任意のモバイルキャリアのアドレス | ルックアップではなく、スコアリング設定のルール | 12下げる | 脅威の証拠がない場合の mobile_carrier | スコアだけで拒否しない |
2つの100は同じに見えますが、同じではありません。Tor 出口にはスパムの履歴があり、VPN サーバーにあるのは匿名性に関する理由だけで、不正利用の証拠はまったくありません。この違いが、VPN からの登録を拒否するか、確認に回すかを決めます。
API 自体の recommended_action がブロックするのは75を超えた場合だけです。GeoIPHub の登録時の出発点となるしきい値は71からブロックしますが、2026年11月2日の時点で、この2つの線の間に入った行はありませんでした。
家庭用ブロードバンドの行はありません。世帯のアドレスは公開していないためです。GeoIPHub のスコアリングが家庭用回線に割引を与えるのは、そのアドレスに住宅パターンの逆引き DNS 名がある場合だけです。そのため、逆引き名のない家庭用回線は住宅用の割引を受けられず、脅威の理由があればそのまま満額で数えられます。
数字ではなく理由を読む：1件の登録を最初から最後までたどる
スコアはアドレスのリスクの高さを示し、scoring.detection_methods はその理由を示します。そして理由が、制限するか、確認するか、拒否するかを決めます。2026年11月2日 04:51:58 UTC に調べた 45.83.220.7 の、省略したレスポンスを示します。
{
"ip": "45.83.220.7",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB",
"connection_type": "datacenter"
},
"detection": {
"is_vpn": true,
"is_hosting": true,
"is_relay": false,
"is_mobile": false,
"vpn_provider": "Mullvad (31173 Services)"
},
"threat": { "is_cgnat": false },
"scoring": {
"fraud_score": 46,
"recommended_action": "review",
"detection_methods": ["known_vpn_server", "datacenter_ip"]
}
}
2つの理由が発火しました。known_vpn_server が36（確度0.9で40ポイント）、datacenter_ip が10（0.5で20ポイント）を加算し、スコアは46になります。これは GeoIPHub の登録時の出発点となるしきい値の26から50の区分に入り、作成してフラグを付けます。アカウントは、メールが確認されるまでトライアルのクレジットやボーナスを付与しない、制限された状態で作成するのがよいでしょう。detection.is_hosting が true なので、この登録は、下のベロシティチェックでも AS39351 に対して数えられます。トライアルの開始やクレジットの付与のような最初の価値あるイベントで、もう一度その IP を調べてください。
185.213.155.73 の Mullvad サーバーはスコア100の block でしたが、4つの理由はどれも匿名性に関するもので、不正利用に関するものではありません。登録時の既定の対応は拒否です。実際のユーザーが VPN を使う製品では、理由に対してルールを書き、このように匿名性の理由があって不正利用の理由がない100を、メールか電話の確認に回せます。VPN だけではプライバシーを守る選択にすぎず、それが守っている人たちは、しばしば誤ってフラグを付けられる側にいます。スパム履歴のある Tor 出口は、どちらの場合でも拒否のままです。
スコア0は合格ではない：登録フォームに来るクローラーとスキャナー
2026年11月2日の GeoIPHub のルックアップで最も好意的な結果、つまり 66.249.66.1 の確認済み Googlebot と、162.142.125.10 の Censys スキャナーは、どちらもスコア0の allow でした。そして、この2つこそ、アカウントを作ってはいけないものです。どの100よりも、これには驚かされました。
GeoIPHub の verified_crawler の理由は28.5を差し引くため、確認済みクローラーはスケールの最下部に入ります。クロールとしては正しいのですが、フォームの POST としては間違っています。登録リクエストで threat.crawler.verified が true なら、アカウントを作成してはいけません。このためには crawler.verified と crawler.operator を読み、crawler.name は決して使わないでください。
threat.is_scanner はスコアにはまったく影響しません。Censys のアドレスは理由を返しませんでした。このフラグは直接確認し、true なら登録を拒否してください。
共有アドレスはスコアだけで拒否しない：リレー、CGNAT、モバイル
iCloud Private Relay の出口、キャリアグレード NAT のアドレス、モバイルゲートウェイは、多くの本物の人を担うことがあります。GeoIPHub のスコアリングは、そのアドレス自身に脅威の証拠がない限り、リレーのアドレスの上限を60、CGNAT のアドレスの上限を50とし、問題のないモバイルのアドレスは割り引き、脅威の証拠があるモバイルのアドレスには逆にペナルティを与えます。ルールでも、これらのアドレスは、自身の証拠がない限りブロックの区分に入れないでください。
GeoIPHub のスコアリングでは relay_ip が8.5を加算し、リレーの割引はないため、リレーのサンプルのスコアは9でした。CGNAT の上限が外れるのは、そのアドレス自身の VPN、プロキシ、Tor、プロトコル、ボットネット、不正利用の証拠がある場合だけです。モバイルキャリアのアドレスには mobile_carrier が付き、脅威の証拠がなければスコアを12下げます。
これは「信頼する」という意味ではありません。IP だけでは、同じアドレスの背後にいる、1人の悪意ある者と大勢の顧客を区別できない、ということです。だからこうした登録はチャレンジの対象にし、スコアを理由に拒否せず、通常の10倍のベロシティ制限を与えてください。Private Relay については特に、通したうえで、そのアカウントがその後に行うことでセッションをスコアリングするのがおすすめです。
IP、/24、IPv6 /64、ホスティングネットワークごとの登録数を自社のコードで数える
GeoIPHub の API は1つのアドレスをスコアリングします。そのアドレス、その /24、その /64、そのネットワークが過去24時間に何個のアカウントを作ったかは数えません。そのカウンターは自社のコードにあり、ルックアップは使うべきキーを教えてくれます。asn.asn、detection.is_hosting、detection.is_relay、detection.is_mobile、asn.connection_type、threat.is_cgnat です。
Okta の AI 動画の事例では、偽の新規登録の試行は、251のアドレスに分散して、1アドレスあたり1日平均約14回でした。IP ごとのカウンターだけでは発動しないかもしれません。プレフィックスとネットワークのカウンターは、まさにこのケースのためにあります。
以下は私たちが選んだ出発点であって、業界のベンチマークではありません。自社の登録データで調整してください。
| キー | ウィンドウ | 出発点となる上限 | 備考 |
|---|---|---|---|
| IPv4 の完全なアドレス | 1時間 | 3 | |
| IPv4 /24 | 1時間 | 10 | 1つのブロック内で切り替わるプールを捕まえる |
| IPv6 /64 | 1時間 | 3 | /64 を1つの IPv4 アドレスのように扱う。1つの割り当てから新しい /64 が出続ける場合は /56 や /48 に広げる |
| ASN、ホスティングのみ（detection.is_hosting が true） | 24時間 | 20 | 本物の顧客がクラウドサーバーから登録することはまれ |
| 共有アドレス（リレー、CGNAT、モバイル） | 同じウィンドウ | IP とプレフィックスの上限の10倍 | ベロシティだけでブロックしない |
上限を超えたら、拒否ではなく、ステップアップ（メールまたは電話の確認、または CAPTCHA）か、制限付きの作成にします。IPv6 では、完全なアドレスではなくプレフィックスを数えてください。そうしないと、1人の行為者が数千の「別々の」登録になってしまいます。家庭には /56 や /48 が割り当てられることが多く、表で範囲を広げるのはそのためです。割り当てのサイズについては、IPv6 をプレフィックスでレート制限するガイドで解説しています。
以下のコードは、依存関係のない Node 18 以降で動作します。信頼できるプロキシのチェーンから取り出したクライアントアドレスを、Node が報告する形のまま、::ffff:192.0.2.1 のような IPv4 マップ形式も含めて受け取ることを想定しています。ウィンドウは固定式で、スライディングウィンドウを単純化したものです。
// Signup velocity keys: exact IP, IPv4 /24, IPv6 /64, and ASN for hosting.
// Starting limits, not benchmarks. Tune them on your own signups.
import { isIPv4, isIPv6 } from "node:net";
const HOUR = 3600e3, DAY = 24 * HOUR;
const LIMITS = {
ip: { window: HOUR, max: 3 }, // one IPv4 address, or one IPv6 /64
v4_24: { window: HOUR, max: 10 },
asn: { window: DAY, max: 20 }, // hosting networks only
};
const SHARED_FACTOR = 10; // relay, CGNAT and mobile egress
function expandIPv6(addr) {
const [head, tail = ""] = addr.toLowerCase().split("::");
const h = head ? head.split(":") : [];
const t = tail ? tail.split(":") : [];
const fill = addr.includes("::") ? 8 - h.length - t.length : 0;
return [...h, ...Array(fill).fill("0"), ...t].map((g) => g.padStart(4, "0"));
}
export function velocityKeys(ip, lookup) {
const keys = [];
const m = ip.match(/^(?:::|(?:0{1,4}:){5})ffff:(\d+\.\d+\.\d+\.\d+)$/i);
const v4 = m && isIPv4(m[1]) ? m[1] : ip;
if (isIPv4(v4)) {
keys.push(["ip", v4], ["v4_24", v4.split(".").slice(0, 3).join(".") + ".0/24"]);
} else if (isIPv6(ip)) {
keys.push(["ip", expandIPv6(ip).slice(0, 4).join(":") + "::/64"]);
}
const asn = lookup?.asn;
if (lookup?.detection?.is_hosting && asn?.asn) keys.push(["asn", `AS${asn.asn}`]);
return keys;
}
const counters = new Map(); // in-memory and unbounded; for a demo only; use Redis INCR + EXPIRE in production
export function checkVelocity(ip, lookup, now = Date.now()) {
const shared = Boolean(
lookup?.detection?.is_relay || lookup?.threat?.is_cgnat ||
lookup?.detection?.is_mobile || lookup?.asn?.connection_type === "mobile");
const hits = [];
for (const [level, value] of velocityKeys(ip, lookup)) {
const { window, max } = LIMITS[level];
const limit = shared && level !== "asn" ? max * SHARED_FACTOR : max;
const key = `${level}:${value}:${Math.floor(now / window)}`;
const count = (counters.get(key) ?? 0) + 1;
counters.set(key, count);
if (count > limit) hits.push({ level, value, count, limit });
}
return { overLimit: hits.length > 0, hits }; // over the limit: step up, don't block
}
このコードそのものに対して、2026年11月2日に Node 24.20.0 で16件のユニットテストを実行しました。ドキュメント用とプライベートのアドレス範囲、および表にある scanme.nmap.org のアドレスを使い、ルックアップは行っていません。16件すべてが合格しました。::ffff:45.33.32.156 のような IPv4 マップ形式は IPv4 としてキー化され、1つの /64 内での切り替えは4回目の登録で発動し、1つの /24 にわたる11個のアドレスは /24 のキーだけが発動し、1つのリレー出口からの30件の登録は通り、31件目にフラグが付きました。ルックアップが失敗した場合（null）でも IP とプレフィックスのキーは生成されるため、API が応答しなくてもカウンターは機能し続けます。
IP レイヤーが見えなくなる場所
IP ルックアップでは、レンタルした家庭用回線や本物の電話から登録する偽アカウントは見えません。また、メール、端末、フォームがどう入力されたかも見えません。
住宅用プロキシは最も明確な死角です。GeoIPHub は、住宅用回線やモバイル回線で観測したプロキシ（サードパーティのリストが中継していると報告するアドレスを含む）にフラグを付けますが、自前の住宅用プロキシ検知は持っておらず、きれいな家庭用回線は通り抜ける可能性があります。本物の SIM カードで動くクリックファームや端末ファームは、モバイルの顧客に見え、私たちのスコアリングは意図的にモバイルの顧客を寛大に扱います。
GeoIPHub がスコアリングするのは IP であり、メールアドレスや電話番号はチェックしません。IP のチェックは、自社のメールチェック（使い捨てドメイン、プラスアドレスとドットの正規化）、電話の確認、端末シグナル、そして登録後にキーを共有するアカウントをクラスタリングすることと組み合わせてください。
制限された状態こそが、中間の区分を低コストで運用できるようにします。アカウントを作成し、クレジットを保留し、確認または最初の実際の操作の後に解放します。確認されない偽アカウントがもたらすのは、トライアルの消費ではなく、データベースの1行だけです。
アカウントが存在する前に偽の新規登録を止める方法
チェック全体は、「送信」と「作成」の間にある、1回のルックアップと1回のベロシティカウントで、次の順番で行います。
- クライアントの IP は、信頼できるプロキシのチェーンから取り出します。クライアントが何でも設定できる、生の
X-Forwarded-Forヘッダーは使いません。 - IP を調べます。
- Tor 出口、確認済みクローラー、スキャナーは拒否します。スコア100の VPN サーバーは、既定では拒否するか、ユーザーが VPN を使い、乱用の理由が発火していなければ確認に回します。リレー、CGNAT、モバイルのアドレスは、スコアだけで拒否してはいけません。それ以外には、GeoIPHub の登録時の出発点となるしきい値を適用します。
- ベロシティチェックを実行し、引っかかったらステップアップします。
- ルックアップが失敗した場合は、ベロシティチェックとメール確認にフォールバックします。拒否はしません。
- スコア、理由、ルックアップの時刻をアカウントとともに保存し、最初の価値あるイベント（トライアルの開始、クレジットの付与、最初の支払い）で IP をもう一度調べます。
手順2と3は、テスト済みの Node と Python の連携で動くコードとして示しています。GeoIPHub の無料プランは、すべてのフィールドを含めて1日1,500回のルックアップをカバーします。
登録ログにある直近10件の IP を IP 不正スコアチェッカーに貼り付けて、表の行に振り分けてみてください。スコアは各アドレスが何であるかを教え、カウンターはそのアドレスがいくつのアカウントを作ったかを教えてくれます。
よくある質問
本物のユーザーをブロックせずに偽の新規登録を止めるには？
アカウントを作成する前に、GeoIPHub の API で各登録の IP を調べます。Tor 出口と最高スコアのものは拒否し、中間のものはメールまたは電話で確認し、iCloud Private Relay、キャリアグレード NAT、モバイルゲートウェイのような共有アドレスは、緩めたベロシティ制限のもとで通します。こうしたアドレスは1つで多くの本物の顧客を担うことがあるからです。
新規登録詐欺はどのくらい一般的ですか？
Okta の Auth0 プラットフォームでは、2024年に登録試行の平均46%が新規登録攻撃と判定されました。Stripe は2026年4月に、自社ネットワーク上の AI サービス全体で、試みられた新規登録の6件に1件が悪意ある者によるものだと述べています。どちらも各社が自社プラットフォームで集計したベンダーの数字です。
IP アドレスだけで偽アカウントを検知できますか？
いいえ。IP ルックアップからわかるのは、登録がどんな種類のネットワークから来たかと、そのスコアになった理由までです。メールアドレス、電話番号、端末、あるいはレンタルした家庭用回線から登録する偽アカウントは見えません。最初のレイヤーとして使い、メール、電話、端末のチェックと組み合わせてください。
GeoIPHub はメールアドレスをチェックしますか？
いいえ。GeoIPHub の API がスコアリングするのは IP アドレスだけです。メールと電話は自社のツールで確認し、その結果を GeoIPHub のスコアと理由と組み合わせてください。
VPN ユーザーの新規登録は許可すべきですか？
多くの場合は許可してかまいません。VPN だけではプライバシーを守る選択にすぎないため、VPN 経由の登録は拒否せずメールや電話の確認に回し、完全なブロックは Tor 出口と、スパムや不正利用の履歴があるアドレスにとどめてください。
IPv6 の新規登録はどのようにレート制限すべきですか？
アドレス単位ではなく /64 単位で数えます。1人の契約者が /64 全体の中でアドレスを切り替えられるからです。同じ割り当てから新しい /64 が出続ける場合は /56 や /48 に広げ、モバイルキャリアでは制限を緩めに保ちます。
GeoIPHub API を支えるチーム
GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。
