Content API終了で商品更新が止まった？移行の確認手順

自社の通販サイトで在庫を変えたのに、Google側の商品情報が更新されない。自社開発の仕組みで商品を送っている店は、旧APIの終了による失敗が起きていないか確認が必要です。この記事では、EC責任者が開発担当と、移行の担当者・失敗の原因・最初の更新の確認順を決められるように説明します。[1]

APIは、システム同士が情報を受け渡す窓口です。Content API for Shoppingは、Googleの商品情報管理サービス「Merchant Center」へ商品などを送る旧来の窓口です。移行先のMerchant APIでも、店のシステムから商品情報の登録や更新を自動化できます。[2][6]

参照確認日：2026年9月14日。 参照版はContent API for Shopping v2.1と、Merchant APIの商品管理・アカウント管理のv1です。以下は、既存連携を持つ店が開発担当と移行を確認する手順であり、認証情報の新規発行から全商品移行までを完結させる実装手順ではありません。

1. 移行するのは自社か、連携サービスの提供者か

自社のプログラムが旧APIを直接呼んでいるなら、そのプログラムの変更が必要です。 外部サービスに商品連携を任せている場合は、その提供者がAPIの移行を担当します。例えば、通販サービスShopifyの「Google & YouTube」アプリによる商品連携は、利用店舗自身がAPIを移行する対象ではありません。[1][2]

EC責任者はまず、商品を送る処理の管理者を開発担当と確認します。「契約している連携サービスが送っているのか」「自社で動かしているプログラムが送っているのか」を分けてください。外部サービスだけを使っている店が、この記事を見て別の商品送信プログラムを新設する必要はありません。[1][2]

旧APIの公式な終了日は2026年8月18日です。ただし、その日に全通信が止まったわけではありません。9月1日から、有効な延長承認のない通信の一部が段階的に失敗する仕組みが始まっています。[1]

全面停止は2027年初めの予定です。この時期は移行状況によって見直される可能性があります。いま成功する通信があることを理由に、旧APIを使い続けられるとは判断できません。[1]

2. 410エラーが終了に伴うものか調べる

この確認では、更新が止まった原因が旧APIの終了措置かどうかを調べます。開発担当は、自社の商品連携プログラムの実行記録から、失敗した送信先URLとGoogleの返答を取り出します。EC責任者は、更新されなかった商品と日時を伝えると、該当する処理を探しやすくなります。

「HTTP 410 Gone」は、通信の失敗を知らせる返答です。番号だけで原因を決めず、Googleの終了案内にあるエラー説明と返答の内容を照合します。終了措置による返答には、理由を表す content_api_sunset と、呼び出したGoogle Cloudプロジェクトの情報が含まれます。[1]

Google Cloudプロジェクトは、APIの利用設定などをまとめる管理単位です。返答中の GCP_ID と GCP_NUMBER は、そのプロジェクトを特定する情報です。開発担当は自社の連携設定と照合し、どの送信処理を移す必要があるか確認します。[1]

失敗後の再送で成功する場合はありますが、再送を恒久対策にはできません。移行時間が足りない場合の入口は、終了案内内の「Content API extension request form」です。延長は承認された期間だけ終了措置によるエラーを免除するもので、2027年初めに予定される全面停止を越えて利用できる制度ではありません。[1]

3. 接続の準備と開発者登録を確認する

この段階では、新APIが「どの店に、誰の権限でアクセスするか」を確認します。開発担当は公式の初期設定ガイドを開き、Merchant Centerアカウント、Google Cloudプロジェクト、認証、開発者登録の準備状況を点検します。既存連携のアカウントや設定情報を使って、未完了の工程を特定します。[6]

認証は、商品を書き換える権限をGoogleに示すための準備です。開発者登録と商品送信には、OAuthという権限を許可する仕組みで、https://www.googleapis.com/auth/content の範囲が必要です。認証をまだ準備していない場合は、初期設定ガイドの「Set up authentication for Merchant API」を先に確認します。[4][6][7]

