AIアシスタントが顧客の代わりに地域の店を決めている――Uberall調査は1クエリ3〜5ブランド、Whitesparkは540クエリで検証【2026年8月】

何が起きたか:比較作業がアシスタント側へ移った

記事の出発点は「AIアシスタントは、ローカルの顧客が自分でやっていた比較作業をこなせるようになった」という指摘です。Googleは AI Mode について、探索や推論、複雑な比較が必要な質問――以前なら複数回の検索を要したような質問――に特に役立つと説明しています。つまりアシスタントは、候補の絞り込みという工程そのものを引き受けます。

結果として、顧客はビジネス側が管理しているどのページにも到達する前に、短い候補リストを見ることになります。記事はこの構図を、オーガニック検索との対比で説明しています。オーガニック検索なら順位を確認すれば自社の立ち位置がおおよそ分かる。GoogleのAI機能については「生成AIパフォーマンスレポート」が、自社サイトへのリンクがAI機能に表示された回数を示します。しかしそのレポートには、各表示のきっかけとなったクエリは含まれず、他のアシスタントで何が起きているかも分かりません。

Googleが説明している仕組み:RAG(グラウンディング)とクエリ・ファンアウト

記事によると、Googleは検索のAI機能が通常の検索結果と同じランキング／品質システムに根ざしていると述べており、回答生成の工程に固有の技術として2つを挙げています。

1つは検索拡張生成(RAG)で、Google自身はこれをグラウンディングとも呼びます。既存のランキングシステムを使って検索インデックスから関連ページを引き出し、それらのページが述べている内容から回答を生成し、根拠となったページへリンクする仕組みです。もう1つはクエリ・ファンアウトで、関連する複数の検索を同時に実行し、元の質問だけでは返らない範囲の結果を集める技術です。

この仕組みの帰結として記事が強調するのは、自社サイトのコンテンツをGoogleのAI回答に寄与させたいなら、それはGoogleが取得できるページ上に存在していなければならないという点です。記事は「クライアントとの昼食に使える静かなレストラン」を例に挙げ、そうした条件はレビューや説明文など、Googleが読める場所に書かれていなければならないと説明しています。また、同じ店について異なる情報を持つ複数のソースをGoogleが引いた場合、その差をどう解決するかはGoogleが文書化していないため、自社が管理できるすべてのページで同じ情報が出るようにしておくことが有効だとしています。

候補に入るための「入場料」:リスティング・レビュー・評判

記事は、リスティング、レビュー、評判のいずれもが「アシスタントがその店を回答内で検討対象にするかどうか」に影響しうると整理しています。これらの信号については同筆者が別記事で扱っており、その内容から変わった点はないと明記されています。

実際の絞り込みの厳しさを示すデータとして、Uberallの数字が引かれています。同社のクイックサービスレストラン(QSR)ベンチマークでは、1クエリあたり推薦されるブランドは通常3〜5社だったというものです。記事はこの数字に「1つのベンダーが1つの業種を読んだ結果にすぎない」という留保を付けつつ、対象となる枠がどれほど小さいかの感覚は得られるとしています。

そして「ローカルSEOの取り組みの多くは、推薦されるに値する状態を確保することに費やされる」という整理が続きます。リスティングを正確に保つ、レビュープロフィールを活発に維持する、ソース間で情報の一貫性を確保する。いずれも「推薦の適格性」に寄与する作業です。ただし記事は、Googleの要件を満たすことは重要だが、それがAI機能への掲載を自動的に保証するわけではないと明確に書いています。

Search Consoleで見えるもの、見えないもの

Googleは AI Overviews と AI Mode のデータをメインのパフォーマンスレポートに折り込み、検索タイプ「ウェブ」の中に他の結果と混ぜて表示します。記事によれば、そこに含まれるクリックは合計値に入っており、その画面で切り出すことはできません。

