コンポーネントライブラリが不要なとき

2026年において、小規模・高度なブランディングが求められる・パフォーマンスを重視するプロジェクトのほとんどでは、コンポーネントライブラリは必要ありません。必要なのは、レイアウト用のユーティリティCSSと、本当に難しい3〜4つのインタラクティブな動作に対応するヘッドレスプリミティブです。MUI、Ant Design、Chakraのような完全なスタイル付きライブラリが価値を発揮するのは、特定の条件下に限られます。複数チーム間での一貫性の確保、出荷速度がブランドより優先される社内ツール、あるいは専任のデザインリソースがない場合です。それ以外の状況では、バンドルサイズ・カスタマイズの手間・画一的な見た目というコストが、得られるメリットを上回ることがほとんどです。本記事では、意思決定のフレームワークを提供します。ライブラリをデフォルトで採用することの実際のコスト、本当に不要なケース、本当に必要なケース、そして「何もなし」から「フルライブラリ」までの具体的なステップを示すことで、実際の問題を解決できる最低限の選択肢を選べるようにします。

最初に重要な視点の転換を示しておきます。「コンポーネントライブラリを使わない」とは、「ドロップダウンを自前で実装する」という意味では決してありません。ユーティリティCSSと、正しく実装するのが難しい動作に対応する実績あるヘッドレスプリミティブを組み合わせるということです。

コンポーネントライブラリをデフォルトで採用することの実際のコスト

完全なコンポーネントライブラリには、プロジェクトのライフサイクルを通じて複利的に積み重なる3つのコストがあります。バンドルサイズ・カスタマイズの摩擦・画一的な見た目です。それぞれ単独では致命的ではありませんが、組み合わさることで、マーケティングサイトや5画面程度のアプリにMUIを導入するのがなぜ割に合わないトレードオフなのかが明確になります。

バンドルサイズ。 モノリシックなスタイル付きライブラリは、テーミングランタイム・コンポーネントレジストリ・デザイントークンといったベースラインのCSSとJavaScriptを含んでいます。これらは、3つのコンポーネントを使おうと30個使おうと、常に配信されます。ツリーシェイキングは有効ですが、ライブラリが真にモジュール化されている場合に限られます。コンポーネントごとのパッケージはツリーシェイキングが効果的に機能します。radix-uiパッケージはツリーシェイカブルであるため、使用するコンポーネントのみを配信できます。一方、モノリシックなテーマやスタイリングのペイロードは同様には軽量化されません。ランタイムがすべてのコンポーネントから参照される共有依存関係だからです。「ツリーシェイキングで解決できる」という主張の正直なところ：モジュール化されたプリミティブには有効ですが、スタイリングエンジンが単一のランタイムであるライブラリには当てはまりません。

カスタマイズの摩擦。 プロジェクトのデザインが汎用的で短命であれば、既製ライブラリが圧倒的に有利です。しかし、デザインが独自性を持ち長期間使われるものであれば、インポートするスタイル付きコンポーネントのひとつひとつが、プロジェクトの存続期間中ずっと戦い続けることになる詳細度の問題になります。ネストされたセレクターのオーバーライド、テーマのデフォルト値との戦い、ブランドに合わせるためのコンポーネントのラッピングが続きます。

画一的な見た目。 ライブラリのデフォルトは、意図的に中立的に設計されています。独自のブランディングを実現するには大量のオーバーライドが必要となり、それがカスタマイズコストに直結します。デザインがライブラリの思想から離れるほど、ライブラリを活用するのではなく、ライブラリと戦う部分が増えていきます。

コンポーネントライブラリが不要なとき

UIが主に静的であるか、デザインに独自性があるか、パフォーマンスが厳しい制約となっている場合、コンポーネントライブラリは不要です。これらのプロジェクトでは、ライブラリは純粋なオーバーヘッドです。

