「アイデンティティ・リーク」とは――AI検索が企業を検証できない構造、71社調査で判明

「アイデンティティ・リーク」とは――AI検索が企業を検証できない構造、71社調査で判明

要点: Search Engine Landが2026年7月24日に公開した調査記事は、カナダ・プリンスエドワード島（PEI）の認証済みビジネス71社を対象に、AI検索が企業を「検証」できているかを独自の500点満点フレームワークで監査しました。結果、平均的なビジネスはAI検証に必要な情報のうち15.6%しか解決できておらず、約84%の「アイデンティティ」がAIに漏洩（＝検証不能）していることが判明しました。著者のDonna Rougeau氏はこのギャップを「アイデンティティ・リーク（Identity Leak）」と名付け、原因の類型化と6つの対策を提示しています。

本稿は同記事のファクトに基づき、日本のマーケター・事業者向けに背景・実務インパクト・具体的な対応手順を整理する解説記事です。

最終更新日: 2026年7月28日

何が起きたのか

調査の概要——PEI州の認証済み71社を独自フレームワークで監査

Search Engine LandのDonna Rougeau氏（編集: Pat Goggins氏、レビュー: Danny Goodwin氏）が2026年7月24日に公開した記事「AI search can't verify your business — here's how to fix it」は、カナダ・プリンスエドワード島（PEI）で認証を受けたビジネス71社を対象に、AI検索システムがそれらの企業をどこまで「検証」できているかを実地調査したものです。

対象となった71社は、食品・飲料、小売、専門サービス、技術、農業、医療、宿泊、ゴルフ関連など、業種を横断してサンプリングされています。調査手法は、Googleが検索品質評価で用いるE-E-A-T（Experience・Expertise・Authoritativeness・Trustworthiness＝経験・専門性・権威性・信頼性）のスコアフレームワークを修正した、独自の500点満点の監査フレームワークです。評価項目は次の5カテゴリーで構成されています。

• 主要企業エンティティ監査: ミッション（企業の存在意義）、リーダーシップの可視性、企業の歴史、連絡先情報が、AIが取得可能な形で存在するか
• 技術的基礎: HTTPS化の状況、プライバシーポリシーや利用規約などの法的ページの有無
• 初期データ収集: バックリンクの品質、ソーシャルシグナル、コンテンツの鮮度
• シニアエンティティ: 企業としての実在性・継続性を裏付ける情報
• ポリシーページ: プライバシーポリシー・利用規約などの明示的な存在とリンク

これに加えて、NAP（Name・Address・Phone、企業名・住所・電話番号）の一貫性、実名を伴う人物の識別可能性、そしてAIクローラーによる直接フェッチでのテキスト可読性という3つの追加チェックも行われています。この「直接フェッチでのテキスト可読性」という項目が特に重要で、AIシステムが実際にどのようにWebページへアクセスし、どのような形でテキストを取得できるか（あるいはできないか）という、人間の目視評価とは異なる技術的な観点を組み込んでいる点が、この調査の独自性です。

中心的な発見——平均で情報の84%がAIに「漏洩」

監査の結果、71社の平均スコアは、AI検証に必要な情報のうち15.6%しか解決できていないというものでした。裏を返せば、平均して約84%の「アイデンティティ」がAIシステムに対して漏洩（leak）している、つまり検証不能な状態にあるということです。

ここでいう「漏洩」とは、情報が盗まれるという意味ではなく、企業が実世界で持っている実態——誰が経営しているか、いつから存在するか、どこにあるか、どのような方針で運営されているか——と、AI検索システムがWeb上から実際に検証できる内容との間に生じる大きなギャップを指す、著者独自の用語です。この「ビジネスが実世界で何であるかと、AI検索システムがそれを検証できる内容との間のギャップ」こそが、本記事が提示する新概念「アイデンティティ・リーク（Identity Leak）」の定義です。

さらに深刻な数値として、71社中17%（およそ12社）は、AIが取得可能なデジタルプレゼンスが皆無という結果も示されています。これは単に「最適化が不十分」という段階ではなく、AI検索システムから見て、その企業がそもそも「存在しない」も同然の状態にあることを意味します。

「情報はあるが、検証に必要な場所にない」――22社の下層ページ問題

