商品データからフィード仕様へのマッピング設計

はじめに

「商品データをGoogleに渡すだけ」と聞くと単純な作業に思えます。ところが実際に手を動かすと、フィード自動生成のなかで一番時間がかかったのがこの部分でした。

ECサイト側が持っている商品データと、Google Merchant Center（以下GMC。Googleに商品情報を登録しておく管理画面）が求める項目は、名前も書き方も一致していません。「価格」ひとつとっても、こちら側は数字だけを持っているのに対し、GMCは通貨の単位まで揃った形を求めます。この食い違いを1項目ずつ埋めていく作業が、マッピング設計です。

この記事では、商品名・識別番号・カテゴリ・在庫状態といった主要な項目を、どう考えてGMCの書式へ変換したのかを紹介します。プログラムの書き方の話は出てきません。「こちらのどのデータを、Googleのどの項目に当てるか」という判断の中身が伝わればと思います。

必須項目を1つも欠かさない

1項目の欠けが、その商品まるごとの不掲載になる

GMCには、商品ごとに必ず入れなければならない項目があります。ここが1つでも空だと、その商品は不承認となり、ショッピングの枠にも無料リスティングにも出てきません。ほかの項目をどれだけ丁寧に埋めていても関係なく、まるごと落ちます。

つまりマッピングの出発点は、必須項目を確実に埋めること。凝った工夫より先に、ここを固めます。下の表が、GMCが求める項目と、こちら側のどのデータを当てたかの対応です。

左がGoogleの欲しい情報、右がこちらで用意できる情報。この対応表を1行ずつ決めていく作業が、マッピング設計の実体です。

色やサイズごとに1件として出す

Googleショッピングでは、色やサイズといったバリエーションごとに1つの商品として扱います。「ジャケットA」ではなく「ジャケットA / 黒 / Mサイズ」という細かさですね。ユーザーが検索して見つけるのも、写真とサイズが具体的に決まった1点だからです。

そのため、こちらの商品1件を、バリエーションの数だけ展開してフィードに並べます。3色×4サイズの商品なら12件。数千SKU（色やサイズまで分けて数えたときの商品の単位）というボリュームになるのは、この展開があるからです。

同じ商品の色違い・サイズ違いだと伝える

ただ12件をバラバラに並べただけだと、Googleからは無関係な12商品に見えてしまいます。そこで、同じ親商品から生まれたバリエーションには共通のitem_group_idという印を付けて束ねます。

これを付けておくと、Googleは「これらは同じ商品の色違い・サイズ違いだ」と理解してくれます。検索結果でカラーバリエーションが並んで表示されたり、在庫が切れた色の代わりに別の色が出たりするのは、この束ねが効いているからです。地味な1項目ですが、掲載の見え方がはっきり変わります。

「どの商品か」を正確に伝える

識別番号とブランド名が照合の手がかりになる

GTIN（JANコードなど、商品パッケージのバーコードとして印刷されている国際的な識別番号）とブランド名は、Googleが「これは世の中のどの商品か」を突き合わせるための手がかりです。ここが揃っていると、同じ商品を探しているユーザーの検索にきちんと当たるようになります。

逆に手がかりが弱いと、商品名の文字列だけで判断されることになり、マッチの精度が落ちます。商品情報としては小さな項目ですが、掲載後の反応にじわりと差が出る部分です。

番号がない商品は「ない」と正直に伝える

すべての商品にGTINがあるわけではありません。自社オリジナル品や、バーコードが登録されていない商品では取れないことがあります。

番号があれば渡し、なければ「ない」と申告する。この2択にしておくのがポイントです。

空欄のまま渡したり、それらしい数字を埋めたりすると、かえって不承認を招きます。「分からないものを分からないと伝える」ほうが、審査は素直に通ります。

Googleのカテゴリ分類に当てはめる

Googleは独自の商品カテゴリの分類体系を用意しています。「アパレル＆アクセサリー ＞ 衣料品 ＞ アウターウェア」のような階層で、自社の商品がどこに属すかを指定する仕組みです。

こちらのコレクションや商品タイプから、この分類へ対応づけるルールをあらかじめ持たせておきます。分類が適切だと、Googleが検索の意図に合わせて商品を出し分けてくれます。ここを空にしてもフィード自体は通りますが、掲載の当たり方が変わってくるので、埋めておく価値のある項目です。

書式のずれをなくす

価格と在庫状態は決まった書き方に直す

同じ「価格」でも、ECサイトの内部データとGMCが求める書式は違います。GMCは価格に通貨コードを添えることを求めますし、在庫状態も自由な文章ではなく、決められた言い方でなければ受け付けません。

要するに、人間が読むための表示と、機械が読み取るためのデータは別物だということ。フィードに載せるのは後者です。

説明文から装飾タグと余計な空白を落とす

商品説明はサイト上で見やすく整えるために装飾タグを含んでいることが多く、これをそのまま渡すと、タグの文字がGoogle側の表示にそのまま出てしまいます。

そこでマッピングの段階で装飾タグを取り除き、連続した空白や改行も整えます。GMCの説明文には文字数の上限もあるため、長すぎる場合は前半の要点を残して切り詰めます。細かい処理ですが、これを飛ばすと掲載の見栄えがはっきり落ちるんですよね。

変換ルールは実データを見ながら詰める

変換ルールは、机上で完成させようとするとまず抜けが出ます。実際の商品データを何百件か眺めてみると、想定していなかった書き方の商品名や、単位の入った価格、空欄のカテゴリが必ず見つかります。

なので、まず素直なルールで一度フィードを作り、出てきた結果を見て例外を足す、という進め方をしました。非エンジニアでも、AIエージェント（対話しながら実装を進められる開発支援ツール）に変換ルールを言葉で伝えて直してもらう形なら、この試行を短い間隔で回せます。ルール自体は複雑な処理ではないので、判断の中身さえ決まれば形にはなります。

まとめ

マッピング設計は、ECサイトの商品データとGMCの仕様という、書き方の違う2つを突き合わせる翻訳作業です。

• 必須項目を落とさない：1項目でも欠けると、その商品はまるごと掲載されない
• 色・サイズごとに展開し、束ねる：バリエーション単位で出しつつ、同じ商品だと分かる印を付ける
• 識別番号・ブランド・カテゴリで「どの商品か」を正確に伝える。ないものは「ない」と申告する
• 書式を仕様に合わせる：価格の通貨表記、在庫状態の変換、説明文の装飾タグ除去

ここが固まってはじめて、フィードのキャッシュとヘルスチェックや品質管理が意味を持ちます。仕組み全体の流れは商品フィードの自動生成でまとめています。