AI検索の質問は長くなった、と言われている ── 商品・サービスページが答えられるか確認する13項目（2026年9月時点）

目次

1. 01 何が起きたか／いま最新版は何か
   1. 「質問が24語になった」という数字が、業界メディアに載った
   2. この数字には、公開された根拠データが示されていない
   3. 一方でGoogle公式は「追加の要件はない」と言っている
2. 02 なぜ・背景
   1. Google公式が挙げる、AI検索に表示されるための基礎
   2. 「対応不要」と「質問が長くなった」は、矛盾しない
   3. 語数が増えるということは、条件の数が増えるということ
   4. 自律的な購入は、まだ実現していない
   5. EC限定の話ではない
3. 03 この記事に出てくる用語
4. 04 型別に見る、確認すべき範囲と手順
   1. 適用範囲 ── 何が対象で、何が対象外か
   2. BtoBサービスページでの設計例（架空の例）
   3. Product構造化データとFAQPage構造化データの使い分け
   4. 本文と構造化データ、両方に条件があるかを図で確認する
   5. 本文と構造化データ、どちらを先に整えるか
   6. この記事で確認できていないこと
   7. 確認の手順 ── 探す・控える・残す
5. 05 明日確認できるチェックリスト
   1. チェックリストの狙い
   2. 項目の内訳と、かかる時間の目安
   3. 何から手を付けるか
6. 06 代替・他の選択肢の比較
   1. 確認する手段は1つではない
   2. 4つの手段の使い分け
7. 07 当サイトの状況
   1. 当サイトはEC構造化データを持たない。だがFAQPageは持っている
   2. 当サイトのFAQは、条件を1つしか持たない質問が中心だった
8. 08 このテーマの、これまで
   1. 公式の資料に当たり直す、という姿勢
   2. 構造化データの実装と表示は、別の話だという記録
   3. 「同じに見えて、実は別だった」という形は、他でも見た
9. 09 この記事のまとめ

01 何が起きたか／いま最新版は何か

「質問が24語になった」という数字が、業界メディアに載った

2026年9月23日、マーケティング業界メディアmartech.orgに掲載された記事「AI search is changing ecommerce forever」で、ECプラットフォームOpiversalの共同創業者兼CEOであるLucas Tieleman氏の発言が紹介された。原文は次のとおりだ。

"Traditional Google searches averaged about six words, whereas the average LLM-driven query has expanded to roughly 24 words."

（訳: 従来のGoogle検索は平均約6語だったのに対し、LLM経由の質問は平均でおよそ24語にまで長くなっている。）

単語数がおよそ4倍になったという主張は、AI検索に対応する側にとって具体的で分かりやすい。だからこそ、この数字だけが独り歩きしやすい。

この数字には、公開された根拠データが示されていない

同じ記事をもう一度読み直しても、「6語」「24語」という数字がどの調査・どの期間・何件の質問ログから算出されたものかは書かれていない。発言の主体はOpiversalという1企業のCEOであり、Googleや第三者調査機関が公表したデータではない。数字そのものを否定する材料もないが、肯定する材料もない、というのが正確な状態だ。本記事ではこの数字を確定した事実としては扱わず、「Opiversal社のCEOはこう述べている（根拠データは示されていない）」という形でのみ引用する。

一方でGoogle公式は「追加の要件はない」と言っている

質問が長くなったという主張と対をなすように、Google検索セントラルの公式ドキュメント「AI features and your website」には、次の一文がある。

"There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary."

（訳: AI OverviewsやAI Modeに表示されるための追加の要件はなく、特別な最適化も必要ない。）

このページの最終更新は2025年12月10日（UTC）。「質問が長くなった」という業界側の観測と、「特別な対応は不要」というGoogle公式の説明は、一見すると矛盾しているように見える。02章では、この2つがどう両立するのかを整理する。

02 なぜ・背景

Google公式が挙げる、AI検索に表示されるための基礎

「追加の要件はない」という一文の直後、同じページはこう続けている。AI OverviewsやAI Modeは、複雑なトピックに対して複数の関連検索をサブトピックにわたって行う「Query Fan-Out」という仕組みを使い、その狙いを次のように説明している。

"display a wider and more diverse set of helpful links associated with the response than with a classic web search"

（訳: 従来のウェブ検索よりも幅広く多様な、参考になるリンクの集合を回答とともに表示する。）

この仕組みのもとで表示対象になるための条件は、目新しいものではない。Googleが挙げているのは、テキストとして読み取れるコンテンツを用意すること、robots.txtでクロールを許可すること、内部リンクの構造を整えること、ページの表示品質を確保することといった、従来のSEOの基礎と同じ項目だ。「AI専用の新しい構造化データ」は求められていない。

「対応不要」と「質問が長くなった」は、矛盾しない

