「shadcn/uiって実際どうなの？」

正直、最初に名前を聞いたとき、「またUIコンポーネントライブラリか」と思いました。Chakra UI、Material UI、Ant Design……フロントエンドの世界にはUIライブラリが星の数ほどあって、乗り換えのたびに「なんで俺はまたこれをやってるんだ」という気持ちになる経験を何度もしていたので。

でも、4月の連休明けに担当しているNext.jsプロジェクトでデザイナーさんから「shadcn/uiで実装してほしい」という要望が来て、腹をくくって1ヶ月間使い込みました。

結論から言うと、「CLIでコンポーネントをコピーするUIライブラリ」という設計思想が、他のライブラリと根本的に違うというのが最大の発見でした。そしてこの思想を理解してから、評価が180度変わった。

この記事では、1ヶ月の実践を週ごとに振り返りながら、shadcn/uiの本当の強みと、正直な弱点を書いていきます。

---

1週目：「npmでインストールしない」という衝撃

4月7日（月）。連休明けの初日、まずセットアップから入りました。

Next.js + TypeScriptのプロジェクト構成はすでにあったので、あとはshadcn/uiを入れるだけ——のはずが、最初に引っかかりました。

npx shadcn@latest init

ここまでは普通です。問題はその後。

npx shadcn@latest add button

このコマンドを叩くと、src/components/ui/button.tsx というファイルが生成される。npmパッケージとしてインストールされるんじゃなくて、コードが直接プロジェクトにコピーされるんです。

最初、「え、これバグ？」と思いました。node_modulesに何も入らないのに、コンポーネントが動く。

正直、当時の僕は「なんか気持ち悪いな」と感じていました。でもこの感覚、3日後に完全に消えました。

生成されたbutton.tsxを見ると、コードがまるっと書いてある。TypeScriptのtype定義もしっかりついていて、カスタマイズするときにそのまま編集すればいい。

// src/components/ui/button.tsx（shadcn/ui生成コード）
import * as React from "react"
import { Slot } from "@radix-ui/react-slot"
import { cva, type VariantProps } from "class-variance-authority"
import { cn } from "@/lib/utils"

