LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Storybookとは何か — コンポーネント単位の開発環境

Storybookとは、UIコンポーネントをアプリケーション全体から切り離し、個別に開発・確認するためのツールである^*1。公式ドキュメントでは「アプリケーションと並行して機能する小さな開発専用のワークショップ」と説明されており^*1、コンポーネントを分離されたiframe内でレンダリングできる点が中核となる。

フロントエンド開発では、1つのボタンや入力フォームの見た目を確認するためだけに、ログイン画面や一覧画面などアプリ全体を起動しなければならない場面が少なくない。Storybookを導入すると、対象のコンポーネントだけを個別に起動して確認できるため、ビジネスロジックや画面遷移の影響を受けずに開発を進められる^*1。

コンポーネントの見た目や振る舞いのバリエーションは「ストーリー」として保存され、UIの状態を宣言的に記録できる^*1。このストーリーは開発・テスト・ドキュメント作成という複数の用途で再利用でき、公式では「チーム内でUIを再利用するための単一の情報源」になり得ると位置づけている^*1。デザイナー・開発者・QA担当者が同じ画面を見ながら仕様をすり合わせる、共通の見本帳としての役割を果たす。

なぜ必要か — アプリ全体を起動しない開発の利点

Storybookを使う一次的な利点は、コンポーネントをアプリケーションのビジネスロジックや文脈から切り離してレンダリングできることである^*1。これにより、開発者は各コンポーネントのバリエーション（正常時・エラー時・読み込み中など）の実装に集中できる^*1。

複数人でUIを開発するプロジェクトでは、あるコンポーネントの状態網羅が不十分だと、特定条件でのみ発生する表示崩れが見過ごされやすい。ボタンの押下不可状態やフォームのバリデーションエラー表示など、通常の操作フローでは再現しにくい状態を、Storybook上でストーリーとして個別に呼び出して確認できる点は、品質確認の抜け漏れを減らす効果につながる。

公式ドキュメントは、Storybookの導入によって「より耐久性のあるUI開発」「より少ない労力でのテスト」を実現できるとしている^*1。ここでいう耐久性とは、コンポーネントの変更が他画面に予期せぬ影響を与えにくくなることを指し、テスト工数の軽減とは、個別のコンポーネント単位で検証を完結できることを意味する。

ストーリーという考え方 — コンポーネントの状態を定義する

ストーリーとは、UIコンポーネントのレンダリングされた状態をキャプチャしたものである^*2。公式ドキュメントでは「コンポーネントの振る舞いと見た目を、一連の引数（args）とともに記述したアノテーション付きのオブジェクト」と定義されている^*2。

状態の定義には「args」という汎用的な仕組みを使う。argsはReactのprops、Vueのprops、AngularのInputプロパティなどに相当する概念で^*2、フレームワークが異なってもストーリーの書き方を統一できる。例えばボタンコンポーネントであれば、「主要ボタン（Primary）」というストーリーに対して、ラベル文言や強調表示の有無をargsとして渡す形で状態を定義する^*2。

この仕組みにより、開発者はコンポーネントの取り得る状態を1つずつストーリーとして書き出し、Storybookの管理画面（Controlsパネル）上でargsの値を動的に変更しながら見た目の変化を確認できる^*2。正常系だけでなく、空データ・エラー・長文入力など境界となる状態を意図的にストーリー化しておくことが、後述するテストやレビューの土台になる。

アドオンで広がる用途 — アクセシビリティ・テスト・ドキュメント

Storybookはストーリーを核として、アドオンと呼ばれる拡張機能を組み合わせることで用途を広げる設計になっている。代表的な用途は、アクセシビリティ検証・操作テスト・ドキュメント自動生成の3つである。

アクセシビリティ検証

StorybookのアクセシビリティアドオンはDequeのaxe-coreライブラリを基盤としており、WCAG（Web Content Accessibility Guidelines）2.0および2.1のLevel A・AAルールと、業界標準のベストプラクティスに基づいてレンダリング結果を自動監査する^*3。公式によれば、この自動検査でWCAG課題の57%程度まで検出できるとされている^*3。検査結果は「違反」「合格」「手動確認が必要な項目」の3種類に分類され、キーボード操作や色コントラストといった観点を早期に洗い出せる^*3。ただし自動検査だけで全てのアクセシビリティ課題を検出できるわけではなく、手動確認が必要な項目が残ることには留意が必要である。

操作テスト・回帰確認

test-runnerと呼ばれる仕組みは、記述済みのストーリーをそのまま実行可能なテストに変換する^*4。play関数を持たないストーリーはエラーなく描画されるかを確認し、play関数を持つストーリーはその内部の操作とアサーションがすべて成功するかを検証する^*4。CI（継続的インテグレーション）環境では、デプロイ済みのStorybookに対してURLを指定して実行する方法と、ローカルでビルドしたStorybookをサーバー起動しながらテストする方法の2種類が案内されている^*4。

ドキュメント自動生成

Autodocsと呼ばれる機能は、ストーリーに付随するargs・argTypes・parametersといったメタデータから、コンポーネントの説明・引数一覧・操作可能なコントロール表を含むドキュメントページを自動生成する^*5。設定ファイルでタグを指定するだけで有効化でき、個別コンポーネント単位での適用や特定ストーリーの除外も可能である^*5。ドキュメントとコンポーネントの実装が同じストーリーを起点にしているため、実装を変更すればドキュメントの表示内容も追随する。

デザインシステム・Web Componentsとの関係

