前回、私たちは untype.jp の <head> を開き、Organization や BlogPosting といったノードを一つずつ読んだ。そして最後に、そこに「無いもの」——構造化されていない自社サービス——を見つけた。
では、その「空白」は、いったい何の空白だったのか。それを言い当てるには、もう一段高いところから全体を見渡す地図がいる。今回は、構造化データを「4つの層」として捉え直す。前回までの「ノードを読む」目線を、いったん「地層を眺める」目線に切り替える回だ。
第1回の「4分類」とは別の切り口だ
最初に、混乱を避けるための断りを置く。第1回でも「4つ」を出した——考え方・語彙・記法・セマンティックHTML、という分類だ。今回も「4つの層」を出すが、これは別の切り口である。
第1回の4分類は、「構造化データという言葉が指しているものを腑分けする」ための整理だった。いわば辞書の話だ。対して今回の4層は、「サイトを機械可読にするとき、実装はどんな地層からできているか」という地図である。同じ対象を、横に分類するか、縦に積み上げて見るかの違いだと思ってほしい。一対一で対応するものではないので、対応表を探さなくていい。
なぜ「層」で考えるのか
構造化データの話は、放っておくと「どの schema.org の型を使うか」「JSON-LD をどこに置くか」という記法の話に縮こまる。だが前回見たとおり、自社サイトの本当の問題は「サービスが構造化されていない」ことだった。これは記法の問題だろうか。違う。そもそも「このページに何の情報を、どんな単位で載せるか」という、もっと手前の設計の問題だ。
記法だけを見ていると、この手前が見えない。だから層で考える。下から順に、情報設計があり、その上に文書の骨格があり、その上に意味のマークアップが乗り、さらにその周りに「サイトが何をできるか」という新しい層が育ちつつある。順に降りて、そして昇っていく。
図：構造化データの4層。情報設計層を土台に、文書構造層・マークアップ層が下から積み上がる3層が「サイトが何を意味するか」を機械に伝える。その隣に立つ能力層（破線＝新興・流動的）は「サイトが何をできるか」をエージェントに渡す層で、標準はまだ固まっていない。各層が誰の仕事かは、後掲の職種表に対応する。
マークアップ層 — 私たちが読んできた層
いちばん上、というより、ここまでの3回で私たちがずっと見ていたのが、このマークアップ層だ。schema.org の語彙を JSON-LD で書き、「これは Organization だ」「これは BlogPosting だ」と機械に意味を渡す。第3回で読んだノードは、すべてこの層の住人だった。
世間で「構造化データ」と言うとき、多くはこの層だけを指している。だが、この層は単独で立っているわけではない。下に土台がある。
文書構造層 — 骨格に意味を与える
マークアップ層のすぐ下が、文書構造層だ。第1回で触れたセマンティックHTML——<header>、<nav>、<main>、<article>、そして <h1>〜<h6> の見出し階層——が、ここにあたる。
これは、ページの骨格に意味を持たせる層だ。見出しが適切な階層で組まれ、本文が <article> で囲まれ、ナビゲーションが <nav> で示されていれば、機械はマークアップを読む前から、「ここが主題で、ここが補足で、ここが案内だ」という見当をつけられる。骨が歪んでいれば、その上にどれだけ立派なマークアップを乗せても、ちぐはぐになる。地味だが、土台に近い層だ。
情報設計層 — そもそも、何を載せるか
さらにその下、いちばん深いところにあるのが情報設計層だ。これは「ページに何の情報を、どんな単位で、どう構成して載せるか」という、コンテンツそのものの設計を指す。
前回見つけた「空白」の正体は、実はこの層に半分埋まっている。自社サービスが構造化されていなかったのは、JSON-LD を書き忘れたから（マークアップ層）だけではない。そもそもサービスを「これは独立した一つの提供物で、名前があり、説明があり、価格の考え方がある」という単位で捉え、機械に渡せる形に整理する——という情報設計が、なされていなかったからだ。マークアップは、整理された情報に意味の札を貼る作業にすぎない。札を貼る前に、貼られる中身が整っていなければならない。
機械可読性の議論が記法に偏りがちなのは、この層がいちばん見えにくいからだ。だが、ここが崩れていると、上の層をいくら磨いても効かない。
能力層 — サイトが「何をできるか」
ここまでの3層が「サイトが何を意味するか」を機械に伝える層だとすれば、いま新しく育っているのが、サイトが「何をできるか」を機械に渡す能力層だ。動きが速く、まだ固まっていない領域なので、現在地を正確に書いておく。
llms.txt は、サイトの素性や主要ページをAI向けに要約して置くファイルで、2026年5月には Google の Lighthouse に「Agentic Browsing（エージェント閲覧）」監査の一項目として加わった。ただし設置は任意で、採用率も全サイトの1割程度にとどまる。当社でもllms.txt の記事で、その効果と限界を扱った。
WebMCP は、サイトが「価格を調べる」「予約する」といった操作を、AIエージェントが直接呼び出せる形で公開する仕組みだ。Google と Microsoft が W3C のコミュニティグループで共同で進めている提案で、Chrome では実験的なプレビューを経て、2026年5月の Google I/O で origin trial へと入った。ただし、まだ正式に確定した標準ではない。NLWeb（自然言語でサイトに問い合わせる仕組み）も同様に、「追うべきだが、本番実装はこれから」という段階にある。なお、これらをエージェントに見つけてもらう置き場所として、/.well-known/（RFC 8615 で定義された共通のディレクトリ）にエージェント向けのファイルを置く動きも出始めているが、これは層そのものというより、層を発見させるための枠だ。このあたりの全体像は、当社のエージェンティックWebの完全スタックで整理している。
能力層は、構造化データの「引っ越し」が最も先鋭的に現れている層でもある。第2回で「読む相手が検索エンジンからAIへ移った」と書いたが、能力層は端的に「AIエージェントに使ってもらう」ための層だ。Google が Lighthouse でこの層を採点し始めたこと自体が、ここが「測れる対象」になりつつある兆しだといえる。
この4層は、3つの職種の仕事だ
さて、ここからが今回の本題かもしれない。「構造化データ」と聞くと、多くの人——とりわけ社内では——「エンジニアがやる細かい技術作業」だと思いがちだ。だが、4層に分けてみると、それが思い込みだとわかる。各層は、異なる職種の仕事だからだ。
unType の職種でいえば、対応はこうなる。
| 層 | 整えるもの | 主に担当する職種 |
|---|---|---|
| 情報設計層 | 何を、どんな単位で、どう構成して載せるか | Communication Architect |
| 文書構造層 | セマンティックHTML、見出し階層 | Experience Designer |
| マークアップ層 | schema.org / JSON-LD | Integration Engineer |
| 能力層 | llms.txt / WebMCP / NLWeb | Integration Engineer |
いちばん深い情報設計層は、何をどう伝えるかを設計する Communication Architect の仕事だ。その上の文書構造層は、ページの骨格と体験を組む Experience Designer の領域。そして意味のマークアップと能力層の実装が、Integration Engineer の手に渡る。
ここで言いたいのは、構造化データはエンジニア一人の作業ではない、ということだ。前回の「空白」——サービスが機械に読めなかったこと——は、まず情報設計層でサービスを整理し（アーキテクト）、文書構造として正しく組み（デザイナー）、最後にマークアップを乗せる（エンジニア）という、三者をまたぐ仕事だった。「構造化データはあなたの層の話でもある」。そう翻訳されて初めて、これは自分ごとになる。
地図を持つと、優先順位が決まる
今回は、構造化データを4つの層——情報設計・文書構造・マークアップ・能力——として捉え直し、それぞれが3つの職種の仕事に対応することを見た。
この地図には、実用的な効き目がある。改修の優先順位が決まるのだ。たとえば前回見つけた自社サービスの「空白」は、いきなりマークアップ層から手をつけるべきではない。まず情報設計層で「サービスをどんな単位で構造化するか」を決め、それから下から順に積み上げる。土台が決まらないうちに上の札だけ貼っても、ちぐはぐになるからだ。
次回はいよいよ、その「空白」を実際に埋める。AI可読性を売る会社が、自社サイトに自社サービスを構造化していなかった——その紺屋の白袴を、4層の地図を手に、自分たちで直していく。本物のビフォーとアフターを、git の差分とともに見ていく。
参照情報
この記事をシェアする
