レポート | 2026年のDTC AI検索対応ギャップ

エグゼクティブサマリー

本調査では、1,238のDTCドメインを対象に、AI検索への対応状況を4つの層で採点しました。評価したのは、AIファイルの品質、一般的な構造化データ、商品ページの構造化シグナル、メタデータです。平均スコアは100点中36.4点、中央値は37.0点でした。このスコアモデルでai_readyティアに分類されたのは11ドメインです。

主要な結果は、サイトを発見できる状態と、商品単位の情報を機械が扱いやすい状態との間に差があることです。llms.txtの品質バケットではplatform_defaultが最も多く、629ドメインでした。多くのブランドには、利用中のプラットフォームが自動生成した基本的なAI可読ファイルがあります。一方、ホームページでProduct schemaが検出されたのは、採点対象ドメインの0.9%でした。商品ページのProduct schemaも、取得を試みた対象の39.2%にとどまります。商品ページの価格シグナルは48.1%、レビューや評価のシグナルは**43.5%**でした。

ティア分布からは、この評価モデルにおける対応状況がまだ初期段階にあることが読み取れます。

AI対応ティア	ドメイン数
未対応	435
部分的に対応	425
基本的な発見可能性	367
AI対応	11

この分布は、混同されやすい3つの状態を切り分ける際に役立ちます。サイトが見つけやすいこと、メタデータやllms.txtが存在すること、商品単位の情報を機械が扱いやすいことは、それぞれ異なる評価項目です。

llms.txtの品質分布を見ると、その違いがさらに明確になります。

llms.txtの品質バケット	ドメイン数
プラットフォーム標準	629
欠如	388
ソフト404	133
手動・軽量	57
手動・構造化	31

したがって、本レポートの中心的な結論は、llms.txtの有無だけではAI検索への対応状況を評価できないという点です。プラットフォームの標準機能によって初期的な発見可能性は生まれている一方、多くのDTCブランドでは、AIショッピングや回答エンジンが参照できる商品レベルの構造化データ層が十分に整っていません。

比較的高いスコアの事例を見ると、この評価モデルで対応度が高い状態の構成が分かります。ai_readyティアには、Mokobara、Magic Mind、Le Petit Ballon、Maine Lobster Now、Yo Mama's Foods、La Maison Convertible、Unbloat、NuRange Coffee、Three Ships Beauty、Manukoraといったブランドが入っています。食品、美容、ウェルネス、家具、アパレル、専門商材のECが含まれており、商品情報の機械可読性は特定のカテゴリだけに限定された課題ではないことが分かります。

主要な調査結果

DTCのAI対応スコアの平均は36.4/100でした。
1,238件の対象ドメインのうち、ai_readyティアに分類されたのは11件でした。
llms.txtは広く見られますが、その多くはプラットフォームによる自動生成です。 最も多い品質バケットはplatform_defaultで、629ドメインでした。
手動で構造化されたllms.txtは少数です。 このバケットに入るのは31ドメインでした。
ホームページでProduct schemaが検出された割合は0.9%でした。
商品ページのProduct schemaは、取得を試みた商品ページの39.2%で検出されました。
AIショッピングへの対応状況は、クローラーのアクセス可否だけでは評価できません。 価格、オファー、レビュー、在庫、Product schemaなど、商品単位の情報も併せて見る必要があります。

1. AI検索対応がSEOの基本と違う理由

従来のSEOでは、ページがクロールされ、インデックスされ、検索結果でどのように表示されるかを見ます。AI検索への対応を考える場合は、それに加えて、ブランド、商品、オファー、価格、レビュー、在庫、ポリシー、エンティティ間の関係を、システムが参照しやすい形で提示できているかを見ます。

この違いはDTCサイトの運用に関係します。ECページには、人には読み取れても、機械処理では取得しにくい情報が含まれることがあるためです。購入者は商品ページから、商品名、価格、サイズ、定期購入の選択肢、割引、レビュー、在庫状況、返品ポリシーを読み取れます。一方、クローラーやAIエージェントがそれらを扱うには、事実が一貫した形式で表現されていることが重要です。

メタデータ、Open Graph、canonicalタグは、ページの文脈や参照先を示すうえで役立ちます。llms.txtも、クローラーが重要なコンテンツを見つける補助になる可能性があります。ただし、商品比較や回答生成に使える情報を整えるには、商品レベルの構造も必要です。たんぱく質パウダー、スキンケア、キャンドル、ドレス、コーヒーの定期購入などを比較する場合、商品名、価格、在庫、レビュー、条件といった構造化された事実が判断材料になります。これらが不足すると、サイトを発見できても、商品情報を正確に参照しにくくなります。

このレポートでは、対応状況を4つの層に分けています。

AIファイル層: llms.txtが存在するか、また欠如、ソフト404、プラットフォーム標準、手動・軽量、手動・構造化のどれに当たるか。
一般的な構造化データ層: JSON-LD、Organization、WebSite、BreadcrumbList、Product schema。
商品ページ層: Product schema、オファーまたは価格シグナル、レビューまたは評価シグナル、在庫シグナル。
メタデータ層: canonical、meta description、Open Graph画像、Twitterカード、hreflangなど、機械可読な文脈。

この階層モデルを使うことで、llms.txtの有無だけに依存した評価を避けられます。llms.txtがあっても商品情報が不足している場合と、llms.txtがなくても商品ページのschemaが充実している場合を分けて捉えることができます。

構造化された商品データを実際に確認する

2. llms.txtの実態：プラットフォーム生成が中心

llms.txtの監査では、次の5つの品質バケットが確認できました。

品質バケット	ドメイン数	解釈
プラットフォーム標準	629	通常は薄いが有効な、標準的なプラットフォーム生成ファイル
欠如	388	利用可能なファイルが見つからない
ソフト404	133	誤解を招く、または実質的に役に立たない応答
手動・軽量	57	人手で作成された、またはカスタムのファイルだが、構造は限定的
手動・構造化	31	見出し、リンク、商品またはポリシー用語を含む、より充実した手動ファイル

ここで重要なのは、llms.txtが存在することと、個別に設計されたAI検索施策とを分けて評価することです。プラットフォーム標準のファイルは広く見られますが、多くの場合は重要ページへの基本的な導線として機能するものであり、商品情報の構造まで保証するものではありません。

プラットフォーム標準にも実務上の役割があります。クローラーが重要なパスを見つける補助になり、プラットフォーム側の実装によって多数のストアへ機械可読ファイルを展開できることを示しています。ただし、ブランドごとの商品構成やポリシーに合わせた情報設計は、別途検討する必要があります。

手動・構造化バケットは31ドメインでした。監査対象には、Dermalogica、Ad Hoc Atelier、DKNY、そしてMagic Mind、Le Petit Ballon、Maine Lobster Now、Yo Mama's Foods、Three Ships Beautyのようなai_ready事例に見られる手動・構造化ファイルが含まれます。これらのファイルでは、デフォルトファイルと比べて、リンク、見出し、商品用語、ポリシー用語、意図的な構造が多く見られました。

ソフト404バケットも分けて扱う必要があります。ソフト404とは、リクエストに応答は返るものの、実質的には利用可能なllms.txtではない状態です。そのため、監査では存在の有無だけでなく、返された内容の品質も評価しています。

3. 主なギャップは商品レベルの構造にある

データ上で最も大きな差が見られた項目は、Product schemaです。

ホームページのProduct schemaは、対象ドメインの0.9%で検出されました。商品ページのProduct schemaは、取得を試みた対象のうち39.2%でした。商品ページの価格シグナルは48.1%、レビューや評価のシグナルは**43.5%**です。

これらの数値は、ECストアを運営していても、基本的な商品情報が一貫して機械可読になっているとは限らないことを示しています。

商品ページにProduct schema、オファー、価格、在庫、レビューのシグナル、ポリシーへのリンクが明示されていれば、機械が参照できる事実を増やせます。一方、それらがJavaScript、統一されていないテンプレート、画像、動的ウィジェットに分散している場合は、取得や解釈が難しくなる可能性があります。

