こんにちは。グッドパッチでUI/UXデザイナーをしているKCです。今日は、デザイナーの仕事に欠かせない「プロトタイプ制作」にまつわる話をしようと思います。

ユーザー検証のために、Figmaでプロトタイプを組むのは、多くのデザイナーが経験したことがあると思います。

ただ、画面と画面を線でつなぎまくるあの作業、しんどくないですか……？

画面が増えるたびにフレームを複製し、線を引き直して、状態違いを作り分けて、インタラクションを一つひとつ設定する。条件分岐を入れようとするとさらに複雑になり、修正が来ればまた張り直し。それだけ手間をかけても、出てくるのは結局“絵の集合”で、ユーザーに触ってもらっても、紙芝居感が残って「本当に使えるか」までは検証しきれないこともある。

手間の割に検証の解像度が上がらない、もったいない時間の使い方をしているのではないか──。そんな違和感を抱えてきた人は、結構多いんじゃないかと思います。正直に言うと、2カ月前の僕もそうでした。

そんな中で、あるプロジェクトで思い切ってFigmaの画面を1個も編集せずに、Claude Codeを使ったバイブコーディングだけで6機能分のプロトタイプを作る、という挑戦をしてみました。

結論から言うと、Figmaで「絵を描く」のをやめ、Claude Codeを相棒に「動きを対話する」。この感覚の切り替えで、Figmaで線をつなぎまくる時間は丸ごと消え、検証の解像度もスピードも別物になりました。備忘録も兼ね、この記事では2カ月で起きたことを順を追って振り返っていこうと思います。

小さく試したら、4日で2機能がFIX
気付けば、Figmaで画面を作らなくなっていた

プロトタイプ作成に生成AIの力を使う。そのきっかけは、プロジェクトがこんな状況になっていたからでした。

• 約1.5カ月で6つの機能のプロトタイプを機能検討段階から作る
• 検証は実店舗で行い、ユーザーにアプリのプロトタイプを触ってもらう

「この期間ではFigmaで全機能を作りきれない」というほどスケジュールが切迫していたわけではありませんが、むしろ僕が気にしていたのは、検証フィールドが店舗だからこそ、ユーザーが“実際のアプリを触れる感覚”で操作できれば、検証の質がぐっと上がるのではないか、という仮説でした。画面の紙芝居どまりでは、店舗で得られるはずの解像度には届かない。そんな懸念があったのです。

そこでまずは、比較的シンプルな機能を1つ、Claude Codeで組めるかどうか試すことから始めました。いきなり全機能に適用するのではなく、リスクを限定して小さく試すところから。正直なところ、半信半疑のスタートです。

ところがこれが想像以上に早かった。着手から4日ほどで2つの機能がFIXしたんです。Figmaで線をつないでいたら、まだ画面の作り込みをしている段階ですが、もう「触って検証できる完成形」が手元にある。

「え、これ、いけるんだ」。

この手応えが、その後の判断を全部変えました。スピードも検証物の質も明らかに上がるのならと、残りのプロトタイプもすべてバイブコーディングで作る方針に。とはいえ「Figmaは必要な道具」と思っていたので、いつものようにFigmaで画面を組み始めようと考えていました。

ただ、バイブコーディングで作る中で、こんなことに気付いていきました。

• 既存のデザイン情報は、Figmaから「読み取る」だけで十分だった
• 画面を組んだり線をつないだりする作業は、Claude Codeに依頼したほうが圧倒的に速くて精度も出る
• 修正も「ここの色をもう少し落として」「この遷移にローディング入れて」と話しかけたほうがラク

気付けば、Figmaで画面を作る作業が一つもなくなっていました。新しく画面を組んだり、線をつないだり、状態を作り分けたり──以前なら当たり前のようにFigma上でやっていた作業が消えていたのです。

「Figmaを使わない」と決めた瞬間があったわけではなく、一つひとつの作業について「速くて正確な方法」を選んだら、結果的にFigmaで画面を作る作業はゼロになっていた、というのが正確な感覚でした。

もちろん、Figmaそのものを全く使わなくなったわけではありません。デザインシステムを整備するとき、既存画面の情報設計をチームで見直すとき、ビジュアルの方向性をそろえていくとき──Figmaのキャンバスが主役になる場面は、今も変わらずたくさんあります。

今回減ったのはあくまで、「画面を量産する」「線でつなぐ」といった、プロトタイプ制作にまつわる手の動かし方でした。Figmaの役割が消えたのではなく、Figmaに任せる仕事と、Claude Codeに任せる仕事の境界線が、自分の中で引き直されたという感覚に近いと思っています。結局、見直すべきだったのはツールそのものではなく、「プロトタイプはFigmaで作るのが当たり前」という、自分の中にあった思い込みだったのかもしれません。

プロトタイプの制作・検討・共有　3つの場面での生成AIの生かし方

ここからは「Figmaで画面を編集せずにプロトタイプを作る場合、実際にどう進めるのか」というHowの話に入ります。