切り分けができるのは「生成AIパフォーマンスレポート」です。ただしGoogleは現在も段階的な提供を進めている途中で、すべてのプロパティで利用できるわけではありません。同レポートが数えるのは表示回数(インプレッション)、すなわちサイトへのリンクがGoogleの生成AI機能のいずれかに現れた回数で、ページ、国、デバイス、日付で内訳が見られます。

ここに2つの限界があります。第一に、クエリのディメンションがないため、1件の表示は「あるページへのリンクが表示された」以上のことを意味しません。第二に、そのページが推薦された回答なのか、競合が推薦されて自社は下部にソースとして並んだだけなのかを区別しません。加えて、このレポートが対象とするのはGoogleのみで、ChatGPT・Perplexity・Claudeが「どのローカルビジネスを使うべきか」を尋ねた人に何と答えたかは、Search Consoleのどこにも現れません。

実測データ:AI Overviewsの出現率は直接型15%、情報型92%、ハイブリッド型97%

記事が引くもう1つの実測は、Whitesparkの分析です。米国3都市・6業種で540クエリを検証したもので、同筆者が7月に取り上げた内容だと注記されています。結果は次のとおりです。

ここでいうハイブリッド型は、情報を求める形をとりながら購買判断を内包している質問で、記事は「事故の後で弁護士を雇うべきか(“should I hire a lawyer after an accident”)」を例に挙げています。そして「AIの回答が、顧客が検討するビジネスの範囲を形づくりうるのは、こうしたクエリだ」と位置づけています。店名や地名を直接打つクエリよりも、その前段にある悩み相談のようなクエリで、候補集合が決まっているという読み方です。

3つの計測方法と、それぞれが取りこぼすもの

より良いレポートを待つ間、現場が使っている計測方法は2通りあると記事は整理します。1つは、主要なアシスタントに対して固定のローカルクエリ群を定期的に投げ、どのビジネスが名指しされたかを記録する方法。これは実行した日のそのクエリを押さえるだけであり、アシスタントの回答は言い回し・位置情報・セッションで変わるため、数値は方向性を示すものにとどまります。もう1つは、データが取れる範囲でAI経由の参照トラフィックを分析上で切り分け、量と行動を時系列で追う方法です。こちらはクリック後に何が起きたかを示しますが、対象は「回答を見た人」より小さい集団です。

記事はこの整理を、どの方法が何を示し何を欠くかという形で表にしています。

あわせて記事は、Googleのガイダンスが「Googleの内部ランキングやAIシステムへのアクセスを主張するサードパーティ製ツール」に対して警告していることにも触れています。

Googleのガイドが明言していること:llms.txtは無視、チャンク分割は不要

記事はGoogleの最適化ガイドの記述も整理しています。まず、AI機能に表示される資格を得るには、サイトが検索の生成AI機能に含まれている必要があります。この設定はGoogleが一部のサイト所有者にのみ段階的に提供しており、既定値は「含める(Include)」です。子プロパティは、手動で設定された最も近い親から設定を継承し、子側で上書きしない限りそのままになります。記事は、設定が利用できる場合は除外されていないかを確認する価値があるとし、店舗ごとに個別プロパティを運用している事業者は、上位ドメインの除外設定を継承していないかも確認すべきだと促しています。

Googleのガイドラインはこのほか、robots.txtとCDNの双方でクロール許可を開けておくこと、重要なコンテンツをテキストとして利用可能にすることを推奨しています。また、可視のページ内容と整合した構造化データ、そして最新のビジネスプロフィール情報の重要性を強調しています。JavaScriptで生成されるコンテンツについても、ブロックされていなければGoogleは処理できるとしつつ、JavaScriptフレームワークのサイトは一般に扱いが複雑になるとガイドは述べており、記事は「レンダリングの各段階が、営業時間が表示されない原因になりうる」と補足しています。

誤解の解消として明示されているのが次の2点です。Google検索は llms.txt および類似のAI向けテキストファイルを無視すること。そして、GoogleのAIシステムに理解させるためにコンテンツを小さなチャンクに分割する必要はないこと。AI検索対策として語られがちな施策のうち、Googleに関しては効果がないと公式に整理されている部分です。

