この記事でわかること
- 商品レビューのAPI送信がMerchant Centerのヘルプに案内されました。API自体には2024年から提供履歴があります。
- 利用には商品評価プログラムへの参加と、APIの利用許可申請が必要です。
- 作成、更新、取得、削除に対応します。レビュー全体を上書きする更新仕様と商品識別子の照合を確認します。
生成AIによる要約
Google Merchant Centerへ商品レビューを送る方法に、APIが案内されました。レビュー管理システムとの連携を検討しているEC事業者には、確認しておきたい更新です。ただし、利用には申請が必要です。
2026年9月18日、Search Engine Landがヘルプの変更を報じました。現在のGoogle公式ヘルプでも、APIによる送信と管理を案内しています。Googleはヘルプの変更日を示していないため、9月18日は報道日として扱います。
商品レビューの送信方法にAPIを明記
Merchant Centerの公式ヘルプは、商品レビューのAPI送信を説明しています。案内先は、Merchant APIの商品レビュー用ガイドです。レビューをプログラムから送信し、管理するための選択肢になります。
APIそのものには以前から提供履歴があります。Googleのリリースノートには、2024年10月16日の週にReviews APIのベータ提供を開始した記録があります。今回の報道を「商品レビューAPIが初めて登場した」と読むのは正確ではありません。
今回確認できた変更は、商品レビューの送信方法として、APIがヘルプに明記されたことです。現在のヘルプには、URLからの取得やファイルのアップロードも併記されています。既存の送信方法を一律にAPIへ切り替える案内ではありません。
商品レビューAPIでできること
商品レビューのAPIリファレンスでは、次の操作を確認できます。
| 操作 | できること |
|---|---|
| 作成と更新 | レビューを新規登録し、登録済みのレビューを更新する |
| 個別取得と一覧取得 | 登録済みのレビューを取得する |
| 削除 | 登録済みのレビューを削除する |
| 状態の確認 | レビューのステータスや問題の情報を確認する |
たとえば、自社のレビュー管理システムで修正された内容を、Googleへ送る処理につなげられます。レビューの件数や更新頻度が多い企業ほど、自動連携を検討する余地があります。これはAPIの機能から考えられる運用上の利点です。
実装時には、更新の扱いに注意が必要です。作成と更新に使うinsertは、既存のレビュー全体を上書きします。変更した項目だけを送る設計にせず、保持したい情報も含めて送信する必要があります。
商品レビューは、購入した商品に対する評価です。購入先の買い物体験を評価する店舗レビューとは対象が異なります。Merchant APIでは別のリソースとして扱うため、連携したい評価の種類を先に確認してください。
利用にはプログラム参加と申請が必要
APIを使うには、Merchant Centerのアカウントを持っているだけでは足りません。Googleの開発ガイドは、商品評価プログラムへの参加を前提としています。有効な商品レビューのフィードも必要です。
商品評価プログラムの申請には、最低50件の商品レビューが必要です。これは「1商品につき50件」という条件ではありません。申請はGoogleの担当者が確認し、アカウントを有効化する流れです。これからレビュー連携を始める場合は、APIの実装より先に参加条件を確認します。
そのうえで、Shopping APIのサポートフォームから利用許可を申請します。2026年9月20日時点の開発ガイドは許可リストへの追加を求めており、全アカウントで申請なしに使えるとは案内していません。
現行ガイドで使われているAPIの版名はv1alphaです。過去のリリースノートにある「ベータ提供」という記述とは区別し、実装時は利用するエンドポイントの仕様を確認してください。
レビューと商品を結びつける情報も確認する
送信処理を自動化しても、どの商品へのレビューかをGoogleが照合できる必要があります。公式ヘルプでは、GTINや、ブランドとMPNなどの商品識別子による照合を案内しています。MPNはメーカーが付ける部品番号です。
通常の商品データと、商品レビューのデータソースは別に扱います。商品フィードをすでにAPIで送信していても、それだけで商品レビューが連携されるわけではありません。レビュー側に商品識別子が保持されているかも確認が必要です。
既存のレビューサービスを使っている場合は、どこまで連携済みかを先に確かめると判断しやすくなります。Googleへの送信がサービス側で完結していれば、自社で新たに同じ仕組みを作る必要があるかを検討できます。
まずは現在の送信方法と更新の流れを点検する
API連携の検討は、現在の運用で手間がかかっている部分から始めます。次の3点を、レビュー管理の担当者や開発担当者と確認してください。
- 送信の担当：自社、レビューサービス、その他の連携先のうち、誰がGoogleへ送っているか。
- 更新の扱い：レビューが修正、削除された際に、Google側のデータへどう反映しているか。
- 商品との照合：レビューが参照する商品識別子と、商品データの識別子が対応しているか。
手動での反映が多く、更新漏れが生じているなら、API連携を検討する理由になります。その際は送信だけで完了とせず、エラーの検知と再送、レビューの状態を確認する運用も合わせて設計します。
APIで送信できることと、Google上で評価が表示されることは別の段階です。APIの利用だけで即時掲載や星評価の表示が保証されるとは、今回の案内からは確認できません。まずは参加状況と現在の連携方法を点検し、自動化する範囲を決めるのがよいでしょう。
関連記事
この記事をシェア
参照元
ryottaman
広告代理店で17年、現在は事業会社でインハウスマーケティングを担当しています。
SIGNALZの記事はAIを活用して作成し、10年以上の運用型広告の実務経験をもとに内容を確認・監修しています。制作方針の詳細はサイトについてをご覧ください。
Google検索の優先ソースにSIGNALZを追加
追加すると、Google検索のトップニュースでSIGNALZの記事が見つけやすくなります。AIモードとAIによる概要でも「優先」バッジが付きます。設定はいつでも解除できます。