ここで01章の「24語」の話に戻る。Googleが求めているのは新しいマークアップの追加ではなく、既存の基礎を満たすことだ。一方でTieleman氏の指摘は、ユーザーが入力する質問そのものの中身についての観察であり、サイト側が用意すべき対応方法についての指摘ではない。質問が長くなったとしても、サイト側が新しく実装すべき技術が増えているわけではないという理解で、2つの情報は両立する。問われているのは「何を実装するか」ではなく、「もともと持っている情報が、長い質問に答えられる形で揃っているか」という点になる。

語数が増えるということは、条件の数が増えるということ

「6語」から「24語」への変化を、単語の個数としてではなく、質問に含まれる条件の数として読み直してみる。「ランニングシューズ」という短い質問は、条件を実質1つしか持たない。これに対して、条件を並べた質問には「サイズ」「用途」「価格帯」「配送日数」「在庫の有無」といった複数の条件が同時に含まれることが多くなる。ページ側が答えるべき情報量は、単語数の増加分ではなく、条件の掛け合わせの数で増えていく。martech.orgの記事が推奨として挙げているのも、この掛け合わせに応えるための方法だ。

"To remain discoverable, retailers must prioritize feeding highly structured data, conversational attributes, and detailed FAQs directly into AI and advertising platforms."

（訳: 発見され続けるためには、小売事業者は高度に構造化されたデータ、会話的な属性、詳細なFAQを、AIおよび広告プラットフォームに直接提供することを優先しなければならない。）

自律的な購入は、まだ実現していない

同じ記事は、AIが買い物を代行する段階についても触れている。

"While autonomous AI agents aren't doing the actual buying for consumers just yet, they are heavily driving research traffic."

（訳: 自律的なAIエージェントが消費者に代わって実際に購入している段階にはまだ達していないが、下調べのトラフィックは大きく押し上げている。）

この一文は、煽った書き方を避けるために重要だ。「AIが自動で買ってくれる時代」はまだ来ていない。今起きているのは、人がAIに条件を伝え、AIが候補を絞り込む段階であり、その絞り込みの材料になるのが、ページに書かれた情報と構造化データになる。

EC限定の話ではない

martech.orgの記事タイトルは「ecommerce」だが、条件を並べた長い質問に答える必要があるのは、商品ページだけではない。サービスページも同じ構造を持つ。「対応地域・料金プラン・導入までの日数・対応言語」を一度に聞かれるBtoBサービスや、「対応可能な内容・予約の空き・料金の目安」を一度に聞かれる相談系のサービスも、同じ確認が必要になる。本記事のチェックリストは、EC・非ECの両方に使える形で組んである。

03 この記事に出てくる用語

本文で使う5つの用語を、先に整理しておく。

04 型別に見る、確認すべき範囲と手順

適用範囲 ── 何が対象で、何が対象外か

Product構造化データやMerchant Center商品データ仕様は、商品を扱うECサイトに限定される仕組みだ。一方で、条件を並べた長い質問に答える設計そのものは、EC限定ではない。02章で触れたとおり、料金プラン・対応地域・所要日数といった条件を複数持つサービスページも対象に含めて考える。逆に対象外になるのは、条件を比較する余地がないページ、たとえば会社概要や単体の採用ページのような、選択肢を持たないコンテンツだ。

対象を絞り込むときに迷いやすいのが、1商品1ページ型のサイトだ。取り扱う商品やプランが常に1種類しかない場合、比較する条件は実質存在しないため、Product構造化データを実装する動機は薄くなる。一方で、その1つの商品に「サイズ違い」「色違い」「容量違い」のようなバリエーションが1つでもあれば、それは条件を比較できるページになる。バリエーションの有無が、対象に含めるかどうかの目安になる。

BtoBサービスページでの設計例（架空の例）

02章で触れたとおり、「対応地域・料金プラン・導入までの日数・対応言語」を一度に聞かれるBtoBサービスも、条件を並べた長い質問への対応が必要になる対象に含まれる。ここでは架空の企業を例に、ページの見出しをどう並べると答えやすくなるかを示す。以下の企業名・条件・数値はすべて説明のための例であり、実在の企業ではない。

たとえば架空の企業「サンプル設備工事社」の施工サービスページが、条件をばらばらに本文へ埋め込んでいる場合、見出しは「サービス概要」「会社案内」「お問い合わせ」のように、条件そのものを指していないことが多い。聞かれやすい条件をそのまま見出しにする形へ並べ替えると、次のようになる。

見出しを条件そのものにすると、本文を読むAIにとっても、ページをざっと見る人にとっても、答えを探す場所が同じになる。料金プランは、見出しの下に文章で書くよりも、条件を並べた表のほうが読み取りやすい。架空の例を表にすると、次のようになる。