調査でとりわけ示唆に富むのは、71社中22社において、実名入りの識別可能なリーダーシップ情報（経営者や責任者の氏名など）が、ホームページ以外の下層ページ——「Our Team」「Our History」といったページ——に存在していた、という発見です。

この22社は、情報そのものが欠落しているわけではありません。しかし、AIによるルーティンなホームページスキャンでは、この情報が見逃されていました。つまり「情報はあるが、AIが検証のために実際に見に行く場所にはない」という状態です。これは、単純な「コンテンツの有無」の問題ではなく、「情報の配置」の問題であることを鮮明に示しています。人間の訪問者であれば、ナビゲーションメニューをたどって「Our Team」ページにたどり着けますが、AIのクロール・フェッチの挙動は、必ずしも人間と同じ経路を効率的にたどるとは限りません。

AI検証失敗の5つのカテゴリー

Rougeau氏は、71社の監査を通じて観察されたAI検証失敗の原因を、次の5つのカテゴリーに整理しています。

1. 信頼シグナルは存在するが発見不可能: リーダーシップ情報や沿革などの信頼シグナルが下層ページに埋没しており、ホームページからのリンクがない
2. クライアントサイドレンダリング問題: JavaScriptのみで構築されたサイトは、AIによる直接フェッチ時に抽出可能なテキストがゼロになる。静的HTMLへのフォールバックが存在しない
3. ドメイン喪失: 調査対象の中には、あるチーズメーカーのドメインがドメインリセラーによって転売中であったケース、ある塩生産業者のドメインが完全に応答しなかったケースが含まれていた
4. アイデンティティの分散: あるチョコレート職人が3つのドメイン変種で事業を運営していたケース、あるバイオテック企業が同一エンティティでありながら2つの独立したドメインを運営していたケースが確認された
5. デジタルプレゼンス欠落: 写真館、HVAC（暖房・換気・空調）業者、製材業、自動車検査工場などが自社サイトを持たず、第三者ディレクトリにのみ情報が存在するケースがあった

この5類型は、それぞれ原因も対応策も異なります。1と5は「情報の不在・不可視化」の問題であるのに対し、2は「技術的な取得可能性」の問題、3と4は「エンティティの同一性・継続性」の問題です。同じ「AIに検証されない」という結果でも、根本原因が異なれば処方箋も異なるという点が、この5分類の実務的な価値です。

技術的根拠——信頼シグナルの欠如と第三者プラットフォームへの流出

記事はさらに、なぜこれらの問題がAI検索での不利益に直結するのかについて、技術的な根拠を示しています。まず、構造化データ・schema・プライバシーポリシーなどのlegal pagesが存在しないことは、AIシステムが重視する信頼シグナルそのものの欠如になります。AIシステムは、Webページの内容を要約・引用する際に、そのソースがどれだけ「検証可能」であるかを判断材料の一つとして扱っており、構造化データや法的ページの有無は、この判断に直接影響する要素です。

もう一つの重要な指摘は、複数ドメインの運営によってNAP情報が分散した場合に起きる現象です。企業名・住所・電話番号が複数のドメインやプロフィールにばらけて存在すると、AIシステムはどの情報源を正とすべきか判断できなくなります。その結果、AIシステムは「最も検証可能性への投資をしている第三者プラットフォーム」をデフォルトで選択してしまう傾向があると記事は指摘しています。具体例として、宿泊業界において、自社の予約ページよりも第三者の予約仲介サイトがAI検索の回答で上位に来てしまう問題が挙げられています。これは、自社サイトの検証可能性が低いために、より整備された第三者プラットフォームにAIの「信頼」が流れてしまう構造です。

実名を伴うリーダーシップ情報・沿革・ポリシーページが二次ページに偏在している場合も同様に、AIの初回クロールでは検出されないため、結果として企業の実在性・信頼性を示す情報が「あるのに使われない」状態に陥ります。

著者の結論的な洞察

Rougeau氏は記事の結びで、次のように述べています。

"The identity leak happens when businesses are represented online by infrastructure that was built for an old technology."

（アイデンティティ・リークは、旧世代の技術のために構築されたインフラによって、ビジネスがオンライン上で表現され続けているときに発生する）

この一文が示すのは、多くの企業のWebサイトが、人間の閲覧者を想定して設計されたナビゲーション構造・視覚的な情報配置・JavaScriptによるインタラクティブ性を前提に構築されている一方で、AI検索システムはそれとは異なる形でWebページを「読む」ということです。人間にとって自然な情報設計が、AIにとっては検証不能な設計になっている——このミスマッチこそが、アイデンティティ・リークの本質だという指摘です。

背景・経緯の整理

E-E-A-Tの応用としての位置づけ

この調査が採用した監査フレームワークは、Googleの検索品質評価ガイドラインで知られるE-E-A-T（経験・専門性・権威性・信頼性）を土台にしています。E-E-A-Tはもともと、人間の検索品質評価者がWebページの品質を判断するための枠組みとして知られてきましたが、AI検索時代においては、この枠組みが「AIがそのページ・そのエンティティをどれだけ検証できるか」という、より機械的・技術的な観点に読み替えられつつあります。

本サイトでも、E-E-A-TとLLMOの関係については別記事「E-E-A-TとLLMOの関係——AI検索時代に信頼性が引用を左右する理由」で解説していますが、今回のPEI調査が新しいのは、E-E-A-Tを定性的な品質評価の枠組みとしてだけでなく、「500点満点」という定量的なスコアリング体系に落とし込み、しかも「直接フェッチでのテキスト可読性」という、AIのクロール挙動そのものを検証項目に組み込んでいる点です。これは、E-E-A-Tの議論を人間の読者向けの品質判断から、AIエージェントによる機械的な取得可能性の判断へと接続する試みと位置づけられます。

NAP一貫性・ローカルSEOの文脈との接続

NAP（企業名・住所・電話番号）の一貫性は、従来のローカルSEO（地域検索対策）において古くから重視されてきた概念です。Googleビジネスプロフィールや各種ディレクトリサイトにまたがってNAP情報が統一されているかどうかは、ローカル検索のランキング要因として長く議論されてきました。

今回の調査が示すのは、このNAP一貫性という古典的な論点が、AI検索の時代においても——むしろAI検索の時代だからこそ——重要性を増しているという点です。従来のローカルSEOでは、NAPの不一致は「ランキングが下がる」という緩やかな不利益として語られることが多かったのに対し、今回の調査が示すのは、NAPの分散・不一致が「AIがそもそもどの情報を信頼してよいか判断できず、第三者プラットフォームに検証の主導権を明け渡してしまう」という、より構造的で不可逆的な不利益につながりうるという点です。

なぜ「アイデンティティ・リーク」という新しい概念が必要だったのか

これまでのAI検索対策の議論は、多くの場合「AI Overviewsに引用されるにはどうすればよいか」「AI検索での言及率をどう上げるか」といった、露出・引用の獲得を主眼に置いたものでした。今回の調査が投げかけているのは、それ以前の、より基礎的な問いです。すなわち、「そもそも自社がAIによって実在する企業として認識され、正しく検証されているか」という問いです。

引用獲得の巧拙を論じる前提として、AIがその企業を実在するエンティティとして検証できていなければ、引用の議論自体が成立しません。アイデンティティ・リークという概念は、この見落とされがちな前提部分に光を当てたものであり、LLMO（大規模言語モデル最適化）の議論において、コンテンツの質や引用獲得テクニックの手前にある「検証可能性そのもの」を扱う新しい切り口を提供しています。

国内外の反応

本稿執筆時点（2026年7月28日）で、この調査に対する他メディアの追随報道や業界からの具体的な反応は確認できていません。Search Engine Land自体がSEO・AI検索の専門メディアとして高い信頼性を持つ媒体であり、E-E-A-Tの応用や実地調査に基づくデータジャーナリズム的な記事を継続的に発信していることを踏まえると、今後、同様の切り口での追加調査や関連記事が続く可能性はありますが、現時点では推測の域を出ません。

日本語での本調査の解説記事は、本稿執筆時点で確認できていません。国内のSEO・LLMO関連メディアでは、AI OverviewsやAI Modeのアップデートといった「機能面」の話題が中心になりがちですが、今回のようにAI検索が企業をどう「検証」しているかという、より基礎的なインフラ面に焦点を当てた調査は、日本語圏ではまだ少ない切り口です。

