Googleの「Buy for me」で注文が自動で入る時代｜EC事業者が今すぐ整える在庫・価格・返品の3点

齋藤竹紘2026年8月3日2026年8月3日AIニュース

Buy for meとは、Googleが購入を代行するAI機能のことです。

Google Payのヘルプには、Buy for meで購入が失敗する条件が3つだけ書かれています。商品が在庫切れになったとき、確認した時点から価格が大きく動いたとき、カードの有効期限切れや決済拒否が起きたときです（Google Pay ヘルプ）。裏を返せば、店舗側が事前に潰せる失敗要因は在庫と価格の2つに絞られます。しかも注文が通ったあとのキャンセル・返品・誤出荷は、Googleが一切引き受けず「販売店に連絡してください」と案内する設計でした。

本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。2026年8月3日時点で Google Buy for me エージェンティックチェックアウトは米国・英語のみの提供で、日本国内向けストアは対象外です。それでも在庫・価格・返品の3点は、日本のモール運営でも今日から手を付けられます。どの順番で、どこまで直せばいいのか。Googleの一次情報に当たりながら整理していきます。

Buy for meが肩代わりする範囲と、処理が止まる場所

Buy for meが自動化するのは、購入ボタンを押す作業だけです。商品を選ぶのも支払い方法を決めるのも、依然として買い手の操作が挟まります。Googleは2025年11月13日の公式ブログで、「常に事前に許可を求め、購入内容と配送情報を確認いただいたあとにのみ購入します」と明記しました（Google The Keyword）。

流れはこうです。買い手が価格追跡機能で、商品をサイズ・色・希望上限額まで指定して登録します。設定額まで値下がりするとGoogleから通知が届きます。対象加盟店なら「Buy for me」ボタンが出て、購入内容を確認するとGoogleがGoogle Payで加盟店サイト上の決済を完了させます。発表時点の対象は米国のWayfair、Chewy、Quince、一部のShopify加盟店です。

この機能を支えるShopping Graphは、Googleの発表によれば500億件超の商品リスティングを持ち、うち20億件が1時間ごとに更新されています。日次バッチでCSVを流すだけの運用では、この鮮度に自店のデータが追いつきません。

2026年1月11日には、GoogleがUniversal Commerce Protocol（UCP）を発表しました。エージェントと加盟店システムが共通言語で会話するためのオープン規格で、Shopify、Etsy、Wayfair、Target、Walmartと共同開発し、20社以上が支持しています。A2A、AP2、MCPとも互換性を持つ設計でした。中身はUCPのEC事業者向け対応点で扱っています。

同じ発表のなかで、実務上いちばん重い一文が置かれています。「Retailers remain the seller of record」、つまり販売者はあくまで小売側のままだ、という宣言でした。エージェントが注文を作っても、契約主体も責任主体も店舗です。ここが、在庫・価格・返品の3点に絞る理由になります。

日本のストアが「まだ来ていない」で放置できない理由

発見と比較の段階は、すでに日本語で動いています。Googleは2025年9月8日にAIモードを日本語を含む5言語へ拡大しました（Google The Keyword）。日本語で「予算1万円台、乾燥肌向け、無香料」と話しかけて比較表を受け取るところまでは、日本でも日常になっています。

一方でBuy for me本体は、Google Payヘルプが「米国、英語、Google Payを受け付ける一部加盟店のみ」と明記しています。利用者側にも、Googleアカウントに保存した有効な支払い方法とGoogle Pay用の米国住所が必要です。日本国内向けストアが対象外である点は、一次情報で明らかです。

地理的な拡大は、2026年5月のGoogle Marketing Liveでカナダ、オーストラリア、英国への展開が示されたとSearch Engine Landが報じています。ただし報道ベースで、日本の時期に触れたGoogleの公式記述は2026年8月3日時点で確認できませんでした。提供時期は未発表、要確認という扱いが妥当です。

それでも待てないのが越境ECです。米国向けにShopifyや自社ECで販売している事業者は、すでに当事者です。初期対象に「一部のShopify加盟店」が含まれていた以上、フィードと返品ポリシーの整備状況で注文が入る店と入らない店が分かれます。実数の動きはAI経由の購入が全体の8%に到達したという調査でも触れました。

国内モールの事業者にとって重要なのは、自社が触れる範囲の線引きです。楽天市場・Amazon・Yahoo!ショッピングでは、Googleに渡る商品データの経路をモール側が握っています。出店者がRMSやセラーセントラルで操作できるのは商品名・価格・在庫数・出荷設定までで、Merchant Centerの返品ポリシー画面には触れません。モール側のデータがShopping Graphへどう流れるかも仕様依存で要確認です。論点は「何もできない」ではなく、「自社ドメインの導線を1本持つか」という経営判断に移りました。

