HTMLは山かっこで開け閉めする箱だ — タグ、headとbody
あるウェブサイトを思い浮かべてみよう。いちばん上にロゴとメニューがあり、その下に大きなバナー、事例を横にめくって見るスライド、相談申し込み欄がある。いちばん下には事業者情報や個人情報保護方針のリンクが集まった領域があり、これをフッターと呼ぶ。ブラウザ（ChromeやSafariのようにウェブページを開くプログラム）では絵のように見えるが、実際にはこの構造を書いたコードがある。そのコードがHTMLだ。
HTMLは山かっこで約束を決めた。<html>のように山かっこの中に名前を書くと箱が開き、</html>のように名前の前にスラッシュ（/）を入れると同じ名前の箱が閉じる。この一対をタグという。箱の中にはさらに別のタグを入れられるので、外側のタグを親、内側のタグを子と呼ぶ。いちばん外側の親はhtmlタグと決まっている。
htmlの中の最初の子は二つある。目に見えないheadと、目に見えるbodyだ。講義はこの名前を便箋にたとえた。便箋の上部でロゴや宛先を入れる場所をレターヘッドと呼ぶように、headには画面に描かれないこのページの基本情報が入る。検索エンジンがこのページを理解するのに必要な情報や、このページが呼び込む別のファイルへのつながりといったものだ。bodyは文字どおり胴体、私たちが見る画面のすべてだ。
headの中の代表的なタグが二つある。ページの基本情報を書くmetaタグは例外的に、閉じタグなしの一つで終わる。titleタグは開いて閉じ、その間に書いた文字がブラウザ上部のタブに出るページタイトルになる。
自分の目で見ることもできる。どのウェブページでもF12キーを押すと（Chromeの場合。MacではCmd+Option+Iを押すか、右上の点三つのメニューにあるツールの項目から開く）デベロッパーツールという画面が開き、そのページのHTMLが見える。ただしバイブコーディングで作ったプロジェクトのファイルでは、こうしたHTMLの原文はほとんど目にしない。今は別の枠組みの上で書いたコードを、インターネットに載せる時点でまとめてHTMLに組み立てる方式が一般的だからだ。
<html>
<head>
<meta charset="utf-8">
<title>相談申し込み</title>
</head>
<body>
<!-- 目に見える画面のすべてがここに -->
</body>
</html>タグ名は好きに付けてもいいのに、なぜみな同じ名前を使うのか — セマンティックマークアップ
bodyの中に入れるタグ名は、実は好きに付けても動く。講師は自分のイニシャルを取って<yss>というタグを開け閉めしてもかまわないと例を挙げた。ところが複数のサイトをデベロッパーツールで開いてみると、同じタグ名が何度も出てくる。
理由は検索だ。SEO（検索エンジン最適化、検索エンジンが自分のページをよく見つけて理解するようにすること）とGEO（生成AI最適化、AIが質問に答えるとき自分のページを根拠にするようにすること）では、ページの構造が約束どおりに書かれているかが大事になる。検索エンジンとAIが、タグ名だけでその部分がメニューなのか入力フォームなのかを見分けられなければならないからだ。そこで、みなが使う名前で書こうという約束が生まれた。これをセマンティックマークアップ（意味が伝わるタグの書き方）という。
最初に思い浮かべたウェブサイトに当てはめるとこうなる。いちばん上のメニューの帯はナビゲーションバー、その中で押すと移動するメニュー一つ一つはナビゲーションアイテムと呼び、タグはnavを使う。一区画ずつ分かれた領域はsectionだ。相談申し込み欄のように入力し、選び、送信するまとまりはformだ。Googleでアンケートを作るときに使うGoogleフォームのあのフォーム、つまり書式である。
formの中で短い文字を入力する欄はinputで、metaと同じく閉じタグがない。押すボタンはbuttonだ。formには、送信を押したとき入力値をどこへ送るかを書く場所がある。フッターの利用規約や個人情報保護方針のように押すと別のページへ移るリンクはa、リストは全体をulで包み、項目一つ一つをliで書く。
約束を破っても画面は表示される。約束は、この部分が何を意味するのかを読む側に伝える目印だ。バイブコーディングがなかった頃は使いながらこれらの名前を覚えたが、数はそれほど多くないので、暗記するというより何度か見れば慣れるものだと講義は言う。
| 画面に見えるもの | タグ | 講義の例 |
|---|---|---|
| いちばん上のメニューの帯 | nav | ロゴとメニューのあるナビゲーションバー |
| 一区画ずつ分かれた領域 | section | バナー、事例スライド、相談申し込み欄 |
| 入力・選択・送信のまとまり | form | 相談申し込みフォーム |
| 短い文字の入力欄 | input（閉じタグなし） | 名前、連絡先 |
| 押すボタン | button | 送信 |
| 別のページへ移るリンク | a | 利用規約、個人情報保護方針 |
| リスト | ul（全体）・li（項目） | チェックリスト |
属性とclass — styleが長くなってCSSへ切り出した
タグ名の後ろ、山かっこを閉じる前には、さらに設定値を書ける。名前=値の対で書くこの設定を属性（attribute）という。属性名も原則として好きに付けられるが、タグと同じく、よく使われる名前が決まっている。
もっとも代表的な属性がclassだ。classがなぜ生まれたかから見よう。HTMLしかなかった頃は、構造だけ書けば足りた。けれども人々はもっと見栄えよく飾りたくなった。画面の区画を分けるときによく使うdivタグ（divisionの略、区画の意）にstyle属性を付けてbackground: redと書くと、その区画の背景が赤く塗られる。
問題は、飾りが背景色一つで終わらないことだった。内側の余白、枠線、ほかのタグとの距離、横に並べるか上下に積むかまで書いていくと、タグ一つが際限なく長くなる。人が読みにくく、同じ飾りがあちこちのページで繰り返される。そこで飾りの情報をCSS（Cascading Style Sheets、飾りだけをまとめておく別の文書）へ切り出し、飾りのまとまりごとに名前を付けて、タグにはその名前だけを書くようになった。その名前を書く場所がclassだ。デベロッパーツールでどのサイトを開いても、ほとんどのタグにclassが付いているのはこのためだ。
特別な機能が約束された属性もある。画像を表示するimgタグにsrc属性を付けてアドレスを書くと、そのアドレスに保存された画像が画面に出る。06回の事例カードとつながる部分だ。カードの画像を管理者がアップロードしたのなら、このsrcに入る画像のアドレスも、データベース（表計算のように行と列で値を保存しておく場所）に保存された値である。
<!-- style属性に飾りを直接書くと長くなる -->
<div style="background: red; padding: 16px; border: 1px solid black; display: flex;">メニュー</div>
<!-- 飾りはCSSへ切り出し、タグには名前だけ書く -->
<div class="nav-bar">メニュー</div>
<!-- imgのsrc属性 = 画像が保存されたアドレス -->
<img src="https://example.com/case-01.jpg">コンポーネント — カードやダイアログのようによく使う部品に付いた名前
タグに約束された名前があるように、画面の部品にもみなで共有する名前がある。これをコンポーネントという。06回の事例一覧では、タイトル・顧客・画像・日付が入った四角が繰り返されるが、これをカードと呼ぶ。HTMLにcardというタグがあるわけではない。人々がその形をカードと呼ぶことにしたのだ。送信を押したのに入力が抜けていて警告の窓が出たなら、その窓はダイアログだ。
ある意図を画面に表すときによく使う部品をあらかじめ作っておいたものがコンポーネントで、アルファベットのAからZまで並べられるほど種類が多い。何を作るにしてもほぼ必ず使うものなので、誰かがあらかじめ作ったものを持ってきて使うのが今の一般的な開発のやり方だ。
バイブコーディングでよく出会うのがshadcn/uiだ。講義は名前の末尾のcnをclassName、つまり前の節で見たclass名の略だと説明した。styleが長くなってclassにまとめたように、class名のまとまりをあらかじめ作り、コンポーネント単位で持ってきて使えるように集めたライブラリ（持ってきて使う部品の集まり）だという説明だ。同じことをする集まりは名前の違うものも多く、講師が以前よく使ったBootstrapもその一つだ。当時はこうした集まりが使うclass名の規則を覚えながら使ったが、今はその必要はないと講義は言う。補足すると、名前のshadcnはこのライブラリを作った人のIDだ。shadcn/uiのコードの中でclass名をまとめる道具の関数がcn()という名前なので、講義の説明はこう覚えると便利だという意味で受け取ればいい。
覚える必要はない代わりに、名前は知っておく必要がある。講義はこれをUI（ユーザーが見て押す画面の要素）伝達力と呼ぶ。AIに「事例を見栄えよく見せて」と言うのと、「事例をカードで並べて、入力が抜けたまま送信したらダイアログで知らせて」と言うのとでは、返ってくる結果が違う。部品の名前を知っていれば欲しい画面を言葉にでき、AIが作った画面を見て何が足りないかも指摘できる。
今日やってみることは一つだ。shadcn/uiのサイト（ui.shadcn.com）に入り、メニューのComponentsを開く。AからZまでコンポーネントがずらりと出てくる。あれこれ押してみながら、この部品はどんな意図を表すために作っておいたものなのかを一つずつ確かめる。
使っているアプリの画面をデータと状態で観察する
コンポーネントを押していくと共通点が見えてくる。ほとんどがデータを扱うか、データによって見た目が変わる。05回の相談申し込みフォームは入力値をデータベースに保存する流れに沿い、06回の事例カードのフィルターは、いま何を見せるかを持つ状態（state、画面が覚えている現在の選択値）で動いていた。
講義が勧める見方がこれだ。画面の裏にはデータベースに保存されたデータがあり、その画面をそう表示するための状態がある、ということを下に敷いて画面を見る。すると普段使っているアプリに面白いものがたくさん見えてくる。
Airbnbを開いて、中のボタンがどう動いているかを見る。Threadsを開いてみる。普段使っているアプリを開き、その中で動くUIをじっくり見る。この一覧はどんなデータの配列（複数の値を角かっこでくくった一覧）なのか、このタブは見た目が違うだけのラジオボタン（いくつかの中から一つだけ選ぶボタン）なのか、いま押されている選択はどんな状態として覚えられているのか、と問いかけるやり方だ。
観察したことをAIに渡すときは、コンポーネント名とデータ・状態を一緒に書く。以下は06回の事例カードのセクションをそのように書き直した依頼文の例だ。
これで連載「画面の裏のデータ」を終える。01〜04回はERD（データをどの表に分けて入れ、どうつなぐかを描いた設計図）の講義に沿ってデータがどう保存されるかを、05〜07回はHTMLの講義に沿ってそのデータが画面でどんな形で現れるかを見た。講義は、HTMLを知ることはバイブコーディングの企画と設計に長く役立つ知識だという言葉で締めくくる。画面を部品の名前とデータ・状態で語れれば、AIに任せる仕事もそれだけ正確になる。
事例セクションを作って。shadcn/uiのコンポーネントを使って。
- 事例一つはカード（Card）で見せて。カードにはタイトル、顧客、画像、日付が入る。
- 事例データは管理者が登録したものを読み込んで。画面に固定値で埋め込まないで。
- 事例ごとに、画面には見えない種類（A・B・C）の値がある。
- カード一覧の上に、すべて・A・B・Cをタブ（Tabs）で外に出して見せて。ドロップダウンの中に隠さないで。
- いま選ばれているタブは状態で管理して、一度に一つだけ選べるようにして。