こんにちは、ミツモアでデザイナーをしている野末です。
今回は、現在検証を進めている「Figma Makeを活用したプロトタイピング初期準備の効率化」というテーマで、現在進行系のトライアルについてお話ししたいと思います。
現在、Figma Makeの進化は加速しており、自社デザインシステム（npmパッケージ）との連携を可能にする機能のリリースが間近に迫っています。
自社デザインシステム（npmパッケージ）とは： エンジニアが実装で使用している「コード化されたUIコンポーネント集（Storybook等で管理されているもの）」のこと。これと連携できるということは、「実装済みの部品そのもの」を使ってデザインが生成できることを意味します。
私たちは、その未来が到来したときに「即座にアクセルを踏める」よう、まだ「これが正解だ！」という完成形ではありませんが、AI時代におけるデザインワークフローの過渡期として、現行のツール（Notion）を駆使して先行実験しています。皆さんの参考になれば幸いです。
はじめに：Figma Makeの「2つの使い方」と導入の壁
私たちのチームは現在、プロダクトのUI/UX改善の初速を上げること、そしてデザインから実装までのリードタイムを短縮することを大きなテーマとしています。そのための強力な武器として注目しているのが、「Figma Make」です。これはプロンプト（テキスト指示）を入力するだけで瞬時にUIデザインを生成でき、誰でも簡単にプロトタイピングを行える画期的なツールです。
このようなプロトタイピングツール（Figma Make、v0等）には、大きく分けて2つの使い方があると考えています。
1つは、既存のコンポーネントやデザインの制約にとらわれず、アイデアを自由に発散させる「アイデアフラッシュ」を目的とした使い方。
そしてもう1つは、既存機能の改善やUI改修のように、「ある程度、実際の画面（Currentの仕様）を再現した上で行うプロトタイピング」です。
課題：「再現性」と「ノイズ」のジレンマ
私たちのような、機能追加や改善を高速に繰り返すプロダクト開発においては、後者のニーズが比較的多いのが実情です。しかし、ここで「あるジレンマ」に直面しました。
「既存のデザインを踏襲してほしい」のに、毎回ゼロからプロンプトで指示を出すと、生成されるデザインのトーンや構造がバラバラになってしまいます。かといって、毎回細かく「ボタンの色はこれ、レイアウトはあれ」と指示するのは準備が大変で、本末転倒です。
「じゃあ、一度うまく生成できたプロトタイプを複製（Duplicate）して流用すればいいのでは？」
そう思うかもしれません。私も最初はそう思いました。しかし、Figma Makeの仕様上、ファイルを複製すると「過去の大量のプロンプト履歴（試行錯誤のログ）」まで引き継がれてしまうのです。
これが次の検討をする際に大きなノイズとなり、「新しいアイデアを試したいのに、AIが過去の文脈に引っ張られる」という現象が起きてしまいました。
「まっさらな状態（Clean Slate）」で、かつ「自社の文脈（資産）」を使って始めたい。 この課題を解決するために、Notionを間に挟むフローを考案しました。
実践：Notionを「Figma Makeの指令室」にする
現在、私が検証しているのは、Notionを「Figma Makeの指令室」として機能させる仕組みです。
具体的には、以下の2つのデータベースを連携させています。
Screens DB（作りたいもの）
「請求書編集画面」「ログイン画面」といった画面単位の要件を管理します。ここは非デザイナーでも書けるよう、自然言語での指示（Instruction）が中心です。
Source Files DB（使う道具）
ここがポイントです。Figma Makeで生成・精緻化して「これは使える（再現性が高い）」となったプロトタイプ用のソースコード（React/TypeScript）だけを蒸留し、ここにストックします。
Screens DBの「要件」とSource Files DBの「コード」。この2つを関連付け（リレーション）することで、Figma Makeへの指示は以下のようなシンプルなプロンプトだけで完結し、高精度な生成が可能になります。
【プロンプト例】 このNotionページ内の「Screens」データベースを参照し、以下の手順で画面を作成してください。 1. 「画面テンプレート」の Source Files（※`svg-*.ts` 等のSVG定義は除外）をベースに、ヘッダーとサイドバーを作成してください。 2. 「画面名（例: "仕事作成"）」の **Design Instruction** と **Source Files** を読み込み、そのコンテンツをメインエリアに配置してください。
▼Notionを連携した実際の生成画面
なぜこのひと手間をかけるのか？
理由は大きく2つあります。
1つ目は、「ノイズのない、シンプルなスタート地点」を作るためです。
Figma上でファイルを複製するのではなく、Notion上の Source Files から必要なコードだけをコピペして新規ファイルで生成を開始する。こうすることで、過去の試行錯誤の履歴に引きずられることなく、常にクリアなコンテキストで新しい検討をスタートできます。
2つ目は、「再現性」です。
Figma上のデザインデータを直接参照させたり画像として貼り付ける運用も試しましたが、それだと毎回AIの解釈に「ゆらぎ」が生じ、生成されるUIにばらつきが出てしまいます。
一方で、コード（React/TypeScript）は構造が明確であり、解釈の余地が少ないため、再現性が段違いに高いのです。
生成されるUIが毎回ブレてしまうと、「デザインが崩れている」といった本質的ではない部分の修正に時間を取られ、肝心のUX検証に集中できません。
また、プロトタイピングの段階でコード構造を意識した再現性の高いものを作っておくことは、結果として実装までのリードタイムを縮める（Dev Readyな状態に近づける）ことにも繋がると考えています。
単に「きれいな画面を作る」ためではなく、「検証の質を高め、全体のプロセスを加速させる」ために、再現性は重要なのです。
これらにより、AIにとっても「今の指示」と「明確なコード」だけに集中できる環境が整い、生成精度が目に見えて安定しました。
「画面再現」はあくまで準備。その先へ
このフローでSource Filesを使って画面を再現するのは、あくまでプロトタイピングのための「土台作り」に過ぎません。
Notion連携の真価は、その整った土台の上で、実際の要件定義書（PRD）を連携させてプロトタイピングを行えることにあります。
Notionであれば、Screens DBの各アイテムにPRDページを紐付けることができます。
「このソースコード（Source Files）でUIのガワを作り、このPRD（要件） に基づいたコンテンツやインタラクションを実装して」
このように指示することで、単に見た目が似ているだけでなく、「仕様（Why）」を含んだ実戦的なプロトタイプを、迷いなく生成できるようになるのです。
組織へのインパクト：プロトタイピングの「民主化」へ
この仕組みが整うと、面白い変化が期待できます。
言語化できれば、誰でも作れる
これまではデザインツールの操作スキルがないと画面が作れませんでしたが、このフローなら「Notionにあるこの部品（Source File）を使って、こんな画面を作って」と言語化さえできれば、誰でもそれなりの精度のプロトタイプが作れるようになります。
エンジニアやPdMが、会議の場で「ちょっと試してみようか」とNotionからコードを拾って画面を作る。
そんな「全員参加型」のデザインワークフローの土台ができるのではないか、と考えています。
今後の展望：これはまだ「過渡期」の実験
現状：手動運用の「泥臭さ」
正直に言うと、現状のフローはまだ泥臭いです。
Figma Makeで生成したコードをNotionに手動でコピペして管理しているので、効率的とは言えません。あくまで検証フェーズの運用です。
未来：npm連携による「本番コード」への昇華
しかし、Figma Makeには今後、「npm packagesのインポート」や「Make Kits（デザインシステム連携）」といった機能の実装が予定されています。
これらが利用可能になれば、Notion上で手動管理している「お試しコード」が、本物の「自社プロダクションコード（npm）」に置き換わります。
そうなれば、Notionは純粋な「レシピ（要件）」の管理に特化し、「作りたい画面を選ぶだけで、最新の自社コンポーネントを使ってプロトタイプが生成される」という世界が実現するはずです。
おわりに
ツールの進化は目覚ましいですが、それを組織として活用するには、受け入れる側の準備も必要です。
今はまだ泥臭いNotion連携かもしれませんが、こうした工夫を通じて「AIと共創してデザインする文化」と「誰でもプロトタイピングできる土壌」を地道に作っておく。
そうした土台があれば、ツールが追いついてきた時に、スムーズに新しいワークフローへ移行できると考えています。
これからも、職能を超えてプロダクトを良くしていくための実験を続けていきたいと思います。
