AI検索のエンティティ設計とは、自社が「誰で・何をしているか」を、サイト・Googleビジネスプロフィール・外部サービス全体で矛盾なく識別できる状態を作る作業です。よく「構造化データを実装すればAIに引用される」と言われますが、2026年に公開された複数の実測は、その因果をそのままは支持していません。この記事では、構造化データがどこまで届き、どこから先は別の作業になるのかを一次データで線引きし、中小企業が着手すべき順番までを整理します。
この記事でわかること
- 効く範囲は実測で決まっている： 既に見つかっているページに構造化データを足しても引用は動かず、AIが直接取りに来た場面では、隠した記述は読まれませんでした。
- Google公式が示す基準線： AI機能に載るために特別な構造化データは不要で、推奨されているのは「構造化データが可視テキストと一致していること」です。
- 着手はGoogleビジネスプロフィールから： 実務で最初に直すべき場所と、効果が見え始めるまでの期間、そして何を見て判断するかを実案件の目安で示します。
エンティティ設計とは「マークアップの追加」ではなく「実体の一致」を作る作業
この記事でいうエンティティ設計の定義
エンティティ設計という言葉は、人によって指す範囲が変わります。構造化データの実装を指す人もいれば、ナレッジグラフへの登録、NAP（社名・住所・電話番号）の統一、ブランド情報の整備まで含める人もいます。この記事では、もっとも広い意味で使います。
ここでいうエンティティ設計とは、Web上の複数の情報源をどこから読んでも、同一の企業・人物・サービスとして矛盾なく識別できる状態を作ることです。自社サイト、Googleビジネスプロフィール、SNSのプロフィール欄、地図サービス、業界団体の名簿——これらが互いに食い違っていない状態を指します。マークアップの記述はその状態を機械に伝える手段のひとつであって、目的そのものではありません。
この整理を先に置くのは、「構造化データを入れたのにAIに引用されない」という相談のほとんどが、手段と目的の取り違えから生じているためです（実務知見）。
判断の基準線＝Google公式が実際に書いていること
議論の出発点として、Google検索セントラルの公式ドキュメント「AI機能とサイト」を確認しておきます。2025年12月10日に更新されたこのページには、AI OverviewsやAI Modeに掲載されるために特別なschema.orgの構造化データを追加する必要はなく、追加要件や特別な最適化も必要ないと明記されています。
一方で、既存のベストプラクティスとして推奨されている項目のなかに、「構造化データが可視テキストと一致していること」が含まれています。つまり公式が求めているのは、マークアップを増やすことではなく、マークアップとページに見えている内容がズレていないことです。
この一文が、本記事全体の基準線になります。以降で紹介する実測結果は、いずれもこの基準線と矛盾しません。
Q. エンティティとは何ですか。AI検索でなぜ重要なのですか
A. エンティティとは、AIが「文字列」ではなく「実在するモノ・人・組織」として識別する単位です。AIは回答を組み立てる際に、その対象が何者かを特定したうえで情報を選びます。自社がひとつの実体として識別されないと、検索順位が高くても引用の候補に入りにくくなります。
GoogleとChatGPTでは、自社情報が通る「取得経路」が違う
同じ構造化データを実装しても、Googleの生成AI機能とChatGPTでは届き方が変わります。理由は、両者が情報を取ってくる経路が異なるためです。この前提を先に押さえておかないと、次章で紹介する実測結果が互いに矛盾して見えてしまいます。
Google側は検索の情報基盤を経由している
GoogleのAI Overviews・AI Modeは、Google検索が持つ情報基盤の上に載っています。検索インデックス、そして2012年に「things, not strings」を掲げて公開されたナレッジグラフといった仕組みが、その基盤に含まれます。ナレッジグラフは、モノ・人・組織を実体として扱い、それぞれの関係を保持する実在のデータベースです。
構造化データが検索インデックスの構築時に読み取られていることは、リッチリザルトの仕組みからも明らかです。したがってGoogle側では、構造化データが何らかの形で処理される余地が残っています。
ChatGPT側は「知っていること」と「今回取りに行くこと」が別
ChatGPT側では、モデルが学習済みで内部に持っている知識と、回答を作るときにその場でWebから取得する情報が、別の仕組みで扱われます。OpenAIが公開しているクローラーの仕様を見ると、この分離がはっきりします。
| クローラー名 | OpenAIが示す用途 |
|---|---|
| OAI-SearchBot | ChatGPTの検索機能で、サイトを検索結果に表示するために使う |
| GPTBot | 基盤モデルの学習に使う可能性のあるコンテンツを収集する |
| ChatGPT-User | 利用者の操作に応じて、その場でページを訪問する |
3つは目的が別で、robots.txtでも個別に制御できます。重要なのは、「AIが自社を知っているか」と「今回の回答でどこから情報を取ったか」は別の話だという点です。この2つを分けずに「AIに効く施策」とひとまとめにすると、施策の当たり外れが読めなくなります。
LLMの内部に「グラフ」が置かれているわけではない
もう一段だけ内部の話に触れておきます。Googleのナレッジグラフのような「実体と関係の一覧表」が、LLMの中にそのまま格納されているわけではありません。
2024年の情報検索・知識管理系の国際会議CIKMで採択された研究（arXiv:2409.00617）は、言語モデル内部において、エンティティに関する知識と、エンティティ同士の関係に関する知識が、互いに転送・写像できないことを実験で示しました。さらに、関係の知識はモデルのMLP層の重みだけでなく注意機構にも有意にエンコードされており、知識の格納は先行研究が想定していたより複雑だと報告しています。
この研究はSEOの実験ではないため、施策の効果を直接語るものではありません。ただし「自社の情報をマークアップで書けば、その関係がそのままAIの中に登録される」というイメージが実態と合わないことは読み取れます（アイダイム分析）。だからこそ、後述するように、外部で観測できる情報の一貫性が効いてきます。
2026年の実測3件：構造化データはどこまで届いたか
ここからが本題です。取り上げるのは、Ahrefsの追跡調査、searchVIUの取得実験、そして当社の代行案件での観察という3件です。測っているものがそれぞれ違うため、勝ち負けの表にはしません。「何を測ったか」「何が起きたか」「何までは言えないか」で並べます。
| 実測 | 何を測ったか | 何が起きたか | 何までは言えないか |
|---|---|---|---|
| Ahrefs（2026年5月11日） | JSON-LDを追加した1,885ページと、対照4,000ページの引用数を前後30日で比較 | AI Overviews −4.6%、AI Mode +2.4%、ChatGPT +2.2% | 対象は既に引用されていたページのみ。まだ見つかっていないページへの効果は対象外 |
| searchVIU（2025年10月30日） | 5つのAIに同じページを直接取得させ、記述場所を変えて抽出できるかを検証 | JSON-LDにだけ書いた価格は5システム中0システムが抽出できず | 学習時・索引作成時の利用は否定していない。直接取得の場面に限った結果 |
| 当社の代行案件 | 構造化マークアップ代行を実施した案件の、その後の検索・AI側の反応 | 基本的には反応が変わる。順位と違い、ドメインの強さに縛られず取りに行ける | 案件ごとの条件を統制した比較実験ではない |
実測1｜既に見つかっているページに足しても、引用は動かなかった
SEOツールを提供するAhrefsは、2026年5月11日、JSON-LDを新たに追加した1,885ページを追跡した調査を公開しました（著者はLouise Linehan氏とXibeijia Guan氏）。対照群として条件を揃えた4,000ページを置き、追加日の前後30日で引用数を比較しています。
結果は、Google AI Overviewsが4.6%の減少（小さいながら統計的に有意）、Google AI Modeが2.4%増、ChatGPTが2.2%増でした。後者2つについて著者は、ゼロとの差を区別できない水準だと説明しています。
ここで読み違えてはいけないのが、対象ページの前提です。調査対象は2025年2月時点で既にAI Overviewsに100件以上引用されていたページ、つまりAIから見て「すでに発見済み」の集団でした。著者自身が、まだAIに見つかっていないページに構造化データが効くかどうかは本調査では答えられない、と明記しています。
したがってこの結果から言えるのは「構造化データは逆効果」ではなく、すでに引用されている状態からさらに引用を増やす手段としては期待できない、ということです。
実測2｜直接取りに来たとき、隠した記述は5つとも読まれなかった
ドイツのSEO監視ツールを手がけるsearchVIUは、2025年10月30日、ChatGPT・Claude・Gemini・Perplexity・Google AI Modeの5システムに対して8通りのシナリオを試す実験を行いました。同じページに対し、情報を可視テキストに置いた場合、JavaScriptで描画した場合、JSON-LDにだけ書いた場合などで、抽出できるかを比べる設計です。
注目すべきは、商品価格をJSON-LDにだけ記述し、ページ上のどこにも表示しなかったケースです。5システムのうち、この価格を取り出せたものはひとつもありませんでした。直接ページを取得する場面では、いずれも可視HTMLの内容だけを抽出し、JSON-LD・隠したMicrodata・隠したRDFaは無視されています。
ただし著者は、これがページを直接取得する段階の挙動であり、学習段階や検索インデックス作成の段階での利用まで否定した実験ではないと注記しています。とくにAI OverviewsやBing Copilotのように検索インデックスを持つ仕組みでは、構造化データが抽出されている可能性が高い、とも述べています。
この実験の実務的な含意は明快です。AIに拾ってほしい情報を、構造化データの中だけに書いてはいけません。ページに見える形で書き、構造化データはその内容と一致させる——先に挙げたGoogle公式の推奨と、まったく同じ結論に行き着きます。
実測3｜当社の代行案件では「基本的には変わる」
2つの調査だけを読むと、構造化データは無駄という結論になりかねません。しかし当社が構造化マークアップ代行として実施してきた案件では、実装後に検索・AI側の反応が変わるケースが基本線です（実務知見）。
この差は、Ahrefsの調査対象が「既に発見済みのページ」だったことと整合します。当社が扱うのは中小企業のサイトで、そもそもAIに十分認識されていない段階から着手することがほとんどです。出発点が違えば、同じ施策でも効き方が変わります。
もうひとつ、当社が重視している判断があります。検索順位はドメインの強さに大きく縛られますが、AIの引用はそこに縛られずに取りに行けるという点です（アイダイム分析）。被リンクの蓄積で大手に届かない中小企業にとって、実体を正しく整えるだけで候補に入れる領域が生まれたことになります。だからこそ、費用対効果の面でも取り組む価値があると判断しています。
なお、これは案件ごとの条件を統制した比較実験ではなく、現場での観察に基づく判断です。数値実験としてはAhrefsやsearchVIUの結果のほうが厳密であり、両者は対立するものではなく、見ている局面が違うと理解するのが正確です。
📌 自社の構造化データの実装状況や費用感を確認したい方へ。
→ 構造化マークアップ依頼の費用と相場
Q. 結局、構造化データは実装すべきなのですか
A. 実装は前提として整えたうえで、それ単体で引用が増えることは期待しない、という位置づけが実測に合っています。構造化データは「自社はこういう存在です」と申告する手段であり、申告内容がページの可視テキストや外部の情報と一致して初めて意味を持ちます。
なぜ「情報の矛盾」がエンティティ認識のリスクになるのか
AIは矛盾を調整せず、一貫した情報のほうを採る
AI検索で見落とされやすいのが、「情報の不足」ではなく「情報の不一致」が足を引っ張るという点です。自社サイト・Googleビジネスプロフィール・各種ポータルで社名や事業内容が食い違っていると、AIはその矛盾を自動では調整しません。より一貫性のある競合や第三者アグリゲータの情報が採用されやすくなります。
出所の検証が可視性を左右するという見方は、ベンダーの検証データにも表れています。AI検索プラットフォームのYextが公開した自社検証（W3C Verifiable Credentials準拠の「認定ブランドデータ」を用いたコントロールテスト）では、認定データの導入によりBingで35.4%、Yahooで37.2%のクリック増、Google Geminiで引用結果が9.2%増・可視性が最大9%増、従来のGoogle検索でも1.9%の改善が報告されています。ベンダー自身の実験である点には留意が必要ですが、出所を信頼シグナルとして扱う動きの一例です。
エンティティ強度には「事業形態」という前提がある
競合記事の多くは「構造化データを実装すればAIに認識される」と結びます。しかし実務では、構造化データはあくまで打ち手の一つに過ぎません（アイダイム分析）。それ以前に、エンティティとしての強度を左右する「事業形態」という土台があります。
たとえば、同じ施策を打っても、個人事業は法人に比べてエンティティ認識で不利になりやすい傾向があります（アイダイム分析）。法人格の有無、登記情報、第三者データベースでの一貫した記載といった「実在性の裏づけ」が、確かな実体だと判断される材料になるためです。構造化データを入れる前に、こうした基礎的な実在シグナルが揃っているかを見極めることが先決です。
次の比較表は、混同されやすい「構造化データ」と「データ検証（出所の認定）」の役割の違いを整理したものです。
| 観点 | 構造化データ | データ検証（出所の認定） |
|---|---|---|
| 役割 | 情報を機械可読な形にする | その情報の出所が信頼できるかを示す |
| 保証する内容 | 「何が書かれているか」の意味づけ | 「どこ由来で、一貫しているか」 |
| AI検索での働き | 抽出・理解を助ける | 採用するかどうかの判断に効く |
| 中小企業の実装 | Schema.orgマークアップ | NAP完全統一・権威あるサイテーション |
つまり、構造化データで「読ませる」だけでは足りず、出所の一貫性で「信じさせる」段階まで設計して初めて、土台が整います。
Q. データ検証と構造化データは何が違うのですか
A. 構造化データは「情報を機械が読める形にする」手段、データ検証は「その情報の出所が信頼できるかを示す」仕組みです。前者を実装しても出所が不一致だと、AIはより一貫した競合・第三者の情報を優先します。
Q. NAP情報が食い違うとAI検索で何が起きますか
A. AIは矛盾を自動で調整せず、より一貫した第三者情報を採用します。結果、誤った社名・住所・営業時間が「自社の事実」として定着し、訂正の機会がないまま顧客の判断材料になるおそれがあります。
こうした不一致を防ぐ手順を、次章で3ステップに分けて解説します。
中小企業のエンティティ設計3ステップ（棚卸し→一致→観測）
ステップ1｜最初に直すのはGoogleビジネスプロフィール
新規案件でエンティティの整合を点検するとき、当社が真っ先に開くのはGoogleビジネスプロフィールです（社内基準）。理由は単純で、ここが最も広く参照され、かつ自社で直せるからです。社名・住所・電話番号・営業時間・カテゴリのいずれかが古いまま放置されていれば、他をどれだけ整えても土台が崩れます。
点検の順番はGoogleビジネスプロフィール → 自社サイトの会社概要ページ → SNSのプロフィール欄です（社内基準）。この順で並べるのは、修正の影響範囲が大きい順であり、同時に修正の手間が小さい順でもあるためです。
教科書的には「すべて統一する」で終わる工程ですが、実務で不整合が最も出やすい場所には偏りがあります。当社で多くの案件を見てきた経験では、SNSのプロフィール欄と、自分の意図とは関係なく自動で情報が入ってしまう地図系——Yahoo!プレイスやApple Business Connectなどが要注意です（実務知見）。本人が更新したGoogleビジネスプロフィールは整っていても、こうした自動生成・第三者登録のデータが古いまま残り、矛盾の発生源になっているケースが少なくありません。
NAPと密接に関わるサイテーションの獲得方法は「サイテーションとは？SEOとの違いや獲得方法」で詳しく解説しています。
ステップ2｜可視テキストと構造化データを一致させる
棚卸しで拾った正しい情報を、3か所に同じ内容で通します。ページに見える本文、外部プロフィール、そして構造化データです。順番が大事で、構造化データは最後に、可視テキストに合わせて書くのが実測に沿った手順になります。
先のsearchVIUの実験が示したとおり、構造化データの中にしか書かれていない情報は、AIが直接ページを取りに来た場面では読まれませんでした。ここを取り違えて「構造化データに書いたから大丈夫」と考えると、そもそも情報が届きません。会社概要ページの本文に社名・所在地・事業内容を明記したうえで、同じ内容を構造化データにも記述する、という順序を守ってください。
実装面で注意が要るのは、既存サイトのテーマが自動生成する構造化データとの重複です（実務知見）。テーマ側が出力するスキーマと手動追加が競合すると、エラーや重複として扱われることがあります。当社では構造化マークアップ代行において、まず既存の出力状況を点検し、重複を避ける形で必要なものだけを追加する手順を取っています（実務知見）。
具体的な記述方法とコード例は「構造化データとは？SEOへの影響と記述例」、店舗・拠点向けの実装は「MEO対策で構造化マークアップが重要な理由」にまとめています。
ステップ3｜一次情報の出所を明示し、観測できる状態にする
最後が、自社にしか出せない一次情報を「誰が・いつ・どこで確認したか」まで添えて発信する設計です。運営者情報・著者情報・確認日時を明示することが、信頼の起点になります。Googleの品質評価ガイドラインでも、コンテンツの作成者や運営責任者を明確にすることが重視されています。
ここまで整えたら、次章の観測に進みます。エンティティ設計は一度実装して終わりではなく、ズレが再発していないかを定期的に見る前提の作業です。
著者性・運営者性の担保については「E-E-A-Tとは？SEOに重要な理由」もあわせてご覧ください。
Q. Yextのような専用ツールがなくてもエンティティ設計はできますか
A. できます。Googleビジネスプロフィールの完全整備、商工会議所や業界団体からの正確なサイテーション獲得、全WebアセットでのNAP完全統一が、中小企業にとって実質的な「認定データ」として機能します。
精度管理の視点で「検索に効いたのか、AI検索に効いたのか」を切り分ける
「検体情報一致確認」に相当する点検手順
観測の設計で有効なのが、臨床検査の精度管理（QC）の視点です（アイダイム分析）。臨床検査では、患者氏名・生年月日・ID番号が検体ラベル・依頼書・システムで一致していなければ、どれだけ精密に測定しても「正しい患者の結果」として扱えません。AI検索における自社情報も同じで、サイトとGoogleビジネスプロフィールと外部サービスで情報が一致しているかを、検体情報の照合と同じ要領で定期点検します。
次の表は、臨床検査の精度管理の考え方を、エンティティ設計の作業に対応づけたものです。
| 臨床検査の精度管理（QC） | エンティティ設計での対応 |
|---|---|
| 検体情報の一貫性の確認 | NAP整合（社名・住所・電話の一致） |
| 検体ラベルの出所記録 | 可視テキストと構造化データの一致 |
| 管理指標の継続測定 | トラフィック推移・表示回数・ブランド言及の継続観測 |
| 異常の検出と是正 | 自社ではなく競合だけが引用される状態の発見と修正 |
| 精度管理のサイクル | 定期的なエンティティ検証・更新 |
臨床検査と違い、AI引用には「正常範囲」のような普遍的な基準値が存在しません。そのため、絶対値の合否ではなく、自社の推移と競合との相対で異常を見つける形になります（アイダイム分析）。
見るべき指標は順位ではなくトラフィックの推移
エンティティ設計の効果を順位で追おうとすると、判断を誤ります。狙うクエリが少数のニッチ語に寄っていると、平均順位だけが良く見えて実際には流入がない、という状態が起こるためです。
当社が判断材料として最も信頼しているのは、Googleアナリティクスのトラフィック推移です（社内基準）。近年はAIエージェント経由の流入も区別して確認できるようになっており、検索経由で伸びたのか、AI側の参照が増えたのかを切り分けやすくなりました。順位ツールの上下より、実際に人が来ているかどうかで判定します。
あわせてSearch Consoleの表示回数を見ると、「検索側で拾われる範囲が広がったのか」が分かります。この2つを並べれば、Googleの検索に効いたのか、AI側の参照が動いたのかを、おおよそ切り分けられます。
効果が見え始めるまでの期間の目安
着手から動きが見え始めるまでは、体感で2週間かからない程度です（実務知見）。ただし判断は1か月見てからにするのが安全です（実務知見）。反映のタイミングは媒体ごとに前後するため、2週間時点の数字だけで打ち切ると、効いている施策を止めてしまうおそれがあります。
この期間感は、あくまで当社が扱う中小企業案件での目安です。サイト規模や元の整備状況によって前後します。
アイダイムのLLMO診断・GBP最適化実績
当社で実際にGoogleビジネスプロフィールを最適化した案件では、表示回数が約10倍に伸び、栃木県内の対象キーワードで1位を獲得した実績があります（自社検証／2026年時点）。この結果から言えるのは、専用ツールに頼らずとも、NAP整合とプロフィールの完全整備という基礎の徹底が、中小企業にとって実質的な「認定データ」として機能するということです。
📌 エンティティの定点観測・GBP最適化のご相談はこちら。
→ Googleビジネスプロフィール最適化
エンティティ設計のよくある質問
Q. 構造化データを実装したのにAIに引用されません。何が足りないのですか
A. まず、その情報がページの可視テキストにも書かれているかを確認してください。構造化データの中だけに書かれた記述は、AIがページを直接取得する場面では読まれないことが実験で確認されています。そのうえで、社名や事業内容が外部の情報源と食い違っていないかを点検します。
Q. FAQのリッチリザルトが廃止されましたが、構造化データは無駄になったのですか
A. 廃止されたのはGoogle検索でのFAQリッチリザルトの表示です（2026年5月7日付でドキュメントに非推奨表記が追加されました）。schema.orgのFAQPageという型そのものが無効になったわけではなく、マークアップを残しておいても問題はありません。表示上の見返りがなくなっただけで、記述の正しさが失われたわけではない、と切り分けてください。
Q. エンティティSEOとGEO・LLMO・AEOの違いは何ですか
A. GEO・LLMO・AEOはAI検索最適化の総称で、エンティティSEOはその土台となる「自社をAIに正しく認識させる」設計層です。総称の施策を回す前提として、エンティティの一貫性が必要になります。
Q. エンティティ設計の効果が出るまでどのくらいかかりますか
A. 当社の案件では、着手から2週間かからない程度で動きが見え始めることが多く、判断は1か月見てから行っています。見る指標は順位ではなくトラフィックの推移です。
参考情報
- Ahrefs「We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.」Louise Linehan・Xibeijia Guan, 2026/05/11
- searchVIU「Schema Markup and AI in 2025: What ChatGPT, Claude, Perplexity & Gemini Really See」2025/10/30
- Google検索セントラル「AI機能とサイト」（最終更新 2025/12/10）
- OpenAI「Bots」（OAI-SearchBot / GPTBot / ChatGPT-User の仕様）
- Wei Y. ほか「Does Knowledge Localization Hold True? Surprising Differences Between Entity and Relation Perspectives in Language Models」CIKM 2024（arXiv:2409.00617）
- TechRadar「How AI search is shifting brand visibility from SEO to data verification」Sam Davis（Yext）, 2026/05/20
- Yext「New Yext Research: Brand Certified Facts」（認定ブランドデータの検証結果／2026年）
