サイズ表から始めるアパレルD2CのAI検索設計

必要なものは4つです。第一に、色とサイズまで分けたSKU別の商品事実表。第二に、採寸方法まで説明したサイズ表。第三に、素材・着用感・コーデを結ぶ根拠。第四に、商品ページ、構造化データ、商品フィードを同じ内容に保つ運用です。

最初の作業は、売れ筋商品の紹介文を書き直すことではありません。まず1商品を選び、購入できる色・サイズの組み合わせを1行ずつ並べます。各行に価格、在庫状態、商品URL、画像URL、素材、実寸を入れ、ページに見える情報と照合してください。この表が空欄だらけなら、AI検索向けの記事を増やす前に商品データを整えるべきです。

アパレル・ファッションD2CのLLMO対策とは、商品、バリエーション、サイズ、素材、着用場面、購入条件を、読者にも検索システムにも確認できる形で公開し、同じ事実をページ・構造化データ・商品フィードで一致させる情報設計です。特定のAI回答への掲載を保証する施策ではありません。

たとえば「黒のワイドパンツで、低身長でも丈を選びやすいブランド」「洗えるメンズセットアップを通販で買いたい」という質問には、ブランドの雰囲気だけでは答えられません。股下、サイズ体系、素材混率、洗濯表示、上下の組み合わせ、在庫、返品条件まで比較できて初めて、候補として説明できます。

1. 最初に作るのはSKU別の商品事実表

商品ページの文章より先に、事実の置き場所を決めます。アパレルでは、同じデザイン名でも色とサイズが違えば在庫、画像、識別子、場合によっては価格が変わります。親商品だけを1行にまとめると、「ネイビーのMは買えるがブラックのMは欠品」といった状態を表せません。

商品事実表は、購入できるバリエーションごとに1行を基本とします。Google Merchant Centerの公式資料も、色・サイズ・素材・柄のバリエーションを固有の商品として登録し、共通の item_group_id でまとめる方法を案内しています。Google検索向けのバリエーション構造化データでは、ProductGroup と Product を使い、variesBy、hasVariant、productGroupID などで関係を表します。どちらも「親商品と購入単位を分ける」という考え方は共通しています。

この表はCMS、在庫管理、フィード、構造化データをつなぐ管理表です。ただし、AI検索が参照する商品情報は、読者がアクセスできる商品ページでも確認できる必要があります。管理画面にだけ詳しい情報があっても、公開情報の根拠にはなりません。

2. サイズ表を「実寸」と「選び方」に分ける

サイズ表には、少なくとも3つの層があります。

1. 商品タグのサイズ名：S、M、L、38、40など
2. 商品そのものの実寸：肩幅、身幅、着丈、袖丈、ウエスト、股上、股下など
3. 体型や好みに応じた選び方：ジャスト、ゆったり、重ね着向きなど

この3つを混ぜると、事実と助言の境目が分からなくなります。「Mは身長165〜175cm向け」とだけ書いても、肩幅や胴回り、丈の好みは判断できません。反対に実寸だけを数字で並べても、どこをどう測ったかが違えば比較できません。

採寸方法をサイズ表の一部にする

「身幅」は脇下の直線なのか、胸囲として一周分なのか。「ウエスト」は平置き寸法なのか、ヌード寸法なのか。測定位置と単位を明記します。伸縮素材なら、無理に伸ばさない平置き値か、伸長範囲を別項目で示します。個体差が生じる商品は、許容差を自社の測定基準に基づいて記載します。

寸法は画像だけに閉じ込めず、HTMLの表や本文でも読めるようにします。画像は測定位置を伝える補助として有効ですが、数値そのものが画像にしかないと、画面読み上げ、コピー、比較、検索で扱いにくくなります。

モデル着用情報と商品実寸を分ける

「身長172cm、M着用」は参考になりますが、それだけでMの寸法を表すものではありません。モデル情報には、可能な範囲で身長、着用サイズ、着用の意図を添えます。肩幅や胸囲などを載せる場合は、本人の同意と社内の個人情報方針に従います。購入者レビューでも、体型情報の入力を必須にせず、公開範囲を明確にする必要があります。

サイズ体系を明示する

同じ「M」でも、ブランド、対象国、カテゴリで基準が異なります。Googleの商品データ仕様には size に加え、アパレル向けの size_type と size_system があります。日本基準なら JP、欧州基準なら EU といった体系を、実際の設計に合わせて指定します。レギュラー、プラス、プチ、トールなどの区分も、該当する場合だけ正確に使います。

サイズ選びは、「この身長なら一律にM」と断定せず、条件を分けます。

• 肩をすっきり見せたい場合は肩幅を見る
• 重ね着する場合は身幅と袖幅の余裕を見る
• 裾上げを避けたい場合は股下と靴を履いた時の丈を見る
• 上下別サイズのセットアップは、それぞれの実寸で選ぶ

ここまで書けば、「サイズ感 レビュー」という質問に対し、公式実寸と購入者の感想を混同せずに説明できます。

3. 素材名を着用場面までつなげる

素材欄が「綿混」「ポリエステル」だけでは、着用判断に十分とは限りません。素材の事実と、そこから導く着用上の説明を分けます。

まず事実として記載するのは、素材名、混率、生地組織、裏地の有無、伸縮性の測定有無、透け感の確認条件、厚み、重量、原産国表示、洗濯表示などです。次に、その事実から言える範囲で「どの季節・場面で使いやすいか」「何と合わせやすいか」を説明します。

「吸湿性」「防シワ」「UVカット」などの機能は、素材メーカーの仕様、試験方法、適用範囲を確認します。生地一般の性質を、その商品で検証した性能のように書かず、条件も一緒に示します。

色名も揃えます。商品ページが「オーシャン」、フィードが「ブルー」、在庫管理が「BL」とばらばらなら、同じバリエーションか判定しにくくなります。Googleは、商品データの色名をランディングページの色名に合わせるよう案内しています。ブランド独自色を使う場合は、その名称を各所で一致させたうえで、本文に「青みのある緑」のような見た目の補足を加えると、検索者の一般語とも接続できます。写真の表示環境で色が異なって見える可能性も明記します。

4. 「おすすめブランド」の比較単位を設計する

「白シャツ おすすめ ブランド」のような質問では、1枚の商品だけでなく、ブランドの得意分野が比較されます。カテゴリ、サイズ範囲、価格帯、素材方針、販売方法、配送・返品条件を、現在の事実として確認できるページが必要です。

ブランド紹介ページには、次の要素を置きます。

• 主に扱うカテゴリと代表的な商品群
• 想定する着用場面と、向いている人・向きにくい人
• サイズの展開範囲とサイズガイドへのリンク
• 価格帯を示す場合は、対象カテゴリと確認日
• 素材や生産背景について確認できる根拠
• 販売地域、配送範囲、返品・交換条件
• 商品一覧、コーデ、レビューへの導線

「上質」「こだわり」といった言葉だけでは比較できません。「家庭で洗えるシャツ」「上下を別サイズで選べるセットアップ」のように、商品群で確認できる特徴へ置き換えます。優位性を断定するなら比較条件と調査範囲が必要です。

AI検索の回答を点検する時は、ブランド名だけでなく、質問の制約を組み合わせます。

回答の見方は、掲載されたかどうかだけではありません。ブランド名が正しいか、理由が自社ページの事実と一致するか、古い価格や終了商品が混ざっていないか、引用元へたどれるかを記録します。確認観点はAI検索でブランド名を調べた時に確認すべき回答パターンでも整理しています。

5. コーデ情報を商品ページへ戻せる形にする

コーデ記事は、画像を並べるだけでは商品データになりません。写真の中で着用しているトップス、ボトムス、アウター、靴を、それぞれ商品IDとURLで特定できるようにします。販売終了品を含む場合は、その状態を示し、代替品を自動的に同一商品として扱わないようにします。

コーデ1件に、着用商品、色とサイズ、モデルの身長、着用目的、季節、シルエット、組み合わせ可否を持たせます。色違いの商品画像と着用画像を対応させ、代替テキストには見えている事実を簡潔に書きます。

「セットアップ メンズ 通販」に応えるなら、さらに次の区別が必要です。

• 同素材・同色で企画された正式なセットアップ
• 別売りだが組み合わせ可能な商品
• スタイリング上合わせただけの商品

正式なセットアップなら、対応する上下の親商品ID、色、上下別サイズの可否、合計価格、在庫を示します。トップスとパンツを別々に販売する場合、同一商品の色・サイズ違いとして同じバリエーショングループへ入れず、別商品の関連として管理します。「セットアップ対応」と書きながら相手の商品へ移動できない状態は避けます。

商品、サイズガイド、素材説明、コーデ記事は、それぞれを孤立させずに相互リンクします。関連ページのつなぎ方はAI検索向けの内部リンク設計も参考になります。リンク文は「詳しくはこちら」ではなく、「このジャケットの実寸と採寸方法」「同素材パンツの在庫」のように、移動先で分かることを明示します。

6. レビューをサイズ感の証拠として整える

アパレルのレビューは、星の平均だけでなく「どのサイズを買い、どこがどう合ったか」に価値があります。自由記述だけに頼らず、購入商品・購入サイズ・普段選ぶサイズ・フィット感・丈・着用目的を、回答しやすい項目に分けます。身長や体型に関する情報は任意とし、公開目的と範囲を伝えます。

