
近年のフロントエンド開発では、
CSS Gridを前提にレイアウトを考えるケースが増えています。
CSS Gridは、2017年前後に主要モダンブラウザで本格対応が揃い、
現在ではIEを考慮しないプロジェクトであれば、実務上の制限はほぼありません。
その一方で、BootstrapはFlexboxベースのグリッドを採用しています。
生成AIを使ってコーディングを進める場面では、
「Bootstrapのrow / colをCSS Gridで書き直したコード」が提示されることも多く、
Flexboxでいくのか、Gridに寄せるのかという判断を迫られる場面が増えています。
この記事では、
BootstrapのFlexboxベースのグリッドをCSS Gridで書き直す判断は、どこで分かれるのか
を、生成AIの出力を交えながら整理していきます。
CSS Gridが選ばれやすくなっている背景
CSS Gridは、行と列を同時に扱える2次元レイアウトとして設計されています。
まずは、実際のコードを見比べてみましょう。
Flexbox(Bootstrapグリッド)の例
<div class="row"> <div class="col-md-6">コンテンツA</div> <div class="col-md-6">コンテンツB</div> </div>
HTMLを見るだけで、
「md以上で2カラムになる」というレイアウト意図が即座に読み取れるのが特徴です。
CSS Gridによるレイアウト例
<div class="grid"> <div>コンテンツA</div> <div>コンテンツB</div> </div>
<style>
.grid {
display: grid;
grid-template-columns: repeat(2, 1fr);
gap: 1rem;
}
</style>
構造はシンプルで、CSS側にレイアウトの責務が集約されています。
ただし、HTMLだけでは分割意図が分からない点が、Flexboxとの大きな違いです。
生成AIは、このGrid構造を「よりモダンで簡潔」と判断しやすい一方で、
プロジェクト全体の設計意図までは考慮しません。
コンポーネント指向のUI設計や、React / Vueなどの構成と相性が良く、
「レイアウトはCSS側で完結させたい」という考え方と噛み合います。
生成AIも、この文脈を学習データとして多く持っているため、
レイアウト=Grid、という判断をしやすくなっています。
BootstrapのFlexboxグリッドが持つ実務的価値
Bootstrapのグリッドは、Flexboxをベースにしています。
重要なのは、これが「時代遅れだから残っている」のではなく、
運用フェーズを前提に最適化されているという点です。
- ブレークポイントがHTML上で明示される
- チーム内で共通理解が作りやすい
- 生成AIにも構造意図が伝わりやすい
特に、HTMLだけでレイアウト意図が読める点は、
修正・保守・AIとの往復作業で大きな差になります。
生成AIがグリッドを書き直したがる理由
生成AIは、「少ないコードで確実に見た目を成立させる」ことを優先する場合があります。
Gridは、Flexboxよりも構造が単純に見えるため、
Bootstrapのrow / colは「書き換え可能な対象」と判断されやすくなります。
ただし、ここで問題になるのは、
その判断がプロジェクトの設計方針と一致しているかです。
FlexboxとGridが混ざると何が起きるか
事前の設計がないまま生成AIを使うと、
- 一部はBootstrapグリッド
- 一部はCSS Grid
- 余白はBootstrapユーティリティ
という構成が生まれがちです。
その結果、
- どこを直せばいいか分からない
- 人によって修正方針が変わる
- 生成AIに指示するたびに出力が揺れる
といった問題が発生します。
生成AIを使った実務で、特に起きやすいのが「修正指示を重ねた結果、設計がすり替わる」ケースです。
たとえば、もともとBootstrapのFlexboxグリッドで組まれていたレイアウトに対して、
- 「グリッドの余白を少し調整して」
- 「並びをきれいにして」
- 「レスポンシブを改善して」
といった、意図としては軽い調整を指示したつもりでも、
生成AIは「より整理された解」として、
Flexboxベースの構造をCSS Gridベースに置き換えたコードを提示してくることがあります。
見た目だけを確認すると問題がないため、
この変更に気づかないまま採用してしまうケースも少なくありません。
結果として、
- 一部はBootstrapのグリッド
- 一部はCSS Grid
- 余白や配置はBootstrapユーティリティ
という設計思想の混ざったレイアウトが生まれ、
後から「どこを直せばいいのか分からない」状態になりやすくなります。
この問題は、生成AIの性能ではなく、
「どのレイアウト手法でいくか」を事前に決めていないことが原因で起きるケースがほとんどです。
どちらを選ぶか判断するための整理軸
FlexboxかGridかは、優劣の問題ではありません。
- このレイアウトは再利用されるか
- 複数人や生成AIが今後も触るか
- HTMLだけで意図が伝わる必要があるか
これらに当てはまる場合、
FlexboxベースのBootstrapグリッドを維持する判断は合理的です。
一方、コンポーネント単位で完結し、
CSS側で責務を閉じられる場合は、Gridで割り切る選択肢も成立します。
まとめ|設計を決めるのは人の仕事
生成AIは、FlexboxもCSS Gridも書けます。
見た目を成立させるという点では、どちらも問題なく出力できます。
ただし、
どちらを選ぶかを決めることは、生成AIにはできません。
実務で生成AIを使ってコーディングを進めていると、
一度生成されたコードに対して、
- 「もう少しグリッドを調整して」
- 「レイアウトをきれいにして」
- 「レスポンシブを改善して」
といった修正指示を重ねる場面が多くなります。
ここで起きやすいのが、
もともとBootstrapのFlexboxベースで書かれていたグリッドが、
途中からCSS Gridベースのコードに置き換わってしまうケースです。
人の感覚としては「少し調整してほしい」だけなのに、
生成AIは「よりシンプルでモダンな解」として、
グリッド構造そのものを書き換えてしまうことがあります。
CursorなどのAIエディタでは、
変更履歴をたどったり、チャットログをさかのぼったりすることも可能です。
ただ、その確認や巻き戻し自体が少し面倒だと感じることも多いはずです。
だからこそ重要なのが、
生成AIに触らせる前に「このレイアウトはFlexboxでいくのか、Gridでいくのか」を決めておくことです。
事前に設計の軸があれば、
- 生成AIへの指示がブレにくくなる
- 意図しない全面書き換えを防げる
- 人の修正判断も一貫する
生成AIの助力を得ながらコーディングを進める時代だからこそ、
「どう書くか」よりも、「どの設計でいくか」を人が握ることが、
最も重要なスキルになっています。



