Merchant Center属性ルール設計ガイド｜補助フィードとの使い分けと手順

Google Merchant Centerで商品フィードを運用していると、「タイトルにブランド名が入っていない」「色の表記が赤・レッド・RED と混在している」「アパレル商品なのに gender や age_group が空欄のまま」といった細かな不備が次々に見つかります。本来はECシステムや基幹データ側で直すのが理想ですが、開発担当の手が空かない、カートシステムの仕様で項目を追加できないなど、元データに手を入れられない事情を抱える広告主は少なくありません。

そこで役立つのが、Merchant Centerの中だけでデータを変換・補完できる「属性ルール」です。ただし、上位の解説記事の多くは補助フィードと属性ルールを並べて機能を紹介するところで止まっており、「どの属性ならルールだけで整形を回せるのか」「どこから先は補助フィードに逃がすべきか」という運用判断の線引きまでは踏み込んでいません。結果として、ルールを継ぎ足し続けて誰も全体像を把握できなくなったり、逆に補助フィードを乱立させて更新漏れを起こしたりする現場をよく見かけます。

本記事では、Google Merchant Center ヘルプの属性ルールを設定する、属性ルールのテストとプレビュー、カスタム属性を設定する、商品データ仕様を一次情報として、属性ルールの仕組み、補助フィードとの使い分け基準、title・color・gender・age_groupなど属性別の設計例、テストから適用までの手順、失敗パターンと運用体制までを実務目線で解説します。記載した仕様と画面上の名称は、いずれも2026年10月時点で公式ヘルプから確認できた内容です。

Merchant Centerの属性ルールでできること

Merchant Centerの属性ルールは、元の商品データを書き換えずに、Merchant Center側で属性値を自動的に補完・変換するための機能です。以前「フィードルール」と呼ばれていた仕組みが、現行のMerchant Center（旧称Merchant Center Next）では属性ルールという名称で提供されています。

属性ルールの定義と補助フィードとの違い

属性ルールとは、「どの商品に」「どの値を」「どう加工して」入れるかを条件と演算子で定義し、メインの商品データソースに対して自動的に適用する変換ルールのことです。たとえば「ブランドが空欄の商品には固定値を入れる」「タイトルの末尾に色の値を連結する」といった処理を、フィードファイルに触れずに実行できます。ルールはデータが取り込まれるたびに繰り返し適用されるため、一度設計すれば新しく追加された商品にも同じ処理が自動で効く点が最大の強みです。

一方の補助データソース（補助フィード）は、公式ヘルプで「予備のデータソース」と位置づけられており、メインのデータソースで不足している属性を入力したり、既存の値を更新したりするために使います。商品ID（id）をキーにメインデータと照合し、ファイル、Googleスプレッドシートのテンプレート、APIのいずれかで値を渡す仕組みです。補助データソースで商品を追加・削除したり、単独のデータソースとして使ったりすることはできません。つまり、属性ルールは「規則に従って加工する仕組み」、補助フィードは「商品ごとの正解値を外から持ち込む仕組み」と整理すると違いがつかみやすくなります。

利用の前提と設定画面の場所

属性ルールを使うには、Merchant Centerの設定にある「アドオン」から「高度なデータソース管理」を有効にする必要があります。このアドオンを追加すると、データソース画面でメインの商品データソースを選んだときに「属性ルール」タブが表示され、そこから「属性ルールを追加」で対象の属性を選んでルールを作成できるようになります。補助データソースのタブも同じアドオンで使えるようになるため、両者を併用する前提で最初に有効化しておくのが実務的です。

なお、商品IDを表す id 属性だけは通常の属性ルールではなく「IDルール」のセクションで扱うと公式ヘルプに記載されています。ID は補助フィードとの照合キーや広告の成果データの紐づけに使われる重要な値なので、他の属性と同じ感覚で変換しないよう注意してください。

演算子で表現できる処理の範囲

属性ルールでは、ルールの冒頭に条件を置いて対象商品を絞り込み、その後に演算子で値の決め方と加工方法を指定します。条件は AND（すべて満たす）と OR（いずれかを満たす）で組み合わせられるため、「カテゴリが靴かつブランドがA社」のような絞り込みも可能です。2026年10月時点で公式ヘルプに掲載されている主な演算子は次の表のとおりです。

