自社サイトの情報が、検索結果でもAIの回答でも思ったとおりに扱われていない。そう感じて「構造化データ」というSEOの施策にたどり着く方は多いと思います。構造化データは検索順位を直接上げる施策ではなく、検索結果での見え方と、機械への伝わり方を整えるための施策です。 ページの内容を決まった書式で書き添え、検索エンジンに意味を取り違えさせないようにする記述を構造化データと呼びます。まず運営者情報・記事情報・パンくずの3つを入れ、入れたら必ず検証する。これがこの記事の結論です。

AI検索での最適化を指す言葉は、AIO(AI Optimization)のほかにLLMO(Large Language Model Optimization)、GEO(Generative Engine Optimization)、AEO(Answer Engine Optimization)などがあり、業界でまだ呼び方が統一されていません。本メディアではこれらを総称して「AIO」と表記します。構造化マークアップやスキーママークアップという呼び方もありますが、本記事では「構造化データ」に統一します。

構造化データとは、ページの内容を機械が読める形で書き添える仕組み

構造化データは、ページに書いてある情報に「これは社名」「これは価格」という荷札を付ける記述です。検索エンジンは、ページを見て人のように「これは会社の代表電話だ」と判断しているわけではありません。文字の並びから推測はしますが、取り違えも起こります。

たとえば商品ページに「1,200円」とだけ書いてあるとします。これが通常価格なのか、期間限定の割引なのか、送料なのかは本文を読まないと分かりません。構造化データは「この1,200円は販売価格です」という宣言を、画面には出ない形でページに添える仕組みです。

「本文に書いてあるのに、なぜもう一度書くのか」という質問をよく受けます。答えは、推測を宣言に変えられるからです。推測に任せると、ページの作りが変わったときや似た数字が並んだときに解釈がぶれます。宣言しておけば、そのぶれが減ります。

AIの回答に自社がどう出ているかを計測するツールを提供する株式会社AI Hackでは、構造化データを「検索エンジンやAIに推測させないための仕組み」として説明しています。順位を動かす魔法ではなく、誤解を減らす地味な下ごしらえだと私たちは考えています。

データ分析の「構造化データ」とは別物

同じ言葉が、データ分析の世界では「表形式に整ったデータ」を指します。売上一覧やアンケート回答表のように、行と列で整理されたデータのことです。本記事で扱うのはWebサイト側の話で、ページに意味の荷札を付ける記述のほうを指します。

schema.org は語彙、JSON-LD は書き方という役割分担

構造化データは「どの言葉で表すか」と「どう書くか」の2つに分かれます。前者を決めているのが schema.org で、世界共通の単語帳のようなものです。「会社」「記事」「商品」「価格」といった言葉と、その使い方がここで定義されています。

後者が書式の話です。同じ単語帳を使っていても、ページへの書き込み方には種類があります。次の表は、その書き方の違いを並べたものです。

書き方

書く場所

本文と分けて管理できるか

保守のしやすさ

JSON-LD

ページの中にひとまとまりの記述として置く

できる

しやすい

Microdata・RDFa

本文のHTMLタグに属性として書き込む

できない

本文を直すたびに影響を受ける

違いは、本文と切り離して置けるかどうかに集約されます。Googleは、サイトの作りが許すなら JSON-LD を勧めています(Google 検索セントラル「構造化データ マークアップの仕組みについて」、2026年10月確認)。規模が大きくても実装と保守がしやすく、書き間違いが起きにくいという理由です。

私たちも、新しく入れるぶんは JSON-LD に統一しています。以降の説明も JSON-LD で進めます。

Google検索で構造化データは何を変え、何を変えないのか

Google検索で変わるのは、順位ではなく検索結果での見え方です。検索結果には、タイトルと説明文に加えて補足が表示されることがあります。これをリッチリザルトと呼びます。サイト内の階層表示や、商品の価格や在庫、レビューの星などがこれにあたります。

一方で「構造化データを入れたら順位は上がりますか」と聞かれることがよくあります。ここははっきりさせておきます。構造化データは、検索順位を直接上げる仕組みではありません。Googleのガイドラインには、手動の対策を受けた場合の説明があります。手動の対策とは、Googleの担当者が人の手で行う措置のことです。構造化データの違反でこれを受けても、ウェブ検索の順位には影響しないと書かれています(Google 検索セントラル「構造化データに関する一般的なガイドライン」、2026年10月確認)。順位とは別の話として扱われている、と読むのが正確です。

では何に効くのか。検索結果での見え方が変われば、ユーザーがクリックを決めるときの材料が増えます。私たちは、構造化データを順位施策ではなく、表示面と伝わり方の施策として見積もるべきだと考えています。

構造化データを入れてもリッチリザルトの表示は確約されない