もう1つ、実務上の注意として記事が挙げるのは、AIの回答が「事業者側が一切管理できないページ」からも情報を引く点です。昨年の営業時間を載せた古いディレクトリ、過去の記事、あるいは競合の比較ページが競合の言葉で自社を説明している、といったケースです。だからこそ、営業時間・サービス・対応エリアを、リスティングの内容と一致する形で、自社サイト上のプレーンテキストとして明記しておくことが推奨されています。

エージェントが予約を始めるとき:アクセシビリティツリーが読まれる

記事はGoogleの説明を引きながら、AIエージェントを「予約を取る、商品オプションを比較するといったタスクを人の代わりに実行するシステム」と定義します。そしてブラウザエージェントはサイトに直接アクセスし、レンダリング済みのスクリーンショットを分析し、DOMを検査し、スクリーンリーダーが依拠するアクセシビリティツリーを解釈する場合があるとされています。

この最後の点が、サイト側の宿題を1つ増やします。ラベルのないdivで作られたボタン、プレースホルダーのテキストしか手がかりのないフォーム項目、画像の中にしか存在しない電話番号は、いずれもスクリーンリーダーにとって問題です。記事は「Googleはこうした欠陥がエージェントを止めるとは言っていない」と留保を付けたうえで、アクセシビリティツリーはブラウザエージェントが解釈しうる層の1つだとGoogleが述べている、と整理しています。Googleは現在のブラウザエージェント向けのサイト準備について web.dev のガイドを案内し、Universal Commerce Protocol(UCP)のようなプロトコルを「出てきつつあるもの(emerging)」と位置づけているとされています。

ローカルビジネスにとっての備えは、これまでと同じ「明確な情報」に加えて、誰かが壊れたフォームを直しに入らなくても機能する予約・注文システムを持つこと、という整理になっています。

今日からできる確認手順

記事の内容から、優先度の高い確認項目を順に挙げます。第一に、Search Consoleで「生成AIパフォーマンスレポート」が自社プロパティに提供されているかを確認し、あればページ単位の表示回数を控えておくこと。クエリは分からないため、これは順位表の代わりにはなりません。第二に、生成AI機能への「含める／除外」設定が自社で利用可能かを確認し、店舗別プロパティを運用している場合は上位ドメインからの継承状態も点検すること。

第三に、営業時間・提供サービス・対応エリアが、画像やJavaScript依存ではなくプレーンテキストでサイト上に書かれているか、そしてその内容がGoogleビジネスプロフィールや各リスティングと一致しているかを突き合わせること。第四に、予約・問い合わせ動線のアクセシビリティ点検です。ボタンが適切な要素とラベルを持っているか、フォーム項目にラベルがあるか、電話番号が画像化されていないか。第五に、固定のローカルクエリ群を決めて主要アシスタントに定期的に投げ、名指しされたビジネスを記録しておくこと。ただしこの数値は方向性を示すものであり、順位のような確定値として扱わないことが前提です。

所感

Scale Basics編集部としては、この記事の要点は「AI検索対策の新しい施策」ではなく、既存のローカルSEOの延長線上にある作業の優先順位が変わったこと、そして計測の限界が公式ドキュメントの水準で確認できるようになったことだと考えています。llms.txt をGoogle検索が無視すること、コンテンツのチャンク分割が不要であることは、AI検索向けの作業として提案されがちな項目です。少なくともGoogleに関しては効果が期待できないと整理されている以上、その工数は「テキストとして読める形で情報を置く」「リスティングとサイトの記載を一致させる」といった、地味だが効く作業に振り向けるのが妥当でしょう。

