「Copilotで自社の商品名を聞いてみたのに、うちの店の名前が出てこない」。ECを運営している方から、そういう相談をいただくことがあります。
多くのEC担当の方は、Bing ShoppingでのCopilot対策を「自社サイトをクロールしてもらう話」だと考えています。ところが、商品情報がCopilot側へ届く道は、それだけではありません。Microsoft Merchant Centerへの商品フィード登録という、もう1つの経路が用意されています。
この記事は、ECサイトの運営を預かっている方に向けて書きました。土台にするのは、Microsoft公式ドキュメントと消費者庁の価格表示ガイドラインという、確認できる情報だけです。専門用語は、出てきたその場で言い換えます。
こんなふうに調べていませんか
- 「Copilot 対策 EC」で検索したものの、自社サイトの何を直せばよいのか分からない
- Bing Shoppingへ商品を載せる方法を調べていて、クロールとフィードの関係が整理できない
- 上司から「うちの商品もAIの答えに出るようにして」と言われ、指示の中身が分からない
この記事を読み終えたときに手に入るもの
- 商品情報がCopilotに届く2つの経路を、社内で説明できるようになります
- フィードとページでそろえる項目が、順番つきで分かります
- セール価格の表示が景品表示法の要件に耐えるかを、自分で確認できます
結論30秒でわかる、この記事の結論
- ECのCopilot対策とは、クロール経路とフィード経路という2つの道に流れる情報を、同じ値にそろえる取り組みです。
- Bing Shoppingへ商品を載せる道は、bingbotのクロールだけではありません。Microsoft Merchant Centerへのフィード登録が、別の経路として用意されています（出典: Microsoft公式）。
- ズレたときに困るのは、AI検索に引用されるかどうか以前の部分です。フィード側ではエラー・警告の対象になり、ページ側の価格表示は景品表示法の論点になります。
この記事では、あるEC事業者の運営チームと専門家の会話をはさみながら進みます。ご自身に近い立場の人の質問から読んでいただいて構いません。
- 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どの順番でやるんですか？」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01そもそもECのCopilot対策は、Bing ShoppingとつながったAIOのどこを直す話ですか？
若葉さんCopilot対策と言われても、Copilotの中身を私たちが触れるわけではないですよね。結局、何を直すことになるんでしょうか。
鈴木さん直すのは自社の側です。Copilotは、Bingの検索基盤を土台にして答えを組み立てる仕組みを持っています。ですから作業の中身は、「Bing側から見える状態を整えること」になります。
Copilotが答えを作るとき、その裏側で使われているのはBingです。Web上の情報で回答を裏づけるこの仕組みは、web groundingと呼ばれます。基本の構造そのものは、金融機関を題材にした別記事で扱いました。この記事では、そこに重ならないEC特有の論点だけを扱います。
EC・ショッピングの領域には、その一般的な仕組みに加えて、もう1つの入口があります。Microsoft Merchant Center（以下MMC）です。商品情報を専用のフィード形式で送り込む仕組みで、Microsoftが公式ドキュメントでその役割を定義しています（出典: Microsoft公式）。フィードとは、商品名・価格・在庫といった項目を決まった形式で並べたデータのことです。人が読む商品ページとは別に、機械が読むカタログをもう1部そろえる、と考えると近いはずです。
手を入れられるのは、自社の商品ページと、自社が送るフィードの2か所だけです。Copilotの回答の作り方そのものを、こちら側から書き換えることはできません。ここを取り違えると、「AI向けの何か」を探しているうちに時間だけが過ぎていきます。
この章のまとめ
Copilotの入口はBingの仕組みにつながっています。手を入れられるのは、自社の商品ページと、自社が送るフィードの側だけです。
02Copilotと商品情報の関係は、AI検索のたとえでいうと何にあたるんですか？
言葉だけで追いかけると混乱しやすいので、商店街の案内所にたとえてみます。
案内所の人を説得しに行くことはできません。できるのは、台帳に自分の店の情報が正しく載るようにしておくことと、品ぞろえ表を自分から渡しておくことです。
このたとえは、もう1つのことも教えてくれます。台帳と品ぞろえ表で値段が違っていたら、案内所の人はどちらを読むのか分からなくなります。情報を2か所に置くということは、そろえ続ける義務がセットで生まれるということです。
この章のまとめ
Copilotは案内所の人、Bingの索引は店の台帳、フィードは店から渡す品ぞろえ表。渡す先が2つある以上、中身をそろえる作業が要ります。
03ECのAI検索対策として、Bing ShoppingとCopilotに届く経路はいくつあるんですか？
高梨課長経路が2つある、というところが分かっていませんでした。robots.txtでbingbotを通していれば、それで足りているものだと思っていました。
鈴木さんそこはよくある勘違いです。クロールとフィードは、別々に用意された経路なんですよ。片方だけを整えても、もう片方は自動では埋まりません。
商品情報がBing側へ渡る道は、大きく2つに分かれます。
1つは、クロール経路です。bingbotが自社サイトを巡回し、商品ページの中身を読み取って索引に記録します。robots.txt・サイトマップ・IndexNowといった技術要件は、金融機関を題材にした別記事で扱った内容と共通です。ECだからといって特別なことはありません。
もう1つが、フィード経路です。MMCへ商品データを送ると、クロールを待たずに、こちらから商品情報を届けられます。Microsoftはこれを、クロールとは別の仕組みとして公式に用意しています（出典: Microsoft公式）。
どちらが優れているという話ではありません。両方を整えておくと、商品情報が伝わる道を1つに絞らずに済みます。片方が止まったときに、もう片方が残ります。
押さえておきたいのは、クロール経路は待つ仕事で、フィード経路は送る仕事だという違いです。送った内容が間違っていれば、間違ったまま材料になります。ECのAI検索対策でフィードの値の正しさが繰り返し問われるのは、このためです。
この章のまとめ
経路はクロールとフィードの2つ。クロールは待つ仕事、フィードは自分から送る仕事です。送る以上、中身の正しさは送り手の責任になります。
04Microsoft Merchant Centerへのフィード登録は、Bing ShoppingのAI検索最適化で何をする作業ですか？
MMCの役割は、公式ドキュメントに明確に書かれています。商品のカタログフィードを作成し、Microsoft Advertising Network上に商品を表示させる仕組みです（出典: Microsoft公式）。
Microsoft Advertisingの公式ブログは、このフィードの役割をもう一段踏み込んで説明しています。フィードは主に「発見」を担い、AIの回答に商品が表示されるための土台になります（出典: Microsoft Advertising公式ブログ、2026年4月）。購入手続きを担う「Copilot Checkout」とは、役割が分かれています（出典: 同）。
つまりフィードは、「買ってもらう」より手前の、「見つけてもらう」ための仕組みです。ここを取り違えて、フィードを整えたのに売上の数字が動かないと落胆する、という順序の誤解が起きやすいところです。フィードが担うのは発見であり、その先の導線は別の話です。
この章のまとめ
フィードが担うのは発見です。買ってもらうより手前の、見つけてもらうための仕組みだと捉えてください。
05公式ブログが出した伸びの数値は、ECのAI対策の判断材料にしてよいんですか？
同じブログは、ある連携事例も報告しています。Shopify Catalogとのリアルタイム連携により、上位加盟店のCopilot上のインプレッションシェアが1か月で約9割伸びたという内容です。比較対象は2026年2〜3月の期間です。これは特定の連携方式・期間における公式発表の数値であり、WEBMARKSが独自に検証した数値ではありません。
公式発表の数値は、条件つきの実測です。連携方式・対象・期間が変われば、同じ伸び方が再現されるとは限りません。社内で共有するときは、数値だけを切り出さず、条件もセットで伝えることをおすすめします。
数値だけが独り歩きすると、次に起きるのは目標の逆算です。同じ伸びを前提に計画を立てると、届かなかったときに施策そのものが否定されます。判断材料として使うなら、「この条件では、こうなったという報告がある」という形で置いてください。
CMSごとの具体的な連携手順は、プラットフォーム別の別記事に譲ります。ここからは、どのCMSを使っていても共通する「何を送るか」に絞って進めます。
この章のまとめ
公式ブログが報告した伸びの数値は、条件つきの実測です。条件ごと共有し、自社でも同じ結果が出る前提には置かないでください。
06Bing Shoppingのフィード必須項目は、ECのAI対策としてどこまで埋めるんですか？
MMCの商品フィードには、必須項目とその条件が公式ドキュメントで細かく定義されています（出典: Microsoft公式）。
| 項目 | 必須条件 | 内容 |
|---|---|---|
| price | 必須 | 商品ページに表示されている価格と一致させる必要がある（0.01〜1,000万の範囲） |
| availability | 必須 | in stock・out of stock・preorderの3値のみ（既定値はin stock） |
| title・imageLink・link | 必須 | 内容はエディトリアルレビューの対象になる |
| description | 任意（推奨） | 必須ではないが、記載する場合はエディトリアルレビューの対象になる |
| gtin・mpn | 製造者が付与している場合は必須 | 商品識別子。判明していれば省略できない |
| brand・channel・condition・offerId等 | 必須 | 商品の基本属性 |
| shipping・shippingLabel・shippingWeight | ドイツ向けのみ必須 | それ以外の国では任意 |
エディトリアルレビューというのは、送った文言が掲載の基準に合っているかを見る審査のことです。任意項目でも、書けば審査の対象になります。「任意だから何を書いてもよい」ではない、という点は押さえておいてください。
配送に関する項目のように、国によって必須かどうかが変わるものもあります。自社が販売している地域を確認したうえで、どこまで埋めるかを決めてください。
この章のまとめ
必須項目は公式ドキュメントに定義されています。任意項目でも、書けば審査の対象になります。
07gtin・mpnのような商品識別子は、ECのAI検索対策でも省略できないんですか？
必須項目の中で、扱いに迷いやすいのがgtin・mpnです。公式ドキュメントは、製造者が付与している場合は必須と定義しています（出典: Microsoft公式）。「任意」ではなく「判明していれば省略できない」という条件つきの必須です。
gtin・mpnは、商品を共通の記号で識別するための番号です。gtinは流通の場で使われる共通の番号、mpnは製造者が付ける型番だと考えると近いはずです。名前の書き方は店ごとに揺れますが、識別子は揺れません。同じ商品かどうかを機械が判断するための、共通の手がかりにあたります。
判明しているのに空欄にすると、その手がかりが1つ減ります。仕入れ元の資料に載っているのに転記されていない、という状態はよく見かけます。商品マスタ側に識別子の欄がなければ、まずそこから作ってください。
この章のまとめ
gtin・mpnは、判明していれば省略できない条件つきの必須項目です。まずは主要カテゴリを1つ、完全な状態にしてください。
08priceがページとズレると、CopilotのAI検索対策では何が起きるんですか？
必須項目の中でも、priceは扱いが少し違います。priceは「商品ページに表示されている価格と一致させる」ことが、公式ドキュメントに明記された必須条件です（出典: Microsoft公式）。
つまり、フィード側の書式が正しいだけでは要件を満たしません。ページ側の表示と突き合わせて、はじめて条件を満たすかどうかが決まります。
Microsoft側では、フィードのpriceが商品ページの価格と一致しない場合、フィードの該当項目がエラー・警告の対象になります（出典: Microsoft公式）。エラー・警告が出ている状態は、商品情報が正しく配信されていないというサインです。
ここで起きやすいのが、ページ側だけを直して終わりにしてしまうという対応です。セール価格に変えたとき、目に見えるページは直すので気づきます。フィードは目に見えないので、直し忘れても誰も気づきません。
この章のまとめ
priceの一致は、公式ドキュメントに書かれた必須条件です。価格を動かす作業は、ページとフィードをセットで動かす手順にしてください。
09Product schemaとフィードの二重管理は、ECのLLMOでどう整合させるんですか？
若葉さん商品ページには、構造化データで在庫状況を書いています。フィードにも在庫の項目がありますよね。これは、同じことを二重に書いているということでしょうか。
鈴木さん内容としては同じ在庫状況を指しています。ただ、使う言葉が違うんです。そこがズレの原因になります。
商品ページには、schema.org Product（Offer型のavailability）という項目があります。MMCのフィードにも、同じ役割のavailabilityという項目があります。両者は同じ在庫状況を指しながら、別々の語彙を使う点に注意が必要です。構造化データとは、ページの内容を機械が読める形で書き添えるための記法のことです。書き方そのものは別記事で扱っているので、ここでは在庫の値だけに絞ります。
schema.orgのavailabilityは12種類の列挙値を持ちます（出典: schema.org公式）。一方でMMCのフィードは、in stock・out of stock・preorderの3値しか受け付けません（出典: Microsoft公式）。
| schema.org（商品ページ側） | Merchant Centerフィード側 |
|---|---|
| InStock | in stock |
| OutOfStock | out of stock |
| PreOrder | preorder |
| BackOrder・LimitedAvailability・Discontinued・SoldOut・Reserved・PreSale・InStoreOnly・OnlineOnly・MadeToOrder（9値） | 対応する既定値なし。3値のいずれかに丸める必要がある |
この章のまとめ
ページ側とフィード側は、同じ在庫を別の語彙で書いています。まず、語彙が違うという事実を共有してください。
10入荷待ちや受注生産は、Bing ShoppingのAI検索最適化ではどの値に寄せるんですか？
対応関係を整理すると、そのまま置き換えられるのは3つだけです。残りの9つには、決まった行き先がありません。
在庫状況が3値に収まらない商品ほど、二重管理のズレが起きやすくなります。予約・入荷待ち・店頭のみ・受注生産といった状態を細かく出し分けている店ほど、フィード側で表現しきれない値が増えていきます。
そして、行き先が決まっていない値は、入力する人の判断で埋まります。ここが、次の章で扱う「決めておくこと」の中身です。
この章のまとめ
そのまま置き換えられるのは3つだけです。残りの9つは、寄せ先を自分たちで決めることになります。
11在庫の12値をBing Shoppingの3値に丸めるとき、AIOの実務では何を決めておくんですか？
たとえば商品ページ側で「入荷待ち」をBackOrderと表示している場合を考えます。フィード側ではpreorderとout of stockのどちらに丸めるかを、あらかじめ社内で決めておく必要があります。
この対応関係を決めずに担当者ごとの判断で入力すると、同じ商品でもページとフィードで違う在庫状況が表示される事態が起こります。担当者が増えるほど、決めていないことはばらけていきます。
決め方に唯一の正解はありません。大切なのは、社内で1つに決めて、書いたものを残しておくことです。口頭の合意は、担当が替わった時点で消えます。
そして最後の一手が、自動化です。商品マスタから、商品ページのJSON-LDとMerchant Centerのフィードを自動生成する設計にしておくことが、実務上もっとも確実な対応になります。手作業でのダブルメンテナンスは、商品点数が増えるほど破綻しやすくなります。
この章のまとめ
丸め方は社内で1つに決め、書いたものを残します。そのうえで、商品マスタからページとフィードの両方を機械に作らせてください。
12セール価格の「通常価格」は、ECのAI検索対策でも同じ基準で見られるんですか？
ここからは、Microsoftの規約とは別の話です。日本国内向けにセール価格を表示する場合は、景品表示法の二重価格表示の規制が関わってきます。
二重価格表示というのは、「通常価格」と「セール価格」を並べて見せる表示のことです。消費者庁のガイドラインは、値下げ前の「通常価格」を比較対照価格として使うための条件を定めています（出典: 消費者庁「不当な価格表示についての景品表示法上の考え方」）。
- 目安となる期間: セール開始時点から遡る8週間のうち、その価格で販売していた期間が、商品を販売していた期間の過半を占めていること
- 下限: その価格で販売していた期間が、通算2週間以上あること
- 直近性: その価格で販売した最後の日から、セール開始まで2週間以上あいていないこと
- 将来価格を比較対照にする場合: 実際にその価格で販売することが確かでなければ、比較対照価格として使えない
言い換えると、「昨日まで売っていなかった価格」を通常価格として並べることはできないということです。セールの見せ方を工夫するつもりが、規制の側から見ると別の意味を持ってしまう。ここが、EC担当者がいちばん踏みやすいところです。
この章のまとめ
通常価格として使えるかどうかは、販売の実績で決まります。表示の工夫ではなく、実際に売っていた期間を確認してください。
13Copilotが引用してくれたら、AI対策として景品表示法の心配は消えるんですか？
高梨課長運用として気になるのは、AIが自動で要約した結果です。うちの表示をCopilotがそのまま引用した場合、こちらで確認する範囲はどこまで広がりますか。
鈴木さんそこは変わらないと考えておくのが安全です。この基準は、表示媒体を問わず適用されます（出典: 消費者庁）。元のページの表示が基準を満たしていなければ、引用されてもリスクは残ります。
Copilotが自社ページのセール価格表示をそのまま引用したとしても、元のページの表示が基準を満たしていなければ景品表示法上のリスクは残ります。AIが要約したから軽くなる、ということはありません。
- Microsoft側: フィードのpriceがページと一致しないと、エラー・警告の対象になります（出典: Microsoft公式）
- 景品表示法: セール表示の「通常価格」が、販売実績の要件を満たしていない可能性があります（出典: 消費者庁）
構造化データやフィードを整備する作業と、価格表示そのものの適法性を確認する作業は、切り離さずに進めてください。同じ1つの価格表示から、性質の違うリスクが2方向へ伸びているからです。
この章のまとめ
引用されても、元のページの表示が基準を満たしていなければリスクは残ります。技術の整備と表示の確認は、同じ作業として扱ってください。
14ECのAIO対策でつまずくのは、CopilotとBing Shoppingのどちら側ですか？
現場でよく見かけるつまずき方を、3つ挙げます。どれも「よかれと思って」起きるものばかりです。
1. フィード側のavailabilityを「in stock」で固定し、実際の在庫切れが反映されない
3値しかないフィード側の更新を後回しにすると、ページ側は在庫切れ、フィード側は在庫ありという食い違いが起こります。既定値がin stockであることも、放置が起きやすい理由の1つです。
2. セール直前に表示価格を引き上げてから割引表示にする
消費者庁のガイドラインは、セール実施決定後に販売を始めた商品や、実績のない価格を「通常価格」と称する表示を、不当表示のおそれがある事例として挙げています（出典: 消費者庁）。見せ方の工夫のつもりでも、実績がなければ通常価格としては使えません。
3. フィードのエラー・警告を放置したまま、ページ側の見た目だけ整える
price不一致の警告は、フィードが正しく機能していないサインです。放置すれば、商品情報の配信そのものに影響します。見えているページだけを直す運用が、いちばん起きやすい遠回りです。
この章のまとめ
つまずきは、たいてい「見えない側」で起きます。フィードは目に入らないので、見に行く習慣を運用に組み込んでください。
15うちの体制で、ECのLLMO運用とフィード更新は誰がやるんですか？
高梨課長専任は置けません。この作業は、どこの担当につけるのが現実的でしょうか。
鈴木さん新しい体制はいりません。価格と在庫を動かしている人のところに、フィードの更新も寄せてください。別部署に切り出すと、片方だけが遅れやすくなります。
高梨課長なるほど。値付けの担当と同じ場所に置く、ということですね。
体制の話で大事なのは、人数ではなく、値を動かす人と、値を送る人を同じにすることです。価格改定はマーチャンダイジング、フィードは情報システム、という分け方をすると、間に伝達の手間が挟まります。挟まった分だけズレます。
フィードとページの二重管理は、商品点数が少ないうちは手作業でも回ります。ただ、点数が増えるほど自動化の必要性が高まります。商品マスタを起点にページとフィードの両方を自動生成する設計へ早めに移行することを、WEBMARKSはおすすめします。
なお、ここで整えた商品データは、Copilot向けだけのものではありません。Perplexity側の対応、Google側の対応は、それぞれ別記事で扱っています。3つのプラットフォームに共通するのは、商品データを機械可読に保つという基礎作業です。プラットフォームごとに別の施策を立てる前に、この土台を1つにしておくほうが早く進みます。
この章のまとめ
値を動かす人とフィードを送る人を同じにします。整えた商品データは、他のAI検索エンジンへの対応にもそのまま効きます。
16よくある質問
bingbotのクロールを許可していれば、Merchant Centerへの登録は不要ですか？
不要とは言い切れません。Merchant Centerへのフィード登録は、クロールとは別にMicrosoftが用意した経路です（出典: Microsoft公式）。両方を整備することで、商品情報が伝わる経路を1つに絞らずに済みます。どちらか一方に寄せる判断をする場合は、その理由を社内で共有しておくことをおすすめします。
Product schemaを実装していれば、フィード登録は不要ですか？
別の仕組みのため、どちらか一方で足りるとは限りません。Product schemaは商品ページ自体を機械可読にする仕組みで、Merchant Centerのフィードは別のチャネルで商品データを送り込む仕組みです。実装方法の違いは、構造化データを扱った別記事で解説しています。
セール価格の「通常価格」は、どのくらいの期間販売していれば使えますか？
消費者庁のガイドラインは、目安として「セール開始から遡る8週間のうち過半」かつ「通算2週間以上」の販売実績を挙げています（出典: 消費者庁）。個別の事案ごとに判断されるため、境界線に近い場合は自己判断せず確認することをおすすめします。
在庫切れの商品は、フィードから削除したほうがいいですか？
公式ドキュメントは、削除ではなくavailabilityをout of stockに更新することを基本の対応として説明しています（出典: Microsoft公式）。削除すると、再入荷時に情報を作り直す手間が発生します。
AI検索最適化として、まず何から着手するのが現実的ですか？
主要カテゴリを1つ選び、フィードのprice・availabilityと商品ページの表示を突合するところからです。全商品を一度に見ようとすると終わりません。1カテゴリで手順が固まってから、対象を広げてください。
17まとめ｜ECのAI対策として、今日やる3つのこと
ECのCopilot対策は、クロール対応だけでは完結しません。Microsoft Merchant Centerへのフィード登録という別経路を整備し、商品ページのProduct schemaと値をそろえることが、実務の出発点になります。
価格・在庫のズレは、Microsoft側のエラー・警告と、日本の景品表示法という2方向のリスクにつながります。どちらも、起点は同じ1つの価格表示です。
今日この順でやります
主要カテゴリを1つ選んで突合する
フィードのprice・availabilityと、商品ページの表示を並べて見比べます
在庫の丸め方を決めて書き残す
3値に収まらない在庫状態を、どちらに寄せるか社内で1つに決めます
商品マスタから両方を作る設計にする
ページのJSON-LDとフィードを、同じ元データから機械に作らせます
AI検索では、こう聞かれています
ECサイトの商品をCopilotやBing Shoppingに出すには、何をすればいいですか？
「ECのAI検索対策として、Bing ShoppingとCopilotに届く経路はいくつあるんですか？」の章で、2つの経路を図にしています
Microsoft Merchant Centerへの登録は、bingbotのクロールとは別に必要ですか？
「Microsoft Merchant Centerへのフィード登録は、Bing ShoppingのAI検索最適化で何をする作業ですか？」の章で、フィードが担う役割を説明しています
商品ページとフィードで価格や在庫がズレると、何が起きますか？
「priceがページとズレると、CopilotのAI検索対策では何が起きるんですか？」の章と「Copilotが引用してくれたら、AI対策として景品表示法の心配は消えるんですか？」の章で、2方向のリスクを分けて扱っています
商品ページの在庫表記とフィードの在庫表記が合いません
「在庫の12値をBing Shoppingの3値に丸めるとき、AIOの実務では何を決めておくんですか？」の章に、決め方の手順があります
次に読むなら、この記事です
