Article schemaの書き方｜推奨5項目と実装後に崩れる更新日【図解つき】

いま読んでいるこのページにも、Article構造化データが埋め込まれています。ブラウザでソースを表示しapplication/ld+jsonで検索すれば、実物を確認できます。

構造化データの解説記事は世の中にたくさんあります。ただ、書き方までは書いてあっても、その媒体自身がなぜその書き方を選んだのかまで開示しているものは多くありません。型を選ぶところで手が止まるのは、たいていそこに理由が見えないからです。

この記事は、Google公式ドキュメントとschema.orgにもとづく実装手順に加えて、本誌自身の判断とその理由まで開きます。そして、実装作業より崩れやすい公開後の運用を、最後にまとめて扱います。

この記事は、ある企業のWeb担当チームと専門家のやり取りをはさみながら進みます。ご自身に近い立場の質問から読んでいただいて構いません。

• 若葉さん（Web担当2年目）— 用語と仕組みを「そもそも」から聞く役
• 高梨課長（マーケ課長）— 手間に見合うのかを詰める役
• 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役

01そもそもArticle schemaって何ですか？AI検索対策になるんですか？

若葉さん

若葉さんの発言

記事のタイトルも著者名も、ページを見れば書いてありますよね。それをもう一度、別の場所に書くんですか？

鈴木さん

鈴木さんの発言

そこは引っかかるところですよね。人が読む場所と、機械が読む場所を分けて置いておく、という考え方なんですよ。

schema.orgの定義では、Article型は「ニュース記事や調査報告書など、様々なタイプの記事」を表す型です（出典: schema.org/Article）。この型を使って、記事の見出しや著者情報を検索エンジンに伝えるのがArticle schemaです。

本文を読めば分かることを、なぜわざわざ別に書くのか。理由は、読み取りの確実さにあります。本文からの推測ではなく、決められた場所に決められた名前で置いてあれば、取り違えが起きにくくなります。

02Article・NewsArticle・BlogPostingは、AIOでどう使い分けるんですか？

Article型の継承構造はThing > CreativeWork > Articleです。Article直下のサブタイプにはNewsArticleやSocialMediaPostingなどがあります。なおBlogPostingはArticleの直下ではなく、Article > SocialMediaPosting > BlogPostingという階層に位置します。

図のとおり、下の段ほど広く、上の段ほど狭いという関係です。BlogPostingは、Articleから2つぶん枝を降りた先にあります。企業ブログの記事にはBlogPostingを、報道機関のニュース記事にはNewsArticleを使うのが一般的です。

ただし、ここで正直にお伝えしておきます。Google公式ドキュメントは、Article構造化データをArticle・NewsArticle・BlogPostingのいずれかの型で実装すると定めています。一方で、3型の使い分け基準そのものは示していません。明文化された正解がない、という状態です。

03Article schemaの実装方法は、AI検索最適化として何から書くんですか？

Google公式ドキュメントは「There are no required properties」と明記しています。必須プロパティは、1つもありません。 そのうえで、該当するプロパティを追加するよう案内しています。

推奨プロパティの主要な5項目は次のとおりです（authorにはauthor.name・author.urlも推奨されています）。

以下は、企業ブログの記事を想定したBlogPostingのテンプレートです。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事のタイトルをここに入力",
  "image": "https://sample.example.com/images/article-thumbnail.jpg",
  "author": {
    "@type": "Person",
    "name": "山田太郎",
    "url": "https://sample.example.com/author/yamada-taro"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://sample.example.com/images/logo.png"
    }
  },
  "datePublished": "2026-07-28",
  "dateModified": "2026-07-28"
}

JSON-LDそのものの書き方に不安がある方は、別記事『JSON-LDの書き方入門｜3つのコピペ例で今日から書ける』（AIOM-040）から先に読むと迷いません。

04著者が複数いるとき、AI対策としてArticle schemaの実装方法はどう変わりますか？

記事に複数の著者がいる場合、書き方を誤ると片方しか認識されないことがあります。Google公式ドキュメントは、著者ごとに独立したオブジェクトを配列で並べる書き方を示しています。

"author": [
  { "@type": "Person", "name": "著者1の氏名" },
  { "@type": "Person", "name": "著者2の氏名" }
]

複数著者の氏名を1つのnameフィールドにカンマ区切りでまとめる書き方は、推奨されていません。 人が読めば2人だと分かる文字列でも、機械にとっては長い1つの名前でしかないためです。

著者情報をさらに詳しく実装したい場合は、別記事『Person schemaとは？コピペで使える実装テンプレ2種と効果の実態』（AIOM-042）のテンプレートを参照してください。組織全体の情報を伝えるOrganization schemaは、別記事『Organization schemaの書き方｜6グループで埋める順番』（AIOM-135）で解説しています。

05本誌はArticleをどう実装しているんですか？AIOの現場で下した3つの判断は？

型の使い分けに公式の正解がない以上、参考になるのは他サイトの実際の選択と、その理由です。ここでは本誌の実装を開示します。

構造化データは「良さそうな値」ではなく「実態と一致する値」を書く場所です。 この原則は、Googleの構造化データ全般のガイドラインが繰り返し求めている点でもあります。存在しない個人著者名を置いてE-E-A-Tを演出するより、編集部という実在の主体を正確に書くほうが筋が通ります。

記名著者を立てている媒体であれば、判断は逆になります。同じ理由から、逆の答えが出るということです。その場合のPerson実装は、前述のAIOM-042を参照してください。

