セマンティックHTMLとは何か ―
"意味のあるマークアップ"が未完のまま30年続いている理由

私たちは毎日HTMLを書いている。だが、その多くは「意味」ではなく「見た目」のために書かれている。セマンティクスという理想はなぜ30年経っても完成しないのか。そこには、Webという仕組みそのものの本質的なジレンマがある。

あなたのHTMLには「意味」があるか

少し想像してみてほしいのです。あなたが昨日書いたHTMLのソースコードを開いて、すべての<div>を数えてみてください。10個? 30個? もしかしたら100を超えているかもしれません。

そのうち、いくつが本当に「div(区分)」として意味を持っていますか。多くの場合、答えは「ほとんどゼロ」でしょう。CSSのフックとして、JavaScriptの取得対象として、レイアウトの箱として——私たちは<div>を「意味のない便利な箱」として使っています。それが悪いとは言いません。でも、HTMLという言語は本来、そういうものではなかったはずです。

HTMLは文書に"意味"を与える言語だ。見た目を記述しているのではない。構造を、関係性を、役割を記述している。

「セマンティックHTML」という言葉を聞いたことはあるでしょう。<header>を使いましょう、<nav>を使いましょう、<article>を使いましょう——そういった「正しいタグの選び方」の話だと思っている方が多いかもしれません。それは間違いではないのですが、話の半分にも届いていません。

セマンティクスとは、「このマークアップが何を意味しているか」を人間だけでなく機械にも伝えようとする試みです。そしてこの試みは、HTMLが生まれた1991年から30年以上続いていて、いまだに完成していません。なぜか。それを知ることは、私たちが今日書いているコードの本質を理解することに繋がるはずです。

はじまり——18個のタグはすべて「意味」だった

1991年、ティム・バーナーズ=リーがCERN(欧州原子核研究機構)で最初のHTML仕様を書いたとき、タグはたった18個しかありませんでした。<title><h1><h6><p><a><address>——これらはすべて「意味」を持つタグです。「これは見出しである」「これは段落である」「これはリンクである」。当時のHTMLに見た目を制御する手段はほぼなく、すべてのタグは文書の構造を記述するためだけに存在していました。

バーナーズ=リーにはもっと大きなビジョンがありました。彼は1991年のメーリングリストで、すでにこう書いています——「<H1><H2>のような固定レベルの見出しではなく、ネスト可能な<SECTION>要素と、その中で自動的にレベルが決まる汎用の<H>要素を持つべきだ」と。文書の意味的な構造をもっと柔軟に記述できる仕組みを、彼は最初から求めていたのです。

HTMLの最初の設計は、100%セマンティックだった。「意味のないタグ」は一つも存在しなかった。

しかし現実は、理想とは違う方向に走り始めます。

1991
HTML誕生——18個のセマンティックなタグ

ティム・バーナーズ=リーが最初のHTML仕様を公開。見た目の制御は一切なく、すべてが文書構造の記述だった。

1995
HTML 2.0 ― そして<font>タグの時代へ

Netscapeが独自拡張として<font>、<center>、<blink>を導入。見た目のためのタグが爆発的に増え始める。

1996
CSS 1.0勧告

W3Cが「見た目はCSSに分離すべき」と提案。しかしブラウザの実装は不完全で、普及には長い年月がかかる。

1999
HTML 4.01 ― Strictモードの理想

非推奨要素を明確に分離したStrict DTDが登場。「構造と表現の分離」が仕様レベルで宣言される。

2001
「セマンティックWeb」構想

バーナーズ=リーがScientific American誌で壮大なビジョンを発表。機械が意味を理解するWebの到来を予言。

2008-2014
HTML5 ― セマンティック要素の大量追加

<article>、<section>、<nav>、<aside>、<header>、<footer>、<main>が標準化。セクショニングモデルが導入される。

2022
アウトラインアルゴリズムの削除

HTML5の目玉だったドキュメントアウトラインアルゴリズムが、一度もブラウザに実装されることなく仕様から削除される。

なぜWebは「div地獄」に陥ったのか

セマンティクスが理想であるなら、なぜ現実のWebは<div>だらけになったのでしょうか。これは開発者の怠慢ではありません。構造的な理由があるのです。

理由1:CSSが「意味」ではなく「箱」を求めた

CSSのレイアウトモデルは、要素の「意味」ではなく「ボックス」に対して作用します。Flexboxで並べるのも、Gridで配置するのも、対象は「ボックスとしての要素」です。<nav>を使おうが<div>を使おうが、CSSの動作はまったく同じ。見た目の結果が変わらない以上、開発者には「正しいタグを選ぶ動機」が薄いのです。

理由2:コンポーネント設計がセマンティクスを上書きした

ReactやVueのコンポーネントベース開発では、再利用性が最優先されます。<Card />コンポーネントの中身が<article>であるべきか<div>であるべきかは、使われる文脈によって変わる。結果、「とりあえずdivで囲んでおく」が安全策になりました。

理由3:セマンティックHTML=アクセシビリティ、という認識のずれ

「セマンティックなタグを使いましょう」という啓蒙は、多くの場合「スクリーンリーダーのために」「アクセシビリティのために」と語られます。それ自体は正しいのですが、結果として「アクセシビリティ対応が不要なプロジェクトでは関係ない」という誤った結論を導いてしまった面があります。

divは何も壊さない。だからこそ、divで済ませてしまう。セマンティクスの最大の敵は「動くからいいじゃないか」という合理性だ。

DIV中心の設計
見た目は完璧、意味はゼロ

CSSクラス名に意味を託し、HTML要素そのものは汎用コンテナとして使用。人間が読めばわかるが、機械には構造が見えない。

セマンティックな設計
要素自体が文書構造を語る

article、nav、aside等を使い分けることで、CSSクラスがなくても文書の骨格が機械に伝わる。ただし「正解」を選ぶ判断コストがかかる。

二つの「セマンティック」——HTMLタグとメタデータの世界

ここで整理しておきたいことがあります。「セマンティック」という言葉は、Web制作の文脈で二つのまったく異なるレイヤーを指しているのです。

一つ目は、HTML要素レベルのセマンティクス。<nav>はナビゲーション、<article>は独立した記事コンテンツ——タグの選択によって文書構造を伝える話です。これは私たちが日常的に考える「セマンティックHTML」です。

二つ目は、構造化データ(Structured Data)としてのセマンティクス。Schema.org、JSON-LD、microdata——HTMLの中に埋め込む「メタ情報」によって、「このページは何についてのページなのか」「この人物の名前は何で、所属はどこか」を機械に伝える話です。

💡 視点
HTML要素のセマンティクスが「文書の骨格」を伝えるのに対し、構造化データは「文書の意味・実体・関係性」を伝えます。前者はブラウザとスクリーンリーダーが主な消費者であり、後者は検索エンジンとAIが主な消費者です。この二つは目的も消費者も異なりますが、「機械が意味を理解できるようにする」という根本の動機は同じです。

バーナーズ=リーの壮大な夢

2001年、バーナーズ=リーはScientific American誌に「The Semantic Web」と題した論文を発表しました。そこで彼が描いたのは、Webページ同士が意味レベルでリンクされ、ソフトウェアエージェントが人間に代わって情報を統合・推論してくれる世界でした。「あなたの母親に近い病院で、あなたの保険が使えて、評価が4以上の医師を探す」——そんな検索が、人間がページを一つ一つ開くことなく完了する。そのビジョンです。

この構想はRDF、RDFS、OWLといった重厚な仕様群を生み出しましたが、その複雑さゆえに一般のWeb制作者にはほとんど普及しませんでした。2011年にGoogle、Bing、Yahoo!(後にYandexが参加)が共同でSchema.orgを立ち上げたのは、この「学術的すぎるセマンティックWeb」を実用的な形にやり直そうという試みだったのです。

セマンティックWebは「失敗した」のではない。壮大すぎたのだ。Schema.orgは、その夢を「検索エンジンが使える範囲」に縮小することで初めて普及させた。

Schema.orgがもたらした現実解

Schema.orgは2011年の発足時に297クラス・187リレーションを持ち、2015年時点で638クラス・965リレーションにまで成長しました。そして2015年の調査では、Webページの31.3%がSchema.orgのマークアップを含んでいたと報告されています。推定で1200万以上のサイトがこの構造化データを使っていました。

