BLOG / ai-commerce-authority-handoffs.mdx
AIコマースの権限引き継ぎ:商品知識から注文まで
SKU.mdからライブCatalog、MCP・UCP、ページ上のWebMCP操作、Checkout、注文システムへ至る4つの引き継ぎを整理します。
商品説明を注文へ変えるまでに、エージェントは4つの明示的な権限引き継ぎを通るべきです。各段階で、識別、状態、許可、利用者の意図を再検証します。
SKU.md は、販売者が自らホストする商品発見と安定した商品知識のレイヤーです。Agent が商品を見つけ、出典のある事実を理解し、リアルタイムの商取引情報をどこで再確認すべきか把握できるようにします。新しい Checkout プロトコルではありません。
4つの引き継ぎ
| 段階 | 情報源が所有するもの | 必要な保護 |
|---|---|---|
| 1. SKU.md → ライブCatalog | 現在のProduct、Variant、価格、在庫 | 正確な識別照合と新鮮な応答 |
| 2. Catalog → MCP・UCP機能 | 呼出可能な操作と合意済み入出力 | 機能、認証、範囲、エラー処理 |
| 3. ライブ情報源 → ページWebMCP操作 | 開いているページの現在UIで意味を持つ操作 | 見える文脈と利用者審査 |
| 4. 操作 → Checkout・注文 | 拘束力のある合計、決済、購入、注文状態 | 明示的確認と権威ある完了結果 |
これは概念上の引き継ぎであり、すべての販売者が4技術を使うという主張ではありません。独立文書からリンクしただけで、SKU.mdがUCP、MCP、WebMCPに採用されたことにはなりません。
引き継ぎ1:知識をライブCatalogへ戻す
エージェントは安定したFacts、Claims、Disclosures、Limitationsを読み、Product、Variant、SKU、存在するGTINをライブ結果と照合します。UCP Catalogは、カタログの価格・在庫が現在の要求条件を反映しても取引上の約束ではなく、Checkoutが権威を持つと説明します。
ライブ情報源が利用できない、または識別が衝突するなら引き継ぎは失敗です。offer_snapshotや文章で代用せず、不確実性を報告します。
引き継ぎ2・3:呼出可能な機能とページ操作
MCPはツールとリソースを公開できますが、その公開面だけでは販売者の呼出許可や結果の鮮度を証明しません。UCPは発見と交渉後にコマース機能をRESTまたはMCPへ結び付けられます。
WebMCPは別のページコンテキストに関する草案です。ページは現在のUIで意味を持つ操作を公開できますが、バックエンドのCatalog、オフライン発見、取引完了の証明ではありません。表示されるフォームやツールにも、限定した入力、安全な失敗、利用者による審査が必要です。
引き継ぎ4:拘束力のある判断はCheckoutと注文システムが行う
UCP Checkoutはセッション状態、履行、決済処理、合計、完了を所有します。購入者の入力やレビューが必要な状態をエージェントは表示しなければなりません。権威あるシステムが確認を返して初めて注文が存在します。
- 正確な商品と現在条件を提示します。
- 重要なDisclosureと未解決の不確実性を説明します。
- 影響の大きい操作について利用者に確認します。
- 許可されたシステムから送信します。
- エラーや保留を成功へ格上げせず結果を報告します。
引き継ぎに失敗したときの動作
| 失敗 | 正しい応答 |
|---|---|
| Variant不一致 | 停止し、曖昧さの解消を求める |
| ライブ価格を取得不可 | 不明とし、古い文章を使わない |
| ツールに権限がない | 正しい引き継ぎを求め、無闇に再試行しない |
| 利用者が拒否 | 副作用なしで終了 |
| Checkoutがレビューを要求 | 信頼できるレビュー経路を開く |
| 注文結果が不確か | 完了ではなく保留または不明と報告 |
関連資料
実装前に安定した商品知識とライブデータとProductGroup、Variant、SKU、GTINを確認してください。