エンティティとは何か — AI は企業・ブランドをどう識別するのか

• 最終検証日：2026年8月13日
• Methodology バージョン：2026.08.46（訂正）
• 本文中の「2026.08.xx」：その訂正を行った判断基準の版の番号です。公開した版は書き換えず、訂正は新しい版として残しています
• 位置づけ：SILVE の操作モデル。業界標準の分類ではありません
• 関連記事：構造化データの整理 / 7 段階の整理 / 測定の 3 レイヤー

things, not strings

Google が Knowledge Graph を公開したのは 2012 年 5 月 16 日で、そのときの言葉が "things, not strings" でした。

それまでの検索では、たとえば「Taj Mahal」という文字列が、インドの建築物なのか、音楽家なのか、カジノなのか、レストランなのかを文字列だけから区別する必要がありました。Google は Knowledge Graph を「現実世界のエンティティと、その相互の関係を理解する知的なモデル」と説明しています。

エンティティの核心は、名前そのものではなく「その名前が何を指しているか」です。

「SILVE」という文字列だけでは、機械にとってそれが AI 検索診断サービスなのか、ソフトウェア企業なのか、商品名なのか、人名なのかは分かりません。名称・公式 URL・運営者・説明・カテゴリ・ロゴ・関連プロフィールが結びついて初めて、同一の対象についての情報として扱えるようになります。

「自社の Knowledge Graph を作る」とは何か

SEO や GEO の記事では「Knowledge Graph を作りましょう」という表現が使われます。しかし Google の Knowledge Graph そのものを企業が直接構築することはできません。

ただし「公開するだけ」でもありません（2026.08.46 で精密化）。 Google は Knowledge Graph の事実の出所について「さまざまな情報源」とし、そのうえで「コンテンツの所有者から直接、事実情報を受け取ることもある。ナレッジパネルをクレームした人が変更を提案する場合を含む」と述べています。

つまり実際はこうです。

• 任意のエンティティを登録できる公開の登録制度は無い
• 一方で、構造化データ・Business Profile・クレーム済みナレッジパネルからの修正提案といった経路で、事実情報を提供できる場合はある
• 採否と統合は Google 側が決める

「作れない」と「何も渡せない」は別です。

Google は 2012 年の発表で、Knowledge Graph が Freebase・Wikipedia・CIA World Factbook といった公開情報源に基づき、さらに大きな規模へ拡張されていると説明しています。Web 上の情報を含む多数の情報源から構成されるものであって、事業者が登録申請するデータベースではありません。

したがって実務上できるのは、自社について機械が識別しやすい情報を、正確かつ一貫した形で公開・提供することだけです。SILVE はこれを Entity Identity Readiness と呼びます。

Knowledge Graph に載れば AI 検索に強くなるのか

Knowledge Graph が検索や質問応答に使われていること自体は確認できます。しかし「Knowledge Graph に存在する企業が AI Overviews で優遇される」「ナレッジパネルがあると引用率が上がる」といった因果を、Google はランキング要因として公開していません。

SILVE は Knowledge Graph Presence と AI可視性 を分けます。

ナレッジパネルの有無を大きな加点にしない

小規模企業・新しいブランド・ニッチなサービスは、明確に実在するエンティティであってもナレッジパネルが表示されないことがあります。 これを準備状態（Readiness）の加点項目にすると、規模を測っているのと変わりません。

Knowledge Graph Search API は「確認手段」として弱い

Google は Knowledge Graph Search API を提供しており、schema.org の型と JSON-LD に準拠しています。エンティティを文字列とは別に扱っていることの直接的な例です。

ただしこの API 自体に、公式の強い限定が付いています。

• 読み取り専用
• "not suitable for use as a production-critical service" — 本番の重要処理が依存すべきではない
• "returns only individual matching entities, rather than graphs of interconnected entities" — 個々の一致するエンティティを返すだけで、相互に接続されたグラフは返さない（接続されたデータには Wikidata を推奨している）
• Cloud Enterprise Knowledge Graph への移行が案内されている

★ ただし「企業名で一致するエンティティを探すこと自体が用途外」ではありません（2026.08.46 で訂正）。 Google が挙げている典型的な用途には「条件に一致する最も著名なエンティティのランク付きリストを取得する」が含まれており、名前で引いて一致を見ること自体は想定の範囲内です。

