ECのAIO・LLMO対策｜商品データ整備と投資の優先順位

AI検索への対応として、まず記事コンテンツを増やそうと考えているEC事業者は少なくありません。ただ、扱う商品数が数万点を超える規模では、その判断が投資効率を大きく下げます。生成AIが商品を扱う際に見ているのは、記事の文章ではなく構造化された属性情報です。商品名、型番、価格、在庫、配送条件、仕様といったデータが欠けていたり古かったりすると、条件に合う商品であってもAIの候補に挙がりません。記事制作とデータ整備のどちらを先に置くかで、同じ予算でも到達できる範囲が変わります。

この記事でわかること

• AIが商品を扱う際に参照している情報の種類
• ページ量産がスパムポリシー違反になる条件
• 記事とデータ供給の投資配分を決める基準
• エージェント経由の発注に対応するための前提
• 自社にAI接点を持つ場合の必要条件

疑問	短い答え
何から着手すべきか	記事制作ではなく商品データの整備状況の確認
記事は不要になるのか	不要ではないが、SKU情報の役割はデータ側が担う
商品ページを増やせば有利か	条件次第でスパムポリシー違反のリスクを負う
構造化データは必須か	生成AI表示の必須要件ではないが継続を推奨
エージェント対応は今すぐ必要か	日本は準備期間。発注完遂の可否を確認する段階
自社にAIを持つべきか	既存の検索基盤とデータ資産の有無で判断が変わる

※各行の詳細は本文の該当章で解説します。判断の前提となる出典はすべて本文に記載しています。

早見表の各項目には、Google公式ドキュメントの記述や国内の実装事例という根拠があります。以下の目次から、判断に必要な箇所へ直接進んでいただけます。

ECのAI検索対応で問われるのは、コンテンツではなく商品データの整備状況である

AI検索への対応を検討する際、まずコンテンツ制作の予算を考える方が多い領域でしょう。しかしECの場合、優先順位はそこにありません。

生成AIが商品を推薦する場面では、利用者が用途や予算、納期といった条件を挙げながら候補を絞り込んでいきます。このときAIが判断材料にしているのは、商品名、型番、ブランド、価格、在庫状況、配送条件、サイズや素材といった属性です。記事の中で商品の魅力を丁寧に説明していても、これらの属性が機械的に読み取れる形で存在していなければ、比較の土俵に乗りません。

流入全体への影響やクリック率の変化については、AI検索がSEO流入に与える二層の影響で調査データをもとに整理しました。本記事ではEC固有の論点に絞って扱います。

AIが商品を扱う際に参照するのは、構造化された属性情報である

では具体的に、どの属性を優先して整えるべきなのでしょうか。判断の起点になるのは、購買の意思決定で使われる条件です。

識別情報

商品名、型番、ブランド、JANコードなど。同一商品を特定するために使われます

価格・在庫

現在価格、割引の有無、在庫状況。変動するため鮮度が結果を左右します

配送条件

納期、送料、配送可能地域。条件付きの絞り込みで参照されます

仕様・属性

サイズ、素材、色、対応規格など。用途からの絞り込みに使われます

評価情報

レビュー件数と評価。比較の判断材料として扱われます

これらのうち価格と在庫については、特に注意して運用する必要があります。人間向けの表示では在庫切れが分かるようになっていても、機械可読なデータが更新されていなければ、AIは古い情報のまま商品を推薦します。推薦された商品が実際には購入できないという体験は、露出があるだけに損失が大きくなります。

商品データの整備状況チェック

• 主要属性の欠損率
• 価格・在庫データの更新頻度
• 商品フィードの登録有無と更新間隔
• 構造化データの実装範囲
• JavaScriptに依存せず出力されているか
• バリエーション商品の親子関係の表現

なお構造化データについては、Googleの公式ドキュメントが生成AI検索の必須要件ではないと明言しています。ただしリッチリザルトの獲得を目的とした継続は推奨されているため、既存の実装を撤去する必要はありません。優先順位を上げすぎないという意味で受け止めてください。

