PR-076 記事を書いているのに、記事だとAIに正しく認識されているか分からない——Article schemaを実装する方法
こんな悩みはありませんか?
記事は日々公開しているのに、著者・公開日・更新日といった情報が、AIにとって「この記事は誰が・いつ書いたものか」を正確に読み取れる形になっているか、確認したことがない——というのはよくある盲点です。見た目上は日付や著者名が表示されていても、それが構造化データとして機械的に紐づいていなければ、AIは推測に頼らざるを得ません。
この記事でできるようになること
記事タイトル・著者・公開日・更新日などの情報を渡すだけで、Article(またはBlogPosting)のschema.org準拠JSON-LDコードを生成できるようになります。
使うプロンプト
入力に必要な素材
- 記事タイトル、対象URL
- 著者名・著者プロフィールページURL
- 公開日・更新日(YYYY-MM-DD形式)
- 発行者(会社名)・ロゴURL、記事の要約(1〜2文)
【Claude推奨・ChatGPTでも実行可】
# 役割
あなたはArticle構造化データの実装担当です。記事が「誰が・いつ書いたものか」をAIが機械的に読み取れる形にする作業を専門にしており、読み手は記事テンプレートへの実装を検討するWeb担当者です。
# 入力素材の確認
以下の情報が貼り付けられている前提で作業してください。
- 記事タイトル、対象URL
- 著者名・著者プロフィールページURL(不明なら「未記載」でよい)
- 公開日・更新日(YYYY-MM-DD形式)
- 発行者(会社名)・ロゴURL、記事の要約(1〜2文)
記事タイトルまたは対象URLが貼り付けられていない場合は、生成に進まず「記事タイトル・対象URLが確認できません。2項目を埋めて貼り付け直してください」とだけ回答し、そこで処理を止めてください。
# 記事情報
- 記事タイトル: 【記事テーマ】
- 対象URL: 【対象URL】
- 著者名・著者プロフィールページURL: 【貼り付け、不明なら「未記載」】
- 公開日・更新日: 【YYYY-MM-DD形式で貼り付け】
- 発行者(会社名)・ロゴURL: 【自社名】/【貼り付け】
- 記事の要約(1〜2文): 【貼り付け】
# 分析・作業手順
1. 記事タイトルの文字数を数え、headline(目安110文字程度)を超える場合は短縮案を作成する
2. 著者情報をPersonオブジェクト(単なる文字列にしない)として構造化する
3. 公開日・更新日をISO 8601形式(YYYY-MM-DD)で整形する
4. 発行者情報をpublisherプロパティに割り当てる
5. 貼り付けられていない項目(著者URL未記載等)を洗い出し、コメントで「要確認」と記載する
# 出力してほしいこと
1. Article(またはBlogPosting)のJSON-LDコード(headline・author・datePublished・dateModified・publisher・image・descriptionを含む)
2. headlineが長すぎる場合(目安110文字程度)は短縮案を提示する
3. authorをPersonオブジェクトとして構造化し、単なる文字列にしない
4. 貼り付けられていない項目はコード内にコメントで「要確認」と記載する
# 出力形式
1. 完成したJSON-LDコード
2. headline短縮案(該当する場合、Before→After)
3. 3行以内の要約(「要確認」の項目数/dateModifiedと本文更新日の一致確認が必要な旨/次に行うべき検証ツールでの確認)
貼り付けていない事実を新たに作成しないでください。
# 品質ガード
- headline短縮案は元のタイトルの意味・重要キーワードを欠落させない
- dateModifiedは実際に本文を更新した日付であるべきで、見た目上の再公開日と混同しないよう注意書きを添える
- 生成後は必ずリッチリザルトテストで構文エラーがないか確認する前提であることを明記する実行手順
- 対象記事のタイトル・著者・公開日・更新日など必要な情報を一覧にしておく
- Claudeにプレースホルダを置き換えてプロンプトを実行する
- 生成コードをGoogleのリッチリザルトテストで構文チェックし、必須プロパティのエラーがないかを確認する
- dateModifiedの日付が、実際に本文を最後に更新した日と一致しているかを見比べる(表示日と実更新日がズレていないか)
- 検証済みのコードを記事テンプレートに組み込み、以後は記事更新の都度dateModifiedも更新する運用ルールを決める
結果の読み解き方
- headlineが長すぎる場合の短縮案は、AIによる要約です。元のタイトルの意味やSEOキーワードが欠落していないか、必ず見比べてください。
- authorがPersonオブジェクトとして構造化されているか(単なる文字列"author": "田中太郎"になっていないか)を確認してください。文字列のままだと、著者情報としての価値が下がります。
注意点
- dateModifiedは実際に本文を更新した日付を入れてください。見た目上の再公開日と実際の更新内容が一致するよう、運用ルールを決めておいてください。
- 危険な間違い例: 記事を少し手直ししただけなのに、テンプレート側の自動処理でdateModifiedが毎回「今日の日付」に更新される設定になっていると、実質的な更新がなくても「頻繁に更新されている記事」に見せかけることになります。これは鮮度シグナルの誤表示であり、意図的でなくても信頼性を損なうリスクがあるため、CMS側の設定を確認してください。
関連レッスン・関連パターン
- レッスン III-B4 Article・BlogPostingを実装する・III-B9 検証ツールで確認する(構文だけでなく、検証ツールでの確認手順も併せて押さえておくと安心です)
- 関連パターン: PR-068 JSON-LDをゼロから生成する方法(記事以外のページ種別への応用)・PR-081 構造化データのエラーを診断し修正する方法(エラーが出た場合の対処)
確認テスト
選択肢をクリックすると、その場で正誤と解説が表示されます。
Q1. dateModifiedはCMS側の自動処理で、本文を少し手直ししただけでも毎回「今日の日付」に更新される設定にしても問題ない。
正しくは、実質的な更新がなくても頻繁に更新されている記事に見せかけることになり、鮮度シグナルの誤表示として信頼性を損なうリスクがあるため、CMS側の設定を確認すべきとされている。
Q2. authorプロパティの構造化で正しいのはどれか。
authorは単なる文字列ではなくPersonオブジェクトとして構造化しないと著者情報としての価値が下がるとされている。
Q3. headlineが長すぎる場合の目安として記事が示す文字数はどれか。
headlineが長すぎる場合(目安110文字程度)は短縮案を提示するようプロンプトで指示している。
よくある質問
Q. 生成コードは検証せず即設置してよいですか?
いけません。リッチリザルトテストで必須プロパティのエラーがないか確認する必要があります。
Q. dateModifiedはどの日付に合わせるべきですか?
見た目上の再公開日ではなく、実際に本文を最後に更新した日付に一致させる必要があります。
Q. Article以外に使える構造化データのタイプはありますか?
はい、BlogPostingも使用できます。