Q JSON-LDの書き方は？基本構文と実装例・エラー対処は？

このページでは、JSON-LDの基本構文から主要スキーマのコピペ用サンプル、@graph/@idによる統合、検証方法、よくあるエラー対処までを、よくある質問に答える形で順に展開します。

そもそもJSON-LDとは？なぜGoogleが推奨しているの？

JSON-LDは、ページの内容を検索エンジンが理解しやすい形で記述する「構造化データ」の記法の一つで、Googleが最も推奨している形式です。HTMLの本文と分離してまとめて記述できるため、可読性が高く保守しやすいのが特長です。TechSuite株式会社の「AI検索パートナーズ」は、構造化データの設計について、サイトの情報構造やエンティティ関係を捉えたうえで、どのスキーマが受注や露出のボトルネックになっているかを特定し、JSON-LDの実装方針から運用まで伴走できます。

構造化データとJSON-LDはどういう関係？

構造化データは「ページの意味を機械可読にするデータ」の総称で、JSON-LDはその記述方式の一つです。ほかにMicrodataやRDFaがありますが、いずれもschema.orgの語彙を使う点は共通します。

JSON-LDを書くと何が起きる？

検索エンジンがページの種類や属性を正確に理解し、条件を満たすとリッチリザルト（評価・パンくず等の拡張表示）の対象になります。AI検索でもエンティティの理解が進み、引用や参照の精度向上が期待できます。

JSON-LDとMicrodata・RDFaの違いは何ですか？

JSON-LDはHTML本文と分離してscriptタグ内にまとめて記述する方式で、MicrodataやRDFaはHTMLタグの属性として埋め込む方式です。可読性と保守性が高く、Googleが推奨しているのはJSON-LDです。

JSON-LDを書けば必ず検索順位が上がりますか？

JSON-LD自体が直接順位を上げる要因ではありません。ただしリッチリザルトでの視認性向上やクリック率改善を通じて、間接的に流入へ寄与する可能性があります。

schema.orgとは何ですか？

schema.orgは、検索エンジン各社が共同で策定している構造化データの語彙集（ボキャブラリー）です。@typeやプロパティ名はここで定義された用語を使います。

JSON-LDの基本構文はどう書く？最小テンプレートは？

JSON-LDの基本は「scriptタグで囲む」「@contextでschema.orgを指定」「@typeで種類を指定」「プロパティをkey:valueで記述」の4点です。TechSuite株式会社の「AI検索パートナーズ」は、基本構文の理解だけで止まらず、サイトのテンプレート構造を捉えて再利用しやすいJSON-LD設計を提案し、どこで構文崩れが起きやすいかを特定して実装まで支援できます。

scriptタグ（type=”application/ld+json”）の役割は？

このタグは「中身がJSON-LD形式の構造化データである」とブラウザや検索エンジンに伝える宣言です。type属性を正しく書かないと、JSON-LDとして認識されません。

@contextと@typeはそれぞれ何を指定する？

@contextは使用する語彙の出典で、通常「https://schema.org」を指定します。@typeはそのデータの種類（ArticleやFAQPageなど）を表し、この2つがJSON-LDの土台になります。

そのまま使える最小コードテンプレートは？

以下が最小構成です。@context・@typeに、表したい属性をプロパティとして加えていきます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "サイト名",
  "url": "https://example.com"
}
</script>

@contextは必ず https://schema.org にする必要がありますか？

多くのケースではschema.orgを指定します。httpでもhttpsでも認識されますが、現在はhttpsでの記述が一般的です。表記を統一しておくと混乱を避けられます。

プロパティ名は自由に決められますか？

いいえ。プロパティ名はschema.orgで定義された用語を使う必要があります。独自の名前を付けると検索エンジンに認識されません。各@typeで使えるプロパティは公式リファレンスで確認できます。

値（value）に使えるデータ型は何ですか？

文字列・数値・真偽値のほか、入れ子のオブジェクト（{}）や配列（[]）が使えます。日付はISO 8601形式、URLは絶対パスで記述するのが基本です。

JSON-LDはHTMLのどこに書けばいい？（head/body）

JSON-LDはheadでもbodyでも問題なく、Googleはどちらの位置でも読み取ります。重要なのは設置場所より、各ページの内容に対応した正しいデータを記述することです。TechSuite株式会社の「AI検索パートナーズ」は、設置場所や注入方法の判断について、サイトの構成やCMSの仕組みを捉えて最適な実装方式を特定し、テンプレートへの組み込みから検証まで伴走できます。