採点しない理由はそこではありません。

この API に存在することが、Entity の確立や AI 検索の Readiness に対応するという公式の根拠が無い。

Google はこの API をエンティティの検索・補完・注釈付けの道具として説明しており、「ここに出ればエンティティとして確立している」という定義は与えていません。 上に挙げた制約（読み取り専用・本番依存に不向き・移行案内）は、それとは別に、道具として過信しない理由です。

用途外だから採点しないのではなく、対応づけの根拠が無いから採点しません。

つまり 「API で自社が見つかるか」をエンティティ確立の判定に使うのは、提供元の想定を超えています。

「Knowledge Graph API で検索できるか」をエンティティ診断として使うサービスは考えられます。しかし Google 自身が本番の重要処理での依存を想定していない以上、SILVE はこれを判定基準にしません。 報告のみに留め、採点しません。

Organization スキーマはエンティティを「作る」のか

Google は Organization 構造化データを、企業の管理情報を Google へ伝える仕組みとして提供しています。url については明確にこう書かれています。

The URL of the website of your organization, if applicable. This helps Google uniquely identify your organization.

さらに name については、

Use the same name and alternateName that you're using for your site name.

表記を一貫させることには公式の根拠があります。

しかしスキーマを書けばエンティティが確立するわけではありません。 Google は構造化データを「ページや世界を理解するために利用する情報の一つ」と位置づけています。エンティティ・データベースへの登録申請ではありません。

識別子は、名前だけでは残る曖昧さを減らせる

名前だけでは同一性が曖昧な場合があります。Google の Organization 構造化データは DUNS・GLN・LEI・NAICS・iso6523Code といった識別子に対応しています（DUNS と LEI は iso6523Code に接頭辞を付けて書くことが推奨されています）。

商品側の GTIN / MPN と同じ発想です。名前より一意性の高い識別子のほうが、機械にとっての同一性判定に役立ちます。

sameAs は「権威の蓄積」ではない

schema.org の定義はこうです。

URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website.

本質は「このページで表現されている対象と、こちらの対象は同じである」という同一性の情報です。 SNS リンクを並べて権威を積み上げる仕組みではありません。

したがって、関係の薄いディレクトリ、自動生成プロフィール、ブランド名が一度出ただけのページを大量に sameAs へ入れるのは、プロパティの意味から外れます。

SILVE は sameAs の件数をスコアにしません。

外部での言及をどう扱うか

Google の生成 AI 向けガイドは、外部の言及についてこう書いています。

Just like the rest of Google Search, our generative AI features can show what's being said about products and services across the web, including in blogs, videos, and forum discussions. However, seeking inauthentic "mentions" across the web isn't as helpful as it might seem. Our core ranking systems focus on high-quality content while other systems block spam; our generative AI features depend on both.

自社サイトだけが唯一の情報源ではないという前半と、不自然な言及の獲得は見た目ほど役に立たないという後半を、両方とも落とさずに読む必要があります。

SILVE は「ブランド名を 100 サイトに言及させる」という量の戦略を採用しません。

「数」と「情報価値」を分ける

自動生成ディレクトリ 100 件に「SILVE　AI検索」と書かれている状態と、業界メディアの記事で「SILVE は AI 検索の準備状況を測定するサービスである」と説明されている状態を、どちらも「外部言及 1」として数えるのは粗すぎます。

見るべきは情報源の質・文脈・具体性・検証可能性・独立性です。

共起（Co-occurrence）はどこまで言えるか

Entity SEO では「ブランド名と関連キーワードを同時に言及させると AI が関係を学習する」という説明があります。

技術的なアイデア自体には研究があります。 NAACL 2018 の ELDEN（Radhakrishnan, Talukdar, Varma）は、大規模テキストコーパスの共起統計でナレッジグラフを高密度化し、それを使ってエンティティ埋め込みを学習することで、接続の疎なエンティティのリンク精度を改善しました。

しかしこの研究が示したのは、あるエンティティリンキング手法のベンチマーク性能が改善したということです。 同論文は検索順位にも生成 AI での可視性にも言及していません。

そこから「ブランド名とキーワードを第三者サイトで同時言及させれば AI Mode の順位が上がる」は導けません。根拠の適用範囲を超えています。

SILVE は次のように分けます。

Wikipedia と Wikidata

