カテゴリー: EC運用メモ

product_typeとGoogle product categoryを混同しないための整理

Shopifyで商品を整理する「商品タイプ（Type）」と、Merchant Centerが分類に使う「Google商品カテゴリ（google_product_category）」は、どちらもカテゴリに関する項目ですが、役割も入力規則も別物です。Type列にGoogleのカテゴリIDを入れてしまったり、逆にgoogle_product_categoryに自社の分類名を入れてしまったりすると、Merchant Centerで分類エラーや警告の原因になります。本記事では、Shopify CSVのType列、Product Category列、Merchant Centerのproduct_type属性、google_product_category属性の4つを整理し、それぞれに何を入れるべきかをまとめます。

4つの項目の対応関係を整理する

まず、名前が似ているこれら4つの項目が、どこに属し、何を表しているかを整理します。

項目名	属する世界	何を表すか	値の決め方
Shopifyの `Type` 列	Shopify（管理画面・CSV）	自社の商品分類	自由に入力可能
Shopifyの `Product Category` 列	Shopify（管理画面・CSV）	Google商品カテゴリとの紐付け	Shopifyが用意した選択肢から選ぶ
Merchant Centerの `product_type`	Google Merchant Center	店舗独自の分類（自社カテゴリ）	自由テキスト。何を入れてもエラーにならない
Merchant Centerの `google_product_category`	Google Merchant Center	Googleが定める公式分類	GoogleのタクソノミーIDまたはパス文字列が必須

ShopifyのType列に入れた値は、フィードアプリ経由でproduct_typeとして送られることが多いです。一方、ShopifyのProduct Category列はgoogle_product_categoryの元データとして使われます。同じCSVに2つのカテゴリ列が並んでいるため、どちらに何を入れるべきか混同しやすい構造になっています。

product_type（自社分類）の特徴

product_typeは、出店者が独自に決めたカテゴリ分類を入れる属性です。Google側でバリデーションされることはほぼなく、任意項目です。

どこで設定するか

Shopify管理画面：商品詳細ページの「商品の整理」セクションにある「商品タイプ」フィールド
Shopify商品CSV：Type列。自由な文字列を入力可能

入力例：Tシャツ、レディース > トップス > Tシャツ、夏季商品など。階層を>で区切ることもできますが、平文でも構いません。

Merchant Centerでの扱い

product_typeは空欄でもただちに不承認になる属性ではありません。任意の文字列を入れてもエラーにはなりません。ただし、広告の商品グループ分け、レポート整理、商品理解の補助に使われるため、運用上は整えておく価値があります。google_product_categoryとは役割が違うため、承認可否の主因として扱うより、運用分類として捉えるのが適切です。

主な用途は、Shoppingキャンペーンでの商品グループ分けです。product_typeを使って「自社カテゴリごとに入札価格を変える」といった運用ができます。

google_product_category（Google公式分類）の特徴

google_product_categoryは、Googleが定めるタクソノミー（分類体系）から選択する属性です。一部のカテゴリでは必須で、不正な値を入れるとエラーまたは不承認になります。

どこで設定するか

Shopify管理画面：商品詳細ページの「商品の整理」セクションにある「商品カテゴリ」フィールド。Shopifyが用意した候補リストから検索して選択する
Shopify商品CSV：Product Category列。入力するのはタクソノミーのパス文字列（例：Apparel & Accessories > Clothing > Shirts）

Googleのタクソノミーとは

Googleは数千のカテゴリを階層構造で定義しており、この一覧を「Google Product Category Taxonomy」と呼んでいます。各カテゴリには数値IDが割り当てられています。

タクソノミーID	パス文字列
`1604`	`Apparel & Accessories > Clothing`
`212`	`Apparel & Accessories > Clothing > Dresses`
`784`	`Media > Books`
`2622`	`Home & Garden > Kitchen & Dining`

Merchant Centerのフィード仕様では、タクソノミーID（例：1604）またはパス文字列（例：Apparel & Accessories > Clothing）のどちらでも受け付けます。

必須になるカテゴリ

以下のようなカテゴリに属する商品では、google_product_categoryの指定が必須です。

衣類・アクセサリー（Apparel & Accessories）
メディア（書籍、DVD、音楽）
アルコール飲料
ギフトカード
健康関連商品

これらのカテゴリでgoogle_product_categoryが未設定・誤設定の場合、Merchant Centerで不承認になります。

Shopify CSVでの2つの列の見分け方

Shopifyの商品CSVには、カテゴリに関する列が2つあります。列名を間違えると、フィードアプリが意図しない属性にマッピングしてしまいます。

CSV列名	何を入れるか	Merchant Center側の属性	値の例
`Type`	自社の商品分類（自由入力）	`product_type`	`レディースTシャツ`
`Product Category`	Google商品カテゴリ（タクソノミーから選択）	`google_product_category`	`Apparel & Accessories > Clothing > Shirts`

CSVを開いたとき、列の並び順は商品のオプション構成やCSVのバージョンによって異なるため、必ずヘッダー行の列名で判断してください。

フィードアプリがどうマッピングしているか

Google & YouTubeアプリやサードパーティのフィードアプリは、Shopifyのデータを読み取ってMerchant Centerに送信する際、次のようなマッピングを行っています。

Shopifyのデータ	フィードアプリの処理	Merchant Centerの属性
`Type`列の値	そのまま、または整形して送信	`product_type`
`Product Category`列の値	Shopify内部IDからタクソノミーパスまたはIDに変換	`google_product_category`
`Type`列が空欄	`product_type`として空欄または未送信	（警告なし）
`Product Category`列が空欄	`google_product_category`が未送信	必須カテゴリ商品の場合は不承認

フィードアプリの設定画面で、Type列をgoogle_product_categoryにマッピングしなおしている場合は注意が必要です。自社分類の文字列がそのままGoogle公式分類として送信されるため、タクソノミーに存在しない値であればエラーになります。マッピング設定は意図通りか確認してください。

よくある混同パターンと影響

Type列にGoogleのタクソノミー文字列を入れている

「Apparel & Accessories > Clothing」のようなGoogleタクソノミーのパスを、Type列に入力しているケースです。これ自体はproduct_typeとして送られるためエラーにはなりませんが、本来はProduct Category列に入れるべき値がType列に入っているため、自社分類としての使い勝手が失われます。

Product Category列に自社分類名を入れている

「レディースTシャツ」のような自社カテゴリ名をProduct Category列に入力しているケースです。Shopifyの候補リストに一致しない値を入れると、Shopify側で認識されず、結果的にgoogle_product_categoryが空欄のまま送信されることがあります。

Type列とProduct Category列に同じ値を入れている

両方に「Tシャツ」と入力しているケースです。Type列は自由入力のため「Tシャツ」で問題ありませんが、Product Category列に「Tシャツ」と入力してもGoogleのタクソノミーには一致しないため、結果的にgoogle_product_categoryが未設定になります。

フィードアプリのマッピング設定を確認していない

Type列をgoogle_product_categoryに、Product Category列をproduct_typeにマッピングしているアプリ設定になっていると、意図と逆の属性に値が送られます。フィードアプリの設定画面で、どの列がどの属性に対応しているかを確認してください。

自動で確認できる部分と人が判断する部分

自動化で確認できること

Product Category列の値がGoogleタクソノミーのパス文字列またはID形式に一致しているかの検証
Type列とProduct Category列の値が完全に同一になっていないかの検出
Product Category列が空欄の商品の一覧化
必須カテゴリに属する商品（衣類など）でgoogle_product_categoryが未設定のものの抽出
フィードアプリから送信されたgoogle_product_category値が、Googleタクソノミーに存在するIDかどうかの照合

人が判断するべきこと

商品に最も適合するGoogleタクソノミーカテゴリの選択（複数の候補がある場合）
自社のカテゴリ体系をType列にどう反映するかの設計
中間的なカテゴリに属する商品の分類判断（例：スマートウォッチは「Electronics」か「Apparel & Accessories > Jewelry」か）
フィードアプリのマッピング設定を変更するかどうかの判断（他の商品への影響を考慮）

確認手順のまとめ

CSVを開き、Type列とProduct Category列のヘッダーを確認する――列名でどちらが自社分類かGoogle分類かを見分ける
Type列に自社の分類名が入っているか確認する――自由入力で構わないが、空欄よりは入っていた方が運用上便利
Product Category列にGoogleタクソノミーのパス文字列が入っているか確認する――空欄の場合は、特に衣類やメディア商品で注意
フィードアプリの設定でマッピングを確認する――Type列がproduct_typeに、Product Category列がgoogle_product_categoryに対応しているか
Merchant Centerでgoogle_product_categoryの値を確認する――意図したカテゴリIDまたはパスが反映されているか

相談時に用意するとよい情報

