はじめに
BtoBの事例ページは、単なる「導入実績の紹介」ではなく、見込み顧客が自社に近い成功事例を見つけるための重要な判断材料です。さらに現在は、Google検索だけでなく、ChatGPTやPerplexityなどのAI検索がWeb上の情報を要約・比較する場面も増えています。
そのため、事例ページでは「誰が」「どの製品・サービスを使い」「どのような課題を解決し」「どのような成果があったのか」を、人間にも検索エンジンにもAIにも理解しやすい形で整理する必要があります。その土台になるのが、Schema.orgに基づく構造化データ、特にJSON-LDによる実装です。Googleも、構造化データはページ内容を理解するための明示的な手がかりになると説明しており、可能であればJSON-LDの利用を推奨しています。
本記事では、BtoB事例ページにおけるJSON-LDの実装方法と、AI検索時代のGEO対策として意識すべきポイントを整理します。
BtoB事例ページに構造化データが必要な理由
BtoBの購買担当者は、価格だけで意思決定をしているわけではありません。業界適合性、導入実績、技術仕様、サポート体制、コンプライアンス、既存システムとの相性など、複数の条件を比較しながら候補を絞り込みます。
ところが、事例ページが通常の文章だけで構成されている場合、検索エンジンやAIは「このページが何の事例なのか」「どの企業が導入したのか」「どの製品・サービスに関する実績なのか」を正確に把握しにくくなります。
構造化データを使うと、ページ内の情報を機械が読み取りやすい形で補足できます。たとえば、事例記事そのものはArticleやTechArticle、自社情報はOrganization、対象製品はProductやService、SaaSならSoftwareApplicationとして定義できます。これにより、ページ全体が単なるテキストではなく、企業・製品・導入事例・評価が結びついた情報として整理されます。
ただし、構造化データを入れれば必ず検索結果で目立つ表示になるわけではありません。Googleは、正しくマークアップされていてもリッチリザルト表示を保証しないと明記しています。また、ページ本文に見えない情報や、ページ内容を正しく表していない情報を構造化データに入れることは避ける必要があります。
JSON-LDとは何か
JSON-LDは、HTML内に<script type="application/ld+json">として記述する構造化データの形式です。MicrodataやRDFaのようにHTMLタグへ直接属性を付ける方法と比べ、表示用HTMLとデータ定義を分けやすく、保守しやすい点が特徴です。
BtoBサイトでは、CMSで事例ページを複数管理することが多いため、JSON-LDは実務上も扱いやすい形式です。WordPressなどのCMSでも、記事タイトル、公開日、著者、アイキャッチ画像、カテゴリ、導入企業名、対象サービス名などをテンプレート化して出力すれば、ページごとに手作業でJSON-LDを書く負担を減らせます。
重要なのは、JSON-LDを「検索エンジン向けのおまけ」と考えないことです。BtoBサイト全体の情報設計として、自社、サービス、顧客、事例、レビュー、FAQをどう関連づけるかを決めることが先です。そのうえでJSON-LDを実装すれば、検索エンジンやAIにとって理解しやすいページになります。
BtoB事例ページで定義すべき主なエンティティ
事例記事本体：ArticleまたはTechArticle
事例ページの中心になるのは、記事本体です。一般的な導入事例であればArticle、技術要件やシステム構成、導入プロセスを詳しく解説するページであればTechArticleを検討できます。
GoogleのArticle構造化データでは、記事のタイトル、画像、公開日、著者情報などを明示することで、ページ内容の理解を助けられるとされています。
BtoB事例ページでは、次のような項目を整理しておくと実装しやすくなります。
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "製造業A社の在庫管理DX導入事例",
"datePublished": "2026-06-01",
"dateModified": "2026-06-10",
"author": {
"@type": "Person",
"name": "記事監修者名"
},
"publisher": {
"@type": "Organization",
"name": "自社名",
"url": "https://example.com/"
}
}ここで注意したいのは、著者や監修者を曖昧にしないことです。BtoB領域では、誰が書いたのか、誰が監修したのかが信頼性に直結します。実名、役職、プロフィールページ、専門領域を整理し、E-E-A-Tを補強する設計が必要です。
自社と顧客企業：Organization
BtoB事例ページでは、「自社」と「導入企業」の2つのOrganizationが登場します。ここを曖昧にすると、AIや検索エンジンが関係性を誤って理解する可能性があります。
自社は、サイト全体のブランド情報としてOrganizationで定義します。会社名、公式URL、ロゴ、問い合わせ先、SNS、創業年などを整理します。一方、顧客企業は事例記事の対象として、可能な範囲で業種、企業規模、地域、導入部門などを記述します。
ただし、顧客名を非公開にしている事例では、無理に実名を構造化データに入れてはいけません。「製造業A社」「従業員300名規模の部品メーカー」など、ページ上で公開している範囲と一致させることが大切です。
製品・サービス：Product、Service、SoftwareApplication
事例ページで紹介する自社サービスは、Product、Service、SaaSであればSoftwareApplicationとして定義できます。GoogleのProduct構造化データでは、価格、在庫、レビュー、配送などの情報が検索結果で活用される可能性があると説明されています。BtoB商材の場合はEC商品のように価格や在庫を出せないケースもありますが、製品・サービスの機能、対象業種、導入形態、提供範囲を整理することには意味があります。
特にBtoBでは、次のような情報が重要です。
- 対象業界
- 対応できる業務領域
- 導入形態
- 連携可能なシステム
- セキュリティ要件
- サポート体制
- 導入までの標準的な流れ
これらはページ本文にも明記し、JSON-LDではadditionalPropertyなどを使って補足する設計が考えられます。AI検索は、単なる商品名よりも「どの条件に合うサービスなのか」を読み取ろうとするため、機能や適合条件を明確にすることが重要です。
レビュー・証言：Review、Quotation
BtoB事例ページでは、顧客の声や担当者コメントが重要な社会的証明になります。導入前の課題、選定理由、導入後の変化、今後の期待などは、購買担当者が自社に置き換えて判断するための材料になります。
顧客の評価を構造化する場合は、ReviewやQuotationの活用を検討できます。Googleは、レビューや評価のマークアップについて、対象となるコンテンツやポリシーに沿った実装を求めています。特に、実在しないレビューや、ページ内容と関係のない評価を入れることは避けるべきです。
BtoBでは星評価を無理に使うよりも、実際のコメントを丁寧に掲載し、発言者の立場や企業属性を明示する方が自然です。たとえば「製造部門責任者」「情報システム部門」「経営企画担当」など、誰の視点なのかが分かると、読み手にもAIにも文脈が伝わりやすくなります。
複数エンティティは@idでつなぐ
事例ページには、記事、自社、顧客企業、サービス、レビュー、FAQ、パンくずリストなど、複数の要素が存在します。これらをばらばらに記述するのではなく、@idを使って相互に関連づけることが重要です。
たとえば、自社サービスに@idを付け、記事本文のaboutでそのサービスを参照します。顧客の声をReviewとして記述する場合も、どのサービスに対するレビューなのかを明示します。
{
"@type": "Article",
"@id": "https://example.com/case/a-company/#article",
"about": {
"@id": "https://example.com/service/dx-tool/#product"
}
}このように関連づけることで、「この記事は自社のこのサービスに関する導入事例である」という関係が明確になります。AI検索においては、単語単位ではなく、企業・製品・課題・成果の関係性が重要になるため、@idによる接続はGEO対策の基礎になります。
ゲートコンテンツやホワイトペーパーへの対応
BtoBサイトでは、詳細な導入事例やホワイトペーパーをフォーム入力後に提供することがあります。この場合、検索エンジンに見せる内容とユーザーに見せる内容が大きく異なると、クローキングと誤解されるリスクがあります。
Googleは、ペイウォールや登録制コンテンツについて、isAccessibleForFreeやhasPartを使って、どの部分が無料で、どの部分が制限されているのかを示す方法を案内しています。あわせて、cssSelectorにはクラスセレクタを使うなどの実装ルールも示されています。
事例ページでは、要約、課題、導入背景、成果の一部は公開し、詳細資料をフォーム後に提供する設計が現実的です。その場合も、公開本文と構造化データの内容を一致させ、隠している情報だけを過度にマークアップしないことが大切です。
実装後に確認すべきポイント
構造化データは、実装して終わりではありません。公開前後に検証し、運用の中で定期的に見直す必要があります。
まず、Googleのリッチリザルトテストで、対応するリッチリザルトの対象になっているか、エラーがないかを確認します。次にSearch ConsoleのURL検査ツールで、Googlebotがページを正しくクロールできているかを確認します。さらに、Schema.org Validatorを使い、Schema.orgの文法として問題がないかも確認しておくと安心です。
あわせて、Search Consoleで事例ページ群の表示回数、クリック数、CTR、検索クエリを定期的に見ます。構造化データの効果は即座に出るとは限りません。数週間から数カ月単位で、実装前後のページ群を比較する視点が必要です。Googleも、構造化データの効果測定では、Search Consoleのデータを使い、実装前後を比較する方法を案内しています。
よくある失敗例
BtoB事例ページの構造化データで多い失敗は、次の4つです。
1つ目は、本文にない情報をJSON-LDだけに入れることです。たとえば、ページ上では公開していない導入企業名や成果数値を、構造化データにだけ記述するのは避けるべきです。
2つ目は、スキーマタイプの選定が雑になることです。事例記事なのに求人情報としてマークアップしたり、サービス紹介なのにイベントとして扱ったりすると、ページ内容と構造化データが一致しなくなります。
3つ目は、顧客の声を過剰に装飾することです。実際には定性的なコメントしかないのに、根拠のない星評価や数値評価を付けると、信頼性を損ないます。
4つ目は、導入後に放置することです。サービス名、価格体系、対応業界、導入企業の状況が変わったのに古い情報が残っていると、ユーザー体験にも検索評価にも悪影響を与える可能性があります。
まとめ
BtoB事例ページの構造化データは、検索結果で目立つためだけの施策ではありません。自社、顧客、製品・サービス、導入背景、成果、レビューを機械が理解しやすい形で整理するための情報設計です。
AI検索時代には、ページの文章だけでなく、情報同士の関係性がますます重要になります。ArticleやTechArticleで事例記事を定義し、Organizationで自社と顧客を分け、ProductやServiceで対象サービスを明示し、ReviewやQuotationで顧客の声を補足する。この積み重ねが、AIに引用されやすく、購買担当者にも伝わりやすい事例ページにつながります。
ただし、構造化データは魔法のSEO施策ではありません。本文と一致していること、誤解を招かないこと、最新情報に保たれていること、テストと効果測定を続けることが前提です。BtoBマーケティングでは、事例ページを「読ませるコンテンツ」から「理解され、比較され、選ばれるデータ資産」へ進化させる視点が求められます。
コメント