日本で「AI の中で買える」はいつ来る？ Universal Cart・UCP の現在地と越える壁

  • 投稿日
  • 著者 TANAKA Hiroki
  • カテゴリー コラム

Google が UCP（Universal Commerce Protocol）を発表したのは 2026年1月でした。その発表を解説した記事と、同年2月に書いた国産カートと商品データの記事に続いて、今回は「AI の中での決済」に絞って、日本の現在地と、日本で使えるようになるまでに越えるべき壁を整理します。

2026年10月15日には、同年5月の Google I/O で発表された Universal Cart が米国で提供開始されました。「AI の中で買える」が、少なくとも米国では、構想から実際の機能になったわけです。

では、日本にはいつ来るのか。何が壁なのか。この2つを、この記事で確かめていきます。（本記事はかなりボリュームが大きくなったので、必要なところだけをご参照ください）

参考記事
Google の UCP 発表で何が変わる？ AI エージェント時代のネットショップはどうなるか
「AI が勝手に商品を選んで買ってくれる時代」が、思ったより早く来そうです。 2026年1月、Google は…
yuwai-inc.jp
日本のネットショップは、AI エージェンティックコマースの波に乗れるのか
「AI が買い物をする時代」は、もう始まっている 「AI エージェンティックコマース」 この言葉を聞いて、あな…
yuwai-inc.jp

「集客」と「AI の中での決済」は別の話

「エージェンティックコマース」という言葉で語られている話には、性質の違う2つの側面が混ざっていると筆者は考えています。

1つ目は集客、つまり見つけてもらう話です。Google 検索の AI モードや ChatGPT が商品を見つけ、自社サイトへ送客する。これは 2026年10月時点の日本でも起きていて、後で触れる特定商取引法（特商法）の論点とは関係なく進みます。

2つ目は AI の中での決済、つまりその場で買える話です。Google や ChatGPT の画面内でチェックアウトが完結する。こちらは日本ではまだ提供されておらず、越えるべき壁があります。

国内で「エージェンティックコマース対応」として出ている提案を見ると、中心は「AI に選ばれる準備」です。商品情報の整理、データフィード、GEO、UCP への接続といったメニューが並びます。

広告代理店や EC 支援会社、カートや決済の事業者が、それぞれの立場からこうした提案を出しています。EC-CUBE も、次のバージョン 4.4 で UCP に対応すると 2026年5月に予告しています（正式版は2026年10月時点で未リリース）。いずれも集客側、つまり「AI に選ばれる準備」とその延長としての UCP 接続のメニューです。

参考

法律の論点そのものは、すでに指摘されています。Google の UCP チェックアウトが日本では使えないことは多くの解説記事でも指摘されていますし、特商法の最終確認画面の表示義務を、日本国内で展開するうえでの障壁として挙げた技術ブログもあります。そうした指摘は開発者向けの記事にとどまっていて、事業者が経営判断をする材料としては流通していない、というのが筆者の見方です。

参考

送客の話に限れば法律の論点が出てこないのは、ある意味当然です。送客で完結するなら、決済画面を誰が用意するかという問題は起きないからです。問題になるのは、両者を混同して語ることで、UCP 対応のような決済側の投資が、日本の集客にも役立つかのように聞こえてしまう場合です。集客の話と決済の話は、投資の判断も、越えるべき壁も別です。

前者の集客の話は、商品ページと商品データの話として別の記事で扱う予定です。この記事が扱うのは後者、AI の中での決済です。ここで言う「AI の中での決済」は、AI の画面に決済が組み込まれ、店のシステムと規格でつながる仕組みを指します。AI が利用者の代わりに店のサイトを操作して購入する仕組みは、店側の関わり方が異なるため、後で分けて取り上げます。

2026年2月の記事で使った「Google Commerce Data Flow」の図で言うと、この記事は、AI の画面から店のカートへ直接伸びる UCP の矢印の話です。商品ページ・商品データから Google Merchant Center、Shopping Graph へ向かう矢印の側が、集客の話にあたります。