現在のShopify商品CSVのType列とProduct Category列に何が入っているか（大まかな傾向で構いません）
使用しているフィードアプリの名称
Merchant Centerで出ているカテゴリ関連のエラーや警告の有無
取り扱う商品の主なカテゴリ（衣類、雑貨、食品など）

初回相談では機密CSVやスクリーンショットの送付は不要です。Type列とProduct Category列の使い分けでお悩みの場合は、現在の入力状況を大まかにお知らせください。

参考にした公式情報

この記事の内容で困っている方へ

Merchant Center / 商品フィードまわりの作業整理、小さな自動化、簡易チェックツール化について相談できます。初回相談で機密CSVやスクリーンショットを送る必要はありません。

無料相談する

2026年6月2日

商品IDとhandleを混同するとフィード確認で何が困るか

Shopifyで商品を管理していると「商品ID」「handle」「variant ID」「SKU」と、似たような識別子が複数出てきます。Merchant Centerのフィードを確認するとき、どれを使えばいいのか迷った経験はないでしょうか。

実は、IDの種類を取り違えるだけで「フィードに商品が見つからない」「エラーの原因箇所が特定できない」といった無駄な往復が発生します。この記事では、各IDの違いとMerchant Center側での表記形式を整理し、トラブル時にどのIDで照合すればよいかをまとめました。

Shopifyに存在する4つの識別子

まずはShopify内部で使われる主な識別子を押さえておきます。

識別子	形式	例	何を指すか
商品ID（Product ID）	数値のみ	`7429183012995`	商品ページ全体（親）
Handle	URLスラッグ	`blue-t-shirt`	商品ページのURL末尾
Variant ID	数値のみ	`42583019464899`	サイズ・カラーなど個別のSKU単位（子）
SKU	自由入力	`BTS-BLU-M`	店舗側が任意で付与する管理コード

商品IDとVariant IDはどちらも数値ですが、桁数が異なることが多く、用途も違います。商品IDは「この商品ページ」全体を指し、Variant IDは「この商品のこのサイズ・カラー」を指します。

Merchant Centerのitem idはどう見えるか

Google Merchant CenterにShopifyアプリ経由でフィードを送ると、商品IDは次のような形式に変換されます。

shopify_JP_7429183012995_42583019464899

この文字列は3つの部分で構成されています。

shopify ― プラットフォーム接頭辞
JP ― ストアの販売チャネル地域
7429183012995 ― Shopify商品ID
42583019464899 ― Shopify Variant ID

つまりMerchant Center上の「item id」はVariant ID単位で付与されており、親商品IDだけでは一意に特定できません。ここを押さえておかないと、Shopify管理画面で商品IDだけ検索してもMerchant Center側と一致しないという事態になります。

IDの混同で起きる具体的なトラブル

1. Handleでフィードを検索してしまいヒットしない

Merchant Centerのフィード検索はitem idベースで行われます。blue-t-shirtのようなhandleで検索しても結果はゼロです。「フィードに商品が登録されていない」と早合点してしまう原因のひとつです。

2. 商品IDとVariant IDを逆に伝える

エラー報告をするとき「商品ID 42583019464899が rejects されています」と伝えても、それが実はVariant IDだと相手には伝わりません。Merchant Center側では先頭にshopify_JP_が付くため、数字だけではどの部分のIDか判断がつきません。

3. SKUの不一致で重複登録に見える

SKUは自由入力なので、運用中に変更するとMerchant Center側では別商品として扱われます。ID体系を理解していないと「同じ商品が2つある」という誤解につながります。

ShopifyとMerchant CenterのID対応表

実際に照合するときの対応関係をまとめました。

Shopify側	Merchant Center側	照合に使う場面
商品ID `7429183...`	`shopify_JP_7429183..._*`	「どの商品か」を大まかに特定
Variant ID `4258301...`	`shopify_JP_*_4258301...`	エラーの原因になった特定バリアントを特定
Handle `blue-t-shirt`	（直接は使われない）	Shopify管理画面内での移動・確認用
SKU `BTS-BLU-M`	attribute `sku` として格納	自社内の在庫管理と突き合わせ
商品ステータス（active/draft）	destination `Shopping` の承認状態	公開対象かどうかの確認

エラー報告に使うべきID

Merchant Centerで商品が rejects や警告になった場合、報告に使うべき識別子は次の優先順位です。

Merchant Centerのitem id（shopify_JP_...形式） ― これが最も確実です。Merchant Center画面の「商品」一覧から直接コピーできます。
Variant ID ― item idの末尾部分です。Shopify管理画面のバリアント編集URLから確認できます。
商品ID ― 大まかな対象商品を伝える目的で補助的に使います。

Handleや商品名だけ伝えても、検索の手間が増えるだけで解決は速くなりません。

自動連携と手動確認の切り分け

自動で処理されること

ShopifyアプリからMerchant Centerへのフィード送信
商品ID → item id（shopify_JP_...形式）への自動変換
新規商品公開時の自動反映

これらはアプリとMerchant Centerの連携設定が正しければ、手動操作は不要です。

人が確認・判断すべきこと

rejects や警告の内容確認と原因特定
Shopify側の商品情報（タイトル、画像、価格）とMerchant Center側の表示との突き合わせ
SKU変更や商品削除に伴うフィードの整合性確認
フィード仕様の変更ポリシーへの対応判断

自動連携に任せきかりではなく、エラーが出たときにどのIDを手がかりに調査するかを知っておくことが、対応の早さに直結します。

照合の手順まとめ

Merchant Centerで不審なステータスを見つけたときの基本的な確認手順です。

Merchant Centerの「商品」画面で該当商品の item id をコピーする
item idの末尾の数値（Variant ID）を確認する
Shopify管理画面で /admin/products/商品ID/variants/Variant ID のURLにアクセスし、該当バリアントを開く
タイトル・画像・価格・在庫などの情報を比較する
原因が判明したら、Shopify側の該当項目を修正する

商品IDだけではバリアント単位の特定ができないため、必ずVariant IDまで確認するのがポイントです。

相談時に用意するとよい情報

Merchant Centerで表示されているitem id（shopify_JP_...形式）
該当商品のShopify管理画面URL
Merchant Centerのエラーメッセージ本文（テキストでOK）
エラーが発生し始めたおおよその時期
最近行ったShopify側の変更（SKU変更、価格改定、商品の複製など）

初回相談では機密CSVやスクリーンショットの送付は不要です。上記のテキスト情報が揃っていれば、原因の切り分けを進められます。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

複数国向けフィードを始める前に整理したい商品データ

Google Merchant Centerで複数国向けに商品フィードを配信しようとすると、最初の壁は「どの項目を国ごとに変えるのか」の整理です。言語や通貨はもちろん、配送料や税の扱いも変わるため、事前に把握しておかないとフィードエラーが連鎖します。ここでは、国別に変動する項目と共通項目を分けて整理します。

国ごとに変わる項目と変わらない項目

商品データのなかには、対象国が変わってもそのまま使える項目と、必ず書き換えが必要な項目があります。この区分を間違えると、Merchant Centerで不承認や表示崩れの原因になります。

項目	国ごとに変わるか	主な変更内容
`title` / `description`	変わる（言語）	対象国の言語に翻訳。文字数上限は共通
`content_language`	変わる	対象国の言語コード（ja / en / de など）
`price`	変わる（通貨・価格）	通貨コード付きの価格（例: 2980 JPY / 25.00 USD）
`shipping`	変わる	国別の配送料・日数。送料無料でも明示が必要
`tax`	変わる（米国など）	米国は州ごとに税率設定が必要な場合がある
`GTIN`	変わらない	国際標準の商品識別子。そのまま流用可
`image_link`	変わらない	画像URLは共通。ただし画像内テキストの言語には注意
`brand` / `MPN`	変わらない	ブランド名とメーカー品番は共通
`link`	変わる場合が多い	ローカライズURLまたは hreflang 設定済みページ

GTINや画像はそのまま使えるため、一度用意すれば全フィードで再利用できます。反面、価格と配送は各国の実情にあわせて個別に設定する必要があります。

Shopify Marketsを使っている場合の確認ポイント

ShopifyのMarkets機能で多国展開している場合、ストア側の設定がフィード出力に直結します。以下の項目を事前に確認しておきます。

対応通貨の設定 — Markets で各国の通貨を有効にしておかないと、Googleチャネルの価格出力がUSD固定になることがあります。
配送プロファイル — 国別の配送料は Shopify の配送設定から制御されます。Merchant Center 側でも配送サービスの上書きが可能ですが、二重管理を避けるためにどちらを主とするか決めておきます。
言語ごとの翻訳ページ — Shopify Markets で翻訳ページを生成している場合、link 属性が各言語のURLを出力するか、Googleチャネルの設定を確認します。

