Vibe Coding完全実践ガイド〜AI時代の新開発スタイル・実践テクニック・落とし穴〜

「Vibe Coding(バイブコーディング)」——2025年初頭にAndrej Karpathy氏が投稿した一言から始まったこの言葉は、2026年現在、シリコンバレー発のスラングから実務開発の一スタイルとして完全に定着しました。「雰囲気でAIに任せて書く」というその軽さとは裏腹に、向き合い方を間違えるとプロダクトを壊し、向き合い方が正しければ個人開発の生産性を10倍以上に押し上げる、極めて諸刃な開発スタイルです。

本記事はVibe Codingに特化し、定義・必要スキル・Cursor/Claude Codeでの具体的実例・初心者と中級者それぞれの失敗パターン・デバッグ手法・著作権・キャリアへの影響まで、コピペできる30個以上のコードサンプルとBefore/After比較を交えて徹底解説します。「AIに任せる」と「AIに丸投げ」の決定的な違いを、現場の手触りで腹落ちさせることを狙いとしています。

1. Vibe Codingとは何か——Karpathyが言い出したスタイル

Vibe Codingは、元Tesla AI責任者のAndrej Karpathy氏が2025年2月にX(旧Twitter)で「最近はvibe codingって呼んでるスタイルがあって、コード自体は読まない。LLMに頼んで、出てきたものを実行して、動かなければエラーをそのまま貼り戻して、動くまで雰囲気で進める」と述べたのが起源です。ポイントは「コードを読まない」「雰囲気(vibe)で進める」という割り切りにあります。

1.1 三つの構成要素

Vibe Codingは大きく次の三要素で成立します。

• 意図の自然言語化:「何を作るか」を曖昧にではなく具体的に日本語/英語で書く
• AIへの委譲:設計・実装・修正のループをAIに任せる
• 動作確認による検証:コードの中身ではなく挙動でレビューする

1.2 「読まない」は本当に正しいのか

Karpathy氏の文脈は使い捨てプロトタイプでした。本番投入や長期メンテを前提にした場合、「読まない」は致命傷になります。2026年現在の現場では、「読みはする、ただし全行ではなく要所のみ」という運用が主流です。詳しくはAIコーディングツール完全比較2026でも比較していますが、ツール選びとレビュー粒度の調整がVibe Codingの肝になります。

2. 従来コーディング vs Vibe Coding

2.1 開発フローの違い

同じ「TODOアプリを作る」でも、フローはまったく異なります。

# 従来コーディング
要件定義 → 設計 → コード作成(自分の手で) → テスト → リファクタ → デプロイ

# Vibe Coding
要件をプロンプト化 → AIに実装させる → 挙動確認 → 不満点を自然言語で再依頼 → デプロイ

2.2 思考の重心が変わる

従来は「どう書くか」に頭を使っていたのが、Vibe Codingでは「何が欲しいかをどう言語化するか」に重心が移ります。プログラミング言語の文法より、要件と境界条件を曖昧さなく伝える力のほうが価値を持つ局面が増えました。

2.3 失敗例:曖昧な指示

# 悪いプロンプト(雰囲気が雑すぎる)
TODOアプリ作って

# 良いプロンプト(雰囲気の中にも要件がある)
Next.js 15 App Router + TypeScript + Tailwindで、
ローカルストレージに保存するTODOアプリを作って。
- タスクは {id, title, done, createdAt} の型
- 追加・完了切替・削除・全削除
- 完了済みは下にソート
- アクセシビリティのためフォーカスリングを残す

3. Vibe Codingに必要な前提スキル

3.1 「読めるけど書かない」レベルの言語力

誤解されがちですが、Vibe Codingはプログラミングを知らなくていいわけではありません。AIが出したコードが「明らかにおかしい」と判別できる程度の読解力は必須です。TypeScript型基礎やasync/awaitの挙動が頭に入っていないと、AIが書いた非同期処理のバグに気づけません。

