ロングクエリ対策｜AI検索で条件の多い問いに答えるために、何を整え、どう確かめるか

ロングクエリ対策は、条件の多い問いに答える情報を整え、それがAIの回答に届いているかを測ることです。 シリーズの親記事の定義を、実務の手順に落としたものです。「ロングクエリ」も「ロングクエリ対策」も実務での言い方で、公式の規格ではありません。

先に、やってはいけないことを置きます。想定される問いごと、ファンクエリごとにページを量産することです。 Googleは、検索しうる変形ごとのコンテンツ作成を、主として操作が目的ならスパムの方針に違反すると明記しています。

では何を整えるのか。問いに含まれる条件を、自社の情報の項目として持つことです。 業種、地域、価格帯、納期、対応範囲、互換性が本文に書かれ、商品であれば商品データにも入っていること。Googleは、生成AIの検索のために特別な schema.org のマークアップは要らないとし、構造化データは見えている本文と一致させるよう求めています。

そして、どう確かめるのか。基準の問いを一つ決め、そこに条件を一つずつ足し、各段を繰り返して割合で読みます。 段どうしは、割合の差とその区間で比べます。一回の結果は試行にすぎません。見える化の道具（Search Console、Bing Webmaster Tools、Merchant Center）は役に立ちますが、それぞれ見えないものがあります。

この記事で分かること

• 問いごと・ファンクエリごとのページ量産について、Googleのスパムの方針が何を書いているか
• 問いの条件を、自社の情報の項目に置き換える整理の仕方
• Merchant Center の商品データ仕様と会話向けの属性、OpenAI の商品フィード仕様の要点と違い
• 「特別な schema は要らない」「構造化データは見えている本文と一致させる」の原文と、その実務上の意味
• 基準の問いに条件を一つずつ足して測る手順、各段の繰り返しの回数と割合の読み方、記録の項目
• Search Console、Bing Webmaster Tools、Merchant Center で見えるものと見えないもの、記録の不具合

対象読者

AI検索への対応を担う実務担当者と、その上長。このシリーズの親記事や、クエリファンアウトを扱った記事を読み、「では、実際に何をするのか」と考えた方を想定しています。情報構造の一般原則や、AI上の認知の測定全般は別の記事に送り、本記事は条件の多い問いに絞ります。

最初に置く数字

同じ問いを10回実行し、各回のファンクエリを比べたところ、一致はおよそ27%でした（Surfer・ベンダーの観測・最終更新2026年9月17日）。

600名が12の問いを計2,961回実行した分析では、ChatGPT と Google の AI で同じ一覧が二度返る確率は100回に1回未満と報告されました（SparkToro・ベンダーの分析・2026年1月27日公表）。一回の結果で判断できない理由が、この二つの数字にあります（§7）。

1-1. シリーズの中での位置

親記事のロングクエリマーケティングとはは、問いの長さについての一次の数字と、その反証を並べ、「条件の数」という見方を分析として示しました。同じ記事の「自社は、どの粒度の問いで出ているか」の章は、条件を一つずつ足す考え方を示しています。クエリファンアウトを扱った記事は、条件の少ない問いと条件を重ねた問いを並べて測る手順を、「測定 — 自社は、どの形の問いで回答に出るか」の章で扱いました。

本記事は、その二つの測定の章を、手順として一段深く書きます。あわせて、測る前に何を整えるかを、公開されている仕様に沿って書きます。

1-2. 本記事で使う言葉

条件は、問いの中で答えを絞り込む要素を指します。業種、地域、予算、時期、用途、仕様などです。基準の問いは、条件を入れずに、対象の分野だけを聞く問いを指します。ファンクエリは、クエリファンアウトで生まれる一つひとつの検索を指す、当社が社内で使っている呼び名です。いずれも本記事の説明のための言葉で、標準化された用語ではありません。

2-1. 生成AI向けガイドの一文

最初に、Googleの原文をそのまま引きます。Search Central の生成AI向け最適化ガイド（最終更新2026年7月10日）からです。

While it might be tempting to create separate content for every possible variation of how people might search (for example, by focusing on other queries that people have asked, or fan-out queries), doing so primarily to manipulate rankings or generative AI responses in Google Search violates Google's scaled content abuse spam policy.

人が検索しうるあらゆる変形ごとに別々のコンテンツを作ることを、主として順位やGoogle検索の生成AIの回答を操作する目的で行えば、大量生成によるスパムの方針に違反する、という一文です。 同じガイドは、続けて次のように書いています。

This is also an ineffective long-term strategy, as a high quantity of pages doesn't make a website higher quality or more relevant to users.

ページの数が多いことは、サイトの質や利用者への関連性を高めない、という理由づけです。

2-2. スパムの方針の定義

引用に出てくる「大量生成によるスパム」は、Googleのスパムに関する方針（最終更新2026年8月28日）で、次のように定義されています。

Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users.

同じ段落は、この行為が「no matter how it's created」、つまりどう作ったかを問わないと書いています。生成AIで作っても、人が書いても、判断の軸は同じです。

同じ方針には、「doorway abuse」という項目もあります。特定の似た検索で上位に出るためにサイトやページを作り、利用者を最終的な目的地ほど役に立たない中間のページへ導く行為、と定義されています。

2-3. 条件の組み合わせごとのページは、どう読まれうるか

条件の多い問いに対して、「業種×地域×予算」の組み合わせごとにページを作りたくなることがあります。本記事は、これを勧めません。 理由は三つです。

第一に、§2-1 の一文が名指ししている形に近いからです。 変形ごとに内容のほとんど同じページを並べれば、目的が操作にあると読まれうる形になります。

第二に、追いかける対象が揃わないからです。 §7-1 のとおり、同じ問いを繰り返すとファンクエリの多くが入れ替わったという観測があります。

第三に、条件への答えは、ページの数では増えないからです。 対応していない地域のページを作っても、対応していない事実は変わりません。

2-4. 禁じられていないこと

原文の条件を落とさずに読んでください。禁じられているのは、操作を主な目的として変形ごとに量産することです。 利用者の役に立つ別のページを作ること自体は禁じられていません。業種ごとに実際に違う事例がある、地域ごとに実際に違う料金や窓口がある、という場合には、それぞれのページが実際に違う情報を持ちます。ページごとに実際に違う、役に立つ情報があるかどうかは、大事な判断の材料です。ただし、Googleが方針に書いている基準は、主な目的が順位の操作にあるのか、利用者を助けることにあるのかです。 情報が違うことだけで、方針に触れないと言えるわけではありません。

3-1. 問いの条件を、情報の項目に置き換える

