🕸️

エンティティとセマンティック SEO

キーワードからエンティティへ — Google のナレッジグラフに、あなたが何者で何を扱っているかを理解させる。

📖 13 分で読めます 🕑 更新日 2026-06-22

検索の歴史の大半において、Google は文字列マッチングのマシンだった。あなたが cheapest flights to tokyo と入力すると、エンジンはまさにその文字列を含むドキュメントを探した。それゆえ SEO とは、正しい文字列を正しい場所に置くゲームだった。タイトルタグ、H1、アンカーテキスト、そして — 悪しき時代には — キーワードを詰め込んだフッターである。

その世界はもう終わった。2012 年にナレッジグラフが立ち上がり、2013 年に Hummingbird アップデートがランキングパイプラインを再編して以来、Google は*文字列（strings）からモノ（things）*への移行を続けている。発表における公式の言い回しは文字どおりだった。「things, not strings（モノであって、文字列ではない）」。現代の Google は「どのページがこれらの単語を含むか」を問うのではなく、「このクエリはどの現実世界のエンティティに関するものか、そしてどのページがそれらのエンティティにとって権威ある情報源か」を問う。

このシフトは、2026 年における高度な SEO にとって、もっとも重要なメンタルモデルそのものだ。いまだにキーワードで考えているなら、あなたはもはや存在しないエンジンに向けて最適化していることになる。本ガイドでは、代わりにエンティティで考え — そしてマークアップする — 方法を示す。

エンティティ vs キーワード

キーワードとはテキストの文字列である。エンティティとはモノ — 人、組織、場所、製品、概念、イベント — であり、特定の言い回しとは独立に存在する。

エンティティ Tim Berners-Lee を例に取ろう。キーワード tim berners-lee、inventor of the world wide web、creator of HTTP、TBL はすべて同じエンティティを指す。Google はそれらをナレッジグラフ内の 1 つのノードへ解決し、機械可読な ID（/m/07d5b のようなナレッジグラフ MID、または Q80 のような Wikidata QID）を割り当て、それを他のエンティティ — World Wide Web、CERN、MIT、W3C — と結びつける。

その違いを 1 つの表にまとめると次のとおりだ。

観点キーワード（文字列）エンティティ（モノ）
性質文字の並び安定した ID を持つ現実世界の概念
同一性nyc ≠ new york citynyc = new york city = Q60
曖昧さ”Jaguar” は 1 つの文字列動物 vs 車 vs OS — 3 つのエンティティ
関係性本質的には持たないグラフ内で接続される（isA、partOf、worksFor）
Google の使い方字句的マッチ曖昧性解消 + 推論 + 検索

🧑‍💻 開発者視点: キーワードを生の string 入力、エンティティを解決済みの外部キーだと考えよう。検索はかつて WHERE body LIKE '%term%' だった。いまではその前段にエンティティ解決レイヤーがある — クエリ文字列はエンティティ ID へとパースされ、ランキングはそれらの ID のグラフ上で部分的に行われる。あなたの仕事は、自分のページを正しいノードへきれいに*結合可能（joinable）*にすることだ。

これが実務でなぜ重要なのか。

  • 曖昧性解消。 あなたの「Python」に関するページがプログラミング言語（Q28865）についてのものであって蛇（Q472）についてのものではない、と Google が理解すれば、無関係な SERP での競合をやめ、あなたが属すべき場所でランクし始める。
  • 同義語と意図のカバレッジ。 もはや 15 通りのキーワードのバリエーションを繰り返す必要はない。エンティティをしっかりカバーすれば、それに解決される文字列のクラスター全体でランクする。
  • 推論。 React、JSX、hooks、仮想 DOM を扱うページが、フロントエンドフレームワークにおける真の権威であると Google は推論できる。これらのエンティティがグラフ上の隣接点だからだ。キーワード密度ではそれを偽装できない。

エンティティになる