3.2 環境構築力

Node.jsを入れる、リポジトリを切る、デプロイ先を用意する——この一連がスムーズに動く前提が必要です。

# 最低限これくらいは1人で完結できる必要がある
node -v               # v22.x
npm create vite@latest my-app -- --template react-ts
cd my-app && npm i && npm run dev
git init && git add . && git commit -m "init"
gh repo create my-app --public --source=. --push

3.3 ドメイン知識

「決済を入れて」と頼んでも、PCI DSSの基本を知らないとAI生成コードを評価できません。業務知識は最後まで人間に残ります。

4. Cursor / Claude CodeでのVibe Coding実例

4.1 CursorのComposerで一気に作る

CursorのComposer(Ctrl/Cmd+I)に貼り付けるプロンプト例です。詳細はCursor完全実践ガイドを参照してください。

@codebase 既存のlib/db.tsを使って、
/api/notesにGET(一覧)・POST(作成)・DELETE(?id=)を実装してください。
- App Router (route.ts)
- zodで入力検証
- エラーは{ error: string }でJSONレスポンス
- 200/201/400/404/500を適切に使う

4.2 Cursorが返してくる典型コード

// app/api/notes/route.ts
import { NextRequest, NextResponse } from "next/server";
import { z } from "zod";
import { db } from "@/lib/db";

const NoteSchema = z.object({
  title: z.string().min(1).max(200),
  body: z.string().max(10000).optional(),
});

export async function GET() {
  const notes = await db.note.findMany({ orderBy: { createdAt: "desc" } });
  return NextResponse.json(notes);
}

export async function POST(req: NextRequest) {
  const json = await req.json();
  const parsed = NoteSchema.safeParse(json);
  if (!parsed.success) {
    return NextResponse.json({ error: parsed.error.message }, { status: 400 });
  }
  const note = await db.note.create({ data: parsed.data });
  return NextResponse.json(note, { status: 201 });
}

export async function DELETE(req: NextRequest) {
  const id = req.nextUrl.searchParams.get("id");
  if (!id) return NextResponse.json({ error: "id required" }, { status: 400 });
  await db.note.delete({ where: { id } });
  return new NextResponse(null, { status: 204 });
}

4.3 Claude CodeでCLIから一気通貫

# Claude Codeでプロジェクト直下に作業を依頼
claude "app/api/notesルートを追加して。GET/POST/DELETE、zod検証つき。
作り終わったらnpm run test:apiでテストも実行して、失敗したら自分で直して"

4.4 ワンショットでスクリプトを書かせる

# CSVをJSONに変換するスクリプトを5秒で
claude -p "csvtojsonでdata/users.csvをdata/users.jsonに変換するts-nodeスクリプトを書いて、最後に実行して"

5. プロトタイプ作成例(SaaS / ゲーム / ツール)

5.1 SaaSのMVP:Notion風メモアプリ

# プロンプト
Next.js App Router + Supabase Auth + Prismaで、Notion風の
ネスト可能なメモアプリのMVPを作って。
- マジックリンク認証
- ユーザーごとにnotes(parent_id null許容)
- 左ペインにツリー、右ペインに編集
- Tiptapでリッチエディタ
- 認証はsupabase-jsのSSRパッケージ

5.2 ゲーム:ブラウザ版テトリス

// AI生成:Reactで作るテトリスの心臓部
const ROWS = 20, COLS = 10;
type Cell = 0 | 1;
type Board = Cell[][];

const empty = (): Board =>
  Array.from({ length: ROWS }, () => Array(COLS).fill(0));

const collide = (b: Board, shape: number[][], x: number, y: number) => {
  for (let i = 0; i < shape.length; i++) {
    for (let j = 0; j = ROWS || nx = COLS) return true;
      if (ny >= 0 && b[ny][nx]) return true;
    }
  }
  return false;
};