計測については、期待値の調整を先にしておくことをおすすめします。生成AIパフォーマンスレポートはクエリを持たず、推薦されたのかソースとして並んだだけなのかも区別しません。この性質を理解せずに数値を社内やクライアントに報告すると、「表示回数は増えているのに問い合わせが増えない」という説明のつかない議論を招きます。表示回数は露出の指標、参照トラフィックはクリック後の指標、固定クエリ追跡は名指しの指標、と役割を分けて提示するほうが実務に耐えます。

一方で、記事が引いている数値の性質にも注意が必要です。Uberallの3〜5ブランドはQSR1業種のベンチマークであり、Whitesparkの15%／92%／97%は米国3都市・6業種・540クエリという条件下の結果です。日本の商圏やアシスタントの言語設定でそのまま再現される保証はありません。自社の主要クエリで実際に何が起きているかを、数十件でも自分の手で記録してから判断するのが確実です。エージェント対応については、アクセシビリティの改善はエージェントのためだけの投資ではなく、スクリーンリーダー利用者と検索エンジンの双方に効く作業です。優先度を上げやすい領域だと考えます。

まとめ

・AIアシスタントが候補の絞り込みを引き受けるため、顧客は事業者が管理するページに到達する前に短い推薦リストを見ている

・GoogleはAI機能を通常の検索と同じランキング／品質システムに根ざすものと説明し、回答生成にはRAG(グラウンディング)とクエリ・ファンアウトを用いると明示している

・UberallのQSRベンチマークでは1クエリあたり推薦は通常3〜5ブランド、Whitesparkの540クエリ検証ではAI Overviewsの出現率が直接型15%・情報型92%・ハイブリッド型97%だった

・Search Consoleの生成AIパフォーマンスレポートは表示回数をページ・国・デバイス・日付で示すが、クエリのディメンションがなく、推薦されたのかソースとして並んだだけかも区別せず、対象はGoogleのみ

・Google検索は llms.txt を無視し、コンテンツのチャンク分割も不要と明言。ブラウザエージェントはスクリーンショット・DOM・アクセシビリティツリーを解釈しうるとされ、フォームやボタンのラベル不足が新たな確認項目になる

よくある質問

Q1: AI検索向けに llms.txt を用意する必要はありますか?

Search Engine Journalの記事によると、Googleの最適化ガイドは、Google検索が llms.txt および類似のAI向けテキストファイルを無視すると明言しています。あわせて、GoogleのAIシステムに理解させるためにコンテンツを小さなチャンクに分割する必要もないとされています。少なくともGoogleに関しては、これらの作業より、重要な情報をテキストとして読める形で置くことやリスティングとの整合性の確保が優先されます。

Q2: Search Consoleの生成AIパフォーマンスレポートで、AI検索の順位は分かりますか?

分かりません。記事によれば、同レポートが数えるのはサイトへのリンクが生成AI機能に現れた表示回数で、ページ・国・デバイス・日付で内訳が見られる一方、クエリのディメンションがありません。さらに、自社が推薦された回答なのか、競合が推薦されて自社は下部のソースとして並んだだけなのかも区別されず、対象はGoogleのみでChatGPTやPerplexity、Claudeの回答は含まれません。

Q3: AIエージェントによる予約に備えて、サイト側で何を確認すべきですか?

記事はGoogleの説明として、ブラウザエージェントがレンダリング済みのスクリーンショット、DOM、そしてスクリーンリーダーが依拠するアクセシビリティツリーを解釈する場合があると紹介しています。そのためラベルのないdivで作られたボタン、プレースホルダーしか手がかりのないフォーム項目、画像内にしか存在しない電話番号は確認対象になります。Googleはこれらの欠陥がエージェントを止めると述べたわけではありませんが、予約・注文の動線が人手の介入なしに機能する状態を保つことが備えとして挙げられています。

出典:AI Assistants Are Choosing Local Businesses For Your Customers(Search Engine Journal、Matt G. Southern氏、2026年8月17日)https://www.searchenginejournal.com/ai-assistants-are-choosing-local-businesses-for-your-customers/585275/