Merchant Centerのフィード設定（国別フィードの考え方）

Merchant Centerでは、基本的に対象国（target country）ごとにフィードを分けるのが推奨されます。1つのフィードで複数国をカバーする設定もありますが、言語や価格の管理が複雑になるため、運用上は国別フィードの方が扱いやすい場面が多いです。

フィードごとの最小構成

日本向けフィードを例にすると、次のようになります。

対象国: JP
content_language: ja
通貨: JPY
配送: 日本国内の配送料と日数

米国向けフィードを追加する場合は、別フィードとして target_country = US、content_language = en、通貨 USD で作成します。

よくあるつまずきポイント

価格の通貨コード不一致

フィードの price に 2980 だけ書いて通貨コードを省略すると、Merchant Center の対象国設定に依存した解釈になります。明示的に 2980 JPY のように書くことで、意図しない不承認を防げます。

配送設定の未入力

対象国の配送設定がフィードにもMerchant Centerにもない場合、商品は不承認になります。送料無料の場合も「0 USD」など明示的に設定が必要です。

画像内テキストの言語

image_link 自体は共通ですが、画像に日本語のテキストが入っている商品画像をそのまま欧州向けフィードに流用すると、ユーザー体験が下がります。可能であれば、主要言語ごとに画像を用意するか、テキストを含まない画像を使用します。

翻訳品質と文字数

自動翻訳をそのままフィードに入れると、title や description が不自然になり、広告のクリック率に影響します。最低でも主要商品の title は人手で確認しておくことを想定しておきます。

自動化できる部分と人手が向く部分

自動化に向く	人手の確認・作業が向く
価格の通貨変換（為替レート適用）	title / description の翻訳・校正
GTIN・MPN・brand の共通項目転記	国別配送料の設定・見直し
image_link の共通URL出力	画像内テキストの多言語対応
feed ファイルの自動生成・アップロード	税設定の国別・州別調整（特に米国）

フィードの生成自体はアプリやスクリプトで自動化しやすい一方、翻訳や価格戦略の判断は手動で行う方が安全です。どこまで自動化するかは取扱商品数にもよるため、規模に応じて線を引きます。

相談時に用意するとよい情報

複数国向けフィードの運用を見据えた初回相談では、以下の情報があると話が進めやすくなります。

現在展開中または予定している対象国のリスト
ストアで使用している多言語・多通貨の対応方法（Shopify Markets / 別ドメイン / サブディレクトリなど）
各国の配送料がすでに決まっているか、検討中か
翻訳の体制（機械翻訳のみ / 人手による翻訳あり）
Merchant Center のアカウントが既にあるか、新規作成か

初回相談では機密CSVやスクリーンショットの送付は不要です。概要を言葉で伝えていただければ、まずは方針の整理から始められます。

複数国フィードは、項目の分類（共通 / 国別）を先に整理しておくことで、あとの設定作業が大きく変わります。まずは対象国を絞り、変わる項目と変わらない項目を書き出すところから始めてみてください。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

日本語ストアから英語圏へ商品を出すときの商品データ注意点

日本語で運用しているShopifyストアの商品を、英語圏（米国・英国・豪州など）向けにMerchant Centerへ送る場合、商品データのどの項目を翻訳し、どの項目をそのまま使うかの整理が最初の工程になります。単純に全項目を機械翻訳にかけるだけでは、ブランド名のゆらぎや単位の不一致で不承認が出やすくなります。本稿では、英語圏向けフィードを作る際に確認すべき項目を、翻訳対象と非翻訳対象に分けて整理します。

翻訳対象と非翻訳対象の分類

商品データの項目は、英語圏向けに必ず翻訳・変換が必要なものと、日本語のままで問題ないものに分かれます。以下の表で区分を確認します。

項目	英語圏向けの対応	注意点
`title`（商品名）	翻訳が必要	英語圏の検索習慣にあわせた語順に調整。ブランド名は後述のルールに従う
`description`（商品説明）	翻訳が必要	素材・用途・特徴を英語で自然に記述。プロモーション文は除去
`product_type` / `google_product_category`	英語が推奨	Google商品カテゴリは英語の分類IDまたは英語名を使用
サイズ・寸法（`size`、カスタム属性）	単位変換が必要	cm → inches、kg → lbs、g → oz など。表記も「S / M / L」の基準が日本と異なる場合がある
`price`	通貨変換が必要	JPY → USD等。為替レートの更新頻度と端数処理を決めておく
画像内テキスト（商品画像・比較画像）	確認が必要	画像に日本語が含まれていると英語圏の購入者に伝わらない
`brand`（ブランド名）	そのまま	ブランド名は無理に翻訳しない。ローマ字表記がなければヘボン式等で統一
`GTIN` / `MPN`	そのまま	国際標準の識別子なので変更不要
`image_link`（URL）	そのまま	画像URLは共通。ただし画像内容の確認は上記のとおり
`shipping`	再設定が必要	国際配送料と日数を英語圏向けに別途設定

GTINやブランド名はそのまま使えるため、翻訳の手間を省けます。反面、titleとdescriptionは購入者が直接目にするテキストであり、翻訳品質がクリック率や转化率に直結します。

商品名（title）の翻訳

日本語のtitleを英語に翻訳する際、語順の違いに注意が必要です。日本語では「ブランド名 + 商品カテゴリ + 特徴」の順が一般的ですが、英語圏では主要キーワードを前に置く傾向があります。

翻訳時のポイント

ブランド名は翻訳しない — 「山田鞄」を「Yamada Bag」と訳すと、実際のブランド名と乖離し、ユーザーの検索時に混乱を生む。ブランド名はローマ字表記または公式の英語名をそのまま使う
素材・色・サイズを英語の自然な語順に — “Cotton T-Shirt, Blue, Size M” のように、英語圏の検索習慣にあわせた配置にする
日本固有の言葉には補足を — 「浴衣」「風呂敷」等は、そのままローマ字にするか “Yukata (Japanese Summer Kimono)” のように簡潔な説明を添える

商品説明（description）の翻訳

descriptionは単なる直訳以上の工夫が求められます。英語圏の購入者にとって、素材の産地名や日本の規格表記は馴染みがない場合があるため、わかりやすい表現への置き換えが必要です。

素材表記の統一 — 「綿100%」は “100% Cotton” に。「ポリエステル」は “Polyester” に。日本のJIS規格番号は英語圏の消費者には意味を持たないため、素材名そのものを記載する
用途・シーンの明示 — 日本語では暗黙に伝わる用途も、英語では明記した方がよい場合がある。「ギフト対応」といった表現は “Gift wrapping available” のように明示する
表現のトーン — 日本語の丁寧な説明文を直訳すると、英語としては冗長になることがある。簡潔な事実ベースの記述に絞る

サイズ・寸法の単位変換

日本と英語圏（特に米国）では、サイズ表記の基準が大きく異なります。変換ミスは返品・クレームに直結するため、特に慎重に扱います。

測定項目	日本の表記	英語圏（米国）の表記	変換の目安
長さ・寸法	cm（センチメートル）	inches（インチ）	1 cm ≈ 0.3937 in
重量	g / kg	oz / lbs	1 kg ≈ 2.2046 lbs、1 g ≈ 0.0353 oz
アパレルサイズ	S / M / L / LL	XS / S / M / L / XL / XXL	日本のLは米国のM〜Lに相当。実測値の併記が安全
靴のサイズ	JP（cm表記）	US / UK / EU	変換表の用意が必須。JP 25.0 ≈ US 7.0（メンズ）等

アパレルや靴の場合、サイズ表（size chart）を商品ページに併設することで、サイズ不一致による返品を減らせます。可能であればcmとinchesの両方を記載したサイズ表を画像またはテキストで用意します。

商品画像内のテキスト問題

商品画像に日本語が含まれている場合、英語圏の購入者には情報が伝わりません。特に以下のケースに注意が必要です。

素材・成分の日本語表記 — 画像内に「綿100%」「成分表」などが日本語で書かれていると、英語圏の消費者は素材を確認できない
使い方・手順の日本語説明 — 商品の使い方を説明する画像が日本語のみの場合、購入後のトラブルにつながる
サイズ比較画像 — 人物とのサイズ比較画像の注釈が日本語だと、寸法の参考にならない

対応策としては、テキストを含まない画像をメイン画像に使い、テキスト付き画像は補足画像に回す方法があります。商品数が多い場合は、主要商品のみ英語版画像を用意し、それ以外はテキストなし画像で対応する段階的なアプローチも現実的です。

ブランド名の取り扱い

日本のブランド名は、そのままローマ字で出すのが基本です。ただし、いくつかのパターンによって対応が変わります。

