はじめに

前回、.tsと.tsxの違いを整理する中で、Reactは「コンポーネント」という部品を組み合わせて画面を作るという話をしました。

今回はその続きとして、「UIコンポーネントとは何か」を改めて整理したうえで、最近よく耳にする shadcn/ui というライブラリが、なぜ「これはライブラリではない」と言われるのかを見ていきます。

1. そもそもUIコンポーネントとは何か

UIコンポーネントとは、ボタンやフォーム、モーダル、プルダウンメニューといった、画面を構成する部品のことです。

たとえば「ボタン」ひとつを取っても、実際には次のような要素が組み合わさってできています。

これらを画面に必要なボタンやフォームの数だけ、毎回一から作るのは大変な作業です。

そこで登場するのが、あらかじめこうした部品を用意してくれる「UIライブラリ」です。

これまで主流だったUIライブラリには、MUI（Material UI）やChakra UIなどがあります。

これらは、npm でパッケージとしてインストールし、完成されたボタンやカードを「外部からインポートしてそのまま呼び出す」という仕組みです。

普段Pythonを触っている方であれば、 pandas などのライブラリをインポートして、中身のコードは読まずに関数だけを呼び出す感覚に非常に近いです。

この「できあがった既製品を呼び出す」方式には、確かなメリットと、実務で直面するデメリットが存在します。

圧倒的な導入スピード： インストールしたその瞬間から、洗練されたデザインのボタンやテーブルがすぐに画面に表示できます。
デザインの一貫性： ライブラリ独自の優れたデザインシステムが背後にあるため、自分で細かいスタイルを書かなくても、適当に組み合わせるだけでUIの統一感を保証してくれます。

中身がブラックボックス： コンポーネントのソースコードはライブラリの内部（node_modules）に隠されています。そのため、「ボタンのこの挙動を少しだけ変えたい」と思っても、直接コードを書き換えることはできません。
オプション（引数）の限界： 見た目やロジックを変更したい場合は、ライブラリ側があらかじめ用意してくれているプロパティ（オプション）の範囲内で調整するしかありません。
スタイルの上書き問題： 用意されたオプションを超えた独自デザインを当てようとすると、ライブラリの基本スタイルを無理やり上書きするような泥臭いハックが必要になり、コードがかえって複雑化してしまうことも珍しくありません。

こうしたカスタマイズの限界という背景の中で登場したのが shadcn/ui （読み方：シャドシーエヌ　ユーアイ）です。

shadcnが従来のライブラリと決定的に違うのは、「コンポーネントのコードを、パッケージとしてではなく、ファイルとしてプロジェクトの中に直接コピーしてくる」という点です。

普段Pythonを触っている感覚で例えるなら、MUIなどの従来型は pip install して中身をブラックボックスのままインポートして使う外部パッケージ です。

一方でshadcnは、「Web上の優秀なソースコードを自分の utils.py に丸ごとコピペしてきて、自分好みに書き換えながら使う」 というスタイルに近いです。

一般的なライブラリは node_modules の中に格納され、開発者がその中身を直接編集することはありません。

ところがshadcnでは、コマンドを実行するとボタンやフォームのソースコード（.tsx ファイル）そのものが、手元のディレクトリに生成されます。

インストールした瞬間から、そのコードは「外部ライブラリ」ではなく「自分のプロジェクトのコード」になります。これが、shadcnが「ライブラリではない」と言われる理由です。

この「コードを所有する」という発想には、実務上いくつかのメリットがあります。

まず、カスタマイズの自由度が上がります。

コンポーネントの中身が手元のファイルとしてあるので、色やレイアウト、振る舞いを直接書き換えられます。

ライブラリ側が用意したオプションの範囲に縛られることがありません。

次に、依存関係の管理がシンプルになります。

従来のライブラリは、ライブラリ自体のバージョンアップに合わせてアプリ側の対応が必要になることがありますが、shadcnの場合は一度コピーしたコードは自分のプロジェクトの資産になるため、ライブラリ側の更新に振り回されることが少なくなります。

一方で、裏を返すとメンテナンスの責任も自分たちに移るということでもあります。

バグ修正やアクセシビリティ対応など、本来ライブラリ側が担っていた部分も、自分たちで面倒を見る必要が出てきます。

shadcnは内部的にRadix UIというアクセシビリティに強いライブラリを土台に使っているため、基礎的な部分はある程度守られていますが、この特性は理解しておく価値があります。

ここまでの内容を簡単に整理すると、次のようになります。

どちらが優れているというより、プロジェクトの性質によって向き不向きがあります。

デザインの独自性を出したい、細かい調整を頻繁に行いたいプロジェクトはshadcnと相性がよく、逆にとにかく早く一貫したUIを組みたい場合は従来型のライブラリが向いていると言えます。

UIコンポーネントとは、ボタンやフォームなど画面を構成する部品のことであり、UIライブラリはそれを一から作らずに済ませるための仕組みでした。