エンティティSEOとは？会社と著者を取り違えられないための整え方

社名で検索したら、右側に同じ名前の別の会社の情報が出てきた。代表者の名前で調べると、同姓同名の人の経歴が混ざっている。英語名と日本語名で、まるで別の会社のように扱われている。

こうしたずれを直すのがエンティティSEOです。エンティティSEOとは、会社や人物、商品などを検索エンジンが1つの「実体（エンティティ）」として見分け、同じ名前のほかのものと取り違えずに理解できるように、サイトの内外にある情報をそろえる取り組みです。

エンティティSEOはマークアップの技術ではありません。「自分たちは誰か」をサイトの内外で一貫させる情報設計です。構造化データはその内容を機械に伝える補助で、AIに引用させるための近道ではありません。

CONTENTS

エンティティとは？キーワードとの違い
エンティティSEOの全体像は？4つの取り組み
ナレッジグラフとナレッジパネルはどう作られる？
AI時代になぜエンティティが大事になるのか？
自社サイトで何を伝える？Organization と Person の設計
サイトの外で何をそろえる？NAP・sameAs・公開データベース
Googleにどう認識されているかを確かめる方法は？
名前と表記を決めるのが先
まとめ

エンティティとは？キーワードとの違い

エンティティは「ほかと区別できる1つのもの」を指します。会社、人物、場所、商品、作品などがそうです。検索エンジンは入力された文字列に一致するページを探すだけでなく、その言葉がどの実体を指しているかを見分けたうえで結果を返しています。

Googleがこの考え方をはっきり打ち出したのは、2012年5月のナレッジグラフの発表です。公式ブログでは「things, not strings（文字列ではなく、もの）」という言葉で説明されました。例に挙げられたのは「taj mahal」という検索で、インドの霊廟のことか、同じ名前のミュージシャンやカジノ、近所のレストランのことかを見分ける必要がある、というものです。発表時点でナレッジグラフには5億を超えるオブジェクトと、35億を超える事実や関係が入っていたと書かれています。

観点	キーワード	エンティティ
単位	入力された文字列	文字列が指している実体
同じ名前が複数あるとき	区別できない	別々のものとして扱う
表記ゆれ（略称・英語名）	別の文字列になる	同じ実体の別名としてまとまる
つながり	語と語の共起	実体どうしの関係（創業者、所在地、所属など）

サイト運営者にとって困るのは、自社が別の実体と混同されたり、1つの会社が複数の実体に分かれて扱われたりすることです。社名が一般的な言葉だったり、同じ名前の会社がほかの地域にあったり、英語名と日本語名がばらばらに使われていたりすると起きやすくなります。ナレッジグラフそのものの仕組みはナレッジグラフとは？検索結果とAI回答への影響で扱います。

「エンティティ」という言葉は、コンテンツの中で扱うトピックや概念の意味で使われることもあります。この記事が扱うのは会社や著者として取り違えられないための整備で、テーマを網羅して専門性を示す考え方はトピカルオーソリティとはで扱います。

エンティティSEOの全体像は？4つの取り組み

エンティティSEOでやることは、名前と表記を決める、自社サイトで伝える、サイトの外でそろえる、認識を確かめる、の4つに分けられます。前の3つは自社で決めて動かせる部分、最後の1つは外からの見え方を確かめる部分です。

図1エンティティSEOの4つの取り組みと、自社で動かせる範囲

正式名、略称、英語表記、代表者名や著者名の書き方を1つに決める
会社概要ページと著者ページに情報を集め、構造化データで同じ内容を伝える
公式SNS、Googleビジネスプロフィール、業界のディレクトリなどで名称・所在地・連絡先をそろえる
社名や人名で検索したときの表示や、ナレッジグラフへの登録状況を確認する

困っていることがはっきりしているなら、深掘りの記事から読んでもかまいません。

社名で検索したときに右側のパネルを出したい、直したい → ナレッジパネルを表示させる方法
会社情報や sameAs、Wikidata の整え方を手順で知りたい → 組織情報の一貫性設計（NAP・sameAs・Wikidata登録）

ナレッジグラフとナレッジパネルはどう作られる？

ナレッジグラフは、ウェブ上の公開情報、スポーツの成績や株価、天気のようにデータ提供元とのライセンス契約で集める情報、本人や公式の代表者から寄せられる情報をもとに作られています（ナレッジパネルヘルプ「Google のナレッジグラフの仕組み」）。検索結果の横などに出るナレッジパネルは、ウェブ上に十分な情報があるときに自動で作られ、誤りは正式な代表者でなくても、画面のフィードバックから誰でも報告できます。お金を払って出すものでも、申請すれば出るものでもありません。

図2ナレッジグラフは3つの情報源から作られ、検索結果の表示とAIモードで使われる

