構造化データとは？｜JSON-LDが効く読み手と効かない読み手を実験データで分ける

「構造化データを入れると、AIに引用されやすくなるらしい」

社内でそう聞いて、実装を検討している方は多いと思います。私も同じ話を何度も耳にしました。

ところが、この前提を一次資料で確かめていくと、どうも雲行きが怪しくなってきます。Googleは公式ドキュメントに、こう書いているからです。

“Structured data isn’t required for generative AI search” （構造化データは、生成AI検索に必須ではありません）

出典: AI features and your website – Google 検索セントラル

さらに、実際に1,885ページで検証した実験があります。JSON-LDを新しく追加したページと、追加していないページを比べたところ、AI検索での引用数はほとんど動きませんでした。

では構造化データは無駄なのかというと、そうでもありません。効く場所と効かない場所が、はっきり分かれているだけです。

この記事では、構造化データを「誰に向けて書くのか」という視点で3つに分けて整理します。読み手が違えば、必要な作り込みも、効果の確かめ方も変わるからです。専門用語はそのつど日本語で説明していきますので、技術的な予備知識がなくても読み進められます。

構造化データの正体｜ページに貼る「機械あての付箋」

まず、構造化データが何なのかを、できるだけ噛みくだいて説明します。

Webページを見ているとき、私たちは文字の大きさや位置から「これはタイトルだな」「ここは値段だな」と自然に判断しています。人間の目には一目瞭然です。

ところがコンピュータには、その判断が難しいのです。ページのHTMLには「大きい文字」「太い文字」としか書かれていないので、それが商品名なのか会社名なのか記事の見出しなのかは、推測するしかありません。

そこで、人間が読む文章とは別に、機械あての説明書きを一緒に置いておく方法が考えられました。これが構造化データです。

たとえるなら、書類に付箋を貼る作業に近いと思います。書類そのものは人間が読むためのものですが、付箋には「これは請求書」「金額はここ」「発行日はここ」と、あとで整理する人のためのメモが書いてあります。付箋を読むのは人間ではなく機械、というわけです。

付箋の書式がJSON-LD、付箋に使う言葉がschema.org

構造化データの話には、必ず2つの名前が出てきます。混同しやすいので、先に切り分けておきます。

ひとつはschema.org（スキーマ・オルグ）です。これは語彙、つまり「使ってよい単語のリスト」にあたります。商品はProduct、記事はArticle、会社はOrganization、といった具合に、あらかじめ名前が決まっています。勝手な単語を使うと相手に伝わらないので、共通の辞書を使いましょう、という取り決めです。

2026年3月19日に公開されたバージョン30.0の時点で、823種類のType（型）と1,529種類のProperty（属性）が定義されています。かなりの規模です。

もうひとつがJSON-LD（ジェイソン・エルディー）です。こちらは書式、つまり「付箋の書き方のルール」にあたります。JSON-LD 1.1は2020年7月16日にW3C勧告になっており、Web標準として正式に定まっています。

整理すると、schema.orgが「何と書くか」、JSON-LDが「どう書くか」を決めています。

実際の見た目は10行ほど

具体的にどんなものか、最小の例を見てみましょう。記事ページに付ける構造化データです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データとは？",
  "datePublished": "2026-08-05",
  "author": {
    "@type": "Person",
    "name": "山田太郎"
  }
}
</script>

HTMLの中に<script>タグを置いて、その中に情報を書くだけです。このタグの中身はブラウザに表示されないので、ページの見た目は一切変わりません。読者には見えず、機械にだけ見える付箋になっています。

3つある書き方と、Googleが勧める1つ

構造化データの書き方には、JSON-LDのほかにMicrodata（マイクロデータ）とRDFa（アールディーエフエー）があります。この2つは、HTMLのタグそのものに属性を書き足していく方式です。

Googleは3つのうちJSON-LDを勧めています。

“Google recommends using JSON-LD for structured data if your site’s setup allows it”

出典: 構造化データの仕組み – Google 検索セントラル

理由も同じページに書かれています。ひとつは、サイト運営者にとって大規模に実装・維持するのが最も簡単だから（原文は「the easiest solution for website owners to implement and maintain at scale」）。もうひとつは、本文と混ざらないので入れ子の情報を表現しやすいからです。さらに、JavaScriptであとから差し込んでもGoogleは読める、と明記されています。

ただし同じページには、こうも書かれています。

“all 3 formats are equally fine for Google, as long as the markup is valid” （マークアップが正しければ、3つの形式はGoogleにとって同等です）

読み替えると「JSON-LDでないとダメ」ではなく、「JSON-LDが一番ラクだからおすすめ」という位置づけです。すでにMicrodataで組んであるサイトを、慌てて書き直す必要はありません。

3つに増えた読み手｜検索エンジン・AI検索・社内AI

ここからが本題です。

構造化データの解説記事の多くは、読み手を1種類しか想定していません。検索エンジンです。「リッチリザルトを出すためにマークアップしましょう」という話に終始します。

しかし2026年現在、この付箋を読む可能性のある相手は3種類に増えています。そして調べていくほど、3者それぞれで事情がまったく違うことが分かってきました。

この3者を混ぜて語ると、話が噛み合わなくなります。「構造化データは効くのか」という問いには、「どの読み手に対して？」と聞き返す必要があるわけです。

とくに注意したいのが、真ん中の②です。日本語の解説記事も英語圏の記事も、いま最も熱心に語っているのがこの②なのですが、実は3つのなかで最も根拠が薄い領域でもあります。順番に見ていきましょう。