図：Google Commerce Data Flow（2026年2月の記事の図を再掲）。右上の、AI の画面からカートへ直接伸びる UCP の矢印がこの記事の範囲。青い矢印の上流（商品ページ・商品データ → Google Merchant Center → Shopping Graph）が別の記事の範囲

Universal Cart・UCP・AP2 の関係を整理する

名前が3つ出てくるので、先に関係を表にしておきます。

名前概要役割2026年10月時点
Universal Cart利用者向けのカート機能複数の店の商品を保存し、値下げ・再入荷の通知、支払い方法の提案、購入のサポートを行う米国で提供中（10/15〜）
UCP（Universal Commerce Protocol）オープンな通信規格AI と店のシステムをつなぐ規格。Google の画面上での購入は、その使い方の1つGoogle のチェックアウトは米国・カナダ・オーストラリア向けの商品が対象（実態は米国先行）
AP2（Agent Payments Protocol）代理決済の規格利用者が決めた条件の範囲で AI が代わりに支払うときの、権限と記録の取り決め規格は公開済み。Universal Cart にはまだ組み込まれていない

ざっくり言えば、Universal Cart は利用者が触る画面、UCP はその裏で店とつながる配線、AP2 は「AI が代わりに払う」ための約束事（まだ Universal Cart には未実装）、という関係です。

Universal Cart：ユーザー向けカート

Universal Cart は、2026年5月19日の Google I/O で発表され、10月15日に米国の Google 検索（AI モード）と Gemini アプリで提供が始まりました。発表時には「今夏」（2026年の夏）とされていたので、予定からは遅れたことになります。

できることは、複数の店の商品を1つのカートに保存することや、値下げ・再入荷の通知、Google ウォレットに登録したカードの特典を踏まえた支払い方法の提案、プロモコードの表示、そして購入などです。購入の経路は2つあります。対応している店なら Google Pay でそのまま購入でき、それ以外の店では、店のサイトのカートへ商品を移して購入します。この「カートごと店のサイトへ送る」経路は、UCP の Cart 機能（dev.ucp.shopping.cart）で動いています。

どちらの経路でも、販売者は各店です。注文確認もサポートも店が行います。2026年5月に紹介されていた互換性チェック、価格履歴、YouTube や Gmail への対応は、提供開始時の発表には記載がありませんでした。発表された構想のすべてが、提供開始の時点で揃っているわけではない、という点は押さえておきたいところです。

参考

UCP：Google の画面上で決済を可能にする規格

UCP は 2026年1月11日、NRF で発表されました。Google 検索の AI モードと Gemini で、Google の画面上でチェックアウトが完結する仕組みです。このとき店は販売者（seller of record）のままで、Google が売主になるわけではありません。

店舗側では、Google Merchant Center に登録されている商品データにおいて、ネイティブ コマース [native_commerce] 属性の購入手続きの対象 [checkout_eligibility] サブ属性を設定します。この属性を true にした商品に「購入」ボタンが出るようになります。

決済は現状では Google ウォレットに保存されたカード番号（FPAN）を使います。店舗側には Google Pay & Wallet Console のアカウントが必要で、Google Pay に対応した決済代行会社（PSP）経由でつなぐか、直接連携するかを選びます。直接連携の場合は、暗号化の設定と PCI 関連の書類が必要です。

ここで混同しやすいのが、Google Merchant Center にもともとある「チェックアウト ボタン」との違いです。既存のチェックアウト ボタンは自社サイトで決済するもので、UCP のチェックアウトは Google 上で決済します。決済がどこで起きるかが、この2つの違いです。

参考

AP2：条件の範囲内で AI が支払いを代行する規格

AP2 は 2025年9月に Google Cloud が公開した代理決済の規格です。利用者が決めた条件の範囲で AI が代わりに支払うときに、どんな権限で動き、何を記録として残すかを定めるものです。

