LLMOに効くJSON-LD入門 ── AIに正しく情報を伝える構造化データの基本

Q: JSON-LDを入れるだけでAIの回答に出る？

JSON-LDはAIに正しく情報を伝えるための手段であり、引用を保証するものではありません。ただし、構造化データがないサイトよりも、あるサイトの方がAIに選ばれやすいのは確かです。他の施策（llms.txt、robots.txt、E-E-A-T、結論ファースト）と組み合わせることで効果が高まります。

Q: Schema.orgのスキーマは全部覚える必要がある？

不要です。LLMO対策として重要なのは Organization、FAQPage、Article、Person、BreadcrumbList の5つがコアです。まずはこの5つを正しく実装することに集中してください。

こんにちは、株式会社テラ AIエンジニアリングチームです。

「構造化データって、SEOの話でしょ？」

そう思っている方も多いかもしれません。しかし今、構造化データはLLMO（AI検索最適化）においても極めて重要な要素になっています。

ChatGPTやGemini、Claudeといった生成AIは、Webページの見た目ではなく、HTMLのソースコードに書かれた情報を読み取って回答を生成します。その際に、構造化データ（JSON-LD）が正しく実装されているかどうかで、AIが自社の情報を「信頼できるソース」として認識してくれるかが変わります。

実際、当社がGeminiに「株式会社テラ」を質問した際、英語表記が「TERRA CO., LTD.」と誤って返ってきました（正しくはTERA Inc.）。これは、構造化データでの正式な宣言がなければ、AIはWeb上の断片的な情報を寄せ集めるしかなく、結果として誤認が起きるという好例です。

この記事では、JSON-LDとは何か、なぜLLMOに効くのか、Google公式の推奨スタンス、llms.txtとの関係、そして具体的にどう書くのかを、実装例を交えて解説します。

INDEX

JSON-LDとは何か
Google公式ガイドラインの推奨
LLMOに効く主要なスキーマ一覧
JSON-LDとllms.txtの関係
基本的な書き方
設置方法
実例：株式会社テラの実装
よくある疑問

JSON-LDとは何か

構造化データの仕組み

構造化データとは、Webページの内容を「機械が読める形」で記述するためのフォーマットです。人間が見る画面上の表示は変わりませんが、HTMLのソースコードにメタ情報を埋め込むことで、検索エンジンやAIがページの内容を正確に理解できるようになります。

たとえば、Webページのテキストに「株式会社テラ、名古屋市中区に本社を置くWeb制作会社です」と書いてあるのと、JSON-LDで同じ情報が "name": "株式会社テラ", "addressLocality": "名古屋市中区" と構造化されているのでは、AIにとっての「確信度」がまったく異なります。テキストは「誰かがそう言っている」情報ですが、構造化データは「このサイトが公式に宣言している」情報です。

なぜJSON-LD形式なのか

構造化データの記述方法にはいくつかの種類（Microdata、RDFa、JSON-LD）がありますが、2026年現在、JSON-LDがGoogleの推奨フォーマットであり、事実上の標準です。

Googleは公式ドキュメント（Google Search Central - 構造化データの仕組み）で、JSON-LDを「推奨形式」と明記しています。理由は明快で、既存のHTMLを変更する必要がなく、<script type="application/ld+json"> タグを追加するだけで済むため、実装・保守の両面でメリットが大きいからです。

JSON-LDは、HTMLの<head>内または<body>内に記述します。既存のHTMLテンプレートに影響を与えず、テンプレートエンジンからの出力やCMSプラグインからの注入もしやすい。この「非侵襲的」な性質が、実務での採用率が高い理由です。

LLMOにおける役割

AIは、Web上の膨大なテキスト情報の中から「この情報は信頼できるか」「この情報の出典は何か」を判断する必要があります。JSON-LDで構造化された情報は、AIにとって以下のような価値を持ちます。

情報の種類が明確：「これは組織情報」「これはFAQ」「これは記事」と種別がわかる
出典が明示される：著者、組織、公開日、更新日が機械可読な形で記載されている
E-E-A-Tの証明：経験・専門性・権威性・信頼性が、テキストの主張ではなくデータとして表現される
情報の照合が可能：構造化データとHTMLテキストの内容が一致していれば、AIは「この情報は確からしい」と判断できる

