エージェント経由で売れた注文は、誰のものとして残るのか：買い手を特定する鍵はすべて任意だった

エージェント経由の注文と、顧客の紐付けとは

ここで言う紐付けとは、エージェント経由で成立した注文を、自社の顧客台帳にある特定の顧客の行に結びつけることです（この言い方は私たちの整理です）。自社サイトの購入なら会員ログインや注文時のメールアドレスが鍵になります。エージェント経由では、その鍵が仕様のどこに、どの要件で置かれているかを読みます。

売れたあとに自社へ何が残るかの全体像は自社に残る顧客データの記事で扱いました。この記事は、その中の「注文を誰に紐づけるか」を条文で詰めたものです。UCPそのものの位置づけはUCP・ACP・MCPの違いの記事、商品データの渡し方はエージェント向けの商品データの記事にあります。

仕様は、紐付けをどう位置づけているのか

1　アクセスレベルは3段で、購入は2段目でも動く

Identity Linkingの仕様は、機能が3つのアクセスレベルで動くとしています。1段目はPublic（認証なし）、2段目はAgent-authenticated（プラットフォームの資格情報＝client_id／client_secret。例としてゲストチェックアウト、カートの作成）。3段目はUser-authenticated（それにユーザーの識別トークンを加えたもの。例として保存済み住所、完全な注文履歴）です（UCP「Identity Linking」版 2026-08-25、2026年10月17日取得。英文は原文［1］。訳は私たちのものです）。

ゲストチェックアウトとカートの作成は、2段目のAgent-authenticatedの例として挙げられています。本人の紐付けは、3段目へ上がるための仕組みとして置かれています。

2　仕様が「ゲートではない」と明言している

同じページは、こう書いています。「Capabilities without identity linking still operate at public or agent-authenticated access levels — identity linking upgrades the experience, it does not gate it.」（同仕様、2026年10月17日取得。訳は上の段落のとおりで、私たちのものです。原文［1］）

ここは私たちの読みですが、この一文は両面です。紐付けを求めないぶん購入の体験は途切れず、同時に、紐付けのないまま売れる経路が仕様の上に残ります。仕様が任意にしているのは、買える体験を壊さないためだと読めます。不利に設計されている、という話ではありません。

3　紐付けの認可サーバーは、事業者側が持つ

紐付けの仕組みはOAuth 2.0で、役割は3つに分かれます。プラットフォームはUser Agent（ユーザーに代わって紐付けを開始する仲介者）、事業者はAuthorization Server / Relying Party（自身の認可サーバーをホストする）、ユーザーはResource Owner（紐付けられる本人）です（同仕様、2026年10月17日取得。原文［1］）。

3段目の経路を開くかどうかは、事業者側の実装で決まります。経路は1本ではありません。事業者ドメインへの直接のOAuth 2.0は常に利用でき、事業者が config.providers で信頼する外部のIDプロバイダを宣言した場合は、プラットフォーム側が、適切な上流トークンを持っていればブラウザのフローを省いて識別を連鎖させてもよい（MAY）、とされています。事業者がするのは宣言までです（同仕様、2026年10月17日取得）。

注文には、何が必須で乗るのか

1　必須の項目に、買い手の情報はない

注文（Order）の項目を読みます。この記事で確認した範囲で必須は、ucp、id、checkout_id、permalink_url、line_items、fulfillment、currency、totals の8つ。任意は label、adjustments、policies、messages、attribution の5つです（UCP「Order」版 2026-08-25、2026年10月17日取得。原文［2］）。

この13項目に、買い手（buyer）の項目は含まれていません。注文の項目名にも、order_id・email・customer はありません（2026年10月17日に取得したOrderページを、大文字と小文字を区別せずに検索した結果です。customer の語は、調整〈adjustments〉の説明文の例「Customer requested」に一度だけ現れますが、項目名ではありません）。

