これまでの記事で見えてきた共通点

これまでの記事では、次のような話題を扱ってきました。

• AIが書いたHTMLは、構造の意図が読みにくくなりやすい
• AI生成CSSは、優先順位や責務が混ざりやすい
• Bootstrap・Flexbox・CSS Gridが混在すると判断が止まりやすい
• モダンCSSでは「前提」が変わっていることに気づきにくい

どれも一見すると別の問題に見えますが、
共通しているのは「事前に決めていないことが多い」という点です。

もう少し実務に寄せると、
設計が言語化されないままプロンプトに渡されている状態で起きやすい現象、とも言えます。

レイアウト手法、CSS設計の考え方、フレームワークの使い方。
それらが曖昧なままAIに書かせると、
AIは完成形を優先して判断を進めます。

その結果、「動くけれど、触りづらい」コードが出来上がりやすくなります。

なぜAIに先に書かせると迷いやすいのか

AIに「とりあえずHTML/CSSを書いて」と頼むと、
見た目としては成立したコードが返ってきます。

ただしそのコードは、
「今この画面を成立させる」ことをゴールにしています。

そのため、

• divが増える
• クラス名が抽象的になる
• FlexboxとGridが自然に混ざる

といった状態が起きやすくなります。

これはAIが雑なのではなく、
判断材料が足りないまま書かせていることが原因です。

方針が整理されないままプロンプトを渡すと、
AIはその空白を推測で埋めるしかありません。
そう考えると、違和感の正体が見えてきます。

HTML/CSSにおける「設計」とは何か

ここで言う設計は、
大げさな設計書を作ることではありません。

最低限、次のような方針が言葉にできているかどうかです。

• このUIは「何の塊」か
• 構造と見た目をどう分けるか
• レイアウトはFlexboxか、CSS Gridか
• Bootstrap前提か、独自CSS中心か

など

ここで言う「設計」とは、
生成AIに渡すプロンプトの“前提条件”を、人が整理すること
と言い換えることもできます。

これらはコードを書く前に決めておくほうが、
実務では圧倒的に楽になります。

設計が決まっていれば、
AIは「実装するだけ」の役割に集中できます。

設計がある状態でAIを使うと何が変わるか

設計の前提を渡した状態でAIに頼むと、
出力されるコードの性質が変わります。

• 「Bootstrap 5のグリッド前提で」
• 「Flexboxのみでレイアウト」
• 「CSS Gridは使わない」

こうした制約があるだけで、
AIは迷わず判断できるようになります。

設計が整理されたプロンプトでは、
AIは「実装」に集中できます。
一方で、設計が曖昧なままのプロンプトでは、
AIが「構造・レイアウト・設計判断」まで抱え込むことになります。

完璧なコードが出るわけではありませんが、
「どこを直すか」が分かる状態で返ってくる確率が高くなります。

これは、これまでの記事で触れてきた
「読みにくさ」や「混在問題」を防ぐための、
もっとも現実的な対策です。

方針が曖昧なまま進めたときに起きること

設計が曖昧なままAIを使い続けると、
修正のたびに次のような状態になりがちです。

• どこを触ればいいか分からない
• 直すと別の場所が壊れそう
• AIに頼むたびに構造が変わる

その結果、「今日は触らないほうが安全」という判断が増え、
コードは少しずつブラックボックス化していきます。

これはスキル不足ではなく、
順番の問題で起きることがほとんどです。

まとめ｜AIは設計を代行しない

生成AIは、HTML/CSSの実装を加速させてくれる強力な道具です。

ただし、
設計そのものを代行する存在ではありません。

先に人が方針を決め、
その上でAIに実装を任せる。

この順番を守るだけで、
これまでの記事で扱ってきた多くの悩みは、
自然と減っていきます。

良いプロンプトを書くことが目的ではありません。
良い設計があり、
それが自然にプロンプトへ落ちている状態を作ること。
それが、生成AIと安全に付き合うための、いちばん確実な方法です。

次の記事では、
「設計を前提にした生成AIへの具体的な指示の出し方」を、
HTML / CSS / Bootstrap の具体例で整理していきます。

まずは、
次にAIへ指示を出す前に「何を決めてから渡すか」を、
一度だけ意識してみてください。