AEO×「AIエージェント時代のナレッジグラフ・エンティティ最適化」設計ガイド【2026年版】——Wikidata・Wikipedia・Google Knowledge Graph・LLMの「内部知識」に自社エンティティを登録させるためのエンティティSEO・構造化データ連鎖・外部リンク戦略

はじめに——「AIに認識される」と「AIにクロールされる」は別物

これまで本サイトでは、AIエージェントに自社サイトを正しく扱ってもらうための一連の設計ガイドを公開してきました。競合分析（エンティティ比較）、商品データフィード、トランザクション設計——これらは共通して「AIエージェントが訪問時に取得する情報」を最適化するアプローチです。

しかし、AIエージェント時代にはもう一段階上のレイヤーがあります。それは、ChatGPT・Claude・Gemini・Perplexityが「すでに知っている知識（pretraining knowledge）」として自社を記憶している状態を作ることです。

たとえばユーザーが「日本の中小企業向けAI導入支援をしている会社を教えて」とChatGPTに尋ねたとき、AIはWebをクロールせずに即答できるケースがあります。これはAIの「内部知識」、つまり学習データの中に該当エンティティが埋め込まれているからです。

この「AIの記憶に自社を組み込む」ための体系的アプローチが、本記事で扱うエンティティ最適化（Entity SEO）とナレッジグラフ戦略です。

---

なぜ今「エンティティ最適化」が重要なのか

LLMの内部知識とWebクロールの二層構造

2026年現在、AIエージェントが情報を取得するルートは大きく2つに分かれています。

取得ルート	特徴	最適化アプローチ
内部知識（Pretraining）	モデル学習時に取り込まれた情報。即座に応答可能で、引用元なしで語られる	エンティティ登録、ナレッジグラフ、信頼性の高い外部ソースへの掲載
外部取得（RAG / Web検索）	クエリ時にWebをクロールして取得。引用元付きで提示される	サイトアクセシビリティ、構造化データ、コンテンツSEO

従来のSEO・AEO施策は後者（外部取得）に集中していました。しかし、AIエージェントが「自分の知っている範囲で候補を絞り込んでから、必要に応じて外部取得する」という挙動を取ることが増えてきており、そもそも候補リストに入っているかどうかが決定的な競争要因になっています。

エンティティとは何か——「文字列」ではなく「もの」として認識される

エンティティ（Entity）とは、Web上で一意に識別できる「もの」のことです。会社、人物、製品、サービス、概念、場所などが該当します。

検索エンジンやLLMは、文字列のマッチングではなくエンティティのマッチングで情報を処理します。たとえば「Apple」という文字列は、果物のリンゴなのか、Apple社なのか、レコードレーベルのApple Recordsなのか——文脈と関係性から判別されます。

この判別を可能にしているのが、Wikidataに代表されるナレッジグラフ（Knowledge Graph）です。ナレッジグラフは「エンティティ」と「エンティティ間の関係性」をグラフ構造で記述したデータベースで、Google Knowledge GraphもこのWikidataを主要なソースの1つとしています。

---

AIが認識する「エンティティ・リンキング」の仕組み

エンティティ・リンキングの3ステップ

LLMやAIエージェントが「Aさんは、B社のCEO」「B社は○○業界の会社」といった関係性を認識するプロセスは、概ね以下の3ステップで構成されます。

1. メンション検出（Mention Detection）：テキストから固有名詞や概念を抽出する
2. 候補生成（Candidate Generation）：抽出した文字列に対応しそうなエンティティ候補をナレッジグラフから列挙する
3. ディスアンビギュエーション（Disambiguation）：文脈と関係性から最も適切な候補を選択する

この3ステップを通過するためには、自社が「ナレッジグラフ上に存在し、適切な関係性が定義されている」必要があります。Wikidata・Google Knowledge Graphに登録されていないエンティティは、AIにとって「存在しない」のと同等です。

ナレッジグラフ埋め込み（Knowledge Graph Embedding）