このほか、既存の属性を変えずに第2の値を保持できる「カスタム属性」も用意されています。公式ヘルプでは「タイトルには『赤』を追加しつつ、color 属性には『赤紫』を残す」といった例が紹介されており、作成したカスタム属性は他のルール内で「*」付きの名前として参照できます。中間値を一時的に置いておく作業用の変数として使えるため、複雑な整形を分解して設計したいときに重宝します。

また、業界メディアの報道によると、従来はフィードやAPIなどで登録した商品にだけ適用されていた属性ルールが、ウェブサイトから自動検出された商品にも適用できるよう段階的に拡大しているとされています。公式の告知ではなく管理画面上の表示から確認された変更のため、自社アカウントで対象になっているかは画面で確かめてから設計に組み込むのが安全です。

商品フィード全体の改善の進め方については、以下の記事で詳しく解説しています。

WEB広告hub

商品フィード最適化 完全ガイド｜Merchant Center・P-MAX改善手順

https://webhub-media.com/column/product-feed-optimization-guide

EC事業を展開する企業にとって、商品フィード最適化は単なる技術的な設定ではなく、広告成果を根本から左右する戦略的な施策です。Google ShoppingやP-MAXキャンペーンで成果を出すには、正確で豊富な商品フィードを整備し、プラットフォームのAIが効率的に学習できる環境を整えることが不可欠です。フィードの質が低い状態で広告予算を投下しても、インプレッションが伸びず、クリックも購買も発生しにくくなります。実際に、当社が100社以上のEC企業に広告運用支援を行った実績の中で、フィード最適化に取り組んだ企業では月間のROAS...

属性ルールで足りるケースと補助フィードへ逃がすケースの判断基準

判断の基準は、補正したい値が元データの中に規則的な形で存在するかどうかです。元データから条件式や文字列操作で導き出せる値なら属性ルールで完結でき、元データのどこにも存在しない情報を商品ごとに付け足す必要があるなら補助フィードに逃がすべきです。

属性ルールで完結できる補正の特徴

属性ルール向きなのは、「全商品に同じ処理をかける」「特定の条件に当てはまる商品群に同じ値を入れる」「既存の文字列を並べ替えたり置き換えたりする」タイプの補正です。たとえばタイトルへのブランド名の付与、色名の英語表記から日本語表記への統一、レディースカテゴリに属する商品への gender の一括設定などは、いずれも元データにある情報だけで処理が完結します。新商品が追加されても同じ規則がそのまま当てはまるため、運用の手間がほとんど増えません。

また、価格帯や商品カテゴリをもとに custom_label を振り分ける処理も属性ルールの得意分野です。キャンペーン側で商品グループを分けるための目印を、元データに手を加えずに付けられるため、広告運用者だけで完結できる改善として優先度が高くなります。

補助フィードを選ぶべき典型パターン

反対に、補助フィードを選ぶべきなのは、正解の値が商品ごとにばらばらで、規則では導き出せないケースです。GTIN（JANコード）のように商品固有の識別子を後から追加する場合や、商品ページを見ないと分からない素材・柄・サイズ感を個別に入力する場合、セールの対象商品と価格を外部の管理表から反映する場合などが該当します。こうした値を属性ルールで無理に表現しようとすると、商品IDを条件にした個別ルールが数百本に膨れ上がり、どのルールが何を変えているのか誰にも分からない状態に陥ります。

目安として、条件に商品IDを10件以上列挙し始めたら補助フィードへの切り替えを検討するのがおすすめです。これは公式の基準ではなく当社の運用上の経験則ですが、IDを列挙するルールは商品の入れ替えに追随できず、保守コストが急激に上がる傾向があります。スプレッドシートの補助フィードであれば、ID と値を表形式で管理できるため、担当者が交代しても内容を引き継ぎやすくなります。

判断を誤ったときに起きる事故

