✍️ 필사 모드: デザインシステム・トークン 2025 完全攻略:Radix・shadcn/ui・Chakra・Tamagui・Park UI・Ark UI・DaisyUI 比較、W3C Design Tokens 標準、Figma Variables・Tokens Studio 連携、コンポーネント API 設計、アクセシビリティ、韓国大企業事例 — Season 6 Ep 2

プロローグ · デザインシステムは CSS ではない

2020 年頃から、あらゆる組織が「デザインシステム構築プロジェクト」を始めた。2025 年現在、成功したシステムと失敗したシステムがはっきりと分かれている。

• 失敗したシステム:CSS やコンポーネントライブラリだけあって、誰も使っていない
• 成功したシステム:組織の共通言語となり、デザイナー・エンジニア・PM が同じ単語を使う

よくある 3 つの誤解:

1. 「design system = コンポーネントライブラリ」(×)
2. 「design system = デザインチームの仕事」(×)
3. 「design system = Figma ファイル」(×)

真実:

design system = トークン + コンポーネント + パターン + ドキュメント + ガバナンス。 そしてこれを Figma・コード・Storybook で同じように表現できる仕組み。

2024–2025 年は Figma Variables と W3C Design Tokens Community Group 標準が定着し、**「Design-to-Code の接続がようやく実用段階に」**入った年だった。この記事はその地形図である。

第 1 章 · デザインシステムの 5 層構造

成熟したデザインシステムは 5 層構造だ。

Layer 1: Primitive Tokens(原子トークン)

• 色・フォント・間隔・半径・影の生の値
• 例:color-slate-500 = #64748b、space-2 = 8px

Layer 2: Semantic Tokens(意味トークン)

• Primitive に意図を与える
• 例:color-surface-primary、color-text-muted、color-border-critical
• テーマ切り替え(light/dark)の要

Layer 3: Component Tokens

• 特定のコンポーネントに紐づくトークン
• 例:button-primary-bg、card-shadow-hover

Layer 4: Components(コンポーネント)

• Button、Input、Card、Dialog など実際の UI 部品
• アクセシビリティ・キーボードナビゲーションを内包

Layer 5: Patterns(パターン)

• コンポーネント組み合わせ・ページレイアウトのルール
• 例:「エラー状態パターン」、「empty state パターン」

なぜ 3 段階のトークンなのか

Primitive だけを使うと

• ダークモード追加時にすべてのコンポーネントを修正する必要がある
• リブランディング時に大規模な変更が発生する

Semantic を挟めば

• color-surface-primary だけをダークモード用の値に差し替えれば → 自動的に反映
• 組織が大きくなるほど必須

第 2 章 · 2025 年の主要コンポーネントライブラリ地形

(1) Radix UI (Primitives)

• Headless(スタイルなし) + アクセシビリティが完璧
• Dialog・Popover・Select・Tooltip など複雑なパターンを内蔵
• shadcn/ui の基盤
• WAI-ARIA を完璧に実装

(2) shadcn/ui

• **「インストールせずにコピーせよ」**という哲学
• Radix ベース + Tailwind でスタイリング
• 各コンポーネントを自分で所有する(自分のリポジトリにコピー)
• 2024–2025 で最も人気
• 拡張・カスタマイズが自由
• CLI(npx shadcn add button)で利便性向上
• 韓国スタートアップでは事実上の標準

(3) Chakra UI

• プロ仕様の完成型、Styled + アクセシビリティ
• sx prop でインラインスタイル
• エンタープライズで素早い開発を好む場合に

(4) Tamagui

• React Native + Web を同時サポート
• コンパイル時最適化でパフォーマンスが良い
• クロスプラットフォームアプリに最適

(5) Park UI(CVA ベース)

• Ark UI + Panda CSS + Class Variance Authority
• デザインシステムビルダー視点

(6) Ark UI

• Zag.js ベースの headless(ステートマシン)
• React・Solid・Vue すべてに対応
• Radix のマルチフレームワーク代替

(7) DaisyUI

• Tailwind ベースの Styled ライブラリ
• テーマシステムが強力
• CSS-first、JS 依存最小

(8) Mantine

• Chakra に似た完成型
• Form・DataTable・Notifications などの付加機能が豊富

(9) HeroUI(旧 NextUI)

• モダンなデザイン、React・Tailwind ベース
• アニメーションを標準搭載

(10) エンタープライズ:Ant Design、Material UI (MUI)、Fluent UI

