Article schemaの実装ミスをAIに指摘させるプロンプト

Article型のJSON-LDには、実は必須プロパティが1つもありません。書いても書かなくても構文エラーにはならないため、著者情報の入れ子崩れや日付形式のミスがあっても、誰にも気づかれないまま公開され続けることがあります。この記事は、実装済みのコードをAIに渡し、抜けや入れ子崩れを見つけさせる手順を扱います。

01この記事でわかること

• 実装済みのArticle schemaのJSON-LDコードをAIに渡し、実装ミスを一覧で指摘させるプロンプト
• 入力する情報（既存のJSON-LDコード）と、得られる出力（チェック項目ごとの判定と修正案）
• AIが判定できる範囲と、別途手動で確認すべき範囲の切り分け方

03課題の整理（なぜ難しいか）

Article schemaは必須プロパティが存在しないぶん、逆に何をどこまで書けば十分なのか、自己流では判断に迷います。

• 著者が複数いる場合、1つの文字列にまとめて書いてしまい、Person型の入れ子として認識されない
• author.nameに役職や敬称、媒体名まで含めてしまい、値が冗長になる
• datePublished・dateModifiedをISO 8601形式でなく、日付のみの独自形式で書いてしまう
• 「imageは単純なURL文字列のままではなくImageObject型にすべき」という思い込みが先行し、本来確認すべきurlプロパティの欠落やリンク切れの確認が後回しになりやすい（URL文字列・ImageObject型・配列はいずれも有効な記述形式です。出典: Google公式Article構造化データドキュメント）

以下のプロンプトは、これらの観点を1回のレビューでまとめて確認する形に設計しています。

04プロンプト本体

自社で実装済みのArticle・NewsArticle・BlogPosting型のJSON-LDを、公開前または定期点検のタイミングでレビューする場面で使います。

あなたはGoogleの構造化データガイドラインに詳しいテクニカルSEO/AIOの
アナリストです。以下のJSON-LDコードを、指定したチェック項目にもとづ
いてレビューしてください。

■レビュー対象のJSON-LDコード
【JSON-LDコード】

■チェック項目(この7項目を必ず全て判定すること)
1. プロパティ名にスペルミスや、schema.orgに存在しないプロパティ名の
   使用がないか。
2. @typeがArticle・NewsArticle・BlogPostingのいずれかであり、内容に
   対応した型になっているか。
3. authorがPerson型またはOrganization型として入れ子で記述されている
   か。文字列のみの記述、または複数著者を1つの文字列にまとめた記述に
   なっていないか。
4. author.nameに、役職・敬称・媒体名など、氏名以外の情報が混入して
   いないか。
5. datePublished・dateModifiedがISO 8601形式(例: 2026-07-26)で記述
   されているか。
6. imageプロパティにurlの欠落がないか。URL文字列・ImageObject型・配列
   のいずれの記述形式も有効なため、形式の違い自体は指摘しないこと。
7. headlineが本文タイトルの冗長な繰り返しになっていたり、極端に長い
   文字列になっていないか。

■出力形式
以下の表形式で、7項目すべてについて出力してください。
| チェック項目 | 判定(OK/NG/要確認) | 該当箇所 | 修正案 |
表の後に、NGと判定した項目の数を1行でまとめること。

■制約
- JSON-LDコードに実際に書かれていない内容から、問題の有無を推測しな
  いこと。判定できない項目は「要確認」とし、理由を該当箇所欄に書くこと。
- 画像の実際のピクセル解像度やURLの実在性は、テキストからは判定でき
  ないため対象外とすること。

使う変数

※入力例のコードは説明用に簡略化したサンプルであり、実在するページの実装ではありません。

05出力の見方と分析の観点

出力された表は、次の3点を中心に確認してください。

• NG判定の該当箇所が、実際のコードの該当プロパティを正しく指しているか
• author・imageの入れ子構造に関する指摘が、schema.orgの型定義と矛盾していないか
• 「要確認」と判定された項目について、AIが理由を明記しているか

著者情報をPerson型で正しく実装する詳しい書き方は、別記事『著者Person schemaの書き方とE-E-A-T効果』で解説しています。JSON-LDを新規生成する場合の基本プロンプトは、別記事『JSON-LD構造化データをAIに生成させる実践プロンプト』を参照してください。

06応用パターン

応用1: 複数記事を一度にまとめてチェックする

複数記事のJSON-LDコードを記事タイトルの見出し付きで連結し、【JSON-LDコード】に入力してください。■出力形式に「記事ごとに表を分けて出力してください」と1行加えると、複数記事をまとめて点検できます。

応用2: 特定のチェック項目だけを深掘りする

「4番のauthor.nameの混入チェックだけを、もっと厳しい基準で見てください」のように対象を絞ると、1項目だけを重点的に精査できます。

07注意点

JSON-LDの診断結果は、あくまでテキスト上の整合性チェックにすぎません。実際の公開前には、必ずGoogle公式のツールでも確認してください。

自社の未公開コンテンツや、公開前の記事のJSON-LDをプロンプトに貼り付ける際は、利用中のAIサービスの法人プラン・データ学習利用設定を事前に確認してください。

診断結果を社外の委託先と共有する場合や、大量記事に自動適用する場合は、利用しているAIサービスの利用規約の範囲内で行ってください。

AIの回答は実行のたびに揺らぎます。同じコードでも、要確認と判定される項目の粒度が実行のたびに変わることがあるため、重要な判断の前には複数回試すことをおすすめします。

AIはJSON-LD内のテキストしか読めないため、imageプロパティに書かれたURLが実在するか、実際の解像度がGoogleの推奨条件を満たしているかまでは判定できません。URLの実在確認や画像の実解像度確認は、別途手動またはリッチリザルトテストで行ってください。

08FAQ

09この分野を体系的に学ぶ