読み手①検索エンジン｜唯一、効果を数字で確かめられる相手

最初の読み手は、従来からの検索エンジンです。

構造化データを正しく書くと、検索結果に通常のリンクとは違う見え方が現れることがあります。レシピに調理時間と星評価が付いたり、商品に価格と在庫が出たり、パンくずリスト（サイト内での位置を示す階層表示）が表示されたりするものです。これをリッチリザルトと呼びます。

いま使える25種類の一覧

Googleがサポートしている構造化データの種類は、検索ギャラリーというページに一覧があります。2026年6月15日更新時点で25種類でした。

Article（記事）、Breadcrumb（パンくずリスト）、Carousel（カルーセル）、Course list（コース一覧）、Dataset（データセット）、Discussion forum（掲示板）、Education Q&A（学習用の問答）、Employer aggregate rating（雇用主評価）、Event（イベント）、Image metadata（画像情報）、Job posting（求人）、Local business（店舗・事業所）、Math solver（数式解法）、Movie（映画）、Organization（組織）、Product（商品）、Profile page（プロフィール）、Q&A（質問と回答）、Recipe（レシピ）、Review snippet（レビュー）、Software app（ソフトウェア）、Speakable（音声読み上げ）、Subscription and paywalled content（有料コンテンツ）、Vacation rental（バケーションレンタル）、Video（動画）の25個です。

ここに載っていないものを実装しても、Googleの検索結果には出ません。まずこの一覧を見るのが出発点になります。

「表示資格」と「表示の約束」の違い

ここは誤解が多いところなので、はっきり書いておきます。構造化データを正しく書いても、リッチリザルトが出るとは限りません。Googleは自分でそう書いています。

“Using structured data enables a feature to be present, it does not guarantee that it will be present.” （構造化データは機能が現れることを可能にするだけで、現れることを保証はしません）

出典: 構造化データに関する general ガイドライン – Google 検索セントラル

同じページには、リッチリザルトテストに合格していても保証はしない、とまで書かれています。検索履歴や位置情報、デバイスの種類によって表示が変わるためです。

構造化データは、応募条件のようなものだと考えるとしっくりきます。条件を満たしていなければ選考の対象になりませんが、満たしたからといって選ばれるとは限りません。

検索順位への影響はゼロ

もうひとつ、大事な点があります。構造化データを入れても、検索順位そのものは上がりません。GoogleのJohn Mueller氏が、2025年4月13日にBlueskyで明確に述べています。

“Structured data won’t make your site rank better.” （構造化データはサイトの順位を良くしません）

出典: John Mueller / Bluesky

裏付けとして、Googleのガイドラインには、構造化データの違反でペナルティを受けた場合について、Google検索での順位には影響しない（原文は「it doesn’t affect how the page ranks in Google web search」）と書かれています。失うのはリッチリザルトの資格だけで、順位は動かないという整理です。順位に効かないから、違反しても順位で罰しようがない、という一貫した立場だと読めます。

答え合わせに使う3つの道具

3つの読み手のなかで、①だけが持っている強みがあります。効果を数字で確かめられる、という点です。

確認に使う道具は3つあり、それぞれ守備範囲が違います。ここを取り違えると「検証ツールは通ったのに何も起きない」という状態になるので、表にしておきます。

注意点として、schema.orgの検証ツールを通っても、Googleのリッチリザルトが出るとは限りません。前者はschema.orgという辞書に照らして文法をチェックしているだけで、Googleが対応しているかどうかは見ていないからです。逆に言えば、Googleが使わない種類でも、辞書として正しければ合格します。

そしてSearch Consoleのレポートには、検出された項目の完全な一覧ではない（原文は「The reports aren’t a comprehensive list of all detected items」）という但し書きがあります。数字を社内報告に使うときは、全件ではなくサンプルだと添えておくのが安全です。

読み手②AI検索｜Google公式の「必要ない」と1,885ページの実験

さて、いま一番話題になっている読み手です。

AI Overviews（Google検索の上部に出るAIの要約）、ChatGPT Search、Perplexityのように、AIが答えを作って出典を示すタイプの検索が広がりました。ここに引用されるために構造化データを入れよう、という主張が世界中で流通しています。

ところが、この主張の根拠を追いかけていくと、どうやら足元はかなり弱そうです。

Google公式ドキュメントの記述

Googleは、AI機能と構造化データの関係について、公式ドキュメントで繰り返し「必要ない」と書いています。

“There’s also no special schema.org structured data that you need to add.” （追加すべき特別なschema.org構造化データもありません）

“There are no additional technical requirements.” （追加の技術要件はありません）

“You don’t need to create new machine readable files, AI text files, or markup to appear in these features.” （これらの機能に出るために、新しい機械可読ファイル、AI向けテキストファイル、マークアップを作る必要はありません）

いずれも出典: AI features and your website – Google 検索セントラル

さらにGoogleは、公式ドキュメントの「Mythbusting（よくある誤解を正す）」というセクションに、構造化データへの過度な注力を挙げています。誤解として名指しされているわけです。

AI文脈でGoogleが構造化データについて出している唯一の要求は、「増やせ」ではなく「合わせろ」でした。マークアップの内容がページの見える文章と一致していること、という整合性の話です。

Googleがもっとも肯定寄りに踏み込んだ発言も見つかりました。Danny Sullivan氏がポッドキャストSearch Off the Record（2025年12月17日）で述べたものですが、実際の言い回しは “we thought that could be helpful for that”（役立ちうると考えていました）という推量形です。同じ場で「構造化データがなければ終わり、というわけではなかった」とも述べています。