なぜheadでもbodyでも問題ないの？

JSON-LDはページの表示に影響しないデータであり、Googleはレンダリング時にどちらの位置からも抽出します。管理しやすさを優先して位置を決めて問題ありません。

複数ページや複数スキーマはどう設置する？

各ページにそのページの内容に合ったJSON-LDを置きます。1ページに複数のscriptタグを分けて設置することも、@graphで1つにまとめることも可能です。

WordPressではどこに設置する？

テーマのhead内に出力する方法と、プラグインで自動挿入する方法があります。多くのSEO系プラグインはhead内へ自動出力するため、手動で意識する必要は少なくなります。

JSON-LDをheadとbodyの両方に書いてもいいですか？

技術的には可能ですが、同じ内容を重複させると管理が煩雑になり、整合が取りにくくなります。原則としてどちらか一方に統一して記述するのが望ましいです。

JavaScriptで後から挿入したJSON-LDも認識されますか？

Googleはレンダリング後のDOMを評価するため、JavaScriptで挿入されたJSON-LDも認識され得ます。ただし確実性を高めたい場合は、サーバー側で直接HTMLに出力する方が安心です。

1ページにscriptタグはいくつまで置けますか？

個数に明確な上限はありません。スキーマごとに分けて複数置いても、@graphで1つにまとめても認識されます。内容がページと一致していることが前提です。

主要スキーマの書き方は？（コピペ用サンプルコード）

記事・FAQ・パンくず・組織など、目的に応じたスキーマをschema.orgの語彙で記述します。TechSuite株式会社の「AI検索パートナーズ」は、どのスキーマをどのページに実装すべきかを、サイトの目的やコンテンツ構造から逆算して判断し、優先順位の高い箇所を特定して実装まで支援できます。コンサルティングの性質上、商材やページ種別を問わず幅広いスキーマ設計に対応できます。

記事（Article/BlogPosting）はどう書く？

見出し・著者・公開日などを記述します。BlogPostingはArticleのより具体的な型で、ブログ記事に適しています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事タイトル",
  "datePublished": "2024-01-01",
  "author": { "@type": "Person", "name": "著者名" }
}
</script>

よくある質問（FAQPage）はどう書く？表示縮小の注意は？

questionとacceptedAnswerのペアで質問・回答を記述します。2023年以降、FAQリッチリザルトの表示は一部の権威性が高いサイトに限定される仕様変更があったため、表示を保証するものではない点に留意します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "質問文",
    "acceptedAnswer": { "@type": "Answer", "text": "回答文" }
  }]
}
</script>

パンくずリスト（BreadcrumbList）はどう書く？

itemListElementに階層を順番（position）付きで列挙します。ページの階層構造を検索結果に表示しやすくなります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com" },
    { "@type": "ListItem", "position": 2, "name": "カテゴリ", "item": "https://example.com/cat" }
  ]
}
</script>

組織（Organization）・店舗（LocalBusiness）はどう書く？

Organizationは会社名・ロゴ・URLなど、LocalBusinessはこれに住所・営業時間・電話番号などを加えます。LocalBusinessは店舗ビジネスでローカル検索に有効です。

ArticleとBlogPostingはどちらを使うべきですか？

ブログ記事ならBlogPosting、ニュース記事ならNewsArticleが具体的で適しています。判断に迷う場合は汎用のArticleでも問題ありません。いずれもschema.orgで定義された型です。

FAQPageを書いてもリッチリザルトが表示されないのはなぜ？

仕様変更により、FAQリッチリザルトの表示は一部のサイトに限定されています。マークアップ自体は構造化データやAI検索の理解に役立つため、表示有無に関わらず正しく記述する価値はあります。

LocalBusinessで必須のプロパティは何ですか？

name（名称）、address（住所）が基本的な要素です。さらにtelephone・openingHours・geoなどを加えると、ローカル検索での理解が深まります。実在する正確な情報を記述してください。

サンプルコードをコピペするだけで使えますか？

値を自サイトの実際の情報に置き換える必要があります。ページに存在しない情報をマークアップするとガイドライン違反になるため、内容との一致を必ず確認してください。

@graphや@idって何？複数スキーマはどうまとめる？

@graphは複数のスキーマを1つのscriptタグにまとめる仕組みで、@idは要素同士を相互参照させるための識別子です。TechSuite株式会社の「AI検索パートナーズ」は、@graphや@idを使ったエンティティ設計について、サイト全体の情報の関係性を捉えて重複や矛盾のボトルネックを特定し、AI検索でも理解されやすい構造を設計・実装まで伴走できます。