SEOの文脈では「あるとベター」程度だった構造化データが、LLMOでは「ないと不利」に変わりつつあります。AIは回答に含める情報源の信頼性を判断する際、構造化データの有無を重要なシグナルとして参照しているためです。

Google公式ガイドラインの推奨

JSON-LDの重要性は、個人の見解ではなく、Googleが公式に推奨しているものです。

Google Search Centralでは、構造化データについて以下のように述べています。

リッチリザルトの表示条件として構造化データが必要（リッチリザルトの仕組み）
Organization構造化データで「組織の曖昧性を排除（disambiguate）」できる（Organization構造化データ）
FAQPage構造化データで検索結果にFAQリッチリザルトを表示できる
Article構造化データで記事のタイトル、著者、日付を明示できる

特に注目すべきは「disambiguate（曖昧性の排除）」という表現です。これはGoogleが使っている公式な用語で、同名の企業・組織をAIが混同しないように構造化データで区別せよ、という意味です。LLMO対策で言う「AIに正しく認識させる」と完全に同じ概念です。

つまり、JSON-LDの実装は「AIに気に入ってもらうための裏技」ではなく、Googleが公式ガイドラインで推奨している正規の施策です。

LLMOに効く主要なスキーマ一覧

Schema.orgが定義するスキーマは数百種類ありますが、LLMO対策として特に重要なのは以下の5つです。

1. Organization ── AIへの「公式名刺」

会社・組織の基本情報を記述します。AIが「この会社は何者か」を理解するための名刺のような存在で、全ページ共通で設置するのが基本です。

LLMO観点での重要性が最も高いスキーマです。なぜなら、Organizationが正しく実装されていることは、サイト内の他のすべての構造化データの信頼性の土台になるからです。ArticleのpublisherもFAQPageのmainEntityの帰属先も、すべてOrganizationに紐づきます。

詳しくは Organizationスキーマの重要性で解説しています。

2. FAQPage ── 最も即効性のあるスキーマ

よくある質問と回答のペアを記述します。AIは対話型の構造を引用しやすいため、LLMOにおいて最も即効性のあるスキーマです。

なぜ即効性があるのか。生成AIは「ユーザーの質問に対して回答を返す」システムです。FAQPageは「質問→回答」の構造がそのままJSON-LDで定義されているため、AIにとって引用のハードルが極めて低い。テキストの中から「ここが質問で、ここが回答だ」と解析する手間がゼロになるのです。

当社のLLMO診断ツールでもFAQPageスキーマを実装しており、公開直後からPerplexityでの引用が確認できています。

詳しくは FAQコンテンツの重要性で解説しています。

3. Article ── コンテンツの鮮度と出典を証明

ブログ記事やコラムの構造を記述します。著者（author）、公開日（datePublished）、更新日（dateModified）が機械可読になり、コンテンツの鮮度と信頼性をAIに伝えられます。

LLMOにおけるArticleスキーマの重要性は、E-E-A-Tの証明手段であるという点です。「この記事は、〇〇という著者が、△△という組織のもとで、2026年4月に書いた」という情報が構造化されていれば、AIはその記事の信頼度を大幅に高く評価します。

逆に、著者名も日付もないブログ記事は、AIにとって「いつ、誰が書いたかわからない」情報であり、引用の優先順位が下がります。

4. Person ── 著者の専門性を証明

著者やキーパーソンの情報を記述します。E-E-A-Tの「専門性（Expertise）」「経験（Experience）」を構造化データで証明するための要素です。

Personスキーマには、名前だけでなくjobTitle（肩書き）、worksFor（所属組織）、knowsAbout（専門領域）、sameAs（SNSやプロフィールページのURL）を含められます。これらの情報が揃っているほど、AIは「この人物は実在し、この分野の専門家である」と判断しやすくなります。

5. BreadcrumbList ── サイト構造の理解を助ける

