Storybook 10 の歩き方 - コンポーネントカタログからテスト基盤へ、Figma 連携まで
読みやすいコードの原則。全エンジニアの基礎。
通称「徳丸本」。Webセキュリティの定番教科書。
打鍵感で選ぶ定番キーボード。長時間の実装に。
当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。
Storybook といえば「コンポーネントを1つずつ確認するカタログ」という印象が強いかもしれません。でも、いまの Storybook（バージョン10系）は、その枠をかなり超えています。テスト基盤であり、ドキュメントであり、デザインとコードの接点でもある——という位置づけに広がりました。
この記事では、Storybook 10 の現在地を「カタログから何になったか」という視点で整理し、あわせてFigma 連携（デザインとの往復）を実務の導入目線でまとめます。
Storybook とは何か（おさらい）
Storybook は公式の言葉で言えば「UI コンポーネントやページを分離して作るためのフロントエンドの作業場（frontend workshop）」です。アプリ全体を起動しなくても、コンポーネントの「届きにくい状態」やエッジケースを単体で開発・共有できます。
1つのコンポーネントの各状態を「ストーリー」として書き、それを一覧・操作しながら開発する——これが基本です。ここまでは従来どおり。変わったのは、そのストーリーが起点になって、テストとドキュメントとデザイン連携まで広がったことです。
カタログからテスト基盤へ
Storybook 10 が「カタログ」を超えた最大の点が、テストです。ストーリー（＝コンポーネントのある状態）は、そのままテストの入力になります。
- インタラクションテスト: ストーリー内でクリック・入力などの操作を記述し、その結果を検証する
- アクセシビリティテスト: コンポーネント単位で a11y の問題を検出する
- ビジュアルテスト: 見た目の差分を検出する（Chromatic 連携）
- スナップショットテスト: レンダリング結果の差分を取る
ポイントは、「書いたストーリーがそのままテストケースになる」こと。状態を確認するために書いた成果物が、そのままリグレッション検知に効きます。コンポーネントテストは Vitest を土台にする方向で進んでおり、モダンテストフレームワーク（Vitest / Playwright）で書いた「コンポーネント〜E2E のテスト戦略」の中に、Storybook が自然に収まります。
NOTE
「Storybook はカタログだから小規模には過剰」という見方は、テスト基盤として捉え直すと変わります。状態の確認・a11y・ビジュアル差分・ドキュメントを1つの成果物（ストーリー）から賄えるなら、導入コストの見え方が違ってきます。
ドキュメントも自動で
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を起こすとも地続きです。
WARNING
Figma 連携は「デザインからボタン1つでコードが完成する」魔法ではありません。addon-designs はデザインと実装を並べて見せるもの、Code Connect は対応関係を宣言するもので、最終的な実装判断は人間が行います。読み替えるべき差分（状態・余白・トークン）を人が詰める前提で使ってください。デザインツールの過信は禁物です（Pencil のような AI デザインツールを使う場合も同様）。
小規模チームでの導入ライン
「入れる価値があるか」は規模で変わります。現実的な判断はこうです。
| 状況 | 判断 |
|---|---|
| コンポーネントを複数人で共有・再利用する | 効果大。カタログ＋テスト＋ドキュメントを一括で得られる |
| デザイナーと実装者が分かれている | Figma 連携の効果が大きい。ズレと往復が減る |
| 個人・ごく小規模で UI も単純 | 過剰になりがち。まずはテスト（Vitest）だけで十分なことも |
| デザインシステムを育てたい | ほぼ必須。トークン・状態・ドキュメントの中心に置ける |
まとめ
- Storybook 10 は「コンポーネントカタログ」からテスト基盤・ドキュメント・デザイン連携へ役割が広がった
- 書いたストーリーがそのままテストになる（インタラクション・a11y・ビジュアル・スナップショット）。Vitest 連携で既存のテスト戦略に収まる
- Autodocs でドキュメントを自動生成でき、実装との乖離を防げる
- Figma 連携は3方向:
addon-designs（Storybook に Figma を埋め込む）、Storybook Connect（Figma に Storybook を埋め込む）、Code Connect（Figma 部品をコードに対応づける） - ただしデザイン連携は「自動でコード完成」ではなく、差分は人が詰める前提
- 導入価値は規模次第。複数人での共有・デザインシステム・デザイナーとの分業がある現場ほど効く
Storybook を「コンポーネントを眺める場所」だと思っていると、いまの姿を見落とします。ストーリーを1つ書けば、確認・テスト・ドキュメント・デザイン照合までつながる——この一気通貫こそが、2026年の Storybook の価値です。
