AIを使えばデザイナーでもStorybookを作れるのかを検証する

こんにちは、UIデザイナーの小高です。以前の「デザイナーからのテック相談」に続き、今回もエンジニアのSさんと、プロマネのKさんを交えた座談会形式の第2弾になります。

テーマは「AIを使えばデザイナーでもStorybookを作れるのか」。実際に検証してみた結果と、デモを見てもらいながら3人で議論してみました。
※2026年5月時点での検討になります。

プロフィール

デザイナー 小： UIデザイナー。デザインの表層分野を得意としていますが、骨格・構造・UXリサーチなど広い範囲でのデザインを担えるよう取り組んでいます。最近はデザインプロセスにAIを取り入れられるか日々模索中です。HTML / CSS / JavaScript等の基本的なコーディングスキルを元々持っています。

エンジニア S： エンジニアからPMのポジションにシフトしたPM。アシアルに入社して、3年目くらいに大きな案件のプロジェクトリーダー（PL）を経験した後に本格的にPMをすることになった。今も現場でPMを担当しつつ、会社課題への取り組みや課題チームのビルディングなどもしています。

プロマネ K： デザイナー出身のPM。アシアルに入社して、２年目くらいからPMや営業の仕事もするようになり、最近はほぼほぼPMとして動いていて、たまに自分のプロジェクトでデザインワークをすることもあります。デザインチームのリーダーっぽいこともしています。

• Storybookとは、Reactなどのフレームワークで作ったコンポーネントをブラウザで手軽に確認できるUIカタログのこと。大規模なプロダクトで作られることも多いが、技術的にデザイナーが関わるには難易度が高く、デザイン検証・フィードバックなどコミュニケーションコストをかけながらエンジニアと協力して完成に近づけていくのが現状。
• そんな中、Kさんの「AIを使えばデザイナーでもStorybookが作れるんじゃないか」という一言がこの検証のきっかけ。AIを使ってデザイナーが直接関われる可能性があれば、コミュニケーションコストは下がり、より完成度の高いプロダクトが作れるのではないかと検証してみることにしました。

デザイナー 小： Kさんは、デザイナーでありながらプロジェクトマネージャーとしても動かれていて、テック領域にも明るく、Storybookのスタイル調整などエンジニアとの協業も経験されています。普通のデザイナーだと修正などはエンジニアにお願いするところも、ご自身でCSSを直接修正することもありますよね。Kさんが「デザイナーもStorybookを作れるのでは」と考えた背景には、どんな課題感があったんでしょうか？

プロマネ K： 特定の課題というより、自分がやれることはデザイナー全員がやれた方がいいし、プロジェクトにとっても一番効率的という思いがベースです。AIが入ることで、それが実現できるんじゃないかと。デザイナーが完全な状態まで仕上げて提供できれば、スピードもクオリティも圧倒的に上がります。自分がプロジェクトを進める時に、エンジニアにはスタイルは適当でいいからコンポーネントの土台だけどんどん作ってと依頼します。後の仕上げはデザイナーがやりますという状態を作ります。

デザイナー 小： なるほどです。それが可能なら、開発スピードとアウトプットのクオリティの向上が見込めます！Sさんは、エンジニア側からデザイナーとのStorybookなど開発フェーズでのやり取りで、課題を感じることはありますか？

エンジニア S： Storybookのスタイル調整はなるべくデザイナー自身にやってもらいたいというのが本音です。エンジニアはロジックに集中したい。ただ現状はどうしてもエンジニアが対応せざるを得ない場面も多くて、そこがもどかしいと感じることはあります。

デザイナー 小： デザイナー自身が開発時のスタイル調整をできる。それぞれが本来の役割に集中できる環境になるイメージでしょうか。

エンジニア S： デザイナーが仕上がりまで責任を持てて、お互いの得意なところに専念できる状態が作れそうですよね。

方向性A：デザイナーがコードを学んでAIと一緒に書く

• AIにサポートしてもらいコードを理解しながら作る
• 最低限のReactなどのフレームワーク・JavaScriptの知識が必要
• 「デザイナーがAIで学び、コードを書けるようになる」アプローチ

方向性B：デザイナーはデザインだけ、コードはAIに任せる（Vibe Coding的）

• AIに自然言語で指示するだけ
• コードを書かなくていい
• 「デザイナーがAIを使い、開発フェーズに携わる」アプローチ

デザイナー 小： アシアルのデザインチームはコーディングスキルを持つメンバーが揃っていますが、StorybookとなるとReactなどのフレームワーク、Git、開発環境の知識が必要でデザイナーにとってハードルが高かった。AとBのどちらをイメージしていましたか？

エンジニア S： 僕は「両方」必要だと思います。最初は自分自身で仕組みを理解するためにAのステップが必要で、技術的な中身を理解した上でないと、いきなりBだけをやっても何が起きているか分からなくなってしまう。AがあってこそのBだと思います。