出典：Google 検索セントラル『Optimizing your website for generative AI features on Google Search』（公開日記載なし）（2026年7月26日確認）

大量SKUのECほど、ページ量産という誤った打ち手に向かいやすい

網羅性を高めれば拾われやすくなるという発想は自然に見えます。しかし、この方向には明確なリスクがあります。

生成AIは、ひとつの質問から関連する複数の検索を並行して生成します。この仕組みはクエリファンアウトと呼ばれ、利用者の質問に答えるために追加の情報を集める働きをしています。ここから、想定される質問のバリエーションごとにページを用意すれば有利になるという発想が生まれがちです。

しかしGoogleは、検索表現の差やファンアウトされたクエリごとに個別のコンテンツを作る行為について、順位や生成AI回答の操作を主目的とする場合は大量生成コンテンツの不正使用ポリシーに該当すると明記しています。あわせて、ページ数の多さがサイトの品質を高めるわけではないという指摘も示されています。

判断の基準として当社が置いているのは、ページを「購買の判断単位」で作るという考え方です。買い手が異なる意思決定を行う場面ごとにページを設け、表現の差だけで分岐したページは作りません。

ページの作り方	買い手にとっての違い	判断
商品ごと	購入対象そのものが異なる	作る
用途・シーンごと	選ぶ基準が変わる	作る
価格帯・規格ごと	絞り込みの条件が変わる	作る
同義語・表記ゆれごと	違いがない	作らない
想定質問の言い回しごと	違いがない	作らない

※判断列を自社の商材特性に合わせて上書きしてお使いください。

この線引きがあれば、網羅性を高める作業とポリシー違反の境界を実務レベルで区別できます。上の表は商材によって変わるため、自社の購買プロセスに照らして判断列を書き換えてください。

出典：Google 検索セントラル『スパムに関するポリシー』（公開日記載なし）（2026年7月26日確認）

記事コンテンツで賄う領域と、データ供給で賄う領域は分けて投資する

記事が不要になるわけではありません。役割の分担を決めることが、投資配分の実務になります。

商品固有の情報を担うのは、記事ではなくデータ側の役割になります。数万点の商品それぞれに解説記事を用意するのは現実的ではなく、仮に用意できたとしても前章のリスクを負います。一方で、選び方の基準や用途ごとの考え方、業界特有の注意点といった文脈情報は、データでは表現できません。ここが記事の領域です。

投資先	担う領域	必要工数	判断	参考
商品フィードの整備	識別・価格・在庫・配送	中	先に着手	—
構造化データの実装	商品属性の機械可読化	中	並行して進める	—
選び方・比較コンテンツ	判断基準の提示	大	継続投資	商品ページ改善
商品ごとの個別記事	商品固有の説明	大	対象を絞る	—
表記ゆれ対応ページ	該当なし	小	対象外	—

※工数の目安は事業規模により変動します。判断列を自社条件で上書きしてお使いください。

商品データをGoogleへ供給する手段としては、Merchant Centerのフィードが公式に案内されています。生成AIの回答には商品情報が含まれる場合があり、フィードを通じた供給が表示の機会につながるとされています。実店舗を持つ事業では、ビジネスプロフィールの整備もあわせて検討してください。

上の表で判断が分かれやすいのが商品ごとの個別記事です。全商品に展開するのではなく、購入の判断が難しい商材や、比較検討に時間がかかる価格帯に絞ることで、工数とリスクの両方を抑えられます。

出典：Google Merchant Center ヘルプ『Merchant Center に商品をアップロードする方法』（公開日記載なし）（2026年7月26日確認）

発注が完遂できるかどうかが、エージェント時代の競争力を分ける

もう少し先の話として、AIが購入の実行まで担う場面を考えておく必要があります。

