HTMLとは？あらゆるウェブページの「骨格」を徹底解説

一言でいうと

HTML (HyperText Markup Language) とは、ウェブページで目にするコンテンツを作成し、構造化するために使われる標準的なテキストベースの言語です。建物の設計図みたいなものですね。

HTMLが解決した問題

今の私たちが知るウェブ以前の世界を想像してみてください。そこは、個々のドキュメントがバラバラに存在する、デジタル版の西部開拓時代でした。もしあなたが大学の物理学者で、最新の研究論文を海の向こうの同僚と共有しようとしたら、それはもう大混乱でした。ファイルをメールで送っても、相手がそれを開くための適切なソフトウェアを持っていないかもしれない。フォーマットはぐちゃぐちゃ。共通のリンクなんてものはなく、あるドキュメントから関連する別のドキュメントへ簡単にジャンプする方法もありませんでした。

そこに登場したのが、1980年代後半、CERNにいたティム・バーナーズ＝リーです。彼が直面していた問題は、頭脳明晰で、忙しく、地理的に離れた場所にいる科学者たちが、効率的に情報を共有し、アクセスできるようにすることでした。その解決策は、シンプルで、プラットフォームに依存せず、そして堅牢である必要がありました。彼が必要としていたのは、派手なページレイアウトプログラムではありません。プレーンなテキスト文書に印（マークアップ）を付けて構造を与える方法でした。これは見出し、これは段落、これはリスト、そして何より重要なのが、『このテキストは、あそこにある別のドキュメントにリンクしている』ということ。

この「リンク」こそが魔法の材料、HTMLの「HyperText」たる所以です。バーナーズ＝リーは、SGMLと呼ばれるより古く複雑なシステムから着想を得て、人間が書きやすく、そして同じくらい重要なことに、コンピュータプログラム（「ブラウザ」）が解釈（パース）して表示しやすい、簡略化されたバージョンを作り出しました。

HTMLは、インターネットのための普遍的なドキュメントフォーマットという問題を解決しました。どんなマシンでも理解できる共通言語を作り出し、混沌としたファイルの集まりを、相互に接続された情報の「ウェブ（蜘蛛の巣）」へと変えたのです。見た目を美しくすることは目的ではありませんでした（それは後からCSSが担当することになります）。機能的で、記述的で、そして世界の知識を結びつけるために設計されたのです。

裏側の仕組み

では、山括弧だらけの単純なテキストファイルが、どうやって今あなたが読んでいるようなリッチでインタラクティブなウェブページになるのでしょうか？これはテキストからピクセルへの魅力的な旅であり、いくつかの重要なコンセプトが関わっています。

### タグ、要素、属性：構成要素

HTMLの核心は、タグと呼ばれる特別な指示が付いたただのテキストです。タグは通常、<p>のように、山括弧で囲まれた短くて覚えやすいキーワードです。

ほとんどのタグは、開始タグ (<p>) と終了タグ (</p>) のペアで使われます。このタグのペアとその間のコンテンツ全体を要素と呼びます。

<p>This whole line is a paragraph element.</p>

タグ: <p> と </p> の部分がタグです。これらは段落の開始と終了を示します。
コンテンツ: "This whole line is a paragraph element." というテキストがコンテンツです。
要素: 開始タグ、コンテンツ、終了タグを合わせて <p> 要素を形成します。

一部の要素は「void」または「空」要素と呼ばれ、コンテンツや終了タグを持ちません。これは、画像 <img> や改行 <br> のように、単一で自己完結したものを表すためです。

要素にさらに情報を追加するには、属性を使用します。これらは開始タグ内に記述される name="value" のペアで、追加の設定を提供します。最も有名な例はハイパーリンクです。

<a href="https://flowing.dev">Visit FlowingDev</a>

ここで、<a> はアンカー（リンク）のためのタグですが、それだけでは役に立ちません。href 属性が、ブラウザにリンクがどこに向かうべきかを伝えます。

### DOMツリー：テキストから家系図へ

ブラウザがHTMLファイルを受け取ると、小説のように一行ずつ読むわけではありません。即座にテキストの解析（パース）を開始し、ドキュメントの構造を論理的にメモリ内に表現したものを構築します。この構造が Document Object Model、略して DOM と呼ばれるものです。

DOMを理解する最良の方法は、家系図として考えることです。<html> 要素はすべてのものの始祖です。それには2つの直接の子、<head>（ページタイトルのようなメタデータ用）と <body>（表示されるコンテンツ用）があります。そして <body> 要素は、見出し <h1>、段落 <p>、リスト <ul> といった独自の子を持ち、それらもまた自分の子を持つことができます。

このシンプルなHTMLを考えてみましょう。

<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>A Main Heading</h1>
    <p>Some text and a <a href="#">link</a>.</p>
  </body>
</html>

ブラウザはこのテキストを、次のような論理的なツリー構造に変換します。

  html
  ├── head
  │   └── title
  │       └── "My Page"
  └── body
      ├── h1
      │   └── "A Main Heading"
      └── p
          ├── "Some text and a "
          └── a (href="#")
              └── "link"
          └── "."

このツリーがすべてです。まだビジュアルなページではありませんが、ブラウザが次のステップで使用する構造化されたモデルです。JavaScriptがページ上の何かを変更したり、CSSがスタイルを適用したりする必要があるとき、彼らはテキストファイルを編集しているのではなく、この生きているDOMツリーと対話しているのです。

### ブラウザのレンダリングパイプライン

DOMツリーが構築されると、ブラウザは画面に実際にピクセルを描画するための一連のイベントを開始します。HTMLビューアは、本質的にこのパイプラインのミニチュア版です。

パース（解析）： 見てきたように、ブラウザはHTMLテキストをパースしてDOMツリーを構築します。同時に、見つけたCSSに対しても同じことを行い、「CSSOM」（CSS Object Model）を構築します。
スタイル計算： ブラウザはDOMとCSSOMを組み合わせて「レンダーツリー」を作成します。このツリーには、実際に表示される要素のみが含まれ、それぞれにどのCSSスタイルが適用されるかを把握しています。例えば、DOMの <h1> ノードは font-size: 2em と font-weight: bold になるべきだと判断します。
レイアウト（または「リフロー」）： ここでブラウザは幾何学者になります。レンダーツリーをたどり、すべての要素の正確なサイズと位置を計算します。「この <h1> は幅500px、高さ40pxで、ページの上から20pxの位置にある」といった具合です。テキストがどのように折り返されるか、マージンが要素をどのように押し離すか、ビューポート内のどこにすべてが配置されるかを計算します。
ペイント（描画）： レイアウトの設計図が完成すると、ブラウザはついに画家として行動できます。テキスト、色、ボーダー、画像など、各要素のピクセルをレイヤーに「ペイント」します。
コンポジット（合成）： 最後に、ブラウザはペイントされたすべてのレイヤーを取り、正しい順序で合成して、画面に最終的な画像を表示します。一部の要素が他の要素の上や下にスライドして表示されるように見えるのは、このステップのおかげです。

このパイプライン全体、HTMLの最初の1バイトを受け取ってから最後のピクセルを描画するまでが、ほんの一瞬で行われます。

現場での実話

理論も素晴らしいですが、HTMLの重要性は現場でこそ真に輝きます。

### フッター家出事件

新人開発者のサムは、頭を抱えていました。彼は3時間もかけて、なぜウェブサイトのフッターがページの途中、メインコンテンツのど真ん中に表示されてしまうのかを解明しようとしていました。CSSは正しく見え、テンプレートのロジックも問題なさそうです。藁にもすがる思いで、最終的にレンダリングされたページのHTMLソースを表示し、ビューアに貼り付けてみました。すると即座に、ビジュアルレンダリングが全く同じ壊れたレイアウトを示しました。その隣のソースコードをスキャンしていると、彼の目に飛び込んできたのは、閉じられていない <div> タグ、<div class="sidebar"> でした。ブラウザはクラッシュしないように英雄的な試みとして推測を行い、フッターを含むページの残りの部分が、そのサイドバーの内部にあるべきだと判断したのです。

教訓： ブラウザは壊れたHTMLに対して信じられないほど寛容ですが、そのエラー修正は、静かで不可解なレイアウトのバグにつながることがあります。あなたが書きたかったことは問題ではなく、ブラウザがパースしたことだけが重要なのです。

### 消えたメールプロモーション事件

あるマーケティングチームが、新製品の発売のために豪華なHTMLメールのデザインに1週間を費やしました。ブラウザベースのエディタでは、アニメーションGIF、カスタムフォント、しゃれたボタンなど、完璧でした。彼らはテストキャンペーンを送信しました。結果は惨憺たるものでした。オーディエンスの半分（特に企業のOutlookを使っている人々）にとって、メールはごちゃ混ぜのテキスト、壊れた画像アイコン、そしてただの青いリンクの塊でした。彼らはそれを現代のウェブページのように構築してしまっていたのです。HTMLビューアを使ってより基本的なレンダリング環境をシミュレートしてみると、彼らは自分たちの過ちに気づきました。メールクライアントは現代のブラウザではありません。それらは2005年から来たデジタルなタイムカプセルのようなものです。しゃれた <div> レイアウト、CSSアニメーション、ウェブフォントは無視されるか、完全に削除されていました。彼らは、昔ながらの、絶対に壊れない <table> レイアウトを使って作り直さなければなりませんでした。

教訓： レンダリングコンテキストが王様です。Chromeで完璧に機能するHTMLも、メールクライアントのようなより厳格な、あるいは古い環境では完全に崩壊する可能性があります。

### SEO強盗事件