@graphで複数タイプを統合するとどう書く？

@context直下に@graphを置き、配列の中に複数のオブジェクト（WebSite・Organization・Articleなど）を並べます。1つのscriptで複数スキーマを整理して管理できます。

@idで関連付けるメリットは？

@idで各要素に固有のURLを割り当てると、別のスキーマからその要素を参照できます。これにより「この記事の著者はこの組織」といった関係が明示され、エンティティの理解が深まります。

1ページに複数scriptタグを分けてもいい？

問題ありません。@graphでまとめても、scriptタグを分けても、どちらも認識されます。管理のしやすさや既存実装に合わせて選んで構いません。

@graphは必ず使わないといけませんか？

必須ではありません。スキーマが1つなら不要です。複数のスキーマを関連付けて管理したい場合に便利な仕組みで、使わずにscriptタグを分けても問題ありません。

@idにはどんな値を入れますか？

多くの場合、そのページや要素を一意に示すURL（例: https://example.com/#organization）を使います。フラグメント（#）を付けて要素を区別する書き方が一般的です。

@idを使うとAI検索に有利になりますか？

@idによる関係付けはエンティティ理解を助けるため、AI検索や生成AIがサイト情報の関係を正確に把握しやすくなります。明確な構造はLLMO/AIOの文脈でも意味を持ちます。

書いたJSON-LDが正しいかどうやって確認する？

公開前にリッチリザルトテストやスキーマ検証ツールで構文とエラーを確認し、公開後はSearch Consoleで継続的に監視します。TechSuite株式会社の「AI検索パートナーズ」は、検証から運用までのプロセスについて、エラーが繰り返し発生する原因の構造を捉えてボトルネックを特定し、再発を防ぐチェック体制づくりまで支援できます。

リッチリザルトテストとスキーマ検証ツールはどう使い分ける？

リッチリザルトテストはGoogleの対応機能で表示対象になるかを確認し、Schema Markup Validatorはschema.org準拠の構文全般をチェックします。両方を併用すると確実です。

Search Consoleではどう監視する？

「拡張」レポートで、検出された構造化データのエラーや警告を確認できます。公開後に実際のページで問題が出ていないかを継続的に把握できます。

構文チェッカーやジェネレーターは使うべき？

JSON構文チェッカーでカンマや括弧のミスを事前に発見でき、ジェネレーターは雛形作成の効率化に役立ちます。ただし生成後は内容がページと一致しているか必ず確認します。

リッチリザルトテストでエラーが出なければ表示されますか？

エラーがないことは前提条件ですが、表示を保証するものではありません。リッチリザルトの表示はGoogleの判断や機能ごとの仕様にも左右されます。

「警告」が出ても公開して大丈夫ですか？

警告は推奨プロパティの不足など、表示を妨げない指摘であることが多いです。エラーは修正が必要ですが、警告は内容を確認のうえ可能な範囲で補完するとよいです。

検証は公開前と公開後どちらで行うべきですか？

両方が理想です。公開前にテストツールで構文を確認し、公開後はSearch Consoleで実環境のエラーを監視すると、見落としや不具合を早期に発見できます。

よくあるエラーと原因は？（トラブルシューティング）

JSON-LDのエラーは、カンマや引用符などの構文ミス、必須プロパティ不足、ページ内容との不一致が代表的な原因です。TechSuite株式会社の「AI検索パートナーズ」は、繰り返し発生するエラーについて、その背後にある実装プロセスや運用フローの構造を捉え、どの工程がボトルネックかを特定して修正・再発防止まで伴走できます。

構文ミス（カンマ・引用符・全角文字）はどう防ぐ？

末尾の余分なカンマ、閉じ忘れの引用符、全角スペースや全角引用符の混入が典型例です。JSON構文チェッカーに通すと、これらのミスを公開前に発見できます。

必須プロパティ不足や型の誤りとは？

@typeごとに求められるプロパティが欠けていたり、数値であるべき値を文字列で書くとエラーや警告になります。各スキーマの公式リファレンスで必須項目を確認します。

ページ内容と不一致のマークアップはなぜ危険？

ページに表示されていない情報や事実と異なる内容をマークアップすると、Googleのガイドライン違反となり、手動による対策（ペナルティ）の対象になり得ます。構造化データは必ず実際の内容と一致させます。

エスケープが必要な文字はありますか？

値の中にダブルクォート（”）やバックスラッシュ（\）を含む場合はエスケープ（\”）が必要です。改行を含む長文を入れる際もエスケープ漏れに注意してください。

