🧩 shadcn/ui が Base UI をデフォルトに変更 — Radix との違い・migration(移行)手順・既存プロジェクトへの影響

npx shadcn init を叩いたら、知らない間に Base UI が入っていた。え、いつから？——と思ってログを追ったら、2026年7月にデフォルトが変わっていた。

「また依存ライブラリが変わった……」と思う気持ちはわかる。でも今回は、移行を急ぐ必要はない。

なぜデフォルトが変わったのか

shadcn/ui チームは昨年から npx shadcn create で両ライブラリを選べるようにしていた。ユーザーに選ばせて、どっちが選ばれるかデータを取っていた。

結果は明快だった。新規プロジェクトの約 2/3 が Base UI を選択した。Base UI v1.6.0 は週間 600 万ダウンロードに達し、shadcn/ui チーム自身も新規プロジェクトで Base UI を使い始めた。データが答えを出したので、デフォルトを変えた。それだけの話なんですよね。

Radix と Base UI、何が違う？

Base UI は Radix の開発チームが「次に作ったライブラリ」だ。同じ人たちが作ったので思想は近いが、設計が整理されている。

一番わかりやすい違いはパッケージ構成。Radix はコンポーネントごとにパッケージが分かれていて、@radix-ui/react-dialog、@radix-ui/react-dropdown-menu ……と使うたびに package.json が膨らんでいく。Base UI は @base-ui-components/react の 1 パッケージに全部入っている。

API も変わった。Radix の asChild パターンが Base UI では render prop になった。

// Radix
<Dialog.Trigger asChild>
  <Button>開く</Button>
</Dialog.Trigger>

// Base UI
<Dialog.Trigger render={<Button />}>
  開く
</Dialog.Trigger>

書き方は変わるが、やっていることは同じ。一見大きな変更に見えるけど、結構シンプルな話だ。アクセシビリティ対応の品質も両者とも高い。

既存プロジェクト、どうすれば？

何もしなくていい。 Radix は廃止されない。

shadcn/ui チームは「Radix は今日も本番で使っており、移行していない」と明言している。既存の Radix ベースのプロジェクトはそのまま動き続ける。

ただし、CI やスクリプトで shadcn init を自動実行している場合は要注意。何も指定しないとデフォルトが変わっている。Radix を使い続けたいなら明示が必要になった。

# Base UI(新しいデフォルト)
npx shadcn init

# 今まで通り Radix を使いたい場合
npx shadcn init -b radix

CI スクリプトに -b radix を追加するだけ。1 行で済む。

移行するなら AI に任せていい

Base UI に切り替えたい場合、shadcn/ui はコードモッドではなく AI スキルで対応している。

pnpm dlx skills add shadcn/ui

インストール後、エージェントに migrate accordion to base-ui と指示するだけ。カスタマイズしたクラスやバリアントを引き継ぎながらコンポーネント単位で移行してくれる。60 以上のコンポーネントを約 25 分で移行できたという報告もある。

コードモッドと違って型チェックが通り、git 履歴もきれいに保たれる。急いで全部移行する必要はない。気になるコンポーネントから 1 本ずつやってみるのが現実的だと思う。

今回追加されたコンポーネント

チャット UI 向けが充実した。

コンポーネント	用途
MessageScroller	スクロール動作とメッセージ管理
Message / Bubble	会話 UI の基本要素
Attachment / Marker	ファイル添付・既読マーカー

CSS ユーティリティとして scroll-fade(スクロール端のフェード)と shimmer(ストリーミング表示)も追加。AI チャット UI を作っているなら押さえておきたい。

GitHub Registry にも対応した。任意の GitHub リポジトリを registry.json で shadcn/ui 互換コンポーネントとして配布できる。社内デザインシステムを npm に上げずに配布できる——地味に、かなり便利だと思う。

render prop に切り替えるとハマるところ

asChild から render に機械的に置き換えるだけでは、たまに壊れる。

一番多いのが ref の受け渡し。Radix の asChild は子コンポーネントに forwardRef があれば自動でつながっていたが、Base UI の render は渡す要素自体が ref を受け取れる構造になっている必要がある。自作コンポーネントを render={<MyButton />} のように渡すと、クリックは通るのにフォーカス管理だけ動かない——みたいな地味なバグを踏みやすい。