すでに英語名（ローマ字）がある場合 — そのまま使用。「MUJI」「UNIQLO」等は何も変える必要がない
漢字・ひらがなのブランド名の場合 — ヘボン式ローマ字または公式の英語表記を使用。「大塚家具」は “Otsuka Furniture”、「無印良品」は “MUJI” のように、公式の英語名があればそちらを優先
ブランド名に翻訳を含めない — ブランド名を翻訳すると、既存の認知と乖離する。検索での合致率も下がるため、品牌名はそのまま維持する

自動化できる部分と人手が向く部分

自動化に向く	人手の確認・作業が向く
価格の通貨変換（為替レート適用・端数処理）	title の翻訳・語順調整
サイズの単位変換（cm → in 等）	description の翻訳・トーン調整
GTIN / MPN / brand の共通項目転記	ブランド名のローマ字表記の統一
フィードファイルの自動生成・Merchant Center送信	画像内テキストの確認・英語版画像の作成
google_product_category のIDマッピング	サイズ表の多言語対応・実測値の確認

単位変換や通貨計算はスクリプトやアプリで処理できますが、titleやdescriptionの翻訳は自動翻訳をベースに人手で補正する流れが現実的です。とくに商品数が数十を超える場合は、主要商品だけを人手で仕上げ、残りを自動翻訳＋簡易確認で回す二段構えが管理しやすくなります。

文化的な配慮

商品データの翻訳にあたっては、言語だけでなく文化的な文脈の違いも考慮に入れます。

色名の感覚の違い — 日本の「生成り」や「杢目」は、英語圏では “Natural” “Oatmeal” 等の一般的な色名に置き換えた方が検索されやすい
「日本人向け」「日本製」の表記 — 英語圏向けフィードでは “Made in Japan” は品質のアピールになるが、「日本人の体型に合わせた」等の表現は “Designed for a comfortable fit” のように汎用化する方が自然
季節商品のタイミング — 日本の春夏秋冬と北米・豪州では季節のタイミングが異なる。オーストラリア向けに「夏向け」を売りに出すときは、時期のズレを意識する

相談時に用意するとよい情報

日本語ストアの商品を英語圏向けに展開する際のご相談では、以下の情報があると方針の検討が進めやすくなります。

展開予定の対象国（米国・英国・豪州など）
商品のおおよその点数と主要カテゴリ（アパレル、雑貨、食品など）
現在の翻訳体制（機械翻訳のみ / 外部翻訳サービス利用 / 社内対応など）
サイズ展開の有無（アパレル・靴の場合）
商品画像に日本語テキストが含まれている割合

初回相談では機密CSVやスクリーンショットの送付は不要です。商品カテゴリと対象国の概要をお伝えいただければ、まずは翻訳・変換の方針整理から始められます。

日本語ストアから英語圏への商品展開は、翻訳対象と非翻訳対象を明確に分けること、単位と通貨の変換ルールを決めること、画像内の日本語テキストに目を向けることの3つが最初の要点です。全商品を一度に完璧にしようとするより、主要商品から段階的に進める方が運用上無理がありません。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

MPN missingと言われたときにメーカー型番をどう扱うか

Merchant Centerで「MPN missing（メーカー型番の欠落）」という警告が出ると、商品データの品質スコアが下がり、広告の表示機会に影響することがあります。しかし「そもそもMPNとは何か」「SKUとどう違うのか」「自社オリジナル商品にMPNはあるのか」と迷う場面も少なくありません。この記事では、Shopify運用の観点から、MPN・SKU・JANコードの違いを整理し、警告への対応方針を考えます。

MPNとは何か

MPN（Manufacturer Part Number）は、文字通りメーカーが自社製品に付与する型番です。Googleの商品データ仕様ではmpn属性として定義されており、商品を一意に識別するための3本柱（GTIN・ブランド・MPN）の1つです。

重要なのは、MPNは「メーカーが決めた番号」であるという点です。EC事業者が自社で付けた管理番号や、ShopifyのSKUは、原則としてMPNではありません。

SKU・Barcode・MPN・JANの違い

Shopify管理画面とMerchant Centerに登場する「番号」を整理します。

用語	Shopifyの列	誰が付けるか	Merchant Center属性
SKU	`Variant SKU`	事業者（店舗）	該当なし（商品IDの一部として利用される場合がある）
Barcode（JAN/EAN）	`Variant Barcode`	GS1等の標準化団体	`gtin`
MPN	専用列なし	商品のメーカー	`mpn`
商品ID（id）	自動採番	Shopify	`id`（フィードアプリが変換）

ShopifyにはMPN専用の列がありません。そのため、フィードアプリ経由でMPNを送る場合は、SKU列やBarcode列、あるいはメタフィールドをMPNにマッピングすることになります。ここが「MPN missing」の混乱を生む原因です。

Merchant CenterがMPNを要求する条件

MPNはすべての商品で必須ではありません。Merchant Centerの商品データ仕様では、MPNが求められるのは以下の条件を満たす場合です。

MPNが必須になるケース

ブランド（brand属性）が設定されている
GTIN（JAN/EAN/UPCなど）が設定されていない、または取得できない
新品（condition = new）である

新品でブランドが明確な商品は、GTINとブランドとMPNの3つで商品を特定できることが求められます。GTINがない場合は、ブランド＋MPNの組み合わせで代替識別されます。

MPNが不要なケース

中古品・コレクター商品（condition = used, refurbished等）
オリジナルブランドでGTINもMPNも存在しない商品
identifier_exists属性をFALSEに設定できる商品

SKUをMPNとして使えるか

結論から言うと、SKUをそのままMPNとして送ることは可能ですが、条件があります。

SKUが「メーカーの型番」と一致している場合は、そのSKUをMPNにマッピングして問題ありません。たとえば、卸売業者から仕入れた商品のSKU列にメーカー型番をそのまま入れているケースがこれに該当します。

SKUが店舗独自の管理番号である場合は、それをMPNとして送ると誤った識別情報を提供することになります。たとえば「A-001」「B-023」のような社内コードはMPNとしては認識されず、かえってデータ品質を下げる可能性があります。

判断のフロー

商品にGTIN（JAN/EAN）がある → GTINを送ればMPNは任意
GTINがないが、メーカー型番が分かる → その型番をMPNとして送る
GTINもメーカー型番もない（オリジナル商品等） → identifier_existsをFALSEに設定する

identifier_existsをFALSEにするタイミング

identifier_exists属性は、商品に標準的な識別子（GTIN・MPN・ブランド）が存在するかどうかをGoogleに伝えるための項目です。

TRUE（デフォルト）：GTIN、MPN、ブランドのいずれかが存在する
FALSE：これらの識別子が存在しない

以下のような商品ではidentifier_existsをFALSEにすることで、MPN missingの警告を回避できます。

自社製造のハンドメイド商品
オリジナルデザインのノベルティ
古いアンティーク品でメーカー型番が不明なもの
セット商品で単一のMPNが存在しないもの

フィードアプリの設定画面で、identifier_existsを一括でFALSEに設定する機能がある場合は、該当商品だけに適用されるよう条件設定に注意してください。

Shopifyでの確認手順

Step 1：Variant SKU列とVariant Barcode列を確認する

ShopifyのProducts CSVをエクスポートし、Variant SKU列とVariant Barcode列を確認します。

Variant Barcodeに13桁の数字が入っている → JANコードの可能性が高い。GTINとして送れるか確認
Variant SKUにメーカー型番らしい文字列が入っている → メーカーのカタログや商品パッケージと照合してMPNとして使えるか判断
どちらも空欄、または社内コードしかない → identifier_exists = FALSEの検討

Step 2：メーカー型番の有無を確認する

仕入先の商品ページ、メーカーの公式サイト、商品パッケージを確認し、メーカーが付与した型番が存在するかを調べます。型番が見つかれば、それをCSVのメタフィールド列などに追記してMPNにマッピングします。

Step 3：フィードアプリのマッピング設定を確認する

Google & YouTubeチャネルやサードパーティのフィードアプリで、mpn属性にどのShopify列をマッピングしているかを確認します。マッピング先が空欄の場合、Merchant Center側でMPN missingの警告が出ます。

自動チェックと手動確認の分離

MPNの対応は、CSVの分析で機械的に進められる部分と、商品ごとの実態確認が必要な部分に分かれます。

自動チェックで対応できること

Variant Barcode列の空欄検出（GTIN不足の洗い出し）
Variant SKU列のパターン分析（社内コードかメーカー型番かの推定）
identifier_existsの未設定検出
MPN未設定商品の一覧出力

人間の判断が必要なこと

SKUに入っている値がメーカー型番か社内コードかの判定
メーカー型番が存在するかどうかの調査（カタログ・パッケージ確認）
identifier_exists = FALSEにしてよいかどうかの判断
オリジナル商品か既製品かの分類

