構造化データとは 非エンジニアでもわかる実装ガイド

この記事の前提として、AI検索対策の実行順序と優先順位もあわせてご覧ください。構造化データは、そこで紹介した「技術的基盤の整備」に含まれる施策の1つです。

「構造化データを入れましょう」と言われても、何のことか分からない

制作会社やコンサルタントから「構造化データを実装しましょう」と提案されて、言葉の意味がよく分からないまま話を進めてしまった、という相談をよく受けます。ややこしいことに、「構造化データ」という言葉は、ビッグデータ分析の世界（Excelのように行と列で整理されたデータ、という意味）でも使われており、検索エンジン向けの意味とは別物です。この記事で扱うのは、後者、つまりWebサイトの情報を検索エンジンやAIに正確に伝えるための技術としての構造化データです。非エンジニアの方にも分かるよう、仕組みから実装、よくある失敗まで整理します。

構造化データは、専門知識が無くても手を出せます。仕組みを理解し、優先順位を決め、無料のツールで検証する、という一連の流れさえ押さえれば、非エンジニアの担当者でも安全に運用できます。この記事では、その一連の流れを順番に解説します。 Web制作の知識が全く無くても、この記事を読み終える頃には、制作会社との会話で使われる用語の意味と、自社が何を用意すればよいかが分かる状態になっているはずです。

構造化データとは、人間とAIの理解のズレを埋める翻訳機

Webページをブラウザで見るとき、人間は視覚的なデザインや文脈から情報を瞬時に読み取れます。ページに「山田太郎」と書かれていれば、それが人名だと直感的に分かります。しかし、検索エンジンのクローラーや生成AIのプログラムにとって、Webページは無機質なHTMLタグと文字列の集合体に過ぎません。「山田太郎」が著者名なのか、企業名なのか、機械は正確に判別できないのです。 同様に、ページ上に「10,000円」と書かれていても、それが商品の価格なのか、送料なのか、キャンペーンの割引額なのか、機械は文脈だけから正確に判断できません。この「人間の直感的な理解」と「機械の文字列処理」の間にあるズレを埋める技術が、構造化データです。実装することで「この文字列は著者名である」「この数字は価格である」という意味を、機械に対して確定的な事実として伝えられます。 レシピサイトで「90分」という表記があれば、人間は調理時間だと直感的に理解できますが、機械にとっては単なる数字の並びです。構造化データで「これは調理時間である」と明示して初めて、機械はその数字の意味を確定できます。

Schema.org（辞書）とJSON-LD（文法）

実装にあたって欠かせないのが「Schema.org」と「JSON-LD」という2つの要素です。それぞれ「辞書」と「文法」の関係にたとえられます。

Schema.orgは検索エンジン各社が共同で作った共通の辞書

Schema.orgは、Google・Microsoft（Bing）・Yahoo!等が共同で策定した共通の規格です。各検索エンジンが独自のルールを求めていたら、サイト運営者の負担は非常に大きくなっていたはずです。そこで、記事（Article）、企業情報（Organization）、店舗情報（LocalBusiness）、よくある質問（FAQPage）など、数百種類の「型」を定義した世界共通の辞書として作られました。 この辞書のおかげで、日本のサイトも海外のサイトも、同じルールで検索エンジンに情報を伝えられます。逆に言えば、Schema.orgに定義されていない独自の型を勝手に作っても、検索エンジンやAIには理解されません。 自社で「うちの業界ならではの型」を作りたくなることもありますが、まずはSchema.orgに既存の型で近いものがないかを探すのが先決です。ほとんどの業種は、既存の型の組み合わせで表現できます。

JSON-LDはGoogleが最も推奨する記述形式

このSchema.orgの辞書を実際のページにどう書き込むかを定めた形式には、主に「Microdata」「RDFa」「JSON-LD」の3種類があります。この中で現在Googleが公式に最も推奨しているのがJSON-LDです。従来のMicrodataやRDFaは、人間が見るためのHTMLタグそのものに直接書き込む必要があり、デザイン変更のたびに構造化データが壊れるリスクがありました。対してJSON-LDは、HTML本文とは完全に切り離された<script>タグの中に独立して記述します。既存のデザインを変更せずに導入でき、記述ミスがあっても画面表示はそのまま保たれます。非エンジニアが安全に実装できる形式として、中小企業でも広く採用されています。 制作会社によっては今もMicrodataで実装を進めるケースがありますが、保守性の観点からは、新規にサイトを作る場合もリニューアルする場合も、JSON-LDへの統一をおすすめします。

