素のCSS vs Bootstrap vs Tailwind:どれを選ぶべきか?

新しいフロントエンドプロジェクトを始めるとき、スタイリングの手法として3つの選択肢の中から選ぶことになります。素のCSSを自分で書くか、コンポーネントベースのCSSフレームワークであるBootstrapを使うか、あるいはutility-firstなアプローチを取るTailwind CSSを使うかです。素のCSSとは、ライブラリを一切使わず、すべてのスタイルを手作業で書くことを意味します。Bootstrapは、あらかじめ用意されたコンポーネントとグリッドシステムを組み合わせてUIを構築できるCSSフレームワークです。Tailwind CSSは第三のアプローチを取り、個別のCSSルールを書く代わりに、マークアップ内で直接utilityクラスを組み合わせてスタイルを作ります。3つとも有効な選択肢であり、あらゆるプロジェクトに常に最適な唯一の答えは存在せず、あるのは「コントロール」「スピード」「カスタマイズ性」の間のトレードオフだけです。本記事では、素のCSS vs Bootstrap、素のCSS vs Tailwind CSS、Bootstrap vs Tailwind CSSをそれぞれ比較し、次のプロジェクトにどれが適しているかを判断できるようにします。

CSSフレームワークとは?

CSSフレームワークとは、あらかじめ用意されたスタイル(多くの場合コンポーネントも含む)の集まりで、すべてのスタイルルールをゼロから書く手間を省いてくれるものです。BootstrapとTailwind CSSはどちらも一般的に「CSSフレームワーク」と呼ばれますが、そのアプローチは正反対です。Bootstrapはボタン、ナビバー、カードといった完成済みのコンポーネントを、デフォルトのビジュアルスタイルとともに提供します。一方Tailwindは、flex、p-4、text-smといった低レベルのutilityクラスを提供し、それらを自分で組み合わせていく形を取ります。完成したUIパーツの集合というより、スタイリングのツールキットに近い存在です。素のCSSはそもそもフレームワークではなく、言語そのものであり、あらかじめ用意されたスタイルやクラスは一切含まれません。その他の代表的なCSSフレームワークにはBulma、Materialize、Pico CSSなどがあり、それぞれ「どこまでの構造をデフォルトで提供するか」について独自の考え方を持っています。

素のCSS vs Bootstrap

Bootstrap vs 素のCSSの違いは、突き詰めると「スピード」対「コントロール」です。素のCSSでは、すべてのスタイルを一行ずつ完全にコントロールできます。依存関係もなく、不要なコードも生まれず、フレームワークの規約や詳細度(specificity)のルールと戦う必要もありません。しかしそのコントロールには代償が伴います。グリッド、スペーシングのスケール、レスポンシブなブレークポイント、インタラクティブな状態管理まで、すべてを自分で構築・維持しなければならず、プロジェクトが大きくなるにつれて一貫性を保てるかどうかは、自分自身の命名規則と規律だけに委ねられます。

Bootstrapはそのコントロールをスピードと引き換えにします。ナビバー、モーダル、カード、フォームコントロールといったあらかじめ用意されたコンポーネントと12カラムのグリッドシステムのおかげで、動くUIを素早く組み立てられます。だからこそBootstrapは、素早く作りたいMVP、社内ツール、管理画面などで今も定番の選択肢であり続けています。トレードオフは、デフォルトのスタイルを上書きする時間をかけない限り「Bootstrapっぽい見た目」がすぐにバレてしまうことで、その上書き作業ではしばしば自分のCSSとBootstrap自身のCSSとの間で詳細度の競合と戦うことになります。

独自性のあるデザインや、変わったレイアウト要件を持つプロジェクトなら、素のCSSは制約に縛られずに済みます。専任のデザイナーがおらず、標準的な見た目のUIを素早くリリースする必要があるなら、Bootstrapは実質的な開発時間を大きく節約してくれます。

素のCSS vs Tailwind CSS