ちなみに、この発言を紹介した英語メディアの見出しは “structured data helps”（構造化データは役立つ）でした。推量形が断定に変わっています。伝言ゲームで主張が強くなる典型例なので、引用元をたどる価値はあります。

実際に1,885ページで試した結果

公式見解だけでは腑に落ちない、という気持ちも分かります。実際に測った人がいました。

SEOツールを提供するAhrefsが2026年5月11日に公開した調査です。手順が丁寧なので、順を追って説明します。

まず相関から始まっています。600万件のURLを分析したところ、AIに引用されたページは、引用されなかったページに比べてJSON-LDを持っている確率が約3倍でした。AIに引用されたページの53%が構造化データを実装していたそうです。

この数字だけを見ると「やはり構造化データは効く」と言いたくなります。実際、こうしたグラフがカンファレンスの資料で使われている、とAhrefs自身が書いています。

しかし同社は、そこで止まりませんでした。構造化データを入れているサイトは、そもそも技術的にしっかりしていて、良いコンテンツを作り、被リンクも多い傾向があります。すると構造化データが効いているのか、それとも他の要素の恩恵に相乗りしているだけなのかが分からない、というわけです。

そこで因果を切り分ける実験を組みました。2025年8月から2026年3月のあいだにJSON-LDを新しく追加した1,885ページを特定し、追加していない約4,000ページを対照群として突き合わせます。追加日の前後30日で引用数の変化を比べます。差分の差分法（difference-in-differences）と呼ばれる手法で、両グループに共通して起きた変化を差し引いて、施策だけの効果を取り出すやり方です。

結果は次のとおりでした。

構造化データを追加しても、AI検索での引用は増えませんでした。Ahrefsは念のため4通りの検定を回していますが、どれも同じ結論だったそうです。

同社の結びの一文が率直です。

“If you’re already doing the rest of the SEO work well, JSON-LD isn’t going to be the unlock.” （他のSEOをきちんとやっているなら、JSON-LDが突破口になることはありません）

この実験の限界

ここで止めると、今度は逆方向に言い過ぎになります。Ahrefs自身が挙げている限界を、そのまま紹介します。

対象となったのは、すでにAIに大量に引用されていたページでした。2025年2月時点でAI Overviewsに100回以上引用されていたページが条件です。ですから「すでに見つけてもらえているページに構造化データを足しても、それ以上は増えない」ことは分かりましたが、「まだAIに見つけてもらえていないページ」については何も言えていません。Ahrefsも、そうしたページでは構造化データが、AIにページを見つけてもらい内容を解析してもらう助けになる可能性は残る、と書いています。

ほかにも、構造化データを追加するときは他の変更も同時にやりがちであること、schemaの種類を区別せず一括で扱ったこと、観測が30日間だけであること、HTMLに直接書いたものだけを対象としたこと、といった留保が並んでいます。

AIが実際に読んでいるものを調べた実験

もうひとつ、角度の違う実験があります。ドイツのsearchVIUが2025年10月に実施したものです。

架空の商品「searchVIU Premium GEO Bears」のテストページを作り、価格情報を8通りの置き方で配置しました。目に見えるHTMLに書いたもの、JavaScriptで描画したもの、JSON-LDにだけ書いてページ上には表示していないもの、といった具合です。そのうえで5つのAIに「このページの商品と価格を教えて」と質問しました。

出典: Schema Markup and AI in 2025 – searchVIU

表の3行目を見てください。JSON-LDにだけ価格を書いた場合、5つのAI全部が答えられませんでした。隠しMicrodata、隠しRDFaも同様です。逆に、目に見える形で書いてあれば、いくつかのAIは正しく答えています。

searchVIUの結論は「AIチャットボットは直接取得の際、JSON-LDを使っていない。目に見えるHTMLの内容だけを抽出している」というものでした。

この実験の射程

この結果を「AIは構造化データを一切使わない」と一般化するのは行きすぎです。searchVIU自身が、はっきり但し書きを付けています。

“Our tests primarily show Phase 4 (Direct Fetch). Schema Markup could very well be used in Phases 1-3 – especially by Google AI Overviews and Bing Copilot, which have access to search indexes.” （このテストが示すのは主に第4段階、つまり直接取得の話です。構造化データは第1〜3段階では十分に使われている可能性があります。とくに検索インデックスにアクセスできるGoogle AI OverviewsやBing Copilotでは）

AIが情報を得る経路は一つではありません。その場でURLを取りに行く「直接取得」と、あらかじめ作られた検索インデックスを引く経路があります。searchVIUが測ったのは前者です。後者、つまり検索インデックスを作る段階では、構造化データが使われている可能性が残ります。

そして検索インデックスを作っているのは、読み手①で見たとおり構造化データを使っている検索エンジンです。ここは今のところ外から観測できません。

この読み手について、いま言えること

整理します。

一次資料で確認できるのは、次の3つです。Googleは「AI検索のために構造化データは必要ない」と公式に書いています。追加しても引用は増えなかったという対照実験があります。そしてAIが直接ページを取りに行くとき、JSON-LDは読まれていません。

一方、確認できなかったのは因果関係のほうです。構造化データを入れるとAIに引用されやすくなる、という主張を裏付ける公式見解も対照実験も、見つけられませんでした。

「効かないと証明された」わけではありません。「効くという証拠が見つからない」というのが正確なところです。この2つは違います。実装コストが低いのであれば、他の理由（読み手①や③）で入れておく判断はありえます。ただ、AI引用を目的に予算と工数を投じる根拠としては、いまのところ弱いと言わざるをえません。

