AP2とは？AIが商品を探して注文するまでをデータで解説

AP2は、AIに買い物を任せたとき、店や決済会社が「本人の許可どおりの購入か」を確認するための共通ルールです。例えば、購入者が許可した商品は1箱なのに、AIから2箱の注文が届いたら、そのまま購入を進めないために使います [1][3][4]。

購入者にとっては、予算や商品を決めて購入までAIに任せる仕組みを作れること。ECサイトにとっては、AIからの注文に本人の許可があるかを、データで確かめられることが利点です。対応する買い物AI、店の注文システム、決済の連携が必要です [7][9]。

ここでは、AIが店の情報を読むところから、商品を探し、購入の許可を得て、注文するまでを追います。APIは、AIと店のシステムが情報をやり取りする窓口です。実際に公開されているAPI名とデータの項目を使い、英語の項目が何を意味するかも説明します。

確認日は2026年9月10日です。 AP2は公開仕様v0.2、商品検索と注文の例はUCPの開発中の仕様（draft）を参照しています。以下は仕組みを理解するための例で、特定のAIサービスで日本の店がすぐ受注できることを示すものではありません [9][10][11][12]。

AP2は、買い物のどこで役に立つ？

まず、購入者が買い物AIに、次のように頼む場面を考えます。

この店で、A4コピー用紙の5冊入りを1箱買いたい。送料込み3,000円以内で探して、最後に内容を見せて。

店のURLは購入者がAIに渡したものとします。商品や価格は架空の説明用です。AIが未知の店を検索で見つける工程は、この例の前に当たります。

買い物は、店の機能を確認 → 商品を探す → 合計を確認 → 購入を許可 → 支払い・注文と進みます。AP2が担うのは、この中の「本人が許可した購入かを確認する」部分です。商品を探すAPIや注文を作るAPIには、この例ではUCPを使います [9][10][11]。

AP2自体には、商品をAI検索に登録する窓口はありません。商品を見つけてもらう準備を済ませたうえで、購入までAIに任せたい場面につながる仕組みです。Googleへ商品を登録する話は、GoogleのAIショッピングを始めるための準備で説明しています [6][9]。

1. AIが、店のAPIの場所と使える機能を読む

購入者が渡した店のURLを https://shop.example.com とします。UCPに対応する店は、次の場所に、APIの接続先や対応機能を案内します [10]。

GET https://shop.example.com/.well-known/ucp

AIが知りたいのは、「商品の検索はできるか」「注文を受け付けるか」「AP2に対応するか」です。実際の案内には、次のような項目があります。

案内にある項目	AIが読み取ること
ucp.services 内の endpoint	APIの接続先。この例では https://shop.example.com/ucp
dev.ucp.shopping.catalog.search	商品を検索できる
dev.ucp.shopping.checkout	購入手続きを作成・更新できる
dev.ucp.common.payment.ap2_mandate	AP2の購入許可をやり取りできる

この表は、公式の項目を抜き出して説明したものです。実際の案内には、対応する仕様の版、支払い方法、署名を確認する公開鍵なども必要になります。AP2は、店とAI側の両方が対応すると確認できた場合に使います [12]。

店のURLが分かっただけで、AIが何でも操作できるわけではありません。 この工程で、両者が使える接続先と機能を確認します。UCPの機能案内を置くことと、特定のAIサービスの販売者審査に通ることも別です。

2. AIが商品を検索し、注文に使う商品IDを受け取る

商品検索に対応していれば、AIは店の POST /catalog/search を呼びます。この例の接続先は次のURLです [10]。

POST https://shop.example.com/ucp/catalog/search

AIから店に渡す検索条件の例です。

{
  "query": "A4コピー用紙 5冊入り",
  "context": { "address_country": "JP" },
  "pagination": { "limit": 3 }
}

query は探したい言葉、address_country は購入先の国を考慮するための情報、limit は一度に受け取る件数です。国の指定だけで、その国への販売が認められるわけではありません。販売できる条件は購入手続きで確認します [10]。