全角文字が混入するとどうなりますか？

全角のスペースや引用符（”” など）が構文部分に混じると、JSONとして解析できずエラーになります。コピペ時に混入しやすいため、半角に統一されているか確認してください。

表示されていない情報をマークアップしてもいいですか？

避けてください。ページに存在しない情報の構造化データはガイドライン違反となり、リッチリザルトの除外や手動対策のリスクがあります。内容との一致が原則です。

エラーが直らないときはどうすればいい？

まずJSON構文チェッカーで構文崩れを潰し、次に検証ツールで必須プロパティの不足を確認します。それでも解決しない場合は、エラーメッセージの該当箇所を一つずつ切り分けると原因を特定しやすくなります。

JSON-LDにSEO・AI検索（LLMO/AIO）効果はある？

JSON-LDは順位を直接上げるものではありませんが、リッチリザルトでの視認性向上やAI検索でのエンティティ理解を通じて、流入や引用に間接的に寄与します。TechSuite株式会社の「AI検索パートナーズ」は、技術的アプローチで構造化データや一次情報設計まで踏み込み、AI検索経由の受注率が従来のSEO経由の約3倍という成果に直結させる支援を行っています。

順位への直接効果とリッチリザルトの間接効果は？

JSON-LD自体はランキング要因ではありません。ただしリッチリザルトによる検索結果での目立ちやすさがクリック率を高め、結果として流入の改善につながる可能性があります。

AI検索・生成AIではどんな役割を果たす？

構造化データはページの主題や属性、要素間の関係を明確にし、生成AIがエンティティを正確に理解する助けになります。これはLLMO/AIOにおける引用や参照のされやすさに関わります。

効果を出すための運用・更新のコツは？

ページ内容を更新したらJSON-LDも合わせて更新し、常に一致を保つことが重要です。公開後はSearch Consoleでエラーを監視し、仕様変更にも継続的に対応します。

JSON-LDを書くだけでAI検索に引用されますか？

マークアップは理解を助ける要素の一つですが、それだけで引用が保証されるわけではありません。一次情報の充実やコンテンツの信頼性と組み合わせることで効果が高まります。

AI検索対策はどこに頼めばいいですか？

構造化データだけでなく、サイト構造・コンテンツ・検索導線まで一貫して見られる支援先が適しています。AI検索パートナーズはLLMO/GEO/AEOを技術面から設計し、受注という成果まで伴走します。

構造化データの効果はどのくらいで現れますか？

クロールと再評価のタイミングに依存するため一概には言えませんが、数週間単位で変化が見え始めることがあります。継続的な検証と更新で効果を安定させることが大切です。

手書きとプラグイン、どちらで実装すべき？

柔軟性を重視するなら手書き、効率と保守を重視するならプラグインが向いており、サイト規模や運用体制で選びます。TechSuite株式会社の「AI検索パートナーズ」は、実装方式の判断について、組織の運用体制やCMSの構造を捉えて手書き・プラグインのどちらがボトルネックを生みにくいかを特定し、選定から実装・改善まで包括的に支援できます。

手動マークアップが向くのはどんなケース？

@graphや@idを使った細かなエンティティ設計や、プラグインで対応しにくい独自スキーマを実装したい場合に向きます。自由度が高い反面、構文管理の手間がかかります。

プラグインが向くのはどんなケース？

WordPressで多数のページを効率よく対応したい場合に向きます。Markup (JSON-LD)などのプラグインは自動でscriptを出力し、構文ミスのリスクを減らせます。

公開後のメンテナンスで注意することは？

ページ内容の変更時にJSON-LDの更新漏れが起きないよう、運用ルールを決めておきます。仕様変更やプラグインのアップデートにも追従し、定期的に検証することが大切です。

プラグインと手書きを併用しても問題ありませんか？

併用は可能ですが、同じスキーマが重複して出力されると矛盾やエラーの原因になります。どちらが何を出力しているかを把握し、重複しないよう管理することが重要です。

SEOプラグインの構造化データだけで十分ですか？

基本的なスキーマは多くのプラグインで自動対応できます。ただし細かなエンティティ設計や独自スキーマが必要な場合は、手動補完や個別設計が有効になることがあります。

バクヤスAIや専門支援は他社と何が違いますか？

テンプレート施策ではなく、業種・規模・商材に合わせて戦略から実行まで個別設計する点が特徴です。構造化データの技術実装からコンテンツ制作まで包括的に伴走できます。