「AI時代のSEO、自社サイトも対応しないと」
——そう聞いて検索すると、記事の多くがコンテンツ最適化やAEO（Answer Engine Optimization）の話だ。小売店のHP担当や、自社ECを一人で触っている人にとっては、どこから手を付ければいいのかわからない。
あなたはどうだろう。「AI SEO」記事を読んで、結局ページのHTMLを直す話だった、と気づいた派？ それともまだ記事の中身を区別できていない派？
私は後者に近い人が多いと思っている。この記事はテキスト記事のSEOではない。「ユーザーがAIに頼み、AIが代わりに商品を探して購入に近づく」——その構造変化に、小売・ECサイトがどう備えるかを整理する。前提知識はほぼ不要で、今のページ構成を大きく変えなくても進められる。
大規模リニューアルは不要——「AIに任せればいい」の正しい意味
よくある誤解は、「AIだから全部AIに任せればいい」という雑な解釈。正しくはこうだ。
人間がサイトの骨格（HTML・構造化データ・購入導線）を整え、細部の文案やスキーマ草案はAIに下書きさせる——この分担が現実的だ。
Shopifyの2026年Q1データなど、AI経由のCVRが高いという話は別記事「2026年実データで読み解くAI検索戦略」で触れた。ここでは小売サイト側が触れる実装に絞る。デザインを作り直す必要はない。既存ページに、エージェントが読める情報と操作可能なUIを足していくイメージだ。
何が起きているか：AIエージェントが「ショッピング代行」になる
Shopifyの2026年Q1データが示す事実がある。
- AI検索経由のCVRは通常のオーガニック検索より49%高い
- AI経由の平均注文額は14%高い
- AI経由セッションの55%は商品詳細ページから直接開始（通常は20%）
- AI経由注文数は前年比13倍に成長
背景にあるのは「比較検討の圧縮」だ。
従来、ユーザーは「商品名 + おすすめ」で検索し、3〜5サイトを巡回して比較し、購入を決断していた。AIはこの比較検討を一瞬で終わらせる。
「〇〇の防音イヤーマフで予算5,000円以内のおすすめを教えて。Amazonで買えるもの」
こういった質問にAIが回答し、ユーザーはそのリンクをクリックして購入する——あるいは将来的にはAIが直接カートに入れて決済まで行く。
これはSEOの問題ではなく、サイトがAIエージェントにとって「使いやすい構造かどうか」の問題だ。
AIエージェントはサイトをどう「読む」か
Googleが公開した「エージェントフレンドリーなウェブサイト設計ガイド」によると、AIエージェントはサイトを以下の方法で解析している。
1. アクセシビリティツリー（最優先）
ブラウザが持つアクセシビリティAPIから生成されるデータ構造だ。各要素の「役割（role）」「名前（name）」「状態（state）」を読み取る。
人間の目には見えていても、アクセシビリティツリーに正しく反映されていない要素は、エージェントに存在しないも同然だ。
2. DOM構造（HTML）
HTMLのタグ階層から、情報の論理的な構造・関係性を読み取る。
3. スクリーンショット
視覚的な情報をキャプチャして解析するが、トークンを大量消費する重い処理だ。エージェントは可能な限りアクセシビリティツリーとDOMを優先する。
結論：セマンティックHTMLとアクセシビリティが高いサイトは、AIエージェントにとっても操作しやすい。
小売サイトの具体的な実装チェックリスト
カテゴリ1：HTMLの構造（優先度：高）
<!-- 悪い例：divだけでボタンを作る -->
<div class="btn-buy" onclick="addToCart()">カートに入れる</div>
<!-- 良い例：button要素を使う -->
<button type="button" aria-label="商品名をカートに追加">カートに入れる</button><button>・<a>・<input>などの標準タグを使う<div>・<span>でインタラクティブ要素を作る場合はroleとtabindexを明示する- フォームの
<label>はfor属性で入力欄と紐付ける - ナビゲーション・メイン・フッターは
<nav>・<main>・<footer>を使う
カテゴリ2：商品情報の機械可読性（優先度：高）
AIエージェントが商品を比較するとき、価格・在庫・仕様が明確に読み取れる必要がある。
構造化データ（JSON-LD）の例：
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "防音イヤーマフ Pro",
"description": "NRR値33dB、折りたたみ式、重量225g",
"sku": "EAR-001",
"offers": {
"@type": "Offer",
"price": "4980",
"priceCurrency": "JPY",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.3",
"reviewCount": "127"
}
}重要フィールド：
price・priceCurrency：価格と通貨を明確にavailability：在庫状態（InStock / OutOfStock / PreOrder）priceValidUntil：価格の有効期限aggregateRating：レビュースコアと件数
カテゴリ3：ページの安定性と操作性（優先度：中）
- 重要なボタン（カートに入れる・購入する）はページ間で一貫した位置に配置する
- クリッカブルな要素は8px × 8px以上（視覚モデルで認識できるサイズ）
- コンテンツを覆う透明なオーバーレイ・ポップアップを除去する
cursor: pointerをCSSで設定してクリック可能要素を示す- 動的に変わる価格・在庫はページロード時点で確定させる（JavaScriptの遅延レンダリングを避ける）
カテゴリ4：AIエージェントが信頼できる情報源かの判断（優先度：中）
エージェントは「このサイトから購入しても安全か」を判断する。
- HTTPS接続（必須）
- 返品・交換ポリシーのページが存在し、機械可読な形式で書かれている
- 会社概要・特定商取引法表示が明確にある
- レビューが第三者から集められており（サクラレビュー対策が見えている）
サイトの型別——3パターンの対応
小売サイトは一枚岩ではない。自社でHTMLを触れる範囲が違う。型ごとに「今週できること」を分ける。
パターンA：Amazon・モール型（商品ページを自社で持てない）
Amazon出品や楽天、Yahoo!ショッピングなど、商品詳細のHTMLを自社で書けないケースだ。
ここでできること：
- 商品タイトル・箇条書きスペックを「AIが比較しやすい粒度」で書く（価格帯・寸法・素材・用途を数値で）
- ブランドストアやA+コンテンツがあるなら、画像だけに頼らずテキストでスペック表を置く
- 自社ドメインの「よくある質問」「返品ポリシー」ページを整備し、モールからリンクする（エージェントの信頼判断材料になる）
- 自社ECがあるなら、モール説明文と価格・在庫の表記を一致させる（矛盾はエージェントの除外理由になる）
触れない部分は触れない。リスト改善と自社サイト側の信頼ページ整備——この二点に集中するのが現実的だ。
パターンB：自社サイト＋広告クリック誘導（LP・CVページ）
Google広告やSNS広告からランディングページへ誘導し、購入・問い合わせ・資料請求につなげる型だ。エージェントコマースの文脈では、AIが「このLPから申し込める」と判断できるかがポイントになる。
- 「今すぐ購入」「無料見積もり」ボタンは
<button>または<a href="...">で実装する（画像ボタンだけにしない） - ファーストビューに価格・提供条件・在庫/受付状況をテキストで置く
- 同一キャンペーンでLPが複数あるなら、商品名・価格・CTA文言を統一する
ProductまたはOfferのJSON-LDをLPに載せる（サービスならServiceも検討）- 計測用にUTMを付けるが、エージェント向けの本文情報はパラメータなしURLでも読めるようにする
広告経由の流入は、AI経由と同様「比較済みのユーザー」が多い。LPの情報が曖昧だと、クリック単価を払ってもCVに繋がらない。
パターンC：申込ページ＋メール・電話注文
カート機能のない小規模店舗——フォーム送信やメール注文が主戦場のケースだ。エージェントは将来的に「フォームを埋めて送信する」操作も増える。
- 注文フォームの各項目に
<label for="...">を付ける - 必須項目は
requiredとaria-required="true"を両方使う - 商品選択は
<select>かラジオボタン（<div>クリックだけにしない） - 確認画面を挟むなら、ステップ数を最小に。ポップアップで最終確認を二度出さない
- ページ上に注文用メールアドレス・電話番号・営業時間をプレーンテキストで書く（画像内文字だけにしない）
- 特定商取引法・返品条件へのリンクを
<footer>か<nav>から常に辿れるようにする
「うちはECじゃないから関係ない」にはならない。AIが代行するのはカート操作だけではなく、申込フォーム操作も含まれる。
AIに構造化データと「道案内」を作らせる
HTMLの知識が乏しくても、AIに下書きを作らせて人間が確認・設置する流れで進められる。ここが「AIに任せる」の実務的な意味だ。
手順の全体像
- 自社の商品ページURL（または商品情報のテキスト）をAIに渡す
- JSON-LDの草案と、ページ上の見出し構成案（H1直下に価格・在庫など）を出力させる
- 実際の価格・在庫と照合し、CMSやテーマの「カスタムHTML」欄に
<script type="application/ld+json">として設置 - Googleのリッチリザルトテストまたは Search Console でエラーを確認
Shopify・WordPress・BASEなど、テーマによってはプラグインやアプリでJSON-LDが自動出力される。自動出力がある場合は重複設置に注意——二重のProductスキーマはエラーの原因になる。
プロンプト例1：Product JSON-LDの生成
商品ページのURLや、コピペした商品情報を添付して使う。
あなたはECサイトの構造化データ担当者です。
以下の商品情報から、schema.org の Product 型の JSON-LD を1つだけ生成してください。
**出力ルール**
- JSONのみを出力（説明文は不要）
- priceCurrency は JPY
- availability は InStock / OutOfStock / PreOrder から選ぶ
- 不明な項目は推測せず、そのキーを省略する
- aggregateRating はレビュー件数が10件未満なら省略
**商品情報**
（ここに商品名・価格・在庫・主要スペック・SKUを貼る）プロンプト例2：ページの「エージェント向け道案内」
HTMLを書き換える前に、どの情報をどの順で置くかの設計図をAIに作らせる。
あなたは小売ECのUXアドバイザーです。AIエージェントが商品を比較購入する時代を想定しています。
以下の現状ページ構成を読み、**大規模リデザインなし**で改善できる見出し順と要素リストを提案してください。
**出力形式**
1. 現状の問題点（3つ以内）
2. 推奨するファーストビュー構成（H1の直下に置く要素を箇条書き）
3. ボタン・フォームのアクセシビリティ修正（具体的なHTMLタグ名で）
4. 追加すべきJSON-LDの型（Product / Offer / FAQ など）
**現状のページ情報**
（URLまたはHTMLの抜粋を貼る）プロンプト例3：メール注文型サイトのフォーム改善
あなたはWebアクセシビリティの実務者です。
以下の注文フォームHTMLを、AIエージェントとスクリーンリーダーの両方が操作しやすい形に書き換えてください。
**ルール**
- button / label / select を適切に使う
- div onclick のボタンは禁止
- 出力は修正後のHTMLのみ
**現状のHTML**
（フォーム部分を貼る）生成結果はそのまま本番に貼らない。価格・在庫・法表記は必ず人間が確認する。AIは「道案内」の下書き役だ。
商品ページの情報設計：エージェントが欲しいもの
AIエージェントがユーザーに代わって比較するとき、判断に使う情報は人間が見るのと同じだ。ただし優先順位が異なる。
| 情報 | 人間の優先度 | エージェントの優先度 |
|---|---|---|
| 価格 | 高 | 最高 |
| 在庫状態 | 中 | 最高 |
| 主要スペック | 高 | 高 |
| 画像・ビジュアル | 高 | 中（代替テキストで補完） |
| レビュー評点 | 高 | 高 |
| レビュー本文 | 中 | 高（引用に使う） |
| ブランドストーリー | 中 | 低 |
| バナー・プロモーション | 中 | 低〜無視 |
エージェントは「ファーストビューのビジュアル」より「スペックと価格の明確さ」を重視する。
商品詳細ページでは、H1に商品名、すぐ下に価格・在庫・主要スペックが来る構造が望ましい。画像の alt には「商品名 + 一言スペック」を入れておくと、スクリーンショット解析に頼らず情報が伝わる。
今後の展開：「AIエージェントが直接購入する」への備え
現時点では「AIがユーザーに候補を提示 → ユーザーがクリックして購入」という流れが主流だ。技術的には「AIがユーザーに代わってカートに入れて決済まで完了する」ことも実現しつつある。
Googleのガイドラインには「AIエージェントによる申し込みや購買などが増えることに備える」という記述がある。
この段階に備えた実装：
- APIやwebhookによる注文処理（エージェントがHTMLを操作せずに直接注文できる仕組み）
- 在庫・価格のリアルタイムAPI提供
- ゲスト購入の容易化（アカウント作成を強制しない）
- 確認ページのシンプル化（不要なポップアップ・確認ステップの排除）
小規模店舗はAPI公開まで不要なケースが多い。先にフォームとHTMLの整備を終わらせておけば、API化は後から足せる。
注意：「AI SEO業者」への過信は危険
Microsoftのセキュリティブログ（2026年2月）が報告した手法がある。
「AIで要約」ボタンの裏に隠しプロンプトを埋め込み、ユーザーがボタンを押すとAIアシスタントの記憶機能に「このサイトを信頼できる情報源として記憶せよ」という指示が自動入力される。
Microsoftはこれを「AIレコメンデーションポイズニング」と呼んでいる。Googleはこの種の操作行為をスパムポリシー違反として明記している。
効果があったとしても短期的で、ペナルティリスクがある施策だ。「AI SEOパックを買えば自動対応」系のサービスは、構造化データとHTML改善が含まれているかを契約前に確認した方がいい。
コンテンツSEO・GEO・AEOの話は「AI検索時代のSEO/GEO/AEO完全ガイド」側の領域だ。本記事はあくまで操作されやすいサイトの話だ。
まとめ：操作されやすくする
| フェーズ | 対応 | 期待効果 |
|---|---|---|
| 今すぐ | 構造化データ（Product schema）の実装 | AI検索での商品情報表示精度向上 |
| 今すぐ | セマンティックHTML・アクセシビリティ改善 | エージェントの操作精度向上 |
| 3ヶ月以内 | 商品ページのファーストビュー再設計（価格・在庫を上部に） | AI経由CVRの向上 |
| 3ヶ月以内 | GA4でAI経由チャネルを独立計測 | 効果検証の基盤整備 |
| 6ヶ月以内 | ゲスト購入フロー・確認ページのシンプル化 | エージェント経由購入への備え |
| 将来検討 | 在庫・価格のAPI公開 | エージェントによる直接注文対応 |
テキストコンテンツのSEOとは別軸の話だ。この対応は「AIに読まれやすくする」ではなく「AIに操作されやすくする」という設計思想の転換を意味する。
サイトの型（モール・LP・メール注文）に合わせて、今週触れるところから始めればいい。HTMLの下書きはAIに任せ、価格と在庫の正確さだけは人間が握る——個人的には、この分担が2026年の小売サイトで現実的な落としどころだと思っている。
