JSON-LDの書き方7ステップ｜コピペ可能なサンプルコードと実装手順を解説

JSON-LDの書き方は、①scriptタグで囲む②@contextと@typeを必須項目として記述する③ページに合うスキーマタイプを選ぶ④サンプルコードを自分のページ用に書き換える⑤@graphで複数スキーマをまとめる⑥HTMLに設置する⑦検証ツールで確認するという7ステップで完成します。本記事ではコピペしてすぐ使えるサンプルコードとともに、文法ルールから設置場所、検証方法、よくあるNGパターンまでを一気通貫で解説します。Googleが推奨する構造化データの記述形式であるJSON-LDを正しく実装し、リッチリザルトやAI検索での引用を狙う際の実務的な手順を確認できます。

JSON-LDとは？構造化データの中でGoogleが推奨する記述形式

JSON-LDとは、schema.orgが定めるプロパティをJavaScriptオブジェクト記法で記述し、ページの内容を検索エンジンやAIに正確に伝えるための構造化データの記述形式です。構造化データにはJSON-LD・Microdata・RDFaの3種類がありますが、Googleが推奨しているのはJSON-LDであるため、基本的にはJSON-LDで記述するのが実務上の標準になっています（GIGブログ）。

TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データ・意味的文脈・エンティティ認識・想定質問の分解といった観点から技術的に捉え、LLMO・GEO・AEOの施策を一次情報設計まで踏み込んで支援しています。JSON-LDはその土台となる技術要素の一つであり、正しく実装できているかどうかがAI検索での引用可能性にも影響します。

構造化データ（JSON-LD・Microdata・RDFa）の違いとJSON-LDが推奨される理由

JSON-LD・Microdata・RDFaはいずれも構造化データを記述する方式ですが、記述場所や保守性が異なります。JSON-LD以外のシンタックスで記述してもGoogleが推奨していないため、検索結果に反映されない可能性が高いという点は実務上とても重要です（GIGブログ）。

形式	記述方法	特徴	Googleの推奨度
JSON-LD	scriptタグ内にJSON形式で記述	HTML本体と分離でき保守しやすい	推奨
Microdata	HTMLタグにitemprop等の属性を追加	HTMLと属性が混在し編集が煩雑	優先度は低い
RDFa	HTMLタグにvocab・property属性を追加	Microdataと同様にタグ内に属性を追加	優先度は低い

JSON-LDで得られる効果（リッチリザルト・Knowledge Graph・AI検索での引用）

JSON-LDを正しく実装すると、検索結果でのリッチリザルト表示やGoogleのKnowledge Graphへの情報反映、さらにAI検索での引用可能性が高まります。Google公式では30種類ほどのリッチリザルトが用意されており、代表例としてパンくずリスト（BreadcrumbList）や記事（Article/NewsArticle/BlogPosting）、求人情報（JobPosting）、レビュー（Review/AggregateRating）などが挙げられます（GIGブログ）。

こうしたリッチリザルトはクリック率の向上に寄与するだけでなく、ページの主題や情報同士の関係性を検索エンジンに明確に伝える手段としても機能します。タイトルや著者、公開日などの情報が構造化されていれば、検索エンジン側での誤認識も減らせます。

なぜ今JSON-LDが重要か：AI検索時代の意義

2026年時点でJSON-LDは、Google AI OverviewやChatGPT、Perplexityといったチャット型のAI検索が引用元を判断する際にも重要な役割を果たすと言われています。とくに著者情報・FAQ・HowToといった情報は重要なシグナルとして扱われ、FAQPageは特にAI Overviewで引用されやすい傾向があるとされています（SEGOブログ）。

AI検索での引用を狙う場合には、GEO（生成エンジン最適化）やAEOの考え方とあわせてJSON-LDの整備を進めると、記事単位の対策から検索導線全体の対策へと視野を広げやすくなります。

JSON-LDの書き方は7ステップで完成する

JSON-LDの書き方は、文法ルールの理解からスキーマ選定、サンプルコードの流用、書き換え、設置、検証までを含む7つのステップに沿って進めれば、初めてでも実装を完了できます。まずは全体像を把握し、その後に各ステップを1つずつ実行していく流れが効率的です。

TechSuite株式会社の「AI検索パートナーズ」は、技術的アプローチを担う人材とAIを活用したコンテンツ制作人材が一つのチームで連携し、戦略設計から技術実装・効果測定・改善までを一気通貫で伴走する体制を整えています。JSON-LDのような技術実装も、コンテンツ企画と分断せずに進められる点が特徴です。

7ステップの全体像（早見表）

まずは7ステップの全体像を早見表で確認し、自分がどの段階にいるかを把握しておくと迷わずに進められます。

ステップ	内容	このステップのゴール
ステップ1	基本文法ルールを理解する	波括弧・クォート・コロン・カンマ・配列の使い方を把握する
ステップ2	ページに合うスキーマタイプを選ぶ	Article/FAQPage等どのタイプを使うか決める
ステップ3	スキーマ別サンプルコードを用意する	コピペできるベースコードを手元に置く
ステップ4	サンプルを自分のページ用に書き換える	日付・URL・画像等の値を実データに置き換える
ステップ5	@graphと@idで複数スキーマをまとめる	必要に応じて中級テクニックを適用する
ステップ6	HTMLに設置する	head内またはbody内にscriptタグを配置する
ステップ7	検証ツールで確認する	Rich Results TestとSchema.org Validatorで確認する

最小コピペテンプレート（@context＋@type）

最小構成のJSON-LDは、scriptタグの中に@contextと@typeだけを含めた形から始められます。@contextは常にhttps://schema.orgを指定し、@typeにはページの主題に合うschema.orgのタイプ名を記述するのが基本ルールの中でも特に重要なポイントです（SEGOブログ）。

• <script type=”application/ld+json”>
• {
• “@context” “https://schema.org”,
• “@type” “Article”,
• “headline” “ページのタイトルを入れる”
• }
• </script>

このテンプレートに、後述するスキーマ別のプロパティを追加していけば、目的に合ったJSON-LDへと拡張できます。

コピペで使えるスキーマ別サンプルコード

結論として、JSON-LDはページの主題に合うスキーマタイプごとにひな形が決まっており、該当するコードをコピペして値を書き換えるだけで実装できます。ここではArticle・FAQPage・BreadcrumbList・Organization/Person・HowTo・Productという実務でよく使う6タイプのサンプルコードをまとめて紹介します。

TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みとノウハウを「バクヤスAI記事代行」事業で培っており、その制作エンジンとナレッジをLLMO対策にも転用しています。検索意図や想定質問の分解に沿ってコンテンツを設計する工程は、FAQPageやHowToといったスキーマ選定の考え方とも通じる部分があります。

Article（記事・ブログ）とFAQPage（よくある質問）のサンプル

ArticleやBlogPostingは記事ページ全般に使えるスキーマで、FAQPageはよくある質問形式のコンテンツに使うスキーマです。FAQPageは前述の通りAI Overviewで引用されやすいと言われているため、FAQコンテンツがあるページでは優先的に実装を検討したいスキーマです。