aiseo-llmo.com ユーザーへの影響

「引用対策」の前提が崩れている可能性

aiseo-llmo.comの読者の多くは、AI Overviews・Perplexity・ChatGPT検索などでの引用獲得を目的にLLMO施策に取り組んでいると考えられます。しかし今回の調査が示すのは、引用獲得のための施策を積み上げる以前に、そもそも自社がAIによって実在企業として検証されているかどうかという、より土台に近い部分に見落としがある可能性です。

コンテンツの質を高め、FAQやハウツー記事を充実させても、企業そのもののアイデンティティ（誰が運営し、どこにあり、どのような沿革を持つか）がAIにとって検証不能であれば、引用の際の「信頼できる情報源」としての評価に不利に働く可能性があります。今回の調査結果は、コンテンツ戦略以前の「エンティティ監査」を、LLMO施策のチェックリストに加える必要性を示唆しています。

日本の中小事業者・地域ビジネスへの示唆

今回の調査対象はカナダの一地域の中小事業者ですが、報告されている問題の構造——JavaScriptのみのサイト、下層ページに埋もれたリーダーシップ情報、ドメインの分散、第三者ディレクトリのみのプレゼンス——は、日本の地域中小事業者やBtoBの専門サービス業にも共通して見られる状況だと考えられます。特に、老舗の名産品メーカーや職人系事業者が、事業拡大や屋号変更に伴って複数のドメインを使い分けている、あるいは代替わりのタイミングで新しい経営者の情報がホームページに反映されていない、といったケースは、国内でも珍しくありません。

こうした状況は、これまでは「機会損失」として緩やかに語られてきましたが、AI検索が情報流通のハブになりつつある局面では、「AIにとって存在しない、あるいは検証不能な企業」として扱われるリスクという、より切実な形で捉え直す必要があります。

業種別の実務インパクト

• 食品・飲料・地場産品メーカー: 今回の調査で挙げられたチーズメーカーやチョコレート職人の事例のように、ブランド展開の過程で複数ドメインを並行運用しているケースが典型的なリスク要因です。ドメインの統一と、実名を伴う生産者・経営者情報のホームページへの明示が有効な対策になります。
• 小売・EC: 商品情報の構造化（Product・Offerスキーマ）に加え、運営会社としてのエンティティ情報（Organization・法人番号・所在地）がAIから検証可能な形で提示されているかを確認する必要があります。
• 専門サービス（士業・コンサルティング等）: リーダーシップ情報や資格・経歴の実名開示は、専門性・権威性の証明として重要ですが、今回の調査が示すように、これが「About」の下層ページにのみ存在し、ホームページから直接リンクされていないケースは実務上よくある落とし穴です。
• 宿泊・観光: 今回の調査でも指摘されている通り、自社の検証可能性が低いと、AI検索の回答内で自社の予約ページよりも第三者の予約仲介サイトが優先される可能性があります。公式サイトのNAP・法的ページ・予約導線の整備は、収益に直結する対応課題です。
• 医療・専門性が問われる業種（YMYL）: 実名の医師・専門家情報や、施設の沿革・資格情報が検証可能な形で提示されているかは、AI検索での信頼性評価に直結する要素です。プライバシーポリシーなど法的ページの整備も含め、基礎的な信頼シグナルの網羅性が特に問われます。
• 地域密着型の職人・サービス業（写真館、設備工事業、製造業など）: 今回の調査で「デジタルプレゼンス欠落」として指摘された業種群です。自社サイトを持たず、第三者ディレクトリのみに情報がある場合、AI検索にとってその企業は実質的に「存在しない」に等しい状態になりえます。最低限の自社サイトと基本情報の整備が出発点になります。

今すぐできる対応策

Rougeau氏が提示する6ステップの対策に沿って、実務的な実装ポイントを整理します。

1. 実名リーダーシップの公開

「About the Owner」「Our Story」「Our Team」といったページを実装し、ホームページから直接リンクします。重要なのは、こうしたページを作るだけでなく、ホームページのナビゲーションやフッターから明示的にリンクすることです。今回の調査で22社が該当した「情報はあるが下層ページに埋没している」問題は、まさにこのリンク構造の欠如によって起きています。

