ChatGPTにCSSを書かせると、
見た目としてはそれなりに整ったコードが、すぐに出てきます。
「とりあえず動く」「デザイン要件は満たしている」
ここまでは、特に問題を感じないかもしれません。
ただ、あとから少し修正しようとしたときに、
「このクラス、どの命名規則なんだろう？」
「BEMなのか、Bootstrap前提なのか、それとも独自ルール？」
そんな疑問が浮かんで、手が止まることはありませんか？
さらに、
「この名前、既存ライブラリと衝突しないだろうか」
「CSS変数を使っていないけど、この値はどこで管理する想定？」
「ブレイクポイントは、Bootstrap基準？それとも独自？」
と考え始めると、修正しづらそうな気配が一気に強まります。
この違和感は、
新規構築・リニューアル・保守といったプロジェクトの文脈によって、
より顕著に表れることがあります。
この記事では、
ChatGPTにCSSを書かせる前に、人が決めておくべき前提を、
実務で判断が止まりやすいポイントに絞って整理していきます。
生成AIがCSSを書けてしまう理由
ChatGPTは、CSSを書くこと自体がとても得意です。
それは、正解のパターンが多く学習されており、
「見た目を成立させる」ための知識を豊富に持っているからです。
ただし、AIが得意なのは完成形を一気に作ることであり、
「このCSSが、どの文脈で使われるか」までは自動では判断できません。
そのため、設計の前提が共有されていない状態では、
見た目優先・局所最適なCSSが生成されやすくなります。
ChatGPTが出力するCSSは、設計意図を考えて組み立てているというより、
「この状況なら、こう書かれていることが多い」という統計的な判断に近いものです。
そのため、
・影響範囲を狭める
・後から拡張しやすくする
・既存設計と噛み合わせる
といった運用フェーズの視点は、どうしても後回しになります。
ここを人が補わないと、
AIは「正しそうだが、長く使う前提ではないCSS」を量産してしまいます。
プロジェクト種別で変わる「AIに任せられる範囲」
CSSを生成AIに任せるかどうかは、
プロジェクトの種類によって、判断基準が大きく変わります。
新規構築の場合
新規構築では、
命名規則・設計思想・ブレイクポイントを、
ある程度自由に決めることができます。
この場合、前提を明示したうえでAIを使えば、
コーディングのスピードを安全に上げやすいです。
リニューアル・保守の場合
既存のCSS設計やライブラリがある場合、
AIはそれを知らない前提でコードを書きます。
その結果、
既存ルールと噛み合わないCSSが混ざり、
修正コストが逆に増えることがあります。
新規構築では、多少の設計ミスがあっても、
まだ全体が固まっていないため見直しや軌道修正は行いやすいといえます。
一方、リニューアルや保守では、
CSSは他の画面・他の機能と密結合していることがほとんどです。
この状態でAIにCSSを書かせると、
「その画面では正しいが、他では壊れる」
というコードが生成されることがあります。
だからこそ、プロジェクトのフェーズによって、
AIに任せていい範囲を先に線引きする必要があります。
命名規則とスコープを決めずにAIを使うリスク
命名規則が決まっていない状態で生成されたCSSは、
「どこまで影響するクラスなのか」が読み取りにくくなります。
BEMなのか、Bootstrap前提なのか、
それとも独自ルールなのか。
これが曖昧だと、修正時の判断が止まりやすくなります。
また、スコープが整理されていないCSSは、
他ライブラリとの衝突や、意図しない上書きを招きがちです。
クラス名は、その場では「動けばOK」に見えますが、
後からコードを検索するときの唯一の手がかりになります。
命名規則が決まっていないCSSは、
「このクラスはどこで使われているのか」
「消しても安全か」
といった判断に、毎回時間がかかります。
BEMなどのルールは、
美しさのためというより、
考えなくていい判断を減らすための仕組みと考えると分かりやすいです。
設計が曖昧だと、なぜ修正が怖くなるのか
修正が怖くなるCSSには、共通点があります。
- どこまで影響するか分からない
- 1行直すと、他も壊れそう
- 誰の意図で書かれたか読めない
これは、技術的な問題というより、
設計の前提がコードに残っていないことが原因です。
設計が見えないCSSは、
結果として「触らないほうが安全なブラックボックス」になっていきます。
CSSの怖さは、表示時のレイアウト崩れなのか、構文のミスなのか、エラーがわかりにくいことです。
そのため、設計が見えないCSSほど、
「どこが原因か分からない不具合」を生みやすくなります。
この経験を何度かすると、
人は自然と「触らない選択」をするようになります。
これが、ブラックボックス化の正体です。
ChatGPTにCSSを書く前に決めておくチェックポイント
- 命名規則（BEM / フレームワーク前提 / 独自）
- スコープ（コンポーネント単位か、全体か）
- CSS変数を使うかどうか
- ブレイクポイントの基準
- 既存CSS・ライブラリとの関係
これらを決めたうえでAIに指示すると、
出力されるCSSの「読みやすさ」と「直しやすさ」が大きく変わります。
このチェックポイントは、
AIを縛るためのものではありません。
人が判断を迷わないための、前提共有です。
ここが決まっているだけで、
AIに修正を依頼するときのプロンプトも、
自然と具体的になります。
まとめ｜AIに任せるために、人が設計する
ChatGPTは、CSSを書く力をすでに十分に持っています。
だからこそ重要なのは、
何をAIに任せ、何を人が決めるかです。
設計が決まっていれば、AIは心強い相棒になります。
逆に、前提が曖昧なままだと、
「動くけど、触れないCSS」が量産されてしまいます。
次の記事では、
「このAIコードを実務で採用すること」を見極める具体的な視点を、
HTML / CSS の実例とともに整理していきます。