llms.txtの現在地｜リクエストゼロが97%という実測データ

読み手②の話には、必ずセットで出てくる話題があります。llms.txt（エルエルエムズ・テキスト）です。

これは「AIに向けて、このサイトの重要なページはここですよ」と案内するファイルを、サイトの決まった場所に置いておこう、という提案です。robots.txt（クローラーに対して、どこを読んでよいかを伝える昔からあるファイル）のAI版、と説明されることが多いと思います。

提案であって、標準ではない

llms.txtは、Answer.AIのJeremy Howard氏が2024年9月3日に提案したものです。IETFやW3Cといった標準化団体は関与しておらず、バージョン番号も批准もありません。

仕様そのものに、こう書かれています。

“This proposal does not include any particular recommendation for how to process the llms.txt file.” （この提案には、llms.txtファイルをどう処理すべきかについての具体的な推奨は含まれていません）

処理方法を定めていない、と提案者自身が明記しています。

主要4社の公式ドキュメント

では実際に、AIのクローラーはこのファイルを読んでいるのでしょうか。各社の公式クローラードキュメントを一つずつ確認しました。2026年8月5日時点の結果です。

4社とも「読む」とは書いていません。ただし「読まない」とも書いていないので、そこは公平に見ておく必要があります。

ここで紛らわしいのが、これらのベンダーが自社のドキュメントサイトにllms.txtを置いている、という事実です。docs.claude.comにも、developers.openai.comにも、docs.perplexity.aiにもあります。

しかしこれは「自分のサイトに置いている」という発行側の話であって、「自社のクローラーが他人のサイトのllms.txtを読む」という消費側の話ではありません。逆の役割です。ここを混同した記事が、かなりの数出回っています。

137,000ドメインのアクセスログ調査

決定的なデータがあります。Ahrefsが137,000のドメインを調べた調査です。

そのうち約28%がllms.txtを公開していました。かなり普及しているように見えます。

ところが、有効なllms.txtファイルの97%が、2026年5月のあいだリクエストをまったく受けていませんでした。Ahrefsの表現をそのまま引くと “No bots, no humans, nothing.”（ボットも人間も、何も来ない）です。

さらに、観測されたわずかなリクエストのうち、識別できるAIボット由来のものは20%未満でした。多くはコーディング用のエージェントだったそうです。

GoogleのJohn Mueller氏の発言も、この観測と整合しています。

“AFAIK none of the AI services have said they’re using LLMs.TXT (and you can tell when you look at your server logs that they don’t even check for it). To me, it’s comparable to the keywords meta tag.” （私の知る限り、llms.txtを使っていると表明したAIサービスはありません。サーバーログを見れば、そもそも見に来ていないことが分かります。私には、キーワードメタタグと同じようなものに見えます）

出典: Search Engine Roundtable

キーワードメタタグというのは、かつてSEOで使われ、現在はGoogleが完全に無視している要素です。かなり厳しいたとえだと思います。なお、これは個人の発言の二次報道であり、Googleのポリシー文書ではない点は付け加えておきます。

自社サイトで確認した結果

他人事として書くのも据わりが悪いので、この記事を載せているmedia.deskrex.ai自身を調べました。2026年8月5日時点の実測です。

https://media.deskrex.ai/llms.txt にアクセスすると、HTTP 200が返ってきます。ファイルは存在していて、固定ページや記事の一覧がずらりと並んでいました。おそらくWordPressのプラグインが自動生成したものです。

私たちも、上の97%側に入っている可能性が高いわけです。置いた記憶すらないファイルが、誰にも読まれないまま置かれています。同じ状況のサイトは相当あると思います。

自分のサイトを確認するのは簡単です。ブラウザのアドレス欄に「（自社ドメイン）/llms.txt」と打ち込むだけで、あるかないかが分かります。

AIクローラーの制御はrobots.txt

「AIに読ませたくない」「特定のAIだけ許可したい」という話であれば、llms.txtは無関係です。llms.txtには、そもそもブロックする機能がありません。

現時点でAIクローラーを制御する共通の手段は、robots.txtだけです。こちらはIETF RFC 9309として2022年9月に標準化されており、4社すべてが公式ドキュメントで制御方法として案内しています。

llms.txtとrobots.txtは、名前が似ているだけで別物です。前者はコンテンツの案内、後者はアクセス制御にあたり、用途がまったく違います。

読み手③社内AI・RAG｜地味だが、効果を自分で測れる領域

3つめの読み手が、この記事を読んでいる方にとって、いちばん実入りが大きいかもしれません。自社のなかで動くAIです。

社内文書を検索できるチャットボットを作った、あるいは作ろうとしている、という話をよく聞くようになりました。この仕組みは一般にRAG（ラグ、Retrieval-Augmented Generation：外部の文書を検索して回答に組み込む手法）と呼ばれます。AIが答える前に、社内の文書から関連しそうな部分を検索して取ってきて、それを見ながら答える、という作り方です。

検索を外したときに起きること

RAGでいちばん困るのは、検索の段階で見当違いの文書を取ってきてしまうことです。AIは取ってきた文書をもとに答えるので、材料が間違っていれば答えも間違います。しかも文章としては流暢なので、読んだ人は気づきにくいのです。

ここで効いてくるのが、文書に付いている情報です。いつ作られたか、どの部署のものか、どの製品についてか、いま有効な規程なのか。こうした情報が構造化されていれば、検索の段階で絞り込めます。