• ランディングページ・ブログ・ポートフォリオ。 主にタイポグラフィ・レイアウト・少数のインタラクティブな装飾で構成されます。スタイリングはユーティリティCSSで対応でき、必要なインタラクティブコンポーネントはほんの数個です。
• 高度にブランディングされたアプリ。 デザインがプロダクトのアイデンティティである場合、ライブラリのデフォルトは逆効果になります。ユーティリティクラスと少数の自前コンポーネントを組み合わせることで、他者の思想と戦うことなく完全なコントロールが得られます。
• パフォーマンスクリティカルなアプリ。 1バイト・1ミリ秒のインタラクションレイテンシーも重要な場合、数個のボタンのためにスタイル付きライブラリのランタイムを配信するのは適切なデフォルト選択ではありません。
• Tailwindを使用しているチーム。 チームがすでにユーティリティクラスでスタイリングしている場合、スタイル付きライブラリを追加すると、スタイリング層が重複し、見た目に関する2つの競合する情報源が生まれます。

ここで有用な区別を示しておきます。コンポーネントライブラリは既製のUI要素の集合であり、デザインシステムはその周辺の原則・トークン・使用ルールを含む、より広範なフレームワークです。後者が必要でも前者を採用する必要はありません。CSSカスタムプロパティのデザイントークンとユーティリティクラスの組み合わせで、誰かのコンポーネントをインポートせずに一貫性を実現できます。

コンポーネントライブラリが必要なとき

ブランドの独自性やバンドルサイズよりも、スケールでの速度と一貫性が重要な場合に、完全なスタイル付きライブラリを選択します。正当化できる状況は4つあります。

• 社内ツールと管理ダッシュボード。 バックオフィスのCRUDパネルに視覚的なアイデンティティは求められません。テーブル・フォーム・モーダル・日付ピッカーをすぐに使えるライブラリが、最速の出荷手段です。
• MVPとプロトタイプ。 デザインに投資する前にアイデアを検証することが目標であれば、既製コンポーネントで素早く動かし、必要に応じて捨てることができます。
• マルチチームのエンタープライズにおける一貫性。 多くのチームが1つのプロダクトに貢献する場合、共有ライブラリが統一された見た目と単一の更新パスを強制します。コンポーネントを一度修正すれば、すべての利用者がその恩恵を受けます。
• 専任のデザインリソースがない場合。 デザイナーもデザインシステムもない場合、ライブラリの合理的なデフォルトは、ほとんどのチームがアドホックに作り出すものより優れています。

共通点：いずれの場合も、ライブラリの意見が強いデフォルトは制約ではなく、機能として働きます。

意思決定のはしご：「何もなし」から「フルコンポーネントライブラリ」まで

「ライブラリを使う/使わない」の二択ではなく、段階的に考えましょう。各段階は機能とコストを追加します。実際のニーズが求める最低限の段階までしか上がらないようにしてください。これは、古典的なビルド対バイのスペクトラムを現代化したものです。

段階2 — ユーティリティCSS。 Tailwindは、スタイリングとレイアウト層の現実的なデフォルトです。Tailwind CSS v4.0は、パフォーマンスと柔軟性に最適化されたフレームワークの全く新しいバージョンであり、設定とカスタマイズの体験が刷新されています。主要なアーキテクチャの変更点として、Tailwind CSS v4はCSSを処理するオールインワンツールであり、Lightning CSSがフレームワークに直接統合されているため、CSSパイプラインについて何も設定する必要がありません。設定はtailwind.config.jsから@themeディレクティブを使ったCSSへと移行しました。パッチリリースは頻繁に行われるため、バージョン番号を暗記するより、プロジェクトでバージョンを固定することをお勧めします。2026年6月時点ではv4が最新です。

段階3 — ヘッドレスプリミティブ。 これは、古い「ライブラリを使わない」というアドバイスが軽視していた段階であり、最も重要な段階です。ヘッドレスプリミティブは、インタラクティブコンポーネントのアクセシブルな動作（キーボード操作・フォーカス管理・ARIAの配線）をスタイルなしで提供するため、独自のユーティリティクラスを適用できます。

