はじめに
こんにちは！mento のエンジニアの @kadoppe です。
現在 mento では、新事業として マネジメントサクセスプラットフォーム の立ち上げに取り組んでいます。最近、仮説検証をさらに加速させるために、チームで「動くプロトタイプ」を作りました。
本記事では Cursor を活用して動くプロトタイプを高速開発している間に体験した「うまくいった点」や「失敗した点」を、開発を主に担当していたエンジニア（僕）の視点からお伝えします。
同様にスタートアップで新プロダクトの開発に取り組まれている方、Cursor などの AI コーディングツールを活用して、短期間でのプロトタイプ開発を検討している方の参考になれば幸いです。
背景と課題
「スタートアップとは、崖の上から飛び降りながら、飛行機をつくるようなもの」と言われています。今よりも少しでも素早く検証を進め、新しい事業やプロダクトの立ち上げを少しでも早いタイミングで実現することがスタートアップにとっては重要です。
そんなことをチームで議論している中で、「実際に動くプロトタイプを作ろう!」というアイデアが挙がりました。動くプロトタイプに期待していたことは以下のようなものでした。
- 動くプロトタイプがあることで、社内で議論するときの拠り所が生まれ、議論が空中戦になりすぎることを防ぐことができる
- 動くプロトタイプをお客様に対してデモすることで、事業や仮説検証を手応えとともに素早く進めることができる
チームで合意し、それまでに議論していた課題仮説・解決策仮説、ユーザーのペルソナや、カスタマージャーニーをもとにして、動くプロトタイプを開発することになりました。
しかし、プロトタイプを開発するにあたって、以下のような課題がありました。
- プロトタイプ開発に使える期間は、先に確定していたお客様との商談までの 2 週間弱と短いものでした。
- プロダクトのワイヤーフレームやデザインはまだほとんどなく、コードに関しては１行も存在していないという状況でした。
- チームで議論したプロダクトコンセプトや仮説、ペルソナやジャーニーはまだブラッシュアップの余地があり、プロダクトの要件としてはまだ明確になっていない状況でした。
- 仮説検証に必要な機能が多く、開発ボリュームは比較的大きいものでした。
この状況を突破するためには従来の開発手法では間に合わないと考え、Cursor などの AI コーディングツールを使ってプロトタイプを爆速で開発していくことにしました。
プロトタイプ開発の流れ
プロトタイプ開発は以下のような流れで進めました。
-
デザイン: デザイナーが現状の課題仮説・解決策仮説を踏まえつつ、事業オーナーである CEO、PdM との議論を通して、カスタマージャーニーやワイヤーフレーム、デザインを Figma 上に作成する
-
実装: その Figma をもとにエンジニア（僕）が動くプロトタイプを開発していく
-
フィードバック: 開発途中のプロトタイプもインプットにしつつ、CEO、プロダクトマネージャー、デザイナーが、さらに仮説、カスタマージャーニー、ワイヤーフレームをアップデートしていく
-
継続的改善: アップデートの内容をエンジニア（僕）がプロトタイプに反映。このサイクルを何度も繰り返す
-
最終調整: 開発終盤でフロントエンドエンジニアを巻き込み、UI や UX の作り込み・仕上げを行う
僕も含めた多くのメンバーがそれぞれの役割を持って、各ステップを並行して進めながら、頻度高く・密に同期をするような形でプロトタイプ開発は進みました。
使用した技術とツール
開発ツール
-
Cursor:
- メインの IDE・エディタとして利用しました。
- mento の開発チームでは他にも Devin が幅広く活躍していますが、今回はインタラクティブにプロトタイプを開発したかったので、個人的に手慣れていた Cursor を選択しました。
-
Framelink Figma MCP server:
- https://www.framelink.ai/
- Figma 上に作成されたワイヤフレーム・デザインをもとに、UI の実装を自動化し、プロトタイプの初期開発スピードを加速させる目的で利用しました。
- プロトタイプ開発期間中はまだ Figma公式のMCP Server が公開されておらず、サードパーティーの MCP Server を採用しました。
-
Claude 3.7 Sonnet → Claude 4 Sonnet
- Cursor 上で主に利用した LLM。
- プロトタイプ開発期間中に Claude 4 Sonnet が公開され、性能向上を実感できたため途中で乗り換えました。
技術スタック
開発スピードを保つため、技術選定は極力シンプルにしました。
-
pnpm Workspace:
- https://pnpm.io/workspaces
- LLM にプロトタイプ全体のコンテキストを渡しやすくする目的で、フロントエンドとバックエンドのコードをモノレポ構成で管理するために利用しました。
-
言語: TypeScript
- 静的型付けを利用して、LLM が生成するコードの品質を担保するために採用しました。
- フロントエンド: React (Vite の react-ts テンプレート)
- バックエンド: Express
-
Linter / Formatter: Biome
- 動作が高速であることで、LLM がコードを生成している最中の待ち時間が短縮できることを期待して採用しました。
- インフラ: CloudFlare Pages、Render
振り返り
結果として、何とか動くプロトタイプが形になりました。また、プロトタイプを使って、当初の目的だった事業やプロダクトに関する検証の高速化も実現できました。
ここからは、プロトタイプ開発中に「うまくいったこと」と「改善できること」についてそれぞれ紹介します。
うまくいったこと
1. 全ての機能をコードで実装しようとしない
プロトタイプの作り方にも色々あります。
- (A) ユーザーが Web ブラウザで実際に利用できるプロトタイプ。ユーザーのインタラクションに応じて、ユーザーに対してリッチなフィードバックや結果を提示できる。
- (B) Figma 上で作られたプロトタイプ。決められたいくつかのシナリオを実現するインタラクティブなフローを構築・検証できる。
- (C) プレゼンテーション資料にスクリーンショットを貼り付けただけのプロトタイプ。画面遷移のイメージを作り、検証できる。
今回はプロダクト全体の機能数が多く、全てを(A)のプロトタイプとして開発する時間がありませんでした。そこで、以下のような議論を重ね、コードを書いてプロトタイプを開発する必要がある部分と、そうでない部分を明確に分けました。
- 「この機能はリアルなインタラクションを実体験してもらい、反応を得ることが検証上重要だから、実際にコードを書いてプロトタイプを作ろう」
- 「この機能はクリックとともに画面に表示される情報がどう変化するのかを理解してもらうことが検証上重要だから、Figma のプロトタイプ機能を使おう」
AI コーディングツールを使って開発速度や生産性は劇的に向上します。ただし工数が"ゼロ"になるわけではありません。つい「全部 Cursor で作ろう」と躍起になってしまいがちですが、プロトタイプを開発する本来の目的を忘れないようにしないといけません。
結果として、議論や作り込みにかける時間を、本当に重要な時間に集中させることができ、プロトタイプ全体としての品質を高めることができました。
2. Linter / Formatter / Type Checkを活用する
LLM が生成したコードの品質を担保するために、Linter / Formatter / Type Check を活用しました。具体的には以下のような Cursor Rule を作成し、常に利用されるようにしました。
## 利用しているLiner / Formatter
- biome を使用しています
## 開発時のルール
- コードを変更した際は、最後に必ず type-check と lint と format と build を実行するようにしてください
- lint と format でエラーが発生した場合は、エラーが解消するまで修正を繰り返してください
## type-checkの実行方法
`pnpm run type-check`
## lintの実行方法
`pnpm run lint`
## formatの実行方法
`pnpm run format`
## buildの実行方法
`pnpm run build`
このルールによって、LLM がコード生成後に必ず Linter / Formatter、型チェックを実行してくれるようになりました。結果として、
- 突然プロトタイプが不具合で動かなくなる
- 可読性の低いメンテナンス不能なコードが生まれる
といったことが発生しづらくなり、トラブルシューティングに時間を取られることが減りました。
プロトタイプのより本質的な部分に時間と集中力を使うことができたため、プロトタイプの品質も高めることができ、本来の目的だった事業・プロダクトに関する検証の加速も実現できました。
3. モノレポ構成
今回のプロトタイプはサードパーティの SaaS やプラットフォームの API を利用するものだったので、ユーザーインタフェースだけでなく、バックエンド API も合わせて開発する必要がありました。
先述の通り、今回のプロトタイプ開発では pnpm Workspace を使って、フロントエンドとバックエンドをモノレポ構成で管理していました。（以下イメージ）
├── README.md
├── package.json
├── pnpm-workspace.yaml
├── frontend/
│ ├── README.md
│ └── package.json
└── backend/
├── README.md
└── package.json
モノレポ構成により、 Cursor から LLM に指示を 1 つするだけで、例えば以下のような実装を一気通貫で生成させることができました。
- バックエンドの API の実装
- フロントエンドでの該当 API を呼び出すクライアントコードの実装
- 該当 API から取得した React コンポーネントでのデータレンダリング
また、フロントエンドで発生したランタイムエラーを修正する指示を LLM にすることで、バックエンド API の仕様を確認したり、必要ならバックエンド API の実装を修正するような動きも実現できていました。
Cursor 0.50 (2025.5.10リリース） で、「multi-root workspaces」が正式にサポートされたので、今後はフロントエンド・バックエンドのコードが複数のリポジトリに分かれていても、上記のようなことが実現できるのかもしれません。今後も引き続き検証していけたらと思います。
改善できること
1. Figmaのデータの構造化と、Cursor上でのプロンプトの改善
先述の Framelink Figma MCP server を利用して、Figma 上に作成されたワイヤーフレームのデータをもとに、UI コンポーネント初期実装の自動化を試みました。ですが、実際にやってみるとデザインの再現性が期待していたよりも低かったです。
生成された UI コンポーネントのデザインが、margin や padding が想定と違っていたり、そもそも画面全体のレイアウトや配置場所が大きく異なり、Figma のデザインとかけ離れてしまいました。結果としてプロトタイプ開発終盤で、デザインや UI の最終調整の工数が嵩み、途中から協力いただいたフロントエンドエンジニアの方の負担を大きくしてしまうことになりました。
後になって（プロトタイプの開発中盤ごろ）、Framelink Figma MCP serverの公式ドキュメント に Best Practice として以下のような記載があることに気づきました。
Generally speaking, you'll want to structure your Figma file in a way that makes it easy to understand and implement.
- Use auto layouts—the MCP isn't great at handling floating or absolutely positioned elements just yet
- Name your frames and groups
- Protip: Try Figma's AI to automatically generate names
人間や LLM が理解・実装しやすいように、「Figma 上のデータをうまく構造化しよう」「auto layout を活用しよう」「frame や group にはわかりやすい名前をつけよう」といったことが書かれています。
今回のプロトタイプ開発では開発期間が短く、また焦っていたこともあって、エンジニアとデザイナーの間でやり取りするアウトプットの内容や構造についてすり合わせをしっかり行わず、僕がいきなり開発作業に取り掛かってしまいました。これらの Best Practice を参考に、Figma 上のデータの作り方についてすり合わせておけば、より高い再現性で UI コンポーネントの初期実装を自動化できたかもしれません。
また、Cursor 上で LLM に指示を出す際の Best Practice についても記載がありました。
The overall key in managing any LLM is to provide the correct context. That's what the Framelink Figma MCP server helps with, but you'll need help your editor to get all the context you need to be successful.
- Let the agent know what resources are available to it (e.g. Tailwind, React)
- Reference key files in your codebase to provide additional context
- Provide written details about the design in addition to the raw data from Figma
- Manage context size—provide links to frames and groups instead of the whole file
Figma のデータだけでなく、デザインについての詳細情報も追加でプロンプトに加えることが重要だと記載されていますが、それを全くやっていなかったことも反省点です。以下は、プロトタイプ開発初期に僕が LLM 伝えたプロンプトの例です。
@https://www.figma.com/design/xxxxxxxxx/hoge?node-id=fuga&m=dev
上記Figmaのワイヤーフレームをトップページに実装して
全くデザインに関する追加情報をプロンプトに記載できていませんね（反省しています）。
- 事前に使うツール（MCP 含む）の公式ドキュメントに目を通し、ベストプラクティスなどを確認しておく
- その上で、プロトタイプ開発に関係する他のメンバー含めて共通認識にし、個人ではなくチーム全体の開発速度を最大化するための、事前のすり合わせ・ルール極めを行う
いくら、開発期間が短いとはいえ、こういった事前準備を初期段階でしっかり行なっておくことが、最終的なプロトタイプの質は開発速度を担保するために重要だと再実感しました。
Figma公式のMCP Server がつい先日公開されたので、こちらも引き続き検証していけたらと思います。
2. LLM向けガードレールの事前設計
今回のプロトタイプ開発で採用した技術スタックについては上述した通りです。シンプルな構成を心がけたのですが、逆にいうとそれ以外のことは何も決めずに、最初から Cursor に指示を出して開発をスタートしました。
結果として、多くを決めなかったが故に、人間・LLM の双方にとってメンテナンス性の低いコードが生成されてしまいました。以下に発生した問題の例を挙げます。
- CSS の影響が意図したコンポーネントに閉じず、影響がグローバルに波及してしまう状態に。
- → LLM から「スタイルを修正しました」と報告を受けても、ほかの UI コンポーネント用のスタイルの影響を受けて、画面から確認するとスタイルが変わっていない / 意図しないものに変わっている。
- バックエンドの API にアクセスするための API クライアントのようなコードがフロントエンドの複数箇所に複数存在する。
- → フロントエンドからバックエンドの特定 API を呼び出すコードを書く指示を LLM に出すと、どの API クライアントを利用するかがほぼランダムに決まってしまう。
- １つの UI コンポーネントの粒度が大きく、コンポーネントが単一責任の原則に基づいて適切な粒度に分割されない。
- → あるコンポーネントの一部の挙動を修正する指示を LLM に出すと、そのコンポーネントの意図しない部分の挙動まで変更してしまう。
上記のような問題が顕在化するたびに、Cursor Rule を作成・更新し、場当たり的に対応していました。ですが、「Cursor Rule を記述→ルールに則る形でコードベース全体のリファクタリングを実施→本来の開発に戻る→また別の問題が顕在化」を繰り返していたため、プロトタイプの本質的な部分の開発にかけられる時間が相対的に少なくなってしまいました。
1〜2 日でプロトタイプ開発が終わるのなら大きな問題にはなりませんが、1〜2 週間といった開発期間が少し長くなる場合は AI コーディングツールを使うとしても、コードのメンテナンス性・可読性は非常に重要です。でないと、開発期間後期に差し掛かるにつれて、どんどん開発速度が遅くなっていくリスクがあります。また、プロトタイプ開発に途中から他のエンジニアを巻き込む場合は、可読性やメンテナンス性が大きな問題となり、引き継ぎやキャッチアップを難しくしてしまう問題も発生します。
プロトタイプ開発に使う技術スタックや、その際に採用する設計指針、コーディング規約などは事前にテンプレートを用意しておき、いざという時にすぐに利用できるようにしておくことが重要だと感じています。今回も、開発着手前に、少し立ち止まってこれらのことを検討していれば、また違った結果になっていたのではと考えます。
おわりに
今回の経験を通して、AI コーディングツールを活用した高速プロトタイプ開発の可能性・価値を実感できました。
短期間でプロトタイプを開発できたことで、「議論してから作るのではなく、作ってから議論する」という状況が実現できました。これにより仮説検証のスピードが加速され、アイデアや仮説を何段階もブラッシュアップでき、さらに価値あるプロダクトの実現に近づくことができました。
一方で、主に準備不足が原因となって、AI コーディングツールのポテンシャルを最大限発揮できなかったという課題にも直面しました。開発期間が短く、スピード重視な状況では、ついまず手を動かすことに集中してしまいますが、適切な準備があってこそ開発速度が最大化できることを実感しました。
同様に、スタートアップで新プロダクトの開発に取り組まれている方、短期間でのプロトタイプ開発を検討している方の参考になれば幸いです。
お知らせ
mento では、新事業・プロダクトの立ち上げに一丸となって取り組むエンジニアの仲間を募集しています！
少しでも興味がある方、ぜひ最初はカジュアルにお話しさせてください！（各種 SNS でも DM いただければすぐ反応します！）
Discussion
実際にようけんからプロトタイプ開発までされた方の記事で、非常に参考になりました。