JSON-LDをSEOの「スープ」にするのをやめ、LLM向けに機械可読なナレッジレイヤーを構築した方法

あるB2Bハードウェアのクライアント向けに、完璧に見えるSchema.orgの実装をデプロイしたときの話です。バリデーターはすべてオールグリーン。Google Search Consoleのエラーもゼロで、全カタログでリッチリザルトを獲得していました。

そこでChatGPT-4oに、同社の主力産業用ポンプの仕様比較を出力させてみました。

結果は完全な失敗でした。

技術公差の半分はハルシネーションを起こし、競合他社の保証規定を引っ張ってきたのです。LLMを旧来の検索エンジンと同じように扱った結果、手痛いしっぺ返しを食らいました。

なぜトークン化が複雑なフォーマットを破壊するのか

根本的な理由はシンプルです。

LLMはウェブページを読んでいません。トークンを読んでいます。

AIボットがサイトをクロールする際、DOMビューアのように美しくネストされたJSON-LDスクリプトを見るわけではありません。構造的な美しさは剥ぎ取られ、生の文字列がサブワード単位のトークンへと分解されます。

標準的なSchema.orgマークアップをページに配置すれば、AIが複雑に紐づく製品エンティティの階層構造を保持してくれると思い込んでいました。

しかし、そうはなりませんでした。

トークン化によって、それらの明示的な関係性はフラットに潰されてしまったのです。モデルは孤立した用語自体は認識できても、ノード間の述語論理を見失いました。ただの「統計的スープ」と化したのです。

アルファベット順の用語集だけを渡して、専門書のストーリーを推測させようとするようなものです。

従来のSEOマークアップだけではもはや不十分です。トークン化の過程でエンティティ間の関係性を保持できなければ、構造化データは何の役にも立ちません。

「とにかくスキーマを増やせ」という安直なアドバイスにはうんざりしています。汎用的なSEOプラグインを重ねがけしたところで、トークン取り込み時の構造崩壊は防げません。

LLMが生のバイトストリームから正確なエンティティ関係を再構築できなければ、生成AIの回答内に自社ブランドは存在しないも同然です。

---

生成AI最適化（GEO）において従来のSchema.orgが破綻する理由

そもそもLLMはJSON-LDスキーマを利用しているのか？

最新の大規模言語モデルは、推論フレームワークやナレッジグラフと組み合わせることで、機械側の文脈を誤認（ハルシネーション）することなく正確なエンティティ関係を抽出するために、JSON-LD構造化データを強く頼りにしています。

AIモデルは構造化データを読み込んでいます。ただし、転置インデックスを作る従来の検索ボットとは処理の仕方が根本的に異なります。

多くのチームはSchema.orgを表層的なチェックリストとして扱っています。Articleタグを貼り、FAQブロックを投げ込み、リッチリザルトが出るのを祈るだけです。2020年のGoogleならそれで通じましたが、現在の生成エンジン最適化（GEO）では完全に通用しません。

モデルは装飾的なマークアップを見にきているのではありません。ノード間の明確な接続関係を抽出しているのです。

AIモデルがスキーマを取り込んでいると気付いている開発チームでさえ、肥大化した実装で自滅しているケースが珍しくありません。

プラグインの競合：重複とオーバーヘッド

昨晩、15,000点以上のSKUを抱える大規模ECサイトの検証に3時間を費やしました。Perplexityが主要な製品スペックをどうしても無視してしまうという相談です。

ソースコードを開いてみると、惨状が広がっていました。

サイト全体のメタデータ用、ユーザーレビュー自動化用、古いEC拡張機能用と、3つのWordPressプラグインが同時に動いていたのです。それぞれが個別に無秩序な@contextブロックを出力していました。1つの製品ページに、競合する3つの@type: Organization定義と、異なる通貨設定が書かれた重複製品ノードが存在していたのです。

関連バリアントのスキーマがループした結果、スクレイパーが本文にたどり着く前に、生のJSON-LDペイロードだけで400KBを超えていました。