• 大きな組織・レガシーを継続利用する場合
• 2024–2025 の新規プロジェクトでは shadcn 系のほうが人気

総合比較表

第 3 章 · Headless か Styled か — どちらを選ぶか

Headless(Radix・Ark・React Aria)

• 振る舞い・アクセシビリティのみを提供、スタイルはゼロ
• 長所:完全なデザインの自由、ブランドアイデンティティの表現
• 短所:スタイリングの責任は 100% 自分
• 向き:自社デザインシステムを作るチーム

Styled(Chakra・MUI・Ant・Mantine)

• 事前にデザインされたコンポーネント
• 長所:素早い開発、基本品質の担保
• 短所:ブランド固有性に制限、オーバーライドが面倒
• 向き:B2B SaaS・社内ツール

Hybrid(shadcn/ui・DaisyUI)

• Headless エンジン + スターター用スタイル
• 所有権を自分に移す(shadcn)
• 長所:素早い立ち上がり + 完全なカスタマイズ
• 2024–2025 の主流

選択基準

Headless が合うケース

• ブランドが視覚的アイデンティティの核心(ラグジュアリー・クリエイティブ系ブランド)
• アクセシビリティ・アニメーションにとことんこだわる
• エンジニアとデザイナーで自力にデザインシステムを作れる体制

Styled が合うケース

• B2B の管理ダッシュボード
• 市場投入スピードが最優先
• ブランドより機能性が重要

Hybrid(shadcn)が合うケース

• 大半のスタートアップ・プロダクトチーム
• 立ち上げは素早く、成長とともにカスタマイズ

第 4 章 · W3C Design Tokens 標準

2024–2025 年、W3C Design Tokens Community Group (DTCG) の標準フォーマットが定着した。

標準フォーマット(DTCG 2024)

{
  "color": {
    "brand": {
      "primary": {
        "$value": "#0066ff",
        "$type": "color",
        "$description": "Main brand color"
      }
    }
  }
}

主な特徴

• $value、$type、$description フィールド
• Alias 対応:"$value": "{color.brand.primary}"
• 入れ子のグループ
• Figma とコードの双方向互換

主な Type

• color、dimension、fontFamily、fontWeight、duration、cubicBezier、typography、shadow、gradient、transition、border

Figma Variables(2023–2024)

• 2023 年末に GA。DTCG 互換
• モード(Mode)対応:Light/Dark、Mobile/Desktop
• トークンを Figma 上で直接定義・利用

連携ツール

(1) Tokens Studio for Figma

• Figma でトークンを定義 → GitHub に push
• Style Dictionary 形式・DTCG に対応
• 最も成熟した Figma と コードの橋渡し

(2) Specify

• デザインソース(Figma・Sketch)をコードリポジトリに自動同期
• CI 連携

(3) Style Dictionary(Amazon)

• オープンソースの標準、2024 年 v4.0 で DTCG 対応
• トークン JSON を CSS/iOS/Android/Web に変換

(4) Supernova

• エンドツーエンドのデザインシステムプラットフォーム
• トークン・ドキュメント・コード生成を統合

実戦ワークフロー

