先に要点
バイブコーディングは、AIに自然言語で「こういうものを作って」と伝え、コードの細部をAIにかなり任せながら開発するスタイルです。
2025年にAndrej Karpathy氏が「vibe coding」という言葉を使ったことで広く知られるようになり、Collins Dictionaryの2025年Word of the Yearにも選ばれました。
ただ、この言葉はかなり誤解されやすいです。
「プログラミングを知らなくても本番アプリが作れる」という希望の言葉として使われることもあれば、「コードを読まずに雰囲気で動かす危ない開発」という批判的な意味で使われることもあります。
この記事では、2026年4月19日時点で、Karpathy氏の発言として広く引用されている内容、Collins Dictionaryの説明、AIコーディングの最近の議論を踏まえながら、バイブコーディングとは何か、どこで役立ち、どこから危険になるのかを実務目線で整理します。
バイブコーディングとは
バイブコーディングは、作りたいものの雰囲気や目的をAIに伝え、AIが生成したコードを動かしながら、会話で修正していく開発スタイルです。
細かい構文や実装を人間が一行ずつ書くというより、AIに「こういう画面にして」「このエラーを直して」「ログイン後に管理画面へ飛ばして」と依頼し、出てきたものを試しながら進めます。
かなりざっくり言うと、次のような流れです。
- 作りたいものを自然言語で説明する
- AIがコードや設定を生成する
- 人間が動かしてみる
- エラーや違和感をAIに伝える
- AIが修正案を出す
- これを繰り返す
従来の開発では、人間が設計し、コードを書き、エラーを読み、修正します。
バイブコーディングでは、人間は「何を作りたいか」「どう動いてほしいか」を中心に伝え、コードの細部はAIに寄せる比率が高くなります。
何が新しいのか
AIによるコード補完自体は以前からありました。
バイブコーディングが違うのは、補完ではなく、開発の主導権のかなり大きな部分をAIとの会話に寄せる点です。
| 開発スタイル | 人間の役割 | AIの役割 |
|---|---|---|
| 従来の手書き開発 | 設計、実装、修正をほぼ自分で行う | 使わない、または調査補助 |
| コード補完 | 実装方針を決め、コードを書く | 行単位・関数単位で候補を出す |
| AIコーディング支援 | 要件、設計、レビュー、テストを担う | コード生成、修正、調査を補助する |
| バイブコーディング | 作りたい動きや雰囲気を伝え、動作確認する | 実装の多くを生成し、会話で修正する |
つまり、バイブコーディングは「AI補完を強く使う」だけではなく、自然言語を中心にソフトウェアを作る感覚に近いです。
ここが面白いところであり、危ないところでもあります。
向いている場面
バイブコーディングが向いているのは、失敗しても影響が小さく、早く形を見たい場面です。
- 個人用の小さなツール
- プロトタイプ
- 画面デザインのたたき台
- 管理画面のモック
- 使い捨てのスクリプト
- 学習用のサンプル
- アイデア検証
たとえば、「CSVを読み込んで簡単なグラフを出すツール」「Notionに貼るための整形スクリプト」「イベント用の簡単なLP」くらいなら、バイブコーディングはかなり相性がいいです。
人間が全部を書き始めるより、AIにざっと作らせて、動くものを見ながら直す方が速いことがあります。
特に、非エンジニアがアイデアを形にしたいときには強いです。
完璧な設計書を書く前に、動くものを見ながら「こうではなく、こうしたい」と言えるため、企画やデザインの初期検証に向いています。
向いていない場面
一方で、バイブコーディングをそのまま本番システムへ持ち込むのは危険です。
特に次のような領域では、雰囲気で進めるべきではありません。
AIが作ったコードは、見た目には動いていても、境界条件、セキュリティ、エラー処理、権限管理、保守性が弱いことがあります。
特に認証や権限まわりは、「動く」だけではまったく足りません。
ここで大事なのは、バイブコーディングが悪いという話ではありません。
バイブコーディングで作ったものを、本番品質のエンジニアリングとして扱うなら、別の確認工程が必要だという話です。
よくある失敗
1. コードを読まずにマージする
バイブコーディング最大の危険は、コードを理解しないまま採用することです。
AIは、もっともらしい命名、自然なコメント、動きそうな構成を作ります。だからこそ、危ないコードも安全そうに見えます。
たとえば、次のような問題が混ざることがあります。
- 入力値検証がない
- SQLインジェクション対策が弱い
- 権限チェックが抜けている
- 例外処理が雑
- 秘密情報をログに出す
- 古いライブラリや非推奨APIを使う
- テストしづらい巨大な関数になる
コードを読まないなら、少なくとも本番へ入れるべきではありません。
2. エラーをAIに貼るだけで原因を理解しない
エラーが出るたびにAIへ貼り、AIが出した修正をまた貼る。
これを繰り返すと、短期的には進んでいるように見えますが、原因を理解しないまま修正が積み上がります。
その結果、最初の問題は消えても、別の場所に副作用が出ます。
AIとの会話で進める場合でも、「なぜこの修正が必要なのか」「他に影響しないか」は確認した方が安全です。
3. 仕様が曖昧なままAIに任せる
AIは、曖昧な指示にも何かを返します。
しかし、仕様が曖昧なら、AIは勝手に前提を補います。
たとえば「ユーザー管理を作って」だけだと、管理者権限、メール認証、パスワードリセット、退会、論理削除、監査ログ、個人情報の扱いなど、重要な仕様が抜けます。
プロトタイプならよくても、本番機能では危険です。
4. テストなしで「動いた」と判断する
画面で1回動いたことと、品質があることは違います。
入力が空の場合、権限がない場合、通信に失敗した場合、同時実行された場合、不正な値が来た場合まで見る必要があります。
バイブコーディングでは、動くものが早く出るぶん、テストを後回しにしがちです。
ここは意識して止めないと、あとでかなり痛くなります。
実務で安全に使うなら
バイブコーディングを実務で使うなら、入口は軽く、出口は厳しくするのが現実的です。
つまり、作るときはAIで速く進めても、本番へ入れる前には通常の開発プロセスに戻します。
| 確認 | 見るポイント |
|---|---|
| 差分レビュー | 何が変わったかを人間が説明できるか |
| テスト | 正常系、異常系、権限、境界値を確認したか |
| セキュリティ | 入力検証、認可、秘密情報、ログ、依存ライブラリを見たか |
| 保守性 | 命名、分割、責務、既存設計との整合性があるか |
| 運用 | 失敗時のログ、ロールバック、監視、問い合わせ対応を考えたか |
AIに作らせたからといって、レビューやテストを軽くしてよいわけではありません。
むしろ、AIが大量に差分を作れるぶん、確認の仕組みは重要になります。
Claude CodeやCursorとの関係
バイブコーディングは特定のツール名ではありません。
ただし、Claude Code、Cursor、Cline、Replit、Bolt系のようなAIコーディングツールと相性が良いスタイルです。
これらのツールは、自然言語で依頼し、コードを生成・修正し、エラーを見ながら再修正する流れを支援します。
とくにAIエージェント型のツールでは、ファイル検索、コマンド実行、テスト実行まで任せられることがあります。
ただし、ツールが強くなるほど危険も増えます。
AIが読めるファイル、実行できるコマンド、変更できる範囲、外部へ送信できる情報を制御しないと、想定外の操作につながります。
このあたりは、ハーネスエンジニアリングやガードレールの考え方とつながります。
AIに任せる範囲が広がるほど、実行環境、権限、評価、ログ、停止条件を設計する必要があります。
バイブコーディングとプロンプトエンジニアリングの違い
プロンプトエンジニアリングは、AIへの指示を整える考え方です。
バイブコーディングは、その指示を使って実際にソフトウェアを作っていく開発スタイルです。
言い換えると、プロンプトエンジニアリングは部品で、バイブコーディングは作業全体の進め方です。
ただ、バイブコーディングでは「完璧なプロンプトを書く」より、AIと対話しながら動くものを作り、違和感を伝えて直す流れが中心になります。
そのため、最初の指示よりも、途中でどうフィードバックするかが重要です。
たとえば、
この画面をもっと見やすくして
より、
一覧の情報量が多すぎます。
ステータス、担当者、期限だけを先に見せて、詳細は展開式にしてください。
既存のCSSクラスを優先し、新しいライブラリは追加しないでください。
の方が、AIは実務に近い修正をしやすくなります。
雰囲気で始めても、最後は具体的な制約へ落とすことが大事です。
学習には役立つのか
バイブコーディングは、学習にも役立ちます。
ただし、使い方を間違えると、動くものは作れるのに基礎が身につかない状態になります。
学習目的で使うなら、次の使い方がよいです。
- AIにコードを書かせたあと、1行ずつ説明させる
- 似たコードを自分で書き直す
- エラーの原因を自分の言葉でまとめる
- テストケースをAIに作らせ、自分で意味を確認する
- セキュリティ上の問題点を質問する
逆に、コピペだけで進めると、エラーが出た瞬間に止まります。
バイブコーディングは、学習を飛ばす道具ではなく、学習の入り口を広げる道具として使う方が強いです。
本番投入前チェックリスト
バイブコーディングで作ったものを本番に近づけるなら、最低限このあたりを確認します。
| 項目 | 確認すること |
|---|---|
| 仕様 | AIが勝手に補った前提がないか |
| 認証・認可 | ログイン済みか、権限があるか、管理者だけの操作か |
| 入力検証 | 空、長すぎる値、不正な形式、想定外の文字を処理できるか |
| エラー処理 | 失敗時に安全に止まり、秘密情報を表示しないか |
| テスト | 自動テスト、手動確認、回帰確認を行ったか |
| 依存関係 | 不要なライブラリ、古いパッケージ、ライセンス問題がないか |
| 差分 | 関係ないファイルまで変更されていないか |
| 運用 | ログ、監視、バックアップ、ロールバックを考えたか |
この確認が重いと感じるなら、その機能はまだ本番に入れる段階ではない可能性があります。 バイブコーディングは速度をくれますが、責任までは引き受けてくれません。
バイブコーディングに関するよくある質問
Q. バイブコーディングは本当に新しい開発スタイルですか？
A. 用語としては Andrej Karpathy が2025年初頭に広めた表現で、コードの細部を AI に任せる速度重視のスタイル を指します。技術自体は新しくありませんが、Cursor や Claude Code のような IDE 統合 AI で実用性が大きく上がりました。
Q. プロトタイプ以外の用途に使えますか？
A. 個人ツール、社内ツール、検証用スクリプト、デモ環境などでは実用十分です。商用本番、決済、認証、医療系のような失敗が許されない領域には、レビューとテストを十分にかけないとリスクが大きいです。
Q. AI 生成コードに脆弱性は混ざりますか？
A. 混ざります。SQL Injection、XSS、認可不備、危険な依存関係、シークレットの平文保存、などが典型的に出ます。AI が書いたら静的解析を必ず通す、セキュリティテストを習慣化する が安全策です。
Q. ジュニアエンジニアが学ぶ機会を奪いますか？
A. その懸念はあります。AI に書かせる前に自分で考える時間 を意識的に取る、生成コードを必ず読む、AI に説明を求めて理解する、などの習慣化が学習を保つコツです。
Q. テストはどう書きますか？
A. 機能実装は AI に任せても、テストは人が書く / レビューする が安全です。生成テストは抜けやすく、テストが緩いと本体のバグを見逃すからです。
Q. バイブコーディングで効率が下がる場面は？
A. 既存大規模コードベースへの修正、複雑な業務ロジック、レガシーコードの理解、高度な設計判断、などは AI を多用するより人手で考える方が早いことがあります。
Q. チームでバイブコーディングを使うときのガバナンスは？
A. AI 利用ポリシー、コードレビュー必須、セキュリティスキャン必須、Enterprise 契約 + 入力データルール、本番マージ前の人間承認 などで運用ルールを明文化します。
まとめ
バイブコーディングは、AIに自然言語で作りたいものを伝え、コードの細部をAIに大きく任せながら進める開発スタイルです。
プロトタイプ、個人ツール、画面のたたき台、学習の入口としてはかなり強力です。
一方で、本番システムを雰囲気だけで作るのは危険です。
動くことと、保守できること、安全であること、仕様を満たすことは別です。
実務での落としどころは、バイブコーディングを「速く形にする入口」として使い、最後はレビュー、テスト、セキュリティ確認、運用設計で締めることです。
AIに任せるほど、人間はコードを書く量より、何を作るべきか、どこまで安全か、どの差分を受け入れるかを判断する力が求められます。