Storybookとは？Figmaとの違いとUIの状態を共有する始め方

Storybookは、実装したボタンやフォームなどを、アプリ全体から切り離して開発・確認・共有するための環境です。 「通常はきれいだが、長い文章やエラーでは崩れる」といったUIの状態を、繰り返し開ける確認用の例として残せます。

カバー画像はUI部品を表現した生成イラストで、Storybookの実画面ではありません。

この記事は、デザイナーとエンジニアの間で部品の仕様を共有したい方や、UIの確認漏れを減らしたい制作担当者向けの入門です。Storybookをこのサイトへ導入する記事ではありません。以下の状態表と運用手順は説明用の提案であり、当社の導入実績や効果を示すものではありません。情報は2026年11月12日の公式資料を確認しています。

Storybookで何ができる？

公式サイトでは、StorybookをUIの開発・テスト・ドキュメント作成に使う、無料のオープンソースの環境として紹介しています。完成したページを眺めるだけでなく、部品を特定の条件で表示できることが特徴です。

たとえば、商品カードなら「通常の商品」「売り切れ」「商品名が長い場合」をそれぞれ表示します。毎回アプリ側のデータや画面遷移を操作して、その状態へたどり着く手間を避けられます。

ただし、Storybookで表示できるのは、用意した部品と条件の範囲です。部品の一覧を作っただけで、すべての不具合を検出できるわけではありません。

Figma・Storybook・本番サイトの役割の違い

次の表は、確認作業を分担するための整理です。Figmaでもプロトタイプを作れますが、実装コードで動く部品の確認とは区別すると、レビューで話がかみ合いやすくなります。

公式のデザイン連携ガイドには、FigmaをStorybookへ埋め込む方法と、StorybookのStoryをFigmaへ関連付ける方法があります。後者のStorybook Connectは、Chromaticで公開したStorybookを前提とします。「FigmaのURLを貼れば自動で実装と同期される」とは考えず、使う連携方式の条件を確認してください。

最初から連携を組み込まず、Figmaの対象部品とStoryのURLをレビュー記録に並べる方法でも始められます。

Storyとは「ある条件で表示したUI」のこと

Storyの公式ガイドでは、StoryはUIコンポーネントの描画状態を記録するものと説明されています。Reactのpropsなど、部品に渡す入力をStorybookではargsと呼びます。

たとえば「申し込む」というボタンの文字や、押せる・押せない状態を変えた例を残します。Storyは単なる画像ではなく、実装した部品を表示します。

Controlsを使うと、argsの値をパネルから変更して、その場で表示を確かめられます。毎回コードを書き換えなくても、文字列や選択肢を変えながら確認できます。変更をチームで再現したい場合は、必要な状態をStoryとして保存しておくことが大切です。

最初に残す状態を決める

すべての部品を一度に登録するよりも、変更頻度が高い部品を一つ選び、判断が変わる状態を残す進め方を提案します。以下は、架空の申し込み画面を題材にした例です。

「送信中」を見せるStoryを作っても、実際に二重送信が防げることまで保証しません。必要な操作テストと、アプリ側の処理確認も別に行います。

導入の始め方：既存プロジェクトで小さく試す

この記事は概念と導入の流れを説明するもので、特定の構成で動作検証したハンズオンではありません。実際の対応フレームワークとバージョンは、公式インストールガイドで確認してください。

1. 依存関係と作業前の差分を確認する

既存のフロントエンドプロジェクトで、未保存・未コミットの変更を整理します。公式資料の確認時点ではNode.js 20以上、npm 10以上などの要件が案内されています。使用するフレームワーク固有の条件も確認しましょう。

2. プロジェクトのルートで初期化する

npmを使う場合、公式に案内されているコマンドは次のとおりです。

npm create storybook@latest

CLIはプロジェクトの依存関係を調べて設定します。質問に答えた後は、追加された設定や依存関係、package.jsonのscriptsを確認してください。既存のビルドやテストも実行し、影響がないかを見ます。

3. 一つの部品にStoryを用意する

生成された例を参考に、自分たちの部品とStoryファイルを対応させます。公式ガイドでは、部品の近くに Button.stories.ts などを置く構成が示されています。具体的なimport先や設定は、選んだフレームワークに合わせます。

最初の目標は「対象の部品を表示できる」「通常と例外の状態を切り替えられる」「別の担当者も同じ状態を開ける」の三つで十分です。

4. 見た目をそろえてから、共有用にビルドする

アプリ側の共通CSS、テーマ、フォント、必要なデータの代替を整えます。本番と前提が違うと、Storybookだけで見た目が合っても、その結果をそのまま本番へ当てはめられません。

共有用の静的ビルドは、標準のscriptがある構成なら次のコマンドです。

npm run build-storybook

公式の公開ガイドでは、静的なWebアプリとして書き出してホスティングする方法を説明しています。実際のscript名と出力先はプロジェクトの設定を確認してください。共有前には、サンプルに機密情報がないか、誰が閲覧できる必要があるかも点検します。

チームレビューでは「部品・状態・期待」をそろえる

「ボタンが少し変」とだけ伝えると、同じ表示を再現するところから作業が始まります。次のように、対象を具体化して記録するのがおすすめです。

• 対象：申し込みフォームの送信ボタン
• 状態：送信中、スマホ幅、文字が長い場合
• 期待：処理中と分かり、文言が欠けず、操作の扱いが明確
• 記録：対象StoryのURL、比較するデザイン、修正担当者

AIにUIの初稿や修正案を作らせる場合も、「きれいなフォームを作る」という依頼に、この状態と期待を添えると、確認する対象を具体化できます。これは作業整理の提案であり、生成品質や修正回数の改善を検証した主張ではありません。公開前の全体確認には、AIで作ったLPのチェックリストも使えます。

テストとアクセシビリティで気をつけたいこと

Storyを残すことと、自動テストを実行することは別の作業です。公式のテストガイドには操作、見た目、アクセシビリティなどのテストが整理されています。利用できる連携と設定は、ビルダーやフレームワークによって確認が必要です。

Accessibilityアドオンは、描画されたDOMの問題を自動で点検するための仕組みです。ただし、自動検査の合格だけでサイト全体のアクセシビリティを保証できません。キーボード操作や実際の画面の流れも確認します。

部品内で成功していても、画面に組み込むと余白、読み込み順、フォーカス移動などの問題が起こり得ます。最後はアプリ全体で操作してください。

よくある質問

Storybookは無料で使える？

Storybook本体は無料のオープンソースです。外部のホスティングやテストサービスを組み合わせる場合は、そのサービスの料金や利用条件を別に確認してください。本記事では有料サービスのプラン比較は扱いません。

デザイナーだけでも使える？

公開されたStorybookの閲覧やレビューには、ローカルの開発環境が不要な構成を取れます。一方、導入やStoryの実装・更新にはコードの作業が必要です。誰が状態を追加し、誰が確認するかを決めておきましょう。

小さなサイトにも必須？

必須ではありません。同じ部品を繰り返し使う、例外の状態を再現しにくい、複数人で確認するといった課題があるかで判断します。一度きりの単純なページなら、維持する手間と得られる確認の価値を比べてください。

まずは一つの部品を共通の確認場所にする

導入前に、よく修正する部品と、見落とすと困る状態を一つずつ書き出してみてください。その部品をStorybookで再現し、デザインと実装を同じ条件で話せるかを試すと、継続する判断がしやすくなります。

制作全体の工数も整理したい場合は、AI内製化の費用と品質を比べる進め方を参照してください。発信元のDEZAINAZはデザイン・Web制作を提供しています。本記事はStorybookやChromaticとの提携を示すものではありません。