Google Merchant Centerの商品フィード完全ガイド｜必須属性・登録・診断・更新

この記事の要点

• Merchant Centerの商品フィードは、Googleが商品を理解し、Shopping広告、P-MAX、無料リスティングなどに利用する商品データです。
• 登録時は必須属性だけでなく、価格・在庫とランディングページの一致、GTINなどの商品識別子、画像品質まで確認します。
• 2026年4月14日に商品データ仕様が更新され、video_linkや配送関連属性が追加されました。
• 2027年1月31日から、商品画像は原則500×500ピクセル以上の新しい最低要件が適用されます。
• 運用ではNeeds attention、商品承認数、価格/在庫不一致、更新遅延を定期確認します。

Google Merchant Centerの商品フィードとは何か

Google Merchant Centerの商品フィードは、商品ID、タイトル、説明、価格、在庫、画像、ブランド、GTINなどの商品情報をGoogleへ提供する商品データです。Merchant Centerに登録された商品データは、Shopping広告、P-MAX、無料リスティングなど複数の表示機会で使われます。

Googleは商品データ仕様を毎年更新しており、属性の必須条件や推奨条件、画像要件も変わります。フィードを一度作って終える運用ではなく、商品マスターとGoogle仕様の両方を継続管理します。

商品データで最初に確認する属性

Googleの商品データ仕様は商品や対象国で条件が変わりますが、実務では次の項目から確認します。

項目	主な意味	確認ポイント
id	商品識別	後から不用意に変更しない
title	商品名	実商品を正確に表す
description	商品説明	商品特徴、仕様を具体化
link	商品ページURL	商品ごとに正しいURL
image_link	メイン画像	取得可否、画質、要件
price	通常価格	サイト表示と一致
availability	在庫	実在庫と同期
brand	ブランド	実商品と一致
gtin	GTIN	メーカー割当値を使う
mpn	MPN	メーカー品番を使う
product_type	自社分類	レポートや入札整理に使える

Googleは固有商品IDについて、GTIN、MPN、ブランドを正しく提供し、推測した値や類似商品の値を使わないよう案内しています。GTINが割り当てられている商品で未登録の場合、表示機会が制限される可能性があります。

商品フィードの登録方式

Merchant Centerでは、ファイル、スプレッドシート、サイト連携、APIなど複数のデータソースが使われます。選定時は「作りやすさ」より更新要件を先に決めます。

価格と在庫が1日に何度も変わる大規模ECで、手作業CSVを日次アップロードすると鮮度が足りない場合があります。一方、商品数が少なく固定情報が中心なら、複雑なAPIを作る必要はありません。

データフィードの作り方ではCSV、XML、API連携を比較しています。

商品IDの設計

IDは商品を追跡するキーです。SKU単位、親商品単位、販売単位のどれを使うかを商品マスター設計と合わせます。

色やサイズ違いで価格、在庫、GTINが変わる場合は、バリエーションごとに個別IDを持たせるのが基本です。サイトリニューアルや商品マスター変更でIDを差し替えると、Google側では新しい商品として扱われる可能性があります。

商品IDは広告運用だけでなく、データ分析やタグ計測との連携にも影響します。変更が必要なときは、旧IDと新IDの対応表を作り、配信への影響を確認します。

タイトルと説明をどう作るか

Googleはtitle属性を商品識別に使い、具体的で正確なタイトルを推奨しています。タイトルを生成AIで作る場合はstructured_title属性に関する公式ルールも確認します。

商品説明では、サイズ、素材、対象年齢、機能、仕様、視覚的特徴など、商品に関係する情報を具体的に書きます。キーワードの詰め込みやキャンペーン文言だけの説明は避けます。

タイトルと説明は検索語句との関連だけでなく、Google側の商品理解にも使われます。商品フィード最適化の基本と第11週以降の属性別記事で改善方法を分けて扱います。

商品画像の要件と2027年変更

image_linkは各商品で必須のメイン画像URLです。追加画像はadditional_image_linkで送ります。

Googleは2026年4月14日に、2027年1月31日からimage_linkとadditional_image_linkの最低解像度を全商品カテゴリ・マーケティング手法で500×500ピクセルへ引き上げると発表しました。2026年4月14日から対象画像への警告も開始しています。