パンくずリストの構造を記述します。サイト全体の階層構造をAIが理解しやすくなり、「このページはサイトのどの位置にあるか」「どのカテゴリに属するか」がわかるようになります。

直接的なLLMOへの影響は他のスキーマより小さいですが、サイト全体の「整理されている感」をAIに伝える効果があります。構造化されたサイトは信頼性が高いと判断されやすいのです。

JSON-LDとllms.txtの関係

LLMO対策においては、JSON-LDとllms.txtは別々の施策ではなく、補完関係にあるセットです。

役割の違い

	形式	対象読者	伝えること	特性
JSON-LD	構造化データ（HTML内）	検索エンジン + AIクローラー	ファクト（社名、住所、設立年等）	機械可読、解釈不要
llms.txt	Markdown（独立ファイル）	LLM / AIエージェント専用	文脈（強み、得意分野、推薦理由等）	自然言語、ニュアンス込み

例えるなら、JSON-LDは名刺、llms.txtは名刺を渡しながらする自己紹介トークです。名刺だけでは肩書きしかわからない。トークだけでは「あの人何て会社だっけ？」となる。両方あって初めて、AIは「何者か」を正確に理解できます。

情報の一貫性が絶対条件

JSON-LDに書いた社名・住所と、llms.txtに書いた社名・住所は必ず一致させてください。

AIは複数ソースを照合して情報の正確性を検証します。もしJSON-LDには「東京都千代田区」と書いてあるのに、llms.txtには「名古屋市中区」と書いてあった場合、AIは「どちらが正しいかわからない」と判断し、どちらの情報も使わないという選択をすることがあります。

社名の英語表記（Inc. / Co., Ltd.の違い等）、住所の表記ゆれ（「4丁目1番18号」と「4-1-18」の違い等）まで含めて、すべてのソースで統一することが重要です。

基本的な書き方

Organization の記述例

会社情報ページやトップページに設置します。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "会社名",
  "alternateName": "英語名",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "description": "会社の概要説明",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "市区町村",
    "addressRegion": "都道府県",
    "postalCode": "000-0000",
    "addressCountry": "JP"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-xx-xxxx-xxxx",
    "contactType": "customer service"
  },
  "foundingDate": "1996",
  "knowsAbout": ["Web制作", "LLMO", "ブランディング"]
}

ポイント： alternateName（別名・英語名）とknowsAbout（専門領域）は、LLMO対策として特に重要です。alternateNameは同名企業との区別に、knowsAboutはAIが「何の会社か」を判断する材料になります。

FAQPage の記述例

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "質問文をここに記述",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "回答文をここに記述"
      }
    }
  ]
}

ポイント： 回答文（text）は結論ファーストで書いてください。AIが引用する際、回答文の冒頭部分をそのまま使うケースが多いためです。「よくあるご質問」ページだけでなく、サービスページやブログ記事にも関連FAQを設置するのが効果的です。

Article の記述例

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事のタイトル",
  "author": {
    "@type": "Person",
    "name": "著者名",
    "jobTitle": "肩書き",
    "worksFor": {
      "@type": "Organization",
      "name": "会社名"
    }
  },
  "datePublished": "2026-04-14",
  "dateModified": "2026-04-14",
  "publisher": {
    "@type": "Organization",
    "name": "会社名",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

ポイント： authorにPersonスキーマを入れ子にし、worksForでOrganizationに紐づけることで、「この記事は、〇〇社の△△さんが書いた」という情報がAIに構造的に伝わります。dateModifiedは更新のたびに変更し、コンテンツの鮮度を示してください。

設置方法

HTMLへの埋め込み

<head>内、または<body>の末尾に以下の形式で記述します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  ...
}
</script>

1ページに複数のJSON-LDブロックを設置することも可能です。たとえば、当社のLLMO診断ツールのページにはOrganization、WebApplication、FAQPageの3つを同時に設置しています。Googleも1ページ複数のJSON-LDブロックを認めています。

WordPressの場合

テーマのheader.phpやfooter.phpに直接記述するか、SEOプラグイン（Rank Math、Yoast SEO等）の構造化データ機能を利用します。