まずは自動チェックで「MPNが未設定の商品」と「GTINも未設定の商品」を洗い出し、そのリストをもとに手動でメーカー型番の有無を確認していく進め方が効率的です。

相談時に用意するとよい情報

MPN missingの警告でお悩みの際は、以下の情報を整理してからご相談ください。

取扱商品のおおよその点数と、警告が出ている商品の割合
商品の種類（既製品の仕入れか、オリジナル商品か、その混在か）
Variant Barcode列にJANコードが入っているかどうか
Variant SKU列に入っている値の性質（メーカー型番か社内コードか）
使用しているフィードアプリの名称
現在identifier_exists属性を設定しているかどうか

初回相談では機密CSVやスクリーンショットの送付は不要です。商品の種類と現在のデータ状況が大まかに分かれば、まずは対応方針の整理から始められます。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

商品フィードの診断で最初に見るべき列一覧

Merchant Centerの診断画面で「不承認」や「警告」が増えているのに、どの列から手をつければよいか迷うことは少なくありません。フィードCSVの列は数十ありますが、承認に直結するのはそのうちの一部です。この記事では、商品フィードを初めて確認するときに見るべき属性を優先順位付きで整理し、エラーと警告の違いも説明します。

フィード列の優先順位一覧

フィードCSVを開いたとき、まず確認するべき列を優先順位順にまとめました。上から順に見ていくと、承認をブロックする問題を効率よく洗い出せます。

優先度	属性名	確認内容	空欄・不備の影響
1	`id`	一意の商品IDが入っているか。重複がないか	不承認または掲載制限の原因になりやすい
2	`title`	商品名が空欄でないか。30〜150文字以内か	不承認または掲載制限の原因になりやすい
3	`image_link`	画像URLが正しくアクセスできるか	不承認または掲載制限の原因になりやすい
4	`price`	通貨コード付きの正しい形式か（例: 1980 JPY）	不承認または掲載制限の原因になりやすい
5	`availability`	`in stock` / `out of stock` / `preorder`のいずれか	警告 → 表示制限の原因になりやすい
6	`link`	商品ページURLとして正しいか。リダイレクトがないか	不承認または掲載制限の原因になりやすい
7	`gtin`	JANコード等のグローバル識別子。該当カテゴリでは必須	警告 → 一部カテゴリで不承認の原因になりやすい
8	`brand`	ブランド名。gtinとセットで確認	警告 → ブランド必須カテゴリで不承認の原因になりやすい
9	`description`	商品説明が空欄でないか。titleと重複していないか	警告 → 品質スコア低下の原因になりやすい
10	`condition`	`new` / `refurbished` / `used`のいずれか	警告 → 省略時はnew扱い
11	`mpn`	メーカー品番。gtinがない場合の代替識別子	警告 → gtinがない商品で推奨

優先度1〜6は、空欄や形式エラーがあると掲載できない、または掲載が制限されることがあります。まずはこの6列を確認し、問題がなければ7以降の列に進むという手順が効率的です。

エラーと警告の違い

Merchant Centerの診断画面では、問題が「エラー」と「警告」の2種類に分かれます。扱いが異なるため、まずはこの違いを押さえておきましょう。

エラー（不承認を引き起こすもの）

商品が掲載されなくなる重大な問題です。idの重複、priceの形式不正、image_linkの404などが該当します。Merchant Centerの診断画面では赤いアイコンで表示され、対象商品数も表示されるため、まずはエラー数が0になることを目指します。

警告（掲載はされるが品質に影響するもの）

商品自体は掲載されますが、広告の表示機会が減る可能性があります。descriptionが短すぎる、gtinが未設定、brandが空欄などが該当します。診断画面では黄色いアイコンで表示されます。すべての警告を0にする必要はありませんが、主要商品の警告は優先的に直すのがよいです。

Shopify側で確認すべき対応列

フィードアプリは、Shopifyの商品データをMerchant Centerの属性に変換して送信します。どのShopify列がどの属性にマッピングされているかを知っておくと、修正箇所がすぐに見つかります。

Merchant Center属性	Shopify側の対応列（目安）	主なマッピング元
`id`	`Variant SKU` または商品ID	フィードアプリの設定による
`title`	`Title` + `Option1 Value` など	商品タイトルがそのまま使われることが多い
`image_link`	`Image Src` または `Variant Image`	アプリによってマッピングが異なる
`price`	`Variant Price`	販売価格がそのまま送られる
`availability`	`Variant Inventory Qty`	在庫数 > 0 で in stock
`gtin`	`Variant Barcode`	バーコード（JAN/EAN）欄
`brand`	`Vendor` または `product.metafields`	ベンダー名またはメタフィールド

マッピングの実際はフィードアプリによって異なります。Google & YouTubeチャネル、Simprosys、FeedArmyなど、使っているアプリのフィードマッピング設定画面で確認してください。

初回フィード確認の進め方

フィードを初めて確認する場合、すべての列を一度に見る必要はありません。以下の手順で進めると効率的です。

Step 1：Merchant Centerの診断画面でエラーを確認する

Merchant Centerの [商品] → [診断] を開き、赤いアイコンのエラーだけを拾います。エラー名と対象商品数をメモしてください。「画像が見つかりません」「価格が無効です」「商品IDが重複しています」などのエラーが代表的です。

Step 2：1商品を抜き出してフィードCSVを確認する

エラーが出ている商品を1つ選び、フィードCSVまたはMerchant Centerの [商品] → 対象商品 → [属性] タブで、優先度1〜6の列を確認します。空欄、形式不正、URLの404を探してください。

Step 3：Shopify側の該当箇所を特定する

フィードで問題が見つかった属性に対応するShopify側の列を特定します。たとえばgtinが空欄なら、Shopify管理画面のバーコード欄（Variant Barcode）が未入力でないかを確認します。

Step 4：同じ問題が他の商品にもないか広げる

1商品で原因が分かったら、CSVの該当列を全体に向けて確認します。idの重複はCSVのピボットや条件付き書式で機械的に見つけられます。

自動チェックと人間の判断の分かれ目

フィードの確認作業は、一部を自動化できますが、すべてを機械的に判定できるわけではありません。

自動チェックで対応できること

idの空欄・重複検出
priceの形式チェック（数値 + 通貨コードの有無）
image_linkのURL形式チェックと404確認
availabilityの値が規定値（in stock / out of stock / preorder）に一致しているか
gtinの桁数チェック（JAN: 13桁、UPC: 12桁など）
title・descriptionの文字数カウント

人の判断が必要なこと

titleの内容が商品を適切に表しているか
image_linkの画像が実際にその商品を写しているか
descriptionの記載内容が正確か（他商品の説明の使い回しなど）
brandの登録名が正式なブランド名と一致しているか
商品カテゴリに応じたgtinの必須・任意判定

形式や空欄のチェックはツールで一括確認し、内容の妥当性はサンプリングして目視で確認する、という2段階の進め方が現実的です。

注意点

この記事はフィード確認の手順を整理するものであり、Merchant Centerの承認を保証するものではありません。Googleのポリシーや属性の要件は変更される可能性があるため、最新の公式ヘルプで確認してください。

また、フィードアプリごとにマッピング方式が異なるため、この記事に書いた対応列はあくまで目安です。実際のマッピングは、お使いのフィードアプリの設定画面で確認してください。

相談時に用意するとよい情報

Merchant Centerの診断画面に出ているエラー名と対象商品数
使用しているフィードアプリの名称（Google & YouTubeチャネル、Simprosys、FeedArmyなど）
Shopifyストアで扱っている商品のおおよその件数と対象国
特に気になっている属性（gtin未設定、image_linkの404など）
フィードCSVの該当行のid、title、price列の値（テキストで可）

初回相談では機密CSVやスクリーンショットの送付は不要です。エラー名、対象商品数、使っているフィードアプリ名だけでも相談できます。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

variant画像とフィード画像がずれるときに見るShopifyの商品画像設定

色違い・サイズ違いの商品を運用していると、Shopifyのvariant画像とMerchant Centerに表示される画像が一致しないことがあります。原因の多くはShopify側の画像紐付けと、フィードアプリがimage_link属性に代入するロジックのズレです。この記事では、Shopify管理画面のどの項目を確認し、フィードのどのカラムを照合すればよいかを整理します。

Shopifyでvariant画像を設定する3箇所

Shopifyの商品画像は、商品（Product）レベルとバリエーション（Variant）レベルの2段階で管理されています。まずはShopify側の設定箇所を押さえておきましょう。

商品画像セクション（Product images）

管理画面の [商品] → 対象商品を開く → [メディア] セクションで登録した画像が商品全体の画像として扱われます。ここにアップロードした画像には内部でProduct Image IDが付与され、CSVではImage Src列にURLが入ります。