Googleはすべてのリスティング形式でのパフォーマンス確保のため1,500×1,500ピクセル以上を推奨しています。最低要件を満たすだけで終わらず、商品が明確に見える画像を用意します。

2026年の商品データ仕様変更

Googleが2026年4月14日に発表した主な変更には、配送関連属性とvideo_linkが含まれます。

新しいhandling_cutoff_timeは注文処理の締め切り時間、minimum_order_valueは配送に必要な最低注文額を商品単位で扱うための属性です。shipping属性にはポイントプログラム関連ラベルのサブ属性も追加されました。

video_linkは商品動画URLを登録する任意属性です。2026年4月14日から技術検証が始まり、6月30日から配信対象化とポリシー/品質チェックが開始されています。動画に問題があっても、そのエラーだけで関連商品全体の配信が停止する仕様ではないとGoogleは説明しています。

GTIN、MPN、ブランドの扱い

GTINは国際的に商品を識別する番号で、日本ではJANとして見慣れた形式があります。GoogleはGTINが割り当てられている商品について正しい値の提供を強く推奨しています。

GTINがない商品もあります。ハンドメイド、オリジナル商品、ビンテージ品などが例です。その場合、存在しないGTINを作って登録してはいけません。商品に割り当て済みの識別子があるかを確認し、公式のUPIガイドラインに沿ってbrand、mpn、identifier_existsを扱います。

誤登録で多いのは、社内SKUをGTIN欄へ入れる、類似商品のGTINを流用する、親商品と子バリエーションで同じGTINを使うケースです。

product_typeとGoogle商品カテゴリ

product_typeは広告主が持つ自社分類です。Googleは最大5個まで送信でき、Google AdsのShoppingキャンペーンでは最初の値が入札やレポート整理に使われると説明しています。

google_product_categoryはGoogle側の分類です。Googleは商品を自動分類し、広告主による上書きは特定ケースで使います。自社カテゴリをそのままGoogle商品カテゴリへコピーする運用は適切ではありません。

第15週のproduct_typeとGoogle商品カテゴリの違いで分類設計を詳しく扱います。

価格と在庫の一致

商品フィードのpriceとavailabilityは、ランディングページと一致させます。価格変更がサイトへ先に反映され、フィード更新が遅れると価格不一致が発生します。逆にフィードだけ先に値下げし、サイト側の表示が旧価格のままでも問題になります。

在庫も同じです。欠品商品をin_stockのまま送信すると、広告クリック後に購入できません。価格と在庫は商品説明より高頻度で変わるため、更新経路を分ける判断もあります。

Needs attentionの確認

運用開始後はMerchant CenterのNeeds attentionを定期確認します。商品単位のエラー、警告、ポリシー問題を「件数」だけで見ず、売上影響の大きい商品から優先します。

例えば主力商品の画像取得エラーが10件と、休眠商品のタイトル警告100件では、前者を先に直す判断があります。商品数の多いECでは、承認率だけでなく対象SKUの売上構成も合わせて見ます。

更新失敗を検知する

自動更新を組んでも、失敗を検知できなければ手作業より危険です。日次更新が3日止まっていても担当者が気づかない状態を避けます。

最低限、最終成功時刻、送信件数、エラー件数、承認商品数を記録し、一定条件を超えたら通知します。例えば送信件数が前日比で大きく減った、更新が予定時刻から2時間以上遅れた、主力カテゴリの承認率が低下した、といった条件です。

P-MAXで商品フィードを使う場合

GoogleはMerchant Centerフィードを使うP-MAXについて、商品説明と画像を充実させ、価格や在庫が頻繁に変わる場合は更新し、Product issues列で不足属性や問題商品を確認するよう案内しています。

また、オンライン販売目標では商品フィードが広告生成の出発点になる一方、テキスト、画像、動画アセットも追加することを強く推奨しています。商品フィードだけに任せる運用と、アセットを組み合わせる運用を分けて考えます。

P-MAXと商品フィードで改善ポイントを整理しています。

初回登録から運用までの手順

1. 商品マスターのID、価格、在庫、画像、URLを確認する
2. 対象国と掲載方法に必要な属性を公式仕様で確認する
3. データソース方式を決める
4. 商品IDの一意性を確認する
5. タイトル、説明、ブランド、GTINを整える
6. 画像要件を確認する
7. Merchant Centerへ登録する
8. Needs attentionを確認する
9. 価格、在庫、URLの一致を確認する
10. 更新頻度と通知条件を決める
11. P-MAXやShopping広告と接続する
12. 変更ログを残しながら属性改善を行う