FAQの書き方も、条件を1つずつ分けて質問にするより、実際に聞かれる形のまま組み合わせて質問にしたほうが、そのまま答えになる。架空の例を示す。

このFAQは「地域」「日数」「料金」という3つの条件を、1つの質問と1つの回答の中で同時に答えている。条件を1つずつ別のFAQに分けてしまうと、複数の条件をまとめて聞く質問には答えられなくなる。

Product構造化データとFAQPage構造化データの使い分け

03章で定義したProduct構造化データと、07章で触れるFAQPage構造化データは、同じ「構造化データ」という括りで語られることがあるが、使う場面も、Googleが示している条件も別だ。どちらか一方だけを実装すれば足りるわけではなく、ページの性質によって使い分けるものになる。

FAQPageは検索結果の見た目には反映されなくなったが、07章で確認するとおり、構造化データ自体は無効化しなければならないわけではない。質問と回答をまとめた形は、02章で扱った「会話的な情報」としてAIに読み取られる材料になりうる。表示が終了したことと、書く意味が無くなったことは、別の話として区別しておきたい。

本文と構造化データ、両方に条件があるかを図で確認する

05章のチェックリストが最終的に確認したいのは、条件を答える情報が「本文の中の文章」と「構造化データ」の両方に存在しているかどうかだ。片方だけでは足りない。本文にしか書かれていなければAIは読み取れても要点として扱いにくく、構造化データにしか書かれていなければ、人が読むページとしては説明不足になる。4つの組み合わせのうち、目指すべきなのは両方に条件が書かれている状態だけだ。

本文と構造化データ、どちらを先に整えるか

05章のチェックリストは「探す→控える→残す」の順で組んである。本文の中に条件が書かれているかを先に確認し、そのあとで構造化データに同じ条件が書かれているかを確認する構成だ。この順番には根拠がある。Google Search Centralの構造化データに関する一般的なガイドラインには、次の一文がある。

"Your structured data must be a true representation of the page content."

（訳: 構造化データは、ページのコンテンツを正確に反映したものでなければならない。）

同じページには、これに続けてもう一つの条件も示されている。

"Don't mark up content that is not visible to readers of the page."

（訳: ページの読者に見えないコンテンツに、マークアップを付けてはいけない。）

この2つの条件をつなげると、構造化データは本文の写しであって、本文の代わりにはならないという理解になる。構造化データだけを先に整えて、本文にはその条件が書かれていない状態を作ると、Googleが示す「ページのコンテンツを正確に反映する」という条件から外れる。だから05章のチェックリストは、構造化データの有無を数える前に、本文の中に条件があるかを数える手順を先に置いている。

この記事で確認できていないこと

01章・02章に書いたとおり、martech.orgの「24語」という数字には、公開された根拠データが示されていない。また、ChatGPTのショッピング機能についてOpenAIの公式ヘルプページを開こうとしたが、アクセスできなかった（403 Forbidden）。そのため、ChatGPT側が商品データをどう見つけているかについては、今回は確認できていない。自律的な購入（AIエージェントが実際に決済まで行う動き）が、いつ・どの程度普及するかについても、公式の見通しは示されていなかった。分からないことは、分からないと書く。

確認の手順 ── 探す・控える・残す

05章のチェックリストは、次の3つの動きで組み立てている。まず自分のページに、条件を並べた質問（サイズ・対応地域・料金プラン・配送日数など）に答えられる情報が本文の中にあるかを探す。次に、その情報が構造化データとしても書かれているかを控える。最後に、抜けている項目を一覧にして残す。この3つは、どれも5分以内で終わる範囲に収まる作業だ。

05 明日確認できるチェックリスト

チェックリストの狙い

以下は、01章から04章の内容を、実際に手を動かして確認するための13項目だ。前半は本文と構造化データの対応状況の確認、後半はその結果をどう記録に残すかという内容になっている。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。

• 自社の商品ページまたはサービスページを1つ開き、「サイズ」「対応地域」「料金プラン」「配送日数」「在庫」のうち何種類の条件が本文中に書かれているか数える
• 同じページのソースをCtrl+Fで開き、「Product」がJSON-LD内に出てくるか確認する
• Product構造化データがある場合、offers・aggregateRating・reviewのうちどれが含まれているかRich Results Testで確認する
• offersが含まれる場合、priceとavailabilityの両方が入力されているか確認する
• 商品説明文の中に、Q&A形式で書かれた文章が3件以上あるか数える
• その中の1件を選び、内容が実際の在庫状況と食い違っていないか確認する
• メイン画像を右クリックして、横幅と縦幅のピクセル数を確認する
• その画像が500×500ピクセル以上あるか確認する
• Merchant Centerに商品を登録している場合、直近の商品診断で承認された商品数と却下された商品数を控える
• サービスページの場合、料金・対応地域・所要日数のうち、本文中の文章として書かれている項目がいくつあるか数える
• 見つけた対応済みの条件と、未対応の条件を1枚のメモに書き出す
• 未対応の条件のうち、優先して追加する上位3件を選ぶ
• まとめたメモを、次回のページ見直しで開く場所に保存する