ガイドラインを満たすことは、リッチリザルトの「対象になる」ための条件であり、表示そのものの保証ではありません(Google 検索セントラル「構造化データに関する一般的なガイドライン」、2026年10月確認)。表示するかどうかは、検索語や端末なども見てGoogleが決めます。検証ツールで合格しても必ず出るわけではない、という前提で扱ってください。

検索結果そのものがAIの回答に置き換わりつつある流れは、Google検索のAI Modeが検索結果をどう変えたかをまとめた記事で整理しています。

AI検索は構造化データをどこまで見ているのか

AI検索のために特別な構造化データを足す必要はない、というのがGoogleの公式の立場です。Googleは、生成AI検索に構造化データは必須ではなく、追加すべき特別な schema.org のマークアップもないと明記しています。そのうえで、通常の検索でリッチリザルトの対象になるため、SEO全体の一部として使い続けるのはよいとしています(Google 検索セントラル「Google 検索の生成AI機能向け最適化ガイド」、2026年5月15日公開)。

言い換えると、AI検索向けの裏技は存在しないということです。構造化データの実務的な意味は、自社・著者・商品が何者かを、機械が取り違えにくい形で置いておくことにあります。

引用されやすさを左右するのは、むしろ本文の書き方のほうだと示した研究もあります。1万件の質問を集めた検証(Aggarwal ほか、KDD 2024)では、本文側の3つの工夫が効くと報告されました。出典の明示、信頼できる引用の追加、具体的な統計の追加です。これらによって、生成AIの回答での見え方が最大40%改善しています(Aggarwal ほか「GEO: Generative Engine Optimization」(KDD 2024)、2024年8月)。構造化データの効果を測った研究ではない点には注意が必要です。入れれば引用が増える、と言える段階ではないと私たちは見ています。

自社が今どう語られているかは、マークアップの有無を見ても分かりません。実務では、AIの回答そのものを複数のエンジンで複数回取得し、言及された割合や引用元のドメインまで分解して観測しています。考え方の全体像は、AI検索の対策(AIO)の進め方を整理した記事にまとめています。

AI向けのファイルや本文の書き方は、構造化データとは別の話

AI検索の施策には層があります。引用されるための本文の書き方はGEOの仕組みを解説した記事で、AI向けのファイルについてはllms.txtの書き方とGoogleの見解をまとめた記事で扱っています。なおGoogleの「Google 検索の生成AI機能向け最適化ガイド」(2026年5月)は、AI検索に出るためにAI向けのファイルを新しく作る必要もない、と述べています。

最初に入れる5つのタイプと、着手する順番

迷ったら、どのページにも共通して存在するものから入れます。判断軸は、どのサイトでも入れるもの、ページの種類に応じて入れるもの、目的を切り替えて判断するもの、の3つに分かれます。次の表は、主なタイプと対象ページの対応です。

タイプ

入れる対象ページ

入れると何が起きるか

着手の順番

運営者情報(Organization)

トップページ、会社情報ページ

社名・ロゴ・公式アカウントがひとまとまりで伝わる

最初

記事情報(Article)

記事・コラムの各ページ

著者・公開日・更新日が伝わる

最初

パンくず(BreadcrumbList)

全ページ

サイト内の位置が伝わり、検索結果に階層が出ることがある

最初

商品(Product)

商品ページ

価格・在庫・レビューが検索結果に出ることがある

商品ページがあれば次に

よくある質問(FAQPage)

質問と回答を載せたページ

検索結果での補足表示はすでに終了している

新規は見送り

要点は、全ページ共通のものを先に片付けることです。商品ページを持たないサイトなら、上の3つで当面は十分だと私たちは考えています。下の図は、どの種類をどの順で入れるかを1枚に落としたものです。

最初に入れる構造化データの種類と着手順

運営者情報(Organization)をSEOの土台として先に入れる

社名、ロゴ、公式サイト、公式アカウントのURLを1か所にまとめて宣言します。同じような社名やサービス名が他にあるとき、どれが自社かを示す手がかりになります。置き場所はトップページと会社情報ページで足ります。

記事情報とパンくずで、誰がいつ書いたかを伝える

記事情報では、見出し・著者・公開日・更新日・画像を書きます。オウンドメディアを運営しているなら、更新日が正しく伝わるだけでも扱いが変わります。パンくずは全ページに入る共通部品なので、テンプレートに一度入れれば済みます。

商品情報は、中身が埋まっているときだけ意味が出る

価格・在庫・レビューといった具体的な値が入って、初めて役に立ちます。型だけ入れて中身が空では、得られるものはほとんどありません。AIが商品を比べて選ぶ流れについては、AIが買い物を代行する時代の商品情報の扱いを解説した記事で触れています。

JSON-LDを書いて埋め込み、3つのツールで検証するまで