店の返答にある、購入できる商品の情報を抜き出すと次のようになります。検索結果全体のうち、products 内の variants に入る1件の例です [13]。

{
  "id": "PAPER-A4-5",
  "title": "A4コピー用紙 5冊入り・1箱",
  "description": { "plain": "500枚入りを5冊まとめた1箱" },
  "price": { "amount": 2400, "currency": "JPY" },
  "availability": { "available": true }
}

ここでAIは、注文に使うIDが PAPER-A4-5、商品価格が2,400円、在庫があると読み取ります。5冊で1箱の商品なので、注文する数量は「1」です。送料を含めた金額は、まだ確定していません。

商品IDは、この後も同じものを使います。名前の似た別商品や、1冊売りの商品と取り違えないためです。商品を検索するこの段階は、AP2による購入の許可には当たりません。

なお、掲載したHTTPとJSONは処理を説明するための抜粋です。実際のUCP REST通信では、AIサービスの案内先を示す UCP-Agent ヘッダーなどを付け、接続先が求める認証にも従います。例のURLは実在の注文先ではありません [10][11]。

3. AIが購入手続きを作り、店が送料を含めた合計を返す

次にAIは、店へ「この商品を1箱購入する場合の手続きを作って」と依頼します。UCPでは POST /checkout-sessions を使います [11]。

POST https://shop.example.com/ucp/checkout-sessions

{
  "line_items": [
    { "item": { "id": "PAPER-A4-5" }, "quantity": 1 }
  ]
}

line_items は注文する商品の一覧です。AIが渡すのは商品IDと数量で、価格は店のシステムが決めます。この呼び出しだけでは、支払いも注文確定も行いません [11]。

店が返した購入手続きのIDを chk_001 とします。配送先や配送方法が必要なら、AIは購入者から確認した情報を使って、この手続きを更新します [11][14]。

PUT https://shop.example.com/ucp/checkout-sessions/chk_001

配送先が未定のまま、送料を0円と決めてはいけません。この例では、配送先と通常配送が確定した後、店が「商品2,400円、送料400円、追加の税額0円、合計2,800円」と返したものとします。金額は説明用で、税金の計算方法は店の設定に従います。

最終的な返答の、ID・状態・金額の部分だけを抜き出します。

{
  "id": "chk_001",
  "status": "ready_for_complete",
  "currency": "JPY",
  "totals": [
    { "type": "subtotal", "amount": 2400 },
    { "type": "fulfillment", "amount": 400 },
    { "type": "tax", "amount": 0 },
    { "type": "total", "amount": 2800 }
  ]
}

ready_for_complete は、注文確定へ進める状態です。total が今回の支払い総額です。AIは商品価格2,400円ではなく、送料を含む2,800円が予算3,000円以内かを確認します [11][14]。

AP2を使う場合、店は購入内容にデジタル署名も付けます。UCP側の項目名は ap2.merchant_authorization です。AI側は署名を検証し、金額や商品が書き換わっていないことを確かめてから、購入者へ見せます [12]。

4. 購入者が「この1箱を2,800円で買ってよい」と許可する

ここで初めて、購入者に確定した内容を確認してもらいます。例えば、確認画面に必要な情報は次のようになります。

確認する内容	今回の例
購入先	サンプル文具店
商品と数量	PAPER-A4-5 を1箱
配送	購入者が指定した配送先へ通常配送
支払い総額	送料込み2,800円
支払い方法	購入者が選んだ登録済みのカード

これは公式画面の再現ではなく、確認内容の説明です。AP2では、AIの自由な文章だけに頼らず、内容を正しく表示して承認を受け取る仕組みを使います [8][9]。

「何を買ってよいか」と「いくら払ってよいか」を結び付ける

AP2 v0.2には、購入内容の許可を表す Checkout Mandate と、支払いの許可を表す Payment Mandate があります。Mandateは、ここでは「AIに認めた購入・支払いの内容」と考えてください [3][4]。

