検索して、比較して、カートに入れて、決済する。この一連の動きを、人間ではなくAIエージェントが代わりにこなす仕組みが、2025年後半から急速に立ち上がりました。
きっかけの一つが、Googleが2025年9月に公開したAgent Payments Protocol（AP2）です。Google Cloudの公式発表によれば、Mastercard・PayPal・American Express・Salesforceなど60社以上が名を連ねる、オープンな決済プロトコルです。
この記事では、エージェントコマースと呼ばれるこの動きの中身を整理したうえで、流入元の正しい見方やファネル分析の基本といった、これまでの計測の前提がどこで崩れるのかを考えます。
自社ECを運営している方だけの話ではありません。プロダクトの申込フォームやセルフサーブの契約フローを持つSaaSであれば、遅かれ早かれ同じ問いに向き合うことになるはずです。
結論を先に言うと、崩れるのは、訪問者は人間でページを順に見て回るという前提そのものです。この前提の上に、ファネル・流入元・コンバージョン率といった指標はすべて組み上がっています。
まずは、エージェントコマースが何を指すのか、言葉の中身から確認していきましょう。
エージェントコマースとは何か
エージェントコマースとは、商品の比較検討から決済までの一連の購買行動を、人間に代わってAIエージェントが実行する購買のかたちを指します。
チャット型のAIアシスタントに、予算内で一番評価の高い加湿器を買っておいてと頼む場面を想像してください。エージェントが候補を比較し、条件に合う商品を選び、決済まで済ませてくれる体験です。
ここで重要なのは、エージェントがページを閲覧するのではなく、APIやプロトコルを介して直接やり取りする点です。人間がブラウザでボタンを押す代わりに、エージェント同士が定められた手順に沿ってデータをやり取りし、取引を成立させます。
この決められた手順を標準化しようとする動きが、2025年後半に一気に具体化しました。次の章で、その代表格であるAP2の中身を見ていきます。
Agent Payments Protocol（AP2）の仕組み
AP2は、エージェントが購入を実行してよいという権限の証明を、暗号署名つきの記録として残す仕組みです。
Google Cloudの発表は、AP2が解こうとしている課題を三つに整理しています。エージェントに購入の権限を本当に与えたのかという認可、エージェントの要求が利用者の本当の意図を反映しているかという真正性、そして問題が起きたときに誰の責任かという説明責任です。
これらを支える中心的な仕組みが、マンデート（mandate）と呼ばれる署名つきの契約データです。次の表に、代表的な二つのマンデートをまとめました。
| マンデート名 | 何を証明するか | 発行されるタイミング |
|---|---|---|
| Intent Mandate | 利用者が最初に出した依頼の内容と条件 | エージェントに依頼した直後 |
| Cart Mandate | 決済直前に確定した商品と金額の中身 | 決済を実行する直前 |
利用者はエージェントに、予算1万円以内でといった条件を伝えます。この条件がIntent Mandateとして記録され、エージェントが候補を絞り込んだ結果はCart Mandateとして固定される、という流れです。
この二段構えによって、加盟店は利用者が本当に承認した内容と金額で決済が実行されたことを、後から検証できるようになります。人間が目視で確認するのではなく、署名という形で確認可能性を担保する発想です。
AP2は、エージェント同士の対話手順を定めるAgent2Agent（A2A）プロトコルを土台にしています。Google Cloudの別の解説記事でも、A2AとAP2は一体のものとして紹介されており、対話の標準とお金の標準がセットで整備されつつあることが読み取れます。
検証可能性という考え方
マンデートの背骨にあるのは、Verifiable Credentials（検証可能な証明書）と呼ばれる技術です。デジタル世界の身分証明書のようなもの、と考えるとつかみやすいかもしれません。
紙の契約書にハンコを押すのと同じように、誰が何を承認したかを暗号的な署名として残す。人が目を通さなくても、後から機械的に検証できる状態を作っておく発想です。
これまでのウェブ計測は、行動のログを残すことはあっても、その行動を誰がどんな条件で承認したかまでは残してきませんでした。エージェントコマースの世界では、この承認の記録そのものがデータの一部になるという違いを、まず押さえておきたいところです。
なぜ今なのか
なぜこの標準化が、2025年後半というタイミングで一気に動いたのでしょうか。
背景にあるのは、生成AIの対話能力が実用レベルに達し、チャット上で完結する購買体験を各社が競って提供し始めたという事情です。チャットで質問し、比較し、その場で買う一連の流れを、画面遷移なしで実現しようとする動きだと言えます。
こうした流れを安全に任せるには、決済までを保証できる標準がどうしても必要になります。だからこそ、AP2のような枠組みが同じ時期に立ち上がったのは、偶然ではありません。
決済網の側も動いています。AP2には、決済ネットワーク各社が自社の仕組みを載せられるよう設計されており、大きな標準が一つでき、その上に各社の実装が乗るという積み上げ方が想定されています。
ここでいったん、Stride自身の立ち位置にも触れておきます。StrideはCookieを使わず個人を特定しない計測ツールで、CRMやMAのように個人へ働きかける機能は持ちません。
エージェントコマースの決済そのものに関わる製品ではなく、あくまで自社サイトに来た反応を計測する側であるという前提で、この先を読み進めてください。
このように土台が整備される一方で、計測する側には積み残された宿題があります。次の章から、その宿題の中身に入っていきます。
訪問者という前提が壊れる場所
ウェブ解析の指標は、ほぼ例外なく、訪問者がページを開き順番に見て回るという前提の上に組まれています。
セッション、ページビュー、直帰率、いずれもこの前提が土台です。エージェントコマースでは、この前提がそのまま成り立たなくなる場面が出てきます。
たとえば、エージェントが商品情報をAPI経由で直接取得し、ページを一度も表示せずに決済まで進めるケースです。この場合、サイト側のアクセスログには、通常の閲覧とは明らかに違う痕跡が残ります。
# 人間の訪問(複数ページを順に閲覧)
GET /products/humidifier-a2 200 Referer: (検索結果)
GET /products/humidifier-b1 200 Referer: /products/humidifier-a2
GET /cart 200 Referer: /products/humidifier-b1
POST /checkout 200
# エージェント経由の取引(1回のAPI呼び出しで完結)
GET /api/products?category=humidifier 200 UA: SomeAgent/1.2 (+mandate-based)
POST /api/checkout 200 UA: SomeAgent/1.2 (+mandate-based)
上のログはあくまで説明用の仮の例ですが、言いたいことは単純です。エージェント経由の取引は、ページビューという痕跡をほとんど残さない可能性があるということです。
これは、流入元の正しい見方で扱った、検索・広告・SNSを分けて見るという発想の、もう一段先の課題でもあります。
人間の訪問者を検索・広告・SNS・メールに分類してきたのと同じように、これからはエージェント経由のアクセスを、それ以外のトラフィックから見分けて分類する必要が出てきます。
見分ける手がかりは、UA(User-Agent)文字列や、APIエンドポイントへの直接アクセス、リファラの欠如といった組み合わせです。ただし、これらの手がかりは各社の実装で今後変わっていく可能性が高く、固定的な分類ルールとして確立しているわけではない点には注意が必要です。
ファネルという物差しの限界
ファネル分析の基本では、訪問から成約までを段階に分け、どこで離脱しているかを見る考え方を紹介しました。
この考え方は、利用者が複数のステップを順番に踏むことを前提にしています。エージェントコマースでは、この前提そのものが揺らぎます。
次の表は、従来の人間の訪問者・検索エンジンなどのクローラー・取引を実行するエージェントの三者を、計測の観点から比較したものです。
| 種別 | 典型的な行動 | ページビューの痕跡 | コンバージョンの形 |
|---|---|---|---|
| 人間の訪問者 | 複数ページを閲覧し比較検討する | 多い | ページ上のフォーム送信・購入完了 |
| 情報収集クローラー | ページ内容を機械的に取得する | 多いが購入に至らない | 基本的に発生しない |
| 取引エージェント | APIを介して直接照会・決済する | 少ない、または無い | APIコールとして完結する |
この三者を一括りにセッションとして数えてしまうと、コンバージョン率のような指標は意味を失います。クローラーが混ざれば分母だけが膨らみ、取引エージェントが混ざればページビューを経ない成約が指標から漏れ落ちるからです。
ここで一つ、仮の数字で考えてみます。以下の数字は説明用の仮定であり、実データではありません。
あるサイトで月間1万セッションのうち、仮に500件が取引エージェント経由の直接API呼び出しだったとします。この500件がページビューを経由しないなら、従来のファネル集計ではそもそも分母にすら現れません。
つまり、実際のコンバージョン件数は変わらないのに、計測上のファネルにだけ映らない成約が生まれる可能性があるということです。これは決して小さな話ではありません。
すべての取引がエージェント経由になるわけではもちろんありませんが、割合が増えていくほど、この見えない部分は無視できなくなっていきます。だからこそ、次の章で扱う測定基盤の備えが意味を持ってきます。
今のうちに測定基盤にしておくべきこと
Google Cloudの解説記事は、事業者側の備えとして三つの方向性を挙げています。商品データを構造化して機械にも読み取りやすくすること、標準プロトコルに対応できるデータ基盤とAPIを用意すること、そして重要な判断には人の目を残すことです。
この三つは製品・データ寄りの話ですが、計測という観点からも、ほぼそのまま当てはめられます。順に見ていきましょう。
一つ目は、トラフィックの発生源を細かく記録しておくことです。UA文字列やアクセス経路をログに残しておけば、後からエージェント経由だったと再分類する余地が残ります。
今すぐ完璧な分類ルールを作る必要はありません。判断材料になる生データを、まず残しておくべきです。
二つ目は、アトリビューションの実務で触れた考え方の延長で、単一の指標に依存しない体制を作ることです。ページビュー起点のファネルだけに頼っていると、API経由の成約が計測から漏れます。
売上や注文データといった、ページビューを経由しない数字とも突き合わせる習慣が要ります。地味ですが、これが一番効きます。
三つ目は、GTMにAIエージェントを入れるで扱ったガードレールの発想を、計測の側にも及ぼすことです。エージェントが人間の代わりに動く場面が増えるほど、誰が、どの権限で、その行動をしたのかを後から追跡できる仕組みの価値が上がります。
AP2のマンデートが決済の世界でやろうとしていることと、根っこは同じです。
エージェントコマースはまだ始まったばかりで、標準規格も実装も動き続けています。ただ、訪問者は人間だという前提の上に指標を積んできたという事実は変わりません。
土台が動くときほど、まず生データを広めに残しておく。派手ではありませんが、これが一番効く備えではないでしょうか。
参考にした一次情報は以下の通りです。