開発者登録は、呼び出しに使うGoogle CloudプロジェクトとMerchant Centerを結び付けます。対象はウェブサイトの確認が済んだ本番アカウントで、テストアカウントは登録できません。認証する利用者は対象アカウントへ直接追加されている必要があり、別アカウントを代理する形での登録はできません。親アカウントの認証で子アカウントを登録する方法も対象外です。[7]

条件を満たしたら、開発担当が開発者登録のREST v1仕様に沿って、既存プログラムから登録を呼び出します。RESTは、URLに対して送信や取得の操作を行う通信方式です。送信を表すPOSTの宛先は、https://merchantapi.googleapis.com/accounts/v1/accounts/{ACCOUNT_ID}/developerRegistration:registerGcp です。[7]

{ACCOUNT_ID} は、既存連携の設定で確認した対象店のMerchant Center IDに置き換えます。任意の連絡先項目 developerEmail には、通知を受け取る担当者のGoogleアカウントのメールアドレスを指定できます。プログラム用の認証主体であるサービスアカウントのメールは、通知先には使えません。既存ユーザーのメールを指定すると、そのユーザーにAPI開発者のアクセス権（API_DEVELOPER）が付与され、API通知の設定も更新されます。既存ユーザーでなければ、通知用の連絡先として追加されます。通知先だけでなく、権限を変更してよい担当者かも指定前に確認します。成功時には、DeveloperRegistration という登録情報が返ることを確かめます。[7]

なお、移行概要の説明例は developer_email と表記しています。一方、今回参照したREST v1の正式な送信項目は developerEmail です。RESTで送るデータは、後者の仕様に合わせます。[2][7]

4. 商品1件と、その商品の登録元を固定する

最初の検証では、別商品を作ったり、意図せず登録元を変えたりしないことを確かめます。ここからは、説明用の架空商品「ステンレスボトル500ml」が売り切れ、在庫ありから在庫なしへ更新する例で追います。実際の検証では、この架空商品を送らず、自社で販売している商品の正しい情報に置き換えてください。

商品の店側の識別番号は offerId と呼びます。この例では bottle-500 ですが、移行時は旧APIで使っていた同じ商品の番号を保ちます。商品情報の言語を表す contentLanguage は日本語の ja、商品を分類・識別するラベル feedLabel は説明用に JP とします。実際には、いずれも既存商品の値を確認して引き継ぎます。[5][8]

次に、商品の登録元を表す「データソース」を確定します。開発担当は最初の商品を送る公式ガイドで案内される dataSources.list、つまり登録元を一覧取得する操作で、対象アカウントの既存データソースを調べます。返ってきた識別用の name を保存し、どの商品がどの登録元を使うか対応させます。[3][5]

商品送信時に指定する項目名は dataSource です。値は accounts/{account}/dataSources/{datasource} という形式ですが、手で組み立てず、取得した name を使います。今回参照した商品送信のREST v1仕様では、入力種別が API のデータソースだけが対象です。公式サンプルの一部にあるファイル入力も使えるというコメントは、この仕様と一致しません。[3][4]

既存商品を違う登録元に送ると、その商品が新しい登録元へ移る場合があります。登録元ごとの変換ルールを使っている店は、処理後の商品を取得する products.get でも所属する dataSource を確かめます。対応が不明なまま、新しい登録元へ全商品を送り直さないでください。[4][5]

ここからは、対象商品の情報の土台となる、既存のメイン（primary）APIデータソースへ送る検証に限定します。補助情報を追加するデータソースは扱いません。新規作成が必要な場合、公式初回ガイドの作成例は本文とコマンド例で接続先の表記が異なるため、その相違を確認してから進めます。[3]

送信する元の情報は ProductInput、Googleがルールや補足情報を反映した後の商品は Product と呼びます。店が送った内容と、Google側で最終的に使われる内容を分けて確認できるのが、この構成の利点です。[5][8]

5. 正しい登録元へ、商品の入力情報を送る

この操作では、新APIが対象商品の入力を受け付けるか確かめます。開発担当は商品送信のREST v1仕様を開き、自社プログラムの送信先と送信項目を照合します。登録する操作名は productInputs.insert です。[4]