実装としては、Personスキーマを用いて経営者・責任者情報を構造化することも有効です。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "founder": {
    "@type": "Person",
    "name": "山田太郎",
    "jobTitle": "代表取締役",
    "sameAs": ["https://www.linkedin.com/in/yamada-taro-example"]
  },
  "employee": [
    {
      "@type": "Person",
      "name": "佐藤花子",
      "jobTitle": "取締役COO"
    }
  ]
}

founder・employeeにPersonを紐づけることで、実名の経営陣情報を構造化データとしても提示できます。あわせて、Personエンティティの実装については「著者エンティティ実装ガイド」も参照してください。

2. サーバーレンダリング移行

企業名・住所・サービス内容・リーダーシップ情報などのコア情報は、静的HTMLで提供する必要があります。JavaScriptによるインタラクティブな要素自体を廃止する必要はありませんが、AIによる直接フェッチ時に空のHTMLしか返らない状態は避けなければなりません。

具体的な実装アプローチとしては次のようなものがあります。

• SSR（サーバーサイドレンダリング）またはSSG（静的サイト生成）への移行: Next.js等のフレームワークを使っている場合、企業情報・コンタクト情報を含むページはSSR/SSGでレンダリングし、初回HTTPレスポンスの時点でテキストが含まれる状態にします
• プリレンダリングの併用: 既存のSPA（シングルページアプリケーション）を大規模に作り替える余裕がない場合、クローラー向けにプリレンダリングされたHTMLを返す仕組み（動的レンダリング）を暫定的に導入する方法もあります
• noscriptフォールバックの整備: 最低限の企業名・住所・連絡先だけでも<noscript>タグ内に静的テキストとして含めておくことで、JavaScriptを実行しないクローラーにも基本情報が伝わります

この論点は「JSON-LD構造化データとAIの理解——なぜマークアップだけでは不十分なのか」でも扱っている、「情報の存在」と「AIによる取得可能性」のギャップの典型例です。

3. ドメイン統一

複数ドメインで事業を運営している場合は、1つのドメインに絞り、他のドメインは301リダイレクトで正規ドメインに集約します。今回の調査で指摘された「チョコレート職人が3つのドメイン変種で運営」「バイオテック企業が2つの独立ドメインを運営」といったケースは、NAP情報の分散を招き、AIがどちらを正としてよいか判断できない状態を作り出します。

# .htaccess例（Apache）
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://www.primary-domain.com/$1 [R=301,L]

ドメインを統一した後は、Google Search Consoleでの新ドメインの検証、Googleビジネスプロフィールをはじめとする各種ディレクトリの登録情報の更新、そして主要な被リンク元への正規ドメインへの更新依頼まで含めて対応する必要があります。

4. ドメイン生存確認

ドメイン登録の有効期限とDNS解決の状態を定期的に確認します。今回の調査で「あるチーズメーカーのドメインがドメインリセラーによる転売中」「ある塩生産業者のドメインが完全に応答しない」という事例が報告されている通り、ドメインの失効・放置はAI検証以前に、企業のオンラインプレゼンスそのものを消失させる致命的な問題です。

実務チェックリストとしては次の項目が有効です。

• ドメインの自動更新設定が有効になっているか
• WHOIS情報の登録者連絡先が現在も到達可能なメールアドレスか
• DNSレコード（A/AAAA/CNAME）が正しく解決しているかを定期監視ツールで確認しているか
• SSL/TLS証明書の有効期限とHTTPS化の状態

5. ポリシーページの明示的リンク

プライバシーポリシー・利用規約を実装し、フッターなどから全ページで一貫してリンクします。今回の監査フレームワークでも「技術的基礎」「ポリシーページ」が独立した評価項目として設定されていることからわかる通り、法的ページの有無はAIが重視する信頼シグナルの一つです。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "sameAs": [
    "https://www.facebook.com/example",
    "https://x.com/example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-1234-5678",
    "contactType": "customer service"
  }
}

Organizationスキーマにurl・logo・sameAs・contactPointを含め、フッターのプライバシーポリシー・利用規約へのリンクと組み合わせることで、法的基盤の整備を機械可読な形でも示すことができます。構造化データ実装時のよくある落とし穴については「構造化データ実装の失敗例——AI引用を妨げる典型パターン」も参考になります。