属性ルールに寄せすぎた場合に起きやすいのは、条件の書き方がわずかにずれて想定外の商品にまで値が入る事故です。たとえば「タイトルに『キッズ』を含む」という条件で age_group に kids を入れると、「キッズ用品収納ラック」のような大人向け家具にまで kids が入ってしまう可能性があります。補助フィードに寄せすぎた場合は、元データ側で商品が増えても補助フィードの更新が追いつかず、新商品だけ属性が空のまま配信される状態が起きやすくなります。

もう一つ見落とされがちなのが、両方の手段で同じ属性を触ってしまうケースです。補助フィードで color を渡しているのに、属性ルールでもタイトルから色を抽出して color に入れていると、どちらの値が最終的に使われているのかを担当者が把握できなくなります。同じ属性を複数の手段で補正する場合は、「最新の値を使用」で優先順位を明示するか、どちらか一方に寄せるかを最初に決めておくと、後から調査する手間を省けます。

どちらの事故も、手段の選択そのものより「規則で表せる範囲」を見誤ったことが原因です。迷ったときは、新商品が追加されたときに自動で正しい値が入るかどうかを想像してみてください。自動で正しく入るなら属性ルール、人の判断が毎回必要なら補助フィードという考え方で、ほとんどのケースは判断できます。

補助フィードの作り方や運用設計については、以下の記事で詳しく解説しています。

WEB広告hub

【2026年版】Google Merchant Center補助フィード実装ガイド｜属性不足をあとから埋めてROASを落とさず改善する運用設計

https://webhub-media.com/column/merchant-center-supplemental-feed-guide

Google Merchant Centerで商品データを運用していて、「主フィードを直接書き換えるのは難しいが、いくつかの属性だけ後付けで上書きしたい」「不承認になった商品のタイトルや説明文を一括で修正したい」「広告運用側だけでカスタムラベルを管理したい」という場面は珍しくありません。こうした「属性を後から差し込む・上書きする」用途で使われるのが、Google Merchant Centerの補助フィード（supplemental feed、別名「補完フィード」）です。主フィードを汚さずに運用要件だけを上書きできる柔軟な仕組みですが、フィードルールと...

属性別に見る属性ルールの設計例

属性ルールの効果が最も大きいのは、title・color・gender・age_group・custom_label の5つです。いずれも広告の表示内容や配信の可否、キャンペーンの管理単位に直結するため、ここを規則的に整えるだけでフィード品質は大きく改善します。

title はブランドと属性値を連結して組み立てる

title は検索語句との一致度を左右する最重要の属性で、商品データ仕様では最大150文字と定められています。ECサイトの商品名がそのまま送られていると、「春の新作ブラウス」のようにブランド名や色、サイズが抜けているケースが多く見られます。そこで「次に設定」演算子を使い、brand、元の title、color、size の各値を半角スペースでつないで組み立て直すのが定番の設計です。

注意したいのは、元の title にすでにブランド名が含まれている商品に同じ処理をかけると、ブランド名が二重になってしまう点です。条件に「title がブランド名を含まない」を加えてから先頭に追加する、あるいはカスタム属性で整形済みのタイトルを作ってから最後に title へ設定する、といった二段構えにすると重複を防げます。商品ページのタイトルとかけ離れた文言にすると表示内容の不一致を招くため、あくまで既存の情報を並べ替える範囲にとどめるのが原則です。

タイトルの組み立て方は商材によって最適解が変わります。アパレルであれば「ブランド＋アイテム名＋色＋サイズ」、家電であれば「ブランド＋型番＋主要スペック」、化粧品であれば「ブランド＋商品名＋容量」のように、ユーザーが検索時に入力しやすい要素を前方に置くのが基本の考え方です。カテゴリごとに組み立て順を変えたい場合は、カテゴリ名を条件にしたルールを分けて作成しておくと管理しやすくなります。

color は検索と置換で表記を正規化する

color は、日本を含む一部の国でアパレル商品に必須とされている属性です。商品データ仕様では、数字や単独の1文字を値に使えないことや、複数の色を「/」で区切ることが定められています。ECの管理画面で担当者ごとに「レッド」「赤」「RED」と入力がばらついている場合は、「検索と置換」で代表表記に寄せておくと、絞り込みや商品グループの管理が安定します。

