なぜGoogle Search LiveでSEOは終わるのか。AI開発とGEO完全ガイド

Google Search Liveが全言語・全ロケーションに展開された。200以上の国と地域で、カメラと音声を使ったリアルタイムAI検索が使えるようになった。

これ、地味にやばい。

「検索」という行為が「タイプする」から「話す・見せる」に変わる。ユーザーはWebサイトを訪問しなくなる。

ゼロクリック・ファンネルという現象が起きている。AIが回答を完結させ、ユーザーがサイトに来る前に選別が終わる。

開発者として「AIに攻める」と「AIから守る」の両輪を考える。

Google Search Liveとマルチモーダル検索の現在地

Google Search Liveは、AIモードで動作するリアルタイムのマルチモーダル対話機能だ。AndroidとiOSのGoogleアプリから使える。

ユーザーはテキストを打たずに「声で質問」して「AIの音声回答」を受け取る。カメラをオンにすれば、目の前にある棚の組み立て方や街中の看板について質問できる。

Google Lensからもアクセス可能だ。カメラで何かを映しながらそのままLiveモードに切り替えられる。

この展開を支えているのが、新しい音声モデル「Gemini 3.1 Flash Live」だ。多言語に対応し、ユーザーが母国語で自然に話しかけられる設計になっている。

一方、フランスのAI企業Mistralも音声AIの領域で動いた。オープンソースのテキスト読み上げモデル「Voxtral TTS」をリリースした。

9言語（英語・フランス語・ドイツ語・スペイン語・オランダ語・ポルトガル語・イタリア語・ヒンディー語・アラビア語）に対応する。5秒未満のサンプル音声からカスタムボイスを生成できる。

パフォーマンスの数字を見る。TTFA（最初の音声が出るまでの遅延）は90msだ。

RTF（リアルタイムファクター）は6倍だ。10秒の音声を約1.6秒で生成する。

エッジデバイス（スマートウォッチ・スマートフォン・ラップトップ）でも動作する軽量設計だ。ベースモデルはMinistral 3Bを採用している。

Mistralの狙いは、音声認識・テキスト読み上げ・マルチモーダル処理を一気通貫で提供するプラットフォームを作ることだ。ElevenLabs・Deepgram・OpenAIとの直接競合になる。

企業のBtoB情報収集はGoogle検索からAI検索へ移行している。ユーザーはサイトを訪問せずにAIの回答だけで意思決定する。

これがゼロクリック・ファンネルと呼ばれる現象だ。

しんたろー：
Googleは「AIとの会話からWebリンクへ深く潜れる」とアピールしてる。でも実際のWebサイト運営者が体感してるのは「ユーザーが来ない」だ。
プラットフォーム側とパブリッシャー側でトラフィックの認識がズレてる。このギャップ、開発者として両方の立場で見てると笑えない。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

攻めと守りのAI実装

音声UIのサービス組み込み

Voxtral TTSのオープンソース化は、開発者にとっての選択肢を広げる。

ElevenLabsのAPIは高い。OpenAIのTTSもコストがかかる。

Mistralのオープンソースモデルにより、音声対話UIの実装コストが下がる。

具体的な変化は以下の通りだ。

• カスタマーサポートの音声自動化：5秒の音声サンプルでブランドボイスを生成できる
• 多言語対応の音声エージェント：言語切り替え時に声の特徴を維持できる
• エッジデバイス展開：クラウドAPIに依存せずスマートフォン上で動作する

TTFA 90msは、人間の会話テンポに追いつくレベルだ。電話口で「少々お待ちください」と言わなくていい。

ただし、まだ手元で動かしていないので「気になる」レベルだ。エッジ動作の実装コストは、実際に触ってみないとわからない。

AIに読まれるサイト構造（GEO）

AIが検索を支配する環境では、AIクローラーがサイトをどう読むかがトラフィックを決定する。

従来のSEOは「Googleアルゴリズムを攻略する」ゲームだった。GEO（Generative Engine Optimization）は「LLMに引用元として選ばれる」ゲームだ。

AIは「コンセンサス」を探す。複数の独立したサイトで一貫して言及されている情報を「世の中の事実」として認識する。

自社の情報がWeb上で薄かったり矛盾していると、AIは回答から除外する。

技術的な変化は3つある。

1. セマンティックHTMLへの回帰

divスパゲッティは終わる。AIクローラーはHTMLの構造を直接読む。

「div class="content"」の中に「div class="title"」があっても、AIには文脈が読めない。article・h2・pの正しい構造で書かれたページは、AIの回答にそのまま引用される確率が上がる。

2. FAQスキーマの実装

AIは「質問と回答」の対応関係を好む。schema.org/FAQPageの構造化データを実装し、AIが回答を生成するときのテンプレートとして機能させる。

箇条書き（ul・li）も要約として引用されやすい。

3. llms.txtの配置

robots.txtが検索エンジンクローラーへの指示ファイルなら、llms.txtはAIクローラーへの指示ファイルだ。サイトのルートディレクトリに置く。

Markdown形式で「このサイトは何についてのサイトか」「重要なデータはどこにあるか」「何について書かれていないか」を記述する。2025年後半から主要AIプロバイダーが参照を開始しており、実装の有無が引用率に差を生む。

これらの作業はClaude Codeが得意な領域だ。既存サイトのHTMLをセマンティック構造に一括リファクタリングするタスクを任せられる。