Google の Knowledge Graph が Wikipedia を情報源の一つとしていることは公式に確認できます。しかし情報源の一つにすぎません。 「Wikipedia ページが無いとエンティティになれない」は誤りです。

SILVE は AI 検索目的での Wikipedia ページ作成を推奨しません。 Wikipedia には独自の特筆性基準と編集方針があり、自社宣伝ページを作るという発想自体が目的と一致しません。

Wikidata は機械可読なエンティティ・データベースとして有用な参照先になり得ます（schema.org も sameAs の例に挙げています）。ただし 「Wikidata に登録すれば AI での可視性が上がる」という普遍的な根拠はありません。 報告のみに留めます。

Google ビジネスプロフィールだけは事情が違う

ローカルビジネスでは、Google ビジネスプロフィールはプラットフォーム公式のデータ経路です。Google の生成 AI 向けガイドも、ビジネスプロフィールが AI の回答での可視性に役立ち得るとしています。

ただし対象事業がはっきり限られています。 Google は明記しています。

Business Profiles aren't for online-only businesses nor properties for rent or sale.

Only businesses that make face-to-face contact with customers are eligible for a Business Profile. If your online-only business doesn't have a physical location that your customers can visit nor do you visit customers in-person, your business isn't eligible.

対象条件のページでも、

To qualify for a Business Profile, a business must make in-person contact with customers during its stated hours.

とされ、対象外の一覧に「ブランド・団体・アーティスト・その他のオンライン専業の事業」が挙げられています。

したがって SILVE のようなオンライン専業のサービスに「Entity 対策としてビジネスプロフィールを作りましょう」と勧めるのは、単に不適切なだけでなく提供元の規定に反します。

ChatGPT ではどうなのか

ここは Google ほど内部が公開されていません。

OpenAI は ChatGPT の検索について、Web 検索を行い、クエリを書き換え、第三者の検索プロバイダを使う場合があり、関連する情報源を取得して引用を表示すると説明しています。

しかし 「Organization スキーマの sameAs を ChatGPT がブランドのエンティティ生成にどう使うか」「Wikipedia のエンティティが推薦順位にどう影響するか」といった内部仕様は公開されていません。

Google 向けのエンティティ施策を、そのまま ChatGPT のエンティティ最適化として一般化してはいけません。 これは SILVE がプラットフォーム固有の仕様を他社へ一般化しない原則そのものです。

コマースでは具体的になる

一方、商品領域では明確です。ただし「GTIN / MPN が必須」ではありません（2026.08.46 で訂正）。 OpenAI 独自スキーマで必須なのは安定した商品 ID（item_id）・ブランド・販売者名で、GTIN と MPN は任意です。GTIN か MPN が必要になるのは Google 互換の経路で identifier_exists を省略または yes にする場合という条件付きです。それでも「識別子で商品を一意に指せること」が仕組みの前提になっている点は変わりません。

行動に近づくほど、エンティティの同一性は運用データとして具体的になります。

Entity Readiness を 5 層に分ける

★ 層 5 を可視性と呼ぶのをやめました（2026.08.46 で訂正）。 以前は「層 1〜4 は自社で管理できるので Readiness、層 5 は観測なので Visibility 側」と書いていましたが、これは SILVE 自身の可視性の定義と食い違います。

MEASUREMENT.md の可視性は「実際に使われた・表示されたか」の観測値です。Wikidata に項目がある / 独立媒体で説明されている、という状態は、AI が実際にその企業を表示・引用・推薦したことではありません。

したがって 3 つに分けます。

「自分で制御できない＝ Visibility」ではありません。 制御可能性の軸と、観測対象の軸は別です。層 5 は制御しにくいが、AI の出力の観測でもないという位置にあります。

法人とブランドは同じではない

「株式会社 Example が運営する SILVE」の場合、法人は Example、ブランドは SILVE です。すべてを Organization として同一視するのは適切とは限りません。 schema.org でも Organization / Brand / Product / Service は別の概念です。

重要なのはエンティティの数を減らすことではなく、関係を正しく表現することです。

ブランド改名は Entity Identity の実践そのもの

SILVE 自身がまさにこれを行いました。 2026 年 8 月に「aiopt」から「SILVE」へ改名しています。