color が空欄で、色名がタイトルの末尾にだけ入っているケースでは、「取得」演算子でタイトルから色名を抜き出して color に設定する方法が有効です。ただし抽出元の表記が商品によってばらばらだと、意図しない語句を拾うおそれがあります。抽出の対象とする色名をあらかじめ一覧にし、その語句に一致した場合だけ値を入れる設計にしておくと、誤抽出を大幅に減らせます。

gender と age_group は条件付きの固定値で埋める

gender に使える値は male・female・unisex の3種類、age_group は newborn・infant・toddler・kids・adult の5種類で、いずれも1商品につき1つの値しか持てません。この2つは商品ごとに自由な値が入るわけではなく、選択肢が決まっているため、属性ルールとの相性が非常に良い属性です。product_type やカテゴリ名に「メンズ」「レディース」「キッズ」といった語句が含まれているなら、それを条件にして固定値を設定するだけで大半の商品を埋められます。

実務では、まず全商品の初期値として age_group に adult、gender に unisex を入れるルールを置き、その下にカテゴリ別の上書きルールを並べる構成がよく使われます。ただし、子ども向け商品に adult が入ったまま配信されると表示の正確性を損なうため、初期値で埋める前に子ども向けカテゴリが漏れなく条件に含まれているかを必ず確認してください。

custom_label は価格帯や利益率で振り分ける

custom_label_0〜4 は広告主が自由に定義できるラベルで、1ラベルあたり最大100文字、アカウント全体で最大1,000種類の値まで使えると商品データ仕様に記載されています。価格を条件に「低価格帯」「中価格帯」「高価格帯」を振り分けたり、product_type の第1階層を「分割して選択」で取り出してラベル化したりすると、P-MAXやショッピング広告の商品グループ設計に直結する切り口を作れます。

利益率や在庫回転率のように元データに存在しない指標でラベルを付けたい場合は、属性ルール単独では対応できません。その場合は利益区分だけを補助フィードで渡し、ラベルへの変換は属性ルールで行うといった組み合わせが現実的です。

商品グループの切り方とキャンペーン構成の考え方については、以下の記事で詳しく解説しています。

WEB広告hub

Googleショッピング広告のアカウント構成 完全ガイド｜ROAS最大化のキャンペーン・商品グループ設計

https://webhub-media.com/column/google-shopping-ad-account-structure-guide

Google広告運用の初心者からプロまで、「アカウント構成」の重要性を理解している企業と、そうでない企業では、ROAS（広告費用対効果）に大きな差が生まれます。特にGoogleショッピング広告は、商品データがそのままユーザーに表示される仕組みであるため、アカウント構成が不適切だと、本来獲得できるはずの顧客を失うことになるのです。本記事では、EC事業を手がける企業のために、Googleショッピング広告のアカウント構成を完全解説します。商品規模別のアカウント設計パターン、リスティンググループの最適設計、P-MAXとの併用戦略...

属性ルールの作成からテスト・適用までの手順

属性ルールは、下書きとして保存し、テストで影響範囲を確認してから適用するのが正しい手順です。作成した時点では本番データに反映されないため、テストを省略せずに結果を確認する習慣をつけることが事故防止の最短ルートになります。

下書きの作成とプレビューで中間値を確かめる

データソース画面でメインの商品データソースを選び、「属性ルール」タブから「属性ルールを追加」をクリックして対象の属性を選びます。条件と演算子を設定したら「下書きとして保存」で保存します。ルールを編集している間は画面右上に「下書きの値」のプレビューが表示され、特定の商品を指定してルール適用後の値を確認できます。

同じ属性に複数のルールを重ねている場合、プレビューでは各ルールを通過した後の中間値も表示されます。title のように段階的に組み立てる属性では、どのルールの時点で想定外の値になったのかを特定しやすくなるため、代表的な商品を数件選んで順番に確認してください。

ルールをテストで承認状況の変化を確認する