最優先は在庫｜フィードの鮮度がそのまま注文成立率になる

3点のうち最初に直すべきは在庫です。在庫切れは即座に注文不成立になるうえ、その失敗が店舗側の管理画面に一切残りません。買い手には「購入できませんでした」と通知が届き、店舗には何も届きません。ログに残らない取りこぼしは、いちばん改善が遅れます。

Merchant Centerには、この種のズレを埋める自動更新機能（automations）があります。対象は price、sale price、availability、condition の4属性です。クローラが商品ランディングページのschema.org構造化データを読み、フィードとズレていればページ側の値で上書きします。ヘルプの例では、フィードが4米ドルでページが3米ドルなら、広告や無料リスティングは3米ドルに更新されます（Google Merchant Center ヘルプ）。

ここに、日本の店舗が高確率で踏む落とし穴があります。ヘルプは在庫判定に「緩めのマッチングルール」を使うと明記しており、in_stock、preorder、backorder の3つは互換扱いです。フィードが in_stock で、クローラがページ上に preorder や backorder を検出しても、Googleは一致と判断して in_stock のまま維持します。取り寄せ品を在庫ありで流していても、警告もエラーも出ません。直近の支援案件で観測したのは、受注生産のアパレルとメーカー取り寄せの家電で、この状態が数か月放置されていたケースでした。人間なら納期表記を見て納得しますが、エージェントは買いに来ます。

対策は2段構えです。1つめは商品ページ側の構造化データを正確に書くこと。availability を InStock、OutOfStock、PreOrder に対応させ、取り寄せ品を安易に InStock にしないことです。2つめは更新頻度で、ヘルプ自身が「価格・在庫・状態が頻繁に変わるならMerchant APIでアップロードをスケジュールすることを検討してください」と案内しています。

そのうえでGoogleは、automations を定期更新の代替ではなく一部商品の一時的なズレを直す機能だと限定しています。日次CSVのまま自動更新に頼る運用は想定外です。モールの在庫連動ツールは入れているのに自社ECのフィード更新だけ日1回、という構成もよく見かけます。同期頻度のボトルネックは、たいてい自社ドメイン側にありました。

次は価格｜確認した金額より高くなると、そもそも買われません

価格の判定は非対称です。Google Payヘルプは「エージェンティックチェックアウトは、最終価格が確認した合計金額と同じか、それより低い場合に購入するよう設計されています」と書いています。値上がりしていれば購入は成立せず、課金も発生しません。値下がりしていれば通ります。値上げ方向のズレだけが注文を落とす構造でした。

日本の販促設計で問題になるのが、タイムセールの終了タイミングです。買い手が確認してからエージェントが動くまでにセールが終わると、その注文は静かに消えます。sale price を使うなら、sale price effective date で期間とタイムゾーンを正しく指定しておくこと。ヘルプもベストプラクティスに挙げています。

見落としやすいのがクーポンとポイントの扱いです。Google Payヘルプは「現時点でプロモコードやロイヤルティ特典に対応していません」と明記しています。クーポン適用後の実質価格で比較優位を取る設計は、エージェント経由では機能しません。楽天のポイント倍率、Amazonのクーポン、Yahoo!ショッピングのPayPay付与は「価格」そのものではないため、比較される金額には乗らないと考えるのが安全です。食品ギフトジャンルの中規模店舗では、通常価格を据え置いてポイント原資で戦っていた商品が、価格比較の土俵で軒並み不利な位置にありました。

参考価格の書き方にも注意が要ります。ヘルプは、ランディングページに打ち消し線価格が複数あると正しくクロールできない場合があるため、価格の自動更新を有効にすべきではないと述べています。「メーカー希望小売価格」「当店通常価格」「セール前価格」を並べる商品ページは、日本のモールでは珍しくありません。表示する参考価格は1つに絞るほうが安全でした。

3つめは返品｜Googleは購入後の問い合わせを全部こちらへ送ってきます

返品とキャンセルは、すべて店舗側の仕事になります。Google Payヘルプの「Fix issues」節では、注文のキャンセル、商品の返品、誤った商品の購入、配送の遅延と未着という4項目のうち3つへの回答が「購入した販売店に連絡してください」でした。UCPの「販売者は小売側のまま」という設計と一致しています。

