Material UIとは：v9系の導入からGrid・テーマ設定までコード付きで解説

Material UI は、Google の Material Design を React コンポーネントとして実装したライブラリです。ボタンやフォーム、テーブルといった画面部品が揃っており、CSS をほとんど書かずに一貫した見た目の管理画面を組み立てられます。ただし日本語の解説記事の多くは v5 系の書き方で止まっており、そのまま写すと現行版では動かない箇所があるため、版の違いに注意が必要です。この記事では 2026 年 9 月時点の公式ドキュメントを実測しながら、導入コマンド、Next.js への組み込み、Grid とテーマの書き方、旧版からの移行で壊れる箇所までを順に扱います。

まとめ｜Material UIをv9系で導入する判断と見送る条件の結論

先に結論を並べます。管理画面・社内業務システム・SaaS の設定画面のように、画面数が多く意匠より一貫性が要る対象であれば、Material UI は採用してよい選択肢です。導入は npm install @mui/material @emotion/react @emotion/styled の 1 行で済み、2026 年 9 月時点の最新は v9.4 系、React 17・18・19 のいずれでも動きます。

一方、ブランド固有の意匠を細部まで作り込むコーポレートサイトや LP では見送ります。Material Design の骨格を外す作業量が、素の CSS を書く量を上回るためです。またスタイリング基盤についても判断が要ります。公式が次世代として発表した Pigment CSS は alpha のまま停止しており、当面は Emotion 前提で設計を確定させるのが現実的な選択です。詳細は後半の 2 章で扱います。

Material UIとMaterial Designの関係とv9系までの版の流れ

まず名前の整理から入ります。混同が多いのは、似た名前が 4 つ並んでいるためです。

Material UI の配布パッケージ名は @mui/material です。仕様側の本体は Material Design 3 の公式サイトにあり、色の生成規則やコンポーネントの状態が定義されています。実装側の本体は GitHub の mui/material-ui で、リポジトリの説明文は「Google の Material Design を実装した包括的な React コンポーネントライブラリ。永久に無料」と書かれています。仕様そのものの中身、とりわけ Material 3 Expressive で加わった表現については、Material Design 3 の解説記事で扱っています。

Flutterのmaterial_uiとReact版の開発元・配布経路の違い

検索で「material_ui」とアンダースコア付きで出てくる場合、Flutter 側のパッケージを指していることがあります。こちらは Dart のパッケージで、React 用の @mui/material とは別系統です。Flutter では Material 系ウィジェットを本体から切り出す動きが進んでおり、その経緯は Flutter 3.47 の移行判断をまとめた記事に整理してあります。React の話をしているのか Flutter の話をしているのか、チーム内で先に揃えておくと事故が減ります。

v5からv9までのスタイリング基盤とGrid・旧APIの変更点

版の流れも押さえておきます。v5 でスタイリングエンジンが Emotion へ切り替わり、v6・v7 を経て、現行の v9 系では Grid の書き方と旧 API の削除が入りました。日本語記事の多くは v5 の時期に書かれているため、Grid まわりのコードだけは必ず現行ドキュメントと突き合わせてください。ここが最も差分の大きい箇所になります。

npmでMaterial UI v9系を入れてButtonを画面へ出すまでの手順

導入手順は短いものです。公式のインストールガイドが示すコマンドをそのまま実行します。

# Material UI 本体とスタイリングエンジン（Emotion）
npm install @mui/material @emotion/react @emotion/styled

peer dependencies は react と react-dom がいずれも ^17.0.0 || ^18.0.0 || ^19.0.0 です。React 16 系のプロジェクトはこの時点で対象外になるため、先に React 側を上げる計画を立てます。インストール後、最小のボタンを 1 つ描画してみます。

import Button from '@mui/material/Button';

export default function App() {
  return (
    <Button variant="contained" size="large" onClick={() => console.log('送信')}>
      申請を送信
    </Button>
  );
}

variant に contained（塗り）、outlined（枠線）、text（文字のみ）を渡すと見た目が切り替わります。import 文を import { Button } from '@mui/material' と書くこともできますが、パスを直接指定する上の書き方のほうがビルド時に読み込む範囲が狭くなります。画面数の多いアプリでは、この読み込み範囲の差が初回表示の速さに影響する要因です。

styled-componentsを選ぶ場合のSSR互換性の制約