近年のLLMは、学習過程でナレッジグラフの情報をベクトル空間に埋め込んでいます。これにより、明示的に学習していない関係性も推論できるようになります。たとえば「A社のCEOは誰か」を学習し、別途「A社はB業界に属する」を学習していれば、「B業界のCEOにはどんな人がいるか」という質問にAさんを候補として出せます。

つまり、自社のエンティティが意味のある関係性のネットワークに組み込まれていることが、AIに「思い出してもらう」ための鍵になります。

---

戦略1：Wikidataへの登録——すべての出発点

なぜWikidataが最重要なのか

Wikidataは、Wikipediaを運営するWikimedia Foundationが運営する、構造化データのためのオープンナレッジベースです。Google Knowledge Graph、Bing、Apple Siri、Amazon Alexa、そして主要なLLMの学習データに広く利用されています。

重要なのは、Wikipediaの記事がなくてもWikidataには登録できるという点です。Wikipediaが「特筆性（notability）」の高い厳格な基準を持つのに対し、Wikidataはより緩やかな基準で、構造化データとして意味のあるエンティティであれば登録可能です。

Wikidata登録の実践手順

Wikidataへの登録は、以下のステップで進めます。

ステップ1：アカウント作成と既存エンティティの確認

まずWikidataでアカウントを作成し、自社名で検索して既存エンティティが存在しないか確認します。同名の別組織と混同されないよう、慎重に確認することが重要です。

ステップ2：新規アイテム作成とQ番号取得

「新しいアイテムの作成」から、自社のラベル（名称）と説明を日本語と英語の両方で登録します。登録が完了すると、Q番号（例：Q12345）と呼ばれる一意の識別子が付与されます。これがエンティティの「住所」となり、以降あらゆる構造化データから参照される最重要IDです。

ステップ3：プロパティ（属性）の設定

Q番号を取得したら、以下のような主要プロパティを設定していきます。

プロパティ	意味	具体例
P31（instance of）	エンティティの種類	「business（事業会社）」「software company」など
P17（country）	所在国	「Japan（Q17）」
P159（headquarters location）	本社所在地	「東京（Q1490）」
P856（official website）	公式サイトURL	https://example.com
P169（CEO）	代表者	代表者のQ番号
P571（inception）	設立年月日	2020-04-01
P452（industry）	業界	「人工知能（Q11660）」
P2002（X username）	Xアカウント	@yourcompany

ステップ4：出典（リファレンス）の付与——最重要

Wikidataで最もつまずきやすいのが出典の付与です。すべてのプロパティ値には、その情報が真実であることを裏付ける外部ソース（URL、書籍、報道など）を出典として付ける必要があります。出典のないデータは、他の編集者によって削除される可能性があります。

自社サイトを出典にすることも可能ですが、第三者ソース（業界メディア、報道、政府データベースなど）を併記することで信頼性が大きく高まります。

削除されないための注意点

• 宣伝色を排除する：「業界をリードする」「革新的な」などの主観的表現は避け、事実のみを記述
• 自分で編集する場合は利益相反（COI）を開示：関係者であることをユーザーページに明記
• 独自研究を載せない：外部ソースで検証可能な情報のみ
• 段階的に育てる：最初から完璧を目指さず、最低限の情報からスタートし、出典が増えるたびに拡張

---

戦略2：Wikipedia記事の作成——特筆性の壁を越える

Wikipedia掲載のハードルは高い

Wikipediaに自社の記事を作るのは、Wikidataよりはるかに難しいです。Wikipediaには厳格な3つの基準があります。

1. 特筆性（Notability）：主題が独立した複数の信頼できる情報源で十分に取り上げられていること
2. 中立的観点（Neutral Point of View）：すべての観点を公平に提示すること
3. 検証可能性（Verifiability）：すべての情報が出典で検証可能であること

特に厳しいのが「特筆性」です。会社の場合、自社サイトやプレスリリース、SNS発信は特筆性の根拠になりません。独立した第三者媒体（全国紙、業界専門誌、書籍など）で実質的に取り上げられた実績が必要です。

