非開発者のためのバイブコーディング入門5ステップガイド
(stdy.blog)ここ数週間、非開発者の知人たち（弁護士、マーケター、PM など）と一緒に、バイブコーディングで簡単なアプリを5〜6個作ってみた。
- WoWギルドのレイドダッシュボード（Web）
- 景品抽選イベント用レーシングシミュレーター（Web + Three.js）
- 映像編集者と依頼者のあいだでコミュニケーションするためのツール（Chrome拡張機能）
- イテレーション回数を決め、一定時間集中し、終わったら振り返れるよう支援する自動タイマー（Electronデスクトップアプリ）
この過程を整理して、「非開発者のためのバイブコーディング入門ガイド」を5段階でまとめてみた。
- 最近のAIがどこまで何をできるのか感覚をつかむ
- 解決したい問題、作りたいプロダクトを明確に定義する
- できるだけ早く、頻繁に、自分の目で成果物の動作を確認する
- AIがうまくコーディングできるよう、プロンプトを工夫してやり取りする
- 異常動作と改善点を認識し、改善しながら仕上げる
1) 最近のAIがどこまで何をできるのか感覚をつかむ
バイブコーディングに初めて触れる非開発者の方には、まずはこの程度の活動から始めることを勧めたい。
- LLMで、または AIプロトタイピングサービスで、短いプロンプトだけでも何かが動くものを作れることを自分で体験し、効力感を高める
- 最新のAI情報を整理して伝えてくれるSNSやニュースレターをいくつか購読する
- すべてのAI情報やツールを消化しようと欲張らず、自分が関心のある特定テーマのツールだけに注目して軽く試してみる
2) 解決したい問題、作りたいプロダクトを明確に定義する
- AIの能力を理解していても、問題定義が明確でなければプロダクトは作れない
- だからまずは、メタ認知を高める質問を通じて自分自身が賢くなる必要がある。
- バイブコーディングで作ったメタ認知アプリを使う
- 何を作りたいのか？
- それをなぜ作りたいのか？ どんな問題を解こうとしているのか？
- それは誰が抱えている問題なのか？
- その人たちはどんな状況でその問題に直面するのか？
- その状況で今はどんな間に合わせ策／代替手段を使っているのか？
- 5より1のほうが問題をよりうまく解決することを、どう確認できるか？
- 彼らが5の代わりに喜んで1を使うようにするにはどうすればいいか？
- 作りたいものが整理できたら、上のアプリで生成された「PRD生成プロンプト」をLLMに入れて、PRDを作らせた
3) できるだけ早く、頻繁に、自分の目で成果物の動作を確認する
- 「動くアプリ」を非常に早い段階で作れることは、バイブコーディング最大の利点だ。非開発者のモチベーションにも非常に重要である
- そういう意味で、非開発者がCursorでバイブコーディングを始めることはあまり勧めない。アプリ実行までに越えるべき大小さまざまな壁が多いと思うからだ
- その代わり、PRDを与えると動くプロトタイプが出てくるLovableのようなサービスのほうが、より良い出発点だと思う。公開リンクもすぐ作れるので、知人に見せてフィードバックをもらうのにも向いている
- ただし、作ろうとしているアプリがWebベースでない場合は少し複雑になる。プロトタイピングツールはWebアプリとして作ってくれるためだ
- この場合は技術的な意思決定と実行環境のセットアップが必要で、そのためには自分もAIも賢くならなければならない
4) AIがうまくコーディングできるよう、プロンプトを工夫してやり取りする
- 自分とAIが賢くなる <-> 良いプロンプトを書く <-> 成果物がより早く、より良く出てくる
- プロンプトをうまく書くほど、目標達成までに必要なピンポン回数（= 時間とお金）が減る
- 各種プロンプトエンジニアリングガイドを見ると、共通して言われているのは、プロンプト内で役割(Role)、文脈(Context)、タスク(Task)をしっかり定義せよということだ
役割、文脈、タスク
- バイブコーディングでは「役割」はそれほど重要ではない
- コーディングエージェントにはすでに適切な役割が定義されていて、かえって混乱することがあるし
- コーディングが重要なベンチマークだからか、LLMでも役割付けなしでうまくコーディングできるためだ
- もちろん、自分が作ろうとしているアプリが特殊なら、適切な役割を与えるのもよい
- 「文脈」はPRDをきちんと作っていれば十分
- 「タスク」は目標と完了基準をしっかり定めること。完了基準は
- プロンプト内に明示されていることもあるし（few-shotプロンプティング）
- 外部ファイルやコードに定義されていることもある（
TODOs.mdやテストコード） - 自分の頭の中にだけあることもある（このスタイルは望ましくない）
- バイブコーディングの究極的な目標は、AIにうまくコーディングを指示して、PRDどおりに動くアプリをすばやく作ることだ。そのためには、3つの中間目標を置くのがよい
- 自分がより賢くなる
- AIがより賢くなる
- 機能が仕様どおりに動作する
自分がより賢くなる？
- 非開発者だったり、ドメインに不慣れだったり、技術スタックに不慣れだったりすると、正確な用語で指示するのが難しい
- そういうときは、自分の不足をLLMに伝えて学べばよい
- 「（スクリーンショットを見せて）こういうゲームって普通は何で作るの？」
- 「こういうものを作るつもりなんだけど、君ならデータをどう確保すると思う？」
- 「ネイティブアプリの中核動作をできるだけ早く確認するには、どんな技術を使うべき？」
- こうした質問を通じて、自分が次のように変化しているか観察してみること
- 技術キーワード: 自分が正確な技術用語／ドメイン用語を使えている
- データフロー: 自分のアプリの中核機能に必要なデータをどう確保し、どう処理し、どう見せるのか説明できる
- 実行環境: AIが書いたコードを実行し、動作するかどうかを自分の目で確認できる環境を用意した
- 理想的には、unknown unknownをすべて解消した状態でPRDを書いてからコーディングに着手するのがよいが、必ずしもそうでなくてもよい
- コーディングに入ってから学べることも多いし、いざとなれば最初から作り直せばよいからだ。（すでにあるものを直すより速いこともある）
AIがより賢くなる？
- 把握した技術キーワードやデータフローを、システムプロンプト（Cursor Rules など）としてAIに伝えること
- 自分の介入回数を減らし、AIのコードをより好みに近づけるには、大きく2つ必要だ。制約条件と文書化に関する指針である
- 制約条件の指針は、AIがより一貫したコードを書く助けになる。たとえば:
- 技術スタック: NextJS app router を使え、TailwindとShadCNでスタイリングしろ、アイコンはLucidだけを使え、決済はStripeを使え、など
- 構造とパターン: フォルダはこう構成しろ、ファイル名はこう付けろ、UIスタイルはMaterial風にしろ、など
- （実行環境に応じた）出力形式: Electron Fiddleを使うのでそれに合わせてファイル4つを出せ、CodePenを使うのでHTML、CSS、JSを1つずつ出せ、など
- 文書化の指針は、AIの集中力と記憶力を高める助けになる。2つのアイデアがとても有用だった
- Clineのメモリーバンク: やったことと、これからやることをファイルに記録しながら進めるワークフローを定義する
- カン・ドンユンさんのプロンプトコンテキスト: プロジェクト全体に対する指針を最上位フォルダに長々と残す代わりに、フォルダごとに指針を作る
- メモリーバンクは、今何が起きているのかを観察し学習しやすくなるので、特に非開発者におすすめだ
機能が仕様どおりに動作する？
- プロジェクトレベルではなく、（コーディングエージェントで）チャットするときのプロンプティング戦略
- 機能を仕様どおりに動かすための最良の戦略は、テストに通ったらコミットだと思う
- 「Xを実装して。まずテストを書いて、次にコーディングして、テストを実行し、通るまでコードを修正し続けて。」
- これは、コーディングエージェントがテストコードを書き、ターミナルで実行し、その結果を読める権限と能力を持っているから可能だ
- そうしてテストに通ったらコミットメッセージを提案してもらい、テストコードと機能コードを一緒にコミットすればよい。自分はコミットを手動で行うが、エージェントによる自動コミットも可能だ
- ユニットテストだけでなく、統合テストやE2EテストもAIに書かせ、実行させ、必要なら自動で修正させることができる（参考: Cursor + Playwright 自動テスト）
- これらすべては、**「仕様どおりに個別機能が実装され、アプリ全体がPRDどおりに動くか」**を、バイブコーダーとAIの双方がより簡単に確認できるようにするための戦略だ
5) 異常動作と改善点を認識し、改善しながら仕上げる
- 自分が考えるバイブコーディングは、「ワンクリックで完成」とはほど遠く、学ぶべきことが多い
- その中でも、「自分だけの小さなプロトタイプ」を超えて、ソロ起業家として商用製品レベルのアプリを作るうえで必須だと思う能力が3つある。認知能力、コーディング能力、プロダクトエンジニアリング能力だ
認知能力
- PRD（または自分の元の意図）と違って動く画面や機能を、敏感に認識すること
- これが不足すると、AIの誤りを見つけて修正させるのがとても難しくなる
- 4段階目の「テスト」は、AIの誤りをそもそも減らすと同時に、自分の能力を伸ばしてくれる面もある。
- 仕様をAIがテストコードに変換する過程を読むことで、単に「この機能が必要だ」ではなく、「この機能実装を完了するにはこうした条件が必要だ」と学べるからだ
- ただし、「アプリを仕様どおり実装した」と「アプリが良い」は別物だ。だから改善点を見つけるためのプロダクトセンスが重要になる（詳しくはリンク先のLennyのニュースレター参照）
コーディング能力
- 少なくとも現時点では、どれだけ作業を細かく分けてAIに任せても、最低5%程度は自分でコードに手を入れて仕上げなければならない。
- これができず、80%程度の完成度で止まってリリースできないアプリがSNS上には山ほどある
- もちろん、作ろうとしているアプリによってこの比率は変わるかもしれないし、最後までAIだけで実装することも不可能ではないが、あまりに非効率だ
- バイブに完全に身を任せるのではなく、（メモリーバンク、テストコードなどを通じて）AIが生成する文書を見ながら、コーディング自体も学ぶことを勧めたい。開発者からコーチングを受けるのもよい
- 特に、比較的目に見えにくいバックエンド（ユーザー認証、外部API連携、データ入出力、決済など）やデプロイ戦略（mainブランチとfeatureブランチ、環境変数管理など）について学ぶと効果が大きい
プロダクトエンジニアリング能力
- アプリのリリースは終わりではなく始まりだ。きちんとやるなら、プロダクト開発ライフサイクル全体を理解する必要がある
- 問題認識、解決アイデアの導出、企画、デザイン、実装、テスト、デプロイ、広報、エラーモニタリング、フィードバック収集、運用...
- これらすべての段階を深く扱うところまでいかなくても、少なくとも各段階でどんな仕事があり、どんなキーワードが使われるのかまでは知っておくとよい
- そうすれば、知らないことを学べるし、一人で抱えきれないときに一緒にやる仲間の力量も見極められる
結びに
- バイブコーディングでアプリを商用製品レベルに仕上げるのは、決して簡単なことではない。しかし、「始める」ことがこれまでになく容易になったのは、誰も否定できないだろう
- 自分の小さなアイデアが生き生きと動き出すのを見た知人たちが、感嘆しながら（「わあ、自分がコーディングしてる！」）とても楽しそうにしているのを見て、自分もとても幸せだった
- この記事を読むほかの非開発者の方々にも、この機会に楽しく「メイカー」になってみることを勧めたい
- 自分だけのドメイン専門性を活かして、特定の問題を卓越して解決する、小さくて速くて便利なツールを（バイブコーディングで）作ることができれば、AI時代でも十分に競争力はあると思う
7件のコメント
わあ、バイブコーディングは幻想だと思っていたのですが
ここまで専門性のある文章は久しぶりに見ました
楽しく読ませていただきました。
ありがとうございます！私は大きな可能性を感じています（笑）
あ;; 今見ると、私のコメントはちょっとアレですね。
幻想という表現よりは、まだ先は長い？ という感じに近いです。
結局、バイブコーディングには限界があって、開発の知識がないと難しいと感じているんです。
もちろん、AIが発展していけば、後々はずっと良くなると思います。
私のコメントが、バイブコーディングには意味がないと言っているように受け取られそうだったので、だらだらと改めて返信します。
私もバイブコーディングはかなり愛用しています（笑）
あ、いえ違います（笑）。私もおっしゃっていたニュアンスは理解しています。
なので本文にも書いたとおり、私が言うバイブコーディングは「カチッ」とはほど遠く、レベルを上げるにはエンジニアがかなり努力しなければならないと思っています。
いつも楽しく拝読しています。
ありがとうございます！
YouTube動画も撮りました（笑） https://www.youtube.com/watch?v=ecY5VBpruOA