パンくずリストは、画面に出して終わりにはなりません。読者に見せている同じ道順を、機械が読める形でもう一度書き添える。それが構造化データのBreadcrumbListです。
やっかいなのは、この2つが別々に育っていくところです。カテゴリの名前を変えた。階層を1つ足した。画面のほうは直したのに、構造化データのほうは前のまま残っている。見た目は何も壊れていないので、気づく機会がありません。
この記事は、サイトの階層構造を1行ずつ渡すだけで、AIにBreadcrumbList schemaのコードを組み立てさせるプロンプトを、そのままコピーして使える形でまとめました。番号を振る仕事は預けて、人の側は「画面に出ているものと合っているか」を見る仕事だけを引き受ける。そういう分け方をした記事です。
こんなふうに調べていませんか
- パンくずの構造化データを入れたいが、JSON-LDの書き方を毎回調べ直している
- 「パンくず schema 実装 AI」で検索して、AIに任せられる範囲を探している
- 階層を足すたびにposition番号を振り直していて、ずれていないか不安がある
この記事を読み終えたときに手に入るもの
- サイトの階層構造を渡すだけで、貼り付けられるBreadcrumbList schemaを手に入れられます
- 返ってきたコードの、どこを疑えばいいかが分かります
- 画面のパンくずと構造化データがずれていないかを、自分で確かめられるようになります
結論30秒でわかる、この記事の結論
- サイトの階層構造（階層名とURL）を渡すと、BreadcrumbList schemaのJSON-LDコードが、そのまま貼り付けられる形で返ってきます。
- BreadcrumbListは、Article型のように任意記述で済む型ではありません。Googleは各ListItemについて、position・name・itemの3プロパティを必須と定めています。
- 返ってきたコードは、そのまま公開しません。画面に出ているパンくずと並び順・文言を突き合わせてから設置します。
この記事は、あるマーケティング部の2人と、専門家のやり取りをはさみながら進みます。若葉さん（Web担当2年目）が「そもそもそれは何ですか」を、高梨課長（マーケ課長）が「誰が、どれくらいの手間でやるんですか」を聞きます。答えるのは鈴木さん（AIO/SEOの専門家・本誌監修）です。
01そもそもパンくずリストのschemaって、AI検索最適化では何のために書くんですか？
若葉さんパンくず、画面にはちゃんと出ているんです。それなのに、schemaのほうも書かないといけないんでしょうか。
鈴木さん見ている相手が違うんですよ。画面のパンくずは読者に向けたもので、schemaは機械に向けたものです。同じ道順を、二通りの言い方で置いておく、というイメージですね。
パンくずリストは、画面に表示するだけでは終わりません。schema.orgのBreadcrumbList型として構造化データも記述しないと、AI検索エンジンにサイトの階層構造が正しく伝わらない場合があります。
伝えているのは、そのページがどこにあるかという居場所です。人は画面の上のほうに並んだ文字を見て、いま自分がどのあたりにいるかを判断します。機械には、その判断材料が別に要ります。
住所を思い浮かべると分かりやすいはずです。都道府県から書き始めて、市区町村、番地と細かくなっていく。順番が入れ替わると届きません。BreadcrumbListも同じで、どこから始まって、どこで終わるかという並びそのものが情報になっています。
この章のまとめ
パンくずのschemaは、ページの居場所を機械に伝えるために書きます。画面のパンくずとは別に持っているので、片方を直しただけでは揃いません。
02パンくずschemaを手で書くと、AIOの実務ではどこでつまずくんですか？
高梨課長書ける人間はいます。それでも任せたほうがいい理由は、どこにあるんでしょうか。
鈴木さん書けるかどうかより、直す回数のほうが効いてきます。階層は増えますし、名前も変わります。そのたびに番号を振り直す作業が戻ってくるんです。
手で書くときにつまずくところは、主に4つに絞られます。
- 画面に出ているパンくずと、schema側のitemListElementの並び順を一致させる必要があることに気づきにくい
- 最後の階層（対象ページ自体）のitemプロパティは省略できる一方、途中の階層で省略すると必須プロパティ違反になる
- カテゴリ名の変更や階層の追加のたびに、schemaのコードも手作業で書き直す必要がある
- position番号を1つずつ手で数えると、階層の追加・削除の際に番号がずれやすい
並べてみると、性質が2つに分かれます。上の2つは知っていれば避けられることです。知らないまま書くと、正しく見えるコードが出来上がってしまいます。
下の2つは性質が違い、知っていても起きることです。数え直しは、慣れている人ほど流れ作業になります。
この章のまとめ
つまずくのは、書けないことではありません。階層が動くたびに番号を振り直すこと、そしてずれても画面には出ないことです。
03パンくずリストschemaの実装をAIに任せると、AI対策として何が変わるんですか？
渡すのは、サイトの階層構造だけです。最上位から対象ページまでを、階層名とURLの組にして1行ずつ並べます。返ってくるのは、<script type="application/ld+json"> タグで囲まれた、そのままHTMLに貼り付けられるコードです。
変わるのは手順ではありません。数える担当が入れ替わる、という言い方のほうが近いはずです。position番号の採番、並び順の写し取り、JSON-LDの記述。この3つがまとめて向こう側へ移ります。
使うAIツールはChatGPTを想定しています。サイトの階層構造をテキストで貼り付けるだけで生成でき、ファイルアップロードは不要です。無料プランでも利用できます（2026年7月時点）。
そのかわり、人の側には別の仕事が残ります。返ってきたコードが、実際の画面と合っているかどうかを決める仕事です。ここは預けられません。
この章のまとめ
変わるのは数える担当です。人の側に残るのは、返ってきたコードと画面のパンくずを突き合わせる仕事になります。
04パンくずリストschemaの実装プロンプトは、AI検索対策としてどこをコピーすればいいんですか？
サイトの新しいカテゴリページや記事ページを公開する際、その階層に対応するBreadcrumbList schemaを実装する場面で使います。次のコードブロックの中身を、そのままコピーしてください。
あなたはテクニカルSEO/AIO実装のアシスタントです。
以下のサイト階層構造をもとに、BreadcrumbList schemaのJSON-LDコードを
生成してください。
■入力データ
サイト階層構造(最上位から対象ページまでを1行1階層で。「階層名 / URL」
の形式):
【サイト階層構造】
■生成ルール(必ず守ること)
1. @contextは"https://schema.org"、@typeは"BreadcrumbList"を使用する
こと。
2. itemListElementは、【サイト階層構造】の入力順そのままの並び順で、
ListItem型の配列として記述すること。
3. 各ListItemには、position(1から始まる連番)・name(階層名)・item
(URL)の3プロパティを全て含めること。
4. 最後の階層(対象ページ自体)のitemプロパティのみ、入力にURLの記載が
ない場合は省略してよい。それ以外の階層でURLが未入力の場合は、省略
せず値の位置に「要確認」の文字列を仮に入れ、出力の最後に注記する
こと。
5. 【サイト階層構造】にない階層名やURLを、AIが推測して作り出さないこと。
■出力形式
<script type="application/ld+json">タグで囲んだ、そのままHTMLに貼り付け
られるコードのみを出力してください。前置き・後書きの説明文は不要です。いちばん下の「あなたはテクニカルSEO/AIO実装のアシスタントです」の1行は、どの立場で答えるかを決めています。その上に材料が乗り、材料の扱い方として生成ルールが乗り、いちばん上に返し方の指定が乗ります。
この章のまとめ
コピーするのはコードブロックの中身だけです。役割・材料・扱い方・返し方の4段でひと組になっていて、どれが欠けても返ってくる形が崩れます。
05schemaの生成ルールは、AI検索最適化として何を止めているんですか？
生成ルールは並んでいますが、全部を覚える必要はありません。止めているものを3つに束ねると、消してはいけない箇所が見えてきます。
1つめは、並びを勝手に変えないことです。 ルール2が、入力した順番そのままでListItemを並べるよう指定しています。読みやすい順に並べ替えられてしまうと、画面のパンくずと突き合わせられなくなります。
2つめは、番号を飛ばさないことです。 ルール3が、各ListItemにposition・name・itemの3プロパティを全て含めるよう求めています。手で数えるのをやめる、という部分がここにあたります。
3つめは、無い階層を作らないことです。 ルール5が、入力にない階層名やURLをAIに推測させません。そしてルール4が、URLが未入力の階層を黙って省略せず、「要確認」の文字列として残したうえで、出力の最後に注記させます。
この章のまとめ
生成ルールが止めているのは、並べ替え・番号の飛び・無い階層の創作の3つです。とくに「要確認」を残させる指定は消さないでください。
06【サイト階層構造】に何を書けば、パンくずschemaはAI検索に正しく伝わるんですか？
渡す変数は1つだけです。
| 変数 | 説明 | 入力例 |
|---|---|---|
| 【サイト階層構造】 | 最上位カテゴリから対象ページまでの階層名とURLを1行ずつ列挙したもの | トップ／https://example.com（架空例）、ブログ／https://example.com/blog（架空例）、記事タイトル／https://example.com/blog/sample-article（架空例） |
※入力例に含むURL・階層名はすべて架空のものです。
ここで迷いやすいのが、階層名に何を書くかです。社内で使っている呼び名ではなく、画面に実際に表示されている文言を写してください。社内の呼び名を渡すと、コードとしては正しいのに、画面と食い違ったまま設置されることになります。
URLも同じで、公開されている実際のアドレスを書きます。最後の階層だけは、URLの記載がなければ省略しても構いません。途中の階層でURLが分からないときは、空欄のまま渡してください。ルール4が働いて、「要確認」として残ります。
この章のまとめ
【サイト階層構造】には、画面に出ている文言と実際のURLだけを書きます。分からないところは埋めずに渡すと、「要確認」として返ってきます。
07生成されたパンくずschemaは、AIOの目でどこを確かめるんですか？
出力されたコードは、そのまま公開せず、必ず次の3点を確認してから設置してください。
- position番号が1から連番になっており、抜けや重複がないか
- 各階層のnameが、実際に画面に表示されているパンくずの文言と一致しているか
- 最後の階層以外でitemの値が「要確認」のまま残っていないか
この3点は、確かめ方が同じではありません。真ん中の1つは、そのサイトを知っている人にしか判断できません。画面に何と書いてあるかを知らなければ、一致しているかどうかは決められないからです。
上と下の2つは逆で、目で追うより機械に見せたほうが早く済みます。連番の抜けや、置き去りになった文字列は、読み流すと正しく見えてしまいます。
AIは実際に公開されているページの見た目を見ていません。生成したschemaの階層順序が、画面に表示されている実際のパンくずの並びと一致しているかどうかは、必ず人が目視で照合してください。
この章のまとめ
nameが画面と合っているかは、人が見て決めます。連番の抜けと「要確認」の残りは、目で追わずツールに確かめさせます。
08パンくずschemaの実装は、AI検索対策としてどこまで検証すれば設置していいんですか？
若葉さんどこまで確かめたら、ページに置いていいことになるんでしょうか。線引きが分からなくて。
鈴木さん検証ツールで指摘が出なくなったところ、と決めてしまうのがいちばん迷いません。自分の目で「たぶん大丈夫」と判断する工程を、途中に挟まないほうがいいんです。
生成後は、Googleのリッチリザルトテストでも構文エラーがないか確認してください。生成したコード、または公開後のURLを貼り付けて実行します。
指摘が出たら、該当する箇所を直して、もう一度かけます。指摘が消えてから、<script> タグとしてページに設置します。直す・かけ直す・消えてから置く。この順番を崩さないでください。
生成されたコードが構文として正しくても、実際のページ階層と内容が食い違っていれば、Googleのガイドラインに沿わない実装になり得ます。構文の検証と、画面との照合は別の工程です。どちらも通してから設置してください。
検証ツールの詳しい使い方は、別記事 AIOM-082 で解説しています。内部リンクの階層設計そのものを見直す場合は、別記事 AIOM-044 も参考になります。
この章のまとめ
設置してよい合図は、検証ツールの指摘が消えたときです。ただし構文が通ることと、画面と合っていることは別に確かめます。
09複数カテゴリや表示用HTMLにも、LLMO対策としてこのschemaプロンプトを使い回せますか？
高梨課長ページごとに回すのは、正直きついです。まとめて処理する使い方はできますか。
鈴木さんできます。それと、もう1つ。画面に出すパンくずのHTMLも、同じ入力から続けて出させると揃いやすくなりますよ。
応用1: 複数カテゴリ分をまとめて生成する。 【サイト階層構造】をカテゴリごとに分けて複数回入力すれば、同じ制約のもとで複数ページ分のBreadcrumbList schemaをまとめて生成できます。階層数が多いサイトでは、はじめからカテゴリごとに分けて実行してください。
応用2: 画面表示用のパンくずHTMLと合わせて確認する。 生成したschemaに続けて「対応する画面表示用のパンくずHTMLも生成してください」と依頼してください。schemaと表示側の整合を保ちやすくなります。
この章のまとめ
まとめて作る使い方と、表示側のHTMLまで揃える使い方があります。どちらでも、設置前に画面と突き合わせる工程は変わりません。
10AIが作ったパンくずschemaを鵜呑みにしないために、AI対策では何に気をつけますか？
AIの出力には誤りが含まれる場合があります。特にposition番号やURLは、そのまま使わず生成後に必ず目視で確認してください。
疑いどころは、大きく3つに分かれます。
1つめは、番号とURLそのものです。 生成のたびに整形が変わるので、前の出力と見比べにくくなります。
2つめは、同じ入力でも変わることです。 AIの回答は実行のたびに揺らぎます。同じ入力でも、生成されるコードの整形や「要確認」の注記の書き方が変わることがあるため、重要なページでは複数回試して比較することをおすすめします。
3つめは、外へ出す前の確認です。 ここだけは、生成する前に決めておく話になります。
この章のまとめ
疑うのは番号とURL、実行ごとの揺らぎ、そして貼り付けてよい情報かどうかの3つです。最後の1つだけは、生成する前に決めておきます。
11よくある質問
表示用のパンくず（画面のUI）と、schemaの実装は別々に作る必要がありますか？
別々に作ること自体は必須ではありませんが、両者の階層順序と文言は一致させる必要があります。応用パターンのように、schemaの生成に続けて表示用HTMLも同じ入力から生成させると、食い違いを防ぎやすくなります。
トップページ自体も、BreadcrumbListに含める必要がありますか？
必須ではありません。Googleはトップレベルのパスやページ自体をリストに含めることを求めていません（出典: Google公式構造化データドキュメント）。含める場合は、サイトの構成に応じて判断してください。
1つのページに複数のパンくずがある場合は、どう扱えばいいですか？
複数カテゴリに属する商品ページなどが該当します。Googleは1ページに複数のパンくずトレイルを指定することを認めています（出典: Google公式構造化データドキュメント）。【サイト階層構造】をトレイルごとに分けて複数回実行し、それぞれのBreadcrumbList schemaを個別に生成させてください。
階層が深いサイトでも、一度に渡してしまって大丈夫ですか？
階層数が多いサイトでは、カテゴリごとに分けて複数回実行してください。一度に渡す量が増えるほど、並び順の写し取りと番号の採番が長く続くことになります。分けて回しても、生成ルールは共通なのでコードの書き方はぶれません。
AIが生成したコードは、そのまま公開してもいいですか？
そのまま公開しないでください。position番号の連番、nameと画面表示の一致、「要確認」の残りの3点を確認し、そのうえでリッチリザルトテストで構文エラーがないことを確かめてから設置します。
12まとめ｜今日から始める3つのこと
パンくずのschemaが手間になるのは、書けないからではありません。階層が動くたびに番号の振り直しが戻ってくるからです。
預けないものもあります。返ってきたコードが、画面に出ているパンくずと合っているかを決める仕事です。ここは人の側に残ります。
今日この順でやります
対象ページの階層を書き出す
最上位から順に、階層名とURLを1行ずつ並べます
画面に出ている文言をそのまま写す
社内の呼び名ではなく、読者に見えている文字を使います
返ってきたコードを検証にかける
指摘が消えてから、
<script>タグとして置きます
AI検索では、こう聞かれています
パンくずリストの構造化データを、AIに書かせることはできますか？
「パンくずリストschemaの実装プロンプトは、AI検索対策としてどこをコピーすればいいんですか？」の章に、そのままコピーできる形で置いています
BreadcrumbListに必須のプロパティは何ですか？
「そもそもパンくずリストのschemaって、AI検索最適化では何のために書くんですか？」の章と、冒頭の結論カードで説明しています
トップページも、パンくずの構造化データに含めるべきですか？
「よくある質問」の2つ目で答えています（結論：必須ではありません）
次に読むなら、この記事です
