ChatGPTに「一番コスパの良いものを買っておいて」と頼むと、AIが候補を比較し、決済まで済ませて注文番号を返してくる——2026年、これは実験ではなく日常の買い物体験になりました。前回の記事では、その決済を成立させるためのACP・UCP・AP2という3つのプロトコルへの「対応」を扱いました。しかし対応を終えた企業から、次に必ず出てくる問いがあります。「対応したのに、そもそもうちは選ばれているのか。そして、選ばれた売上を測れているのか」——本記事はこの2つの問いに正面から答えます。
はじめに——プロトコル対応の「次」に来る2つの問い
これまで当サイトのAEO（Answer Engine Optimization）関連記事では、AIに引用されるための商品データフィード設計、トランザクション面のコンバージョン設計、そして直近ではACP・UCP・AP2へのプロトコル対応を順に扱ってきました。これらはいずれも「技術的に対応する」話です。フィードを機械可読にし、決済を通し、署名付きマンデートを検証できる状態にする——ここまでが前回までの到達点でした。
ところが、プロトコル対応を完了した企業の担当者は、しばらくすると同じ壁に突き当たります。カートも在庫も機械可読にした。エージェント決済も通るようにした。それでも管理画面を見ると、エージェント経由でどれだけ選ばれ、どれだけ売れたのかが分からないのです。従来のUTMパラメータや「最終流入元」を見ても、AIエージェントの購買はそこに現れません。対応はしたはずなのに、成果が見えない——これがプロトコル対応の「次」に立ちはだかる壁です。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで、長年トラフィックの可視化と異常検知に携わってきました。本記事の視点はそこにあります。「対応する」ことと「選ばれる・測れる」ことは別の設計課題であり、後者はトラフィックを主体ごとに追跡し、経路を突合して可視化するという、ネットワーク運用に近い発想を必要とします。本記事は、既存のフィード設計（4月）・決済コンバージョン設計（4月）・プロトコル対応（7月）の「その先」として、次の2つに絞って解説します。
ひとつは選定最適化——AIショッピングエージェントが商社や商品を選ぶときに使う「信頼シグナル」を、どう設計・最適化するか。もうひとつは計測——エージェント経由で発生した売上を、どのようなアトリビューション・スタックで可視化するか。想定読者は、すでにプロトコル対応を終えた、あるいは着手中のEC事業者・ブランド・SaaS事業者のマーケティング／情シス／事業責任者の方々です。
前提の整理——「選定」と「計測」はなぜ従来手法で捉えられないのか
本論に入る前に、なぜこの2つが従来のSEO／広告の延長では扱えないのかを整理します。ここを押さえておくと、以降の施策がなぜ必要かが腑に落ちます。
「選定」の主体が人からエージェントに変わった
従来のECでは、選ぶのは人でした。人は商品ページの写真やレビューを「見て」判断します。しかしエージェンティック・コマースでは、選ぶのはAIエージェントです。エージェントは写真の雰囲気を感じ取ったりしません。機械可読な構造化データと、検証可能な信頼シグナルを読んで、アルゴリズム的に候補を絞り込みます。つまり「選ばれる」ための最適化対象が、人間向けのマーケティングから、エージェント向けのシグナル設計へと移っています。
さらに重要なのが、①で扱った署名付きエージェント（Web Bot Auth／RFC 9421）の位置づけです。エージェントが「正規か偽装か」を暗号的に検証できる仕組みは、いまや選定の前提条件になりつつあります。売り手側から見れば、来訪したエージェントの素性を検証できることが取引の入口であり、買い手のエージェント側から見れば、署名で身元を証明できる相手としか安全に決済できません。署名付きエージェントは「守り」の技術であると同時に、「選ばれる」ための最初のゲートでもあるのです。
「計測」の経路が最終流入では捕捉できない
従来のWeb解析は、ユーザーが自社サイトに「流入」してコンバージョンするという前提に立っています。UTMパラメータで流入元をタグ付けし、最終流入（ラストクリック）に売上を帰属させる——これが標準でした。ところがエージェント購買では、この前提が2重に崩れます。
第一に、ユーザーは自社サイトを訪れないことがあります。ChatGPTやGeminiの会話の中で比較・決済が完結し、自社サイトには一度も来ないまま注文だけが届く。ブラウザのCookieもリファラも、UTMパラメータも付きません。第二に、たとえ経由があっても、それは人間のクリックではなくエージェントのAPI呼び出しです。JavaScriptベースの計測タグは発火しませんし、そもそもブラウザですらないケースが多い。結果として、GA4のような従来型の計測基盤は、エージェント経由の売上を「ダイレクト」や「不明」に押し込めてしまいます。
この2つの断絶を、下表に整理します。
| 観点 | 従来のEC／SEO | エージェンティック・コマース |
|---|---|---|
| 選ぶ主体 | 人間（ページを見て判断） | AIエージェント（構造化データを読んで判断） |
| 選定の入口 | 検索順位・広告表示 | 署名検証・機械可読なフィード・信頼シグナル |
| 購買の場所 | 自社サイト／自社アプリ | AIの会話面（自社サイト非経由もあり） |
| 計測の起点 | ブラウザのタグ・Cookie・リファラ | エージェントのAPI呼び出し・プロトコルイベント |
| 帰属モデル | ラストクリック（最終流入） | エージェント経由イベントの突合・サーバーサイド計測 |
要するに、「選ばれる」も「測れる」も、従来手法の延長線上にはありません。以降で、この2つをそれぞれ設計していきます。
第1部：選定最適化——AIショッピングエージェントに「選ばれる」信頼シグナル設計
まず「選ばれる」側です。AIショッピングエージェントは、ユーザーの依頼に対して複数の商社・商品を候補として集め、その中から推薦・決済する相手を絞り込みます。この絞り込みで効いてくるのが「信頼シグナル」です。人間なら「なんとなく安心そう」で選ぶところを、エージェントは検証可能なシグナルの束で判断します。
エージェントは何を見て「選ぶ」のか
エージェントの選定は、大まかに「到達できるか→信頼できるか→条件が合うか→リスクが低いか」という順に進みます。どんなに価格が安くても、身元が検証できず、在庫や納期が機械可読でなければ、そもそも候補に残りません。逆に言えば、上流のゲートを通過することが、価格競争に参加する前提になります。
信頼シグナルの4階層
信頼シグナルは、次の4つの階層で捉えると設計しやすくなります。下から順に、土台がないと上が効かない構造です。
第1層：身元の検証可能性（署名）。 前述のとおり、署名付きエージェント（Web Bot Auth／RFC 9421 HTTPメッセージ署名）への対応は、いまや選定の前提です。売り手として、来訪エージェントの署名を検証できること、そして自社が買い手エージェントに対して正規のマーチャントであることを証明できること——この双方向の身元保証が土台になります。ここが欠けると、上位のシグナルがどれだけ整っていても、リスク回避的なエージェントからは選ばれにくくなります。
第2層：条件の機械可読性と鮮度。 価格・在庫・納期・送料・返品条件といった取引条件が、リアルタイムかつ機械可読で提供されているか。エージェントは古いフィードや曖昧な在庫表現を嫌います。「在庫あり」ではなく「残り3点・24時間以内出荷」のように、確定的で最新の値を返せることが、選定の決め手になります。フィードの鮮度そのものが信頼シグナルです。
第3層：取引実績と評価の構造化。 レビュー評価、返品率、配送遵守率、キャンセル率といった実績が、構造化データとして参照可能か。人間向けの★表示ではなく、エージェントが読み取れる形式で「約束を守る売り手である」ことを示せるかが問われます。プラットフォームが提供する販売者評価スコアも、ここに含まれます。
第4層：ポリシーの一貫性と決済の確実性。 提示した条件と実際の決済・配送が食い違わないこと。署名付きマンデート（AP2）で合意した金額・条件どおりに決済が成立し、キャンセルや価格変更が起きないこと。この「言ったとおりに実行される」という一貫性が、エージェントの再選択（次回も選ばれる）を左右します。
| 層 | 信頼シグナル | 具体的な打ち手 |
|---|---|---|
| 第1層：身元 | 署名の検証可能性 | Web Bot Auth対応、マーチャント認証、双方向の身元保証 |
| 第2層：条件 | 機械可読性と鮮度 | リアルタイム在庫・確定納期・送料/返品条件の構造化 |
| 第3層：実績 | 評価の構造化 | レビュー・返品率・配送遵守率を機械可読に公開 |
| 第4層：一貫性 | 決済の確実性 | マンデートどおりの決済、価格・在庫の乖離ゼロ |
「選ばれる」ための最適化は、SEOではなく品質保証に近い
ここで発想の転換が必要です。人間向けのSEOは「よく見せる」施策でした。しかしエージェント向けの選定最適化は、「約束を検証可能な形で示し、その約束を確実に守る」という品質保証の運用に近づきます。誇張したフィードは、条件の乖離としてすぐに実績シグナルに跳ね返り、次から選ばれなくなる。エージェント経済では、正直さと一貫性がそのまま競争力になります。これはネットワーク運用でいう「SLAを掲げたら守り、守れたことをログで示す」のと同じ構図です。
第2部：計測——エージェント経由売上を可視化するアトリビューション・スタック
次に「測れる」側です。選ばれているかを知るには、エージェント経由の売上を捕捉できなければなりません。前述のとおり従来のラストクリック計測では捕捉できないため、エージェント購買を前提にしたアトリビューション・スタックを組み直します。ここでも、トラフィックを主体ごとに識別し、経路を突合するというネットワーク運用の発想がそのまま使えます。
なぜUTM・最終流入では測れないのか（再確認）
エージェント経由の売上が「ダイレクト」や「不明」に消えてしまうのは、計測の起点をブラウザに置いているからです。エージェントはブラウザのタグを発火させず、Cookieもリファラも運びません。したがって計測の起点を、ブラウザからサーバーサイドのイベント——具体的にはプロトコルのやり取りと注文APIの呼び出し——へ移す必要があります。
アトリビューション・スタックの4層
エージェント経由売上を可視化するスタックは、次の4層で構成します。
第1層：エージェント識別。 到達したリクエストが、どのAIエージェント（ChatGPT／Gemini／その他）由来かを識別します。ここで効くのが署名です。Web Bot Authの署名や、リクエストに付随するエージェント識別子を使って、「誰が来たか」をログの最上流で確定させます。人間トラフィックとエージェントトラフィックを最初に分離することが、以降のすべての計測の起点になります。
第2層：プロトコルイベントの計測。 ACP・UCP・AP2のやり取りの各段階——候補としての参照、カート化、マンデート提示、決済確定——をイベントとして記録します。これはWeb解析でいうファネルに相当しますが、ブラウザではなくプロトコルのステート遷移を計測対象にします。どの段階で離脱したか（参照はされたが決済に至らなかった等）が、選定最適化の改善点を教えてくれます。
第3層：サーバーサイドの注文突合。 実際に成立した注文を、注文管理システム（OMS）やバックエンドの決済記録と突合します。エージェント識別子・マンデートID・注文IDをキーに、「このエージェント経由のこのセッションが、この注文になった」という因果をサーバー側で確定させます。フロントの計測タグに依存しないため、自社サイト非経由の購買も取りこぼしません。
第4層：統合ビューと帰属モデル。 第1〜3層のログを、既存のGA4や広告データと突合し、エージェント経由を独立したチャネルとして可視化します。ラストクリックに代わり、エージェント参照から決済までの経路イベントに基づく帰属を採ります。人間の検索・広告経由と、エージェント経由を並べて比較できる統合ビューを作ることが最終的なゴールです。
| 層 | 計測対象 | キーになる識別子 | 使う基盤の例 |
|---|---|---|---|
| 第1層：識別 | どのエージェント由来か | 署名・エージェント識別子 | エッジ／APIゲートウェイのログ |
| 第2層：イベント | 参照→カート→決済のステート遷移 | セッションID・マンデートID | プロトコルサーバーのイベントログ |
| 第3層：突合 | 成立注文との因果 | マンデートID・注文ID | OMS・決済記録・サーバーサイド計測 |
| 第4層：統合 | チャネル横断の帰属 | 統一顧客/注文キー | GA4（サーバーサイド）・BI・データウェアハウス |
計測設計の勘所——「ブラウザを捨て、サーバーで拾う」
最大の勘所は、計測の重心をフロント（ブラウザのタグ）からバックエンド（サーバーサイドのイベントとログ）へ移すことです。エージェント経済では、購買の事実が最も確実に残るのはサーバー側です。逆にブラウザのタグは、エージェント購買に対しては構造的に沈黙します。したがって、サーバーサイド計測（Measurement Protocol等）を主、ブラウザ計測を従とする設計に切り替えるのが、エージェント時代のアトリビューションの基本方針になります。これは、パケットをクライアントの申告ではなくゲートウェイのフローログで数えるのと同じ発想です。
選定×計測をつなぐKPIとダッシュボード設計
選定最適化（第1部）と計測（第2部）は、KPIでつながって初めて運用になります。計測で見えたボトルネックを選定最適化にフィードバックする——このループを回すために、最低限見るべき指標を挙げます。
エージェント参照シェア： 特定カテゴリで、自社がエージェントの候補に「参照された」回数の割合。選定の第一関門（第1〜2層の信頼シグナル）が効いているかを示します。参照→決済転換率： 参照されたうち、実際に決済まで至った割合。ここが低ければ、条件（価格・納期）か第4層の一貫性に課題があります。エージェント経由売上と客単価： チャネルとしての規模。条件乖離率／キャンセル率： 提示条件と実行の食い違い。第4層の信頼シグナルの健全性を示し、放置すると次回以降の参照シェアを削ります。
| KPI | 何を診断するか | 対応する打ち手 |
|---|---|---|
| エージェント参照シェア | 候補に残れているか（選定の入口） | 署名対応・フィード鮮度（第1〜2層） |
| 参照→決済転換率 | 選ばれ切れているか | 条件最適化・決済の確実性（第4層） |
| エージェント経由売上／客単価 | チャネルの規模と質 | 統合ビューでの継続モニタリング |
| 条件乖離率／キャンセル率 | 約束を守れているか | フィードと実行の整合、在庫連携 |
実装ロードマップ——プロトコル対応済み企業が次にやること
プロトコル対応を終えた企業が、選定最適化と計測に着手する順序を整理します。いきなり全部は要りません。土台から積み上げます。
ステップ1：エージェント識別の基盤を作る。 まず署名検証（Web Bot Auth）とエージェント識別を、エッジ／APIゲートウェイのログに実装します。ここが計測の第1層であり、選定の第1層でもある——最優先の共通基盤です。ステップ2：プロトコルイベントを計測する。 ACP・UCP・AP2のステート遷移をイベントログに落とし、参照→決済のファネルを可視化します。ステップ3：サーバーサイドで注文を突合する。 マンデートID・注文IDでOMSと突合し、自社サイト非経由の売上まで捕捉します。ステップ4：信頼シグナルを最適化する。 計測で見えたボトルネック（低い転換率、高い乖離率）を起点に、第2〜4層のシグナルを改善します。ステップ5：統合ビューでループを回す。 既存チャネルと並べたダッシュボードを作り、KPIで改善を継続します。
よくある質問（Q&A）
Q1. プロトコル対応（ACP・UCP・AP2）さえ済ませれば、選ばれるようになりますか？
プロトコル対応は「取引できる状態になる」ことであって、「選ばれる」こととは別です。エージェントは、身元の検証可能性（署名）・条件の鮮度・実績・一貫性という信頼シグナルの束で候補を絞り込みます。対応は入場券にすぎず、選定はその先の信頼シグナル設計で決まります。本記事の第1部がその設計にあたります。
Q2. なぜGA4のUTMパラメータではエージェント経由売上が測れないのですか？
UTMやラストクリック計測は、ユーザーがブラウザで自社サイトに流入することを前提にしています。エージェント購買では、AIの会話面で決済が完結し自社サイトに来ないケースがあり、来ても発火するのはAPI呼び出しでブラウザのタグではありません。結果としてエージェント経由売上は「ダイレクト」や「不明」に消えます。計測の起点をサーバーサイドのプロトコルイベントに移す必要があります。
Q3. 署名付きエージェント（Web Bot Auth）は「守り」の技術では？なぜ選定や計測に関係するのですか？
署名は確かになりすましボットを遮断する「守り」の技術ですが、同時に「誰が来たか」を暗号的に確定させる技術でもあります。だからこそ、選定では「検証可能な身元を持つ相手だけが安心して選ばれる」前提になり、計測では「エージェントを識別する最上流のキー」になります。①で扱った守りの仕組みが、そのまま選定と計測の土台として二重に効くのがポイントです。
Q4. 小規模ECでも、ここまでの計測基盤が必要ですか？
フルスタックを一度に組む必要はありません。まずステップ1（署名検証とエージェント識別のログ化）だけでも、エージェント経由トラフィックを人間と分離して可視化できます。規模に応じて、プロトコルイベント計測、注文突合へと段階的に拡張してください。重要なのは「サーバー側にログを残す」という起点を最初に押さえることです。
Q5. 誇張したフィードで、とりあえず候補に食い込むのは有効ですか？
短期的にも逆効果になりやすい戦術です。提示条件と実際の決済・配送が食い違うと、条件乖離率やキャンセル率という実績シグナルに跳ね返り、エージェントの次回の選定で候補から外れていきます。エージェント経済では正直さと一貫性が最も効率の良い競争戦略です。品質保証の発想でシグナルを整えるのが、結局は最短ルートになります。
まとめ——「対応した」の次は「選ばれる・測れる」で差がつく
エージェンティック・コマースの議論は、長らく「どうプロトコルに対応するか」に集中してきました。しかし対応が一巡した2026年後半、勝敗を分けるのは「選ばれているか・測れているか」という運用の質です。要点は3つです。
1. 選定は信頼シグナルで決まる。 署名（身元）・鮮度（条件）・実績・一貫性の4階層を、品質保証の発想で整える。誇張ではなく、検証可能な約束と、その確実な実行が競争力になります。
2. 計測はブラウザを捨ててサーバーで拾う。 UTM・ラストクリックではエージェント購買は測れません。エージェント識別→プロトコルイベント→注文突合→統合ビューの4層で、サーバーサイドに計測の重心を移します。
3. 署名付きエージェントが両者の土台になる。 ①で扱った守りの技術は、選定の入口であり、計測の最上流キーでもあります。守り・選定・計測が一本の軸でつながるのが、エージェント時代の設計の妙です。
プロトコル対応は入場券にすぎません。「対応した」の次に、選ばれる信頼シグナルを設計し、選ばれた売上を可視化する——このループを回せる企業が、エージェント経済の売上を実際に手にします。
参考リンク
- 【2026年版】エージェンティック・コマース対応ガイド——ACP・UCP・AP2の3プロトコルをどう選び対応するか（前回記事）
- 【2026年版】”AIエージェントの本人確認”実装ガイド——Web Bot Auth（RFC 9421）で正規か偽装かを暗号的に検証する（①）
- 【2026年版】AEOのクエリリサーチ完全ガイド
- 【2026年版】AEO×「コンテンツの値付け」戦略ガイド
免責事項： 本記事は2026年8月時点の公開情報および一般的な設計論に基づく情報提供であり、特定の製品・構成における成果や計測精度を保証するものではありません。また、法的・税務的助言ではありません。プロトコルの仕様、計測基盤の仕様、および関連するプライバシー・広告関連法令は更新されるため、実装にあたっては最新の公式情報を確認し、必要に応じて専門家にご相談ください。
コメント