Gemini SEO：情報源の検証と可視性の測り方

「Geminiで順位を上げる」という表現は一つの成果に聞こえますが、実際には複数の製品と観測結果を指し得ます。AIによる概要でリンクされる場合、AIモードで情報源として示される場合、Geminiアプリでリンクなしにブランド名だけが挙がる場合、出典がまったく表示されない場合があります。これらに共通する公開順位はありません。

実務上の目標は、秘密のランキング要因を探すことではありません。対象面を選び、固定した購買者質問をテストし、情報源を確認し、観測で裏づけられた問題だけを直す、再現可能なエビデンス・ループを作ることです。

Microsoftでも同じく対象面を先に分けますが、Bingの適格性、公開Webグラウンディング、Bing Webmaster Toolsの引用証拠はMicrosoft Copilot SEOガイドで確認してください。

Gemini SEOとは何か

Gemini SEOは、従来の検索基盤と回答単位の観測を組み合わせます。基盤整備によってページを発見・掲載候補にできる状態にし、回答の観測によって、明記した条件下で実際に利用・リンク・言及されたかを確かめます。

次の三つは分けて扱います。

• AIによる概要は、一部のGoogle検索結果内に表示され、回答を支えるWebページへのリンクを示すことがあります。
• AIモードは、関連する検索へクエリを展開しながら、補足リンクを提示する対話型のGoogle検索体験です。
• Geminiアプリは独立したアシスタント体験です。回答、機能、情報源の表示、パーソナライズはGoogle検索と異なる場合があります。

Googleの公式ガイダンスによれば、検索の生成AI機能は中核となる検索ランキングと品質システムに基づいています。また、AI専用の特別なマークアップは不要です。つまり、堅実なSEOは必要ですが、要件を満たしても回答への採用は保証されません。

混同してはいけない二つの層

第1層：Google検索での掲載適格性

AIによる概要とAIモードでは、通常の検索結果と同じ基礎項目から確認します。

• URLは正常なレスポンスを返すか。
• Googlebotがページと重要なリソースにアクセスできるか。
• レンダリング後のHTMLに、利用者が読む回答が存在するか。
• 意図した正規URLが指定されているか。
• 意図しないnoindex、スニペット制限、重複版がないか。
• 有用な内部リンクとサイトマップから到達できるか。

Googleは、検索の生成AI機能に表示されるには、ページがインデックスされ、スニペット付きの検索結果として表示可能である必要があると説明しています。これらを満たすのは候補になるためであり、AI回答への掲載を約束するものではありません。

第2層：回答での実際の選択

次に回答そのものを調べます。プロンプト全文、対象面、言語、市場、日付、ログイン状態、回答本文、表示された全情報源URLを保存し、結果を次のように分類します。

1. 自社ページへのリンクがある。
2. ブランド名はあるが、自社リンクはない。
3. 第三者ページがブランド説明に使われている。
4. 競合は含まれるが、自社ブランドはない。
5. 関連する回答がない、または収集に失敗した。

収集失敗を「表示されなかった」と数えてはいけません。出典マーカーが近くの文章すべてを裏づけるとも限りません。リンク先を開き、主張を支える箇所、または支えられない箇所を確認します。

集計前にGeminiの情報源を検証する方法

GoogleのGeminiアプリのヘルプによると、すべての回答にリンクがあるわけではなく、情報源欄には公開Webや接続した個人資料などの関連コンテンツも含まれます。表示ラベルと文脈を保存してください。リンクの表示は一つの観測であり、取得処理の完全な記録でも、ページが回答の主張を裏づける証明でもありません。

以下は編集レビュー用ワークシートです。AEO Mantisの採点式を示すものではありません。新しい会話で公開Webの質問をテストし、アップロードしたファイルや接続済みの業務文書を公開情報の発見性の基準値に混ぜないでください。意図的に個人化したテストは別のコホートにします。

情報源ごとに、次を記録します。

