ツール一覧 ／ AI活用ノート ／ ChatGPTのJSON-LDが検証に落ちる7パターンと確認手順
ChatGPTに構造化データを書かせると、骨組みは正しいのに値で落ちます。営業時間の中抜け、定休日、必須プロパティ欠落、価格形式など実際に落ちる7パターンと、生成後に確認する項目を公式ドキュメントから整理しました。
JSON-LD の骨組みを書かせるのは速いです。@context と @type のネストを手打ちするより、生成させて直したほうが確実に短く済みます。
落ちるのはいつも値の側です。特に、営業時間のように「日本語では自然に書けるが、語彙としては表現しにくい」ものが崩れます。昼休みの中抜け、定休日、隔週の休業。ここを見ずに納品すると、構文エラーはゼロなのに営業時間が実態と違う JSON-LD が公開されます。
時間で見るなら、生成は30秒、確認は3〜5分です。この3〜5分を省くと、後から店舗側に「日曜も開いていると出ている」と言われて調べ直す羽目になります。割に合いません。
なお、ここに書いた仕様は 2026-09-03 時点の Google 検索セントラルと schema.org の記述に基づいています。筆者が有料プランで検証したわけではなく、根拠はすべて公式ドキュメントです。
このあとに出てくる「7パターン」と「生成後に見る5項目」は、順位付きの一覧です。何を見て並べたのかを先に書いておきます。
7パターンを選んだ基準
7パターンの並び順
上から、検証ツールで検出できない度合いが高い順に並べています。1と2は構文としては完全に正しいためツールが何も言わず、目視でしか見つかりません。3〜5は検証ツール側で拾える可能性があります。6と7はツールではなくガイドラインの解釈の問題で、実害が最も大きいので最後に置きました。
「生成後に見る5項目」の並び順
ツールが検出しない項目を先、ツールで拾える項目を後にしています。ツールを先に通すと「エラーなし」の表示で確認を打ち切りやすいためです。
この基準に当てはまらないもの（型の選び方、パンくずの設計、複数エンティティの @id 参照など）は、本題から外れるため扱っていません。
| # | 症状 | 何が起きるか | 確認場所 |
|---|---|---|---|
| 1 | 中抜けを1件で書く | 12:00–14:00 も営業中として扱われる | openingHoursSpecification の件数 |
| 2 | 定休日を書かない | 「休み」ではなく「情報なし」になる | 曜日が7日分あるか |
| 3 | 時刻・曜日の形式違い | 検証でエラー、または黙って無視される | "9:00 AM" "月曜" の混入 |
| 4 | 必須プロパティ欠落 | リッチリザルトの対象外 | name / address / offers |
| 5 | 価格に記号やカンマ | Offer が無効 | price の中身 |
| 6 | aggregateRating の勝手な追加 |
自社管理のレビューは星の対象外 | 数値の出どころ |
| 7 | ページに無い情報の補完 | ガイドライン違反、手動対策の対象 | 本文との突き合わせ |
← 表は横にスクロールできます →
一番よく見る崩れ方です。「9時から18時、12時から14時は昼休み」と伝えると、opens: "09:00" / closes: "18:00" の1件だけを出し、休憩は description に日本語で添える、という書き方をしてきます。
schema.org の OpeningHoursSpecification は dayOfWeek / opens / closes を持つ型で、opens は「指定曜日の営業開始時刻」、closes は「営業終了時刻」と定義されています。1件で書けるのは連続した1区間だけです。休憩を挟むなら、午前と午後で2件に分けます。
ややこしいのは、深夜0時をまたぐケースの扱いが逆であることです。Google のローカルビジネスのドキュメントでは、営業時間が深夜0時をまたぐ場合は1つの OpeningHoursSpecification で開始時間と終了時間を定義する、と書かれています。「またぐときは分けない、中抜けは分ける」。ここを取り違えた出力もよく見ます。
水曜定休と伝えると、水曜のエントリを配列から落として返してくることがあります。人間の目には正しく見えます。実際には「水曜は休み」ではなく「水曜の情報がない」という状態です。
Google のドキュメントには、終日休業を示すには opens と closes の両方に 00:00 を指定する、と明記されています。終日営業は opens: "00:00" / closes: "23:59" です。この2つは似ているのに意味が正反対なので、生成された JSON をざっと眺めるだけでは見分けがつきません。
季節営業や臨時休業を入れる場合は validFrom と validThrough の両方を日付で指定します。片方だけだと期間が閉じません。日付は YYYY-MM-DD 形式です。
schema.org の Time 型は「A point in time recurring on multiple days in the form hh:mm:ss[Z|(+|-)hh:mm]」と定義されています。日付を含まない、繰り返しの時刻です。ChatGPT は文脈に引っ張られて "9:00"、"9:00 AM"、"午前9時" を混ぜてくることがあります。特に、プロンプトに日本語の営業時間表を貼り付けたときに起きやすい印象です。
曜日は "Monday" のような英語表記（Google のドキュメントには短縮表記も対応とあります）か、https://schema.org/Monday のフル URL です。"月曜日" や "Weekdays" は通りません。
もう一つの混線が、openingHours と openingHoursSpecification の取り違えです。schema.org の openingHours は "Tu,Th 16:00-20:00" のような文字列で、曜日は2文字コード、時刻は24時間表記、複数曜日はカンマ、範囲はハイフンです。オブジェクト形式の openingHoursSpecification とは書式が別物なので、両方を1つの JSON に混ぜた出力が出てきたら片方に寄せます。
ここが構造的な弱点だと思います。生成AIは「それらしく豊かな」出力を好むので、推奨プロパティを大量に付ける一方で、地味な必須プロパティを落とします。
ローカルビジネスで必須なのは address と name の2つだけです。openingHoursSpecification も geo も priceRange も telephone も、Google のドキュメント上は推奨です。それなのに、address が streetAddress だけで addressLocality や postalCode が無い、という出力は珍しくありません。
商品（商品スニペット）では、name に加えて review / aggregateRating / offers のいずれか1つが必須です。販売者リスティングまで狙うなら image と offers.price、offers.priceCurrency が必須に上がります。組織（Organization）には必須プロパティがなく、該当するものを足していく設計です。型ごとに要件が違うので、「LocalBusiness の感覚で Product を書く」と抜けます。
Google の構造化データの解説ページには、こう書かれています。「完全でないデータ、不正な形式のデータ、不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要」。生成された JSON-LD は、たいていこの逆を向いています。プロパティを削る方向の編集は、遠慮なくやっていい部分です。
Offer の price は数値形式で、通貨記号やカンマを使いません。"¥3,000" も "3,000" も落ちます。priceCurrency は ISO 4217 の3文字なので "JPY" です。"円" や "¥" ではありません。
availability は https://schema.org/InStock のような完全な URL の列挙値です。"InStock" と裸で書かれた出力をよく見ます。値の一覧は InStock / OutOfStock / PreOrder / SoldOut / BackOrder / Discontinued / InStoreOnly / OnlineOnly / LimitedAvailability / PreSale です。
aggregateRating は別の意味で注意が要ります。Google のレビュー スニペットのドキュメントには、レビューされる側のエンティティが自身のレビューを管理している場合、LocalBusiness やその他の Organization タイプを使っているページはスターレビュー機能の対象外になる、とあります。それでも「ローカルビジネスの構造化データを書いて」と頼むと、ratingValue: 4.8 / reviewCount: 127 のような数字を添えてくることがあります。この数字には出どころがありません。実在しない評価をマークアップするのは、後述の一般ガイドラインにも触れます。消してください。
技術的なエラーより、こちらのほうが実害が大きいです。
Google の一般的なガイドラインには「ページの読者に表示されないコンテンツをマークアップしないでください」と書かれています。構造化データはページのメインコンテンツを正確に表現する必要があり、実装する場所も「内容を記述するページ」です。そして、これに反した場合は手動による対策が実施される可能性があり、対策を受けるとページがリッチリザルトとして表示されなくなります（通常の検索ランキングには影響しないとされています）。
ChatGPT は空欄を嫌います。店舗名と住所しか渡していないのに、それらしい電話番号、それらしい priceRange、それらしい営業時間を埋めてくることがあります。悪気があるわけではなく、そういう出力になりやすいというだけです。ただ、これをそのまま公開すると、ページ本文には無い情報がマークアップされた状態になります。
対策は単純で、生成前に「ページ本文にある情報だけを使い、不明なプロパティは省略すること」と指示を足すことです。それでも埋めてくることはあるので、生成後にページ本文と突き合わせます。
ここが意外と共有されていない部分だと思います。検証ツールは2つあり、見ている範囲が違います。
スキーマ マークアップ検証ツール（validator.schema.org）は schema.org の語彙として正しいかを見ます。存在しないプロパティ名や型名の綴り違いは、ここで出ます。
リッチリザルト テストは、Google がサポートするリッチリザルトの要件を見ます。ヘルプには、構造化データを実装して Google 検索結果の特別な機能を有効にするときにテストできる、とあります。裏を返すと、検索ギャラリーに載っていない型は「対象外」として素通りします。エラーが出ないことと、正しいことは違います。
そして両方を通しても、リッチリザルトが表示される保証はありません。Google のドキュメントには、ガイドラインに準拠しない構造化データはリッチリザルトとして表示されない場合がある、と書かれています。公開後の実態は Search Console のリッチリザルト ステータス レポートで見ます。ここでは「有効な項目」（重大な問題がなくリッチリザルトとして表示できる項目）と「無効な項目」（表示できない重大な問題が1つ以上ある項目）が分けて出ます。修正後に同じ問題が90日以内に再発した場合の再検出ルールもあるので、直したつもりで放置しないほうがいいです。
もう一つ、Google 検索は schema.org の語彙を使っていますが、動作の定義は schema.org ではなく Google 検索セントラルのドキュメントを見るように、と明記されています。ChatGPT は schema.org 全体から自由に語彙を引いてくるので、「schema.org 的には正しいが Google は見ていない」プロパティが混ざります。害はありませんが、意味もありません。
FAQPage はその典型です。2023年の変更で、FAQ のリッチリザルトは「よく知られた信頼のおける政府機関および保健衛生関連のウェブサイト」向けに限定されました。それでも FAQPage を提案してくる出力はあります。マークアップ自体は無効ではありませんが、一般的な制作会社のクライアントサイトで FAQ の展開表示を期待するのは、2026-09-03 時点では現実的ではありません。
順番の根拠は「選定基準」に書いたとおりです。1と3はどちらのツールでも検出されません。構文としては完全に正しいからです。ツールを先に通すと「エラーなし」の表示で確認を打ち切りやすく、中抜けの取りこぼしを見逃します。目視を先、ツールを後にしたほうが、取りこぼしが減ります。
営業時間については、曜日の数を数えるのが一番速いチェックです。定休日を含めて7件（中抜けがある曜日は2件ずつ）になっているか。ここだけで、パターン1と2はほぼ潰せます。
Q. ChatGPT に「Google のドキュメントに従って」と指示すれば防げますか。
指示の有無で出力は変わりますが、確認を省ける水準にはならないと考えたほうがいいです。特に、ページに無い値を補完する挙動と、中抜けを1件で書く挙動は、指示していても出てきます。生成の指示を工夫するより、生成後のチェックリストを固定するほうが、作業として安定します。
Q. どちらの検証ツールを使えばいいですか。
用途が違うので両方通します。schema.org のマークアップ検証ツールは語彙と構文、リッチリザルト テストは Google の機能要件です。公開後は Search Console のリッチリザルト レポートで、無効な項目が出ていないかを見ます。
Q. 中抜けを description に日本語で書くのは無意味ですか。
構造化データとしては読まれない、と考えるのが妥当です。opens / closes は曜日ごとの開始・終了時刻として定義されているので、休憩を表現したいなら区間を分けます。ページ本文には人間向けに「12:00–14:00 休憩」と書いておく。役割が違います。
Q. FAQPage は付けないほうがいいですか。
リッチリザルトの表示を目的にするなら、2026-09-03 時点では期待しないほうがいいです。マークアップとして無効ではないので残しても構いませんが、「FAQ を構造化データにしたので検索結果に出ます」という説明をクライアントにするのは避けてください。後で説明が必要になります。
Q. LocalBusiness に星評価を付けたいと言われたら。
Google のレビュー スニペットのドキュメントに、レビュー対象のエンティティが自身のレビューを管理している場合、LocalBusiness や Organization のページはスターレビュー機能の対象外になると書かれています。この根拠を示して、自社サイト上の自己申告レビューでは星は出ない、と伝えるのが正確です。数字を入れて様子を見る、という進め方は勧めません。
Q. 生成された JSON-LD をそのまま納品物に含めていいですか。
構造化データは、クライアントの店舗名・住所・営業時間といった事実データを JSON 形式に整形したものです。中身の値はクライアント由来なので、実務上の論点は「値が正しいか」に集約されます。ただし利用規約の解釈が絡む部分については、この記事の執筆時点で OpenAI の規約ページ本文を取得できなかったため、断定を避けます。納品条件に不安がある場合は、提供元の規約を直接確認してください。
Sources: