なぜスキーマだけでは不十分なのか

Schema.orgを正しく実装しているにもかかわらず、AIに引用されない——そうした状況の多くは、スキーマとコンテンツ本文の意味的整合性が欠如していることが原因です。 AIは構造化データを「ヒント」として参照しますが、最終的に回答に引用するか否かは本文テキストのエンティティ認識を優先して判断します。スキーマの name プロパティに正しい製品名が入っていても、本文で「当社のツール」「こちらのサービス」と記述されていれば、 AIはその文が何を指しているかを確定できず、引用候補から外れます。

この問題を根本から解決するアプローチが、オントロジーを前提にしたコンテンツ編集です。本記事では、オントロジーの概念からSchema.orgとの紐付け、Sightedのスコアへの影響まで、実装者・コンテンツ設計者向けに解説します。なお本手法は検証が進行中であり、効果はドメインやコンテンツタイプによって差があります。

オントロジーとは何か — ナレッジグラフとの関係

オントロジー（Ontology）とは、ある領域に存在する 「概念（エンティティ）」と「概念間の関係（プロパティ）」を形式的に定義した体系 です。図書館の分類体系（タクソノミー）が「モノの階層」を表すのに対し、オントロジーは「モノとモノの関係」まで含みます。

用語	定義	例
エンティティ	独立して存在する概念・物・人	Sighted、TKBase、永淵翔大、AEO
クラス	エンティティの種別	SoftwareApplication、Organization、Person、Concept
プロパティ（関係）	エンティティ間をつなぐ述語	provider（提供者）、author（著者）、measures（測定対象）
インスタンス	クラスに属する具体的なエンティティ	Sighted は SoftwareApplication のインスタンス

GoogleのナレッジグラフはRDF（Resource Description Framework）に基づく大規模オントロジーです。 ChatGPTやPerplexityも、学習データから類似の内部エンティティグラフを構築していると考えられています。 AIが「Sighted は TKBase が提供する AEO モニタリングツールである」と正確に回答できるのは、この関係が学習データの中で一貫して記述されているからです。

AEOにおけるエンティティ認識の重要性

AIが引用判断をする際のエンティティ依存

生成AIが回答を生成する際、対象クエリに関連するエンティティを特定し、そのエンティティについて信頼できる記述を持つソースを引用します。エンティティが曖昧なソース（「当社」「弊社ツール」等）は、 AIがどのエンティティに関する記述かを確定できないため、引用候補のスコアが下がります。

Profound Insights の調査（2025年11月）によると、エンティティ名を明示した段落は、代名詞・省略を使った段落と比較して AI引用率が平均 1.8倍高い という傾向が確認されています。ただしこの数値はカテゴリ・ドメインによる偏りがあり、すべての領域で再現するとは限りません。

コンテキスト依存解消（Coreference Resolution）の問題

「それ」「これ」「こちら」「同社」といった指示語・省略は、人間の読者には自然でも、AIのコンテキスト依存解消（Coreference Resolution）を要求します。解消に失敗すると、その段落全体のエンティティ紐付けが不定になります。特に セクションをまたいだ参照（前のH2セクションのエンティティを後のH3で「それ」と呼ぶ）はリスクが高く、AIが引用ブロックを切り出す際に情報欠損が生じます。

オントロジー設計の実施手順

ステップ1: ドメインエンティティ表の作成

サイト全体で登場するエンティティを洗い出し、クラス・正式名称・別名・定義文をまとめます。この表がコンテンツ編集の「辞書」になります。

クラス（Schema.org型）	正式名称	別名・略称	定義（冒頭60語で書く）
Organization	TKBase株式会社	TKBase	TKBaseは、AI時代のビジネス成長支援を行う日本のスタートアップ。AEOコンサルティングサービスおよびAEOモニタリングツールSightedを提供する。
SoftwareApplication	Sighted	Sighted AEOツール	SightedはTKBaseが開発するAEOモニタリングプラットフォーム。ChatGPT・Perplexity・Geminiにおける企業のMention・Citation・Response Shareを計測する。
Person	永淵翔大	永淵	永淵翔大はTKBaseの代表取締役。京都大学卒業後、M&A分析およびAEOコンサルティングの実務を経て、Sightedを開発。
Concept	AEO（Answer Engine Optimization）	AEO、回答エンジン最適化	AEOとは、ChatGPTやPerplexityなどのAI回答エンジンにおいてコンテンツが引用・推薦されるよう最適化する手法。SEOの進化形として2024年以降注目を集める。