特筆性をクリアする現実的なアプローチ

Wikipedia掲載を目指す場合、まずは「掲載に値する事実を作る」ことから始めます。

• 業界専門メディア（日経XTECH、ITmedia、TechCrunch Japan など）への記事掲載を地道に積み上げる
• 業界団体での受賞、政府関連プログラムへの採択など、客観的に検証可能な実績を作る
• 書籍出版・専門誌への寄稿で「業界専門家」としてのポジションを確立する
• カンファレンス登壇など、第三者が記録に残す活動を増やす

これらの「特筆性の素材」が3〜5件以上揃ってから、Wikipedia記事の作成を検討するのが現実的です。

記事作成時の鉄則

• 自分で書かない、他者に依頼する：自社関係者の編集は利益相反として削除リスクが高い。Wikipedia編集経験のある第三者に依頼するのが望ましい
• 宣伝口調を徹底排除：「先進的」「優れた」などの形容詞を一切使わず、事実のみを記述
• 1記事につき出典15件以上を目安に：各文に対して独立した第三者ソースを付ける
• 最初は小さく：完璧な長文より、出典の充実した短い記事から始める

なお、Wikipedia記事ができると、対応するWikidataアイテムにWikipedia記事へのリンク（sitelinks）が自動的に追加され、エンティティとしての信頼性が大きく向上します。

---

戦略3：Google Knowledge Graphへの認識——sameAsプロパティ連鎖

Google Knowledge Graphとは

Google Knowledge Graphは、Googleが独自に構築・管理しているエンティティデータベースです。検索結果に表示される「ナレッジパネル（右側に表示される情報ボックス）」の情報源であり、Gemini・AI Overviewsの根幹データでもあります。

Google Knowledge Graphに認識されるためには、Wikidataへの登録が大きな助けになりますが、それだけでは不十分です。複数の信頼できるソースから一貫した情報が発信されていることを、Googleが「triangulation（三角測量）」によって検証する必要があります。

sameAsプロパティ連鎖の設計

「同じ実体（エンティティ）が、複数の場所で同じ情報として存在する」ことをGoogleに伝えるのが、Schema.orgのsameAsプロパティです。自社サイトのOrganization Schemaに、関連する全プロフィールへのリンクをsameAsで列挙します。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "株式会社サンプル",
  "alternateName": "Sample Inc.",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "foundingDate": "2020-04-01",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q12345",
    "https://ja.wikipedia.org/wiki/株式会社サンプル",
    "https://www.crunchbase.com/organization/sample-inc",
    "https://www.linkedin.com/company/sample-inc",
    "https://x.com/sampleinc",
    "https://www.facebook.com/sampleinc",
    "https://github.com/sampleinc",
    "https://www.youtube.com/@sampleinc"
  ]
}

このsameAs連鎖により、Googleは「これらは全部同じエンティティを指している」と認識し、一貫性のある情報として統合します。

Person SchemaとOrganization Schemaの相互リンク

CEO・代表者の個人エンティティと、組織エンティティを相互リンクすることで、ナレッジグラフ上の関係性が強化されます。

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/about-ceo/#person",
  "name": "山田太郎",
  "jobTitle": "代表取締役CEO",
  "worksFor": {
    "@id": "https://example.com/#organization"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q67890",
    "https://www.linkedin.com/in/yamada-taro",
    "https://x.com/yamada_taro"
  ]
}

そしてOrganization Schema側でも、employeeまたはfounderプロパティで個人エンティティを参照します。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "株式会社サンプル",
  "founder": {
    "@id": "https://example.com/about-ceo/#person"
  }
}

この双方向リンクにより、AIは「Aさん」と「B社」が単なる別々のエンティティではなく、特定の関係性で結ばれていることを認識します。

Product Schemaとの連結

