こんにちは。フロントエンドエンジニアをしているNokogiri（@nkgrnkgr）です。
はじめに
カケハシのある新規プロダクト開発で、PdM やデザイナーが AI を使って実コードベースでプロトタイピングをするようになりました。進め方としてはわりと大きな変化です。
もちろん会社として全職種に対して AI の利用を推奨している背景もあり、PdM やデザイナー自身も AI を使うことには前向きでした。そのうえで、実際にプロトタイピングを始めるまでのハードルを越えるところを、フロントエンドエンジニアとしてサポートしたいという思いがありました。
その背景の一つに、新規プロダクト開発の不確実性の高さがあります。事業責任者をはじめさまざまなステークホルダーと要件を詰めていく必要があり、早めに動くものを見せて合意を取っていきたいという思いがありました。一方で、Figma や Figma Make ベースでプロトタイプを作ると、プロダクションコードから乖離したものができてしまい、開発フェーズで再現するのが大変になるという懸念もありました。PdM やデザイナーが自然言語で実コードのプロトタイプを作る事例を社外でも見聞きするようになっていたので、フロントエンド側がサポートすればカケハシでもやれるんじゃないか、と考えたのです。
ただし、これを実現するためには、フロントエンドエンジニアとしていくつかの準備が必要でした。本記事では、何が変わったか、用意した準備の中身、安全に運用するための決まり事、PdM・デザイナーの心理的ハードルをどう下げていったか、運用してみて気づいた課題を共有します。
進め方が変わってきた
以前、デザイナーは AI を使っておらず、UI デザインや画面遷移は基本的に Figma で表現していました。今は AI を使って実コードを触りながらプロトタイプを作るようになり、「UI を詰めていく」メインの場が Figma から動くプロトタイプに移ってきています。Figma を全く使わなくなったわけではなく、部分的な詳細議論や、FigJam での抽象度の高い構造議論には引き続き使っています。
PdM も同様です。以前は仕様をドキュメントにまとめることが多かったのですが、今はそれをやる前に自分でプロトタイプを作って思考を整理するようになりました。ドキュメント作業がなくなったわけではなく、その前段に「動くものを試す」が加わったという感覚です。
プロトタイピングを支える3つの準備
PdM・デザイナーがプロダクションコードを使ってプロトタイピングできるようにするには、それなりに準備が必要でした。大きく分けて「環境」「AI を利用するスキル」「コードベース」の3つです。
環境
エンジニアでない PdM・デザイナーが Cursor でプロトタイピングするためには、まずは開発環境のセットアップが必要です。具体的には以下のような項目をひとつずつクリアしていきました。
- GitHub アカウントの整備（持っていない人には作ってもらう）
- Cursor の社内利用申請
- PC のセットアップ: 依存するライブラリなどのインストール（Homebrew、Git、gh、pnpm、mise など）
- ssh で GitHub に push できる環境整備
- Cursor をインストールし、リポジトリをクローン・push する一連のフロー構築
- main ブランチ向けに作業ブランチを作ると、自動で AWS Amplify にプレビュー環境ができる仕組み作り
自走できる人もいれば、ターミナルや Git の操作に慣れていない人もいます。後者の場合はペア作業で一緒に環境を構築していく形をとっていました。「動くまでが大変」というところでつまずいてしまうと、その後のプロトタイピング自体を試してもらえなくなってしまうので、ここはエンジニアが伴走する価値が大きいフェーズです。
特にプレビュー環境を自動で作る仕組みは効きました。ブランチを push すれば URL ができる、というのは、PdM やデザイナーが成果物を他のステークホルダーに共有しやすくなる重要な要素だったと感じています。
AI を利用するスキル
環境が整っても、いきなり「AI を使ってプロトタイピングしてください」と渡すだけでは進みません。PdM・デザイナー向けに勉強会やハンズオンを開き、AI への指示の出し方や修正の仕方を実演しました。
伝えていることの例：
- 「○○みたいな画面を作って」と一気に指示するのではなく、段階的に指示する
- Cursor の内部ブラウザを使うと DOM レベルで「ここをこうして」と指定できるので、コンテキストを渡しやすい
- ターミナルや Git でエラーが出たら、スクショを AI に渡して解決してもらう
- 期待した結果にならないときは、何を期待していたかを言語化してもう一度伝える
特に Cursor の内部ブラウザを使った DOM 単位の指定は強力で、デザイナーが「ここの余白を少し詰めたい」「このボタンをもう少し左に」と話している内容を、そのまま AI に伝える橋渡しになっています。
「ターミナルや Git がよくわからない」という部分も、最近は AI に聞けば解決することが多いので、「困ったら AI に聞いていい」というスタンスを共有するだけでも自走しやすくなったと感じています。
コードベース
3つ目はコードベース側の準備です。
何も準備せずに「AI で好きにプロトタイプを作ってください」と任せると、AI はゼロベースでコードを生成し始めます。デザインシステムから外れた色や余白を勝手に使ったり、画面ごとにバラバラな実装パターンが量産されたりしがちで、再現性がないため後から本実装に活かしづらい状態になります。フロントエンドエンジニアとしては避けたいところです。
そこで、AI の生成にガードレールを敷くための準備を3つ用意しました。
1つ目は、プロトタイプ用のページとディレクトリを切ったことです。プロダクションコードの本体に直接手を入れるとレビューや影響範囲の議論が必要になりますが、プロトタイプ専用のディレクトリならその心配は不要です。
2つ目は、Claude / Cursor 用のプロトタイピング Skill を用意し、「このディレクトリ以下のコードベース構造はこうなっている」「使えるコンポーネントはこれ」といった知識を AI に渡せるようにしたことです。これによって AI が生成するコードのブレが大きく減ります。
3つ目は、AI フレンドリーなデザインシステムの事前準備です。これについては以前 生成AIフレンドリーなフロントエンド基盤をつくる に詳しく書いているので本記事では割愛しますが、「使うべきコンポーネント」「使うべきトークン」が明確になっていることが、AI に意図に沿ったコードを生成してもらうための土台になります。
安全に運用するための決まり事
準備が整って自由に触ってもらえる状態にすると、今度は「意図しない変更がプロダクションコードに混ざらないか」が気になります。そこで、いくつかの運用ルールを決めて回しています。
ブランチを切って、PR を FE がレビューする
プロトタイプ作業は必ずブランチを切ってもらい、main には直接 push しない運用にしています。マージは PR を経由し、フロントエンドエンジニアがレビューしてからマージします。
レビューでは特に「想定していない箇所への変更が混入していないか」をかなり注意して見ています。AI が生成するコードは、ときに指示の範囲を超えた変更を含むことがあるため、ここのチェックは欠かせません。
PdM・デザイナー側から見ても、ブランチで作業して push し続けるかぎりプロダクションコードには影響が出ないというのは安心材料です。試行錯誤しても何かを壊すリスクがないので、心理的なハードルが下がって挑戦しやすくなる、というメリットもあります。
/prototype-design スキルを必ず起動して開発する
コードベースの準備で触れた Cursor 用のプロトタイピング Skill（/prototype-design）について、プロトタイプ作成時には必ずこのスキルを起動してから開発するようにお願いしています。スキルの中には、AI に守ってもらいたい運用ルールを書き込んでいます。
具体的には、以下のような内容を盛り込んでいます。
- ペルソナ: ユーザーはデザイナーで、コードの読み書きはできない、という前提を AI に共有しておく
- 作業ディレクトリ:
src/labs/pages/proto-design以下に限定し、そのスコープを越えた変更は行わないこと - AI への指示の出し方: 修正を依頼するときはスクショを撮って「どこに」「どんな修正をするのか」を具体的に伝える。曖昧さが残っていれば AI 側から逆質問してもらう
決まり事と書くと堅苦しく聞こえますが、要するに事故が起きにくい状態を仕組みで作っておくということです。これによって、PdM・デザイナーが安心して試行錯誤でき、FE 側もレビューの観点が明確になります。
意思決定はどう変わったか
準備が整って PdM・デザイナーがプロトタイプを作れるようになると、意思決定のあり方にも変化が出てきました。これはレイヤーごとに見ていくとわかりやすいです。
要件整理・画面構成のフェーズ
このフェーズでは、Figma の静的なパーツやページを見て判断していたときには気づけなかった部分が、先に議論できるようになりました。
たとえば：
- 「この画面遷移は同一タブで開くのか、別タブか」
- 「どのタイミングでサーバー通信が発生するのか」
- 「既存プロダクトとの画面遷移はどんな体験になるのか」
こうした「動かしてみないとわからない」種類の論点は、従来は実装に入ってから初めて気づくことが多く、そのたびに手戻りが発生していました。動くプロトタイプがあれば、要件整理の段階で議論の俎上に乗せられるようになります。
実装フェーズ
実装フェーズでも変化があります。以前は、Figma で詰められた UI を FE がコードで再現する、という流れが基本でした。実装してみると Figma 通りに再現できない部分があったり、細かいあしらいでバランスが悪い部分が見えてきたりして、その都度デザイナーに相談していました。
今は、デザイナー側がプロダクションコードでプロトタイプを作る段階で「コードで実現できること・できないこと」がある程度わかった状態になります。実装に入る前にデザインと実装の現実が突き合わせされているので、開発に入るまでのステップが短くなった感覚があります。
ただし、こんな落とし穴もある
一方で、動くプロトタイプがあるがゆえの落とし穴もあると感じています。
ひとつは、議論が細部に引きずられやすいことです。
全体の画面の流れや業務の流れを意思決定したいステークホルダーミーティングで、こんなことがありました。「ボタンの配置」「ヘッダーの色」など、その時点では仮で作っていた要素にフィードバックが集中してしまい、ミーティングの意図とずれてしまったのです。Figma のワイヤーフレームで議論していたらそうはならなかっただろうと思います。動くものはそれだけで「具体的」に見えるので、抽象度の高い議論をしたい場ではかえって邪魔になることがある、というのが学びでした。
もうひとつは、一度作ったプロトタイプを「壊しにくい」心理が働くことです。
エンジニア視点からすると、プロトタイプはあくまでプロトタイプなので「全然作り直して OK」だと思っているのですが、PdM・デザイナーからするとせっかく動いているものを捨てる心理的ハードルがあるようでした。これは現在進行形の課題で、「プロトタイプは捨てていい」というスタンスをチームで共有することが大事だと感じています。
ロールごとに使い方が違う
「PdM・デザイナーがプロトタイピングする」と一括りに書きましたが、実際にはロールごとに使い方や向き不向きが違うことが見えてきました。
デザイナー
デザイナーがこのやり方にハマる理由は、動くものを自分の手で作れるスピード感と楽しさが大きいようです。「Figma には戻れない」と話す人もいるくらいで、最初は及び腰だった人も、触り始めるとハマっている様子で、新しい働き方として定着しつつあります。
デザイナーの強みは、AI が生成したものをデザインの方向性に沿って修正していくのが上手い点です。自分の中に「こうしたい」というデザインの軸を持っているので、AI とのやりとりを通じて意図に近い形に近づけていくことができます。
PdM
PdM も積極的にプロトタイプを作るようになりました。自分で画面を思い通りに作れることに楽しさを感じているようです。
ただ、ある PdM は「自分で作るとダサい画面にしかならない（笑）」と話していて、実際に余計な要素が多くなっていたり、色がふんだんに使われた画面になっていたりと、デザインの方向性に合わない画面ができてしまうこともありました。最終的にはデザイナーがそれを参考にしながらプロトタイプを作り直す、という流れになることが多いです。
つまり、PdM が作るプロトタイプは「自分の思考を試す」役割として位置づけるのが現状はよさそう、ということが見えてきました。完成形を作るというより、頭の中にある仕様や流れを実際に手を動かして確かめる、という使い方です。
FE 自身の役割
PdM・デザイナーがプロトタイプを作るようになって、フロントエンドエンジニア自身の関わり方も変わってきました。ここまで書いてきた「ガードレールを整える」「ペアプロで伴走する」といった準備・運用の仕事はもちろんあるのですが、それ以外にも新しい関わり方が出てきています。
- デザインの意思決定への理解が深まる: デザイナーがどのように思考してデザインを考えているのか、なぜその意思決定をしているのかを、ペアプロや壁打ちを通じて理解する機会が増えました。これは「Figma 通りに UI を再現する人」だった頃には得られなかった視点です
- 複雑な状態管理を伴う UI の実装: GUI 操作が複雑になり状態管理を慎重に組まないといけない部分は、AI に指示するだけだと組み立てづらいので FE が手を入れます
- コードの共通化・抽象化: プロトタイプでもある程度量が増えてくると、画面間でロジックや UI の重複が出てきます。共通化や抽象化が必要な部分を見極めてリファクタリングするのは FE の仕事として残ります
- 本実装への橋渡し: PdM・デザイナーが作るプロトタイプはあくまでフロントエンドだけで動くもので、API 通信や実データの扱いは入っていません。それを実際のデータと繋ぐとどう動くか、技術的なハードルはないか、を並行して考えるのは引き続きエンジニアの仕事です
イメージとしては、フェーズによってデザイナーの右腕のような立ち位置になることが増えました。デザイナーが思考をダイレクトに UI に反映できるよう、AI への指示の出し方をサポートしたり、コードベース側の制約や可能性を伝えたりする役割です。
これからの課題
ここまでポジティブな変化を中心に書いてきましたが、まだ発展途上の取り組みなので課題もあります。
ひとつは デザインの資産が残らない問題 です。
Figma 中心の開発では、画面デザインが Figma にデザイン資産として蓄積されていきました。一覧で見たり、過去の検討の経緯を振り返ったりすることもできました。プロトタイプをコードで作るやり方では、プロトタイプはいつかなくなり、最終的にはプロダクションコードしか残りません。「過去にどういう検討をしたか」「ボツになった案はどんなものだったか」を振り返るのが難しくなっているのは、デザイナー側の負荷として現れ始めています。
加えて、このやり方を始めてからまだ日が浅いので、長期的に運用したときに何が問題になってくるかも正直まだわかりません。やりながら気づいた課題を都度チームで議論して、運用を調整している段階です。
まとめ
最後にあらためて整理します。
- 従来は Figma で詰めてから FE が再現実装する流れだったが、PdM・デザイナーが AI で実コードベースをプロトタイピングする流れに変わってきている
- それを成立させるためには「環境」「AI を利用するスキル」「コードベース」の3つの準備が必要で、フロントエンドエンジニアが伴走する場面も多い
- 安全に運用するために、ブランチを切って PR レビューする運用と、必須スキルによる制約を組み合わせて事故を防いでいる
- 意思決定の解像度が上がる一方で、議論が細部に引きずられたり、プロトタイプを捨てづらかったりという落とし穴もある
- ロールごとに使い方が違い、PdM は「思考を試す」、デザイナーは「形にする」、FE は「ガードレールの整備・伴走・複雑な実装・本実装への橋渡し」という役割が見えてきた
- デザイン資産の蓄積や長期運用の知見はまだこれからの課題
プロトタイプは誰が作ってもよくて、そのほうが早く意思決定できることがわかってきました。一方で、フロントエンドエンジニアとして大事な保守性を考慮した設計・実装・テスト・改善の仕事はなくなりません。むしろ Figma 通りに CSS を微調整する時間が減って、より上流の意思決定や品質担保に時間を使えるようになったのは、個人的にはいい変化だと感じています。
カケハシでは現状こうしている、というひとつの実践例として参考になれば嬉しいです。
