Storybook 10 の歩き方 - コンポーネントカタログからテスト基盤へ、Figma 連携まで

Storybook といえば「コンポーネントを1つずつ確認するカタログ」という印象が強いかもしれません。でも、いまの Storybook（バージョン10系）は、その枠をかなり超えています。テスト基盤であり、ドキュメントであり、デザインとコードの接点でもある——という位置づけに広がりました。

この記事では、Storybook 10 の現在地を「カタログから何になったか」という視点で整理し、あわせてFigma 連携（デザインとの往復）を実務の導入目線でまとめます。

Storybook とは何か（おさらい）

Storybook は公式の言葉で言えば「UI コンポーネントやページを分離して作るためのフロントエンドの作業場（frontend workshop）」です。アプリ全体を起動しなくても、コンポーネントの「届きにくい状態」やエッジケースを単体で開発・共有できます。

1つのコンポーネントの各状態を「ストーリー」として書き、それを一覧・操作しながら開発する——これが基本です。ここまでは従来どおり。変わったのは、そのストーリーが起点になって、テストとドキュメントとデザイン連携まで広がったことです。

カタログからテスト基盤へ

Storybook 10 が「カタログ」を超えた最大の点が、テストです。ストーリー（＝コンポーネントのある状態）は、そのままテストの入力になります。

• インタラクションテスト: ストーリー内でクリック・入力などの操作を記述し、その結果を検証する
• アクセシビリティテスト: コンポーネント単位で a11y の問題を検出する
• ビジュアルテスト: 見た目の差分を検出する（Chromatic 連携）
• スナップショットテスト: レンダリング結果の差分を取る

ポイントは、「書いたストーリーがそのままテストケースになる」こと。状態を確認するために書いた成果物が、そのままリグレッション検知に効きます。コンポーネントテストは Vitest を土台にする方向で進んでおり、モダンテストフレームワーク（Vitest / Playwright）で書いた「コンポーネント〜E2E のテスト戦略」の中に、Storybook が自然に収まります。

ドキュメントも自動で

Storybook は Autodocs で、コンポーネントを解析してストーリーの隣にドキュメントを自動生成できます。props の型や各状態が、書いたストーリーから自動でまとまる。「ドキュメントを別途書く」負担が減り、実装とドキュメントの乖離が起きにくくなります。

Figma 連携: デザインとの往復

ここからが、今回あわせて扱いたいFigma 連携です。Storybook は「コードで作ったコンポーネント」、Figma は「デザインの正」。この2つを行き来できると、実装とデザインのズレが激減します。連携には方向の違う複数の道があります。

1. Storybook 側に Figma を埋め込む（addon-designs）

@storybook/addon-designs を使うと、ストーリーのパネルに対応する Figma デザインを並べて表示できます。設定はストーリーの parameters.design に書くだけです。

export const MyButton = {
  parameters: {
    design: {
      type: 'figma',
      url: 'https://www.figma.com/file/xxxxxxxx/Design-File',
    },
  },
};

これで、実装したコンポーネントの隣にデザインの正が表示されます。レビュー時に「Figma だとどうだっけ」と往復する手間が消えます。

2. Figma 側に Storybook を埋め込む（Storybook Connect）

逆方向の連携が Storybook Connect（Figma プラグイン）です。公開した Storybook のストーリーを Figma のフレームに紐づけ、デザイナーが Figma の中で実物のコンポーネントを確認できます。デザイン側からも「これは実装でこう動く」が見える状態になります。

3. Figma コンポーネントをコードに対応づける（Code Connect）

Figma の Code Connect は、Figma 上のコンポーネントを実コードのコンポーネントに対応づける仕組みです。デザインから実装へ渡すときに「この Figma 部品はこの React コンポーネント」と機械可読に結びつけられます。AIによるデザインからの実装でも効く考え方で、Figma MCP でデザインからHTMLを起こすとも地続きです。

小規模チームでの導入ライン

「入れる価値があるか」は規模で変わります。現実的な判断はこうです。

まとめ

• Storybook 10 は「コンポーネントカタログ」からテスト基盤・ドキュメント・デザイン連携へ役割が広がった
• 書いたストーリーがそのままテストになる（インタラクション・a11y・ビジュアル・スナップショット）。Vitest 連携で既存のテスト戦略に収まる
• Autodocs でドキュメントを自動生成でき、実装との乖離を防げる
• Figma 連携は3方向: addon-designs（Storybook に Figma を埋め込む）、Storybook Connect（Figma に Storybook を埋め込む）、Code Connect（Figma 部品をコードに対応づける）
• ただしデザイン連携は「自動でコード完成」ではなく、差分は人が詰める前提
• 導入価値は規模次第。複数人での共有・デザインシステム・デザイナーとの分業がある現場ほど効く

Storybook を「コンポーネントを眺める場所」だと思っていると、いまの姿を見落とします。ストーリーを1つ書けば、確認・テスト・ドキュメント・デザイン照合までつながる——この一気通貫こそが、2026年の Storybook の価値です。

参考リンク

• Storybook 公式ドキュメント
• @storybook/addon-designs
• Vitest 4 のブラウザモード（当ブログ）
• モダンテストフレームワーク Vitest / Playwright（当ブログ）
• Figma MCP でデザインからHTMLを起こす（当ブログ）