そこで効いてくるのが、Merchant Centerの返品ポリシー設定です。商品ページに書いた返品説明文とは別に、構造化された設定として登録します。設定項目は11段階でした（Google Merchant Center ヘルプ）。返品ポリシーのURL、適用国、返品可否（不良品と自己都合の両方／不良品のみ／受け付けない）、交換の可否、返品可能な商品状態（未使用のみ／軽度使用まで可）、返品期間（日数指定または無期限）、繁忙期の期間延長、返品方法（店頭・持ち込み拠点・郵送）と返送ラベルの渡し方、通貨、返品手数料（無料・定額・定率）、返金処理日数の11点です。

要件も具体的です。返品ポリシーは、ログインや会員登録なしに誰でも閲覧できる状態でなければなりません。不良品だけでなく買い手都合の返品も対象に含めること、フッター・返品ページ・サイト内バナーで内容が一貫していることも条件でした。登録後はGoogleが検証し、Verified、Pending、Rejected のいずれかが付きます。

未登録でも、Googleは自店サイトから返品条件を推定して表示することがあります。その際、広告やリスティングに「ほとんどの商品について」という但し書きが付きます。5,000社支援の中で何度も再現したパターンとして、この状態を「Googleが勝手に書いた」と誤解して放置する例がありました。自分で登録して検証を通せば但し書きは外れます。商品ごとに条件が違う場合は、return policy label 属性で例外ポリシーを紐づけます。

日本の実務では、特定商取引法にもとづく表記の返品特約と、Merchant Centerの構造化返品ポリシーが別物である点を押さえておきます。前者は法定表示、後者は機械可読なデータです。片方だけ更新して食い違うと Rejected になる余地が生まれるため、返品期間を変えるときは両方を同時に直す運用にしておくと安全です。

ChatGPT・Claude・Geminiで回す準備プロンプト5本

ここからは、在庫・価格・返品の3点を棚卸しするためのプロンプトを5本掲載します。2026年8月時点のフラッグシップは、OpenAIのGPT-5.6（Sol / Terra / Luna）、AnthropicのClaude Opus 5とSonnet 5、GoogleのGemini 3.6 Flash / 3.1 Pro です。長文の仕様書を読ませる工程はOpus 5、量をさばく工程はGemini 3.6 Flash、というように使い分けると工数が抑えられます。

1本目は現状把握です。在庫データがどこで生まれ、どの経路でGoogleに届くかを時系列で書き出させます。

プロンプト1：在庫同期フローの穴出し

あなたはEC運用の業務設計に詳しいコンサルタントです。
以下の在庫更新フローを読み、AIエージェントが自動購入してくる前提で
「注文が入った瞬間に在庫が無い」事故が起きうる箇所を洗い出してください。

現状フロー：
- 基幹システムの在庫更新タイミング：{例：受注時に即時引き当て}
- モールへの在庫連携：{ツール名と頻度}
- 自社ECサイトへの在庫反映：{頻度}
- Google Merchant Centerへのフィード送信：{頻度と方式}
- 取り寄せ・受注生産品の在庫表現：{現状の値}

出力：
1. 事故が起きうる箇所を、発生確率が高い順に5つ
2. 各箇所について「何分〜何時間のズレが発生するか」の見積もり
3. 改修コストが低い順に並べた対策案
4. 今週中に手を付けられる項目と、システム改修が必要な項目の分類

2本目は商品ページ側の構造化データ点検です。availability の値がGoogleの想定と一致しているかを確認します。

プロンプト2：商品ページ構造化データの点検リスト作成

あなたはGoogle Merchant Centerの仕様に詳しいテクニカルSEO担当です。
以下の商品ページHTMLを読み、Merchant Centerの自動更新（automations）が
正しく機能するかを判定してください。

判定基準：
- schema.org の price / priceCurrency / availability / itemCondition が存在するか
- price は通貨記号・桁区切りなしの数値か
- priceCurrency はISO 4217の3文字か
- availability の値が InStock / OutOfStock / PreOrder のどれに該当するか
- 打ち消し線価格（参考価格）が2つ以上表示されていないか

商品ページHTML：
{HTMLを貼り付け}

出力：
1. 各判定基準の合否と、根拠になったHTML行
2. 不合格項目の修正案（実際に貼り替えるHTML）
3. この商品で価格の自動更新をオンにすべきか、オフにすべきかの判断と理由

3本目は価格設計です。クーポンとポイントを外した素の価格で、どこまで戦えるかを見ます。

プロンプト3：エージェント耐性の価格・セール設計チェック

あなたはEC事業者向けの価格戦略アドバイザーです。
AIエージェントは「プロモコード・ロイヤルティ特典を適用できない」前提で
比較・購入を行います。この条件下で以下の商品群の競争力を評価してください。