Google検索とAI検索、それぞれでの扱われ方

構造化データの役割は、検索環境の変化とともに進化しています。

従来のSEOでの役割：リッチリザルトによる視認性向上

歴史的に、構造化データを実装する主な動機は「リッチリザルト」の獲得でした。検索結果に星評価や画像、パンくずリストなどが表示され、視覚的な占有面積が増えることで、クリック率の向上につながるとされてきました。ただし、2026年5月7日、Googleは「FAQリッチリザルト」（よくある質問のアコーディオン表示）のサポートを検索結果で終了しました。同年6月にはサーチコンソールのレポート機能からもFAQの項目が削除されています。この機能を理由にFAQPageの構造化データを削除するのは早計です。次に説明する生成AI検索での役割は、むしろ強まっているためです。 「表示されなくなったなら意味がない」と考えて構造化データを削除してしまう判断は、ここでは誤りです。検索結果の見た目という表面的な恩恵が無くなっただけで、機械が情報を理解する土台としての役割は変わっていません。

生成AI検索での価値：RAGを補助する「カンニングペーパー」

ChatGPTのWeb検索機能やPerplexity、Google AI Overviewsは、「RAG（検索拡張生成）」という仕組みで回答を作っています。ユーザーの質問に関連するWebページをリアルタイムに検索・抽出し、その情報をもとに回答を生成する仕組みです。AIは人間のように文脈を完璧に読み取れるわけではないため、長文のHTMLから「どれが提供サービスか」「どれが正確な価格か」を推論するには計算負荷がかかります。構造化データが実装されたページは、AIにとって情報が整理された「カンニングペーパー」として機能し、複雑な推論なしに確実な事実を抽出できるため、優先的な情報源として採用されやすくなります。Ahrefsが約100万件のAI Overviewsを分析した調査によると、AI Overviewsに引用されたページの76.1%が、Google検索で上位10位以内にランクインしていたページでした。検索エンジンでの評価という土台があってこそ、AIにも参照されるという関係が、データからも裏付けられています。

この関係は、「AI検索に対応すればGoogle検索の順位は関係なくなる」という誤解を否定する根拠にもなります。AIは既存の検索インデックスを土台に情報を取得しているため、検索エンジンからの評価を得られていないページは、そもそもAIの参照対象にすら入りません。構造化データの実装は、検索エンジン向けの対策とAI検索向けの対策を、同時に進められる数少ない施策の1つです。

中小企業が優先的に実装すべき4種類

Schema.orgには数百種類の型がありますが、全てを実装する必要はありません。ビジネスへの影響が大きく、実装難易度が比較的低い4種類に絞って着手します。

スキーマ	目的	優先度
FAQPage	AIへの直接的な回答パーツの提供、疑問解決	極めて高い
LocalBusiness	ローカル検索（地図検索）での対応強化	実店舗があれば高い
Article	専門性（E-E-A-T）の担保、著者情報の明示	ブログ運営時は高い
Organization	企業情報の定義、ブランドの同一性の認識	基礎設定として必須

FAQPage：AIが最も引用しやすい型

生成AIは質問に対する回答を作るシステムなので、サイト側が「質問」と「回答」のペアを明示的に保有していると、AIはそれをそのまま回答パーツとして引用しやすくなります。 逆に、FAQらしき見た目のアコーディオンをHTMLとCSSだけで作り、構造化データを実装していないケースも多く見られます。人間の目には同じFAQに見えても、構造化データが無ければAIにとってはただの文章の羅列です。営業やコールセンターが実際に受ける「生の質問」を元に作成することが有効です。回答は3〜5行程度で簡潔に完結させます。 質問文はユーザーが実際に検索・入力しそうな自然な言い回しにし、キーワードを機械的に詰め込んだ不自然な文にしないことがポイントです。

要素	役割
@context	Schema.orgの辞書を使うことの宣言
@type	データの種類の指定（大文字小文字を区別する）
mainEntity	質問と回答のペアを入れ子で記述する部分

LocalBusiness：地図検索での優位性

