Article schemaの実装ミスをAIに指摘させる｜7項目の点検プロンプト

Article型のJSON-LDには、実は必須プロパティが1つもありません。

書いても書かなくても構文エラーにならないので、著者情報の入れ子が崩れていても、日付の形式が独自のものでも、誰にも気づかれないまま公開され続けます。間違いが静かに残るタイプの実装です。

この記事は、実装済みのコードをそのままAIに渡し、抜けや入れ子の崩れを表にして返させるプロンプトを、コピーして使える形でまとめました。あわせて、AIには判定できない範囲を先に切り分けておきます。

この記事は、あるマーケティング部の2人と、専門家のやり取りをはさみながら進みます。若葉さん（Web担当2年目）が「そもそもそれは何ですか」を、高梨課長（マーケ課長）が「誰が、どれくらいの手間でやるんですか」を聞きます。答えるのは鈴木さん（AIO/SEOの専門家・本誌監修）です。

01そもそもArticle schemaに必須項目が無いのは、AI検索対策でどう効くんですか？

若葉さん

若葉さんの発言

必須プロパティが無い、というところが引っかかっていて…。無くてもいいなら、書かなくても困らないということですか？

鈴木さん

鈴木さんの発言

そこが分かれ目なんですよ。困らないのは構文の側だけなんです。読み取る側は、書かれていないものを推し量ってはくれませんから。

Article型のJSON-LDには必須プロパティが存在しません（出典: Google公式Article構造化データドキュメント）。書かなくても構文エラーにはなりません。

その代わり、Googleは推奨プロパティを示しています。具体的にはheadline・image・datePublished・dateModified・authorの5項目に、書き方の注意点が示されています。

構文としては正しくても、入れ子の崩れたArticle実装はエラーにならないまま放置されます。

推奨プロパティが空だと、検索エンジンやAIが記事の著者・公開日を正しく把握できなくなります。Googleも「該当する内容があるプロパティは追加すること」と案内しています（出典: 同ドキュメント）。

02Article schemaの実装ミスをAIに指摘させると、AI検索最適化で何が分かるんですか？

このプロンプトは、実装済みのコードを推奨事項と照らし合わせ、入れ子構造の崩れや記述ミスを表形式で洗い出します。返ってくるのは、チェック項目・判定・該当箇所・修正案の列を持つ表です。

判定は3種類です。OK・NG・要確認。判定できないものをOKにしないようにしてあるので、確かめきれなかった行がそのまま残ります。表の後ろには、NGと判定した項目の数が1行でまとまります。

使用AIツールはClaudeです。既存コードを貼り付けるだけで診断が完了し、Web検索や特別な拡張機能は使いません（2026年7月時点の無料プランで動作確認済みです）。

03Article schemaの実装ミスをAIに指摘させる前に、AI検索対策で何を知っておくんですか？

高梨課長

高梨課長の発言

そもそも、うちの記事にどんな間違いが入っているのか見当がつきません。よくある型はあるんでしょうか。

鈴木さん

鈴木さんの発言

あります。しかも自己流で判断に迷ったときに出やすいものが決まっているんですよ。先に知っておくと、表を読むのが早くなります。

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

• 著者が複数いる場合、1つの文字列にまとめて書いてしまい、Person型の入れ子として認識されない
• author.nameに役職や敬称、媒体名まで含めてしまい、値が冗長になる
• datePublished・dateModifiedをISO 8601形式でなく、日付のみの独自形式で書いてしまう
• 「imageは単純なURL文字列のままではなくImageObject型にすべき」という思い込みが先行し、本来確認すべきurlプロパティの欠落やリンク切れの確認が後回しになりやすい

最後の1つだけ、性質が違います。URL文字列・ImageObject型・配列は、いずれも有効な記述形式です（出典: Google公式Article構造化データドキュメント）。形式を直すことに気を取られて、本来見るべきurlの欠落が後回しになる、という順番の問題です。

04実装ミスをAIに指摘させるArticle schema用プロンプトは、AIOのどこをコピーするんですか？

自社で実装済みの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の実在性は、テキストからは判定でき
  ないため対象外とすること。

前の3段で「誰として、何を、どの観点で見るか」を決め、後ろの2段で「返し方」と「推測の止め方」を縛っています。削ってはいけないのは、いちばん上の段です。ここが無いと、書かれていないことまで推し量った表が返ってきます。

057つのチェック項目と制約は、Article schemaのAI検索対策で何を守っているんですか？

チェック項目は、先に挙げたつまずきどころに1つずつ対応しています。加えて、制約の2行がこの診断の性格を決めています。

• JSON-LDコードに実際に書かれていない内容から、問題の有無を推測しないこと
• 画像の実際のピクセル解像度やURLの実在性は、テキストからは判定できないため対象外とすること

この2行が無いと、AIは書かれていないことまで推し量って書き始めます。判定できないものを要確認に落とすという決まりがあるから、表がそのまま作業リストになります。

チェック項目6も、同じ働きをしています。URL文字列・ImageObject型・配列のいずれの記述形式も有効なため、形式の違い自体は指摘しない、と先に書いてあります。有効な書き方をミス扱いさせないための一文です。

06【JSON-LDコード】には、Article schemaのAI検索最適化のために何を渡すんですか？

使う変数

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

渡すのは全文です。抜き出した一部だけを渡すと、抜いたプロパティが「書かれていないもの」として判定されます。

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

07返ってきた判定表は、Article schemaのAI検索対策としてどこから読むんですか？

若葉さん

若葉さんの発言

表が返ってきたら、上から順に全部読んでいけばいいんでしょうか。

鈴木さん

鈴木さんの発言

全部読む前に、表そのものが信用できるかを先に見るほうが早いですよ。指し先がずれている表を丁寧に読んでも、時間だけが減っていきますから。

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

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

順番には理由があります。1つめは、指し先がずれていれば、その行の判定そのものを読み直す必要があるからです。2つめは、有効な書き方をミス扱いしていないかを確かめる行です。3つめは、理由の書かれていない要確認が並んでいたら、診断そのものを疑う手がかりになります。

08AIが判定できない範囲は、Article schemaのLLMO対策で誰が引き受けるんですか？

高梨課長

高梨課長の発言

表が全部OKになったら、そのまま公開してしまってよいのでしょうか。

鈴木さん

鈴木さんの発言

そこは止めてください。この診断は、テキスト上の整合性チェックにすぎません。公開前には、Google公式のツールでも必ず確認してください。

AIはJSON-LD内のテキストしか読めません。imageプロパティに書かれたURLが実在するか、実際の解像度がGoogleの推奨条件を満たしているかまでは判定できません。

URLの実在確認や画像の実解像度確認は、別途手動またはリッチリザルトテストで行ってください。「テキストから言えること」と「見にいかないと分からないこと」を先に分けておくと、任せる範囲で迷わなくなります。

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

09複数記事や項目の深掘りにも、Article schemaのAI検索最適化でこのプロンプトは使えますか？

同じプロンプトのまま、伸ばし方が2つあります。広げるか、絞るかです。

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

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

新規にJSON-LDを生成する場合の基本プロンプトは、別記事 AIOM-662 を参照してください。著者情報をPerson型で正しく実装する詳しい書き方は、別記事 AIOM-042 で解説しています。

10よくある質問

11まとめ｜今日から始める3つのこと

Article型の点検が難しいのは、書き方が複雑だからではありません。間違えてもエラーが出ないからです。必須プロパティが無いぶん、確かめにいく仕組みを持たないと、間違いはそのまま残ります。

照合はプロンプトへ預けます。預けないのは、URLの実在と画像の実寸、そして公開前の最終確認です。