PR-068 構造化データという言葉は知っているが、何から手をつければいいか分からない——JSON-LDをゼロから生成する方法
Claudeこんな悩みはありませんか？
「構造化データ」「JSON-LD」という言葉はセミナーや記事で何度も見たけれど、コードを書いた経験がなく、何から手をつけていいか分からない——エンジニアがいない会社・個人事業では特によくある悩みです。「専門知識がなくても、まずは1ページ分だけ試してみたい」というときに、ゼロからschema.org準拠のコードを組み立てるのは、非エンジニアにはハードルが高い作業です。
この記事でできるようになること
自社ページの情報（会社名・URL・所在地など、わかる範囲の事実）をAIに渡すだけで、schema.org準拠のJSON-LDコードの下書きを生成し、そのままサイトに設置できる形に近づけられるようになります。
使うプロンプト
入力に必要な素材
- 対象ページの種別（Organization / Article / FAQPage など）
- 会社名・サイト名、対象URL
- 掲載してよい事実情報（所在地・設立年・著者名・公開日など、わかる範囲）
【Claude推奨・ChatGPTでも実行可】
# 役割
あなたはWeb実装の担当者です。非エンジニアでも1ページ分の構造化データを試せるよう、schema.org準拠のJSON-LDをゼロから組み立てる作業を専門にしており、読み手はコードを書いた経験がないコンテンツ担当者です。専門用語は初出時に一言で補足してください。
# 入力素材の確認
以下の情報が貼り付けられている前提で作業してください。
- 対象ページの種別（Organization / Article / FAQPage など）
- 会社名・サイト名、対象URL
- 掲載してよい事実情報（わかる範囲）
ページ種別または会社名・サイト名が貼り付けられていない場合は、コード生成に進まず「ページ種別・会社名・サイト名が確認できません。3項目を埋めて貼り付け直してください」とだけ回答し、そこで処理を止めてください。
# 対象ページの情報
- ページ種別: 【Organization / Article / FAQPage などいずれか】
- 会社名・サイト名: 【自社名】
- 対象URL: 【対象URL】
- 掲載してよい事実情報: 【会社所在地・設立年・著者名・公開日など、わかる範囲で箇条書き】
# 分析・作業手順
1. 指定されたページ種別に対応するschema.orgのタイプ（Organization/Article/FAQPage等）を確認する
2. 貼り付けられた事実情報を、対応するプロパティ（name・url・datePublished等）に1つずつ割り当てる
3. 貼り付けられていない項目（電話番号が不明など）を洗い出し、空欄にせずコメントで「要確認」と記載する
4. 生成したコードの構文（括弧・カンマの対応、必須プロパティの有無）を自己点検する
5. 自己点検の結果（構文上問題がないか）を出力の最後に一言で示す
# 出力してほしいこと
1. 該当するschema.orgのタイプ（Organization/Article/FAQPage等）を使ったJSON-LDコードを生成する
2. 貼り付けた情報にない項目（例: 電話番号が不明など）は空欄にせず、コード内にコメントで「要確認」と記載する
3. 生成したコードの構文が正しいか、閉じ忘れ等がないかを自己点検した結果も一言添える
# 出力形式
1. 完成したJSON-LDコード（`<script type="application/ld+json">`込み）
2. 使用したプロパティの一覧（プロパティ名｜値の出典｜要確認の有無）
3. 3行以内の要約（使用したschema.orgタイプ／要確認の項目数／次にすべき検証ツールでの確認）
貼り付けていない事実（未確認の数値・肩書等）を新たに作成しないでください。
# 品質ガード
- 貼り付けられていない項目を、それらしい一般値で埋めない（必ず「要確認」コメントにする）
- 生成後は必ずGoogleのリッチリザルトテスト等の検証ツールで再確認する前提であることを明記する
- 自己点検はあくまでAIによる目視相当のチェックであり、検証ツールでの確認を省略してはいけない旨を添える実行手順
- 実装したいページの種別（会社概要ならOrganization、記事ならArticleなど）を決める
- Claudeで新規チャットを開き、プレースホルダを実際の情報に置き換えてプロンプトを実行する
- 生成されたコードを丸ごと
<head>または<body>内に<script type="application/ld+json">...</script>で囲んで設置する（設置方法はCMSにより異なるため、必要ならエンジニアに確認する） - Google公式のリッチリザルトテスト（search.google.com/test/rich-results）にページURLまたはコードそのものを貼り付け、エラー・警告が出ていないかを確認する
- あわせてSchema Markup Validator（validator.schema.org）でも構文チェックを行い、2つのツールの結果が一致しているかを確認する
結果の読み解き方
- リッチリザルトテストの「有効」「警告」「エラー」の違いを理解してください。「警告」は必須ではない項目の不足で致命的ではありませんが、「エラー」は構文または必須プロパティの欠落で、修正が必要です。
- AIが「要確認」とコメントを残した箇所は、そのまま本番環境に設置してはいけません。事実確認が済むまで空欄運用にするか、実装を保留してください。
- コードが「検証ツールでエラーなし」でも、記載内容が事実と異なっていれば意味がありません。検証ツールは構文の正しさを見るものであり、内容の正しさは人間が確認する必要があります。
注意点
- AIが生成するコードは実行のたびに微妙に異なる書き方になることがあります。毎回、検証ツールでの再確認を省略しないでください。
- 危険な間違い例: JSON-LDはカンマ1つ・括弧1つのミスでコード全体が無効になります。特に配列の最後の要素にカンマを残してしまう（trailing comma）ミスは見た目では気づきにくく、検証ツールに通して初めて発覚することが多いです。目視だけで「大丈夫そう」と判断せず、必ずツールでチェックしてください。
- 貼り付けていない実績・肩書・数値をAIが「それらしく」補完してしまうことがあります。生成されたコードの中に、自分が渡していない情報が紛れ込んでいないか必ず見比べてください。
関連レッスン・関連パターン
- レッスン III-B2 JSON-LD基礎を理解する・III-B3 Organization・Personを実装する（構文の基本を理解してからコードを読むと、AIの出力の妥当性を自分でも判断できます）
- 関連パターン: PR-074 Organization/Person schemaで会社を正しく認識させる方法（会社情報に絞った発展版）・PR-081 構造化データのエラーを診断し修正する方法（設置後にエラーが出た場合の対処）
確認テスト
選択肢をクリックすると、その場で正誤と解説が表示されます。
Q1. JSON-LDはカンマ1つ・括弧1つのミスでコード全体が無効になることがあり、特に配列末尾のtrailing commaは目視では気づきにくい。
記事は「危険な間違い例」として、trailing commaのミスは見た目では気づきにくく、検証ツールに通して初めて発覚することが多いと述べている。
Q2. JSON-LDを設置した後、必ず行うべき検証はどれか。
実行手順で、2つの検証ツールの結果が一致しているか確認するとされている。
Q3. コード内に「要確認」とコメントが残った項目の扱いとして正しいのはどれか。
「要確認」コメントが残った箇所は事実確認が済むまで空欄運用にするか実装を保留するべきとされている。
よくある質問
Q. 生成AIの出力は毎回同じコードになりますか？
なりません。記事は「AIが生成するコードは実行のたびに微妙に異なる書き方になることがある」と述べており、毎回の検証を省略しないよう注意しています。
Q. JSON-LDのページ種別はOrganization以外にも選べますか？
はい。記事ではArticleやFAQPageなど、ページ種別に応じてschema.orgのタイプを選ぶ想定になっています。
Q. 貼り付けていない実績や肩書をAIが補ってしまうことはありますか？
あります。記事は「貼り付けていない情報が紛れ込んでいないか必ず見比べる」よう注意喚起しています。