この対応ギャップは、検索結果での露出だけでなく、商品情報の表現にも関係します。AIシステムが商品カテゴリを要約し、選択肢を比較し、対象者別の候補や買い物の提案を示す場面では、整理された商品情報のほうが参照されやすくなります。

ai_readyグループのスコアは次のとおりです。

Mokobaraは、調査出力内で最高の83点でした。
Magic Mind、Le Petit Ballon、Maine Lobster Nowはいずれも81点。
Yo Mama's Foodsは80点。
La Maison Convertible、Unbloat、Vinocheepo、NuRange Coffeeは79点。
Three Ships Beautyは77点。
Manukoraは75点でした。

これらの例は複数のカテゴリにまたがっています。商品比較や説明の対象となる食品、ウェルネス、家具、アパレル、専門商材などでも、機械可読な商品情報は評価対象になります。

4. AI対応ティア：公開シグナルで見た分布

ティア分布は次のとおりです。

ティア	ドメイン数	サンプルに占める割合
未対応	435	35.1%
部分的に対応	425	34.3%
基本的な発見可能性	367	29.6%
AI対応	11	0.9%

各名称は、この評価モデルで観測した公開シグナルを整理するための区分です。Not readyはブランドや事業自体を評価するものではなく、本モデルで用いた公開シグナルからAI検索への対応を十分に観測できなかった状態を指します。Partially readyは一部の要素がある一方で重要な層が欠けている状態、Basic discoverabilityは発見可能性のシグナルがある一方で商品レベルの完全性が不足している状態です。AI readyは、ファイル品質、構造化データ、商品情報、メタデータの組み合わせが相対的に充実している状態を指します。

AI readyに分類されたのは11ドメインでした。一方、サンプルの大部分は、未対応、部分的に対応、基本的な発見可能性の3層に分布しています。これは、何らかの公開シグナルを持つブランドがある一方、4つの評価層がそろったブランドは少数であることを示します。

改善の優先順位は、自社に不足している層から決めるのが実務的です。llms.txtの内容、schemaの有効性、商品情報の公開方法、メタデータ、商品ページの解析しやすさを順に点検し、事業上重要な商品やテンプレートから対応範囲を決めます。

5. カテゴリ別傾向：美容・アパレルが相対的に高い

カテゴリ分類は厳密なものではなく、方向性を把握するための区分です。その前提で見ると、カテゴリごとの傾向に違いがあります。

カテゴリ	サンプル数	平均AI対応スコア	手動または構造化llms	商品ページschema	商品ページschema率
美容・スキンケア	98	46.2	3	56	57.1%
アパレル・フットウェア	149	45.7	6	79	53.0%
ジュエリー・アクセサリー	34	44.5	0	20	58.8%
ペット	15	43.5	0	8	53.3%
ベビー・キッズ	27	42.6	1	15	55.6%
食品・飲料	118	42.5	5	58	49.2%
ホーム・家具	48	42.3	0	23	47.9%
ヘルス・ウェルネス	58	40.7	6	27	46.6%
アウトドア・スポーツ	49	39.8	1	23	46.9%

美容・スキンケアは平均AI対応スコアが46.2で最も高く、アパレル・フットウェアが45.7で続きます。これらのカテゴリでは、商品カタログ、レビュー、バリエーション、画像、説明コンテンツを扱うECテンプレートが多く、構造化できる商品情報の項目も比較的多いと考えられます。

ジュエリー・アクセサリーは商品ページschema率が**58.8%**である一方、カテゴリ表では手動または構造化されたllms.txtの検出がゼロでした。商品schemaとAIファイル品質では結果が異なるため、カテゴリの対応状況も層ごとに評価する必要があります。