実務チェックリスト

• IDが重複していない
• titleが商品を正確に説明している
• descriptionに仕様情報がある
• linkが正しい商品ページを開く
• image_linkが外部取得できる
• 2027年1月31日の500×500px要件対象を抽出済み
• priceがサイト価格と一致する
• availabilityが在庫と一致する
• GTINを推測で補完していない
• brandとmpnが商品情報と一致する
• product_typeが自社の分析粒度に合う
• 更新失敗時に通知できる
• Needs attentionを定期確認する担当が決まっている
• 仕様変更の確認日を記録している

公式情報と更新時点

最終確認日: 2026年8月29日。

• 2026年商品データ仕様更新
• image_link
• 固有商品ID
• GTIN
• product_type
• Google商品カテゴリ

Googleの商品データ仕様は対象国、商品カテゴリ、掲載方法で条件が変わります。実装時は対象商品の公式仕様を再確認してください。

Merchant Centerのデータソース変更時に確認すること

CSVからAPI、ECプラットフォーム連携から独自フィードなど、データソース方式を変更する場合は、同じ商品IDを維持できるかを最初に確認します。

方式変更で商品IDまで変わると、Google側では別商品として扱われる可能性があります。切替前後で商品件数、ID、価格、在庫、画像URL、GTINを比較します。

切替日は旧データソースと新データソースが二重に商品を登録しないよう、優先順位や停止時刻を決めます。

自動更新と補助データの優先順位

Merchant Centerでは、主データソース以外の情報で商品データが補われるケースがあります。自社側で複数経路から値を送る場合、どの経路が最終値になるかを把握します。

価格だけAPI、その他属性はファイルという構成なら、価格更新失敗時にファイル側の古い値が残るのか、商品がエラーになるのかをテストします。

商品登録前に100件サンプル監査を行う

数万SKUを一括登録する前に、代表100件程度を選ぶと初期不具合を見つけやすくなります。

代表商品には、通常商品、セール商品、在庫切れ、予約商品、バリエーション、GTINあり、GTINなし、追加画像あり、高価格商品を含めます。

確認するのは次です。

• IDの一意性
• タイトルの実商品一致
• descriptionの欠損
• linkの遷移
• image_linkの取得
• priceの税込/税別
• availabilityの実在庫一致
• GTIN/MPN/brand
• product_type

100件で問題が見つかったら、全件登録前に変換ルールへ戻します。

Merchant Centerの問題を影響額で並べる

Needs attentionには複数の問題が並びます。件数だけで対応すると、売上影響が小さい警告に時間を使うことがあります。

対応表へ、問題種別、対象SKU数、対象売上、広告費、緊急度を追加します。

例えば画像警告1,000件でも売上寄与が小さい商品中心なら、主力50SKUの価格不一致を先に直します。2027年画像要件のように期限がある項目は、売上影響と期限の両方で優先順位を付けます。

2027年画像要件の移行計画

2026年中に次の工程で進めると、施行直前の差替え集中を避けられます。

1. 500×500px未満の商品抽出
2. 売上上位順に並べる
3. 元画像の有無を確認
4. リサイズで対応可能か、撮影/制作が必要か判定
5. 新画像URLを登録
6. Merchant Centerで反映確認
7. 2027年1月に再監査

Googleが一部画像を最適化して要件を満たす場合があるとしても、自社で高品質画像を持てる商品は差替えた方が管理しやすくなります。

Merchant CenterとECサイトを定期照合する

商品フィードの品質確認では、媒体内の値だけでなく商品ページと突合します。

日次で全商品を照合するのが難しい場合、売上上位や更新頻度の高い商品を自動サンプリングします。価格、在庫、商品名、画像、URLを比較し、不一致率を記録します。

運用体制の引き継ぎ項目

担当者が変わっても運用できるよう、次を文書化します。

• データソースの場所
• 生成バッチの時刻
• API認証情報の管理場所
• 商品ID規則
• 価格/在庫の正データ元
• 変換ルール
• エラー通知先
• Needs attention確認手順
• 仕様更新の確認日

Merchant Centerは広告担当だけでなく、ECと開発の連携点です。担当者交代時にこの情報が欠けると、更新停止の発見が遅れます。