AIエージェントは、画面の描画結果を解析したり、DOM構造を参照したり、アクセシビリティツリーを解釈したりしながらサイトを操作します。生成AI機能そのものの動きについてはGoogleのAIモードの機能解説で扱っています。人間が見て分かる画面であっても、機械が構造を追えなければ、途中で操作が止まります。

自社のサイトがどの段階まで到達できるかは、実際にエージェントを動かしてみなければ分かりません。特に、仕様の組み合わせで注文内容が決まる商材や、データの入稿を伴う商材では、第2段階で止まる可能性が高くなります。

エージェント経由の取引を標準化する動きとしては、Universal Commerce Protocolのような規格が登場しています。Google公式ドキュメントも、検索エージェントができることを広げる規格として言及しています。ただし日本での提供は2026年7月時点で開始されておらず、いまは準備期間にあたります。

出典：web.dev『Agent-friendly website best practices』（公開日記載なし）（2026年7月26日確認）

顧客の探索行動を外部AIに明け渡すと、出し分けの精度が落ちる

ここまでは露出と取引の話でしたが、それとは別に見落とされやすい影響があります。

購買データを活用して顧客ごとに表示を変える仕組みは、多くのECが強みとしてきた領域です。同じ検索語であっても、業種や過去の購入履歴に応じて上位に出す商品を変える設計が、探しやすさを支えてきました。この仕組みは、顧客がどんな条件で何を探しているかというデータの蓄積に依存しています。

法人向け間接資材通販のモノタロウは、この点を経営課題として捉えました。同社は約2800万点の商品を扱い、医療系の顧客と製造業の顧客とで同じ検索語に対する表示を変えるといった設計を積み重ねてきた事業者です。

AIが顧客の要望をくみ取り、商品の比較や推薦を代替するようになれば、EC事業者は誰が何を探しているのかというデータを得にくくなります。最終的にECサイトへ送客される構造が変わらないとしても、事業者にとって無視できない変化です。データを活用してサービスを改善してきた立場から、常務執行役CTOの普川泰如氏は次のように述べています。

「データが取れなくなるのは大きなリスクだ」（AWS Summit Japan 2026 講演セッション／2026年6月25〜26日）

同社の対応は、自社の購買AIエージェントを内製してECサイトに組み込むというものでした。開発を決めたのが2025年秋、本格着手が同年12月、リリースが2026年3月末で、期間は約4か月です。現在は一部の顧客向けに限定公開されており、その段階で、過去に買った商品を再び求める「リピート購買」の購入率が、指名検索や用途検索に比べて約2倍高かったと報告されています。

出典：ITmedia ビジネスオンライン『「ねこ」検索で「手押し一輪車」表示――モノタロウが守った、生成AIに“譲れない”購買体験』（2026年7月2日公開）（2026年7月26日確認）

自社にAI接点を持つ選択肢には、前提条件がある

前章の事例を見て、自社でも同じ方向を検討したいと考える場合、確認すべき条件があります。

先行事例が短期間で構築できた背景には、既存の資産がありました。2024年から運用していたベクトル検索、自社で開発してきた検索エンジン、そして蓄積された購買履歴データです。これらの上に生成AIを組み合わせたため、約4か月という期間に収まりました。ゼロから同じ範囲を構築する場合、必要な期間と投資は大きく変わります。

三つ目の運用体制は見落とされやすい条件です。大規模言語モデルは同じ質問に対して毎回同じ回答を返すとは限らず、問題が報告されても再現できない場合があります。先行事例でも、観測性の水準を大幅に上げる必要があるという課題が挙げられていました。作って終わりではなく、動かし続けるための設計が求められます。

判断の順序としては、外部AIでの現在地を測ることを先に置くべきでしょう。どの条件で候補から外れているかが分からないまま自社側の開発に投資すると、効果の検証ができません。

測定は「候補化」「推薦」「引用」を分けて行う

施策の効果をどう確認するかという問題が残ります。ここで指標の設計を誤ると、改善の方向を見失います。