「2024年度の営業部の規程」と指定できるかどうかで、取ってくる文書の精度は大きく変わります。逆にこの情報がなければ、AIは文章の意味の近さだけを頼りに探すので、廃止済みの旧規程を持ってきてしまうことがあります。

見出しの階層を持たせるだけで、正答率が6.5ポイント上がった実験

ここには、査読を通った定量データがあります。ポルトガル語の行政文書36件、1,706ページ、約49万語を対象に、21通りの構成をそれぞれ50回ずつ実行して比較した研究です。

RAGでは、長い文書をそのまま扱えないので、細かく切り分けて保存します。この切り分け方を変えると、正答率がどう動くかを測っています。

差は6.5ポイントです。偶然でこの差が出る確率は10のマイナス34乗を下回りました。差の大きさを表すCohen’s dという指標は4.54で、一般に0.8を超えれば大きいとされる水準を大きく上回っています。論文はこれを、このベンチマークで観測された単一要因として最大の改善（原文は「the largest single-factor gain observed in the benchmark」）と表現しています。

とくに目を引くのが、表を読む必要がある設問での差です。ここだけを取り出すと、機械的に切った場合と階層で切った場合で33ポイントも開きました。

比較として、PDFをテキストに変換するツールを変えたときの差は1.5ポイントしかありませんでした。しかも変換ツールの優劣は、事前の予想とは逆の結果です。論文の結論は、どの変換ツールを使うかより、階層構造とメタデータを持たせるほうが効く、というものでした。

やっていることは、「この文書のこの章の、この節にある一文」という位置情報を各断片に持たせることだけです。

「絞り込む」と「埋め込む」で逆になる効果

ここで、実務上かなり重要な区別があります。メタデータの使い方には2通りあって、効果が逆方向に出ることがあるのです。

ひとつは絞り込みに使う方法です。「2024年度の」「営業部の」と条件を指定して、検索範囲を狭めます。直感的には精度が上がりそうですが、金融文書を対象にした実験では、事前の絞り込みを足すと必要な情報を拾えた率がむしろ下がりました。絞り込みが効きすぎて、周辺にあった証拠まで落としてしまうためです。論文はこれを「諸刃の剣」と呼んでいます。

もうひとつは、断片の本文そのものに書き込む方法です。同じ論文で、こちらは比較したすべての構成で回答品質を改善していました。先ほどの見出し階層の研究も、後者にあたります。

条件で切り捨てるのではなく、断片に文脈を持たせる。同じ「メタデータを整える」という言葉でも、この2つは分けて考えたほうがよさそうです。

断片に説明文を足すという方法

似た発想の手法として、Anthropicが公開したContextual Retrievalがあります。

Anthropicが挙げている例が分かりやすいので借ります。ある断片に「同社の収益は前四半期比で3%増加しました」と書いてあったとします。この文だけでは、どの会社の、いつの話なのか分かりません。「同社」が誰なのか、断片からは復元できないからです。

そこで各断片に、元の文書のどこから来たものかを説明する短い文を付けてから保存します。報告されている数字は、上位20件を取ってきたときの検索失敗率が5.7%から3.7%へ、キーワード検索を併用すると2.9%へ、並べ替えを追加すると1.9%へ下がった、というものでした。

ただしこれはAnthropic自身による社内評価で、評価用データセットは公開されていません。第三者がこの数字をそのまま再現した報告は、探した範囲では見つかりませんでした。参考値として読むのが妥当だと思います。順序としては、別の研究チームが独立に実装したときも、この方式が意味的な切り分けや機械的な切り分けより上位に来ることは確認されています。

いずれにしても、読み手①や②とは性質がまったく違う話です。①は表示資格が得られるだけで、②は効果が確認できません。それに対して③は、自社のデータで測れて、しかも効きます。

項目名の辞書は、schema.orgより先に見るべきものがある

社内文書に情報を付けるとき、項目名をどう決めるかで迷うことがあります。「作成日」なのか「発行日」なのか「更新日」なのか。部署ごとにバラバラだと、あとで横断検索ができなくなります。

ここでschema.orgの語彙を借りればよいのでは、と考えたくなります。ところが調べてみると、その方向はあまり支持されていませんでした。

まずschema.org自身が、そういう使い方を想定していないと明記しています。

“schema.org is not intended as a universal ontology.” （schema.orgは、普遍的なオントロジーとして意図されたものではありません）

出典: Schema.org Data Model

想定されている適用範囲も「Webページ、メール、およびその周辺」で、社内システムへの言及はありません。

実際の製品を見ても同じでした。Microsoft 365 Copilotのコネクタ、Google Vertex AI Search、Glean、Atlassian Rovo、AWS Q Business。社内文書を検索させるこれらの仕組みは、いずれも独自のスキーマを使っており、schema.orgを採用しているものは見つかりませんでした。

企業が社内で実際に使っている語彙は別にあります。社内の分類体系にはSKOS（用語や分類を階層で定義するW3Cの規格）、文書のメタデータにはDublin Core（作成者や日付など15項目の国際規格）、データカタログにはDCAT、組織構造にはW3CのOrganization Ontologyというように、用途ごとに確立した辞書があります。社内文書の項目名を決めるなら、schema.orgよりこちらを見たほうが早いはずです。

もうひとつ関連する報告があります。エンティティのページにJSON-LDを付けた効果を検証した実験では、マークアップ単体での改善はわずかで、効いたのはページの作り直し、つまりナビゲーションや相互リンクを整えたほうだったとされています。29.6%の改善は後者によるものでした。ここでも、付箋より書類そのものを整えるほうが効いています。