2026年5月の発表では、条件を満たしたときだけエージェント（Gemini Spark）が購入する仕組みを今後導入するとされました。これは Universal Cart の提供開始時点の機能には含まれていません。「AI が代わりに買ってくれる」というイメージが先行しがちですが、2026年10月時点で米国で動いている仕組みでは、利用者が自分でカートを確認して購入する形になっています。

参考

現在地：どこで、誰が使えるのか

※ この章の内容は 2026年10月29日時点のものです。対応国の追加などがあれば更新します。

Google Merchant Center ヘルプによると、UCP チェックアウトの対象は米国・カナダ・オーストラリア向けの商品で、2026年10月時点では一部の店舗に限って提供されています。英国は 2026年5月の Google の発表で「その後に続く」とされています。UCP チェックアウトの利用規約は米国のみを対象としています。Universal Cart は米国のみの提供で、日本での提供時期は発表されていません。

なお、開発者向けドキュメントでは、UCP の統合ハブは米国から順次提供され、オーストラリアとカナダは来年（2027年）初めに続くと書かれています。ヘルプの「3か国向けの商品が対象」という記述とは時期のニュアンスが異なるため、実態としては米国が先行していると見ておくのがよさそうです。

補足として、店側の実装がどれだけ進んでいるかを示す数字があります。店が UCP に対応していることを示すファイル（ディスカバリーファイル、/.well-known/ucp）を公開しているサイト数を追っている Originality.ai のダッシュボードによると、2026年5月1日時点で26サイトだった公開実装は、9月1日に1,015サイト、10月1日には73,509サイトに急増しています。9月から10月にかけて約70倍に増えていますが、急増した直接の原因は確認できていません。

関連して、Shopify は2026年6月の Spring ’26 Edition で、Shopify ストアでは初期設定で UCP が有効になっているとしています。

参考

Meta の Muse は「AI の中で買える」にあたるのか

Meta のパーソナル AI エージェント「Muse」は、2026年10月23日に日本で提供が始まり、ショッピングにも使えるとされています。購入のような重要な操作の前には、利用者本人に確認する設計です。日本でも「AI の中で買える」時代がすでに来ているのではないか、という見方もできそうです。

UCP と Muse は、仕組みを見ると別物です。Meta の説明では、Muse は利用者ごとに用意された専用の仮想マシンの中でブラウザを開き、フォームに入力して、人と同じように店のサイトを操作します。利用者はその様子を見ることも、途中で操作を引き取ることもできます。購入の前には、店や金額を示した承認の画面が Muse のアプリ側に出て、利用者が承認して初めて支払いが進みます。

決済は米国では Stripe の Link を使い、Link 対応店なら保存済みの支払い方法で、非対応店には利用者が承認した金額に限った使い捨ての仮想カードを発行して支払います。最終的な金額の承認は利用者がチャット上で行います。Stripe はこの仕組みを米国の消費者向けとしていて、日本で Muse がどの決済経路を使うかは、筆者が確認できた範囲では発表されていません。

UCP が「店が規格を実装して、Google の画面に決済を組み込む」仕組みだとすると、Muse は「店が何もしなくても、AI が店の画面を代わりに操作する」仕組みです。店から見ると、UCP は参加するかどうかを自分で決める仕組みで、Muse は自社のカートと最終確認画面がそのままエージェントに操作される仕組みです。

EU の研究機関 CERRE の論文（後述）も、人のクリック操作を模倣するエージェントと、規格で直接つながるエージェントを分けて論じています。この記事で「AI の中での決済」と呼ぶのは UCP のほうで、Muse はその枠の外にあります。ただし Muse には Muse なりの論点があるため、次の章で順次触れていきます。

参考

日本で提供するために乗り越えるべき壁

ここからは、日本で提供するにあたってクリアすべき論点を見ていきます。Google が日本での提供時期やその理由について言及した発表は、筆者が確認した限り見当たりません。そのため、本稿は「なぜ遅れているのか」を断定・説明するものではなく、どのような論点があるかを整理したものとして読んでいただければ幸いです。

注意事項

