Vibe Coding 2.0 — 「何を作らないか」を知る 18 のルール
Vibe Coding とは（前提知識）
Vibe Coding は、Andrej Karpathy（OpenAI 共同創設者）が 2025 年初頭に提唱した概念で、「コードの細部を手で書く」のではなく、AI に自然言語で指示してコードを生成させ、“ノリ（vibe）“で開発を進める スタイルを指します。Cursor や Claude Code などの AI コーディングツールの普及とともに広まりました。
MVP とは
MVP（Minimum Viable Product / 実用最小限の製品） とは、顧客に価値を提供できる最小限の機能だけを備えた製品のことです。完璧な製品を作り込んでからリリースするのではなく、核となる機能だけを素早く形にして市場に投入し、実際のユーザーからフィードバックを得ながら改善していくアプローチを指します。
- 目的: アイデアが市場に受け入れられるかを、最小のコストと時間で検証する
- 考え方: 「完成品」ではなく「検証のための道具」。100 点を目指すのではなく、60 点で出して学ぶ
- 例: 動画配信サービスなら、レコメンド機能や検索機能を後回しにして、まず「動画を再生できる」だけのアプリをリリースする
Vibe Coding 2.0 の文脈では、AI ツールを活用して MVP を高速にシップ（出荷）する ことが繰り返し強調されています。以下のルール群は、すべて「いかに早く MVP を世に出すか」を軸に設計されています。
Vibe Coding 2.0 とは
Harshil Tomar 氏が X で投稿 した 「Vibe Coding 2.0: 18 Rules to be the Top 1% builder」 は、Vibe Coding の「次のフェーズ」を定義したものです。
初期の Vibe Coding が「とにかく AI に書かせて動けばOK」という姿勢だったのに対し、Vibe Coding 2.0 は「AI を活用しつつも、品質・スピード・持続性を両立させるための規律」を重視します。
核心のメッセージは:
「最強の Vibe Coder は、コーディングが上手い人ではなく、“何を作らないか” を見極められる人だ」
18 Rules の概要
50 以上の MVP を複数の国でシップした経験から導き出されたルールで、大きく 4 つのカテゴリに分類できます。
I. 車輪の再発明をやめる（ツール選定）
| # | ルール | 要点 |
|---|---|---|
| 1 | 認証は自作するな | Clerk や Supabase Auth を使う。自前認証は数週間のムダ |
| 2 | Tailwind + shadcn/ui を使え | Tailwind は制約システム、shadcn/ui は本番品質のコンポーネント。デザインゼロから作らない |
| 3 | 生 CSS を書くな | Tailwind で 99% カバーできる。一貫性とスピードが段違い |
| 4 | 状態管理はシンプルに | MVP には Zustand、サーバー状態には React Query / Server Components。Redux は不要 |
| 5 | REST API を自作するな | tRPC や Server Actions を使えば、バリデーション前に数週間を浪費しない |
| 6 | ORM は Prisma + マネージド DB | Prisma + Neon/Supabase で DB 操作を型安全に |
| 7 | バリデーションは Zod + React Hook Form | フォームとスキーマバリデーションを統一 |
| 8 | 決済は Stripe | 決済ロジックの自作は危険。Stripe に任せる |
II. コード品質の規律
| # | ルール | 要点 |
|---|---|---|
| 9 | クリーンなモジュール構成 | components / hooks / utils / types を整理。他人がオンボードできる構造に |
| 10 | 技術的負債は 2〜3 機能ごとに清掃 | 早期の負債は許容するが、定期的に返済する |
| 11 | 判断を文書化せよ | ライブラリ選定、DB 設計、トレードオフの理由を記録 |
III. ユーザー体験への投資
| # | ルール | 要点 |
|---|---|---|
| 12 | 空状態とオンボーディングに投資 | コンテンツがないときに何を表示するか、初日にどう価値を届けるかが UX の要 |
| 13 | パフォーマンスは必須 | Lighthouse スコア 70 未満はリリース前に修正。遅いアプリはユーザーを失う |
| 14 | エラートラッキングを入れろ | Sentry 等でエラーを可視化。ユーザーが報告する前に気づく |
補足: Lighthouse スコアとは？
ルール 13 で言及されている Lighthouse は、Google が提供するオープンソースの Web ページ品質診断ツールです。Chrome DevTools に組み込まれており、以下の 5 カテゴリを 0〜100 点で評価します。
カテゴリ 測定内容 Performance ページの読み込み速度、描画タイミング、インタラクティブになるまでの時間 Accessibility 視覚障害者向けの対応、alt 属性、コントラスト比など Best Practices HTTPS 使用、非推奨 API の回避、コンソールエラーの有無 SEO メタタグ、クロール可能性、モバイル対応 PWA Progressive Web App としての要件充足度 「スコア 70 未満はリリース前に修正」は主に Performance カテゴリを指し、LCP（メインコンテンツの描画完了時間）、FID（最初の操作への応答遅延）、CLS（レイアウトのズレ）などの指標で構成されます。
1 2 3 4 5 6# Chrome DevTools から F12 → Lighthouse タブ → Analyze page load # CLI から npm install -g lighthouse lighthouse https://example.com --viewPython バックエンドでテンプレートから HTML を返す場合は Lighthouse が直接有効です。API のみ提供する場合は、フロントエンド側で計測する指標になります。
IV. マインドセット
| # | ルール | 要点 |
|---|---|---|
| 15 | MVP をまずシップせよ | 完璧を目指さず、動くものを世に出す |
| 16 | 過剰設計しない | 「将来必要かも」で機能を追加しない。今必要なものだけ作る |
| 17 | エネルギーの配分を見極めろ | 全部に全力を注がない。インパクトの大きい部分に集中する |
| 18 | “何を作らないか” を知れ | これが最も重要。作らないことが最速の開発 |
Vibe Coding 1.0 vs 2.0 の違い
| 観点 | Vibe Coding 1.0 | Vibe Coding 2.0 |
|---|---|---|
| 姿勢 | 「AI に任せて動けばOK」 | 「AI を活用しつつ規律を持つ」 |
| 品質 | 動けば良い | モジュール構成・パフォーマンス・UX を意識 |
| ツール選定 | 好きなものを使う | 実績あるスタックを選び車輪の再発明を避ける |
| 技術的負債 | 放置 | 定期的に返済 |
| ゴール | プロトタイプ | シップ可能な MVP |
Python での適用案
元の 18 Rules は JS/TypeScript（Next.js / React）エコシステムを前提としています。Python バックエンド開発に適用する場合、各ルールは以下のように読み替えられます。
I. 車輪の再発明をやめる（ツール選定）
| # | 元ルール (JS/TS) | Python 版 | 要点 |
|---|---|---|---|
| 1 | Clerk / Supabase Auth | django-allauth / FastAPI + Auth0 | Django なら allauth 一択。FastAPI なら Auth0 や Supabase Auth の SDK を使う。自前でパスワードハッシュやセッション管理を書かない |
| 2 | Tailwind + shadcn/ui | Django Templates + Tailwind / htmx + Jinja2 | フロントを分離しない構成なら htmx + Tailwind で SPA 的な体験を最小構成で実現。管理画面は Django Admin をカスタマイズする方が速い |
| 3 | 生 CSS を書くな | Tailwind / Pico CSS | テンプレートに直接 Tailwind を当てる。同じ原則 |
| 4 | Zustand / React Query | サーバーサイドで完結させる | 状態は DB + セッション + キャッシュ（Redis）で管理。フロント側の状態管理を最小化する設計にする |
| 5 | tRPC / Server Actions | Django REST Framework / FastAPI | FastAPI なら型定義から自動で OpenAPI ドキュメントが生成される。Django なら DRF の Serializer + ViewSet で CRUD を数行で実装。Django Ninja も良い選択肢 |
| 6 | Prisma + マネージド DB | Django ORM / SQLAlchemy + Alembic | Django ORM はマイグレーション込みで完結。FastAPI なら SQLAlchemy + Alembic。DB は Supabase / Neon / PlanetScale などマネージドを使う |
| 7 | Zod + React Hook Form | Pydantic / DRF Serializers | Pydantic は Python における Zod。FastAPI はネイティブサポート。Django なら DRF Serializers がバリデーション層を担う |
| 8 | Stripe | stripe-python | まったく同じ。pip install stripe で SDK を入れるだけ |
II. コード品質の規律
| # | 元ルール | Python 版 | 要点 |
|---|---|---|---|
| 9 | モジュール構成 | Django apps / FastAPI routers | Django なら機能ごとに app を分割。FastAPI なら APIRouter でドメインごとにルーティングを分離。models/ schemas/ services/ api/ の層を意識する |
| 10 | 技術的負債の定期清掃 | ruff + mypy | ruff（linter/formatter）と mypy（型チェック）を CI に組み込む。2〜3 機能ごとに ruff check --fix と型エラーを潰す |
| 11 | 判断の文書化 | ADR + pyproject.toml | Architecture Decision Records で「なぜ FastAPI ではなく Django を選んだか」等を残す。依存ライブラリの選定理由も記録 |
III. ユーザー体験への投資
| # | 元ルール | Python 版 | 要点 |
|---|---|---|---|
| 12 | 空状態とオンボーディング | API レスポンス設計 | 空リストの場合に hint や next_action をレスポンスに含める設計。フロントが空状態を表示しやすくする |
| 13 | パフォーマンス | django-debug-toolbar / SQLAlchemy echo | N+1 クエリの検出が最優先。select_related / prefetch_related（Django）、joinedload（SQLAlchemy）を徹底。本番では Sentry Performance で監視 |
| 14 | エラートラッキング | sentry-sdk | pip install sentry-sdk で Django / FastAPI どちらも対応。例外の自動キャプチャとパフォーマンス監視を一括で導入 |
IV. マインドセット
| # | 元ルール | Python 版 | 要点 |
|---|---|---|---|
| 15 | MVP をまずシップ | Django のフルスタック力を活かす | Django なら Admin + ORM + テンプレートだけで MVP が完結する。API が必要になるまで SPA にしない |
| 16 | 過剰設計しない | マイクロサービスにしない | MVP 段階でマイクロサービスは不要。モノリスで始めて、必要になったら分割する |
| 17 | エネルギー配分 | Django Admin を最大活用 | 管理画面を自作しない。Django Admin のカスタマイズで 80% は間に合う |
| 18 | 何を作らないか | PyPI を先に検索する | 「自分で書く前に PyPI を検索する」を習慣にする |
Python 特有の追加ルール
元の 18 Rules には含まれていませんが、Python 開発で重要なポイントです。
| ルール | 要点 |
|---|---|
| 仮想環境を必ず使え | uv または poetry でプロジェクトごとに環境を隔離。グローバルに pip install しない |
| 型ヒントを最初から書け | AI ツールが型情報を頼りにコードを生成するため、Vibe Coding との相性が非常に良い。関数シグネチャには必ず型を付ける |
| Django vs FastAPI の選定基準 | 迷ったら Django。詳細は後述の「Django vs FastAPI の選定指針」を参照 |
推奨スタック対応表
| 用途 | JS/TS 版 | Python 版 |
|---|---|---|
| フレームワーク | Next.js | Django / FastAPI |
| ORM | Prisma | Django ORM / SQLAlchemy + Alembic |
| バリデーション | Zod | Pydantic / DRF Serializers |
| 認証 | Clerk | django-allauth / Auth0 |
| API 構築 | tRPC | DRF / Django Ninja / FastAPI |
| Linter / Formatter | ESLint + Prettier | ruff |
| 型チェック | TypeScript | mypy / pyright |
| パッケージ管理 | pnpm | uv / poetry |
| エラー監視 | Sentry | sentry-sdk |
| 決済 | Stripe (JS) | stripe-python |
Django vs FastAPI の選定指針
一言でいうと、「迷ったら Django」。FastAPI を選ぶのは明確な理由があるときだけです。Vibe Coding 2.0 の「車輪の再発明をやめる」原則に最も忠実なのは Django です。認証・管理画面・ORM・マイグレーションが全部入りで、MVP を最速でシップできます。
判断フローチャート
管理画面が必要？
├─ Yes → Django
└─ No
└─ 認証（ログイン/ユーザー管理）が必要？
├─ Yes → Django
└─ No
└─ 既存の Django プロジェクトがある？
├─ Yes → Django に追加
└─ No
└─ API のみで DB も小規模？
├─ Yes → FastAPI
└─ No → Django
Django が適しているケース
| 場面 | 理由 |
|---|---|
| 業務システム / 管理画面が必要 | Django Admin だけで管理画面の 80% が完成する。FastAPI にはこれがない |
| 認証・権限管理 | django-allauth, django-guardian 等のエコシステムが成熟。FastAPI では自前で組み立てる部分が多い |
| フルスタック（テンプレート + API） | Django Templates + htmx で SPA なしに動的 UI を実現。API も DRF / Django Ninja で同じプロジェクト内に共存 |
| マルチテナント | django-tenants 等の実績あるライブラリがある |
| チーム開発 | 「Django の流儀」に従えばプロジェクト構造が統一される。Convention over Configuration |
| GraphQL | Strawberry Django が ORM モデルからスキーマを自動生成。リレーション解決も統合済み |
FastAPI が適しているケース
| 場面 | 理由 |
|---|---|
| API 専用のマイクロサービス | 管理画面もテンプレートも不要で、軽量に API だけ提供したい場合 |
| 非同期処理が中心 | WebSocket、SSE、大量の並行 I/O。FastAPI は async/await がネイティブ |
| ML / データパイプラインの API 化 | 学習済みモデルの推論エンドポイントを立てるだけなら FastAPI の方が軽い |
| Lambda / Cloud Functions | コールドスタートの速さが重要な場合。Django は起動が重い |
| OpenAPI ドキュメント自動生成 | Pydantic モデルから自動生成される OpenAPI spec が秀退。DRF でも可能だが FastAPI の方が洗練されている |
「両方使う」パターン
排他的な選択ではなく、以下のような構成もあります。
Django (メインアプリ)
├── Admin（管理画面）
├── django-allauth（認証）
├── Strawberry Django（GraphQL API）
└── Django ORM（データ層）
FastAPI (サブサービス)
├── ML 推論エンドポイント
├── WebSocket サーバー
└── 外部 API との非同期連携
Django をモノリスとして中心に据え、非同期処理や ML 推論など Django が苦手な部分だけ FastAPI で切り出す のが実用的です。
Vibe Coding 2.0 の原則との対応
| 原則 | Django | FastAPI |
|---|---|---|
| 車輪の再発明をやめる | Admin, allauth, ORM が全部入り | 自分で組み合わせる必要がある |
| MVP を速くシップ | Django だけで完結する場合が多い | API 以外の部分を別途用意する必要がある |
| 過剰設計しない | モノリスで始められる | マイクロサービス化の誘惑がある |
| 何を作らないか | 管理画面を作らなくて済む | 管理画面が必要なら別途作る |
GraphQL API の利用について
元の 18 Rules はルール 5 で「REST API を自作するな（tRPC / Server Actions を使え）」と述べていますが、これは「REST を使え」という意味ではなく、API 層の構築に時間をかけるなという原則です。GraphQL の運用経験があるなら、無理に REST に切り替える必要はありません。
GraphQL が Vibe Coding 2.0 の原則に合致する場面
| 原則 | GraphQL の適合性 |
|---|---|
| 車輪の再発明をやめる | Strawberry や Graphene で Django ORM / SQLAlchemy から自動的にスキーマを生成できる。CRUD の API を手書きする量が減る |
| バリデーション | GraphQL の型システム自体がバリデーション層になる。Pydantic + REST と同等の安全性がスキーマ定義に含まれる |
| 過剰設計しない | フロントが必要なデータだけ取得できるため、「このエンドポイントにはこのフィールドが要る/要らない」の調整が不要 |
| MVP を速くシップ | フロントとバックエンドの開発者が同一人物（＝Vibe Coder）なら、API 仕様の合意プロセスがなくなり速い |
REST の方が適している場面
| 場面 | 理由 |
|---|---|
| 外部公開 API | REST + OpenAPI の方がサードパーティ開発者にとって馴染みがある |
| 単純な CRUD のみ | DRF の ViewSet + Router なら 10 行で API が完成する。GraphQL のスキーマ定義はオーバーヘッド |
| ファイルアップロード中心 | GraphQL でのファイル操作は仕様が不安定（multipart request spec） |
| キャッシュが重要 | REST は HTTP キャッシュ（CDN, ETag）がそのまま効く。GraphQL は POST ベースなのでキャッシュ戦略が複雑 |
| AI ツールの生成精度 | REST/DRF のコード例は学習データに豊富。GraphQL（特に Strawberry）は AI の生成精度がやや落ちる場合がある |
Python GraphQL の推奨スタック
| 用途 | ライブラリ | 理由 |
|---|---|---|
| GraphQL フレームワーク | Strawberry | 型ヒントベースでスキーマ定義。Pydantic / dataclass と自然に統合。Django / FastAPI 両対応 |
| Django 統合 | Strawberry Django | Django ORM のモデルから自動でフィルタ・ページネーション・リレーション解決を生成 |
| 認証 | django-allauth + Strawberry の permission classes | REST と同じ認証基盤を共有 |
| N+1 対策 | Strawberry DataLoader | GraphQL 最大の落とし穴。DataLoader を最初から入れておかないとパフォーマンスが崩壊する |
判断基準
- GraphQL を選ぶべき: フロントが複雑なネスト構造のデータを取得する / 複数の画面が異なるフィールドの組み合わせを必要とする / すでに GraphQL の運用経験がある
- REST を選ぶべき: 単純な CRUD が中心 / 外部公開 API / チームに GraphQL 経験者がいない
慣れたスタックを使い続けることが最速のシップにつながります。ただし DataLoader の導入だけは MVP 段階から必須 です。
まとめ
Vibe Coding 2.0 の本質は、AI コーディングが「誰でもモノを作れる時代」をもたらした一方で、プロダクトとして成立させるには「作らない判断力」と「ツール選定の規律」が不可欠 だという主張です。コードを書く能力よりも、アーキテクチャの判断力と出荷スピードが差別化要因になる、という新しい開発者像を提示しています。
参考: