AIがコードを書く時代にHTMLとCSSを勉強し直してみた話

最近、Webページの画面づくりは、ほとんどAIに任せています。「こんなページを作って」と頼むと、それらしいページが数十秒でできあがります。

そうなると、「HTMLとCSSを今から勉強する意味はあるの？」と思いますよね。私もそう考えるようになりました。

ひとこと解説

• HTML：ページの「中身と骨組み」を書く言語です。見出し、文章、ボタンなどを並べます。
• CSS：ページの「見た目」を決める言語です。色、大きさ、配置などを指定します。

先に結論を書いておくと、私の答えは「勉強する意味はある。ただし、勉強のしかたは変わった」です。そう考えるようになった経緯を、メモとして残しておきます。

そもそも何を疑問に思っていたのか

疑問は、次の2つでした。

• AIが書けるものを、人間も書けるようになる必要はあるのか
• 必要だとしたら、どこまで覚えればいいのか

海外でも、同じような話題はよく見かけます。たとえば、エンジニア向けの投稿サイト DEV Community には、Is Learning HTML & CSS Still Worth It in the Age of AI?（AI時代でもHTMLとCSSを学ぶ価値はある？）のような記事がいくつもありました。

多くの記事は「基礎は必要」という結論です。

ただ、正直なところ、最初はあまりピンときませんでした。「基礎は大事」と言われても、基礎を知らないと具体的に何が困るのかが分からなかったからです。

AIが書いたHTMLを読み直してみる

そこで、AIが書いたコードを、自分の目で1行ずつ読んでみることにしました。

きっかけはレビューで指摘されたからでした。

画面の見た目は問題ありません。クリックすれば、ちゃんと動きます。ところが中身を見ると、次のようなコードが混ざっていました。

html

<div class="btn" onclick="openModal()">詳細を見る</div>

これは「ボタンのように見える箱」です。div は、もともと特に意味を持たない入れ物のタグです。そこにCSSでボタンっぽい見た目を付け、onclick（クリックしたときに動く処理）を付けています。

本来は、ボタン専用のタグである button を使って書くところです。

html

<button type="button" onclick="openModal()">詳細を見る</button>

div で書いても、マウスでクリックすれば動きます。では、何が困るのでしょうか。

• キーボードで操作できない：Tab キーを押すと、操作できる部品に順番に移動（フォーカス）できます。しかし div はこの対象にならないため、マウスを使えない人は押せません。
• 画面読み上げソフトに伝わらない：目の見えにくい人は、「スクリーンリーダー」という、画面の内容を音声で読み上げるソフトを使います。div だと「これはボタンです」と伝わりません。

どちらも、見た目を確認しているだけでは気づけない問題でした。

ひとこと解説

• アクセシビリティ：障害の有無や使う道具に関係なく、誰でもWebページを使えるようにする考え方です。
• type="button" は「これは普通のボタンです」という指定です。フォームの中で使うときに、意図せずフォームが送信されるのを防げます。

Web開発の学習サイト Frontend Masters の AI-Generated UI Is Inaccessible by Default（AIが作るUIは、そのままだとアクセシブルではない）という記事でも、同じ傾向が指摘されています。div に onClick を付ける書き方や、aria-* 属性の付け忘れが多いそうです。理由としては「AIが学習したコードに、そういう書き方が多いから」と説明されていて、納得しました。

ひとこと解説

• aria-* 属性：スクリーンリーダーなどに「この部品は何か」「今どんな状態か」を伝えるための追加情報です（例：aria-label、aria-expanded）。

ここで気づいたのは、AIの出力が正しいかどうかを判断するには、自分が正しい書き方を知っている必要があるということです。当たり前のことですが、実際に手を動かすまで実感がありませんでした。

CSSは「直してもらう」ときに困った

CSSでも、似たようなことがありました。

レイアウト（部品の並びや配置）が崩れたときにAIに直してもらうと、たいていはその場で直ります。ただ、直し方が「とりあえず見た目を合わせる」ものになることがあります。たとえば、こんなコードです。

css

.card {
  margin-top: -12px;   /* 上の余白をマイナスにして、無理やり上にずらす */
  position: relative;  /* 位置を調整できるようにする */
  z-index: 999;        /* 重なり順を、とにかく一番手前にする */
}

その画面では、見た目がきれいに合います。しかし、スマホなど別の画面幅で見ると崩れます。崩れたところをまたAIに直してもらうと、別の数値がどんどん足されていきます。根本の原因が直っていないので、修正が終わらないのです。

本当の原因は、親要素の display: flex と gap の指定でした。そこで、一度 flexbox の仕組みを理解してから、AIへの頼み方を変えてみました。すると、修正は1回で済みました。

ひとこと解説

• flexbox（display: flex）：部品を横や縦にきれいに並べるためのCSSの仕組みです。
• gap：並べた部品どうしのすき間を指定します。
• margin：部品の外側の余白です。gap と margin を両方使うと、余白が二重になって崩れる原因になることがあります。

AIに「直して」とだけ頼むのと、「親要素の gap が効いていないので、子要素の margin を外して」と原因まで伝えて頼むのとでは、返ってくるコードの質がかなり違うと感じました。原因が分かっていれば、AIへの指示も正確になるということです。

どこまで勉強するかを決める

すべてを暗記する必要はないと思っています。私は、次のように線を引きました。

自分で理解しておくもの

• よく使うタグの使い分け（button、a、nav、main、label など）
  • 「意味に合ったタグ」を使うことを、セマンティック（意味的）なHTMLと呼びます
• flexbox と grid（部品を並べる仕組み）の基本的な動き
• ボックスモデル（部品の中身・内側の余白・枠線・外側の余白の関係）と、position（位置指定）がどんなときに効くか
• アクセシビリティの最低限（キーボードで操作できるか、画像の代わりの説明文 alt、入力欄のラベル）

AIに任せるもの

• 細かいプロパティ名や値の暗記
• アニメーションやグラデーションの細かい調整
• ブラウザ（Chrome、Safari など）ごとの細かい違いの調べもの

線を引く基準は、「AIの出力を読んで、おかしいと気づけるかどうか」です。ゼロから書けなくても、読んで判断できれば十分な場面は多いと思います。

逆に、あえてやらなかったこともあります。HTML/CSSの入門書を1冊まるごと読み直すのはやめました。最初から全部やるよりも、AIの出力で「あれ？」と引っかかったところから調べるほうが、自分には合っていました。

まとめ

HTMLとCSSを勉強する意味はある、というのが今の考えです。ただし、目的は「ゼロから書けるようになる」から「AIが書いたコードをチェック（レビュー）できるようになる」に変わったと感じています。

少し意外だったのは、AIに任せる量が増えるほど、基礎の知識が役に立つことです。AIへの指示の正確さも、出てきたコードのチェックの正確さも、結局は自分の理解の深さで決まっていました。

次は、AIに作らせた画面を axe などのツールで自動チェックする方法を試してみたいと思います。axe は、アクセシビリティの問題を自動で見つけてくれるツールです。人の目だけでは見落としが出るので、どこまで自動化できるかを確かめるつもりです。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

• 選考ではありません
• 履歴書不要
• 技術の話が中心
• 所要時間30分程度
• オンラインOK

エンジニアと話してみる