こんにちは。CTO の十川です。
NCDCでは、Storybookというソフトウェアを活用してデザインシステムを構築した実績があります。この記事では、Storybookを使ったデザインシステムの構築例を中心に、導入のメリットや管理方法に加え、近年のトレンドであるパッケージ配布やデザイナーとの協業、そして生成AIとの組み合わせ方についても紹介します。
（本記事は、2021年に公開した記事をもとに、2026年9月時点の最新情報を加味してリライトしたものです）
デザインシステムとは？
デザインシステムとは、デザインの概念、原則などをまとめたドキュメント、それらを具体的なデザインに落とし込むためのスタイルガイド、コンポーネント集、そしてその管理・運用ルールや、コード化されたコンポーネントの管理に用いるツールなど、さまざまな構成要素で成り立つ仕組みです。
デザインシステムの活用により一貫した UI デザインを短期間に実装できるようになるため、大規模な Web サイト・システムの構築などのプロジェクトでは多くのメリットが得られます。
（詳細は別の記事「デザインシステムとは？ メリット・デメリット・具体例を解説」で紹介しているので、併せてご覧ください）
デザインシステムは、原則やスタイルガイド、運用のルールまで含む包括的な仕組みであるため、Storybookがそのすべてを担うわけではありません。Storybookは「コード化された UI コンポーネント」と「その使い方」を一つの場所で扱えるため、デザインシステムの「実装側（コンポーネントライブラリ）」を支える道具には非常に適しています。
デザインツールのFigmaが「あるべき見た目」を示すものだとすれば、Storybookは「実際に画面に載る部品」を管理して各所へ配るツール、という関係性になります。フロントエンドの実装作業の際に、デザイナーからFigmaのデザインやCSSを共有するだけでは、どうしてもエンジニアが画面ごとに部品を作り直してしまう余地が残りますが、Storybookを活用することでそれを防ぐことができます。
Storybookとは？
Storybookは、UIコンポーネントをアプリケーション本体から切り離して開発・確認するためのオープンソースのツールです。ReactやVue、Angularなど、主要なフロントエンド環境で幅広く使われています（Storybook 公式サイト）。
最大の特徴は、アプリ全体を起動しなくても、ボタンや入力フォーム、ヘッダーといったUIコンポーネント（部品）を「カタログ」のように並べて、単体で確認できる点にあります。もう少し具体的に言うと、エラー時の表示やデータの空き状態、ユーザーの権限による表示の違いなど、実際のアプリ画面では意図的に再現しにくい状態も、Storybookのカタログ上であれば簡単に確認することができます。
同じリポジトリ内で Storybookを起動し、アプリ全体を動かさずに部品をチェックする、というのが基本的な使い方です。複数のアプリで共通のUIデザインルールを使いたい場合には、共通 UI（部品とStorybook）をひとつのパッケージとして切り出して配布する運用も可能です。NCDCでも、案件の要件に応じてこれら両方のアプローチを使い分けています。
Storybookでできること
UIコンポーネントをアプリケーション本体とは別に管理することで、具体的には次のようなメリットが得られます。
- アプリケーションとは独立した開発環境に構築できるため、UIコンポーネントを先行して開発したり、挙動のテストなどを行ったりできる
- UIコンポーネントをカタログのように一覧で管理できる
- UIコンポーネントの使用方法や注意点なども Storybook 上に記載できるため、ガイドラインを部品と一緒に提供できる
- UIコンポーネントを共通利用できるため、同じような部品を複数の人が作ったり、似ているが微妙に違う実装が乱立したりするのを防げる
また、挙動の確認や、使いやすさのチェックも、アプリ全体ではなく部品単位で行いやすくなります。
ただし、コンポーネントを取り込んだだけで画面が完成するわけではありません。画面全体の組み立てやデータのつなぎ込みといった処理は、当然ながらアプリ側に残ります。Storybookが担うのは、あくまで「見た目と基本的な動きの再利用」と「その使い方の共有」です。
Storybookを利用したデザインシステム
実際にStorybookがどのように使われているかというと、UberやAirbnb、IBM、GitHubなど、多くの世界的企業がデザインシステムに利用しています。
前述した通り、デザインシステムには「一貫したUIデザインを短期間に実装できる」ことが求められます。そのため、UIコンポーネントの開発・管理を効率化できるStorybookが積極的に採用されていると考えられます。
Storybookを使用したデザインシステムの構築例
NCDCでもStorybookを使ったデザインシステムの構築例があるので、ここでは前述した「パッケージとして配る場合」によくある構成のポイントを3つ紹介します。
- フロントエンドの開発には、コンポーネント指向（ソフトウェアを機能ごとに部品化し、必要に応じて組み合わせる考え方）で画面を組めるReact、Vue などを採用する
- 共通UI（部品とStorybook）は、アプリ本体とは別のパッケージとして管理する。複数のリポジトリから取り込む場合は別リポジトリにし、一つのリポジトリの中で使う場合はUI用のパッケージに分ける
- アプリ側は、その共通UIをパッケージとして取り込み、必要な部品だけを呼び出して画面を実装する
この場合の公開先は、パッケージ化されたプログラムの保存・共有用サービスであるnpmや GitHub Packagesなどが一般的です。コンポーネントにバージョンを付けて配布し、各アプリからそれを取り込んで使用します。
一方で、UIコンポーネントをパッケージとして取り込む手法は、中身の書き換えがしにくく、プロダクト固有の細かな事情に合わせづらいという側面もあります。そのため、近年フロントエンド開発で注目を集めている『shadcn/ui』などに代表される「部品のソースコードそのものをプロジェクトへ直接コピーして使うやり方」も増えています。
この場合、依存関係として導入するのではなく、コード自体を自分たちで持てるため、見た目や挙動を案件に合わせて柔軟に変更しやすいというメリットがあります。
その代償として、複数のアプリへ同じ修正を配布したり、どのアプリがどのバージョンを使っているかを追跡したりするのは、パッケージ管理よりも手間がかかります。「共通UIを複数のアプリで厳密に揃えたい場合」はパッケージとして配布し、「一つのアプリで中身まで柔軟に調整したい場合」はソースコードを直接置く、といった使い分けが重要です。
下の図は、パッケージとして配る場合の流れを示しています。
デザイナーとエンジニアの協業
デザインシステムを効果的に運用するには、デザイナーとエンジニアのスムーズな協業が欠かせません。
デザイナーはFigmaの画面を、エンジニアは自身の書いたコードの画面をそれぞれ別々に見ていると、どうしてもデザインと実装の間に認識の差が生まれやすくなります。しかし、Figmaの見た目だけに基準を置くのではなく、Storybook上の実装を「実際に画面に載るUI」の共通言語として扱うことで、その差は残りにくくなります。使い方や注意点をカタログに書き添えておけば、デザイナーもエンジニアも「どの状態が想定されているか」を同じ場所で正確に確認できます。
ただし、そのカタログがエンジニアのローカルマシンでしか動かない状態では、確認できる人が限られてしまいます。そこで、Storybook を静的なサイトとしてウェブ上に公開すると、URLを開くだけでチーム全員が部品や状態を見られるようになります。環境構築の手間なく、全員が同じカタログを見ながら議論できるようになるのです。Storybookの公式では、その公開先として「Chromatic」というサービスを推奨しています（Publish Storybook）。
見た目の意図しないズレをしっかりと拾い上げたい場合は、ストーリー（通常時や無効時など、部品の状態を確認用に切り出した画面）を基準にしたデザインレビューも可能です。Chromaticには変更前後の画面を比較してズレを検知する機能があり、デザイナーが「ここが想定と違う」と直接コメントを残すコミュニケーションの場にもなります。
もちろんChromatic以外のサービスに公開することも可能ですが、PR （プルリクエスト）のコードレビューと並行して、見た目の差分確認まで行うのであれば、現在のところ非常に有力でよく使われる選択肢です。
共通UIコンポーネントのバージョン管理
Storybook に限らず、デザインシステムを運用する場合は、「さまざまな場所で利用されている共通 UI コンポーネントの修正やアップデートに、どのように対応するか」という課題が必ず出てきます。
基本的な考え方は、一般的なソフトウェアの共通ライブラリのバージョンアップと同様です。関わっているすべてのアプリを強制的にアップデートするのではなく、UIコンポーネント自体をしっかりとバージョン管理し、各アプリケーションの都合に合わせて「どのバージョンを使用するか」を選択できるように設計するのが望ましいです。
実際の運用の例としては次のようなイメージになります。
- 共通UIはパッケージとして公開し、「1.4.0」「2.0.0」のように複数のバージョンを並行して保持する
- 互換性のない大きな変更を加える際は、「2.0.0」のように先頭の数字（メジャーバージョン）を上げてリリースする
- 新規に開発するアプリは、最新のバージョン（例：2.0.0）を採用する
- 既存のアプリは、次の大きな改修タイミングが来るまでは、無理にアップデートせず古いバージョン（例：1.4.0）を使い続けてもよいルールにする
このように各アプリが採用しているバージョンを明示的に残せる仕組みにすることで、どのアプリがどの状態のUIを使っているかを追跡・管理しやすくなります。
Storybookでデザインシステムを構築するメリット
Storybookで何ができるか説明してきましたが、あらためて「デザインシステムをStorybookで構築するメリット」は何か？を整理したいと思います。
これまで一貫したUIを実装するための手段としては、スタイルガイドやUIキットの提供、CSSファイルの共有など、さまざまな方法がとられてきました。
しかし、これらの手法はいずれも「UIコンポーネントそのもの」はそれぞれのアプリのエンジニアが個別に開発・管理する必要があり、複数のアプリケーションで共通のUIを使うようなケースでは、効率化や一貫性の維持に限界がありました。
一方、アプリケーションから独立した環境でUIコンポーネントを構築・管理できるStorybookを使用した場合、UIコンポーネントそのものを直接共有できるため、アプリケーション側は共通部品を取り込んで画面を組めるようになります。画面の組み立てやデータのつなぎ込みはアプリ側に残りますが、部品そのものをゼロから作り直す必要はなくなります。さらに、ReactやVueのようなコンポーネント指向のフレームワークと組み合わせることで、部品の再利用性やカタログ化の恩恵を最大限に引き出すことができます。
このように、一貫した高品質なUIを実現しつつ、従来はエンジニアが個別にかけていたUIの開発・管理工数を大幅に削減できる点が、デザインシステムをStorybookで構築する最大のメリットだと言えます。
Storybookベースのデザインシステムの向き・不向き
Storybookをベースにしたデザインシステムがすべてのプロジェクトにおいて万能な仕組みというわけではありません。導入を検討する際は、初期の構築や日々の運用に一定の工数をかけてでも、それを作る価値があるかどうかを慎重に判断する必要があります。
メリットが大きいもの、適しているもの
大まかに言えば、「それなりの規模のUIコンポーネントが必要であり、継続的にデザインを管理していくプロジェクト」には適していると言えます。とくにReactやVueのようなコンポーネント指向のフレームワークと組み合わせると、部品の再利用やカタログ化がしやすいです。
具体的には以下のようなケースはメリットが大きいです。
- 社内ユーザー向けの業務アプリ群など、同じユーザーのグループに対して複数のアプリを提供する場合
- 同一のブランドデザインで、サービスページ、サポートページなど複数のWebサイトを横断的に運用する場合
- 構築するアプリは一つでも、長期間にわたって継続的に機能をリリース・改善していく場合
メリットが小さいもの、適していないもの
逆に言えば、「規模が小さいプロジェクト」や「継続的にUIを管理する必要がないプロジェクト」において、わざわざStorybookでデザインシステムを構築するのはオーバースペックになります。
- デザインの統一性がそこまで重要視されないもの
- 一度作れば終わりで、継続的にUIを追加・管理する必要がないもの
Storybookが主に想定しているのはWebフロントエンドです。React Native向けは存在しますが、SwiftやKotlinといったモバイルネイティブアプリまで同じカタログで完全に賄うのは難易度が高いです。このような場合は、Figmaで決めた色や余白など、実装言語に依存しない上位の層で共通化を図った方が良いかもしれません。
StorybookにおけるAI活用術
2026年現在の開発現場では、カタログを作る際のFigmaのデザインデータや、完成したカタログを各プロダクトへ展開したあとの部品の仕様情報を、Claude CodeやGitHub CopilotなどのAIエージェントに直接読み込ませて作業を効率化できるようになっています。
カタログの構築
カタログを作る段階では、Figma上のデザインデータをAIエージェントから読み取れるように設定します。Figma MCPがそれに当たります（Figma MCP Server）。（MCP：Model Context Protocolの略称。AIエージェントに外部ツールの情報を連携・提供するための共通規格）
これを利用すると、AIエージェントが選んだフレームから、色や余白、部品の構成、レイアウトなどを直接取得できるようになります。
その実データを手がかりに、次のような作業をAIに支援させることができます。
- Storybookに載せるUI部品のコーディング（実装）を進める
- 通常時・無効時・危険操作時などのバリエーション状態を、ストーリーとして自動的に揃える
- 使い方や注意点の説明文を生成し、部品と一緒にカタログへ記載する
Figma上のデータをAIが読み取りコードを生成する方が、エンジニアがFigmaのデザイン指定を目視で拾い上げながら手打ちで進めるよりも、はるかに効率よく、正確にカタログを構築できます。
プロダクトへの展開
できあがったカタログを各プロダクトの画面実装で使うときは、今度はStorybook上のカタログ情報をAIエージェントから読み取れるようにします。Storybook MCPがこれに当たります（Using Storybook with AI）。
AIはここから部品の一覧、プロパティの仕様、ストーリーのバリエーション、使い方の説明などを取得します。
AIエージェントに単に「画面を実装して」と指示を出すだけでは、せっかく作ったカタログの存在を知らずに、似たような部品を独自に新規作成してしまうことがあります。しかし、MCPを通じてカタログの情報を渡しておくことで、AIは「既存の共通部品を使って画面を組み立てる」ようになります。もちろん、実装したい画面のデザインも、Figma MCPを経由して同時に渡すことが可能です。
その情報を手がかりに、次のような作業を支援できます。
- 必要な入力フォームやボタンをカタログから探し出し、組み合わせて画面全体を構築する
- カタログに規定されている「正しい使い方」や「状態」に沿った実装にする
人間が手作業で部品を探して画面に配置していくよりも実装スピードが上がり、プロジェクト内に不要な「似て非なる部品」が増殖するのも防ぐことができます。
Storybookを用いたデザインシステムをお勧めする理由
繰り返しになりますが、Storybookでデザインシステムを構築する最大のメリットは「アプリケーションの実装言語やフレームワークを使って、UIコンポーネントを独立して開発・管理し、アプリから簡単に再利用できること」にあります。
UIコンポーネント自体を共通化することで、デザインの統一と実装の効率化という2つの側面において、非常に優れた環境を構築することができます。
デザインシステムの継続的な運用にはデザイナーとエンジニア双方の協力が必要不可欠ですが、エンジニア視点で言えば、現在においてもStorybookを採用することは、非常に理にかなった良い選択肢だと考えています。
UX/UIデザインからデザインシステムの構築まで
NCDCではデジタルプロダクトのUX/UIデザインからモバイル・Webアプリの開発まで、一貫してサービスを提供しています。プロジェクトの規模に応じて、こうしたデザインシステムの構築支援も行っています。
また、システムの内製チームがあり開発自体は自社で行っている、という場合でも、こうしたモダンな手法を取り入れる内製の支援やAI駆動開発の支援も行っています。
「デザインの共通化によってUXの改善を図りたい」「UIの管理方法を改善してシステム開発の効率を良くしたい」といった課題をお持ちの方は、ぜひお気軽にご相談ください。
