WEBサイトMerchant Centerの自動更新は、価格や在庫が1日に2回以上など頻繁に変わる商品では働かないことがあり、ずれを検出すると不承認になることがある ── 商品ページと商品データの価格・在庫がそろっているか確認する13項目（2026年10月時点）
Merchant Centerの自動更新は、価格や在庫が1日に2回以上など頻繁に変わる商品では働かないことがあり、ずれを検出すると不承認になることがある ── 商品ページと商品データの価格・在庫がそろっているか確認する13項目（2026年10月時点）
目次
01 公式ヘルプの本文は、「頻繁な変更」「不承認」「更新の停止」の3点を書いている
2026年10月11日に確認した本文
Googleの Merchant Center ヘルプに、「Allow Merchant Center to update product information automatically」（商品情報の自動更新を許可する）というページがある。ページには更新日の記載がない。そのため本記事は、2026年10月11日に確認した本文を根拠にして書く。いつ書き足された文なのかは、この記事では扱わない。
ページが説明しているのは、商品ページ（ランディングページ）に載っている情報を使って、Merchant Center の商品データを自動で直す機能だ。ヘルプの英語表記は Automations で、本記事では「自動更新」と呼ぶ。ページによると、自動更新はショッピング広告と無料リスティングの商品を、構造化データやそのほかの情報源をもとに更新する。商品ページに4ドルではなく3ドルと書いてあれば、商品データが4ドルでも3ドルに更新される、という例が載っている。
自動更新が扱う項目は4つ
ヘルプには、自動更新が使える属性として、価格、セール価格、在庫状況、状態の4つが挙がっている。構造化データでは、次の表のように対応する。この表は、ヘルプの書式の説明を並べ直したものだ。
| Merchant Center の項目 | 構造化データの項目（schema.org） | 値の対応 |
|---|---|---|
| 価格 [price] | price と priceCurrency | 価格は数字だけ（通貨記号や桁区切りを付けない）。通貨は3文字のコード（例: JPY） |
| 在庫状況 [availability] | availability | 在庫あり [in_stock] は InStock・LimitedAvailability・OnlineOnly。在庫なし [out_of_stock] は OutOfStock・SoldOut・Discontinued・InStoreOnly。予約 [preorder] は PreOrder・PreSale |
| 状態 [condition] | itemCondition | 新品は NewCondition、再生品は RefurbishedCondition、中古は UsedCondition |
| セール価格 [sale_price] | Merchant listing の価格の書き方（打ち消し線価格の指定を含む） | 現在の価格を主にして、元の価格を別に指定する（03章の用語で扱う） |
本題の3つの文
この記事の中心は、ヘルプの注意書きにある3つの文だ。原文のまま引く。
Automations may not work for products with frequent price or availability value changes (for example more than once per day).
（訳: 価格や在庫の値が頻繁に変わる商品（たとえば1日に2回以上）では、自動更新が働かないことがある。）
The product may be disapproved instead of updated if we detect a mismatch.
（訳: ずれを検出したとき、商品は更新されずに不承認になることがある。）
We may also stop updates if the total number of detected mismatches becomes too large.
（訳: 検出したずれの合計が多くなりすぎると、更新そのものを止めることもある。）
どの文も、「may（〜ことがある）」で書かれている。必ず不承認になるとは書いていない。「1日に2回以上」も「for example（たとえば）」の例であって、境目の線として示された数字ではない。「多くなりすぎる」が何件のことかは、ヘルプに書かれていない。本記事は、この3つの文を、自社の商品ページと商品データを並べて確かめる手順に変える。
二重線の価格が複数あるページ
ヘルプはもう1つ、価格の自動更新を勧めない場合を書いている。
If product pages show multiple strikethrough prices, our system may not be able to accurately find the correct strikethrough price.
（訳: 商品ページに打ち消し線の価格が複数出ていると、システムが正しい打ち消し線価格を正確に見つけられないことがある。）
You shouldn't enable automatic updates for price in this case.
（訳: この場合、価格の自動更新を有効にするべきではない。）
打ち消し線の価格とは、セール前の元の価格を横線で消して見せる表示のことだ。価格の自動更新は、この打ち消し線の価格も更新することがある、とヘルプは書いている。ページに2本以上の横線の価格が出ているなら、それは価格の自動更新をオフにする側の事情になる。
公式情報
ここまでの引用と数値は、2026年10月11日にAllow Merchant Center to update product information automatically（Merchant Center ヘルプ）の本文を取り直して確かめたものだ。ページに更新日の記載はない。引用した英文は、本文から1文字ずつ照らして写している。
02 なぜ・背景
自動更新は、小さなずれを直すための仕組みだ
ヘルプは、自動更新の位置づけを2文で書いている。
Automations aren't a replacement for regular updates of your product data.
（訳: 自動更新は、商品データの通常の更新の代わりにはならない。）
続けて、自動更新は「価格・在庫・状態の正確さについて、商品の一部（small percentage）に起きる、散発的な問題」を直すための機能だと書いている。つまり、商品データを日常的に更新する仕組みが別にあることが前提だ。自動更新に任せきりにすると、その前提がなくなる。
頻繁に変わる商品には、別の方法が指定されている
価格や在庫が頻繁に変わる商品について、ヘルプの案内ははっきりしている。
If you expect the pricing, availability, and condition of your products to update frequently, you should use the Merchant API to manage product updates.
（訳: 商品の価格・在庫・状態が頻繁に更新される見込みなら、商品の更新の管理には Merchant API を使うべきだ。）
Merchant API は、商品データをプログラムから登録・更新するための窓口だ。ヘルプは、頻繁な変更は自動更新の守備範囲ではなく、商品データ側を更新する仕組みで受けるように、と書いている。
ずれが起きる場所は、ページ・構造化データ・商品データの3つ
ECサイトの価格と在庫は、3か所に書かれる。お客さんが見る画面、HTMLに入っている構造化データ、Merchant Center に登録した商品データだ。更新の担当者や頻度が違うと、時間差でずれる。たとえば、画面の価格だけを書き換えて、構造化データを直し忘れる。または、在庫が0になった画面は更新したのに、商品データの取り込みが翌日になる。こうしたずれが、頻繁に起きる商品では、見つかる回数も増える。
ヘルプは、商品ページの価格について、場所によって変えないことも求めている。
Don’t change the price of your product on your landing page based on a user’s location.
（訳: ユーザーの所在地に応じて、ランディングページの商品価格を変えない。）
これは価格のページの要件で、自動更新のページではない。画面の価格が見る人によって違うと、Google が読んだ値と、担当者が画面で見た値が食い違う。確かめるときは、ログインしていない状態の画面と、構造化データの値を比べるのが基本になる。
構造化データがなく、抽出もできないと、不承認の対象になる
自動更新は、構造化データがあれば、それを読む。ないときや不完全なときは、別の読み取りの仕組みで商品ページを読むと、FAQ に書かれている。
If the extractors are unable to determine price availability, or condition information, your products will be subject to product-level disapprovals.
（訳: 抽出の仕組みが価格・在庫・状態の情報を判別できないときは、その商品は商品単位の不承認の対象になる。）
この文でいう抽出の仕組みは、ヘルプでは「advanced data extractors」と呼ばれている。構造化データを整えておくことは、不承認を避ける入口にもなる。次の03章で、用語を整理する。
03 この記事に出てくる用語
自動更新（Automations）と、更新の設定
用語
自動更新（Automations）：商品ページの情報をもとに、Merchant Center の商品データの価格・在庫・状態を直す機能。ヘルプによると、初期状態でオンになっている。価格だけ、在庫だけ、状態だけ、またはその組み合わせを選んでオンオフできる。設定は、Merchant Center の「商品」から「Automations」のタブを開き、各項目の詳細で切り替える。
構造化データ
用語
構造化データ：ページに入れる、商品名・価格・在庫などの機械向けの注釈。Merchant Center のヘルプは、JSON-LD での記載を勧めている。値は、画面に見えている値と一致している必要がある。
打ち消し線価格
用語
打ち消し線価格：セール前の価格を、横線で消して見せる表示。ヘルプでは reference price、original price、previous price、regular price とも呼ばれる、と書かれている。構造化データでは、元の価格に priceType として StrikethroughPrice を指定する書き方がある。
不承認と、更新の停止
不承認は、その商品が広告や無料の掲載に使えなくなる状態を指す。更新の停止は、ずれが多すぎるときに、自動更新そのものが止められることを指す。どちらも、ヘルプに「may（ことがある）」で書かれている。不承認の有無は、Merchant Center の商品の問題を見る画面で確かめる（画面の名前は、アカウントの表示に合わせて読み替える）。
Merchant API
実務のヒント
Merchant API は、商品データを登録・更新するためのプログラム向けの窓口だ。Overview of Merchant API（Google for Developers）に概要がある。ECサイトのシステム会社に「商品データをいつ・どの方法で Merchant Center へ送っているか」と聞くと、1行で答えが返ることが多い。その答えが「1日1回のファイル取り込み」なら、1日に2回以上変わる商品とは、更新の速さが合っていない。
04 画面・構造化データ・商品データの3つを並べて確かめる
適用範囲 ── 価格・在庫・状態を扱う商品に当てはまる
このテーマが当てはまるのは、Merchant Center にショッピング広告または無料リスティング用の商品データを登録している会社だ。自動更新の初期設定がオンのままなら、気づかないうちに、自動更新の対象になっている。広告の担当者が代理店で、サイトの担当者が別の制作会社、という体制でも当てはまる。
この記事が確かめていないこと
この記事は、ヘルプの本文を読んだだけで、実際の Merchant Center アカウントで試していない。次のことは、分からない。
- 「1日に2回以上」の変更で、自社の商品が実際に不承認になるか
- 「ずれの合計が多くなりすぎる」が、何件、何割のことか
- ずれを検出する頻度や、不承認になるまでの時間
この3つは、自社のアカウントの診断画面でしか分からない。05章のチェックリストは、見えるものを見える形に並べるためのものだ。
手順1 ── 自動更新の設定を書き写す
最初に、いまの設定を確かめる。Merchant Center で「商品」を開き、「Automations」のタブから、価格・在庫・状態それぞれの詳細を開く。ヘルプによると、画面は、価格、在庫、状態、画像の改善の更新を切り替える形になっている。日本語の画面では名称が違うことがあるため、見つからないときはヘルプの日本語版で確かめる。オンになっている項目を、メモに書き写す。
手順2 ── 1日に2回以上変わる商品を洗い出す
次に、直近7日間で価格や在庫が変わった商品を、管理画面の変更履歴から書き出す。その中で、同じ日に2回以上変わった商品に印を付ける。履歴がないときは、ECの担当者に「タイムセールや在庫連動で、1日に2回以上変わる商品はどれか」と聞く。印の付いた商品が、ヘルプの1つ目の文の対象になりうる商品だ。
手順3 ── 3つを並べて、1商品ずつ照らす
印の付いた商品から3つ選び、画面の価格と在庫、構造化データの値、Merchant Center の商品データの値を、1枚の表に並べる。構造化データは、ブラウザの「ページのソースを表示」で、読み込み直後のHTMLを開いて探す。次の表は、書き方の見本だ。数字は架空の商品の例で、実在のデータではない。
| 商品 | 画面の価格・在庫 | 構造化データ | Merchant Center の商品データ | 判定 |
|---|---|---|---|---|
| 商品A（架空） | 3,980円・在庫あり | price 3980・InStock | 3980 JPY・in_stock | そろっている |
| 商品B（架空） | 2,480円・売り切れ | price 2480・InStock | 2480 JPY・in_stock | 構造化データと商品データが画面とずれている |
| 商品C（架空） | 1,500円（元は2,000円） | price 2000 | 2000 JPY | セール価格が構造化データにない |
判定の欄は、3つが同じなら「そろっている」、1つでも違うなら、どれが違うかを書く。ヘルプは、構造化データについて次のように書いている。
Structured data must match the values that are shown to the user.
（訳: 構造化データは、ユーザーに表示される値と一致していなければならない。）
手順4 ── 構造化データの置き方を確かめる
構造化データには、置き方の条件がある。Merchant Center のヘルプは、Google のクロールが商品データと照合できるための条件として、次の点を挙げている。
Structured data markup must be present in the HTML returned from the web server. The structured data markup can’t be generated with JavaScript after the page has loaded.
（訳: 構造化データは、ウェブサーバーが返すHTMLの中になければならない。ページが読み込まれたあとに、JavaScriptで生成することはできない。）
確かめ方は簡単だ。ブラウザで「ページのソースを表示」を開く。表示されるのは、サーバーが返した直後のHTMLだ。そこに application/ld+json の script があり、価格と在庫の値が入っていれば、条件を満たしている。開発者ツールのElementsでは見えるのに、ソース表示では見えない場合は、JavaScriptで作っている可能性がある。JavaScriptで描画するページの読まれ方は、JavaScriptで描画したページはいつ読まれるのか ── レンダリングキューの仕組みと、確認する14項目に書いた。
同じヘルプには、1ページに複数の商品がある場合の条件もある。1ページに複数のオファーがあるときは、それぞれのオファーにSKUかGTINを付け、Merchant Center 側の商品の同じ識別子と合わせる、という内容だ。ヘルプは、構造化データを検証するツールとして、リッチリザルト テストと Search Console を挙げている。
Google検索側の書き方は、Merchant listing の構造化データ（Google Search Central）とProduct snippet の構造化データに分かれている。前者の本文（最終更新は2026-09-08 UTC）には、現在の価格に加えて、元の価格を別に書き、その元の価格に priceType として StrikethroughPrice を指定する例がある。在庫の値の一覧は、ItemAvailability（schema.org）で確かめられる。
注意
構造化データの値を直すだけでは足りない場合がある。ヘルプは、ページの内容、価格を含めて、IPアドレスやブラウザの種類のようなユーザーの情報で動的に変えないことも、条件に挙げている。確かめるときは、ログインしていない状態で、普段と違うブラウザでも画面を開いて、値が同じかを見る。
構造化データの値を確かめるときに使える、当サイトの無料ツール
構造化データの書き方で迷うときは、🔧 【SEO】WEBサイト・構造化データ 自動作成ツール（たたきファイルね） ★コウゾウで、JSON-LDのたたきを作れる。ページ全体の項目を、ひと続きに点検したいときは、🔧 【SEO/UX】WEBサイト総合分析・レポートツールを使える。どちらも、商品ページの価格や在庫の値を、Merchant Center の値と照らす代わりにはならない。照らす材料を、手元にそろえるための道具だ。
05 画面・構造化データ・商品データをそろえるチェックリスト
このチェックリストの使い方
以下は、01章から04章を、実際に手を動かして確かめるための13項目だ。前半は自動更新の設定と、頻繁に変わる商品の洗い出し。中盤は3つの値の照合。後半は二重線の価格、構造化データの置き方、診断画面の確認、担当者の整理になっている。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。
- Merchant Center で「商品」から「Automations」のタブを開き、価格・在庫・状態それぞれのオンオフを、メモに3行で書き写す
- 直近7日間に価格か在庫が変わった商品を、管理画面の変更履歴から10点、商品名で書き出す
- 書き出した10点の中で、同じ日に2回以上変わった商品に印を付け、その数を数えて書く
- 印の付いた商品について、商品データの更新方法（ファイルの取り込みの頻度、または Merchant API）を、担当者に聞いて1行で書く
- 印の付いた商品から3つ選び、ログインしていない状態で商品ページを開いて、画面の価格と在庫の表示を書き写す
- 同じ3ページで「ページのソースを表示」を開き、price と priceCurrency と availability の値を探して書き写す
- 同じ3つの商品について、Merchant Center の商品データの価格と在庫の値を書き写し、画面・構造化データ・商品データを1枚の表に並べる
- 表の各行について、3つがそろっているか、ずれているかを書き、ずれている行はどの列が違うかを添える
- 在庫の表示（在庫あり・売り切れ・予約）と availability の値が、ヘルプの対応表（InStock、OutOfStock、PreOrder など）に合っているかを、3商品で確かめる
- 打ち消し線の価格が出ているページを探し、1ページに何本あるかを数えて、2本以上のページ名を書く
- 二重線の価格があるページで、構造化データに priceType の StrikethroughPrice があるかを探し、あるか・ないかを書く
- ソース表示で、application/ld+json の script が読み込み直後のHTMLにあることを、3ページで確かめる
- Merchant Center の商品の問題を一覧にした画面を開き、価格と在庫に関わる問題の件数を、それぞれ書く。あわせて、ページの表示・構造化データ・商品データの更新・Merchant Center の設定の4つの担当者の名前を書き出す
所要時間の目安と、手を付ける順番
1番目から4番目は、画面の確認と担当者への質問で、合わせて20分ほどだ。5番目から9番目は、3商品の値を写して表にする作業で、30分ほどかかる。10番目から12番目は、二重線の価格と構造化データの置き方の確認で、15分ほど。13番目は、診断画面の確認と担当者の整理で、10分ほどだ。全体で1時間半が目安になる。時間がないときは、1番目、10番目、13番目の3つを先に行う。この3つは、ほかの項目の結果がなくても進められる。自動更新の設定、打ち消し線の価格が複数あるページ、診断画面の問題の件数と担当者が分かる。
実務のヒント
13番目の「4つの担当者の名前」は、確認の中でいちばん後回しにされやすい。ずれが見つかったとき、誰に何を直してもらうかが決まっていないと、見つけたことが止まってしまう。06章の最後に、聞く相手の整理を書いた。
06 代替・ほかの選択肢の比較
頻繁に変わる商品の更新方法は、4つから選べる
ヘルプの記述をもとに、頻繁に変わる商品の扱い方を並べると、次の表のようになる。ヘルプが述べているのは、1つ目の限界、2つ目の勧め、4つ目の注意だ。3つ目は、自社の状況に応じて選ぶ方法として、この記事の整理で並べた。
| 方法 | 向いている場合 | 分からないこと・注意 |
|---|---|---|
| 自動更新に任せる | たまに起きる小さなずれを直したい。変更の頻度が低い | 1日に2回以上など頻繁に変わる商品では、働かないことがある。ずれを検出すると不承認になることがある |
| Merchant API で商品データを更新する | 価格・在庫が頻繁に変わる。ヘルプが勧めている方法 | ECシステム側での対応が要る。更新の頻度や連携の方法は、システム会社に確認する |
| 商品データのファイルの取り込みを、頻繁に回す | APIの対応が難しく、ファイルでの運用を続けたい | 取り込みの間隔の最短は、アカウントの設定で確かめる。ヘルプの本文では確認していない |
| 価格の自動更新だけをオフにする | 二重線の価格が複数出るページがある。ヘルプが「価格の自動更新を有効にするべきではない」と書いている場合 | ほかの項目（在庫・状態）の自動更新は、別に切り替えられる。オフにしたあとは、商品データ側で価格を正しく保つ必要がある |
どの方法を選んでも、先に決めることは同じ
表のどの行を選んでも、先に決めることは変わらない。画面の価格と、構造化データの価格を、同じ場所から出すことだ。画面だけを手で書き換える運用では、構造化データがずれる。ヘルプは、セール価格について次のように書いている。
Clearly display both non-sale and sale prices on your landing pages, and only the sale price at checkout.
（訳: ランディングページでは、セール前の価格とセール価格の両方をはっきり表示し、チェックアウトではセール価格だけを表示する。）
セール価格を使う場合、自動更新のヘルプは、セールの有効期間を sale_price_effective_date で正しく指定し、タイムゾーンも合っていることを、勧めている。期間の書き方は、Sale price effective date（Merchant Center ヘルプ）で確かめられる。 また、価格が絶えず動く商品について、ヘルプは別のページで次の注意を書いている。
Don’t submit products with a price that constantly changes, such as auctions and prices based on a live currency exchange.
（訳: オークションや、為替レートにその場で連動する価格のように、絶えず変わる価格の商品は登録しない。）
これは価格のページの要件で、自動更新の注意とは別の文だ。ただ、「価格が絶えず動く」商品は、自動更新の注意書きの対象と重なる。該当する商品があれば、商品データに載せる方法そのものを、広告の担当者と相談する。
聞く相手を、3つに分ける
ECサイトの運営が複数の会社に分かれているとき、聞く相手を決めておくと、ずれが見つかった日のうちに話が進む。
システム会社には、画面の価格と構造化データの価格が同じ場所から出ているかを聞く。商品データの担当には、Merchant Center への送り方と頻度を聞く。広告の担当には、自動更新の設定と、診断画面の件数を聞く。1人が全部を兼ねている会社でも、この3つの質問は別々に書き出しておくと、見落としが減る。
07 当サイトで確かめたこと
当サイトでは確かめていない
当サイトはECサイトではなく、Merchant Center も使っていない。そのため、本記事の手順を当サイトに当てはめた結果は、書かない。この記事で確かめたのは、ヘルプの本文を取り直して、引用した文を原文と照らしたところまでだ。実際のアカウントで、1日に2回以上変わる商品が不承認になるかどうかは、試していない。
自社のアカウントで確かめる範囲
読者の側で確かめられるのは、05章の13項目だ。とくに7番目の表は、アカウントに入れる人なら、30分もあれば3商品分が埋まる。表が埋まった段階で、ずれがあるかどうかは、画面の上で分かる。不承認になるかどうかの判断は、その表とアカウントの診断画面を並べて、担当者と話す材料になる。
08 このテーマの、これまで
構造化データを確かめる前の考え方
構造化データが書かれていても、Googleが使うとは限らない。語が増えても使われない場合の確かめ方は、schema.orgに語が増えても、Googleが使うとは限らない ── 自社の構造化データを3つの段で確かめる13項目（2026年10月時点）に書いた。FAQやHow-toの構造化データが同じ時期に変わらなかったことは、FAQとHow-toのリッチリザルト廃止は、同じ時期の話ではなかった ── 自分のサイトの構造化データを確認する13項目（2026年9月時点）にまとめた。
在庫と価格を機械が読めるか
AIモードの見守り機能が、在庫・価格・営業時間の変化を追う、という話は、AIモードの見守り機能は全員向けに展開が始まった ── 在庫・価格・営業時間の変化を、機械が正しく読めるか確認する13項目（2026年9月時点）に書いた。画面の表示と、機械が読む値を揃えるという点は、本記事と同じ向きだ。商品やサービスのページが、長い質問に答えられるかを見る視点は、AI検索の質問は長くなった、と言われている ── 商品・サービスページが答えられるか確認する13項目（2026年9月時点）にある。
画面と、読まれる値の差
自動のスクリーンショットが、読者の画面と違って写る話は、「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数）に書いた。画面で見えているものと、機械が取る値が違うことは、商品ページでも同じように起きる。正しい構造化データの書き方を確かめる記録は、FAQPageスキーマが壊れていた — 確認したら気づいた3つのこと、当サイトの修正と展開の全記録（2026年6月）に残っている。
通知の確かめ方と、週次の点検
Search Console の通知を、読んだだけで終わらせず、毎週の点検にした記録は、Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日にある。診断画面の件数を定期的に見る習慣は、そこからつなげられる。ページの正規のURLや、sitemapなどの整合性を揃える考え方は、Google が求める 4 層整合性 — sitemap・canonical・内部リンク・末尾スラッシュを curl 3 行で揃えるに書いた。Search Console の基本の見方は、Search Consoleが教えてくれること — データを読む力がサイトを変えるにある。
現在の貴方のIPアドレス
このサイトで書いている人