最初の戦略的な一手は、あなた自身 — あなたのブランドと著者 — を、Google が認識するエンティティにすることだ。認識されていないブランドは推論レイヤーにとって不可視であり、ただの別の文字列にすぎない。認識されたエンティティはナレッジパネルを得て、信頼シグナル（E-E-A-T の「T」）を稼ぎ、情報源として引用される資格を得る。

Google はウェブ全体にわたる相互裏付けの証拠からエンティティを構築する。あなたの仕事は、一貫した、機械可読で、相互参照されたシグナルを与え続けることだ。もっとも重要なレバーは 3 つある。

1. sameAs — あなたのエンティティを既知の権威にリンクする

schema.org マークアップにおける sameAs プロパティは、「このページ上のエンティティは、あなたがすでに信頼しているこのノードと*同一（same as）*である」と告げるもっとも直接的な方法だ。Wikidata、Wikipedia、LinkedIn、GitHub、Crunchbase、そして公式のソーシャルプロフィールへ向けよう。Wikidata と Wikipedia は最高価値のターゲットである。Google のナレッジグラフは部分的にそれらから種付けされているからだ。

以下は架空の開発ツール企業向けの Organization マークアップだ。<head> 内または </body> の前に JSON-LD で置き、理想的にはトップページと会社概要ページに配置する。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.dev/#organization",
  "name": "Acme Dev Tools",
  "url": "https://acme.dev/",
  "logo": "https://acme.dev/logo.png",
  "foundingDate": "2019-04-01",
  "description": "Acme builds open-source observability tooling for distributed systems.",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://en.wikipedia.org/wiki/Acme_Dev_Tools",
    "https://www.linkedin.com/company/acme-dev-tools",
    "https://github.com/acme-dev",
    "https://www.crunchbase.com/organization/acme-dev-tools",
    "https://x.com/acmedev"
  ]
}
</script>

そして対応する著者向けの Person マークアップ。著者が組織に対して worksFor であり、2 つのエンティティが配線されている点に注目してほしい。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://acme.dev/team/jane-doe/#person",
  "name": "Jane Doe",
  "jobTitle": "Principal Engineer",
  "worksFor": { "@id": "https://acme.dev/#organization" },
  "url": "https://acme.dev/team/jane-doe/",
  "knowsAbout": ["Distributed tracing", "OpenTelemetry", "Go"],
  "sameAs": [
    "https://www.linkedin.com/in/janedoe",
    "https://github.com/janedoe",
    "https://orcid.org/0000-0002-1825-0097"
  ]
}
</script>

💡 ヒント: @id の値は、あなたのスキーマグラフがそれ自身を参照できるようにする内部アンカーだ。#organization のような安定した URL フラグメントを使えば、Article、Person、BreadcrumbList のブロックすべてが、組織を再定義することなく 1 つの正規（canonical）な組織ノードを指し返せる。これこそグラフがモデル化されるべきあり方だ — 一度定義し、あらゆる場所から参照する。

2. about / mentions — コンテンツが扱う対象を宣言する

about は「このページは主にエンティティ X についてである」と告げる。mentions は「このページはエンティティ Y に言及している」と告げる。曖昧さが生じないよう、実在のエンティティ ID を使おう。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "OpenTelemetry vs Jaeger: choosing a tracing backend",
  "author": { "@id": "https://acme.dev/team/jane-doe/#person" },
  "publisher": { "@id": "https://acme.dev/#organization" },
  "about": {
    "@type": "Thing",
    "name": "OpenTelemetry",
    "sameAs": "https://www.wikidata.org/wiki/Q98961422"
  },
  "mentions": [
    { "@type": "SoftwareApplication", "name": "Jaeger",
      "sameAs": "https://www.wikidata.org/wiki/Q60803298" },
    { "@type": "Thing", "name": "Distributed tracing",
      "sameAs": "https://www.wikidata.org/wiki/Q105749746" }
  ]
}
</script>

3. 一貫した NAP と命名

