構造化データを入れようとして、まず @context の綴りを確かめに行く。次に、その型では何を書かなければいけないのかを調べる。author はそのまま書けるのか、それとも入れ子にするのか。ここでまた調べ直す。
書けないわけではありません。ただ、ページを出すたびに同じ道を通り直している。JSON-LDのつらさは、たぶんそこにあります。
この記事は、ページ種別と掲載情報の2つを渡すだけで、AIにJSON-LDのコードを組み立てさせるプロンプトを、そのままコピーして使える形でまとめました。調べ直す工程はまとめて預けて、人の側は「このコードを設置してよいかどうか」を決める仕事だけを引き受ける。そういう分け方をした記事です。
こんなふうに調べていませんか
- 構造化データを入れたいが、JSON-LDの書き方を毎回ゼロから調べ直している
- AIに書かせたコードを、そのままページに貼っていいのか判断がつかない
- これから公開するページのぶんを、手早く用意したい
この記事を読み終えたときに手に入るもの
- ページ種別と掲載情報を渡すだけで、貼り付けられるJSON-LDを手に入れられます
- 返ってきたコードの、どこを疑えばいいかが分かります
- 設置してよいかどうかを、自分で判断できるようになります
結論30秒でわかる、この記事の結論
- ページ種別と掲載情報を渡すと、schema.org準拠のJSON-LDコードが、そのまま貼り付けられる形で返ってきます。
- JSON-LDは型によって必須プロパティの有無が異なります。Article型のように必須項目のない型もあれば、リッチリザルト系のように必須が1つ欠けただけで対象から外れる型もあります。
- 返ってきたコードは、そのまま公開しません。リッチリザルトテストを通してから設置します。
この記事は、あるマーケティング部の2人と、専門家のやり取りをはさみながら進みます。若葉さん（Web担当2年目）が「そもそもそれは何ですか」を、高梨課長（マーケ課長）が「誰が、どれくらいの手間でやるんですか」を聞きます。答えるのは鈴木さん（AIO/SEOの専門家・本誌監修）です。
01そもそもJSON-LDの構造化データって何ですか？AIOでなぜ必要なんですか？
若葉さん構造化データを入れておいてください、と言われたんですが…そもそも何を入れる作業なんでしょうか。
鈴木さんページに書いてあることを、機械にも分かる形でもう一度書き添えておく作業です。読み手が見る本文はそのままにして、別のところに「この記事の題はこれ」「書いたのはこの人」と並べておく、というイメージですね。
構造化データとは、ページの内容を決まった語彙で書き直したものです。その書き方のひとつがJSON-LDで、ページのHTMLに <script type="application/ld+json"> というタグで書き添えます。
語彙の取り決めがschema.orgです。「どの型に、どのプロパティを持たせるか」があらかじめ決まっていて、@context でその語彙を使うことを示し、@type でこのページがどの型なのかを指定します。本記事のプロンプトは、この一式をAIに組み立ててもらうための、AI検索最適化（AIO）向けの実践プロンプトです。
ここで最初の分かれ道になるのが、型によって必須プロパティの有無が違うという点です。Article型のように、必須項目が定められていない型があります（出典: Google公式構造化データポリシーページ）。一方でリッチリザルト系の型は、必須プロパティが1つでも欠けると、その対象から外れてしまいます。
この章のまとめ
JSON-LDは、ページの内容をschema.orgの語彙で書き直したものです。型ごとに必須の決まりが違うので、「どの型で書くか」が最初の分かれ道になります。
02JSON-LD構造化データを手で書くと、AI検索最適化の実務ではどこでつまずくんですか？
高梨課長書ける人に任せれば済む話ではないんですか。うちにも触れる人間はいます。
鈴木さん書けるかどうかより、確かめる回数のほうが効いてきます。ページを1つ出すたびに、型の綴り、入れ子の形、必須と推奨の区別。同じところを何度も調べ直すことになるんです。
手で書くときにつまずくところは、慣れないうちは主に4つに絞られます。
@context・@type・プロパティの正しい組み合わせを、型ごとに覚えるのが大変author・publisherのように、入れ子にすべき情報とそうでない情報の区別がつきにくい- 必須プロパティと推奨プロパティの違いを、都度確認するのが手間
- カンマや括弧の対応崩れなど、構文エラーに手作業では気づきにくい
並べて眺めると、性質が2つに分かれます。前の3つは調べれば分かることです。分かるけれど、ページを出すたびに調べ直しになります。最後の1つだけが性質が違い、読んでも気づけないことです。カンマの過不足や括弧の対応は、目で追っても正しく見えてしまいます。
この章のまとめ
つまずくのは書けないことではなく、ページを出すたびに同じ確認を繰り返すことです。手作業でいちばん気づきにくいのは、最後の構文の崩れです。
03JSON-LD構造化データをAIに生成させると、AI検索対策では何が変わるんですか？
渡すのは、ページ種別と掲載情報の2つだけです。返ってくるのは、<script type="application/ld+json"> タグで囲まれた、そのままHTMLに貼り付けられるコードと、選ばれた @type とその理由を書いた1行です。
変わるのは調べる順番ではありません。調べる担当が入れ替わる、という言い方のほうが近いはずです。型の綴りを探しに行く工程、必須と推奨を照合する工程、入れ子の形を確かめる工程。この3つがまとめて向こう側へ移ります。
使うAIツールはChatGPT等を想定しています。コード生成もチャットのやり取りだけで完結し、無料プランでも実行できます（2026年7月時点）。ファイルのアップロードやWeb検索は使いません。
そのかわり、人の側には別の仕事が残ります。返ってきたコードを設置してよいかどうかを決める仕事です。
この章のまとめ
変わるのは調べる担当です。人の側に残るのは、返ってきたコードを設置してよいかどうかを決める仕事になります。
04AIにJSON-LDを生成させるプロンプトは、AI対策としてどこをコピーすればいいんですか？
新しく記事や会社概要ページを公開する際、構造化データを一から書く場面で使います。次のコードブロックの中身を、そのままコピーしてください。
あなたはテクニカルSEO/AIO実装のアシスタントです。
以下の入力データをもとに、schema.org準拠のJSON-LDコードを生成してください。
■対応するページ種別
【ページ種別】
■掲載情報(項目ごとに1行で入力)
【掲載情報】
■生成ルール(必ず守ること)
1. @contextは"https://schema.org"を使用すること。
2. @typeは【ページ種別】に対応するschema.org語彙を選択すること。判断に
迷う場合は最も一般的な型を選び、選定理由を出力の最後に1行で添える
こと。
3. Googleが定める必須・推奨プロパティのうち、【掲載情報】に対応する値
がある項目は漏れなく記述すること。
4. 【掲載情報】にない値を、AIが推測して作り出さないこと。値が不明な
項目はプロパティごと省略すること。
5. author・publisher等、入れ子にすべき情報はPerson型・Organization型
等で正しく入れ子にすること。
■出力形式
<script type="application/ld+json">タグで囲んだ、そのままHTMLに貼り付け
られるコードのみを出力してください。前置き・後書きの説明文は不要です。
コードの直後に、選択した@typeとその理由を1行で添えてください。いちばん下の「あなたはテクニカルSEO/AIO実装のアシスタントです」の1行は、どの立場で答えるかを決めています。その上に材料が乗り、材料の扱い方として生成ルールが乗り、いちばん上に返し方の指定が乗ります。
この章のまとめ
コピーするのはコードブロックの中身だけです。役割・材料・ルール・返し方の4段でひと組になっていて、どれが欠けても返ってくる形が崩れます。
05構造化データを作らせる生成ルールは、AI検索最適化として何を止めているんですか？
4段のうち、出力の中身をいちばん左右するのが3段目です。ここは項目が並んでいますが、全部を覚える必要はありません。
消さずに残してほしいのは4番目です。掲載情報にない値を作り出さず、不明な項目はプロパティごと省略するという歯止めになっています。ここが無いと、それらしい値で空欄が埋まったコードが返ってきます。
埋まってしまうと厄介なのは、あとから見て、どこが埋められたのか分からなくなる点です。空欄のまま返ってくれば、足りない項目がひと目で分かります。
出力形式で説明文を省かせているのも、あとの工程のためです。前置きが付いていないので、返ってきたものをそのまま検証ツールに貼れます。
この章のまとめ
生成ルールが止めているのは、空欄をそれらしい値で埋めることです。空欄のまま返ってくるから、足りない項目が見えます。
06構造化データの【ページ種別】と【掲載情報】には、AI検索に何を伝えるつもりで書くんですか？
使う変数
| 変数 | 説明 | 入力例 |
|---|---|---|
| 【ページ種別】 | 生成したいJSON-LDのページ種別 | ブログ記事（Article） |
| 【掲載情報】 | ページに実際に表示されている情報を項目ごとに1行で | タイトル: 〇〇の始め方／著者名: 山田太郎／公開日: 2026-07-25 |
※入力例はすべて架空の例です。
【ページ種別】は、どの用紙を使うかを決める欄です。ここに入れた言葉から @type が選ばれます。判断に迷う型のときは、AIが最も一般的な型を選んだうえで、選定理由を1行添えて返してきます。迷ったかどうかが、その1行で分かるようになっています。
【掲載情報】は、用紙に書き込む中身です。ここで大事なのは、ページに実際に表示されている情報だけを書くことです。まだ載せていない著者名や、社内でしか決まっていない公開日を渡すと、ページと構造化データが食い違ったまま設置されます。
この章のまとめ
【ページ種別】が用紙を決め、【掲載情報】が中身を埋めます。ページに出ていない値は渡しません。渡さなければ、その項目はプロパティごと省かれます。
07生成されたJSON-LD構造化データは、AI検索最適化の目でどこを確かめるんですか？
出力されたコードは、そのまま公開せず、次の3点を確認してから設置してください。
- 選択された
@typeが、ページの内容と実際に合っているか - 出力されたプロパティの値が、ページに表示されている情報と一致しているか
- 波括弧・角括弧の対応が崩れていないか（検証ツールでの確認が確実です）
この3点は、確かめ方が同じではありません。前の2つは、ページを知っている人が読んで決めることです。@type が合っているかは、そのページが何のページなのかを知らないと判断できません。値がページと一致しているかも同じです。
最後の1つは逆で、人が目で追うのに向いていません。括弧やカンマの対応は、読み流すと正しく見えてしまうからです。ここは検証ツールに任せます。
コードの直後に付いてくる @type の選定理由は、最初に読んでください。選定理由が腑に落ちないときは、その先の値も疑う、という順番で見ると早く済みます。
この章のまとめ
@type と値の一致は、人が読んで決めます。括弧やカンマの対応は、目で追わずツールに確かめさせます。
08JSON-LDの検証は、LLMO対策としてどこまでやれば設置していいんですか？
若葉さんどこまで確認したら、ページに置いていいことになるんでしょうか。線引きが分からなくて。
鈴木さん検証ツールでエラーが出なくなったところ、と決めてしまうのがいちばん迷いません。自分の目で「たぶん大丈夫」と判断する工程を、途中に挟まないほうがいいんです。
使うのは、Googleが提供するリッチリザルトテスト（search.google.com/test/rich-results）です。生成したコード、または公開後のURLを貼り付けて実行すると、構文エラーやプロパティの過不足を確認できます。
エラーが出たら、該当するプロパティを直して、もう一度かけます。エラーが消えてから、<script> タグとしてページに設置します。直す・かけ直す・消えてから置く。この順番を崩さないでください。
検証ツールの詳しい使い方は、別記事 AIOM-082 で解説しています。JSON-LDの基本文法や、Article・Organization型の書き方そのものを押さえたい場合は、別記事 AIOM-040 を参照してください。
この章のまとめ
設置してよい合図は、リッチリザルトテストでエラーが消えたときです。自分の目で「たぶん大丈夫」と判断する工程を、途中に挟みません。
09AIが作った構造化データを鵜呑みにしないために、AIOでは何に気をつけますか？
AIの出力には、誤りが含まれる場合があります。特に @type の選定やプロパティの値（Google仕様、2026年7月時点）は、そのまま使わず一次情報で確認してから採用してください。
疑いどころは、大きく3つに分かれます。
1つめは、型と値そのものです。 聞き慣れない型のときほど、schema.orgに実在しないプロパティ名が生成されてしまうことがあります。生成後は、schema.orgの公式定義ページと照らし合わせて確認してください。
2つめは、同じ入力でも変わることです。 AIの回答は実行のたびに揺らぎます。同じ入力でも、選択される @type やプロパティの構成が変わることがあるため、複数回試して比較することをおすすめします。
3つめは、外へ出す前の確認です。 ここだけは、生成する前に決めておく話になります。
生成されたJSON-LDには、カンマの過不足や括弧の対応崩れといった構文エラーが含まれるリスクがあります。設置前に、リッチリザルトテストで構文エラーがないことを確認してください。
この章のまとめ
疑うのは型と値、実行ごとの揺らぎ、そして貼り付けてよい情報かどうかの3つです。最後の1つだけは、生成する前に決めておきます。
10構造化データの一括生成や修正にも、AI対策として使い回せますか？
高梨課長1ページずつ回すのは正直きついです。まとめて処理する使い方はできますか。
鈴木さんできます。それと、もう1つ。すでに公開しているページを直すときにも、同じプロンプトが使えますよ。
応用1: 複数ページ分を一括生成する。 複数ページの【ページ種別】と【掲載情報】をまとめて入力すれば、同じ制約のもとで複数のJSON-LDコードを一度に生成できます。制約が共通なので、ページごとに書き方がぶれません。
応用2: 既存コードの修正に使う。 新規生成だけではありません。【掲載情報】を実際の既存コードの内容に合わせて更新すれば、情報が古くなったJSON-LDの修正にも応用できます。
どちらの応用でも、確認の工程は変わりません。まとめて生成したぶんも、直したぶんも、設置の前にリッチリザルトテストを通します。
この章のまとめ
まとめて作る使い方と、古くなったものを直す使い方があります。どちらでも、設置前に検証を通す工程は同じです。
11よくある質問
AIが生成したJSON-LDは、公開前にどう確認すればいいですか？
Googleが提供するリッチリザルトテスト（search.google.com/test/rich-results）を使ってください。生成したコード、または公開後のURLを貼り付けて実行すれば、構文エラーやプロパティの過不足を確認できます。エラーが出た場合は、該当するプロパティを直してから、もう一度かけ直します。
Article型以外の構造化データも、同じプロンプトで生成できますか？
生成できます。【ページ種別】にOrganization・BreadcrumbList等、任意のschema.org型を指定すれば、同じプロンプトの構成で、対応する型のコードを生成できます。型が変われば必須プロパティの決まりも変わるため、設置前の検証は型ごとに行ってください。
AIが存在しないプロパティ名を作ってしまうことはありますか？
あり得ます。特に聞き慣れない型では、schema.orgに実在しないプロパティ名を生成してしまう場合があります。生成後は、schema.orgの公式定義ページと照らし合わせて確認することをおすすめします。
同じ入力なのに、返ってくるコードが変わるのはなぜですか？
AIの回答は実行のたびに揺らぎます。同じ入力でも、選択される @type やプロパティの構成が変わることがあります。重要なページで使うときは、複数回試して比較することをおすすめします。
未公開のページ構成を、そのまま貼り付けてもいいですか？
その判断は、貼り付ける前に済ませてください。未公開の情報や、社内限定のページ構成を含む掲載情報をプロンプトに渡す際は、利用中のAIサービスの法人プラン・データ学習利用設定を事前に確認してください。生成したコードを商用サイトで使う場合も、利用規約の範囲内で行ってください。
12まとめ｜今日から始める3つのこと
JSON-LDは、書けないから手が止まるのではありません。ページを出すたびに、型の綴りと必須項目と入れ子の形を調べ直すから止まります。
預けないものもあります。返ってきたコードを設置してよいかどうかを決める仕事です。ここは人の側に残ります。
今日この順でやります
公開するページの種別を決める
【ページ種別】に入れる言葉を、まず1行で書き出します
ページに出ている情報だけを並べる
【掲載情報】に、表示されていない値は入れません
返ってきたコードをテストにかける
エラーが消えてから、
<script>タグとして置きます
AI検索では、こう聞かれています
JSON-LDの構造化データを、AIに書かせることはできますか？
「AIにJSON-LDを生成させるプロンプトは、AI対策としてどこをコピーすればいいんですか？」の章に、そのままコピーできる形で置いています
schema.orgの型やプロパティを調べずに、構造化データを作る方法はありますか？
「JSON-LD構造化データをAIに生成させると、AI検索対策では何が変わるんですか？」の章で、何を預けて何が手元に残るかを説明しています
AIが生成したJSON-LDは、そのままページに貼っても大丈夫ですか？
「JSON-LDの検証は、LLMO対策としてどこまでやれば設置していいんですか？」の章で、設置してよい合図を説明しています
次に読むなら、この記事です