6. 第三者プラットフォームの監視

予約システムを持つ業種（宿泊・飲食・美容など）は、第三者リセラー・仲介サイトが自社の予約ページよりもAI検索の回答で上位に来ていないかを定期的にチェックします。今回の調査が示した「自社の検証可能性が低いと、AIはより検証可能性への投資をしている第三者プラットフォームをデフォルトで選ぶ」という構造を踏まえると、これは受動的な監視だけでなく、自社サイトのNAP・法的ページ・構造化データの整備を継続的に強化することで能動的に是正できる問題でもあります。

NAP一貫性チェックリスト

上記6ステップを横断する基礎作業として、NAP一貫性の棚卸しを推奨します。

1. 自社サイト、Googleビジネスプロフィール、主要SNS、業界ディレクトリに登録されている企業名・住所・電話番号を一覧化する
2. 表記ゆれ（番地の表記、電話番号のハイフンの有無、企業名の全角・半角、法人格の位置など）を統一する
3. 統一後の情報を、Organizationスキーマのname・address・telephoneに反映する
4. 3〜6ヶ月ごとに主要ディレクトリの登録情報を再チェックする運用ルールを定める

エンティティ最適化全般の考え方は「エンティティ最適化でAI引用を3倍にする方法」「日本市場におけるエンティティ最適化とAI検索」、Organizationスキーマの具体的な設定手順は「Organizationスキーマ実装ガイド——AI引用のための2026年版セットアップ」、どのスキーマから優先して実装すべきかの判断軸は「構造化データ実装の優先順位——AIO時代の2026年版ガイド」で詳しく解説しています。全体設計はピラー記事「LLMO完全ガイド」も参照してください。

今後の見通し

今回の調査はカナダの一地域・71社という限定的なサンプルに基づくものであり、著者自身も断定的な結論よりも「アイデンティティ・リーク」という新しい枠組みの提示に主眼を置いています。今後、同様の監査フレームワークが他地域・他業種にも適用され、より広範なデータが蓄積されていく可能性はありますが、現時点でその予定が公表されているわけではありません。

一方で、この調査が示した問題構造——信頼シグナルの下層ページへの埋没、クライアントサイドレンダリングによる取得不能、ドメインの喪失や分散、第三者プラットフォームへの検証主導権の流出——は、いずれも技術的に検証・是正が可能な項目です。LLMO施策において、コンテンツの質や引用獲得テクニックに注力する前段階として、「自社がAIにとって検証可能なエンティティになっているか」を棚卸しする実務——エンティティ監査——が、今後のLLMOの基本動作の一つとして定着していく可能性があります。

AI検索プラットフォーム側においても、企業の実在性・信頼性をどのように判定し、引用や回答内での言及にどう反映させるかというロジックは今後も変化し続けると見られます。この変化に対して受動的に対応するのではなく、NAP一貫性・構造化データ・法的ページの整備といった基礎的な対策を先んじて講じておくことが、プラットフォーム側のロジック変化に左右されにくい、最も確実な備えになります。

よくある質問

Q1. 「アイデンティティ・リーク」とはどのような概念ですか？

ビジネスが実世界で何であるかと、AI検索システムがそれを検証できる内容との間のギャップを指す概念です。Search Engine Landの調査記事の著者Donna Rougeau氏が提唱しました。単なる情報不足ではなく、「情報はあるのにAIが検証のために参照する場所にない」という配置・技術面のギャップを含む点が特徴です。

Q2. 今回の調査の対象と手法を教えてください。

カナダ・プリンスエドワード島（PEI）で認証を受けたビジネス71社を対象に、E-E-A-Tスコアフレームワークを修正した独自の500点満点の監査フレームワークで評価しました。主要企業エンティティ監査、技術的基礎、初期データ収集、シニアエンティティ、ポリシーページの5カテゴリーに加え、NAP一貫性、実名人物の識別可能性、直接フェッチでのテキスト可読性もチェックしています。

Q3. 調査結果の中心的な数値は何ですか？

平均的なビジネスは、AI検証に必要な情報のうち15.6%しか解決できておらず、平均で約84%の「アイデンティティ」がAIに漏洩（検証不能）していることが判明しました。また71社中17%（約12社）は、AIが取得可能なデジタルプレゼンスが皆無という結果でした。