下書きを保存したら「ルールをテスト」を実行します。公式ヘルプによると、テストレポートの生成には10〜20分程度かかります。完了後に「テスト結果を表示する」を開くと、承認済み・不承認・除外済みの商品数の変化、影響を受ける属性と商品数、テストによって解決される問題や新たに発生する問題を確認できます。

特に見落としてはいけないのが「新たに発生する問題」です。color を整形したつもりが一部の商品で値が空になり、アパレル商品が不承認になる、といった副作用はここで初めて表面化します。問題があればルールを修正して「変更をテスト」で再実行し、意図どおりの結果になったことを確認してから「変更を適用」をクリックします。

カスケード順序を意識してルールを並べる

公式ヘルプでは、属性ルールはカスケード方式で動作し、複数のルールがある場合は上から順に適用されると説明されています。つまり、後ろのルールは前のルールで加工された値を受け取って処理するため、並べる順番が結果を左右します。「表記ゆれを統一してからタイトルに連結する」のように、正規化の処理を先、組み立ての処理を後に置くのが基本です。

順序の設計を誤ると、置換前の表記ゆれがそのままタイトルに連結されたり、後ろのルールが前のルールの結果を上書きしたりします。ルールを追加するたびに、同じ属性に既存のルールがないか、追加位置が適切かを確認する手順をチーム内で決めておくと安心です。

不承認が発生したときの原因の切り分け方については、以下の記事で詳しく解説しています。

WEB広告hub

【2026年版】Merchant Center不承認・アカウント停止 完全ガイド｜商品不承認の原因・解消手順・再審査の進め方

https://webhub-media.com/column/merchant-center-disapproval-guide

Google Merchant Centerは、Googleショッピングやその他のGoogleプロダクトに商品を掲載するための必須ツールです。しかし、運用する事業者の多くが「商品が突然不承認になった」「アカウント停止を突然通知された」という状況に直面します。一度不承認やアカウント停止が発生すると、配信商品の減少やROAS低下につながり、事業に大きな影響を及ぼします。本ガイドでは、Merchant Centerで発生する不承認・アカウント停止の具体的な原因、解消手順、再審査プロセスを実務レベルで解説します。この記事は、Hermandot（ハーマンドット）...

属性ルール運用で起きやすい失敗と防ぎ方

属性ルールの失敗の多くは、条件の一致判定と必須属性の扱いに起因します。仕様を知っていれば防げるものがほとんどなので、代表的な失敗パターンを押さえておきましょう。

クリア演算子で必須属性を空にしてしまう

「クリア」演算子は属性値を削除するため、誤った値を消す用途では便利です。しかし公式ヘルプでは、必須属性が空白になると商品が不承認になる可能性があると注意喚起されています。たとえばアパレル商品の color をクリアすると、日本向けの配信ではその商品が配信停止になりかねません。

クリアを使う前には、その属性が対象商品にとって必須かどうかを商品データ仕様で確認してください。誤った値を空にするよりも、「検索と置換」や「次に設定」で正しい値に置き換える設計を優先すると、配信停止のリスクを避けながら品質を上げられます。

等しい条件の完全一致と大文字小文字

条件に「等しい」を使う場合、値は正確に一致している必要があります。公式ヘルプでは「13.00」と「13」が別の値として扱われる例が示されており、値の大文字と小文字も区別されます。ブランド名の条件に「nike」と入れたのにフィードには「NIKE」と入っていた、という単純なずれで、ルールが1件も適用されないことは珍しくありません。

表記が揺れる可能性がある値を条件にするときは、「等しい」よりも「含む」系の条件を使うか、先に表記を統一するルールを上段に置いておくのが確実です。テスト結果で影響を受ける商品数が想定より極端に少ないときは、まず条件の一致判定を疑ってください。

商品ページとの不一致を生む過度な加工

属性ルールで書き換えられるのはMerchant Center上のデータだけで、ECサイトの商品ページそのものは変わりません。タイトルに商品ページにない文言を付け足したり、価格を計算で書き換えたりすると、広告の表示内容とランディングページの内容がずれ、不承認やユーザーの離脱につながるおそれがあります。

属性ルールは「すでにある正しい情報を、Googleが読み取りやすい形に整える」ための道具と割り切るのが安全です。商品ページの情報そのものが不足している場合は、ルールで補うのではなく、ECサイト側の修正を優先してください。

