AIが書いたCSSは正しいのか？「動くけど、後から直せなくなる」コードの正体

AIが書いたCSSは正しいのか、それとも「後から直せなくなる設計」なのか？

今見ているそのCSS、表示は問題ない。
デザインも要件どおりで、とりあえず見た目も問題ない。

それなのに、少し修正しようとした瞬間に手が止まる。
「この指定、どこまで影響してるんだろう」
「後から書いたCSSが、なぜか当たらない」

AIで生成したCSSを実務で使っていると、
こうした違和感を覚える場面が増えてきます。

この記事では、AI生成CSSがなぜ“後から直しづらい状態”になりやすいのかを、
開発現場で起きがちな具体的な状況に引き寄せながら、一緒に整理していきます。

AIを否定する話ではありません。
「どう使えば、半年後の自分が困らないか」
その視点で考えるための記事です。

ChatGPTがCSSを書くときの「クセ」

まず前提として、ChatGPTが生成するCSSは、
「動く見本としては優秀、運用コードとしては未整理」になりやすい傾向があります。

セレクタは広く、名前は抽象的。
.container や .box のような、
「どこでも使えそうな名前」が選ばれがちです。

これは、AIが確実に見た目を当てにいくための選択です。
既存CSSとの衝突や、影響範囲の管理（スコープ）までは考慮されていないことが多くなります。

その結果、「どこまで効くCSSなのか」がコードから読み取りにくくなります。
皆さんのプロジェクトでも、影響範囲が読めないCSS、増えていませんか？

後からの変更を拒む「優先順位の壁」

AI生成CSSで特に困りやすいのが、
セレクタが「強く書かれすぎている」ケースです。

たとえば、本来は .button で十分な場面でも、
AIは確実に色を変えるために、

div.container ul li .button

のように、要素の構造を細かく指定して出力することがあります。

ここで問題になるのが、CSSの基本ルールです。
「より詳しく書かれた指定ほど、優先される」

何が起きるか

あなたが後から、

.button { background: red; }

と書いても、AIが書いた「強い指定」に負けてしまい、
スタイルが反映されません。

どう対応せざるを得なくなるか

結局、さらに長いセレクタを書くか、
!important を使うしかなくなります。

こうした「優先順位で殴り合うCSS」が積み重なると、
どこを直しても反映されないが、どこも消せない状態になります。

AIは「確実に当てること」を優先するあまり、
セレクタの優先順位を高く設定しすぎる傾向があります。
これが積み重なると、現場の秩序が少しずつ崩れていくのです。

こうした「優先順位で殴り合うCSS」が積み重なると、
修正のたびに「また当たらないかもしれない」という不安が先に立ち、
コードを書く前から手が止まる状態になりやすくなります。

役割が詰め込まれすぎると、CSSはブラックボックスになりやすい

メンテナンスが苦しいCSSを解剖してみると、
「見た目（色や装飾）」と「レイアウト（配置や余白）」という異なる目的が、
1つのセレクタにギュッと詰め込まれていることがよくあります。

本来であれば、
「どう見せたいか」と「どこに置きたいか」は、
別々に考えたほうが調整しやすいルールです。

ところがAIは、「このコンポーネントを完成させて」というオーダーに応えるため、
最短距離でゴール（完成形）を目指します。

その結果、色・形・余白・配置といったルールをすべてまとめて書いてしまい、
あとで「色だけ変えたい」「余白だけ調整したい」といった、
役割を分けて管理する視点が抜け落ちがちになります。

「抱き合わせ」の指定が招くブラックボックス化

このように役割が混ざってしまうと、
「今やりたい変更」だけに集中できなくなります。

色を変えたいだけなのに、その行をいじると配置まで崩れるかもしれない。
余白を調整したいだけなのに、文字サイズや背景まで影響するかもしれない。

こうした不安が積み重なることで、
CSSを触る心理的なハードルは、少しずつ高くなっていきます。

私はCSSを整えるとき、
「これは骨組み（構造）の話か、それともお化粧（見た目）の話か」
を、まず頭の中で切り分けるようにしています。

もしコード側でこの整理がついていないと、
修正のたびにパズルを解くような負担が発生します。

その結果、
「下手に触らないほうが安全そうだな」という判断が積み重なり、
CSSはいつの間にか触れないブラックボックスになってしまうのです。

皆さんのプロジェクトにも、
「色を変えたいだけなのに、どこを触ればいいか分からないCSS」
いつの間にか増えていませんか？

フレームワークと噛み合わなくなる理由

BootstrapやTailwindを使っていると、
AI生成CSSとの噛み合わなさを感じることがあります。

これは、AIがプロジェクト固有の設計ルールを知らないためです。
utilityで済むものを独自CSSで書き、さらに上書きしていくと、
「どの思想で直すのか」が毎回揺れます。

実は、プロンプトに
「BEMで書いて」「Bootstrap前提で」
と一言添えるだけで、この問題の多くは回避できます。

私自身も、「この修正はフレームワーク側？それとも独自CSS？」と
毎回立ち止まっていた時期がありました。
この迷いが続くと、修正スピードが確実に落ちていきます。

実務で「素材」として扱うための判断基準

私は、AI生成CSSを完成品ではなく、素材として扱っています。

このCSSはどこまで影響するか（スコープ管理）
この値の役割は何か
増やす前に減らせないか

ここでの小さな整理は、
半年後の自分へのギフトになります。

半年後、このCSSを覚えていられるか。
他人が読んで用途が分かるか。
皆さんのプロジェクトでも、一度立ち止まって考えてみてください。

ここでの整理は、
未来の自分や、チームメンバーを助けるための作業です。
今の数分が、半年後の安心につながることは意外と多いです。

まとめ｜AI生成CSSは「優秀な下書き」

ChatGPTが書くCSSは、決して「使えないコード」ではありません。
ただし、それは「動く＝採用できる」とは限らない、という話でもあります。

表示は問題ないのに、
・どこまで影響するか分からない
・直そうとすると優先順位の壁にぶつかる
・少し触るだけで全体が壊れそうに感じる

こうした違和感は、スキル不足ではなく、
「そのコードが、運用フェーズを想定していないだけ」のことがほとんどです。

AIが出力したコードを前にして、
「これは便利そうだけど、このまま採用していいのか？」
と立ち止まれた時点で、すでにプロとして正しい判断を始めています。

次回の記事では、
「動くけど、採用できないAIコード」をどう見分けるかについて、
HTML / CSS の実例を交えながら整理します。

まずは今日、あなたの手元にあるAI生成コードを、
「これは将来の自分が触れるコードか？」という視点で、
一度だけ眺めてみてください。