Q4. AI検証が失敗する主な原因は何ですか？

記事は5つのカテゴリーに整理しています。（1）信頼シグナルが下層ページに埋没し発見不可能、（2）JavaScriptのみのサイトによるクライアントサイドレンダリング問題、（3）ドメインの喪失（転売・応答停止）、（4）複数ドメイン運営によるアイデンティティの分散、（5）自社サイトを持たず第三者ディレクトリのみに存在するデジタルプレゼンス欠落、の5つです。

Q5. なぜ情報が「あるのに」AIに検証されないケースがあるのですか？

71社中22社では、実名入りのリーダーシップ情報が「Our Team」「Our History」などの下層ページに存在していましたが、ホームページからリンクされていないため、AIのルーティンなホームページスキャンでは見逃されていました。情報の有無ではなく、情報の配置とリンク構造がAI検証の可否を左右するということです。

Q6. 著者が提示する対策の要点は何ですか？

6ステップです。（1）実名リーダーシップの公開とホームページからの直接リンク、（2）企業情報を静的HTMLで提供するサーバーレンダリング移行、（3）複数ドメインを1つに統一しリダイレクト、（4）ドメイン登録期限とDNS解決の定期確認、（5）プライバシーポリシー・利用規約の明示的リンク、（6）第三者予約サイト等が自社ページより上位に来ていないかの監視です。

Q7. 日本の中小事業者にはどのような示唆がありますか？

調査対象はカナダの地域企業ですが、複数ドメインの並行運用、代替わりに伴う経営者情報の未更新、JavaScriptのみのサイト構成、自社サイトを持たず第三者ディレクトリのみに存在する状況などは、日本の地域中小事業者や職人系事業者にも共通しやすい課題です。AI検索が情報流通のハブになるほど、こうした状態は機会損失にとどまらず「AIにとって検証不能な企業」という扱いにつながるリスクがあります。

Q8. 宿泊業界で指摘されている問題は何ですか？

自社サイトの検証可能性（NAP一貫性、法的ページ、構造化データなど）が低い場合、AI検索の回答内で自社の予約ページよりも第三者の予約仲介サイトが優先して表示される可能性があるという問題です。AIシステムが「最も検証可能性への投資をしている第三者プラットフォーム」をデフォルトで選択してしまう傾向によるものと説明されています。

Q9. 構造化データを実装すればアイデンティティ・リークは解消しますか？

構造化データの実装は有効な対策の一つですが、それだけでは不十分です。今回の調査は、静的HTMLでのテキスト提供（サーバーレンダリング）、ホームページからのリーダーシップ情報への直接リンク、ドメインの統一と生存確認、ポリシーページの明示的リンクなど、構造化データ以外の複数の要素を組み合わせて初めて検証可能性が高まることを示しています。

Q10. この調査結果はどの程度一般化できますか？

対象はカナダの一地域・71社という限定的なサンプルであり、著者自身も断定的な一般化よりも「アイデンティティ・リーク」という新しい分析枠組みの提示に主眼を置いています。ただし、報告されている問題構造（下層ページへの情報埋没、クライアントサイドレンダリング、ドメインの喪失・分散、第三者プラットフォームへの流出）自体は、業種や地域を問わず起こりうる普遍的な技術的問題であり、日本を含む他地域の事業者にとっても参考になる内容です。

関連記事

• LLMO完全ガイド——AI検索時代の最適化戦略の全体像
• AI検索最適化（AIO/LLMO）完全ガイド
• E-E-A-TとLLMOの関係——AI検索時代に信頼性が引用を左右する理由
• エンティティ最適化でAI引用を3倍にする方法
• 日本市場におけるエンティティ最適化とAI検索
• Organizationスキーマ実装ガイド——AI引用のための2026年版セットアップ
• JSON-LD構造化データとAIの理解——なぜマークアップだけでは不十分なのか
• 構造化データ実装の失敗例——AI引用を妨げる典型パターン
• 著者エンティティ実装ガイド
• 構造化データ実装の優先順位——AIO時代の2026年版ガイド
• 用語集: E-E-A-T
• 用語集: Schema.org
• 用語集: 構造化データ
• 用語集: GEO（生成エンジン最適化）