shadcn/ui が Base UI をデフォルトに — 公式発表から読み解く移行の背景と実務対応

Last updated at 2026-07-21Posted at 2026-07-21

はじめに

2026年7月、shadcn/ui の公式チェンジログに「Base UI as the Default」という一文が追加されました。新規プロジェクトを作成すると、これまでの Radix UI ではなく Base UI が標準の基盤になる、という内容です。

「shadcn/ui は普段から使っているけど、Radix UI と Base UI の違いまではよく分かっていない」というフロントエンドエンジニアも多いと思います。この記事では、まず前提となる用語を整理したうえで、今回のアップデートの中身と、既存プロジェクトへの実務的な影響を、公式ドキュメントの記述に沿って解説していきます。

対象読者は以下のような方を想定しています。

shadcn/ui を使ってプロダクト開発をしている、または検討している
Radix UI と Base UI の違いをきちんと理解したい
今のプロジェクトを Base UI に移行すべきか判断材料が欲しい
Material UI(MUI)を使っていて、Base UI との関係性や違いが気になっている

shadcn/ui とは何か

shadcn/ui は、React 向けの UI コンポーネント集です。ただし、一般的な UI ライブラリとは配布の形が根本的に違います。

Material UI のような従来型のライブラリは、npm install でパッケージを追加し、import して使います。コンポーネントの中身は node_modules の奥に隠れていて、基本的には触りません。

一方 shadcn/ui は、CLI(npx shadcn add button のようなコマンド)を実行すると、コンポーネントのソースコードそのものが自分のプロジェクトの components/ui フォルダにコピーされます。以降そのコードは完全に自分のプロジェクトの一部になり、自由に書き換えられます。「ライブラリを使う」のではなく「コードをもらって自分のものにする」という表現の方が近いです。詳しい仕組みは公式のInstallationドキュメントにまとまっています。

従来型ライブラリとの比較

「コードをコピーして使う」という配布方式は、従来型のライブラリと比べてメリットとデメリットが表裏一体になっています。どちらが優れているという話ではなく、トレードオフとして捉えるのがフラットな見方だと思います。

観点	従来型ライブラリ(MUIなど)	shadcn/ui
導入	`npm install` だけで即座に使える	CLIでコンポーネント単位にコードをコピーする手間がかかる
アップデート	`npm update` で追従できる。破壊的変更もライブラリ側の変更ログを追えば把握しやすい	コピーしたコードは自動更新されない。ライブラリ側にバグ修正や機能追加があっても、自分で再度コピーし直すか手動で反映する必要がある
カスタマイズ	テーマAPIやスタイルオーバーライドの仕組みに沿って行う。仕組みの外側に出る改修は難しいことがある	コードが手元にあるため、Tailwind CSSのクラスやロジックをそのまま直接編集できる。制約が少ない分、書き方の一貫性は自分たちで保つ必要がある
バンドルサイズ	ライブラリ全体もしくは使用コンポーネント分を読み込む(tree-shakingの効き方はライブラリ次第)	使った分だけがプロジェクトのコードとして存在するため、不要なコードを持ちにくい
品質の担保	ライブラリの開発元がテスト・アクセシビリティ・デザインの一貫性を担保してくれる	コピー後の品質担保(テスト、デザインの一貫性維持など)は自分たちの責任になる
チーム運用	全員が同じライブラリバージョンを参照するため、実装のブレが起きにくい	コンポーネントごとに手が入っている可能性があるため、プロジェクトが大きくなるほどコードの一貫性維持にコストがかかる
セキュリティ更新	脆弱性情報が出れば、ライブラリのバージョンを上げるだけで対応できることが多い	依存しているヘッドレスUI部分(Radix UIやBase UI)のアップデートは追従できるが、コピーしたコード自体の脆弱性は自己責任で気づいて直す必要がある

つまり shadcn/ui は、「アップデートの手間や品質担保の責任を引き受ける代わりに、自由度と依存関係のシンプルさを得る」という選択です。逆に、チームの人数が多く、デザインの一貫性やメンテナンスコストを一元管理したい場合は、従来型ライブラリの方が向いていることもあります。

ヘッドレスUIという考え方

shadcn/ui のコンポーネントは、見た目(スタイル)の部分を自分たちで書いていますが、内部の「振る舞い」の部分は自分たちでは作っていません。ここで登場するのが ヘッドレスUI(headless UI) という考え方です。

ヘッドレスUIとは、見た目を一切持たず、以下のような「動作」の部分だけを提供するライブラリを指します。