5.3 個人ツール:Markdown→PDF変換CLI

// AIに頼んで30秒で出てきたCLI
#!/usr/bin/env node
import { readFileSync, writeFileSync } from "node:fs";
import { marked } from "marked";
import puppeteer from "puppeteer";

const [, , input, output = "out.pdf"] = process.argv;
const html = `${marked.parse(
  readFileSync(input, "utf8")
)}`;

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.setContent(html, { waitUntil: "networkidle0" });
await page.pdf({ path: output, format: "A4", printBackground: true });
await browser.close();
console.log(`generated: ${output}`);

6. AIに任せる範囲・自分でやる範囲

6.1 任せていい領域

• ボイラープレート(ルーティング、CRUD、型定義の雛形)
• ライブラリの使い方の調査・サンプル化
• 正規表現・SQL・シェルワンライナー
• UI実装(Tailwindのclassの組み立て、レイアウト)
• テストコードの初稿生成

6.2 自分でやるべき領域

• セキュリティ境界の設計(認可、CSRF、SSRF、Secret管理)
• データモデル設計とインデックス設計
• 外部連携の契約(API仕様、SLA、リトライ戦略)
• 計測指標とログの設計
• ビジネスロジックの最終判断

6.3 境界の引き方:プロンプトに役割を書く

あなたはこのプロジェクトの実装担当のシニアエンジニアです。
- アーキテクチャの最終判断は私が下します
- 外部APIキーの取り扱いは絶対に勝手にハードコードしないでください
- 不確実なら必ず質問してください
- テストが落ちる場合は実装ではなくテストを変更する前に私に確認してください

7. 失敗パターン(初心者編)

7.1 失敗1:依存を聞かずに全部入れる

# NG: AIが提案したものを盲信
npm i lodash moment axios react-query@3 next-auth@3 ...
# → React Query v3はもうレガシー、moment.jsはdeprecated扱い

# OK: バージョンを明示して聞き返す
npm i @tanstack/react-query@latest next-auth@beta
# 「2026年時点でメンテされている代替は?」と一度確認するクセを

7.2 失敗2:エラーをそのまま貼って解決を待つだけ

エラーの再現条件を添えないと、AIは推測で当て物をするだけになります。

# NG
Error: Hydration failed 直して

# OK
Error: Hydration failed
- ページ: /dashboard
- 直前の変更: useEffectでlocalStorageを参照する処理を追加
- ブラウザ: Chrome 142
- next.config.jsのreactStrictMode=true
原因として怪しい箇所を挙げ、修正案を2パターン出してください

7.3 失敗3:認証情報を平文でコミット

// NG: AIが提案するままに書く
const SUPABASE_KEY = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."; // 漏洩

// OK
const SUPABASE_KEY = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!;
if (!SUPABASE_KEY) throw new Error("missing env");

7.4 失敗4:.envをコミットする

# .gitignoreに必ず以下を含める
.env
.env.local
.env*.local
*.pem
*.key

7.5 失敗5:「動いた!」で満足する

ハッピーパスだけで動作確認すると、境界値・空配列・null・タイムアウトでまとめて落ちます。「3つの異常系を必ず試す」をクセに。

8. 失敗パターン(中級者編)

8.1 失敗1:既存コードと矛盾するスタイルを混ぜる

AIが提示するコードはしばしば「最新ベストプラクティス」ですが、既存プロジェクトと噛み合わないこともしばしば。

// Before: AIがいきなりServer Actionsで書いてきた
"use server";
export async function createNote(formData: FormData) { ... }

// 既存リポジトリはRoute Handlersで統一されている
// → ルールから外れた実装を混ぜるとレビュー負債になる

// After: CLAUDE.md / .cursorrules に「Route Handlersを使う」と書いておく

8.2 失敗2:N+1クエリを見落とす

// NG: ループ内でクエリ
for (const userId of userIds) {
  const orders = await prisma.order.findMany({ where: { userId } });
  // ...
}