POSTの宛先は https://merchantapi.googleapis.com/products/v1/accounts/{ACCOUNT_ID}/productInputs:insert?dataSource={DATASOURCE_NAME} です。{ACCOUNT_ID} は対象店のID、{DATASOURCE_NAME} は前の工程で取得した登録元の name に置き換えます。登録元は商品情報の本文に混ぜず、URLに添える指定値として渡します。[4]

送信には、認証済みのアクセストークンという権限を示す値を、通信に付ける Authorization: Bearer の情報として渡します。商品情報の本文は、項目名と値を組にして書くJSON形式です。以下は構造を読むための説明用抜粋であり、実行用の完成データではありません。[3][4]

{
  "offerId": "bottle-500",
  "contentLanguage": "ja",
  "feedLabel": "JP",
  "productAttributes": {
    "title": "ステンレスボトル500ml",
    "availability": "OUT_OF_STOCK"
  }
}

productAttributes は商品名や在庫などの商品情報をまとめる場所です。商品名は title、在庫状態は availability に入れ、OUT_OF_STOCK は在庫なしを表します。初回ガイドの例にあるように商品名を name へ入れるのではなく、商品属性のREST仕様に合わせて title に入れます。[3][8][9]

この抜粋には、必須の識別項目である offerId、contentLanguage、feedLabel を含めています。ただし、価格、説明、商品ページURL、画像URLなどは省略しています。商品としての検査に必要な情報は商品データ仕様にも従うため、この短い例だけを本番へ送って掲載条件を満たせるとは判断しないでください。[8][9]

同じ商品の入力がある場合、insert は既存の入力を置き換える操作です。そのため、実際には元の商品情報を保ったうえで、在庫状態だけを正しい値に変えたデータを用意します。個別項目だけを変更する productInputs.patch もありますが、ここでは全体を再送する検証と混ぜずに扱います。[4][5]

6. 送信成功、処理後の値、次回更新を順に確かめる

送信の成功だけでは、更新の確認は終わりません。 productInputs.insert が成功すると返るのは、入力情報の ProductInput です。その中の name は入力側の識別名、product は後から取得する処理済み商品の識別名です。[4][8]

開発担当は返答の product を保存し、取得を表すGETで https://merchantapi.googleapis.com/products/v1/{name} を呼びます。ここでの {name} には、保存した product の値を入れます。説明用商品の場合は、accounts/{ACCOUNT_ID}/products/ja~JP~bottle-500 のような識別名になりますが、実際には返答の値を使ってください。[2][3][8]

商品番号自体に / や ~ などを含む場合は、そのままURLへ入れられません。返答の base64EncodedProduct は、特殊文字をURLで扱える形に変換済みの識別名なので、処理後の商品を取得する際に使えます。手作業で区切り文字を置き換える方法は避けます。[8]

処理後の商品が取得できるまで、数秒から数分かかる場合があります。取得できたら、同じ bottle-500 の在庫状態が OUT_OF_STOCK になっているか、登録元が予定した dataSource かを照合します。時間を置いても値が変わらなければ、送った商品番号・登録元・商品情報を再確認します。[3][5]

さらに、掲載先ごとの状態や商品上の問題をまとめた productStatus を確認します。入力を受け付けたこと、処理後の値が正しいこと、掲載上の問題がないことは別の確認です。掲載先や対象国の状態を見ずに、Google上で表示されると判断しないでください。[3][5]

EC責任者は、開発担当から「送信の返答」「処理後の在庫と登録元」「掲載上の問題」の3点を受け取ります。送信が失敗した場合は、返答を起点に認証、対象アカウント、登録元、商品情報を照合します。成功した場合も、次の定期更新で同じ商品が正しく更新されるか確認してから、検証する商品を増やす進め方を勧めます。

全商品へ広げる前には、複数商品をまとめて送る旧方式 customBatch がそのまま使えない点も開発担当と確認します。また、移行済みの処理はMerchant APIに寄せ、旧APIとの二重運用を残す範囲を明確にします。1件の成功を、全商品の移行完了とは扱いません。[2][5]

本稿の送受信例は説明用で、実アカウントでの登録、商品送信、掲載は未検証です。商品を送る仕組みの確認と、無料掲載の条件を調べる作業は分けて進めます。