Emotion ではなく styled-components を使う構成も用意されており、@mui/styled-engine-sc を挟むと切り替わります。ただし公式ガイドには、styled-components はサーバーレンダリング構成の Material UI とは互換性がないと明記されています。Next.js や Remix のように SSR を前提とするなら、この選択肢は外して Emotion のまま進めるのが安全です。

Next.js App Routerへ組み込むlayout.tsxの実装とキャッシュ設定

Next.js の App Router に載せる場合は、素のインストールだけでは足りません。公式の Next.js 統合ガイドに従って、専用パッケージを 2 つ足します。

npm install @mui/material-nextjs @emotion/cache

そのうえで、ルートの layout.tsx で children を AppRouterCacheProvider で包みます。

// app/layout.tsx
import { AppRouterCacheProvider } from '@mui/material-nextjs/v15-appRouter';

export default function RootLayout(props) {
  return (
    <html lang="ja">
      <body>
        <AppRouterCacheProvider>
          {props.children}
        </AppRouterCacheProvider>
      </body>
    </html>
  );
}

import パスの v15-appRouter は Next.js のメジャー版に対応しており、別の版を使う場合は v1X-appRouter の形で読み替えます。この Provider が何をしているかというと、サーバー側で生成された CSS を集めて、Next.js がページをストリーミング配信する際に head へ差し込む処理です。これを置き忘れると、本文が先に表示されてスタイルが後から当たる、いわゆる無装飾の一瞬が発生します。原因が分かりにくい症状なので、App Router を採用した時点で最初に入れておくものと考えてください。

use clientの付け方と状態を持つ画面部品の切り出し範囲

もう一点、App Router 特有の詰まりどころがあります。Material UI のコンポーネントの多くは内部で状態やイベントを扱うため、クライアントコンポーネントとして扱うことが必要です。ページ全体に 'use client' を置くとサーバーコンポーネントの利点が消えるので、対話が要る部分だけを小さな子コンポーネントへ切り出し、そこにだけ宣言を付ける形にします。テーブルの行選択やダイアログのように状態を持つ箇所と、静的な見出しやテキストを分けて設計する、という粒度の話になります。

Gridのsizeプロップで12カラムのレスポンシブ配置を組む手順

v9 系で書き方が最も変わったのが Grid です。公式の Grid ドキュメントと移行ガイドによれば、旧実装の GridLegacy は廃止され、Grid へ統一されました。変更点は 3 つあります。item プロップが不要になったこと、xs や sm といったブレークポイント指定が size プロップへ移ったこと、そして direction="column" が削除されたことです。

import Grid from '@mui/material/Grid';
import Paper from '@mui/material/Paper';

// 旧: <Grid item xs={12} sm={6} md={4}>
// 新: size に集約する
export default function Dashboard() {
  return (
    <Grid container spacing={2}>
      <Grid size={{ xs: 12, sm: 6, md: 4 }}>
        <Paper sx={{ p: 2 }}>今月の申請件数</Paper>
      </Grid>
      <Grid size={{ xs: 12, sm: 6, md: 4 }}>
        <Paper sx={{ p: 2 }}>未処理の差戻し</Paper>
      </Grid>
      <Grid size={{ xs: 12, md: 4 }}>
        <Paper sx={{ p: 2 }}>承認待ち</Paper>
      </Grid>
    </Grid>
  );
}

縦積みのレイアウトが要る場面では、Grid の direction ではなく Stack を使います。移行ガイドもその方針を示しており、縦並びは Stack、格子は Grid という住み分けになりました。既存コードに direction="column" が残っていると、v9 へ上げた時点で意図した並びになりません。検索して洗い出す対象のひとつです。

createThemeとThemeProviderで配色とタイポグラフィを一元管理する

色やフォントを個別のコンポーネントで指定していくと、画面が増えたときに揺れます。公式のテーマ機能を使って、プロジェクト全体の既定値を 1 か所に集めます。

// theme.ts
import { createTheme } from '@mui/material/styles';

export const theme = createTheme({
  palette: {
    primary:   { main: '#1a3a6b' },   // コーポレートカラー
    secondary: { main: '#c25a1f' },
  },
  typography: {
    fontFamily: '"Noto Sans JP", "Helvetica Neue", sans-serif',
    button: { textTransform: 'none' },  // 日本語UIでは大文字変換を切る
  },
  components: {
    MuiButton: {
      defaultProps: { disableElevation: true },
      styleOverrides: { root: { borderRadius: 8 } },
    },
  },
});

