生成AI×Cursorで爆速開発！新卒1年目が6つのデモアプリで学んだ Vibe Coding 実践録
0. はじめに
こんにちは、クラウドエース第四開発部の永井です。
現在、私は Vibe Coding に強く魅了されており、日々の開発業務でも積極的に活用しています。
新卒として入社してから半年ほど経ち、実際に案件へ参画してからは約 4 か月になりますが、その間に Vibe Coding と生成 AI（今回は主に Cursor）を活用して 6 つのデモアプリを開発してきました。
これらは社内外で高い評価をいただくことも多く、「なぜ短期間でここまで作り込めるのか？」と聞かれる機会も増えてきました。
そこで本記事では、私がどのように生成 AI を活用して高速にアプリケーションを作っているのか、そして Vibe Coding が開発体験をどう変えてくれたのか を、実体験ベースで紹介していきます。
1. まず Vibe Coding とは？
Vibe Coding（バイブコーディング）は、生成 AI に「こんな感じで動いてほしい」という雰囲気（Vibe）を伝え、出てきた結果を見ながら方向を調整していく開発スタイルです。
一見すると“簡単そう”に思われがちですが、実際に使ってみると
独特のつまずきポイントや、乗り越えるためのコツ（ヒント） が多くあります。
この記事では、自分が Vibe Coding を使ってデモアプリを作りまくる中で気付いた
「どこでハマるのか」「どう突破したのか」 を中心に紹介していきます。
2. V0 を使ってチームのイメージを即共有すべし
今回担当したデモアプリは、やりたいことだけ決まっていて、具体的な機能や画面イメージがまだ固まっていない状態から始まるケースが多くありました。
その結果、会議では「こうしたい」「こんな感じがいい」など抽象的な話が続き、なかなか前に進まない状況が発生します。
そこで役立つのが、フロントエンドの試作に特化した V0 です。
コツその 1：議事録とセットで V0 を使うべし
会議中に取った議事録をそのまま V0 に入力すると、
その場で “仮のフロントエンド” が生成され、即イメージ確認ができるようになります。
まさに、ライブクッキングならぬ ライブコーディング です。
「この画面の雰囲気で合っていますか？」
と会議中に共有できるため、そこを起点に議論が具体化し、抽象論の空中戦が一気に減ります。
ポイントは “会議中に作ること” です。
会議後に 1 人で作ると、どうしても自分の解釈バイアスが入り、次の会議で
「なんか違う」
と言われるケースが多くなります。
フロントエンドが固まったら、生成された画面をスクショして Cursor に
「これを再現して」
と指示すると、ほぼ同じ UI を再現したコードを生成できます。
ここでよく聞かれるのが、
「じゃあ V0 のコードをそのまま使えばいいのでは？」
という点ですが、結論として 直接使わないほうが後工程での負担が少ない です。
なぜ V0 のコードを使わないのか？
- V0 が生成するコードは便利な反面、
独自の構成や依存が多く、扱いづらいことがある - 特に Python でバックエンド（例：チャットボット）を構築する場合との相性があまり良くない
- CSS の構成やコンポーネント構造が複雑で、
後の改修・機能追加で手間が増えやすい
そのため、
V0 →（スクショ）→ Cursor に再構築させる
という流れにすると、
- コードがシンプル
- バックエンド連携しやすい
- デバッグしやすい
- 後々の保守がかなり楽
というメリットがあります。
結果として、
“UI のイメージは V0 で固める、コードは Cursor で再構築する”
という使い分けが最も開発効率が良いと感じています。
3. Ask モードを使うべし
Cursor には 3 つのモードがあります。
- コーディングから相談まで幅広く対応する Agent モード
- 実装方針の設計を任せられる Plan モード
- 思考の整理に特化した Ask モード
特にやりがちなのが、いきなり Agent モード を使い始めてしまうことです。
自分もここで大きくつまずきました。
「伝わっているはず」と思い込み、そのまま進めると、実は根本からズレていて後戻りが一気に増えてしまいます。
これを避けるためにまず使うべきなのが Ask モード です。
Ask モードでは、自分の構想を言語化したり、
- この進め方で問題ないか
- 認識にズレがないか
- 足りない観点はどこか
といった形で AI に質問させることができます。
ここで十分に対話しておくことで、
自分と AI の認識を揃え、以降の方向性を明確に決めることができます。
コツその 2：md ファイルを多用すべし
現在、Cursor で最も高性能なコーディングモデルである Sonnet 4.5 は、
長期記憶を持ち、複雑な開発にも耐えられる非常に強力なモデルです。
しかし、
コーディング → テスト → エラー修正 → テスト → 再コーディング…
と繰り返していくと、どうしても方向性を見失いがちになります。
そこで役立つのが md ファイル（Markdown）での指針管理 です。
- このプロジェクトのルール
- 画面仕様
- API 設計
- 命名規則
- 目標とする動作イメージ
などを 1 つの md ファイルにまとめておく と、
モデルが常にそれを参照して進められるため、方向修正が非常に簡単になります。
しかも、これを 自分で書く必要はありません。
Cursor に向かって
「これを md ファイル形式でまとめて」
と一言添えるだけで、きれいに整理された指針ファイルが完成します。
エージェントの迷走を防ぎ、長期開発を安定させるための
必須テクニック と言っても過言ではありません。
4. 生成 AI は一つにこだわるな。複数を使いこなすべし
Vibe Coding では、開発中にエラーや想定と異なる挙動に遭遇することがよくあります。
多くの場合はすぐに修正できますが、まれに エラー修正の無限ループ に陥るケースも存在します。
初心者（自分も含む）がやりがちな例として、
◯◯ でエラーが発生しています。直してください。
<エラーコード>
を同じモデルに延々と投げ続けてしまう、というものがあります。
最新モデルなら表面的には解決できそうに見えますが、実際には
暴走して関係ないデータやデータベースを削除する といった危険な挙動を取る場合すらあります。
特に 同じエラーが 3 回続く場合は要注意 です。
解決策：複数の生成 AI を併用する
こうした問題を回避するために効果的なのが、複数の生成 AI ツールを併用することです。
Cursor だけに依存せず、別のモデルにもエラー内容と対象コードを渡して解析してもらうことで、
まったく新しい視点からの 修正方針や原因特定のヒント を得られます。
方法（とても簡単）
- 発生しているエラー文
- 関連するコード
この 2 つをセットで、ChatGPT / Gemini / Claude など別の AI に投げるだけです。
これにより、単一モデルでは解決できなかった問題でも、
「別 AI の視点」 から突破口が生まれることがあります。
コツその 3：ここでも md ファイルを活用すべし
コツその 2 では「保存」のために md ファイル を使いましたが、
ここでは エラーの状況を“伝える”ために md ファイル を使う のがおすすめです。
対象コードが多く、どこでエラーが出ているのか分からない場合は、
Cursor に対して次のように指示するだけで OK です。
今発生しているエラーと、これまで試した対策を md ファイルでまとめて。
これで エラー状況・発生箇所・試した対処方法 がきれいに整理された md ファイルが生成されます。
その md ファイル をそのまま Gemini や ChatGPT に渡せば、
別視点からの新しい解決案が提示されるので、それを Cursor に戻して修正すれば完了です。
自分はこの方法で ほとんどの問題を解決できました。
5. コードは Cursor、アイディアは自分で考えるべし
Cursor はコーディング能力が非常に高く、「◯◯ を実装して」と指示すれば、多くの場合はほぼ完成形の機能を作成してくれます。
しかし問題なのは、アイディア（方針）を自分で決められない という点です。
一度提示した方針から大きく外れる思考は苦手で、
その結果 一部機能だけが永遠に完成しない状態 に陥ることがあります。
例：Cloud Run のアップロード制限
Cloud Run には 32MB のアップロード制限 があります。
例えば、60MB のプレゼン資料をレビューしたいときにこの問題が発生します。
Cursorに「60MB のファイルをアップロードしたいが失敗する。解決策は？」
と聞くと、多くの場合は次のような返答になります。
「ファイルを分割してアップロードしましょう」
しかしこの方法だと、
- 前後関係を維持する処理
- 分割と結合のロジック
など、追加の手間が増えてしまい、そもそもの目的から外れる ことになります。
ここで重要なのが “ユーザー側のアイディア”
本来の解決策は非常にシンプルです。
- 一度 Google Cloud Storage（GCS）にアップロード する
- 生成された URL を参照 すれば大容量ファイルでも処理可能
しかし、このような “ルート変更” の発想を
Cursor が自動で思いつくかどうかは 確率の問題 です。
だからこそ、
ユーザー自身が最低限の知識と選択肢を持っておくことが重要 になります。
AI はコードを書くのが得意ですが、
何をどう作るかという “アイディアの転換” は、依然として人間の役割 です。
コツその 4：思いついたら即 ASK モードで聞くべし
「あれ、なんか止まってるな…」
「行き詰まってきたかも…」
こう感じたら、迷わず ASK モード に切り替えるのがおすすめです。
自分が思い描いている機能・アイディア・やりたいことを
そのまま ASK に投げるだけで、
最適な方向性や別の選択肢を提示してくれる可能性が一気に高まります。
Cursor はコード生成に集中するツールですが、
ASK モードは “アイディアの棚卸し” に向いているため、
自分の思考の詰まりが一気に解消することも珍しくありません。
6. チームでのコーディングでは新しい開発方法を受け入れるべし
従来の開発では、フロントエンド・バックエンド・データ処理など、
領域ごとに分かれた分担型の開発 が一般的でした。
しかし、Vibe Coding では生成 AI を駆使することで、
フロントからバック、データ構築までを一人で開発することも可能 になっています。
この変化によって、チーム開発では「機能単位で進める」方が効率的になりつつあります。
つまり、これまでのように「担当領域」で区切るのではなく、
“機能ごと”にチームメンバーが動く という新しい開発スタイルが求められています。
コツその 5：メインコーダーとサブコーダーを分けて動くべし
これはあくまで自分の持論ですが、
チーム内で 「メインコーダー」 と 「サブコーダー」 の 2 つの役割を明確に分けることで、
Vibe Coding の開発効率をさらに高められると感じています。
メインコーダーの役割
- 最初にアプリの大枠（UI 構成・画面遷移）を作成する
- データベースのスキーマ（構造）を設計する
- サブコーダーが開発した機能を統合し、アプリ全体をまとめ上げる
サブコーダーの役割
- 個々の機能（例：チャット機能、ログイン、分析画面など）をピックアップして開発する
- 完成したコードをメインコーダーに渡して統合してもらう
- データベースの変更は極力行わず、定義された構造の範囲で開発 する
このように、メインが全体を設計・統合し、サブが機能を量産する という流れを確立することで、
迅速かつ高精度なアプリ開発が可能になります。
また、ここでも md ファイルが大活躍 します。
サブコーダーが機能を完成させたタイミングで、
「今回作成したコードの説明を md ファイルでまとめて」
と指示するだけで、簡単に作業報告書が完成します。
メインコーダーはその md ファイル を Cursor に読み込ませるだけで、
仕様や実装意図を正確に把握したうえで統合作業ができる ようになります。
結果として、
- 情報共有のコストが大幅に減る
- コードレビューがスムーズになる
- 統合時の不整合が減る
といった効果が得られます。
7. まとめ：「魂で書く」Vibe Coding という開発スタイル
ここまで、僕が新卒 1 年目で Vibe Coding と Cursor を使い倒してきた中で感じた
「実際ここがキモだったな」というポイントを書いてきました。
ざっくり振り返ると、Vibe Coding をうまく回すために大事なのは、次のような考え方でした。
-
V0 でまず “見た目のイメージ” を合わせる
→ 会議中に仮フロントを出して、抽象論の空中戦を終わらせる。 -
Ask モードで “言葉と前提” をそろえる
→ いきなりコードを書かせず、まずは構想・要件を一緒に整理する。 -
md ファイルで “プロジェクトの共通脳” をつくる
→ 仕様・ルール・エラー状況・作業報告を Markdown に集約する。 -
生成 AI は一つにこだわらない
→ エラー無限ループにハマったら、別の AI に相談して突破口を探す。 -
コードは Cursor、アイディアと判断は自分が握る
→ ルート変更・アーキテクチャ選択は、まだまだ人間の仕事。 -
チーム開発ではメイン／サブという役割を決めて動く
→ メインが設計と統合、サブが機能量産。md ファイルで仕様共有していく。
Vibe Coding は、「AI に任せれば全部なんとかなる」という魔法ではありません。
むしろ、
- 自分のイメージをどれだけ言語化できるか
- AI にどこまで任せて、どこから自分で舵を取り直すか
- チームの情報をどう整理して共有するか
といった 人間側のスキルや姿勢 が、これまで以上に問われる開発スタイルだと感じています。
それでもなお、うまくハマったときの開発体験は本当に気持ちよくて、
「自分 1 人じゃ絶対にここまで作れなかったな」と思える瞬間が何度もありました。
この記事で紹介したコツが、
これから Vibe Coding に挑戦する人、
あるいはすでに使っているけど「なんかしっくりこない」と感じている人の
ちょっとした参考や助け になれば嬉しいです。
もしこの記事を読んで
「うちの案件だとこう使えそう」
「ここは自分はこうしている」
といったフィードバックや体験談があれば、
ぜひどこかで教えてもらえるとめちゃくちゃ喜びます。
最後まで読んでいただき、ありがとうございました。🔥
Discussion