AIが生成したHTML/CSSの品質を検証する ─ 納品前チェックで見つかる問題パターン

株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。

うちでは記事「コーディング代行にAIを導入して変わったこと」でもお話しした通り、AIを使ったコーディングを日常的に行っています。AIが出力するコードの「初期精度」は確実に上がっていて、見た目は正しく表示されるケースが増えました。

ただ、「見た目が正しい」と「納品できる品質」の間には、まだ差があります。

うちの納品前チェックでAI生成コードに繰り返し見つかる問題パターンを、今回は具体的にまとめます。コーディング代行を発注する側のWebディレクターにとっても、「何をチェックすべきか」の参考になるはずです。

問題パターン1：見出し階層の乱れ

AIが生成するHTMLで最も多い問題がこれです。

<!-- AIが出したコード -->
<h1>サービス紹介</h1>
<h3>コーディング代行</h3>  <!-- h2を飛ばしてh3 -->
<p>HTML/CSSのコーディングを代行します。</p>
<h4>対応範囲</h4>
<h2>実績紹介</h2>  <!-- 突然h2に戻る -->

見出しレベルが飛んだり、前後で不整合が起きたりします。ブラウザの表示上は問題ありませんが、以下の2つの観点で問題です。

• アクセシビリティ：スクリーンリーダーは見出し階層をナビゲーションに使います。階層が壊れていると、視覚障害のあるユーザーがページ構造を把握できません
• SEO：Googleのクローラーは見出し階層からコンテンツの構造を理解します。不自然な階層はクロール品質に影響する可能性があります

うちの納品基準では、h1はページ内に1つ、h2→h3→h4の順で飛ばさない、というルールを設けています。AIの出力は、セクション単位で生成させるとセクション内のh2がh1になりやすい。統合時に人間が階層を調整する必要があります。

問題パターン2：不要なdivの入れ子

AIはdivを多用する傾向があります。

<!-- AIが出したコード -->
<div class="section">
  <div class="section-inner">
    <div class="section-content">
      <div class="content-wrapper">
        <h2>サービス紹介</h2>
        <p>テキスト</p>
      </div>
    </div>
  </div>
</div>

4層のdivが入れ子になっていますが、実際にスタイリングに必要なのは2層程度です。不要なdivが増えると、以下の問題が起きます。

• CSSのセレクタが深くなり、保守性が下がる
• DOMのノード数が増えてレンダリングパフォーマンスに影響する
• 後から構造を理解するのに時間がかかる

AIは「念のため」ラッパーを追加する傾向があります。デザインカンプの余白やレイアウトを実現するために必要だと判断しているようですが、CSSのFlexboxやGridを使えば不要なケースがほとんどです。

問題パターン3：!importantの安易な使用

これは以前の記事でも触れましたが、繰り返し発生するため改めて取り上げます。

AIが既存のCSSと組み合わせてスタイルを書くとき、競合を解消するために!importantを使い始めることがあります。1箇所使うと、その後の修正でも!importantが必要になり、連鎖的に増えていきます。

うちでは!importantの使用をCSSリセットやユーティリティクラスの一部に限定しています。AIの出力に!importantが含まれていた場合は、セレクタの詳細度を見直して解消するようにしています。

問題パターン4：alt属性の品質

AI生成コードのalt属性には3つのパターンがあります。

正しいaltは画像の内容を説明するものです。たとえば企業サイトのヒーロー画像ならalt="オフィスで打ち合わせをするチームメンバー"のように、何が写っているかを記述します。

AIはデザインカンプからテキスト情報を読み取れますが、画像の「内容」を正確に説明するaltを書くのは苦手です。これは画像のコンテキスト（そのページで画像が果たしている役割）を理解する必要があるためで、現状は人間が書くべき領域です。

問題パターン5：メディアクエリの散在

AIにセクション単位でコードを生成させると、各セクションごとに個別のメディアクエリが書かれます。

/* セクション1のレスポンシブ */
@media (max-width: 768px) {
  .hero { ... }
}

/* セクション2のレスポンシブ */
@media (max-width: 768px) {
  .service-list { ... }
}

/* セクション3のレスポンシブ */
@media (max-width: 768px) {
  .footer { ... }
}

同じブレイクポイントのメディアクエリが3箇所に散在しています。動作には問題ありませんが、CSSの管理という点では以下の問題があります。

• 同じブレイクポイントの変更が必要になったとき、全箇所を探して修正する必要がある
• CSSファイルのサイズが無駄に増える
• チームでの保守が難しくなる

うちではメディアクエリの管理方法（ブレイクポイントごとにまとめるか、コンポーネントごとに書くか）を案件ごとに規定しています。AIの出力をそのまま使うと、この規定に合わないケースがほとんどです。

問題パターン6：Lighthouseスコアへの影響

AI生成コードをそのまま使った場合と、人間がリファクタリングした場合で、Lighthouseスコアを比較したことがあります。コーポレートサイトのトップページ（7セクション構成）での検証結果です。

なお、この数値は1つのプロジェクトでの検証結果であり、ページの構成やコンテンツによって結果は変わります。

Performance の差は、主に不要なDOMノード数（パターン2）と、CSSの未使用セレクタの多さに起因しています。Accessibility の差は、見出し階層（パターン1）とalt属性（パターン4）が主な原因です。

チェックリスト

これらの問題パターンを踏まえて、うちで使っている納品前チェックリストの一部を共有します。

HTMLのチェック：

• 見出し階層がh1→h2→h3の順で正しいか
• 不要なdivの入れ子がないか（3層以上の入れ子は要検討）
• セマンティックHTMLが適切に使われているか（nav、main、section、article、aside）
• 画像のalt属性が適切に設定されているか
• フォーム要素にlabel要素が紐づけられているか

CSSのチェック：

• !importantが不要に使われていないか
• メディアクエリの管理方法がプロジェクトの規定に沿っているか
• 未使用のセレクタがないか
• マジックナンバー（根拠不明な数値）がないか
• ベンダープレフィックスが最新の対応状況に合っているか

パフォーマンスのチェック：

• Lighthouseスコアが基準値を満たしているか
• DOMノード数が適正か（Lighthouseは800ノードで警告、1,400ノードでエラー）
• CSSファイルサイズが適正か

まとめ

AIが生成したHTML/CSSの品質検証について、うちの現場で繰り返し見つかるパターンをまとめました。

「見た目が正しい」と「納品できる品質」は別物です。見出し階層、不要なdiv、!important、alt属性、メディアクエリの管理。これらは表示上は問題がなくても、アクセシビリティ、保守性、パフォーマンスに影響する項目です。

AIの出力精度は確実に向上しています。ただ、「そのまま納品できるか」と聞かれれば、現時点では「チェックと修正が必要」が正直な回答です。うちではこのチェックと修正こそが、コーディング代行の付加価値だと考えています。

コーディング代行の品質基準やAI生成コードの検証について相談したいという方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご連絡ください。