ここからは本記事の整理です。条件の多い問いに答えるには、問いに入りうる条件の一つひとつに、自社側で答える情報の項目があるかを確かめます。

表の右の列は、商品を扱う場合の例です。商品データを持たない事業については §4-4 で扱います。

この表で見るのは、項目が「ある」かどうかと、それが本文として「読める」かどうかです。 料金が問い合わせ後にしか分からない、対応地域が画像の地図にしか無い、事例の業種が書かれていない。こうした状態では、自社の公開ページの上で、条件を含んだ問いに直接答える根拠が足りません。

3-2. 答えられない条件は、無理に埋めない

条件を情報として持つとは、すべての条件に「はい」と答えることではありません。 対応していない地域、扱っていない価格帯があるなら、そう書かれていることも一つの情報です。

商品データの仕様は、二つとも、確かでない値を埋めないよう求めています。Merchant Center の商品データ仕様は、商品の詳細の属性について「Only provide an attribute name and value when the value is confirmed.」、つまり値が確かなときだけ書くよう求めています。OpenAI の商品フィード仕様は、任意の項目で値が分からなければ省くよう求め、「null」「unknown」「n/a」のような文字列を埋め草として使わないよう書いています。ただし同じ仕様は、「unknown」を正式な値として明記している項目では使ってよいとしており、在庫（availability）では、在庫の状態が分からないときに「unknown」をはっきり入れるよう求めています。

確かでない値で空欄を埋めると、問いの条件に「合う」と誤って答えさせる材料になりえます。

4-1. Merchant Center の商品データ仕様と、会話向けの属性

Googleの生成AI向け最適化ガイドは、Merchant Center のフィードなどが、AIの回答と他の検索結果の両方で商品やサービスが見えるのに役立ちうる（can help）としています。

Googleは2026年1月11日の発表で、AI Mode などでの会話型の買い物に向けて、よくある質問への答え、互換性のある付属品、代わりの品などを含む新しい属性を Merchant Center に加え、まず少数の小売事業者から始めると書きました。

Merchant Center のヘルプ「How to use conversational attributes」は、その属性を次の6つとして挙げています。

ヘルプは、これらの属性が任意であり、既存の商品データを補うものであること、入れても既存の商品の承認状態には影響しないことを書いています。AI Mode などの面で商品の情報を見つけてもらう助けになりうる、とも書いています。入れれば回答に出る、とは書いていません。

一つ注意があります。商品データ仕様は、商品のハイライトや詳細の属性について、検索語やキーワードを並べないよう書いています。条件を情報として持つことと、問いの語を詰め込むことは別です。

4-2. OpenAI の商品フィード仕様

OpenAI の開発者向けドキュメントは、商品データの仕様を「Submit product data for discovery in ChatGPT」として公開しています。要点は次のとおりです。

• 品目か、色やサイズ違いごとに1行を出し、9つの必須項目（品目のID、商品名、説明、商品ページのURL、ブランド、販売者名、画像、在庫、価格）を入れる。説明は事実に基づくものにする
• 素材、色、サイズ、寸法、重さなどを任意の項目として持てる
• レビューは件数と平均の評価を持てるが、レビューの本文や質問と答えの一覧は、この仕様の対象外と明記している
• Googleの形式に合わせたフィードは、登録したフィードについて OpenAI が対応を確認した後に限って使える（「Use this format only after OpenAI confirms it for your registered feed.」）
• 標準の形式で上げたフィードは、現時点では米国を対象にしており、ほかの市場は OpenAI が確認した後に限って使える、と書いている

4-3. 二つの仕様を並べる

二つの仕様は、持てる項目が同じではありません。 質問と答えは、Googleの仕様では持てますが、OpenAI の仕様では対象外です。どちらの仕様にも共通しているのは、確かな事実を、項目ごとに分けて持つという向きです。

4-4. 商品データを持たない事業の場合

受託の制作、専門サービス、BtoBの事業など、商品データを出さない事業には、これらの仕様は当てはまりません。Googleのガイドは、地域の事業について Google ビジネスプロフィールにも触れています。そのほかにも資料や外部の登録などの経路はありますが、商品データを持たない事業では、自社サイトの本文が、条件をはっきり示す主な公開の情報源の一つになります。

そこで、表2の考え方をページの本文に当てはめます。 対応業種、対応地域、価格帯、期間、対応範囲が、それぞれ読める形で書かれているか。これは本記事の整理であり、提供元が求めている形式ではありません。

5-1. 特別な schema は要らない

Googleの「AI features and your website」（最終更新2025年12月10日）は、次のように書いています。

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

同じページは、新しい機械向けのファイルやAI向けのテキストファイル、マークアップを作る必要はなく、「There's also no special schema.org structured data that you need to add.」とも書いています。生成AI向け最適化ガイドも、構造化データは生成AIの検索に必須ではなく、特別な schema.org のマークアップは無いとしたうえで、リッチリザルトのために従来どおり使うことは勧めています。

したがって、条件の多い問いのために、特別な構造化データを足す必要はありません。

ただし、これはAI向けの特別な要件が無いという意味です。通常の検索の要件が要らないという意味ではありません。同じページは、AI Overviews や AI Mode の補足のリンクとして表示される対象になるには、次の状態が必要だと書いています。

a page must be indexed and eligible to be shown in Google Search with a snippet

インデックスされ、スニペット付きで検索結果に表示されうる状態であること、です。

5-2. 構造化データは、見えている本文と一致させる

同じ「AI features and your website」は、推奨する取り組みの一つとして、次を挙げています。

Making sure your structured data matches the visible text on the page

構造化データの一般的なガイドライン（最終更新2026年7月10日）も、「Don't mark up content that is not visible to readers of the page.」と書いています。読者に見えていない内容をマークアップしない、ということです。

ここからは本記事の実務上の整理です。 条件に答える情報は、まず利用者にも見える形で示し、構造化データの内容は、その見えている情報と整合させます。構造化データが本文の逐語の写しである必要はありませんが、本文に無い対応地域や価格を構造化データにだけ書くことは、上のガイドラインに反します。求人の構造化データについて同じ論点を扱った求人票の構造化データについての記事もあわせて参照してください。

5-3. フィードとページを食い違わせない

Googleの「AI features and your website」は、推奨する取り組みに、Merchant Center とビジネスプロフィールの情報を最新にしておくことも挙げています。

ここからは本記事の整理です。同じ条件についての情報が、ページ、構造化データ、商品フィード、外部の登録に分かれて存在すると、食い違いが起こりえます。 価格や在庫、対応地域が場所ごとに違えば、どれが引かれるかで、条件に「合う」とも「合わない」とも答えられえます。表2の項目ごとに書いてある場所を一覧にし、正とする場所を一つ決めておきます。

