Merchant Center提案属性値レビューガイド｜推奨値の採否と巻き戻し手順
Merchant Centerの「注意が必要」タブを開くと、商品データの問題と並んで「推奨される属性値（Suggested attribute values）」というカードが表示されることがあります。Googleが商品ページや既存データをもとに属性の候補値を提示し、ボタン操作だけで不足や誤りを埋められる便利な機能ですが、提案をまとめて承認した結果、色やサイズ、性別などの値が実物と食い違い、広告の表示や絞り込み検索で不利になるケースも起こり得ます。
上位の解説記事の多くは、商品フィード最適化の総論や不承認対応の一般論の中でこの機能に軽く触れる程度にとどまり、「どの属性なら採用してよいのか」「承認後に元データとどちらが優先されるのか」「誤って承認した値をどう戻すのか」という運用判断までは整理されていません。現場で迷うのは、まさにこの採否の線引きと巻き戻しの部分です。
本記事では、Google Merchant Center ヘルプの[注意が必要] タブ、商品情報の編集、自動商品更新、属性ルールを設定するの各ページを一次情報として、推奨される属性値の仕組み、属性別の採否基準、承認前のレビュー手順、適用後の確認と巻き戻し、根本修正への落とし込みまでを実務目線で解説します。仕様はいずれも2026年10月時点で公式ヘルプから確認できた内容です。
この記事の要点
- 機能の位置づけ：推奨される属性値は「注意が必要」タブに課題カードとして表示され、「修正」から候補を個別に確認して承認する仕組み
- 最大の注意点：承認した値は商品エディタでの編集と同様に扱われ、その後にファイルなど別の方法で送った変更より優先される
- 採否の線引き：表記ゆれの補正は採用しやすく、色・サイズ・性別・年齢層・GTINなど商品の同一性に関わる属性は必ず人手で確認する
- 巻き戻し：適用済みの編集は商品詳細ページの「商品を編集」から確認・取り消しでき、件数が多い場合は承認前の抽出レビューが前提になる
- 根本修正：承認は応急処置と割り切り、同じ値を商品マスタや補助フィードへ反映して上書き状態を解消する
Merchant Centerの推奨される属性値の仕組み
推奨される属性値とは、Merchant Centerが商品データの不足や誤りを検出した際に、修正後の候補値をGoogle側から提示する機能です。公式ヘルプでは、商品データの属性値を修正するための手順を候補として提示するものと説明されており、候補がある場合は「注意が必要」ページに課題カードとして、候補の内容と対象商品数が表示されます。
この機能は、フィードを作り直さなくても管理画面上で問題を解消できる点に価値があります。一方で、提示される値はGoogleが推定した候補であり、自社の商品マスタと完全に一致する保証はありません。公式ヘルプも、承認前にランディングページのデータと照合して候補が正確であることを確認するよう明記しています。
表示される場所と操作の流れ
候補は管理画面の「商品」メニュー内にある「注意が必要」タブに表示されます。課題カードには「修正」「商品を表示」「詳細」といった操作が並び、「修正」を選ぶと推奨される属性値の一覧が開き、商品ごとに候補を確認して個別に承認できます。「商品を表示」では影響を受けている商品の一覧を、「詳細」では関連するヘルプ記事を確認できます。
承認すると候補値が商品に追加され、適用されたことが通知で知らされます。操作自体は数クリックで完了するため、担当者が忙しい時期ほど「とりあえず全部承認する」判断に流れがちです。後述するとおり、承認した値はフィードより優先される状態になるため、操作の手軽さと影響の大きさがつり合っていない点を最初に理解しておく必要があります。
自動修正や自動商品更新との違い
Merchant Centerには、推奨される属性値と似た「Googleが値を補う」機能がほかにも存在します。代表的なのが自動商品更新で、公式ヘルプによると、対象は価格、セール価格、在庫状況、状態の4属性に限られ、サイト上の構造化データなどをもとに広告と無料リスティングの表示を自動で更新します。こちらは原則として有効化された状態で動き、担当者が1件ずつ承認する仕組みではありません。
「注意が必要」タブには自動修正という項目もあり、データの誤りに対して継続的に適用される修正ルールとして案内されています。推奨される属性値は、担当者が候補を見て承認するまで反映されない点が大きな違いです。人の判断が介在する以上、承認した結果の責任も運用側が負うと考えておくと、レビューの重要性が明確になります。
| 機能 | 対象 | 反映のタイミング | 運用側の関与 |
|---|---|---|---|
| 推奨される属性値 | 候補が提示された属性（公式に対象一覧の記載なし） | 担当者が承認した時点 | 候補ごとに確認と承認が必要 |
| 自動商品更新 | 価格・セール価格・在庫状況・状態の4属性 | クロールで不一致を検出した時点 | 有効・無効の設定のみ |
| 自動修正 | 注意が必要タブで案内されるデータの誤り | 修正ルールとして継続適用 | 適用内容の確認 |
| 属性ルール | 任意の属性 | 適用を保存した時点 | ルールの作成・テスト・適用 |
なお、どの属性で候補が提示されるかについて、2026年10月時点の公式ヘルプには対象属性の一覧が示されていません。本記事で後述する属性別の採否基準は、表示された候補をどう扱うかという運用上の判断軸として整理したものであり、特定の属性に必ず候補が出るという意味ではない点にご注意ください。
候補値を承認したときに起きる上書きの仕組み
承認した候補値は、その後に別の方法で送った商品データより優先されます。これがこの機能で最も注意すべき仕様です。公式ヘルプでは、適用された修正は商品追加に使う別の方法で後から行った変更を上書きすると説明され、ファイルで商品をアップロードしている場合、商品エディタでの変更がファイル側の変更より優先されるという例が示されています。
商品エディタでの編集と同じ扱いになる
推奨される属性値の承認は、実質的に管理画面上で商品を手動編集したのと同じ状態を生みます。商品情報の編集に関する公式ヘルプでも、商品エディタはほかの方法で行った変更を上書きすると記載されています。つまり、承認後に基幹システムやカートの値を正しく直してフィードを更新しても、管理画面で承認した値が残り続ける可能性があるということです。
この挙動は、承認した値が正しい場合には便利に働きますが、誤った値を承認した場合には、フィード側の修正が反映されない原因として気づきにくい問題になります。「フィードを直したのに表示が変わらない」という相談の一因が、過去に承認した候補値の上書きであることは珍しくありません。担当者が交代した後に発覚すると、原因の特定に時間がかかります。
フィードや属性ルールとの関係を整理する
Merchant Centerでは、メインのデータソース、補助データソース、属性ルール、管理画面での編集という複数の経路から最終的な商品データが組み立てられます。属性ルールは複数設定した場合に上から順に処理される仕組みで、下書き保存、テスト、変更の適用という手順を踏んで反映されます。
一方で、属性ルールと管理画面での編集のどちらが最終的に優先されるかについて、2026年10月時点で確認した属性ルールの公式ヘルプには明確な記載がありません。そのため実務では、同じ属性に対して承認済みの候補値と属性ルールを重ねて設定しない運用が安全です。どちらで管理する属性なのかを決めておけば、優先関係を推測で判断する必要がなくなります。
上書きで起こりやすいトラブル
- フィード修正の不反映：商品マスタを直しても承認済みの値が残り、表示が変わらない
- セール後の値の固定：期間限定の情報をもとにした値が、終了後も残り続ける
- 担当交代後の原因不明化：誰がいつ承認したかの記録がなく、調査に時間がかかる
- ルールとの二重管理：同じ属性を属性ルールと承認値の両方で触り、最終値が読めなくなる
補助フィードで属性を補う設計については、以下の記事で詳しく解説しています。
採用してよい属性と人手確認が必要な属性の線引き
推奨される属性値は、誤っていたときの影響が小さい属性なら採用しやすく、商品の同一性や購入判断に直結する属性ほど人手確認が必須です。判断の軸は「その値が間違っていたら、ユーザーが別の商品を買ってしまうか」「広告の配信対象や表示条件が変わるか」の2点に集約できます。
そのまま採用しやすい属性の特徴
採用しやすいのは、値の候補が限られていて、ランディングページを見れば正誤がすぐに判断できる属性です。たとえば在庫状況や商品の状態のように、決められた値から選ぶ属性で、サイト上の表示と候補が一致しているなら、承認しても事故につながりにくいと考えられます。表記ゆれや形式の誤りを正しい形に整える候補も、内容自体が変わらないため比較的安全です。
ただし、採用しやすい属性であっても、承認前に数件はランディングページと照合する手順を省略しないことが大切です。サイトのテンプレートが商品カテゴリによって異なる場合、特定のカテゴリだけ誤った値を読み取っていることがあります。カテゴリ単位で最低限のサンプル確認を行い、問題がなければまとめて承認するという進め方が現実的です。
必ず人手で確認すべき属性の特徴
色、サイズ、性別、年齢層、素材、GTIN、ブランドなどは、商品の同一性やバリエーションの区別に関わる属性です。これらは誤った値が入ると、検索の絞り込みで別商品として表示されたり、比較の対象を取り違えられたりするため、候補が提示されても1件ずつ実物と照合する前提で扱います。とくにアパレルや化粧品のようにバリエーションが多い商材では、親商品の情報を子商品に誤って当てはめた候補が混ざりやすくなります。
GTINやブランドは、商品を世界共通の識別情報と結び付ける役割を持つため、誤登録の影響が長く残ります。自社で企画したオリジナル商品や、セット販売の商品に対して、他社の類似商品の識別情報が候補として提示される可能性もゼロではありません。識別子は商品マスタを正として扱い、管理画面の候補は参考情報にとどめるのが安全です。
| リスク区分 | 属性の例 | 推奨する扱い | 確認の単位 |
|---|---|---|---|
| 低 | 在庫状況・状態・表記ゆれの補正 | サンプル確認後にまとめて承認 | カテゴリごとに数件 |
| 中 | 商品カテゴリ・商品タイプ・素材 | カテゴリ単位で照合してから承認 | カテゴリごとに全体の一部を抽出 |
| 高 | 色・サイズ・性別・年齢層 | 1件ずつ実物と照合して承認 | 全件 |
| 最高 | GTIN・ブランド・MPN | 原則は商品マスタ側で修正し候補は参考扱い | 全件をマスタと照合 |
承認を見送るべきケース
候補の内容が正しく見えても、承認を見送った方がよいケースがあります。代表的なのは、近いうちに商品マスタの改修やフィードの作り直しを予定している場合です。管理画面で承認した値が残ると、改修後の正しい値が反映されない状態を自ら作ることになるため、改修の完了を待ってフィード側で直す方が後工程の手間が少なくなります。
また、期間限定の情報に基づく候補も見送りの対象です。セール中だけページに表示されている文言や、季節限定のパッケージ情報をもとにした値は、期間終了後に実態と合わなくなります。値が変わる可能性がある属性は、管理画面で固定せず、更新の仕組みを持つフィード側で管理するという原則を決めておくと判断がぶれません。
不承認の原因別の解消手順については、以下の記事で詳しく解説しています。
承認前に行うレビューの手順
承認前のレビューは、ランディングページとの照合、サンプルの抽出、判定記録の3つで構成するのが基本です。公式ヘルプが求めているのはランディングページとの照合ですが、運用を継続するには、誰がどの基準で承認したかを後から追える状態にしておくことも欠かせません。
ランディングページとの突き合わせ
照合で確認するのは、候補値がランディングページに実際に記載されている内容と一致しているかどうかです。商品名や説明文の中に候補の根拠となる記載があるか、バリエーションを選択したときに表示が切り替わる場合はその商品IDに対応する値になっているかを確認します。複数のバリエーションを1ページで扱うサイトでは、初期表示のバリエーションの値がすべての子商品に当てはめられていないかがとくに重要な確認点です。
あわせて、ランディングページ自体の情報が正しいかも確認しておきます。サイトの表示が古いままになっていると、Googleの候補もその古い情報に引きずられます。候補とページが一致していても、商品マスタや実物と食い違っていれば承認すべきではありません。この場合はサイトの修正が先で、フィードとページの両方を直した後に改めて状況を確認する流れになります。
抽出レビューの進め方
対象商品が数百件、数千件に及ぶ場合、全件を目視で確認するのは現実的ではありません。そこで、前の章で整理したリスク区分に応じて確認する件数を変えます。リスクの低い属性はカテゴリごとに数件、中程度の属性はカテゴリごとに一定割合を抽出して確認し、問題が1件でも見つかったカテゴリは全件確認に切り替えるという運用にすると、手間と精度のバランスを取りやすくなります。
抽出する際は、売上の大きい商品や広告費を多く使っている商品を優先的に含めることをおすすめします。誤った値が入ったときの影響が大きい商品から確認しておけば、仮にレビューの途中で時間切れになっても、事業への影響を最小限に抑えられます。商品ごとの売上や広告費は、Google広告のレポートやECの管理画面から事前に書き出しておくと作業が速く進みます。
判定記録を残す方法
承認した候補値は、後から見返したときに「なぜこの値になっているのか」がわからなくなりがちです。そこで、承認日、担当者、対象属性、対象商品数、確認したサンプル、判断理由を一覧にまとめて残しておきます。スプレッドシートに1行ずつ記録するだけでも、担当交代時の引き継ぎや、表示に問題が出たときの原因調査が格段に楽になります。
記録には、承認を見送った候補も含めておくと効果的です。同じ候補が再び提示されたときに、以前どのような理由で見送ったかがわかれば、毎回ゼロから判断し直す必要がありません。社内の運用ルールとして「承認と見送りの両方を記録する」ことを決めておけば、レビューの品質が担当者によってばらつくことも防げます。
判定記録に残す項目
- 承認日と担当者：誰がいつ判断したかを特定できるようにする
- 対象属性と件数：どの属性を何件承認したかを残す
- 確認サンプル：照合した商品IDとランディングページのURL
- 判断理由：採用または見送りの根拠を一文で記録する
- 根本修正の予定：商品マスタやフィードへの反映予定日
レビュー体制を社内で組む余裕がない場合や、どの候補を承認すべきか判断に迷う場合は、広告運用とフィード管理の無料相談をご活用ください。アカウントの状況を確認したうえで、優先して見るべき属性と商品を整理します。
承認後の確認と巻き戻しの方法
承認後は、適用された値が意図どおりかを商品詳細ページで確認し、誤りがあれば「商品を編集」から取り消します。公式ヘルプでは、適用済みの編集は商品詳細ページで「商品を編集」を選ぶと確認や取り消しができると案内されています。承認して終わりにせず、確認までを1つの作業として扱うことが事故を防ぐ前提です。
適用直後に確認すべき点
承認直後は、まず対象商品のうち数件を開き、候補値が正しく反映されているかを確認します。あわせて、その属性がフィード由来の値ではなく管理画面での編集値として扱われている状態であることを把握しておきます。これにより、後からフィードを更新したときに値が切り替わらない理由を説明できるようになります。
次に、数日から1週間程度の期間で、対象商品の表示状況や広告の配信状況に変化がないかを確認します。属性の変更によって、商品が特定の絞り込み条件に含まれるようになったり、逆に外れたりすることがあるためです。ショッピング広告やP-MAXで商品グループを属性ごとに分けている場合は、商品がどのグループに属しているかも見直しておくと安心です。
誤った値を取り消すときの注意点
誤った値を承認してしまった場合は、商品詳細ページの「商品を編集」から該当する編集を取り消します。取り消した後は、フィードなど元のデータソースの値が適用される状態に戻るため、元のデータソースの値が正しいかを事前に確認しておくことが大切です。元の値も誤っていた場合は、取り消すだけでは不承認や不足の状態に戻るだけで問題は解決しません。
2026年10月時点で確認した公式ヘルプでは、取り消しは商品詳細ページから行う手順として案内されており、多数の商品の編集をまとめて取り消す方法は示されていません。誤承認が数百件規模になると、取り消しだけで数日分の作業になる可能性があります。承認前の抽出レビューを丁寧に行う理由は、まさにこの巻き戻しの負担にあります。
削除や再同期で起こる誤解
取り消しの代わりに商品を削除して再登録すればよいと考える方もいますが、この方法には注意が必要です。公式ヘルプでは、削除した商品がスプレッドシートなどのデータソースに残っている場合、次回の同期で再び追加されると説明されています。削除によって管理画面での編集が確実に消えるかどうかは公式ヘルプで明示されていないため、巻き戻しの手段としては「商品を編集」からの取り消しを基本とすることをおすすめします。
また、商品IDを変更して新しい商品として登録し直す方法は、それまでに蓄積した商品単位の実績が引き継がれない可能性があるため避けるべきです。巻き戻しは公式に案内されている手順で行い、どうしても件数が多い場合は、影響の大きい商品から優先的に取り消す計画を立てて進めます。
巻き戻しで避けたい操作
- 商品の削除と再登録：データソースに残っていれば次回同期で再追加される
- 商品IDの変更：商品単位の実績が引き継がれない可能性がある
- 元データ未確認での取り消し：元の値が誤っていれば問題が再発する
- 記録なしの一括対応：どの商品を戻したか追えなくなる
商品フィード全体の最適化手順については、以下の記事で詳しく解説しています。
承認を根本修正につなげる運用設計
推奨される属性値の承認は応急処置と位置づけ、同じ値を商品マスタやフィードへ反映して管理画面の上書き状態を解消するのが理想です。管理画面での編集が増えるほど、最終的な商品データの出どころが複数に分かれ、誰も全体を把握できない状態に近づきます。承認は、あくまで根本修正までの表示機会の損失を防ぐための手段と考えます。
どこで直すかを決める基準
修正の場所は、値の変わりやすさと対象の範囲で決めるとわかりやすくなります。商品そのものの性質を表す値で、今後も変わらないものは商品マスタで直すのが基本です。商品マスタを短期間で改修できない場合は、補助フィードで値を補う方法が有効です。特定の条件に当てはまる商品をまとめて変換したい場合は、属性ルールの出番になります。
どの方法を選ぶ場合でも、同じ属性を複数の経路で触らないことが重要です。属性ルールでは下書き保存とテストを経てから変更を適用できるため、大量の商品に影響する変換を行う前に、結果を確認する手順を必ず挟みます。管理画面での承認値が残っている商品は、根本修正が反映された後に承認値を取り消し、データの出どころを一本化します。
| 修正の場所 | 向いているケース | 注意点 |
|---|---|---|
| 商品マスタ（基幹・カート） | 商品固有で今後も変わらない値 | 改修に時間がかかる場合がある |
| 補助フィード | マスタ改修まで値を補いたい場合 | マスタ側の修正後に重複を解消する |
| 属性ルール | 条件に当てはまる商品をまとめて変換 | テストで結果を確認してから適用する |
| 推奨される属性値の承認 | 根本修正までの応急処置 | フィードより優先されるため後で取り消す |
定例レビューに組み込む方法
推奨される属性値は、商品の追加やサイトの変更に応じて新たに提示されることがあります。そのため、単発の作業として片付けるのではなく、週次や月次の定例作業に「注意が必要」タブの確認を組み込むことをおすすめします。新しい候補が出ていないか、前回承認した値の根本修正が進んでいるかを、同じタイミングで確認すると効率的です。
定例レビューでは、前の章で紹介した判定記録をもとに、管理画面での編集が残っている商品の件数を追いかけます。この件数が月ごとに減っていけば、データの出どころが一本化に向かっていると判断できます。逆に件数が増え続けている場合は、承認に頼った運用になっているサインであり、商品マスタやフィードの改修を優先課題として扱う必要があります。
商品属性を使ったキャンペーンと商品グループの設計については、以下の記事で詳しく解説しています。
社内と代理店で分担するときのポイント
推奨される属性値の運用は、商品知識を持つEC担当者が承認判断を担い、広告運用者が配信への影響確認を担う分担が最も事故を防ぎやすい体制です。属性の正誤を判断するには商品の実物やマスタの知識が必要であり、広告運用者だけで判断すると誤承認のリスクが高まります。
権限と役割を分ける
Merchant Centerのアカウントには、EC担当者、広告運用者、外部の代理店など複数の関係者がアクセスしていることが一般的です。誰でも候補を承認できる状態のままだと、別々の担当者が異なる基準で承認し、後から整合が取れなくなります。承認できる担当者をあらかじめ決め、ほかの関係者は候補の発見と共有までを担当するというルールにしておくと、判断の基準がそろいます。
代理店に運用を委託している場合は、推奨される属性値を承認してよい範囲を契約や運用ルールの中で明確にしておくことが大切です。たとえば、リスクの低い属性は代理店の判断で承認してよいが、色やサイズ、識別子に関わる属性は必ず広告主側の確認を経る、といった線引きです。承認の範囲を決めずに委託すると、誤承認の責任の所在があいまいになります。
広告成果への影響を確認する
属性値の修正は、商品が表示される検索語句や絞り込み条件に影響するため、広告の成果にも変化が出ることがあります。承認後の数週間は、対象商品のクリック数や表示回数、コンバージョンの推移を確認し、承認前と比べて大きな変化がないかを見ておきます。成果が改善していれば、同じ種類の候補を今後も積極的に採用する判断材料になります。
反対に、承認後に表示回数が大きく落ちた商品があれば、承認した値が検索語句とのつながりを弱めた可能性があります。この場合は値の正誤だけでなく、商品タイトルや説明文との整合も含めて見直します。属性の管理と広告成果の分析を切り離さずに運用することが、フィード改善の効果を最大化する近道です。社内での体制づくりが難しい場合は、フィード運用を含めた広告運用代行のご相談も承っています。
P-MAXで商品データを活用した入札設計については、以下の記事で詳しく解説しています。
まとめ 推奨される属性値は採否の線引きと巻き戻し設計が鍵
Merchant Centerの推奨される属性値は、管理画面上で属性の不足や誤りを手早く解消できる便利な機能ですが、承認した値がフィードより優先されるという仕様を理解せずに使うと、後から修正が効かない状態を生みます。最後に、運用上の要点を3つに整理します。
- 承認値はフィードより優先される。商品エディタでの編集と同様に扱われるため、承認前にランディングページと照合し、判定記録を残してから適用します。
- 属性のリスクで確認の深さを変える。表記ゆれの補正はサンプル確認で承認し、色・サイズ・性別・年齢層・GTIN・ブランドは1件ずつ照合するか商品マスタ側で直します。
- 承認は応急処置として根本修正につなげる。同じ値を商品マスタや補助フィードへ反映し、反映後は承認値を取り消してデータの出どころを一本化します。
まずは無料で広告アカウント診断を
Merchant Centerの「注意が必要」タブに候補が溜まっている、フィードを直したのに表示が変わらない、ショッピング広告やP-MAXの成果が商品データの質に左右されている気がする、といったお悩みはありませんか。株式会社ハーマンドットでは、広告アカウントと商品データの両面から現状を診断し、優先して直すべきポイントを具体的にお伝えします。
属性値の採否判断やフィードの根本修正、商品グループの設計見直しまで、運用の実務に踏み込んだ支援が可能です。社内のリソースが足りない場合も、どこまでを社内で担い、どこからを外部に任せるべきかを一緒に整理します。
初回相談は完全無料・所要時間30分・オンライン対応可能です。