ナレッジグラフ（情報同士のつながりを地図のように持たせる方式）を組む場合の考え方は、ナレッジグラフとは？GraphRAGとAI調査での使い方で詳しく書いていますので、あわせて読んでみてください。また、AIが文章の意味を捉える仕組みそのものについてはエンベディングとは？が参考になります。

廃止済み仕様の落とし穴｜HowToとFAQのその後

ここまでは「何を入れるか」の話でした。ここからは「何を入れてはいけないか」の話をします。

構造化データの種類は、増えるだけではありません。減ることもあります。そして減ったことは、あまり大きく報じられません。

この3年で消えた種類

Googleが2023年以降に廃止・縮小した主なものを並べます。

とくに大きいのがFAQです。多くの解説記事が「実装しやすくて効果が高い」と勧めてきた定番でしたが、2026年5月7日をもってGoogle検索での表示が完全に止まりました。

“The FAQ rich result feature is no longer shown in Google Search results”

出典: Google 検索セントラル 更新履歴

FAQのドキュメントページにアクセスすると、現在は更新履歴へリダイレクトされます。HowToのページも同様で、旧URLは404です。

日本語の解説記事20本の実地調査

廃止から時間が経っているのに、解説記事は追いついているのでしょうか。実際に調べました。

「構造化データとは JSON-LD 実装 方法」などで検索し、上位に出てくる日本語記事20本を取得して、廃止済みの種類がどう扱われているかを確認しました。ここで大事なのは、キーワードの出現回数を数えるだけでは判定できない、という点です。実際に該当箇所の本文を読んで判断しました。

まず、廃止済みの仕様を「今も使えるもの」として書いている記事がありました。

bakuyasu.techsuite.co.jpは、実装できる型の一覧表にFAQとHowToを載せたうえで、「FAQリッチリザルトは、一つの検索結果が通常より大きなスペースを占めるため、クリック率向上に効果的です」と現役の施策として推奨していました。

webries.co.jpは、FAQPageを「高優先」と位置づけ、「2026年現在、GoogleはFAQリッチリザルトの表示基準を厳格化しています」と書いています。厳格化ではなく、すでに全面停止しています。2023年時点の理解のまま更新が止まっているようです。

0120.co.jpでは、2026年6月10日付の関連記事として「構造化データでAI検索を強化する実装ガイド2026｜FAQ・HowTo・Article」が紹介されていました。FAQの停止から1か月あとの日付で、廃止済みの2つを中核スキーマとして扱っていることになります。

atoz-design.jpは「FAQPage：AI Overviewに掲載されやすい構造化データ」という見出しを立てていました。読み手②で見たとおり、この因果関係を示す一次資料は見つかっていません。

正確に更新されている記事

公平を期すために書いておくと、日本語圏の記事が一律に遅れているわけではありませんでした。むしろ正確な記事もあります。

shwat.jpは見出しに「【Googleサポート終了】」と明記し、2026年5月7日の停止日まで書いたうえで、すでに実装済みなら無理に削除する必要はない、という対処まで示していました。

jinrai.co.jpは「Googleは『AI OverviewsやAI Modeのために特別なスキーマは必要ない』としており、実装すればAIに引用されるという因果関係は公開情報の範囲では確認されていません」と書いています。この記事の立場とほぼ同じです。

envydesign.jpは、先ほど紹介したAhrefsの1,885ページ調査を引用したうえで、「スキーマの追加単体ではAI引用数に大きな変化は見られなかった」と明記していました。

検索結果は玉石混交で、上位に出てくるかどうかと内容が最新かどうかは、別の話だということです。

数えるだけでは間違える

この調査をしていて、自分でも一度失敗しかけました。記録として残しておきます。

keywordmap.jpの記事には「HowTo」という文字列が13回も出てきます。回数だけ見れば「廃止済みの仕様を大々的に扱っている記事」に見えます。

ところが本文を開いて読むと、すべてRecipe（レシピ）のrecipeInstructionsという項目のなかで使うHowToStepでした。Recipeは現在もサポートされている25種類のひとつで、その手順を書くのにHowToStepを使うのは正しい実装です。廃止されたHowToリッチリザルトとは別物でした。

キーワードの出現数だけで判定していたら、この記事を誤って「古い」と分類していたわけです。判定は本文を読んでから、というのは面倒ですが避けて通れないところだと思います。

公式ページに残る古い記述

もう一つ、落とし穴があります。廃止情報の出どころであるGoogleの検索ギャラリーページですが、末尾の自動生成された要約文には、いまだにFAQsやpractice problems、salary estimates、vehicle listingsといった廃止済みの名前が残っています。

ページ本体の表には載っていないので、更新漏れだと思われます。うっかりこの要約文を引用すると、公式ページを見ていながら誤情報を書くことになります。一次資料にあたるときも、ページのどこを見ているかは意識したほうがよさそうです。

自分のサイトを点検する手順

いま実装しているものが生きているかどうかは、次の順で確認できます。

1. Search Consoleを開き、左メニューの「拡張」に何が並んでいるかを見る。廃止された種類は、そもそも項目ごと消えています
2. 検索ギャラリーの一覧表と照らし合わせる。ページ末尾の要約文ではなく、本体の表を見る
3. 一覧にないものを実装している場合、リッチリザルトテストにかけると対象外として扱われる