作ったテーマは ThemeProvider でアプリ全体を包んで適用します。components の下に置く defaultProps と styleOverrides は使い分けが要ります。前者は「毎回書いている props を既定値に格上げする」もの、後者は「CSS を上書きする」ものです。個々の画面で同じ props を繰り返し書いていると気付いたら、defaultProps へ引き上げる合図になります。

なお v9 では、mt や color といったシステムプロップが削除され、sx プロップへ集約されました。<Box mt={2}> のような書き方は <Box sx={{ mt: 2 }}> へ書き換えます。ルーティングと組み合わせたテーマの一元管理については、MUI の Link と React Router を連携させる手順で具体例を扱っています。

v7からv9へ移行するときに壊れる箇所とcodemodの実行手順

既存プロジェクトを上げる場合、公式の v9 アップグレードガイドが列挙する破壊的変更を先に把握します。影響範囲の広いものを整理すると次のとおりです。

表中の Grid の変更は、GridLegacy の廃止、item の指定不要化、xs 等から size への移行です。旧 API は components/componentsProps から slots/slotProps へ統一されます。Slider では onMouseDown を onPointerDown へ変更してください。対応ブラウザの最低バージョンは Chrome 117・Firefox 121・Safari 17.0 で、それぞれ以上のバージョンが対象です。

機械的に置換できる部分は codemod が用意されています。実行形式は次のとおりで、対象ディレクトリを指定して個別に走らせます。

# 非推奨APIの書き換え（対象を絞って1つずつ実行する）
npx @mui/codemod@latest deprecations/accordion-props ./src
npx @mui/codemod@latest deprecations/alert-props ./src
npx @mui/codemod@latest deprecations/button-classes ./src

# 差分を確認してからコミットする
git diff --stat

実務では、codemod を全部一度に流してからまとめて確認するやり方は勧めません。1 つ走らせるたびに git diff を見て、意図しない置換が無いか確かめる進め方のほうが結局早く終わります。とくに Grid は size プロップへの集約で構造が変わるため、自動変換の結果をそのまま信用せず、実際の画面で崩れを目視する工程を挟んでください。ブラウザ要件の引き上げも見落としがちな点です。社内システムで古い環境を残している場合、v9 へ上げた時点で動作保証の範囲が変わります。

Pigment CSSの停止とBase UIへの重心移動から読む採用リスク

採用判断に直結する話を 1 つ挙げます。数年前から MUI は、実行時コストのない CSS-in-JS として Pigment CSS を打ち出してきました。日本語記事にも「次世代のスタイリング基盤」として紹介したものが残っています。しかし 2026 年 1 月 1 日付の公式ブログには「Pigment CSS remains in alpha phase and is currently on hold.」と書かれており、alpha のまま止まっている状態が明言されました。

同じ記事にはもう 2 つの表明があります。「MUI Base has been deprecated and replaced by Base UI」として旧 MUI Base の非推奨化が示され、「Base UI is where we are concentrating our foundational work going forward.」として基盤側の開発資源が Base UI に集まっていることが述べられています。次のメジャー版については feature set を策定中という段階の記述に留まっていました。

これから設計する際のEmotion継続とBase UI選択の判断軸

読み解きは単純です。第一に、Pigment CSS への移行を待って設計を保留する理由は無くなりました。Emotion 前提でテーマとコンポーネント構成を確定させ、将来の乗り換えは「起きたら考える」枠に置きます。第二に、意匠を自前で全部作りたい要件であれば、Material UI ではなく Base UI を土台に選ぶ道が公式の方向に沿った選択です。両者の違いと選び分けは Base UI の解説記事で確認できる内容です。第三に、Material UI 本体が止まったわけではない点も押さえておきます。停止したのはスタイリング基盤の実験であって、コンポーネント本体は v9 系として更新が続いています。

受託開発でMaterial UIを選ぶ条件と別のライブラリへ振る場面

ここまでの内容を、採用可否の判断に落とします。まず採用する条件です。画面数が 20 を超える管理画面や業務システムで、専任のデザイナーが付かない案件。表・フォーム・ダイアログが繰り返し出てくる構成。アクセシビリティの基礎を自前で実装したくない場合。この 3 つのどれかに当たるなら、Material UI を選んで問題ありません。部品の網羅性が高く、実装者ごとの見た目の揺れを構造的に抑えられます。

