「AIO対策として構造化データを実装してほしい」
そう指示を受けたものの、どのスキーマから手をつけるべきか、そもそも工数に見合うのか、判断がつかない。
そんな状況にいる方は少なくないはずです。ネット上には「実装すればAIに引用される」という記事が並びますが、2026年に入ってその前提を揺るがす調査結果が公開されました。
本記事では、構造化データのAIO実装について、最新の一次データを踏まえた「正しい期待値」から解説します。そのうえで、優先すべきスキーマをJSON-LDのコード例つきで示し、環境別の実装方法、検証手順、よくあるミスまでを整理します。読み終えるころには、上司やクライアントに「なぜやるのか」を説明できる根拠と、明日から着手できる実装リストが手元に残るはずです。
まずは自社のAI検索対策状況を無料で診断しませんか？
バクリ株式会社の「無料AIOアセスメント」では、ChatGPT・Gemini・Perplexityにおける自社の引用状況と改善ポイントを10分で可視化します。
【お知らせ】4月17日（金）に弊社代表荒川が書籍を発売しました！
AI時代を勝ち抜く最先端のノウハウをまとめた書籍『海外の先行事例に学ぶ AI検索最適化（AIO/AISEO/LLMO）実践ガイド』（著者：弊社代表取締役 荒川 大史）が、4月17日（金）よりKindleストアにて配信開始しました。
これからのビジネス戦略にぜひお役立てください！
目次
構造化データのAIO実装とは？先に結論から
コードの話に入る前に、この施策の立ち位置を確定させておきます。ここを誤ると、工数の配分を間違えます。
構造化データ（JSON-LD）とは？
構造化データとは、Webページの内容を検索エンジンやAIが機械的に理解できる形式で記述したものです。人間は「株式会社◯◯」という文字列を見れば企業名だと分かりますが、機械にとっては単なる文字の並びにすぎません。そこで「これは組織名です」「これは価格です」とラベルを付けて伝えるのが構造化データの役割です。
記述の共通言語がSchema.orgで、これはGoogle・Microsoft・Yahoo・Yandexが共同で策定した標準仕様です。そして、その仕様を書き表す形式としてGoogleが推奨しているのがJSON-LDです。HTMLの<head>内などにスクリプトとしてまとめて記述できるため、本文のマークアップを汚さずに済むという実装上の利点があります。
AIOにおける構造化データの位置づけ
ここで用語を整理しておきます。AIOとは、主な対象がAI Overview＋各種生成AI（AI検索全般）、目的はAI Overview対策とLLM対策（その他AI対策）を合わせた総称であり、AI検索全体で引用・紹介される状態をつくることを指します。
このゴールに対して、構造化データは「情報の正確な伝達」を担当します。AIが自社を説明するとき、社名・事業内容・所在地・著者情報を誤解なく認識できているか。その土台をつくる作業です。逆に言えば、構造化データはコンテンツの中身そのものを良くするわけではありません。ここが期待値の分かれ目になります。
「引用が増える施策」ではなく「誤解されないための施策」
結論を先に置きます。構造化データのAIO実装は、AI引用を増やす攻めの施策ではなく、機械に誤解されないための守りの施策です。
この位置づけは、次章で扱う一次データとGoogleの公式見解の両方から導かれます。実装しないことによるマイナスは存在しますが、実装したことによるプラスは限定的——そう理解しておくと、工数配分を間違えません。実装は必要です。ただし、そこに全予算を投じるべき施策ではない、ということです。
【最新データ】構造化データはAI引用を増やすのか
もっとも判断に迷うポイントを、公開されている一次データで検証します。
Ahrefs調査：JSON-LD追加後もAI引用は動かなかった
2026年5月、AhrefsがJSON-LDスキーマの追加とAI引用の因果関係を検証した調査を公開しました。設計は、JSON-LDを追加した1,885ページを追跡し、追加前の引用水準が近い約4,000ページを対照群として比較する差分の差分（difference-in-differences）分析です。
結果は次のとおりでした。
| プラットフォーム | 変化 | 統計的有意性 |
|---|---|---|
| Google AI Overviews | −4.6% | 有意 |
| Google AIモード | +2.4% | 有意差なし |
| ChatGPT | +2.2% | 有意差なし |
いずれのプラットフォームでも、スキーマ追加による有意な引用増加は確認されませんでした。
ただし、この結果を「構造化データは無意味」と読むのは誤りです。Ahrefs自身が3つの重要な留保を付けています。第1に、AI Overviewsの減少については、対象群・対照群ともにスキーマ追加前から下降傾向にあったため、減少をスキーマに帰属させることはできないとしています。第2に、調査対象はすでにAIに大量に引用されていたページ（実装前の時点でAI Overviewsの引用が100件以上）に限定されています。第3に、測定期間はスキーマ追加の前後30日間です。
つまりこの調査が示したのは、「すでに認知され引用されているページに、あとからスキーマを足しても上乗せは起きない」という事実です。まったく引用されていないページが実装によってどう変わるかは、この設計では検証されていません。
相関と因果の混同に注意する
業界でよく引用されるデータに、「AIに引用されているページの53%がスキーマを実装しており、これは引用されていないページの約3倍」というものがあります。Ahrefsが600万URLを分析した結果です。
しかしこれは相関にすぎません。スキーマを実装しているサイトは、そもそも予算と技術リソースがあり、コンテンツの質や運用体制も整っている傾向があります。引用の理由がスキーマなのか、それとも背後にある総合的な運用力なのかは、この数字だけでは切り分けられません。むしろ後者だと考えるほうが自然でしょう。
Googleの公式見解はどうなっているか
Googleは、AI OverviewsやAIモードのために特別なスキーマは必要ないという立場を明確にしています。生成AI機能への表示は、従来の検索のベストプラクティスの延長線上にあるという説明です。
一方で、Googleの検索リレーションズチームは、サポート対象のスキーマタイプは引き続き使う価値があるとも述べています。「AI引用のために特別な実装は不要」と「サポート対象のスキーマには意味がある」は矛盾しません。前者はAI固有の裏技を否定しており、後者は検索全体における基盤としての価値を認めている、と読むのが妥当です。
それでも実装する3つの理由
以上を踏まえたうえで、私たちは実装を推奨しています。理由は3つです。
第1に、エンティティの誤認を防げること。同名企業や類似サービスが存在する場合、機械が自社を正しく識別できるかどうかは死活問題です。Organizationスキーマで公式サイト・SNS・ロゴを明示しておくことは、その識別の助けになります。
第2に、実装コストが低いこと。主要なスキーマはテンプレート化でき、一度仕組みを作れば追加コストはほぼ発生しません。効果が限定的でも、投じる工数が小さければ実装しない理由になりません。
第3に、副作用がほぼないこと。ただし、本文と矛盾する内容をマークアップした場合は別です。この点は後述します。
📥 【CTA②・中盤／ハードル中】 「自社の場合、どのスキーマにどれだけ工数をかけるべきか」——実装優先度の判断シートと、実際の設計手順をまとめた資料をご用意しています。 → 支援資料をダウンロード（[資料DLURL]）
構造化データの実装前に知るべき2026年の変更点
過去の記事を参考にすると、すでに廃止された施策を実装してしまうおそれがあります。最新の状況を押さえておきましょう。
FAQリッチリザルトは2026年5月に廃止された
長年「AIO対策の定番」として推奨されてきたFAQPageスキーマですが、リッチリザルトとしての役割は終了しました。Googleは2026年5月7日以降、よくある質問のリッチリザルトをGoogle検索に表示しないと発表しています。関連機能の廃止は3段階のスケジュールで進みます。
| 時期 | 内容 |
|---|---|
| 2026年5月7日 | 検索結果でのFAQリッチリザルト表示が終了 |
| 2026年6月 | 検索での見え方・リッチリザルトレポート・リッチリザルトテストのサポート終了 |
| 2026年8月 | Search Console APIでのサポート終了 |
なお、この変更は突然のものではありません。2019年5月に導入されたFAQリッチリザルトは、2023年8月の時点で表示対象が政府機関・保健機関などの権威あるサイトに限定されており、一般企業サイトでは以前から表示されにくい状態が続いていました。今回はその残りが整理された、という位置づけです。
FAQPageスキーマは削除すべきか
結論から言えば、急いで削除する必要はありません。Googleは公式ドキュメントで、FAQPage構造化データを積極的に削除する必要はないと明記しています。使用されていない構造化データが検索に問題を引き起こすことはない、という説明です。
ここで重要なのは、FAQというコンテンツ形式の価値と、FAQリッチリザルトの価値を切り分けることです。検索結果でのリッチリザルト表示という「見た目のメリット」は消えましたが、質問と回答が1対1で対応した構造は、AIが答えを抜き出す単位として依然として有効です。狙いを「SERPの占有」から「AIに引用されること」へ切り替えれば、FAQセクション自体は引き続き作るべきコンテンツです。
廃止されたその他のスキーマにも注意する
同様の整理は他のスキーマでも進んでいます。HowToリッチリザルトはデスクトップ限定となった後に廃止され、Course Info、Claim Review、Estimated Salaryといったタイプも2025年に終了しています。
実装前には必ず、Google検索セントラルの該当ドキュメントで現在のサポート状況を確認してください。2024年以前に書かれた解説記事をそのまま参考にすると、すでに意味を失った実装に工数を使うことになります。
AIO実装で優先すべきスキーマ【優先度順】
ここからが実務パートです。優先度の高い順に、JSON-LDのコード例つきで解説します。すべてを一度に実装する必要はありません。上から順に着手してください。
優先度①：Organization｜自社が何者かを定義する
AIO実装で最初に入れるべきスキーマです。AIが自社を説明するときの土台になります。トップページまたは会社概要ページに設置してください。
{
“@context”: “https://schema.org”,
“@type”: “Organization”,
“name”: “バクリ株式会社”,
“alternateName”: “BAKURI Inc.”,
“url”: “https://www.bakuri.co.jp/”,
“logo”: “https://www.bakuri.co.jp/images/logo.png”,
“description”: “AIO/LLMO対策コンサルティングとWebマーケティングのインハウス化支援を提供するマーケティング会社。”,
“sameAs”: [
“https://x.com/example”,
“https://www.linkedin.com/company/example”
]
}
ポイントはsameAsです。公式SNSや外部プロフィールのURLを列挙することで、Web上に散らばった情報が同一の組織を指していることを機械に伝えられます。エンティティの分断を防ぐうえで、もっとも効く記述です。
優先度②：Article｜記事の著者と更新日を明示する
コンテンツを持つサイトなら、次に実装すべきはArticleです。E-E-A-T（経験・専門性・権威性・信頼性）の観点でも、著者と日付の明示は重要度が上がっています。
{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “構造化データのAIO実装ガイド”,
“author”: {
“@type”: “Person”,
“name”: “山田 太郎”,
“url”: “https://www.example.com/authors/yamada/”
},
“publisher”: {
“@type”: “Organization”,
“name”: “バクリ株式会社”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://www.bakuri.co.jp/images/logo.png”
}
},
“datePublished”: “2026-08-18”,
“dateModified”: “2026-08-18”
}
dateModifiedは、記事を更新するたびに実際の更新日へ変えてください。中身を変えていないのに日付だけ新しくする運用は、信頼性を損ないます。
優先度③：BreadcrumbList｜サイト内の位置関係を伝える
パンくずリストのマークアップです。そのページがサイト全体のどこに位置づけられるかを示すことで、トピックの階層構造が機械に伝わりやすくなります。
{
“@context”: “https://schema.org”,
“@type”: “BreadcrumbList”,
“itemListElement”: [
{
“@type”: “ListItem”,
“position”: 1,
“name”: “ホーム”,
“item”: “https://www.example.com/”
},
{
“@type”: “ListItem”,
“position”: 2,
“name”: “AIO対策”,
“item”: “https://www.example.com/aio/”
},
{
“@type”: “ListItem”,
“position”: 3,
“name”: “構造化データのAIO実装”
}
]
}
最後の階層（現在のページ）にはitemを付けないのが仕様です。テンプレートで自動生成する場合、ここを間違えるケースが多いので確認してください。
優先度④：Product・LocalBusiness｜業種に応じて追加する
ECサイトならProduct、店舗ビジネスならLocalBusinessを追加します。価格・在庫・営業時間といった情報は、AIが回答を生成する際に参照されうる具体的な事実です。
ただし注意点があります。存在しないレビューや実態のない評価をマークアップするのは、ガイドライン違反にあたります。実データのみを使ってください。また、価格や在庫を更新したのにスキーマが古いままだと、AIが古い情報を引用し続けることになります。自動生成の仕組みを整えておくことが前提です。
優先度⑤：Person｜著者の専門性を裏づける
著者ページを持つメディアなら、Personスキーマで経歴・所属・保有資格を記述します。誰が書いたのかという情報は、AI検索において情報源の信頼性を判断する材料のひとつです。
Articleのauthorから著者ページへリンクし、その著者ページにPersonスキーマを置く。この2段構えにすることで、著者という存在が独立したエンティティとして認識されやすくなります。
構造化データにおけるJSON-LDの実装方法【環境別】
書き方が分かっても、どこに置くかで迷う方が多いパートです。
WordPressの場合
多くの場合、プラグインで完結します。SEO系プラグインの多くはOrganization・Article・BreadcrumbListを自動生成する機能を備えているため、まずは既存プラグインの設定画面を確認してください。すでに出力されているのに手動で追加すると、重複してエラーになります。
プラグインでカバーできない項目は、テーマのheader.phpに直接記述するか、カスタムフィールドと連携させる方法があります。ただしテーマを直接編集する場合は、アップデートで上書きされないよう子テーマで作業してください。
Next.js・自社CMSの場合
コンポーネント側でJSON-LDを生成し、<script type=”application/ld+json”>として出力するのが基本です。ページの種類ごとにスキーマを出し分けられるよう、テンプレート単位で設計しておくと運用が楽になります。
重要なのは、CMSの入力値とスキーマの値を紐づけることです。記事タイトルや更新日を手打ちで管理すると、必ずどこかで実態とずれます。データベースの値を参照する形にしておいてください。
タグマネージャー経由で実装する場合の注意
Googleタグマネージャーで構造化データを挿入する方法もあり、開発リソースが確保できない場合の選択肢にはなります。ただしJavaScriptで後から挿入する形になるため、レンダリングのタイミングによっては正しく認識されないリスクがあります。
恒久的な実装としては、サーバー側で出力する方法を推奨します。タグマネージャーは、あくまで暫定対応と位置づけてください。
構造化データの実装後の検証と運用のやり方
書いて終わりにすると、気づかないうちにエラーが蓄積します。
リッチリザルトテストで確認する
Googleのリッチリザルトテスト（search.google.com/test/rich-results）にURLを入力すると、Googleが認識しているスキーマと、リッチリザルトの対象になるかどうかを確認できます。Google固有の要件に沿った検証ができるのが特徴です。
なお前述のとおり、FAQリッチリザルトについては2026年6月にこのツールでのサポートが終了しています。ツール上に表示されないことをもって「実装ミス」と判断しないよう注意してください。
Schema Markup Validatorで仕様準拠を確認する
もう1つ、Schema.orgが提供するSchema Markup Validator（validator.schema.org）も併用します。こちらはGoogle固有の要件ではなく、Schema.orgの仕様に準拠しているかを検証するツールです。
リッチリザルトの対象外であっても、仕様として正しく書けているかはこちらで確認できます。AI検索を含めた広い意味での機械可読性を担保したいなら、両方を通しておくのが標準です。
Search Consoleで継続的に監視する
一度の検証で終わらせず、Search Consoleの拡張レポートで定期的にエラーを確認してください。テンプレートの改修やCMSの仕様変更で、ある日突然エラーが大量発生することがあります。
情報の陳腐化を防ぐ運用を組む
構造化データの最大のリスクは、実装ミスよりも放置です。移転した住所、変わった価格、退職した著者。実態とずれた情報がマークアップされたまま残ると、AIはそれを正しい情報として扱い続けます。
四半期に一度、Organization・Product・LocalBusinessの内容を実態と突き合わせる運用を決めておきましょう。
構造化データのよくある実装ミスと注意点
支援の現場で頻出する3つのパターンです。
ミス①：本文に存在しない情報をマークアップする
構造化データは、ページに表示されている内容を機械可読にするための仕組みです。本文に書いていない情報をスキーマだけに記述するのは、ガイドライン上も推奨されません。
「本文には載せたくないがAIには伝えたい」という発想が出てきたら、それは本文の設計を見直すサインです。まず本文に書き、そのうえでマークアップしてください。
ミス②：実データでない評価・レビューを記述する
自作のレビューや、根拠のない評価数をProductスキーマに記述するのは明確な違反行為です。ペナルティの対象になりますし、そもそもユーザーを欺く行為にあたります。実際に取得したレビューのみを使用してください。
ミス③：表記ゆれでエンティティが分断される
「株式会社◯◯」「◯◯株式会社」「◯◯」——サイト内やスキーマ内で社名の表記が揺れていると、機械は別々の存在として扱う可能性があります。
OrganizationのnameとalternateNameを定義したら、サイト全体の表記をそれに揃えてください。地味な作業ですが、エンティティ整備という観点では構造化データの記述そのものより効きます。
構造化データの実装は内製すべきか外注すべきか
体制の話で締めます。
工程ごとに切り分けて判断する
| 工程 | 内製向き | 外注向き |
|---|---|---|
| スキーマ設計・優先度づけ | △（最新仕様の把握が必要） | ◯（廃止動向を追う必要がある領域） |
| テンプレートへの実装 | ◯（開発リソースがあれば） | ◯（初回構築は外注が確実） |
| 記事ごとの値の入力 | ◯（運用に組み込める） | △（都度依頼はコスト過多） |
| 検証・エラー対応 | ◯（ツールで完結） | △ |
| 仕様変更の追跡 | △ | ◯ |
初回の設計と実装は外部の知見を借り、以降の運用は内製に引き取る。これがもっとも費用対効果の高い形です。構造化データは一度仕組みを作れば追加コストが小さい施策なので、外注を継続する必然性は高くありません。
支援会社を選ぶときの視点
確認すべきは、廃止・変更の動向を一次情報で追えているかです。FAQリッチリザルトの廃止に触れずにFAQPageの実装を勧めてくる提案書が出てきたら、情報が更新されていない可能性があります。
バクリでは、AI検索での引用状況を可視化したうえで実装の優先度を設計し、最終的にクライアント自身で運用できる状態までを一貫して支援しています。
AIOにおける構造化データの実装に関するよくある質問（FAQ）
Q1. AI引用が増えないなら、構造化データは実装しなくていいのでは？
A. 実装は推奨します。引用を増やす効果は確認されていませんが、企業や著者の情報を機械に誤解なく伝える土台としての価値は残ります。実装コストが低く副作用も小さいため、やらない理由のほうが見つかりにくい施策です。
Q2. FAQPageスキーマは削除すべきですか？
A. 削除は不要です。Googleは公式ドキュメントで、FAQPage構造化データを積極的に削除する必要はないと明記しています。リッチリザルトは表示されなくなりましたが、FAQという形式自体はAIが答えを抜き出す単位として引き続き有効です。
Q3. スキーマは何種類実装すべきですか？
A. まずはOrganization・Article・BreadcrumbListの3つで十分です。そのうえで業種に応じてProductやLocalBusinessを追加してください。種類を増やすこと自体が目的化すると、更新されない情報が増えるだけです。
Q4. 1ページに複数のスキーマを入れてもいいですか？
A. 種類が異なれば問題ありません。ArticleとBreadcrumbListを併記するのは一般的です。ただし同じタイプを重複して配置するとエラーになるため、プラグインとテーマの二重出力には注意してください。
Q5. 実装の効果はどう測ればいいですか？
A. 構造化データ単体での引用増加を測るのは困難です。Search Consoleの拡張レポートでエラーがない状態を維持しつつ、AI検索での露出はコンテンツ改修も含めた総合的な施策として評価するのが現実的です。
まとめ｜構造化データは「守りの土台」として実装する
構造化データのAIO実装について、期待値・優先順位・実装方法・検証手順を見てきました。整理すると、話はきわめてシンプルです。実装すればAIに引用される、という因果関係は現時点の公開データでは確認されていません。Googleも生成AI機能のために特別なスキーマは不要としています。それでも、企業や著者が何者かを機械に誤解なく伝える土台として、実装する価値は変わりません。
2026年に起きた変化は、この位置づけをより鮮明にしました。FAQリッチリザルトの廃止が示したのは、「コードを足してSERPの表示面積を稼ぐ」という戦略の終わりです。Ahrefsの調査が示したのは、「コードを足せば引用される」という期待の空振りです。どちらも、構造化データの価値を否定したわけではありません。否定されたのは、構造化データに過剰な役割を負わせる考え方のほうです。
ですから、進め方はこうなります。Organization・Article・BreadcrumbListを確実に実装し、業種に応じて必要なものを足す。実装した内容を実態と一致させ続ける。そこまでやったら、残りの工数はコンテンツそのものに振り向ける。AIが引用するかどうかを最終的に決めるのは、そのページが本当に良い答えになっているかどうかだからです。土台は土台として静かに整え、勝負は中身でつけるのが2026年時点での現実的な結論です。
まずは自社のAI検索対策状況を無料で診断しませんか？
バクリ株式会社の「無料AIOアセスメント」では、ChatGPT・Gemini・Perplexityにおける自社の引用状況と改善ポイントを10分で可視化します。
【お知らせ】4月17日（金）に弊社代表荒川が書籍を発売しました！
AI時代を勝ち抜く最先端のノウハウをまとめた書籍『海外の先行事例に学ぶ AI検索最適化（AIO/AISEO/LLMO）実践ガイド』（著者：弊社代表取締役 荒川 大史）が、4月17日（金）よりKindleストアにて配信開始しました。
これからのビジネス戦略にぜひお役立てください！
