AIが書いたHTML/CSS、そのまま使って大丈夫？受け入れ前チェックリスト15項目【コピペOK】

2026年7月2日

AI × Web制作

AIにHTML/CSSを書いてもらうと、たしかに「動くもの」が返ってきます。ただ、このまま使っていいのかと聞かれると、自信を持ってYESと言えない——そんなモヤモヤはないでしょうか。

前回の記事「AIにコーディングを任せる前に、人間が決めておくべき3つのこと」では、受け入れ基準を先に決めることをお伝えしました。本記事はその実践編です。決めた基準で実際に検品するための、Web制作（LP・コーポレートサイトのHTML/CSS）に特化したチェックリスト5軸15項目を、コピペOKの形で用意しました。

この記事で分かること

AI生成コードに検品が必要な理由（データで確認）
コピペで使える受け入れチェックリスト【5軸15項目】
各項目の見方と、チェックする順番

「動くコード」と「受け入れられるコード」は違う
AI生成HTML/CSS 受け入れチェックリスト【コピペOK・5軸15項目】
各チェック軸の見方 — どこをどう確認するか
チェックリストは「基準を決める→検品する」のセットで使う
よくある質問（FAQ）
まとめ
関連記事

「動くコード」と「受け入れられるコード」は違う

チェックリストに入る前に、なぜ検品が必要なのかを短く確認しておきます。

AIのコードは「動く」ことが多いからこそ危ない

AIが生成するHTML/CSSは、たいてい一発でそれらしく表示されます。エラーで止まらないぶん「動いているからOK」とレビューなしで通過しやすい——ここが一番の落とし穴だと感じています。

表示されることと、納品物として受け入れられることは、別の話です。

データで見る: AI普及期に重複コードが急増している

「動く＝品質ではない」ことを示すデータがあります。

2020〜2024年の2億1,100万行超のコード変更を分析した調査では、5行以上の重複コードブロックの割合が、それまでの1%未満から2024年には6.66%へ急増したと報告されています。

出典: GitClear「AI Copilot Code Quality」レポート（日本語要約）

重複コードは「動くのに保守しづらい」コードの典型です。動くかどうかだけを見ていると、この種の品質低下には気づけません。

納品した瞬間、それは「自分のコード」になる

AIが書いたコードでも、コピペして納品した時点で責任は自分に移ります。クライアントから見れば、誰が書いたかは関係ありません。

とはいえ「AIのコードは危ない」という話ではなく、動くコードを出せるようになったからこそ、次は検品の目を持つ段階だ、ということです。何をどの順で見ればいいのか——それが次のチェックリストです。

AI生成HTML/CSS 受け入れチェックリスト【コピペOK・5軸15項目】

まずはリスト全文です。そのままコピペして、案件のメモやタスク管理に貼り付けて使ってください。

Markdown

## AI生成HTML/CSS 受け入れチェックリスト（5軸15項目）

(1) 表示・デザイン再現
- [ ] カンプ・参考デザインとの目視差分がない
- [ ] ダミーテキスト・仮画像・不要コメント・未使用クラスが残っていない
- [ ] 実ブラウザ（Chrome＋iOS Safari）で崩れがない

(2) レスポンシブ・モーション
- [ ] モバイル・タブレット・PCの各幅で崩れ・横スクロールがない
- [ ] 中間幅のリサイズで、はみ出し・不自然な改行がない
- [ ] prefers-reduced-motion に配慮している（アニメーションがある場合）

(3) HTML構造・アクセシビリティ
- [ ] 見出し階層に飛びや見た目目的の流用がない
- [ ] 画像のaltが適切（装飾画像は空alt）
- [ ] Tabキーだけで全操作でき、フォーカスが見える
- [ ] role/ariaの盛りすぎ・欠落がない

(4) CSS設計・命名
- [ ] 案件の命名規則と整合している
- [ ] 同じ見た目のスタイルが重複定義されていない
- [ ] 直書きの数値・色に説明できる理由がある

(5) 依存・過剰実装
- [ ] 頼んでいない読み込み（link/script/import）がない
- [ ] 各JSに「CSSでは実現できない理由」がある

## AI生成HTML/CSS 受け入れチェックリスト（5軸15項目）

(1) 表示・デザイン再現
- [ ] カンプ・参考デザインとの目視差分がない
- [ ] ダミーテキスト・仮画像・不要コメント・未使用クラスが残っていない
- [ ] 実ブラウザ（Chrome＋iOS Safari）で崩れがない

(2) レスポンシブ・モーション
- [ ] モバイル・タブレット・PCの各幅で崩れ・横スクロールがない
- [ ] 中間幅のリサイズで、はみ出し・不自然な改行がない
- [ ] prefers-reduced-motion に配慮している（アニメーションがある場合）