自社が提供する製品・サービスもエンティティとして登録し、Organizationと連結します。これはAIショッピングエージェント向けの商品データフィード設計とも連動する施策で、AIに「会社」「人」「製品」の3層エンティティ構造を一貫して認識させることができます。

---

戦略4：信頼性の高い外部データソースへの登録

LLMが学習ソースとして参照する「権威ある外部DB」

Wikipedia・Wikidataの次に、LLMが学習データとして高頻度で参照すると考えられる外部データソースがいくつかあります。これらに自社情報を登録することは、エンティティ最適化の重要な柱です。

カテゴリ	主要プラットフォーム	登録のポイント
スタートアップDB	Crunchbase, PitchBook, Tracxn	会社概要、資金調達、創業者情報を網羅。プレスリリース提供で更新頻度を確保
ビジネスSNS	LinkedIn (Company Page), X (Verified)	カバー画像・概要・URL・業種を完全入力。定期的な投稿で活性化シグナルを発信
SaaSレビュー	G2, Capterra, GetApp, ITreview（日本）, Boxil（日本）	製品プロフィール、機能リスト、料金、ユースケースを詳細に記述。ユーザーレビューを促進
業界メディア	日経XTECH, ITmedia, TechCrunch Japan, ZDNET Japan	記事掲載・寄稿・インタビュー。エンティティとしての言及を増やす
政府・公的DB	gBizINFO（経済産業省）, J-Stage（学術）	事業所情報、業種コード、論文掲載を確実に
開発者コミュニティ	GitHub, Stack Overflow, Hugging Face, Qiita	OSSプロジェクト公開、技術ブログ、企業アカウントの活性化
地図データ	Google Business Profile, OpenStreetMap, Apple Business Connect	住所・営業時間・電話番号を全プラットフォームで一致させる

NAP一貫性——情報の不一致が信頼性を損なう

Name（名称）、Address（住所）、Phone（電話番号）の頭文字を取った「NAP」は、Local SEOでは古くから重視されてきた概念です。エンティティ最適化でも、すべての登録先でNAPが完全に一致していることが重要です。

名称表記の揺れ（「株式会社サンプル」「サンプル株式会社」「Sample Inc.」「Sample Corporation」）、住所のフォーマット差異（「東京都千代田区…」「Chiyoda-ku, Tokyo…」）、電話番号のハイフン有無——こうした細かい不一致が積み重なると、AIは「同じエンティティかどうか確信が持てない」と判断します。

登録時に使う表記を1つの「マスター表記」として定め、すべての登録先・自社サイト・Schemaで統一することを徹底しましょう。

---

戦略5：LLM学習タイミングを踏まえた「タイムラグ設計」

LLMの学習サイクルと反映ラグ

LLMの内部知識は、モデルの学習データのカットオフ時点で固定され、新モデルがリリースされるまで更新されません。主要モデルは概ね以下のような頻度で更新されています。

• OpenAI GPTシリーズ：大規模アップデートは年1〜2回程度。中間で「knowledge update」も実施されることがある
• Anthropic Claudeシリーズ：新モデルのリリースに合わせて学習データが更新される
• Google Gemini：頻繁にアップデートされるが、内部知識の更新頻度は明示されていない

つまり、今Wikidata・Wikipediaに登録した情報が、AIの内部知識に反映されるまでには数か月〜1年以上のタイムラグがあると考えるべきです。

「次の学習で取り込まれる」ための仕込み戦略

このタイムラグを踏まえると、エンティティ最適化は長期投資として捉える必要があります。

1. 四半期ごとの登録・更新サイクル：Wikidataのプロパティ追加、外部DBの情報更新を四半期ごとに必ず実施。学習データに含まれる確率を最大化する
2. 「複数ソース戦略」で冗長化：1か所だけでなく、5〜10か所の信頼できるソースに同じ情報を散布する。LLMが複数ソースから一貫した情報を学習することで内部知識として定着しやすくなる
3. 新製品・新サービスの発表時は同時多発展開：プレスリリース、Wikidata、業界メディア、SNSを同日に展開し、検出されやすいシグナル波形を作る
4. 過去の実績も継続発信：古い情報こそ「定着済みの事実」として認識される。一度登録した情報を消したり大幅に変更したりしない

---

戦略6：AIに「あなたの会社」を聞く検証プロトコル

月次モニタリングの基本クエリ

エンティティ最適化の効果は、定期的にAIに直接質問して確認します。最低でも月1回、以下のクエリパターンをChatGPT・Claude・Gemini・Perplexityで実行し、応答を記録します。

カテゴリ	クエリ例	確認ポイント
直接認知	「[自社名]について教えて」	正確な情報が返ってくるか。誤情報や混同があるか
関係性認知	「[自社名]のCEOは誰か」「[CEO名]はどんな会社の人か」	人と組織の関係が正しく認識されているか
カテゴリ想起	「日本の[業界]企業を5社挙げて」	業界カテゴリの中で自社が想起されるか
ユースケース想起	「[自社の課題領域]を解決する会社を教えて」	具体的な課題に対して候補に挙がるか
競合比較	「[競合A]と[自社]の違いは何か」	競合との位置付けが正しく認識されているか

結果の解釈と打ち手

応答パターン	意味	打ち手
正確に応答される	内部知識として定着している	定期更新で情報の鮮度を維持
「Web検索で確認」となる	内部知識にはまだ無いが、Web経由では到達可能	Wikidata登録、外部DBへの掲載強化
誤情報が返る	類似名のエンティティと混同されている可能性	Wikidataで明確な属性を追加して識別性を高める
「知らない」と返る	内部知識にもWeb経路にも情報が乏しい	外部メディア掲載、SNS発信を含む包括的な露出強化

モニタリング結果の記録方法

スプレッドシートで「日付・モデル名・クエリ・応答全文・正誤判定・スコア」を記録し、四半期ごとにトレンド分析します。応答品質が向上していれば施策が効いている証拠です。

競合のエンティティ最適化との比較分析については、AEO×競合分析の記事も合わせて参考にしてください。

---

実装ロードマップ——3〜12か月の段階的アプローチ

Phase 1：基礎構築（1〜2か月目）

• 自社サイトのOrganization Schema・Person Schemaを実装
• sameAsプロパティに既存の主要プロフィールを列挙
• Google Business Profile、LinkedIn Company Page、X認証バッジを完備
• NAP情報の表記マスターを確定し、既存登録先の不一致を全修正

Phase 2：エンティティ登録（2〜4か月目）

• Wikidataアイテムを作成し、最低限の主要プロパティを設定
• Crunchbase、G2/Capterra、ITreview、Boxilなどの業界DBに登録
• 各プロパティに第三者ソースを出典として付与
• サイトのSchemaにWikidataへのsameAsリンクを追加

Phase 3：信頼性ソース構築（3〜9か月目）

• 業界メディアへの記事掲載・インタビュー機会を能動的に作る
• カンファレンス登壇、書籍寄稿、専門誌記事執筆を継続
• Wikipedia記事掲載に向けた「特筆性の素材」を3〜5件以上蓄積
• OSS公開、技術ブログ運営でGitHub・Hugging Faceでのプレゼンスを構築

Phase 4：Wikipedia化と高度化（6〜12か月目）

• Wikipedia記事の作成（特筆性が確立されてから）
• Wikidataのプロパティ拡張（受賞歴、関連企業、子会社など）
• 月次AIモニタリングを開始し、応答品質をスコア化
• 応答品質が低いカテゴリに対して追加施策を実施

---

よくある質問（Q&A）

Q1. Wikipediaに記事がない場合、Wikidataに登録する意味はある？

あります。むしろWikipediaがない段階こそWikidataから始めるべきです。Wikidataは構造化データとしてLLMに参照されやすく、Wikipediaに比べてはるかに登録しやすいためです。Wikipedia記事は将来的な目標として、まずWikidataで実績を積み上げましょう。

Q2. 中小企業や個人事業主でもエンティティ最適化はできる？