ポイントは「アップロード順」です。Shopifyは基本的にアップロード順＝並び順として扱うため、意図した順番で登録されていないと、最初の画像が自動的に代表画像になります。

Variant Image の紐付け

各バリエーション（色・サイズなど）には、[バリエーション] セクション → 対象variantの編集 → [プレビュー画像] で特定の商品画像を紐付けられます。CSVでいうとVariant Image列にImage Srcと同じURLを入れることで紐付けが成立します。

ここが空欄のvariantは、商品の1枚目の画像（代表画像）が自動的に割り当てられます。これが「フィード画像がずれる」一番よくある原因です。

Image Alt Text

Image Alt Text列は画像の代替テキストです。フィードアプリの中には、このAlt Textをキーワードとして画像を自動振り分けするものがあります。Alt Textが未設定、あるいは色名と一致していない場合、アプリ側の判定ロジックが誤動作を起こすことがあります。

フィードアプリが画像を拾う仕組み

ShopifyからMerchant Centerへ商品データを送るフィードアプリ（Google & YouTubeチャネル、Simprosys、FeedArmyなど）は、それぞれ画像の取得ロジックが異なります。大きく分けると以下の2パターンがあります。

パターンA：Product Imageの先頭をimage_linkにする

商品レベルで登録した画像の1枚目をimage_linkに、2枚目以降をadditional_image_linkに送る方式です。variantごとの画像紐付け（Variant Image）を参照しないため、Shopify側できちんと紐付けていてもフィード側ではすべて同じ代表画像が送られます。

パターンB：Variant Imageをimage_linkにする

ShopifyのVariant Image設定を参照し、そのvariantに紐付いた画像をimage_linkとして送る方式です。この方式ではVariant Imageが正しく設定されていないと、意図しない画像がMerchant Centerに表示されます。

どちらのパターンを採用しているかは、フィードアプリのマッピング設定画面で確認できます。Google & YouTubeチャネルの場合は、商品データの詳細画面でimage_linkの値を直接確認可能です。

画像ずれの原因チェックリスト

実際に画像がずれているケースで確認すべき項目を表にまとめました。自動で判定できるものと、目視での確認が必要なものを分けています。

確認項目	確認方法	自動 / 目視
`Variant Image`列が空欄でないか	CSVエクスポート → `Variant Image`列を確認	自動判定可
`Image Src`のURLと一致しているか	`Variant Image`と`Image Src`のURLを突合	自動判定可
画像のアップロード順が正しいか	管理画面のメディアセクションで順序確認	目視
`Image Alt Text`に色名が含まれているか	CSVの`Image Alt Text`列を確認	自動判定可
フィードアプリのimage_linkマッピング設定	アプリ管理画面 → フィードマッピング	目視
Merchant Centerのimage_link値	MC管理画面 → 商品 → 属性確認	目視
CDNキャッシュの影響	画像URLに直接アクセスして確認	目視

上3つ（Variant Imageの空欄、URL不一致、Alt Textの欠落）はCSVの比較で機械的に洗い出せます。下4つは管理画面を開いて確認する必要があります。

実際の確認手順

Step 1：CSVでVariant Imageの紐付けを確認する

Shopify管理画面から [商品] → [エクスポート] でCSVをダウンロードします。Variant Image列とImage Src列を並べて確認し、以下をチェックします。

Variant Imageが空欄のvariantがないか
Variant ImageのURLが、実際にその色・サイズに対応したImage SrcのURLと一致しているか

空欄が見つかった場合は、該当variantの編集画面でプレビュー画像を手動で設定します。

Step 2：フィードアプリ側のimage_linkを確認する

Google & YouTubeチャネルを使っている場合、[販売チャネル] → [Google] → [商品データ] から個別商品を開き、image_link属性にどのURLが入っているかを確認します。

サードパーティのフィードアプリの場合は、アプリ管理画面のプレビュー機能またはTest Feed機能で、実際に送信されるXML/CSVのimage_linkカラムを確認します。

Step 3：Merchant Center側と突き合わせる

Merchant Centerの [商品] → 対象商品 → [属性] タブでimage_linkの値を確認し、Step 2で確認したフィード出力値と一致しているかを見ます。ここで不一致がある場合は、フィードアプリの送信とMerchant Centerの受信の間で何らかの変換が起きている可能性があります。

よくある落とし穴

画像を差し替えたのにフィードに反映されない

Shopifyで画像を差し替えるとImage SrcのURLが変わりますが、フィードアプリ側でキャッシュが残っている場合、古いURLが送られ続けることがあります。この場合、フィードアプリ側で手動リフレッシュ、あるいはMerchant CenterでコンテンツAPI経由の再取得を待つ必要があります。

Variant Gramsの確認

Variant Gramsは配送重量の確認項目であり、画像ずれの主因としては扱いません。画像ずれではVariant Image、Image Src、フィード側のimage_link、アプリの画像マッピング設定を優先して確認します。重量や配送条件の確認は、画像ではなく配送・送料関連の警告を調べるときに分けて扱います。

additional_image_linkの上限

Merchant Centerのadditional_image_linkは最大10枚までです。Shopify側に11枚以上の画像を登録していても、11枚目以降はフィードで送られません。その結果、特定のvariantに紐付けていた画像がadditional_image_linkに含まれず、image_linkだけが参照されるケースがあります。

自動化できる部分と人の判断が必要な部分

画像ずれの調査は、一部を自動化できますが、すべてを機械的に解決できるわけではありません。以下の通り整理します。

自動チェックで対応できること

Variant Image列の空欄検出
Image SrcとVariant ImageのURL不一致検出
Image Alt Textの未設定・重複検出
additional_image_linkの10枚超過アラート

人の判断が必要なこと

画像自体が正しい色・サイズを写しているか（画像内容の妥当性）
アップロード順の意図的な変更（代表画像の選択）
フィードアプリのマッピング方式の選択（パターンAかBか）
Alt Textの文言が色名として適切か

CSVの突合で機械的に問題を洗い出したあと、人間が画像内容を確認して最終判断を下す、という2段階の運用が現実的です。

相談時に用意するとよい情報

ずれが発生している商品のShopify商品タイトル（またはハンドル）
使用しているフィードアプリの名称（Google & YouTubeチャネル、Simprosys、FeedArmyなど）
Merchant Centerで実際に表示されているimage_linkのURL
Shopify側で意図している画像URL（該当variantのVariant Image値）
CSVエクスポート時の該当行（Handle、Variant Image、Image Src列）

初回相談では機密CSVやスクリーンショットの送付は不要です。上記の情報がテキストで分かれば、まずは現状の整理から始められます。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

Google Shopping向け商品タイトルを直す前に、Shopifyの商品名で確認すること

Google Shoppingで「商品タイトルを直したい」と思ったとき、Merchant Center側だけをいじり始める前にやることがあります。それはShopify側の商品名がどうなっているかを確認することです。商品名の構造が分かっていなければ、どこを直すべきか判断できません。この記事では、Shopifyの商品名関連フィールドを整理し、Google Shoppingのtitle属性とどう関係するかをまとめます。

Shopifyの商品名に関わるフィールド

Shopifyで商品を登録するとき、タイトルに関係する主なフィールドは次の通りです。

フィールド（管理画面）	CSV列名	役割
タイトル	Title	商品ページの見出し。Googleのtitle属性に反映されやすい
ベンダー（ブランド）	Vendor	メーカーやブランド名。Googleのbrand属性に対応
商品カテゴリ	Product Category	Googleの商品カテゴリ分類とは別物。Shopify独自分類
オプション1名	Option1 Name	バリエーションの軸（例：Color、Size）
オプション1値	Option1 Value	バリエーションの具体的値（例：Red、M）

Google Shopping向けに「title」を直そうとするとき、まずこのCSVの「Title」列がどうなっているかを確認します。ここにブランド名が含まれているか、色・サイズが入っているかによって、Merchant Center側で足すべき情報が変わります。

titleに入れるべき情報と、別属性に分ける情報

Googleのtitle属性には、次の情報を含めることが推奨されています。

ブランド名
商品名（製品名）
型番・品番
色
サイズ
材質（必要な場合）
性別・年齢層（アパレルなど）

ただし、すべてをtitleに詰め込めばよいわけではありません。色、サイズ、材質などはGoogle側で専用の属性（color、size、material）として登録するため、title内での重複は必須ではありません。とはいえ、検索でのマッチングを考えると、titleにも主要なバリエーション情報を含めるほうがクリック率は上がりやすい傾向があります。

titleに含めるべき情報の優先順位

優先度	情報	理由
高	ブランド名	ブランド検索でのマッチングに直結
高	製品名（モデル名）	商品の特定に必須
中	型番・品番	精度の高い検索で有利
中	色	バリエーション区別・検索マッチング
低〜中	サイズ	カテゴリによる。アパレルは中、それ以外は低
低	材質・その他	補助情報