商品情報：
- ジャンル：{ジャンル}
- 表示価格（税込）：{価格}
- 現在の販促手段：{クーポン・ポイント倍率・セール頻度}
- クーポン適用後の実質価格：{価格}
- 主要競合の表示価格：{価格帯}

出力：
1. 「クーポン・ポイントを外した表示価格」だけで比較したときの順位イメージ
2. ポイント原資を表示価格の値下げに振り替えた場合の損益シミュレーション条件
3. セール期間中にエージェント注文が落ちるリスクが高い商品の特定
4. 参考価格（打ち消し線）を1つに整理する場合の推奨表記

4本目は返品ポリシーの下書きです。11項目を空欄なく埋めた状態にします。

プロンプト4：Merchant Center返品ポリシー11項目の下書き

あなたは日本のEC事業者の法務・カスタマーサポート設計に詳しい担当者です。
以下の情報から、Google Merchant Centerの返品ポリシー登録に必要な
11項目を過不足なく埋めた下書きを作成してください。

自社情報：
- 取扱ジャンル：{ジャンル}
- 現在の返品条件（サイト掲載文）：{文面を貼り付け}
- 特定商取引法にもとづく表記の返品特約：{文面を貼り付け}
- 返品を受け付けない商品カテゴリ：{該当があれば記載}

埋める11項目：
返品ポリシーURL／適用国／返品可否／交換可否／返品可能な商品状態／
返品期間／期間延長／返品方法と返送ラベルの渡し方／通貨／
返品手数料／返金処理日数

出力：
1. 11項目の記入内容
2. 特商法表記との食い違いがある箇所の指摘
3. 例外ポリシーが必要な商品グループと、付けるべきラベル名の案
4. サイト側で修正が必要な記述（フッター・返品ページ・バナー）

5本目は運用側です。注文が落ちたケースを店舗が拾えるようにします。

プロンプト5：エージェント注文の失敗・トラブル対応テンプレ

あなたはECのカスタマーサポート責任者です。
AIエージェント経由の注文で発生しうるトラブルについて、
一次対応のメールテンプレートを作成してください。

想定ケース：
1. 在庫切れで購入が成立しなかった買い手からの問い合わせ
2. 価格が上がって購入が成立しなかったケース
3. 意図と違う商品が購入されたという申し出
4. 注文のキャンセル依頼
5. 配送遅延・未着の問い合わせ

条件：
- 日本語のですます調、1通400字以内
- 自社が販売者であることを明確にする
- 返品・キャンセル可否は当社の返品ポリシー（{返品条件を記載}）に従う
- 謝罪と事実確認と次のアクションを、この順で書く

出力：ケースごとのメール本文5通と、それぞれの社内エスカレーション基準

現場で起きている失敗例と回避策

1つめは、取り寄せ品を in_stock で流し続けるパターンです。回避策は、受注生産・取り寄せ・予約商品のSKUを洗い出し、availability を PreOrder または OutOfStock に寄せること。売上が落ちるように見えて、キャンセル対応の工数と評価の毀損を考えれば割に合います。

2つめは、参考価格を並べすぎる商品ページです。複数の参考価格を同時に見せていると、クローラがどれを打ち消し線価格と判断するかが安定しません。楽天市場で二重価格表記が景表法上の指摘を受けやすいことも踏まえると、1つに整理しておくのが実務的でした。

3つめは、返品条件を画像の中に書いているケースです。PC用商品説明文に貼った画像バナーに「返品は商品到着後7日以内」と書いてあっても、クローラも生成AIもテキストとして読めません。アパレル系の単一店舗で試したケースでは、画像内テキストを本文テキストに書き起こしただけで、返品ポリシーの検証ステータスが Pending から Verified に変わりました。

KPI設計と費用・工数目安

追うべき指標は3つです。1つめは在庫データの同期遅延、つまり基幹システムの在庫変動からMerchant Centerへの反映までの経過時間で、日次バッチなら最大24時間、Merchant APIで1時間ごとに回せば最大1時間まで縮みます。2つめは商品不承認率と、価格・在庫の不一致アラート件数。3つめは返品ポリシーの検証ステータスで、Verified 以外が残っていないかを月1回確認します。

工数の目安は、構造化データの点検と修正に初回2〜3人日、返品ポリシー11項目の整備に半人日、フィード更新頻度の見直しに1人日前後という感覚です。生成AIの月額は、ChatGPT Plusが20米ドル、Claude Proが20米ドル、Geminiの有料プランが同水準というのが2026年8月時点の目安で、最新価格は要確認です。上記のプロンプト5本なら1アカウントで足ります。

