決済時の AI ショッピングエージェント不正:本物の売上を止めずに IP でボット不正を防ぐ方法
決済時の AI ショッピングエージェント不正。当社のルックアップでは、検証済みの ChatGPT-User アドレスはスコア 0、通常のクラウドサーバーは 10 でした。エージェントを検証してから、IP にスコアを付けます。

最もコンバージョンの高い決済トラフィックと、最も損失の大きい不正が、いまや同じ種類のネットワークから届きます。Adobe は、米国の小売サイトへの AI 経由のトラフィックが、2026 年 3 月には人間の訪問者より「42% 高く転換した」ことを確認しました。その 1 年前は 38% 低かったのです(TechCrunch 経由の Adobe データ)。一方、自動化されたトラフィックは 2025 年にウェブトラフィック全体の 53% を超えました(Imperva 2026 Bad Bot Report)。
HUMAN Security は、「エージェント活動の 2.3% が現在、決済ページで発生している」こと、そして無害な自動化と悪意ある自動化の割合を「分けているのは、わずか 0.5% の差」にすぎないことを報告しています(HUMAN、2026 年 3 月)。振る舞いだけでは、両者を分けられません。
以下では、実際の 4 件のルックアップ、User-Agent の照合がなぜお客様の仕事なのか、そして本物のエージェントからの売上を守るスコアとアクションの対応表を紹介します。

