B2Bコンテンツの90%以上では、ArticleとBlogPostingのどちらを選んでも、AIエンジンに引用されるかどうかにはほとんど影響しません。結果を左右するのは型の名称ではなく、必要なフィールドが揃い、正確に記述されているかです。ただし、「ほとんど」には例外があります。コンテンツによっては、型を誤ると本来狙えた検索機能への掲載機会を逃します。本記事では、迷わなくてよい違いと、見過ごせない違いを整理します。
まず押さえておきたいのは、BlogPostingがArticleのサブタイプであることです。schema.orgの継承関係はArticle → SocialMediaPosting → BlogPostingです。BlogPostingを指定すると、「これはArticleであり、より具体的にはブログ記事である」と宣言したことになります。両者が使う主要フィールドは同じです。GoogleのドキュメントでもArticle、NewsArticle、BlogPostingは同じ仕様内で扱われ、必須・推奨フィールドも共通しています。
多くの場合、「どちらを選ぶか」がそれほど重要ではない理由
AIエンジンやGoogleが記事を評価する際に読み取るのは、型の「ラベル」よりも構造化データの「属性」です。誰が執筆したのか、いつ公開・更新されたのか、どのWebサイトに属するのか、メイン画像は何か。こうした情報を参照します。ArticleとBlogPostingでは、これらのフィールド名が共通しています。つまり、@typeをArticleからBlogPostingへ変更しても、author、datePublished、dateModified、publisherの値は変わらず、機械が読み取る情報も同じです。
- headline:記事タイトルです。110文字以内を目安とし、ページタイトルと一致させます。
- author:必ずPersonまたはOrganizationオブジェクトを使用し、sameAsで検証可能な著者情報を示します。
- datePublishedとdateModified:公開日時と最終更新日時です。AIがコンテンツの鮮度を判断する主な材料になります。
- publisher:ロゴを含む発行組織の情報です。記事とブランドのエンティティを結び付けます。
- imageとmainEntityOfPage:記事のメイン画像と正規URLを示します。
では、型の選択が本当に問題になるのはどのような場合でしょうか。
違いが実際の影響として表れるのは、さらに具体的な2つの型です。1つ目はNewsArticleです。GoogleではNewsArticleが特別に扱われ、Top StoriesやGoogle Newsへの掲載を目指すうえで重要な条件の1つになります。ただし、これは諸刃の剣です。速報性のある報道記事ではないコンテンツにNewsArticleを付けてもニュース枠には掲載されず、内容と型が一致していないと判断される可能性があります。反対に、実際の業界ニュースをBlogPostingにすると、ニュース枠への入口を自ら閉ざすことになります。
2つ目はTechArticleです。技術ドキュメント、開発者向けチュートリアル、実装ガイドなどに使用します。proficiencyLevelやdependenciesといった追加フィールドにより、想定する読者の習熟度や必要な前提条件を明示できます。開発者向けSaaSのAPIチュートリアルであれば、BlogPostingよりTechArticleのほうが適切です。明確な手順がある場合は、HowToを組み合わせることもできます。原則はシンプルです。「正確かつ最も具体的な型」を選び、無難だからという理由で汎用的な型に戻さないことです。
30秒で判断できる3ステップ
- 明確な時事性と報道性があるコンテンツか? はい → NewsArticle(実際に報道記事としての要件を満たす場合に限ります)。
- 技術ドキュメント、開発チュートリアル、段階的な実装ガイドか? はい → TechArticle。明確な手順があればHowToも組み合わせます。
- どちらでもない場合、公開日を持つブログ記事か? はい → BlogPosting。
- 時系列に左右されない定番の資料、ガイド、ナレッジベース記事か? はい → Article。

AIエンジンが実際に読み取るのは、これらのフィールドです
適切な型を選ぶことは、最低限の条件にすぎません。ChatGPT、Perplexity、Google AI Overviewsで繰り返し引用されるために重要なのは、各フィールドが漏れなく、検証可能な形で記述されていることです。authorが単なる「編集部」という文字列では、エンジンは権威性を判断できません。Personオブジェクトを使い、sameAsでLinkedInや著者ページを示せば、E-E-A-Tを裏付けるシグナルを構築できます。また、dateModifiedが2年前のままであれば、AIはより新しい情報源を優先する傾向があります。記事の完成度が高くても、参照候補として後回しにされかねません。
型の選択ミスより深刻な4つの問題
- WebPageだけを使用する、または型を指定しない。Article固有のフィールドを活用する機会をすべて手放すことになります。
- authorをプレーンテキストで記述し、PersonオブジェクトやsameAsを設定しない。権威性を裏付けるシグナルをほとんど提供できません。
- headlineがページタイトルと一致していない、または110文字を超えて途中で切れている。
- 矛盾する複数の型を同じノードへ無理に詰め込む、または全記事に同一のdatePublishedをコピー&ペーストする。
B2B SaaS企業のGEO監査を行っていると、型の指定ミスが主因になっているケースは多くありません。むしろよく見られるのは、サイト内の全記事にBlogPostingが設定されているものの、authorはプレーンテキスト、dateModifiedは一度も更新されず、publisherにはロゴがないという状態です。型が正しくてもフィールドが空では、AIは信頼性の判断に必要な情報を抽出できません。型の名称に悩み続けるより、こうしたフィールドを整備するほうが、通常は改善効果も大きくなります。
型は、エンジンが記事をどう分類するかを決めます。フィールドは、その記事を信頼できるかどうかの判断材料になります。カテゴリを誤れば、失うのは特定の掲載枠かもしれません。しかし、必要なフィールドが空であれば、記事全体の評価が下がります。— Tenten GEO
結論として、こう使い分けます
一般的なブログ記事にはBlogPosting、長期的に参照される資料にはArticle、ニュースにはNewsArticle、技術解説にはTechArticleを使います。最も正確で具体的な型を選んだら、残りの労力はフィールドの充実に充ててください。型の名称を決めるために30秒以上悩む必要はありません。自社サイトの構造化データについて、型が適切か、必要なフィールドが欠けていないかを確認したい場合は、30分のGEO診断をご予約いただけます。実際の記事を確認し、優先して整備すべきフィールドを具体的にお伝えします。