購入内容のデータは、読みやすい形にすると次のようになります。署名付きの送信データそのものではなく、中に入る項目の説明用の例です。EXAMPLE_ で始まる値は差し替えが必要な仮の文字列です [3]。

{
  "vct": "mandate.checkout.1",
  "checkout_jwt": "EXAMPLE_MERCHANT_SIGNED_CHECKOUT",
  "checkout_hash": "EXAMPLE_CHECKOUT_HASH"
}

checkout_jwt には、店が署名した購入内容が入ります。今回なら、商品 PAPER-A4-5 を1箱、購入手続き chk_001、合計2,800円という内容です。

checkout_hash は、その署名付きデータから計算する照合用の値です。商品・数量・金額などが変わると、元の許可とは一致しなくなります。「2,800円の注文への許可」を「3,200円の注文」にそのまま使えないようにします [3][9]。

支払いの許可にも、同じ照合用の値を入れます。次は金額と購入内容のつながりを示す抜粋で、実際には支払い先や支払い方法なども含めます [4]。

{
  "vct": "mandate.payment.1",
  "transaction_id": "EXAMPLE_CHECKOUT_HASH",
  "payment_amount": { "currency": "JPY", "amount": 2800 }
}

transaction_id にある値と、先ほどの checkout_hash が同じ購入内容を指します。これによって、許可された1箱の購入に対して、2,800円を払うという関係を確かめられます。ここで使う照合用の値は、注文番号 chk_001 そのものではありません。

JSONにこの文字を書くだけでは、本人の許可にはなりません。実際は、承認を受けた内容を署名付きの形式にし、店や決済側が署名と対象の購入内容を検証します [8][9]。

5. AIが許可のデータを渡し、店が決済と注文を進める

本人の許可が得られたら、AI側は支払いに必要な情報を準備します。AP2 v0.2の基本フローでは、支払いの許可を決済情報の提供側が検証し、今回の購入に使う決済情報を返します。AIは購入内容の許可と合わせて店へ渡します [2][9]。

UCPで注文確定を依頼するAPIは、次のものです [11]。

POST https://shop.example.com/ucp/checkout-sessions/chk_001/complete

UCPのAP2拡張では、ap2.checkout_mandate に購入内容の許可を置きます。支払い側の情報は、選択した支払い方法の credential.token に入れて渡す構成です。送信先と項目の位置を示すため、次は必要な部分だけを掲載しています [12]。

{
  "payment": {
    "instruments": [
      {
        "id": "instr_1",
        "handler_id": "handler_example",
        "type": "card",
        "selected": true,
        "credential": {
          "type": "PAYMENT_GATEWAY",
          "token": "EXAMPLE_PAYMENT_TOKEN_NOT_PAYABLE"
        }
      }
    ]
  },
  "ap2": {
    "checkout_mandate": "EXAMPLE_SIGNED_CHECKOUT_MANDATE"
  }
}

handler_id は、店が案内した決済の接続設定を選ぶIDです。カード番号をこの例へ書き足すものではありません。仮のトークンや署名は決済には使えず、実際の形式は接続する決済側の仕様に従います [12][15]。

ここは、公開資料をつなぐ際に注意が必要な箇所です。 AP2 v0.2は、署名付き購入データの照合と、決済情報を受け取る基本フローを定義しています。一方、参照したUCP draftは、本文と分けた店の署名や、支払いの許可を含むトークンの格納場所を説明しています。この記事の抜粋だけで、両者の署名データをそのまま相互接続できると確認したわけではありません。実装時は、両者が採用する版と決済方式をそろえる必要があります [3][4][9][12]。

店は、受け取ったらすぐ発送するわけではない

店は購入の許可を検証し、現在の購入手続きと商品・数量・金額が合うかを確かめます。その後、決済側の検証と支払い処理へ進みます [12]。

