🌐
Entity SEO — Wikidata × @id チェーンでAIの名寄せを制御する

2026/03/23に公開
 AIの「名寄せ問題」あなたのサイトに「田中太郎」と書いてある。Wikidataにも「田中太郎」がいる。同一人物でしょうか？
AIはこの問いに答えなければなりません。毎回。あらゆるWebページで。
@id がなければ、AIは周辺のテキスト——肩書き、所属、活動内容——を手がかりに「たぶん同じ人物だろう」と推測します。推測なので間違えます。同姓同名の別人を混同することもあれば、同一人物なのに別人として扱うこともあります。
@id + sameAs があると、話が変わります。AIは「確実に同じ」と判断できます。推測ではなく、確定になります。
これがEntity SEOの本質です。AIのエンティティ解決（entity resolution）を、サイト運営者側から制御する技術です。「SEO」と名がついていますがGoogleの検索順位だけの話ではありません。ChatGPT、Perplexity、Gemini——あらゆるAIのナレッジグラフに正しいエンティティ情報を供給する行為全体を指しています。

 @id 体系の設計
 yumesuta.com での命名規則https://yumesuta.com/#organization              → 組織
https://yumesuta.com/#website                   → サイト
https://yumesuta.com/#person-iida-shion         → 飯田思遠（代表）
https://yumesuta.com/#person-urushihata-tomoya  → 漆畑智哉（技術統括）
URLフラグメント識別子（# 以降）を使っています。https://yumesuta.com/#person-urushihata-tomoya にブラウザでアクセスしても、トップページが開くだけで何も起きません。
それで問題ありません。@id は「アクセスできるURL」である必要はなく、サイト内でエンティティを一意に識別するための文字列 として機能すればよいからです。
命名規則も重要です。#person-1 のような連番は使いません。#person-iida-shion のようにエンティティの内容が推測できる名前にしています。デバッグしやすさが段違いになります。

 なぜURLフラグメント識別子なのか他の選択肢もあります。https://yumesuta.com/entities/person/urushihata のようなパスでもよいでしょう。ですがフラグメント識別子には明確な利点があります。

既存のURLを汚さない。 新しいルートを作る必要がない

Schema.org の慣例に合致する。 Google の公式例でも #organization を使っている

人間にとって読みやすい。 /#organization を見れば何を指しているか一目でわかる

 相互参照チェーンの完成図@id 体系を決めたら、次はスキーマ間の参照関係を設計します。