もう一つは型。Base UI は「型安全性優先派」と言われるだけあって、render の型が渡す要素のpropsと厳密に噛み合っている必要がある。Radix では素通りしていた微妙な型不一致が、Base UI ではコンパイルエラーとして表面化することがある。移行時にエラーが増えたら、ライブラリのせいではなく元々あったズレが見えるようになったと捉えたほうがいい。

コンポーネント単位で移行するときは、まず ref を使っている箇所(フォーカス制御・アニメーション連携)から手をつけると、後半で楽になる。

---

デフォルトが変わっただけで、Radix は消えない。CI スクリプトに 1 行足せば何も変わらないよ。

新規から始めるなら Base UI を素直に選んでいいと思う。パッケージが 1 つにまとまっていて、API も整理されている。移行も AI に任せればいい。「Radix か Base UI か」で迷う時間、もう要らないんじゃないかな。

パッケージが1つでも、軽くなるとは限らない

ここは意外だった。「@base-ui-components/react に全部入り」と聞くと、依存がまとまって軽くなる気がしてしまう。でも実際は逆で、Base UI 公式リポジトリの Issue #3688 では、Radix と比べて minified で 20〜30KB、gzip換算でも+10KB前後大きいと報告されている。

理由は単純だ。1パッケージにまとめた分、コンポーネント単位でのツリーシェイキングが Radix ほど削れない。Radix は @radix-ui/react-dialog だけ入れれば他のコンポーネントは一切バンドルされないが、Base UI は今のところそこまで割り切れていない。

バンドルサイズにシビアなプロジェクトなら、移行前に一度ビルド後のサイズを計測しておいたほうがいい。「1パッケージ=シンプル」は開発体験の話であって、配信サイズが軽くなる話ではないんだよね。

Radixにない機能で選ぶという選択肢

バンドルサイズやCI設定の話ばかりしてきたけど、実は「Base UIじゃないと無理」なケースもある。

Combobox、Autocomplete、Number Field。この3つはBase UIにあってRadixにはまだない。検索候補付きの入力欄や数値スピナーを自前で作った経験がある人ならわかると思うけど、キーボード操作とARIA属性を1から実装するのは地味にしんどい。

新規プロジェクトでこの手のコンポーネントが要件に入っているなら、パッケージ構成やバンドルサイズを気にする以前にBase UI一択になる。逆に既存Radixプロジェクトで必要になったときは、そこだけBase UIを部分導入する手もある。「全部移行 or 何もしない」の二択じゃなくていい。

RadixからBase UIへの migration(移行)手順まとめ

ここまでの話を、実際に移行するときの順番に並べ直しておく(2026-07-23追記)。

1. ビルドサイズの基準値を取る。移行前に一度 next build なり vite build なりでバンドルサイズを記録しておく。前述の通りBase UIはgzipで+10KB前後大きくなる報告があるので、シビアなプロジェクトは先に判断材料を持つ
2. AIスキルを入れる。pnpm dlx skills add shadcn/ui。コードモッドではなくエージェント移行が公式ルートだ
3. コンポーネント単位で移行を指示する。migrate accordion to base-ui のように1本ずつ。最初はrefを使っている箇所(フォーカス制御・アニメーション連携)から着手すると後半が楽になる
4. 型エラーを潰す。render propは渡す要素のpropsと厳密に噛み合う必要がある。エラーが増えたら、元々あったズレが見えるようになったと考える
5. data-testid を持たせ直す。次のセクションの通り、asChildが自動で引き継いでいた属性は render={<Button data-testid="submit" />} と明示が要る

全部一気にやらない。1コンポーネントを1つ移してテストを通しコミットする、という小さいサイクルで回すのが、60超のコンポーネントを約25分で移行できたという報告の実態でもある。

テストコードは無傷では済まない

移行作業をコード側だけで完結させようとすると、Testing LibraryやPlaywrightのテストが静かに壊れる。

RadixのasChildはforwardRefを通じてdata-testidやARIA属性を子要素にそのまま引き継いでいた。Base UIのrenderは渡した要素自体がpropsを受け取る構造なので、render={<Button />}と書いただけではdata-testidが消えていることがある。render={<Button data-testid="submit" />}のように、テスト用の属性を明示的に持たせ直す必要がある。

getByRoleベースのクエリはARIA属性がそのまま保たれるので影響を受けにくいが、getByTestIdに依存しているテストスイートは、コンポーネント移行のたびに1件ずつ落ちる。移行を進める前に、対象コンポーネント配下のテストでdata-testidを使っている箇所を先に洗い出しておくと、後から慌てずに済む。