可能です。ただし、Wikipediaの特筆性基準は高いため、まずはWikidata、業界DB（Crunchbase、ITreviewなど）、Schema.org実装、SNS整備から着手するのが現実的です。地道にメディア掲載を増やし、3〜5年かけてエンティティとしての存在感を育てていく長期視点が重要です。

Q3. 効果が出るまでどのくらい時間がかかる？

Google Knowledge Graphへの反映は施策開始から3〜6か月、LLMの内部知識への反映はさらに長く、6〜18か月程度を見込むべきです。短期的な効果を求めるよりも、四半期ごとに着実に施策を積み上げる長期投資として捉えてください。

Q4. 自社のエンティティ情報が誤って登録されている場合はどうする？

Wikidata・Wikipediaの場合は、編集権限を持つアカウントで修正提案を行えます。利益相反を開示した上で、トークページで議論し、出典付きで修正することが推奨されます。Google Knowledge Graph（ナレッジパネル）の修正は、Google Search Consoleからの「変更を提案」機能で対応します。

Q5. 競合がエンティティ最適化を進めている場合、追いつけるか？

追いつくことは可能ですが、競合が先行している場合は2〜3年単位の取り組みが必要です。差別化のポイントは、競合がカバーしていない切り口（特定のニッチ業界、地域、技術領域）でエンティティ・プレゼンスを確立することです。「業界全体で1位」を狙うより、「特定セグメントで圧倒的1位」を目指すほうが現実的です。

Q6. AI検索で誤情報が返ってくる場合の対応は？

誤情報の発生源を特定することが第一歩です。Wikidata・Wikipedia・業界DBのいずれかに古い情報や誤情報が残っているケースが多いです。発生源を修正した上で、AIの応答を3〜6か月かけて継続観察します。即座に修正されることは稀で、複数のモデルアップデートを経て徐々に修正されることが一般的です。

---

まとめ——「AIに記憶される会社」になるための長期投資

AIエージェント時代のエンティティ最適化は、従来のSEOやAEOとは異なる時間軸と思考が求められます。改めて押さえるべきポイントを整理します。

1. 内部知識への組み込みは長期投資。3〜18か月のタイムラグを前提に、四半期サイクルで継続的に積み上げる。

2. Wikidataから始める。Wikipedia記事は最終目標、まずは構造化データの基盤を作る。

3. sameAs連鎖でエンティティを束ねる。サイト・SNS・外部DBを1つのエンティティとしてGoogleとAIに認識させる。

4. 第三者ソースの蓄積が鍵。自社発信だけでは信頼性が積み上がらない。業界メディア・受賞・登壇・寄稿を地道に。

5. 月次でAIに自社を聞く。定期モニタリングが施策の効果測定であり、修正の起点でもある。

AIエージェントが情報の「一次窓口」になりつつある今、「AIにクロールしてもらう」のではなく「AIに記憶してもらう」段階に踏み込むことが、これからの数年の競争優位を決めます。本記事のロードマップを参考に、自社のエンティティ最適化を始めてみてください。

---

関連記事

• AEO（Answer Engine Optimization）入門｜エンティティSEOの基礎
• ブランドレピュテーション×AEO｜Wikidataとナレッジパネル戦略
• AEO×競合分析｜AIによるエンティティ比較への対応
• AEO×AIショッピングエージェント｜商品データフィード設計
• AEO×AIエージェント｜トランザクション完了のためのコンバージョン設計

---

参考リンク

• Wikidata公式
• Wikipedia「特筆性」ガイドライン
• Schema.org Organization
• Schema.org sameAs プロパティ
• Google Knowledge Graph Search API

免責事項：本記事は2026年4月時点の公開情報および筆者の知見に基づく情報提供です。Wikidata・Wikipediaの編集ポリシー、各プラットフォームの登録基準、LLMの学習サイクルは変更される可能性があります。実際の登録や編集にあたっては、各プラットフォームの最新ガイドラインを必ず確認してください。