あるEコマースサイトの主力商品「職人技のコーヒーグラインダー」のGoogleからのトラフィックが突然急落しました。ページはユーザーには全く同じに見えました。SEOコンサルタントのマリアが呼ばれました。彼女はただページを見るだけでなく、その骨格を見ました。右クリックで「ソースを表示」し、HTMLをコピーしました。彼女の分析は迅速でした。最近のサイトリニューアルで、正しく <h1>職人技のコーヒーグラインダー</h1> タグを使っていたメインページのタイトルが、一般的な <span class="big-fancy-title">職人技のコーヒーグラインダー</span> に置き換えられていたのです。人間にはテキストは同じに見えました。しかし、Googleのクローラーにとっては、そのページにはもはや明確な主要な見出しがありませんでした。ページのトピックに関する最も重要なセマンティックなシグナルが消去されてしまったのです。

教訓： HTMLは単なるスタイリングのためだけではありません。それは意味を伝えます。仕事に適したタグ（セマンティックHTML）を使うことは、アクセシビリティと検索エンジン最適化にとって極めて重要です。

よくある間違いと落とし穴

Div-itis（div病）： 何にでも <div> を使うのは古典的な間違いです。ボタンが必要ですか？ <button> を使いましょう。ナビゲーションバーが必要ですか？ <nav> を使いましょう。リストが必要ですか？ <ul> を使いましょう。セマンティックなタグを使うことで、サイトはスクリーンリーダーにとってよりアクセシブルになり、検索エンジンにとってより理解しやすくなります。
altテキストの忘れ： 情報を伝えるすべての <img> タグには、画像を説明する alt 属性が必要です。画像の読み込みに失敗した場合、alt テキストが表示されます。さらに重要なことに、これはスクリーンリーダーが視覚障害のあるユーザーに読み上げる内容です。純粋に装飾的な画像の場合は alt="" とします。
不適切なネスト： タグは開いたのと逆の順序で閉じなければなりません。<b><i>太字と斜体</i></b> は正しいです。<b><i>太字と斜体</b></i> は壊れています。現代のブラウザはしばしばそれを正しくレンダリングしますが、技術的には無効であり、特に複雑なDOM操作で予測不可能な動作を引き起こす可能性があります。
インライン要素内にブロック要素を使用する： ブロックレベル要素（<div> や <p>など）をインライン要素（<span> や <a>など）の中に入れてはいけません。ブラウザはそれをレンダリングするかもしれませんが、HTML標準に違反しており、奇妙なレイアウトやスタイリングの問題につながる可能性があります。
どこでも同じように見えると仮定する： ウェブの美しさと呪いは、あなたのHTMLが何千もの異なるデバイス上の何十もの異なるブラウザエンジンによってレンダリングされることです。あなたのビューアやデスクトップのChromeで完璧に見えるものが、iOSのSafariでは少し違って見えるかもしれません。常に主要なターゲットデバイスでテストしてください。

なぜアンテナを張っておくべきか

あなたがゴリゴリのバックエンドエンジニアであれ、データサイエンティストであれ、UI/UXデザイナーであれ、HTMLからは逃れられません。それはウェブの共通言語なのです。

デバッグのために： あなたの素敵なJavaScriptフレームワークが奇妙なUIを吐き出したとき、最終的な責任はそれが生成したHTMLにあります。最終的なDOMを読んで理解できることは、基本的なデバッグスキルです。
パフォーマンスのために： 肥大化し、深くネストされたHTMLは、レイアウトとペイントの時間を遅くします。HTMLの構造を理解することは、高速でレスポンシブなサイトを構築するための第一歩です。
セキュリティのために： 誤解されたHTMLは、セキュリティホールにつながる可能性があります。例えば、ユーザーが提供したデータを適切にサニタイズせずにHTMLに注入している場合、クロスサイトスクリプティング（XSS）攻撃に対して脆弱になる可能性があります。
コミュニケーションのために： デザイナーがモックアップを渡してきたとき、あるいはフロントエンドのバグを同僚に説明する必要があるとき、HTMLの要素、属性、DOMツリーについて流暢に話せることで、会話が10倍効果的になります。

要するに、あなたの仕事が何らかの形でウェブブラウザに触れるのであれば、HTMLの基礎をしっかりと把握することは選択肢ではなく、土台そのものなのです。

さらに深く学ぶ

MDN Web Docs: HTML basics - あらゆるウェブ開発者にとって最高の出発点です。明確で、包括的で、例が豊富です。
HTML Living Standard (WHATWG) - HTMLの公式で正典となる仕様です。内容は濃く、非常に技術的ですが、究極の真実の源です。
The History of HTML on Wikipedia - 学術的なルーツから今日私たちが使用するHTML5標準までのHTMLの進化についての素晴らしい概観です。
W3C Markup Validation Service - 単なるツールではなく、教育です。自分のHTMLをバリデータにかけることは、ルールやベストプラクティスを学ぶための素晴らしい方法です。

HTMLとは？ あらゆるウェブページの「骨格」を徹底解説