キーボード操作(Tab で要素を移動する、Escape でダイアログを閉じるなど)
フォーカス管理(モーダルを開いたときにフォーカスをどこに移すか)
スクリーンリーダー向けの ARIA 属性の付与
開閉状態やホバー状態などのロジック管理

つまり「見た目」と「振る舞い」を分離し、振る舞いの部分だけを土台として提供するのがヘッドレスUIです。shadcn/ui は、この土台の上に Tailwind CSS でスタイルを乗せることで成り立っています。

そして、この土台の部分に何を使うかというのが、今回のアップデートの本題です。これまで shadcn/ui はこの役割を Radix UI に任せてきましたが、Base UI という新しい選択肢が加わりました。

Radix UI・Base UI・Material UI の関係

ここが今回の話の肝になる部分です。混乱しやすいポイントなので、先に全体像を整理しておきます。

この3つの名前は、実は2つの異なる軸で登場します。

shadcn/ui というUIライブラリの話:内部の振る舞い(ヘッドレスUI)を担う基盤として、Radix UI か Base UI のどちらかを選べる
MUI という運営組織の話:MUI という会社が、Material UI と Base UI という2つの別プロダクトを開発している

図にすると、次のような関係です。

shadcn/ui(UIライブラリとしての話)
└ Radix UI
└ Base UI

MUI社(組織としての話)
└ Material UI
└ Base UI

つまり「Base UI」は、shadcn/ui から見れば「Radix UI の代わりに選べる基盤」であり、MUI 社から見れば「Material UI とは別に手掛けているもう一つの製品」です。同じ Base UI という名前でも、どちらの軸で見ているかによって意味合いが変わってきます。この2つの軸を混同しないことが、以降を理解するポイントになります。

ここからは、まず shadcn/ui の軸に沿って Radix UI と Base UI を順番に説明したうえで、MUI 社の軸(Material UI とのつながり)を補足として見ていきます。

Radix UI

shadcn/ui は2023年1月の登場時から Radix UI を土台にしてきました。当時、アクセシビリティの作り込みとAPIの使いやすさを両立したヘッドレスUIライブラリとして、Radix UI に匹敵するものは他になかったと shadcn 自身が公式チェンジログで振り返っています。実際、Radix UI は数百万規模のアプリケーションで実戦投入されてきた実績があります。

New projects now use Base UI by default. Radix is still fully supported.
—— shadcn/ui Changelog, "July 2026 - Base UI as the Default"

Base UI

そして数年後、Radix UI を作った当人たちが、ゼロから新しく作り直したライブラリが Base UI です。Base UI 公式サイトのトップには「From the creators of Radix, Floating UI, and Material UI」(Radix・Floating UI・Material UI の作者たちによる)と明記されており、開発チームには Colm Tuite(Design Engineering責任者)、Marija Najdova(Engineering責任者)をはじめ、複数のプロダクトを渡り歩いてきたメンバーが名を連ねています。

つまり「Radix UI の後継として、同じ人たちが過去の反省を踏まえて再挑戦したもの」が Base UI、という位置づけです。

補足:Material UI(MUI)とのつながり

Base UI の開発は MUI が主体となって進めています。MUI はフランス・パリを拠点とする企業で、もともとは Material Design を実装した「Material UI」の開発元として知られていますが、現在は社名を「MUI」に改め、複数のUI関連プロダクトを展開する組織になっています。GitHub 上のリポジトリは mui/base-ui として公開されており、MUI という組織の管理下にあります。

Base UI には前身にあたるプロジェクトがあります。2022年、MUI は Material UI からコンポーネントを抽出する形で「MUI Base」というヘッドレス版のライブラリを発表しました。当時のAPIは Material UI 由来の slots / slotProps という仕組みを踏襲したものでしたが、2023年にかけて「Base UI」へと改名・再構築される過程で、この設計は Radix UI 由来のものに置き換えられています(次の節で詳しく扱います)。パッケージ名も @mui/base → @base-ui-components/react → @base-ui/react と変遷しました。この再構築には、Radix UI の主要メンバーの一人である Vlad Moroz 氏も加わっています。

Base UI の API は Radix UI にあえて似せてある

Base UI 公式サイトのFAQには、見落とされがちですが重要な一文があります。「API設計としては両者(Base UIとRadix UI)は非常に似ている。移行をしやすくするために、意図的に Radix UI に近いAPIを保っている」という趣旨の説明です。つまり Base UI が似せている対象は、Radix UI です。