1. 実行の識別： プロンプト全文と直前の会話、対象面、言語・市場、時刻、アカウントの文脈、収集の成否。
2. 表示された根拠： 保存した回答、リンクのラベルと位置、元URL、最終到達先、自社か第三者か。関連リンクや分類不明のリンクは、情報源として明示されたリンクと分けます。
3. 主張の確認： 回答の具体的な文、ページの該当箇所、明確な支持・部分的な支持・矛盾・不明の判定。アクセスできないページは不明であり、合格ではありません。
4. 判断： 範囲を限定した施策、担当者、受け入れ確認の根拠、再テスト条件。これは人による判断です。回答を保存するだけでは確認は完了しません。

情報源レビューの例：リンクと検証済みの主張を分ける

以下は説明用の観測例であり、Geminiの実測や顧客の結果ではありません。 同じ公開Webプロンプト群で完全な回答を3件収集し、収集失敗を1件別に記録したとします。

このワークシートの規則では、観測した自社リンク率は 成功回答3件中1件（33.3%） で、失敗1件は別記します。唯一の自社リンク付きの主張は、裏づけの確認に合格していません。33.3%や情報源ラベルは、正確な推薦、1位、訪問獲得を意味しません。同じ自社URLが一つの回答に2回出ても、リンクの有無は回答ごとに1回だけ数えます。各マーカーは該当箇所の確認用に残します。

検証した公開URLと保存した主張を次回も参照できるようにします。変わったのが画面や収集方法だけなら、比較条件の変更を注記し、新しい数値をコンテンツ改善の成果として示さないでください。

計画から外すべき四つのGemini SEO神話

神話1：Google-ExtendedがAIによる概要を制御する

Google検索へのアクセスと、モデル利用に関する制御は別の方針です。Googleの検索ガイダンスでは、AIによる概要とAIモードは検索インデックスから情報を取得すると説明されています。そのため、この二つの検索面ではGooglebotによるクロールとインデックス登録の適格性が技術的な基準になります。根拠なしに学習・モデル利用の設定を変えて、検索での可視性問題を診断してはいけません。

Google-Extendedは別の検索クローラーでも、Google検索のランキングシグナルでもありません。Googleの説明では、将来のGemini学習と、Geminiアプリおよび指定されたVertex AIサービスのグラウンディングを対象とするコンテンツ利用トークンです。その方針は別に検討し、検索面の規則をすべてのGemini製品へ当てはめないでください。

神話2：AI専用schemaで掲載を保証できる

Googleは、検索の生成AI機能に構造化データは必須ではなく、専用schemaもないと説明しています。表示内容と一致する正しい構造化データは、通常の検索機能や事実の明確化には役立ちますが、引用を保証しません。品質管理の一層として扱います。

神話3：llms.txtでGoogle AIの順位が上がる

Googleは、Google検索とその生成AI機能でllms.txtを使用しないと明記しています。他の利用者やサービス向けに維持することはできますが、Gemini検索への近道ではありません。まずクロール可能性、インデックス、役立つ内容、検証可能な根拠を整えます。

神話4：一度の成功回答で順位を証明できる

回答は、表現、市場、言語、時点、アカウント状態、製品変更で変わり得ます。一つの引用は保存された一回の観測です。傾向を示すには、固定プロンプト、成功実行数の分母、保存した情報源、反復測定が必要です。

7ステップのGemini SEOワークフロー

ステップ1：対象面と意思決定を定義する

「3人の代理店に合うAI可視性プラットフォームを選ぶ」といった購買タスクから始めます。AIによる概要、AIモード、Geminiアプリのどれを調べるか決めます。複数を扱う場合は、一つの平均点にせず、面ごとに列を分けて報告します。

ステップ2：小さな購買者プロンプト群を作る

営業会話、サポート問い合わせ、製品比較、反対意見から実際の質問を集めます。カテゴリ探索、評価、導入、リスク、ブランド事実確認をバランスよく含めます。誰も確認できない数百件より、精査できる10件のほうが役立ちます。

文言はそのまま保存します。追加質問は会話経路の一部なので、直前のやり取りも記録します。

ステップ3：技術的な適格性を確認する