ここからは、読者が自社で試せる一般的な手順です。当社の製品の機能を説明するものではありません。 当社の測り方は §11 に分けて書きます。

親記事の「条件を一つずつ足して測る」の節は、条件を一つずつ足すほうが、全部を一度に入れるより読み取りやすいことを示しました。本章は、それを実際に回すための手順として書きます。

6-1. 基準の問いを決める

基準の問いは、自社の名前を出さず、条件も入れずに、対象の分野だけを聞く問いです。 例として、制作会社であれば「コーポレートサイトの制作を頼める会社は」、靴であれば「トレイルランニング用の靴は」です。

基準の問いで自社が出てくるかどうかが、以後のすべての段の比較の起点になります。基準の問いで出てこない場合、条件を足して出てくるかを見る意味が変わります。 その場合は、条件を足すと出てくるのか（§6-5）を、別に読みます。

6-2. 条件の順番と、言い回しを固定する

次に、実際に投げられそうな形に近づくまで、条件を一つずつ足した問いの列を作ります。本記事ではこれを「条件の梯子」と呼びます。

作るときの約束は三つです。

一つ目。一段で足す条件は一つにします。 二つを同時に足すと、出てこなくなったときに、どちらの条件で出てこなくなったのかが分かりません。

二つ目。前の段の文をそのまま残し、足す部分以外の言い回しを変えません。 Sclar ほかの研究（ICLR 2024 採択）は、意味を保った書式の小さな変更で、あるモデルの正答率が最大76ポイント変わったと報告しています。この研究が調べたのは、例を添えて解かせる評価での書式の違いであり、AI検索や、自然な文の言い換えを直接調べたものではありません。それでも、足す条件以外の表現まで同時に変えると、比べる要因が増えます。本記事が言い回しも固定するのは、そのためです。

三つ目。条件の順番を入れ替えた梯子も、一本作ります。 業種→地域→予算の順で出てこなくなったとき、予算→地域→業種の順でも同じ条件のところで同じ向きの変化が出るなら、その結果が一つの並べ方だけに頼ったものではない、という手掛かりになります。順番によって結果が変わる場合は、条件どうしの組み合わせに加えて、語順や、条件が文のどこに置かれたかの影響も候補になります。

一段に一つの条件を足す組み立て方は、研究でも使われています。FollowBench（ACL 2024 採択）は、最初の指示に条件を一つずつ足す段階を設けて、13のモデルが条件にどこまで従うかを調べています。ただし、これは指示に従う能力の研究で、検索や引用を調べたものではありません。

6-3. 一段ごとに繰り返し、割合で読む

各段の問いは、同じ条件で繰り返し投げ、何回のうち何回、自社が出てきたかを割合で持ちます。回数が少ないと、割合の不確かさは大きくなります。

5回投げて一度も出なかったとしても、それだけでは、その条件のもとで出てくる確率が4割を超えている可能性を退けられません。

この区間は本記事の計算で、前提があります。記録した製品、モデル、検索の設定などが同じで、一回一回を、互いに影響しない、同じ条件の試行として扱えることです。実際には、検索の索引やモデルの更新、時刻などで、回答を作る過程そのものが変わることがあります。ここでいう割合は、時間を通じて変わらない真の値ではなく、記録した条件のもとで出てくる確率を推し量るものです。

段どうしを比べるときは、二つの区間が重なるかどうかでは判断しません。 二つの95%の区間が重なっていても、差がはっきりしている場合があります。比べるのは、二つの割合の差と、その差についての95%の区間です。差の区間が0をまたぐなら、この回数では差の向きを決めきれません。0をまたがないなら、上の前提が保たれている範囲で、実行ごとの揺らぎだけでは説明しにくい差と読みます。

梯子の読み方を、仮の数字で示します。基準の問いで20回中17回（85%）、業種を足して20回中14回（70%）、地域を足して20回中3回（15%）だったとします。本記事の計算（ニューカム–ウィルソンの方法による、差の95%の区間）では、次のようになります。

この場合、地域の条件に答える情報を、§3 の表で確かめることになります。ただし、段が多いほど、比べる組み合わせも増え、偶然の差を拾いやすくなります。 梯子の比較は探索のための診断として読み、一つの区間だけから原因を決めないでください。

何回繰り返すかは、読み取りたい差の大きさで決まります。 小さな差を見るほど回数が要ります。回数は、すべての段で同じにします。

6-4. 何を記録するか

親記事の「何を記録するか」の節は、出てきたか、どう扱われたか、何が出典として引かれたかの三つを記録するよう書きました。梯子で測るときは、段ごとの比較のために、次の項目を加えます。

「条件を満たすとされたか」は、名前が出たかどうかとは別に取ります。 名前は出ていても、「ただし首都圏には拠点がない」と書かれていれば、その条件については答えが届いていません。事実と違う理由で外されている場合は、その記述そのものが整える対象になります。

6-5. 結果を、整えるものへ戻す

梯子の結果は、原因を確定するものではありません。原因の候補を絞り、どの整備を確かめるかを決める手掛かりです。

整備を変えたら、同じ梯子を、同じ回数で、問い、製品とモデル、検索の設定などをできる限り揃えてもう一度測ります。ただし、その間にもモデルや検索の索引、外部の情報は変わりえます。これらは自社の側では固定できないため、前後の差だけから、整備が原因だと確定することはできません。 整備の後に、想定した向きの変化が繰り返し見られるかを確かめます。なお、整えた情報がAIの回答に反映されるまでの時間は提供元ごとに違い、本記事では扱いません。その論点はAIの回答に情報がいつまで残るかを扱う記事で扱っています。

7-1. ファンクエリは、安定して再現するとは限らない

クエリファンアウトを扱った記事の「ファンクエリそのものは、繰り返されるか」の節で扱ったとおり、Surfer の報告（最終更新2026年9月17日）は、グラウンディング付きの Gemini で同じ問いを10回実行し、各回のファンクエリを1回目、および直前の回と比べています。どちらでも一致はおよそ27%で、語句の66%は一度しか出ず、すべての回に出たのは0.6%でした。

これはAPIを使ったベンダーの観測で、利用者の画面そのものではなく、一致の判定の方法も書かれていません。それでも、一回の実行で得たファンクエリの一覧を、固定した対象として扱う根拠にはなりません。

7-2. 推薦の一覧も引用元も、同じものが返りにくいという観測がある

答えの側の揺らぎも報告されています。一つは、SparkToro のランド・フィッシュキン（Rand Fishkin）が、AIの可視性を測る事業者 Gumshoe と行った分析（2026年1月27日公表）です。ベンダーによる分析で、査読は経ていません。

600名の協力者が、12の問いを ChatGPT、Claude、Google の AI Overviews（表示されないときは AI Mode）に計2,961回投げ、返ってきたブランドや商品の一覧を集めています。ChatGPT と Google の AI では、同じ一覧が二度返る確率は100回に1回未満と報告され、Claude はそれよりわずかに同じ一覧を返しやすかった、とされています。同じ順番まで揃う一覧は、およそ1,000回に1回と報告されています。

同じ記事は、ヘッドホンについて人が書いた142通りの問いで994件の回答を集めたところ、上位の数ブランドは回答の55〜77%に出ていた、とも書いています。ここから言えるのは、一覧や順番をそのまま比べるより、何回のうち何回出たかという割合のほうが、読み取れる形になりやすい、ということです。 §6-3 で割合を使うのは、このためです。

なお、協力者はふだんの設定のまま実行しており、個人の文脈による違いと実行ごとの揺らぎは、この分析の中では分けられていません。

もう一つは、引用元についての Sielinski の研究です（未査読のプレプリント・最新版2026年8月26日）。Perplexity、SearchGPT、Gemini に、三つの商品分野の問い（言語モデルで作った各200問）を、約9日間の毎日と10分おきの二通りで繰り返し投げています。同じ問いへの回答どうしで、引用元がドメイン単位で重なる度合い（ジャカード係数）の中央値は、Gemini で0.29〜0.31、SearchGPT で0.33〜0.40、Perplexity で0.50でした。同研究は、一回で測った可視性の数字は実際より精密に見える、と結んでいます。

7-3. 記憶と個人の文脈で、答えが変わりうる

もう一つの理由は、提供元が、個人の文脈を使って答えを変える機能を公表していることです。記憶と個人に合わせた答えの論点は、AIの記憶とパーソナライズで扱います。本記事では、測り方に関わるところだけを書きます。

Googleは2025年8月13日の発表で、Gemini アプリが過去の会話を参照し、より個人に合わせた応答を返す設定を導入したと書きました。発表の時点では、対象となる利用者について、この設定は既定で有効とされていました。 個人に合わせるためには使われない「Temporary Chat」も、同時に導入されています。Anthropic も2025年9月11日に Claude に記憶の機能を導入し、記憶を使わず保存もしない「Incognito chat」があるとしています。ChatGPT の記憶の機能は、提供元の説明のページを取得できなかったため、本記事では扱いません。

ここから言えることは二つです。一つ目。測る側は、記憶や履歴を使わない状態で測り、その状態を記録します。 測っている人の過去の会話が答えに入れば、自社を測っているのか、測っている人を測っているのか区別がつきません。二つ目。そうして測った結果は、記憶を使う実際の利用者に見えている答えと、同じとは限りません。 利用者の記憶には、問いの文に書かれていない条件が入っている場合があるからです。

8-1. Search Console の生成AIのレポート

Search Console の「Generative AI performance report (Search)」は、AI Overviews と AI Mode で自社サイトへのリンクが利用者に表示された回数を見るレポートです。ヘルプは、2026年8月31日に全世界のサイトへ展開したとしています。見られるのは、ページ、国、日付、デバイスごとの表示回数です。検索の種類として、文字による検索と、画像を使った検索（multimodal）を分けて絞り込むこともできます。

利用者が入力した問いは、切り口に含まれていません。 したがって、どの条件の問いで表示されたかは分かりません。

8-2. Bing Webmaster Tools の AI Performance と Clarity の Citations

Microsoft は2026年2月10日に、Bing Webmaster Tools の「AI Performance」を公開プレビューとして案内しました。対象は、Microsoft Copilot、Bing のAIによる要約、一部の提携先です。引用の総数、引用されたページの数、grounding queries（AIの回答で参照されたコンテンツを取り出すときに使われた語句）、ページごとの引用の数とその推移が見られます。2026年6月16日には、意図の分類（Intents）、語句のまとまり（Topics）、ある語句で表示された引用のうち自社サイトが占める割合（Citation Share）、期間の比較（Compare）が、プレビューとして世界で加わりました。

限界も書かれています。引用の総数は、回答の中での位置や見せ方を示しません。grounding queries は、引用の活動全体からの標本です。 Citation Share は、他社のドメインを示さず、順位や競争の点数でもない、と Microsoft 自身が書いています。そして、見えるのは引用に至った取得の語句で、取得されたが引用されなかった分は入りません。

Microsoft は、Bing Webmaster Tools と Clarity の信号をまとめた Clarity の「Citations」も、2026年5月13日に一般提供としました。引用されたページ、ほかの引用元と比べた割合、取り出しに使われた語句、AIからの流入の割合などが見られ、2026年2月17日の案内の記事は引用率（Citation Rate）も挙げています。同じ記事は、データについて次のように書いています。

The data provides a representative view of grounding and citation activity rather than a complete log of every reference.

すべての引用の記録ではなく、代表的な姿を示すもの、ということです。 量のごく少ないものは除かれうる、とも書いています。

8-3. Merchant Center の AI performance insights

Merchant Center のヘルプ「About AI performance insights」は、この報告を、AI Mode と AI Overviews での、買い物の意図を持つ会話型の問いにおける自社ブランドの見え方を示すもの、と説明しています。ヘルプは冒頭で、AIの面で買い物をする人は、より長く複雑な質問をすることがある（may ask）と書いています。

見られるのは、Merchant Center で定められた競合と比べた表示の占有率（share of voice）、問いを「探す」「比べる」「買う直前」の三つの段階に分けた見え方、よく使われる語、商品データに欠けているかもしれない、よく求められる属性、問いの背後の意図などです。

本記事の主題に直接つながるのは、欠けている属性の一覧です。 問いの条件と、自社の商品データの項目の差を、提供元が示す形になっているからです。

ただし、提供の範囲は限られています。ヘルプ（2026年9月25日確認）は、英語の問いについて、オーストラリア、カナダ、インド、ニュージーランド、米国の Merchant Center アカウントに提供しているとしています。日本語の問いは対象に入っていません。 集計は自然な表示（無料リスティング等）に限られ、広告は含まれません。

8-4. 三つの道具と、自社の測定を並べる

