エンティティSEOとは、検索エンジンに対して「誰が」「何について」書いているかという情報の実体（エンティティ）と、その関係性を正しく伝えるためのSEO対策です。文字列としてのキーワードを詰め込む発想ではなく、Googleが持つナレッジグラフに自社を1つの実体として認識させ、指名検索やナレッジパネルにつなげる考え方を指します。この記事では、キーワードSEOとの違い、JSON-LDによる構造化データのコード例、表記統一と外部データベースへの接続、Wikidata APIやリッチリザルトテストでの認識確認、そしてナレッジパネルやサーチコンソールでの効果測定までを、2026年10月時点の公式ドキュメントにもとづき、実装できる粒度で説明します。
まとめ：エンティティSEOは構造化データと表記統一で実体を伝える施策
エンティティSEOの要点は3つに絞れます。第一に、検索エンジンは単語の一致ではなく実体とその関係性で情報を理解しているため、自社が「何者で何に詳しいか」を機械可読な形で提示すること。第二に、JSON-LDによる構造化データで組織・人物・記事を記述し、@idで3つを結んだうえで、sameAsやknowsAboutで外部の権威あるエンティティと結び付けること。第三に、社名・サービス名・著者名の表記をサイト全体で統一し、Wikipediaや業界データベースなど外部からの言及を積み上げることです。
成果はナレッジパネルの表示、指名検索の増加、AI検索での引用として現れます。ただし構造化データを入れるだけで順位が動くわけではありません。実体としての一貫性と外部からの評価がそろって初めて機能します。実装後はリッチリザルトテストで構文を、Wikidata APIやナレッジグラフAPIで実体の登録状況を確かめ、月次で指名検索の推移を追います。まず着手すべきは、指名検索が発生しているブランドや、E-E-A-Tが順位を左右する専門領域を持つ事業者です。
エンティティSEOとは何か：キーワードSEOとの根本的な考え方の違い
エンティティSEOを理解する出発点は、検索エンジンの情報の捉え方が「文字列」から「実体」へ移った点にあります。従来のキーワードSEOと何がどう違うのかを整理します。SEO対策全体の基礎を先に押さえたい場合はSEO対策とは？仕組みと施策の進め方もあわせて参照してください。
キーワード一致から実体の理解へ移行した検索エンジン側の評価軸
Googleは2012年5月にナレッジグラフを発表し、その公式ブログの題名で「things, not strings（文字列ではなく実体）」という方針を掲げました。それ以前の検索は、ページ内にクエリと同じ単語が何回出るかを手がかりにしていました。現在は、ある語が指し示す対象を一意の実体として識別し、その実体が他の実体とどうつながっているかで文脈を判断します。
たとえば「一創」という語だけでは、企業なのか一般名詞なのか機械には判別できません。エンティティSEOは、この曖昧さを構造化データと文脈で解消し、対象を確定させる作業です。単語の出現頻度を上げる発想とは目的が異なります。
| 観点 | キーワードSEO | エンティティSEO |
|---|---|---|
| 評価の単位 | 単語・文字列 | 実体と関係性 |
| 主な手段 | 語句の配置・網羅 | 構造化データ・表記統一 |
| ゴール | 個別クエリの順位 | 実体としての認知 |
| 成果の現れ方 | 検索順位 | ナレッジパネル・指名検索 |
| 確認の手段 | 順位計測ツール | ナレッジパネル・API照会 |
両者は排他ではありません。個々のページはキーワードの検索意図に答えつつ、サイト全体では実体を強化する、という二層で設計します。
生成AI検索とゼロクリック時代にエンティティSEOが持つ意味
AI OverviewやAIチャットは、回答を生成する際に「信頼できる実体」を参照します。実体として認識されていない事業者は、そもそも引用候補に入りにくいのが実態です。検索結果画面だけで完結し、クリックが発生しないゼロクリック検索が増えるほど、順位より「AIに実体として選ばれること」の比重が上がります。
自社がAIに引用されるための記事構造についてはAI Overview対策とはで扱っていますが、その土台になるのがエンティティの明確化です。AI検索が1つの質問を複数の検索に分解して情報を集める仕組みはクエリファンアウトの解説で補足しています。分解された検索のどれで拾われても同じ発信者だと判別できることが、引用の積み上げにつながります。何者かが定まらない発信者は、生成AIにとって参照しづらい情報源です。
検索エンジンがエンティティを実体として認識する仕組みとナレッジグラフ
実装に入る前に、Googleが実体をどう蓄積し表示に反映するのかを押さえます。仕組みを理解すると、どの施策がどこに効くかの見極めが可能です。ナレッジグラフとエンティティの関係を概念面から深く知りたい場合はGoogleのナレッジグラフとエンティティSEOの関係が背景の解説になります。
Googleナレッジグラフとナレッジパネルが生成・表示される流れ
ナレッジグラフは、実体（人物・組織・場所・概念など）と、その属性・相互関係を蓄えた大規模データベースです。Googleは公開情報、構造化データ、Wikipediaやウィキデータなどの権威あるソースから実体情報を収集し、確度が一定を超えた実体について、検索結果の右側などにナレッジパネルを生成します。
ナレッジパネルは自分で直接作るものではありません。複数の信頼できる情報源が同じ実体について一致した情報を示したとき、その集約として表示されます。だからこそ、自社サイト内の記述と外部の言及を食い違わせないことが、表示に向けた前提です。パネルの表示条件や申請の流れはナレッジパネルの仕組みと認証の申請手順で詳しく扱っています。
実体を一意に識別するエンティティIDと関連性のネットワーク構造
ナレッジグラフ内の各実体には、機械可読な識別子が割り当てられています。Googleのナレッジグラフではkg:/m/0dl567のような形式のIDで、ウィキデータではQ53268（トヨタ自動車）のようなQ番号です。これらを軸に「勤務先」「創業者」「提供サービス」といった関係が線でつながり、検索エンジンはこの関係のネットワークをたどって文脈を補完します。
自社を強い実体にするとは、このネットワーク上で自社ノードの接続を増やし、確からしさを高めることに等しくなります。孤立したページをいくら量産しても、実体のネットワークには反映されにくいのが実情です。
エンティティSEOの実装手順1：JSON-LDで組織と著者を書いてsameAsで結ぶ
ここからが本記事の核心です。エンティティを機械に伝える主役は、Schema.org語彙にもとづく構造化データで、Googleは構造化データの概要ドキュメントでJSON-LDを推奨形式に挙げています。組織・人物・記事の3種を書き、互いを@idで参照させるのが基本形です。
組織・人物・記事の3種を@idでつなぐJSON-LDの全体設計
まず自社サイトのトップページや会社概要に、組織を表すOrganizationを配置します。社名、ロゴ、公式サイトURL、問い合わせ先を記述し、これが自社という実体の起点になります。記事ページにはArticle、書き手にはPersonを割り当てるのが、著者を機械に明示する基本形です。
3種を別々に書くだけでは、同じ組織が複数あるように見えることがあります。そこで組織に"@id": "https://example.co.jp/#organization"のような固有のIDを与え、記事のpublisherや著者のworksForから同じIDを参照させます。IDはURLの形をしていれば実在ページである必要はありませんが、サイト全体で固定した1つの値を使う設計です。JSON-LDはHTMLの本文と分離してscriptタグ内に書けるため、デザインを崩さず追加できます。
| 型 | 置くページ | 主なプロパティ |
|---|---|---|
| Organization | トップ・会社概要 | name・url・logo・sameAs |
| Person | 著者プロフィール | name・url・worksFor |
| Article | 各記事 | headline・author・publisher |
Organization：name・logo・sameAs・knowsAboutの記述例
GoogleのOrganizationの構造化データ（2026年9月8日更新版）では必須プロパティは定められておらず、関連するプロパティをできるだけ多く書くよう推奨されています。配置先はホームページか、会社概要のように組織を説明する1ページです。ロゴは112×112px以上と記載されています。次の例は会社概要ページの<head>内にそのまま貼れる形です。値は自社のものに置き換えてください。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.co.jp/#organization",
"name": "株式会社サンプル",
"alternateName": "Sample Inc.",
"url": "https://example.co.jp/",
"logo": "https://example.co.jp/images/logo-512.png",
"foundingDate": "2015-04-01",
"address": {
"@type": "PostalAddress",
"addressCountry": "JP",
"addressRegion": "東京都",
"addressLocality": "千代田区"
},
"sameAs": [
"https://www.wikidata.org/wiki/Q00000000",
"https://x.com/sample_inc",
"https://www.linkedin.com/company/sample-inc/"
],
"knowsAbout": ["Webシステム開発", "AI開発", "クラウドインフラ構築"]
}
</script>sameAsのQ00000000は仮の値です。ウィキデータに自社の項目が無い場合は、その行ごと削除します。存在しないQ番号や他社の項目を書くと、実体の取り違えを招きます。
ArticleとPersonのコード例：著者プロフィールページへ@idで結ぶ
記事側では、GoogleのArticleの構造化データが案内するとおり、authorに著者名とプロフィールページのURLを記述します。著者のプロフィールページ自体にはProfilePageの構造化データを置き、mainEntityに同じPersonを書くと、記事と著者ページが同じ人物を指していることが機械に伝わります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "エンティティSEOとは？構造化データで実体を伝える実装手順",
"datePublished": "2026-10-01T09:00:00+09:00",
"dateModified": "2026-10-01T09:00:00+09:00",
"author": {
"@type": "Person",
"@id": "https://example.co.jp/author/yamada/#person",
"name": "山田 太郎",
"url": "https://example.co.jp/author/yamada/",
"worksFor": { "@id": "https://example.co.jp/#organization" }
},
"publisher": { "@id": "https://example.co.jp/#organization" }
}
</script>ポイントはpublisherとworksForが、前のコード例で組織に与えた@idと完全に同じ文字列になっている点です。末尾のスラッシュやwwwの有無が1文字でも違うと別のIDとして扱われるため、テンプレートで一元管理します。WordPressならテーマや構造化データ系プラグインの出力と重複していないかも確認します。
sameAsとknowsAboutに書いてよい値と書いてはいけない値
schema.orgのsameAsは、その実体の身元を明確に示す参照ページのURLを指すプロパティです。公式のWikipedia、ウィキデータ、主要SNS、業界団体の会員ページなどを列挙すると、Googleは「このサイトの発信者は、これらの外部エンティティと同一だ」と解釈しやすくなります。バラバラに存在していた言及が一本の実体に束ねられます。
schema.orgのknowsAboutは、その組織や人物が何に精通しているかを示し、テキストのほか実体やURLも値に取れます。受託開発会社なら「Webシステム開発」「AI開発」といった専門領域を記述し、E-E-A-Tの専門性を機械可読な形で補強します。ただし2026年9月時点のGoogleのOrganizationドキュメントの推奨プロパティ一覧にknowsAboutは含まれていません。Googleが表示に使うと明言した項目ではないため、書いても直接の効果を約束するものではない、という前提で扱います。
- 書いてよい：自社が管理する公式SNS、自社のウィキデータ項目、会員として掲載されている業界団体ページ
- 書いてはいけない：他社や同名別法人の項目、取材記事や口コミサイトの個別記事、実績の無い専門領域
- 迷ったら外す：自社が編集権を持たず、内容の正確さを保証できないページ
Googleの構造化データに関する一般的なガイドラインは、ページの内容を表していないマークアップや誤解を招くマークアップを禁じています。プロパティは一度に全部入れず、事実として裏付けられる範囲に限定します。
エンティティSEOの実装手順2：テストとAPIで実体の認識状況を検証する
コードを書いたら、構文が正しいか、そしてGoogleやウィキデータ側で実体がどう登録されているかを確かめます。前者はテストツール、後者はAPIへの照会によって、それぞれ確認が可能です。自社で設計と検証まで書き切るのが難しい場合は、一創のSEO内部施策・キーワード設計で構造化データの設計から検証・運用まで支援しています。
リッチリザルトテストとSchema Markup Validatorで構文と値を確かめる
構造化データは、記述してからGoogleのリッチリザルトテストとサーチコンソールの拡張レポートで必ず検証します。リッチリザルトテストはGoogleが対応する型の検出と警告を返し、Schema Markup ValidatorはGoogleが対応していない型やプロパティも含めてSchema.orgの語彙として正しいかを返します。knowsAboutのようにGoogleの対応表に無いプロパティの確認先は、後者のツールです。プロパティ名のつづり誤りや必須項目の欠落があると、Googleに無視されるか警告が出る扱いです。反映は即時ではなく、再クロールを待つ期間が生じます。
検証で見るのは3点です。構文エラーがないか、本文の記述内容とJSON-LDの値が一致しているか、そして実在しない受賞歴や資格を書いていないか。構造化データと本文の乖離は、スパム扱いのリスクになります。
- リッチリザルトテストとSchema Markup Validatorで構文エラーの有無を確認する
- サーチコンソールの拡張レポートで警告数の推移を追う
- 本文とJSON-LDの記述内容が食い違っていないか照合する
- 組織の
@idが全ページで同じ文字列になっているかを抽出して比べる
この検証を挟まないまま公開すると、誤った実体情報を発信し続ける事故につながります。
Wikidata APIで自社や競合がエンティティ登録済みか調べる手順
ウィキデータに自社の項目があるかは、Wikidata APIのwbsearchentitiesで調べられます。APIキーは不要です。次のコマンドは、2026年10月1日に実行して結果を確認したものです。
curl -s -G "https://www.wikidata.org/w/api.php" \
--data-urlencode "action=wbsearchentities" \
--data-urlencode "search=Toyota" \
-d "language=ja" -d "uselang=ja" -d "type=item" \
-d "limit=1" -d "format=json"返ってきたJSONの主要部分は次のとおりです。idがQ番号、descriptionが日本語の説明文です。
{
"id": "Q53268",
"concepturi": "http://www.wikidata.org/entity/Q53268",
"label": "トヨタ自動車",
"description": "愛知県豊田市にある自動車メーカー"
}自社名でsearchが空配列になれば、ウィキデータには未登録です。同名の別法人が返ってきた場合は、sameAsにそのQ番号を書かないよう注意します。競合の社名でも同じ照会をすると、同業他社のうち実体として登録済みの企業がどこかを把握できます。
ナレッジグラフAPIでGoogle側の実体IDとresultScoreを確かめる
Google側の登録状況は、GoogleナレッジグラフのAPIで照会できます。Google Cloudで発行したAPIキーが必要です。
curl -s -G "https://kgsearch.googleapis.com/v1/entities:search" \
--data-urlencode "query=株式会社サンプル" \
-d "languages=ja" -d "limit=3" -d "indent=true" \
-d "key=YOUR_API_KEY"応答の@idにkg:/m/…形式の実体IDが、resultScoreに一致度が入ります。自社名で結果が返らなければ、Googleのナレッジグラフ上では実体として確立していないと判断できます。パラメータの全体を確認できる資料は、APIリファレンスです。なお公式ドキュメント（2024年4月26日更新版）は、このAPIが読み取り専用であること、本番環境の重要なサービスが依存すべきではないこと、後継サービスへの移行が進んでいることを明記しています。定期的な確認に使う程度にとどめ、自社システムの機能をこのAPIに依存させない設計が安全です。
エンティティを強化する表記統一と外部データベースへの接続の進め方
構造化データは入口にすぎません。実体としての確からしさは、サイト内外の情報が一致していることで積み上がります。技術的な実装と並行して進める運用面を説明します。
社名・サービス名・著者情報の表記ゆれを全ページで統一する手順
「株式会社一創」「一創」「ISSOH」のように表記が揺れていると、機械は同一実体だと確信を持てません。正式名称を1つ決め、フッター、会社概要、著者プロフィール、構造化データの値をすべて同じ表記にそろえます。英語表記やロゴのalt属性も対象です。英語名や略称を使う場合は、前述のコード例のようにalternateNameへ明示すると、揺れではなく別名として扱われます。
著者情報も同様に統一します。同じ書き手が記事ごとに別プロフィールになっていると、著者という実体が分散した状態です。プロフィールページを1枚に集約し、各記事のPersonから同じURLと同じ@idへ結ぶのが実務上の起点になります。
Wikipedia・SNS・業界データベースへの登録と外部言及の獲得
ナレッジグラフは外部ソースを重視します。自社が実在の信頼できる組織であることは、第三者の情報源からの裏付けが前提です。無理にWikipediaページを自作するのではなく、業界団体の会員名簿、公的機関の事業者登録、信頼できるメディアの取材記事といった、事実として存在する言及を増やします。
獲得した外部URLは、前述のsameAsに反映して自社サイトと結線します。外部での言及と自社の構造化データが相互に指し合う状態が、実体の確からしさを底上げする条件です。言及の質は数より一貫性が効きます。
内部リンクで関連エンティティ同士の結び付きを補強するクラスタ設計
サイト内でも、関連する概念やサービスのページを内部リンクで結び、トピッククラスタを作ります。階層そのものを機械可読に伝える配線としては、パンくずリストとBreadcrumbListの実装が同じ役割を担う実装方法です。中心となるハブページに周辺の記事から一貫したアンカーテキストでリンクを集めると、その領域における自社の専門性が構造として伝わります。
アンカーテキストは「こちら」ではなく、リンク先の実体を表す具体語にします。関連エンティティ同士を意味のある言葉でつなぐことが、機械にとっての関係の明示になります。ページ単体ではなく、領域全体で実体を描く発想です。
エンティティSEOの効果測定とナレッジパネル獲得を確認する指標
エンティティSEOは順位という単一指標で測りにくい施策です。何をもって前進とみなすか、確認できる観測点を定めます。
ナレッジパネルとサイトリンクの表示からエンティティ認識を確認
最も分かりやすい観測点は、社名で検索したときのナレッジパネルとサイトリンクの表示です。ナレッジパネルが出れば、Googleが自社を1つの実体として認識した証拠になります。表示前でも、サイトリンクの本数や内容の変化は認識状況の手がかりです。
パネルが表示されたら、Googleのナレッジパネルの本人確認ヘルプに沿って、パネル下部の「Claim this knowledge panel」から公式サイトや公式プロフィールのアカウントでログインし、認証済みの代表者になれます。すべてのパネルが申請対象になるわけではないと明記されているため、表示されない場合は時期を空けての確認が必要です。社名や商品名で検索した際に、自社の公式情報が正しく要約されているかも確認し、誤りがあれば外部ソースと構造化データの記述を見直します。
サーチコンソールとブランド指名検索の推移から測る間接的な効果
サーチコンソールでは、社名やサービス名を含む指名検索の表示回数とクリック数の推移を追います。エンティティが強まると、実体を直接探す指名検索が増える傾向です。一般キーワードの順位より、指名検索とAI検索での引用が先に動くことが多い点を踏まえます。生成AIの回答に自社が選ばれているかの観測と対策はAIに引用されるための記事構造とサイト対策で扱っています。
| 観測点 | 確認の手段 | 頻度の目安 |
|---|---|---|
| 構文エラー | リッチリザルトテスト | 改修のたび |
| 実体の登録 | Wikidata・ナレッジグラフAPI | 四半期ごと |
| パネル表示 | 社名での検索結果 | 月次 |
| 指名検索 | サーチコンソール | 月次 |
効果測定は月次で定点観測します。構造化データの反映やナレッジグラフへの取り込みには数週間から数か月かかるため、短期で判断せず、指名検索とパネル表示を継続して記録するのが現実的です。
エンティティSEOに取り組むべき企業と後回しでよい場面の判断基準
すべての事業者が今すぐ全力で取り組むべき施策ではありません。投資対効果が見合う条件と、優先度を下げてよい場面を条件付きで示します。
指名検索とE-E-A-Tを重視する企業がまず着手すべき理由と優先度
先に着手すべきなのは、すでに一定の指名検索が発生しているブランドと、専門性・信頼性が順位を左右する領域（医療、金融、法律、受託開発などの専門サービス）を持つ事業者です。実体の土台があるほど、構造化データと表記統一の効果が乗りやすくなります。着手の順番は、組織のOrganizationと@idの固定、著者ページの集約、sameAsの結線、外部言及の獲得です。前の2つは社内作業だけで完結するため、1〜2週間で終えられます。
逆に、立ち上げ直後で指名検索がほぼ無いサイトは、まず個々のページで検索意図に答えるコンテンツを積む段階です。実体を語る材料が乏しいうちにエンティティSEOだけ先行させても、参照されるべき情報が不足します。この段階でも組織マークアップだけは入れておき、外部言及の獲得は後回しにする、という分け方が現実的です。
構造化データを入れるだけで成果が出ると誤解する典型的な失敗例
最も多い失敗は、JSON-LDを設置した時点で対策完了とみなすパターンです。構造化データは実体を伝える文法にすぎず、伝えるべき実体の中身と外部からの裏付けが無ければ、ナレッジパネルにもAI引用にもつながりません。マークアップだけを増やしても順位は動きません。構造化データそのものの型選定と実装五工程は、構造化データの定義とリッチリザルト機能の選び方で整理しています。
2つ目の失敗は、実績を誇張した構造化データを書くことです。実在しない受賞歴や資格を記述すると、本文との乖離が検出され、信頼をむしろ損ないます。3つ目は、プラグインとテーマが別々にOrganizationを出力し、@idや社名が食い違った2つの組織がページ内に並ぶケースです。ページのソースでapplication/ld+jsonを検索し、組織の記述が1つに収まっているかを確かめます。エンティティSEOで書くべきは、事実として裏付けられる実体情報だけです。
よくある質問
エンティティSEOの実務でよく寄せられる疑問に、簡潔に回答します。
エンティティSEOとキーワードSEOは何が違いますか？
キーワードSEOは個々のクエリと語句の一致を軸に順位を狙う手法で、エンティティSEOは自社や著者を1つの実体として検索エンジンに認識させる手法です。目的が「特定クエリの順位」か「実体としての認知」かで異なります。両者は対立せず、ページ単位でキーワードに答えつつ、サイト全体で実体を強化する二層構造で併用します。
構造化データを入れればエンティティSEOは十分ですか？
不十分です。JSON-LDは実体を伝える文法であって、伝える中身と外部からの裏付けがそろって初めて機能します。構造化データに加え、社名や著者の表記統一、Wikipediaや業界データベースなど外部ソースでの一貫した言及が必要です。マークアップだけでナレッジパネルや指名検索が発生することはありません。
中小企業や個人サイトでもエンティティは強化できますか？
可能です。大企業でなくても、正式名称と著者情報の統一、OrganizationとPersonの構造化データ、事実にもとづく外部言及の積み上げは実行できます。規模より一貫性が効くため、発信者が明確で専門領域が定まっている個人サイトは、むしろ実体を描きやすい面があります。
自社がエンティティとして認識されているかはどう確認しますか？
社名で検索してナレッジパネルが出るかを見るのが最も簡単です。出ない場合は、Wikidata APIのwbsearchentitiesでウィキデータへの登録を、GoogleナレッジグラフのAPIでGoogle側の実体IDの有無を照会します。どちらにも結果が無ければ、まだ実体として確立していない段階です。効果はナレッジグラフへの取り込みを含めて数週間から数か月かけて現れるため、月次で指名検索の表示回数とパネル表示を定点観測します。
ナレッジパネルは狙って獲得できますか？
直接作ることはできませんが、獲得の確率は高められます。構造化データで実体を明示し、複数の信頼できる外部ソースが同じ情報を示す状態が、Googleがナレッジパネルを生成する土台です。表示された後は、Googleのヘルプに沿って「Claim this knowledge panel」から本人確認を行えば、情報の修正を提案できるようになります。
関連記事
- SEO対策とは？仕組み・3つの施策と成果までの進め方：エンティティSEOの土台になるSEO全体像を解説しています。
- クエリファンアウトとは：AI検索がクエリを分解する仕組みで、実体認識が引用に効く背景を補足します。
- GXOとは：生成AI検索でブランドが選ばれる考え方を扱い、エンティティ強化と地続きです。
- ナレッジパネルとは？表示の仕組みと認証の申請手順：パネル獲得後の本人確認と情報修正の流れを扱います。
