Vibe Coding（バイブコーディング）とは？Karpathyが提唱したAI時代の開発スタイルと2026年の進化を解説

Vibe Coding（バイブコーディング）とは

Vibe Coding（バイブコーディング）とは、人間が大まかに「やりたいこと」を自然言語で指示し、LLMがコードを生成・修正することで、開発者がコードそのものをほとんど書かずにアプリやプロトタイプを作るスタイルを指す。2025年2月、AI研究者のAndrej Karpathyが「There’s a new kind of coding I call ‘vibe coding’」とXに投稿したことで広まり、Collins English Dictionaryの2025年Word of the Yearにも選ばれた。

身近な例えで言えば、Vibe Codingは「翻訳家を介して建築家とやり取りする発注者」のようなものだ。発注者（人間）はやりたいことを伝え、翻訳家（LLM）が建築家の言葉（コード）に置き換えて成果物を作る。実務では、HackathonのMVP作成、社内ツールの素早い構築、UIの試作、業務スクリプトの自動生成といった用途で広がっている。

Vibe Codingの読み方

Vibe Codingの仕組み

Vibe Codingの中核にあるのは「LLMがコードを書き、人間がvibe（空気感・雰囲気）で承認する」というワークフローだ。Karpathyの2025年2月のX投稿では「Cursor Composer + Sonnetが上手すぎて、コードを忘れてしまえる」という体験が紹介された。彼は具体的にSuperWhisperで音声入力し、CursorにしゃべりかけながらUIをイテレートしていた。重要なポイントですが、この方式は「コードを読まずに採用する」ことを許容するスタイルで、伝統的なコードレビュー文化とは対照的です。

典型的なツールチェーン

2026年時点で代表的なツールはCursor、Windsurf、Claude Code、Replit Agent、Bolt.new、v0、Lovableなどで、自然言語の指示から実行可能なコードと環境を瞬時に生成する。Karpathyは2025年12月のステートメントで「自分のコードの80%は今やAIが書いている」と明言し、業界の急速な変化を象徴している。注意しておきたいのは、Karpathy自身は2026年に「vibe codingという呼び方は古くなった、これからはagentic engineering」と発言しており、用語そのものが進化を続けている点だ。

歴史的背景

Vibe Codingの源流は、2022〜2023年のChatGPTおよびGitHub Copilotの普及にある。当初は「コード補完」レベルだったAI支援が、2024年のCursor Composer、Aider、Devinの登場で「機能単位の生成」に進化し、2025年初頭にKarpathyの言葉で文化的アイデンティティが与えられた格好だ。覚えておきたいのは、Vibe Codingが単なる技術トレンドではなく、開発者の役割そのものの再定義として議論されている点で、企業の採用基準や教育カリキュラムにまで影響を及ぼしている。

Vibe Codingの使い方・実例

基本的な使い方（Quick Start）

Cursorを例にすると、Vibe Codingの最小フローは次のとおり。

# 1. プロジェクトを開く
$ cursor my-app

# 2. Composerに自然言語で依頼（Cmd+I）
"テキスト入力欄とボタンを追加して、ボタンを押したら入力をトーストで表示するUIを作って"

# 3. 提案された差分を確認 → Accept
# 4. プレビューで動作確認
# 5. 違うところがあれば「ボタンの色を青に」と続ける

よくある実装パターン

パターンA: プロトタイピング（捨てるコード）

"3秒で次のページに切り替わるカルーセルを作って"
→ 一瞬でモックが完成
→ Yes/No判断 → Yesなら次のフェーズへ

向いているケース: ハッカソン、社内デモ、UIアイデア検証。コードは捨てる前提なので品質より速度が優先される場面。

避けるべきケース: 本番に乗せるコード。コードを読まずに採用する習慣が品質低下を招く。

パターンB: ペアプログラミング型

"認証フローをClerkに置き換えて。既存のテストは保持して"
→ AIが差分提示
→ 人間がレビュー → 修正点を再依頼
→ テストがpassすればコミット

向いているケース: 既存コードベースに対する小〜中規模の改修。AIにドラフトを書かせ、人間が品質保証する。

避けるべきケース: セキュリティに関わるコードや独自ドメインの深い知識を要する箇所。

パターンC: 仕様駆動（Spec-Driven）

1. 仕様書を Markdown で書く
2. "このSpecに沿ってFastAPIで実装して" と依頼
3. AIが実装＋テストを生成
4. 人間はSpecを更新するだけ → AIが追従

向いているケース: APIエンドポイントのCRUD実装、定型業務スクリプト。仕様が明確に書ける作業。

避けるべきケース: 仕様自体が曖昧で、書きながら考える必要がある作業。

アンチパターン: 全量Vibe Coding

# やってはいけない例
- 本番DB操作スクリプトをコードレビューせず採用
- 認証・認可ロジックをAI出力そのまま運用
- セキュリティ監査なしに外部公開

Vibe Codingは「捨てる前提のコード」に向く反面、本番品質を担保したいコードでは必ず人間によるレビューと自動テストを組み合わせる必要がある。注意しておきたいのは、AI生成コードには「もっともらしいけれど実在しない関数の呼び出し」が混入しやすく、コードレビューを省略するとそれを本番に投入してしまう事故が起きうる点だ。