飲食店、美容院、クリニック、地域の工務店など、実店舗や対応エリアを持つ企業に必須です。住所・電話番号・営業時間を正確に記述し、Googleビジネスプロフィールに登録している情報と完全に一致させることが最も重要です。情報の不一致は、検索エンジンやAIに「この店舗情報は信頼できない」というシグナルを送ってしまいます。 また、LocalBusinessという汎用的な型だけでなく、可能であればRestaurant（飲食店）やDentist（歯科医院）など、より具体的な業種のサブタイプを指定することで、AIが業種を正確に認識しやすくなります。

Article：専門性と鮮度の担保

ブログやコラムで情報発信をしている企業に適しています。著者（Author）と公開日・更新日を明示することで、情報の鮮度と責任の所在を機械に伝達できます。日付の記述は「2026年8月28日」ではなく「2026-08-28」という国際規格（ISO 8601形式）で書く必要があります。日本語表記のまま記述すると、検索エンジンが読み取れずエラーになります。

Organization：企業そのものの定義

コーポレートサイトのトップページや会社概要ページに実装します。企業名、ロゴ画像のURLに加えて、sameAsという項目を使い、自社の公式SNSアカウントのURLを紐付けることが重要です。これにより「これらのアカウントとこのサイトは同一のブランドである」という関連性を、AIに正確に認識させられます。 Organizationは1サイトに1つだけ実装するのが基本です。複数のページに重複して記述すると、AIがどれを正しい企業情報として扱えばよいか判断できなくなり、逆効果になることがあります。

実装しても効果が出ないケースと、よくある間違い

構造化データはコードを貼り付ければ魔法のように効果が出るものではありません。実装を誤ると、無視されるだけでなく、サイト全体の評価を下げるリスクもあります。

【重要】2026年8月からの「二重エスケープ」問題

2026年8月21日、Googleは構造化データを読み取る処理（パーサー）の仕様を変更しました。JSONの国際規格であるRFC 8259に合わせるため、HTMLの特殊文字を元に戻す処理（アンエスケープ）を、これまでの2回から1回のみに変更したのです。WordPress等のCMSやプラグインが安全性のために自動でエスケープ処理をした結果、別の処理が重ねてもう一度エスケープしてしまう「二重エスケープ」が起きることがあります。これまでのGoogleは、この二重エスケープを見つけると気を利かせて自動修正していましたが、2026年8月21日以降、この自動修正が廃止されました。例えば社名に「&」が含まれる場合、二重エスケープが起きていると、正しい社名がAIに伝わらなくなります。厄介なのは、ブラウザでの見た目には一切崩れが現れないことです。JSON-LD内の特殊文字は、テストツールで実際の出力結果を確認する習慣をつけてください。

この仕様変更が厄介なのは、多くのサイト運営者が「自分のサイトには関係ない」と思い込んでしまう点です。社名やサービス名に「&」「’」「”」といった記号が一切含まれていなければ影響はありませんが、少しでも該当する文字があれば、ある日突然AIに正しい情報が伝わらなくなるという形で問題が表面化します。特に、WordPressのテーマやプラグインを更新した直後は、意図せずエスケープ処理の挙動が変わることがあるため、更新のたびにテストツールで確認する習慣が有効です。 サイト内に「株式会社A&B」のような記号を含む固有名詞が1つでもあれば、自社にも関わる話です。一度リストアップし、テストツールで実際の出力を確認しておくことをおすすめします。

ページ上に存在しない情報を書く

最も重篤なガイドライン違反が、Webページ上に表示されていない情報を構造化データの中だけに書くことです。ページ上のどこにもレビューの星評価が無いのに、構造化データにだけ「星5つ」と仕込む行為は、検索エンジンを欺くスパムと見なされます。同様に、実際には提供していないサービスをFAQPageの回答に含めることも、同じ理由で避けるべきです。構造化データの内容は、必ずブラウザ上で見えるコンテンツと一致していなければなりません。

文法エラーと必須プロパティの欠落

JSON-LDはJSON形式というプログラミング言語の一種のため、厳密な文法ルールがあります。カンマの付け忘れ、クォーテーションの閉じ忘れ、最後の要素に余分なカンマを付けてしまう「トレイリングカンマ」といった些細なミスが1つあるだけで、コード全体が解析不能になります。また@typeの値は大文字小文字を厳密に区別します。「article」ではなく「Article」、「faqpage」ではなく「FAQPage」と正確に記述する必要があります。 さらに、各スキーマにはGoogleが指定する必須プロパティがあり、これが欠けているとエラーとして扱われます。例えばFAQPageであれば質問（name）と回答（text）、Articleであれば見出し（headline）と公開日（datePublished）が該当します。