決済時にデータセンターとプロキシの IP をブロックしても、両面で失敗する理由
データセンターの一括ブロックは、穴だらけで、しかもコストが高いため失敗します。穴だらけなのは、高くつく攻撃にデータセンターのアドレスが必要ないからです。HUMAN は、「カードの総当たり攻撃の量は 2022 年以降 250% 急増した」「ログイン後のアカウント侵害の試みは前年比で 4 倍以上になった」と述べています(HUMAN)。GeoIPHub はレジデンシャルプロキシを検出しないため、家庭用回線からの不正は、お客様側のリクエスト頻度と決済データで捕捉する必要があります。その理由は、レジデンシャルプロキシ不正の解説で扱っています。
コストが高いのは、販売したい相手まで巻き込むからです。
- 本物のエージェントはクラウドネットワーク上で動きます。 下の検証済み ChatGPT-User アドレスは Microsoft の AS8075 上にあり、
datacenter_ipのフラグが立ちます。 - Apple iCloud プライベートリレーのユーザーは、リレーのエグレスアドレスを共有しています。 そのアドレスは、Cloudflare などのパートナーネットワーク上で運用されています。
- キャリアグレード NAT では、多数の契約者が 1 つのアドレスの背後に置かれます。 RFC 6598 は、そのための共有アドレス空間として
100.64.0.0/10を予約しています。Cloudflare の測定では、「CGNAT の IP は、CGNAT でない IP より 3 倍多くレート制限の対象になる」一方、ボットの平均率は CGNAT のアドレスのほうが低く、7% 対 13.1% でした(Cloudflare)。
したがって、接続タイプは重み付けされた入力であり、決して一律の拒否理由ではありません。IP によるボット検出のハブ記事では、5 件の実際のルックアップとともに、各 IP フラグが証明できることとできないことを示しています。
4 つの決済呼び出し元、4 件のルックアップ:2026-10-23 に確認した内容
検証済みのエージェントのアドレスは、スコア 0 の allow になりますが、ほぼどのクラウドサーバーもそうなります。2026 年 10 月 23 日の 05:03:52 から 05:04:07 UTC の間に、キーなしで 4 回のルックアップを 5 秒間隔で実行しました。
- ChatGPT-User:
104.208.184.193。OpenAI の chatgpt-user.json の最初のプレフィックスである104.208.184.192/28の最初のホストです。このファイルは 05:03 UTC に取得しました。IPv4 プレフィックスが 234 件、IPv6 はなし、creationTimeは 2026-10-20 でした。 - Google のユーザー起動型フェッチャー:
107.178.192.1。Google のuser-triggered-fetchers.jsonにある107.178.192.0/27の内側です。 - 通常のクラウドサーバー:
45.33.32.156、scanme.nmap.org。Linode 上の公開テストホストです。エージェントではありません。 - iCloud プライベートリレー:
104.28.46.99。Cloudflare 上にある Apple のリレーのエグレスアドレスです。
| 呼び出し元 | crawler.verified / name / category | fraud_score | recommended_action | 決済時の判断 |
|---|---|---|---|---|
ChatGPT-User、104.208.184.193 | true / ChatGPTUser / ai | 0 | allow | 購入者のエージェントとして受け入れる |
Google フェッチャー、107.178.192.1 | true / GoogleUserTriggeredFetcher / fetcher | 0 | allow | 受け入れる |
クラウドサーバー。エージェントを名乗った場合、45.33.32.156 | false / none / none | 10 | allow | 追加認証 |
プライベートリレー、104.28.46.99 | false / none / none | 9 | allow | 受け入れる |
次が ChatGPT-User のルックアップで、一部を省略し、ネスト構造は保持し、値は編集していません。
{
"ip": "104.208.184.193",
"asn": {
"asn": 8075,
"org": "MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"detection": {
"is_hosting": true
},
"threat": {
"is_crawler": true,
"crawler": {
"verified": true,
"name": "ChatGPTUser",
"operator": "OpenAI",
"category": "ai",
"verification_method": "ip_range_list"
}
},
"scoring": {
"fraud_score": 0,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter", "verified_crawler"]
}
}
2 つのホスティングシグナル、datacenter_ip と no_ptr_datacenter が発火しました。免責シグナルである verified_crawler が合計を 0 に引き下げました。このアドレスには、ライブにも保存済みにも逆引き DNS がないため、OpenAI の範囲ファイルが唯一の証明です。Google のフェッチャーも 0 で同じパターンですが、ホスト名は解決されるため、no_ptr_datacenter ではなく rdns_hosting が発火します。
重要なのはクラウドサーバーの行です。その 10 は datacenter_ip だけによるもので、allow の区分(25 以下)の内側です。このリクエストが ChatGPT-User の User-Agent で届いたとしても、スコアは allow のままです。主張が偽であることを示すのは、verified: false と name: "none" だけです。だから判断の列は、allow ではなく追加認証になっています。
リレーのアドレスは、relay_ip だけを根拠にスコア 9 でした。リレーは上限が 60 なので、プライベートリレーのユーザーが block に達することは決してありません。当社のジオロケーションはアンゴラのルアンダを示しますが、2026-10-12 に確認した時点の Apple のエグレスフィードはザンビアのルサカでした。そのため、リレーのユーザーは国単位で判断してください。
05:09 UTC には、Google の user-triggered-agents.json の最初の IPv4 ホストである 136.121.16.1 も調べました。このファイルは Google-Agent を対象としており、Google はこれを「Google のインフラ上でホストされたエージェントが、ユーザーの要求に応じてウェブを移動し操作を行うために使用される」と説明しています(Google)。結果は GoogleUserTriggeredAgent として検証済み、スコア 0、allow でした。fcrdns_mismatch も発火しましたが、実際の dig ではそのホスト名は正引き確認が取れます。これは当社側のバグで、スコアは動かしておらず、すでに記録しています。
これは 1 日の朝に行った 5 件のルックアップであり、ベンチマークではありません。範囲は移動するので、値をコピーする前に再実行してください。
User-Agent の照合は、API ではなくお客様のコードの仕事
API は、あるアドレスをどのボットが所有しているかを証明し、リクエストがそれと同じボットを名乗ったことは、お客様のコードが証明します。IP のルックアップは User-Agent を見ないため、GeoIPHub が単独で偽のエージェントにフラグを立てることはできません。ヘッダーを持っているのはお客様の決済ハンドラーであり、比較するのもそこです。
両側で名前が異なります。OpenAI の User-Agent トークンは ChatGPT-User ですが、API はハイフンなしの ChatGPTUser を返します。Google のトークンは Google-Agent ですが、API は GoogleUserTriggeredAgent を返します。文字列をそのまま比較すると失敗するため、小さなマップを持ってください。
// User-Agent token mapped to threat.crawler.name as the API returns it (seen 2026-10-23)
const AGENT_NAMES = {
"ChatGPT-User": "ChatGPTUser",
"Google-Agent": "GoogleUserTriggeredAgent",
};
// Returns null when the request makes no agent claim,
// true when the claim matches a verified range, false when it doesn't.
function agentClaimHolds(userAgent, lookup) {
const token = Object.keys(AGENT_NAMES).find((t) => userAgent.includes(t));
if (!token) return null;
const c = lookup.threat.crawler;
return c.verified === true && c.name === AGENT_NAMES[token];
}
false が返った場合は、上のクラウドサーバーの行に当たります。スコアにかかわらず、追加認証を求めるか、拒否してください。偽の GPTBot を使ったテストを含む nginx と Express による完全な実施方法は、AI クローラーをブロックすべきかのガイドにあります。
IP にスコアを付ける前に、エージェントの署名を検証する
有効なプロトコルの認証情報や署名は、どの IP シグナルよりも優先されます。「誰が送ったのか」には、範囲ファイルより確かな答えを出せる仕組みが 3 つあります。
エージェンティックコマースプロトコル(ACP)。 Stripe は2025 年 9 月 29 日に ACP を発表しました。「Stripe と OpenAI が共同開発した」オープン標準で、仕様のリポジトリは Apache-2.0 ライセンスです。そのエージェンティックチェックアウト RFCでは、Authorization ベアラートークンと API-Version、そしてすべての POST で Idempotency-Key が必須とされ、Signature と Timestamp は推奨とされています。Stripe は、同社の Shared Payment Token は「特定の加盟店とカート合計額にスコープが限定されている」と述べており、盗まれたトークンで買えるものが制限されます。
Web Bot Auth。 エージェントは、RFC 9421 HTTP Message Signatures(標準化過程、2024 年 2 月)に基づいて各リクエストに署名します。Cloudflare の Web Bot Auth の投稿では、Signature、Signature-Input、Signature-Agent の各ヘッダーと、署名者が公開する Ed25519 の鍵を使います。
カードネットワークのエージェントプログラム。 Visa は、HTTP Message Signature 標準に基づいて「Cloudflare と協力して」Trusted Agent Protocol を構築し、信頼できるエージェントを「悪意ある自動化や不正なボット」から区別できるようにしました(Visa、2025 年 10 月 14 日)。同日の Cloudflare の発表には、「Mastercard は Web Bot Auth を Mastercard Agent Pay に組み込んでいる」とあります。
ACP の呼び出しでは、RFC によれば ChatGPT がお客様の決済エンドポイントを呼び出すため、接続元の IP は買い物客ではなくエージェントプラットフォームのものです。その経路では認証情報を検証し、IP のスコアリングは直接のウェブトラフィックのために取っておきます。それぞれのチェックは、IP、逆引き DNS、Web Bot Auth による AI クローラーとエージェントの検証のガイドで順に説明しています。
本物のエージェントでも、IP の許可リストだけでは脆い理由
手作業で管理する許可リストは、エージェントのアドレスが共有され、動き続けるため破綻します。Cloudflare ははっきり述べています。「IP アドレス範囲が製品やユーザーグループを表すという考え方は脆い」。さらに、接続は「プライバシープロキシや VPN のように、複数のユーザーに共有されている場合がある」こと、クラウドの範囲は「時間とともに変わる」ことを付け加えています(Cloudflare)。
OpenAI 自身のファイルが、その変動を示しています。
| 取得日 | chatgpt-user.json の IPv4 プレフィックス数 | creationTime |
|---|---|---|
| 2026-10-06 | 230 | 2026-09-25 |
| 2026-10-23 | 234 | 2026-10-20 |
2026-10-06 の件数は、GPTBot、OAI-SearchBot、ChatGPT-User の比較によるものです。OpenAI は ChatGPT-User について、「これらの操作はユーザーが開始するため、robots.txt のルールは適用されない場合がある」とも述べています(OpenAI)。
当社側にも遅れがあります。GeoIPHub は 19 件の公式範囲ファイルを再取得し、ルックアップデータベースを毎日再構築するため、新しいプレフィックスの検証には最大で約 2 日かかることがあります。範囲の一致は強い裏付けと考え、エージェントが署名を送ってくる場合は署名を優先してください。
AI ショッピングエージェント不正:決済の段階での脅威
決済時の AI ショッピングエージェント不正を動かす攻撃は 3 つあり、どれも、1 人の購入者が 1 つのカートで行う正当なエージェントの注文には見えません。
- カードテスト(列挙)。 少額または与信のみの試行が連続して行われ、拒否率が高くなります。Visa は、列挙攻撃が「年間 11 億ドルの不正損失」を引き起こし、「列挙されたアカウントの 33% が 5 日以内に不正被害を受けた」と述べています(Visa、2024 年 5 月)。
- アカウント乗っ取り。 盗まれたログイン情報を使い、保存されたカードで購入します。Imperva は、金融サービスが「アカウント乗っ取りインシデントの 46%」を占めたと述べています(Imperva 2026)。ログイン側については、アカウント乗っ取り対策のガイドで扱っています。
- 転売目的の買い占め。 需要の高い限定販売で、数量限定の在庫を買い占めるボットです。
多数のアドレスに分散したカードテストは、IP ごとのカウンターをすり抜けます。そのため、ASN ごと、BIN ごとの拒否数と異なるカード数も数えてください。
0 から 100 のスコアを決済のアクションに対応づける
0 から 100 のスコアが決済で役立つのは、各区分が固定のアクションに対応づけられている場合だけです。GeoIPHub の説明可能なリスクスコアが IP 側の入力を扱い、scoring.detection_methods が発火したすべてのシグナルを挙げます。残りは、お客様のコードと決済データが補います。
| 入力 | 判断への影響 |
|---|---|
| 有効な ACP 認証情報または Web Bot Auth 署名 | 信頼できる経路。摩擦は小さい |
crawler.verified が true で、名前が User-Agent と一致 | ホスティングのシグナルを打ち消す |
| 検証済みの一致がないエージェントの User-Agent | スコアにかかわらず追加認証または拒否 |
ホスティングネットワーク(datacenter_ip) | 小幅な上昇。現状では単独で 10 |
| VPN または Tor 出口 | 大幅な上昇。多くは block |
リレー(relay_ip) | 小幅な上昇。上限は 60 |
| IP ごと・ASN ごとのカード、BIN、拒否のリクエスト頻度 | 大幅な上昇 |
| IP の国が請求先の国と異なる | 上昇。国単位で判断する |
そのうえで、区分をアクションに対応づけます。
| 区分 | スコア | 決済時のアクション |
|---|---|---|
allow | 0 から 25 | 通す。ただしエージェントの主張が検証に失敗した場合を除く |
review | 26 から 50 | 3-D セキュア |
step_up | 51 から 75 | 3-D セキュアに加え、リクエスト頻度のチェック |
block | 76 から 100 | 拒否、または手動レビューのために保留 |
上限があるおかげで、共有アドレスは block に入りません。リレーのアドレスは上限が 60 なので、スコアだけで拒否されることはなく、API がキャリアグレード NAT と識別したアドレスには上限 50 が適用されます。ACP には、独自のカードテストのシグナルもあります。delegate-payment RFC は、card_testing タイプの risk_signals を、blocked、manual_review、authorized のいずれかのアクションとともに送ります。これを埋めるのはエージェントプラットフォームで、お客様のスコアは別のチェックとして残ります。これらの区分をさらに 5 つのアドレスで試した結果は、ログイン、サインアップ、決済の IP 不正スコアのしきい値の記事にあります。
ブロックではなくエスカレーション:3-D セキュアが責任を移す
中間の区分は、拒否せずに 3-D セキュアへ回してください。追加認証は売上を残し、通常はチャージバックのリスクも移すからです。Trust Payments の 3-D Secure v2 の責任に関するガイドは、認証に成功した後は「ほとんどの場合、不正なチャージバックが発生したときはカード発行会社が責任を負う」と述べています。同時に、「取引の認証に成功しても、責任の移転や与信の成功が保証されるわけではない」とも警告しています。
追加認証は、本物の購入者に通り道を残し、カードテストを行う者にはカードを所持していることの証明を迫ります。この中間の区分に、ほかにどんな人が入るのかは、VPN 検出の誤検知のガイドで扱っています。
認可されたエージェントかどうかは、技術ではなく法律の問題
より難しい問いは、そもそもそのエージェントがお客様から購入してよいのかどうかです。2026 年 3 月 9 日、米国カリフォルニア州北部地区連邦地方裁判所は、Perplexity に対する Amazon の仮差止命令を認めました。The Register は、判事が Perplexity の Comet エージェントは「Amazon ユーザーの許可を得てアクセスしているが、Amazon の認可は得ていない」と書いたと報じています(The Register)。Perplexity は控訴し、2026 年 8 月 4 日に第 9 巡回区控訴裁判所は差止命令を取り消して事件を地方裁判所に差し戻し、現在も係属中です。
この判断で問題が決着したわけではありません。IP のチェックが教えるのは、誰がリクエストを送ったかです。その送信者が購入してよいかどうかは、お客様の利用規約が決めます。
決済で IP チェックが通用しない場面
IP のシグナルがカバーするのは決済の全体像の一部にすぎません。既知の限界は次のとおりです。
- レジデンシャルプロキシの検出はありません。 家庭用回線からの不正には、お客様のリクエスト頻度と決済データが必要です。
- User-Agent は見えません。 API が偽のエージェントにフラグを立てることはありません。それを行うのは、お客様のコード内の名前の照合です。
- 範囲の遅れと DNS の欠落。 新しいプレフィックスの検証には約 2 日かかることがあり、今朝は誤った
fcrdns_mismatchを 1 件確認しました。 - キャリアグレード NAT は、現時点では範囲でフラグが立ちません。 2026-10-22 に
100.64.0.1を調べたときは、CGNAT として返ってきませんでした。このフラグに基づくルールは、まだ作らないでください。
ルールを変更した後は、iOS Safari、モバイルキャリア、プライベートリレーなどのセグメントごとに誤検知を追跡してください。国が市区町村より信頼できる理由は、IP ジオロケーションの実際の精度の記事で説明しています。
決済ハンドラーに組み込む
サーバー側の決済エンドポイントに、4 つのステップで組み込みます。
- ACP の認証情報または Web Bot Auth の署名をまず検証し、有効なものには信頼できる経路を与えます。
- 無料 API で IP 不正検知をアプリに追加するガイドのとおりに、接続元の IP を調べます。
- User-Agent のマップを
threat.crawler.nameと照合します。エージェントの主張が失敗した場合は、追加認証または拒否とします。 scoring.recommended_actionを区分の表に対応づけ、その上にカードと ASN のリクエスト頻度を加えます。
判断がおかしいと感じたら、IP アドレスを調査する方法の手順で理由を確認してください。まず、今週 ChatGPT-User を名乗った、お客様自身の決済ログのアドレスを 1 つ選びます。それを調べて、crawler.name を主張と比較してみてください。
よくある質問
ボットを止めるために、決済時にデータセンターやプロキシの IP をすべてブロックすべきですか?
いいえ。本物のエージェントはクラウドネットワーク上で動きます。2026-10-23 に、Microsoft の AS8075 上にある検証済みの ChatGPT-User アドレスは、スコア 0、allow でした。一括ブロックは、プライベートリレーやキャリアグレード NAT のユーザーも拒否してしまいます。ホスティングはスコアの中で重み付けし、中間の区分は 3-D セキュアに回してください。
決済の段階で、正当な AI ショッピングエージェントと不正ボットをどう見分けますか?
まず身元を検証します。ACP の認証情報、または RFC 9421 に基づく Web Bot Auth の署名です。どちらもない場合は IP を調べます。threat.crawler.verified とボット名が返るので、コード側でその名前をリクエストが名乗った User-Agent と照合してください。
なぜ IP の許可リストだけでは AI エージェントに対して脆いのですか?
Cloudflare は、クロールサービスの接続はプライバシープロキシや VPN のように共有されうること、クラウドの範囲は時間とともに変わることを指摘しています。OpenAI の chatgpt-user.json は、当社が取得した 2026-10-06 と 2026-10-23 の間に、IPv4 プレフィックスが 230 から 234 に増えました。
0 から 100 の IP リスクスコアを、決済の判断にどう対応づけますか?
allow(25 以下)は通し、review(50 以下)と step_up(75 以下)は 3-D セキュアに回し、block(75 超)は拒否または保留にします。検証に失敗したエージェントの主張は、スコアにかかわらず追加認証とします。
3-D セキュアへの追加認証は、ブロックよりコンバージョンを損ないますか?
ブロックでは確実に売上を失いますが、追加認証なら本物の購入者に通り道を残せます。Trust Payments は、認証に成功した後は、ほとんどの場合、不正なチャージバックの責任をカード発行会社が負うと述べています。ただし、これは保証されているわけではありません。
自分のストアで AI エージェントによる購入をブロックするのは合法ですか?
認可の有無によります。これは法的助言ではありません。2026 年 3 月、連邦裁判所は Amazon に対し、Perplexity への仮差止命令を認めました。判事は、Perplexity の Comet エージェントはユーザーの許可を得て Amazon にアクセスしたが、Amazon の認可は得ていなかったと述べています。第 9 巡回区控訴裁判所は 2026 年 8 月にその差止命令を取り消し、事件は現在も係属中です。
GeoIPHub API を支えるチーム
GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。