Storybookは、コンポーネントの設計思想そのものを決めるツールではなく、既に定義されたコンポーネント群を開発・検証・共有するための運用ツールという位置づけである。デザインシステムの構築（トークン設計やコンポーネント設計方針の策定）や、Web Components（ブラウザ標準のCustom Elements・Shadow DOM等によるUI部品化技術）の実装そのものとは役割が異なり、それらの成果物をStorybook上でストーリーとして可視化し、チームで確認・合意形成する土台として機能する。

公式ドキュメントでも、Storybookはデザインツールとの連携を想定した拡張性を持つとされている。例えばFigmaとの連携では、Chromatic（Storybookの公開・レビュー用サービス）上に公開したStorybookをFigma内に埋め込む方法と、逆にFigmaのファイルやプロトタイプをStorybook側に埋め込む「Designs」アドオンの両方が用意されている^*6。ZeroheightやInVision DSMのようなデザインシステム文書化ツールも、ストーリーを設計仕様と並べて埋め込む連携をサポートしている^*6。

技術面では、Storybookは特定のUIフレームワークに縛られない設計になっており、Web Componentsを用いたプロジェクト向けの専用フレームワーク統合（Web Components & Vite等）が提供されている^*7。フレームワークを問わずコンポーネントを分離して開発・テストするという仕組みは共通しており、Web Componentsで実装したUI部品もStorybook上で同様にカタログ化できる。

導入の論点 — 保守コスト・CI連携・陳腐化させない運用

Storybookの導入自体は、公式のセットアップコマンドを実行すれば短時間で完了する。実務上の論点は、導入後にストーリー群を実装と同期させ続けられるかという保守運用の側面にある。

第一に、ストーリーの保守コストである。コンポーネントの仕様変更のたびにストーリーとargsの定義を更新しないと、Storybook上の表示と実際のアプリケーションの挙動がずれていく。ストーリーを「実装の一部」として扱い、コンポーネントの変更と同一のプルリクエストで更新する運用ルールを設けないと、ストーリーが古い状態のまま放置されやすい。

第二に、CI連携の設計である。test-runnerをCIパイプラインに組み込むには、Storybookのビルド・起動・テスト実行という一連の処理をどのタイミングで走らせるかを設計する必要がある^*4。プルリクエストごとに全ストーリーを検証する構成にすると、コンポーネント数の増加に伴ってCIの実行時間が伸びる点も考慮しなければならない。

第三に、アドオン構成の陳腐化である。アクセシビリティ検証・ビジュアル確認・ドキュメント生成などアドオンを増やすほど機能は充実するが、Storybook本体やフレームワーク統合のバージョンアップに伴い、アドオンの互換性確認や設定の見直しが定期的に発生する。導入して終わりにせず、継続的に手を入れる前提で体制を組む必要がある。

外注する場合の委託範囲と発注準備

Storybookの導入を外部に委託する場合、依頼側があらかじめ委託範囲を整理しておくと、見積もりと成果物のすり合わせがしやすくなる。委託範囲は大きく分けて、初期構築・ストーリー移行・アドオン設定・CI連携・継続保守の5つに分解できる。

内製でこの範囲をすべて担う場合、フロントエンドの実装知識に加えて、CIパイプラインの構成やアクセシビリティ基準（WCAG）の理解が必要になる。特にストーリー移行は、既存コンポーネントの仕様書が整備されていないプロジェクトほど、状態の洗い出し自体に工数がかかりやすい作業である。専門的な知見を持つ外部パートナーに委託した場合は、フレームワークごとの統合方法やアドオン構成の知見を踏まえた設計を、自社で試行錯誤する期間を経ずに導入できる点が内製との違いになる。

発注準備としては、対象とするコンポーネントの一覧、フロントエンドフレームワークとバージョン、既存のCI環境、アクセシビリティ対応の目標水準を事前に整理しておくと、外注先とのすり合わせが円滑になる。ストーリーの保守を発注後も自社で続けるのか、継続的な保守委託とするのかも、契約範囲を決める段階で明確にしておく必要がある。

まとめ — Storybook導入を外注で進める3つの判断軸

本稿では、Storybookがコンポーネントを個別に開発・確認するための環境であること、ストーリーという単位で状態を定義しアドオンで用途を広げること、そして外注する際の委託範囲について整理した。要点は3つに集約できる。第一に、Storybookはデザインシステムやコンポーネント実装そのものを決めるのではなく、それらを運用・共有するためのツールである。第二に、ストーリーはargsによって状態を定義し、アクセシビリティ検証・テスト・ドキュメント生成という複数のアドオン用途の起点になる。第三に、導入後の保守コストとCI連携の設計をどう担うかが、外注範囲を決める判断軸になる。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Storybook「Why Storybook」（storybook.js.org、https://storybook.js.org/docs/get-started/why-storybook）
2. *2　出典：Storybook「Stories」（storybook.js.org、https://storybook.js.org/docs/writing-stories）
3. *3　出典：Storybook「Accessibility testing」（storybook.js.org、https://storybook.js.org/docs/writing-tests/accessibility-testing）
4. *4　出典：Storybook「Test runner」（storybook.js.org、https://storybook.js.org/docs/writing-tests/integrations/test-runner）
5. *5　出典：Storybook「Automatic documentation」（storybook.js.org、https://storybook.js.org/docs/writing-docs/autodocs）
6. *6　出典：Storybook「Design integrations」（storybook.js.org、https://storybook.js.org/docs/sharing/design-integrations）
7. *7　出典：Storybook「Storybook for Web Components & Vite」（storybook.js.org、https://storybook.js.org/docs/get-started/frameworks/web-components-vite）

Tweet