効果の見え方は断定を避けたい部分です。エージェント経由の注文が日本でまだ立ち上がっていない以上、売上インパクトは測定できません。ただし在庫精度と返品条件の整備は、Merchant CenterのAIパフォーマンス計測でも見たとおり、通常のショッピング広告と無料リスティングの成果に先に表れます。

2026年後半に差が出る論点

Googleは2026年1月の発表で、Merchant Centerに会話型コマース向けのデータ属性を数十種類追加すると告知しました。よくある商品質問への回答、互換性のあるアクセサリ、代替商品といった、従来のキーワードの外側にある情報が対象です。商品名とスペックだけを整えてきた店舗と、質問への回答や代替提案まで構造化した店舗で、エージェントが引ける情報量が変わる。ここが次の分岐点です。

同時に発表されたBusiness Agentは、ブランドの声で商品質問に答える仮想販売員を検索結果に出す機能で、米国の対象小売事業者がMerchant Centerから有効化できます。Direct Offersは、AIモード内で限定オファーを出すGoogle Adsのパイロットです。いずれも米国先行ですが、AIモード内で比較から購入までを完結させにいく方向性ははっきりしています。

属性追加が進むほど、モール依存度が判断軸として重くなります。楽天市場やAmazonだけで売る店舗はデータの粒度をモールに委ねますが、自社ドメインを1本持てば、返品ポリシーも構造化データも属性追加も自分の裁量で動かせるからです。この観点はAIコマース対応度の診断やShopifyのエージェント向けプロファイル最適化でも整理しています。

今日から3週間で動かす順番

初週は在庫です。取り寄せ・受注生産・予約のSKUを抽出して availability を実態に合わせ、商品ページに price、priceCurrency、availability、itemCondition の4つが揃っているかを点検します。2週目は価格で、参考価格の整理と sale price effective date のタイムゾーン設定を直します。3週目は返品で、Merchant Centerの11項目を埋め、サイト側の記述と特商法表記を一致させます。

この3週間は、Buy for meが日本に来るかどうかと独立して価値があります。在庫精度は不承認率を下げ、返品ポリシーの明示は購入判断を後押しします。エージェント対応という名目で、通常のショッピング運用の基礎体力を上げる。順番としては、これが現実的でした。

よくある質問

Buy for meは日本でいつ使えるようになりますか

日本での提供時期は、2026年8月3日時点で発表されていません。Google Payヘルプは提供範囲を「米国、英語、Google Payを受け付ける一部加盟店」と明記しています。カナダ・オーストラリア・英国への拡大は2026年内という報道がありますが、日本は要確認です。

楽天市場やAmazonの出店者でも準備できることはありますか

はい、あります。ただし触れる範囲は限られます。商品名・価格・在庫数・出荷設定はRMSやセラーセントラルから操作できますが、Merchant Centerの返品ポリシーやフィード設計はモール側の管轄です。自社ドメインのECを1本持つかが実質的な分かれ目になります。

在庫と価格と返品のうち、1つだけ直すならどれですか

在庫です。在庫切れは注文を即座に不成立にするうえ、その失敗が店舗側の管理画面に記録として残りません。価格は値上がり方向のみ、返品は購入後の話ですが、在庫だけは注文の入口そのものを閉じます。

クーポンやポイントで勝負している商品はどうすればいいですか

エージェント経由では不利になると考えるのが安全です。Google Payヘルプは、現時点でプロモコードやロイヤルティ特典に対応していないと明記しています。表示価格そのものの競争力を、クーポンを外した状態で一度確認してください。

Merchant Centerの自動更新をオンにしておけばフィードは適当でいいですか

いいえ、想定外の使い方です。ヘルプは自動更新を、定期的な商品データ更新の代替ではなく一部商品の一時的なズレを直す機能だと明記しています。頻繁に価格や在庫が変わるならMerchant APIでのスケジュール投入を検討するよう案内されています。

返品ポリシーはサイトに書いてあれば登録しなくてもいいですか

登録したほうが有利です。未登録でもGoogleがサイトから推定して表示することがありますが、その場合は「ほとんどの商品について」という但し書きが付きます。自分で登録して検証を通せば但し書きは外れ、商品ごとの例外もラベルで指定できます。

エージェント経由の注文かどうかは店舗側で判別できますか

2026年8月3日時点では、明確な判別方法を公開情報から確認できておらず、要確認です。Google Payヘルプは購入結果をメールと通知で買い手に伝えるとしていますが、加盟店側の注文データにエージェント由来のフラグが立つかは記載がありません。

著者：齋藤竹紘（株式会社オルセル編集長／5,000社以上のEC支援実績／書籍3冊）

参考文献

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）

齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。齋藤竹紘のすべての投稿を表示