【
エージェンティック・コマース（ACP／UCP／AP2対応、商品フィード整備、被起動最適化、アトリビューション設計）で「AIエージェントに買ってもらう導線」を整えた企業が、次に必ず直面するのが「AI経由の不正・悪用」です。本稿は、売上を作る設計から、売上を守る設計へ視点を切り替え、ショッピングエージェント経由の注文を防御側から体系化します。対象読者は、EC・決済・不正対策・セキュリティの実務者、およびエージェンティック・コマースの導入責任者です。
筆者はネットワーク機器のNOC／TAC運用に25年以上携わり、現在は独立してAI活用の設計・実装を支援しています。「境界の内側を守る」内部統制の発想と、「境界の外から来る自動化されたトラフィックをどう見分けるか」という運用の発想の、ちょうど交差点にあるのがエージェンティック・コマースの不正対策です。本稿では、攻撃面の変化を整理したうえで、入口（本人性）→ 決済フロー → 注文後 → 監視の順に、多層防御の具体を示します。
1. なぜコマース対応の”次”に不正対策が要るのか——攻撃面の変化
従来のEC不正対策は、暗黙のうちに「画面の向こうに人間がいる」ことを前提にしてきました。CAPTCHA、行動のわずかな揺らぎ、カート投入から決済までの時間、デバイスフィンガープリント——いずれも「人間らしさ」をシグナルにして不正を弾く設計です。ところがエージェンティック・コマースでは、正規の取引そのものをプログラム（AIエージェント）が行うことを前提にします。つまり「人間らしくない＝怪しい」という最大のシグナルが、そのまま使えなくなります。
攻撃面は次の3点で質的に変わります。
- 主体が自動化される：大量のクエリ・注文を、高速かつ休みなく実行できる。1件あたりの利ざやが小さい不正でも、規模で成立してしまう。
- 指示（マンデート）が介在する：「誰が」「何を」「いくらまで」買ってよいかを表す購入指示が、エージェントとマーチャントの間を流れる。ここが偽造・改ざん・使い回しの新しい標的になる。
- 本人性の確認先が二重になる：「このエージェントは本物か（真正性）」と「このエージェントは本当にこの利用者から委任されているか（権限）」を、別々に検証しなければならない。
| 観点 | 従来のEC不正対策 | エージェント経由の不正対策 |
|---|---|---|
| 取引の主体 | 人間（ボットは基本的に排除対象） | 正規のエージェント（プログラム）を受け入れる前提 |
| 主なシグナル | 人間らしさ・行動の揺らぎ・デバイス情報 | 署名・マンデート・冪等性キー・支出パターン |
| 本人確認 | ログイン＝本人 | 真正性（誰のエージェントか）と権限（何を委任されたか）の二段 |
| スケール | 手作業に近く、速度に上限 | 高速・大量・無停止。異常が一気に広がる |
| 被害の広がり方 | 1件ずつ | ループ暴走・多重支払いで指数的に拡大しうる |
整理すると、コマース対応で整えた「選ばれ・買われるための仕組み（enablement）」は、そのまま「攻撃者にとっての入口」でもあります。導線を広げた分だけ、守るべき面も広がった——これが不正対策を”次”に置くべき理由です。
2. 脅威マップ——エージェント経由で何が起きるのか
まず、起こりうる悪用を5つに分けて整理します。防御を語る前に、何から守るのかを共有言語にしておくことが重要です。
脅威1：なりすましエージェント
攻撃者が、正規のショッピングエージェント（例：大手プラットフォームの購入エージェント）を名乗ってアクセスし、優遇された在庫・価格・レート制限の緩和を引き出そうとします。User-Agent文字列の偽装だけなら容易であり、「名乗り」を信じてはいけない、というのが出発点です。真正性を暗号的に検証しない限り、なりすましは常に成立します。
脅威2：マンデート（購入指示）の偽造・改ざん
「利用者Aが、商品Xを、上限1万円で購入することを許可した」という購入指示（マンデート）を、攻撃者が捏造・改ざんします。上限額の書き換え、対象商品のすり替え、有効期限の延長などが典型です。マンデートに署名がない、あるいは署名の検証が甘いと、この改ざんがそのまま通ってしまいます。
脅威3：決済リプレイ（多重支払い・重複注文）
一度成立した正規の決済リクエストを攻撃者が捕捉して再送する、あるいはエージェント側のリトライ実装の不備で同じ注文が何度も送られます。結果として、同じマンデートで複数回の課金・出荷が発生します。ネットワーク的な故障やタイムアウトでリトライが起きるのは正常な挙動であり、「悪意」と「不具合」の両方が同じ症状（重複）を生む点が厄介です。
脅威4：暴走ループ購入（支出の暴走）
エージェントの制御ロジックの欠陥やプロンプト操作により、短時間に大量の注文が実行されます。「在庫が確保できるまで買い続ける」「安くなるまで発注し続ける」といった意図が暴走すると、支出が青天井になります。人間なら疲れて止まる操作を、エージェントは止まりません。
脅威5：返金・チャージバック悪用
注文後の局面での悪用です。エージェント経由の注文であることを逆手に取り、「自分は注文していない」「エージェントが勝手にやった」と主張してチャージバックや返金を不正に引き出す手口、あるいはアトリビューション（成果の帰属）を改ざんして紹介料・ポイントを詐取する手口が含まれます。「誰が本当に指示したのか」を後から証明できないと、マーチャントが一方的に負けます。
| 脅威 | 攻撃者が狙うもの | 主なシグナル | 防御の軸 |
|---|---|---|---|
| なりすましエージェント | 優遇された在庫・価格・レート | 署名なし／検証不能な名乗り | 真正性の暗号検証（入口） |
| マンデート偽造・改ざん | 上限額・対象・期限の書き換え | 署名不整合・スコープ逸脱 | 署名付きマンデート検証 |
| 決済リプレイ | 多重課金・重複出荷 | 同一キー／nonceの再出現 | 冪等性・リプレイ防止 |
| 暴走ループ購入 | 支出の暴走 | 短時間・高頻度・同一パターン | 支出上限・レート制限・ループ検知 |
| 返金・チャージバック悪用 | 不正返金・成果詐取 | 「指示していない」主張・帰属の不整合 | 証跡・非否認・アトリビューション保全 |
3. 第一層——エージェント本人性と権限の検証（入口で弾く）
最初の防御線は入口です。ここで問うべきは2つの別々の問いであり、混同すると穴になります。すなわち「このエージェントは本物か（真正性）」と「このエージェントはこの取引を委任されているか（権限）」です。
3-1. 真正性：Web Bot Authによる正体確認
正規のエージェントかどうかは、名乗り（User-Agent）ではなく暗号署名で確かめます。Web Bot Auth（HTTPメッセージ署名を用いてボットの正体を検証する仕組み）では、エージェントがリクエストに秘密鍵で署名し、マーチャントは公開鍵で検証します。鍵はエージェント運営者が公開する鍵ディレクトリで管理されるため、「署名が正しく検証できたエージェントだけを、正規プレイヤーとして扱う」という運用ができます。なりすまし（脅威1）は、この段階で大半を弾けます。
ポイント：Web Bot Authは「このリクエストは、公開鍵の持ち主が確かに送った」ことを保証しますが、「この取引をエンドユーザーが承認した」ことまでは保証しません。真正性は入口の一要素であり、権限の検証（次項）と必ずセットにします。
3-2. 権限：署名付きマンデートとOBO（委任）の検証
「誰が」「何を」「いくらまで」「いつまで」買ってよいか——この委任内容を表すのがマンデート（購入指示）です。AP2（Agent Payments Protocol）などが目指すのは、これを検証可能な形（署名付きの証明）で流通させることです。マーチャント側は、受け取ったマンデートについて次を検証します。
- 署名の正当性：マンデートが改ざんされていないこと（脅威2への直接の対策）。
- スコープの一致：実際の注文（商品・数量・金額）が、マンデートで許可された範囲に収まっていること。上限額・対象カテゴリ・数量の逸脱を拒否する。
- 有効期限とワンタイム性：期限切れのマンデート、および使用済みのマンデートを再利用させない。
- 委任チェーン（OBO：On-Behalf-Of）：「エージェント運営者 → エンドユーザー → 今回の取引」という委任の連鎖が途切れていないこと。誰の代理で動いているのかを明示的に持たせる。
真正性と権限の両方を通過したリクエストだけを、決済フローに進めます。ここまでを入口で徹底することが、後段の負荷とリスクを大きく下げます。
4. 第二層——決済フローの防御（お金を動かす瞬間を守る）
入口を通過しても、決済そのものの実装が甘ければ多重支払いや暴走が起きます。第二層は「一度きり・上限内・確認付き」を技術で担保します。
4-1. 冪等性（べきとうせい）：同じ注文は一度だけ
各注文リクエストに冪等性キー（Idempotency-Key）を持たせ、同じキーの再送に対しては新規課金を行わず、最初の結果を返すだけにします。これにより、正常なリトライも悪意ある再送も、同じく「二重課金しない」という一点に収束します。冪等性は、不具合と攻撃の両方に効く、決済防御の土台です。
4-2. リプレイ防止：nonce・タイムスタンプ・有効期限
冪等性が「同じ注文」を吸収するのに対し、リプレイ防止は「そもそも古い／使い回しのリクエストを受け付けない」ための仕組みです。リクエストに一意の値（nonce）と発行時刻を含め、サーバ側で短い有効期限と使用済みnonceの記録を持つことで、捕捉された正規リクエストの再送（脅威3）を無効化します。
4-3. 支出上限・レート制限・ループ検知
暴走ループ購入（脅威4）には、複数の粒度で上限を設けます。
- 取引単位：1注文あたりの上限額。
- 時間単位：1分・1時間・1日あたりの注文件数と累計金額の上限（レート制限）。
- 委任単位：1つのマンデート／1人のエンドユーザーに紐づく累計上限。
- パターン検知：同一商品への短時間・高頻度・等間隔の発注など、機械的なループの兆候を検知して自動で減速・停止させる。
上限は「拒否」だけでなく段階的な減速（レートの絞り込み）や保留（人間の確認待ち）と組み合わせると、正規トラフィックを止めずに暴走だけを抑えられます。
4-4. 二経路確認：高額・高リスクは別チャネルで承認
一定額を超える取引や、普段と異なるパターンの取引については、決済フローとは別の経路（アウトオブバンド）でエンドユーザーの承認を求めます。エージェント経由の1本の経路だけで完結させないことで、なりすまし・改ざん・暴走がすり抜けた場合の最後の関門になります。
5. 第三層——注文後の防御（返金・チャージバック・帰属を守る）
決済が通った後にも戦線があります。ここでの鍵は「非否認（後から否定させない）」と「帰属の保全」です。
5-1. 返金・チャージバックへの備え
「自分は注文していない／エージェントが勝手にやった」という主張（脅威5）に対しては、取引ごとの証跡が唯一の反証になります。少なくとも次を、改ざん困難な形で保存します。
- 検証済みのエージェント真正性（どの署名で正体確認したか）。
- 提示・検証された署名付きマンデート（誰が、何を、いくらまで委任したか）。
- 冪等性キーとnonce（一度きりの取引であった記録）。
- 二経路確認の結果（該当する場合）。
これらが揃っていれば、チャージバック審査に対して「正規に委任された取引である」ことを主張できます。証跡がなければ、エージェント経由という事実がそのまま加盟店側の不利に働きます。
5-2. アトリビューション改ざんへの対策
成果の帰属（どのエージェント・どの導線が売上を生んだか）が改ざんされると、紹介料やポイントが詐取されます。アトリビューション設計で用いる帰属情報（クリック・セッション・エージェント識別子）も、署名付きの真正性検証とひも付け、後から差し替えられない形で記録します。「売上を作る」側で整えたアトリビューションを、「守る」側でも保全するという発想です。
6. 監視と証跡——異常検知・監査ログ・封じ込め
多層防御を敷いても、すり抜けはゼロにはなりません。最後の層は「早く気づき、記録し、素早く止める」運用です。
6-1. 振る舞い検知（異常検知）
個々のリクエストは正常に見えても、集合として異常なパターンが見えることがあります。特定エージェントからの急な注文増、特定商品への集中、返金率の急上昇、同一マンデートの再出現の増加などを継続監視し、しきい値超過で自動アラートと自動減速につなげます。
6-2. 監査ログ（何を残すか）
後日の調査・チャージバック対応・インシデント対応に耐えるため、少なくとも「真正性検証の結果」「マンデートの内容と検証結果」「冪等性キー／nonce」「適用した上限・レート判定」「二経路確認の有無と結果」「最終的な許可／拒否／保留の判断理由」を、時刻・相関IDとともに残します。ログは非否認の証拠でもあるため、改ざん耐性を持たせます。
6-3. 封じ込め（キルスイッチ）
暴走やなりすましが確認されたとき、特定エージェント・特定マンデート・特定パターンを即時に遮断できる仕組み（キルスイッチ）を用意します。全体を止めずに、問題のある経路だけを止められる粒度が重要です。封じ込めの速さが、被害額を直接左右します。
まとめ——「買われる側」も多層防御で守る
エージェンティック・コマースは、「AIに選ばれ・買われる」ための強力な導線です。しかしその導線は、そのまま自動化された不正の入口にもなります。本稿の要点は次の通りです。
- 攻撃面が変わった：「人間らしさ」を頼れなくなり、署名・マンデート・支出パターンが新しいシグナルになる。
- 入口で二段に検証する：真正性（Web Bot Auth）と権限（署名付きマンデート・OBO）は別物。両方を通す。
- 決済は一度きり・上限内・確認付き：冪等性・リプレイ防止・支出上限／ループ検知・二経路確認。
- 注文後は非否認と帰属保全：証跡でチャージバックとアトリビューション改ざんに備える。
- 監視で早く止める：異常検知・改ざん耐性のある監査ログ・粒度の細かい封じ込め。
売上を作る設計を終えた企業ほど、次の一手は「守る設計」です。導線を広げた面積の分だけ、多層で守る——これがエージェンティック・コマース時代の不正対策の基本姿勢です。
よくある質問（FAQ）
Q1. Web Bot Authだけ導入すれば、なりすまし対策は十分ですか？
不十分です。Web Bot Authは「このエージェントは本物か（真正性）」を保証しますが、「この取引をエンドユーザーが承認したか（権限）」は保証しません。署名付きマンデートの検証と必ずセットで運用してください。
Q2. 冪等性とリプレイ防止は同じものですか？
目的が異なります。冪等性は「同じ注文が二重に処理されない」ことを保証し、正常なリトライにも効きます。リプレイ防止は「古い・使い回しのリクエストをそもそも受け付けない」ための仕組みで、捕捉された正規リクエストの再送を無効化します。両方を実装するのが基本です。
Q3. 支出上限はどの粒度で設ければよいですか？
取引単位・時間単位（レート）・委任単位（1マンデート／1ユーザー）の複数粒度を重ねるのが有効です。さらに、単純な拒否だけでなく「減速」や「人間の確認待ちで保留」を組み合わせると、正規取引を止めずに暴走だけを抑えられます。
Q4. エージェント経由の注文でチャージバックされたとき、加盟店はどう反証しますか？
取引ごとの証跡が反証の要です。真正性検証の結果、署名付きマンデート、冪等性キー／nonce、二経路確認の記録などを改ざん困難な形で保存しておけば、「正規に委任された取引である」と主張できます。証跡がないと、エージェント経由という事実が不利に働きます。
Q5. まず何から着手すべきですか？
入口の二段検証（真正性＋権限）と、決済の冪等性を最優先で固めるのが費用対効果に優れます。そのうえで支出上限とレート制限、監査ログの整備、封じ込めの仕組みへと広げていくのが現実的な順序です。
参考リンク
- Web Bot Auth（IETF／HTTP Message Signaturesを用いたボットの正体検証の取り組み）
- AP2：Agent Payments Protocol（エージェント決済における検証可能なマンデートの流通）
- Agentic Commerce Protocol（ACP）／関連するコマース連携仕様
- OWASP：Web／API／LLMアプリケーションのセキュリティリスク一覧
- PCI DSS：カード決済のセキュリティ要件
※ 上記は分野の参照先です。公開後、WordPress側で各仕様・団体の正式URLを差し込んでください。
コメント