食品・飲料には、Maine Lobster Now、Yo Mama's Foods、NuRange Coffee、Manukoraなど、比較的高いスコアの事例が含まれます。食品・飲料では、原材料、栄養、1回分の量、定期購入、原産地、配送、保存方法、レビュー、在庫など、商品判断に関わる事実が多くあります。これらを一貫した形式で提示することは、人と機械の双方が情報を参照しやすくするうえで役立ちます。

ヘルス・ウェルネスは、表中で手動または構造化llms率が10.3%と主要カテゴリ中で最も高い一方、平均スコアは40.7でした。一部ブランドではAI可読ファイルの導入が見られるものの、商品ページ構造を含む他の層には改善余地があります。信頼性や説明責任が重要な領域では、主張の根拠、商品情報、ポリシーをどの層から整備するかを検討する必要があります。

このサンプルでは、平均スコアが50/100を上回るカテゴリはありません。カテゴリ別の数値は優劣を断定するものではなく、各カテゴリで不足している情報層を特定する材料として利用できます。

6. AI対応スコアが高いブランドに見られる要素

ai_readyグループは小規模ですが、この評価モデルでスコアが高くなる要素を検討する材料になります。

Mokobaraは83点で、調査出力内の最高点でした。単一のシグナルではなく、複数の評価要素がそろっている事例です。

Magic Mind、Le Petit Ballon、Maine Lobster Nowはいずれも81点で、手動・構造化llmsバケットに入っています。プラットフォーム標準とは異なり、ファイル単位で見出しやリンクなどを構成している事例として参照できます。

Yo Mama's Foodsは80点で、こちらも手動・構造化llmsです。食品ブランドでは、原材料、味、用途、レシピ、食事制限との相性、比較など、商品説明に必要な項目が多いため、機械可読な形で整理できる情報も多くなります。

Three Ships Beautyは77点で、手動・構造化llmsでした。美容商品では、肌質、成分、ルーティン、テクスチャ、レビュー、代替品などの情報を扱うため、商品データの構造を点検する意義があります。

Manukoraは75点でした。はちみつやウェルネス寄りの食品では、原産地、品質、効能、認証、使い方などの説明が必要になることが多く、商品情報とポリシーの提示方法が評価に関係します。

ここで共通しているのは、AI対応を単一の機能ではなく、複数の情報層の組み合わせとして捉えている点です。

役立つllms.txtファイル
きれいなメタデータ
構造化されたOrganizationおよびWebSiteデータ
商品ページschema
価格とオファーのシグナル
レビューまたは評価シグナル
在庫シグナル
ポリシーとサポートの明確さ

各要素は個別にも評価対象になりますが、本モデルでは組み合わせによって総合的な対応状況を算出します。

7. llms.txtだけでは不十分な理由

llms.txtは、AI対応を示す分かりやすいシグナルとして扱われることがあります。ただし、本調査では、それだけで対応状況の全体を評価できないことが分かりました。

プラットフォーム標準のllms.txtは、クローラーを重要なページへ導き、AI可読な入口を示す補助になる可能性があります。一方、誘導先の商品ページで商品情報が明確に提示されていなければ、商品単位の理解に必要な情報は不足したままです。

AI検索への対応を評価する際は、サイトの発見可能性に加えて、次の項目を見ます。

商品を識別できること
ブランドを識別できること
価格を解析できること
在庫を解析できること
レビューや評価を識別できること
商品コンテンツとマーケティングコンテンツを区別できること
ポリシーを参照できること
バリエーションを比較できること
正しいcanonicalページを参照できること

llms.txtはナビゲーションと優先順位づけを補助し、構造化された商品データは商品情報の参照を助けます。本レポートでは、その両方を別の層として評価しています。

8. 運用担当者向けプレイブック：AI検索対応の改善手順

DTCおよびECチームでは、次の順序で公開シグナルと商品情報を点検できます。

ステップ1: AIファイル層を確認する。 ドメインにllms.txtがあるか、実体のあるファイルか、ソフト404かを判定します。そのうえで、プラットフォーム標準、手動・軽量、手動・構造化のどれに該当するか、必要なページを参照しているかを見ます。