道具は、実際の利用者への表示や引用を、集計として見せます。梯子は、条件ごとの答えを、決めた問いで見せます。 どちらかが他方を置き換えるものではありません。日本語の問いについては、Merchant Center の報告は対象外です。Search Console の数字と、Bing については自社のアカウントで日本語のデータがどう現れるかを確かめたうえでその数字を、自社で決めた問いの測定と合わせて読むことになります。

8-5. 記録の側の不具合

道具の数字にも揺れがあります。Search Console のヘルプ「Data anomalies in Search Console」には、性質の違う二つの不具合が載っています。

一つ目は、検索の結果などのパフォーマンスレポート全般の不具合です。2025年5月13日から2026年4月27日まで、記録の不具合で表示回数が正しく報告されていなかったとされています。クリック率と平均掲載順位も影響を受け、クリック数は影響を受けていないとしています。生成AIのレポートに固有の不具合ではありません。

二つ目は、それとは別の、生成AIのレポートに固有の不具合です。2026年8月13日から17日の表示回数が減ったとされ、8月21日に欠けたデータを戻したとしています。

これらの期間をまたいで前後を比べるときは、当時保存した値に不具合の影響が混ざっていないかを確かめてください。 整備の前後の比較を、道具の数字だけで行わない理由の一つです。

ここまでを、一巡の手順にまとめます。

1. 条件を洗い出す。 自社の顧客が問いに入れそうな条件を並べる（表2の左の列）
2. 項目があるかを確かめる。 条件ごとに、自社側の情報の項目が本文で読めるか、商品データにあるかを見る
3. 正とする場所を決める。 ページ、構造化データ、商品フィード、外部の登録の値を突き合わせ、食い違いを直す
4. 梯子を作る。 基準の問いと、一段に一つずつ条件を足した問いの列を作り、順番を入れ替えた列も一本作る
5. 条件を固定して測る。 回数、製品とモデル、検索の有無、記憶と履歴の状態、言語、地域を決めて記録する
6. 割合と、差の区間で読む。 段どうしは割合の差とその区間で比べ、0をまたがない低下がどの条件で起きたかを、探索のための診断として見る
7. 整備へ戻す。 表9の型に当てはめ、確かめる整備を決めて直す
8. 同じ条件で測り直す。 条件をできる限り揃えて同じ梯子を測り、想定した向きの変化が繰り返し見られるかを確かめる（§6-5）
9. 道具の数字と並べる。 Search Console、Bing、（対象であれば）Merchant Center の数字を、不具合の期間に注意して並べる

ここを飛ばして読まないでください。 本記事の手順には、弱いところが複数あります。

一つ目は、本記事の手順にとって重い反証です。 実際の利用者は、梯子のように条件を一つずつ足して問いません。梯子は、利用者の問いを再現するものではなく、どの条件で答えが変わるかを切り分けるための、診断の道具です。 梯子の結果を、そのまま利用者が見ている姿として読まないでください。

二つ目。固定した言い回しそのものが結果に影響している可能性は残ります。余力があれば、基準の問いを二通りの言い回しで用意し、同じ梯子を二本測ります。

三つ目。未査読のプレプリントですが、Chen ほかの研究は、AI検索がブランド自身の媒体より外部の権威ある媒体へ偏っていると報告しています。条件に答える情報を自社で整えても、回答に引かれるのは外部の媒体の記述である場合があります。 §6-4 で出典を記録するのは、この場合を見分けるためです。

四つ目。効果として引かれる研究の数字の射程です。 Aggarwal ほかの研究（KDD 2024 採択）は、文章の書き換えで生成エンジンの回答の中での見え方が最大40%上がりうると報告していますが、測ったのは回答の中の見え方で、サイトへの流入や売上ではありません。Martinez のレビュー（未査読のプレプリント）は、この結果を、情報源がすでに回答の材料に入っている条件でのものとし、45の研究の中に、自然に見つけられることやその先の利用者の行動について、複数のエンジンで長期に安定した因果の効果を示した手法は無かったと書いています。Puerto ほかの研究も、会話型の検索向けの書き換えの多くがほとんど効かず、順位を下げることも多かったと報告しています。

反証を並べたうえで残るのは、次のことまでです。 条件を情報として持つことは、操作を目的とした量産とは別の取り組みであり、条件を一つずつ足して繰り返し測れば、答えが変わる条件の候補を絞れる。「こうすれば回答に出る」とは、本記事は主張しません。

ここからは当社の立場です。

当社、株式会社Vaigate（ヴァイゲート）が運営する Vaipm（ヴァイピム）は、AI上の認知を、複数のAIへの合計25回のステートレス計測で測定しています。ステートレスとは、ログインの状態や過去のやりとりを引き継がずに測るという意味で、§7-3 の一つ目と同じ考え方です。この回数は当社が採用している観測の設計であり、研究から導かれた最適な値ではありません。

Vaipmは、対象について4通りの聞き方をします。名指しで聞く。名前を出さずカテゴリで聞く。競合と並べて聞く。固有の施策名で聞く。聞き方によって、AIの答えは変わります。

§6 の「基準の問いに条件を一つずつ足す」手順は、本記事が示す一般的な手順であり、Vaipmの聞き方と同じものではありません。 自社がAIの回答の中でどう扱われているかは、Vaipmで測れます。

この測定で分からないことも書いておきます。実際の利用者がどんな問いを入力しているか、記憶を使う利用者にどう見えているか、回答の中での扱われ方が事業の成果にどう結びつくかは、この測定では分かりません。 測定が答える範囲を広げて書かないことも、設計のうちだと考えています。

ロングクエリ対策は、ページの数ではなく、情報の中身の話です。 Googleは、変形ごとのコンテンツ作成を、主として操作が目的ならスパムの方針に違反すると明記しています。

整えるのは、問いの条件に答える情報の項目です。 それが本文で読め、商品であれば商品データにも入っていること。Merchant Center と OpenAI の仕様は持てる項目が同じではありませんが、どちらも確かでない値を埋めないよう求めています。特別な schema は要りませんが、通常どおりインデックスされ、検索結果に表示されうる状態であることは必要です。構造化データは、見えている情報と整合させます。

測るのは、基準の問いに条件を一つずつ足したときの、段ごとの割合です。 言い回しを固定し、順番を入れ替えた列も作り、各段を同じ回数繰り返し、段どうしは割合の差とその区間で比べます。梯子の比較は、探索のための診断です。記録には、条件に合うとされたか、何が引かれたか、記憶と履歴の状態も残します。一回の結果は、試行にすぎません。