// OK: 一括取得してメモリで分配
const orders = await prisma.order.findMany({ where: { userId: { in: userIds } } });
const grouped = Object.groupBy(orders, (o) => o.userId);

8.3 失敗3:過剰な抽象化を許容してしまう

AIは「将来のために」と称して、不要なファクトリ、ジェネリック、依存性注入を盛り込んでくることがあります。YAGNIの原則を持ち込んで剥がすのも人間の仕事です。

8.4 失敗4:テストが「実装の写経」になっている

// NG: 実装そのままなので、実装が壊れても誰も気づけない
it("multiplies two numbers", () => {
  expect(multiply(2, 3)).toBe(2 * 3); // 計算式を書いてしまう
});

// OK: 期待値はリテラル
it("multiplies two numbers", () => {
  expect(multiply(2, 3)).toBe(6);
});

8.5 失敗5:プロンプトの「最近の」を信用する

「最近のNext.jsで」と指示しても、AIの学習データは時点を持ちます。バージョンを必ず数字で指定するのが鉄則です。

9. デバッグ手法

9.1 「最小再現コード」を一緒に貼る

以下が最小再現です。
```ts
const fn = (xs: number[]) => xs.reduce((a, b) => a + b);
console.log(fn([])); // TypeError
```
このコードを、空配列でも0を返す関数に直してください。
ただし型レベルでも空配列を許容できる形にしてください。

9.2 二分探索デバッグをAIにやらせる

git logを貼ります。
最後に動いていたのは a1b2c3d。
動かなくなったのが f4e5d6c。
間の差分のうち、HydrationエラーをもたらしうるコミットをSHA単位で挙げて。

9.3 ログ駆動で詰める

// AIに「ここからここまでにconsole.logを足して」と頼む
console.log("[notes] req body:", JSON.stringify(json));
console.log("[notes] parsed:", parsed.success ? parsed.data : parsed.error);
console.log("[notes] db result id:", note?.id);

9.4 print debugから抜け出すタイミング

3回以上同じ箇所にlogを足し直したら、デバッガを使うべきサインです。Node.jsならnode --inspect-brk、ブラウザはDevTools、Reactはreact-devtoolsを併用しましょう。

10. テストの位置づけ

10.1 「テストもAIに書かせる」が正しい

テストコードは仕様の文書化です。AIに先に書かせ、人間が「このケースは漏れている」と追加する流れが効率的。

// AI生成テストの典型
import { describe, it, expect } from "vitest";
import { sum } from "./sum";

describe("sum", () => {
  it("足し算", () => expect(sum(1, 2)).toBe(3));
  it("負の数", () => expect(sum(-1, -2)).toBe(-3));
  it("ゼロ", () => expect(sum(0, 0)).toBe(0));
});

10.2 人間が必ず足すべきテスト

• 境界値(0、-1、Number.MAX_SAFE_INTEGER、空文字、NaN)
• 同時実行・競合状態
• 権限境界(他ユーザーのデータを読めないか)
• I/O失敗時のロールバック

10.3 カバレッジは目的ではない

「100%目指してAIに書かせる」は本末転倒。クリティカルパスの分岐網羅を優先しましょう。

11. 著作権・ライセンス

11.1 AI生成コードの権利帰属

米国・日本ともに、現時点で純粋にAIが生成したコードは著作物として保護されないという見解が主流です。一方、人間が指示・選択・修正を加えたものは保護対象になり得ます。

11.2 学習元コードの混入リスク

AIがGPLコードを混ぜて出してくる可能性はゼロではありません。商用プロダクトに入れる場合は、社内のCode Scanningツール(GitHub Advanced Security、Black Duck、FOSSAなど)でライセンス検査を回しましょう。

11.3 社内規程を整える