• { “@context” “https://schema.org”, “@type” “Article”,
• “headline” “記事タイトル”, “datePublished” “2026-01-10”,
• “dateModified” “2026-01-15”, “author” {“@type” “Person”, “name” “著者名”},
• “image” “https://example.com/image.jpg” }

• { “@context” “https://schema.org”, “@type” “FAQPage”,
• “mainEntity” [ { “@type” “Question”, “name” “質問文”,
• “acceptedAnswer” {“@type” “Answer”, “text” “回答文”} } ] }

BreadcrumbList（パンくず）とOrganization/Person（企業・著者）のサンプル

BreadcrumbListはサイト内の階層構造を伝えるスキーマで、Organization・Personは企業情報や著者情報を伝えるスキーマです。著者情報をPersonでマークアップしておくと、AI検索が発信者の専門性を判断する材料になり、E-E-A-Tの観点でも意味を持ちます。

• { “@context” “https://schema.org”, “@type” “BreadcrumbList”,
• “itemListElement” [ {“@type” “ListItem”, “position” 1,
• “name” “トップ”, “item” “https://example.com/”} ] }

• { “@context” “https://schema.org”, “@type” “Person”,
• “name” “著者名”, “url” “https://example.com/author/”,
• “sameAs” [“https://x.com/xxxx”,”https://facebook.com/xxxx”] }

HowTo（手順解説）とProduct（商品・価格・レビュー）のサンプル

HowToは手順解説コンテンツに、Productは商品ページの価格やレビューを伝える際に使うスキーマです。HowToも著者情報やFAQと並んでAI検索の重要シグナルとされているため、手順系のコンテンツを持つサイトでは実装の優先度が高いスキーマです（SEGOブログ）。

• { “@context” “https://schema.org”, “@type” “HowTo”,
• “name” “手順のタイトル”, “step” [ {“@type” “HowToStep”,
• “text” “手順1の説明”} ] }

• { “@context” “https://schema.org”, “@type” “Product”,
• “name” “商品名”, “offers” {“@type” “Offer”, “price” “1980”,
• “priceCurrency” “JPY”}, “aggregateRating” {“@type” “AggregateRating”,
• “ratingValue” “4.5”, “reviewCount” “12”} }

ページの種類	推奨スキーマ	主なプロパティ
記事・ブログ	Article/BlogPosting	headline/datePublished/author
よくある質問	FAQPage	mainEntity/acceptedAnswer
階層のあるページ	BreadcrumbList	itemListElement/position
手順解説	HowTo	step/HowToStep
商品ページ	Product	offers/aggregateRating

JSON-LDの設置場所と検証方法

結論として、JSON-LDは内に設置するのが一般的に推奨されていますが、内に記載しても問題なく認識されます。設置後はRich Results TestとSchema.org Validatorという目的の異なる2つのツールで検証するのが確実です。

TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・商材・課題に合わせてサイトごとに構造化データの実装方針を個別設計しており、CMSの制約や既存の実装状況を踏まえたうえでボトルネックを特定し、設置場所や検証手順まで含めて解決策の提示と実行支援を行っています。

head推奨・bodyでも可という結論（設置場所）

JSON-LDはheadもしくはbodyのどちらに記載しても問題なく、一般的にはhead内が推奨されています（GIGブログ、SEGOブログ）。WordPressであればテーマファイルの編集欄やプラグインの入力欄、Next.jsであればheadタグを扱うコンポーネント等を使って埋め込みます。

CMSやフレームワークによって設置方法は異なるため、まずは自社の環境でHTMLをどこまで直接編集できるかを確認しておくことが実装をスムーズに進めるポイントです。

Rich Results TestとSchema.org Validatorの使い分け

検証は目的の異なる2ツールを使い分けます。Rich Results TestはGoogleのリッチリザルト対象かどうかを判定するツールで、Person等のリッチリザルト非対応タイプは表示されません。一方でSchema.org Validatorはschema.org仕様への文法準拠を判定するツールで、全タイプを確認できるため最終チェックに向いています（SEGOブログ）。

ツール名	主な用途	確認できる範囲	向いている使い方
Rich Results Test	リッチリザルト対象か判定	Google検索でリッチリザルト表示されるタイプのみ	公開前の見え方確認
Schema.org Validator	schema.org仕様準拠の判定	Person等リッチリザルト非対応タイプも含む全タイプ	実装後の最終文法チェック

エラー・警告が出たときの読み方と修正手順

エラーが表示された場合は、まずどの行・どのプロパティで発生しているかをツールの表示から特定し、ダブルクォートの不足やカンマの位置といった文法上の問題を優先的に確認します。修正後は再度同じツールで検証し、エラーが消えたことを確認してから公開するという流れが安全です。

JSON-LD実装でやりがちなNG・注意点

結論として、JSON-LD実装で最も注意すべきなのはページに存在しない情報をマークアップしてしまうことで、構文の些細なミスはペナルティにはならずリッチリザルトが表示されないだけです。ただしJSON-LD自体は直接の順位要因ではない点も理解しておく必要があります。

TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおいてAI Share of Voiceが高水準で推移しており、支援先でAI Overviewの引用率を改善した実績もあります。こうしたNGパターンを避けて正確な構造化データを積み重ねることが、引用率向上の土台になっています。

ページに存在しない情報はマークアップしない

構造化データはあくまでページ内に書かれている内容が前提で、監修者欄がないのに監修者情報を記載したり、FAQがないのにFAQPageでマークアップしたりするのはガイドライン上のNGです（GIGブログ）。追加したい情報がある場合は、まずページ本文にその情報を明記することが先決です。

構文エラーはペナルティではないが不正な記述は要注意

ダブルクォートの不足やカンマの付け忘れといった構文エラーは、多くの場合ペナルティにはつながらずリッチリザルトが表示されないだけで済むと考えられています。一方でページに存在しない情報を意図的に記載するといった不正な記述は、ガイドライン違反として手動対策の対象になる可能性があるとも言われています※（この点については各サービスの一次情報での確認をおすすめします）。

状況	NG例	OK例
監修者情報	ページ本文に監修者欄がないのにPersonで記載する	本文に監修者欄を追加した上でPersonを記載する
FAQ情報	本文にFAQが無いのにFAQPageを実装する	本文にQ&Aを掲載した上でFAQPageを実装する
評価情報	実際には収集していないレビュー数を記載する	実際に収集した件数のみを記載する

JSON-LDは直接の順位要因ではないという前提

JSON-LDは直接的な検索順位の上昇要因ではなく、Googleに情報を正確に伝えるための仕組みです。順位向上にはコンテンツの質や被リンクなど他の要素も欠かせないとされています（SEGOブログ）。JSON-LDの整備と並行して、LLMO対策のようなコンテンツ面の取り組みや、ChatGPTのSEO対策の考え方も合わせて進めると効果的です。

よくある質問

ここでは、JSON-LDの書き方や運用に関してよく聞かれる質問をまとめました。TechSuite株式会社の「AI検索パートナーズ」の支援実績では、AI検索経由での受注率が従来のSEO経由の約3倍になったケースもあり、構造化データの整備は露出だけでなく受注という成果にもつながる施策として位置づけられます。

JSON-LDを実装したのに順位が上がらないのはなぜですか？

JSON-LDは検索順位の直接的な上昇要因ではなく、ページ内容を正確に伝えるための仕組みだからです。順位向上にはコンテンツの質や被リンクなど他の要素も必要とされています。

@graphは必ず使う必要がありますか？

必須ではありません。単一のスキーマだけで済むページでは1つのオブジェクトで十分ですが、複数のエンティティを関連付けたい場合には@graphと@idを使うと参照構造を作れます。

headとbodyのどちらに入れるべきですか？

どちらに記載しても問題なく認識されますが、一般的にはhead内への記載が推奨されています。CMSの仕様に応じて設置しやすい場所を選んで問題ありません。

テスト環境にJSON-LDを入れても大丈夫ですか？

問題ありません。テスト環境で検証ツールを使って文法や表示を確認してから、本番環境に反映する進め方が安全です。

まとめ

JSON-LDの書き方は、文法ルールの理解からスキーマ選定、サンプルコードの流用と書き換え、@graphでのまとめ、設置、検証までの7ステップで完成します。まずはArticleやFAQPageなど自分のページに合うスキーマを選び、コピペしたコードを実データに書き換えることから始められます。

設置後はRich Results TestとSchema.org Validatorで確認し、ページに存在しない情報を記載しないよう注意すれば、リッチリザルトやAI検索での引用につながる構造化データを整備できます。JSON-LD単体で順位が決まるわけではないため、コンテンツの質や検索導線全体の設計と合わせて取り組むことが大切です。

参考にした情報源

• JSON-LDによる構造化データの書き方（Web担当者Forum）
• 構造化データ（JSON-LD）の書き方と注意点（GIGブログ）
• JSON-LDの書き方ガイド（SEGOブログ）