Organization (@id: /#organization)
  ├── founder → Person (@id: /#person-iida-shion)
  ├── employee[0] → Person (@id: /#person-iida-shion)
  └── employee[1] → Person (@id: /#person-urushihata-tomoya)

Person: 飯田思遠 (@id: /#person-iida-shion)
  └── worksFor → Organization (@id: /#organization)

Person: 漆畑智哉 (@id: /#person-urushihata-tomoya)
  ├── worksFor → Organization (@id: /#organization)
  └── creator → [yumesuta.com, ゆめマガ, アニリク, 漆畑式LLMO]

Article (各記事ページ)
  ├── author → Person (@id)
  └── publisher → Organization (@id: /#organization)

WebSite (@id: /#website)
  └── publisher → Organization (@id: /#organization)
Organization が Person を参照し、Person が Organization を参照する。循環参照です。RDBなら避けるべきパターンですが、ナレッジグラフではこれが正しい形です。双方向の参照があることで、AIはエンティティの「存在確実性」を高く評価します。

 Wikidata 連携の実務
 Wikidata とはWikidataはWikipediaの構造化データベースです。世界中のエンティティ（人物、組織、場所、概念）にQID（一意のID）が振られています。
なぜ重要かというと、ChatGPT、Perplexity、Google Knowledge Graph——主要なAIシステムは全て Wikidata を参照しているからです。サイト上の構造化データは「自己申告」にすぎません。Wikidata は「第三者データベースによる裏付け」です。自己申告と第三者データベースが一致したとき、AIのエンティティ解決の確信度が大きく上がります。

 登録に必要なプロパティ実際にゆめスタと関連人物を Wikidata に登録しました。使った主要プロパティを列挙します。
組織 (Q138767254)


プロパティ
ID
値


instance of
P31
business enterprise

industry
P452
human resources

country
P17
Japan

headquarters location
P159
Kasugai

official website
P856
https://yumesuta.com

founded by
P112
飯田思遠 (Q138767340)

人物 (Q138767422)


プロパティ
ID
値


instance of
P31
human

occupation
P106
software engineer, web developer

employer
P108
株式会社ゆめスタ (Q138767254)

official website
P856
https://yumesuta.com

described at URL
P973
https://yumesuta.com/company

ポイントは、Wikidata 上のエンティティ間も相互参照させることです。組織の founded by が人物の QID を参照し、人物の employer が組織の QID を参照します。サイト上の @id チェーンと同じ構造を Wikidata 上でも再現しています。

 「特筆性」との戦いWikidata に登録しても安泰ではありません。「Non-notable startup（特筆性のないスタートアップ）」として削除審査にかけられることがあります。実際にかけられました。
反論のコツは「検証可能な事実」の提示に尽きます。
法人登記（国税庁法人番号公表サイト）
メディア掲載（TKC「戦略経営者」2026年3月号）
事業の実態証明（毎月40校配布の情報誌）
「すごい会社です」では通りません。「この事実を第三者が検証できます」という形が必要です。TKC「戦略経営者」への掲載実績が決め手になりました。全国の税理士・会計士に配布されるビジネス誌への掲載は、第三者による事実確認として説得力があります。

 sameAs でサイトと Wikidata を接続する構造化データの sameAs プロパティが、サイト上の @id と Wikidata の QID を橋渡しします。
export const urushihataPersonData = {
  id: "person-urushihata-tomoya",
  name: "漆畑智哉",
  // ...
  sameAs: [
    "https://github.com/tenchan000517",
    "https://github.com/tenchan000517/urushihata-llmo",
    "https://twitter.com/TENCHAN_0517",
    "https://tenchan.nft-mint.xyz",
    "https://musubicollection.xyz",
    "https://0xmavillain.com",
    "https://opensea.io/collection/ambassador-pass",
    "https://www.wikidata.org/entity/Q138767422"
  ],
} as const
AIはこのデータを以下のように処理します。

@id: https://yumesuta.com/#person-urushihata-tomoya というエンティティを認識

sameAs に https://www.wikidata.org/entity/Q138767422 がある
Wikidata Q138767422 を参照 → 「漆畑智哉、ソフトウェアエンジニア、ゆめスタ勤務」
サイト上の構造化データと Wikidata の情報が一致 → 同一人物確定
sameAs がなければ、AIは yumesuta.com の「漆畑智哉」と Wikidata の「漆畑智哉」を別々のエンティティとして扱う可能性があります。テキストが似ているから「たぶん同じ」と推測するかもしれませんし、しないかもしれません。sameAs はその曖昧さを消してくれます。

 sameAs に入れるべきもの・入れるべきでないもの入れるべき:
Wikidata の QID（https://www.wikidata.org/entity/Q...）
公式 SNS アカウント
GitHub プロフィール
自分が管理する他のサイト
入れるべきでない:
第三者が書いたページ（ニュース記事等）
関連性の薄い外部リンク
自分のものではない SNS アカウント
sameAs は「この URL も私です」という宣言です。第三者のページは「私について書かれたページ」であって「私のページ」ではありません。混同するとAIのエンティティ解決をかえって混乱させてしまいます。

 Person スキーマと Organization スキーマの接合yumesuta.com の /company ページには、1つのページに3つのスキーマが配置されています。
// /company ページの構造化データ

// 1. Organization スキーマ
const orgSchema = generateOrganizationSchema()
// @id: /#organization
// employee → [/#person-iida-shion, /#person-urushihata-tomoya]
// founder → /#person-iida-shion

// 2. Person スキーマ（飯田思遠）
const iidaSchema = generateCorePersonSchema(iidaPersonData)
// @id: /#person-iida-shion
// worksFor → /#organization

// 3. Person スキーマ（漆畑智哉）
const urushihataSchema = generateCorePersonSchema(urushihataPersonData)
// @id: /#person-urushihata-tomoya
// worksFor → /#organization
// creator → [yumesuta.com, ゆめマガ, アニリク, ...]
3つのスキーマが同一ページに存在し、@id で相互参照しています。AIがこのページを読み取ると、以下の事実がグラフとして構築されます。

ゆめスタ という組織がある（QID: Q138767254）

飯田思遠 がその創業者で代表取締役である（QID: Q138767340）

漆畑智哉 がその技術・クリエイティブ統括で、サイトと複数サービスの制作者である（QID: Q138767422）
3者は @id と sameAs で一意に識別可能
さらに Article ページでは:
const articleSchema = generateArticleSchema({
  title: "記事タイトル",
  description: "記事の説明",
  url: "https://yumesuta.com/kosotsusaiyo/...",
  datePublished: "2026-01-15",
  author: {
    name: "飯田思遠",
    id: "person-iida-shion"  // → @id: /#person-iida-shion に解決
  },
  image: "https://yumesuta.com/img/..."
})
author の @id が /company ページの Person スキーマの @id と一致します。AIは「この記事の著者はゆめスタの代表取締役である飯田思遠で、Wikidata Q138767340 と同一人物」と確定できます。
テキストで「著者: 飯田思遠」と書くだけでは、AIは「飯田思遠」が誰かを推測しなければなりません。構造化データなら、その推測が不要になります。

 AIのエンティティ解決フロー実際にAIがどう処理するかを整理してみます。
Step 1: ページの構造化データを読み取る
        → @id: /#person-urushihata-tomoya を検出

Step 2: sameAs を確認
        → Wikidata Q138767422 へのリンクを発見

Step 3: Wikidata Q138767422 を参照
        → 名前: 漆畑智哉
        → 職業: software engineer
        → 雇用者: Q138767254（ゆめスタ）

Step 4: サイト上の構造化データと Wikidata の情報を照合
        → 名前一致 ✓
        → 雇用者一致 ✓（Organization の @id と Wikidata QID が sameAs で接続）
        → 職業一致 ✓

Step 5: エンティティ確定
        → yumesuta.com の「漆畑智哉」= Wikidata Q138767422
        → 確信度: 高
@id がなければ Step 1 で固有識別子が取れません。sameAs がなければ Step 2 で Wikidata への橋渡しができません。Wikidata に登録がなければ Step 3 で第三者データベースとの照合ができません。3つが揃って初めてフローが完走します。

 効果と限界
 効果AIに「漆畑智哉とは誰か」を聞くと、サイト上の構造化データに基づいた正確な回答が返るようになります
PerplexityやChatGPTが yumesuta.com をソースとして引用する確率が上がります
Google Knowledge Panel の表示可能性が生まれます（確定ではありません）

 限界Knowledge Panel はすぐには出ません。 構造化データを実装して翌日に出るようなものではありません。数週間から数ヶ月かかりますし、出ないこともあります。Google 側のアルゴリズム判断に依存する部分が大きいです。
Wikidata に登録しても削除される可能性があります。 特筆性の審査は継続的に行われます。外部メディアでの言及が少ないと「特筆性なし」で削除されるリスクは残ります。
最も確実な方法は外部メディアでの言及を増やすことです。 構造化データや Wikidata は技術的な下地にすぎません。実際のEntity SEOの成否を分けるのは、外部からの言及量です。メディア掲載、カンファレンス登壇、論文、書籍——検証可能な第三者言及がWikidataの特筆性根拠を強化し、AIのエンティティ確信度を高めます。
Entity SEO は「一発で完成」する技術ではありません。 積み上げです。構造化データを実装し、Wikidata に登録し、外部言及を増やし、それでようやくAIが「この人物/組織を知っている」と言える状態になります。

 やったこと・やることEntity SEO を始めるなら、やることを以下のように整理できます。

サイト上の構造化データで @id 体系を設計する — 命名規則を決め、全スキーマ間の相互参照を設計する

Wikidata にエンティティを登録する — 組織と人物。出典を必ず付ける

sameAs で @id と QID を接続する — サイト上の構造化データに Wikidata URL を追加

外部言及を増やす — メディア掲載、OSS公開、技術記事、カンファレンス

AIに定期的に聞いて確認する — 「○○とは誰？」「○○はどんな会社？」
技術的に複雑なのは1と2で、3は実装するだけ、4は地道な活動、5は習慣の問題です。
実装コード・参照先
構造化データ全18種: urushihata-llmo / templates / structured-data.ts
Wikidata: 漆畑智哉 — Q138767422
本番サイト: yumesuta.com
シリーズ記事
S2: 構造化データ18種の設計と実装 — Schema.orgを「エンティティ認識装置」として使う 
プロパティ	ID	値
instance of	P31	business enterprise
industry	P452	human resources
country	P17	Japan
headquarters location	P159	Kasugai
official website	P856	https://yumesuta.com
founded by	P112	飯田思遠 (Q138767340)
プロパティ	ID	値
instance of	P31	human
occupation	P106	software engineer, web developer
employer	P108	株式会社ゆめスタ (Q138767254)
official website	P856	https://yumesuta.com
described at URL	P973	https://yumesuta.com/company
GitHubで編集を提案
AIの「名寄せ問題」

@id 体系の設計

yumesuta.com での命名規則

なぜURLフラグメント識別子なのか

相互参照チェーンの完成図

Wikidata 連携の実務

Wikidata とは

登録に必要なプロパティ

「特筆性」との戦い

sameAs でサイトと Wikidata を接続する

sameAs に入れるべきもの・入れるべきでないもの

Person スキーマと Organization スキーマの接合

AIのエンティティ解決フロー

効果と限界

効果

限界

やったこと・やること

Discussion