成功の鍵は「インセンティブの設計」にありました。構造化データを書けば、Google検索結果にリッチスニペットが表示される。レシピサイトなら写真と調理時間が出る。ECサイトなら価格と在庫状況が出る。つまり「意味を記述すれば、実利がある」という仕組みが、普及のエンジンになったのです。

📌 豆知識
構造化データの記述方式は歴史的に三つ存在します。HTML属性に埋め込むRDFa、HTML5仕様の一部として生まれたMicrodata、そしてJavaScriptオブジェクト記法で別ブロックに書くJSON-LD。現在Googleが推奨しているのはJSON-LDで、HTMLの構造を汚さずに意味情報を追加できる点が評価されています。

HTML5の「約束」と「裏切り」

2008年に策定が始まり、2014年に正式勧告となったHTML5は、セマンティクスの観点から言えば「最大の前進」と「最大の挫折」を同時にもたらしました。

前進——新しいセマンティック要素たち

<article><section><nav><aside><header><footer><main><figure><figcaption><time><mark>——HTML5は大量のセマンティック要素を追加しました。これらの要素は「divに名前をつけただけ」ではありません。ブラウザやスクリーンリーダーに対してランドマーク(目印)となり、支援技術がページ構造を理解するための手がかりになります。

HTML5以降のセマンティックな文書構造
<body>
  <header>
    <nav>...</nav>
  </header>
  <main>
    <article>
      <h1>記事タイトル</h1>
      <section>...</section>
      <aside>...</aside>
    </article>
  </main>
  <footer>...</footer>
</body>

挫折——アウトラインアルゴリズムの幻

HTML5の仕様には「ドキュメントアウトラインアルゴリズム」という壮大な構想が含まれていました。<section>の入れ子レベルに応じて、<h1>を何度使っても自動的に適切な見出しレベルが計算される——つまり、バーナーズ=リーが1991年に夢見た「汎用見出し+ネスト構造」が30年越しに実現する、はずでした。

しかし2022年、このアルゴリズムは仕様から正式に削除されました。Bruce Lawsonが指摘した通り、「一度もブラウザに実装されなかった」からです。仕様書にはあるが、どのブラウザもそれを実装しない。開発者は「仕様にあるのだから正しいのだろう」と信じて<h1>を連発し、結果としてスクリーンリーダーには完全にフラットな見出し構造が伝わっていた——という、悲しい乖離が何年も続いていたのです。

仕様書に書かれていることと、ブラウザが実装していることは、必ずしも一致しない。セマンティクスの理想は、実装の現実によって何度も裏切られてきた。

WebAIMの調査によれば、スクリーンリーダーユーザーの85.7%が「見出しレベルは有用だ」と回答しています。アウトラインアルゴリズムが機能していれば、開発者は見出しの入れ子レベルを気にせずにコンポーネントを作れたはずでした。しかし現実には、<h1>から<h6>のレベルを手動で管理し続けなければならない。これは特にコンポーネントベースの開発において大きな摩擦を生んでいます。

セマンティクスは「誰のため」なのか——そして今

セマンティックHTMLが「未完」である本質的な理由に、ここで触れなければなりません。それは「意味の正しさに、即座の報酬がない」ということです。

CSSを間違えれば、見た目が崩れる。JavaScriptを間違えれば、動かない。しかし<article><div>に変えても、何も壊れません。検索順位が即座に落ちるわけでもなく、ページは表示され、リンクは機能する。セマンティクスの「正しさ」に対するフィードバックループが存在しないのです。

しかし、消費者は増えている

状況は変わりつつあります。HTMLの「意味」を消費する主体が急速に増えているからです。

スクリーンリーダーは昔からセマンティクスの消費者でしたが、今やそこにAI、LLM(大規模言語モデル)、音声アシスタント、ブラウザのリーダーモード、RSS的なコンテンツ抽出サービスが加わっています。GoogleのAI Overview(旧SGE)がWebページの内容を「理解」して要約を生成するとき、HTMLの構造は重要なシグナルです。Appleの音声読み上げが<main>の中身だけを読むのも、<nav>をスキップするのも、セマンティックな要素があるからこそ可能なのです。

2005年の消費者
ブラウザとスクリーンリーダー

セマンティクスの消費者は限定的。「アクセシビリティ対応」と同義に語られることが多かった。ビジネス上の動機が弱い。