Figma Variables / Tokens Studio
         ↓ push
    GitHub (tokens/*.json)
         ↓ CI
    Style Dictionary
         ↓ build
[web.css, ios.swift, android.xml]
         ↓ publish
    NPM · CocoaPods · Maven

第 5 章 · コンポーネント API 設計原則

ライブラリの価値を決めるのは API 設計だ。使い心地がよければ定着し、難しければそっぽを向かれる。

5 つの原則

(1) Composition over Props

• 数百の prop か、コンポジションか
• Bad: <Button leftIcon={...} rightIcon={...} loading iconOnly ... />
• Good: <Button><Button.Icon><Plus/></Button.Icon>追加</Button> のように子要素の組み合わせで

(2) Controlled と Uncontrolled の両対応

• デフォルトは Uncontrolled(内部状態)
• 必要時に Controlled へ(value / onChange)
• React ライブラリの標準

(3) asChild パターン(Radix)

• 親コンポーネントの機能を子に委譲する
• 例:<Button asChild><Link href="/home">ホーム</Link></Button> — Button のスタイルとアクセシビリティを Link が引き継ぐ

(4) ポリモーフィックな as prop(ただし型が複雑)

• <Box as="section"> のようなタグ差し替え
• asChild が現代的な代替

(5) Variant パターン

• Class Variance Authority(CVA)、Tailwind Variants

const button = cva('base-classes', {
  variants: {
    size: { sm: '...', md: '...', lg: '...' },
    variant: { primary: '...', ghost: '...' },
  },
});

悪いサイン

• API 変更が頻繁 — 四半期ごとに breaking change
• ドキュメントに「普通はこうだが例外は…」が多い
• prop の組み合わせでバグが頻発
• カスタムフックが多すぎる(ライブラリに縛られる)

第 6 章 · Theming とダークモード

2025 年の標準アプローチ

1. Semantic Tokens で色を抽象化(surface、text、border)
2. CSS Variables ベースでテーマをランタイム切り替え
3. prefers-color-scheme メディアクエリ + ユーザー選択を保存
4. SSR のちらつき防止:サーバー側で localStorage を読むか、初期 HTML にクラスを挿入

実装例(shadcn/ui デフォルト)

'use client';
import { ThemeProvider } from 'next-themes';

export default function Root({ children }) {
  return (
    <ThemeProvider attribute="class" defaultTheme="system">
      {children}
    </ThemeProvider>
  );
}

:root { --background: 0 0% 100%; --foreground: 222.2 84% 4.9%; }
.dark { --background: 222.2 84% 4.9%; --foreground: 210 40% 98%; }

色の細分化(2024–2025)

• 3 状態モード:system / light / dark
• 4〜5 テーマ:ブランド別あるいは役割別(例:admin/customer)
• HDR 対応の議論:新しい CSS color() 関数、P3 色空間

第 7 章 · アクセシビリティ — デフォルト哲学

「アクセシビリティは追加機能ではなく、デフォルトだ。」

WCAG 2.2(2023)の主要変更

• ドラッグ操作にDrag-less 代替手段を義務化
• Target Size 24×24px 以上
• Consistent Help(ヘルプ配置の一貫性)
• Focus Indicator を明確に

デザインシステムのデフォルト

• すべての interactive 要素にキーボード対応
• フォーカスリングを可視化(:focus-visible)
• スクリーンリーダー用ラベル(aria-label / aria-labelledby)
• 色のコントラスト 4.5:1 以上(テキスト)
• prefers-reduced-motion を尊重してモーションを抑制

主要ツール

• axe-core、axe DevTools:ブラウザ自動検査
• Lighthouse Accessibility
• Storybook a11y addon:コンポーネント単位
• NVDA・VoiceOver:実機スクリーンリーダーテスト

法的要求

• EU アクセシビリティ法(EAA) が 2025 年 6 月に発効
• 韓国のウェブアクセシビリティ認証マーク、障害者差別禁止法
• 米国の ADA・Section 508
• グローバル SaaS では必須レベル

第 8 章 · モバイル・クロスプラットフォームのデザインシステム

Web と モバイルの共存戦略

(1) 分離運用

• Web は React、モバイルは Swift/Kotlin ネイティブ
• トークンだけを共有、コンポーネントは各自

(2) React Native 共有

• Web と Native を両方 React で
• Tamagui、Solito、Expo Router
• トークンとコンポーネントの多くを共有できる

(3) Flutter

• 技術スタックが全く異なる、独自の DS を構築する必要あり

2024–2025 のトレンド

• Expo + React Native Web:多くのスタートアップが採用
• Apple HIG と Material You の差異を尊重
• Responsive と Adaptive の組み合わせ:ブレークポイント + プラットフォーム

第 9 章 · 韓国大企業のデザインシステム事例

Toss(TDS / Toss Design System)

• Headless + shadcn 系の影響
• モーションの細部にとことんこだわる
• 公開ブログ・カンファレンス(SLASH)で有名
• 独自アイコンシステム・Toss Font

Naver(NAVER Design System、NaverNow)

• Whale ブラウザ・Naver 全般で共通
• アクセシビリティ先導(国内で最初に WCAG 対応)
• 露出範囲が非常に大きい(数億ユーザー)

Kakao(Kakao Design Language)

• KakaoTalk・Pay・Mobility・Games
• 統合 vs サービスごとの分離のバランス
• Ryan・Apeach キャラクターが強いブランド

Coupang(Coupang Design System)

• 大規模 e コマースに特化
• A/B 実験と連動するコンポーネント
• 多国展開(米国・台湾・日本)に対応

LINE(LINE Design System、LDS)

• グローバルチームでの協業
• アクセシビリティ・国際化(i18n)が深い
• 日本・タイの UX も考慮

Baemin / Woowa(Woowa Design System)

• カスタム化した Toss 系と shadcn を併用
• 開発・デザインカンファレンスが活発

共通パターン

• Figma ライブラリと Storybook を連携
• トークンを Primitive/Semantic で分離
• ブランド単位のバリアント(サービスごとの色)
• 社内のデザインシステム専任チームが 10–30 名規模

第 10 章 · チーム規模別の導入戦略

1–3 名(個人・アーリーステージ)

• shadcn/ui + Radix + Tailwind
• トークンは Tailwind config に直接
• Figma Variables を軽く利用

10–30 名(Series A–B)

• shadcn をベースに自社コンポーネントライブラリを分離(monorepo パッケージ)
• DTCG トークン JSON を別管理
• Storybook を導入、利用ガイドのドキュメントを整備
• デザインシステム担当 0.5–1 名

50–200 名(Series C 以上)

• トークン自動同期パイプライン(Tokens Studio → GitHub)
• デザインシステム専任チーム 2–5 名(デザイナー + エンジニア)
• クロスチームのガバナンス・バージョン管理
• アクセシビリティ専任レビュー

200–1500 名(大企業)

• プラットフォームチームが 5–20 名
• マルチプラットフォーム(Web + iOS + Android)
• 多国対応・法的要求(WCAG・ADA・EAA)
• 社内デザインシステムカンファレンス・研修

共通の失敗パターン

• コンポーネントだけ作ってトークンがない → ダークモード切り替え不可
• デザイナーとエンジニアの断絶 → 実装とデザインの不一致
• ドキュメント不在 → 使われない
• ガバナンスなし → チームごとに fork、多様性が爆発
• マイグレーション計画なし → 既存 UI が放置される

第 11 章 · 実戦 · 「shadcn で社内デザインシステムを始める」90 日

Day 1–14:トークン定義

• Figma Variables で Primitive + Semantic トークン
• DTCG JSON をエクスポート
• CSS Variables で web に反映

Day 15–30:基礎コンポーネント

• Button、Input、Select、Dialog、Toast、Card
• shadcn CLI で導入後、ブランドに合わせて調整
• Storybook を整備

Day 31–45:パターン

• Form、Table、EmptyState、ErrorState
• 実プロダクトのページを 1–2 本、再構成

Day 46–60:ガバナンス

• 貢献ガイド、PR レビュー基準
• 変更ログ・SemVer

Day 61–75:アクセシビリティ

• axe・Storybook a11y を統合
• キーボード・スクリーンリーダーテスト

Day 76–90:展開・教育

• 社内発表、チャンピオンの指名
• 各チームへの導入支援

第 12 章 · 次回予告 — Season 6 Ep 3:「AI-Native UI と Generative UX」

デザインシステムがあれば、次は AI が UI を作る時代だ。Ep 3 では AI-native UI パターンを扱う。

• Generative UI:LLM が直接 UI を選択・生成
• Streaming UI:トークン単位の逐次レンダリング
• Tool Use と UI(Tool Call → Dynamic Card)
• AI SDK(Vercel)、LangChain UI、LlamaIndex.TS UI
• 対話型インターフェースの設計
• フィードバック・修正 UX
• 不確実性・ハルシネーションの可視化
• エージェントの Human-in-the-loop UI
• Progressive Disclosure と AI
• 2025 年の AI プロダクト UX ベンチマーク

「AI が応答を生成している間、ユーザーは何を見ているのか?」

次回の記事で会おう。

エピローグ · チェックリスト 12

1. デザインシステムがトークン・コンポーネント・パターン・ドキュメント・ガバナンスの 5 層を備えているか?
2. Primitive と Semantic トークンが分離されているか?
3. Figma とコードの同期パイプラインがあるか?
4. コンポーネントが Composition・Controlled・Variant パターンを一貫して使っているか?
5. ダークモードがテーマトークンの差し替えだけで自動切り替えになっているか?
6. アクセシビリティ(WCAG 2.2) のデフォルトが組み込まれているか?
7. Storybook とドキュメントサイトが最新の状態か?
8. トークンが DTCG 形式で保存されているか?
9. 貢献ガイド・レビュー基準がドキュメント化されているか?
10. 既存 UI から新 DS へのマイグレーション計画があるか?
11. デザインシステムが実プロダクトに 80% 以上使われているか?
12. 保守担当が明確か?

「良いデザインシステムは見えない。 プロダクトが『当然こうあるべき』と感じられれば、システムは正しく機能している。」

— Season 6 Ep 2, Fin.