AIに注文を任せるルールとは？W3C会合で見えた現在地

AIが客に代わって商品を選び、注文まで進める仕組みでは、店への接続と、代金を払ってよいという本人の許可を分けて考える必要があります。日本のEC・予約サービスの責任者にとっては、「新しい規格に対応した」という説明だけで採用を決めないための判断材料になります。

Web技術の共通ルールを扱うW3Cと、商品情報などの共通ルールを扱うGS1。両団体が2026年9月8〜9日に開いた会合では、注文の共通ルール、サイト内でAIが使う機能、支払いの許可に関する発表がありました。この記事では、その担当範囲と残る課題を一つの注文例で説明します。会合の開催は、W3Cの正式な標準である「W3C勧告」の採択を意味しません。[1][2][3][4]

参照確認日は2026年9月14日です。根拠は会合の議事日程と3件の発表資料であり、採択済み仕様の一覧や会合後の合意文書ではありません。実アカウントの設定、本番接続、実際の注文・決済は確認していません。

1. 注文を任せるには、三つの役割が必要

今回の資料は、「何をどう注文するか」「サイト上でどう動かすか」「誰の許可で支払うか」に分けると、自社の担当範囲を考えやすくなります。どれか一つの仕組みを採用すれば、残りも自動的に解決するという発表ではありません。[2][3][4]

UCP（Universal Commerce Protocol）は、AIと店が商品や購入手続きを共通のルールでやり取りするための仕組みです。WebMCPは、サイトがAI向けに操作機能を用意し、そのサイトを利用中の状態で動かす仕組みです。HuaweiのA4Pは、本人が事前に許可した条件に照らして支払いを検証するための提案です。[2][3][4]

説明用に、「指定した店のコーヒーを1杯、配送料込み600円以内で注文する」場面を考えます。商品名と金額は説明用の例であり、発表資料の実績ではありません。AIが店と商品を知る経路や、店が注文を受け取る接続は、別途用意されている前提です。

店の価格と配送料を取得できても、それだけでは支払ってよいとは判断できません。また、AIが注文内容を変更できても、客に見える画面が変わらなければ、客は何が起きたか分かりません。今回の発表を照合すると、採用判断には処理の成否だけでなく、画面と許可の確認も必要だと読み取れます。[2][3][4]

2. UCPは店ごとの違いを残しながら注文を共通化する

Googleの発表では、UCPを、店や決済事業者ごとに異なる仕組みをつなぐ共通の土台として説明しています。狙いは、AIの接続先が増えるたびに、相手専用のやり取りを一から作る負担を抑えることです。すべての店に同じ販売手順を強いる設計ではありません。[2]

そのために登場するのが「対応機能の発見」です。これは、店側とAI側が、それぞれ何を扱えるかを示し、利用できる機能を確認する考え方です。購入、配送、会員特典などの違いを隠さず、扱える範囲で処理を進めるために使います。[2]

コーヒーの例なら、AI側が店の接続情報と対応機能を確認し、利用できる商品情報や購入手続きを使う、という関係になります。店側は、価格や受け渡し方法など、取引に必要な情報を返す役割を担います。ただし今回確認したスライドだけでは、実際に送る項目や必須情報を確定できないため、実行用の通信例にはしません。

発表されたリリースと、拡張の方向を分ける

Googleの資料は、1月、4月、8月のリリースとして機能の広がりを示しています。購入手続き・支払い・注文を土台に、商品一覧やカート、会員アカウントの連携へ範囲を広げた説明です。8月の説明では、会員特典や近隣での受け渡しに関わる機能も取り上げています。[2]

一方、食事注文と宿泊については、分野を広げる方向が示されています。食事注文にはメニューと食事の注文、宿泊には予約という機能が描かれています。しかし、これらの図だけから、すべての機能が完成し、日本の店舗や宿泊施設で利用できるとは判断できません。[2]

資料には、何を開発中とし、どの版で利用できるかを全機能について対応づけた一覧はありません。したがって、「食事・宿泊へ拡張している」は言えても、「予約業務に必要な機能が一式そろった」とは言えません。掲載された企業名も、その会社の全サービスで利用可能という証拠にはなりません。[2]

予約サービスの責任者なら、検討中の連携先について、宿泊日、人数、キャンセル条件、予約確定をどこまで扱えるかを確認する必要があります。これは採用条件の例であり、今回の資料で対応を確認した項目ではありません。UCPという名前より、自社の予約が最後まで成立する範囲を見ることが重要です。

3. WebMCPの課題は、AIの操作を客にも見える形にすること

Shopifyの発表で具体的だったのは、AIが処理を実行できても、客が使いやすいとは限らないという点です。WebMCPでは、サイト側が「何を受け取り、何を返すか」を決めた操作機能をAIに示します。その機能は、利用者がサイトを開いている間の情報や、ログインしているかどうかに応じて動きます。すべての操作でログインが必須という意味ではありません。[3]

MCPは、AIと外部の機能をつなぐための通信の仕組みです。今回の発表では、サイト画面を経由しないUCPとMCPの接続と、ページ内の機能を使うWebMCPの経路を分けています。UCPとWebMCPは、どちらか一方を選べば済む単純な競合関係としては説明されていません。[3]

コーヒーの例で、AIが1杯をカートに追加しても、画面が空のままならどうでしょうか。客は追加に失敗したと思い、手で同じ商品を入れるかもしれません。これは説明用の場面ですが、Shopifyは実際に、AIがカートを更新しても画面に変化がなく、人が操作を引き継げない問題を報告しています。[3]