Base UI は Radix UI を置き換える目的で作られたライブラリですが、乗り換えのハードルをできる限り下げるという設計判断が、当初から意図的になされているわけです。この前提が、後述する shadcn/ui 側の移行しやすさにもつながってきます。

コードで見る「似ている」の中身

では、実際にどれくらい似ているのか、Dialog(モーダル)コンポーネントを例に比べてみます。まず Radix UI です。

// Radix UI
import * as Dialog from "@radix-ui/react-dialog"

function Example() {
  return (
    <Dialog.Root>
      <Dialog.Trigger asChild>
        <button>開く</button>
      </Dialog.Trigger>
      <Dialog.Portal>
        <Dialog.Overlay />
        <Dialog.Content>
          <Dialog.Title>タイトル</Dialog.Title>
          <Dialog.Close asChild>
            <button>閉じる</button>
          </Dialog.Close>
        </Dialog.Content>
      </Dialog.Portal>
    </Dialog.Root>
  )
}

次に、同じものを Base UI で書くとこうなります。

// Base UI
import { Dialog } from "@base-ui/react/dialog"

function Example() {
  return (
    <Dialog.Root>
      <Dialog.Trigger render={<button>開く</button>} />
      <Dialog.Portal>
        <Dialog.Backdrop />
        <Dialog.Popup>
          <Dialog.Title>タイトル</Dialog.Title>
          <Dialog.Close render={<button>閉じる</button>} />
        </Dialog.Popup>
      </Dialog.Portal>
    </Dialog.Root>
  )
}

見比べると分かるように、Root → Trigger → Portal → 中身、という全体の構造や粒度はほぼ同じです。「APIが似ている」という公式の説明は、この構造レベルの話を指しています。

一方で、細部の名前は微妙に変わっています。

カスタム要素への差し替え方法:Radix UI の asChild(子要素に暗黙的にpropsをマージする)→ Base UI の render(明示的にpropsを渡す)
背景の要素名:Radix UI の Overlay → Base UI の Backdrop
中身を包む要素名:Radix UI の Content → Base UI の Popup

つまり「構造は同じだが、末端の命名やprops の渡し方が変わっている」というのが実態です。この粒度の違いこそ、公式チェンジログが「asChild は render に機械的に変換できる」と説明している理由でもあります(この点は移行の章で詳しく扱います)。

なお、前の節で触れた通り、Base UI は元々 Material UI 寄りの設計として生まれましたが、Radix UI 由来の設計に作り直された経緯があります。そのため「MUIが作っているから Material UI にも似ているだろう」と考えるのは早合点で、現在の Base UI のAPIが実際に似ているのは Radix UI である、という点を押さえておくと理解がスムーズです。

ここまでで、「shadcn/ui はコードをコピーして使う仕組みであること」「その裏側の振る舞いを Radix UI か Base UI のどちらかが担っていること」「Base UI は Radix UI の作者自身が作った後継であること」という前提が揃いました。

ここからは、2026年7月に公式チェンジログで実際に何が発表されたのかを見ていきます。

2026年7月、何が発表されたのか

結論から言うと、変わったのは新規プロジェクトを作成したときの初期設定です。これまで shadcn/ui は Radix UI を土台にする設定がデフォルトでしたが、これ以降は Base UI が標準の選択肢になりました。

とはいえ、この発表は単なる設定変更の告知ではありません。チェンジログの本文は、shadcn/ui 作者自身の振り返りからかなりの分量を割いて始まっています。2025年に Base UI がベータ版としてタグ付けされた際、「Radix UI を Base UI に置き換えるのか」という質問が多く寄せられたそうですが、そのとき作者は「本番運用中のアプリにとって一番やってはいけないのは、コンポーネントライブラリを乗り換えることだ」と答えていたと明かしています。実際、その考えは今も変わっていません。だからこそ、Radix UI を置き換えるのではなく、Base UI 版のコンポーネントを一から作り直し、同じ抽象化(shadcn/ui としての使い勝手)を保ったまま、どちらを使うか選べる形にする、という選択を取ったと説明されています。

この経緯自体は2025年12月の npx shadcn create 導入、2026年1月の Base UI ドキュメント整備という形ですでに進んでいたものですが、今回はそれを「デフォルト」に格上げした、という発表です。

具体的に何が変わったのか

チェンジログが挙げている変更点は、次の3つです。