買い手につながる情報は、ゼロではありません。必須の fulfillment の中の Expectation には destination（配送先の住所）が必須で置かれ、Postal Addressの定義には first_name、last_name、phone_number が任意で並びます（同仕様、2026年10月17日取得。原文［2］）。氏名と電話番号は、必須の配送先の中に任意で乗りうる鍵です。ただし仕様の定義は「住所に紐づく連絡先」の氏名で、買い手本人とは限りません。突合には弱い鍵ですが、使えます。メールアドレスは、読んだOrderページの項目には出てきません。

2　鍵の連鎖は、途中から任意になる

買い手へ辿る線も1本あります。checkout_id です。注文からチェックアウトへは必須の項目で戻れますが、そのチェックアウト側の buyer（買い手の表現）は任意で、Buyerの中身（first_name、last_name、email、phone_number）もいずれも任意です（UCP「Checkout」「Reference」各仕様 版 2026-08-25、2026年10月17日取得。原文［3］）。

UCP「Order」「Checkout」「Reference」各仕様 版 2026-08-25（2026年10月17日取得）の記述を、私たちが辿る順に並べたもの。仕様にこの表はない。要件の語（Required／Optional）は仕様の表記。1行目の原文は “checkout_id | string | Required | Associated checkout ID for reconciliation.”。

連鎖の1段目は必須ですが、2段目から任意になります。鍵が任意ということは、相手が渡さない場合がある、ということです。渡されるかは、その注文がどのアクセスレベルで成立したか、双方が何を実装したかで変わります（ここは私たちの読みで、仕様が頻度を述べているわけではありません）。

3　経路の情報（attribution）も任意で、注文の上では読み取り専用

台帳に欲しくなるもう1つは「どこから来た注文か」です。仕様のattributionは、プラットフォームが発するリファラルおよびコンバージョンイベントの文脈 ── キャンペーンの識別子、クリックID、source／mediumのマーカーなど ── と定義され、要件は任意です（同リファレンス、2026年10月17日取得。原文［3］）。

注文の側では、事業者が元のチェックアウトのattributionのスナップショットを出してもよい（MAY）とされ、注文の上では読み取り専用で、エージェントが order.attribution を書くことはない、とされています（同じOrderの仕様、2026年10月17日取得。原文［2］）。

あわせて押さえる言葉

では、どこで鍵を持つか

1　自社の台帳側に、鍵を置く

まず前提を1つ。任意の項目でも、事業者が要求する経路は仕様にあります。Checkoutの仕様の例には、買い手のメールアドレスを必須として差し戻すエラー（code は field_required、内容は「Buyer email is required」）があり、その重大度は帯域内で解決できる recoverable です。求める入力をAPIで得られないときだけ requires_buyer_input となり、continue_url で買い手を事業者の画面へ渡す形になります（UCP「Checkout」版 2026-08-25、2026年10月17日取得。原文［4］）。要求はできる。ただし値が渡ってくることの保証ではありません。ここからは私たちのやり方です。台帳側の鍵は、相手の実装にも購入の流れにも触らず、自社だけで動かせます。だから順番は、まず自社の台帳の側で鍵を持つことからです（顧客台帳のつくり方）。

2　渡ってくる分と、来ない分を分けて数える

次に、エージェント経由の注文を、買い手の情報が渡ってきた分と来ていない分に分けて数えます。注文には checkout_id が必須で付くので、注文自体は1件1行で載ります。載らないのは、その行が自社の既存顧客の誰なのかという対応です。売上は数えられるのに、顧客が数えられない。この差を月次で見ると、紐付けへの投資を数字で決められます（この見方は私たちの整理です）。

3　紐付けの入口を、自社側に用意するかを決める

3段目に上がる経路を用意するかは、事業者側の判断です。用意すれば、保存済み住所や完全な注文履歴といった、仕様が3段目の例に挙げる体験に手が届きます。用意しなければ、エージェント経由の売上は立っても、顧客としての蓄積は自社の台帳の外に置かれたままになります（この対比は私たちの読みです）。

紐付けができた注文を、会員や契約の情報とどう結合するかは会員・契約情報の結合の記事で扱っています。

いまのデータで何が渡せて、何が足りないか。1枚に書き出すところから始めます。
ご相談は営業を受ける場ではありません。一行でも構いませんし、フォームは7項目・3分で送れます。

