UCP（Universal Commerce Protocol）とは、AIエージェントが利用者に代わって商品を探し、決済まで進めるために、プラットフォーム・エージェント・事業者の間の手続きを共通化したオープンな仕様です。GoogleのAIモードやGeminiはその利用先の一つで、事業者は自社サーバーの /.well-known/ucp に公開JSONを置き、対応できる機能とAPIのバージョンを宣言します。2026年8月25日に4か月ぶりの更新が入り、既存の実装に修正が必要な変更が含まれました。
この記事でわかること
- 日本向けの開始時期は公表されていない： Googleが示している展開先はカナダ・オーストラリア、その後の英国です。日本の開始時期に触れた公式発表は確認できません。
- 中小ECが自前実装を急ぐ理由は薄い： 仕様は4か月で作り直されました。実装の多くはカートや決済事業者側の対応に乗る形になります。
- 待つ間に効く3つは今日から着手できる： 商品ページ・構造化データ・Merchant Centerフィードの値を揃える作業は、UCPが来なくても価値が残ります。
自社はいま何をすべきか｜3つの分岐で決める
日本国内向けだけで販売しているなら、いま必要なのは商品データを揃えることだけです。
UCPへの対応は「やる／やらない」の二択ではありません。販売先の国、使っているEC基盤、そしてカートや決済事業者の対応予定という3つで、やるべきことが変わります。この記事の読者の多くは、自分で /.well-known/ucp を書く側ではなく、使っているカートが対応するのを待つ側になります。
| 条件 | いまやること | 自前実装 |
|---|---|---|
| 日本国内向けのみ・SaaSカート（Shopify／国内ASP） | 商品データと構造化データ、フィードの値を揃える | 不要。カート側の対応を待つ |
| 日本国内向けのみ・フルスクラッチ | 同上に加え、仕様の更新だけ定点で追う | 急がない。仕様が落ち着いてから |
| 米国など対応市場が主要販路 | 仕様の確認と検証環境での試験 | 検討する理由がある |
| カート・決済を提供する側（ベンダー） | PoCと自社製品への組み込み設計 | 必要。国内でも着手例がある |
| ECサイトを持たない事業者 | 自社情報がAIに読める形かの点検 | 不要 |
自分の会社がどの行に当たるかを先に決めてしまえば、この先の技術的な話は読み飛ばせる部分が出てきます。
Q. 今のうちに /.well-known/ucp を置いておくべきですか。
A. 中身のない宣言ファイルを先に置く意味はありません。UCPプロフィールは対応できる機能・APIのバージョン・エンドポイント・決済設定・公開鍵を宣言するファイルで、宣言した機能に実装が伴っていることが前提です。実装の予定がない段階で置くと、更新されないまま古いバージョンを宣言し続けることになります。
置くかどうかの前に、そもそも自社が対応する側なのかを見ておく必要があります。
ECではない会社に関係はあるのか
ECサイトを持たない会社が、いまUCPそのものに手を入れる必要はありません。
UCPが対象にしているのは商取引の手続きです。ただし対象領域は小売だけにとどまらず、2026年7月に食品向け、8月11日に宿泊向けの専門委員会が組成され、店舗検索や営業時間、住所、地図座標、重量単位での注文といった仕様が追加されています。飲食・宿泊のように、将来的に予約や注文がエージェント経由になり得る業種は、動きだけ見ておく価値があります。
一方で、UCPに対応しているかどうかをGoogleが検索順位のシグナルとして説明した一次情報は確認できません。「対応しないと順位が下がる」という前提で判断しないでください（アイダイム分析）。UCPは検索順位の話ではなく、購買導線の規格です。
非ECの事業者にとって現実的な論点は、UCPそのものではなく「自社のサービス内容や条件が、AIに読める形で書かれているか」のほうです。この観点は「AI検索対策とは？Googleが「不要」とした施策と、いまやるべき5つ」で扱っています。
UCPとは何か｜AIが代わりに買う導線の共通言語
UCPは、AIエージェントが人に代わって商品を探し、決済まで進めるための共通仕様です。
いまのオンライン購入は、利用者がブラウザで店舗ページを開き、カートに入れ、フォームに情報を入れて決済する流れを前提にしています。AIエージェントが代理で買う場合、この「画面を操作する」前提が使えません。そこで、商品情報の書式、カートの作り方、決済の受け渡し方をあらかじめ共通化しておき、エージェントが店舗ごとの個別対応なしに手続きを組み立てられるようにする——これがUCPの狙いです。
事業者側が用意するのは、/.well-known/ucp に置く公開JSONファイル（UCPプロフィール）です。このファイルで、対応しているUCPの機能、準拠するAPI仕様のバージョン、APIのエンドポイント、決済処理の設定、メッセージ検証用の公開鍵を宣言します。認証は不要で、公開アクセスできる状態にする必要があります。
Googleは2026年1月のNRFでUCPを公表し、AIモードやGeminiの中でのチェックアウトに使うとしています。ただしUCPはGoogle製品専用の仕組みではなく、プラットフォーム・エージェント・事業者の間をつなぐオープンな仕様として策定されています。Googleの各サービスは、その利用先の一つという位置づけです。
Q. UCPとschema.orgの構造化データは同じものですか。
A. 別のものです。UCPで「スキーマ」と呼ばれるのは、エージェントと事業者のシステムがやり取りするJSONの定義で、検索結果にリッチリザルトを出すためのschema.orgマークアップとは層が違います。ただし、商品名・価格・在庫・配送条件を機械が読める形に整えるという点では地続きで、どちらも同じ商品データを源にします。
この仕様を誰が決めているのかを見ると、Googleの単独案件ではないことが分かります。
誰が決めているのか
UCPはGoogleの単独仕様ではなく、Google・Shopify・Stripeが並ぶ委員会で決まっています。
意思決定は階層になっており、全体方針を決める統治委員会（Governing Council）の下に、技術面を見る委員会と、領域ごとの専門委員会が置かれています。
| 組織 | 構成 | 組成時期 |
|---|---|---|
| 統治委員会（Governing Council） | Google、Shopify、Stripe | 2026年1月発足／Stripeは同年4月に加盟 |
| 技術委員会（Tech Council） | 仕様の技術面を担当 | — |
| 食品向け専門委員会 | Block、DoorDash、Google、Toast、Uber Eats | 2026年7月 |
| 宿泊向け専門委員会 | Amadeus、Booking.com、Expedia、Google、Hilton、Marriott、Trip.com | 2026年8月11日 |
専門委員会が半年で2つ増えている点は、仕様がまだ広がり続けていることを示します。範囲が広がっている最中の仕様は、細部が動きます。
バージョンが日付なのはなぜか
UCPのバージョンは v2026-08-25 のような日付表記で、旧版を残したまま新版へ移れるようにするためです。
数字の連番ではなく日付を使うことで、事業者とプラットフォームが「どの日付の仕様に準拠しているか」で会話できます。旧版のサポートを続けたまま新版に対応することも許容されており、移行に猶予を持たせる設計です。
これまでのリリースは、v2026-01-11、v2026-01-23、v2026-04-08、そして2026年8月25日のv2026-08-25の4つです。1月に2回、4月に1回、8月に1回。つまりUCPは「一度実装したら終わる仕様」ではなく、数か月おきに構造が動く前提で運用する仕様です（アイダイム分析）。
中小ECが自前実装を待ってよい3つの理由
日本向けの開始時期が公表されておらず、仕様も4か月で作り直されているためです。
理由は3つあります。1つ目は提供地域です。Googleが公表している展開先はカナダとオーストラリア、その後に英国とされており、日本の開始時期に触れた公式発表は2026年9月1日時点で確認できません。日本向けの時期が見えない段階で自前実装に工数を割いても、動作を確認する場所がありません。
2つ目は仕様の安定度です。後述するとおり、2026年8月25日の更新では既存実装の修正が必要な変更が3系統入りました。4月版に合わせて作った実装は、8月版でそのまま動きません。同じことが次のリリースで起きない保証はない状況です。
3つ目は利用者側の受け入れです。ネットプロテクションズが2026年6月10〜12日に実施した調査（直近6か月以内にネットショッピングで購入した20〜65歳の男女1,150人が対象）では、AIに任せてよい範囲として「購入・決済まで自動で完了してもらう」を選んだ回答者は2.2%でした。商品探しや比較までは任せても、決済まで委ねる層はまだ限られています。これは実装時期を直接決める数字ではありませんが、急ぐ根拠が薄いことの補助材料にはなります。
Q. UCPは日本でいつ使えるようになりますか。
A. 2026年9月1日時点で、Googleの公式発表に日本向けの開始時期は明示されていません。公表されている展開先はカナダとオーストラリアで、その後に英国が続くとされています。日本での提供開始が決まった場合は、Googleの発表とUCPの仕様サイトの双方で告知されると考えられます。
ただし、待つべきでない立場の会社もあります。
例外：いま検証を始めてよい会社
米国が主要販路の会社と、カートや決済を提供する側の会社は、いま検証を始める理由があります。
該当するのは次の4種類です。米国など既に対応が始まっている市場が主要販路になっている事業者、自社開発のEC基盤を持ち仕様変更を自分で吸収できる事業者、ECカートや決済サービスを提供していて顧客企業への提供責任がある事業者、そしてUCP連携を売りにした製品を開発している事業者です。
国内でも動きはあります。ecbeingはUCPの仕様を採用した実装の推進を、GMOペイメントゲートウェイはUCPを採用した決済ソリューションの構築を、それぞれ公表しています。つまり「日本ではまだ誰も触っていない」わけではなく、提供側が先に動いている段階です。
2026年8月25日の更新で何が壊れたのか
配送設定・購入者同意・署名鍵の3系統に、既存実装の修正が必要な変更が入りました。
v2026-08-25は4月版以来の更新で、食品領域への対応、ベンダー中立の3Dセキュア2認証、頭金や分割を含む支払いスケジュール、複数の支払い方法にまたがる注文の分割といった追加が入りました。仕様全体もShopping・Payment・Commonの3区分に再編されています。ただし実装済みの事業者にとって重要なのは、追加された機能よりも、既存の記述を書き換える必要がある破壊的変更のほうです。
| 対象 | v2026-04-08まで | v2026-08-25 |
|---|---|---|
| 配送の設定フラグ | 名称に allows_ が付いていた |
allows_ を削除した名称へ変更 |
| 配送方法の説明 | fulfillment_option.description は文字列 |
構造化オブジェクトへ変更 |
| 複数配送先 | multi_destination はマップ |
オブジェクトの配列へ変更 |
| 配送方法の種別 | fulfillment_available_method.type は列挙値 |
文字列へ開放 |
| 配送設定ファイル | merchant_fulfillment_config.json |
廃止し business_fulfillment_config.json へ統合 |
| 購入者同意 | 固定のブール値フィールド | reverse-DNS形式のキーを持つ動的マップへ全面刷新 |
| 署名鍵 | signing_keys[] |
廃止。keys[]（JWK Set）を正規の署名鍵に |
配送まわりは項目名・型・ファイル名のすべてが動き、購入者同意は考え方そのものが差し替わりました。固定のブール値から動的なマップへの変更は、同意の種類を後から増やせるようにするための設計変更ですが、既存実装から見れば読み書きの箇所を作り直す規模です。署名鍵の統一も、鍵の置き場所を1か所に寄せる変更で、検証処理に影響します。
日本語でこの更新を、バージョン番号まで明示して解説した記事はほとんど出ていません。数少ない解説の結論も、いま仕様に合わせて実装を始めるより、次のリリースで構造が落ち着くのを待つ判断にも合理性がある、というものでした。
待つ間に整える3つ｜UCPが来なくても価値が残る土台
商品ページ・構造化データ・Merchant Centerフィードの3層を、同じ値に揃えることです。
ここは誤解されやすいので先に書きます。schema.orgのProduct・Offer・Reviewは、UCPが必須要件として求めているものではありません。層が違います。それでもこの3層を揃える作業を勧めるのは、UCPが日本に来ても来なくても、商品データが機械に正しく読まれる状態は資産として残るからです（アイダイム分析）。
揃えるとは、3層に書かれている値が食い違っていない状態を作ることです。実務で見るのは次の4項目です。
- SKU・商品識別子： 商品ページ、構造化データ、フィードで同じ値が入っているか。型番違い・旧品番の残りがないか
- 価格： 税込・税抜の扱いが揃っているか。セール価格が構造化データ側だけ古いまま残っていないか
- 在庫状態： ページの表示とフィードの在庫ステータスがずれていないか。売り切れ商品が「在庫あり」で残っていないか
- 配送条件： 送料無料の条件、配送日数、地域による違いが、ページとフィードで同じ内容になっているか
この4項目のどれかが食い違っていると、機械が読む側では「どちらが正しいか判断できない」状態になります。人が見るページだけを直して、フィードや構造化データを直し忘れる——という形で発生することがほとんどです。
構造化データそのものの書き方は「JSON-LDとは？書き方・実装例・SEO効果【2026年版】」、マークアップが実際にどこまで効くのかは「構造化マークアップはMEOに効くのか｜公式で確認できる効果と実装手順」で扱っています。AI検索側から見た設計は「AI検索のエンティティ設計｜構造化データはどこまで効く？2026年実測」が近い論点です。
📌 サイト全体をAIに読ませる設計から見直したい場合は、こちらもあわせてご覧ください。
→ 【図解】LLMOに強いホームページ制作とは？対策手順と費用相場
3層を揃える作業の重さは、使っているEC基盤で変わります。
EC基盤別に何が変わるか
自分で /.well-known/ucp を書くことになる会社は、実際にはごく一部です。
| EC基盤 | UCP対応の主体 | 事業者側でやること |
|---|---|---|
| Shopify系 | Shopify（統治委員会のメンバー） | 商品データの整備。カート関連の仕様変更の告知を追う |
| 国内ASP・カート | カートベンダー・決済事業者 | 商品データの整備。ベンダーの対応方針を確認する |
| フルスクラッチ | 自社 | 商品データの整備に加え、仕様の定点監視と実装判断 |
SaaSカートを使っている事業者にとって、UCP対応は「自分で実装する」課題ではなく「使っているカートがいつ対応するか」を確認する課題です。逆にフルスクラッチの事業者だけが、仕様の更新を自分で追い続ける必要があります。
仕様が動くものにどう追随するか｜精度管理の視点で運用を設計する
参照するバージョンを1つに固定し、更新が出たときだけ差分を見る形にしておくことです。
臨床検査の精度管理では、測定値そのものを毎回疑うのではなく、先に「正常範囲」を決めておき、そこから外れたときだけ止めて原因を追います。毎回全部を見直すのは現実的ではないからです。日付でバージョンが刻まれる仕様への追随も、同じ形に落とせます（アイダイム分析）。
具体的には3つを決めます。
1. 参照バージョンを固定する。 自社が準拠しているバージョンを1つ決めて記録します。「最新版に追従」と書くと、どの時点の仕様で作ったのかが分からなくなり、動かなくなったときに切り分けができません。
2. 更新を検知する場所を決める。 UCPの場合、見るのは仕様のリリースノートと、仕様サイトのアナウンス、それにGoogleの開発者向けドキュメントの3か所です。更新が出たら、リリースノートの破壊的変更のセクションだけを読み、自社の実装が触れている項目が含まれているかを確認します。含まれていなければ、そのリリースは見送ってよいという判断になります。
3. 検証環境で当ててから本番に入れる。 破壊的変更が自社に該当した場合は、検証環境で新しいバージョンに当ててから本番へ反映します。日付バージョン制は旧版のサポート継続を許容しているので、当日中に切り替える必要はありません。
構造化データの世界でも同じことが起きます。マークアップは書いて終わりではなく、Googleのガイドラインや推奨プロパティが変われば、書いたときには正しかった実装が要件を満たさなくなります。仕様が動く前提のものを扱うときは、実装そのものより「動いたことに気づく仕組み」を先に置くほうが結果的に安く済みます（アイダイム分析）。
UCP対応のよくある質問
ここまでで触れきれなかった、実装判断に関わる質問をまとめます。
Q. Shopifyを使っている場合は何をすればいいですか。
A. 商品データの整備に集中してください。ShopifyはUCPの統治委員会のメンバーで、UCPへの対応はプラットフォーム側で進みます。事業者側で `/.well-known/ucp` を書く場面は通常ありません。ただしカート関連の仕様変更が入ると既存の連携が動かなくなることがあるため、Shopifyからの告知は追ってください。
Q. Merchant Centerのフィード整備だけで足りますか。
A. 足りません。フィードだけを整えても、商品ページの表示と食い違っていれば、機械が読む側でどちらが正しいか判断できません。フィード・商品ページ・構造化データの3層で、SKU・価格・在庫・配送条件が同じ値になっている状態を目指してください。
Q. schema.orgの構造化データだけでUCPに対応できますか。
A. できません。構造化データはページの内容を機械に伝えるためのもので、UCPが求めるのは対応機能を宣言するプロフィールと、カートや決済をやり取りするAPIです。構造化データの整備はUCP対応の代わりにはなりませんが、商品データを揃える作業としては共通の土台になります。
Q. UCPに対応すると検索順位は上がりますか。
A. UCPへの対応を検索順位のシグナルとして扱うというGoogleの公式な説明は確認できません。UCPは検索順位ではなく、AIエージェント経由の購買導線に関する規格です。順位を目的にUCP対応を検討するのは、目的と手段がずれています。
参考情報
- UCP公式サイト（仕様・アナウンス）
- UCP仕様のリリースノート（破壊的変更の一覧）
- Google公式：UCPプロフィールの設置方法
- Google公式ブログ：ショッピングでの展開について
- ネットプロテクションズ 調査リリース（2026年8月4日）
最終確認日：2026年9月1日／参照仕様：v2026-08-25
