- はじめに——測るものが「引用された○×」から「回答内のシェア」へ変わった
- なぜ「引用された○×」では足りないのか——AEOからGEO計測へ
- 計測指標の3層整理（SEO／AEO／GEO）と、Share of Modelの定義
- プロンプトセットの設計——自社が”definitively”答えるべき15問の作り方
- エンジン別の計測手順——ChatGPT・Gemini・Perplexity・AI Overviewと手動verifyの限界
- AIクローラーのサーバーログ解析——識別できる範囲と、その限界
- 監視スタックの設計——ベースライン→ドリフト検知→アラート（NOC流）
- センチメントと競合シェアのダッシュボード化
- 月次レポートテンプレート
- よくある質問（Q&A）
- まとめ——presenceは「測れないものは改善できない」
- 参考リンク
はじめに——測るものが「引用された○×」から「回答内のシェア」へ変わった
これまでのAEO（Answer Engine Optimization）の効果測定は、突き詰めれば「自社がAIの回答に引用されたか／されなかったか」という二値に集約されてきました。AEO効果測定の記事でも、その○×をPDCAで回す思想を扱っています。しかし2026年、計測の前提そのものが変わりつつあります。問いは「引用されたか」ではなく、「AIの回答という限られた紙面の中で、自社がどれだけの割合（シェア）を占めているか」へ移りました。これが本記事の主題であるシェア・オブ・モデル（Share of Model）です。
背景には、検索の地殻変動があります。GEO専門企業Brandlightの調査では、Googleの上位リンクとAIが引用するソースの重複は、かつての約70%から20%未満まで落ち込んでいると報告されています。「Google1位＝AIでも引用される」という長年の前提が崩れ、AI上の可視性はGoogle順位とは独立した、もう一つの計測層になったということです。順位を測っても、AIの回答内での存在感はわからない——だからこそ、専用の計測スタックが要ります。
筆者はネットワークのNOC/TAC（運用センターとテクニカルアシスタンスセンター）で長年、トラフィックの平常ベースラインを学習し、その逸脱を監視・アラートする仕事に携わってきました。本記事の核心は、そのNOC流のObservability（可観測性）の発想が、そのままブランドのAI上の存在感（presence）の監視に転用できるという点にあります（Observability設計の記事の考え方をブランド計測へ応用します）。エンジン別・競合別の占有率ドリフトを継続監視する——これは監視運用そのものです。
想定読者は、AEO施策を打ち始めたものの「効いているのか」を経営に数字で示せない、あるいは競合との差を定量化したいマーケティング・広報・経営企画の方々です。連載第2回の効果測定思想のAEO版を求める読者にも、本記事はその続きとして読めるよう設計しています。
なぜ「引用された○×」では足りないのか——AEOからGEO計測へ
「引用された／されない」の二値には、3つの致命的な欠落があります。
1. 競合との相対が消える。自社が引用されていても、同じ回答内で競合5社がより詳しく言及されていれば、ユーザーの選択肢の中で自社は埋もれています。○×は単体ブランド視点であり、回答という「土俵」の上での占有率を捉えられません。
2. 文脈（センチメント）が消える。引用されていても、それが「価格は高いが」「サポートに難あり」という否定的文脈であれば、可視性はむしろ逆効果です。2026年6月のBurson×Profoundの調査も、可視性と信頼性は別物であり、回答に登場しても信じられなければ意味がないと指摘しています。○×にはセンチメントの軸がありません。
3. 時系列とドリフトが消える。AIの回答は同じ質問でも日によって揺れます。ある日の○×はスナップショットにすぎず、傾向（じわじわ競合に押されている、特定エンジンで急に出なくなった）を捉えられません。NOCで言えば、瞬間のping応答だけ見てトラフィックの傾向を語るようなものです。
GEO（Generative Engine Optimization）は、AEOを包含しつつ、シェア・オブ・モデル、センチメント管理、引用権威性、ナラティブ制御へと広がる上位概念です。AEOが「回答に入るための最適化」なら、GEO計測は「回答内でどう・どれだけ存在しているかの定量化と監視」です。本記事は、AEO効果測定（○×のPDCA）の一段手前にある”presenceの定量化と監視システム化”に特化します。
計測指標の3層整理（SEO／AEO／GEO）と、Share of Modelの定義
混乱を避けるため、計測指標を3層に分けて整理します。それぞれ「何を見ているか」が異なり、置き換え可能なものではありません。
| 層 | 主な指標 | 見ているもの | NOC的なたとえ |
|---|---|---|---|
| SEO | 検索順位・流入・インプレッション | 従来検索での到達性 | リンク帯域・到達経路 |
| AEO | 言及の有無・引用回数・AI Overview出現・ゼロクリック表示シェア | 回答に入れたか（○×） | サービスの死活監視（up/down） |
| GEO | Share of Model・ブランド言及シェア・ドメイン影響度・センチメント分布 | 回答内での占有率と文脈 | トラフィック占有率・品質メトリクスの監視 |
シェア・オブ・モデルの定義はシンプルです。あるカテゴリの質問群をAIに投げたとき、自社が言及される割合を、競合を含めた全言及の中での比率として測ったものです。たとえば100個の関連質問のうち、自社が30回、最大の競合が25回言及されていれば、自社のシェアはその分だけ高い、という相対指標になります。これをエンジン別×競合別×時系列で測ることで、初めて「回答という土俵での自社の位置」が数字になります。
実務上、経営に最初に見せるべき数字は多くても5つに絞るのが定石です。(1) 総合AI可視性スコア（90日トレンド付き）、(2) 主要カテゴリ別の上位3競合とのシェア・オブ・モデル比較、(3) センチメント分布、(4) エンジン別の出現率、(5) 主要質問群でのカバレッジ。残りはドリルダウン用です。
プロンプトセットの設計——自社が”definitively”答えるべき15問の作り方
計測の精度は、測定対象の「質問セット（プロンプトバンク）」の質でほぼ決まります。ここが雑だと、その後のダッシュボードがどれだけ綺麗でも誤った結論を導きます。NOCで言えば、監視対象のメトリクスを間違えれば、いくら高機能な監視基盤を組んでも意味がないのと同じです。
質問セットは、自社が”definitively”（決定的に）答えるべき質問から設計します。これはAEOのクエリリサーチで発見した「実際にAIに聞かれている質問」を、計測用に絞り込んだものです。設計のステップは次の通りです。
- カテゴリを定義する：自社が勝ちたい領域を3〜5カテゴリに分ける（例：機能比較／価格／導入事例／信頼性）。カテゴリを混ぜると、シェアの良し悪しの原因が特定できなくなります。
- 各カテゴリ3〜5問、計15問前後に絞る：多すぎると手動verifyが破綻し、少なすぎると揺らぎに埋もれます。まずは15〜50問でベースラインを取り、安定運用に乗ったら拡張します。
- 「指名なし」質問を中心にする：「○○（自社名）はどう？」ではなく「××のおすすめツールは？」のように、ブランドを指名しない質問でこそ真のシェアが測れます。指名質問は別枠で管理します。
- 意図の幅を固定する：同じ質問を時系列で繰り返すため、文言は固定します。文言が揺れると、シェアの変動が施策の効果なのか質問の差なのか切り分けられません（NOCで監視項目の定義をコロコロ変えないのと同じ規律です）。
重要なのは、質問セットを”監視の構成定義（コンフィグ）”として版管理することです。いつ・なぜ質問を追加／変更したかを記録し、ベースラインとの比較可能性を守ります。
エンジン別の計測手順——ChatGPT・Gemini・Perplexity・AI Overviewと手動verifyの限界
各エンジンは「性格」が異なります。同じ質問でも引用元の傾向がまったく違うため、横並びの単一指標で語るとミスリードになります。エンジンごとの癖を踏まえて測ります。
| エンジン | 引用の癖（傾向） | 計測上の注意 |
|---|---|---|
| ChatGPT | 百科事典的バイアス。Wikipediaなど権威ソースへの偏りが強い。リンクなしのブランド言及も多い | 「リンク引用」だけ数えると過小評価になる。テキスト中の言及も拾う |
| Gemini | 独自ロジックが強く、Google順位との相関が低い。応答の揺らぎが大きい | サンプル数を増やさないと揺らぎに埋もれる |
| Perplexity | ライブ検索型でソース提示が積極的。コミュニティ（Reddit等）への依存が高い | 従来検索に最も近いが、コミュニティでの存在感がそのまま効く |
| Google AI Overview | Googleが上位表示する内容の要約寄り。ただし上位10件との重複は急低下中 | 従来SEOの貯金が部分的に効くが、過信は禁物 |
手動verifyの限界を正しく認識することが、運用設計の分かれ目です。同じ質問を手で何度も叩いて記録するのは、(1) 応答が確率的に揺れるため少数試行では代表性がない、(2) 人手では頻度・継続性を保てない、(3) ログイン状態・地域・パーソナライズで結果が変わる、という3点で破綻します。これはNOCで「人が画面を目視で監視し続ける」運用が必ず限界を迎えるのと同じ構図です。
したがって現実解は、初期のベースライン構築と抜き取り検証は手動、定常監視はツール化という二段構えです。市場には複数エンジンを横断してシェア・オブ・モデル、センチメント、競合比較を測る専用ツール群（Profound、Otterly、Similarweb、各種AI可視性トラッカー等）が登場しており、まずはこの計測層を持つこと自体が、まだ少数派の競争優位になります。ある2026年の調査では、AI可視性をトラッキングしているマーケターは14%程度にとどまると報告されています。
AIクローラーのサーバーログ解析——識別できる範囲と、その限界
ツールに頼る前に、自社のサーバーログという一次データを使う手があります。AI各社のクローラー（学習・検索用ボット）が自社サイトのどのページを、どれだけ巡回しているかは、ログのUser-Agentから部分的に識別できます。これはNOCのアクセスログ解析そのもので、筆者が最も得意とする領域です。
識別できること：主要なAIクローラーのUser-Agent別アクセス頻度、巡回されているページとされていないページの偏り、robots.txtやペイウォールでブロックしているクローラーの有無。「AIに引用されたい記事が、そもそもクロールされているか」という最も基本的な前提を、ここで検証できます。
一方で、限界も明確です。(1) User-Agentは詐称可能であり、すべてのAIアクセスを正確には捕捉できません。(2) クロールされた＝引用される、ではありません。巡回は必要条件であって十分条件ではない。(3) AIからの流入の大半はリファラーが欠落します。ある2026年の分析では、AI起点のトラフィックの7割前後がリファラーヘッダーを持たず、標準的なアナリティクスでは見えないと報告されています。つまりサーバーログは「入口（クロール）」の検証には強いが、「出口（回答内シェア）」の計測は別の層で補う必要があります。コンバージョン・アトリビューションの記事で扱う流入後の成果計測とも、ここで線引きが要ります。
監視スタックの設計——ベースライン→ドリフト検知→アラート（NOC流）
ここからが本記事の中核です。単発の計測を「監視運用」へ昇華させます。NOCの異常検知の鉄則は、平常時のベースラインを学習し、その逸脱（ドリフト）を検知し、段階的にアラートする——この3段構えです。これをブランドのAIプレゼンスにそのまま適用します。
ステップ1：ベースラインの学習
固定した質問セットを、複数エンジンで一定期間（最低4週間が目安）繰り返し測り、エンジン別・競合別のシェアの「平常域」を確立します。応答は揺れるため、単発値ではなく分布（平均と幅）でベースラインを持つのが要点です。瞬間値で一喜一憂しないための土台になります。
ステップ2：ドリフト検知
ベースラインからの逸脱を継続的に見ます。見るべきドリフトは主に3種類です。
- 自社シェアの低下：特定エンジン・特定カテゴリで自社の占有率がベースライン下限を割り込む。
- 競合シェアの急増：特定競合が短期間でシェアを伸ばしている（新コンテンツ投入や被引用増の兆候）。
- センチメントの悪化：言及はされているが文脈が否定方向へ振れている。
ステップ3：段階的アラート（観測→警告→緩和→対応）
過剰反応は運用を疲弊させます。NOCのインシデント対応と同じく、閾値に応じた階段を設計します。
| 段階 | 条件の例 | アクション |
|---|---|---|
| 観測 | シェアが平常域 | 記録のみ |
| 警告 | シェアが下限近辺、または競合が上振れ | ダッシュボードにフラグ、担当へ通知 |
| 緩和 | 2週連続で下限割れ | 対象カテゴリのコンテンツ点検・更新トリガー |
| 対応 | 主要カテゴリで明確なシェア喪失 | 原因分析（被引用ソースの変化）・施策投入・経営報告 |
AIの被引用は鮮度の影響が大きく、更新のないコンテンツは十数週でAI引用頻度が落ちるとの報告もあります。新規コンテンツが数日でAIの引用候補に入る一方、Google順位は数ヶ月かかるという速度差も踏まえ、監視サイクルは月次より短く設計するほうが現実的です。
センチメントと競合シェアのダッシュボード化
計測値は、見られる形にして初めて運用に乗ります。ダッシュボードは「経営が3秒で判断できる上段」と「担当が原因を掘れる下段」の二層で設計します。
- 上段（サマリー）：総合AI可視性スコアの90日トレンド、主要カテゴリ別の対競合シェア（自社vs上位3社）、センチメント分布（肯定／中立／否定）。数字は5つ以内に絞る。
- 下段（ドリルダウン）：エンジン別の内訳、質問単位のシェア、被引用ソースの一覧（どのドメインが自社の代わりに引用されているか）、時系列の生データ。
競合分析については、「なぜ競合が推薦されるのか」という定性分析は競合分析の記事に、否定的言及への対応（レピュテーション）はレピュテーション管理の記事に接続します。本記事のダッシュボードは、その定性分析を起動する「どこを見るべきか」のアラート装置という位置づけです。占有率の数字が「異常」を示し、定性分析が「原因」を突き止める——この役割分担が、計測を施策につなげる勘所です。
月次レポートテンプレート
監視スタックの出力を、定型レポートに落とし込みます。毎月同じ構成で出すことで、傾向（trend）が読めるようになります。
- 1. サマリー：総合AI可視性スコアと前月差、最大の良化／悪化トピック1件ずつ。
- 2. シェア・オブ・モデル：カテゴリ別・エンジン別の自社シェアと、上位3競合との比較表。
- 3. センチメント：肯定／中立／否定の分布と、否定文脈の代表例。
- 4. ドリフト＆アラート：当月発報したアラートと、その原因・対応状況。
- 5. 被引用ソースの変化：自社の代わりに引用が増えたドメイン（＝今後狙うべき場所）。
- 6. 次月アクション：シェア低下カテゴリへのコンテンツ施策。
このレポートは、AEO群の各施策（クエリリサーチ→コンテンツ投入→効果測定）の成果を、経営の言葉である「占有率」と「対競合」で束ねる結節点になります。
よくある質問（Q&A）
Q1. AEOの○×測定（引用された／されない）はもう不要ですか？
不要ではありません。○×は「回答に入れたか」という死活監視として今後も基礎であり続けます。シェア・オブ・モデルは、その上に重ねる「回答内でどれだけ・どんな文脈で存在しているか」の層です。死活監視（up/down）とトラフィック占有率の監視を両方持つのと同じで、片方では不十分というのが本記事の主張です。
Q2. 手動で各AIに質問して記録するだけでは不十分ですか？
初期のベースライン構築や抜き取り検証には有効ですが、定常監視には不向きです。AIの応答は確率的に揺れるため少数試行では代表性がなく、人手では頻度・継続性も保てません。ログイン状態や地域でも結果が変わります。初期は手動、定常はツール化という二段構えが現実解です。
Q3. 計測ツールは必須ですか。自前でどこまでできますか？
自前でできるのは主にサーバーログ解析（AIクローラーの巡回状況）です。これは「引用されたい記事がクロールされているか」という入口の検証に強い。一方、複数エンジン横断の回答内シェアやセンチメントを継続計測するのは人手では限界があり、専用ツールの導入が現実的です。まずはログ解析で入口を固め、出口の計測をツールで補う順序を推奨します。
Q4. シェア・オブ・モデルが下がったら、まず何をすべきですか？
原因の切り分けが先です。(1) どのエンジン・どのカテゴリで下がったか、(2) 自社の代わりに何が引用されるようになったか（被引用ソースの変化）、(3) センチメントは悪化していないか。この3点を見てから、競合分析やコンテンツ更新といった施策に進みます。数字は「異常」を示すだけで、原因は定性分析が突き止めます。
Q5. Google検索順位を上げれば、AIの回答でも有利になりますか？
かつてはそうでしたが、現在は前提が崩れています。Googleの上位リンクとAIが引用するソースの重複は約70%から20%未満まで落ちたとの調査があり、Google1位がAI引用を保証しなくなりました。Google AI Overviewには従来SEOの貯金が部分的に効きますが、ChatGPTやGeminiは独自ロジックで動きます。だからこそ、SEO順位とは独立した計測層が必要になります。
まとめ——presenceは「測れないものは改善できない」
AEOの議論は長らく「引用されるための最適化」に集中してきました。しかし2026年、計測の前提は「引用されたか（○×）」から「回答内でどれだけ・どんな文脈で存在しているか（シェア・オブ・モデル）」へ移っています。要点は3つです。
1. ○×では競合・文脈・傾向が消える。回答という土俵の上での占有率、センチメント、時系列ドリフトを測って初めて、AI上の存在感を経営の言葉で語れます。
2. 計測は監視運用として設計する。固定した質問セットでベースラインを学習し、ドリフトを検知し、段階的にアラートする——これはNOC/TACのObservabilityそのものです。瞬間値ではなく分布と傾向で見るのが鉄則です。
3. 入口（ログ）と出口（回答内シェア）を分けて固める。サーバーログでクロールという前提を検証し、複数エンジン横断のシェア計測をツールで補う。両方そろって初めて、計測スタックが成立します。
「測れないものは改善できない」——これはネットワーク運用の鉄則であり、ブランドのAIプレゼンスにもそのまま当てはまります。AEO施策の効果を経営に示し、競合との差を埋める出発点は、presenceを定量化し、監視に乗せることです。
参考リンク
- Similarweb「2026 Generative AI Brand Visibility Index」（ブランド言及シェアのベンチマーク）
- LLMrefs「Generative Engine Optimization: The 2026 Guide」（Google上位とAI被引用の重複低下に関するBrandlight調査の紹介）
- Search Engine Journal「Gap Between Google Rankings And LLM Citations」（エンジン別の重複率の実測）
免責事項：本記事は2026年6月時点の公開情報および各種調査に基づく一般的な情報提供であり、特定のツール・手法による計測精度や成果を保証するものではありません。引用した統計値は出典元の調査時点・条件に依存し、AIエンジンの仕様や各社の計測手法は頻繁に更新されます。実際の計測スタック構築は自社の目的・対象市場・関連サービスの規約に照らして検討し、最新情報は各公式ソースでご確認ください。
コメント