本章では、法律の論点を【事実】と【仮説】に分けて書いています。

【事実】は条文・公的資料・公式ヘルプで確認できたことです。【仮説】は条文を読んだうえでの筆者のまとめで、法律の専門家の確認を経ていません。

筆者は条文の当てはめがどちらに転ぶかを判断する立場にないため、【仮説】では結論を出さず、どちらに転んだ場合に店に何が起きるかを並べる形で書いています。個別の判断の根拠にはせず、専門家にご確認ください。

特定商取引法の最終確認画面（第12条の6）

【事実】特商法第12条の6は、事業者が画面に表示する手続きに従って行われる申込み（特定申込み）について、その画面（最終確認画面）に6つの項目を表示するよう求めています。①分量、②販売価格（送料を含む）、③支払時期と支払方法、④引渡時期、⑤申込期間、⑥申込みの撤回や解除に関する事項です。あわせて同条第2項は、送信が申込みになることや上記の事項について誤認させる表示を禁じていて、誤認して申し込んだ場合は第15条の4で取消しができます。

参考

【事実】消費者庁の堀井長官は、2026年10月15日の記者会見で、AI エージェントが人に代わって商品を購入する取引について質問を受けています。公式の会見要旨によると、長官は、特商法には最終確認画面の表示義務や誇大広告の禁止などがあり問題があれば同法で対応すると述べました。そのうえで、AI の提供主体や代行する行為の範囲によって取引の形態が多様になりうるため、個別の事案を離れた一般論としては現時点で法的評価が難しい、という認識を示しました。

AI エージェントの介在が既存の義務に影響するかは「現時点では未知数」とし、新しい取引の状況把握に努めるとしています。この点は、所管官庁も判断を示していない段階です。

参考

【仮説】UCP のチェックアウトでは、最終確認画面は Google が用意します。この画面が第12条の6 の「特定申込み」の画面に当たるのかどうか、当たるとして表示義務を負うのは店なのか Google なのか、という線引きは、筆者が確認できた範囲では見当たりません。

当たるなら、店は自分の義務を他社の画面に預ける形になり、6項目が店の意図どおりに出せるのかどうかが焦点になります。当たらないなら、最終確認画面の規定が働かない場面で買い物が完結することになります。どちらに転んでも、店が自分で表示を確認できない状態が生まれます。ここが、まだ答えの出ていないところです。

【仮説】もう1つ、AI モード上で商品を提示する場面が通信販売の広告（第11条と施行規則）に当たる場合、事業者の氏名や住所、返品特約の表示をどう担保するかも分かっていません。

【仮説】Muse のように AI が店の画面を操作する場合は、最終確認画面を用意するのは店のままですが、それを読んで操作するのはエージェントで、購入の承認は Muse のアプリ側の画面で行われます。利用者は店の画面を見ることもできますが、見なくても購入は確定します。店の最終確認画面を人が見ることを前提にしていない申込みの扱いがどうなるのかは、まだ見えていません。

特商法の見直し（中間取りまとめ）

【事実】消費者庁の「デジタル取引・特定商取引法等検討会」は、2026年9月2日の第9回で中間取りまとめ（案）を示し、9月10日付で中間取りまとめとして公表しました。10月31日まで意見募集が行われています。これは検討会の提言であって、確定した法改正ではありません。主な方向として、次の4点が挙げられています。

  • 最終確認画面での支払総額の表示と、取引条件の分離表示（価格・期間・解約条件を別の場所に散らす表示）の禁止
  • 注文完了後、契約内容を記載した電子書面を遅滞なく交付する義務（後から改変されない形で保存できる方法が望ましいとしつつ、現行の取引慣行も踏まえて検討）
  • 広告や UI のダークパターンに、一定程度包括的な規律を検討する
  • チャット等による勧誘に、電話勧誘販売と同等の規律

【事実】あわせて中間取りまとめの脚注には、AI エージェントや AI アシスタントを介した取引の論点についても今後検討を行う必要がある、という指摘があったことが記されています。