届いた内容	今回の例での判断
1箱・2,800円への有効な許可があり、現在の内容とも一致	決済処理へ進める。決済成功は別に確認する
現在の合計が3,200円に変わった	2,800円への許可では進めない
AP2を使う約束なのに購入の許可がない	mandate_required などのエラーとして扱う
署名が正しくない、期限切れ	許可を受け付けない

店が注文を完了すると、UCPの返答に completed と注文情報が入ります。結果の一部を示す例です [11][16]。

{
  "id": "chk_001",
  "status": "completed",
  "order": {
    "id": "order_001",
    "permalink_url": "https://shop.example.com/orders/order_001"
  }
}

AIはこの返答を受けて、購入者に注文番号と確認先を伝えます。chk_001 は購入手続きのID、order_001 は成立した注文のIDです。途中の ready_for_complete を見ただけで「注文できました」と伝えてはいけません。

毎回確認せず、条件内の購入をAIに任せる場合は？

ここまでの例では、最後に本人が2,800円の購入を確認しました。AP2には、先に条件を許可し、その範囲でAIが購入する流れもあります [2][9]。

例えば「この店の PAPER-A4-5 を1箱、送料込み3,000円以内なら購入してよい」と任せる場合です。購入者は最初に、商品・店・金額などの条件を確認して許可します。購入のたびに自由な判断をAIへ認めるものではありません。

支払い上限を表す、AP2の実際の条件項目は次のものです。これは条件1件の例で、事前の許可のデータ全体ではありません [4]。

{
  "type": "payment.amount_range",
  "currency": "JPY",
  "max": 3000
}

購入する商品と数量には、checkout.line_items という条件を使えます [3]。

{
  "type": "checkout.line_items",
  "items": [
    {
      "id": "line_1",
      "acceptable_items": [{ "id": "PAPER-A4-5", "title": "A4コピー用紙 5冊入り・1箱" }],
      "quantity": 1
    }
  ]
}

実際には、購入先、使用する支払い方法、任せるAIの鍵、期限なども組み合わせます。店は購入内容が条件に合うか、決済側は金額などが条件に合うかを検証します。価格を監視して買い時を探す機能は、買い物AI側が別に用意するものです [3][4][9]。

今回の合計2,800円は上限以内です。送料が上がって3,200円になれば、条件から外れます。AIが「少し高くても買った方がよい」と判断しても、この許可だけでは購入を進められません。

また、条件を決めた場合も、実際に購入する内容の許可を作ります。検証する側には、本人が先に許可した条件と、AIがその範囲で決めた購入内容を渡します。「予算3,000円」という文字だけで支払いを通す仕組みではありません [8][9]。

ECサイトにとってのメリットと、今使える範囲

ECサイトにとってAP2が役立つのは、AIから受け取った注文を、本人が許可した内容と照合できることです。購入者は商品探しに加えて購入もAIへ任せられ、店は、その注文を受けてよい根拠をシステムで確認できます [1][7][9]。

購入内容や支払いの許可は、後から取引を確かめる材料にもなります。ただし、返品や不正利用への対応が不要になるわけではなく、AP2だけで責任の所在が自動的に決まるわけでもありません [5][9]。

2026年9月10日の確認範囲では、AP2は公開仕様と開発用サンプルを提供しています。公式FAQは、サンプルの決済処理が模擬的なものだと説明しています。一般の店がAP2の会員登録をすれば、すぐにAIから注文を受けられるという手順は確認できませんでした [6]。

これから商品をAIに見つけてもらいたい店では、まず販売先への商品情報の提供が検討対象です。すでにAIから購入手続きを進める連携があり、本人の許可をどう確かめるかが課題になっているなら、AP2が関係します。

AP2の役割は、今回の例なら「PAPER-A4-5 を1箱、2,800円で買ってよい」という許可を、AI・店・決済側の間で確認できるようにすることです。商品を見つけるところから順に追うと、購入のどの場面を支える技術なのかが分かります。