ステップ2: 関係（プロパティ）の定義

エンティティ間の関係を動詞で明確化します。この作業がSchema.orgのプロパティ設計と直接対応します。

主語	関係（動詞/Schema.orgプロパティ）	目的語
TKBase株式会社	provider / 提供する	Sighted
TKBase株式会社	provider / 提供する	AEOコンサルティングサービス
Sighted	measures / 計測する	AI可視性（Citation・Mention）
永淵翔大	founder / 代表を務める	TKBase株式会社
永淵翔大	author / 著者である	各ナレッジ記事
Sighted	relatedTo / 関連する	AEO（概念）

ステップ3: Schema.orgネスト構造への変換

ステップ2の関係表をJSON-LDに落とし込みます。重要なのは、関係を ネストで表現する（IDで参照するだけでなく、主要プロパティをインラインで含める）ことです。 AIはJSON-LDのIDをたどる能力が限定的なため、インライン展開のほうが認識精度が高まります。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tkbase.co.jp/#organization",
      "name": "TKBase株式会社",
      "url": "https://tkbase.co.jp",
      "description": "AI時代のビジネス成長支援を行う日本のスタートアップ。AEOコンサルティングサービスおよびAEOモニタリングツールSightedを提供する。",
      "founder": {
        "@type": "Person",
        "@id": "https://tkbase.co.jp/team/nagabuchi#person",
        "name": "永淵 翔大",
        "jobTitle": "代表取締役",
        "sameAs": [
          "https://twitter.com/tkbase_nagabuchi",
          "https://www.linkedin.com/in/nagabuchi"
        ]
      },
      "makesOffer": {
        "@type": "Offer",
        "itemOffered": {
          "@type": "SoftwareApplication",
          "@id": "https://sighted.tkbase.co.jp/#product",
          "name": "Sighted",
          "applicationCategory": "BusinessApplication",
          "description": "ChatGPT・Perplexity・GeminiにおけるMention・Citation・Response Shareを計測するAEOモニタリングプラットフォーム。",
          "provider": {
            "@id": "https://tkbase.co.jp/#organization"
          }
        }
      }
    }
  ]
}

@graph を使うと、同一JSON-LD内で複数のエンティティを定義し @id で相互参照できます。これにより「OrganizationがPersonを含み、SoftwareApplicationを提供する」という関係が一枚のスキーマで表現されます。

ステップ4: 本文テキストへのエンティティ明示ルールの適用

スキーマ設計が完了したら、コンテンツ本文にも同じエンティティ名・関係を反映します。以下のルールを編集ガイドラインとして使用してください。

ルール	修正前	修正後
初出時は正式名称＋クラスを明記	「当社のツールは…」	「AEOモニタリングツールSighted（TKBase提供）は…」
セクション冒頭では省略せず再提示	「これを使えば…」（前H2から続く）	「Sightedを使えば…」
関係を動詞で明示	「TKBaseとSightedの…」	「TKBaseが開発・提供するSightedは…」
定義文は冒頭60語以内に配置	（定義なしでいきなり機能説明）	「SightedはAEOモニタリングプラットフォームで、AI回答内の…を計測する。」から始める
数値・統計にはソースと日付	「引用率が2倍になる」	「引用率が平均1.8倍高い（Profound Insights, 2025年11月）」

ステップ5: 検証 — Sightedスコアへの影響確認

オントロジー設計を反映したコンテンツをデプロイした後、以下の指標で効果を検証します。

指標	ツール	確認のタイミング
テクニカルスコア（スキーマネスト構造）	Sighted 無料診断	デプロイ直後
Mention / Citation 数の推移	Otterly / Peec	2〜4週間後
エンティティ認識の正確性	ChatGPTへの直接質問	随時（「Sightedとは何ですか？」「TKBaseはどんな会社ですか？」など）
構造化データの有効性	Google リッチリザルトテスト	デプロイ直後

Sightedスコアとオントロジー設計の対応関係

Sightedの診断スコアのうち、以下の項目がオントロジー設計の質と直接対応します。

ネスト型スキーマ（Organization → WebPage → Article）：ステップ3で実装した @graph 構造が正確に認識されているか
Publisher / Author の紐付け：記事ごとのAuthorとPublisherがPersonおよびOrganizationのIDと一致しているか
質問形式見出し：エンティティを含む質問形式の見出しがAEO引用対象として評価される

スコアが「High」以上の問題として検出されている場合は、オントロジー設計より先にテクニカル問題を解消してください。スキーマのネスト構造が壊れていると、本文のエンティティ記述がどれほど正確でもAIのエンティティグラフ構築が正しく行われません。

よくある設計ミスと対処法

ミス1: sameAs を設定せずに別名を混在させる

「Sighted」「sighted.tkbase.co.jp」「サイテッド」を同一ページ内で混在させると、 AIは別エンティティとして扱う場合があります。 sameAs に正規URL・SNSプロフィール・Wikidataを列挙し、本文での表記は定義表の正式名称に統一してください。

ミス2: @id を絶対URIではなく相対パスで書く

"@id": "#organization" のような相対IDは、複数ページにまたがるエンティティグラフの一貫性を壊します。 "@id": "https://tkbase.co.jp/#organization" のように絶対URIを使用してください。Sightedの診断でも「相対URLによるバリデーションエラー」として検出されます。

ミス3: オントロジーとタクソノミーを混同する

カテゴリ階層（パン屑リスト・taxonomy）は「AEOツール＞モニタリング＞ Sighted」のような IS-A関係のみを表しますが、オントロジーは「SightedはTKBaseが開発し、AEO可視性を計測し、ChatGPT・Perplexityに対応する」という多様な関係（HAS-A、DOES、RELATED-TO）を含みます。 BreadcrumbListのみ実装してオントロジー設計が完了したと判断しないでください。

ミス4: Concept（抽象概念）エンティティを定義しない

「AEO」「GEO」「Citation」などの専門用語は、サービスや製品と同様にエンティティとして定義が必要です。用語集ページ（Glossary）に DefinedTerm スキーマを実装し、その定義をコンテンツ本文で一貫して使用することで、 AIが専門用語の定義ソースとしてサイトを認識しやすくなります。

{
  "@type": "DefinedTerm",
  "@id": "https://sighted.tkbase.co.jp/glossary/aeo#term",
  "name": "AEO",
  "alternateName": "Answer Engine Optimization",
  "description": "ChatGPTやPerplexityなどのAI回答エンジンにおいてコンテンツが引用・推薦されるよう最適化する手法。",
  "inDefinedTermSet": {
    "@type": "DefinedTermSet",
    "name": "Sighted AEO用語集",
    "url": "https://sighted.tkbase.co.jp/glossary"
  }
}

実行チェックリスト

ドメインエンティティ表（クラス・正式名称・定義文・別名）を作成した
エンティティ間の関係を動詞で定義し、Schema.orgプロパティに対応付けた
@graph を使って Organization・Person・Product の関係をネストで表現した
すべての @id が絶対URIになっている
主要エンティティに sameAs を設定した（公式URL・SNS・Wikidata）
コンテンツ本文で代名詞・省略表現を正式名称に置き換えた
各セクション冒頭60語以内にエンティティ定義文を配置した
用語集エントリに DefinedTerm スキーマを実装した
Googleリッチリザルトテストでスキーマバリデーションを確認した
Sightedの診断でネスト構造・Author紐付けが正常と判定されている
Otterly / Peec でMention・Citation のベースラインを計測し、施策前の数値を記録した

次のステップ

本手法はオントロジー設計〜スキーマ実装〜コンテンツ編集の連携を扱います。個別の実装詳細は以下のナレッジ記事を参照してください。

構造化データ（Schema.org）ガイド — 推奨・非推奨タイプの一覧と実装方法
GEO完全ガイド — AI引用全体のフレームワーク
AI可視性モニタリングツールガイド — 効果測定の手順
Citability（引用可能性） — 最適パッセージ長・回答ブロックの設計

検証が進んだ段階で、本記事の知見はナレッジベースに contentType: "framework" として昇格させる予定です。測定データや反例があればフィードバックをお寄せください。

オントロジーを前提にしたAEOコンテンツ編集 — エンティティ設計からSchema.orgまで