Vibe Coding実践を通して感じた「勘所」
Vibe Coding、してみたくないか
「Vibe Coding」という言葉を聞いたことはあるでしょうか?
最近話題の AI を活用した開発手法の一つですが、実際に体験したことがなかったので、一つのアプリケーションを最初から最後まで作ってみました。
本記事では、実践を通して得られた知見と、これから Vibe Coding に挑戦する方へのアドバイスをまとめています。
Vibe Coding とは
OpenAI の Andrej Karpathy が提唱したコーディング手法です。
従来の厳密な設計・仕様策定を重視する開発とは異なり、AI との対話を通して試行錯誤しながら直感的にコーディングを進める手法です。
「雰囲気開発」とも呼ばれるように、ノリと勢いで AI に実装させながら、徐々にアプリケーションを完成させていくスタイルが特徴的です。
なぜ Vibe Coding に挑戦したのか
挑戦の理由は明確でした。AI エージェントを活用した開発が主流になりつつある中、実際の体験がなかったためです。
今回の実践を通して、以下の 2 点を明らかにしたいと考えました:
- AI エージェントでどの程度のことができるのか
- 効果的な AI 活用に必要なスキル・知識・ドキュメントは何か
実践
開発したアプリケーション
毎日の健康タスクをクエストとして管理し、達成することで経験値を獲得できる RPG 風アプリケーションを開発しました。
このアプリを作ろうと思ったきっかけは、最近の怠惰な生活への反省と、YouTube で見かけた「冷蔵庫にタスクを書いて達成するとレベルが上がる」という海外の取り組みでした。これをデジタル化できれば面白いのではと考えました。
実験の制約条件
学習効果を最大化するため、以下の制約を設けました:
制約 1:未経験の技術スタックを使用する
AI エージェントがどの程度浅い知識をカバーできるか、また未知の技術についてどのような学習支援が可能かを検証するためです。
制約 2:コーディングは極力 AI に任せる
人間は指示役に徹し、コードは基本的に書かない方針としました。
ドキュメント作成に集中することで、効果的な AI 指示の方法論を探ることが目的です。
使用したツール・技術
一般的なアプリケーション開発同様、要件定義からコーディングまで各フェーズを実施しました。
フェーズ | 使用ツール・モデルなど |
---|---|
要件定義 | Gemini(ブラウザ) gemini-2.5-Flash |
設計 | Gemini(ブラウザ) gemini-2.5-Flash |
デザイン | ❌ スキップ(後で説明) |
コーディング | Cursor claude-4-sonnet |
なぜ Cursor を採用したか
簡単なところではお金です。
Claude Code が現在(2025/06/26)では最も流行っているかと思います。が、月$100 は若干高い。
Cursor はリクエスト数に制限はあるものの、月$20 とだいぶコスト的に優しかったため採用することとしました。
また、今回の目的はあくまで Vibe Coding すること 。
Claude Code を利用してアーリーアダプター(もう遅い感じはしますが)を目指してもいいですが、AI エージェント自体流れが早すぎるので、AI エージェントを使いたいだけであればどれでも良いだろうと判断して、Cursor を採用しました。
開発プロセスの詳細
要件定義
Gemini に雑に要件定義を依頼しました。
アプリケーション開発の要件定義を手伝ってください。
健康管理を RPG のようにしたアプリケーションを作成しようと思っています。
毎日のタスク達成で経験値が貯まる仕組みを想定しています。
...
このような依頼で以下のようにやるべきことをまとめてくれます。
1. コア機能の定義
2. ユーザーモチベーション要素
3. 技術要件・非機能要件
4. UI/UX 考慮事項
...
ここから提案された各項目を一つずつ詳細化していきました。
また、 後のフェーズで AI がコンテキストとして参照できるよう、すべてマークダウン形式でドキュメント化 しました。
設計:技術選定から詳細設計まで
技術選定
設計フェーズも要件定義と同じように雑に依頼します。
このアプリケーションの技術選定を考えたいです。
以下の制約があります:
...<制約>...
制約にはプラットフォームや利用したい技術等を伝えます。
それだけで向いている技術等を出してくれます。
詳細設計
技術選定後に、同じチャットで詳細な設計をします。
続いて、システム設計も検討していきたいです。
このくらいの短文で DB の設計からエンドポイント、処理の概要などを 70%くらい作ってくれます。
ただし、時々不要な機能の追加提案があるため制御が必要です。
デザイン
結論:デザインフェーズはスキップしても問題ありませんでした。
当初は Figma AI の活用を検討しましたが、
- Figma AI が有料プランが必要
- デザイン領域の学習コストが高い
- 今回の目的(Vibe Coding 体験)からの逸脱
といったことからスキップしました。
結果として、Cursor が生成する UI で十分実用的なアプリケーションが完成しました。
コーディング
コーディングは以下の順序で進行しました:
- 環境構築(クライアント・サーバー環境)
- UI 実装(画面作成)
- バックエンド実装(サーバーサイド処理)
- API 連携(フロントエンド・バックエンド接続)
- 動作確認・デバッグ
基本的には、これまでに作成したドキュメントをコンテキストとして AI に渡し、実装を依頼する形で進めました。
実践で見えた Vibe Coding の「勘所」
1. AI の得意・不得意を理解する
AI エージェントを利用して、個人的には以下のようなところが得意そうだなと感じました。
- 明確な機能・仕様が定義された実装
- 複雑すぎない一般的な処理
- 既存パターンに則った開発
以上のようなドキュメントで言語化がしっかりされている、またはエージェントへの指示が明確なタスクは早く、それなりに正確だった印象です。
一方で、以下は人間の補助が必要に感じました。
- 人間でも解決に時間を要する複雑なエラー
- 曖昧な要求からの推測実装
- 根本的な問題解決(暫定対応に逃げる傾向)
実際に発生したエラー対応では、「自分でも詰まりそうだなぁ」と感じるものほど、AI も解決に苦労する傾向が見られました。
2. 「線路」を敷くことの重要性
AI エージェントに抽象的な指示を出すほど、予期しない実装をする確率が高まります。
具体的には以下のような問題が発生しました。
- デザイン未作成の影響で、データベース設計にない項目が UI 表示される
- 必要以上に複雑な機能が勝手に追加される
- 仕様の解釈が意図と異なる
こちらに対しては以下のように対策しました。
- 詳細なドキュメント作成:データベース設計、画面仕様等を明文化
- 制約の明示:実装してほしくない機能・パターンを具体的に指示
- 抽象から具体への誘導:段階的に詳細化していく指示方法
3. 評価・批判能力の必要性
AI は時として、バグを含むコードでも「完動する」として提示してきます。
そのため生成されたコードを評価・批判していく必要がありました。
具体的には以下のような点になりそうです
- コードレビュー能力:生成されたコードの品質判断
- テスト観点:動作確認の観点・手法
- 技術的判断力:実装方針の妥当性評価
今回は Flutter と Firebase という未経験技術でしたが、AI との対話を通じて周辺知識を効率的に習得できました。
まとめ:Vibe Coding で感じたこと
実践を通じて感じたのは、アプリケーションの理解度とエンジニアとしてのスキルがより強く求められるようになったなぁというところでした。
とくに評価・批判がこれから大きなするべきことになりそうだなと感じています。
これからもしっかりと技術をつけていければと感じました。
Discussion