参考

【仮説】この方向が法律になった場合、AI との会話の画面が最終確認画面として扱われるなら、総額・期間・解約条件を一体で表示できるかどうかが論点になります。やり取りを短くすることが会話の画面の価値だとすると、「散らさずに一体で見せる」要請とは相反することになります。扱われないなら、見直しの趣旨である「取引条件を一体で把握できる」状態が、会話の画面には及ばないことになります。

【仮説】また、店が運営するチャット型の AI（Business Agent と呼ばれるもの）との会話が「チャット等による勧誘」に当たるのかどうかも決まっていません。当たるなら店の会話に電話勧誘販売と同等の規律がかかりますし、当たらないなら勧誘の規律が及ばない会話から申込みに至ることになります。

カード決済と EMV 3-D セキュア

【事実】日本のクレジットカード・セキュリティガイドラインは、2025年3月末までに原則すべての EC 加盟店に EMV 3-D セキュアの導入を求め（4.0版）、現行の 6.1版でも EC 加盟店は EMV 3-D セキュアを導入するものとしています。未導入が認められる取引は附属文書で別に定められています。一方で、UCP の決済は現状、Google ウォレットに保存されたカード番号（FPAN）を使う仕組みです。

参考

【仮説】会話の中で買い物が完結する画面で、本人認証の画面をどこで、どう出すのかは整理が必要ではないかと考えています。AP2 の代理購入のように人が画面を見ていない場面で買う場合や、Muse のように使い捨ての仮想カードで店に支払う場合も、誰がどこで本人認証を通すのかを整理する必要があります。

電子消費者契約法と代理購入

【事実】電子消費者契約法（電子消費者契約に関する民法の特例に関する法律）は、画面の手続きに従って送信する契約を対象に、操作ミスによる申込みの扱いを、事業者が画面で意思の確認を求める措置を講じていたかどうかで分ける規定を置いています（第3条）。また、総務省と経済産業省の「AI 事業者ガイドライン」第1.2版（2026年3月31日）は、AI 全般の原則として適切なタイミングで人間の判断を介在させることを挙げています。別添では AI エージェントが人間の意図しない商品の注文を行う可能性をリスクとして挙げています。

参考

【仮説】AP2 が想定する条件付きの自動購入は、「人が最終確認画面を見て申し込む」ことを前提にした枠組みと噛み合いにくいのではないか、と筆者は考えています。確認措置を AI 側の記録で代替できるなら、人が画面を見ない購入が枠組みの中に収まります。代替できないなら、条件を満たした時点で人の確認を挟む形になり、「代わりに買う」の意味が変わります。どちらになるかは 2026年10月の時点では分かりません。

業種ごとの規制

酒類の年齢確認や医薬品の販売ルールのように、業種ごとに上乗せされる規制もあります。AI の画面で誰が、どの段階で確認するのか、という同じ形の論点がここにもあります。

法律以外の壁

法律だけが壁ではありません。日本で使われている支払い手段には、後払い、コンビニ払い、代引き、ポイントがあります。UCP の決済が現状 Google ウォレットのカードを前提にしている以上、Google の画面内で完結する経路では、これらの手段は使えないことになるのではないでしょうか。

カートごと店のサイトへ送る経路なら店側の支払い手段が使える余地はありますが、それは「AI の中で買える」とは別の話です。Google Pay が日本でどれだけ使われているかも、見ておく必要があるでしょう。

もう1つが日本で使われているカートの UCP 対応です。筆者が確認できた範囲では、日本で広く使われているカートのうち、店が何もしなくても UCP の入口が開いているのは Shopify だけです。Shopify は2026年6月から店の UCP を初期設定で有効にしていて、日本の Shopify ストアでも、UCP のディスカバリーファイルの対応機能の一覧に checkout や cart が並んでいることを筆者は確認しました。

