こんにちは。サービス開発課の今門です。
自社のWebアプリケーション開発において、「AIを活用してより効率的な開発手法を確立したい」と考えている方が多いのではないでしょうか。というより、ほとんどの方がそのように考え、AIを使った開発手法へのシフトを検討したり、実際に導入し始めていると思います。
シナプスでも、AIを使った開発手法にシフトしており、Vibe Coding でLPを作成したり、前回ご紹介したとおりFigmaのMCPサーバーを利用したりと試行錯誤を繰り返しています。今回はその取り組みの一環として、React + TailwindCSS v4 + shadcn/ui の構成に 「shadcn/ui MCP」 を組み合わせた環境を構築し、どのような挙動をするか試してみました。
MCP導入前後の開発フローを比較しながら、この構成の可能性について考えたいと思います。
- React + TailwindCSS v4 + shadcn/ui + shadcn/ui MCPの導入
- React + TailwindCSS v4 + shadcn/uiを選択する理由
- 従来の開発フローとその課題
- shadcn/ui MCPを導入した開発フロー
- まとめ
- 今後について
- 参考リンク
React + TailwindCSS v4 + shadcn/ui + shadcn/ui MCPの導入
まずは導入の手順を説明します。
構築した環境
Node.js : 24.x LTS #shadcn/uiは、バージョン22以上を要求 パッケージマネージャ : pnpm フレームワーク : Vite + React + TypeScript スタイリング : TailwindCSS v4 UIコンポーネント : shadcn/ui MCP : shadcn/ui MCP(.vscode/mcp.json)
注意点として、最新のshadcn/uiは、Node.jsのバージョン22以上を要求します。事前にアップデートしておいてください。
また、TailwindCSSは、v4とそれ以前とで設定方法が大きく異なっています(後述)。今回は、v4を採用しました。
インストール・設定手順
手順1:Vite プロジェクト作成
pnpm create vite shadcn-lab --template react-ts cd shadcn-lab pnpm install
pnpm create vite shadcn-lab --template react-tsを実行します。オプションのreact-tsで、React/TypeScriptを選択しています。
手順2:TailwindCSS v4 インストール
pnpm add tailwindcss @tailwindcss/vite
vite.config.ts にプラグインを追加します。
import tailwindcss from '@tailwindcss/vite' import { defineConfig } from 'vite' import react from '@vitejs/plugin-react' import path from 'path' export default defineConfig({ plugins: [react(), tailwindcss()], resolve: { alias: { '@': path.resolve(__dirname, './src'), }, }, })
手順3:パスエイリアスの設定
shadcn/ui のCLIはパスエイリアス(@/)を必要とします。tsconfig.json とtsconfig.app.json に追記します。
{ "compilerOptions": { "baseUrl": ".", "paths": { "@/*": ["./src/*"] } } }
手順4:shadcn/ui 初期化
pnpm dlx shadcn@latest init -d
-d フラグでデフォルト設定を使います。初期化後、src/components/ui/button.tsx と src/lib/utils.ts が生成されます。
手順5:shadcn/ui MCP の設定
.vscode/mcp.json を作成します。
{ "servers": { "shadcn": { "type": "stdio", "command": "npx", "args": ["-y", "shadcn@latest", "mcp"] } } }
このファイルをプロジェクトルートの .vscode/ に置くことで、VS Code がこのプロジェクトを開いたときに自動的に MCP サーバーが起動します。
ファイル構成
最終的に次のようなファイル構成になりました。