デザイナー 小： 同感です。Aの前提知識がないと、指示自体がうまく組み立てられないんじゃないかと思っていました。そもそもBで何をどう進めればよいか、イメージすら湧かなかったかもです。

プロマネ K： Storybookをゼロから完全に構築するのであればAからBへというステップになると思います。ただ、すでに土台があってデザイン部分の調整だけに関して言えば、最初からBだけでもいけるんじゃないかという気もしています。Pull Requestの形でエンジニアに投げて、実務に影響がないかを最終確認してもらう座組みにすれば、Bだけでも回るかもしれません。

方向性Aを試した結果：布石にはなったが、タイパは悪い

書籍とUdemyでReact / Storybookを学びながら、AIをメンター代わりにスピード重視で進めてみました。結果は、後半は写経になってしまい「できる」状態のクオリティを保てなくなったというのが正直なところ。ただ、Storybookがどう作られているかという概要をつかめたことは収穫でした。

方向性Bで指示の精度を上げるための前提知識を得るという意味では有効だったため、方向性Bへの布石として必要なフェーズと判断し、次に進みます。

方向性B：Figma ⇔ Claude Code ⇔ Storybook

ここからがデモの本題です。FigmaとClaude CodeをMCPで連携し、FigmaのURLを渡すだけでReactコンポーネントとStorybookのStoryファイルを自動生成する流れを検証しました。

MCPとは？

AIツールが外部サービスとやり取りするための仕組み。FigmaがMCPサーバーを公式提供しており、Claude Codeと連携できる。

MCP（リモート版） セットアップ手順：

1. Claude CodeにFigma MCPプラグインをインストール

   claude plugin install figma@claude-plugins-official

2. Claude Codeを再起動
3. /mcpからFigmaを選択してブラウザ認証する

検証手順

• STEP 1：Figmaでコンポーネントを作成
  • シンプルな要素のButton、言語化しづらい複雑な要素のCardの2種のコンポーネントを作成
    
  • Figma Variablesでデザイントークン定義
  • コンポーネントのスタイルは、カラー・スペーシング・角丸などVariablesで管理
    

  

• STEP 2：FigmaのURLからButtonを生成
• FigmaでButtonコンポーネントのフレームURLをコピー
  • Claude CodeにFigmaのButtonコンポーネントのURLを渡して指示
  • 「このFigmaデザインをReactコンポーネントとして実装してください：[URL]」
• 結果：FigmaのVariablesが正確にCSS変数として反映され、正確に再現

  

• STEP 3：Storybookをセットアップして表示確認
  • Claude Codeに以下を指示
    「このプロジェクトにStorybookをセットアップして Buttonコンポーネントが確認できるようにしてください」
  • ターミナルウィンドウで起動

    npm run storybook

• 結果：ローカルサーバーで、各バリアントのStoryが表示されることを確認
  
    
• STEP 4：FigmaのURLからCardを生成
  • FigmaでCardコンポーネントのフレームURLをコピー
  • Claude CodeにFigmaのCardコンポーネントのURLを渡して指示
  • 「このFigmaデザインをReactコンポーネントとして実装してください：[URL]」
• 結果：Cardコンポーネントが自動生成され、Storybookも更新
  ここでFigmaデザイン上でCardコンポーネントに罫線が入っていない事に気づきます
  

  

• STEP 5：Figmaで修正→Codeに反映
  • FigmaでCardコンポーネントに罫線を追加
  • 修正したCardコンポーネントのFigmaのURLを再度Claude Codeに渡して指示
  • 「Figmaを修正したので、再度このURLを元に更新してください：[URL]」
  • コンポーネントが正しく更新された
• 結果：Figmaで修正→URL渡すだけでスムーズに反映できることを確認
  （言語化しづらい部分の指示もFigmaで修正し更新する事が可能）
  

  

• STEP 6：Code → Figmaの双方向同期を確認
• primaryカラーを以下のように変更してください。Codeのみを更新してください。
  • button-primary-default → green-700の値
    button-primary-hover → green-800の値
    button-primary-active → green-900の値
• Storybookでブラウザを更新してボタンの色が変わっていることを確認
  
• Claude CodeにFigmaへの反映を以下のように指示
  • colors.cssのprimaryカラーをgreenに更新しました。 FigmaのVariablesも同じ内容に更新してください：[FigmaのファイルURL]
• FigmaのVariablesが更新されキャンバス上のbuttonもgreenに変わっていることを確認
• 結果：コード側の変更をFigmaに反映できることを確認
  

確認できたこと

• 言語で指示しにくい細かい修正もFigmaで修正してURL渡すだけで正確に反映される
• Figma→Code だけでなく Code→Figma の双方向同期も成り立つ
• Storyファイルも自動生成できる

