はじめに
Googleで商品名を検索すると、写真と価格が並んだ「ショッピング」の枠が出てきます。あそこに自社の商品を載せるには、Google Merchant Center（以下GMC。Googleに商品情報を登録しておく管理画面）へ商品データを渡す必要があります。この渡すデータの一覧表が、商品フィードです。
多くのECサイトでは、このフィード作りを専用アプリに任せます。ただ、アパレル・ギア系のECサイトを担当したときは、あえてアプリを使わず、サイト側で自前のXMLフィード（決まった書き方でデータを並べたテキスト形式のファイル）を作る方式を選びました。扱う商品は数千SKU（色やサイズまで分けて数えたときの商品の単位）あり、価格も在庫も毎日動きます。
この記事では、なぜアプリではなく自前生成にしたのか、そして数千SKUを毎日最新に保つ仕組みがどう組み立てられているのかを説明します。プログラムの書き方の話は出てきません。「どこからデータを取り、どう変換して、どうGoogleに届けるか」という流れがつかめれば十分です。
専用アプリではなく自前生成を選んだ理由
アプリの設定画面では届かない調整がある
フィード生成アプリはよくできていて、導入した初日から動きます。ただ、便利さの裏返しで、アプリが用意した設定項目の範囲からは出られません。「この商品グループだけタイトルの組み立て方を変えたい」「特定のタグが付いた商品は除外したい」といった要望は、設定画面に該当する項目がなければそこで行き止まりになります。
自前生成なら、商品データからフィードへの変換ルールを自分たちで決められます。売り方の都合に合わせて自由に組み替えられること。これが一番の動機でした。変換ルールそのものは複雑な処理ではないので、非エンジニアでもAIエージェントに実装を任せながら仕様を詰めていく形で十分組み立てられます。
複数サイトのフィードを1か所で管理できる
このプロジェクトでは、同じ商品基盤から複数のECサイトを運営していました。サイトごとに扱う商品の範囲、表示言語、通貨が少しずつ違います。
アプリを使うと、サイトが増えるたびに契約と設定作業も増えていきます。自前生成なら、1つの仕組みでサイト別のフィードを出し分けられます。フィードを取りに来るURLにサイトを指定するだけで、そのサイト向けの内容が返る。この一元管理が、運用の手間をかなり減らしてくれました。
広告だけでなく無料リスティングにも同じフィードが使われる
商品フィードはショッピング「広告」のためのもの、と思われがちです。ただ、Googleの無料リスティング（広告費をかけずに検索結果へ商品を掲載できる枠）にも、まったく同じフィードが使われます。
フィードを整えておけば、広告を出していない期間も検索結果に商品が並ぶ状態を保てるわけです。フィードは広告の付属品ではなく、集客の土台そのもの。そう捉えると、外部アプリに任せきりにせず自分たちで作り込む価値が見えてきます。
フィードが作られてGoogleに届くまで
1本のURLにアクセスするとXMLが返る
仕組み自体はシンプルで、/api/merchant/feed.xml という1本のURLにアクセスすると、GMCが読み取れる形式のXMLが返ってきます。GMC側にはこのURLを登録しておくだけ。あとはGMCが決まった間隔でこのURLを取りに来て、最新の商品データを吸い上げていきます。
商品名・在庫・価格をまとめて取り出す
1本のURLがGoogleの仕様へ変換する
数時間ぶん保存して使い回す
定期的にURLを取得し、ショッピング広告・無料リスティングへ反映
図にすると、商品データを持っているShopifyと、それを受け取りたいGoogleの間に「翻訳して渡す窓口」を1つ置いた形です。
商品データはShopifyから取得する
在庫や価格の正しい値を持っているのはShopifyです。フィードを作る窓口は、Shopifyの管理側データを取り出すための窓口（Admin GraphQL API）に問い合わせて、商品名・説明文・価格・在庫状態・画像・GTIN（商品に付けられた国際的な識別番号）などをまとめて受け取ります。
GraphQL（必要な項目だけを指定してまとめて取り出せる問い合わせ方法）を使うのは、欲しい項目を1回の問い合わせで揃えられるからです。項目ごとに何度も問い合わせる方式だと、数千SKUぶんの取得だけで時間がかかってしまいます。扱う件数が多いほど、この差が処理時間に効いてきます。
Googleの仕様に合わせてXMLへ変換する
取得した商品データは、そのままではGMCに渡せません。GMCには決まった項目名（title description link image_link price availability など）と、項目ごとの書き方のルールがあります。
そこで、Shopifyの商品1件ずつを、この仕様に沿ったXMLの塊へ変換していきます。どの商品データをどの項目に対応づけるか、という変換ルールの設計が、フィードの品質をほぼ決めます。この部分はマッピング設計の記事で詳しく扱います。
運用で効いてくる3つの視点
数千件を毎回作り直さないためのキャッシュ
数千SKUを毎回Shopifyから取得してXML化していると、GMCがURLを取りに来るたびに重い処理が走ります。取得と変換に時間がかかりすぎると、GMC側で時間切れになってフィードが読み込まれないこともあります。
そこで、作った結果を数時間ぶん保存して使い回します。フィードの中身は分単位で変わるものではないので、これで足ります。あわせて、一度に扱う件数を区切って分割生成できるようにしておくと、商品数が増えてもメモリを使い切らずに返せます。この設計はキャッシュとヘルスチェックで解説します。
フィードが止まると広告も止まる
見落とされやすいのですが、フィードが止まると広告も止まります。フィードが生成できなくなったり、中身が空になったりすると、GMCは商品を掲載できなくなり、そのまま広告配信も途切れます。
やっかいなのは、この失敗が画面に出ないこと。管理画面にエラーが赤く表示されるわけではなく、掲載商品数が減り、数日かけて売上が落ちていく形で表面化します。だからこそ、フィードがきちんと生成できているかを外から確認する仕組み（ヘルスチェック用のURL）が欠かせません。
不承認を減らすための品質管理
GMCは、渡された商品を1件ずつ審査します。必須項目が欠けていたり、掲載ポリシーに反していたりすると、その商品は不承認となり掲載されません。
不承認は掲載商品数を減らしていく
1件2件の不承認では気づきにくいのですが、積み重なると掲載できる商品数が数百件単位で減ることがあります。「広告の反応が落ちた」原因をたどると、大量の不承認が溜まっていた、というケースは珍しくありません。
下書き商品や非公開商品を確実に除外し、必須項目の欠けを渡す前に検査する。こうした品質管理の詳細はフィード品質の管理で扱います。
まとめ
Googleショッピングの商品フィードは、アプリに頼らず自前で作ることで、変換ルールも除外の条件も複数サイトへの対応も、自分たちの都合に合わせて設計できます。
- 自前生成の価値：アプリの設定項目に縛られない変換ルールと、複数サイトの一元管理
- 仕組み：Shopifyから商品データを取得し、Googleの仕様に合わせたXMLへ変換して1本のURLで配信
- 運用の要点：キャッシュで軽くし、ヘルスチェックで止まりを検知し、品質管理で不承認を減らす
フィードは広告の付属品ではなく、無料リスティングにも効く集客の土台です。止まれば広告も止まる仕組みなので、丁寧に作り、動いているかを見張り続ける価値があります。
各テーマの詳細は、以下のサブ記事で掘り下げています。