Merchant Center商品データ不承認をClaudeで直す手順 — 仕様と1行ずつ照合

Merchant Centerの商品データが不承認になったら、Claudeには「フィードの各行が仕様のどの条件に外れているか」を洗わせます。仕様の条件は属性ごとに文字数・許容値・形式が決まっているので、機械的に照合できる部分が大きい作業です。値を直したあとのアップロードと、ランディングページ側の確認は人の操作です。

広告文そのものが不承認になった場合はClaudeでGoogle広告の不承認を修正し再審査に出す手順が対象です。ここで扱うのは、ショッピング広告と無料リスティングに載せる商品データの不承認です。

不承認は「値の誤り」と「サイトとの食い違い」に分かれる

商品データ仕様の冒頭には、情報が不正確・不足していると不承認や利用資格の制限が起きると書かれています。よくある問題として挙がっているのは次のものです。

• Google商品カテゴリ[google_product_category]やGTIN [gtin]の値が正しくない
• バリエーション属性(商品グループID [item_group_id]、色[color]、サイズ[size])が無い、または誤っている
• 画質が低い
• フィードとウェブサイトのデータが競合している

前の2つはフィードの中だけで直せます。後の2つは、フィードの外にあるものと突き合わせないと分かりません。たとえば商品リンク[link]のページが404を返す、robots.txt にアクセスできないといった場合は、「商品ページを利用できない」という別の問題として扱われ、Googleがアクセスできるようになるまで商品は広告にも無料リスティングにも出なくなります。

Claudeに渡す3点を集める

診断の起点は、Merchant Centerの問題の詳細ページ(IDP)です。仕様のページには、商品に影響する問題の診断情報がここで確認できると案内されています。次の3点を揃えて渡すと、Claudeが推測で埋める場面が減ります。

1. 問題の詳細ページに出ている問題名と、影響を受けている商品のリスト
2. 該当商品のフィード行(CSVやTSVの抜粋。仕入れ値などの社外秘の列は外す)
3. 商品データ仕様のうち、問題名に関係する属性の節

仕様の全文は長いため、Claudeのプロジェクトに仕様ページの該当節だけを置き、「この節の条件だけを根拠にする」と指示しておく運用が扱いやすくなります。

不承認に直結しやすい条件の早見表

仕様のうち、フィードの値だけで判定できる条件を拾うと次の表になります。

属性名と許容値は英語で登録する決まりです。タイトルや説明文のような自由記述は、フィード内で同じ言語に揃えます。

照合スクリプトをClaude Codeに書かせる

行数が多いフィードは、チャットに貼るよりスクリプトにしたほうが漏れません。Claude Codeに「仕様の条件を表にして渡すので、フィードCSVを検査するPythonを書いて」と頼み、出てきたスクリプトを手元のサンプルで必ず動かして確かめます。次は、上の表の条件を検査する形で書かせたスクリプトを、わざと誤りを混ぜた3行のCSVに実行した例です。

python3 check_feed.py sample.csv

行3 id=A002: title/description: 宣伝文の疑い
行3 id=A002: link: http(s)で始まっていない
行3 id=A002: availability: 許容値外 -> 在庫あり
行3 id=A002: price: 「数字 ISO4217コード」形式でない、または0
行3 id=A002: condition: 許容値外 -> 新品
行3 id=A002: gtin: 桁数またはチェックディジット不正
行3 id=A002: brand: 「なし」系の値は登録しない
行4 id=A003: availability_date: preorderなのに無い/形式不正
行4 id=A003: brand/gtin/mpn: すべて空でidentifier_existsもno以外

ヘッダー行を1行目と数えるため、データ1件目(A001)は行2で指摘なし、2件目(A002)が行3、3件目(A003)が行4と表示されます。指摘が並ぶのはA002とA003の2件です。スクリプトの核になるのはGTINのチェックディジット検算で、末尾以外の桁に右端から3・1・3・1の重みを掛けて合計し、10との差で末尾を割り出します。

def gtin_ok(v):
    if not v.isdigit() or len(v) not in (8, 12, 13, 14):
        return False
    body, check = v[:-1], int(v[-1])
    total = sum(int(d) * (3 if i % 2 == 0 else 1)
                for i, d in enumerate(reversed(body)))
    return (10 - total % 10) % 10 == check

この検算で分かるのは桁と検査桁の整合までです。その番号が本当にその商品のGTINかどうかは判定できないので、次の節の扱いが必要です。

カテゴリとバリエーション属性の誤り

冒頭の「よくある問題」のうち、Google商品カテゴリとバリエーション属性もフィードの値だけで検査できます。

google_product_category は省略可の属性ですが、入れるなら条件があります。

• カテゴリは1つだけ指定する。最も関連性の高い、その商品に固有のカテゴリを選ぶ
• 数字のカテゴリIDか、カテゴリのフルパスのどちらか一方で指定する。両方は指定できない。IDの利用が推奨されている
• アルコール飲料、ギフトカード、サービス契約つきのモバイル機器は、仕様で決まったカテゴリで登録する(ギフトカードはID 53)