# 推奨される社内ルール例
- 生成元のモデル名/バージョンをコミットメッセージに記録
- セキュリティ機微コード(認証/決済/暗号)は人手100%レビュー
- 外部ライブラリの追加は別PRに分離
- AI生成と人手の比率をPR本文に明記

12. 「動くけど理解してない」問題

12.1 症状

機能は完成した、テストも通る、しかし1か月後に小さな改修ができない。これがVibe Codingの最大の落とし穴です。

12.2 処方箋:逐次質問

この実装の中で、私が理解できていない関数を1つずつ説明してください。
- まずdebounce処理の流れを擬似コードで
- 次にuseMemoが必要だった理由を依存配列の観点で
- 最後に、もし私が並行アクセス対応を入れる場合の修正点を

12.3 処方箋:逆方向の演習

AIが書いたコードを仕様書に戻す練習をします。コードを読み、要件箇条書きを書き、AIに再度同じものを書かせて差分を見る——これだけで理解度は跳ね上がります。

13. 中長期メンテナンス

13.1 README / CLAUDE.md / .cursorrules を整える

# CLAUDE.md (プロジェクトルートに置く)
## アーキ
- Next.js 15 App Router (Route Handlersのみ。Server Actionsは使わない)
- DB: Prisma + PostgreSQL
- 認証: NextAuth v5 (Auth.js)

## コーディング規約
- import順: 標準 → 外部 → @エイリアス → 相対
- error throwは独自Error class経由
- 日付はDateではなくTemporal

## やってはいけないこと
- 新規ライブラリ追加は別PRに分離
- migration生成は手動。AIに自動生成させない

13.2 ライブラリ更新時のVibe

# 半年に1回はやる
ncu -u            # package.jsonを最新に
npm i
claude "package.jsonとロックファイルを参照し、breaking changesがあるパッケージのみコード修正案を提示して"

13.3 ドキュメントを書かせ続ける

機能追加のたびに「READMEとADR(Architecture Decision Record)も更新して」と添えるだけで、ドキュメント腐敗を防げます。

14. AI生成コードのレビュー観点

14.1 セキュリティ

• 入力検証(zod / valibot)があるか
• 認可チェックがある層で実行されているか
• SQL/コマンドインジェクションを起こさないか
• Secret/PIIをログに吐いていないか

14.2 パフォーマンス

// 危険な兆候: ループ内await、N+1
for (const u of users) {
  await sendEmail(u);            // 直列で待っている
}
// → Promise.allSettledで並列化を検討

14.3 例外処理

// NG: catchで握りつぶし
try { await save(); } catch (e) { /* nothing */ }

// OK: 文脈付きで再スロー、または計測
try {
  await save();
} catch (e) {
  logger.error({ err: e, op: "save" });
  throw new SaveError("failed to save", { cause: e });
}

14.4 「やってないこと」を見抜く

AIは未実装をスルッと埋める癖があります。// TODOや空関数を見落とさないこと。CIでgrep -R "TODO"を回すのも有効です。

15. プロダクション投入の判断軸

15.1 4軸チェックリスト

• 可読性:自分で1か月後に直せるか
• テスト:クリティカルパスがカバーされているか
• セキュリティ:認証・認可・Secret・入力検証が通っているか
• 可観測性:ログ・メトリクス・トレースが入っているか

15.2 段階的に出す

# 推奨手順
1. feature flagで内部公開
2. dogfooding(社内)
3. 5%カナリア → 25% → 100%
4. ロールバック手順を用意

16. Vibe Codingが向くプロジェクト

• 個人ブログ、ポートフォリオ、社内ツール
• ハッカソン用プロトタイプ
• MVPで仮説検証したいSaaS
• 機械学習のデータ前処理スクリプト
• 使い捨ての移行スクリプト

17. 向かないプロジェクト

• 金融・医療・政府系のミッションクリティカル
• 大規模分散システム(整合性設計が肝)
• 長期保守が必要なOSSライブラリ
• 厳格な監査・コンプライアンス対応

