Bootstrapの次期メジャーバージョン、v6の開発が進んでいるようで、2026年10月には最初のアルファ版が公開されました。
変更点を見てみると、CSS変数やブラウザ標準の機能を積極的に取り入れるなど、これまでのBootstrapとはまた違う方向への進化が伺えます。
Bootstrapといえば、Web制作をずいぶん変えた存在と言えるでしょう。
かつてはWebサイトを見れば「あ、Bootstrapだ」と分かることも珍しくなく、特にTwitter Bootstrapと呼ばれていた頃のv2〜3には、どこもかしこも使っているような印象がありました。
筆者も当時、公式サイトで紹介されているコードをコピペするだけで、一定の品質を備えたページを作れることに驚きました。
こんなに簡単に作れるのか、と。
振り返れば、Web制作に対する考え方の一部は、あの体験から始まっているのかもしれません。
新しいv6をきっかけに、BootstrapがWeb制作にもたらした変化と、15年間の進化を振り返ってみます。
Bootstrapが持ち込んだ「一定品質を簡単に作る」という価値
Bootstrapは2011年、Twitter社内で使われていたUIの仕組みをもとに公開されました。
当時、Webサイトのボタンや入力欄、余白、ナビゲーションを揃えるには、個々のプロジェクトでCSSを積み重ねる必要がありました。
Bootstrapは、統一感のあるデザインとコンポーネント、グリッド、サンプルを提供します。
複数の要素を一から設計しなくても、ドキュメントにあるマークアップを使うだけで整った画面を組み立てられました。
もちろん、それ以前にもCSSフレームワークは存在しましたが、Bootstrapの新しさは、レイアウトだけでなく、実際のサービスで必要になるUI一式を、分かりやすい使い方でまとめたところにあったと思います。
その手軽さには代償もあり、採用するサイトが増えるほど、似た配色やパーツが目立ち、「Bootstrapっぽい」見た目にもなります。(いわゆるBootstrap臭ですね)
それでも、まず使える画面を短時間で作れることには大きな意味がありました。
デザインを個人のセンスだけに頼らなくてよくなったからです。
v1〜v3:PCの標準化から、スマートフォンが主役になるまで
| 世代 | 登場年 | 代表的な変化 | そこから見える課題 |
|---|---|---|---|
| v1 | 2011年 | UI部品とグリッドの共通化 | ページごとの見た目や実装のばらつき |
| v2 | 2012年 | レスポンシブ対応の導入 | PCとスマートフォンの画面をどう両立するか |
| v3 | 2013年 | モバイルファースト、フラットなデザイン | スマートフォンを例外ではなく基準にする |
v1:まずは画面を揃えたい
最初のBootstrapが与えたのは、UIをゼロから作らずに済むという安心感でした。
デザイナーと開発者が、同じ部品とルールを使って画面を組み立てられます。
この価値は今も残っています。
個々のボタンを美しくするより、画面全体の一貫性を保ち、次の画面を作りやすくすること。
Bootstrapが広めた実務上のメリットはそこにありました。
v2:レスポンシブを「追加できる」ようになる
2012年のv2は、レスポンシブレイアウトを取り入れました。
ただし、初期のv2ではレスポンシブ対応はオプションで、追加のスタイルシートを使う構成でした。
この位置づけが時代をよく表しています。
基本はPC向けのサイトで、スマートフォン向けの調整を後から加える。
今となっては遠回りに見えるけれど、当時のWeb制作が抱えていた現実的な移行段階だったと言えるでしょう。
v3:モバイルファーストが標準になる
2013年のv3では、その関係が逆転します。
公式が掲げたのは「Mobile first and always responsive」。
追加の対応なしでモバイル優先とレスポンシブ対応が基本仕様になりました。
デザインも、以前のグラデーションや立体感の強い表現から、よりフラットな方向へ。
パネルやリストグループなどの部品が整備され、スマートフォン時代の管理画面やサービス画面を組み立てやすくなりました。
個人的には、このv2〜3の時代がBootstrapの存在感を最も強く感じた頃です。
ただし、それは当時の制作現場での印象であって、利用率の統計的なピークを意味するものではありません。
興味深いのは、v2ではオプションだったレスポンシブが、v3ではデフォルトになったことです。
新しい技術が「あれば便利」から「あるのが当然」へ変わると、フレームワークの設計も大きく変わります。
v4:レイアウトとカスタマイズの自由度を広げる
2018年のv4では、Flexboxを利用したグリッドへの移行と、Sassによるカスタマイズの拡充が大きな変化でした。
以前のパネル、ウェル、サムネイルなどを整理して、より汎用的なカードへまとめたのも象徴的です。
v1〜3では共通の部品を使って画面を揃えることが魅力でした。
v4では、その部品をプロジェクトごとのデザインに合わせて組み替える自由度が増しました。
統一されたデザインを手軽に得る段階から、共通の仕組みを使って独自の画面を作る段階へ進んだ、と捉えられます。
ユーティリティクラスも増え、CSSを書かずに余白や配置を調整できる場面が広がりました。
この便利さは、同時にHTMLのクラス指定が増え続ける方向にもつながります。
共通の完成品を使うのか、細かな部品を組み合わせるのか。
そのバランスは、現在まで続くCSSフレームワークの論点でしょう。
v5:jQueryとInternet Explorerからの卒業
2021年のv5は、jQueryへの依存とInternet Explorerを非対応にしたことが大きなトピックでしょう。
JavaScriptをブラウザの標準機能で実装し、CSSカスタムプロパティも拡充されていきました。
v4がカスタマイズの自由度を広げた世代なら、v5は何を引き継がないかを決めた世代とも言えます。
古いブラウザとの互換性を広く背負うより、ブラウザの標準機能を前提にする。
その選択が、v6でのネイティブCSSやUI要素の活用へつながっています。
一方で、Bootstrapを使う側にも移行の判断が求められます。
古いブラウザが必要な業務システムでは、すぐに新しい世代を選ぶわけにはいきません。
標準技術へ寄せることと、既存利用者を置き去りにしないことは、いつもセットで考える必要があります。
v6:ブラウザ自身がUIを支える時代へ
2026年10月8日に発表されたBootstrap 6 Alpha 1は、まだ開発途中です。
それでも、目指している方向はかなりはっきりしています。
| 変更 | v5までとの違い | 意味 |
|---|---|---|
| CSS変数とトークン | SassとCSSの併用からCSS主体の見た目調整へ | 再ビルドしなくても変更を反映しやすい |
| CSS標準 | @layer、oklch()、light-dark()などを活用 | 独自の仕組みで補う範囲を減らす |
| コンポーネント | <dialog>、<details>などを活用 | ブラウザに任せられる振る舞いを増やす |
| レイアウト | コンテナクエリを導入 | 画面全体だけでなく親要素に応じて調整する |
| クラス名 | .col-lg-6から.lg:col-6のような接頭辞形式へ | レスポンシブや状態指定を統一する |
| JavaScript | ESM専用、TypeScriptソースへ | 現代のビルド環境を前提とする |
v6ではSassを生成や構造化に使い、色や余白といったデザイントークンをCSS変数を使用する方向に寄せています。
標準要素を採用しても、Bootstrapがコンポーネントとして提供する価値まで消えるわけではありません。
一方、対応ブラウザの下限はChrome・Edge 130、Firefox 132、Safari 18へ引き上げられ、古い環境向けのフォールバックは用意しない方針です。
既存サイトでは、ブラウザの利用状況とクラス名・JavaScriptの破壊的変更を確認してから移行を検討する必要があります。
これらはあくまでAlpha 1時点の仕様で、正式版までに変更される可能性があります。
v6ではLLM向けドキュメントや移行支援のSkillも用意されているのは興味深いところです。
かつて人がサンプルのHTMLをコピーしていたBootstrapが、AIエージェントにも仕様を伝えるようになったのは、制作環境の変化を感じさせます。
フレームワークに任せるものが変わってきた
v2では追加できる機能だったレスポンシブ対応が、v3ではデフォルトになりました。
v5でjQueryやInternet Explorerへの依存を外し、v6ではCSSやUIの実装をさらにブラウザへ任せようとしています。
その間に、Bootstrapの役割も、足りない機能を補うことから、標準機能を使って一貫したデザインを組み立てることへと変化してきました。
最近の筆者自身の制作でも、CSS変数へ定義を集約したり、古いブラウザ向けの互換コードを見直したり、独自実装を減らしたりしています。
Bootstrap 6の変更点に見覚えがあったのは、このあたりの考え方が重なっているからでしょう。
ただ、進む方向がすべて同じわけではありません。
Bootstrapは総合的なデザインシステムとして機能を増やす一方、個人制作ではPicoCSSやBeerCSSのような軽量な選択肢が合うこともあります。
ブラウザが進化したからこそ、必要なものだけを選ぶ余地も広がっています。
昔、Bootstrapを触って驚いたのは、難しいことを自分で全部やらなくても、きちんとした画面を作れたからでした。
15年が経った今も、求めているものは案外変わっていないのかもしれません。
すでにある良い仕組みを使って、作りたいものに時間を使う。
その「良い仕組み」の置き場所が、Bootstrapの中から、少しずつブラウザ自身へ移ってきたのだと思います。


コメント