ブランド名の配置パターン

Shopifyの「Title」列にすでにブランド名が含まれている場合と、含まれていない場合で対応が変わります。

パターンA：Titleにブランド名が含まれている例

Title: "BrandX ワイヤレスイヤホン BX-200 Black"
Vendor: "BrandX"

この場合、Google側のbrand属性はVendorから、title属性はTitleから自動で反映されることが多いです。タイトル内のブランド名が冗長になる可能性がありますが、検索マッチングの観点からは残して問題ありません。

パターンB：Titleにブランド名が含まれていない例

Title: "ワイヤレスイヤホン BX-200 Black"
Vendor: "BrandX"

この場合、brand属性はVendorから補われますが、title内にブランド名がないため、ブランド検索での表示機会が減る可能性があります。titleの先頭にブランド名を追加するか、Merchant Centerの商品フィード補正ルールで追加するかを検討します。

バリエーション（色・サイズ）の取り扱い

Shopifyでは、バリエーションごとにOption1 Name / Option1 Value（必要に応じてOption2、Option3）を設定します。Google Shoppingに送られるtitle属性には、通常、親商品のTitleがそのまま使われます。

バリエーションごとに色やサイズをtitleに含めたい場合、次の点を整理します。

Shopify側では、親商品のTitleと各variantのoption値（Color、Sizeなど）を分けて管理するのが基本です
バリエーションごとにtitleへ色・サイズを反映したい場合は、フィードアプリの設定、Merchant Centerのフィードルール、またはアプリ側のタイトル生成ルールで対応します
Shopify CSVでvariant行のTitle列に個別のタイトルを入力する方法は推奨されません。親商品のTitleが上書きされたり、フィード連携で不整合が起きる原因になるためです

アパレルや靴など色・サイズでの検索が多いカテゴリでは、バリエーション情報をtitleに含めることが特に重要です。Googleのポリシーでも、アパレルカテゴリの商品はtitleに色とサイズを含めることが強く推奨されています。

titleの文字数について

Googleのtitle属性は最大150文字まで登録できますが、検索結果に表示されるのは先頭から約70〜80文字程度です。重要な情報は前半に配置するのが基本です。

推奨する配置順序

[ブランド名] [製品名・モデル名] [型番] [色] [サイズ] [その他]

長すぎるtitleは末尾が省略されるだけなので登録自体は可能ですが、管理のしやすさも考えると100文字以内に収めるのが実用的です。

自動チェックと人間の判断の分担

titleの改善にあたって、機械的に確認できることと、運用者の判断が必要なことを分けておきます。

自動チェックで確認できること

titleが空ではないか
150文字を超えていないか
ブランド名がtitle内の先頭付近にあるか（brand属性値との照合）
アパレルカテゴリでcolor属性やsize属性が設定されているか
「新品」「送料無料」などのプロモーション用語が含まれていないか（ポリシー違反）

人間の判断が必要なこと

titleの自然な読みやすさ
競合との差別化に必要な情報の取捨選択
ブランド名をtitleに含めるかどうか（含まれていなくてもbrand属性があればGoogle側で補完される）
色やサイズをtitleに含めるか、属性のみにするか
カテゴリごとの顧客検索行動に合わせた情報の並び順

相談時に用意するとよい情報

Google Shoppingのタイトル改善について相談する場合、以下の情報があると話が進めやすくなります。

対象商品の数（おおよその件数で構いません）
現在のShopify商品名（Title列）の代表的な例を数点
Google Merchant Centerで警告や不承認が出ているかどうか
対象商品のカテゴリ（アパレル、家電、雑貨など）
タイトル修正をShopify側で行うか、フィードルールで行いたいかの希望
現在使っているGoogle連携アプリ（Shopifyアプリの有無）

初回相談では機密CSVやスクリーンショットの送付は不要です。商品名の例をいくつかテキストで共有いただければ、大まかな修正方針の検討が可能です。

まとめ

Google Shoppingのタイトル改善は、まずShopify側の商品名構造を確認することから始まります。Title列に何が含まれ、何が欠けているかを把握すれば、Merchant Center側で補うべき情報が見えてきます。ブランド名、型番、色、サイズのそれぞれがどこにあり、どこにあるべきかを整理してから修正範囲を決めることで、効率よくタイトルの品質を上げられます。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

商品説明文をMerchant Center向けに見直すときの注意点

Shopifyの商品説明（Body HTML）をそのままMerchant Centerのdescription属性に送ると、HTMLタグの残渣や文字数不足で警告が出ることがあります。本稿では、CSV上のBody HTML列をMerchant Center向けに整形するときの確認ポイントを整理します。手作業で見直すべき項目と、フィードアプリ側で自動処理できる部分に分けて解説します。

Merchant Centerがdescription属性で見ていること

Merchant Centerは商品説明文を通じて、以下の3点を確認しています。

商品そのものの説明になっているか
ユーザーが購入判断できる情報が含まれているか
誇大表現や無関係なプロモーション文が混ざっていないか

description属性は必須項目ではありませんが、未設定の場合は「品質の低い商品」扱いになりやすく、無料リスティングや広告の表示機会に影響します。

Shopify CSVのBody HTML列とMerchant Centerのdescriptionの違い

ShopifyのProducts CSVでは商品説明が「Body HTML」列に出力されます。この列にはリッチテキストエディタで入力したHTMLタグがそのまま含まれます。

Merchant Center側ではdescription属性としてプレーンテキストに近い形が求められます。主な違いは次のとおりです。

項目	Shopify Body HTML	Merchant Center description
HTMLタグ	<p>、<ul>、<strong>等がそのまま入る	対応タグ（<br>等）以外は無視または警告対象
文字数の目安	制限なし（実務上は数千文字以内が多い）	1,000文字〜5,000文字が推奨範囲
販売促進文	自由に入力可能	「期間限定」「送料無料」等のプロモーション表記は不可
言語	自由	ターゲット国の言語と一致させる必要がある

よくある不承認・警告パターン

文字数が短すぎる

「Tシャツ」「青色」など数単語だけのdescriptionは、Merchant Centerから「説明が不十分」とみなされます。素材、サイズ、用途など、商品の特徴をある程度詳しく書く必要があります。

プロモーション文が含まれている

「今だけ半額」「レビュー投稿でポイント還元」といった販売促進文はdescriptionに入れないでください。セール情報はpromotion_idやセール価格で別途設定します。

言語がターゲット国と合っていない

日本向けフィードなのにdescriptionが英語のままだと、言語不一致で警告が出ます。Shopify側で多言語対応している場合は、フィード出力時に適切な言語版を選択できているか確認します。

HTMLタグが壊れている

Body HTML内に閉じタグのないや、のインラインスタイルが残っていると、Merchant Center側でパースエラーを起こすことがあります。

自動処理と手動確認の分離

フィード連携アプリ（Google & YouTube Channel等）は、Body HTMLから特定のHTMLタグを除去してdescriptionにマッピングする機能を持っています。ただし、すべてのアプリが同じ処理をするわけではありません。

アプリ側で自動処理できること

、<div>、等の構造タグの除去
 の改行変換
HTML実体参照（&等）のデコード
文字数の切り詰め（上限超過時）

人間が手作業で見直すべきこと

プロモーション文の有無
商品実態と説明文の整合性
ターゲット国の言語で書かれているか
説明文として十分な情報量があるか

自動処理に頼り切るのではなく、最初の1回は全商品のdescriptionを目視で確認することをお勧めします。

見直しの手順

Shopify管理画面からProducts CSVをエクスポートする
Body HTML列をテキストエディタに貼り付け、HTMLタグを可視化する
プロモーション表記・無関係なテキストを削除する
商品の素材・サイズ・仕様などの事実情報が含まれているか確認する
ターゲット言語で記述されているか確認する
文字数が1,000文字以上あるか確認する（不足していれば補完する）
Merchant Centerに反映後、管理画面の「商品」タブで警告が出ていないか確認する

この手順は一度だけ実施すればよいわけではなく、新商品の追加時や説明文の大幅変更時には都度確認が必要です。

相談時に用意するとよい情報

Merchant Centerのdescription周りでお悩みの際は、以下の情報を整理してからご相談ください。

Merchant Center管理画面に表示されている警告メッセージの内容
対象商品のおおよその点数とカテゴリ
現在利用しているフィード連携アプリの名称
descriptionの入力元（Shopifyの商品説明をそのまま使っているか、別途用意しているか）
ターゲット国（日本国内のみか、海外向けも含むか）

初回相談では機密CSVやスクリーンショットの送付は不要です。商品名やカテゴリなどの大まかな情報だけでも相談可能です。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日

セール価格と通常価格をShopifyとMerchant Centerで合わせるときの確認項目

