ここまでの2回は、理屈の話だった。構造化データとは何か（第1回）、その意味がなぜ引っ越したのか（第2回）。だが「意味が引っ越した」と言葉で言うのは簡単で、本当にそうなのかは現物を開いて確かめるしかない。今回は、私たち自身のサイト untype.jp の <head> を開く。
先に断っておきたい。この連載を書きながら、私たちは自社サイトの構造化データを実際に改修した。その顛末は第5回で扱う。だから今回読むのは、連載を始めた時点のスナップショット——改修前のベースの状態だ。改修後の姿と並べて見せるのは第5回の役目で、今回はまず「もともと何が、誰に向けて書かれていたか」を、過去形で丁寧に読む。古い写真を一枚、机に広げるようなものだと思ってほしい。
開き方：view-source から始める
特別なツールはいらない。ブラウザでページを開き、右クリックして「ページのソースを表示」、あるいは URL の頭に view-source: を付けるだけでいい。表示されたHTMLの中で application/ld+json を検索すると、<script type="application/ld+json"> で囲まれたブロックが見つかる。これが、人間向けの見た目とは別に書かれた「意味の層」だ。
untype.jp のトップページには、このブロックが2つあった。ひとつは会社とサイトの素性を束ねたもの、もうひとつはFAQ（後述）。まず1つめを、整形して並べるとこうなる（説明に不要な部分は省いている）。
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"name": "株式会社アンタイプ | untype.jp",
"url": "https://www.untype.jp",
"publisher": { "@id": "https://www.untype.jp/#organization" }
},
{
"@type": "Organization",
"@id": "https://www.untype.jp/#organization",
"name": "株式会社アンタイプ",
"alternateName": "unType Inc.",
"url": "https://www.untype.jp",
"logo": {
"@type": "ImageObject",
"url": "https://www.untype.jp/images/logo-email.png",
"width": 650,
"height": 60
},
"foundingDate": "2007-04",
"address": {
"@type": "PostalAddress",
"addressRegion": "東京都",
"addressLocality": "港区",
"addressCountry": "JP"
},
"sameAs": ["https://x.com/untype_jp"]
}
]
}数十行のJSONだが、ここには「この会社は何者か」が、推測の余地なく書かれている。順に読んでいく。
Organization — 会社の身元を、機械に手渡す
@type: "Organization" は、「ここから先は組織の情報だ」という宣言だ。その下に、身元の各項目が並ぶ。name は正式名称、alternateName は英語表記（unType Inc.）、foundingDate は設立年月（2007-04）、address は所在地、logo はロゴ画像、sameAs は公式SNS（X）へのリンク。
なぜこれを書くのか。第1回で「構造化データは機械の推測を不要にする仕組みだ」と述べた。それがここで具体的に効く。たとえば、AIに「アンタイプはいつ設立された会社か」と尋ねたとする。構造化データがなければ、AIは本文のどこかにある「2007年創業」といった文字列を探し、文脈から推測するしかない。書き方によっては取りこぼすし、別の年号と取り違えることもある。だが foundingDate: "2007-04" が機械可読の形であれば、AIはそれを推測なしに、確定値として受け取れる。name も address も sameAs も同じだ。人間が見た目から読み取っていることを、機械にも同じ確かさで渡している。
この情報は、誰に向けて書かれているのか。第2回の言葉を借りれば、もともとの読み手は検索エンジンだった。Organization の情報は、Googleがブランドを識別し、社名で検索したときに右側に出るナレッジパネル（ロゴ・説明・SNS・連絡先などの情報枠）に反映されうる。とくに sameAs で公式SNSを結びつけると、Googleはそれを手がかりにブランドのエンティティ（知識グラフ上の実体）を組み立てる。そして同じ情報は、いまや検索エンジンだけでなく、ChatGPT や Perplexity のようなAIアシスタントが企業情報を理解するときの手がかりにもなる。読み手が検索エンジンからAIへ広がっても、書いてある中身は変わらない——第2回で見た「引っ越し」が、ここでも起きている。
ただし、留保がいる。Organization スキーマを書けばナレッジパネルが必ず出る、というものではない。パネルの生成はWikipediaやWikidataを含む複数の情報源に依存し、スキーマはあくまでその判断材料のひとつにすぎない。検索順位を直接押し上げるものでもない。スキーマができるのは「機械が推測せずに済むようにする」ことであって、「機械にこう表示しろと命じる」ことではない。この区別は、連載の第6回で改めて掘り下げる。
そしてもうひとつ、この時点のベースについて言っておくべきことがある。読んでのとおり、ここには会社の「名前・場所・ロゴ・SNS」はあるが、「何の会社か（事業内容や専門領域）」を機械可読で語るプロパティは入っていない。これは後で効いてくる欠落だ。覚えておいてほしい。
@graph と @id — ノードを「つなぐ」作法
もう一度、さっきのJSONの構造に注目する。@graph という配列があり、その中に WebSite と Organization という2つのノードが並んでいた。@graph は「複数の関係し合うノードを、ひとつのまとまりとして束ねる」入れ物だ。
注目すべきは、WebSite の中にある publisher: { "@id": "https://www.untype.jp/#organization" } という記述。これは「このサイトの発行者は、#organization というIDを持つあのノードだ」と指している。一方、Organization 側には "@id": "https://www.untype.jp/#organization" と、同じIDが振られている。つまり WebSite は、Organization の情報をもう一度書き写すのではなく、IDで参照している。
これは地味だが重要な作法だ。もし参照を使わず、サイトの各所で会社情報を何度も書いていたら、住所が変わるたびに全部を直さねばならず、食い違いも生まれる。@id で一度定義したノードを指し示せば、実体はひとつ、参照は何本でも、という構造になる。機械から見ても「この WebSite とこの Organization は同じ会社の話だ」と、曖昧さなく辿れる。第1回で「構造化データは関係を明示する」と書いたが、その「関係」を支えているのが、この @id による接続なのだ。
（この WebSite と Organization の参照関係、そして後述する記事ノードとの繋がりを図にしたものは、検証後に本記事へ追加する予定だ。）
BlogPosting — 記事に、著者と日付を結びつける
トップページではなく、ブログ記事のページを開くと、別のノードが現れる。BlogPosting だ。untype.jp では、記事ごとにこのノードが自動生成されている。整形して要点だけ示すと、こういう形だ。
{
"@type": "BlogPosting",
"headline": "記事のタイトル",
"datePublished": "2026-04-28T00:00:00+09:00",
"dateModified": "2026-05-10T00:00:00+09:00",
"author": [{ "@type": "Person", "name": "著者名" }],
"publisher": { "@id": "https://www.untype.jp/#organization" },
"inLanguage": "ja"
}ここでも、機械に渡しているのは「関係」だ。この記事の見出しは何で、いつ公開され、いつ更新され、誰が書き、どの組織が発行しているか。とくに author を独立した Person として持ち、publisher を例の @id で会社ノードに結びつけているのが効いている。これは、Googleが品質評価で重視するE-E-A-T（経験・専門性・権威性・信頼性、つまり「誰が書いたか」を重んじる考え方）とも地続きだ。構造化データがE-E-A-Tを直接スコア化するわけではないが、著者を機械可読にしておくことは、その考え方に沿っている。
BlogPosting（Article系）は、第2回で消えたFAQと違って、いまも有効な型だ。ただし「必ずリッチな表示を生む」というより、記事の日付・著者・見出し・発行主体を検索エンジンに正しく伝えるための基礎マークアップと考えるのが正確だ（その上で、文脈によっては日付や著者などの付加表示につながりうる）。同時に、AIが「この情報はいつのもので、誰の責任で書かれたか」を判断する手がかりにもなる。検索向けの価値とAI向けの価値が、同じマークアップに同居している。
BreadcrumbList と FAQPage — 残りの2ノード
ベースの untype.jp には、あと2つのノードがあった。
ひとつは BreadcrumbList。「ホーム > サービス > AI統合支援」のような、ページの位置を示すパンくずを構造化したものだ。これは機械にサイトの階層を伝え、いまも検索結果のパンくず表示として生きている。地味だが、サイトの地図を機械に渡す役割を果たす。
もうひとつが FAQPage——第2回の主役だ。トップページの2つめのJSON-LDブロックが、これだった。よくある質問とその答えを構造化したもので、かつては検索結果にドロップダウン表示を生んでいた。だが第2回で見たとおり、その表示用途は2026年5月7日に終わっている。にもかかわらず、このマークアップは untype.jp の <head> にいまも置かれている。なぜなら、表示は終わっても、Googleがページ理解に使い、Bingや各種AIが読む、という機械向けの用途は生きているからだ。「引っ越し」の生き証人を、私たちは自社の <head> の中に、実物として持っていたわけだ。
読めると、欠けているものが見える
ここまで、untype.jp のベースにあった5つのノード——Organization、WebSite、BlogPosting、BreadcrumbList、FAQPage——を読んできた。会社の身元、サイトの素性、記事と著者、ページの階層、よくある質問。どれも、人間向けの見た目とは別に、機械が推測せずに受け取れる形で書かれていた。決して手抜きの実装ではない。むしろ、よく整っている部類だ。
だが、ノード単位で読めるようになると、別のことが見えてくる。そこに無いものだ。
untype.jp は5つのサービス（Web制作、AI統合支援、SEO、アプリ開発、ブランディング）を掲げ、看板商品としてAIエージェント互換性診断を売っている。ところが、これらのサービスは画面上ではカードとして人間に見えているのに、構造化データとしては——Service や Offer といったノードとしては——どこにも書かれていなかった。機械から見ると、untype.jp は「会社の名前と住所と記事はわかるが、何を、いくらで売っているのかは構造として読めない」サイトだったのだ。
これは、なかなかに皮肉な状態だ。サイトをAIに正しく読ませることを売りにしている会社の自社サイトで、肝心の「売り物」がAIに読めない構造になっていた。紺屋の白袴、である。第1回で整理した「考え方・語彙・記法」を、自分たちはどの層まで実装できていたのか。読めるようになって初めて、その地図と、地図の空白が見えてくる。
次回は、いったん untype.jp を離れ、構造化データを「4つの層」として捉え直す。マークアップ層、文書構造層、情報設計層、能力層。今回見えた「空白」が、どの層の話で、私たちの会社の3つの職種のうち誰の仕事なのかを、地図の上に置いていく。そして第5回で、その空白を実際に埋める。
参照情報
この記事をシェアする
