TIS株式会社 生成AIイノベーション室は、生成AI時代に対応した次世代デザインシステムを構築しました。

なぜ今、デザインシステムなのか

受託開発を主軸とするSIerにとって、デザインシステムへの投資は長らく「費用対効果が見えにくい」領域でした。案件ごとに要件が異なり、納品後の保守期間も限られているため、社内資産として育てるインセンティブが生まれにくい構造です。

しかし、生成AIの登場によって状況は一変しました。Claude CodeやGitHub Copilotが開発現場に普及する中で、デザインシステムは「AIが正しく動作するための必須インフラ」として新たな役割を担います。

従来の課題

開発の現場では、以下の課題が顕在化しています。

  • 結合テスト段階での手戻り：画面のインタラクション確認が後回しにされ、デザイナーが実画面を確認した際に「イメージと違う」という手戻りが発生
  • 開発者のスキル差による品質差：案件ごとに異なるフレームワークやスタイルが採用され、経験やスキルの差が成果物に直接影響
  • AIコード生成の一貫性不足：明確な基準がないまま生成AIを利用すると、コードのスタイルや記述方法がばらつく

生成AI時代のデザインシステムはこれらの課題を解決します。

デザインシステムの構成と技術選定

私たちのデザインシステムは、Figma（デザイン側）からリポジトリ（開発側）への一方向のデータフローを基本としています。

技術スタックは以下の通りです。

技術 役割 選定理由
Figma Variables デザイントークンの定義・管理 デザイナーが直接編集できる唯一の「開発に影響するパラメータ」
Tailwind CSS v4 スタイリングシステム CSS Variablesが自動的にユーティリティクラス化
shadcn/ui + Radix UI UIコンポーネントライブラリ 案件ごとのカスタマイズに対応
Storybook 品質保証・合意形成 フロントエンド単体での確認を早期に実現、静的ホスティングで顧客確認も可能

Figma Variablesを「Single Source of Truth」とすることで、デザインとコードの乖離を防止します。Figma Variablesから生成されたトークンを、Tailwind CSS、shadcn/ui、Feature Componentsへと段階的に適用する一貫した変換フローを実現しています。

Storybookが担う4つの役割

Storybookは、デザインシステムの品質保証レイヤーにおいて、以下の4つの役割を果たします。

1. コンポーネントカタログ

すべてのUIコンポーネントを網羅的にカタログ化します。Default、Disabled、Loading等のすべての状態を可視化し、新規参画者のオンボーディングを短縮します。

2. 合意形成の場

「動く画面」を早期に確認し、ステークホルダー間で合意を取ります。結合テスト前のデザインレビューを実現し、「言った言わない」問題を解決します。顧客・デザイナー・PMを含む誰もが、ローカル環境不要で実装画面にアクセスできます。

3. AI実装基準

AIエージェントが参照する「正解」として機能します。実装パターン、トークン使用例、アクセシビリティ基準を提供し、一貫性のある生成を実現します。

リポジトリのルートに配置したAgents.mdがベースのシステムプロンプトとして機能し、AIは以下のリソースを参照して実装を行います。

  • Design Tokens：色・スペーシング等の値参照
  • theme.css：Tailwind設定の理解
  • Storybook：コンポーネント実装例・合意された正解
  • 方式設計書：実装ルールの遵守
方式設計書の一部抜粋

従来、方式設計書を丁寧に書いても実装時には全エンジニアが漏れなく遵守することは困難でした。エンタープライズ品質のための方式設計資料は多岐に渡るためです。AIがドキュメントを「読む」ことで、この問題は解消されます。ドキュメントが「人間が読むかもしれない資料」から「AIが必ず参照するシステムの一部」へと昇格するのです。

4. QA・テストプロセスの起点

品質保証・テスト戦略のハブとして機能します。画面動作の確認、アクセシビリティテストの統合実行により、リグレッション・抜け漏れを防止します。

関連記事 : 生成AI時代のフロントエンドテスト戦略 /なぜStorybook 10 + Vitest 4 を選ぶのか

期待される効果

各ステークホルダーが得られる価値は以下の通りです。

  • デザイナー：Figma Variables変更で全コンポーネントが自動更新、結合テストを待たずにStorybookで確認可能
  • 開発者：デザイントークンが定義済み、shadcn/uiで基盤コンポーネント完備、AIが設計を守った実装を支援
  • AIエージェント：トークン・方式設計書・Storybookを参照し一貫性のあるコードを生成、手作業での修正が最小限
  • 顧客：結合テスト前にStorybookで画面確認、手戻りの最小化、納期短縮

まとめ

デザインシステムは「作って終わり」ではありません。プロジェクトを重ねるごとに蓄積される知見が、次のプロジェクトの開発効率を高め、品質を向上させます。そして、その知見を「AIが読める形」で残すことで、組織全体の資産として機能し続けます。

人が育てたデザインシステムを、AIが学び、次の開発を支援する——このサイクルが、生成AI時代における真の競争優位性となります。

今後の展開

TISは本デザインシステムを社内全体に展開し、Reactプロジェクトにおける50%以上の生産性向上を目指します。

システム開発への生成AI活用を前提とした「AI中心開発」の取り組み

Appendix: 採用する技術スタック

補足：本記事の記載情報は、2026年3月時点のものです。全体構成や使用ライブラリはTIS デザインシステムチームにて継続した改善と試行がされています。

1. フロントエンド技術スタック

レイヤー 技術 用途 / 位置づけ
フレームワーク Next.js (App Router) SSR / RSC / Server Actions / ルーティング
言語 TypeScript 型安全・契約整合
UIレンダリング基盤 React コンポーネントレンダリング
デザインツール Figma UI設計 / Variables定義 / 仕様管理
スタイリング Tailwind CSS ユーティリティファースト設計
UI コンポーネント shadcn/ui Radixベースラッパー
UI プリミティブ Radix UI Primitives アクセシビリティ準拠
サーバ状態管理 @tanstack/react-query サーバ状態キャッシュ / 再検証
クライアント状態 Zustand 軽量状態管理
フォーム react-hook-form 非制御フォーム管理
スキーマ検証 Zod 実行時型検証・Factory SSOT
HTTP通信 fetch + 独自 httpClient Web標準ラッパー（SSR/CSR共通）
API モック MSW Story / E2E 統一環境
国際化 next-intl App Router最適化 i18n
通知 Sonner トースト通知

2. テスト・品質検証スタック

レイヤー テスト種別 技術構成
Static 型・構文・規約検査 TypeScript + ESLint
Logic Solitary Tests（ロジック） Vitest
UI（Solitary） Solitary Tests（UI） Storybook + Playwright
UI（Sociable） Sociable Tests Storybook + Playwright + MSW
A11y アクセシビリティ自動検証 vitest-axe
VRT Visual Regression Test Storybook
E2E End-to-End テスト MagicPod
Performance パフォーマンス基準確認 Lighthouse CI
Bundle バンドルサイズ増分検知 Vite analyze + custom script

3. パイプライン管理

機能 技術 役割
API 契約（スキーマ） OpenAPI コントラクトの単一真実（SSOT）
自動コード生成 orval / openapi-zod-client 型 + Zod スキーマ自動生成
テストデータ Factory Zod Factory OpenAPI → Zod → Factory → MSW
CI/CD パイプライン GitLab CE PR検証 / Scheduled実行 / Security
E2E Sharding Playwright 並列実行・CI最適化