Radix Primitivesが参照すべき選択肢です。アクセシビリティ・カスタマイズ性・開発者体験に重点を置いた低レベルUIコンポーネントライブラリであり、高品質でアクセシブルなデザインシステムとWebアプリを構築するためのオープンソースUIコンポーネントライブラリです。WorkOSによってメンテナンスされています。ダイアログ・ドロップダウン・ポップオーバー・ツールチップなど一般的なUIパターンのプリミティブを提供し、すべてWAI-ARIAに準拠しており、スクリーンリーダーのサポートとキーボードナビゲーションが確保されています。マルチフレームワークのチームには、Ark UI（Zag.jsのステートマシンを基盤とし、React/Vue/Solid/Svelteに対応）が同じ領域をフレームワークをまたいでカバーします。Reactを使用している場合は、AdobeのReact AriaとTailwind LabsのHeadless UI（ReactとVueをサポート）も同等の選択肢です。

明確に指摘しておくべき点があります。2026年においてReach UIは避けてください。Reach UIは現在メンテナンスされていません。メンテナーは2022年に「OSSバンクラプシー」を宣言しており、Reachが登場して以来、他のプロジェクトが低レベルでコンポーザブルかつアクセシブルなコンポーネントを構築してきました。現在は複数のよくメンテナンスされたライブラリが存在し、RadixとReact Ariaがその筆頭です。「難しいもの」にReach UIを推奨している記事は、放棄された依存関係へと誘導しています。

段階4 — 単一目的コンポーネント。 検索可能なマルチセレクト・日付範囲ピッカー・リッチテキストエディタなど、1つのウィジェットが本当に難しい場合は、UIキット全体を採用するのではなく、そのウィジェット専用の実績あるパッケージを導入しましょう。

また、プラットフォーム自体がかつてライブラリを必要としていた問題を吸収してきた点も注目に値します。React 19では、トランジション内での非同期関数のサポートにより、保留状態・エラー・フォーム・楽観的更新が自動的に処理されます。新しいフォームアクションとuseActionState・useFormStatus・useOptimistic・use() APIにより、特定のフォームに対して「フォームライブラリが必要」という理由が減少しています。はしごを上る理由が少なくなることは、良いことです。

インタラクティブコンポーネントを自前実装することの隠れたコスト

「ライブラリを使わない」がすべてを自前で構築することを意味してはならない理由は、アクセシビリティとエッジケースの動作にあります。自前実装のドロップダウンで最もコストがかかる部分はマークアップではなく、キーボードナビゲーション・フォーカストラップ・外部クリックによる閉じる処理・スクリーンリーダーへのアナウンスです。これらはヘッドレスプリミティブが無償で提供してくれます。

これはまさにRadixの作者たちが指摘するギャップです。Webプラットフォームがこれらのパターンに対して提供する実装は不十分であり、存在しないか、機能が不足しているか、カスタマイズが不可能です。そのため開発者はカスタムコンポーネントを構築せざるを得ませんが、これは非常に困難なタスクです。その結果、Web上のほとんどのコンポーネントはアクセシブルでなく、パフォーマンスが低く、重要な機能が欠けています。

自前実装のインタラクティブコンポーネントにおけるアクセシビリティの失敗は、セッションリプレイが本番環境で表面化するバグの種類です。カスタムビルドのコントロールのリプレイを見ることで、「自分で作ればいい」という考えの真のコストが明らかになります。カスタムモーダルからフォーカスが外れてページの背後に落ちてしまうキーボードユーザー、外部クリックやEscapeキーの処理がないために閉じないドロップダウンを何度もタップするモバイルユーザー、オプションをスクリーンリーダーに通知しないコンボボックスに諦めてしまうユーザー。これらはまさにヘッドレスプリミティブがデフォルトで処理する動作であり、自前実装のコンポーネントが誰かが実際に使うまで静かに間違え続ける動作です。

重要な教訓は「常にプリミティブを使え」ではありません。DIYのインタラクティブコンポーネントのコストは、マークアップを書く時点ではなく、後からアクセシビリティのバグや放棄されたインタラクションとして支払われるということです。自前実装を決断する前に、そのコストを見積もってください。

意思決定チェックリスト

段階を選ぶ前に、プロジェクトを5つの質問で評価してください。