なお、廃止された種類のマークアップが残っていても、ペナルティにはなりません。Googleが単に無視するだけです。慌てて削除する必要はありませんが、「実装したのに何も起きない」と悩んでいる場合は、まずここを疑うと早いと思います。

実装の優先順位｜読み手ごとに決める3つの段階

ここまでの話をふまえて、実務での優先順位を考えます。

前提として、構造化データの実装コストはそれほど高くありません。WordPressであればプラグインが自動で出力しますし、自社開発でもテンプレートに数行足すだけで済むことが多いはずです。コストが低いので「とりあえず入れておく」判断は十分ありえます。

問題は、どこに時間をかけるかです。

第1段階｜読み手①のうち、自社に該当する種類だけ

まず検索ギャラリーの25種類を眺めて、自社に該当するものを選びます。全部入れる必要はまったくありません。

事業内容ごとの目安を挙げます。オウンドメディアを運営しているならArticleとBreadcrumb、実店舗があるならLocal business、商品を売っているならProduct、求人を出しているならJob posting、会社としての情報を明示したいならOrganizationを選びます。だいたいこの範囲で足ります。

選んだら実装し、リッチリザルトテストで文法を確認して、公開後にSearch Consoleの「拡張」で検出されているかを見ます。ここまでが、効果を数字で追える唯一の経路です。

第2段階｜読み手③の設計

自社でAIに社内文書を読ませる計画があるなら、こちらのほうが投資対効果は高いと思います。

やることは、Webページのマークアップとは違います。優先順位も、先ほどの実験結果からはっきりしています。

最初にやるのは、文書を切り分けるときに見出しの階層を保つことです。「どの章の、どの節にある一文か」を各断片に持たせます。6.5ポイントの改善が出たのはここでした。とくに表を含む文書では効きます。

次が属性名の統一です。作成日なのか発行日なのか、部署ごとにバラバラな状態を揃えます。更新日と、いま有効な文書かどうかは必ず持たせてください。廃止済みの旧規程を引いてくる事故は、これで防げます。

絞り込み条件としてのメタデータは、その後で構いません。効きすぎると必要な証拠まで落とすことがあるので、入れたら必ず前後を比べてください。

ここは自社で効果を測れます。よく聞かれる質問を20個ほど用意して、正しい文書を引けているかを数えるだけでも、改善したかどうかは判断できます。

第3段階｜読み手②のための追加作業は保留

AI検索のために構造化データを追加する、という作業は、現時点で根拠が薄いと考えています。

Googleが「必要ない」と明言していること、対照実験で引用が増えなかったこと、AIが直接取得時にJSON-LDを読んでいないこと。この3つが揃っている以上、AI引用を目的に予算を組むのは説明が難しいはずです。

ただし、読み手①のために入れた構造化データが、結果として②にも効く可能性は残っています。検索インデックスを作る段階では使われているかもしれないからです。追加投資はしないが、①のためのものは維持しておく、という構えが妥当だと思います。

AI検索を意識するときに、実際にやること

では、AI検索に引用されたい場合は何をすればいいのでしょうか。Googleが唯一出している要求が、そのままヒントになります。構造化データがページの見える文章と一致していること、でした。

そしてsearchVIUの実験が示したのは、AIが読んでいるのは目に見えるHTMLだ、という事実です。JSON-LDに書いてあってもページに書いていない情報は、拾われませんでした。

ここから導ける行動は単純です。伝えたい情報を、構造化データの中だけでなくページの本文にきちんと書きます。価格を伝えたいなら本文に価格を書き、会社の所在地を知ってほしいならページに所在地を書く。付箋ではなく、書類そのものを整えるということです。

拍子抜けするような結論かもしれませんが、実験データが示しているのはそういうことでした。

今後の見通し｜種類の削減と、検証を求める流れ

最後に、この先の見通しを短く書きます。ここからは確認済みの事実ではなく、現時点の材料からの推測です。

さらに減っていく種類

2023年から2026年にかけての流れを見ると、Googleは構造化データの種類を減らす方向に動いています。2025年6月には7種類をまとめて廃止し、その理由として検索結果の簡素化を挙げていました。

背景として考えられるのは、AI Overviewsのような要約表示が広がるなかで、リッチリザルトという表示形式そのものの役割が縮んでいることです。この流れが続くなら、いま残っている25種類も安泰とは限りません。

実務への含意は明確で、「一度実装したら終わり」という扱いはできない、ということです。年に一度は検索ギャラリーの一覧と自社の実装を突き合わせる運用にしておくと安全だと思います。

測れない施策への懐疑

Ahrefsの調査が象徴的でした。相関のグラフを出したうえで、それでは因果を示せないと自ら書き、対照実験まで組んでいます。

AI検索への最適化という領域は、効果測定が難しいぶん、根拠の弱い主張が流通しやすい構造になっています。その反動として、対照群を置いた検証を求める動きが出てきているように見えます。社内で施策を提案する側も、「相関なのか因果なのか」を先に整理しておくと、話が早くなるはずです。

価値が上がる、社内向けの構造化

AI検索での効果が曖昧なままなのに対して、社内AIでの効果ははっきり測れます。見出しの階層を保つ、属性名を統一する、更新日を持たせる。地味な作業ですが、自社のデータで改善が確認できます。

外向きの構造化データが不確実さを増しているぶん、内向きの情報整備のほうに重心が移っていくのではないかと考えています。少なくとも、投資判断の説明はこちらのほうがずっとしやすいはずです。

よくある質問

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