ステップ2: メタデータを監査する。 canonicalタグ、meta description、Open Graph画像、Twitterカード、必要に応じてhreflang、モバイルviewportを点検します。これらは、機械がページの文脈や参照先を扱う際の基本情報になります。

ステップ3: JSON-LDを検証する。 Organization、WebSite、BreadcrumbList、Product schemaを対象に、有効性と出力内容を検証します。本調査ではProduct schemaの不足が大きかったため、ECサイトでは優先的な点検項目になります。

ステップ4: ホームページだけでなく商品ページを監査する。 商品名、説明、画像、価格、オファー、在庫、SKU、レビュー、評価、バリエーション、返品ポリシーなど、商品単位の情報を点検します。

ステップ5: 商品情報を安定させる。 重要な商品情報を画像だけに含めたり、正しくレンダリングされないタブや、クローラーが解析しにくいJavaScriptウィジェットだけに依存したりしないようにします。

ステップ6: ポリシーの明確さを高める。 配送、返品、定期購入の条件、保証、認証、安全性に関する主張を、利用者と機械の双方が参照しやすい場所に整理します。

ステップ7: テンプレート変更後に再テストする。 schemaは、リデザイン、テーマ変更、アプリ変更、ヘッドレス移行によって出力が変わることがあります。構造化データの検証をリリース時のQAに含めます。

ステップ8: 責任の所在を明確にする。 AI対応はSEOだけで完結しません。EC、商品、コンテンツ、エンジニアリング、法務、カスタマーサポートの担当範囲と更新手順を決めます。

9. SEO・コンテンツチーム向けの引用候補

本調査から引用できる主なデータポイントは次のとおりです。外部資料で使用する場合は、サンプル範囲、取得日、評価方法も併記すると解釈の範囲が明確になります。

「1,238のDTC対象ドメインのうち、AI対応ティアに届いたのは11件だけでした。」 サンプル全体のティア分布を示す数値です。

「llms.txtは一般的ですが、その多くはプラットフォームの自動生成です。」 platform_defaultバケットには629ドメインがあり、手動・構造化ファイルは31件でした。

「ホームページのProduct schemaは、対象ドメインの0.9%で検出されました。」 ホームページ上の構造化データの状況を示します。

「商品ページのProduct schemaは、取得を試みた商品ページの39.2%にあります。」 ホームページと商品ページでは検出率が異なることを示す補足データです。

「美容とアパレルはカテゴリ表で相対的に高い平均スコアですが、いずれも50/100未満です。」 カテゴリ別の差を示す際に使えます。

「AI対応は階層的です。」 llms.txt、構造化データ、商品情報、メタデータを分けて評価する本調査の考え方を示しています。

ただし、このデータは本サンプルにおける公開サイトのシグナルを反映したものであり、業界全体の普及率や内部の検索パフォーマンスを示すものではありません。

10. AIショッピングがDTCチームにもたらす変化

従来のECにおける商品発見は、検索結果、順位、広告、クリックを中心に設計されてきました。購入者は検索結果を比較し、商品ページを開き、レビューを読んで判断します。AIショッピングや回答エンジンでは、この比較プロセスの一部をシステムが担う可能性があります。購入者は、「平日のパスタに合う低糖質ソースはどれか」「レビューの良い200ドル以下の機内持ち込み用バックパックはどれか」「香料なしで敏感肌に配慮した洗顔料はどれか」と尋ねるかもしれません。システムが候補を要約する場合、購入者が各ブランドの商品ページを開く前に比較情報へ触れることになります。

そのため、商品ページには、人にとって分かりやすい訴求と、機械が比較しやすい事実の両方が必要になります。ブランドトーン、画像、商品名に加えて、商品の種類、対象者、価格、在庫、バリエーション、レビュー、主張の根拠、原材料や素材、適用されるポリシーを明確に示すことが重要です。

llms.txtは、クローラーが参照先を見つける補助になる可能性があります。Product schemaと整理された商品ページ情報は、その参照先にある商品情報を扱いやすくします。このため、本調査では一般的なAIファイルと商品レベルの構造を別の層として評価しています。