詰まった点

• カラーがコンポーネントのCSSにハードコードされた
• インラインスタイルで生成されることがある
• コンポーネントが1ファイルに詰め込まれすぎることがある

CLAUDE.md（AIへのルールファイル）にあらかじめルールを定義しておくことで解決できました。

Figmaの設計品質が、AIの生成精度に直結する

今回の検証で強く感じたのは、Figma側の設計品質がそのままAIの生成精度に直結するということです。Variablesでデザイントークンをしっかり管理していたことで、Claude CodeがFigmaの値を正確に読み取れるだけでなく、変更の指示もシンプルになりました。

デザイナー 小： 今、作ったStorybookは、実務として使えるものになっていると思いますか？

プロマネ K： 実務で十分使えると思います。Gitで管理していれば何をどう変更したかの差分が明確に分かるので、スタイルの変更であればデザイナーがPRを出して、エンジニアがサクッと確認してマージする運用で全く問題ないですね。

デザイナー 小： Sさんはエンジニア目線で、品質面でどんな点が気になりますか？

エンジニア S： エンジニア目線で言うと、Storybookのスタイル調整はなるべくデザイナー自身に任せたいというのが本音なので、ここまでイメージ通りのモックを作ってくれるのは本当にありがたいです。Reactのコンポーネントとして出力されていればそのままベースとして使えますしね。脆弱性やセキュリティを心配する声もあるかと思いますが、これはあくまでフロントの見た目（モック）の段階なので、そこまで神経質にならなくていいと思います。もし気になるなら、セキュリティチェックを担当するエージェントをClaude Code内でもう一つ作り、2段構えで検証させる構造にすれば解決できます。

エンジニア S： あと毎回URLを渡すのが面倒なら、Claude Codeの初期情報としてFigmaのURLをあらかじめ「覚えさせて」おけばいい。あと、ブラウザでエラーが出ていないかを手動で確認していましたが、MCPを使ってAI自身にブラウザを確認させるフローを組めば、AIが自分でエラーに気づいて勝手に直してくれますよ。

デザイナー 小： 確かに、まだまだ工夫次第で効率的に作る事ができそうです。デザインチームでも研究して共有しながら正解を求めていきたいです。

ここまでを踏まえて、もう一つ議論したかったテーマがあります。Figmaなしで、Claude CodeとStorybookだけで管理する方法もあるのではないか、という問いです。

デザイナー 小： Storybookが必要なプロジェクトは、大規模だったり継続的に改善が必要だったり、デザインの一貫性を保ちたいプロダクトが多いと思います。コンポーネント同士を横に並べて比較・決定したり、「何をなぜ作るか」を思考する場所として、Figmaの役割があるんじゃないかと感じています。コード上だけで管理するのはシンプルですが、思考・発散・決定をするツールとしてFigmaは必要なのでは、というのが私の今の意見です。

エンジニア S： エンジニアとしては動くソースコードがあるのが一番扱いやすいですが、プロダクト全体を俯瞰したり、ユーザーの体験フローを確認したりする時には、やっぱりFigmaのようなビジュアルツールが必要になると思います。

プロマネ K： 僕は究極的にはデザイナーがStorybookを使って、直接ページ単位のコーディングまでAIと一緒に行う時代が来ると思っています。そうなると、どこかでFigmaのような中間成果物としてのデザインツールは不要になる日も来るかもしれない。

今回の検証とデモを通じて私が感じたのは、「AIへの指示力＝知識」だということです。

• コードを書かなくてもStorybookが作れることはわかった
• ただし完成に見えても、作り方が意図していない場合があった
• 曖昧な指示だとAIはコードや構成の最適解まで責任を持ってくれない
• AIとの対話の質は、人間が問いを立てられるかどうかで決まる

AIを使いこなす力は、結局その人が持っている経験と知識の量と質に比例すると感じました。

ただし、この結論自体も変わるかもしれません。「指示者の知識や解像度が低くてもクオリティの高いアウトプットができる世界が来る」という論もあります。そうなったとき、「何をなぜ作るか」という問いを立てる力と判断する責任も、いずれAIが担う領域になるのか。デザイナーに求められる役割は何か。まだ答えが出せていない問いだと思います。

プロマネ K： まずはデザインチームみんなで実際に試してみることから始めたいです。自分のプロジェクトのここに使えそう、という部分からどんどん使っていってもらうのが一番いい。

エンジニア S： 案件の規模や性質によって「どこまでやるか」の引き出しを多く持っておくことが重要だと思います。小規模案件はこのパターン、大規模でStorybookが必要な時はこのフロー、とデザイナー自身で提案できること。これこそがAIに代替されない、人間のデザイナーに必要なスキルになっていくはずです。

以前の座談会の記事はこちら