FAQPageの実装コード例

実際にどのようなコードになるのか、非エンジニアの方が制作会社とやり取りする際のイメージとして、基本形を示します。

記述	意味
“@context”: “https://schema.org”	Schema.orgの辞書を使うという宣言
“@type”: “FAQPage”	このデータはFAQページであるという指定
“name”: “質問文”	ユーザーが実際に聞きそうな質問
“text”: “回答文”	その質問への簡潔な回答

制作会社に依頼する場合は、コードそのものを理解する必要はありません。ただし「どのページに」「どの質問と回答を」構造化データにするかは、現場を知る自社側で用意した方が、AIに引用されやすい自然な内容になります。実装は外部に任せても、質問と回答のリストは自社で作る、という分担が現実的です。

業種別に見る実装の始め方

優先すべきスキーマは、業種によって多少異なります。

実店舗を持つ業種

クリニックのLLMO対策や工務店・リフォーム会社のLLMO対策のように、実店舗や対応エリアを持つ業種は、LocalBusinessスキーマの優先度が最も高くなります。Googleビジネスプロフィールとの情報の一致を、他のどの施策よりも先に確認してください。

比較検討が長い高額商材

不動産会社のLLMO対策のように検討期間が長い業種は、FAQPageの充実度が特に効いてきます。物件の条件や契約の流れなど、検討段階で生まれる疑問をあらかじめ拾っておくことで、AIが回答の材料として引用しやすくなります。 物件そのもののFAQだけでなく、「仲介手数料はいくらか」「内見からどのくらいで契約できるか」といった、意思決定の周辺にある疑問まで拾うと、より広い検討フェーズのプロンプトに対応できます。

専門性の高い記事コンテンツを持つ業種

士業のLLMO対策のように、専門的なコラムで情報発信をしている業種は、Articleスキーマと著者情報の明示が信頼性の担保に直結します。有資格者本人が執筆者として明記されているだけで、匿名の一般記事との差別化になります。 監修者と執筆者が別の場合は、両方の役割をArticleスキーマ内で書き分けることも可能です。誰が書き、誰が専門的な観点で確認したのかを明確にするほど、信頼性のシグナルは強くなります。

実装後の検証方法

構造化データは「入れて終わり」ではありません。CMSのアップデート等で、気付かないうちにデータが壊れることがあります。 実装した直後だけでなく、テーマやプラグインを更新したタイミングでも、意図せず構造化データが壊れていないかを確認する習慣が必要です。

ツール	確認できること	使うタイミング
Google リッチリザルト テスト	Googleの要件を満たしているか	実装直後・修正直後
Schema Markup Validator	Schema.orgの国際的な文法ルールに違反していないか	Google対象外のスキーマも含めた広範なチェック時
Google Search Console	サイト全体でのエラーを一覧で把握	月1回程度の定期点検

特にSearch Consoleの「拡張」レポートは、サイト全体を定点観測するために欠かせません。赤色のエラーが出た場合、Googleがデータを正しく読み込めていない状態です。エラーメッセージに従って修正し、「修正を検証」をリクエストするところまでが1セットの作業になります。

非エンジニアが安全に実装する方法

コードの文法エラーやエスケープのミスを防ぐため、ゼロから手書きすることはおすすめしません。フォームに企業名やFAQの質問・回答を入力するだけで、文法的に正しいJSON-LDコードを生成してくれる無料ツールが複数公開されています。生成したコードをリッチリザルトテストで確認したうえでCMSに貼り付ける、という運用を標準化すれば、実装の安全性は大きく高まります。

よくある質問（FAQ）

Q. 構造化データと非構造化データは同じものですか？

別のものです。非構造化データはビッグデータ分析の分野で使われる用語で、画像や音声など、行と列に整理されていないデータ全般を指します。この記事で扱う構造化データは、Webページの情報を検索エンジンやAIに伝えるためのマークアップ技術であり、まったく異なる概念です。

Q. 構造化データを入れると検索順位は上がりますか？