新規プロジェクトが Base UI をデフォルトにする:npx shadcn init を実行すると、Base UI が最初の選択肢として選ばれるようになりました。
shadcn/create の表示順が変わる:プロジェクト作成ツール上でも、Base UI が先に表示されます。
ドキュメントの既定タブが変わる:各コンポーネントのドキュメントページは、Base UI 側のタブが最初に開くようになりました。Radix UI 版のドキュメントは、ワンクリックで切り替えられる場所に残っています。

なぜこのタイミングだったのか

チェンジログでは、この判断の理由として4点が挙げられています。

Base UI が安定版になっていること:バージョン1.6.0に達し、週間600万ダウンロードを超える規模になっています。
開発が活発であること:新しいコンポーネントが継続的に追加されています。
shadcn/ui のチーム自身が採用していること:新しく始めるプロジェクトは、すべて Base UI 上で動いているとのことです。
ユーザー側の選択がすでに Base UI に傾いていたこと:shadcn/create で作られたプロジェクトが、正式発表前の時点で Radix UI の2倍の比率で Base UI を選んでいたというデータが紹介されています。

つまり今回の発表は、「公式が主導して切り替えを促した」というより、「すでにユーザーが選び始めていたものを、正式な既定値として追認した」という位置づけに近いです。なお背景として、Radix UI は開発元が Modulz から WorkOS に移って運用が続いている一方、Base UI は 7名体制の専任チームがフルタイムで開発しているという体制の違いがあります。

既存プロジェクトへの影響

ここが実務上、最も気になる部分だと思います。結論としては、既存プロジェクトに対しては、何も変わりません。

チェンジログは、この点をかなり明確に述べています。Radix UI が非推奨になるわけではなく、コンポーネントの更新や新機能は、今後も(Base UI にしか存在しないものを除いて)両方のライブラリ向けに提供され続けるとしています。また、Radix UI は十分に成熟し実績のあるライブラリであり、shadcn/ui のチーム自身も本番環境で使い続けているとして、「今動いているなら、そのまま使い続けて構わない」という趣旨のメッセージが添えられています。

つまり、すでに Radix UI ベースで動いているプロジェクトが、このアップデートによって何かを強制されることはありません。影響が及ぶのは、あくまで「これから新しく npx shadcn init を実行する場合」に限られます。

移行(マイグレーション)の実際

「移行は不要」というのが公式スタンスですが、それでも移行したい場合に向けて、shadcn/ui は具体的な仕組みを用意しています。ここではその中身を見ていきます。

コード変換ではなく「skill」を提供する

多くのライブラリ移行ツールは、コードを機械的に書き換える「codemod」という手法を使います。しかし今回 shadcn/ui が採用したのは、それとは異なるアプローチです。公式チェンジログによれば、次のコマンドで「skill」と呼ばれる知識セットをプロジェクトに追加し、コーディングエージェント(Claude Code や Cursor など)に読み込ませる形を取ります。

pnpm dlx skills add shadcn/ui

そのうえで、エージェントに次のように指示します。

migrate accordion to base-ui

codemod ではなく skill を選んだ理由について、チェンジログは「ユーザーが元のコードに独自の変更(variants の追加、class の変更、props の追加など)を加えている以上、codemod では手を加えていない部分まで書き換えてしまい、手を加えた部分ではかえって壊れてしまう」という趣旨の説明をしています。そこで、asChild を render に変換するといった機械的な部分と、挙動が変わる可能性がある部分をあらかじめ整理した「知識」をエージェントに渡し、エージェント自身にユーザーのカスタマイズを踏まえた判断をさせる、というアプローチを取っています。

段階的に進められる

この移行は、コンポーネント単位で少しずつ進められるように設計されています。一度に全部を移行する必要はなく、1つのコンポーネントを移行してプロジェクトが問題なく動く状態を保ったまま、途中で作業を止めて別の日に続きから再開する、といった進め方ができます。移行の途中は、Radix UI ベースのコンポーネントと Base UI ベースのコンポーネントが同じプロジェクト内に共存する形になります。

移行1回ごとに残るもの

チェンジログによれば、移行を実行すると次の3つが手元に残ります。

動作するコード:型チェックとビルドを通過した状態でのみ、成功として報告されます。
コンポーネントごとのレポート:プロジェクトルートの .migration/ 以下に、何を変更し、何をあえて変更しなかったか、手動で確認すべき項目のチェックリストが記録されます。
クリーンな Git 履歴:コンポーネントごとに1つのコミットとしてブランチ上に記録されるため、気に入らなければブランチを削除するだけで元に戻せます。

