私はBIPROGYのデザイン組織に所属しており、これまで業種・業界を問わず、さまざまな案件のUI/UXデザインに携わってきました。BIPROGYにおけるUI/UXの取り組みについては、以下の記事で詳しく紹介しています。
はじめに：要件定義における「触れる」プロトタイプの重要性
UXデザイナーやベンダーの立場で顧客と要件定義を進める際、デザインツールで作成した静的な画面デザインだけでは、実際の操作感や画面遷移のイメージが伝わりきらないことがよくあります。その結果、開発が進んでから「思っていた動きと違う」「こんな機能も欲しい」といった認識齟齬や、追加要件の発生につながってしまうことは、よくある課題です。
これを防ぐには、要件定義の早い段階で「実際に触って動かせるプロトタイプ」を顧客に提示し、イメージを具体化することが非常に有効です。
※本記事では、「プロトタイプ（成果物）」と「プロトタイピング（プロセス）」を区別して記載します。
なぜ「まずプロトタイプで動かす」のが有効なのか
要件定義段階のプロトタイピングでは、必ずしもHTMLとして実装すること自体が重要なのではありません。重要なのは、関係者ができるだけ早く「触って確かめられる状態」を用意し、認識を揃えられることです。
ReactやVueなどで別途実装環境を整える方法もありますが、要件定義の初期段階では、その準備や説明のコストが議論のスピードを落としてしまうことがあります。
そのため本記事では、まずFigma Makeを活用しながら、デザインを素早く動くプロトタイプに近づけ、関係者との合意形成を加速させるアプローチを紹介します。
AIを活用したプロトタイピングのワークフロー
これまで、触れるプロトタイプを短時間で用意するには、画面設計と動きの検討を何度も往復する必要があり、手間のかかる作業でした。しかし現在では、以下の組み合わせによって、この「プロトタイピングのプロセス」を劇的に短縮できます。
Step 1. Figma Make で画面のベースを素早く作成する（Reactのコードで生成される）
Step 2. 顧客の要件に合わせて、Figma上でデザインを手作業で微調整する
Step 3. 調整したデザインをもとに、Figma Make で再度プロトタイプ化し、画面遷移や操作感を素早く確認できる状態にする
本記事では、複雑な実装作業に入る前に、FigmaとAIを活用して顧客との合意形成をスムーズにするためのプロトタイピングのワークフローをご紹介します。
提案するプロトタイピングのワークフロー
この手法の最大のポイントは、「AIによるたたき台作成」「人間による要件反映と調整」「AIによる再プロトタイプ化」の3つを分業させることにあります。すべてを一つのツールで完結させようとするのではなく、適材適所でツールを組み合わせることで、最も摩擦の少ないプロセスを実現します。
Step 1: Figma Makeによる「ゼロイチ」の土台作成
真っ白なキャンバスからUIのレイアウトを組み上げるのは、認知負荷が高く時間のかかる作業です。最初のステップでは、この「ゼロイチ」の工程を生成AIに任せます。
Figma Make（あるいは類似のUI生成AIツール）に対して、作成したい画面の要件をプロンプトで指示し、ベースとなるUIを出力させます。
💡 Figma Make（Make Designs）とは
Figmaの公式AI機能の一つで、テキストプロンプトからUIのレイアウトやコンポーネントを自動生成する機能です。詳細な仕様や使い方については、Figmaの公式ヘルプをご参照ください。
Figma Makeを用いた検証結果については、以下の記事でも詳しく説明しています。
ここで生成されるUIは、Reactコンポーネントを前提とした構造になっていたり、コンテンツの細部が甘かったりしますが、この段階では全く問題ありません。目的はあくまで「要素の配置」と「画面の骨格」を数秒で用意し、思考の土台を作ることだからです。
今回は、セミナーのランディングページ案をAIで検討しました。セミナーの前提情報やトーン＆マナーのイメージをFigma Makeに渡すことで、ゼロベースから、「UIの初期プロトタイプ（たたき台）」が生成されます。
Step 2: Figma上でのUI調整（手作業）
AIが生成したUIは「それっぽい」ものの、コンテンツの内容が適当だったり、細かな導線設計まではカバーしきれていません。プロンプトで細かな指示を出すよりも、Figma上でデザインを微調整していくほうが効率的なため、Figmaのデザインファイルにコピーし、手作業で調整を行います。
Step 1で生成されたデザインをFigmaのキャンバス上で直接編集し、要件定義で固めた内容を反映させていきます。
- ブランドのトーン＆マナーの調整
- 情報の優先度に基づいたレイアウトの調整
- コンテンツやアイコンの細かな調整など
AIが作った土台をもとに調整を加えることで、「人間が考えるべきUXのコアな部分」の検討に十分な時間を割り当てることができます。Step1で生成した「初期プロトタイプ（成果物）」に対し、コンテンツ内容やアイコンの変更、画像配置などデザインツール上で調整を加えています。
Step 3: Figma Makeによる再プロトタイプ化
Figma上でのデザイン調整ができたら、次はその内容をもとに、再びFigma Makeを使って「触って確認できるプロトタイプ」に近づけます。
要件定義段階では、必ずしもHTMLとして書き出すことが重要なのではなく、関係者がその場で操作しながら認識を合わせられることのほうが重要です。そこで今回は、調整済みのデザインや要件をもとにFigma Makeへ再度指示を行い、画面遷移やインタラクションを含んだプロトタイプとして素早く再構成する流れを採用しました。
この方法の利点は、コード化や実装環境の準備に進む前に、要件定義に必要な粒度で「動き」を確認できることです。たとえば、導線のつながり方、ボタン押下後の挙動、フォーム入力から確認画面までの流れなどを短時間で検証しやすくなります。
以下は、Figma上で調整した内容を踏まえて再プロトタイプ化した例です。静的なデザインだけでは見えにくかった操作感や画面遷移を、関係者とその場で確認できるようになりました。
💡 コラム：プロトタイプをさらに精緻化して見せたい場合は、Figma MCP × Cursorも有効
本記事では、要件定義段階で素早く合意形成することを重視し、Figma Makeを中心にプロトタイピングを進める流れをご紹介しました。
一方で、関係者への説明や検証の粒度をさらに上げたい場面では、Figma MCPとCursorを組み合わせて、Figma上のデザインをもとにHTML / CSS / JavaScriptとしてプロトタイプ化する方法も有効です。
たとえば、画面遷移だけでなく、フォーム入力、モーダル表示、タブ切り替え、バリデーションのような、より具体的なインタラクションを実際のブラウザ上で確認したい場合には、この方法が適しています。
つまり、要件定義の初期段階では Figma Makeで素早く合意する、その後さらに精緻な確認が必要になった段階で Figma MCP × Cursorでブラウザ上のプロトタイプに落とし込む、という使い分けが考えられます。
Figma MCPについては、Figma開発者ガイドも参考になります。
プロトタイプがもたらす要件定義の質の向上
出力されたプロトタイプは、関係者とのミーティング中にその場で操作しながら確認できます。静的な画面だけでは伝わりにくい画面遷移やインタラクションを共有しやすくなるため、要件定義の初期段階で認識を揃える助けになります。
「ボタンを押したらどう遷移するか」「タブを切り替えると何が変わるか」といった動きを実際に体験してもらうことで、静止画では引き出せなかった「ここはもっとこうしてほしい」という要望を、要件定義のより早い段階で引き出しやすくなります。
まとめ：プロトタイプは目的ではなく「対話のツール」である
AI技術の進化により、Figma Makeのような強力なツールを活用することで、今や誰でも簡単に、そして短時間で「動くプロトタイプ」を用意できる時代になりました。
しかし、ここで忘れてはいけないのは、プロトタイプという成果物を用意すること自体や、プロトタイピングそのものが目的ではないということです。プロトタイプはあくまで、顧客と認識をすり合わせ、システムやプロダクトの真の要件を詰めるための「対話のツール」に過ぎません。
どれだけ素早く動くプロトタイプを用意できたとしても、それを触る顧客や関係者の反応を観察し、隠れたニーズを引き出し、最終的な要件としてしっかりと固め切るスキルは、依然として私たち人間に求められます。
本記事では、そのもっとも重要な「顧客や関係者との対話」に集中し、要件定義のプロセスをスムーズに進めるために、AIをどう活用して試行錯誤の摩擦を減らすか、という一つのアプローチをまとめてみました。
なお、要件定義の初期段階ではFigma Makeによる高速なプロトタイピングが有効ですが、より精緻な確認が必要な場面ではFigma MCP × Cursorのような手法へ発展させる余地もあります。
プロジェクトにおける「要件のズレ」や「後出しの仕様変更」といった同じような課題に悩む方々にとって、このワークフローが何らかのヒントや、状況を好転させるきっかけになれば嬉しいです。
We Are Hiring
BIPROGYでは一緒に働く仲間を募集しています。ご興味ある方は下記をご参照ください。