Shopifyでセール価格を設定するとき、Variant Compare At Price（通常価格）とVariant Price（販売価格）の関係をGoogle Merchant Centerのpriceとsale_priceに正しく反映させる必要があります。通貨コードの表記、税込み・税抜きの扱い、セール期間の開始・終了タイミングのズレなど、両プラットフォーム間で確認すべき項目を整理します。

ShopifyとMerchant Centerの価格属性の対応関係

まず、Shopifyの商品CSV・管理画面の価格項目が、Merchant Centerのフィード属性とどう対応するかを押さえておきます。

Shopifyの項目	CSV列名	Merchant Center属性	意味
価格（販売価格）	`Variant Price`	`sale_price`（セール時）または `price`（通常時）	顧客が実際に支払う金額
割引前価格	`Variant Compare At Price`	`price`（セール時）	セール前の通常価格。セール中でなければ空欄

セールを実施している間は、ShopifyのVariant Compare At PriceがMerchant Centerのprice属性に、Variant Priceがsale_price属性に送られるのが基本です。セールが終了してCompare at Priceを空欄に戻すと、Variant PriceがMerchant Centerのpriceとして送られ、sale_priceは空になります。

通貨コードと価格フォーマット

日本国内向けに運用している場合、両プラットフォームで通貨の扱いを統一する必要があります。

確認項目	Shopify側	Merchant Center側	注意点
通貨コード	ストア設定で`JPY`	フィードまたは手動入力で`JPY`	異なる通貨コードを混在させると不承認になる
小数点の有無	`2980`または`2980.00`	`2980 JPY`（通貨コード付き推奨）	Shopifyは小数なしでも可。Merchant Centerは数値＋通貨コードの形式
税込み・税抜き	ストア設定で「税を含む」かどうかを指定	フィード仕様上は税抜・税込どちらも可だが、表示と整合させる	Shopifyが税込価格を送信しているのにMerchant Center側で税抜として扱うとズレる
カンマ区切り	カンマなし（`2980`）	カンマなし（`2980`）	`2,980`のようにカンマを含めるとパースエラーになる

日本のストアでは、Shopifyの設定で「価格に税を含める」を有効にしていることが多く、その場合はCSVのVariant Priceも税込金額として扱われます。Merchant Center側でも同じ税込金額がそのままpriceやsale_priceに渡るため、税抜き金額と混同しないように注意してください。

セール期間のタイミングズレ

Merchant Centerではsale_price_effective_date属性でセールの開始日時と終了日時を指定できます。一方、Shopify側ではセール価格の開始・終了を自動セール（自動ディスカウント）や手動価格変更で管理します。この2つのタイミングがずれると、次のような問題が起きます。

Shopify側が先にセール価格になってしまった場合

ShopifyではすでにVariant Priceがセール価格に切り替わっているのに、Merchant Centerのフィード更新が追いついていないと、広告には通常価格が表示される一方で、ショップにはセール価格が表示されるというズレが生じます。顧客が広告をクリックしてショップに来たとき、期待した価格と違う印象を与える可能性があります。

Merchant Center側の期間が先に終了してしまった場合

sale_price_effective_dateの終了日時が過ぎると、Merchant Centerは自動的にsale_priceを無効化しpriceだけの表示に戻ります。しかしShopify側ではまだセール価格のままである場合、広告に通常価格が表示され、ショップではセール価格が継続している状態になります。

推奨する期間設定の考え方

sale_price_effective_dateの開始日時は、Shopifyでセール価格を設定する時刻と同じか、少し遅らせて設定する
終了日時は、Shopify側で価格を戻す時刻と同じか、少し早めに設定する
フィードの取得頻度（毎日・毎時など）を考慮し、最低でもフィード取得間隔分の余裕を持たせる

Compare at Priceのマッピングで起こりやすい間違い

ShopifyのVariant Compare At PriceとMerchant Centerの属性の対応で、よくある設定ミスをいくつか挙げます。

よくある間違い	何が起きるか	正しい対応
Compare at Priceを設定していないのに`sale_price`を送っている	Merchant Centerで「通常価格がないのにセール価格がある」という警告、または`price`と`sale_price`が同額のまま不承認	`sale_price`を送るなら必ず`price`（通常価格）も送る。Shopify側でCompare at Priceを必ず設定する
セール終了後もCompare at Priceを残したままにしている	Merchant Centerがセールが継続中と判断し、広告にセール価格として表示され続ける	セール終了時にCompare at Priceを空欄に戻す
PriceとCompare at Priceが同額	Shopifyの画面ではセール扱いにならず、Merchant Center側でも`price`と`sale_price`が同額になり警告が出る	Compare at Price > Price の関係を保つ
CSVの`Variant Price`列に通貨記号を含める	Shopifyのインポートで数値として認識されずエラー	数字のみ（`2980`）で入力する

セール終了時の価格の扱い

セールが終了したあとの価格の扱いは、運用フローの中で見落とされがちです。セール終了時に確認すべきことを整理します。

Compare at Priceを空欄に戻す: Shopify管理画面またはCSVで、Variant Compare At Priceをクリアする。これを忘れるとMerchant Centerはセール継続中と判断する。
Variant Priceを通常価格に戻す: 自動ディスカウントを使っている場合は自動的に戻るが、手動で価格を下げていた場合は手動で元に戻す必要がある。
フィードの次回取得タイミングを確認する: Merchant Centerのフィードが次に取得されるまで、広告上の価格表示に反映されない。急ぐ場合は手動でフィードを取得する。
Merchant Centerの「価格」診断を確認する: 終了後もsale_priceが残っている商品がないか、Merchant Center管理画面の診断で確認する。

自動で確認できる項目と人の判断が必要な項目

自動でチェックできる項目

スプレッドシートの関数やスクリプトで機械的に確認できる項目です。

チェック項目	確認方法	期待される結果
`Variant Price`が数値のみ	正規表現 `^[0-9]+(.[0-9]{1,2})?$`	通貨記号やカンマを含まない数値
`Variant Compare At Price` > `Variant Price`	両列の数値を比較	Compare at Priceの方が常に大きい
通貨コードの一致	Shopifyストア設定とMerchant Centerフィード設定を照合	両方で`JPY`
`sale_price`が`price`より小さい	Merchant Centerフィードの該当属性値を比較	sale_price < price
価格のカンマ区切りがない	値にカンマが含まれていないか検索	カンマなしの数値文字列

人の判断が必要な項目

セールの開始・終了日時の決定: マーケティング施策の都合で変更されることがあり、自動化しにくい。
税込み・税抜きのどちらで運用するか: ストアの価格表示方針に関わるため、運用ルールとして決めておく必要がある。
複数通貨対応が必要かどうか: 海外向けにも販売している場合、通貨ごとに価格を設定するか、為換算に任せるかの方針決定が必要。
Compare at Priceとして表示する「通常価格」の根拠: 過去30日間の最低価格などのルールが地域の法規に関わることがある。
セール終了後の価格戻し忘れの確認: 自動ディスカウントを使っていない場合、手動で戻す必要があるため、終了日の運用カレンダー管理が必要。

ShopifyとMerchant Center間の価格確認チェックリスト

セール設定の前後で確認すべき項目をまとめます。

No.	確認項目	確認手段
1	Shopifyの`Variant Price`がセール価格に更新されている	管理画面またはCSV
2	`Variant Compare At Price`に通常価格（セール前の価格）が設定されている	管理画面またはCSV
3	Compare at Price > Price の大小関係が正しい	数値比較
4	通貨コードがShopify・Merchant Center双方で一致している	両方の設定画面
5	価格に通貨記号・カンマが含まれていない	CSVの該当セルを確認
6	税込み・税抜きの扱いが両プラットフォームで統一されている	ストア設定とフィード設定を照合
7	`sale_price_effective_date`の期間がShopify側のセール期間と一致している	フィードまたはMerchant Center管理画面
8	セール終了後にCompare at Priceを空欄に戻す予定が立てられている	運用カレンダー・タスク管理

相談時に用意するとよい情報

価格設定のズレやMerchant Centerの不承認で相談される際、次の情報があると状況の把握が早くなります。

対象商品のShopifyでのVariant PriceとVariant Compare At Priceの値（テキストで構いません）
Merchant Center管理画面の「診断」に表示されている該当商品のエラーメッセージ（テキストで構いません）
ストアの税設定（税込みか税抜きか）
使用しているフィードアプリまたは連携方法（Shopify公式アプリ、サードパーティ製アプリ、手動XMLなど）
セールの開始・終了の予定日時
対象商品の通貨と販売対象国

初回相談では機密CSVやスクリーンショットの送付は不要です。まずは概要をお知らせください。

参考にした公式情報

この記事の内容で困っている方へ

無料相談する

2026年6月2日