すべてを「バイブ・コーディング」と呼ぶのはやめるべきです

長いブランクの後にコーディングに戻り、再び手を付けたのは Lovable だった。アプリは見た目も素晴らしく、見た目どおりに動き、数時間で完成した。当初はそれが驚くべきことに思えた。しかし、コードが何をしているのか、なぜそうなのかを知りたくなった瞬間に、満足できなくなった。そこから私のアプローチは変わり始めた。

違いはツールや、AI がどれだけコードを書いてくれるかではありません. それは、出力に対して受け入れる契約—つまり、世にリリースしたものを説明できるかどうか—に関することです

バイブ・コーディングとは、本来、AI が生成したソフトウェアを、下にある仕組みを適切に検証・理解せずに受け入れることを指す。AI 補助開発はこれとは異なる。モデルが大部分のコードを書いたとしても、システムを構築する人間はその挙動を理解し、前提条件をテストし、出荷可能かどうかを判断する責任を負う。

自分のマシン上だけで完結する使い捨ての実験であれば、この区別はほとんど影響がないかもしれない。しかし、ソフトウェアがデプロイされ、他者に使用され、実データと接続されると、その重要性は計り知れない。

「バイブ・コーディング」の意味が失われた経緯

「vibe coding」という用語は、2025年2月に Andrej Karpathy が作り出した。彼の例は意図的にカジュアル: “Accept All” を自動的にクリックし、差分を無視してコードが自分の理解を超えて増えていく“使い捨ての週末プロジェクト”だった。

数週間後、開発者でツール制作者の Simon Willison は、この用語が全く異なる意味で使われていることに気付いた: AI 補助プログラミング全般の代名詞として、それが用語を希薄にし、責任ある AI 補助開発が達成できることに対する誤った印象を与えると主張した。

興味深いのは、Karpathy が最終的に同意した点だ。1 年後、彼はコーディングエージェントを用いたより規律ある作業のために別の用語を導入した。彼は「agentic engineering」を、開発者が生成物を単に受け入れるのではなく、エージェントを指示・監督するワークフローと説明した。この区別は重要で、プロの AI 補助開発は、カジュアルなバイブ・コーディングにはない計画、精査、責任を必要とする。

境界は責任である

Willison のルールはシンプルで、誰にでも試せるテストとして機能する: 他人に説明できないコードはコミットしないことだ。これは、すべての行を読むことを意味するわけではない: エージェントが一度に数百行生成しても、経験豊富な開発者はもはや全行を読むことはしない。重要なのは、コアロジックを理解し、コードがなぜそのように動くのかを正当化できることだ。もしできるなら、モデルが書いたか自分が書いたかは関係ない: それはバイブ・コーディングではなく、ツールを使ってソフトウェアを構築しているに過ぎない。

2025年12月に公表された研究はこの区別を裏付けている。現場観察とプロの開発者を対象とした定性的調査に基づき、経験豊富な実務者はソフトウェアの設計・実装に対するコントロールを保持し、プロセス全体を AI に委ねていないことが分かった。彼らはエージェントを協働者として扱い、作業を慎重に計画し、監督に関わり続けていた。

したがって、経験だけでは説明できない。重要なのは、AI が生成したものに対して責任を取る意思があるかどうかだ。これは、すべての開発者がプロジェクトごとに何度も下す決断である。

コントロールが欠如したときに起こること

ソフトウェアをリリースする際に、そのセキュリティを理解・検証せずに行う結果は抽象的なものではない。デート中の女性の安全を支援することを目的としたアプリ「Tea」は、数万枚の身分証明書写真と 100 万件以上のプライベートメッセージを 2 件のセキュリティインシデントで漏洩させた。失敗の要因は、保護されていないストレージバケットと、認証なしでアクセス可能な別のデータベースであった。

同様の根本的問題—ソフトウェアは動作しているように見えても、認可ロジックが危険なほど誤っていた—が、Lovable プラットフォーム上で構築されたアプリでも顕在化したセキュリティ調査により、認可ロジックが逆転していることが判明した。これにより、ログインユーザーはロックアウトされ、認証されていない攻撃者が自由に侵入でき、18,000 人以上（学生を含む）のユーザーが影響を受けた。

これらは「悪い」プロジェクトだけに起こる個別事例ではない。Google の 2025 年 DORA レポートによると、開発者の 90% が職場で AI を使用しており、約 3 分の 1 が生成物に対してほとんど信頼していないと報告している。

AI の利用は現在広く浸透しているが、信頼は依然として限定的である。そのため、生成されたコードが認証や権限、機密データを扱う場合、慎重なレビューが特に重要になる。

コントロールは層状に構築され、一度にすべてではない

私の場合、最初から正式なセキュリティ監査を行ったわけではない。何かが期待通りに動かない理由を説明できない限り、先に進むことを拒んできた—分析者としての自然な本能だ。構文そのものよりも、結果が当初の要件に合致しているかを重視する。合致しなければ、掘り下げ続ける。

プロジェクトが本格化するにつれ、私のワークフローはより体系的になった。単にプロンプトに頼るだけでなく、何かを生成する前に仕様書を作成し始めた。ビジネス要件、技術スタック、統合点を文書化した。その後、主要なユーザージャーニーに対するユニットテストと Playwright テストを実施した。

セキュリティチェックも同様に追加した。AI が選択したライブラリをレビューし、アップロードファイルに対するマルウェアスキャンを導入した。各チェックは、事前に用意したコントロールリストに従うのではなく、次に何が問題になるかを自問することから生まれた。

その習慣が、あるプロジェクトで問題を捕らえた。AI が導入したライブラリが、私が使用しているフレームワークのバージョンと互換性がなかったのだ。アプリケーションは直ちにクラッシュしなかったため、互換性の問題は簡単に見過ごされていた可能性がある。後で発見した場合、原因の特定ははるかに困難になっていただろう。

Tea と Lovable のケースと比較すると、これは普通の問題だった。早期に発見し、修正し、次に進んだ。これが実務でのレビューの典型的な姿である。多くの場合、小さな問題が大きくなるのを防いでいる。

AI が生成したからといってコードを不信するわけではない。また、アプリが動作するからといって信頼するわけでもない。テストとレビューによって、意図した通りに動作しているかを確認している。

バイブ・コーディングからエージェント工学へ

Karpathy が「バイブ・コーディング」から「エージェント工学」へと移行したのは、単なる語彙の変更ではない。「エージェント工学」は、プロフェッショナルな開発が向かう方向性を示す、より有用な名称だ。開発者が自ら書くコード行数は減っても、責任が軽減されるわけではない。むしろ、システムがすべきことを指定し、エージェントを指示し、出力をテストし、リリースの安全性を判断する作業へとシフトする。

危険なのは AI がコードを素早く生成することではない。生成が理解よりも速く進むことだ. そうなると、見かけ上の生産性がリスクを隠蔽してしまい、誰も適切に検証していない。

守る価値のあるルール

「バイブ・コーディング」を AI 補助開発のすべての形態のラベルとして使うのはやめよう—それは用語を希薄にし、重要なコントロールの区別を消してしまう。シンプルなルールを設定しよう：説明できないものは出荷しない。そして、プロジェクトが成長するにつれ、層ごとにコントロールを組み込み、リスクに応じてチェックを追加していく。

AI がコードの大半を書いたとしても、出荷に対する責任は取れない。その責任は依然として我々にある。