AI検索エンジンはどのように「同一性」を識別するのか：エンティティ解決と引用のメカニズム
AI検索エンジンがブランドを引用するには、Web上に分散した無数の言及がすべて同一の対象、つまり「自社」を指していると認識する必要があります。この「エンティティ解決（Entity Resolution）」と呼ばれる処理によって、コンテンツ制作の成果が引用として積み上がるか、信頼性の低い断片的なアイデンティティとして分散してしまうかが決まります。エンティティ解決を左右するのは、自社サイト内での同一性の一貫性、同一の事実に関する第三者ソースによる裏付け、事実を明示する構造化データ、そしてエンジンが正規とみなす単一の拠点の4つのレバーです。エンティティ解決が正しく機能していれば、作成したすべての引用可能な文章が強固なアイデンティティに紐づきます。逆にここが曖昧だと、優れたコンテンツであっても、エンティティ解決が明確になされている競合に引用枠を奪われてしまいます。
クローラーのアクセス許可、アンサーファーストなコンテンツ作成、プロンプトセットのモニタリングといった基本的な生成エンジン最適化（GEO）施策を実行しているにもかかわらず、自社より内容の薄い競合に引用を奪われ続けている場合、そのボトルネックがライティングにあることはほとんどありません。問題はさらに上流、多くのガイドが見落としているステップにあります。それは、エンジンが自社ブランドを「回答内で名前を挙げるに値する、単一の信頼できるエンティティ」として解決できているかどうかです。
これは、ChatGPTに引用される方法の基盤となるメカニズムです。そのガイドでは引用対象となる要件やコンテンツの構成を扱っていますが、本稿ではそれらを確実に成果へと結びつけるための「アイデンティティ解決」の課題を解説します。
引用は最初のステップではなく、最後のステップである
一見すると、引用はエンジンがリストから自社のページを選び出しているだけのように見えます。しかし、その手前には3つの段階が存在します。
- 解決（Resolve） — クローラー、学習データ、構造化データを通じて確認された「自社ブランド」に関するすべての言及を、1つのレコードに統合する。
- 検索・取得（Retrieve） — プロンプトが実行された際、解決されたエンティティのコンテンツやWeb全体から候補となる文章を抽出する。
- 引用（Cite） — 生成された回答の出典として、それらのソースを紐づけて明記する。
一般的なGEOのアドバイスの多くはステップ3に飛びつきがちです。しかし、ステップ1で失敗すると、ステップ2で抽出される候補群の質が下がり、ステップ3では回答の帰属先が他社になるか、あるいはどこにも紐づかなくなります。どれほど優れた引用可能な最小単位（citable atoms）を執筆していても、エンジンがそれらを確固たる単一のアイデンティティとして統合できていなければ、引用を勝ち取ることはできません。
つまり、コンテンツの測定ばかりに目を向けていると、評価すべきレイヤーを見誤る恐れがあります。引用率は検索取得やライティングの改善によって向上しますが、その上限はエンティティ解決の精度によって規定されます。まずはその上限を引き上げることが先決です。
AI検索エンジンにとって「エンティティ」とは何か
エンティティとは単なるホームページのことではありません。正式名称、既知の別名・通称、主要ドメイン、カテゴリ、そして他のエンティティ（創業者、親会社、競合他社、製品など）との関係性といった属性を持つ「解決済みのレコード」です。エンジンが回答を生成する際、単一のWebページではなく、このレコードに基づいて処理を行います。
最も近い概念は、ナレッジグラフのノードです。エンジンは実質的に「対象である『AEO Mantis』について得たすべての情報に基づき、確信を持って事実と言えるものは何か？」と問いかけています。そのノードに正しく統合・照合された事実の完全性と正確さが、そのまま回答の精度となります。
コンテンツの質がほぼ同等である2つのブランド間で、引用結果に大きな差がつくのはこれが理由です。一方はクリーンで十分に裏付けられたエンティティレコードを持っていますが、もう一方は情報の欠落や矛盾、別名の重複が多く存在します。その結果、エンジンはより安全で明確に解決されている競合を選択するのです。
エンティティの一貫性の真の意味
エンティティの一貫性（Entity Consistency）とは、自社サイト、構造化データ、そして自社を裏付ける第三者ソースなど、AI検索エンジンが読み取るすべての情報源において、ブランドの基本情報（名称、カテゴリ、創業者、設立日、主要ドメインなど）を寸分違わず統一して提示する手法です。一貫性がインプットであり、クリーンなエンティティ解決がアウトプットとなります。情報同士が一致するたびに、エンジンが保持するレコードの確信度が高まります。そしてエンジンが回答内でブランド名を明記する際には、この確信度が不可欠となります。
これは、LLMOにおいて最もコストパフォーマンスの高い施策でもあります。新しいコンテンツの作成や新規被リンクの獲得を必要とせず、既存のページ間における情報の整合性を整えるだけで実行できるからです。以降では、この4つの具体的なレバーと、それぞれが破綻しやすいポイントについて解説します。
エンティティ解決を左右する4つのレバー
一貫性と言っても単一の要素ではありません。4つの明確なレバーが存在し、そのいずれか1つに不備があるだけでもレコード全体の評価が制限されてしまいます。
1. 自社管轄サイト内におけるアイデンティティの一貫性
自社サイト上の記述は、エンジンにとっての一次情報源です。もしホームページで「AEO Mantis」、会社概要で「AEO Mantis, Inc.」、フッターで「AEO Mantis Inc」、プレスキットで「Pilot Cite」と表記されていた場合、エンジンはこれらが1つのエンティティなのか、それとも3つの異なるエンティティなのかを推測しなければなりません。推測には計算コストがかかりエラーのリスクもあるため、エンジンは安全策としてそのブランドの信頼度を下げてしまいます。
カテゴリ、創業者名、設立日、本社所在地、製品名についても同様です。各項目について正式な表記を1つ決定し、自社が管理するすべての媒体で統一して記載してください。表記の揺れはバグとして扱うべきです。
2. 第三者ソースによる事実の裏付け
エンジンは、第三者による独立した言及の一致を重視します。自社のホームページがあるカテゴリを主張し、さらに企業ディレクトリ、レビューサイト、プレス記事などの3つの独立したソースが同じカテゴリを記載していれば、その情報は十分に解決されたとみなされます。自社サイトにしか書かれていない場合、エンジンの確信度は低いままにとどまります。
これは、いわゆる「オーソリティ（権威性）」に関するアドバイスの根底にある極めて実直な基礎です。この取り組みは従来のSEO的なリンクビルディングではなく、エンジンがすでに信頼している外部ソース上に、自社に関する同一の事実が一貫して記載されている状態を作ることです。AIによるブランド情報のハルシネーションのほとんどは、自社サイト外で裏付けが取れなかった事実に起因しています。
3. 事実を明示する構造化データ
Schema.orgマークアップを使用すると、エンジンが誤読できない形式で属性を直接渡すことができます。Organizationスキーマにname、url、logo、sameAs（公式プロファイルへのリンク）、foundingDateを記述することで、自然言語では曖昧になりがちな項目の推測を排除できます。
特にsameAsは、多くのチームで十分に活用されていないレバーです。各エントリは「このプロファイルは自社サイトと同一のエンティティである」という明示的な宣言になります。これにより、Wikipedia、LinkedIn、Crunchbase、GitHubなどのプレゼンスを無関係なものとして扱わず、1つのノードへと統合する手助けとなります。
4. 単一の正規ドメイン（カノニカルホーム）
すべてのエンティティには、エンジンが信頼できる情報源として扱う単一のドメインが必要です。マーケティングサイト、別ルートにあるドキュメント用サブドメイン、別ドメインのWebアプリといったように存在を3つに分散させてしまうと、エンジンはどれがブランドを代表するドメインなのか判断を迫られます。正規化（canonicalization）による統合、単一のルートへの一貫した内部リンク、そしてドメイン間での重複エンティティレコードの排除こそが、エンジンが確信を持って自社を認識できるようにするための鍵です。
エンティティ解決が失敗する典型的なパターン
4つのレバーには、それぞれ特徴的な失敗パターンが存在します。自社の問題がどれに当てはまるかを把握することで、優先的に取り組むべき箇所が明確になります。
アイデンティティの断片化（Fragmented identity）：本来1つであるはずのブランドに対して、エンジンが2〜3個の不完全なレコードを保持している状態。症状：ある回答では正式な法人名で表示され、別の回答では製品名で表示されるなど、両者がいつまでも統合されない。対処法：すべての媒体で正式名称を統一し、sameAsでそれらを相互に結びつける。
別名・通称のドリフト（Alias drift）：別名（旧名称、製品の略称、よくある誤記など）が、誤って別のエンティティ（競合他社や無関係の企業など）に解決されている状態。症状：自社が言及されるべきプロンプトで別のラベルとして引用されるか、まったく引用されない。対処法：自社ページおよび構造化データ内で、その別名を明示的に自社のものとして定義し直す。
正規ドメインの誤認（Wrong canonical）：エンティティ自体は正しく解決されているものの、信頼できる情報源が誤ったドメイン（地域別サイト、旧ドメイン、代理店サイトなど）に設定されている状態。症状：自社のコンテンツは読み取られているが、エンティティレコードが管理外のドメインに紐づいている。対処法：単一のルートドメインに集約する正規化を徹底し、不要なドメインを順次廃止する。
事実の矛盾（Contradictory facts）：媒体ごとにカテゴリ、創業者、日付などの記載が食い違っている状態。症状：エンジンの回答における自社の説明が不正確になるか、類似のブランドと混同される。対処法：項目ごとに正式な事実を1つ決定して全体に反映させ、情報のズレが生じた場合は次回の修正サイクルで即座に是正する。
30日間のエンティティクリーンアップ手順
エンティティ解決の課題は修正可能です。ただし、一回限りの作業ではなく、体系的なプロジェクトとして進める必要があります。以下のステップは、前段階の成果をもとに次のステップの効果を測定しやすい順序で構成されています。
- 第1週 — 自社管轄サイトの監査：正式な事実情報（名称、法人名、カテゴリ、創業者、設立日、本社所在地、製品名）と、それらが記載されているすべてのページを洗い出し、不一致を特定する。
- 第2週 — 正式情報の統一：各項目につき1つの正式な表記を決定し、トップページ、会社概要、フッター、プレスキット、製品ページに反映する。表記の揺れは別バリエーションではなく不具合として処理する。
- 第3週 — Organizationスキーマの追加・修復：公式プロファイル（Wikipedia、LinkedIn、Crunchbase、GitHub、公式SNSなど）を指すsameAsを設定したOrganizationスキーマを実装または修正する。sameAsは統合の明確な指示として機能する。
- 第4週 — 第三者ソースのギャップ解消：主要な事実ごとに、少なくとも2つ以上の独立したソースで同一の記載がある状態を作る。エンジンがすでにクロールしているディレクトリやレビューサイトを優先する。
30日間のクリーンアップを終えるとエンティティレコードは整いますが、その効果が現れるのは自社サイト上ではなくAIの回答側です。したがって、測定の軸もそちらへ移行させる必要があります。
エンティティ解決が機能しているか測定する方法
エンジンの内部にあるエンティティレコードを直接確認することはできません。そのため、単発のテストではなく、固定されたプロンプトセットに対する生成回答の割合（レート）を時系列で追跡することで、解決の精度を推測します。
解決精度が向上していることを示す3つのシグナル：
- コンテンツを追加していないのにブランド言及率が上昇する — クリーンアップ後に新しいコンテンツを公開していないにもかかわらず、回答内での言及が増加した場合、それはエンティティ解決の改善による成果です。以前は確信が持てず言及を避けていた場面で、エンジンが自信を持ってブランド名を挙げられるようになったことを意味します。
- 引用率がブランド言及率に追いつく — 言及されているのにリンク（引用）されないという大きなギャップがある場合、エンジンはブランドの存在を把握していても、出典ソースを確信を持って紐づけられていないケースが多く見られます。エンティティ解決が強固になるにつれ、言及に追従して引用も増加します。
- 回答における説明（フレーミング）が安定する — 初期段階では、回答内の説明に食い違い（誤ったカテゴリ、古い創業者名、誤表記など）が見られます。レコードが統合されるにつれて、回答の表現は展開した正式な事実へと収束していきます。
これら3つの指標は、一時点のスナップショットではなく推移として捉える必要があります。同一のプロンプトセットに対して定期的にトラッキングを実行し、プラットフォームごとに時系列の傾向を分析してください。有意な変化が見られた場合は、実際の回答内容を確認して何が変化したかを読み解く契機とします。「測定、分析、修正、再測定」のループを回し続けることで、エンティティの最適化は一過性の作業から継続的な資産へと変わり、AI検索での可視性メトリクスの信頼性を担保することにつながります。
よくある質問
自社サイト、構造化データ、第三者ソースにわたり、ブランドに関する基本的事実（名称、カテゴリ、創業者、日付、主要ドメインなど）を寸分違わず統一して記載することです。AIエンジンは分散した言及を1つのエンティティレコードに統合するため、インプットの一貫性こそが、引用を獲得できる精度でレコードを解決するための条件となります。
いいえ、異なります。キーワードターゲティングは「どのプロンプトに対してコンテンツが回答を提供すべきか」を対象とします。一方、エンティティ解決は「そもそもエンジンがその回答の主体として自社ブランドを認識しているか」を扱います。適切なプロンプトを完璧にターゲットしていても、エンティティレコードが断片化していたり誤認されていたりすると、引用を獲得することはできません。
いいえ。llms.txtはクロールすべきページを提示するヒントに過ぎず、エンティティの属性を定義したりレコードを統合したりするものではありません。llms.txtでは不可能な統合処理は、sameAsを設定したOrganizationスキーマが担います。これらは解決する課題が異なり、代替関係にはありません。
検索取得レイヤー（Retrieval）においては、再クロール後数日以内に構造化データやページ上の修正が反映されることがあります。一方、第三者ソースによる裏付けや学習データへの反映には数週間から数ヶ月かかります。自社サイトの修正による即効性のある改善に加え、外部ソースの更新に伴う中長期的な複利効果を見込む必要があります。
直接的な効果はありません。エンティティ解決はリンクの量ではなく、裏付けられた事実の一貫性によって左右されます。自社のホームページに向けられた多数の低品質なリンクよりも、信頼性の高い少数の情報源が正式な事実を正確に記載していることの方が、エンティティレコードにとってはるかに有効です。
プライマリドメイン上に、すべての公式プロファイルへのsameAsリンクを含む正規のブロックを1つ設置してください。複数のドメインに競合するブロックが存在すると、エンジンがそれらを別々のエンティティとして認識する原因となり、防ぐべき断片化を招いてしまいます。