DTCブランドが考慮すべき点は、候補から外れる可能性だけではありません。商品情報が不明瞭な場合、AIの回答で特徴が正確に要約されない、重要な差別化要素やポリシーが省略される、競合との比較に必要な事実が不足するといった可能性があります。機械可読な商品情報の整備は、ブランド情報の正確性を支える施策にもなります。

検討項目が多いカテゴリでは、情報構造の重要性が高まります。美容では肌質、成分、ルーティン、敏感性、効果、食品では栄養、アレルゲン、原産地、味、レシピ、食事制限との相性が判断材料になります。アパレルではフィット感、サイズ、素材、返品、コーディネート、ウェルネスではエビデンス、使い方、安全性、信頼性、ホーム商品では寸法、素材、配送、組み立て、耐久性が問われます。これらはマーケティング上の説明項目であると同時に、機械可読なコンテンツとして整理する対象でもあります。

本調査の平均対応スコアは36.4/100で、ai_readyティアに分類されたのは11ドメインでした。改善はサイト全体の再構築だけに限られません。既存のテンプレート、schema、ポリシー、商品情報を点検し、優先度の高いページから整備できます。

11. 部門別のAI対応プラン

AI対応には複数部門が関わるため、情報の作成、実装、検証、更新を分担する必要があります。

SEOの主な役割は、発見可能性とschemaの検証です。 canonicalタグ、メタデータ、構造化データ、Product schema、パンくず、hreflang、クロール可能性を監査します。テーマ変更やアプリ更新の後にもProduct schemaが正しく出力されているかを検証します。

ECの主な役割は、商品ページ上の事実を整えることです。 商品名、価格、バリエーション、在庫、セット販売、定期購入、レビュー、配送条件、返品情報を一貫した形で提示します。ウィジェット、タブ、画像、スクリプトに情報が分散している場合は、利用者と機械の双方が参照できる場所を見直します。

コンテンツの主な役割は、説明に必要な情報を補うことです。 購入ガイド、比較表、成分解説、用途別ページ、サイズガイド、FAQセクションは、購入者の質問に答える情報源になります。商品ページだけでは説明しきれない判断材料を、検索・参照しやすい構成で用意します。

エンジニアリングの主な役割は、実装品質を維持することです。 schemaを有効かつ安定したテンプレートで出力し、重要な商品情報をクライアントサイドレンダリングだけに依存させないようにします。商品ページテンプレートはリリース後にもテストします。

法務・コンプライアンスの主な役割は、主張の正確性と根拠を管理することです。 健康、サステナビリティ、安全性、原材料、性能に関する表現について、根拠、適用範囲、注意事項を整理します。曖昧な主張が外部システムに参照される可能性も考慮します。

カスタマーサポートの主な役割は、繰り返し寄せられる質問を商品情報へ反映することです。 配送日数、フィット感、原材料、互換性、返品、定期購入の解約、手入れ方法、商品比較など、問い合わせの多い項目を商品ページやFAQの改善に利用します。

経営層の主な役割は、部門横断の優先順位を決めることです。 構造化された商品情報は、SEO、AI検索、商品フィード、ショッピング広告、サイト内検索、サポート、コンバージョンなど複数の業務に関係します。各部門の目的と更新責任を整理し、投資対象を決めます。

12. AI対応商品ページの基本項目

DTCの商品ページを点検する際は、商品やカテゴリに応じて、次の項目を基本チェックリストとして利用できます。

商品名
ブランド名
canonical URL
商品説明
商品画像
価格
通貨
在庫状況
バリエーション情報
該当する場合の商品SKUまたは識別子
利用可能なレビューまたは評価シグナル
オファー詳細
配送・返品ポリシーへのリンク
カテゴリに応じた素材、原材料、仕様情報
よくある購入質問に対するFAQまたはサポート情報

該当する商品ページには有効なProduct schemaを含め、重要な情報を画像や、クローラーが解析しにくいスクリプトの中だけに置かないようにします。デザイン上の訴求と、参照しやすい構造化された事実は両立できます。

初期施策としては、代表的な商品ページを10件選び、schemaと表示内容を検証し、重要な商品情報がHTMLと構造化データの両方で参照できるかを見直す方法があります。その結果をもとに、対象テンプレートや商品範囲を広げます。

方法論

この調査は、2026年5月11日に取得したDTC dual-reportデータセットを使っています。master.csv、detection.csv、seo_signals.csv、生のllms.txtファイル、そして取得できた場合は生の商品ページHTMLを用いて、1,238ドメインを採点しました。

スコアモデルは4つの層を分けています。

AIファイル層: llms.txtの存在と品質。
一般的な構造化データ層: JSON-LD、Organization、WebSite、BreadcrumbList、Product、および関連する構造化シグナル。
商品ページ層: Product schema、オファーまたは価格シグナル、レビューまたは評価シグナル、在庫シグナル。
メタデータ層: canonical、meta description、Open Graph画像、Twitterカード、hreflang、および関連ページコンテキスト。

このモデルは0〜100のAI対応スコアを算出し、ドメインを未対応、部分的に対応、基本的な発見可能性、ai_readyの4ティアのいずれかに分類します。

留意点

AI対応はAIトラフィックではありません。 このスコアは、AI検索システムやショッピングエージェントからの実際の流入を測っているわけではありません。
公開シグナルは下限値です。 一部の構造化データは動的に読み込まれたり、クロールで取得できない形で表示されたりする可能性があります。
llms.txtの品質判定はヒューリスティックです。 手動・構造化ファイルは、見出し、リンク、商品用語、ポリシー用語などの観測可能な特徴から識別しています。
商品ページの検出は、試行した商品ページ取得に依存します。 商品ページschemaの割合は、商品ページの取得を試み、かつ利用可能だったケースに適用されます。
サンプルはDTC全体の完全な国勢調査ではありません。 ECツールのエコシステムや公開DTCリストで可視性の高いブランドに偏っています。
カテゴリラベルは方向性を示すものです。 大まかな比較には有用ですが、厳密な分類体系ではありません。
AI検索の基準はまだ進化しています。 このスコアモデルは、恒久的な定義ではなく、2026年時点の実用的なベンチマークとして設計しています。

再現性メモ

納品フォルダには次のファイルが含まれています。

analyze_ai_search_readiness.py — llms.txt、構造化データ、商品ページシグナル、メタデータシグナルを横断してDTCドメインを評価するためのスコアリングスクリプト。
ai_search_readiness_scores.csv — ドメイン単位のAI対応スコア、ティア、各種コンポーネントシグナル。
llms_quality_audit.csv — プラットフォーム標準、ソフト404、欠如、手動・軽量、手動・構造化の分類を含む、ドメイン単位のllms.txt品質監査。
category_ai_readiness.csv — カテゴリ単位のAI対応比較。
top_ai_ready_brands.csv — 編集レビューと事例選定のための高得点ドメイン。
lowest_ai_ready_brands.csv — ギャップ分析と編集レビューのための低得点ドメイン。
summary.json — サンプルサイズ、ティア数、平均スコア、中央値、商品ページシグナル率を含む、このレポートで引用した主要集計値。

すべてのスクリプトとデータセットをダウンロード

方法論の修正、データセットの問題、追加分析のご要望は support@thunderbit.com までお寄せください。ThunderbitはAI搭載のウェブスクレイパーを開発しており、この分野に事業上の関心があります。そのうえで、本レポートの集計と評価は、記載したデータセットと方法論に基づいています。対象は、2026年5月11日に取得した公開サイトシグナルに基づく1,238件のDTCドメインです。数値と結論は、公開したスクリプトとデータセットから検証できる形で提示しています。— Thunderbitリサーチチーム、2026年5月。

AI検索対応のためにThunderbitを試す Get Started Free

AIでデータを抽出

Google Sheets、Airtable、Notionへ簡単にデータを移行できます

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week

レポート | 2026年のDTCにおけるAI検索対応ギャップ