NAP — Name（名称）、Address（住所）、Phone（電話番号） — は、どこでもバイト単位で同一でなければならない。自社サイト、Google ビジネスプロフィール、LinkedIn、Crunchbase、各種ディレクトリ。NAP が一貫していないと、あなたのエンティティは複数の弱く支持された候補へと分裂し、Google はそれらを統合できないかもしれない。あなたの正規のエンティティ事実は、設定における単一の信頼できる情報源（single source of truth）として扱おう。

# entity.yml — the one place your NAP lives; render everything from this
name:    "Acme Dev Tools, Inc."
url:     "https://acme.dev/"
phone:   "+1-415-555-0142"
address:
  street:  "500 Howard St, Suite 400"
  city:    "San Francisco"
  region:  "CA"
  postal:  "94105"
  country: "US"

⚠️ 注意: “Acme Dev Tools” と “Acme Dev Tools, Inc.” と “ACME” は、素朴なマッチャーにとって 3 つの異なる文字列だ。法人名 1 つと一般名 1 つを選び、一貫して使おう。同じ規律はドメインにも当てはまる。意図的なリダイレクト戦略がない限り、acme.dev、acme.io、getacme.com にブランドの権威を分散させてはいけない。

トピカルオーソリティ

エンティティは単独では存在しない — クラスターの中で生きている。OpenTelemetry は 分散トレーシング、スパン、OTLP プロトコル、Prometheus、サンプリング戦略、計装ライブラリ と結びついている。トピカルオーソリティとは、1 つの太いキーワードでランクすることではなく、そのエンティティの近傍全体と、ユーザーがそれらについて尋ねる問いを、明確にカバーすることを意味する。

古いキーワードの定石は、それぞれ 1 つのフレーズ（opentelemetry tutorial、opentelemetry vs jaeger、opentelemetry python……）を狙う薄いページを 10 枚生み出し、しばしば互いに食い合った。エンティティの定石が生み出すのはコンテンツクラスターだ。包括的なピラー 1 つと、相互リンクされた支援ページ群。それらが一緒になって、意味のあるサブエンティティとサブ質問のすべてをカバーする。

キーワードアプローチエンティティ / トピカルアプローチ
計画の単位検索フレーズトピックとそのサブエンティティ
ページ数の論理キーワードごとに 1 ページナレッジマップに対応づけたページ群
内部リンクランダム / 関連性の勘エンティティ関係を軸に構造化
成功指標そのキーワードでランクSERP 全体でトピックを掌握
リスクカニバリゼーション、薄いコンテンツカバレッジの抜け

マップを構築するには、Google がすでにあなたのトピックと関連づけているエンティティを掘り起こそう。

  • People Also Ask ボックスと「関連性の高い検索」 — それぞれが事実上のサブ質問またはサブエンティティだ。
  • コアエンティティに対する Wikipedia の目次と「関連項目（See also）」 — 無料の、人間がキュレートしたエンティティグラフ。
  • Wikidata のプロパティパネル — 実際のグラフのエッジ（subclass of、uses、has part）。
  • 関連するナレッジグラフのエンティティを手早くプログラム的に取得する。
curl -s "https://kgsearch.googleapis.com/v1/entities:search" \
  --data-urlencode "query=OpenTelemetry" \
  --data-urlencode "types=Thing" \
  --data-urlencode "limit=10" \
  --data-urlencode "key=$GOOGLE_KG_API_KEY" -G \
  | jq '.itemListElement[].result | {name, id: ."@id", desc: .description}'

💡 ヒント: 有用な経験則 — あるトピックで権威を獲得するには、知識のある同僚が 30 分の会話でそのトピックについて尋ねうるすべての問いに、あなたのクラスターが答えるべきだ。あるサブ質問にページもセクションも存在しないなら、それは競合が埋めるカバレッジの抜けである。

