v0 や Lovable、Bolt、Cursor、Claude Code で開発していて、「同じことを頼んでいるのに、通るときと盛大に破綻するときがある」と感じたことはないでしょうか。

差が出るのは、たいていツールの性能ではなく**プロンプトの"型"**です。実際に個人開発で使い回している型を5つ、そのまま使えるスニペット付きで共有します。

1. 制約先出し型 — 技術スタックと非機能要件を最初に固定する

一番効くのがこれです。「作って」の前に、動かす環境と守ってほしい制約を先に固定します。後出しで直すより、最初に枠を決めるほうが圧倒的に手戻りが減ります。

前提（ここから外れないで）:
- スタック: Next.js(App Router) / TypeScript / Tailwind
- 状態管理は使わない。サーバーコンポーネント優先
- 外部ライブラリ追加は禁止（標準機能で）
この前提で、〇〇の画面を1つだけ作って。

2. 段階分割型 — 1画面 / 1機能ずつ渡す

「アプリ全部作って」は破綻の入口です。人間のレビュー単位（1画面・1機能）に割ると、生成物が読める粒度に収まり、途中で軌道修正できます。

今回は「ログイン画面だけ」。API連携やDBはまだ書かない。
UIとバリデーションだけを完成させて。次のステップは私が指示する。

出力の"形"を指定すると、コピペの事故が激減します。特に既存コードの修正時は「差分だけ」を明示します。

出力は「変更のあるファイルのみ」。ファイルパスを見出しにして、
全文でなく変更箇所の前後3行付きで示して。無関係な整形はしない。

そのツールが"やりがちな失敗"を、先回りして禁止事項に書きます。これだけで生成品質が一段上がります。

やらないでほしいこと:
- 使っていないimportを足さない
- 型を any で握りつぶさない
- 勝手にディレクトリ構成を変えない
まずこの3点を守った上で実装して。

生成しっぱなしにせず、同じターンで「自分の出力の穴」を挙げさせます。バグの半分はここで拾えます。

実装が終わったら、最後に「この実装で壊れそうな箇所・未対応のエッジケース」を
3つだけ箇条書きで挙げて。直すかどうかは私が決める。

この5つは"型"の話ですが、実際にはツールごとに効くプロンプトが違います（v0は画面単位が強い、Claude Code は制約先出しが刺さる、など）。ツール別の具体プロンプトと、実際に1日でLP・10時間でMVPを組んだときのケーススタディは、こちらの記事にまとめています。

なお、5ツール×各10本の実戦プロンプト（失敗パターン付き）を一括で欲しい方向けに、有料のVibe Coding プロンプトパック（$19・30日返金保証）も用意しています。※こちらは筆者の自作商品です。まずは上のガイドと本記事の5つの型を試してみてください。

型を1つ足すだけでも生成の"通る率"は変わります。よければ普段のプロンプトに組み込んでみてください。