国産カートでは、ecbeing が UCP の仕様を採用した独自の実装を進めると2026年8月に発表しています。ただしこれは社内で概念実証を実施したという報告で、提供時期は示されていません。同じ日に GMO ペイメントゲートウェイも、UCP をベースにした決済ソリューションを構築したと発表し、ecbeing を含む国産カート各社との連携について、対応範囲と提供時期はカートごとに順次案内するとしています。

入口が開いていても、それを使って買い物を成立させるのは Google の側です。その Google の UCP チェックアウトが、日本向けの商品を対象にしていません。入口が開いている米国の店でも、起きるのは Google の画面での決済と、Universal Cart からカートごと自社サイトへ送られる送客の2つです。店側の準備とGoogle側の提供は、まったく別の話なのです。

UCP には決済のほかに、エージェントが店の商品を検索・参照するための機能（Catalog 機能）もあります。Shopify はこれを店ごとのエンドポイントで提供していて、日本の Shopify ストアのディスカバリーファイルにも並んでいます。ただ、この検索は「その店を既に知っているエージェントが、その店の中を探す」ためのもので、どの店に商品があるかを決める段階では使えません。

Shopify は全店を横断する Global Catalog も出していますが、それは Shopify が自社の全店のデータを索引にして持っているからできることで、UCP の規格の力ではありません。

どの店が選ばれるかは、Google なら Merchant Center と Shopping Graph、Shopify なら Shopify Catalog という商品索引、つまり UCP の外にある各社の商品データが決めています。Shopify を整えるだけでは AI に見つけてもらえるとは限らない、という話は 2026年6月の記事に書きましたが、その構図は UCP の入口が開いた後も変わっていません。

参考
参考記事
Shopify を整えれば AI 時代も安泰、とも限らない。商品探索の「入り口」と「出口」の話
エージェンティックコマースをめぐって、ひとつの空気が広がっています。「Shopify を使っていれば、AI 時…
yuwai-inc.jp

「日本だけが遅い」とは言い切れない

ここまで読むと、「日本は法律が厳しいから遅れる」という話に聞こえるかもしれません。ただ、そうは言い切れない、というのが筆者の見立てです。

EU でも、消費者法が求める開示や、支払義務を負うことの確認が、人間による直接の操作を前提に作られていると指摘されています（CERRE の論文、2026年7月）。この論文は UCP を名指しして、エージェントが API で直接やり取りする場面では、ボタンや目立つ表示を前提にした要件を満たすこと自体が構造的に難しくなる、と書いています。「人が画面を見て、確認して、申し込む」ことを前提にした消費者法と、AI が代わりに動く仕組みとの噛み合わなさは、日本に限った話ではないわけです。

参考

そのうえで、日本固有の上乗せと言えるものはあります。EMV 3-D セキュアの義務化、特商法の最終確認画面の規定、そして後払いやコンビニ払いのような決済習慣です。「日本だけが遅れているわけではない」ものの、独自のハードルが存在するのも確かです。

経営判断：今やる・備える・検討を続ける・やらない

では、ネットショップの側は何をすればいいのか。AI の中での決済に限って、4つに分けます。

判断対象
今やる日本向けのみの場合は該当なし。米国・カナダ・オーストラリア向けに越境販売している場合は、UCP チェックアウトの提供対象になる要件の確認
備える最終確認画面と注文完了メールの点検。カートベンダーへの UCP 対応ロードマップの確認
検討を続ける日本で提供が始まった後に、カートベンダー経由ではなく自前で UCP に対応するかどうか
やらない日本向けのみの店が、提供前に自前で UCP を実装すること

日本向けのみの店では「今やる」が該当なし、という結論に意外さを感じるかもしれません。ただ、日本で提供されていない仕組みに先行投資しても回収の見通しは立たない、と筆者は考えています。

「提供が始まったときにすぐ乗れるよう、先に作っておくべきだ」という考え方もあるでしょう。とはいえ、Shopify のように店側の作業なしで入口が開く例が出てきたことで、自前で先行投資する必要性は以前より下がっています。提供が始まってからカートベンダーの対応に乗るほうが、投資の無駄が少ないのではないでしょうか。そのため、「備える」にカートベンダーへのロードマップ確認を入れています。

