目次
2025年2月、OpenAI 共同創業者・元 Tesla AI リーダーの Andrej Karpathy が X に投稿した一文から、ある言葉が世界中に広まった——「vibe coding（バイブコーディング）」。
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
（コードという存在自体を忘れて、流れに身を任せる新しいコーディング——それを「バイブコーディング」と呼んでみたい）
1年後の2026年、この言葉は 賛否両論の中心 にある。Karpathy 自身が改名を提案し、エンタープライズではセキュリティ事故が急増し、それでも個人開発・スタートアップ・社内ツール開発では 標準的なコーディングスタイル として定着した。本記事では、定義から最新の議論までを公式情報と業界データベースで整理する。
バイブコーディング＝「コードを読まずにAIに任せる」流儀
— 伝統的コーディングとエージェント・エンジニアリングの間にある立ち位置
バイブコーディングは 気軽に試作する のには最強。
本番に投入するなら、エージェント・エンジニアリング側に寄せていく必要がある。
1. バイブコーディングとは何か
バイブコーディング（vibe coding）とは、「コードを書く・読む」のではなく「コードに何をさせたいかを話す」スタイルのプログラミング。AI（Claude / GPT / Cursor Composer 等）に自然言語で要望を伝え、生成されたコードを読まずに実行・修正依頼を繰り返す。
核となる思想は3つ:
- コードへの執着を捨てる: 「自分が書いたコード」という所有感を手放す
- 動けば良し: 動作を確認したら、内部実装の理解は後回し（or 永遠にしない）
- 会話で進める: バグやエラーが出たら、AIに「直して」と話す。スタックトレースをコピペするだけ
典型例: 個人開発者が「Tetris ゲームを Pygame で作って」とプロンプト → Claude が500行のコードを出す → 実行 → ボールが落ちないので「ブロックが回転しない」と伝える → 修正版を受け取る。1行も自分で書かずに完成。
2. Karpathy の発明と1年後の改名
「vibe coding」という言葉は、2025年2月に Andrej Karpathy が X（旧 Twitter）で生み出した造語だ。Cursor Composer（当時 Sonnet 搭載）と SuperWhisper（音声入力）を組み合わせて、ほぼ話すだけでアプリを作る体験を表現した。
その後1年で起きたこと:
- 2025年8月: 主要LLMが SWE-bench で60%超を達成、vibe coding が現実味を帯びる
- 2025年12月: Karpathy 自身が「11月は手書き80%だったが、12月は AI生成80%」とワークフローの劇的な逆転を報告
- 2026年2月: Karpathy が「vibe coding」という名前を捨て、「agentic engineering（エージェント・エンジニアリング）」に改名することを提案。違いは「vibe = 何か欲しいかを話して、返ってきたものを受け入れる」「agentic engineering = システムを設計し、制約を指定し、すでに考え抜いた実装を AI で加速する」
つまり vibe coding は 「概念を広めた言葉」だが、本人がもう推奨していない状態にある。それでも市場では vibe coding という言葉が使われ続けている——それは 「気軽さ」「コードを読まない解放感」のニュアンスを含む言葉が他に無いからだ。
3. 典型的なワークフロー
ここまで抽象論だったので、実際の作業ループを見ておく。
Describe → Generate → Run → Talk back
この4ステップを 数十回〜数百回 繰り返して機能を組み上げる。
従来の「設計 → 実装 → テスト」線形フローとは別物。
4. 代表的なツール
2026年5月時点で vibe coding スタイルが特に効くツール群。
| ツール | 提供元 | 強み | 典型ユース |
|---|---|---|---|
| Claude Code | Anthropic | 長時間自律タスク、MCP統合、narrate-then-code でコード理解も助ける | 既存リポジトリへの大規模変更、新規プロジェクト立ち上げ |
| Cursor Composer | Cursor | IDE一体型、複数ファイル編集、Karpathy が好んで使うことで知名度爆発 | 個人開発、スタートアップ MVP |
| Codex CLI | OpenAI | GPT-5.5 統合、端末オートメーションが強い | CLI ツール、スクリプト群、運用自動化 |
| Lovable | 独立スタートアップ | 「アプリを話すだけで作る」専用 UI、デプロイまで自動 | 非エンジニアの SaaS プロトタイプ |
| v0 | Vercel | UI コンポーネント特化、生成 → デプロイが滑らか | ランディングページ、フロント単体 |
| Bolt.new | StackBlitz | ブラウザ完結、フルスタック WebApp を雛形から生成 | 勉強用、デモ、社内ツール |
| Devin | Cognition | 自律エージェント。チケット渡せば PR まで作る | チームの「もう1人のエンジニア」枠 |
非エンジニアが学習・プロトタイプ目的で使うなら Lovable / v0 / Bolt.new。職業エンジニアが既存コードに対して使うなら Claude Code / Cursor / Codex CLI が現状の王道だ。
5. 暗い面——セキュリティと品質の現実
「vibe coding は気持ちいい。でも本番投入は別の話」——この温度差が2026年に明確になった。第三者調査の数字は厳しい。
数字で見る vibe coding の暗い面
— 楽しいからといって安全ではない
2026年1月比: 約6倍
Georgia Tech Vibe Security Radar
業界調査の中央値
100%が同種の SSRF 脆弱性を導入
Tenzai 12月調査
セキュリティ脆弱性は 2.74倍
CodeRabbit 470 PR 分析
人間製は 1.5% — 約2倍
CSA 2026
86% に XSS 脆弱性
Georgetown CSET
Escape.tech が公開済 vibe coding アプリ 5,600 件をスキャン → 2,000件の重大脆弱性、400件の API キー露出、175件の PII（医療・決済データ）露出を検出。「動いている」と「安全である」は別の話。
これは「AI が悪い」のではなく、「コードを読まずに本番投入する開発スタイル」が悪いという構造問題だ。同じ AI でも、人間がレビューと検証を入れれば事故率は大きく下がる。
6. バイブ vs エージェント・エンジニアリング
Karpathy が2026年に提案した改名を理解しておくと、運用判断が明確になる。
| 観点 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 始点 | 「これを作りたい」と話す | 「こう設計したい」と決める |
| 制約の明示 | 暗黙、AI の解釈に任せる | 明示、AIに伝える |
| コード理解 | 不要、結果だけ確認 | 必須、AIは加速ツール |
| レビュー | 動作確認のみ | 差分・設計判断・セキュリティを見る |
| 適用範囲 | 個人実験、学習、捨てるコード | 本番システム、長期運用、共有資産 |
| 失敗パターン | セキュリティ事故、保守不能 | 遅くなる、AI の制約に縛られる |
| 主役 | AI | 人間（AIは増幅装置） |
同じツール（Claude Code / Cursor）を使っていても、使う人の姿勢で vibe coding にも agentic engineering にも変わる。重要なのは「いま自分はどっちのモードか」を意識的に切り替えること。
7. 「Vibe & Verify」——実用のための鉄則
2026年に標準化しつつあるベストプラクティスは 「Vibe & Verify」。AIに書かせる軽快さを保ったまま、後段で必ず検証を入れる。
① ステークごとにモードを切り替える
- 低ステーク（個人ツール、勉強用、スクリプト）: フル vibe で OK
- 中ステーク（社内ツール、MVP、捨てる前提のプロト）: vibe + 動作テスト + 簡易セキュリティスキャン
- 高ステーク（本番、顧客データ扱い、外部公開）: agentic engineering モード必須。vibe で書いても 人間レビュー＋自動セキュリティスキャン＋テスト追加 なしには push しない
② AI生成コードに対して必ずやる3つ
- 差分を見る: 一行も読まないのは捨てるコードまで。共有するコードは差分くらいは目で追う
- セキュリティリンタを通す:
semgrep/bandit/truffleHog等。secrets・SSRF・XSS の機械チェックは必須 - テストを書かせる: 同じAIに「これにテスト書いて」を必ず追加。テスト無しコードは vibe ですら成立しない
③ 「コードを読む」スキルを捨てない
vibe coding に慣れすぎると、いざ AI が間違ったとき・コードを引き継いだときに 読めなくなる。Karpathy 自身も「AI 生成コードの細部を理解する力は重要だ」と繰り返し強調している。vibe するときも、たまには立ち止まってコードを読む習慣が長期的な実力差になる。
④ シークレット管理を vibe しない
API キー・DB パスワード・本番アクセストークンは 絶対に AI に渡さない・コードに書かせない。.env + .gitignore + 環境変数の運用は vibe コードでも例外にしない。Escape.tech の調査で 400 件露出していたのはこの基本が崩れたケース。
8. 誰が・何を・どこまで vibe coding するか
| 属性 | vibe coding の使いどころ | 注意点 |
|---|---|---|
| 非エンジニア（PM、デザイナー、起業家） | プロト・社内ツール・自動化スクリプト | 本番の顧客データを扱うものは別途エンジニア招集 |
| 新人エンジニア（〜2年） | 学習用、個人プロジェクト、業務の補助 | vibe しすぎると基礎力がつかない。意識的に「コードを読む時間」を確保 |
| 中堅エンジニア | 定型タスクの高速化、ドキュメント生成、テスト追加 | 本番リファクタは agentic engineering 寄りに |
| シニアエンジニア | 仕様検討の壁打ち、複数案の高速プロト、レガシー読解 | vibe を「思考の加速装置」として使うのが旨味 |
| セキュリティ・SRE | 運用ツール、監視スクリプト、ダッシュボード | 本番に触れるものは Vibe & Verify を厳格に |
まとめ
- バイブコーディングは Karpathy が2025年2月に提唱した「コードを読まずに AI に任せる」コーディングスタイル
- Karpathy 自身は2026年に「agentic engineering」への改名を提案——本番では設計・制約・人間判断が必須
- 主要ツール: Claude Code / Cursor Composer / Codex CLI / Lovable / v0 / Bolt.new / Devin
- セキュリティの現実: AI コードの 40〜62% に脆弱性、SSRF は5社全てで検出、CVE は3ヶ月で6倍に
- Vibe & Verify: ステークで使い分け、差分は見る、セキュリティスキャン必須、テストは AI に書かせる、シークレットは絶対 vibe しない
- 「コードを読む力」を捨てるな——vibe する人ほど、たまに立ち止まって理解する習慣が長期的な実力差を生む
FAQ
Q1. バイブコーディングは Karpathy が改名したなら、もう使わない言葉なのか？
市場ではまだ広く使われている。「気軽にAIに任せる」というニュアンスを表す代替語が無いため。本記事では 「気軽な探索モード = vibe coding」「本番モード = agentic engineering」と整理して併用するのが現実的。
Q2. プログラミング初心者が vibe coding から始めるのはアリか？
アリだが 必ずコードも読む こと。vibe だけで進めると、AI が間違えたときに何も判断できなくなる。最初は「動くコードが手元にある」喜びをモチベーションにしつつ、徐々にコード理解の比率を上げていく学び方が現実的。
Q3. 仕事で vibe coding を使うとき、上司を説得する材料は？
3点セットで持っていく: (1) Vibe & Verify の運用ルール、(2) セキュリティスキャンと CI 統合、(3) コードレビューはこれまで通り厳格に。「速度を上げるが、ガードは緩めない」と明示できれば、ほとんどの組織で許可される。
Q4. Vibe coding と従来の「AI 補助コーディング」（Copilot 等）はどう違う？
主導権の所在が違う。Copilot は人間がコードを書きながら AI が補完する「ペアプロ」型。vibe coding は AI が主体で人間は会話と確認のみ。境界は曖昧で、現実には両方を行き来する開発者が多い。
Q5. どのツールから始めるのがいい？
個人開発・学習なら Lovable / Bolt.new / v0（ブラウザだけで完結）。本格的なソフト開発なら Claude Code / Cursor。Claude Code は CLI、Cursor は IDE 一体型なので、好みで選ぶ。Karpathy の好みは Cursor Composer。
Q6. AI に書かせたコードの著作権はどうなる？
2026年5月時点、米国・日本ともに 「AI のみが生成したコードは著作権で保護されない」が基本。ただし「人間が大幅に修正・選別したコード」は保護対象になり得る。商用利用で問題が起きやすいのは ライセンス汚染（AI が GPL 等のコードを再生成して混入）の方なので、ライセンスチェッカーを CI に入れておく。
Q7. Vibe coding は「エンジニアの仕事を奪う」のか？
「コードを書くだけのエンジニア」の単価は下がる方向。一方、仕様設計・アーキテクチャ判断・セキュリティ・本番運用のスキルは vibe coding の普及で逆に価値が上がっている。AI が書いた大量のコードを「読んで・判断して・直せる」人材は2026年時点で需給逼迫している。
