TANAKA Hiroki
2026年5月20日（米国時間）に開催された、Google Marketing Live 2026 にて、Google Merchant Center の「会話属性」として、新たに6つの商品属性が追加されたことが発表されました。
キーノートスピーチでは言及がありませんでしたが、同時にポストされた Google 公式ブログ内でひっそりと公開された形になります。
なお、これに伴い Google Merchant Center ヘルプも更新され、会話属性の仕様詳細について確認することが可能になっています。
本記事では、会話属性の概要について Google Merchant Center ヘルプに沿う形でみていきたいと思います。
会話属性として追加された6つの属性
2026年5月20日（米国時間）に、下記6種の属性が Google Merchant Center に加わりました。ヘルプにならって日本語の属性名 [英語の属性名]のまま表記します。
- 質問と回答 [question_and_answer]
- ドキュメント リンク [document_link]
- 関連商品 [related_product]
- 商品グループのタイトル [item_group_title]
- バリエーション オプション [variant_option]
- 人気度の順位 [popularity_rank]
これらの属性はいずれも推奨属性となり、登録は必須ではありません。
次より、各属性について触れていきます。
質問と回答 [question_and_answer] 属性
この属性を使用して、ユーザー、販売者、メーカーが作成した商品に関する質問と回答を提供します。たとえば、この属性を使用して、商品に関する詳細を知りたいユーザーからの詳細な質問に回答し、調査や購入の意思決定をサポートできます。
質問と回答
[question_and_answer]属性は、すべての国で使用できます。
AI Mode や Gemini での会話をしながらの商品探索の際に、ユーザーが商品を決定する過程で参照される情報になりそうです。
質問と回答 [question_and_answer] 属性は、2つのサブ属性から構成されており、質問と回答を必ずセットで登録する必要があります。
例として、ヘルプでは ヘッドフォン端子は付いていますか？ という質問に対して、このバージョンにはヘッドフォン端子は付いていません。 という回答を行う場合は、質問：回答 のペアとして登録するようにフォーマットが指定されます。
なので、前述の例だと "ヘッドフォン端子は付いていますか？"："このバージョンにはヘッドフォン端子は付いていません。" という形で登録します。これを1個として、最大30個までの Q&A を登録できるようになりました。
この属性はあくまでも商品に対する Q&A なので、これらに関係ないキーワードや検索語句を追加することは推奨されません。
ドキュメント リンク [document_link] 属性
この属性を使用して、商品に関する関連情報を含む PDF ドキュメントを登録します。これらのドキュメントは、主に会話型 AI エクスペリエンスで使用されます。たとえば、商品に関するユーザーの詳細な質問に回答したり、調査や購入の意思決定をサポートしたりするために使用されます。
ドキュメント リンク
[document_link]属性は、すべての国で使用できます。
商品に付随する説明書や組み立てガイド、ファーストガイドなどの添付文書を指定することができます。ドキュメントとして登録ができるのは PDF 形式のファイルのみです。また、PDF ドキュメントは公開されていて、Google のクローラーが読めるようにしておく必要があります。
商品購入前に PDF 化されたドキュメントを参照してもらえるのは地味にありがたいかもしれません。
どうでも良い話ですが、PDF の中身を読み取って参照すると思うので、テキストがきちんと埋め込まれている PDF ファイルにした方が良さそうです。すべてがイメージで構成されていても問題はないかもしれませんが、OCR を使うと思うので、認識できるテキストの精度がごくわずかに変わりそうです。
関連商品 [related_product] 属性
この属性は、会話型 AI エクスペリエンスで使用されます。たとえば、ユーザーがこの商品と一緒に購入できる、またはこの商品の代わりに購入できる他の商品を提案するために使用されます。
関連商品
[related_product]属性はすべての国で使用できます。
一眼レフカメラの本体に対して、適合するレンズやバッテリーはこの商品ですよ！というように、商品やパーツ、類似商品の関係性を伝えるための属性です。
このカメラ本体を購入するなら、適合するレンズはこれ！バッテリーはこれ！という感じで事前に知らせる事ができますね。
関係のタイプ [relationship_type] : ID のタイプ [identifier_type] : ID [identifier] という3つのサブ属性を持つ構成なので、値の登録が煩雑になりそうですね。
関係のタイプ [relationship_type]（必須） として選択できる値
- セットの一部
[part_of_set]: 同じシリーズや商品ラインの一部である別の商品（テーブルに属する椅子など）。 - 必須部品
[required_part]: 商品が機能するために必要な部品（例: バッテリー駆動ランプの電池）。 - よく一緒に購入される商品
[often_bought_with]: この商品とよく一緒に購入される商品（スマートフォンとスマートフォン ケースなど）。 - 代替品
[substitute]: この商品の代替品となる商品（別のプリンタと同等の機能を持つプリンタなど）。 - 異なるブランド
[different_brand]: 異なるブランドで販売されている同一の商品（より安価な自社ブランドなど）。 - アクセサリー
[accessory]: この商品のアクセサリー（デスクトップ パソコンのアクセサリーとしてのウェブカメラなど）。
ID のタイプ [identifier_type]（必須） として選択できる値
- GTIN
[gtin]: 識別子は GTIN（または UPC、EAN、JAN、ISBN）です。 - ID
[id]: データソースの商品 ID です。
ID [identifier]（必須） として入力する値
ID のタイプ [identifier_type] で選択した GTIN または ID の値そのものを登録する
メインの商品に対して複数のアクセサリや交換部品などがある場合は、セット買いにつながる可能性もありますし、本体は持っているけどアクセサリやパーツだけほしいというニーズにも応えることができるようになるのは良いですね。わざわざメーカーのサイトに訪問して調べる必要も無くなるので。
商品グループのタイトル [item_group_title] 属性
商品グループ ID
[item_group_id]属性と組み合わせて商品グループのタイトル[item_group_title]属性を使用すると、複数のバリエーションがある商品にタイトルを割り当てることができます。商品グループのタイトル
[item_group_title]属性は、すべての国で使用できます。
今までバリエーション商品は SKU ごとに登録することが基本で、その場合は商品名にもサイズや色などの情報を含めて、バリエーションごとに商品名がユニークになっていました。
例えば下記のような感じ
半袖Tシャツ 赤 S サイズ
半袖Tシャツ 赤 M サイズ
半袖Tシャツ 赤 L サイズ
半袖Tシャツ 白 S サイズ
半袖Tシャツ 白 M サイズ
半袖Tシャツ 白 L サイズこのように、バリエーションが存在する商品は親 SKU の値を持たせるよう商品グループ ID [item_group_id] 属性を使ってまとめていました。
上記の例であれば６商品すべての商品グループ ID [item_group_id] 属性に「short-sleeve」みたいなテキストを持たせてグループ化するイメージです。
この商品グループのタイトルは、親 SKU に対する商品名を設定するイメージで、個別の商品からバリエーション情報を抜いた商品名を設定することで、商品名も共通化しようという意図のようです。
上記の例であればすべての商品に対して商品グループのタイトル [item_group_title] 属性に「半袖Tシャツ」という値を登録します。
ヘルプで見る限りは会話型エクスペリエンス専用ではないので、これを登録する事でどのあたりに効いてきそうかは未知です。入力する値としても、個別に登録する商品情報よりは情報量が減るはずなので･･･。今後の新しいフォーマットなどに活用されるイメージでしょうか。
バリエーション オプション [variant_option] 属性
多くの商品にはさまざまなバリエーションがあります（たとえば、T シャツにはさまざまなサイズや色があります）。バリエーションのある商品の場合は、この属性を使用してバリエーションを特定するプロパティと値を指定します。この属性は、会話型 AI エクスペリエンスと従来の検索エクスペリエンスの両方で、商品と一緒に、利用可能なすべてのバリエーションをユーザーに表示するために使用されます。
バリエーション オプション
[variant_option]属性は、すべての国で使用できます。
Google Merchant Center では色、柄、素材、サイズ、年齢層など既に標準的なバリエーション属性を持っています。
ですが、例えば色 [color] 属性を取り上げてみると、「T シャツとして同一商品の色バリエーション」なのか、「単一商品という前提での色指定」なのかは、システム上判断がつきにくい状況でした。どちらの意図で登録しても間違いではないので。
例えば、アパレルではアイテムグループ ID [item_group_id] を指定することでバリエーションであることを伝えられる仕組みでしたが、今回はより正確にバリエーションの一部である事を判断したいという意図で、これらを明示することを要求してきたかのように見えます。
カスタムバリエーションとして２つのサブ属性を持ち、名称 [name]:値 [value] というフォーマットで登録します。名称と値は任意で、商品あたり30個まで登録できます。
ヘルプでは、商品が靴である場合に、「靴の幅」と「サイズ」をもつカスタムバリエーションとして、靴の幅:幅狭 サイズ：8 という2つの値を登録する例が紹介されています。
アパレルなどで既に標準のバリエーション属性を持っている場合でも、同じ情報をバリエーション オプション [variant_option] 属性に登録する事が推奨されていますが、サブ属性で指定する形式です。そのため、少なくとも属性ルールや外部の有料ツールなどの介入が必要になってくるので、何処までやるべきかは悩む属性ではあります。
人気度の順位 [popularity_rank] 属性
この属性を使用して、最新のベストセラーなど、商品の売れ行きを伝え、ユーザーがより多くの情報に基づいて購入を決定できるようにします。
人気度の順位
[popularity_rank]属性は、すべての国で使用できます。
「◯◯のおすすめを教えて」のようにざっくりとした検索や会話がなされたとき、推薦の候補にあたる商品に対して、各店舗での人気度の順位 [popularity_rank] の値をみて、「今ならばこの商品が人気でベストセラーです」といった回答に使うものと想像します。
仕様としては、0～100.0（小数第一位）までの値を指定するので、ショップ内のランキングに応じて1位ならば100、99位ならば1のような数値を入れていくというのが基本の使い方になりそうです。
自社の商品を紹介してもらうためというよりは、Google がユーザーにオススメできるかを判断するために、各ショップでの人気度を確認したいという意図のように見えます。もちろん、同一ショップで類似商品を扱っている場合、より人気の商品はこちらという使い方も想定されるのではありますが、商品探索の段階で特定のショップを推薦するために考慮するシグナルとしては個人的に弱い気がしています･･･。
Google のヘルプから引用になりますが、これらの会話属性を適用した商品データのイメージは下記になるようです。
会話属性に取り組まなくても良いケースがある
今回6種の会話属性が追加されましたが、ヘルプに下記の注意書きがあります。
注: 商品説明
[description]、商品に関する情報[product_highlight]、商品の詳細[product_detail]属性ですでに具体的な詳細情報を登録している場合は、会話属性にそのデータの複製を再度指定する必要はありません。
つまり、従来のこれらの属性を使って、会話型属性で要求されるような情報をカバーしている場合は、改めて会話属性の実装を行う必要が無いという点です。
細かく会話属性を設定していくか、既存属性でカバーできるようにするか、これらはシステムの制約も考慮して選択するべき問題なので、どちらの方式で対応するかはサイトの管理者やエンジニアの方と相談して進めていただくのが良いでしょう。
会話属性の実装は補助データソースを使うことが推奨される
これらの属性を既存の商品データの設定に直接追加するには、補助データソースを使用するか（推奨）、メイン データソースに追加します。Merchant API を使用してこれらの属性を登録することもできます。これらの商品を含めても、既存の商品の承認状況には影響しません。これらの属性を使用して、バリエーション データなど、商品に関するわかりやすい情報を伝えます。
当然の話ですが、現在各社から提供されているカートシステムが、これらの会話属性にネイティブで対応しているわけではないため、会話属性を利用する場合は補助データソースでの実装がオススメになります。
補助データソースは、別のデータソースを用いて、1対1で商品情報を補完したり上書きしたりする機能のため、商品の追加削除の度にメンテナンスが発生するのが手間にはなります。
ですが、逆に言うとスモールスタートもできますので、特に注力したい商品群から始めてみるなど手軽に実装することもできますので、興味のある方は是非実装してみてください。
Merchant API を使っての実装も可能ですが、カートの制約やエンジニアリングリソースが必要になるので、ほとんどのケースで Google スプレッドシートを補助データソースとして利用、編集もスプレッドシートでという運用がやりやすいと思います。
さいごに
2026年1月時点での Google の発表では、数十種類（dozens of…）の属性を追加すると公表したので、今回発表された6種の属性追加は少ないようにも見受けられます。
予告通り数十種類まで追加されていくのか、現時点では判断できません。ですが、エージェンティックコマースの拡大に向けて本格的に動き始めているタイミングに来ました。
エージェンティックコマースというキーワードは半ばバズワードに感じます。ですが、結局は Google がどのように商品を認識し、ユーザーにお勧めするかが本質であり、会話型エージェントは UI/UX の1つに過ぎません。
どの出口でも商品が推薦されるように、これまで通り商品の情報を棚卸しして、データを構造化して整え、適切に Google へ送信するという対応をしていく事は変わりません。
この記事でお伝えした内容を、実際に自社のネットショップに落とし込むには、制作、エンジニア、広告運用という複数の視点を揃えて、構造としてデータを整えていく必要があります。
Yuwai株式会社では、Google Merchant Center の構造設計を通じて、エージェンティックコマース時代に備えるための支援を行っています。
ネットショップを運営している事業者の方へ
- 何から始めればいいかわからない
- 社内で対応できる人材がいない
- 現状が正しいのか判断できない
まずは現状把握から始めてみませんか。1時間単位の相談から、本格的な構造設計まで、段階的に支援できる形をご用意しています。
広告代理店・Web 制作会社・EC支援会社の方へ
クライアント企業の Google Merchant Center 対応で悩まれているパートナー様からのご相談も受け付けています。貴社の名義で支援する形態にも対応可能です。