サイトのコンテンツを解析してllms.txtのドラフトを生成するタスクも、Claude Codeに投げると効率が違う。ThreadPost開発でも、コンテンツ構造の見直しをClaude Codeと一緒に考えることが増えてきた。

しんたろー：
divスパゲッティのリファクタリング、「いつかやろう」案件の筆頭だった。GEO対応という理由ができたので、Claude Codeに「このHTMLをセマンティック構造に直して」と投げた。
思ったより早く終わりそうな気がしてる。やってみるか。

実務への影響と優先度

全AIボットを同じように扱うのは機会損失だ。Google-Extended（Google検索・Gemini連携）、GPTBot（ChatGPT）、ClaudeBot（Anthropic Claude）、PerplexityBotは、それぞれ特性が違う。

Google-ExtendingはGeminiとの連携で検索順位にも影響する。ClaudeBotは技術・ホワイトペーパー系コンテンツとの親和性が高い。

Perplexityはリアルタイム性重視でニュース系コンテンツを好む。自社サービスの性質に合わせてボット別のアクセス制御を設計する。

AIは単一サイトの情報より、複数の独立したサイトで一貫して言及されている情報を信頼する。自社サービスの情報が他のサイトに正確に掲載されているかを確認する。

矛盾した情報（価格・機能・会社概要）が散在していると、AIは回答から除外する。

Google Search Liveが200カ国に展開されたことで、音声で質問されたときに引用されやすいコンテンツが求められる。

音声検索の回答は短い。40〜50語程度の明確な回答が冒頭に来るコンテンツ構造が、音声AIに引用されやすい。

長い前置きや「〜については諸説ありますが」系の書き方は音声回答には向かない。

優先度の整理は以下の通りだ。

1. llms.txtをルートに配置（実装コスト：低）
2. FAQスキーマを主要ページに追加（実装コスト：中）
3. robots.txtをボット別に再設計（実装コスト：低）
4. HTMLのセマンティック構造確認（実装コスト：高・Claude Codeで効率化可能）

Mistral Voxtral TTSを使った音声UI実装は、コスト面での優位性が確認できたら検討する。まずTTFA 90msの実際の体感を試してみたい。

しんたろー：
llms.txtは「ファイル1個置くだけ」なのにまだやってないサイトが多い。実装コストほぼゼロで引用率に差が出るなら、今週中にやらない理由がない。
ThreadPostのサイトも今週確認する。

よくある質問

Q. llms.txtとは何ですか？どのように実装すればよいですか？

llms.txtは、AIクローラーに対して「このサイトの情報をどう解釈すべきか」を直接指示するMarkdown形式のファイルだ。サイトのルートディレクトリ（例：example.com/llms.txt）に配置する。

記述内容は3つある。「何についてのサイトか」（サービス概要・専門領域）、「重要なデータはどこにあるか」（サービス比較表・導入事例・用語集へのリンク）、「何について書かれていないか」（スコープ外の領域を明示）だ。

2025年後半から主要AIプロバイダーが参照を開始している。ChatGPTやPerplexityなどのAI検索で自社情報が正確かつ優先的に引用される確率が上がる。

実装コストはほぼゼロだ。robots.txtと同じ感覚で置ける。

Q. MistralのVoxtral TTSのパフォーマンスは実務に耐えうるレベルですか？

数字で見ると実用的だ。TTFA（最初の音声が出るまでの遅延）は90msを記録している。

これは人間が「返答が遅い」と感じるラインより速い。RTF（リアルタイムファクター）は6倍で、10秒の音声を約1.6秒で生成する。

5秒未満のサンプル音声でカスタムボイスを生成できる。言語切り替え時も声の特徴（アクセント・抑揚・間の取り方）を維持する。

ベースモデルがMinistral 3Bという軽量設計だ。スマートフォンやスマートウォッチ等のエッジデバイスでも動作する。

カスタマーサポートの音声自動化や多言語対応の音声エージェント構築において、既存の有料APIと比較してコストが下がる。オープンソースなので自社環境でのチューニングも可能だ。

Q. AI検索の普及で、従来のSEO対策は無駄になりますか？

完全に無駄にはならないが、アプローチを変える。

従来型SEOは「キーワード出現率と被リンクでGoogleアルゴリズムを攻略する」ゲームだった。GEO（Generative Engine Optimization）は「LLMに信頼できる引用元として選ばれる」ゲームだ。

具体的な変化点は3つある。セマンティックなHTML構造（divスパゲッティからarticle・section・h2への回帰）、FAQスキーマの実装（AIが回答テンプレートとして利用）、llms.txtの配置（AIクローラーへの直接指示）だ。

AI検索で引用されないことは、存在しないことと同じになる。SEOとGEOを並行して走らせる。

まとめ

200カ国でカメラと音声の検索が始まった。Mistralが90ms遅延の音声モデルをオープンソースで出した。

SEOが終わるというより、ゲームのルールが変わった。

llms.txtを置く。HTMLをセマンティックにする。

FAQスキーマを入れる。実装コストが低い順にやっていけば、AI検索時代の守りは整う。

攻めの音声UI実装は、Voxtral TTSを試してから判断する。Claude Codeでセマンティックリファクタリングを効率化しながら、GEO対応を進めていく。

---

👉 ThreadPostでSNS運用を自動化する