バイブコーディングの「光と影」——なぜ限界を知るべきなのか
バイブコーディングが変えた開発の常識
まず前提として、僕はバイブコーディングの大推進派です。ShiftBのカリキュラムでもバイブコーディングを中核に据えていますし、自社サービスの開発でもClaude CodeとCursorを毎日使っています。
バイブコーディングがもたらした恩恵は計り知れません。実際にShiftBの受講生データを見ても、その効果は明らかです。
| 指標 | バイブコーディング導入前 | バイブコーディング導入後 | 変化率 |
|---|
| MVP完成までの平均期間 | 6.2週間 | 1.9週間 | 3.2倍高速化 |
| プロダクトリリース率 | 42% | 77% | +35ポイント |
| 1日あたりのコード生産量 | 約150行 | 約520行 | 3.5倍 |
| 挫折率（3ヶ月以内） | 38% | 15% | -23ポイント |
数字だけ見れば、バイブコーディングは完全に「正解」に見えます。しかし、このデータには続きがあります。
見落とされている「もうひとつのデータ」
同じ受講生142名のデータをさらに深掘りすると、別の現実が見えてきます。
| 問題の種類 | 発生率 | 深刻度 |
|---|
| セキュリティ上の脆弱性（リリース前に発見） | 68% | 高 |
| リリース後1ヶ月以内に重大バグ発生 | 45% | 高 |
| 3ヶ月以内に「コードが読めない」と感じた | 72% | 中 |
| 機能追加時に予期しない箇所が壊れた | 61% | 中 |
| パフォーマンス問題（ユーザー100人超で顕在化） | 34% | 中〜高 |
速く作れても、「使えるプロダクト」になっていないケースが圧倒的に多い——これがバイブコーディングの不都合な真実です。
「限界を知る」ことが最大の武器になる
誤解しないでください。バイブコーディングが「ダメ」なのではありません。限界を知らずに使うことが危険なのです。
車を運転するとき、ブレーキの効き方やスリップしやすい路面条件を知っているドライバーと、アクセルしか踏めないドライバー——どちらが安全に速く走れるかは明らかです。
バイブコーディングも同じです。限界を理解した上で使いこなす人こそが、本当に価値あるプロダクトを生み出せるのです。
限界① セキュリティ——AIが生むコードの27%に脆弱性がある現実
AIは「動くコード」を最優先する
AIコーディングツールの最大の問題は、「動くこと」を最優先し、「安全であること」を二の次にする傾向があることです。
2026年のCheckmarxの調査によると、AIが生成したコードの27%にセキュリティ上の脆弱性が含まれていました。さらにVeracodeの調査では、AI共著コードの脆弱性発生率は人間が書いたコードの2.74倍という衝撃的な数字が出ています。
実際に起きたセキュリティ事故の例
ShiftBの受講生サポートの中で実際に遭遇した、バイブコーディング起因のセキュリティ問題を紹介します（個人を特定できない形に加工しています）。
事例1: SupabaseのRLS未設定（発生率: 最も多い）
Claude CodeやCursorに「SupabaseでToDoアプリを作って」と指示すると、AIは高確率でRLS（Row Level Security）を設定しないままテーブルを作成します。結果として、全ユーザーのデータが誰でも閲覧・編集可能な状態になります。
悪い例：AIが生成しがちなコード
-- AIが生成するテーブル作成文（RLSなし）
CREATE TABLE todos (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
user_id UUID REFERENCES auth.users,
title TEXT NOT NULL,
completed BOOLEAN DEFAULT FALSE
);
-- ← RLSが有効化されていない！
良い例：セキュリティを考慮したコード
-- RLSを有効化し、ポリシーを設定
CREATE TABLE todos (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
user_id UUID REFERENCES auth.users NOT NULL,
title TEXT NOT NULL,
completed BOOLEAN DEFAULT FALSE
);
ALTER TABLE todos ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can only access own todos"
ON todos FOR ALL
USING (auth.uid() = user_id);
事例2: APIキーのハードコード
AIに「Stripe決済を実装して」と指示すると、開発の利便性を優先してシークレットキーをフロントエンドのコードに直接埋め込むことがあります。これがGitHubにプッシュされると、第三者に課金操作される危険性があります。
事例3: SQLインジェクション対策の欠如
検索機能を実装する際、AIがユーザー入力をそのままSQLクエリに組み込むコードを生成するケースがあります。Supabaseのクライアントライブラリを使っていれば基本的には安全ですが、Server Actionsで生のSQLを書く場合は要注意です。
セキュリティ脆弱性の種類と発生頻度
| 脆弱性の種類 | AI生成コードでの発生率 | 深刻度 | 対策の難易度 |
|---|
| 認証・認可の不備（RLS未設定含む） | 42% | 致命的 | 中 |
| APIキー・シークレットの露出 | 31% | 致命的 | 低 |
| 入力値バリデーションの不足 | 38% | 高 | 低 |
| XSS（クロスサイトスクリプティング） | 25% | 高 | 中 |
| CSRF対策の欠如 | 19% | 中 | 低 |
AI時代のアプリ開発コース
ShiftBのAIシフトコースは、Claude Codeで本格的なWebアプリケーションを作りながらAI駆動開発を身につけるコースです。ただ作って終わりではなく、コードを読め、セキュリティに責任を持って提案でき、要件定義などの上流工程まで担えるところまで現役エンジニアがサポートします。
AIシフトコースを見る →限界② 技術的負債——バイブコーディングは負債を3倍速で積み上げる
なぜAI生成コードは「負債化」しやすいのか
バイブコーディングで生成されたコードは、技術的負債を従来の3倍のスピードで蓄積するという研究結果があります。その理由は明確です。
AIは「その場の要求」に最適化したコードを書く。プロジェクト全体の設計思想や、将来の拡張性を考慮した設計をAIに期待することは、現時点では難しいのです。
技術的負債が蓄積する5つのメカニズム
1. コピペ的な重複コード
AIに「ユーザー一覧ページを作って」「商品一覧ページを作って」と個別に指示すると、ほぼ同じ構造のコードがそれぞれ独立して生成されます。共通のリストコンポーネントを作るという発想がAIにはありません（明示的に指示しない限り）。
2. 不要な依存パッケージの追加
AIは問題を解決するために、すぐにnpmパッケージをインストールしようとします。「日付のフォーマットをしたい」だけでmoment.js（287KB）をインストールしたり、すでにプロジェクトにあるdate-fnsを無視して別のライブラリを入れるケースは日常茶飯事です。
3. 一貫性のない命名規則
チャットの会話が長くなると、AIは以前の文脈を忘れます。同じプロジェクト内でgetUserData、fetchUserInfo、loadUserProfileと、同じ処理に異なる命名が使われるようになります。
4. エラーハンドリングの欠如
AIは「正常系」のコードを書くのは得意ですが、「異常系」の処理が甘くなりがちです。ネットワークエラー、タイムアウト、想定外の入力——これらの処理が抜けていると、本番環境でユーザーが真っ白な画面を見ることになります。
5. テストコードの不在
バイブコーディングで作られたプロジェクトの89%がテストコードを持っていない（ShiftB受講生調べ）。AIに「テストも書いて」と指示すれば書いてくれますが、多くの人がその一言を忘れるのです。
技術的負債の「見える化」——3ヶ月後の比較
| 指標 | 適切に管理されたプロジェクト | 負債を放置したプロジェクト |
|---|
| 新機能追加にかかる平均時間 | 2〜3時間 | 8〜12時間 |
| バグ修正にかかる平均時間 | 30分 | 3〜5時間 |
| 他の開発者が理解するのにかかる時間 | 1〜2時間 | 1〜2日 |
| リファクタリングの必要性 | 部分的 | 全面書き直し |
限界③ スケーラビリティ——「動く」と「使える」の間にある深い溝
ユーザー10人で「動く」は当たり前
バイブコーディングで作ったMVPが「ちゃんと動いた！」と喜ぶのは早いです。開発環境やユーザー数人の段階では、ほとんどのアプリは問題なく動きます。問題は、ユーザーが100人、1,000人と増えたときに顕在化します。
スケーラビリティ問題が発生する3つのポイント
1. N+1クエリ問題
AIが生成するデータ取得コードは、しばしば「N+1クエリ問題」を含んでいます。一覧ページで10件のデータを表示するために11回のデータベースクエリが走る——ユーザーが少ないうちは気づきませんが、データが増えるとページ読み込みに数十秒かかるようになります。
2. フロントエンドの無駄な再レンダリング
Reactを使ったアプリで、AIは状態管理を最小限の労力で実装します。結果として、1つの状態変化でアプリ全体が再レンダリングされるような構造になりがちです。コンポーネントが増えるにつれ、UIの応答速度が目に見えて悪化します。
3. 画像・アセットの最適化不足
AIに「画像アップロード機能を作って」と指示すると、圧縮やリサイズの処理が入らないことが多いです。ユーザーがスマホで撮った5MBの写真がそのまま保存され、一覧ページで10枚表示すると50MBのデータ転送が発生します。
パフォーマンス劣化の実測データ
| ユーザー数 | 最適化なし（平均応答時間） | 最適化あり（平均応答時間） |
|---|
| 10人 | 0.3秒 | 0.2秒 |
| 100人 | 1.8秒 | 0.3秒 |
| 500人 | 5.2秒 | 0.4秒 |
| 1,000人 | 12.5秒（タイムアウト多発） | 0.5秒 |
Googleの調査によると、ページ読み込みが3秒を超えると53%のユーザーが離脱します。せっかくバイブコーディングで素早くリリースしても、パフォーマンスが悪ければユーザーは定着しません。
限界④ AIへの過度な依存——「理解せずに進む」の代償
「コピペプログラマー2.0」問題
かつてStack Overflowからコードをコピペして開発する「コピペプログラマー」が問題視されましたが、バイブコーディングはその進化版ともいえます。
AIが生成したコードを理解せずにそのまま採用する開発スタイルは、短期的には速いですが、中長期的には致命的です。
理解なき開発の4つのリスク
1. デバッグ能力の欠如
コードを理解していないと、バグが発生したときに自分で原因を特定できません。AIに「直して」と指示しても、AIは文脈を完全には把握できないため、別のバグを生む「モグラ叩き」状態に陥ります。
ShiftBの受講生データによると、コードを理解せずにバイブコーディングで進めた受講生は、1つのバグ修正に平均4.2回のAI往復が必要でした。一方、基礎を理解している受講生は平均1.3回で解決しています。
2. 要件の伝達ミス
プログラミングの基礎を知らないと、AIへの指示も曖昧になります。「ログイン機能を作って」と言っても、セッション管理、パスワードハッシュ化、メール認証、多要素認証——どこまで実装するのか、適切に伝えられません。
3. AIの「幻覚」を見抜けない
AIは自信たっぷりに間違ったコードを提案することがあります。存在しないAPIを呼び出したり、非推奨のメソッドを使ったり。プログラミングの基礎知識がなければ、これらの「幻覚」を見抜くことは不可能です。
4. アーキテクチャ設計ができない
個々のファイルのコードはAIが書けますが、アプリ全体の設計——フォルダ構成、状態管理の戦略、API設計、データベース設計——は人間が決める必要があります。この設計力は、プログラミングの基礎なしには身につきません。
「理解度」による開発成果の違い
| 指標 | 基礎理解あり + バイブコーディング | 基礎理解なし + バイブコーディング |
|---|
| リリースまでの期間 | 2〜3週間 | 1〜2週間（※ただし品質低い） |
| リリース後の重大バグ | 平均0.8個 | 平均4.5個 |
| 3ヶ月後もサービス継続 | 82% | 31% |
| 収益化に成功 | 28% | 5% |
「急がば回れ」という言葉がぴったりです。基礎を理解した上でバイブコーディングを使う人が、最も速く、最も遠くまで行けるのです。
AI時代のアプリ開発コース
ShiftBのAIシフトコースは、Claude Codeで本格的なWebアプリケーションを作りながらAI駆動開発を身につけるコースです。ただ作って終わりではなく、コードを読め、セキュリティに責任を持って提案でき、要件定義などの上流工程まで担えるところまで現役エンジニアがサポートします。
AIシフトコースを見る →ShiftB受講生142名のデータに見る失敗パターンTOP5
ShiftBでは、受講生142名のバイブコーディングによる開発プロジェクトを分析し、共通する失敗パターンを特定しました。ここでは、発生頻度の高い順にTOP5を紹介します。
第1位: CLAUDE.mdやカーソルルールを設定しない（発生率: 78%）
AIツールにプロジェクトの文脈を伝える設定ファイル（CLAUDE.mdやCursorRules）を作成せずに開発を始めるケースが最も多い失敗パターンです。
設定なしだと、AIは毎回ゼロから文脈を推測するため、コーディング規約がバラバラになり、既存コードと矛盾する実装が増えます。
対策：プロジェクト開始時に、技術スタック・コーディング規約・ディレクトリ構造・重要な設計方針をCLAUDE.mdに記述してからバイブコーディングを始める。
第2位: テストを書かない（発生率: 89%）
「動いたからOK」でリリースする——バイブコーディングの「速さ」に酔って、テストを完全にスキップするパターンです。
テストがないプロジェクトは、新機能追加時に既存機能が壊れているかどうかを確認する手段がありません。結果として、ユーザーから「昨日まで使えた機能が消えた」という問い合わせが頻発します。
対策：最低限、認証・決済・データ操作などビジネスクリティカルな機能にはテストを書く。AIに「この機能のテストも一緒に書いて」と一言添えるだけで劇的に改善する。
第3位: AIの提案を無批判に受け入れる（発生率: 65%）
AIが提案するコードをレビューせずにそのまま採用してしまうパターンです。特に初学者に多く、不要なパッケージのインストール、非推奨APIの使用、セキュリティ上問題のあるコードが混入します。
対策：AIが生成したコードの変更点を必ずdiffで確認する。Claude Codeの場合、変更前後の差分が表示されるので、最低限「何が変わったか」を目視確認する習慣をつける。
第4位: 1つのプロンプトに詰め込みすぎる（発生率: 58%）
「ログイン機能、ダッシュボード、プロフィール編集、通知機能、設定画面を全部作って」——1回のプロンプトで大量の機能を要求するパターンです。
AIは一度に処理する情報量が増えると、各機能の品質が低下します。1プロンプト1機能の原則を守ることで、生成されるコードの品質は格段に向上します。
対策：大きな機能は小さなタスクに分解し、1つずつAIに依頼する。「まずデータベースのスキーマを設計して」→「次にAPIエンドポイントを作って」→「最後にフロントエンドのUIを作って」のように段階的に進める。
第5位: バージョン管理をしない（発生率: 43%）
Gitを使わずに開発を進め、AIが意図しない変更を加えたときに元に戻せなくなるパターンです。
バイブコーディングでは、AIが一度に大量のファイルを変更します。その変更が意図通りでなかった場合、Gitがなければ手作業で元に戻す必要があり、膨大な時間をロスします。
対策：機能追加のたびにコミットする習慣をつける。Claude Codeなら/commitコマンドで自動コミットできるので、活用しない手はない。
限界を超える7つの実践テクニック
ここまで限界と落とし穴を紹介してきましたが、恐れる必要はありません。以下の7つのテクニックを実践すれば、バイブコーディングの恩恵を最大限に受けながら、リスクを最小限に抑えられます。
テクニック1: CLAUDE.mdを最初に作る（所要時間: 15分）
プロジェクト開始時に、AIへの「取扱説明書」を作成します。技術スタック、コーディング規約、ディレクトリ構造、避けるべきパターンを記述することで、AIの出力品質が一貫性を持つようになります。
最低限含めるべき項目：
- 使用する技術スタック（Next.js 15, Supabase, Tailwind CSS等）
- コーディング規約（命名規則、ファイル構成）
- セキュリティ要件（RLS必須、環境変数の使用等）
- 禁止事項（不要なパッケージの追加禁止等）
テクニック2: セキュリティチェックリストを使う（所要時間: 10分/機能）
新しい機能を実装するたびに、以下のチェックリストを確認します。
- RLS（Row Level Security）は有効か？
- APIキー・シークレットは環境変数に入っているか？
- ユーザー入力のバリデーションは行われているか？
- 認証チェックはすべてのAPI経路に入っているか？
- エラーメッセージに内部情報が含まれていないか？
テクニック3: テストをAIに「一緒に」書かせる（所要時間: 追加5分/機能）
機能を実装する際、プロンプトの末尾に「テストも一緒に書いて」と一言添えるだけです。AIは機能と同時にテストコードも生成してくれます。
すべてのコードにテストを書く必要はありません。認証・決済・データ操作など、バグが致命的になる箇所に絞ればOKです。
テクニック4: 段階的に開発する（1プロンプト1機能）
大きな機能を一度に作らず、小さなタスクに分解してAIに依頼します。
- データベース設計: テーブル構造とRLSポリシーを先に作る
- API層: Server ActionsまたはAPIルートを作る
- UI層: フロントエンドのコンポーネントを作る
- テスト: 重要な機能のテストを書く
- レビュー: 生成されたコードを確認する
テクニック5: Gitを「保険」として使う
機能が1つ完成するたびにコミットします。AIが予期しない変更を加えても、git diffで変更点を確認し、git checkoutで元に戻せます。
Claude Codeを使っているなら、各タスクの完了時に自動でコミットしてくれる設定も可能です。
テクニック6: AIの出力を「レビュー」する習慣をつける
AIが生成したコードをそのまま採用せず、最低限以下の3点を確認します。
- 差分の確認: 何が変更されたかをdiffで見る
- 新しい依存の確認:
package.jsonに不要なパッケージが追加されていないか - セキュリティの確認: 上記チェックリストに照らし合わせる
テクニック7: 基礎学習を並行で続ける（1日30分）
バイブコーディングと並行して、プログラミングの基礎を学び続けることが重要です。HTML/CSS/JavaScriptの基礎、Reactの状態管理、データベースの基本概念——これらを理解していると、AIへの指示が的確になり、出力の品質が劇的に向上します。
学習の優先順位：
- HTML/CSS/JavaScriptの基礎（1〜2週間）
- Reactの基本概念（コンポーネント、状態管理、hooks）（2〜3週間）
- データベースの基礎（テーブル設計、SQL、RLS）（1〜2週間）
- Gitの基本操作（1週間）
- セキュリティの基礎知識（継続的に）
よくある質問（FAQ）
Q. バイブコーディングは初心者が手を出すべきではないですか？
いいえ、むしろ初心者こそバイブコーディングを使うべきです。ただし、HTML/CSS/JavaScriptの基礎（1〜2週間程度）を学んでから始めることを強く推奨します。まったくのゼロ知識だと、AIの出力が正しいかどうかの判断ができず、結果的に大きな手戻りが発生します。ShiftBでは「基礎2週間 → バイブコーディング実践」のカリキュラムを推奨しており、このルートが最も効率的です。
Q. バイブコーディングで作ったアプリを本番環境にリリースしても大丈夫ですか？
条件付きで「はい」です。この記事で紹介した7つのテクニック——特にセキュリティチェックリストとテストの実装を実践していれば、本番リリースに耐えうるクオリティのアプリは作れます。実際に、ShiftBの受講生が作ったアプリの中で、適切な対策を施した上でリリースし、月数万円の収益を上げているサービスは複数存在します。
Q. セキュリティの知識がまったくないのですが、どこから学べばいいですか？
最低限、以下の3つを理解していれば、個人開発レベルでは十分です。①認証と認可の違い（誰がログインしているかと、何ができるかは別）、②環境変数の使い方（秘密情報をコードに直書きしない）、③RLSの概念（データベースのアクセス制御）。これら3つは、バイブコーディングを始める前の30分で学べます。
Q. Claude CodeとCursor、どちらがセキュリティ的に安全ですか？
ツール自体のセキュリティに大差はありません。どちらも使う人間のリテラシー次第です。ただし、Claude Codeは変更の差分を表示して確認を求めてくれるため、「レビューの習慣づけ」という意味ではClaude Codeのほうが初心者向きです。Cursorの場合は、Composerの変更を必ず確認してからAcceptする習慣をつけてください。
Q. バイブコーディングの「限界」はいつ解消されますか？
技術の進化により、セキュリティやパフォーマンスの問題は年々改善されています。2026年時点で、Claude CodeのCLAUDE.md対応やCursorのカスタムルール機能など、「AIにプロジェクト文脈を伝える」仕組みは大きく進化しました。しかし、「人間が設計し、AIが実装する」という分業構造は今後も変わらないでしょう。つまり、設計力・判断力を持った人間の役割はなくなりません。
Q. エージェンティックエンジニアリングに移行すべきですか？
バイブコーディングと対比される「エージェンティックエンジニアリング」は、AIをより厳密に管理する開発スタイルです。プロフェッショナルな開発では移行が進んでいますが、個人開発や学習段階では、まずバイブコーディングの限界を理解して適切に使いこなすことが先決です。限界を理解した上でのバイブコーディングは、エージェンティックエンジニアリングへの自然なステップになります。
Q. ShiftBではバイブコーディングの限界にどう対応していますか？
ShiftBでは、この記事で紹介した7つのテクニックをカリキュラムに組み込んでいます。特にCLAUDE.mdの設計とセキュリティレビューは必修項目として設定しており、メンターによるコードレビューでセキュリティ問題を早期に発見する体制を整えています。受講生がリリースしたプロダクトで、セキュリティインシデントの報告はゼロです。
まとめ——限界を知ることが、最強のバイブコーダーへの第一歩
この記事のポイントを整理します。
バイブコーディングの4つの限界
- セキュリティ: AI生成コードの27%に脆弱性。RLS未設定、APIキー露出に特に注意
- 技術的負債: 従来の3倍の速度で蓄積。重複コード、不要な依存、テスト不在が主因
- スケーラビリティ: ユーザー100人超でパフォーマンスが急激に悪化しうる
- AI依存: 基礎理解なしでは、バグ修正に4倍の時間がかかり、3ヶ月後の継続率が31%に低下
限界を超えるための核心
バイブコーディングの限界は、バイブコーディングそのものの欠陥ではなく、「使い方」の問題です。CLAUDE.mdの設定、セキュリティチェックリスト、テストの実装、段階的な開発、Gitの活用、コードレビュー、基礎学習——これら7つのテクニックを実践するだけで、バイブコーディングの恩恵を最大化しながらリスクを最小化できます。
限界を知った上で使いこなす人が、真のバイブコーダーです。
ShiftBでは、バイブコーディングの「光と影」の両面を理解した上で、実践的なプロダクト開発スキルを身につけるカリキュラムを提供しています。興味のある方は、まず無料相談会でお気軽にご相談ください。
バイブコーディングについてもっと詳しく知りたい方は、以下の記事もあわせてご覧ください。
