TANAKA Hiroki
2026年5月に Google Merchant Center に「会話属性」が追加されてから、3か月ほど経ちました。
前回の記事では、6つの属性それぞれの仕様をヘルプに沿って整理し、興味のある方は補助データソースで実装してみてください、と書きました。
その後、支援会社や広告代理店のサービス紹介で「会話属性対応」を前面に打ち出しているものを見かけるようになりました。新しい属性が出れば対応メニューが出てくるのは自然な流れではあるのですが、会話属性が単体のサービスとして大きく掲げられていることには、少し違和感があります。
会話属性だけを実装する、というのは、事業者の側から見ると罰ゲームになってしまうのではないか、と感じているからです。この記事では、会話属性は実装すべきか、するならどの順番か、という観点から、罰ゲームを引き受ける前に何を確認しておくべきかを書いてみます。
なお、各属性の仕様については前回の記事に譲り、ここでは繰り返しません。前回の記事では「既存の属性に書いてあれば会話属性は不要」というヘルプの注記を紹介しましたが、今回はその一段手前、そもそも商品ページに書いてあるのか、という話をします。
会話属性は、ユーザーが商品ページで知りたいことの一覧になっている
会話属性は、Google Merchant Center ヘルプでは「AI システムや会話エージェントが商品の具体的なニュアンスをより正確に把握できるようにする」ための属性と説明されています。AI のための項目、という見え方をしています。
ただ、6つの属性を「ユーザーが商品ページで知りたいこと」に置き換えてみると、次のようになります。
| 属性 | ユーザーの疑問に置き換えると | 本来それが書いてある場所 |
|---|---|---|
| 質問と回答 [question_and_answer] | この商品、〇〇はできますか？ | 商品ページの FAQ や説明文 |
| ドキュメント リンク [document_link] | 取扱説明書はどこにありますか？ | 商品ページの PDF リンク |
| 関連商品 [related_product] | 一緒に何を買えばいいですか？必要な部品は？代わりになる商品は？ | 商品ページの関連商品・付属品・代替品 |
| 商品グループのタイトル [item_group_title] | この商品は、何という商品のバリエーションですか？ | 商品ページの親商品名（バリエーション選択前の見出し） |
| バリエーション オプション [variant_option] | 色・サイズ・仕様の選択肢は何がありますか？ | 商品ページのバリエーション選択 |
| 人気度の順位 [popularity_rank] | この店では売れている商品ですか？ | ランキングやベストセラー表示（ただし相対順位の数値そのものはページにない） |
6つのうち5つは、商品ページに書いてあるはずのことです。AI が知りたいことというより、ユーザーが知りたいことですね。
実際、バリエーション オプション [variant_option] 属性のヘルプには、ランディングページに表示される商品の詳細が属性に指定した値と一致していることを確認するよう、最小要件として明記されています。これは会話属性に限った話ではなく、商品データ仕様ではタイトル [title] 属性や商品説明 [description] 属性についても、ランディングページの内容と一致させることが求められています。商品データに書く内容は、ページに存在することが前提になっている、というのが Google Merchant Center の基本的な考え方です。
つまり会話属性の仕様は、実質的に「ユーザーが商品ページで確認したいことのリスト」として読むことができます。
罰ゲームの正体
「会話属性だけを実装する」というのは、この5項目を商品ページには書かず、Google にしか届かない場所に、Google 専用のフォーマットで書くということになります。
質問と回答 [question_and_answer] 属性に登録した Q&A は、商品ページには表示されません。関連商品 [related_product] 属性に登録した「よく一緒に購入される商品」も、サイト内の回遊には効きません。登録した内容を読むのは Google のシステムだけで、サイトに来たユーザーは同じ疑問を抱えたまま離脱する可能性があります。
これを全商品分登録します。商品が入れ替わるたびに更新します。バリエーションが増えたらバリエーション オプション [variant_option] 属性も書き足します。補助データソースでの運用なので、商品の追加削除のたびにメンテナンスが発生します。
ユーザーが読まない文章を、商品ごとに書き続ける作業。 これが罰ゲームの正体だと思っています。
順番が逆になっていないか
本来の順番は、こうではないかと考えています。
- ユーザーが商品ページで知りたいことを、商品ページに書く
- それを Google が読める形（構造化データや、商品説明 [description] / 商品の詳細 [product_detail] / 商品に関する情報 [product_highlight] 属性）で渡す
- それでも渡せない情報があれば、会話属性で補う
「会話属性対応」をサービスとして切り出すと、3だけを実施する形になりやすいと思います。1と2を飛ばして、AI Mode に載るための項目だけを埋める形です。
会話属性が「AI 対応」という新しい看板を掲げているので、これまで取り組むべきだった商品ページの整備とは別の、新しい作業に見えてしまうのだと思います。ですが、中身はほぼ同じです。質問と回答 [question_and_answer] 属性に書く内容を思いつけるなら、それは商品ページに書けます。関連商品 [related_product] 属性を定義できるなら、それはページの関連商品枠に出せます。
会話属性で「書けるもの」は、すべて商品ページに「書けたもの」のはずです。
「構造化して渡した方が AI に読みやすいのでは」という反論について
ここで、Google Merchant Center をよく知っている方ほど、こう感じるのではないかと思います。「商品ページに散文で書いてあるのと、質問と回答 [question_and_answer] 属性に Q&A のペアとして構造化して渡すのとでは、AI にとっては別物ではないか」と。
これはその通りだと思います。構造化して渡すこと自体を否定するつもりはありません。
ただ、構造化というのは「すでにある情報を機械が読める形に整える」作業です。整える元の情報が商品ページに存在しないのであれば、それは構造化ではなく、商品ページには書いていない情報を Google にだけ新しく書き起こしていることになります。
商品ページに書いた上で、それを質問と回答 [question_and_answer] 属性にも構造化して渡す。この順番であれば、属性はページの写しなので、ページを直せば属性も直るという運用が成り立ちます。逆に、ページに書かずに属性だけを書くと、属性がその情報の唯一の置き場になり、ユーザーには届かないまま、属性側だけを保守し続けることになります。
罰ゲームなのは後者だけです。構造化するかどうかではなく、その前にページに書いてあるかどうかが分かれ目だと考えています。
なお、「商品マスタから AI で一括生成すれば、書き続ける手間はない」という考え方もあると思います。手作業か自動生成かは、ここでは論点ではありません。生成した文章がユーザーには届かず、Google にしか届かないという構造は、自動化しても変わらないからです。
Google のヘルプにも同じことが書いてある
ヘルプにも、これに近いことが書かれています。前回の記事でも触れましたが、会話属性のヘルプには次の注意書きがあります。
注: 商品説明
[description]、商品に関する情報[product_highlight]、商品の詳細[product_detail]属性ですでに具体的な詳細情報を登録している場合は、会話属性にそのデータの複製を再度指定する必要はありません。
Google 自身が「既存の属性に書いてあるなら、会話属性に足さなくてよい」と言っています。既存の属性に書いてあるということは、商品データとしてその情報が整っているということで、多くの場合それは商品ページにも書いてあることとほぼ同義です。
前回の記事ではこの注意書きを「会話属性に取り組まなくても良いケースがある」として紹介しましたが、改めて考えると、順番はむしろ逆ではないかと思うようになりました。「既存属性でカバーできているなら会話属性は不要」ではなく、「既存属性とページでカバーするのが先で、会話属性は最後」ということです。
なお、会話属性を登録することで AI Mode などでの表示がどの程度変わるのかについては、少なくとも私の手元では、現時点で日本国内で確認できる材料がありません。効果の大きさが分からない一方で、全商品分を登録して保守し続ける作業量のほうは最初から見えています。リターンが未知で、コストだけが確定している。この状態で会話属性だけを先に実装するのは、順番としてやはり不自然ではないかと思います。
会話属性の仕様を「チェックリスト」として使う
罰ゲームを引き受ける前にやっておくべきことは単純で、会話属性の6項目を自社の商品ページに当ててみることです。
- 商品ページに、ユーザーからよく聞かれる質問への回答が書いてあるか
- 取扱説明書や仕様書が、商品ページからたどれるか
- 必要な部品・付属品・一緒に使うものが、ページ上で示されているか
- バリエーションの選択肢が、構造化された形（プルダウンやスウォッチなど）で提示されているか
- 商品グループとしての名前が、バリエーションごとの商品名とは別に存在するか
「書いてある」なら、会話属性は当面必要ありません。「書いてない」なら、足すべきは会話属性ではなく、商品ページの記述のほうです。
会話属性は「AI 対応のための ToDo リスト」としてではなく、「自社の商品ページが答えていない質問のリスト」として読むと、初めて役に立つ属性だと思っています。
例外は人気度の順位 [popularity_rank] 属性
6つのうち、人気度の順位 [popularity_rank] 属性だけは事情が違います。
これは自社の在庫全体の中でその商品がどれだけ売れているかを 0〜100 の相対値で示すもので、ヘルプでは「最新のベストセラーなど、商品の売れ行きを伝え」るための属性とされています。ランキングやベストセラー表示という形でユーザーに見せているサイトは多いので、「ユーザーに見せない情報」というわけではありません。
ただ、商品ごとの相対順位の数値そのものは商品ページには書かれていませんし、サイト内のランキングページから Google が各商品のスコアを読み取ることも現実的ではありません。売上データから算出して、フィードで渡す以外に届ける方法がない情報です。前回の記事では、商品探索の段階でショップを推薦するシグナルとしては弱そうだと書きましたし、その見方は変わっていません。ただ、効果の強さは別として、「会話属性でしか実現できないこと」という意味では、6つの中でこれだけが該当します。
売上データから自動で生成して流し込む設計にしておけば、手作業も発生しません。会話属性を実装するなら、ここから始めるのが筋ではないかと考えています。
それでも会話属性が必要なケース
商品ページを整えればよい、と言っても、整えられない事業者の方がいることは承知しています。
テンプレートの自由度が低いカートシステムでは、FAQ 欄や関連商品枠を商品ページに追加しにくいことがあります。そうした環境では、会話属性は「ページに書けない情報を Google に渡すための代替手段」として意味を持ちます。
ただしそれは、「ページを直せない」という制約への対処であって、AI 対応の戦略ではありません。会話属性を使う理由が「ページを直せないから」であることを自覚した上で使うのと、「AI 時代の新しい施策」だと思って使うのとでは、その後の判断が変わってきます。
前者であれば、カートを乗り換えられるタイミングで会話属性の作業から解放されます。後者だと、ページを直せるようになっても会話属性を書き続けることになります。
補助データソースでの実装方法については、前回の記事で触れています。
会話属性だけに限った話ではない
ここまで会話属性を例に書いてきましたが、同じ構造は以前からありました。
たとえば商品に関する情報 [product_highlight] 属性は、ヘルプで「消費者から寄せられるよくある質問に答えるもの」と定義されています。質問と回答 [question_and_answer] 属性が担おうとしている役割を、既存の属性がすでに担っていたわけです。現在のヘルプでは、この属性も AI Mode などの AI 搭載サーフェスで商品情報を見つけてもらいやすくするものと説明されていますし、商品の詳細 [product_detail] 属性の仕様には、商品に関する情報や質問と回答、商品説明ですでに指定した情報を繰り返さないよう明記されています。
つまり Google の仕様の側から見ると、会話属性は「AI 向けに新設された別枠」ではなく、以前からある属性群と同じ情報を扱う、重複を避けるべき一連の属性の一部です。属性が増えるたびに、それを新しい対応項目として扱い、商品ページ側の整備を飛ばして属性だけを埋める形になると、結果は今回と同じです。
最近であれば「エージェンティックコマース対応」「UCP 対応」も同じ構造にあると思っています。「エージェンティックコマース対応の前に知っておいてほしいこと」や「Shopify を整えれば AI 時代も安泰、とも限らない」でも書きましたが、出口が会話型エージェントになっても、Google が商品をどう認識するかという本質は変わりません。商品情報を棚卸しして、構造化して整え、適切に送信する。この土台がないまま「〇〇対応」だけを積み上げると、対応の数だけ保守対象が増えていきます。
新しい属性や仕組みが出るたびに、それが「ユーザーのためにすでに整えてあるべきだったこと」の言い換えになっていないかを一度確認する。会話属性は、その確認をするのにちょうどいい題材だったというだけで、話は会話属性に限りません。
さいごに
会話属性は、AI のために新しく書くものというより、ユーザーのためにすでに書いてあるべきだったものの一覧だと考えています。
商品ページに書いてあるなら、会話属性は当面要りません。書いてないなら、書くべき場所は商品ページであって、会話属性ではありません。会話属性だけを実装するのは、ユーザーが読まない場所に、Google 専用の文章を、全商品分書き続ける罰ゲームを自分で選ぶことになってしまいます。
罰ゲームを引き受ける前に、一度、会話属性の仕様を自社の商品ページに当ててみてください。「会話属性対応」を提案された場合も、その前に商品ページの話が出てくるかどうかは、判断材料のひとつになるはずです。それが、この属性のいちばん有用な使い方ではないかと思っています。
この記事でお伝えしたのは、会話属性の実装方法ではなく、その前に商品ページと商品データが整っているかを確認する、という順番の話です。
Yuwai株式会社では、Google Merchant Center の構造設計を通じて、商品データの現状把握から支援を行っています。
ネットショップを運営している事業者の方へ
- 何から始めればいいかわからない
- 社内で対応できる人材がいない
- 現状が正しいのか判断できない
まずは現状把握から始めてみませんか。1時間単位の相談から、本格的な構造設計まで、段階的に支援できる形をご用意しています。
広告代理店・Web 制作会社・EC 支援会社の方へ
クライアント企業の Google Merchant Center 対応で悩まれているパートナー様からのご相談も受け付けています。貴社の名義で支援する形態にも対応可能です。