見える化の道具は、実際の利用者への表示や引用を集計で見せますが、問いの文や日本語の問いには限界があります。 道具の数字と自社の測定は、並べて読みます。そして、梯子は利用者の問いの再現ではなく、診断の道具です。 整えても引かれるとは限らず、効果の研究も回答の中の見え方を測ったものです。本記事が示せるのは、何を整え、どう確かめるかの手順までです。

Q1. ロングクエリ対策とは何ですか。

本記事では、条件の多い問いに答える情報を整え、それがAIの回答に届いているかを測ることを指します。シリーズの親記事の定義を実務の手順に落としたもので、実務での言い方です。公式の規格や標準化された用語ではありません。整えるのは問いの条件に答える情報の項目で、測るのは基準の問いに条件を一つずつ足したときの、段ごとの割合です（§1、§3、§6）。

Q2. 想定される問いごとにページを作れば対策になりますか。

本記事は勧めません。Googleは、人が検索しうる変形ごとに別々のコンテンツを作ることを、主として順位や生成AIの回答を操作する目的で行えば、大量生成によるスパムの方針に違反すると明記しています。ページの数が多いことはサイトの質や関連性を高めない、とも書いています。利用者の役に立つ、実際に違う情報を持つページを作ること自体は禁じられていません（§2）。

Q3. 条件の多い問いのために、特別な構造化データは必要ですか。

必要ありません。Googleは、AI Overviews や AI Mode に出るための追加の要件は無く、特別な schema.org の構造化データを足す必要も無いと書いています。一方で、構造化データは見えている本文と一致させるよう求め、読者に見えていない内容をマークアップしないよう書いています。ただし、これはAI向けの特別な要件が無いという意味で、通常どおりインデックスされ、スニペット付きで検索結果に表示されうる状態であることは必要です。本記事の実務上の整理としては、条件に答える情報をまず利用者に見える形で示し、構造化データの内容をそれと整合させます（§5）。

Q4. Merchant Center の会話向けの属性を入れれば、AI Mode に表示されますか。

そうとは書かれていません。Merchant Center のヘルプは、question_and_answer や related_product などの会話向けの属性を任意のものとし、AI Mode などの面で商品の情報を見つけてもらう助けになりうる、と書いています。入れても既存の商品の承認状態には影響しないとしています。表示を約束するものではありません（§4-1、§10）。

Q5. Google と OpenAI の商品データの仕様は同じですか。

同じではありません。Merchant Center では質問と答えを question_and_answer として持てますが、OpenAI の仕様は、レビューの本文や質問と答えの一覧を対象外と明記しています。共通しているのは、確かでない値を埋めないことです。Merchant Center は値が確かなときだけ書くよう求め、OpenAI は任意の項目で分からない値を省き、「unknown」などの文字列を埋め草に使わないよう求めています。ただし在庫の項目のように、「unknown」が正式な値として定められている項目は別です（§3-2、§4-3）。

Q6. 商品を扱っていない事業では、何を整えればよいですか。

商品データの仕様は当てはまりませんが、同じ考え方をページの本文に当てはめます。対応業種、対応地域、価格帯、期間、対応範囲などが、それぞれ本文で読める形で書かれているかを確かめます。これは本記事の整理で、提供元が求めている形式ではありません。対応していない条件があれば、そう書かれていることも一つの情報です（§3、§4-4）。

Q7. 「基準の問いに条件を一つずつ足す」とは、どういう手順ですか。

自社の名前も条件も入れずに分野だけを聞く問いを基準にし、業種、地域、予算などの条件を一段に一つずつ足した問いの列を作ります。前の段の文を残して言い回しを変えず、順番を入れ替えた列も一本作ります。各段を同じ回数繰り返し、何回のうち何回自社が出たかを割合で持ち、どの条件を足した段で下がったかを見ます（§6）。

Q8. 何回繰り返せばよいですか。

読み取りたい差の大きさで決まります。本記事の計算では、5回投げて一度も出なかった場合でも、その条件のもとで出てくる確率が4割を超えている可能性を退けられません。20回で半分出た場合の95%の区間はおよそ30〜70%、40回ならおよそ35〜65%です。回数を決めたら、すべての段で同じにします。段どうしは、二つの区間が重なるかどうかではなく、割合の差とその95%の区間で比べます。これらは、同じ条件の試行を互いに影響しないものとして扱えることを前提にした計算です（§6-3）。

Q9. 測るときに、記憶の機能は切るべきですか。

切って測り、その状態を記録することを勧めます。Google は、Gemini アプリが過去の会話を参照して応答を個人に合わせる設定を導入し、発表の時点では対象となる利用者について既定で有効としていました。Anthropic も Claude に記憶の機能を導入しています。測る人の履歴が答えに入ると、何を測っているか区別がつきません。ただし、記憶を切った測定は、記憶を使う実際の利用者の画面と同じとは限りません（§7-3）。

Q10. Search Console で、どの条件の問いで表示されたか分かりますか。

分かりません。Search Console の生成AIのレポートで見られるのは、AI Overviews と AI Mode で自社サイトへのリンクが表示された回数を、ページ、国、日付、デバイスごとに分けたものです。利用者が入力した問いは切り口に含まれていません。なお、Search Console では、2025年5月13日から2026年4月27日までパフォーマンスレポート全般で表示回数が正しく記録されない不具合がありました。これとは別に、生成AIのレポートでは2026年8月13日から17日の表示回数が減る不具合があり、8月21日に欠けたデータが戻されています（§8-1、§8-5）。

Q11. Bing Webmaster Tools や Merchant Center の報告で、日本語の問いを見られますか。

Merchant Center の AI performance insights は、ヘルプの記載では、英語の問いについて、オーストラリア、カナダ、インド、ニュージーランド、米国のアカウントに提供されており、日本語の問いは対象に入っていません。Bing Webmaster Tools の AI Performance は、引用に至った取得の語句を標本として見せますが、発表の記事に言語についての記載は無く、日本語での扱いを本記事では確かめていません。自社のアカウントで、日本語のデータがどう現れるかを確かめてください（§8-2、§8-3、§8-4）。

Q12. 梯子で測った結果は、実際の利用者が見ている答えと同じですか。

同じとは限りません。実際の利用者は、同じ意図でも大きく違う問いを書き、条件を一つずつ足しては問いません。記憶を使う利用者には、問いの文に書かれていない条件も入りえます。梯子は、どの条件で答えが変わるかを切り分けるための診断の道具です。原因を確定するものでもなく、整備を確かめる候補を絞る手掛かりです（§6-5、§10）。