逆に見送る場面も明確です。ブランドの意匠を 1px 単位で作り込むコーポレートサイトや LP では、Material Design の骨格を外す作業のほうが重くなります。すでに Tailwind CSS で運用しているコードベースへ後から足す場合も、スタイルの優先順位の調整が積み上がるため見送り寄りに倒します。表示速度の要件が厳しい公開サイトでも、実行時 CSS-in-JS のコストを踏まえて別の選択肢を検討してください。

Material UIの無料範囲と有償部品・代替ライブラリの選定基準

費用の話も先に済ませます。Material UI 本体（@mui/material）は無料で、商用利用にも制限はありません。有償になるのは MUI X の一部で、公式の価格ページでは 2026 年 9 月 10 日時点で Pro が開発者 1 人あたり年額 299 ドル、Premium が同 599 ドルと表示されています。DataGrid の高度な機能や日付範囲の選択が要る場合に発生する費用なので、要件定義の段階で「どの部品が有償側か」を洗い出しておくと、後から予算の話にならずに済みます。

代替を検討するなら、方向性ごとに候補が分かれます。中国発で管理画面向けの部品が厚いAnt Design、日本語圏での扱いやすさを重視したYamada UI、見た目を持たない土台から組む Base UI、といった並びです。どれを選ぶかは、意匠の自由度をどこまで求めるかで決まります。業務用・Webアプリ開発では、こうしたライブラリの選定から画面設計、既存システムとの連携までを一括で引き受けています。版の移行で止まっている案件の引き継ぎも扱っていますので、判断に迷う段階でご相談ください。

よくある質問

Material UI の導入時に問い合わせの多い論点を 5 つ挙げます。

Material UIとMUIとMaterial Designは何が違うのですか？

Material Design は Google が定めたデザインの仕様で、Material UI はその仕様を React 実装したライブラリです。MUI は開発元の組織名であり、npm パッケージのスコープ名（@mui/）でもあります。したがって「MUI を入れる」と言った場合、文脈によって @mui/material のことを指す場合と、MUI X まで含む場合があります。見積もりや要件の会話では、パッケージ名まで具体に落として確認してください。

v9へ上げるとGridのコードは全部書き直しになりますか？

全部ではありませんが、Grid を使っている箇所はほぼ触ることになります。item の削除と xs などから size への集約は機械的な変換で片付く一方、direction="column" を使っていた箇所は Stack への置き換えという設計判断が入ります。既存コードで direction と GridLegacy を検索し、その件数から工数を見積もるのが実務的な進め方です。

Material UIは無料で商用利用できますか？

@mui/material 本体は無料で、商用のプロダクトにも使えます。GitHub のリポジトリ説明にも「Free forever」という記載があり、無料で使えることを示す表現です。費用が発生するのは MUI X の Pro 以上に含まれる部品を使う場合で、公式の価格ページでは開発者 1 人あたりの年額として提示されています。無料の DataGrid でも基本的な表示と並べ替えはできるため、まず無料の範囲で試してから判断できます。

Tailwind CSSと併用しても問題ありませんか？

技術的には併用できますが、勧められる構成ではありません。Material UI は Emotion が実行時にスタイルを注入する方式で、Tailwind はビルド時にクラスを生成する方式です。両者が同じ要素に当たると、優先順位の調整のために !important や sx での上書きが増え、どちらの記法で書くかがファイルごとに揺れます。既存が Tailwind なら Base UI 系の土台コンポーネントを、既存が Material UI ならそのまま sx で通すほうが保守は楽になります。

Flutterのmaterial_uiパッケージとは関係がありますか？

直接の関係はありません。どちらも Google の Material Design を実装対象にしている点は共通ですが、React 向けの @mui/material と Flutter の Dart パッケージは開発元も配布経路も別です。検索結果が混ざりやすいので、調べるときは「mui react」「flutter material」のように実行環境を語に足すと絞り込めます。

関連記事

• MUIのLinkとReact Routerで画面遷移を実装する方法｜component指定とテーマ一元化（v9／v8対応）：ルーティング連携とテーマ側での一元化はこちらです
• Base UI（React）とは？特徴・Radix UI／MUIとの違い・使い方をわかりやすく解説：意匠を自前で作る場合の土台ライブラリを扱っています
• Material Design 3（Material 3）とは？Expressiveの新機能と使い方を解説：実装ではなく仕様側の中身を知りたいときの入口です
• Flutter 3.47とは？material_ui分離とIntel Mac終息で決まる移行判断【2026年8月時点】：Flutter側のmaterial_ui分離の経緯を整理しています