06Article schemaを入れると、AI検索に引用されやすくなるんですか？

高梨課長

高梨課長の発言

実装の手間はかかりますよね。それで引用が増えるなら通しますが、増えないなら後回しにしたいところです。

鈴木さん

鈴木さんの発言

そこは期待値を先に正しておきます。増えるという因果関係は、証明されていません。 そのうえで、書く意味は別のところに残っています。

Article schemaを実装すればAI検索に引用されやすくなる、という因果関係は現時点で証明されていません。 SSRNで公開された検証論文では、構造化データの有無とAI引用の関連は交絡要因の補正後に統計的に消えています。

補正後に消えた、というのは大事な言い方です。「関係がある」ように見えていたものが、他の要因を揃えたら見えなくなったということです。詳細は別記事『構造化データとAI引用の相関｜論文を読んで分かった3つの事実』（AIOM-039）で扱っています。

07LLMO対策として、Article schemaを書く意味はどこにあるんですか？

期待値を下げたうえで、それでも書く実務的な意味は残ります。著者・公開日・更新日という「誰がいつ書いたか」の情報を、本文とは別に機械可読な形で置いておくこと自体が目的です。

引用率を上げる施策としてではなく、記事の素性を明示する土台として実装してください。土台は、それ単体で成果を生むものではありません。ただ、無いと上に何も積めません。LLMOの取り組み全体で見ても、素性がはっきりしている記事は、後から手を入れる余地が残ります。

08Article schemaの実装方法は、AI検索対策としてどこまで検証できますか？

高梨課長

高梨課長の発言

これは記事を出すたびに、毎回やることになりますか。本数が増えたときに回らなくなりそうで。

鈴木さん

鈴木さんの発言

型と項目の決定は、最初に済ませれば終わりです。あとから毎回見るのは、値が実態と合っているかどうかだけなんですよ。

書いたあとは、答え合わせをします。公開前にリッチリザルトテスト（search.google.com/test/rich-results）へURLまたはコードを入力し、検出された型とエラー・警告を確認します。

エラーが出た場合は、該当プロパティ名とJSON構文のカンマ・括弧の過不足を見直してください。エラーの多くは、思想の問題ではなく記号の問題です。 ツールの詳しい使い方は、別記事『構造化データのテストツール入門｜今使うべき2つの使い分け方』（AIOM-082）で解説しています。

ここまでで、実装作業そのものは終わります。ただし、この記事で本当に伝えたいのはこの先です。

09公開後にArticle schemaのdateModifiedがずれるのは、AI検索最適化でも問題ですか？

若葉さん

若葉さんの発言

実装は終わりました。あとは記事を書くたびに同じ形で入れていけば大丈夫ですよね？

鈴木さん

鈴木さんの発言

そこが落とし穴なんです。入れた値は、あとから勝手に動くことがあります。 とくに更新日は、書いた本人が知らないうちにずれていきます。

CMSが本文の編集に合わせてdateModifiedを自動更新するとは限りません。 誤字修正のような軽微な編集で日付が動くケースもあれば、大幅な加筆をしても日付が初回公開時のまま止まるケースもあります。

図のうち、実態と合っているのは1つだけです。残りは、放っておくとずれ続けます。 そして厄介なことに、ずれていること自体は画面のどこにも表示されません。だから、公開後は次の2点を運用ルールとして決めておいてください。

10Article schemaの運用でつまずくのは、AI検索対策のどこですか？

現場でよく見かけるつまずきを3つ挙げます。どれも、実装の腕前とは関係のないところで起きます。

BlogPostingとNewsArticleを混同してしまう。 企業ブログの記事にNewsArticleを使うなど、実態と異なる型を選ぶケースがあります。自社コンテンツの性質に合った型を選ぶことが基本です。

複数著者を1つのnameフィールドにまとめてしまう。 「山田太郎、鈴木花子」のようにカンマ区切りで1つのnameに詰め込む書き方は、著者ごとに個別のPersonオブジェクトとして認識されません。

dateModifiedを更新せず放置してしまう。 記事を編集してもdateModifiedを書き換えないままだと、実際の更新日と構造化データの内容が食い違います。

3つに共通しているのは、書いた値とページの実体がずれているという点です。原因は違っても、症状はいつも同じ形で出ます。

11明日からのArticle schema運用は、AI検索最適化としてどう回しますか？

最後に、続けられる形へ落とします。1回で終わる作業と、見続ける作業を分けるのがコツです。

• Article・NewsArticle・BlogPostingのいずれか、記事内容に合う型を選んでいる
• headline・image・datePublished・dateModified・authorを実装している
• 複数著者がいる場合、配列で個別のオブジェクトとして記述している
• マークアップの内容が、ページに実際に表示されている情報と一致している
• リッチリザルトテストでエラー・警告がないことを確認している
• 記事を編集したときにdateModifiedが更新されるかを、実際の記事1本で確認している

上の段だけを先にやっても、土台がずれていれば意味を持ちません。実態と一致する値 → 検証 → 更新日の追跡。この順番で積むと、あとから戻る回数が減ります。

12よくある質問

13まとめ｜今日やる3つのこと

Article schemaとは、記事のタイトル・著者・公開日を伝える構造化データです。必須プロパティは存在しませんが、headline・image・datePublished・dateModified・authorの5項目を軸に実装することが基本になります。

この実装で本当に難しいのは、初回の記述ではなく公開後の維持です。値は静かにずれていきますし、ずれたことは画面のどこにも出ません。