項目の内訳と、かかる時間の目安

13項目すべてに目を通した場合の時間の目安は合計31分程度だ。1番目と2番目だけであれば1分もかからない。

何から手を付けるか

自社に商品構造化データがあるかどうかも把握していない場合は、1番目と2番目から始める。すでに実装していることが分かっている場合は、3番目から6番目の確認を先に済ませ、対応状況を把握したうえで、11番目以降の記録に進むとよい。

06 代替・他の選択肢の比較

確認する手段は1つではない

構造化データや商品データを確認する方法は、1つのツールに限らない。目的が違えば、使う道具も変わる。「これから構造化データを作る」のか、「Googleの対応タイプとして正しく書けているか」を見たいのか、「会話的な情報（FAQ）を整理したい」のかによって、選ぶ手段は変わってくる。

4つの手段の使い分け

この表が示すのは、4つの手段はどれも代わりにはならないという点だ。コウゾウは「これから作る」ときの出発点であり、FAQメーカーは会話的な情報を整理する役割を持つ。Rich Results TestとSchema Markup Validatorは、書いた後の文法を確かめる手段として役割が異なる。05章のチェックリストの3番目から6番目は、この4つを組み合わせて使うよう組んである。

07 当サイトの状況

当サイトはEC構造化データを持たない。だがFAQPageは持っている

当サイトはEC向けのProduct構造化データを実装していない。2026年9月25日時点でトップページのJSON-LDを確認したところ、含まれていた型はArticle・BlogPosting・FAQPage・ItemList・Organization・Person・WebPage・WebSiteなどで、ProductやOffer、AggregateOfferは1件も見つからなかった。商品を販売するサイトではないため、この結果自体は当然といえる。一方でFAQPageは実装しており、質問と回答のペアは10件だった。

当サイトのFAQは、条件を1つしか持たない質問が中心だった

トップページのFAQPageに書かれている質問を確認すると、「SEOとGEO（AI検索最適化）の違いは何ですか」「llms.txtとは何ですか」「構造化データ（JSON-LD）とは何ですか」といった、1つのテーマについて説明を求める質問が中心だった。02章で書いた「条件を並べた長い質問」に相当する形、たとえば「対応地域・料金・対応期間を一度に聞く質問」は、当サイトのFAQには見当たらなかった。これは当サイトが情報提供サイトであり、価格プランや配送条件のような複数条件を持つ商品・サービスを扱っていないためだが、05章のチェックリストの5番目と6番目を当サイト自身に当てはめると、「条件を並べた質問」の観点ではまだ数えられる項目がないという結果になる。

08 このテーマの、これまで

公式の資料に当たり直す、という姿勢

以前、公開済みの記事の8割が検索エンジンから正しく認識されていない状態に気づき、一夜で公開状態へ切り替えた記録（1,238記事の8割が「土俵に上がっていない」ことに気づいた日）がある。あのときも今回も、業界メディアの主張をそのまま受け取るのではなく、Google公式のページを直接開いて確認して初めて実態が分かった点は同じだ。

構造化データの実装と表示は、別の話だという記録

当サイトのFAQPageは、実装した直後に一度壊れていたことがある。その時の修正と展開の記録はFAQPageスキーマが壊れていた — 確認したら気づいた3つのこと、当サイトの修正と展開の全記録にまとめてある。構造化データを追加した記録はAI Agentに引用される準備 — llms.txtの次にやること、当サイトの実践ロードマップにも残っており、「実装して終わり」ではなく、実際に表示や中身を確認する作業が必要だという点は、今回のテーマとも重なる。FAQとHow-toのリッチリザルト廃止は、同じ時期の話ではなかったで扱ったとおり、構造化データは実装しても表示形式が変わることがあり、07章で「まだ判断していない」と書いたのは、この経緯を踏まえたものだ。

「同じに見えて、実は別だった」という形は、他でも見た

アクセスログを日別に割り直したら、「AIクローラーが弾かれている」ように見えていたものの正体が、複数の名前を名乗る貸しサーバーだったと分かった記録（「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった）や、警告の96.7%が見なくていいもので、本物の警告は自分で叩くまで分からなかった記録（毎朝の「警告1,415件」を、初めて種類別に数えた）も、根は同じだ。ひとつの見出しや数字だけを見て判断すると、実際の中身とはずれた結論に着地する。今回の「24語」という数字も、見出しだけを見れば確定した事実のように見えたが、原文を直接確認するまでは分からなかった。