JSON-LDとは何か。AI検索・リッチリザルト・E-E-A-Tに必須な理由
各章へクイックジャンプ：
あなたのWebサイトは「見えている」かもしれません。でも、Googleのアルゴリズムや、ChatGPT・Perplexity・Geminiといった AI検索エンジンに「正しく読まれている」かどうかは別問題です。JSON-LD（JavaScript Object Notation for Linked Data） は、 その「正しく読まれる」を実現する技術です。2026年現在、これはSEOの小技ではなく、 AI時代におけるWebサイトの「機械向け名刺」として機能しています。
1. JSONとJSON-LDは何が違うのか
JSON（JavaScript Object Notation）は、エンジニアなら誰でも知っているデータ交換フォーマットです。 しかし JSON-LD は、その JSON に「意味（セマンティクス）」を持たせた拡張仕様です。@context と @type という2つの特殊キーが、その核心です。
// ただのJSON：機械はこれが「会社情報」だと知る方法がない
{
"name": "株式会社サンプル",
"url": "https://example.com",
"email": "info@example.com"
}
// JSON-LD：機械が「これはOrganizationスキーマの会社情報だ」と理解できる
{
"@context": "https://schema.org", // 語彙の定義元（schema.orgを参照せよ）
"@type": "Organization", // このデータの種類（組織情報）
"name": "株式会社サンプル",
"url": "https://example.com",
"email": "info@example.com"
}@context は「このデータの言葉の定義元はどこか」を示します。@type は「このデータが何であるか」を宣言します。 この2つがあることで、GoogleのクローラーもChatGPTも、 「あ、これは組織情報だ」と明確に解釈できるようになります。
「Linked Data（リンクトデータ）」とは、異なるWebサイト間のデータが 意味的につながっている 状態を指します。 たとえば「AIOGeoScan」というOrganizationが https://aiogeoscan.com と紐づけられることで、 AIは「この記事の著者」「この会社のサービス」「このサービスのレビュー」などを グラフ構造として追跡・理解できるようになります。これがGoogleが「Knowledge Panel（ナレッジパネル）」を 表示できる仕組みの根幹です。
2. Microdata・RDFa との違いと、なぜJSON-LDが推奨されるのか
構造化データの記述方式は JSON-LD だけではありません。歴史的には Microdata と RDFa という方式が先に存在しました。 しかし Google公式ドキュメントはJSON-LDを最も強く推奨 しており、その理由は明確です。
| 方式 | 記述場所 | HTMLとの分離 | Googleの推奨度 | 開発・保守のしやすさ |
|---|---|---|---|---|
| JSON-LD | <script>タグ内（HTML本体と分離） | ✅ 完全分離 | ⭐⭐⭐ 最推奨 | ◎ JavaScriptで動的生成も容易 |
| Microdata | HTML要素のインライン属性 | ❌ HTML内に混在 | ⭐⭐ 対応 | △ HTMLが複雑になり保守が困難 |
| RDFa | HTML要素のインライン属性 | ❌ HTML内に混在 | ⭐ 限定的サポート | △ 記述量が多く学習コスト高 |
JSON-LDの最大のメリットは HTMLとデータの完全分離 です。 Microdataはすべての構造化データをHTMLの属性として記述するため、 デザイン変更のたびにSEO設定にも影響が及ぶリスクがあります。 JSON-LDは <head> または <body> 内の <script type="application/ld+json"> タグに 独立して記述するため、Next.jsなどのフレームワークで動的に生成することも極めて容易 です。
3. JSON-LDが果たす3つの役割：SEO・AI検索・E-E-A-T
役割① Googleリッチリザルトへの表示（直接的なSEO効果）
最も広く知られた効果が、Googleの検索結果における リッチリザルト（旧称：リッチスニペット） への反映です。 ただし、2026年4月13日時点では、どのスキーマでも同じように表示が狙えるわけではありません。現在も実務上の価値が高いのは、Article / Product / Review / BreadcrumbList のように Googleの現行サポートが安定しているものです。FAQPage や HowTo は schema.org としては有効でも、 Google検索での表示面では期待値を低めに見積もる必要があります。
Q&Aの意味構造を明示する用途では有効。ただしGoogle検索でのFAQ表示は現在かなり限定的。→ 第3章で「2026年時点の使いどころ」を解説
著者名・公開日・更新日・パブリッシャー情報を検索結果に表示。信頼性の可視化に直結。→ 第2章でテンプレートを公開
URLの代わりにパンくずリストを検索結果に表示。サイト構造の明示とユーザーの信頼感向上。→ 第2章でテンプレートを公開
評価星・価格・在庫状況を検索結果に表示しやすい現役スキーマ。ECでは特に重要。→ 第3章で詳細解説
役割② AI検索エンジンでの構造理解を補助する
2024〜2025年にかけてAI検索が急拡大した結果、構造化データはGoogleだけでなく、ChatGPT Search・Perplexity・Google AI Overviews・Geminiなどでページ理解を補助する要素 として扱う価値が高まりました。 ただし、各サービスがJSON-LDをどの程度・どの順番で使うかは公表範囲が限られます。 以下は Googleの公開情報 + 実務上の観測 をもとにした整理です。
- Perplexity / ChatGPT Search： ページの主題・著者・組織・更新日時を機械的に把握しやすくなるため、 引用候補としての解像度を上げる補助情報として機能しやすいと考えられます。
- Google AI Overviews（SGE）： Googleは構造化データを検索理解に使うことを公開しています。AI Overviews でも、 Organization・Person・Article といったエンティティの明示は、ページ理解とナレッジグラフ接続の補助になります。
- Gemini： Googleの検索理解基盤と近い文脈で扱われる以上、構造化データの整備は無駄になりません。 ただし「FAQPageやHowToがそのまま回答骨格に使われる」といった断定までは避け、 まずは Article・Organization・Person・BreadcrumbList を優先するのが安全です。
役割③ E-E-A-Tの「機械的証明」
GoogleのSearch Quality Evaluator Guidelinesが定める E-E-A-T（Experience・Expertise・Authoritativeness・Trustworthiness） は、 コンテンツの評価基準として広く知られています。しかし、「専門性がある」「信頼できる」という主張を Googleのアルゴリズムに証明する手段が必要です。JSON-LDはその機械的証明を可能にします。 E-E-A-Tの各要素をどう設計・証明するかは、E-E-A-T 実践ガイドで体系的に解説しています。
Experience（経験）の証明
Article スキーマの author プロパティに Person スキーマをネストし、 著者の knowsAbout（専門分野）・hasOccupation（職種）・alumniOf（学歴）を記述することで、 「このコンテンツは実際の経験を持つ専門家が書いた」という構造的な証明になります。
Expertise・Authoritativeness（専門性・権威性）の証明
Organization スキーマで sameAs プロパティにWikipediaページやLinkedInページのURLを記載することで、 「この組織は実在し、外部から認証されている」という権威性をGoogleのナレッジグラフに伝えられます。 また award（受賞歴）や memberOf（業界団体への加盟）も有効です。
Trustworthiness（信頼性）の証明
WebSite スキーマで privacyPolicy・termsOfService のURLを、Organization スキーマで contactPoint（連絡先情報）・legalName（法人名）・address（住所）を記述することで、「実体のある信頼できる事業者だ」という証明になります。 特に法律・医療・金融（YMYL）系サイトでは必須とも言える実装です。
4. schema.org とは何か：JSON-LDの語彙体系
JSON-LD を書く際、@context に "https://schema.org" を指定します。 これは schema.org という語彙定義サイトを参照先として指定しているためです。 schema.orgは2011年にGoogle・Microsoft（Bing）・Yahoo!・Yandexが共同で設立した非営利組織が管理する 「機械が理解できる意味的語彙のリスト」です。
- コンテンツ系：Article、BlogPosting、NewsArticle、TechArticle、FAQPage、HowTo、Recipe、Book
- 組織・人物系：Organization、Person、LocalBusiness、MedicalOrganization、EducationalOrganization
- 商品・サービス系：Product、Service、Offer、Review、AggregateRating
- イベント・場所系：Event、Place、PostalAddress, GeoCoordinates
- ナビゲーション系：WebSite、WebPage、BreadcrumbList、SiteLinksSearchBox
- 雇用系：JobPosting、EmployerAggregateRating
重要な原則があります：スキーマは「正直に」記述することです。 FAQPageスキーマを実装してもページにQ&Aコンテンツが実際には存在しない場合、 Googleはスパムポリシー違反としてペナルティを適用します。 JSON-LDはページに実際に存在するコンテンツを「機械語に翻訳する」ツールであって、 ないものをあるように見せるためのツールではありません。
5. JSON-LDの基本構文：最初に覚える5つのキー
@context 語彙の定義元を指定。ほぼ常に "https://schema.org" を指定します。 これがないとキーの意味が解釈されません。
@type このデータの種類を宣言。"Organization"、"Article"、"FAQPage" など、 schema.orgで定義された型名を使います。
@id このエンティティのユニークな識別子URL。 同じエンティティを複数ページから参照するときに一貫性を保つためのキーです。 通常はそのエンティティの正規URLを指定します。
name、url、description などの通常のJSONキー。 schema.orgが各 @type に対して使えるプロパティを定義しています。
プロパティの値に別のスキーマオブジェクトを埋め込めます。 例：author プロパティの中に @type: "Person" をネストするなど。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/articles/json-ld-basics",
"headline": "JSON-LDとは？AI検索時代に必須の構造化データ入門",
"description": "JSON-LDの基礎から実装方法まで、わかりやすく解説します。",
"datePublished": "2026-04-12",
"dateModified": "2026-04-13",
"author": {
"@type": "Person",
"name": "山田 太郎",
"url": "https://example.com/author/yamada"
},
"publisher": {
"@type": "Organization",
"name": "株式会社サンプル",
"url": "https://example.com",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"image": "https://example.com/articles/json-ld-basics/ogp.jpg",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/articles/json-ld-basics"
}
}
</script>💡 HTMLのどこに書くのが正解か？
JSON-LDの <script type="application/ld+json"> タグは、<head> 内でも <body> 内でも Googleは読み取ります。 Next.js App Router では <head> 内（layout.tsxやpage.tsx内）に配置するのが一般的です。 ページのコンテンツと一致するよう、各ページに個別のJSON-LDを実装することを強く推奨します。
6. AI開発ツール（Cursor・Claude Code・Copilot）との関係
ここまでは「AIに読まれる」という観点でJSON-LDを解説してきましたが、AI開発ツールのユーザーにとって特に重要な視点 があります。 CursorやClaude Code、GitHub CopilotでWeb開発をしている場合、 これらのAIはあなたのサイトのコードと構造を解析してコード補完や提案をします。 その際、サイトが適切な構造化データを持っているかどうかが、AIの提案精度に影響します。
- コンテキスト効率の向上： プロジェクトにJSON-LDが整備されている場合、Cursor/Claude Codeは「このページが何を意図しているか」を コードの意図から推測する必要が減り、より精度の高いSEO関連のコード提案ができます。
- 自動生成の精度向上： 「このページのJSON-LDを追加して」と指示する際、既存のスキーマパターンが一貫していると AIが正しいプロパティを推論しやすくなります。第4章ではCursorとClaude Codeに JSON-LDを自動生成させるプロンプトパターンを詳解します。
- あなたのサービスが「AI診断ツール」の対象になる： AIOGeoScanのような診断ツールを活用する開発者は、構造化データのエラー検出を 自動化したいニーズを持っています。JSON-LDが正しく実装されているサイトは 診断スコアが高くなり、結果として検索・AI検索への露出が改善されます。
7. JSON-LDを「実装しないリスク」：2026年時点での影響
JSON-LDの実装は任意ですが、実装しないことで以下のリスクが現実的に発生します。
リスク1：リッチリザルト枠の競合他社への占有
構造化データを適切に実装した競合サイトは、検索結果でより豊かな表示を獲得できる余地があります。 その結果として、非実装サイトよりクリックされやすくなるケースがあります。
リスク2：AI検索での「無名扱い」
著者・組織・更新日時が機械的に読み取りにくいサイトは、 AI検索や各種クローラーから見たときに情報の解像度が下がりやすくなります。 構造化データで自己紹介できていない状態は、AI時代の不利要因になり得ます。
リスク3：E-E-A-Tスコアの低迷
特に医療・法律・金融・SaaSといった専門性が問われる分野では、 OrganizationやPersonスキーマで専門性を機械的に証明できないサイトは Googleの品質評価で不利になります。対策を先延ばしにするほどライバルとの差が広がります。
概念を理解したら、すぐに実装に移りましょう。次の第2章では、 WebSite・Organization・Article・BreadcrumbList の4大スキーマを コピペで使えるテンプレートとして提供します。 また第4章では Next.js App Router・Cursor・Claude Code での 実装パターンを解説します。
全5章を通して、AI時代に構造化データを使いこなす技術を学びましょう。
あなたのサイトの構造化データ、
正しく実装されていますか？
AIOGeoScanの診断ツールなら、JSON-LDの存在チェック・スキーマエラーの検出・ E-E-A-T観点での評価まで、URLを入力するだけで一括診断できます。 まずは無料診断から始めましょう。
今すぐ自社サイトを無料診断する