上がりません。GoogleのJohn Mueller氏が「Structured data won’t make your site rank better.」と明言しています。構造化データが与えるのはリッチリザルトの表示資格であって、順位を動かす要素ではありません。実際、構造化データの違反でペナルティを受けた場合も、失うのは表示資格だけで順位は影響を受けない、とGoogleのガイドラインに書かれています。

Q2. 構造化データを入れるとAIに引用されやすくなりますか

そう断定できる根拠は、一次資料では見つかりませんでした。Googleは公式ドキュメントで「生成AI検索に構造化データは必須ではない」と書いています。またAhrefsが1,885ページを対象に行った対照実験では、JSON-LDを追加してもAI Overviews、AI Mode、ChatGPTのいずれでも引用数は増えませんでした。ただし、この実験の対象はすでにAIに引用されていたページなので、まだ見つかっていないページについては分かっていません。

Q3. FAQPageはもう実装しなくてよいのですか

Google検索でのリッチリザルト表示を目的とするなら、実装する意味はなくなりました。2026年5月7日に表示が停止し、6月にはドキュメントも削除されています。すでに実装しているものを慌てて削除する必要はありません。Googleが無視するだけで、ペナルティにはならないからです。他の検索エンジンや社内システムで使っている場合は、そのまま残しておいて問題ありません。

Q4. JSON-LDとMicrodataとRDFa、どれを使えばよいですか

新規に実装するならJSON-LDです。Googleが推奨しており、理由として「大規模に実装・維持するのが最も簡単」であることを挙げています。本文と混ざらないので管理しやすく、JavaScriptで後から差し込んでも読み取られます。ただしGoogleは同時に「マークアップが正しければ3つの形式は同等」とも書いているので、すでにMicrodataで組んであるサイトを書き直す必要はありません。

Q5. llms.txtは置いたほうがよいですか

2026年8月時点で、OpenAI、Anthropic、Google、Perplexityのいずれも、自社クローラーがllms.txtを読むとは公式に明記していません。Ahrefsが137,000ドメインを調べたところ、有効なllms.txtの97%が1か月間まったくリクエストを受けていませんでした。置くこと自体に害はありませんが、効果を期待して工数をかける段階ではないと考えています。AIクローラーを制御したい場合は、標準化されているrobots.txtを使ってください。

Q6. 検証ツールを通ったのにリッチリザルトが出ません

2つの理由が考えられます。ひとつは、使ったツールの守備範囲です。schema.orgのスキーママークアップ検証ツールは語彙と文法だけを見ているので、Googleが対応していない種類でも合格します。リッチリザルトテストで確認し直してみてください。もうひとつは、そもそもGoogleが表示を保証していないことです。Googleは「正しくマークアップされていても、リッチリザルトが表示されることは保証しません」と明記しています。検索履歴や位置情報、デバイスによって表示は変わります。

Q7. 社内文書にschema.orgを使う意味はありますか

あまり向いていません。schema.org自身が「普遍的なオントロジーとして意図されたものではありません」と明記しており、想定範囲もWebページやメールに限られています。Microsoft 365 Copilot、Vertex AI Search、Glean、AWS Q Businessといった社内検索の製品も、いずれも独自スキーマを使っています。社内文書の項目名を統一したいなら、分類体系はSKOS、文書メタデータはDublin Core、データカタログはDCATというように、用途ごとに確立した辞書を見るほうが早いはずです。

まとめ

構造化データは、ページに貼る機械あての付箋です。schema.orgという辞書の言葉を使い、JSON-LDという書式で書きます。ここまでは昔から変わっていません。

変わったのは、その付箋を読む相手が3種類に増えたことです。そして3者で事情がまったく違います。

検索エンジンに対しては、リッチリザルトの表示資格が得られます。効果をSearch Consoleで数字として確かめられる、唯一の相手です。ただし表示は保証されませんし、順位は上がりません。

AI検索に対しては、Googleが公式に「必要ない」と書いています。1,885ページの対照実験でも引用は増えませんでした。AIが直接ページを取りに行くとき、JSON-LDは読まれていないという実験結果もあります。効かないと証明されたわけではなく、効くという証拠が見つからない、というのが現状です。

社内のAIに対しては、いちばん確実に効きます。文書を切り分けるときに見出しの階層を各断片に持たせるだけで、正答率が6.5ポイント上がったという査読論文があります。しかも、この効果は自社のデータで測れます。ただし語彙にschema.orgを持ち込むのは筋が違うので、SKOSやDublin Coreといった社内向けの辞書を見てください。

もうひとつ、忘れずに確認したいことがあります。いま実装しているものが、まだ生きている仕様かどうかです。HowToは2023年に、FAQは2026年5月に廃止されました。それでも解説記事の一部は、いまだにこの2つを推奨しています。実装する前に、Googleの検索ギャラリーで一覧を確認してください。

構造化データを入れるかどうかで迷ったときは、種類を数える前に、まず読み手を決めるのがよいと思います。誰に読ませたいのかが決まれば、何を入れるべきかも、効果をどう確かめるかも、自然に決まってきます。

なお、この記事のように「業界で言われていること」と「一次資料で確認できること」を切り分ける作業は、それ自体がかなりの調査量になります。今回もGoogleの公式ドキュメント、W3Cの勧告、各AIベンダーのクローラードキュメント、そして実験レポートを一つずつ当たっていきました。私たちが開発しているSnorbeは、こうした横断的な裏取りを出典付きで進めるためのAIリサーチエージェントです。「この主張の一次ソースはどこか」を追いかける調査を、まるごと任せる選択肢として使ってみてください。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/