(3) HTML構造・アクセシビリティ
- [ ] 見出し階層に飛びや見た目目的の流用がない
- [ ] 画像のaltが適切（装飾画像は空alt）
- [ ] Tabキーだけで全操作でき、フォーカスが見える
- [ ] role/ariaの盛りすぎ・欠落がない

(4) CSS設計・命名
- [ ] 案件の命名規則と整合している
- [ ] 同じ見た目のスタイルが重複定義されていない
- [ ] 直書きの数値・色に説明できる理由がある

(5) 依存・過剰実装
- [ ] 頼んでいない読み込み（link/script/import）がない
- [ ] 各JSに「CSSでは実現できない理由」がある

ポイントは2つです。

軸の並び順＝チェックする順番です。見た目→レスポンシブ→構造→CSS設計→依存と、表層から深層へ進むので、どこから見るか迷いません
項目は15個で打ち止めにしています。増やしすぎると「全部やらない」リストになるため、網羅より実行率を優先しました

各項目をYES/NOで判定するための具体的な見方は、次のセクションで軸ごとに解説します。

各チェック軸の見方 — どこをどう確認するか

(1) 表示・デザイン再現 — 最初に「見た目」を疑う

カンプとの目視差分: 主要セクションをカンプと並べて見比べ、余白・文字サイズ・色に意図しない差分がなければYES。AIは「だいたい似ている」ものを作るのが得意なぶん、細部の差分が残りがちです
ダミー・残骸の除去: ダミーテキスト・仮画像のパス・コメントアウトの残り・未使用クラスをエディタで検索して0件ならYES
実ブラウザでの表示確認: DevToolsのプレビューだけでなく、実ウィンドウ（最低限 Chrome＋iOS Safari）で崩れがなければYES

(2) レスポンシブ・モーション — AIは「指定した幅」しか見ていない

主要ブレークポイントの確認: モバイル・タブレット・PCの各幅で、崩れ・横スクロールが出なければYES
中間幅の破綻確認: ウィンドウを連続リサイズして、固定px幅による、はみ出しや不自然な改行がなければYES。AIは指示された幅ぴったりでは正しく組みますが、その間の幅は見ていません
prefers-reduced-motion の考慮: アニメーションがある場合、動きを抑える設定のユーザーへの配慮が入っていればYES。実装方法は「スクロールフェードインの作り方」で詳しく解説しています

(3) HTML構造・アクセシビリティ — 「盛りすぎ」も「足りない」も直す

見出し階層の飛び（h2→h4）・altの過不足・キーボード操作は、AIの出力で崩れやすい定番です。加えて注意したいのが、ariaの盛りすぎです。AIは「アクセシビリティ対応です」と言いながら、不要なroleやaria-labelを大量に付けてくることがあります。

HTML

<!-- Before: divと不要なariaが多い -->
<div class="header" role="banner" aria-label="ヘッダー">
  <div class="nav" role="navigation" aria-label="ナビゲーション">
    <div class="nav-item" role="link" tabindex="0" aria-label="ホームへ移動">ホーム</div>
    <div class="nav-item" role="link" tabindex="0" aria-label="制作実績へ移動">制作実績</div>
  </div>
</div>

<!-- Before: divと不要なariaが多い -->
<div class="header" role="banner" aria-label="ヘッダー">
  <div class="nav" role="navigation" aria-label="ナビゲーション">
    <div class="nav-item" role="link" tabindex="0" aria-label="ホームへ移動">ホーム</div>
    <div class="nav-item" role="link" tabindex="0" aria-label="制作実績へ移動">制作実績</div>
  </div>
</div>

HTML

<!-- After: 要素の意味で伝える（ariaは必要最小限） -->
<header class="l-header">
  <nav class="l-header__nav" aria-label="メイン">
    <ul class="l-header__list">
      <li><a href="/">ホーム</a></li>
      <li><a href="/works/">制作実績</a></li>
    </ul>
  </nav>
</header>

<!-- After: 要素の意味で伝える（ariaは必要最小限） -->
<header class="l-header">
  <nav class="l-header__nav" aria-label="メイン">
    <ul class="l-header__list">
      <li><a href="/">ホーム</a></li>
      <li><a href="/works/">制作実績</a></li>
    </ul>
  </nav>
</header>

header や nav を使えば、roleを書き足す必要はほとんどありません。「必要な箇所に欠けていないか」と「不要な箇所に盛られていないか」を両方向で確認できればYESです。ariaの正しい使いどころは「バニラJSで作るアコーディオン」が実例として参考になります。

(4) CSS設計・命名 — 案件の規約に合っているか

