AI経由の注文後はどうする？UCPで発送・返金の状況を伝える仕組み

AIの画面で商品が売れた後、お客さんが「いつ届く？」「返品の後、お金は戻った？」と尋ねたら、誰が答えるのでしょうか。注文を受ける仕組みだけでなく、店で起きたことをAI側へ伝える仕組みも必要になります。

UCP（Universal Commerce Protocol）は、店とAIなどの買い物サービスが、商品選びや購入の情報をやり取りするための共通ルールです。その中のOrderという機能は、購入が確定した後の注文を扱います。何を買ったか、どう届けるか、その後に何が起きたかを伝えるための仕様です。[1]

この記事は、AI経由の販売を検討している通販サイトの運営担当者向けです。発送や返金で店に残る仕事と、AIへ渡す情報を、一つの注文で追います。確認日は2026年9月12日、参照する仕様は2026-08-25版です。特定のAIサービスへの新規申込ガイドではありません。

店の注文記録を、買い物をしたAIの画面へつなぐ

例えば、AIの買い物画面でバッグを二つ購入したお客さんがいるとします。片方を先に発送し、もう片方は入荷待ちになりました。AI側が最初の「注文完了」しか知らなければ、その後に聞かれても正しい状況を答えられません。

UCPのOrderは、店の注文記録を更新して相手へ伝えるために使います。荷物を運ぶのは店が使う配送の仕組みで、返金するのは店が使う決済の仕組みです。Orderは、それらで起きた事実を共有する役割を担います。[1]

お客さんにとっては、買い物を始めた画面から、その後の状況を確認しやすくなる可能性があります。店にとっては、AI側へ伝える情報の形式をそろえられます。問い合わせが何割減るかなどの効果は、導入した店の運用で確かめる必要があります。

商品がAIに紹介されるまでの準備は別に必要です。Googleとの購入連携の入口については、GoogleのAIで商品を売るためのガイドで説明しています。ここから先は、対象サービスとの接続を済ませ、注文が成立している前提で読み進めてください。

注文番号と購入手続きの番号を結び付ける

購入途中の情報にはCheckout、成立した注文にはOrderを使います。Checkoutは、商品や配送先を選び、金額を確認して購入を完了するまでの手続きです。[1]

注文側には、注文番号のidと、元の購入手続きを示すcheckout_idがあります。これによって、AI側で進めていた購入と、店が受け付けた注文を照合できます。[1][2]

以下は説明用の抜粋です。商品・注文番号・アドレスは架空です。注文全体には、仕様の版、商品明細、配送情報、合計などの必須項目も必要で、この四項目だけを実際に送るものではありません。

{
  "id": "order-bag-001",
  "checkout_id": "checkout-bag-001",
  "permalink_url": "https://shop.example.com/orders/order-bag-001",
  "currency": "USD"
}

permalink_urlは、店の注文ページへのアドレスです。shop.example.comは説明用なので、開いて使うサイトではありません。実装では、その注文を正しく確認できる自社のページを返します。[2]

このアドレスを案内することと、誰にでも注文内容を公開することは別です。住所などの情報がある注文ページでは、購入者を確認する仕組みが必要になります。AIから注文データを取得する場合も、店は相手の認証と、その注文を見てよい権限を確認します。[1]

「届ける予定」と「実際に発送した」を別の情報にする

注文のfulfillmentは、商品を届けることに関する情報です。その中で、予定や約束を入れるexpectationsと、実際に起きたことを入れるeventsを分けます。[1]

例えば「明日発送予定」と、「配送会社へ荷物を渡した」は違います。予定が書かれただけで発送済みと案内すると、お客さんが追跡しても荷物が見つからないかもしれません。

バッグ二つの架空の注文で、一つだけ発送したなら、その数量が分かるようにします。商品明細の数量では、現在の注文数をtotal、発送などの提供を済ませた数をfulfilledで表します。今回ならtotalが2、fulfilledが1という状態です。[1]

店で確認したこと	AI側へ伝える内容の例
バッグ二つの注文が成立した	注文番号と二つの商品数量
一つだけ配送会社へ渡した	対象の商品明細、数量一つ、発送の記録
残り一つの発送時期が変わった	残りの配送予定の変更
お客さんへ配達された	配達されたことを示す記録

仕様の配送イベントには、発送を表すshippedや、配達を表すdeliveredなどが例示されています。追跡番号や追跡先のアドレスを伝える項目もあります。日付は、通知を作っただけの時刻ではなく、その出来事が起きた時刻として扱う項目です。[1]

「二つのうち一つが発送済み」と分かれば、AI側は注文全体を完了したように案内せずに済みます。数量、出来事、予定を別に持つ意味は、こうした途中の状態を伝えられることです。

店からAIへ通知する方法と、AIが取りに来る方法がある