React + TailwindCSS v4 + shadcn/uiを選択する理由
必要な環境構築が終わったところで、実際のソースコードや設定ファイルなどを見ながら、ベースとなる技術スタックReact + TailwindCSS v4 + shadcn/uiを選択する理由について説明します。
React とTailwindCSS v4 について
React はみなさんもご存知のとおり、JSフレームワークの標準であり、エコシステムの充実度・採用実績ともに申し分ありません。すなわち、ReactについてはLLMが事前に大量に学習しており、AIエージェントに質問した際に信頼のおける情報を返してくれる可能性が高いです。実際、プログラミング系のAIサービスではReactをベースにしていることが非常に多く、AIエージェントとの相性が抜群であることも、みなさんすでにご存知かと思います。
TailwindCSSは、ご存知のとおり、あらかじめ用意された小さなクラスを組み合わせてスタイルを当てるCSSフレームワークです。「ユーティリティファースト」と呼ばれる設計思想で構築されています。 「クラス名を考えなくてよい」「CSSファイルを別途管理しなくてよい」という点が、コンポーネントベースのReact開発と非常に相性がよいです。
v4 での変化
TailwindCSS v4 では設定方法が大きく変わりました。従来の tailwind.config.ts ファイルは使わず、CSSファイルの @theme ブロックに設定を直接記述する CSS-first 設定になっています。
私の環境では、src/index.cssに、次のとおり設定されています。
/* src/index.css */ @import "tailwindcss"; @import "tw-animate-css"; @import "shadcn/tailwind.css"; @import "@fontsource-variable/geist"; @custom-variant dark (&:is(.dark *)); @theme inline { --font-heading: var(--font-sans); --font-sans: 'Geist Variable', sans-serif; --color-sidebar-ring: var(--sidebar-ring); /* 以下、省略 */ } :root { --background: oklch(1 0 0); --foreground: oklch(0.145 0 0); --card: oklch(1 0 0); /* 以下、省略 */ } .dark { --background: oklch(0.145 0 0); --foreground: oklch(0.985 0 0); --card: oklch(0.205 0 0); /* 以下、省略 */ } @layer base { * { @apply border-border outline-ring/50; } body { @apply bg-background text-foreground; } html { @apply font-sans; } }
shadcn/ui について
shadcn/uiは、React用UIコンポーネント集です。
アクセシビリティや複雑なインタラクションを担当するヘッドレスUIライブラリ(Base UI または Radix UI)を TailwindCSS でスタイリングしたものが shadcn/ui のコンポーネントになります。当初はRadix UIをベースにしていましたが、MUI (GoogleのMaterial Designに基づいたReact用UIコンポーネントライブラリ)で使われているBase UIへの移行作業が進んでいます。
Base UI / Radix UI(機能・アクセシビリティ)
+
TailwindCSS(見た目)
─────────────────────────────
= shadcn/ui コンポーネント
例えば、MUI などReactでよく使われる多くのコンポーネント集がnode_modulesにインストールして使われるのに対し、shadcn/ui は、CLIでコンポーネントを「追加」するよう指定し、ソースコードが自分のプロジェクトにコピーされます。
例えばinputコンポーネントをインストールするには、下記のコマンドを入力します。
pnpm dlx shadcn@latest add input
# → src/components/ui/input.tsx が生成される
input.tsxの中を確認してみると、次のようになっています。
import * as React from "react" import { Input as InputPrimitive } from "@base-ui/react/input" import { cn } from "@/lib/utils" function Input({ className, type, ...props }: React.ComponentProps<"input">) { return ( <InputPrimitive type={type} data-slot="input" className={cn( "h-8 w-full min-w-0 rounded-lg border border-input bg-transparent px-2.5 py-1 text-base transition-colors outline-none file:inline-flex file:h-6 file:border-0 file:bg-transparent file:text-sm file:font-medium file:text-foreground placeholder:text-muted-foreground focus-visible:border-ring focus-visible:ring-3 focus-visible:ring-ring/50 disabled:pointer-events-none disabled:cursor-not-allowed disabled:bg-input/50 disabled:opacity-50 aria-invalid:border-destructive aria-invalid:ring-3 aria-invalid:ring-destructive/20 md:text-sm dark:bg-input/30 dark:disabled:bg-input/80 dark:aria-invalid:border-destructive/50 dark:aria-invalid:ring-destructive/40", className )} {...props} /> ) } export { Input }
これがinputコンポーネントです。
import { Input as InputPrimitive } from "@base-ui/react/input"とあることからわかるように、Base UIがベースになっています。
ソースコードは編集可能な領域に保存され、次のいずれかの方法で、コンポーネントを使用することになります。
- そのまま利用
- ソースコードを編集して利用(再インストール時に上書きされないよう、ファイル名を変更する必要あり)
- ラッピングして利用
従来の開発フローとその課題
React + TailwindCSS v4 + shadcn/ui の開発フローは、概して次のようになります。
従来の開発フロー
1. ドキュメントを調べる └── ブラウザで https://ui.shadcn.com を開く └── 使いたいコンポーネントの仕様・依存関係を確認 2. ターミナルでコマンドを手動実行 └── pnpm dlx shadcn@latest add date-picker 3. AIにコード生成を依頼 └── 「DatePicker をこのフォームに組み込んで」 4. 生成されたコードを確認・修正 └── エラーがあれば原因を調べて修正
一見シンプルに見えますが、実際の開発ではいくつかの課題が生じます。
従来の開発フローの課題
コンテキストスイッチが多い
コードを書く作業の途中で、ブラウザでドキュメントを確認し、ターミナルでコマンドを実行し、またエディタに戻る——この行き来が積み重なると集中力が分断されます。1コンポーネントの導入に数分かかることも珍しくありません。
AIの生成コードが環境とズレることがある
shadcn/ui はアップデートが頻繁です。AIの学習データは過去のある時点のものであるため、現在のAPIと異なるコードが生成されることがあります。
// AIが生成したコード(古い知識に基づく) <DatePicker selected={date} onSelect={setDate} /> // 実際の現在のコード <DatePicker mode="single" selected={date} onSelect={setDate} /> // → props名が変わっていてエラーになる
生成されたコードが動かない場合、エラーの原因がAIのハルシネーションなのか実装の問題なのか判断するところから始まり、余計な時間がかかります。
依存コンポーネントの把握漏れ
shadcn/ui のコンポーネントは他のコンポーネントに依存していることがあります。
DatePickerコンポーネント を使うには Calendarコンポーネント + Popoverコンポーネント が必要 → AIが Calendarコンポーネント だけ追加するよう指示 → Popoverコンポーネント が足りずエラー → 原因を調べて Popoverコンポーネント も追加
依存関係はドキュメントを読めばわかりますが、AIはその情報を確実に把握しているとは限りません。
shadcn/ui MCPを導入した開発フロー
なぜshadcn/ui MCPを導入するのかというと、「自然言語を入力するとAIが直接ツールを操作できる仕組み」を構築するということにほかなりません。
従来:開発者 → ターミナルでコマンド入力 → ツール実行 MCP :開発者 → AIへ自然言語で依頼 → AIがMCP経由でツール実行
shadcn/ui は公式の MCP サーバーを提供しています。
shadcn/ui MCP ができること
主に以下の機能を提供します。
| 機能 | 内容 |
|---|---|
| コンポーネント検索 | 利用可能なコンポーネントの一覧・情報を返す |
| コンポーネント追加 | shadcn add [component] を自動実行する |
| コンポーネント情報取得 | 使い方・props・依存関係をAIが把握した上でコード生成できる |
従来の課題の視点で言うと、AIが「今この環境に何があるか」「最新の仕様はどうか」を自分で調べて操作できるようになることが本質的な変化です。
shadcn/ui MCP導入後の開発フロー
1. AIに依頼するだけ └── 「日付選択フォームを作って」 2. AIがMCP経由でコンポーネントを自動追加 └── DatePicker(+ Calendar + Popover)を自動インストール 3. AIが実際の環境を参照してコードを生成 └── インストールされたコードを見てコード生成するためズレが起きにくい
従来の開発フローとの比較
| 課題 | MCP導入前 | MCP導入後 |
|---|---|---|
| コンテキストスイッチ | ブラウザ・ターミナル・エディタを行き来 | AIとの会話だけで完結 |
| ハルシネーション | 古い学習データでコード生成 | 現在の環境を参照して生成 |
| 依存コンポーネント漏れ | 手動で確認が必要 | AIがMCP経由でCLIを操作し、依存関係込みで処理 |
まとめ
実際に使ってみて感じたのは、次のような点です。
効果・メリットなど
コマンドやコンポーネントを知らなくてもよい
shadcn add の正確なコマンドや依存コンポーネントの名前を覚えていなくても、AIに「日付選択フォーム が欲しい」と伝えれば追加してくれます。ドキュメントを調べる時間が減りました。
コンポーネントの依存関係を気にしなくても大丈夫
従来、DatePicker には Calendar と Popover が必要といった依存関係を自分で把握する必要がありました。MCP 経由ではこの解決が自動化されます。
コードの品質があがる
MCP を導入することで変わるのは「操作の自動化」だけではありません。「AIが環境を直接知った上でコードを生成する」という信頼性の向上が、より本質的な変化です。
AIが現在のプロジェクトに実際に存在するコードを参照してコードを生成するため、インポートパスや props のズレが起きにくくなりました。
注意点・デメリットなど
shadcn/ui の習熟が前提
MCP はあくまで「shadcn/ui の操作を自動化する仕組み」です。自然言語をAIに伝えることでさまざまなことができるようになりますが、shadcn/ui 自体を理解していないと、問題が起きたときに対処できません。MCP を導入する前に、手動でコンポーネントを追加・読解する経験を積む必要があると思います。
また、自らコーディングしなくても、React・TailwindCSSなど基になる技術も押さえておく必要があるように感じました。
ツールとしてまだ発展途上
shadcn/ui MCP は比較的新しいツールです。バージョンアップで挙動が変わることがあります。本番プロジェクトに導入する前に、小さなプロジェクトや検証環境で十分に検証することが必要です。
今後について
今回の取り組みはあくまで第一歩です。現時点で次のステップとしてFigma MCPとの連携を考えています。
デザインツールである Figma にも MCP サーバーが提供されています。Figma 上のデザインデータを AI が直接参照し、shadcn/ui のコンポーネントに変換するフローを整備することで、「デザイン → コード」の工程を短縮できると考えています。
さらに、「コード → デザイン」の仕組みを導入し、これまでフロントエンドエンジニアにとって敷居の高かった、Figmaの直接操作ができるようになれば、さらなる効率化を図れます。
この双方向のフローが実現すれば、デザイナーとエンジニアの間にあった「翻訳コスト」が大幅に削減され、より本質的な開発・設計に集中できる環境が整うはずです。結果として、デザインと実装の乖離が起きにくくなり、チーム全体の開発速度と品質を同時に高められると期待しています。
検証を進め、ある程度の目処がたったら、このシナプス技術者ブログで記事にしたいと考えています。ご期待ください。