問題はここにあります。AIスクレイパーはトークン制限やリクエストのタイムアウトを厳密に設定しています。自律エージェントが0.5MBもの冗長なJSONテキストに遭遇すると、ペイロードを途中で切り捨てるか、未解析のゴミデータとして破棄してしまいます。

そして、これが最大の問題へと直結します。

ほとんどのAIクローラーは、クライアントサイドのJavaScriptを実行しません。

カスタマーレビューを遅延読み込みしていたり、信頼性シグナルをページ下部の動的スクリプトでページネーションしていたりすると、AIクローラーには空の殻しか見えません。Googleの従来のウェブクローラーなら、セカンダリキューでクライアントサイドスクリプトをレンダリングしてくれることもあります。しかし、オンデマンドでリアルタイム検索を行うLLMボットは待ってくれません。

最初の1バイト目から静的で決定論的なHTMLにデータがハードコードされていなければ、機械にとってそのデータは存在しないのと同じです。

---

パラダイムシフト：ナレッジレイヤーとしての構造化データ

この10年間、JSON-LDは見栄えを整えるためのギミックとして扱われてきました。コードの断片を追加し、検索結果に星評価やFAQアコーディオンが出ることを祈るだけの、表層的なパッチでした。

その時代は終わりました。

構造化データはリッチリザルト生成ツールではなく、大規模言語モデルのための基盤ナレッジレイヤーです。

AIエンジンがサイトを評価するとき、高解像度のメイン画像を探しているわけではありません。求めているのは曖昧さのない事実、すなわち直接的なノード、検証済みのプロパティ、具体的な関係性です。自然言語のテキストだけに頼ると、モデルは統計的な確率に基づいて意味を推測せざるを得なくなります。

検索拡張生成（RAG）の限界を超える

誰もが、素のRAGパイプラインですべて解決できると考えがちです。構造化されていないブログ記事をベクターデータベースに放り込み、コサイン類似度で上位チャンクを取得して、あとはLLMに任せればいいと。

しかし、このやり方は頻繁に破綻します。

専門的なB2Bカタログの複雑なクエリに対し、標準的なベクターベースのRAGと、エンティティを適切にモデル化したクリーンなJSON-LDナレッジグラフを直接比較テストしました。

ベクターRAGは混乱を極めました。断片的なチャンクを取得し、似たモデル番号間で価格帯を取り違え、前後の文脈が曖昧なためにスペックのハルシネーションを起こしました。

次に、クリーンなJSON-LDグラフをモデルに読み込ませました。

ハルシネーションはゼロ。即座にエンティティが特定されました。モデルは不要なコンテキストトークンを消費することなく、正確な階層構造、ネストされた属性、製品間の関係性を完全に理解しました。

ベクター類似度は関連テキストを見つけ出しますが、構造化データは機械可読なコンテキストを直接届けます。RAGがLLMに生の食材を渡すものだとすれば、適切なJSON-LD構造は完成された設計図を渡すようなものです。AIに自社のエンティティを極めて正確に引用させたいなら、肥大化したテキストの流し込みをやめ、マークアップ内に直接ナレッジレイヤーを構築してください。

---

AIの可視性を確保する実践的JSON-LDフレームワーク

JSONスキーマがLLMに認識されているか確認する方法

JSONスキーマがLLMに認識されているかを確かめるには、サーバーログを直接分析する必要があります。従来の検索インデックスしか追跡できないGoogle Search Consoleに頼るのではなく、AIクローラー（GPTBotやClaudeBotなど）のユーザーエージェントを特定し、JSON-LDペイロードが埋め込まれた特定の静的HTMLファイルを正常に取得しているか確認します。

Google Search Consoleを見ても、OpenAIやAnthropicのスクレイパーがOrganizationスキーマを取り込んだかどうかは一切分かりません。GSCはGooglebotと従来の検索結果の機能を追跡するツールに過ぎないからです。

GSCの確認は後回しにし、GPTBot、ClaudeBot、PerplexityBotからのリクエストを分離する自動ログフィルターを構築しました。監視したのはインデックスステータスではなく、生の取得ペイロードです。