パネルに載っている人物や組織の本人、または正式な代表者は、Googleの認証を受けて変更を提案できます。認証では、YouTubeやSearch Console、公式のSNSなど、本人のものと確認できるアカウントにログインします。ただし、認証で得られるのは提案する権限です。提案がそのまま反映される保証はなく、パネルが無い状態から表示させる手続きでもありません。

サイト運営者が働きかけられるのは、図2のうち「ウェブ上の公開情報」と「本人からの情報」の2つです。自社サイトや公式プロフィールに正確な情報を置き、誤りがあればフィードバックや認証を通じて伝える。できるのはこの範囲です。認証の手順や表示された実例はナレッジパネルを表示させる方法で扱っています。

AI時代になぜエンティティが大事になるのか？

Googleは、AIモードがナレッジグラフを情報源の1つとして使うと説明しています。AIの回答でも「どの会社の、誰の話か」を見分けることが前提になるので、取り違えられない状態をつくる意味が大きくなっています。

AIモードを発表した2025年3月5日の公式ブログには、ウェブのコンテンツに加えて、ナレッジグラフのようなリアルタイムの情報源も使えると書かれています。また、AI Overviews（AIによる概要）やAIモードは通常の検索と同じランキングと品質の仕組みの上に作られている、というのが公式ガイド「Optimizing your website for generative AI features on Google Search」（2026年7月10日更新）の説明です。エンティティの理解は、この土台の一部にあたります。

「構造化データを入れるとAIに引用されやすくなる」という説明も見かけますが、同じ公式ガイドは、生成AI検索のために構造化データは必要なく、追加すべき特別な schema.org のマークアップもないと明言しています。llms.txt も、Google検索は使っていません。構造化データの価値はリッチリザルトの対象になることや、ページの内容をGoogleが理解しやすくなることにあり、Google検索に限れば、AIの回答に関わるのは会社や人物が正しく見分けられている状態のほうです。

ChatGPTやPerplexityなどGoogle以外のAIについては、エンティティをどう扱っているかを各社が公式に説明していません。これらのサービスも回答の多くをウェブ上の情報から作るので、社名や人名の表記がそろい、公式の情報がはっきりしているほど、別の会社と混同されたり古い情報を答えられたりする余地は小さくなると考えます。ただし、効果を示す公表データはまだありません。AIが回答を作る仕組みの全体は LLMO（AI検索最適化）とは？にまとめています。

自社サイトで何を伝える？Organization と Person の設計

会社の情報はトップページか会社概要ページに、著者の情報は著者ページに集めます。そのうえで、ページに書いた内容と同じことを構造化データで伝えます。先にページの中身があり、構造化データはそれを機械向けに言い直したものです。

会社の情報（Organization）

Google検索セントラルの「Organization structured data」は、組織の構造化データをトップページに加えると、Googleが組織の管理上の情報を理解し、検索結果でほかの組織と区別する助けになると説明しています。置き場所はトップページか、組織を説明する1ページ（会社概要など）でよく、サイト全体に入れる必要はありません。必須のプロパティは無く、当てはまるものをできるだけ加えるよう勧めています。

プロパティ	伝えること
name／alternateName	正式名と、略称・英語名などの別名
url	公式サイトのURL
logo	検索結果やナレッジパネルに使われうるロゴ（112×112px以上）
sameAs	公式SNSや口コミサイトなど、ほかのサイトにある自社のプロフィール
address／contactPoint／telephone／email	所在地と連絡先
iso6523Code・duns・leiCode・vatID・taxID など	国際的な識別子や、法人番号にあたる番号
foundingDate／numberOfEmployees／description	設立日、従業員数、事業の説明

識別子のようにほかの組織と区別するために裏側で使われるプロパティもあれば、ロゴのように検索結果やナレッジパネルの見た目に関わるものもある、とドキュメントには書かれています。サイト名は別のドキュメントで、トップページで使う名前をそろえること、略称などは alternateName で示せることが説明されています。

著者の情報（Person）

記事の著者は、Article 構造化データの author に Person として書き、著者ページのURLを url に、ほかのサイトにある本人のプロフィールを sameAs に入れます。著者ページそのものには ProfilePage 構造化データを使えます。name に肩書きを混ぜない、著者を全員書くといった書き方の決まりは E-E-A-Tとは？の著者情報の章にまとめているので、ここでは繰り返しません。

エンティティの面から付け加えたいのは、Person は実在する1人の人として、サイトの内外で同じ名前と同じ経歴で語られている必要があるということです。Googleは2026年10月、有用なコンテンツのガイドに、AIで生成した顔写真や架空の名前、偽りの資格で作り手のプロフィールをでっち上げることは欺瞞の一種で、ページを信頼できないものにすると書き加えました。マークアップをどれだけ整えても、指している人が実在しなければ意味がありません。