商品データの検証を自動化する

数万SKUを人が目視するのは現実的ではありません。送信前に機械的な検証を入れます。

• id空欄、重複
• title空欄、文字数超過
• description空欄
• price異常値
• availability許可値外
• URL形式エラー
• 画像URLのHTTPエラー
• GTIN形式エラー
• 商品件数の前日差

検証エラーは「送信停止」と「警告」に分けます。ID重複や価格ゼロは送信停止、説明文が短いなどは警告として継続可能にするなど、影響度で分けます。

Merchant Centerの変更ログを残す

商品データとキャンペーンの変更を同じ日付で追えるようにします。

例:

日付	対象	変更	SKU数	担当
9/1	title	ブランドを先頭へ	120	EC
9/5	image	追加画像2点	80	制作
9/10	GTIN	欠損補完	350	商品
9/15	P-MAX	予算変更	-	広告

成果変化の原因を後から追いやすくなります。

無料リスティングも同じ商品データを使う

Merchant Centerの商品データは広告だけでなく無料リスティングでも使われます。広告を停止している期間でも、商品データの品質管理には意味があります。

商品フィードの改善を広告部門だけの作業にせず、ECの商品情報品質として管理すると、複数のGoogle面で再利用できます。

商品属性の欠損率をカテゴリ別に見る

全体のGTIN欠損率が10%でも、家電0%、自社ブランド80%なら対応はカテゴリ別に違います。

title、description、GTIN、brand、image、product_typeの欠損率をカテゴリ別に出し、どのカテゴリの登録フローに問題があるかを確認します。

仕様更新の月次確認

Googleは商品データ仕様を継続更新します。月1回、公式ヘルプの更新有無を確認し、影響属性と対応期限を台帳へ記録します。

変更を見つけたら、対象SKU数、システム改修有無、制作工数、施行日を整理します。2027年画像要件のように長い移行期間がある項目は、早めに制作計画へ入れます。

Merchant Centerの権限管理

商品データの修正、広告連携、アカウント設定を誰でも触れる状態にすると事故が起きやすくなります。担当者ごとに必要な権限を分け、退職・異動時の削除手順を用意します。

外部支援会社へ権限を渡す場合も、商品データの正データ元やAPI認証情報まで共有する必要があるかを分けます。

商品データ変更のリリース手順

変換ルールを変更するときは、開発環境または少数SKUで確認し、全件反映前に差分をレビューします。

例えばタイトル生成ルール変更なら、旧タイトルと新タイトルを100SKU程度比較し、欠損、文字数、禁止文言、型番消失がないか確認します。

大量不承認が出たときの対応

商品件数が急減した場合、個別商品を直す前に共通原因を探します。

• 価格フォーマット変更
• 在庫値変換ミス
• 画像CDN障害
• URLドメイン変更
• GTIN列ずれ
• 文字コード変更

共通原因なら1件ずつ修正せず、フィード生成処理を戻します。直前の正常ファイルを保存しておくと比較できます。

Merchant CenterとP-MAXの担当境界

Merchant Center側は商品データ品質、P-MAX側は予算、入札、アセット、コンバージョン設定が中心です。

同じ担当者が両方を見る場合でも、変更ログを分けます。商品フィード修正と目標ROAS変更が同時に行われると、成果変化の原因が追えません。

初回公開前の承認基準

本番広告へ接続する前に、社内で承認基準を決めます。

例として、売上上位商品の不承認0、価格不一致0、在庫不一致0、画像取得エラー0、更新テスト3回連続成功などです。数値は自社の運用基準として決めます。

この基準を満たしてから広告配信へ進むと、P-MAX側の問題とMerchant Center側の問題を分けて評価できます。

商品マスター側へ戻す改善

Merchant Centerで同じ警告を何度も直す場合、商品登録フローを変えます。GTIN欠損、低解像度画像、カテゴリ空欄、ブランド表記揺れなどは、フィード送信前に検出できる項目です。

広告運用担当が毎回補完する状態を減らすほど、媒体追加や担当者変更に強くなります。

定期監査の頻度

価格・在庫は日次、承認状況は週次、属性品質と仕様更新は月次というように確認頻度を分けます。すべてを毎日人が見る必要はなく、異常値だけ通知する構成へ寄せます。

監査結果は月次で残し、前月から悪化した項目を優先修正します。