改名で必要になるのはロゴの差し替えではありません。旧名称・新名称・公式 URL・運営者・リダイレクト・構造化データ・外部プロフィール・About ページの整理です。これは「AI 対策」ではなく Identity Migration です。

旧名称を完全に消すべきか

改名直後にすべての旧名称を削除すると、過去の外部記事やリンクと新ブランドの関係が分かりにくくなります。 一定期間は「SILVE（旧 aiopt）」のように関係を明示するほうが合理的です。

ただしこれは「旧名を残せば AI での順位が維持される」という根拠ではありません。 人にも機械にも移行を理解しやすくするための運用上の原則です。

SILVE の現状を正直に書きます

この記事の原則に照らすと、SILVE 自身の Identity Migration はまだ途中です。

• 記事・用語集・方法論のすべての本文で旧名称を新名称へ置換しました。 継続性を明示しているのは変更履歴の 1 エントリだけです
• silve.jp はまだ取得していません。 記事内の URL・構造化データ・メール送信元は新ドメイン前提で書き換えてありますが、実際に解決するのはこれからです
• 旧ドメインからのリダイレクトは未設定です
• 外部プロフィールの統一も未着手です

自分たちが「まだできていない」ことを、できているかのように書かないためにここに残します。

SILVE は何を採点しているか

なぜ 3 点なのか、そして何を減点していないのか

この節は 2026.08.46 で追加しました。 記事はこれまで重みを 6 と書いていましたが、実装は 3 です（実効重み 91 のうち約 3.3%）。数字の誤りを訂正したうえで、根拠を書きます。

直接性が inferred なので、重くしません。 Google が公式に述べているのは「Organization 構造化データの name / alternateName をサイト名と揃える」「url は組織を一意に識別するのに役立つ」「iso6523Code や naics は裏側で曖昧さの解消に使われる」といった範囲で、曖昧さの解消が重要であること自体は明確に支持されています。 一方、「正式名称・通称・英語表記・カタカナ表記が混在する」という日本語固有の形の問題に対応する海外の一次資料はありません。方向は支持されているが、この項目の形は SILVE 独自という状態なので、3 に留めています。

そして「表記が複数あること」自体は減点していません。 ここは重要な区別です。

判定は、申告された正式名称と別名の集合に対して、サイト上の Organization 構造化データの name がすべて一致すれば 2 点、一部なら 1 点、どれも一致しなければ 0 点です。alternateName として正常に併存している表記と、同一性が食い違っている状態を分けています。

つまり測っているのは「表記の数」ではなく「申告と実装のずれ」です。 これは冒頭の原則（強くするのではなく、曖昧でなくする）とも、sameAs の件数を採点しない判断とも一貫します。

現在の診断でエンティティに直接対応するのは 1 項目です。

evidenceDirectness: inferred にしてあります。 表記の揺れが実体解決を妨げること自体は知識グラフの一般的な性質ですが、「正式名称・通称・英語表記・カタカナ表記が混在する」という形の問題は日本語に固有で、これを診断項目に持つのは SILVE 独自の判断だからです。

ただし今回、部分的な公式根拠が見つかりました。 Google は Organization 構造化データについて「サイト名に使っているものと同じ name / alternateName を使う」よう推奨しています。表記の一貫性そのものには公式の推奨があるということです。

それでも inferred は据え置きます。 Google の記述はサイト名との一致についてであり、この項目が実際に検出している日本語の表記揺れとは範囲が違うためです。部分的に一致する資料を、項目全体の直接的根拠へ格上げしないというのが 2026.08.2 で evidenceDirectness を導入した理由そのものです。

採点していないもの

企業がまず整えるもの

1. 正式表記を決める — 表記を 1 つに統一する
2. 読みを併記する — 必要なら（SILVE なら「シルヴェ」）
3. 一文で説明できるようにする — 何をするサービスなのか
4. 運営者を明示する — 誰が運営しているのか
5. 公式 URL を決める — canonical なブランド URL
6. 関係を整理する — 会社 / ブランド / 商品 / 著者
7. 構造化データを本文と一致させる
8. 実際に公式管理しているプロフィールだけを紐付ける

「AI に理解させる文章」を量産する必要はない

Google は生成 AI 検索向けに特別な書き方は不要とし、AI システムは同義語や一般的な意味を理解できるため、キーワードの変化形を網羅する必要はないと明記しています。