これらは「AI支援はするが、設計と実装は人間主導」が原則です。Vibe Codingの「読まない」を持ち込むと事故ります。

18. AIが書いたコードを「自分のコード」にする方法

18.1 リライトの儀式

機能完成後、必ず自分の手で1ファイル書き直す。これだけでドメインが頭に入ります。

18.2 命名を全部見直す

// Before: AIが付けがちな汎用名
function handleData(data: any) { ... }

// After: ドメイン語彙
function normalizeInvoiceLineItems(items: InvoiceLineItem[]) { ... }

18.3 自分のテストを足す

AI生成テストの後に、必ず「自分が壊れて困るシナリオ」を1〜2件足しましょう。これがオーナーシップの境界線です。

19. 学習速度の比較(Vibe Coding時代の独学)

19.1 速い領域

• ライブラリAPIの習得(質問しまくれる)
• 新言語の基本構文(コード例が無尽蔵)
• 環境構築(エラーをそのまま貼れる)

19.2 遅くなりやすい領域

• 低レイヤ(メモリ、スレッド、ネットワーク)
• アルゴリズム設計(AIに出させるとパターン暗記で終わる)
• 大規模システム設計

このあたりは独学の限界とスクール活用で深掘りしています。

20. キャリアへの影響

20.1 ジュニアの定義が変わる

「コードが書ける」ことの価値が薄まり、「要件を引き出せる・設計できる・レビューできる」スキルが前倒しで求められます。35歳限界説とも絡みますが、シニアの実装力よりジュニアの上澄み層がAIで武装し、中間層が薄くなる動きが続いています。

20.2 副業・フリーランスにとっての追い風

副業やフリーランスでは、1人で完結できる範囲が広がるためVibe Codingの恩恵が大きい領域です。レバテックやGeeklyなどの案件サイトでも「AI活用前提」の案件が増えました。

20.3 学習リソース

体系的に学ぶなら、テックアカデミー・侍エンジニア・DMM WEBCAMPなどのスクールでも、2026年からはAIコーディングを取り入れたカリキュラムが標準になりました。「AIに任せる前提でドメインと設計を学ぶ」発想を持つかどうかで、学習効率が大きく変わります。

21. よくある質問(FAQ)

Q1. Vibe Codingで作ったコードは履歴書に書いていい?

書いていいですが、どの設計判断を自分でしたかを具体的に語れるようにしてください。「Cursorで作りました」で終わると評価は伸びません。

Q2. 月いくらかかる?

Cursor Pro $20/月、Claude Code Pro $20/月、ChatGPT Plus $20/月で合計$60前後が現場の標準。こちらの比較で詳述しています。

Q3. プログラミング未経験でも始められる?

始められますが、HTML/CSS/JSの基本構文と環境構築だけは事前に。完全未経験から始めると、エラーが出た瞬間に詰みます。

Q4. オフラインで使える?

主要ツールは原則クラウドです。完全オフラインはClaude Code+ローカルLLMでも限定的。商用は難しいです。

Q5. 機密コードを食わせて大丈夫?

各社のデータポリシーを確認のうえ、社内規程を整備してください。Cursor PrivacyモードやClaude Codeの企業契約など、「学習に使われない」契約を結べる選択肢があります。

22. まとめ

Vibe Codingは「雰囲気で書く」という軽さの裏に、要件定義力・読解力・レビュー眼というかなり高いメタスキルを要求します。プロトタイプの速度は10倍に化け、量産フェーズではむしろ落とし穴が増える——この両面性を理解して使い分けるのが2026年型エンジニアの基本姿勢です。

まずはCursorやClaude Codeを入れて、小さな個人プロジェクトで「読まない」感覚を一度味わってみてください。そのうえで本記事のレビュー観点・失敗パターン・プロダクション判断軸を持ち帰り、徐々に守備範囲を広げていけば、Vibe Codingはあなたの最大の武器になります。