Shopifyは、必要なときに関連ページへ移動させる方法や、カートの更新を画面側にも通知する方法を紹介しています。人の操作とAIの操作を同じ処理経路へ寄せる取り組みです。店舗側が減らしたいのはAIの操作時間だけでなく、客が状況を確かめ直す手間でもあります。[3]

導入報告があっても、全体が確定したわけではない

同社資料には、Shopifyのストアへの導入済みという説明があります。同時に、ChromeとEdgeではOrigin Trial、つまり参加するサイトで機能を試す試験提供とされています。これを、すべての環境で同じように使えるという意味に広げてはいけません。[3]

ページ移動によってAI向けの機能が登録し直されることや、ページ内のAIの状態が再読み込みされることも課題として挙がっています。状態を保ちやすくする仕組みは検討中です。また、操作回数や時刻を数えられても、利用者が満足したかまでは分からないという計測上の不足も報告されています。[3]

さらに、店側のAIと客側のAIが協力する構想も示されました。そこに使うUCPの「ask」機能は、会話で問い合わせるための開発初期の検討として扱われています。将来像を、現在すぐ接続できる機能として採用要件に入れないことが必要です。[3]

4. 本人の支払い許可は、注文処理とは別に確かめる

Huaweiが提案したTASPは、利用者、サービス、支払い、身元や資格の確認、運営上の監督という五つの領域で役割を分ける枠組みです。AIが端末をまたいで注文を進める場面で、誰が何を確認し、記録を残すかを整理しています。A4Pは、その中で支払いの許可を扱う構成要素です。[4]

同社は、支払いをAIへ任せる程度をP0〜P4の五段階に分ける案も提示しました。ここで採用判断に直結するのは、支払いごとに本人が確認するP1と、本人が先に決めた条件内でAIが支払うP2の違いです。この区分もHuaweiの提案であり、会合全体が採択した共通分類ではありません。[4]

P1なら、コーヒー1杯の注文内容、支払先、総額を本人が見て、その支払いを確認します。P2なら、本人が店、商品、金額、時間、回数などの境界を先に許可し、実行時に条件を照合します。「おすすめを選ぶ」と「本人へ再確認せず支払う」では、店と決済側に必要な確認が変わります。[4]

説明用の条件を「指定店、コーヒー1杯、配送料込み600円以内、平日10時、1日1回」とします。合計580円なら金額の条件には収まりますが、店や時間、当日の実行回数も確認が必要です。合計650円や同日2回目なら、その事前許可の範囲では進められない、という読み方になります。

これはTASPの正式なデータ形式ではなく、許可の境界を理解するための自作例です。上限外で本人へ再確認するのか中止するのかという画面や処理の詳細は、今回の資料からは確定できません。金額だけ合っていれば実行してよい、という説明にもしていません。

A4Pの構想では、利用者が端末側で許可内容を確認し、改ざんの有無などを検証できる電子署名を付けます。支払いを処理するシステムは、許可内容と現在の実行状況に照らして支払いを検証します。後から経緯を追える証拠を残すことも狙いです。[4]

資料では、P1に関するHuawei Payなどの実装説明と、P2の事前許可のシナリオを分けています。後者のシナリオを本番運用の実績と読むことはできません。また、A4PはGoogleのAP2と同一ではなく、資料中でも別の仕組みとして列挙されています。[4]

5. 相互接続は「同じ規格名」だけでは判断できない

今回の資料で残るのは、複数の会社の仕組みをつないだとき、同じ意味と条件で処理できるかという課題です。これを相互接続と呼びます。注文の形式が似ていても、本人の許可や画面の状態まで一致するとは限りません。[3][4]

Shopifyは、自社のAI向け機能がおおむねUCPに沿いつつも、複雑な操作がAIモデルを混乱させたため、一部に違いがあると説明しています。Huaweiは、異なる注文・決済の仕組みの間で、用語の意味、対応づけ、検証可能な証拠を共有する枠組みを提案しています。どちらも、接続の不足がすでにすべて解消したという報告ではありません。[3][4]

コーヒーの例なら、「1杯を注文する」という内容を各システムが同じように扱うことが第一です。加えて、配送料込みの総額が許可と一致し、注文結果が客に見え、許可外なら止まる必要があります。担当する仕組みを分けたうえで、この一連の動きをつないで確かめることが採用条件になります。

6. 自社は何を待ち、何を先に検討できるか

すべての標準の完成を待つか、今すぐ全面導入するか、の二択にする必要はありません。 今回の資料からは、対象を絞った検討と、未確定部分を残した判断を分けられます。ただし、日本での利用資格や自社環境への提供条件は、この4資料だけでは確認できません。[1][2][3][4]

商品選びやカート操作の補助が目的なら、AIの操作結果を客が確認し、手動で引き継げるかが中心になります。本人へ都度確認せず注文・支払いまで進めたいなら、事前許可の範囲、実行回数の管理、許可外の停止、経緯の記録が追加の検討事項です。宿泊などでは、分野別の必要機能が対象の版で利用できるかも切り分けます。

根拠を読み返す場合は、会合の議事日程で発表者と題目を確認できます。UCPの拡張はGoogleの発表スライド、画面連動の課題はShopifyの発表スライド、本人許可の提案はHuaweiの発表スライドが確認先です。いずれも申込フォームではありません。[1][2][3][4]

自社の採用判断は、「対応済み」という一語ではなく、扱える注文、本人が確認する時点、客に見える結果の三点で行えます。今回の会合資料が役立つのは、この三点のどこに実装があり、どこに試験や提案が残るかを区別できることです。