構造化データには、ページに表示されていない内容を書かないことも大切です。Googleの一般ガイドラインは、読者に見えない内容をマークアップしないよう定めています。会社概要ページに所在地が書かれていないのに、構造化データにだけ住所を入れるといった書き方は避けてください。

会社と著者と記事をつなぐ最小の例は次のとおりです（URL や名前は架空です）。会社と著者にそれぞれ @id を付け、記事の author と publisher からその @id を指します。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.co.jp/#organization",
      "name": "株式会社サンプル",
      "alternateName": "Sample Inc.",
      "url": "https://example.co.jp/",
      "logo": "https://example.co.jp/images/logo.png",
      "sameAs": ["https://x.com/sample_inc", "https://www.linkedin.com/company/sample-inc/"]
    },
    {
      "@type": "Person",
      "@id": "https://example.co.jp/author/yamada/#person",
      "name": "山田花子",
      "url": "https://example.co.jp/author/yamada/"
    },
    {
      "@type": "Article",
      "headline": "記事のタイトル",
      "datePublished": "2026-10-23T09:00:00+09:00",
      "author": { "@id": "https://example.co.jp/author/yamada/#person" },
      "publisher": { "@id": "https://example.co.jp/#organization" }
    }
  ]
}

図3サイトの中は@idでつなぎ、サイトの外の公式プロフィールはsameAsで指す

COCORO Pulse.も同じ考え方で構造化データを設計しています。トップページでは WebSite と Organization を、記事ページでは Article、BreadcrumbList、Person、Organization を出力し、Article の author と publisher は Person と Organization の @id を参照する形でつないでいます。著者の sameAs は、著者プロフィールに登録した関連リンクから出力します。

SEOプラグインの構造化データ出力は使わず、テーマの1か所だけから出しています。同じ組織が別々の書き方で二重に出力されるのを避けるためです。著者は実名です。

ほかのプロパティの書き方や、リッチリザルトテストでの検証方法は構造化データとは？種類・実装方法・AI検索への影響で扱っています。

サイトの外で何をそろえる？NAP・sameAs・公開データベース

サイトの外では、名称・所在地・連絡先（NAP）を公式プロフィールどうしでそろえ、sameAs で指す先を本当に自社が管理しているものに絞ります。Wikidataのような公開データベースや第三者の言及は、自分で作り込むものではなく、事業の実態から生まれるものとして扱います。

名称・所在地・連絡先をそろえる

Googleビジネスプロフィール、公式SNS、業界のディレクトリや求人サイトなど、自社の情報が載っている場所を一覧にし、表記を1つに寄せます。移転や社名変更のあとは古い情報が残りやすいので、変更時の更新先リストを作っておくと管理が楽になります。

sameAs で指す先を選ぶ

schema.org は sameAs を「その実体が何であるかを曖昧さなく示す参照ページのURL」と定義し、例として Wikipedia の記事、Wikidata の項目、公式サイトを挙げています。Googleの Organization のドキュメントでは、SNSや口コミサイトにある組織のプロフィールページが例に挙がっています。

自社が運営している公式アカウントやプロフィールページ
自社について書かれた Wikipedia の記事や Wikidata の項目（すでに存在する場合）

一方、自社について触れているだけのニュース記事やブログ記事、運用をやめたアカウント、同じ名前の別の会社のページは指しません。並べるほど、どれが公式かがかえってわかりにくくなります。

公開データベースと第三者の言及

Wikidata には掲載基準があり、ウィキメディアのほかのプロジェクトに記事があること、信頼できる公開の情報源で説明できる実体であること、ほかの項目の記述に構造上必要であること、のいずれかを満たす必要があります。自社を説明する情報源がまだ無い段階で、登録だけを急いでも意味はありません。

第三者による言及も同じです。Googleは生成AI機能向けの公式ガイドで、不自然な形でウェブ上の言及を集めても思ったほどの役には立たないとしています。言及は事業や発信の結果として生まれるもので、施策として作るものではありません。

リンクのない言及の価値はサイテーションとは？で扱います。

Googleにどう認識されているかを確かめる方法は？

現状をつかむ方法は2つあります。社名や人名で検索してナレッジパネルの有無と内容を見ることと、Knowledge Graph Search API でナレッジグラフに登録されている実体を調べることです。施策を足す前に、まず今どう見えているかを確かめます。

検索結果とナレッジパネルを見る

正式名、略称、英語名、代表者名などで検索し、ナレッジパネルが出るか、出る場合に内容が正しいかを確認します。同じ名前の別の会社のパネルが出るなら、取り違えが起きているサインです。誤りを見つけたらパネルのフィードバックから報告でき、本人や正式な代表者であれば認証を受けて変更を提案できます。