素のCSS vs Tailwind CSSの違いは、スピードの差というより「スタイリングのロジックがどこに存在するか」の違いです。素のCSSでは、スタイルは独立したスタイルシートの中に存在し、多くの場合BEMのような命名規則に従って自分で名付けたクラスから参照されます。出力を完全にコントロールできる一方で、スペーシングのスケール、カラーパレット、レスポンシブなブレークポイントもすべてゼロから自分で構築する責任を負います。

Tailwind CSSは、flex、gap-4、text-slate-600のようなutilityクラスを通じて、スタイリングをマークアップ自体の中に留めます。CSSクラスに名前を付けて管理する代わりに、スペーシング・カラー・ブレークポイント用の共有設定(config)を使って、要素の上に直接デザインを組み立てていきます。この設定によって、すべてのデザイントークンをゼロから作らなくても、素のCSSに近いカスタマイズの自由度が得られます。ただしその分、HTML内のクラス文字列は長くなり、従来のCSSの書き方に慣れた開発者にとっては学習コストも発生します。

スタイリングをマークアップと同じ場所に置きたい、かつデザイントークンを自作せずに一貫性を保ちたいと考えるチームは、素のCSSよりもTailwind CSSを好む傾向があります。一方、CSS仕様との間に抽象化を一切挟みたくないチームや、スタイリングの要件が小規模で限定的なチームは、素のCSSを使い続けることが多いです。

Bootstrap vs Tailwind CSS

BootstrapとTailwind CSSはどちらも一般的に「CSSフレームワーク」と呼ばれますが、両者は「CSSをゼロから書かずに済ませる」という同じ課題を、正反対の方法で解決しています。Bootstrapはcomponent-first(コンポーネント優先)で、デフォルトのビジュアルスタイルですでにデザインされた完成済みのナビバー、モーダル、カードをそのまま組み込みます。Tailwindはutility-first(utility優先)で、低レベルのクラスから自分自身でコンポーネントを組み立てていくため、上書きすべき「デフォルトの見た目」自体が存在しません。

この違いはカスタマイズの場面で顕著に表れます。Bootstrapサイトを独自性のある見た目にするには、通常デフォルトのクラスを上書きする必要があり、それが詳細度の競合につながることがあります。Tailwind CSSプロジェクトを独自性のある見た目にするのは、戦うべき既定のビジュアルアイデンティティが存在しない分、デフォルトの体験に近い作業になります。ただしその代わり、Bootstrapのような既製のコンポーネントは手に入らないため、よくあるUIパターンを最初に組み立てるのには時間がかかります。

Bootstrapは、標準的なUIで素早く前進したく、高度にカスタムなデザインを必要としないチームに向いています。Tailwind CSSは、独自のデザインシステムを構築しているチームや、ReactやVueのようなコンポーネントベースのフレームワークと組み合わせて使うチーム — 再利用可能なコンポーネントがutilityクラスの冗長さを吸収してくれる環境 — に向いています。

比較表

以下の表は、選択する際に重要となる要素ごとの実務的な違いをまとめたものです。実際のパフォーマンス(CSSバンドルサイズやページ速度など)は、技術そのものよりも、各アプローチをどう実装し最適化するかに大きく左右されます。

どれを選ぶべきか?

万能な「ベスト」な選択肢は存在しません。あるのは、あなたのプロジェクト、チーム、制約に合った選択肢だけです。一般的な指針として、以下を参考にしてください。

素のCSSを選ぶべき場合:

• CSSの一行一行に対して最大限のコントロールが必要
• プロジェクトが独自性のあるデザインシステムを持っている
• スタイリングの要件が比較的小規模で限定的
• どのフレームワークの規約も採用したくない

Bootstrapを選ぶべき場合:

• あらかじめ用意された、すぐに使えるコンポーネントが欲しい
• 標準的なUIを素早くリリースする必要がある
• チームが既にBootstrapに慣れている
• 独自性のある見た目よりも、一貫性や確立されたパターンを重視する

Tailwind CSSを選ぶべき場合:

• デザイントークンが組み込まれたutility-firstなスタイリングが欲しい
• ゼロからではなく、独自のデザインシステムを構築している
• スタイリングをマークアップと同じ場所に置きたい
• ReactやVueのようなコンポーネントベースのフレームワークで作業している