機械的に置き換えられる部分(asChild から render への変換など)はすべての箇所で修正される一方、挙動が変わる可能性のある部分は自動で書き換えず、レポート上で「要確認」として明示される、という設計になっています。

実測値

チェンジログでは、実際のプロジェクトでこの移行を試した結果も紹介されています。60個以上のコンポーネント(うち36個が Radix UI ベース)を含むプロジェクトで、移行全体がおよそ25分、コンポーネント1つあたり約1万トークンで完了したとのことです。ビルドは問題なく通り、独自にカスタマイズしていた部分もそのまま保持されていた、としています。

Radix UI を使い続ける場合の選択肢

これから新しくプロジェクトを始める場合でも、Radix UI を選ぶことは引き続き可能です。公式チェンジログが案内している具体的な方法を紹介します。

CLIでの明示的な指定

npx shadcn init を実行する際に、-b radix というオプションを付けると、Radix UI を基盤として初期化できます。

pnpm dlx shadcn init -b radix

チェンジログでは、CI環境や非対話的なスクリプトで shadcn init を実行していて、これまで通り Radix UI を使い続けたい場合は、このオプションを付けて明示しておくよう案内されています。今回のデフォルト変更に気づかないまま自動化スクリプトを動かしていると、意図せず Base UI 側で初期化されてしまう可能性があるため、既存の CI 構成を持つプロジェクトでは確認しておくとよさそうです。

レジストリを運営している場合

自分たちで shadcn/ui のレジストリ(コンポーネント配布の仕組み)を運営している場合は、registry:base という設定を明示することで、特定のライブラリに固定できます。この設定がない項目は、今後 Base UI として初期化されるとのことです。

これから新規プロジェクトを始めるなら

最後に、新規プロジェクトでどちらを選ぶかの判断材料を整理します。どちらが優れているという話ではなく、状況に応じた選び方の参考にしてください。

公式の推奨:shadcn/ui は現時点で Base UI を推奨しており、チーム自身が手掛ける新規プロジェクトもすべて Base UI 上で動いているとしています。特にこだわりがなければ、デフォルトのまま進めるのが最も情報量の多い選択になります。
チームの習熟度:すでに Radix UI の asChild パターンに慣れているチームであれば、学習コストという観点では Radix UI を選ぶ理由になります。
必要なコンポーネント:Combobox や Autocomplete のように、Base UI 側にしか用意されていないコンポーネントを使う予定がある場合は、Base UI を選ぶ動機になります。
後から変更できるか:今回紹介した skill による移行の仕組みにより、後から Base UI に切り替えることも技術的には可能です。つまり「今回の選択が後戻りできない」というわけではなく、判断を保留してひとまず動かし始める、という選び方もできます。

いずれの基盤を選んでも、shadcn/ui としての使い勝手(コンポーネントの見た目やAPIの大枠)はほぼ変わりません。土台の選択に時間をかけすぎず、まずは手を動かしてみるのが良さそうです。

まとめ

2026年7月、shadcn/ui は新規プロジェクトのデフォルトを Radix UI から Base UI に切り替えました。この記事で見てきたポイントを振り返ります。

shadcn/ui は「コードをコピーして使う」仕組みであり、その裏側の振る舞いを Radix UI か Base UI のどちらかが担っている
Base UI は Radix UI の設計思想を引き継いで作られたライブラリで、APIも意図的に近づけられている
MUI という会社が Base UI の開発を主体的に進めているが、これは Material UI とは別の話であり、現在の Base UI のAPIは Material UI よりも Radix UI に近い
今回の変更は既存プロジェクトに影響しない。Radix UI は非推奨にならず、両方のライブラリが今後も並行してサポートされる
移行したい場合は、codemod ではなく「skill」という仕組みを使い、コンポーネント単位で段階的に進められる
新規プロジェクトでどちらを選ぶかは、公式の推奨・チームの習熟度・必要なコンポーネントなどを踏まえて判断すればよく、後から移行することも技術的には可能

いずれにしても、既存のプロジェクトが何かを強制されるわけではありません。手元のプロジェクトが問題なく動いているなら、慌てて手を加える必要はなさそうです。

本記事の内容は、shadcn/ui公式チェンジログ、Base UI公式サイト、MUI公式ブログなど、本文中にリンクした一次情報をもとに執筆しています。

なお、本記事は筆者がAI(Claude)を活用して執筆しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up