「これ、どこで買えますか？」「○○に強いのはどの会社？」——最近は、こうした問いの答えをAIに聞く人が増えています。ところが、実際にその商品を扱っている自社の名前が、AIの回答には出てこない。商品は売っているし、ページもあります。それなのに出てこない——これはSEOだけでは説明がつかない、新しいタイプの課題でした。
私たちは、自社で運営している越境フィットネスEC（海外のフィットネスギアを正規取扱する越境セレクトEC）を題材に、この「AIに見えない」状態を計測し、原因をデータ構造のレベルまで掘り下げて、商品データを作り直してみました。本稿はその実装記録です。テーマはコンテンツの量ではなく、機械が読める形にデータを構造化すること——私たちが事業の中心に置いている AI-Ready Data そのものです。
先に結論をお伝えします。AIに見えない原因の多くは「情報が足りない」ことではなく、「情報が機械の読める構造になっていない」ことにあります。そしてこれは、納品物ではなく、社内に残せる設計力で解ける問題です。
題材: 越境フィットネスEC
題材にしたのは、欧州・北米・豪州の海外フィットネスブランドを正規取扱する越境セレクトECです。日本ではまだ流通の薄いギアを扱っているぶん、検索の世界では「海外ブランド名 × 日本で買う」という問いにどう答えてもらえるかが、そのまま売上導線の入口になります。
EC本体は、ちゃんと動いています。課題は、AI検索・生成AIの回答のなかで「正規取扱店」として想起してもらえるか——この一点に絞られていました。
ステップ1: 「見えなさ」を計測する — その前に、計測自体を疑う
まず取りかかったのは、いまの可視性をベースラインとして数値化することでした。生成AIに対して、指名・カテゴリ・状況・How-toの4系統で15個のクエリを設計し、各クエリの上位10件、合計150件を観測しました。
ところが、ここで計測そのものに3つの欠陥が見つかります。データを語る前に、まず「データの取り方が信用できるか」を潰しておく必要がありました。
- コンテキスト汚染: 同じチャットの中でクエリを続けて実行すると、AIが前の問いの情報を引きずってしまいます。→ クエリは毎回、新しいチャットで実行する。
- Web検索ON/OFFによる幻覚: Web検索をオフにすると、AIは訓練データだけで答えてしまい、実在する自社ストアを「同名の海外インディーバンド」と取り違えて埋めてしまうことがありました。→ Web検索ONを明示する。
- クエリの曖昧さ: 「グリップ 選び方」のような言葉は、別カテゴリ（ゴルフなど）の文脈に流れてしまいます。→ 「機能性フィットネス グリップ 選び方」のように、検証したい意図を一意にする。
これらを直す前のデータは、信頼できる指標としては採用しませんでした。計測の条件を固定して、はじめて改善の前後を比較できる——これはお客様のデータ活用でも最初に効いてくる規律で、ダッシュボードの数字を信じる前に、その数字がどう作られたかを点検するのと同じことです。
条件を揃えて取り直したベースラインは、正直なところ厳しいものでした。150件の観測のうち、自社ストアが現れたのはわずか1回（指名検索で4位）。「ブランド名 → どこで買える」の逆引きが、機械のなかではまだ結びついていなかったのです。
なお本稿は、ここから構造を整え終えた段階での記録で、同じ条件での再計測はこれから行います。ですので「1件から何件に改善した」という成功談ではなく、AIに読まれる形へデータを作り直すまでの実装記録として読んでいただければと思います。効果の検証は、整えたあとにこそ正しく測れます。
ステップ2: 原因をデータ構造のレベルで特定する
可視性の低さを「発信不足」で片づけてしまわずに、商品データの構造をひとつずつ点検しました。出てきたのは、コンテンツではなく構造の問題でした。
- 構造化データ（JSON-LD）の欠落・不整合: 返品ポリシーや配送情報、商品スニペットに必要なフィールドが欠けていて、検索側が商品の素性を確定できない状態でした。
- 表記揺れによる属性の取りこぼし: 商品バリアントのオプション名が全角カタカナの「カラー」になっていた商品で、検索側が色の属性を認識できていませんでした（「色」または「Color」なら認識されます）。データの中身ではなく、キーの表記ひとつで機械が読めなくなる、典型的な例です。
- ブランド情報の出力ミス: 全商品の vendor 値が運営者名で統一されていたため、構造化データ上のブランドが、取扱メーカー名ではなく運営者名として出力されていました。「正規取扱店」という立ち位置と、機械が読むデータが食い違っていたわけです。
どれも「見ればわかる不足」ではなく、「機械の目線で読まないと気づけない不整合」でした。ここが AI-Ready Data の肝で、人間が読めることと、機械が正しく解釈できることは別物なのです。
ステップ3: メタフィールド駆動で商品データを作り直す
打ち手は、商品ページを手書きで飾ることではなく、構造化した属性をデータとして持たせ、表示とJSON-LDを自動で生成する設計にすることでした。商品ごとに21個のメタフィールドを定義し、6つのカテゴリに整理しました。
- A. ブランド情報（7） / B. 商品仕様（7） / C. SEO・GEO（3） / D. FAQ（1・JSON型） / E. 関連（1・参照型） / F. 信頼性（2）
設計上の判断も、いくつか残しておきます。読者のみなさんの現場にも、そのまま持ち帰れる類のものです。
- vendorは触らず、ブランドはメタフィールド経由で上書きする。既存の vendor 値を一括で変えるより、ブランド情報フィールドから正しいブランドを供給するほうが、SEOの面でも運用の面でもシンプルで壊れにくくなります。データの「正」を一箇所に寄せる発想です。
- 型を使い分ける。リスト型・JSON型・参照型を、属性の性質に応じて選び、表示とスキーマの両方から同じデータを参照します。表記揺れを上流で消しておけば、下流で何度も直さずに済みます。
- 権利表現の線引きをルール化する。大会名や選手の実績の引用はOK、店舗カテゴリを商標で名乗る表現はNG（一般名詞に置き換え）。これも一種のデータガバナンスで、何を書けて何を書けないかを、設計の段階で決めておきました。
あわせて、正規取扱の宣言ページ、ブランドの位置づけを示すページ、商品マスタの構造化、外部の商品データ連携、そしてAI検索のバックエンドにあたる検索基盤への登録まで、依存関係の順に整えていきました。
ここで効いてくるのが、商品の世界共通の識別子（GTIN／JANコード）と、商品フィードの整備です。GTINがないと、AIの買い物検索は手元の商品を世界の商品データベースと照合できず、候補から外してしまいます。さらに、Google Merchant Center に流す商品フィードは、いまや ChatGPT のショッピングや Google の AI Overviews、Perplexity といった複数のAIが共通で参照する供給源になっています。そして地味に効くのが、価格や在庫がフィードとサイトでズレていないかという一貫性です。AIは、値段が食い違う商品を「データが信用できない」とみなして、候補からまるごと外してしまうからです。
SEO対策と何が違うのか — GEO / AIO の視点
ここまでの打ち手は、従来のSEOと重なる部分もありますが、狙いははっきり違います。ざっくり言えば、SEOは「検索結果のリンク一覧で上位に並ぶ」ための最適化、GEO（Generative Engine Optimization）／AIO（AI Optimization）は「AIが生成する“ひとつの答え”のなかで、正しく引用・想起される」ための最適化です。並び順を競うのか、要約に採用されるのか——ゴールが違えば、効く打ち手も変わってきます。
今回、GEO／AIO だからこそ効いたと感じた打ち手は、次の3つでした。
- エンティティの曖昧さを消す（名寄せ）: SEOではあまり問題にならない「同名の海外インディーバンドと取り違えられる」現象は、AIが文脈から実体を推定するからこそ起きます。ブランド・店舗・取扱関係を構造化データで明示して、「何者か」を機械に確定させることが、キーワードの最適化より先に効きました。
- モデルがそのまま引用できる“事実”を置く: 上位表示ではなく要約への採用を狙うなら、AIが抜き出しやすい形——FAQのJSON、正規取扱の宣言、配送・返品といった確定情報——を構造として用意しておくことが効きます。人間向けの説得文よりも、機械が転記できる事実のほうが、回答に乗りやすいのです。
- AI検索の“引く側”に登録する: 検索エンジンにインデックスさせるだけでなく、AI検索のバックエンドにあたる検索基盤に商品データを登録し、AIが回答を組み立てるときに参照できる状態をつくりました。リンクを辿らせるのではなく、引かれるデータとして置いておく、という発想です。
裏を返せば、ページ速度や被リンクといった従来のSEO資産がムダになるわけではありません。土台は共通で、その上に「機械が実体を取り違えず、事実を引用できる」層を重ねるのが GEO／AIO だと捉えています。
この事例が示すもの
ここでやったことは、特別なツールを導入することではありません。自社が持っているデータを、機械が正しく読める構造に整え直しただけです。それでも、効果の出かたはコンテンツを足すのとは質が違います。構造が整えば、同じ商品データが検索にもAIにも、そして将来の別の用途にも使える形になります。
「AIがうまく使えない」という声をよく聞きますが、その原因はモデルよりもデータ基盤の側にあることが多いです。今回の事例は、その縮図を自社で起こして、自社で解いてみた記録です。御社の商品データや顧客データも、人間には読めるけれど機械には読めない構造になっていないか——そこを点検するところから、AI時代の足場づくりは始まります。
私たちが残したいのは、整ったデータそのものよりも、自社のデータを機械可読に保ち続けるための設計の型です。外部への依存ではなく、内部の能力を。コードを納品するのではなく、データで意思決定できる組織を残したいと考えています。
自社で点検できる AI-Ready チェックリスト
ここまでの内容を、自社のデータに当てはめてみてください。ひとつでも「あやしい」と思ったら、それがAIに見えていない入口かもしれません。
- 主要ページに構造化データ（JSON-LD）が入っているか — 商品なら名称・価格・在庫・ブランド・SKUを、表示内容と一致する形で。Googleのリッチリザルトテストで検証できます。
- 商品にGTIN（JAN／EANコード）が付いているか — これが無いと、AIの買い物検索は世界の商品データベースと照合できず、候補から外してしまいます。
- 冒頭で問いに即答できているか — AIはページの最初のほうを重く見ます。FAQ形式の構造化も、要約への採用率を上げます。
- 主張に裏づけ（数字・出典・引用）があるか — 研究でも、統計や出典の明示が「引用されやすさ」を大きく押し上げると報告されています。
- 自社の実体（エンティティ）が名寄せされているか — ブランド・会社・取扱関係を一貫した表記で明示し、同名の別物と取り違えられない状態に。
- 第三者の独立した場所で言及されているか — 業界メディアやレビューなど、外部からの言及がAIの信頼度を上げます。
- 価格・在庫がフィードとサイトで一致しているか — 食い違うとAIは「信用できないデータ」とみなし、候補からまるごと外します。情報の更新日（鮮度）も保ちましょう。
- AIから見えているかを定点観測しているか — 新規チャット・Web検索ONなど条件を固定して、自社が想起されるかを定期的に確認する。
「いくつ当てはまるか自信がない」という段階でも大丈夫です。どこから着手すべきかは、現状を見れば整理できます。
自社データがAIに読める構造になっているか、30分の無料診断で点検します。