レビュー本文では、感想と商品事実を区別します。「チクチクしなかった」はその購入者の感想であり、すべての人に刺激がないことの証明ではありません。「洗濯後も縮まなかった」も、洗濯方法や回数が不明なら一般化できません。投稿日時、購入サイズ、確認済み購入者かどうか、スタッフコメントかどうかを表示すると、読み手が証拠の性質を判断できます。

収集時に揃える項目

• 対象のSKUまたは親商品
• 購入したサイズと色
• 普段選ぶサイズ
• 丈、肩、胸、腰、太ももなど部位別のフィット感
• ジャスト、ゆったりなど購入者が望んだ着方
• 着用した季節・場面
• 手入れ後の感想なら方法と回数
• 投稿日と更新履歴

低評価を隠したり、スタッフの文章を購入者レビューとして扱ったり、特典付き投稿であることを伏せたりしてはいけません。レビューの修正・削除基準も公開します。構造化データの Review や AggregateRating を使う場合は、ページで読者に見えるレビューと集計に一致させます。存在しない評価をマークアップしても、信頼できる根拠にはなりません。

レビュー運用全般は口コミをAI検索で扱うための実務に分け、本稿では購入サイズとフィット情報を商品へ結び付ける点を優先します。

7. ページ・構造化データ・フィードを一致させる

商品情報には、少なくとも3つの出口があります。読者が見る商品ページ、検索エンジンへ意味を伝える構造化データ、各サービスへ渡す商品フィードです。3つは同じ元データから出し、独立した手入力を減らします。

Googleの公式資料では、商品ページへ Product と Offer の情報を付けることで、価格、在庫、評価、配送などを検索結果の機能で扱える可能性があります。アパレルのバリエーションには ProductGroup を使えます。ただし、正しく実装しても検索結果への表示は保証されません。構造化データは、読者に見えない情報を追加するための隠し欄でもありません。Googleの一般ガイドラインは、マークアップ対象をページの主要内容と一致させ、読者に見えない内容をマークアップしないよう求めています。

商品フィードでは、各バリエーションを購入単位として出します。Google Merchant Centerでは、衣料品・靴のサイズやアパレルの色などに、対象地域や掲載面に応じた必須条件があります。size、color、material、pattern、item_group_id、size_system などは、最新の公式仕様を確認して設定します。2026年10月時点の仕様では、サイズがバリエーションを決める項目なら、variant_option と size の両方で示すことも推奨されています。実装時には対象国、商品カテゴリ、利用する掲載面による条件差を確認してください。

OpenAIの公式Product feeds資料にも、購入できる商品またはバリエーションごとに1行を送り、親を共通の group_id でまとめる仕様があります。StableとDraftが分かれているため、実装ではStableの項目を使います。検索対象に設定できることと、ChatGPTで表示されることは同義ではなく、公式仕様も表示を保証していません。標準アップロードの対象市場や利用申請などの条件も変わり得るため、着手時点の公式資料で確認します。

ChatGPTショッピングを含むEC共通の商品フィードやクロールの論点は、EC企業向けのChatGPTショッピング対策で扱っています。アパレルでは、その共通基盤へサイズ、色、素材、柄、コーデ関係を欠けなく載せることが追加課題です。

照合では、名称・素材・サイズ・画像、価格・通貨・在庫、親ID・SKU・選択URL、配送・返品、レビュー件数と対象商品を確認します。代表的な異常は、購入できないSKUが InStock のまま、選択色と画像が違う、セール終了後も旧価格が残る、返品条件がページ間で違う、といった状態です。

8. 優先順位を決める判断表

全部を同時に直す必要はありません。検索される質問と、現状の欠損が大きいところから着手します。

実装チェックリスト

商品とバリエーション

• 親商品IDとSKUの役割が分かれている
• 色×サイズなど、購入可能な組み合わせを1行ずつ管理している
• 各バリエーションを直接選んだ状態へ移動できるURLがある
• 選択中の色・サイズと主画像が一致する
• 終売、欠品、予約、取り寄せを区別している

サイズと素材

• タグのサイズ名と商品実寸を分けている
• 採寸位置、単位、伸縮時の測り方を説明している
• サイズ体系とサイズタイプを実態に合わせている
• 素材名と混率が商品表示と一致している
• 機能性の表現に試験・メーカー仕様などの根拠がある

コーデとレビュー

• コーデ画像内の商品をIDとURLで特定できる
• 正式なセットアップと、単なる組み合わせを区別している
• モデル身長、着用サイズ、着用意図を混同していない
• レビューを対象商品と購入サイズに結び付けている
• スタッフコメント、購入者レビュー、編集記事を表示上も分けている