属性ルールを長く回すための運用体制

属性ルールを長期で安定させるには、ルールの目的と担当者を台帳で管理することが欠かせません。ルールは画面上で簡単に追加できる反面、作成者が異動したり外部パートナーが交代したりすると、なぜそのルールがあるのか誰も説明できなくなりがちです。

ルール台帳で目的と影響範囲を記録する

台帳には、対象属性、条件、演算子、設定値、作成日、作成者、目的、テスト時の影響商品数を最低限記録しておきます。スプレッドシート1枚で十分ですが、ルールを変更したときは必ず台帳も更新する運用を徹底してください。広告の成果が急に変化したときに、直前に変更したルールを台帳から追えるだけで原因調査の時間を大幅に短縮できます。

あわせて、月に1回程度はテスト機能を使って既存ルールの影響商品数を確認するのがおすすめです。商品構成やカテゴリ名が変わると、以前は機能していた条件が空振りしていることがあります。定期点検で影響商品数がゼロになっているルールを見つけたら、条件を見直すか削除するかを判断しましょう。

恒常化した補正は元データへ差し戻す

属性ルールは便利ですが、本来は元データ側で正しい値を持つのが理想です。半年以上同じ補正を続けているルールや、補正対象が全商品の過半数を占めるルールは、ECシステムや基幹データ側での修正を開発担当に依頼する候補になります。元データが整えばルールを減らせるため、Merchant Centerの設定がシンプルになり、他の広告媒体へのフィード連携にも同じ品質のデータを流せるようになります。

当社が広告運用を支援する現場でも、まず属性ルールで短期的に品質を引き上げ、効果が確認できた補正から順に元データへ移していく二段階の進め方が最も無理なく定着しています。自社だけでルール設計や優先順位づけが難しい場合は、フィードと広告アカウントの無料診断で現状の課題を整理するところから始めることもできます。

広告運用の指標とつなげて効果を検証する

属性ルールの成果は、フィードのエラー件数だけでなく広告の指標で検証することが重要です。title の整形後であれば表示回数やクリック率、custom_label の導入後であれば商品グループ別の費用対効果の変化を、ルール適用日を起点に比較します。成果が見えたルールは台帳に結果を書き残し、同じ考え方を他のカテゴリにも展開していくと、改善のサイクルが回り始めます。

反対に、成果が確認できないルールを放置すると、フィードの複雑さだけが増えていきます。ルールを追加するときと同じ熱量で、効果のないルールを外す判断も行うことが、属性ルールを長く健全に回すための秘訣です。データ設計と広告運用を一体で見直したい場合は、ハーマンドットへのご相談もご検討ください。

まとめ 属性ルールは規則で表せる補正に絞って使う

Merchant Centerの属性ルールは、元データに手を入れられない状況でもフィード品質を引き上げられる強力な機能です。最後に、本記事の要点を振り返ります。

• 使い分けの軸は規則性です。元データから条件式で導ける補正は属性ルール、商品ごとに異なる正解値を足すなら補助フィードを選びます。
• 属性別の定番設計を押さえます。title の連結、color の表記統一、gender・age_group の条件付き固定値、custom_label の価格帯振り分けから着手すると効果が出やすくなります。
• テストと台帳で事故を防ぎます。「ルールをテスト」で不承認の増減を確認してから適用し、ルールの目的と担当を記録して定期的に棚卸しします。

まずは無料で広告アカウント診断を

属性ルールや補助フィードの設計は、ショッピング広告やP-MAXの成果を左右する土台です。しかし、どの属性から手を付けるべきか、どこまでルールで補いどこから元データを直すべきかは、商品数や商材、カートシステムの仕様によって大きく変わります。

株式会社ハーマンドットでは、Merchant Centerのフィード品質から広告アカウントの構成・入札設定までを一体で診断し、成果につながる改善の優先順位をご提案しています。社内に専任担当がいない場合でも、現状の設定を拝見したうえで具体的な打ち手をお伝えします。

初回相談は完全無料・所要時間30分・オンライン対応可能です。