1. ライフスパン。 使い捨てのプロトタイプか、複数年にわたるプロダクトか？短命なものは既製品が有利であり、長命なものはスタイリング層を自分で管理することが有利です。
2. ブランドの独自性。 汎用的でテンプレート的か、独自のアイデンティティを持つか？独自のデザインは、スタイル付きライブラリをリスクにします。
3. チームサイズ。 1チームか、複数チームが1つのプロダクトに貢献するか？マルチチームでの一貫性は、共有ライブラリの最も強力な根拠です。
4. パフォーマンス予算。 バンドルサイズやインタラクションレイテンシーが厳しい制約か？そうであれば、モノリシックなランタイムよりもユーティリティCSSとコンポーネントごとのプリミティブを優先してください。
5. メンテナンス体制。 デザイナーがいて、カスタム層をメンテナンスできる体制があるか？デザインリソースがない場合は、ライブラリの合理的なデフォルトに頼ることになります。

ほとんどの答えが「短命・汎用・マルチチーム・デザイナー不在」を指しているなら、段階5まで上がってください。「長命・独自性あり・1チーム・パフォーマンス予算が厳しい」を指しているなら、段階2と3にとどまってください。

まとめ

2026年の新しいフロントエンド開発のデフォルトは、スタイリングにユーティリティCSSを使い、正しく実装するのが難しい少数のインタラクションにヘッドレスプリミティブを使うことです。スケールでの一貫性・純粋な出荷速度・デザインリソースの不在が、意見の強いデフォルトを資産にする場合にのみ、完全なスタイル付きライブラリへと上がります。習慣的にUIキットをnpm installする前に、5つの質問のチェックリストを実行し、目の前の問題を解決できる最低限の段階を選んでください。習慣ではなく意図を持って構築し、どれだけのライブラリが本当に必要かをプロジェクト自身に決めさせましょう。

よくある質問

ヘッドレスコンポーネントライブラリとスタイル付きコンポーネントライブラリの違いは何ですか？

Radix Primitives・React Aria・Headless UIなどのヘッドレスライブラリは、インタラクティブコンポーネントの動作とアクセシビリティ（キーボードナビゲーション・フォーカス管理・ARIAの配線）をスタイルなしで提供します。独自のCSSやユーティリティクラスを適用できます。MUI・Ant Design・Chakra UIなどのスタイル付きライブラリは、動作と意見の強いビジュアルデザイン、そしてテーミングランタイムの両方を提供します。ヘッドレスは利便性を犠牲にして、完全なビジュアルコントロールとより小さなスタイリングのフットプリントを得ます。

同じプロジェクトでTailwind CSSとコンポーネントライブラリを併用できますか？

可能ですが、通常はスタイリング層が重複し、見た目に関する2つの競合する情報源が生まれます。スタイル付きライブラリは独自のテーミングランタイムを持つため、Tailwindと組み合わせると両方をメンテナンスすることになります。よりクリーンな組み合わせは、スタイリングにTailwindを使い、独自のスタイルを持たずユーティリティクラスでスタイリングするよう設計されたRadix・React Aria・Ark UIなどのヘッドレスプリミティブを組み合わせることです。

なぜReach UIはアクセシブルなReactコンポーネントとして推奨されなくなったのですか？

Reach UIは公式GitHubリポジトリによると、現在メンテナンスされていません。メンテナーは2022年にOSSバンクラプシーを宣言し、それ以来アクティブな開発は行われていません。2026年時点でドロップダウン・ツールチップ・その他の難しいインタラクティブパターンにReach UIを推奨するガイダンスは、放棄された依存関係へと誘導しています。かつてReach UIが担っていたアクセシブルなプリミティブの役割は、現在Radix PrimitivesとAdobeのReact Ariaが担っており、両者とも完全なWAI-ARIAキーボードおよびフォーカスサポートでアクティブにメンテナンスされています。

React・Vue・Solid・Svelteをまたいで動作するヘッドレスコンポーネントライブラリはどれですか？

Ark UIがフレームワーク非依存の選択肢であり、Zag.jsのステートマシンを基盤としてReact・Solid・Vue・Svelteに対応しています。ほとんどのヘッドレスプリミティブはフレームワーク固有です。Radix PrimitivesとAdobeのReact AriaはReactを対象とし、Tailwind LabsのHeadless UIはReactとVueをサポートします。1つの組織内で複数のフレームワークをまたいでコンポーネントロジックを共有する必要がある場合、Ark UIはそのユースケースのために設計されています。基盤となる動作が単一のフレームワークバインディングではなくZag.jsに存在するためです。