AIはその時々で「平均的な」命名を返すため、案件の規約と無関係な独自命名や、同じ見た目の重複定義が混ざりがちです。

CSS

/* Before: 独自命名・重複定義・根拠のない数値 */
.card-wrapper-box {
  margin-top: 37px;
  color: #333333;
}
.cardBox { /* 同じ見た目を別の書き方で再定義 */
  margin-top: 37px;
  color: #333;
}

/* Before: 独自命名・重複定義・根拠のない数値 */
.card-wrapper-box {
  margin-top: 37px;
  color: #333333;
}
.cardBox { /* 同じ見た目を別の書き方で再定義 */
  margin-top: 37px;
  color: #333;
}

CSS

/* After: 案件の規約（例: FLOCSS）と既存の変数に合わせる */
.c-card {
  margin-top: var(--space-lg); /* 余白スケールに乗せる */
  color: var(--color-text);
}

/* After: 案件の規約（例: FLOCSS）と既存の変数に合わせる */
.c-card {
  margin-top: var(--space-lg); /* 余白スケールに乗せる */
  color: var(--color-text);
}

命名規約との整合: 案件の規則（例: FLOCSS）に沿っていて、AI独自の命名が混入していなければYES。FLOCSSの考え方は「FLOCSSとは？基本の考え方と実際の書き方」を参照してください
重複スタイルの混入: 同じ見た目を作るスタイルが、別の書き方で二重定義されていなければYES
ハードコード値の説明可能性: 直書きされた数値・色に理由を説明できればYES。「37px」のような根拠不明の値は、変数や余白スケールに乗せ直します

(5) 依存・過剰実装 — 「頼んでいないもの」を探す

ここはコード例より、確認手順がそのまま判定基準になります。

HTML内の <link> と <script>、CSS/JS内の import を全数リストアップする
1つずつ「自分が依頼したものか」を確認する。頼んでいないライブラリ・CDN読み込みが0件ならYES
残ったJSに対して「CSSでは実現できない理由」を自分の言葉で説明できればYES。説明できないJSは、CSSだけで書き直せることが多いです

チェックリストは「基準を決める→検品する」のセットで使う

前回の記事のDoDと本記事5軸の対応

前回の記事で紹介した受け入れ基準（DoD）は基準を決めるためのもの、本記事のチェックリストはその基準で検品するためのものです。対応関係は次のとおりです。

受け入れ基準（DoD）の観点	本記事のチェック軸
見た目の再現性	(1) 表示・デザイン再現＋ (2) レスポンシブ・モーション
アクセシビリティ	(3) HTML構造・アクセシビリティ
保守性（半年後の可読性）	(4) CSS設計・命名
ブラウザ対応	(1) の実ブラウザ確認

(5) 依存・過剰実装は、AI生成コード特有のリスクとして本リストで追加した軸です。

案件ごとにリストを育てる

このリストは汎用の叩き台です。案件ごとに足し引きして、自分のリストに育ててください。

既存テーマの改修案件: (4) CSS設計・命名を厚くする（例: テーマ既存クラスとの命名衝突がないか、を項目に追加）
LP案件: (2) レスポンシブ・モーションを厚くする（例: 実機での確認幅を増やす、ファーストビューの崩れを最優先で見る）

よくある質問（FAQ）

毎回15項目すべてチェックするのですか？: 慣れるまでは全項目をおすすめします。慣れると(1)(2)は数分で終わるようになります。案件の性質に応じて、厚くする軸を変えて構いません。

NGを見つけたら自分で直す？AIに直させる？: どちらでも大丈夫です。AIに直させる場合は「何がNGか」を具体的に伝えます。チェックリストの項目名（例:「同じ見た目のスタイルが重複定義されている」）が、そのまま修正指示になります。

チェックにどのくらい時間をかけるべきですか？: 私は、生成にかけた時間と同程度〜倍くらいを見込むようにしています。検品時間を見込んでいない見積もりは、納品後の保守で自分が苦しくなると感じています。

JavaScript主体のコードもこのリストで足りますか？: 本記事はHTML/CSS＋軽いJS（メニュー開閉やスクロール演出程度）を対象にしています。ロジック主体のJSには、テストなど別の観点が必要です。

まとめ

AIのコードは「動く」と「受け入れられる」が別物。検品するのは人間の仕事です
見た目→レスポンシブ→構造→CSS設計→依存の順に、5軸15項目で見れば迷いません
リストは「基準を決める」（前回の記事「AIにコーディングを任せる前に、人間が決めておくべき3つのこと」）とセットで、案件ごとに自分のものへ育てていくのがおすすめです

AIが書いたコードをそのまま使うかどうか迷ったら、まずこの15項目から試してみてください。