店で注文の状態が変わったら、相手のAIサービスへ通知できます。この通知をWebhookと呼びます。相手が何度も問い合わせなくても、変更した側から知らせるための仕組みです。[1]

通知先は、AIサービス側が用意します。仕様では、接続時に共有される相手の設定のwebhook_urlから通知先を確認します。店が自分の商品ページに通知先らしいURLを書くだけで、任意のAIへ接続できるものではありません。[1]

送るのは、変更した項目だけの短いメモではなく、現在の注文全体の情報です。バッグ一つの発送が進んだときも、どの注文の現在の状態なのかを、商品明細や配送情報とともに伝えます。[1]

一方、AI側から店へ取りに来る方法もあります。REST方式、つまりWebのアドレスへ決まった方法で依頼する方式では、GET /orders/{id}で注文の現在の情報を取得します。GETは情報を取得する依頼、{id}は対象の注文番号が入る位置です。[2]

今回の例なら、接続済みの店のAPIへ/orders/order-bag-001を指定します。APIは、プログラム同士で注文データをやり取りする窓口です。店は相手がこの注文を見てよいかを確認してから返します。存在しない注文や権限がない場合のエラーも、公開仕様にあります。[2]

通常の更新は通知を使い、必要なときに取得して照合する、という使い方が仕様で推奨されています。どちらも、接続先や権限を確認した相手との間で実装します。[1]

返品を受け付けたことと、返金が完了したことを分ける

バッグが店へ戻ってきても、お金の返金が終わっているとは限りません。荷物の状態と、お金の処理を同じ項目にまとめると、「返金済み」と誤って案内する原因になります。

UCPでは、配送とは別にadjustmentsという変更の記録を持てます。返金、返品、キャンセルなどの購入後の変化を表します。typeは変更の種類、statusは処理の状態です。[1][3]

以下は、返金の記録一件を読むための架空の例です。注文全体のadjustmentsに入る要素の例であり、返金APIへ送る命令ではありません。[3]

{
  "id": "refund-bag-001",
  "type": "refund",
  "occurred_at": "2026-09-12T03:00:00Z",
  "status": "pending",
  "description": "返品を確認し、返金処理の完了を待っている"
}

refundは返金、pendingは処理待ちを表します。occurred_atはこの記録に対応する出来事の日時です。例では協定世界時で記述しており、日本時間では2026年9月12日12時です。

この時点でAIが伝えられるのは、「返金は処理待ち」という状態です。店が使う決済の仕組みで結果を確認し、完了を表すcompletedや、失敗を表すfailedを適切に記録します。実際の資金移動を確認せず、表示だけを完了へ変えないようにします。[3]

つまり、Orderに返金の項目があることは、返金手続きそのものをUCPが代行するという意味ではありません。返品を受け付ける条件や、返金を判断する店の運用も、別途必要です。

通知を信用する前に、送信元と注文を確かめる

注文の通知を受ける側は、それが接続した店から届いたか、内容が途中で変わっていないかを確認します。UCPのWebhookでは、電子署名を店が付け、相手が検証することが必須とされています。[1][4]

電子署名は、送信元と内容を確かめるために計算して付ける情報です。本文に「正規の店からです」と書くだけでは、同じように名乗る別の送信者を見分けられません。

この通信では、署名の値をSignature、どこを署名したかをSignature-Input、本文が変わっていないかを調べる値をContent-Digestへ入れます。これらはHTTPヘッダーと呼ばれる、本文に添える情報欄です。[4]

署名が正しいことに加え、その店が対象注文を扱う権限を持つかも確認します。同じ通知が再び届いた場合に何度も処理しないことや、古い状態で新しい記録を上書きしないことも、接続の検査に含めます。

本稿では、公開されたデータ形式の部分例を照合しています。署名の生成・検証、AIサービスとの相互接続、配送や返金の実処理は実行していません。形式が合うことを、本番で取引できることと扱わないための区別です。

導入の判断では、購入後のどの記録を渡せるかを見る

運営担当者が確認したいのは、「UCP対応」という名前だけでなく、店の現在の記録をどこまで正確に渡せるかです。注文番号を照合できるか、一部発送を表せるか、返金の処理待ちと完了を区別できるかを、実際の業務に当てはめます。

例えば、倉庫の発送完了が店のシステムへ届くまで時間がかかるなら、AIへの通知だけ速くしても、正しい状況は早まりません。店の記録が更新される流れまで確かめる必要があります。

仕様では、詳しい注文情報や購入後の操作について、店のpermalink_urlへ案内することも推奨しています。AIだけで無理にすべてを完結させず、確かな注文記録と手続きがある場所へつなぎます。[2]

商品を売った後にも、お客さんは状況を知りたくなります。Orderは、その質問へ答えるために店とAIが情報を共有する仕組みです。発送や返金の担当を曖昧にせず、店で確認できた状態を正確に届けるところに役割があります。