const buttonVariants = cva(
  "inline-flex items-center justify-center...",
  {
    variants: {
      variant: {
        default: "bg-primary text-primary-foreground hover:bg-primary/90",
        destructive: "bg-destructive text-destructive-foreground...",
        outline: "border border-input bg-background hover:bg-accent...",
      },
      size: {
        default: "h-9 px-4 py-2",
        sm: "h-8 rounded-md px-3 text-xs",
        lg: "h-10 rounded-md px-8",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
)

ここがポイントなんですが、このコードは自分のリポジトリの中にある。つまり、ライブラリのアップデートで破壊的変更があっても、自分のコードには影響しない。

「プログラミング的に言うと、依存関係を自分でコントロールできる」ということです。

ただ、1週目の終わりにつまずきがありました。TailwindCSSの設定がtailwind.config.tsに正しく設定されていないと、スタイルが全く当たらない。ここで1.2時間溶かしました。公式ドキュメント通りにやったつもりが、contentのパス指定が抜けていた。些細なミスですが、初回はそこで引っかかりがちです。

---

2週目：実案件で使って気づいた「本当の強み」

2週目からは、フォームを中心に実装を進めました。

shadcn/uiの中で最も感動したのが、Radix UIとの組み合わせによるアクセシビリティの担保です。

Dialog、Select、Comboboxなどのコンポーネントは、内部でRadix UI Primitivesを使っています。これの何が嬉しいかというと、WAI-ARIAに準拠したマークアップが最初から入っている。フォーカス管理、キーボードナビゲーション、スクリーンリーダー対応——これを自前でやろうとすると、下手すると1週間かかります。

（ちょっと話が逸れますが、アクセシビリティって、意識していないと後から直すのが本当に大変なんですよね。shadcn/uiはこれを「最初から入ってる」状態にしてくれる。プログラミング的に言うなら、「型安全」と同じような安心感があります）

もう一つ気づいたのが、VS Codeの補完との相性の良さ。コンポーネントのpropsが全部TypeScriptで定義されているので、Buttonを書いた瞬間にvariant・sizeの選択肢が全部サジェストされる。これは地味に快適でした。

正直、ここは微妙だなと思った点も書きます。

shadcn/uiの弱点: スタイルの上書きが癖になる

TailwindCSSのクラスを直接書く設計なので、カスタマイズの自由度は高い。でも「デフォルトのButtonに少しだけ手を加えたい」みたいなケースで、cn()関数でクラスを合成するのが最初は直感的じゃない。MUIみたいなsx propに慣れている人は、少し戸惑うと思います。

// こういう書き方に慣れるまで、2週間くらいかかった
<Button
  className={cn(
    "w-full", // 幅を広げたいとき
    isLoading && "opacity-50 cursor-not-allowed" // 条件付きスタイル
  )}
>
  送信する
</Button>

週の後半はこのcn()の使い方に慣れることに時間を使いました。

---

3〜4週目：チームへの導入と予想外の展開

3週目から、もう一人のエンジニア（同じく独学出身のjr.）にshadcn/uiを引き継ぎました。

ここで意外な問題が発生しました。「コンポーネントがnode_modulesにない」という概念が伝わりにくかった。

「shadcn/uiのButtonを変更したいんですけど」→「src/components/ui/button.tsxを直接編集していいよ」→「え、それって公式のコードを上書きするんですか？」

この会話を3回しました（笑）。

ここがshadcn/uiの思想的な転換点で、「ライブラリのコードをそのまま使う」から「コードをオーナーシップとして持つ」に変わる。コードで言うなら、node_modules内の読み取り専用ファイルから、自分のsrcディレクトリにある編集可能なファイルへの移行です。

この概念が浸透してからは、むしろ「このButtonにローディングスピナー追加したいんで、直接いじります」という会話が自然に出てくるようになりました。

4週目は、React Server Componentsとの組み合わせで詰まる時間がありました。shadcn/uiのコンポーネントはデフォルトでClient Componentとして動作するものが多く、"use client" ディレクティブの管理を意識する必要があります。これはshadcn/ui固有の問題というよりReactの話ですが、組み合わせ時の注意点として残しておきます。

---

1ヶ月後の総合評価 — 正直に点数をつける

カスタマイズ性: 95点 コードが手元にある設計上、カスタマイズの自由度は事実上無制限。デザインシステムを構築するうえで、これ以上の柔軟性は必要ないと思います。

学習コスト: 70点 TailwindCSSとRadix UIの知識がある程度必要。ゼロスタートだと辛い。逆に言えば、CSS/TailwindCSSの基礎がある人なら1週間あれば実務で使えます。

実務での安定性: 88点 ライブラリのバージョンアップで壊れるリスクがほぼゼロ（コードが手元にあるため）。長期プロジェクトへの安心感がある。ただし、コンポーネントが増えるとui/ディレクトリの管理が少し大変になる。

チーム導入しやすさ: 75点 「npmパッケージじゃない」という概念の浸透に時間がかかる。ドキュメントを共有して、1回ペアプロしてから引き継ぐのがベスト。

総合: 85点/100点

4週間使って、MUIに戻ろうと思った瞬間は一度もありませんでした。特にポートフォリオ制作や個人プロジェクトでは、shadcn/uiの「コードが手元にある」安心感は他のライブラリにはない体験です。

---

shadcn/uiをおすすめする人・しない人

こんな人には絶対おすすめです

• TailwindCSSをすでに使っている人
• Next.js + TypeScriptの構成で開発している人
• デザインシステムをゼロから作りたいフリーランス・スタートアップ
• 長期運用するプロジェクト（ライブラリ依存を最小化したい）

正直、合わないケース

• TailwindCSSをまだ学習中の人（shadcn/uiの前にTailwindをマスターした方が良い）
• 「とにかく速くUIを組みたいだけ」という短期プロジェクト（MUIの方が早い場合もある）
• ぶっちゃけ、社内にTailwindを書ける人がいない環境だと管理コストが上がります

（ここまで書いてたらコーヒーが完全に冷めた。shadcn/uiについて書き始めると止まらない）

ここで一度、「“いや、Mantine UIはどうなの？“って思ってる人、います？」と聞かせてください。

Mantine UIは確かに強力で、TailwindCSSに依存しない分だけ学習コストは低い。ただ、Next.jsのApp RouterやRSCとの相性を考えると、今のトレンドではshadcn/uiに軍配が上がると思っています。2026年5月時点では特に。

---

よくある質問

Q: shadcn/uiって無料で使えるの？商用利用も大丈夫？

A: 完全無料で、商用利用も問題ありません。MITライセンスです。コードが手元にコピーされる設計なので、どう変更しても問題ない。フリーランスの案件でも迷わず使えます。

Q: shadcn/uiとMUI（Material UI）どっちがいいの？

A: 用途次第です。MUIはすぐに見た目の整ったUIを作れる分、カスタマイズに癖があります。shadcn/uiはセットアップにTailwindCSSが必要ですが、デザインの自由度が高い。Figmaのデザインカンプを正確に再現したいならshadcn/ui、Googleマテリアルデザインで十分ならMUIです。

Q: Next.js以外（ViteのReactプロジェクト等）でも使えますか？

A: 使えます。shadcn@latest init時にフレームワークを選択できるので、Vite + React、Remix、Astroにも対応しています。ただ、公式のサポートが最も手厚いのはNext.jsなので、初めて使うならNext.jsでの構築が無難です。

Q: TypeScriptじゃないと使えない？JavaScriptだけでも動きますか？

A: JavaScriptでも動きます。ただ、shadcn/uiの強みの一つが「コンポーネントのpropsが型定義された状態で手元にある」ことなので、TypeScriptで使ってこそ恩恵が大きいです。TypeScriptを学ぶコストは1〜2ヶ月あれば十分なので、学んでから使う方をおすすめします。

Q: 初心者がshadcn/uiを使うのは早すぎる？

A: HTML/CSS/Reactの基礎が終わっていれば大丈夫です。Git/GitHubの操作とTailwindCSSの基礎があれば、公式ドキュメント通りに動かせます。「ReactもTailwindもまだ怪しい」という段階なら、先にそちらを固めてからがスムーズです。

---

追記（2026/05/13）: shadcn/ui v2系のアップデートでstorybook連携がより簡単になりました。コンポーネントのコードが手元にある設計なので、Storybookとの統合はMUIより格段にシンプルです。今後この組み合わせについても書く予定です。

---

というわけで、shadcn/uiの1ヶ月実践レポートでした。

最初の3日間の「これ本当にいいの？」という疑問が、4週目には「なんでもっと早く使わなかったんだ」に変わる——そういう体験ができるライブラリです。

フロントエンドの学習ロードマップについてはエンジニアロードマップ記事も参考にしてください。まずはnpx shadcn@latest initの1行から始めてみてください。