直接的な順位上昇要因ではありません。検索エンジンがコンテンツの内容を正確に理解する助けとなり、間接的にクリック率やAIからの引用率へ良い影響を与える技術です。

Q. JSON-LDと他の形式（Microdata・RDFa）はどちらを使うべきですか？

Googleが公式に最も推奨しているのはJSON-LDです。HTML本文と分離して記述できるため保守性が高く、非エンジニアが運用するサイトに向いています。

Q. FAQリッチリザルトが廃止されたなら、FAQPageは不要ですか？

不要ではありません。検索結果での表示という「見た目の恩恵」は無くなりましたが、AI Overviews・ChatGPT・Perplexity等が情報を理解するための土台としての役割は、むしろ重要性が増しています。

Q. 全てのページに構造化データを入れるべきですか？

優先順位を付けるべきです。まずはトップページのOrganization、主要なサービスページのFAQPage、実店舗があればLocalBusinessから着手し、記事コンテンツにはArticleを順次追加していく進め方が現実的です。

Q. 実装は自社でもできますか？

無料の生成ツールとテストツールを使えば、非エンジニアでも実装可能です。ただし複数のスキーマを1ページに統合する場合や、大規模なサイトへの一括実装は、専門知識のある担当者に依頼した方が安全です。 迷ったときの判断基準は、「間違えたときにどれだけ影響が広がるか」です。1つのFAQページで試すのは自社でも進めやすい一方、サイト全体のOrganizationやテンプレート単位の実装は、影響範囲が広いため慎重に進めるべき領域です。

まとめ

構造化データは、検索結果を装飾するための小手先のテクニックから、AIが情報を正確に理解するための必須インフラへと役割を変えました。中小企業は、大きな開発投資をしなくても、FAQPageやLocalBusiness、Articleといった自社の強みに直結するスキーマを適切に実装するだけで、AIに信頼できる情報源として認識される確率を高められます。

一方で、2026年8月の二重エスケープの仕様変更のように、技術的な仕様は常に更新されています。構造化データは一度設定して終わりではなく、リッチリザルトテストやSearch Consoleで継続的に点検する運用を組み込むことが、AI検索時代のWeb集客を左右します。

まずはトップページのOrganizationと、問い合わせの多いページのFAQPageから着手してみてください。無料のツールを使えば、コードを書けなくても今日から始められます。 分からない用語が出てきたら、この記事に戻って確認しながら進めてください。 AI検索対策全体の中でこの施策がどこに位置するかは、冒頭で紹介した記事もあわせてご確認ください。

制作会社に依頼するときに確認しておきたいこと

実装を外部に依頼する場合、見積もりや提案内容を比較する前に、自社側で整理しておくと話がスムーズに進む点があります。

優先ページを先に決めておく

全ページへの一括実装を依頼すると、費用も期間も膨らみます。トップページ、主要なサービスページ、実店舗があれば店舗ページ、といった優先順位を自社側であらかじめ決めておくことで、見積もりの精度が上がります。

FAQの質問リストは自社で用意する

FAQPageの質問と回答は、制作会社が一般論から作るより、実際の問い合わせ内容を知っている自社側で作成した方が、内容の精度もAIへの引用されやすさも高くなります。営業担当者やコールセンターに、直近でよく聞かれた質問を聞き取っておくと、依頼がスムーズです。

実装後の検証を誰が行うかを決めておく

実装して終わりではなく、継続的な点検が必要な施策です。制作会社に依頼する場合も、月次・四半期ごとの点検を契約に含めるか、自社の担当者がSearch Consoleを確認する運用にするか、実装前に決めておくと、公開後に放置される事態を防げます。

今日できる点検

点検項目	確認方法	該当したら次にすること
トップページにOrganizationがあるか	リッチリザルトテストにURLを入力する	企業名・ロゴ・SNSのURLを含めて実装する
主要ページにFAQPageがあるか	同上	営業でよく聞かれる質問を3〜5問構造化する
エラーが出ていないか	Search Consoleの「拡張」レポートを見る	赤色のエラーがあれば内容に従って修正する
特殊文字を含む社名・製品名がないか	「&」等を含む固有名詞を洗い出す	二重エスケープが起きていないかテストツールで確認する

初回は無料・60分・オンライン完結・その場で契約のお願いはいたしません