Storybook 10.3（2026年3月24日リリース）で、React プロジェクト向けに MCP（Model Context Protocol）サーバー が公式アドオンとして追加された。AIエージェント（Claude Code、Cursor など）がStorybookのコンポーネント情報を直接参照し、UIの生成・プレビュー・テスト・修正までを一貫して行えるようになる。
個人開発者にとって、これはデザインシステムの「規約を守らせる」問題への実用的な解答になり得る。
なぜ Storybook MCP が必要なのか
AIエージェントにUIを作らせると、既存のコンポーネントライブラリを無視して新しいパターンを勝手に発明する——という経験は多くの開発者にあるだろう。ボタンのバリエーションが5種類もできたり、デザイントークンを完全に無視したスタイルが生成されたりする。
この問題は「エージェントがコンポーネントの存在と使い方を知らない」ことに起因している。Storybook MCP はこのギャップを埋めるために設計された。
3つの柱
1. コンポーネント情報の提供（知る）
MCPサーバーはエージェントに以下の情報を提供する：
- Storyのメタデータ
- コンポーネントのAPI定義（Props）
- ドキュメント
これにより、エージェントは「既にあるコンポーネントを再利用する」行動を取るようになる。Reshaped コンポーネントライブラリでのベンチマークでは、MCP未使用時と比べて より高速・少トークンでUI生成 が可能という結果が出ている。
また、Storybook Composition との連携により、アプリとデザインシステムを別々のStorybookで管理していても、複数のStorybookをまたいだコンポーネント参照ができる。エージェントは1つのMCPエンドポイントから全てのコンポーネント情報を取得できる。
2. ライブプレビュー（確認する）
エージェントがUIを生成した後、チャットUI内に ライブストーリーを直接埋め込み表示 できる（MCP Apps経由）。ホバー状態などのインタラクションもそのまま確認可能で、別ウィンドウに切り替える必要がない。
これは MCP Apps（2025年11月に発表されたMCPの拡張仕様）を活用した機能だ。ストーリーのライブプレビューに加えて、詳細確認用のリンクも提供される。
3. テスト実行＋自動修正（直す→再確認）
MCPサーバーにはコンポーネントテストとアクセシビリティテストを実行するツールが含まれている。エージェントはテストを自ら実行し、結果はStorybookのUIにリアルタイムでストリームされる。
エラーがあればエージェントが自分で修正を試み、人間の判断が必要なケースだけアラートを出す。この セルフヒーリング（自己修復）テストループ が、MCP独自の価値だ。
Skills との違い
Storybookチームは「Skills（タスク手順テンプレート）とMCPの両方に投資している」と明言している。
| Skills | MCP | |
|---|---|---|
| 役割 | タスクの手順をエージェントに教える | エージェントとの双方向通信 |
| テストループ | 手順に含められるが自己修復は難しい | セルフヒーリングテストが可能 |
| 使い分け | 定型作業の標準化 | 動的なフィードバックループ |
両者は競合ではなく補完関係にある。Skillsで「どう作るか」を教え、MCPで「作ったものが正しいか検証・修正する」サイクルを回す。
Chromatic によるリモートMCP公開
Chromatic（Storybookの商用サービス）を使えば、Storybook MCP サーバーをリモートに公開できる。チームメイトがローカルでStorybookを起動していなくても、公開されたMCPエンドポイントからコンポーネント情報を参照できる。
この機能は無料で利用可能で、品質チェック、バージョニング、セキュア認可が組み込まれている。
導入方法
# Storybook 10.3+にアップグレード
npx storybook@latest upgrade
# アドオンをインストール・登録
npx storybook add @storybook/addon-mcp
# MCPサーバーをクライアントに追加
npx mcp-add --type http --url "http://localhost:6006/mcp" --scope project
現時点では React のみ 対応。他フレームワークは2026年後半に対応予定。
MCPの効果を最大化するベストプラクティス
Storybook公式ドキュメントでは、MCP と組み合わせて使う際のベストプラクティスが公開されている。MCPサーバーはStoryから生成される マニフェスト を通じてエージェントにコンポーネント情報を渡す仕組みのため、Storyの書き方次第でエージェントの精度が大きく変わる。
Storyの書き方が精度を決める
MCPサーバーはStoryを参照してコンポーネントの使い方を理解する。そのため、1つのStoryは1つの概念・ユースケースを示す のが基本だ。さらに重要なのは、「何を」ではなく 「なぜ」そのStoryが存在するのか をdescriptionに書くこと。エージェントはStoryの説明文を読んで「このコンポーネントをいつ使うべきか」を判断する。
なお、args やデコレーターなどのStorybook固有の抽象化は、マニフェスト生成時に最終的なレンダリング結果として評価される。エージェントは実装の詳細ではなく、表示結果としてのコンポーネントを理解できる。
JSDoc コメントでコンポーネントの「辞書」を作る
エージェントがコンポーネントを正しく使えるかは、ドキュメントの質に直結する。公式が推奨するのは JSDoc コメント による3層のドキュメント化だ：
| レベル | 書く場所 | エージェントへの効果 |
|---|---|---|
| コンポーネントの説明 | コンポーネントの export 上に JSDoc | 「何のためのコンポーネントか」を理解 |
| Storyの説明 | 各Storyの description / summary | 「どんな場面で使うか」を理解 |
| Propsの説明 | Props の各フィールドに JSDoc | 「どう設定するか」を理解 |
react-docgen-typescript を使うとProps情報がより正確に抽出される（速度重視なら react-docgen も選択可能）。
マニフェストの「ノイズ除去」も重要
情報が多すぎるとエージェントのパフォーマンスが下がる。非推奨パターンのStoryやレガシーなドキュメントなど、エージェントに参照させたくないものは manifest タグを外すことで除外できる。適切な量のコンテキストを渡す ことが、MCPの効果を最大化する鍵だ。
個人開発者にとっての意味
デザインシステムの維持は、チーム開発だけの課題ではない。個人開発でも、プロジェクトが大きくなるにつれてコンポーネントの一貫性を保つのは難しくなる。
Storybook MCP の本質的な価値は、「エージェントにルールを守らせる仕組み」 が開発ツールチェインに組み込まれたことだ。MCPという標準プロトコルを通じて、StorybookがAIエージェントの「コンポーネント辞書」として機能する。
特に注目すべきは「知る → 作る → 確認する → 直す → 再確認」のフィードバックループが、人間の介入なしに回る点だ。個々のツールは単純でも、MCPで接続することで開発サイクル全体が自動化される。
ソース:
- Storybook MCP for React（公式ブログ）
- Best practices for using Storybook with AI（公式ドキュメント）
- MCP Apps 仕様
- Storybook MCP ドキュメント