30分の相談を申し込む

エージェント経由の注文について、よくある質問

エージェント経由で売れた注文は、自社の顧客と紐づきますか？

仕様の上では、紐づかない場合があります。ゲストチェックアウトは、プラットフォームの資格情報だけで動くエージェント認証レベルの例として挙げられ、本人の紐付けは購入のゲートではない、とされているためです（UCP「Identity Linking」版 2026-08-25、2026年10月17日取得。訳は私たちのもの）。

注文のデータには、買い手のメールアドレスは含まれますか？

注文の項目一覧に買い手の項目はなく、buyer はチェックアウト側に任意で置かれ、その中の email も任意です。一方、必須の配送先（Postal Address）には first_name・last_name・phone_number が任意で並びます（UCP「Order」「Checkout」「Reference」各仕様 版 2026-08-25、2026年10月17日取得。訳は私たちのもの）。メールアドレスは、読んだOrderページの項目には出てきません。

本人の紐付けを、購入の条件にはできないのですか？

購入のゲートにはできません。仕様は、本人の紐付けがない機能も公開レベルまたはエージェント認証レベルで動作し続け、紐付けは体験を引き上げるものでありゲートするものではない、としています（UCP「Identity Linking」版 2026-08-25、2026年10月17日取得。訳は私たちのもの）。事業者にできるのは、紐付けの入口を用意することと、自社の台帳側で鍵を持つことです。

買い手の項目は、事業者から要求できないのですか？

要求はできます。Checkoutの仕様の例には、買い手のメールアドレスが足りないことを指すエラー（code は field_required、path は $.buyer.email、内容は「Buyer email is required」）があり、重大度は recoverable ── プラットフォームが値を入れて再送すれば購入の流れは続く区分です。求める入力をAPIで得られないときだけ、continue_url で買い手を事業者の画面へ渡す形（requires_buyer_input）になります（UCP「Checkout」版 2026-08-25、2026年10月17日取得。訳は私たちのもの）。ここは私たちの読みですが、要求できることと、実際に値が渡ってくることは別です。

この記事の内容は、いつ時点の仕様ですか？

版 2026-08-25 の仕様ページを、2026年10月17日に取得して読んだ内容です。読んだのは Order・Checkout・Identity Linking・Reference の4ページで、これ以外のページの記述は扱っていません。仕様は更新されるため、実装の前に同じページを開き直してください。

まとめ

エージェント経由の注文が自社の顧客に紐づくかは、仕様の要件の強さで決まります。アクセスレベルは3段で、ゲストチェックアウトは2段目（エージェント認証）の例です。仕様は本人の紐付けを、体験を引き上げるものでありゲートするものではない、としています（UCP「Identity Linking」版 2026-08-25、2026年10月17日取得。訳は私たちのもの）。

注文の項目では checkout_id が必須である一方、買い手の項目は一覧になく、チェックアウト側の buyer もその中の email も任意でした。必須の配送先の中に氏名と電話番号が任意で乗りうる点だけが、弱い鍵として残ります（UCP各仕様 版 2026-08-25、2026年10月17日取得）。鍵の連鎖は、1段目は必須でも2段目から任意になります。

任意は、事業者が要求できないことを意味しません。Checkoutの仕様の例には、買い手の項目を必須として差し戻すエラーがあり、重大度は帯域内で解決できる区分です。要求できることは、渡ってくることの保証ではありません。経路の情報（attribution）も任意で、注文の上では読み取り専用です。紐付けのないまま売れる経路は、仕様の上では開いたままです。仕様は、事業者に不利か有利かを述べてはいません。

だから、鍵は自社の台帳側で持ちます。やることは3つです。顧客を1人に数える鍵を台帳に置く、エージェント経由の注文を「渡ってきた分」と「来ていない分」に分けて数える、紐付けの入口を用意するかを決める。売上は数えられるのに顧客が数えられない差を、月次で見える形にしておくことが出発点です。

エージェント経由の売上が増えたときに自社に何が残るか ── その手前の現在地は、顧客資産化診断（7問・約3分）で分解できます。

出典と、書けなかったこと

引用した原文