Knowledge Graph Search API で調べる

Knowledge Graph Search API は、Googleが開発者向けに公開しているAPIで、APIキーを付けて名前で検索すると、ナレッジグラフに登録されている実体のIDや名前、型（Organization、Person など）が schema.org に沿った JSON-LD で返ってきます。自社や著者が実体として登録されているか、どの型で見られているかを確かめるための道具で、検索順位やAIの回答での扱われ方まではわかりません。読み取り専用で本番のサービスで頼る用途には向かないとされ、新しく使う人には Cloud Enterprise Knowledge Graph を案内しているので、現状をスポットで確かめるときに使います。

名前と表記を決めるのが先

最初に決めるのは名前と表記です。次に会社概要ページと著者ページを整え、そのあとで構造化データ、最後にサイトの外のプロフィールへ広げます。構造化データから手を付けると、ページとマークアップと外部の情報がずれたまま固まりがちです。

構造化データより先に名前とページを整えるのは、マークアップがページに書いた「誰か」を言い直すものにすぎないからです。

順番	やること	次に進む目安
1 名前と表記	正式名、略称、英語表記、代表者名・著者名の書き方を決め、社内で共有する	表記の一覧が1枚にまとまっている
2 ページ	会社概要ページと著者ページに、名称・所在地・連絡先・事業内容・経歴を書く	ページを読めば「誰か」が特定できる
3 構造化データ	Organization と Person を、ページの内容と一致させて出力する。sameAs は公式プロフィールだけ	出力が1か所にまとまり、テストでエラーがない
4 サイトの外	公式SNS、Googleビジネスプロフィール、ディレクトリの表記をそろえ、変更時の更新先リストを作る	検索して出てくる公式情報に食い違いがない
5 確認	社名・人名での検索結果、ナレッジパネル、Knowledge Graph Search API を定期的に見る	取り違えや古い情報に気づける

エンティティSEOを進める順番

よくある誤解

構造化データを入れればナレッジパネルが出る、というのは誤解です。パネルは十分な情報があるときに自動で作られ、Googleは構造化データを使う機能が表示されることを保証しないと明記しています
sameAs はたくさん並べたほうがよいわけではありません。自社のものと言えないURLを並べると、どれが公式かがかえってわかりにくくなります
百科事典の項目や言及を自分で増やしても認知は得られません。Wikidata は掲載基準を満たさない項目を受け入れませんし、不自然な言及は役に立たないとGoogleは述べています

エンティティの整備は、LLMO対策の4つの領域のうち「エンティティと自然な評判」にあたります。

まとめ

エンティティSEOは、会社や人物を検索エンジンが取り違えずに見分けられるよう、サイトの内外の情報をそろえる取り組みです
AI時代に意味が増すのは、GoogleのAIモードがナレッジグラフを情報源の1つとして使うからです。要るのはマークアップの追加より、取り違えられない状態です
名前と表記を決め、会社概要・著者ページを整え、構造化データ、サイトの外の順に進めます

参考にした一次情報

Introducing the Knowledge Graph: things, not strings Google 公式ブログ・2012-05-16
Expanding AI Overviews and introducing AI Mode Google 公式ブログ・2025-03-05、確認日 2026-10-23
Google のナレッジグラフの仕組みナレッジパネルヘルプ・確認日 2026-10-23
Google の認証を受けるナレッジパネルヘルプ・確認日 2026-10-23
Optimizing your website for generative AI features on Google Search Google Search Central・最終更新 2026-07-10、確認日 2026-10-23
Creating helpful, reliable, people-first content Google Search Central・最終更新 2026-10-05、確認日 2026-10-23
Organization (Organization) structured data Google Search Central・最終更新 2026-09-08、確認日 2026-10-23
Article (Article, NewsArticle, BlogPosting) structured data Google Search Central・最終更新 2026-09-08、確認日 2026-10-23
Profile page (ProfilePage) structured data Google Search Central・最終更新 2026-09-08、確認日 2026-10-23
Introduction to structured data markup in Google Search Google Search Central・最終更新 2025-12-10
General structured data guidelines Google Search Central・最終更新 2026-07-10、確認日 2026-10-23
Provide a site name to Google Search Google Search Central・最終更新 2025-12-10、確認日 2026-10-23
Knowledge Graph Search API Google for Developers・最終更新 2024-04-26、確認日 2026-10-23
Method: entities.search Google for Developers・最終更新 2024-06-26
Authorize requests and identify your application Google for Developers・Knowledge Graph Search API、確認日 2026-10-23
sameAs Schema.org・確認日 2026-10-23
Wikidata:Notability Wikidata・確認日 2026-10-23