「SILVE は AI 検索診断です」という文を 100 ページにコピーすることは Entity Optimization ではありません。

むしろ Google は、生成 AI 検索において独自の視点・一次体験・専門性に基づく内容を重視するよう案内しています。ブランドの文脈を作るなら、自己紹介文の量産よりそのブランドにしか出せない一次情報のほうが筋が通ります。

「何者か」は自称だけでは完成しない

企業は自社サイトに「私たちは AI 検索のリーダーです」と自由に書けます。しかし外部のシステムにとってそれは自称です。

公式記録・プラットフォームのデータ・独立した報道・研究での引用は、資料としての役割が違います。 SILVE が Evidence を扱うときに情報源の役割を分けるのと同じ考え方が、エンティティの情報にも当てはまります。

まとめ

• エンティティの核心は名前ではなく「その名前が何を指しているか」です
• Google の Knowledge Graph を企業が直接構築することはできません。 ただし構造化データ・Business Profile・クレーム済みナレッジパネルからの修正提案という経路で事実情報を提供できる場合はあります。採否と統合は Google 側が決めます
• Knowledge Graph に載ることと AI 検索で有利になることは別です
• Knowledge Graph API に存在することがエンティティの確立に対応する、という公式の根拠はありません。 名前で引くこと自体は想定の用途ですが、結果を確立の判定に使う根拠が無いので採点しません。加えて提供元は本番依存を想定していません
• sameAs は同一性の情報であって権威の蓄積ではありません。 件数を増やしても意味がありません
• 共起は研究上エンティティ解決に役立ち得ますが、AI 検索の順位への効果は未検証です
• 不自然な言及の獲得は、見た目ほど役に立たないと Google 自身が書いています
• Wikipedia を AI 対策目的で作ることは推奨しません
• ビジネスプロフィールはオンライン専業の事業を対象外と明記しています。 「Entity 対策に作る」は提供元の規定に反します

Entity Optimization とは、エンティティを「強くする」ことではありません。エンティティを「曖昧でなくする」ことです。

Web 上で名前が何回出たかではなく、その名前が何者なのかを曖昧なく説明できるか。それが出発点です。

Framework Record

この記事の判断を、あとから検証できる形で記録したものです。本文の結論（Core Rules）と、SILVE が内部で持つ記録の項目、参照した一次資料が入っています。

Framework Name: Entity Identity Readiness Version: Methodology 2026.08.46 Status: SILVE Operational Model（業界標準ではない） Last Verified: 2026-08-13 実装: src/lib/metrics/authority.ts の authority.entity_consistency（重み 3 / 直接性 inferred）

Layers

1. Identity — 何者か
2. Type — どの種類のエンティティか
3. Relationship — 他のエンティティとどうつながるか
4. Consistency — 重要な属性が矛盾していないか
5. External Evidence / Ecosystem Presence — 外部でどう表現されているか（Visibility ではない。AI の出力の観測とは別）

Core Rules

1. エンティティを「強くする」のではなく「曖昧でなくする」
2. Knowledge Graph presence ≠ AI Visibility
3. Knowledge Panel presence ≠ 推薦のランキング要因
4. sameAs は同一性 resolution。件数を最適化しない
5. 言及の数を採点しない。共起の回数も採点しない
6. 層 1〜4 は準備状態、層 5 は External Evidence、AI が実際に認識・引用・推薦したかが可視性。 3 つを混ぜない
7. プラットフォーム固有の仕様を他社へ一般化しない
8. 部分的に一致する資料を、項目全体の直接的根拠へ格上げしない

一次資料

• Google — Introducing the Knowledge Graph: things, not strings（2012-05-16） https://blog.google/products/search/introducing-knowledge-graph-things-not/
• Google Search Central — Organization (Organization structured data) https://developers.google.com/search/docs/appearance/structured-data/organization
• Google — Knowledge Graph Search API https://developers.google.com/knowledge-graph
• Google Search Central — Google's Guide to Optimizing for Generative AI Features on Google Search https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
• Google — Guidelines for representing your business on Google https://support.google.com/business/answer/3038177
• schema.org — sameAs https://schema.org/sameAs
• Radhakrishnan, Talukdar & Varma — ELDEN: Improved Entity Linking Using Densified Knowledge Graphs（NAACL 2018） https://aclanthology.org/N18-1167/