プロトタイプの制作・検討・共有。大きくこの3つの場面それぞれで、順番に僕が実際にやっていたことをまとめます。これらの作業は並行して進めることが多いため、ステップというより、“3つの場面”くらいの感覚で読んでもらえると、ちょうど良いかもしれません。

【制作】最も手間がかかるのは、既存デザインシステムへの忠実さ

Figmaで画面を作らなくなった代わりに、最も手を動かすことになったのが「既存のデザインシステムにどれだけ忠実にそろえられるか」という点でした。

確かにAIは賢いですが、放っておくと「それっぽい」けど微妙にズレたUIを出してきます。色味が少し違う、余白が共通スケールに乗っていない、フォントウェイトが微妙に違う、など。今回のプロトタイプを触ってもらうユーザーは、既存のアプリを使っている人たちなので、できるだけ既存のデザインを踏襲できることが望ましい状況だったのです。

僕が試行錯誤の末にたどり着いた、デザイン情報の渡し方の使い分けがこちらです。

特に「FigmaのCSSコピー機能」と「SVGの直接渡し」は精度が高く、コンポーネント単位ではスクショよりはるかに正確に再現してくれます。

加えて、複数機能・複数バージョンを作り続けると、同じはずの色や余白が少しずつ揺れていく。そのため、デザイントークンを定義したCSSファイルを1枚、すべてのプロトタイプから読み込ませる”おおもとのファイル”として運用する形に切り替えました。Figma側で変更があれば、このCSS1枚を更新するだけで全プロトタイプに伝播します。

そして、進めるうちにもう一つ気付いたのが「言葉で書かれたデザインシステムの取扱説明書」が、AIにはものすごく効果的、ということでした。

途中からは、デザインの原則や命名規則、トークン、コンポーネントの使い分け、運用ルールをMarkdownで言語化した「DESIGN.md」という1枚の索引ファイルを用意して、Claude Codeが常にそれを参照できる状態にしました。

CSSは「数字の正解」を伝える役割、DESIGN.mdは「なぜそのデザインなのか／どう使い分けるべきか」という意図と運用の理解を伝える役割。この二段構えにしてから、AIから返ってくるアウトプットの“ズレ”がさらに減っていきました。

ただ、正直に言ってAIへの指示の出し方については、まだ完成形にたどり着いていません。今も運用改善を進めている領域です。

【検討】Figmaを触らずに、複数案の検討ってどうやるの？

ここまで読んだ人の中には「Figmaで画面を組まないなら、A案・B案を比較検討するときって、どうやって進めるの？」という、疑問が浮かんだ人もいるかもしれません。

その答えは至ってシンプル。複数案をClaudeとの会話で並行して用意します。

「このボタン、A案は強調する方向で、B案は控えめにしてみて」「このシート、A案は下から、B案は中央から出すパターンで作って」。こうしたやりとりを重ねれば、Claude Codeの上で複数のバリエーションがそのまま立ち上がっていきます。

さらに、用意した複数案を1枚のHTMLファイルに並べて、提案書のように仕立てることもできますし、その提案書上で直接プロトを触ってもらうことも可能です。「触れる提案書」という選択肢が手元にあるだけで、検討フェーズの引き出しは一つ確実に増えると感じています。

【共有】プロトタイプの共有ツールも、バイブコーディングで自前で開発

もう一つ、運用面で触れておきたいのが、プロトタイプの共有方法です。

今回作っているプロトタイプはHTMLファイルです。これをユーザーテスト参加者やクライアントに触ってもらうには、配信のための仕組みが必要になります。

そこでプロトタイプを共有するためのサービスそのものも、バイブコーディングで自前で組むことにしました。Claude Codeに「HTMLファイルをアップロードして、URLで限定的に配信できるシンプルな仕組みを作って」と話しかけて、プロトタイプ配信用のミニサービスを内製したんです。

ただし、当然ながらセキュリティ面の設計には、細心の注意を払う必要があります。クライアントワークでは、プロトタイプそのものがNDA対象の機密情報です。アクセス制限、パスワード、配信期限、URLの推測困難性。基本的なセキュリティ要件は、自前で組むからこそ、自分で設計しきる必要があります。手軽さに引っ張られて、ここをおろそかにしては絶対にいけません。

それさえ押さえれば、配信インフラまで自分の手で組み上げられる。これも、Claude Codeを“道具として持つ”ことで広がる選択肢の一つです。

生成AIでプロトタイプを作成して、何が変わった？1.5カ月走って見えた3つの変化

プロトタイプ作りに生成AIを使ってみてまず驚いたのは、Figmaで「絵を描く」ことから、Claude Codeを相棒に「動きを対話する」ことへ、作業の感覚そのものが変わったことでした。この変化を起点に、プロトタイプ制作の前後の工程まで、いろんな場面で「あ、これも変わったな」が連鎖していきました。

1.作る“手間”が丸ごと消え、検証までのスピード感が別物に