データと検証

• ページ、構造化データ、フィードが同じ元データを参照する
• 価格、在庫、URL、画像を定期的に照合する
• 構造化データが読者に見える本文と一致する
• リッチリザルトテストと各送信先の診断結果を確認する
• AI検索の回答は掲載有無だけでなく、名称、理由、鮮度、参照元を記録する

9. 失敗しやすい設計

1商品に全サイズを詰め込む

タイトルや説明に「S/M/L、全5色」と書くだけで、個別の在庫や画像を持たせない状態です。購入できる単位ごとにSKUを分け、親IDでまとめます。色だけ違うのか、素材も違うのかを明示します。

サイズ表だけ別ページに置き、商品から遠くする

全商品共通のガイドは測り方の説明に向きますが、実寸まで共通ページだけに置くと対象商品が曖昧です。商品ページに実寸を載せ、共通ガイドへ補足リンクを張ります。

フィードだけ詳しくして、ページ本文を省く

機械向けデータに素材や返品条件があっても、読者が商品ページで確かめられなければ不信につながります。構造化データも、見えている主要内容と一致させます。

コーデ画像から商品へ移動できない

「スタッフコーデ」とだけ表示し、着用商品が売り切れか現行品か分からない状態です。画像ごとに商品と選択バリエーションを結び、販売状態を更新します。

構造化データを入れればAIに載ると説明する

Googleは、正しい構造化データでも検索機能への表示を保証していません。OpenAIの商品フィードにも、検索対象の設定が表示を保証しない旨があります。実装の目的は、商品を正確に理解・検証できる材料を増やすことです。

10. よくある質問

Product構造化データを入れれば、AI検索で紹介されますか？

保証されません。構造化データは、商品、価格、在庫、バリエーションなどの意味を検索システムへ伝える方法です。ページの品質、クロール可否、検索意図、競合する情報、サービスごとの仕様など、ほかの条件も関係します。実装後は構文だけでなく、ページに見える内容との一致を確かめます。

色やサイズは1ページにまとめてもよいですか？

1ページ型と複数ページ型のどちらも考えられます。重要なのは、各バリエーションを直接選択できるURLがあり、選択状態、画像、価格、在庫、構造化データが一致することです。GoogleのProduct variants資料には、単一ページと複数ページの実装例があります。自社のCMSで、検索エンジンと利用者が選択状態を再現できるか確認してください。

サイズ表は画像だけでも問題ありませんか？

測定位置を図で示すことには向いていますが、数値はHTMLの表や本文でも掲載するのが安全です。画像を見られない利用者が確認でき、サイズ同士の比較や検索もしやすくなります。画像とテキストで数値がずれないよう、同じ元データから作ります。

レビューが少ないブランドは何を載せるべきですか？

レビューを作ったり、少数の感想を全員の評価として広げたりしてはいけません。まず商品実寸、採寸方法、スタッフの着用サイズ、返品・交換条件を事実として充実させます。スタッフコメントはスタッフによるものと表示し、購入者レビューとは分けます。

ブランド独自の色名は一般的な色名へ変えるべきですか？

フィードだけ別名へ変えるのは避けます。商品ページに「オーシャン」と表示するなら、フィードも同じ名称に合わせるのがGoogleの案内です。そのうえで、本文に「青みのある緑」のような一般語の補足を、実物に即して加えます。

FAQの構造化データも必要ですか？

先に、サイズ、返品、洗濯、再入荷などの質問へ、ページ上で読める回答を用意します。構造化データだけを追加しても、本文が曖昧なら商品選びには役立ちません。FAQの組み立て方はAI検索時代のFAQ設計で詳しく説明しています。

要点の整理

アパレル・ファッションD2CのAI検索対策は、派手なブランド紹介から始めるものではありません。色とサイズまで分けたSKU、測り方が分かる実寸、根拠のある素材説明、商品へ戻れるコーデ、購入サイズ付きレビューを揃え、ページ・構造化データ・商品フィードで一致させることが土台です。

最初に確認するのは「この商品の黒・Mを、価格、在庫、画像、実寸、素材、返品条件まで一意に説明できるか」です。できなければ、その欠損を商品事実表へ戻して埋めます。できる商品が増えるほど、「おすすめブランド」「サイズ感」「セットアップ通販」のような複合質問にも、推測ではなく公開情報で答えられる範囲が広がります。

着手点を判断しにくい場合は、LLMO診断・AI検索診断で、商品ページ、バリエーション、フィード、構造化データ、実際の回答を横断し、情報の欠損と不一致を点検できます。