引用の有無だけを成果指標に据えると、実態を見誤ることになります。自社のページが引用元として使われていても、回答の本文では競合の商品ばかりが推薦されている場合があるためです。逆に、自社サイトが直接引用されていなくても、比較メディア経由で自社の商品が有力候補として挙げられているなら、一定の成果が出ていると判断できます。

候補化

質問に対する選択肢のひとつとして自社の商品が挙がる割合

推薦

明確に推奨される形で提示される割合

最上位推薦

第一候補として提示される割合

公式引用

自社サイトが回答の根拠として引用される割合

なおこの4区分は、当社が観測のために定義した自社指標であり、公式の評価指標ではありません。自社の商材特性に合わせて定義を調整していただいて構いません。

測定の基準としては、Search Consoleの生成AIパフォーマンスレポートが一次の手段になります。外部ツールを併用する場合も、Googleの内部指標にアクセスできる第三者ツールは存在しないという公式の注意喚起を踏まえ、方向性の把握に留めてください。効果測定の考え方全般はSEO対策の効果と測定方法で扱っています。

商品データの整備より先に着手すべきケースもある

ここまでの整理は多くのECに当てはまりますが、優先順位を変えるべき状況もあります。

指名検索とリピート購入が売上の大半を占める場合

ブランド名を含む検索は、AI Overviewが表示される頻度が低い傾向にあります。売上の構成として指名検索と既存顧客のリピートが大半を占めているなら、AI検索経由の新規獲得は事業への影響が限定的です。この場合はブランド認知の維持と既存顧客との関係強化を優先し、商品データの整備はその次に置いて構いません。

商品データの更新体制が整っていない場合

価格や在庫のデータが手作業で更新されている、あるいは更新の頻度が週単位という状況では、フィードを整備しても古い情報が供給され続けます。誤った情報でAIに推薦されると、購入できない商品への誘導が増え、露出があるほど損失が拡大します。まずは更新の仕組みを整えることが先になります。

当社の支援においても、データ更新の体制が整わないまま露出だけを増やす進め方は、成果の設計が難しくなります。着手前に更新頻度と担当体制を確認させていただいています。

ECのLLMO対策に関するよくある質問

EC特有の論点について、寄せられることの多い質問へ短く回答します。前提によって答えが変わる項目は、本文の該当章もあわせてご確認ください。

Q. 記事コンテンツはもう作らなくてよいのでしょうか

A. 商品固有の情報はデータ側が担いますが、選び方の基準や用途ごとの考え方といった文脈情報は記事の領域です。役割を分けて投資してください。

Q. 商品ページを増やすとペナルティを受けますか

Q. 構造化データは実装すべきでしょうか

Q. Merchant Centerへの登録は必要ですか

Q. エージェント対応は今から始めるべきですか

Q. 自社でAIを持つべきでしょうか

記事を増やす前に、商品データの整備状況を確認することが出発点になる

ECのAI検索対応では、コンテンツの制作量よりも、機械が読み取れる形で商品情報が揃っているかどうかが先に問われます。属性の欠損や更新の遅れは、記事の質では補えません。判断の要点を整理します。

着手前に押さえる要点

• 最初に確認するのは記事の本数ではなく商品データの整備状況
• 価格と在庫は更新頻度そのものが成果を左右する
• ページは買い手の意思決定が変わる単位で作る
• 記事は選び方や用途の文脈を担い、商品固有の情報はデータ側が担う
• 購入フローが機械的に追える構造かどうかを早めに確認しておく

ページを増やす方向には、条件によってスパムポリシー違反のリスクが伴います。判断の単位を「買い手の意思決定が変わる場面」に置けば、網羅性を高める作業と違反の境界を実務で区別できます。さらに先を見れば、AIが購入の実行まで担う場面が視野に入っており、自社の購入フローが機械的に追える構造かどうかが競争力を左右します。LLMOという用語の整理や基本的な考え方についてはLLMO対策とSEOの違いで解説していますので、あわせてご確認ください。