新しいURLを作る前に、各購買タスクに最も近い既存ページを調べます。レスポンス、レンダリング、正規URL、robots、インデックス適格性、内部導線、モバイル表示、コンテンツの同等性を確認します。既存ページが同じタスクに答えるなら、類義ページを増やさず、そのページを改善します。

ステップ4：情報源として使う価値を作る

各節は直接の答えから始め、証拠、適用範囲、限界を続けます。役立つ根拠には次があります。

• 最新の一次資料。
• 入力と出力が明確な手順。
• 日付とサンプルを示した観測。
• 例示であることを明記した実例。
• 評価基準を説明した比較。
• 事実が変わったときの明確な訂正方法。

クエリの展開をまねる目的だけで、キーワード違いのページを増やしてはいけません。Googleは、表現ごとの量産より、独自性があり人の役に立つコンテンツを推奨しています。

ステップ5：比較可能な基準値を保存する

条件を定義してプロンプト群を実行します。回答全文、表示された情報源、ブランドの有無、自社リンクの有無、競合の推薦状況を保存します。失敗した実行は別に記録します。

Google検索面では、プロパティとデータが利用できる場合、Search Consoleの生成AIレポートを使います。このレポートはAIによる概要やAIモードなどの検索機能を対象とし、独立したGeminiアプリの測定値として扱うものではありません。

ステップ6：確認できた最も弱い層を診断する

各未掲載を、一つの主因に分類します。

• アクセスまたはインデックス適格性。
• 検索意図との不一致。
• 事実の不足、または検証不能。
• ブランド・製品情報の不整合。
• 競合に関する第三者の裏づけが強い。
• 診断するには証拠不足。

「証拠不足」は正当な結論です。ランキング要因を作り上げるより安全です。

ステップ7：一つだけ変えて再確認する

一つの製品事実を明確にする、既存ページを一つ強化する、正規URLの問題を一つ直す、文脈に合う内部リンクを一つ追加する、といった最小限の有用な修正を行います。同じプロンプトを近い条件で再実行し、新しい回答と情報源を保存します。

結果の変化は動きの証拠ですが、修正が原因だと自動的に証明するものではありません。観測の間に、検索システム、情報源、製品挙動も変わる可能性があります。

実例：対象面を分けて観測する

以下は説明用の例です。 あるB2B分析企業が、米国英語の購買者プロンプトを12件追跡します。AIモードでは12件、Geminiアプリでは11件の回答収集に成功しました。AIモードは3件で自社ドメインにリンクし、Geminiアプリは4件でブランド名を挙げましたが、自社情報源が表示されたのは1件だけでした。

チームは「Gemini可視性29%」とは報告しません。AIモードの自社リンク率を3/12、Geminiアプリのブランド言及率を4/11、自社情報源ありを1件と分けます。情報源を確認すると、競合を含む二つの回答が、古いエクスポート上限を記載した比較ページに依存していました。

次の施策はschema追加ではありません。既存のエクスポート資料に、検証済みの上限、改訂日、例を追加し、関連する自社ヘルプページからリンクします。次回も同じプロンプトと対象面を維持します。因果を支える追加証拠が得られるまでは、変化を観測として記録します。

Gemini SEOを誠実に測る方法

分母を明示した別々の指標を使います。

• 言及率： ブランド名がある成功回答 ÷ 成功回答。
• 自社リンク率： 自社ページへのリンクが一つ以上ある成功回答 ÷ 成功回答。
• プロンプト網羅率： 自社リンクがある対象プロンプト ÷ 収集に成功した対象プロンプト。
• 検索生成AIでの表示回数： Search Consoleが報告する、対応するGoogle検索生成AI機能でリンクが表示された回数。
• 参照流入の成果： 分析ツールでGeminiまたはGoogle由来と判断されたセッションと主要イベント。
• コンバージョン成果： それらのセッションから生じた有効な行動。ラストクリックだけを全行程とはみなしません。

横断的な指標設計にはAI検索での可視性指標を、情報源中心の回答エンジンで同じ検証原則を使う場合はPerplexity SEOを参照してください。