Claudeに任せるなら、検査スクリプトで「IDとパスが両方入っている行」と「複数カテゴリを並べた行」を拾わせます。商品に最も合うカテゴリの判断は、Googleの商品分類の一覧と見比べて人が決めます。

バリエーション商品(サイズ違い・色違い)は、日本向けの販売で item_group_id が必須です。最大50文字で、可能なら親SKUを使い、更新のたびに同じIDを渡します。color は日本向けのファッション商品と色違いのある商品で必須、size は衣料品と靴、およびサイズ違いのある商品で必須です。

• 同じグループの全バリエーションで item_group_id と item_group_title を揃え、違いを表す color や size だけを変える
• color に数字、#fff000 のようなコード、1文字の値(全角1文字の日本語は可)、「マルチカラー」「N/A」のような色でない語を入れない。複数色は「赤/ピンク/青」と / で区切る
• size が複数の寸法を含むときは、「40/86トール」のように1つの値にまとめる

この3属性は「グループIDが揃っているか」「同じグループ内で色・サイズが重複していないか」まで、CSVを集計すれば機械的に判定できます。

画像の条件

画質の問題は、フィード側の image_link と画像ファイルそのものの両方で起きます。仕様が求める条件は次のとおりです。

• 商品のメイン画像を、httpまたはhttpsで始まるエンコード済みURLで指定する
• GooglebotとGooglebot-imageのアクセスを robots.txt で許可する
• 形式はJPEG、WebP、PNG、アニメーションでないGIF、BMP、TIFF
• 拡大した画像やサムネイル、プレースホルダや一般的な画像は不可
• 宣伝文、透かし、枠線を入れない
• 商品を正確に表示する

URLの形式とrobots.txtはスクリプトで見られますが、透かしや宣伝文が入っていないかは画像を見ないと判定できません。画像をClaudeに見せて確認させる方法はありますが、最終判断は人が行います。Claudeで生成・加工した画像は、AI生成を示すメタデータ(IPTC DigitalSourceType)を消さずに残す決まりです。

修正案を作らせるプロンプト

スクリプトの出力を、行ごとの修正案に変えるところでClaudeを使います。

添付のフィード抜粋と、検査スクリプトの出力を渡します。
商品データ仕様の次の節だけを根拠にしてください(貼り付け済み)。
- 指摘ごとに「仕様のどの条件か」「現在の値」「修正後の値」を表にする
- 値を決められない行は、修正後の値を空にして「要確認」と書く
- GTIN・MPN・ブランドは、元データにない値を補わない

「元データにない値を補わない」の一文が要です。仕様には、GTINは正しいと確信できる場合のみ指定し、迷うなら指定しない、間違ったGTINで登録した商品は不承認になるとあります。MPNも同じ扱いです。Claudeに空欄を埋めさせると、もっともらしい番号が出てきて、新たな不承認の原因になります。

直してはいけない・Claudeに決めさせない項目

• GTINとMPN: 仕入れ先の資料、パッケージ、メーカーのデータで裏を取ります。分からない商品は空欄のままにします。
• identifier_exists: GTINがある商品に no を設定すると、不承認になることがあります。空欄のときの既定値は yes です。
• 価格と在庫状況: 仕様は、ランディングページ・構造化データ・購入手続きの値との一致を求めています。フィードだけを直しても、サイト側とずれたままなら解消しません。
• 生成AIで作ったタイトルと説明: Claudeに書かせたタイトルや説明文をフィードに入れるときは、title や description ではなく structured_title と structured_description を使い、デジタルソースタイプに trained_algorithmic_media を指定する決まりです。通常の title にそのまま入れると、仕様に沿わなくなります。

最後の点は見落としやすいところです。Claudeで不承認の行を直したタイトルを、そのまま title 列に戻して再アップロードする運用は、仕様から外れます。

再アップロードとつまずきやすい点

修正後のデータは、元と同じ取り込み方法(ファイル、API、スプレッドシートなど)で再アップロードします。反映までには時間がかかるため、直後に問題が残って見えても、すぐに別の値へ書き換えない運用が安全です。

• 画像は、500×500ピクセル以上の要件が2027年1月31日に適用開始と案内されています。小さい画像の商品は、今のうちに洗い出しておけます。
• 有効期限[expiration_date]は、現時点から30日以内の日付を指定する決まりです。長く先の日付を入れていないか確かめます。
• 価格の通貨記号は、仕様の例が「15.00 USD」の形です。円建ての商品も、記号ではなく通貨コードで書く点は同じです。

「商品ページを利用できない」の問題は、IDPに出るエラーの種類で直す場所が変わります。

直したあとはウェブサイトの検証をリクエストすると、再審査が早まります。検証には12時間ほどかかり、その間は新しいリクエストを送れません。

不承認の原因が価格や在庫の食い違いだった場合は、ショップ側のデータを変える作業になります。商品データを整える作業全般は、ClaudeでShopifyのEC運営を回す方法やClaudeでCSVを集計する手順の考え方が土台になります。