「備える」に挙げた最終確認画面と注文完了メールの点検は、UCP があってもなくても必要なものです。特商法の見直しが支払総額の表示や注文後の電子書面の交付を求める方向で進んでいる以上、今の自社の画面とメールがどうなっているかを確かめておくことは、AI とは無関係に意味があります。

Muse のように AI が店の画面を操作する場合は、自社の最終確認画面そのものをエージェントが読むことになるので、この点検はそちらにも役立つと見ています。この記事で勧めるのは、大きな改修ではなく、今あるものの棚卸しです。

「検討を続ける」を「今やる」に動かすきっかけは、3つあると考えています。日本での UCP チェックアウトや Universal Cart の提供発表、特商法の見直しの法案確定、そして 3-D セキュアと代理購入の扱いの整理です。このどれかが動いたら、この記事の判断も変わります。

さいごに

もう一度、図に戻ります。

図：Google Commerce Data Flow（再掲）。UCP の矢印は図の一部で、手前に商品ページ・商品データ・Google Merchant Center がある

この記事で扱った UCP の矢印は、図の一部でしかありません。矢印の手前、商品ページ・商品データ・Google Merchant Center が整っていなければ、決済の入口ができても AI に商品が届きません。逆に、データと決済の入口が整っても、選ばれるかどうかは商品・価格・信頼・需要といったマーケティング次第です。UCP は買いやすくする仕組みであって、選ばれる理由を作るものではないと筆者は考えています。

そして多くの場合、テコ入れが必要なのは図に描かれた商品ページよりさらに手前、商品を管理している基幹システムと、商品情報を入力する運用のほうです。いちばん多いのは、商品データに入れたい情報が商品マスタの項目として存在しない、というケースです。詳しくは別の記事で扱う予定です。

エンタープライズ向けには、データ・SEO・広告・開発・計測を分業でカバーするサービスが出てきています。一方で、中小の事業者にとっては、商品ページから Google Merchant Center、AI の画面、計測までを一続きで見て相談に乗れる相手が少ない、というのが筆者の実感です。「AI の中で買える」体験が日本に上陸するのがいつかは、まだ分かりません。その時が来たときに慌てないために、今の自社の商品データと決済の画面がどうなっているか、一度見直してみてはいかがでしょうか。

この記事でお伝えしたかったのは、「AI の中での決済」は集客とは別の話であり、日本で使えるようになるまでに越えるべき壁があること、そして今できるのは現状の棚卸しだということです。

Yuwai株式会社では、Google Merchant Center の構造設計を通じて、商品データの現状把握から支援を行っています。基幹システムや入力の運用まで含めて全体を俯瞰し、どこに穴があるか、どう直すか（データの持ち方、システム間の連携、入力や生成の自動化）を一緒に設計します。システムの改修そのものは、今お使いのベンダーと進めていただくことを基本に、必要に応じて小さな連携ツールの実装まで支援します。

ネットショップを運営している事業者の方へ

  • 何から始めればいいかわからない
  • 社内で対応できる人材がいない
  • 現状が正しいのか判断できない

まずは現状の棚卸しから。原因がどこにあるか、それは誰の持ち場か（EC・マーケ、商品部、情報システム部門）、どう直すかの選択肢を、社内でそのまま共有できる形でお出しします。1時間単位の相談から、本格的な構造設計まで、段階的に支援できる形をご用意しています。

ネットショップ担当者向け
サービスについて

広告代理店・Web 制作会社・EC 支援会社の方へ

原因がフィードや広告の手前、クライアントの商品マスタや入力の運用にある場合、そこから先は支援の契約範囲の外になりがちです。パートナー型なら、クライアントの情報システム部門やベンダーとの調整に同席し、黒子型なら、御社名義でクライアントに提案できる診断と設計の材料をご用意します。

支援事業者さま向けの
連携サービスについて
パートナー型・黒子型、いずれの連携にも対応しています