フレームを複製して、線をつないで、状態の分岐を作り、インタラクションを一つひとつ設定する。正直しんかった作業を、6機能ぶん丸ごとスキップできてしまった。プロトタイプ制作という文脈においては、Figmaは「デザインの情報源」、プロトタイプはコードベース。この役割分担が自分の中できれいにハマった瞬間でした。

そして、これは自分でも驚いた変化ですが「1.5ヶ月で6機能」という量を検討段階から進め、しっかりと触れる検証物としてそろえられたこと自体が、Figmaで線をつないでいたら絶対に起き得なかった結果です。1機能あたり、制作着手から数日でPdMの承認まで到達するスピードで進められて、機能FIXまでの時間は体感で半分以下になりました。

クライアントとの議論も「このボタンを押したらどうなる？」というものではなく、「この遷移、もう少しこうしたい」と具体的な議論から始められる。検証物の設計が精緻になると、フィードバックの解像度も上がる。これは想像以上に大きな変化でした。

2.Figmaでは作れなかった検証物が、作れるようになった

これも始める前はまったく予想していなかった収穫でした。Figmaのプロトタイプは「画面間をつなぐ」ことでの表現までしかできないですが、今回作ったプロトタイプでは、こんなことができるようになりました。

• カメラを起動して、対象物をその場で画面に映せる
• 検索ボックスのキーワードでリストがリアルタイムに絞り込まれる
• 入力したメモを保存して、別画面の一覧にちゃんと反映される

このように、条件分岐や状態保持、デバイス機能まで含んだ“本物に近い挙動”まで組み込めるようになりました。ユーザーの「あ、ちゃんと動く」という体験まで含めて検証できると、フィードバックは「画面の話」から「体験の話」へと一段上がります。

3.現場でリアルタイムに、プロトタイプの改善ができた

検証の現場で起きることも変わりました。これまでなら「次回までに直しておきます」が精一杯だった「ちょっと分かりにくい」というフィードバックを、検証の合間に一部反映して、次のテストからは改善版を触ってもらう。そんな対応ができたんです。

“検証→改善→再検証”が日単位で回ると、議論は「想定通りに動くか」じゃなく「直したところは本当に良くなったか」「次に潰すべき課題はどこか」という、一段先のレベルに上がります。検証期間を、仮説を確かめる時間から、磨き込む時間に変えられた。これは大きな変化でした。

AIで変わるデザインの仕事。だからこそ、まず触ってみることが大事

ここまで書いてきた1.5カ月の変化は、僕個人だけの話ではなく、デザイン制作のあり方そのものがAIで変わり始めている、その入り口の話だと感じています。

「画面を作って」「線でつないで」「ハンドオフする」が当たり前だったプロトタイプ制作の前提が、「言葉で伝える」「動きを対話する」「自分の手で動くものまで組み上げる」という形へ変わりつつある。デザイナーが扱える対象と粒度が、根本から変わってきている。それに伴って、デザイナーの価値の出しどころも、確実に変わりはじめています。

そういう状況下で伝えたいことは、本当にシンプルに一つだけ。「怖がらず、まず一度、自分の手で触ってみることが大事だ」ということです。

僕もプログラムやコードは書けません。やったことは、相棒のClaude Codeに「どう動いてほしいか」を言葉で伝えることと、「意図通りに仕上がっているか」を判断することの2つだけ。

要件定義であり、UXライティングであり、デザインレビュー。デザイナーがずっとやってきた仕事そのものを、AIに向けるだけのことです。最初の一歩のハードルは、思っているよりずっと低いです。僕も半信半疑で1機能から始めて、4日で2機能がFIXした手応えに、背中を押されました。

そしてこれは、デザイナー個人の話に見えて、モノづくりに関わるすべての人に関わる話でもあります。分業で固まっていた制作・検証・検討の壁が、AIによって溶け始めている。PdM、エンジニア、経営層、誰もが「アウトプットの解像度をどう上げるか」を問われる時代の、一つの実装例として読んでもらえるとうれしいです。

AI時代のデザイナーって、これから何ができるんだろう──今の僕なりの答えは、シンプルに「AIを相棒にして、自分が扱える解像度を上げ続けていくこと」かな、と思っています。動くものでデザインの意図を伝えられる範囲が広がれば、デザイナーから見える景色も、きっと少しずつ広がっていく。そんな手応えを胸に、僕もこれからの仕事に向き合っていこうと思っています。

こうした変化を、一緒に作っていく仲間へ

最後に、少しだけ採用の話をさせてください。グッドパッチでは今、AI時代のデザインのあり方を、クライアントワークの現場で、一緒に探求してくれるデザイナーを募集しています。

• ツールが変わっても揺るがない「デザインの本質」を握り続けたい方
• AIを使いこなす側に回って、デザイナーの仕事の射程を広げていきたい方
• 検証物やアウトプットの解像度を上げて、動くもので議論できる場を作っていきたい方

この記事を読んで「自分の現場でもやってみたい」「もっと深く話を聞いてみたい」と感じた方は、ぜひグッドパッチの採用情報から覗いてみてください。カジュアル面談からの相談も歓迎しています！