プラグインを使う場合の注意点として、デフォルト設定では社名とURLだけの最低限の内容になっていることが多いです。description、address、foundingDate、knowsAbout、alternateName等のLLMOに重要なプロパティは、プラグインの設定画面から手動で追加してください。

設置後の確認

GoogleのRich Results TestでJSON-LDが正しく解析されるか確認できます。エラーや警告があれば修正してください。また、ブラウザのデベロッパーツール（F12 → Elements → ld+jsonで検索）でも、実際に出力されているJSON-LDを確認できます。

実例：株式会社テラの実装

当社では、LLMOの自社実践として以下の構造化データを実装しています。

LLMO診断ツールのページ

Organization ── 株式会社テラの組織情報（alternateName、knowsAbout含む）
WebApplication ── 診断ツール自体のスキーマ（無料ツール、LLMOチェッカーとして定義）
FAQPage ── よくある質問5件のQ&Aペア
BreadcrumbList ── TERACOYA > LLMO診断ツールの階層構造

これにより、AIが当社のツールを「何のためのツールか」「誰が提供しているか」「どんな質問に答えるツールか」「サイトのどこに位置するか」を構造的に理解できる状態になっています。

効果

ツール公開後、PerplexityでLLMO関連のキーワードを検索した際に、当社の情報が引用されるケースが確認できています。特にFAQPageスキーマの内容がそのまま引用されるケースが多く、構造化データの即効性を実感しています。

よくある疑問

JSON-LDを入れるだけでAIの回答に出る？

JSON-LDは「AIに正しく情報を伝える」ための手段であり、引用を保証するものではありません。ただし、構造化データがないサイトよりも、あるサイトの方がAIに選ばれやすいのは確かです。

構造化データは、LLMO対策の5つの柱（llms.txt、robots.txt、構造化データ、E-E-A-T、結論ファースト）のうちの1つであり、他の施策と組み合わせることで効果が高まります。

全ページに入れるべき？

Organizationは全ページ共通で入れるのが推奨です。FAQPage、Articleは該当するページのみ。BreadcrumbListはすべてのページに入れるのが理想です。

優先順位としては、Organization（全ページ）→ FAQPage（FAQがあるページ）→ Article（ブログ・コラム）→ BreadcrumbList（全ページ）→ Person（著者ページ） の順で実装するのが効率的です。

間違った内容を書くとペナルティがある？

あります。Googleは、ページに表示されている内容と矛盾するJSON-LDを「スパム構造化データ」として扱い、リッチリザルトの除外やペナルティの対象にすると明言しています。ページに書いてある事実を正確に構造化するのが鉄則です。

特に注意すべきは、FAQPageスキーマをJSON-LDで実装したのに、同じFAQをHTMLの可視テキストとして掲載していないケース。これはGoogleから不正と判断されます。JSON-LDとHTMLは必ず内容を一致させてください。

Schema.orgのスキーマは全部覚える必要がある？

不要です。Schema.orgには数百種類のスキーマがありますが、LLMO対策として重要なのは本記事で紹介した5つ（Organization、FAQPage、Article、Person、BreadcrumbList）がコアです。まずはこの5つを正しく実装することに集中してください。

まとめ

JSON-LDは、LLMOにおける「AIへの正式な自己紹介」です。

テキストとして書かれた情報だけでなく、構造化されたデータとしてAIに情報を渡すことで、信頼性の判断材料が増え、引用される確率が上がります。

Googleが公式に推奨している施策であり、llms.txtと組み合わせることで「ファクトの証明（JSON-LD）× 文脈の説明（llms.txt）」の相乗効果が期待できます。

まだ実装していない方は、まずOrganizationスキーマから始めてください。それだけで、AIがあなたの会社を「知らない」状態から「知っている」状態に変わる可能性があります。

構造化データの実装、ご相談ください

「JSON-LDを実装したいが、自社サイトへの入れ方がわからない」
「WordPressにどう組み込めばいいか知りたい」
「LLMO対策として、構造化データの優先順位を整理したい」
「llms.txtとJSON-LDの整合性を確認してほしい」

そうした方は、ぜひ一度ご相談ください。

→ お問い合わせはこちら