バイブコーディングとは、大規模言語モデルを使って、それが生成するコードをレビューせずにソフトウェアを作るプラクティスである。2025 年 2 月初めにこの用語を作った Andrej Karpathy は、それを、完全にバイブ（ノリ）に身を任せ、コードが存在することすら忘れることだと説明した。すなわち、すべての diff を読まずに受け入れ、エラーメッセージをコメントも付けずにそのまま貼り戻し、モデルがバグを直せない場合は、それを回避するか、バグが消えるまで適当な変更を頼み続ける、というものである。Simon Willison は AI 支援型プログラミングのすべてがバイブコーディングではない（でもバイブコーディングは素晴らしい） の中で、この用語を、ソフトウェアを作っている人がコードをレビューするかどうかという、ただ一つの運用上の判定基準に還元している。そのうえで彼は、この用語がすでにあらゆる形の AI 支援型プログラミング を覆うまでに引き伸ばされつつあり、それが用語を薄めると同時に、責任ある AI 支援の作業がどのようなものかを誤って伝えていると論じている。
用法
この用語は、ソフトウェアがどのように作られるかにおける境界を示すものであり、特定のツールやワークフローを指すものではない。同じモデルとエディタをどちらのやり方にも使うことができ、このラベルを決めるのは、生成されたコードが頼りにされる前に読まれ、理解されているかどうかである。Willison の説明では、LLM が書いたコードであっても、その後レビューされ、テストされ、他人に説明できるほど十分に理解されたものは通常のソフトウェア開発であり、LLM がそれを生成したという事実は重要ではない。
Willison はこの狭い解釈を、用語への批判ではなく用語の擁護として提示している。彼は、バイブコーディングが本来なら高いプログラミングの初期障壁を下げ、コンピュータサイエンスの学位もブートキャンプもなしに、人々が面倒な作業のためのカスタムツールを作れるようにし、そのうちの何人かはやがて熟練した開発者になるだろうと論じる。また、経験豊富な開発者にとっても、LLM に何ができて何ができないかについての直観を養うための最良の手段として有用だと述べ、自身がこの方法で作った実験を 80 件以上公開してきたと報告している。この数字とその評価は、彼自身の実践についての彼自身の説明である。
この用語が広まってから数週間のうちに、狭い解釈は目に見えて劣勢になっていた。2025 年 3 月下旬には、Willison は自分がこの戦いに負けつつあると述べ、LLM を使ってコードを書くあらゆる場面を指してこの用語が使われるのを目にし続けていると語り、この用語に起きていることを 意味の拡散（Semantic Diffusion） と名付けた。これは、作られた言葉が考案者たちの外へ広まるにつれてその定義が弱まっていくことを指す、彼が知ったばかりの用語である。彼の原因診断は、人々が Karpathy の元の投稿を最後まで読むとは期待できず、使い捨てのプロジェクトへの限定はその最後の部分に書かれている、というものだった。その記事に返信した Karpathy は、定義が定まるまでにはしばらく時間がかかるだろうと書いた。彼は「vibe coding」という言葉を、「自分が何をしているのかさっぱりわからない」という画像の犬のような気分になるときに使っていると述べ、前夜に作った iOS アプリを例に挙げたが、実際には完全なバイブコーディングに振り切ることはめったになく、むしろ多くの場合、今でもコードを見て、複雑さを少しずつ加え、各部分がどう動くのかを時間をかけて学ぼうとし、確認のための質問をしているとも述べた。
2026 年になっても Willison は狭い解釈を保ち続けており、それを議論としてではなく、確立した語彙として述べるようになっていた。2026 年 2 月に自身のガイド エージェント型エンジニアリングのパターン を紹介する際、彼はバイブコーディングを元の定義に従って、コードにまったく注意を払わないコーディングと注釈し、誰がそれを行っているかについての観察を付け加えている。すなわち、この用語は今日では、LLM を使ってコードを書く非プログラマーと結び付けられることが多いという。ガイドの最初の章は、狭い解釈が果たす目的を改めて述べている。つまり、レビューされていないプロトタイプ品質の LLM 生成コードを、作者が本番投入可能な水準にまで引き上げたコードと区別するために、それを指す用語が必要だということである。そして、この用語を LLM 支援によるあらゆるコード生成にまで広げるのは誤りだと繰り返している。また、この用語の誕生時期をツールの歴史と照らし合わせ、Claude Code の最初のリリースのおよそ 3 週間前に登場したことにも触れている。
2026 年に変わったのは定義ではなく、著者自身がその定義にどれだけ従っているかについての報告だった。バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている で彼は、自分の仕事の中でこの 2 つのカテゴリーの境界が曖昧になっていると述べている。コーディングエージェントの信頼性が高まるにつれて、彼は本番レベルの作業も含め、エージェントが書くすべての行をレビューすることをやめた。これは彼自身の運用上の判定基準に照らせば、その作業を、他人が使うソフトウェアにとって無責任だと彼が位置付けていた側へと近づけるものである。それでもなお擁護できる理由として彼が挙げるのは、他チームのサービスに依存することとの類推である。つまり、ドキュメントを読み、それを使い、誤動作したときにだけ実装を調べる、というものだ。そして彼はこの類推の限界を自ら述べている。チームは説明責任と職業上の評判を負っているが、コーディングエージェントはそのどちらも負っていない。彼はこの逸脱に潜むリスクを「逸脱の常態化」の一要素と呼び、監視されずに正しい結果が出るたびに、後に誤った信頼を寄せる可能性が高まるとしている。
2026 年のある実務家の説明は、狭い解釈を保ちつつ、それを別の用途に使っている。そもそも何を AI に任せるかを決めるためである。Andrew Connell はバイブコーディングを、AI と自然言語で会話し、生成されたコードをレビューせずにアプリケーションを AI に作らせる開発アプローチと定義し、この用語を 2025 年 2 月の Andrej Karpathy のツイートに帰している。エージェント型エンジニアリング との違いについての彼の要約は、所有権に関するものである。バイブコーディングはコードの所有権を AI に委ねるが、エージェント型エンジニアリングは開発者のエンジニアリング上の判断に主導権を持たせ続ける。
この説明が珍しいのは、バイブコーディングが何に向いているかについて述べている点である。Connell は、それが低リスクのタスク（彼の例はフォームでのデータ収集と、受信したサポートチケットの処理である）や、ヒューマン・イン・ザ・ループなしに自律的な行動を取らないもの、セキュリティが重大な懸念ではないもの、そして誰も長期にわたって結果を保守する必要がないものにはうまく機能すると考えている。そのうえで彼は、リスクにまったく依存しない、2 つ目の肯定的な論拠を示す。バイブコーディングは、まさにエンジニアではない人々にとって価値がある、というものである。プロダクトマネージャー、マーケター、その他のステークホルダーが要求仕様書を持ってくる代わりにプロトタイプを自然言語で表現できるようになり、チームが本番コードを一行も書く前に、顧客と一緒にプロトタイプを「vibe up（ノリで作り上げる）」して認識を揃えられるようになるという。
さらに 2 つの説明は、この用語を、守るべきカテゴリーとしてではなく、移行の出発点として用いている。どちらも、作業を制御・検証できるかどうかに独自の境界を引いており、これは狭い解釈のコードレビューという判定基準と重なりはするが、同じものではない。
Jimmy Song のオンラインハンドブック 智能体构建指南 のある章は、バイブコーディングをプログラミングパラダイムの変遷における一段階として扱っている。すなわち、IDE 時代のツール支援開発、AI プログラミング時代の協働的な創作、そして人間と AI が 1 つのコンテキストと 1 つの意味空間を共有するバイブコーディング時代の流動的な共創である。その主張は、この段階はチームの規模では不安定だというもので、3 つの問題を挙げている。AI が業務上の境界を忘れてしまうコンテキストのドリフト、コードの品質とセキュリティに大きなばらつきが出る制御不能な結果、そして人間・AI・ツールの間の協働に標準がないことである。したがってその問いは、「バイブ」にエンジニアリング上の制約を与えられるかどうかであり、その答えは 仕様駆動開発 である。つまり、雰囲気を構造へと変え、協働を制御可能かつ検証可能なものにすることである。この説明は、変わるのはコードの書き方だけではなく開発パラダイム全体であるという点を、珍しいほど明確に述べている。
韓国のある実務家の説明は、経験から同じ境界にたどり着いている。本当に「ポチッ」で全部できるのか？ — 保守的な開発者が AI エージェントでプロダクトをリリースして気づいたこと は、実際のプロダクトでエージェントと作業することは、バイブというより戦いに近く感じられたと報告している。著者は、やらないように言ったことをなぜやっているのかと繰り返しエージェントに問いただしたことを振り返り、ツールが価値をもたらすのはその出力を制御・検証できるようになってからであるため、現実はバイブではなくエンジニアリングの領域だと結論付けている。その説明はこの理由から自らの実践を エージェント型エンジニアリング の下に位置付け、この 2 つの用語をいずれも Karpathy に帰して、1 つ目は 2025 年 2 月初め、2 つ目は 2026 年 2 月初めと、1 年の間隔があるとしている。
適用される場面
Willison は、バイブコーディングが許容できると考える条件を、ソフトウェア作りの初心者に明示的に向けて示している。
- 低い利害。 コードにバグやセキュリティ脆弱性があった場合にどれほどの害（評判の毀損、金銭の損失、あるいはそれ以上）を引き起こしうるかを見積もること。他の人がそれを使う場合は特に注意すること。
- シークレット。 パスワードや API キーのようなものはすべて意図的に扱わなければならず、それはつまりコードを読まずに済ませるのではなく、コードがどう動くのかを理解することを意味する。
- データのプライバシー。 非公開データにアクセスできるツールには慎重に取り組み、そのデータがマシンの外に出ていく経路があるかどうかを確実に把握すること。
- 他のサービスへの負荷。 他のプラットフォームにリクエストを送るコードは、そのプラットフォームの負荷とコストを増やしうるので、良きネットワーク市民であることも判断の一部である。
- 従量課金の支出。 Willison は、請求上限のない API に対してバイブコーディングを行い、数千ドルの料金を発生させた人々の事例を挙げている。
これらの条件のうち 2 つは、このプラクティス自身の前提と相反する。シークレットの扱いやデータの外部流出を判断するには、バイブコーディングが読まずに残すコードを理解する必要があるため、この手法が最も安全なのはそのどちらも関係しない場面である。他人が使うかもしれないものについての Willison 自身の緩和策は技術的なものではなく社会的なもの（共有する前に、より経験のある人に確認すること）であり、彼が提案する設計の方向性は、Claude Artifacts のように、読まれていないコードが到達できる範囲を制限するサンドボックスである。彼は、Cursor のように、当初はプロの開発者向けに作られたツールには、そうした安全柵がはるかに少ないと指摘している。
ここで示した定義は、Karpathy による造語を踏まえた一人の実務家の論証された立場に基づいている。その投稿自体が、この用語が他所でより緩く使われていることへの反応であるため、狭い解釈を確立した普遍的な用法と受け取るべきではない。
2025 年のある学術レビュー バイブコーディング対エージェント型コーディング：エージェント型 AI の基礎と実践的な含意 は、Willison が劣勢に立たされていると述べる広い用法を例示している。このレビューもこの用語の造語を Karpathy に帰しているが、バイブコーディングそのものを、開発者が生成された各部分をレビューし洗練させる能動的な共同制作者であり続ける、人間中心のモデルとして定義している。これは Karpathy の元の「コードが存在することすら忘れる」よりも、通常のレビューされた AI 支援型プログラミング に近い説明である。この論文はバイブコーディングを、自律的なエージェントが人間の監督を減らした状態で複数ステップのタスクを計画・実行する エージェント型コーディング と対比している。
別の 2025 年のサーベイ 大規模言語モデルによるバイブコーディングのサーベイ は、広い解釈の陣営の内側から同じドリフトを明示的に指摘している。このサーベイはバイブコーディング全体を、実装を「一行ずつのコード理解ではなく、結果の観察を通じて」検証することと定義しているが、バイブコーディングの実践についての独自の 5 モデルの分類（バイブコーディングの開発モデル）のうち、AI の出力をレビューせずに信頼する Unconstrained Automation Model の 1 つだけを「Vibe Coding の元の定義に最も沿った開発アプローチ」としている。残る 4 つの名前付きモデルのうち 3 つ、すなわち Iterative Conversational Collaboration、Planning-Driven、Test-Driven は、Karpathy の元の造語が除外していた、何らかの形の人間によるレビュー、事前の計画、あるいはテストに基づく検証を伴う。5 つ目の Context-Enhanced は、それ自体はレビューや計画のプラクティスではない。サーベイはそれを、他の 4 つのモデル（Unconstrained Automation Model 自体も含む）のいずれにも重ねられる、直交する技術的なコンテキスト管理能力（検索、コードベースのインデックス化）として説明している。
Connell の条件はリスクの点で Willison の条件と重なるが、AI が考慮してくれるとは当てにできない事柄について、彼独自の 2 つを付け加えている。1 つ目はコストである。彼は、これらのツールは指示されない限り運用上の制約を最適化せずに動くコードを書くと論じ、その例として、Microsoft Graph のデータをバッチ処理せずにユーザーごとのループで取得するコードを挙げている。これは本番デプロイから数時間以内にスロットリングの上限を超えたり、従量制のクォータを 1 週間で使い切ったりしうる。2 つ目を彼は「できるからといって（just because you can）」問題と呼ぶ。AI アシスタントは、技術的には動作するがプラットフォームベンダーがサポートしていない解決策を提案することがある。彼の例は、モダンな SharePoint ページの DOM を並べ替える SharePoint Framework のアプリケーションカスタマイザーであり、彼によれば Microsoft はこれを明示的にサポートしておらず、テナント全体のサポートを知らぬ間に無効にしてしまいかねない。彼の説明では、どちらも実務のエンジニアなら下す判断であり、バイブコーディングには下せないものである。
彼が挙げる保守性への異論も同じ形をしている。ある解決策が広く展開されると、それを変更したり修正したりするために誰かがそれを理解しなければならない。彼は、後でコードベースの分析を頼まれた LLM には、作成時の元のコンテキスト、つまりコードに完全には反映されていないものが欠けていると論じ、少なくとも現時点では、モデルはある規模を超えたアプリケーションをコンテキストウィンドウに保持できないと付け加えている。彼の結論は狭い解釈の最も平明な形である。コードを理解していなければ、それをデバッグすることも、拡張することも、チームに説明することもできない。
Red Hat Developer に掲載されたある実務家の記事 バイブコーディングについての不都合な真実 は、この用語を広い意味、すなわちすべての行を書く代わりに AI と会話してソフトウェアを作るという意味で使い、コードが読まれるかどうかではなく、プロジェクトの寿命とテスト可能性によって境界を引いている。著者は、プロトタイプや自己完結したプロジェクトでは速さは本物だと報告する一方で、バイブコーディングで作られたプロジェクトは 3 か月ほど経った頃に、1 つの小さな変更が他のいくつもの機能を壊すという壁によく突き当たると述べ、その原因を仕様なしで作ることに帰している。コードが生成された時点でプロンプトは役目を終えるため、コードだけがソフトウェアが何をするのかの唯一の記録となり、なぜそうするのかの記録は残らない。この記事の処方箋は、保守しなければならないものについては 仕様駆動開発 に移行しつつ、バイブコーディングはユニット単位にとどめることである。ユニットテストや機能テストで出力を検証できるなら、その範囲はバイブでやってよいほど小さく、そうでなければ仕様が必要である。Connell と同様に、この記事も開発者はやはり技術に通じていなければならないと主張する。アーキテクチャ、依存関係、トレードオフを理解せずに書かれた仕様は、ただの希望リストにすぎないからである。これらは一人の実務家が自身のプロジェクトから得た観察であり、測定された知見ではない。
関連用語
- エージェント型エンジニアリング — ある情報源がこの用語と対比する、規律ある対となる概念
- AI 支援型プログラミング — この用語がその部分集合である、より広いプラクティス
- 意味の拡散（Semantic Diffusion） — この用語自体の受け止められ方がその一例として挙げられている現象
- エージェント型コーディング — 2025 年のある学術的分類がバイブコーディングと対比するパラダイム
- バイブコーディングの開発モデル — この用語の下で公開された実践の 5 モデルの分類で、情報源が元の造語と結び付けているのはそのうち 1 つだけである
- コードの前にコンテキストを：実践におけるバイブコーディングの経験報告 — バイブコーディングは足場作りには信頼できるが、明示的にプロンプトで指示しない限りテナント分離や非同期処理のようなアーキテクチャ上の特性には信頼できないとした経験報告で、そのギャップに対して 委任不可領域 を提案している
- バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている — 同じ著者が、境界の規律ある側からその侵食を報告したもの
- 仕様駆動開発 — バイブコーディングで作られたプロジェクトを保守する必要が生じた時点で、ある実務家の記事が処方するプラクティス
- 検証負債 — 狭い定義が拠り所とするレビューの工程が省略されたときに蓄積するもの