見返りは複利で効いてくる。いったん Google があなたを 分散トレーシング の権威として信頼すれば、そのクラスター内の新しいページはより速くランクする。信頼が個々の URL ではなく、トピック内におけるあなたのエンティティに紐づくからだ。

実践的なステップ

ここに、端から端までのワークフローを示す。各ステップはチケットに載せられる程度に具体的だ。

1. エンティティの棚卸しを行う。 あなたのサイトがそうであるエンティティ（ブランド、製品、著者、所在地）と、あなたが権威となりたいエンティティ（コアトピックとそのサブエンティティ）を列挙する。それぞれについて、正規の参照先 — 存在すれば Wikidata QID、なければ内部の @id — を見つけるか作成する。

We ARE:        Acme Dev Tools (Q123456789), Jane Doe (no QID → /team/jane-doe/#person)
We OWN:        distributed tracing, OpenTelemetry, observability, OTLP, span sampling
Gaps to fill:  span sampling (no page), OTLP (only a passing mention)

2. エンティティをスキーマでマークアップする。 アイデンティティページには Organization + Person を、コンテンツページには about/mentions 付きの Article を追加し、すべてを @id で互いに配線する。スキーマジェネレーターで JSON-LD を生成・検証し、続いて Google のリッチリザルトテストと Schema.org バリデーターで確認する。これは レイヤー 4: コンテンツと構造 で詳しく扱う構造化データの規律だ。

3. 内部リンクを思いつきではなくエンティティ単位で整理する。 すべての支援ページは、ピラーへ上向きにリンクし、兄弟エンティティへ横向きにリンクすべきだ。その際、エンティティ名を挙げる説明的なアンカーテキスト（distributed tracing であって click here ではない）を使う。こうすることで、あなたのクラスターはグラフとして可読になる。

        [ Pillar: Distributed Tracing ]
        /        |          |         \
 [OpenTelemetry][Jaeger][Span sampling][OTLP]
        \________cross-links between siblings________/

4. 権威ある言及を獲得する。 sameAs はあなたの主張であり、第三者による裏付けがその証明だ。Google がすでに信頼している情報源 — カンファレンスの講演、人気プロジェクトの GitHub README、業界誌、そして本当に正当な場合には Wikidata エントリー — から引用され、紹介され、リンクされよう。リンクのないブランド言及もカウントされる。Google はそれらをエンティティ連想シグナルとして読む。

5. 計測して反復する。 あなたのブランドにナレッジパネルが表示されるか、「ウェブ全体の情報源から（From sources across the web）」や AI Overviews に登場するか、そしてどのクラスターページがランクするかを追跡する。抜けを埋め、弱いノードを深掘りし、その際には updated の日付を更新する。

  • エンティティの棚卸しが完了（we-are + we-own + 抜け）
  • 完全な sameAs を備えた Organization と Person スキーマを公開
  • 重要なすべてのコンテンツページに about/mentions
  • すべてのプロパティで NAP が一貫している
  • 内部リンクがエンティティグラフを軸に構造化されている
  • 四半期ごとに少なくとも 1 件の新しい権威ある第三者言及

重要ポイント

  • ✅ Google はエンティティ（モノ）をランクするのであって、キーワード（文字列）ではない — 正確なフレーズではなく概念に向けて最適化する。
  • ✅ Organization/Person スキーマと、Wikidata、LinkedIn、GitHub、Crunchbase への sameAs リンクで、ブランドと著者を認識されたエンティティにする。
  • ✅ 実在のエンティティ ID を使った about と mentions で、各ページが何を扱っているかを Google に正確に伝える。
  • ✅ NAP と命名をバイト単位で一貫させ、Google があなたのエンティティを 2 つに分裂させないようにする。
  • ✅ キーワードごとに 1 ページではなく、相互リンクされたコンテンツクラスターでトピックのエンティティ近傍全体をカバーして、トピカルオーソリティを構築する。
  • ✅ スキーマジェネレーターでマークアップを生成・検証し、レイヤー 4: コンテンツと構造 を通じて適用する。