ボットが生のHTMLを取得し、その静的レスポンスに統合されたJSON-LDグラフが含まれていれば、データは正常にパースされます。もしJSON-LDがハイドレーション後にクライアント側のJavaScriptで挿入されていた場合、ボットは200 OKを記録しても、空白スペースをパースしてそのまま離脱してしまいます。

AI向けOrganizationスキーマとFAQPageスキーマの設計

生成AIの回答内で自社エンティティを確実に提示させるには、決定論的な構造が必要です。利用可能なスキーマタイプを1つのページに手当たり次第に詰め込むと、ノイズを生むだけです。

実際にデプロイしている構造パターンは以下のとおりです。

• Organizationスキーマ（アンカー）： ドメイン全体にグローバルに配置。エンティティの主体を確立し、誰が発信しているかをLLMに伝えます。同時にsameAsを使って検証済みのWikidata IDや外部の権威あるプロフィールと紐づけます。
• Article / TechArticleスキーマ（コンテキスト）： 無駄を削ぎ落とした構成。authorやdatePublishedに加え、ページのトピックを定義済みエンティティノードに結びつける明示的なabout / mentions配列を重視します。
• FAQPageスキーマ（ダイレクトフィード）： LLMは決定論的なQ&Aフォーマットを高精度で処理します。重要な技術パラメータや仕様を、明確な質問と回答のペアとしてJSON-LDペイロード内に直接マッピングします。

多くのエンジニアリングチームが躓くのが配信方法です。

AIボットに対してクライアントサイドレンダリングに頼ることはできません。

React経由でFAQスキーマを動的にマウントしていたクライアントの案件で、手痛い失敗を経験しました。AIクローラーは最初のサーバーレスポンスだけを取得し、クライアントスクリプトを実行することはなかったのです。

原則は極めてシンプルです。JSON-LDペイロードは、0バイト目から初期HTMLレスポンス内に静的レンダリングされていなければなりません。ハイドレーションの遅延も、クライアントサイドでのインジェクションも不要です。

---

Google向けの最適化をやめ、エンティティのエンジニアリングへ移行する

旧来の検索最適化は限界を迎えつつあります。検索結果の青いリンクばかりを追うやり方は、現代の情報検索の仕組みを無視しています。本質的な変化はマシン・ツー・マシン（M2M）の通信へのシフトです。

現実として、AIエージェントがインターフェース内で直接回答をまとめ、選択肢を比較し、ユーザーの検索意図を完結させてしまうと、ユーザーはサイトをクリックしなくなります。そのエージェントが確定的なマークアップを通じて自社の属性や関係性を検証できなければ、回答から自社ブランドが丸ごと除外されます。

M2M SEOの未来

スキーマが単なる後付けとして扱われ、肥大化したDOMツリーの上に適当にスクリプトが貼られている状態では、コンテキストウィンドウが無駄に消費されます。整理されていないトークンノイズをパースすることはレイテンシを悪化させ、モデルに確かなデータではなく統計的な確率に頼った推測を強いることになります。

AIボットが構造化されていないテキストからエンティティの関係性を推測せざるを得ない場合、自社ではなく競合他社の情報をハルシネーションします。

AnswerShaperでは、スキーマを単なるSEOの追加要素ではなく、自律モデルのための明示的なAPIとして扱っています。高密度で相互接続されたエンティティグラフを静的コードに直接落とし込むことで、パース時の曖昧さを排除し、わずかなトークンコストで検証済みの純粋なデータを届けることが可能です。

もしM2Mを考慮していないSEOを続けているなら、急速に消え去りつつある検索環境のために設計しているようなものです。プロンプトの中に組み込まれるか、さもなければ存在しないものとして扱われるかの二者択一です。今すぐコアインフラに機械可読なナレッジレイヤーを組み込むか、生成AIが中心となるウェブで不可視の存在になるかを選ばなければなりません。エンティティスタックの構築手法について詳しくは、トークン消費を抑えAI向けナレッジグラフ最適化を極める方法のガイドをご覧ください。