こんにちは！ourlyに10月入社＆ドキドキ初投稿、大天使カリンエルです（@archkrnel）
この記事はourly Advent Calendar 2025🎄 22日の記事です。
前回は、弊社エンジニアのつっちーさん(@ourly_nobuo)の「AI活用のプロトタイプ実装で「全体最適」を先に攻略し、開発者体験が爆上がりした話」でした。
ourlyでは実装工程以外のフェーズにおいてもAIを活用できないかを模索しており、その一環として実装工程の前段階でAIを活用したプロトタイピングにトライしております。
私はつっちーさんとは別のチームで開発しているので、また別の角度からプロトタイプを作成してみた結果わかった、
- 実際にやってみて良かった点
- いまいち活用できなかった原因
についてお話しします。
検証した環境とやったこと
前提
- 実現したい機能要件は決まっている
- Figmaのデザインは概ね完成している
- 開発規模：約2スプリント（4週間）
使用したツール
- Cursor (Claude Code)
- Figma MCP (Figmaの情報を直接取得・操作できる機能)
実施内容
CursorからFigma MCPを利用してデザインデータを読み込ませ、フロントエンドの実装を行いました。
バックエンドとの接続は行わず、Mockデータを使用して画面が表示され、動作するところまでを2〜3日で作りきりました。
試してみた結果
今回の検証を通じて、
Figma MCPとCursorを活用することで、フロントエンド実装2スプリント分に相当する画面を、2〜3日で「動く状態」にすることは十分に可能であることが分かりました。
また、作ったプロトタイプをもとに画面仕様書を作成できたので、ドキュメントを自分で作る手間が省けた点は効率的だったなと感じました。
一方で、作成したコードを本番開発に活用するのが難しく、結局本番用にコードを新しく作り直すことになってしまいました...
作ってみて感じたプロトタイプの利点
1. 「動くもの」を見ながら仕様を詰められた
ここが1番のメリットですね。
プロトタイプを作成することで画面仕様も固まっていったので、本番コードの実装に集中できた体感があります。
本開発を始める前に「実際に動く画面」を見せることができたため、まだ固まっていなかった仕様に関しても、画面で表示や挙動を確認しながらPO（プロダクトオーナー）と議論を深めることができました。
Figmaデザインでもある程度イメージはつくのですが、動くものがあったほうが話がしやすくなります。
2. 未知のコードベースでも理解が進みやすかった
入社2ヶ月目でまだ全体の構造を把握しきれていない中、AIの実装を参考にすることで、現行仕様のキャッチアップが非常にスムーズでした。
今回は初めて触れる箇所だったので、特に役立った実感があります。
なぜ「使い捨て」に終わってしまったのか
仕様詰めには多少役に立ったものの、いざ「じゃあこれを本番コードとして仕上げよう」となった時には、作ったコードのほとんどをそのまま使うことができませんでした。
1. 既存機能と分けて表示する新機能だったのに上書きしてしまった
今回は既存の表示は残しつつ、Feature Flagのような設定で新機能を出し分ける必要がありましたが、AIにプロトタイプ作成を指示する際、スピード重視で既存の構造を「上書き」する形で作ってしまっていました。
（もし既存機能の変更であれば、ここから本番コードにリファクタしていくことも可能だったかと思います）
今回は後で切り出して分岐処理を入れないといけなかったため、本番コードに変換するのが難しくなってしまうという結果に...
❌ 上書きパターン
// Button.tsx - 既存コードを直接変更
export const Button = () => {
return <button className="new-style">新デザイン</button>;
};
✅ 別コンポーネント + 出し分けパターン
// Button.tsx - 既存のまま
export const Button = () => {
return <button className="old-style">既存</button>;
};
// ButtonNew.tsx - 新規作成
export const ButtonNew = () => {
return <button className="new-style">新デザイン</button>;
};
// 使う側で出し分け
{featureFlag ? <ButtonNew /> : <Button />}
最初から「別ファイル」や「別コンポーネント」として切り出して作っておけば、次工程の実装に繋げやすかったと思います。
2. データ設計が不十分だった
今回はフロントエンドのみをMockで作りましたが、バックエンドと連携するデータ構造を考慮せずに進めてしまい、フロント側でデータの加工を行ってしまっていました。
本番コードに変更する際に、バックエンド側でフロントエンド側で扱いやすいデータ構造に整えてから連携していただくことになったため、関連箇所は全て手直しする必要がありました。
ここも速度優先で作ってしまっていたためですが、データ構造の認識合わせをしておけばスムーズだったかなと思いました。
教訓：AI時代こそ「目的」の明確化が必要
「プロトタイプめっちゃ早くできたけどな〜んかいまいち活用できなかったなぁ」とモヤモヤしていたのですが、弊社EM神本さんの記事「プロトタイプは“最初のデッサン”──モナリザ式で進めたらプロジェクトが速くなった」の内容と比較して気がつきました。
私は「仕様の爆速検証」用のプロトタイプを作っていたのに、「実装の土台作り」用のプロトタイプと混同していたのです。
先述の神本さんの記事より引用ですが、プロトタイプには検証すべき目的があります。
- 価値リスク (ユーザーはそれを買ってくれるか?)
- 使いやすさリスク (ユーザーはその使い方をわかるか?)
- 実現可能性リスク (私たちのエンジニアはそれを作れるか?)
- 事業実現性リスク (ステークホルダーたちの支持が得られるか?)
今回、プロトタイプを「価値・使いやすさ（仕様）」の検証としては使うことができましたが、仕様やデザインが事前検討されていたため、大きな恩恵を感じることができなかったのだと思います。
一方、「実現可能性（実装の土台作り）」としては、作り方が粗すぎて役に立ちませんでした。
AIを使ってプロトタイプを作るということに気を取られていましたが、何を目的とするかによって作るものは分けるべきだったのです。
じゃあどうすればよかった？
今回は 「仕様の爆速検証」用のプロトタイプを、「実装の土台作り」用のプロトタイプとして使おうとしてしまったところに問題 がありました。
また、要件やデザインが概ね決まっていたこともあり「仕様の爆速検証」用としても大きく活用はできませんでした。
逆に、デザインがワイヤーフレーム程度しかない場合であればもっと活用できていたかと思います。
もしやり直すのであれば「仕様の爆速検証」用のプロトタイプは確認用にサッと作って使い捨て、その後に多少時間をかけて「実装の土台作り」用のプロトタイプを作成したいです。
動きを見てイメージをしたいだけであれば、Figma Make（FigmaのAIツール）で作った簡易的なプロトタイプで良いかもしれません。
まとめ
今回の検証を通じて、CursorとFigma MCPを組み合わせた実装スピードには、正直驚かされました。
しかし、「AIが高速でコードを書いてくれる」ことと、「プロジェクト全体が効率化される」 ことはイコールではありません。
AIで業務効率化が進む中、「何のためにそのコードを書かせるのか」 という目的を握っておく必要があります。
- 仕様を握りたいのか（＝コードは捨ててもいいから最速で）
- 実装を楽にしたいのか（＝設計や整合性を重視して丁寧に）
この「目的」を着手前に明確にし、AIへの指示出し（プロンプトや文脈共有）を使い分けることこそが、AI時代のエンジニアに求められる新しいスキルなのかもしれません。
Discussion