現代の消費者
AI・検索・音声・抽出ツール

LLM、Google AI Overview、Apple Intelligence、ブラウザのリーダーモード、構造化データ抽出ツール。HTMLの意味を解釈する主体が爆発的に増加。

WAI-ARIAという「補助輪」

HTML要素だけでは表現しきれない意味——たとえばタブUI、アコーディオン、ライブリージョン——を補うために、WAI-ARIA(Web Accessibility Initiative - Accessible Rich Internet Applications)が2014年にW3C勧告となりました。role="tablist"aria-expanded="true"aria-live="polite"——これらの属性は、HTML要素だけでは伝えられないUIの状態と役割を支援技術に伝えます。

ただし、ARIAには重要な原則があります。「ネイティブのHTML要素で表現できるなら、ARIAを使うな」。<button>で済むものに<div role="button">を使うのは、セマンティクスの後退です。ARIAは「HTMLのセマンティクスが足りない場面」を補完するものであり、代替するものではない。この原則が守られないまま使われるARIAは、かえってアクセシビリティを悪化させることすらあります。

⚠️ 注意
WAI-ARIAの第一ルールは「Don't use ARIA(ARIAを使うな)」です。つまり、まずネイティブHTML要素で解決できないかを考え、それで不可能な場合にのみARIAを追加する。この原則は「セマンティックHTMLが基盤であり、ARIAは補助である」という設計思想を端的に表しています。

完成しないことの意味

30年以上かけて「セマンティックHTML」は完成していません。アウトラインアルゴリズムは夢に終わり、セマンティックWeb構想は当初の形では実現せず、divは今日も量産されている。これは「失敗」なのでしょうか。

私はそうは思いません。

HTMLが「許す」言語であること——閉じタグを忘れても壊れない、divで何でも書いても表示される——この寛容さこそが、Webをここまで普及させた力です。もしHTMLが「意味的に正しくなければ表示しない」言語だったなら、90年代のWeb爆発は起きなかったでしょう。セマンティクスが「未完」であることは、Webの寛容な設計思想とのトレードオフなのです。

それでも、セマンティクスは少しずつ「報酬」を持ち始めています。構造化データを書けばリッチリザルトに出る。正しいランドマークを使えばリーダーモードで読みやすくなる。AIがコンテンツを正しく解釈するかどうかに、HTMLの構造が影響する。「意味を書くインセンティブ」が、これまでの30年で最も強くなっているのが今です。

セマンティクスが未完であることは失敗ではない。Webの寛容さとのトレードオフだ。しかし「意味を書くことの報酬」は、AIの時代にようやく十分な大きさになりつつある。

次にHTMLを書くとき、<div>と打つ指を少しだけ止めてみてください。「この要素は何なのか」「これはナビゲーションなのか、記事本文なのか、補足情報なのか」——その1秒の問いが、あなたのマークアップに意味を与えます。完璧でなくていい。全部を正しくする必要もない。ただ、「意味を考える習慣」を持つだけで、あなたの書くHTMLは少しだけ、未来のWebに貢献するものになるはずです。

まとめ

  • HTMLは1991年の誕生時、18個すべてのタグが「意味」を持つ純粋なセマンティック言語だった。見た目のためのタグは一つも存在しなかった。
  • Webの急速な普及に伴い、見た目のためのタグが増殖し、CSSとの役割分離に長い年月がかかった。その間にdiv中心の開発文化が定着した。
  • HTML5は多くのセマンティック要素を追加したが、目玉だったアウトラインアルゴリズムは一度もブラウザに実装されず、2022年に仕様から削除された。
  • 「セマンティック」には二つのレイヤーがある。HTML要素レベルの文書構造と、Schema.org/JSON-LDによる構造化データ。後者はGoogleのリッチリザルト等で実利を生んでいる。
  • セマンティクスが未完な根本理由は「間違えても壊れない」というHTMLの寛容な設計思想とのトレードオフにある。しかしAI・音声アシスタント等、意味を消費する主体が爆発的に増えている現在、セマンティクスの価値はかつてないほど高まっている。
  • WAI-ARIAはHTMLのセマンティクスを「補完」する技術であり、代替ではない。まずネイティブ要素で意味を伝え、足りない部分だけをARIAで補うのが正しい設計。