作業は4つの工程に分かれます。全体の流れは次のとおりです。

  1. JSON-LDで書く
  2. ページのテンプレートに埋め込む
  3. ツールで検証する
  4. エラーを直して確認し直す

JSON-LDで書く構造化データの最小構成

中身は3つの部品でできています。どの単語帳を使うかの宣言、何についての情報かの指定、そして中身の項目です。次のコードは、自社が何者かを伝える運営者情報を、トップページに貼り付けるための記述です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png",
  "sameAs": [
    "https://x.com/example",
    "https://www.youtube.com/@example"
  ]
}
</script>

書き換えるのは、社名・サイトのURL・ロゴ画像のURL・公式アカウントのURLの4か所だけです。記事ページでは型の指定を記事情報に変え、見出し・著者・公開日・更新日・画像の項目を埋めます。

テンプレートに埋め込むか、タグ管理の仕組みで入れるか

埋め込む場所はページの中であれば構いませんが、1ページずつ手で貼るのは現実的ではありません。記事なら記事用のテンプレート、商品なら商品用のテンプレートに1回入れ、値を差し込む形にします。タグマネージャ(サイトに入れるタグの配信をまとめて管理する仕組み)でも入れられますが、読み込まれるタイミングに左右されます。この方法を取るなら、公開後の検証を必ず行ってください。

構造化データの検証に使う3つのツールの使い分け

  • リッチリザルトテスト(Google):1ページ単位で、Googleの補足表示の対象になるかを確認する
  • スキーマ マークアップ検証ツール(schema.org):書式と語彙の誤りを広く確認する。Google固有の判定はしない
  • Search Console(Google):公開後に、サイト全体のエラーを継続して確認する

使い分けは、公開前の1ページ確認と、公開後の全体確認という軸で考えると迷いません。

検出されないときに見る順番

見るべきは3点です。まず、公開ページのソースに記述が入っているかどうか。次に、そのツールが扱う種類かどうか。最後に、必須の項目が埋まっているかどうかです。この順で追うと、たいていは2つ目までで原因が分かります。

次の図は、書いてから直すまでが一方通行ではなく、戻る作業を含むことを表したものです。

構造化データを書いてから検証し、修正に戻るまでの流れ

私たちは、テンプレートを改修したあとに必ず検証をやり直しています。記述ごと消えていた、という事故が最も多いためです。

つまずきやすい5つの誤りと、FAQタイプの現在地

構造化データでつまずきやすい5つの誤り

  • 画面に表示されていない内容を書く(Google 検索セントラル「構造化データに関する一般的なガイドライン」で禁じられています。2026年10月確認)
  • 型と中身がずれている(サービス紹介ページに商品の型を当てる、など)
  • 複数のページで同じ記述をそのまま使い回す
  • 必須の項目が欠けていて、対象から外れている
  • テンプレートの改修で記述ごと消えたことに気づかない

共通するのは、画面に見えている内容と記述が一致していない点です。まずはここを疑ってください。

FAQタイプは今どう扱うか

2023年8月8日、Googleは検索結果での表示を見直しました。よくある質問の補足表示は、よく知られた信頼できる政府機関・保健衛生関連のサイトに限定されました(Google 検索セントラル ブログ「Changes to HowTo and FAQ rich results」、2023年8月)。一般の企業サイトでは、この時点で通常は表示されなくなっています。

そして2026年5月7日に、検索結果での表示そのものが終わりました(Google 検索セントラル「ドキュメントの最新の更新内容」、2026年5月8日)。Googleは同じ告知で、2026年6月にSearch Consoleの検索での見え方のフィルタとレポート、リッチリザルトテストでの対応を、8月にSearch Console APIでの対応を終えるとしていました。FAQタイプの説明ページ自体も2026年6月15日に削除されています(Google 検索セントラル「ドキュメントの最新の更新内容」、2026年6月)。

判断を書き切ります。表示を目的にするなら、この型の役目はすでに終わっています。既存の記述を急いで削除する必要はありませんが、新しく表示目的で入れるのは勧めません。残すなら、ページ内の質問と回答を正確に書き表す目的に切り替え、画面の内容と一致させてください。私たちは、AI検索に効くからという理由でこの型を足すことはしていません。

まとめ:順位ではなく、伝わり方を整える施策として扱う

構造化データは、検索順位を直接動かす施策ではありません。検索結果での見え方と、機械への伝わり方を整える下ごしらえです。今日からの一歩は1つに絞れます。運営者情報をトップページのテンプレートに入れ、リッチリザルトテストでエラーだけを先に潰してください。そこまで終えたら、記事情報とパンくず、商品ページがあれば商品情報へ広げます。テンプレートを改修するたびに見直すことも忘れないでください。マークアップは土台であり、AI検索で自社がどう語られているかは別に観測しないと分かりません。現状を実測で確かめたい方は、無料AIO診断(実測)からご相談ください。