これらはルールではなく、あくまで出発点です。コンポーネントライブラリの上にTailwind CSSを重ねて使ったり、Tailwindベースのアプリの隣で小規模なマーケティングサイトだけ素のCSSで作ったりと、複数のアプローチを組み合わせて成功しているプロジェクトも数多くあります。

これらのCSSアプローチをFigma-to-Codeワークフローで活用する

選択するCSSアプローチは、Figmaデザインをコードに変換した際の結果にも影響します。FigmaデザインをコードにするMarkupGenは複数の出力形式に対応しており、変換のためだけに新しいアプローチを無理に採用させるのではなく、プロジェクトが既に使っている手法に合わせて生成コードを出力できます。

素のCSSで開発しているなら、MarkupGenのFigma to HTMLコンバーターがデザインのAuto Layout構造から直接、対応するCSSと合わせてセマンティックなHTMLを生成します。スタイルシートだけが必要な場合はFigma to CSSコンバーターを使ってください。コンポーネントフレームワークを標準化しているチームは、Figma to BootstrapコンバーターやFigma to Tailwind CSSコンバーターを使うことで、デザインからスペーシング・ブレークポイント・コンポーネントを後から手作業で変換することなく、既に使っている規約に沿った出力を得られます。

FAQ

素のCSSはBootstrapより優れていますか？ どちらが普遍的に優れているということはありません。素のCSSはより高いコントロールと依存関係のなさを提供し、Bootstrapはあらかじめ用意されたコンポーネントによって標準的なUIをより早くリリースできます。どちらが自分にとって適しているかは、プロジェクトが独自性のあるデザインを必要としているか、それとも素早いリリースを優先すべきかによって決まります。

Tailwind CSSは素のCSSより優れていますか？ Tailwind CSSは、設定可能なデザイントークンとutilityクラスを提供することで、独自のデザインシステムの構築を加速させます。一方、素のCSSはフレームワークの層を一切挟まずに完全なコントロールを提供します。スタイリングをマークアップと同じ場所に置きたいチームはTailwindを好む傾向があり、CSSに対して抽象化を一切挟みたくないチームは素のCSSを好む傾向があります。

BootstrapはTailwind CSSより優れていますか？ それはプロジェクト次第です。Bootstrapは既製のコンポーネントによって標準的な見た目のUIを素早くリリースでき、Tailwind CSSは独自のデザインシステムを構築する上でより柔軟性があります。あらゆるユースケースにおいて、どちらかが厳密に優れているわけではありません。

CSSフレームワークとは何ですか？ CSSフレームワークとは、あらかじめ用意されたスタイル(多くの場合コンポーネントも含む)のセットであり、すべてのCSSルールをゼロから書く手間を省いてくれるものです。BootstrapとTailwind CSSはどちらもCSSフレームワークですが、component-firstとutility-firstという、まったく異なるアプローチを取っています。

Tailwind CSSはCSSフレームワークですか？ はい、Tailwind CSSは一般的にCSSフレームワークに分類されます。ただしBootstrapのようなcomponent-firstなフレームワークではなく、utility-firstなフレームワークであり、完成したUIコンポーネントではなく、設定可能なデザインのプリミティブを提供します。

BootstrapとTailwindを併用できますか？ 技術的には可能ですが、ほとんどのプロジェクトでは推奨されません。両方のライブラリが独自のutilityクラスとリセットクラスを定義しているため、競合が起きたり、CSSの出力が肥大化したりする可能性があります。多くのチームは、両者を組み合わせるのではなく、プロジェクトごとにどちらか一方のアプローチを選んでいます。

フレームワークの代わりに素のCSSを使うべきなのはどんなときですか？ プロジェクトが小規模である場合、デザインが高度にカスタムである場合、あるいはフレームワークの規約やバンドルサイズを完全に避けたい場合には、素のCSSが理にかなった選択肢になります。手作業は増えますが、その分最大限のコントロールが得られます。