セマンティックWebとは何だったのか ── LLM 時代に「意味の構造化」は要るのか

元の構想は明快でした。Web 上の情報に機械が解釈できる意味づけを与え、横断的に扱えるようにする。人間向けに書かれた文章を機械が理解するのは当時ほぼ不可能だったので、最初から機械向けの層を用意しようという発想です。

そのために整備されたのが RDF（Resource Description Framework） を中心とする技術体系でした。あらゆる事実を「主語・述語・目的語」の三つ組で書き、語彙は オントロジー で厳密に定義し、問い合わせ言語で横断的に検索する。理屈としては非常に美しい設計です。

技術的な欠陥が原因ではありませんでした。普及を妨げたのは、ほぼすべてインセンティブの問題です。理由は3つに整理できます。

• 書く側の負担が報酬に見合わなかった: 正確なメタデータを書くのは手間がかかる。しかも得をするのは読む側（機械）で、書いた本人ではない。この非対称は、放っておくと必ず「書かれない」に収束する
• 合意形成のコストが高すぎた: 「顧客とは何か」を厳密に定義しようとすると、組織内ですら合意が取れません。まして世界規模で共通語彙を決めるのは、技術ではなく政治の問題になる
• 信頼の問題が未解決だった: メタデータは書いた者が自己申告するものです。検索順位のために嘘を書く動機がある以上、機械が鵜呑みにできない。構造化されていることと、正しいことは別

ここが面白いところです。壮大な構想は実現しませんでしたが、その部品は驚くほど普及しました。

勝因は一貫しています。「範囲を絞った」か「妥協した」か、そのどちらかです。schema.org は理論的な厳密さを捨てて実用に振り、その代わりに普及しました。ナレッジグラフは全世界の合意を待たず、作る主体が自分で決めて作るという形にしたから動いた。完全性を諦めたものだけが生き残ったというのが、この 20 年の教訓です。

そして LLM（Large Language Model） が登場しました。何が変わったのかを正確に押さえます。変わったのは「読む側のコスト」だけです。

下2行が変わっていないのが決定的です。LLM は文章から「営業時間は10時から」を読み取れますが、それが本当かどうかは判定できません。そして発信者が公式にそう主張したのか、単に本文にそう書いてあるだけなのかも区別できない。ここに構造化データの残された役割があります。

問いに正面から答えます。当初構想された形での実現は、もはや目指す意味が薄いというのが私の見立てです。理由は、それが解こうとしていた問題の大半を LLM が別の方法で解いてしまったからです。

「機械が意味を理解できない」という前提でメタデータ層を用意する設計でしたが、その前提が崩れました。わざわざ全世界の合意を取って語彙を統一する労力を払う理由が、ほとんど消えている。20 年かけて普及しなかったものが、必要性が下がってから普及する道理はありません。

もう1つ、実務的な理由があります。決定性です。LLM に毎回読ませて抽出すると、コストがかかり、結果が揺れます。構造化データを直接読めば、同じ入力から必ず同じ値が得られる。営業時間や価格のように揺れてはいけない情報では、この差が効きます。

投資判断の表です。基準は単純で、「間違えられると困るか」と「揺れてはいけないか」の2つです。

「記事の主張」を構造化しなくてよくなったのが、LLM 以降の最大の変化です。かつては本文を機械に理解させるために要約メタデータを書く発想がありましたが、いまは本文をそのまま読ませればよい。労力は事実情報の側に集中させるべきです。

1. 1事実情報だけを Schema.org で書く。営業時間、価格、著者、組織。実装は EP.03
2. 2本文と構造化データを食い違わせない。食い違いは信頼を損なううえ、どちらが正かを機械が判定できない
3. 3llms.txt で読み手への案内を置く。構造化とは別軸で、何をどう読んでほしいかを伝える（EP.02）
4. 4オントロジーは範囲を絞る。自社製品の語彙など、合意が数人で取れる範囲から
5. 5更新の仕組みを作る。構造化データの最大の問題は古くなること。手で書くと必ず腐る

• 全部を構造化しようとする: 20 年前に失敗した道をなぞることになる
• 全社オントロジーを目指す: 合意形成のコストで停滞する。範囲を絞る
• 本文と構造化データがずれる: どちらが正か判定できず、信頼を損なう
• 書きっぱなしにする: 古い構造化データは無いより悪い
• 構造化すれば信頼されると思う: 自己申告であるという性質は変わっていない
• LLM が読めるから不要と切り捨てる: 検証可能性と決定性の価値を見落としている
• 手作業で書く: 規模が増えると必ず腐る。生成の仕組みとセットで設計する

「構造化データはどこまでやるべきか」というご相談では、まず間違えられると困る情報の棚卸しから入ります。多くの場合、本当に構造化すべき項目は想像よりずっと少なく、その少数を確実に更新し続ける仕組みの方が価値を生みます。範囲を広げるより、腐らせない設計に投資する方が効果的だというのが実感です。

• セマンティックWeb が広まらなかった原因は技術ではなく、書く側の負担・合意形成コスト・信頼の3点
• 生き残ったのは「妥協したもの」と「範囲を絞ったもの」。Schema.org、JSON-LD（JSON for Linked Data）、ナレッジグラフ
• LLM が変えたのは 読む側のコストだけ。書かれた内容の正しさは保証されないまま
• 当初構想の実現を目指す意味は薄い。解こうとした問題の大半が別の方法で解けたため
• しかし構造化の価値は上がった。役割が「理解の補助」から「出典の明示と決定性」に移った
• 構造化するのは 間違えられると困るもの・揺れてはいけないもの。記事の主張は不要
• 古い構造化データは無いより悪い。更新の仕組みまで含めて設計する

セマンティックWeb の物語は、「正しい構想が、正しいという理由だけでは普及しない」という教訓として読むのが一番実りがあると思っています。勝ったのは理論的に美しい方ではなく、書く人の負担が小さい方でした。この構図は LLM 時代の設計にもそのまま当てはまります。続編では、構造化データを自動生成して腐らせない構成、ナレッジグラフを社内検索に使う実装などを、読者リアクションに応じて随時追加していきます。