1. Google Search Central「Optimizing your website for generative AI features on Google Search」最終更新2026年7月10日。検索しうる変形ごとにコンテンツを作ることと大量生成によるスパムの方針の関係を定めた一文（"While it might be tempting to create separate content for every possible variation of how people might search (for example, by focusing on other queries that people have asked, or fan-out queries), doing so primarily to manipulate rankings or generative AI responses in Google Search violates Google's scaled content abuse spam policy."）、"This is also an ineffective long-term strategy, as a high quantity of pages doesn't make a website higher quality or more relevant to users."、構造化データが生成AIの検索に必須ではなく特別な schema.org のマークアップも無い旨、Merchant Center のフィードやビジネスプロフィールがAIの回答と他の検索結果で商品やサービスが見えるのに役立ちうる旨、Search Console の生成AIのレポートを使うよう案内する記述。https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
2. Google Search Central「AI features and your website」最終更新2025年12月10日。"There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary."、"There's also no special schema.org structured data that you need to add."、推奨する取り組みとしての "Making sure your structured data matches the visible text on the page" および Merchant Center とビジネスプロフィールの情報を最新にしておくこと、AI Overviews や AI Mode の補足のリンクとして表示される対象になるには "a page must be indexed and eligible to be shown in Google Search with a snippet" である旨と、インデックスや表示が保証されない旨。https://developers.google.com/search/docs/appearance/ai-features
3. Google Search Central「Spam policies for Google web search」最終更新2026年8月28日。"Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users."、作り方を問わない旨（"no matter how it's created"）、doorway abuse の定義。https://developers.google.com/search/docs/essentials/spam-policies
4. Google Search Central「General structured data guidelines」最終更新2026年7月10日。"Don't mark up content that is not visible to readers of the page."https://developers.google.com/search/docs/appearance/structured-data/sd-policies
5. Google Merchant Center ヘルプ「How to use conversational attributes」。会話向けの属性6つ（question_and_answer、document_link、related_product、item_group_title、variant_option、popularity_rank）、任意であり既存の商品データを補うものである旨、既存の商品の承認状態に影響しない旨、AI Mode などの面で商品の情報を見つけてもらう助けになりうる旨。https://support.google.com/merchants/answer/17085370?hl=en
6. Google Merchant Center ヘルプ「Product data specification」。商品の詳細の属性について "Only provide an attribute name and value when the value is confirmed."、商品のハイライトや詳細に検索語やキーワードを並べない旨、popularity_rank が利用者の評価ではなく事業者による人気の評価である旨、question_and_answer と related_product の定義。https://support.google.com/merchants/answer/7052112?hl=en
7. Google「New tech and tools for retailers to succeed in an agentic shopping era」2026年1月11日。AI Mode、Gemini、Business Agent などの面での会話型の買い物に向けて Merchant Center に多数の新しい属性を加える旨、よくある質問への答え・互換性のある付属品・代わりの品を含む旨、少数の小売事業者から始める旨。https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/
8. OpenAI 開発者向けドキュメント「Products」（Commerce・File Upload）。"Submit product data for discovery in ChatGPT"、9つの必須項目、説明は事実に基づくものにする旨、任意の項目で値が分からなければ省き "null"・"unknown"・"n/a" のような文字列を埋め草に使わない旨（"unknown is valid only where explicitly listed"。availability では在庫の状態が分からないとき unknown を明示する旨）、"Raw review entries and question-and-answer lists are not part of this discovery contract."、Googleの形式に合わせたフィードは "Use this format only after OpenAI confirms it for your registered feed." である旨、標準の形式のアップロードが現時点で米国を対象にする旨。https://developers.openai.com/commerce/specs/file-upload/products
9. Google Merchant Center ヘルプ「About AI performance insights」。AI Mode と AI Overviews での買い物の意図を持つ会話型の問いにおける見え方を示す旨、"As people use AI surfaces to shop, they may ask longer, more complex questions."、英語の問いについてオーストラリア・カナダ・インド・ニュージーランド・米国のアカウントに提供している旨、share of voice、三つの買い物の段階、よく使われる語、欠けているかもしれない属性、自然な表示に限る旨、競合の組を変更できない旨。https://support.google.com/merchants/answer/17200695?hl=en
10. Microsoft Bing Webmaster Blog「Introducing AI Performance in Bing Webmaster Tools Public Preview」2026年2月10日。対象（Microsoft Copilot、Bing のAIによる要約、一部の提携先）、引用の総数、引用されたページの平均、grounding queries（"Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers."・標本である旨）、ページごとの引用、推移、引用の総数が回答の中での位置や見せ方を示さない旨。https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview
11. Microsoft Bing Search Blog「New AI Visibility Insights in Bing Webmaster Tools: Intents, Topics, Citation Share, Compare」2026年6月16日。四つの機能をプレビューとして世界で提供した旨、Citation Share の算出の仕方と、他社のドメインを示さず順位や競争の点数ではない旨。https://blogs.bing.com/search/June-2026/New-AI-Visibility-Insights-in-Bing-Webmaster-Tools-Intents-Topics-Citation-Share-Compare
12. Google Search Console ヘルプ「Generative AI performance report (Search)」。2026年8月31日に全世界のサイトへ展開した旨、AI Overviews と AI Mode での表示回数、ページ・国・日付・デバイスの切り口、文字による検索と画像を使った検索の絞り込み、Search Labs の実験を含まない旨、同じサイトの結果が同じ機能の中に二つ出た場合にグラフで1回として数える旨。https://support.google.com/webmasters/answer/16984139?hl=en
13. Google Search Console ヘルプ「Data anomalies in Search Console」。パフォーマンスレポートについて、2025年5月13日から2026年4月27日まで記録の不具合で表示回数が正しく報告されず、クリック率と平均掲載順位も影響を受け、クリック数は影響を受けていない旨。これとは別に、生成AIのレポート（Search）で2026年8月13日から17日の表示回数が減り、8月21日に欠けたデータを戻した旨。https://support.google.com/webmasters/answer/6211453?hl=en
14. ベンダーの観測。Surfer「AI Search Study: Understanding Keyword Query Fan-out」最終更新2026年9月17日。グラウンディング付きの Gemini で同じ問いを10回実行し、各回のファンクエリを1回目・直前の回と比べて一致がおよそ27%、66%が一度だけ出現、全回に出たのは0.6%。https://surferseo.com/blog/keyword-query-fan-out-research/
15. ベンダーの分析。Rand Fishkin「NEW Research: AIs are highly inconsistent when recommending brands or products; marketers should take care when tracking AI visibility」SparkToro、2026年1月27日（Gumshoe との共同）。600名が12の問いを ChatGPT・Claude・Google の AI Overviews（表示されないときは AI Mode）に計2,961回投げた結果、ChatGPT と Google の AI で同じ一覧が二度返るのは100回に1回未満、Claude はそれよりわずかに同じ一覧を返しやすい旨、同じ順番まで揃うのはおよそ1,000回に1回。人が書いた問いどうしの意味の近さの平均0.081。ヘッドホンについての142通りの問い・994件の回答で上位の数ブランドが55〜77%に出現。協力者はふだんの設定（個人に合わせた設定か既定の設定か）のまま実行した旨。2025年11月から12月に実施。https://sparktoro.com/blog/new-research-ais-are-highly-inconsistent-when-recommending-brands-or-products-marketers-should-take-care-when-tracking-ai-visibility/
16. Google「Gemini adds Temporary Chats and new personalization features」2025年8月13日。Gemini アプリが過去の会話を参照して好みを学び、個人に合わせた応答を返す設定、発表の時点でその設定が既定で有効とされた旨（当初は一部の国・モデル、18歳以上の個人アカウントに限る旨の注記あり）、個人に合わせるために使われない Temporary Chat。https://blog.google/products-and-platforms/products/gemini/temporary-chats-privacy-controls/
17. Anthropic「Bringing memory to Claude」2025年9月11日（2025年10月23日に対象拡大の追記）。Claude の記憶の機能が任意である旨、記憶を使わず保存もしない Incognito chat。https://claude.com/blog/memory
18. Yuxin Jiang, Yufei Wang, Xingshan Zeng, Wanjun Zhong, Liangyou Li, Fei Mi, Lifeng Shang, Xin Jiang, Qun Liu, Wei Wang「FollowBench: A Multi-level Fine-grained Constraints Following Benchmark for Large Language Models」arXiv:2310.20410、2023年10月31日投稿／2024年6月5日改訂（ACL 2024 採択）。最初の指示に条件を一つずつ足す段階を設け、13のモデルを評価。https://arxiv.org/abs/2310.20410
19. Melanie Sclar, Yejin Choi, Yulia Tsvetkov, Alane Suhr「Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design or: How I learned to start worrying about prompt formatting」arXiv:2310.11324、2023年10月17日投稿／2024年7月1日改訂（ICLR 2024 採択）。意味を保った書式の変更で正答率が最大76ポイント変わった（LLaMA-2-13B）こと、一つの書式ではなく書式の幅を報告するよう勧める旨。https://arxiv.org/abs/2310.11324
20. Mahe Chen, Xiaoxuan Wang, Kaiwen Chen, Nick Koudas「Generative Engine Optimization: How to Dominate AI Search」arXiv:2509.08919、2025年9月10日（未査読のプレプリント）。AI検索がブランド自身の媒体より外部の権威ある媒体へ偏っているとすること、AI検索のサービスどうしで言い回しへの反応などが大きく異なるとすること。https://arxiv.org/abs/2509.08919
21. Pranjal Aggarwal, Vishvak Murahari, Tanmay Rajpurohit, Ashwin Kalyan, Karthik Narasimhan, Ameet Deshpande「GEO: Generative Engine Optimization」arXiv:2311.09735、2023年11月16日投稿／2024年6月28日改訂（KDD 2024 採択）。"GEO can boost visibility by up to 40% in generative engine responses"、効果が分野によって異なる旨。測っているのは生成エンジンの回答の中での見え方。https://arxiv.org/abs/2311.09735
22. Haritz Puerto, Martin Gubri, Tommaso Green, Seong Joon Oh, Sangdoo Yun「C-SEO Bench: Does Conversational SEO Work?」arXiv:2506.11097、2025年6月6日投稿／2025年10月20日改訂（arXiv の Comments 欄に NeurIPS 2025 Datasets & Benchmarks 採択と記載）。質問応答と商品推薦の二つの課題・各三分野。"most current C-SEO methods are not only largely ineffective but also frequently have a negative impact on document ranking"、従来のSEOの手法のほうが効果が大きかった旨、採る者が増えるほど利得が減る旨。https://arxiv.org/abs/2506.11097
23. Olivier Martinez「Optimizing Visibility in Generative Engines: A Critical Survey of Generative Engine Optimization (2023-2026)」arXiv:2607.14035、2026年7月15日投稿（未査読のプレプリント）。45の研究のレビュー。基礎の研究の効果は情報源がすでに固定の文脈にある条件でのものである旨、"no reviewed technique shows a stable, longitudinal, cross-platform causal effect on organic discoverability or downstream behavior"。https://arxiv.org/abs/2607.14035
24. Ronald Sielinski「Quantifying Uncertainty in AI Visibility: A Statistical Framework for Generative Search Measurement」arXiv:2603.08924、2026年3月9日投稿／2026年8月26日改訂（未査読のプレプリント）。Perplexity Search・OpenAI SearchGPT・Google Gemini、三つの商品分野・各200問（言語モデルで生成）、約9日間の日次と10分間隔の二通りの反復。ドメイン単位の照合。同じ問いへの回答どうしの引用元ドメインのジャカード係数の中央値（Gemini 0.29〜0.31、SearchGPT 0.33〜0.40、Perplexity 0.50）、"single-run visibility metrics provide a misleadingly precise picture of domain performance"。https://arxiv.org/abs/2603.08924
25. Microsoft Clarity Blog「Understanding Your Influence in AI Answers with Microsoft Clarity (Early Access)」2026年2月17日（一般提供の旨の追記あり）。Citations の指標（Citation Rate、Grounding Queries ほか）、"The data provides a representative view of grounding and citation activity rather than a complete log of every reference."、量のごく少ないものは除かれうる旨、Bing Webmaster Tools と Clarity の信号をまとめたものである旨。https://clarity.microsoft.com/blog/understanding-your-influence-ai-citations/
26. Microsoft Clarity Blog「Understand Your Influence in AI Answers: Citations Now Generally Available」2026年5月13日。Citations の一般提供、引用されたページ、Share of authority、AI referral traffic、Queries などの指標。https://clarity.microsoft.com/blog/citations-now-generally-available/

本記事の出典1〜20は2026年9月25日に、21〜26は2026年9月28日に、一次情報で直接確認した。ChatGPT の記憶の機能についての提供元の説明のページは、取得が拒否され、原文を確認できなかったため、本記事はそれに基づく記述を含まない。表6と表7の区間は本記事の計算（表6はウィルソンの方法、表7はニューカム–ウィルソンの方法）であり、§6-3 の回数は仮の例である。日本語でのファンクエリの再現や推薦の一覧の揺らぎを測った一次のデータは、本記事の調査範囲では確認できなかった。