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

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 のようなパスでもよい。だがフラグメント識別子には明確な利点がある。

1. 既存のURLを汚さない。 新しいルートを作る必要がない
2. Schema.org の慣例に合致する。 Google の公式例でも #organization を使っている
3. 人間にとって読みやすい。 /#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)

人物 (Q138767422)

ポイントは、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はこのデータを以下のように処理する。

1. @id: https://yumesuta.com/#person-urushihata-tomoya というエンティティを認識
2. sameAs に https://www.wikidata.org/entity/Q138767422 がある
3. Wikidata Q138767422 を参照 → 「漆畑智哉、ソフトウェアエンジニア、ゆめスタ勤務」
4. サイト上の構造化データと 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 を始めるなら、やることを以下のように整理できる。

1. サイト上の構造化データで @id 体系を設計する — 命名規則を決め、全スキーマ間の相互参照を設計する
2. Wikidata にエンティティを登録する — 組織と人物。出典を必ず付ける
3. sameAs で @id と QID を接続する — サイト上の構造化データに Wikidata URL を追加
4. 外部言及を増やす — メディア掲載、OSS公開、技術記事、カンファレンス
5. AIに定期的に聞いて確認する — 「○○とは誰？」「○○はどんな会社？」

技術的に複雑なのは1と2で、3は実装するだけ、4は地道な活動、5は習慣の問題。

---

実装コード・参照先

• 構造化データ全18種: urushihata-llmo / templates / structured-data.ts
• Wikidata: 漆畑智哉 — Q138767422
• 本番サイト: yumesuta.com

シリーズ記事

• S2: 構造化データ18種の設計と実装 — Schema.orgを「エンティティ認識装置」として使う <!-- 公開後にURL差し替え -->