Vibe Codingのメリット・デメリット

メリット

• 圧倒的なスピード: 1時間で動くプロトタイプができる。アイデア検証のサイクルが激短になる
• 非エンジニアの参入: コードが書けなくてもプログラム的な仕事に参加できる
• 言語横断: TypeScript/Python/Goなど複数言語をストレスなく行き来できる
• 退屈な定型作業の削減: API叩き、スキーマ変更、ボイラープレートをAIに任せられる
• 学習効果: AIの出力からベストプラクティスや慣習を学べる

デメリット

• コード品質の劣化: 動くけれど読めない、テストがない、保守性が低いコードが量産されやすい
• セキュリティリスク: ライブラリ選定や認証ロジックでの間違いが見過ごされやすい
• ハルシネーション: 存在しないAPIや誤った設定がもっともらしく書かれる
• スキル空洞化: 自分でコードを書く機会が減り、根本理解が浅くなる懸念
• コスト: AI APIのトークン課金が積み重なると馬鹿にできない

Vibe Codingと従来コーディング・Agentic Engineeringの違い

2026年時点では「Vibe Coding／伝統的コーディング／Agentic Engineering」の3つが混在している。Karpathy自身がVibe Codingを「素人っぽい使い方」、Agentic Engineeringを「プロの使い方」と位置づける発言をしているため、整理しておきたい。

つまり、Vibe Codingは「コードを忘れて雰囲気で開発するライトな使い方」、Agentic Engineeringは「AIに大半を書かせつつ厳格な監督と検証で品質を保つプロの使い方」と整理できる。Karpathyは「2026年の本番開発はAgentic Engineeringが主流になる」と予測している。

Vibe Codingに関するよくある誤解

誤解1: 「Vibe Codingならエンジニアは不要になる」

なぜそう誤解されるのか: 「コードを書かずにアプリが作れる」というメッセージから「プログラミング職そのものが消える」と早合点する人が多い。SNSでバズったAI生成アプリのデモが影響しており、職業観への不安と結びつきやすい背景がある。

正しい理解: Karpathyを含む業界の主要な声は「設計・統合・運用・セキュリティの判断は人間に残る」と一致している。Vibe Codingが代替するのは「タイピング」と「定型コードの記述」であって、「アーキテクチャ判断」「ビジネス要件の翻訳」「責任の所在」までは肩代わりできない。むしろ高水準の設計力を持つエンジニアの価値は上がるという観測が一般的だ。

誤解2: 「Vibe Coding＝コードを一切読まない」

なぜそう誤解されるのか: Karpathyが「コードを忘れる」と表現したインパクトが強く、字面通り「読まない」が基本動作だと受け取られやすい。実際には彼自身、後の発言で「ある程度のレビューは必要」と補足しているが、初期の表現が独り歩きしている背景がある。

正しい理解: 実際の現場では「ざっと差分は確認するが、全部の文法は追わない」という中間解が大半だ。「読まない」のは流暢な英文を一字一句チェックしないのと同じ感覚で、危なそうな箇所だけ拾い読みする運用が主流。本番品質を狙う場合はもっと丁寧にレビューする必要がある。

誤解3: 「Vibe Codingは初心者向け、プロは使わない」

なぜそう誤解されるのか: 「コードを書けない人がコードを作る方法」というニュアンスが強調されたため、上級者には不要と見なされやすい。実際にはKarpathyやSimon Willisonら著名エンジニアもVibe Coding風のワークフローを多用しており、上級者ほど効果的に使いこなしている背景がある。

正しい理解: Vibe Codingの効果はむしろ熟練エンジニアほど大きい。なぜなら、AIの誤りを瞬時に見抜き、適切なプロンプト軌道修正ができるからだ。逆に初心者は誤りに気づけずバグを温存しがちで、習得コストが意外と高い。「初心者でも始められる」と「初心者向け」は意味が違う。

Vibe Codingの実務での活用シーン

• 社内ツール開発: 申請フォーム、ダッシュボード、簡易CRUDアプリなど
• UI/UXプロトタイピング: ユーザーテスト用モックの即席生成
• データ分析スクリプト: pandas/Polarsを使ったアドホック分析
• マイグレーション支援: 古いコードベースから新フレームワークへの自動書き換え
• 非エンジニアの自動化: マーケターやアナリストが業務スクリプトを直接生成
• 教育・学習: 「これがどう動くか試したい」を即座にコード化して理解する

Vibe Codingに関するよくある質問（FAQ）

まとめ

• Vibe Codingは2025年2月にAndrej Karpathyが命名した、自然言語でAIに「だいたいの雰囲気」を伝えてコードを作ってもらう開発スタイル
• Cursor、Windsurf、Claude Code、Replit Agent、Bolt、v0などのAIネイティブIDEで実践される
• 2026年現在、米国では92%の開発者がVibe Coding的手法を採用しているとの調査結果もある
• プロトタイプ・社内ツール・データ分析で威力を発揮するが、本番品質には人間レビュー＋テストが必須
• Karpathy自身が2026年に「Vibe Codingは古い、これからはAgentic Engineering」と発言、概念は進化中
• Collins English Dictionaryの2025年Word of the Yearに選ばれた、文化的な広がりを持つ用語

参考文献・出典