AIで“思いつき”をプロダクトに変える：並列プロトタイピングの実践
Vibe Codingは、雑に言えば「コードを書く」よりも先に、“作りたいものを言語化してAIに実装させ、結果を見ながら前に進む”という開発スタイルだ。
重要なのは「自分で全部書けるか」ではなく、AIが迷わない材料（目的・制約・仕様・評価基準）を渡し、反復でゴールに寄せる運用にある。
近年この言葉が広まった背景として、生成AIが「補助」から「実行」へ寄ってきたことが大きい（いわゆる“Vibe Coding”という呼び方もその流れの中で広がった）。
1. Lazarの仕事：Lovableの“Vibe Coding Engineer”は何をしているのか
LazarはLovableで、Vibe Codingを仕事として実践する立場にいる。彼の説明で特に象徴的なのは、この一文だ。
「私は、Vibe Codingで給料をもらっています」
彼のスタイルは、典型的な「設計→実装」よりも、複数プロジェクトを並行して短いサイクルで叩き、ダメなら切り替えるに近い。
常時20〜30プロジェクトが進行
毎日2〜3個の新プロジェクトを始める
ただし、放置ではなく、“定期的に戻って育てる”
重要なのはスピードだけではなく、“学習（Learning）を溜める”こと
この動き方は、スタートアップ的に言えば「小さな実験を大量に回して、当たりに資源を寄せる」に近い。
2. 非エンジニアが強い理由：Vibe Codingは“言語化ゲーム”である
Lazarが繰り返し強調しているのは、非エンジニア（PM・マーケ・BizDev）のほうが強い場面があること。
「非エンジニアは、頭の中のことを言語化する訓練を受けている。エンジニアは、アイデアをコードで表現する訓練を受けている」
つまり、Vibe Codingは、「正しいコード」を書く競争というより、“AIに正しい仕事をさせるための指示書を作れるか”の勝負になる。
ここで勝ちやすいのが、普段から「意図」「優先順位」「要件」「価値」を文章で扱っている非エンジニアだ。
3. 失敗の本質：AIは“コード”より“前提”で詰まる
彼の問題分解は明快だ。
「AIがうまくいかない最大の理由は、文脈（コンテキスト）が足りないこと」
AIにとってのコンテキスト不足は、以下のような形で表面化する。
どの画面・どの状態・どのユーザー行動を想定しているか曖昧
制約（期限／技術選定／禁止事項）が抜けている
期待する「正しさ」（成功条件）が不明
既存コードの意図や設計思想が渡っていない
これはCursorなどの“エージェント型コーディング”でも繰り返し語られる原則で、「ゴールが検証可能な形になっているか」「エージェントが迷わない前提が揃っているか」が成果を分ける。
4. “10分PRD”で精度が跳ねる：最初に作るべきは設計図ではなく「指示書」
彼が実務でやっているのは、長い仕様書ではない。たった10分の“PRD（プロダクト要件）”だ。
機能の目的（Why）
対象ユーザー（Who）
主要ユースケース（When/Where）
必須機能（What）
触って確認できる成功条件（How to verify）
「AIに渡す“コンテキストの塊”を作るだけで、品質が一段上がる」
そして彼は、そのPRDをChatGPTに作らせる。
「いいプロンプトを書くより、PRDを書かせたほうがいい」
ここが逆転している。
“プロンプト職人”ではなく、「要件職人」になるのがVibe Codingの近道、という発想だ。
5. プロンプトの本質：良い指示は“賢い言葉”ではなく“判断可能な条件”
彼が強調するのは「長文プロンプト」ではなく、AIが判断できる材料。
「プロンプトは長くなってもいい。でも重要なのは、必要な情報が入っているかどうか」
このとき、AIが最も困るのは「センスのいい文章」ではなく、曖昧な要件だ。
逆に言えば、次の3点が入るだけで“Vibe”は急に現実になる。
目的（何のために）
制約（何をしてはいけない／何を守る）
成功条件（どうなったらOKか）
6. “Rules”と“Project Knowledge”：AIをチームメンバー化する仕組み
Lazarは、AIを単発のチャット相手ではなく、“プロジェクトに常駐するメンバー”として扱っている。
ルール（Rules）＝開発の作法・禁止事項・設計方針
プロジェクト知識（Project Knowledge）＝ドメイン知識・仕様・背景
「AIに“どう働いてほしいか”のルールを与える」
たとえば、「テストがない変更は禁止」「既存のコンポーネント設計に従う」「この画面遷移は変えない」など、人間チームの“暗黙知”を明文化して渡すイメージだ。
これは、Cursorが公開しているエージェント運用ベストプラクティス（計画を求める／検証可能なゴール／テスト・型・リンタなどの明確なフィードバック）とも一致している。
7. 詰まった時のデバッグ：Lazarの“4×4ループ”
Vibe Codingの現場は、詰まり方も独特だ。
Lazarは、AIが迷子になった時の対処として「繰り返しのループ」を持っている。
まず問題を小さく切る
期待値（成功条件）を明確化する
失敗の原因を“仕様・文脈・実装”のどこにあるか切り分ける
必要なら別ルート（別プロジェクト／別アプローチ）に逃がす
Vibe Codingは、「一発で当てる」より、反復して“正しさの方向”に寄せるゲームで、
この反復の設計が上手い人が強い。
8. 何が変わる？「エンジニアリング」より「プロダクト運用」が中心になる
彼が示唆している未来像は、エンジニア職の否定ではない。むしろ逆で、“エンジニアリングの比重が、実装から運用へ移る”という見立てだ。
実装そのものはAIが加速する
人間の価値は、要件化・優先順位・品質保証・継続改善へ寄る
つまり「作る」より「作り続けて当てる」が重要になる
この変化の中では、非エンジニアの武器（言語化、仮説検証、顧客理解）が効きやすい。
9. 今日から使える：Lazar式Vibe Codingの実践テンプレ
最後に、彼の話を“再現可能な手順”に落とすと、こうなる。
Step 1：10分PRDを作る（自分で書かずにAIに書かせてもOK）
目的、ユーザー、必須機能、成功条件を箇条書きで
Step 2：Rules / Knowledgeを用意する（最低限でいい）
禁止事項（守るべき制約）
既存仕様（変えてはいけない前提）
“このプロダクトの常識”を短く
Step 3：小さく作って、触って検証する（成功条件で判定）
“動いた気がする”ではなく、成功条件を満たしたかで判断
Step 4：詰まったら「文脈不足」を疑う
どの状態で？誰が？何をしたら？どうなるべき？が欠けていないか
結論：Vibe Codingは「AIにコードを書かせる技術」ではなく「意図を仕様に変える技術」
Lazarの話を一言に圧縮すると、こうなる。
Vibe Codingは魔法ではない
でも、“文脈（コンテキスト）を構造化して渡せる人”には、急にレバレッジが効く
そして、その能力は、非エンジニアが本来持っている武器でもある
だからこそ、彼は言い切れる。
「私はVibe Codingで給料をもらっています」
