Vibe Codingはあなたを目的地へ速く届けてくれる——でも、目的地は選んでくれない

2025年初頭、 Andrej Karpathy Definition OpenAIの共同創業者の一人 がXにこんな投稿をしました。大意はこうです：コードを書かずにAIと会話するだけで、自分が欲しいものを説明し、生成されたものをそのまま受け入れる——そういう新しいやり方でソフトウェア開発をしている、と。彼はそのやり方を Vibe Coding と名付けました。 この言葉はその後、あっという間に広まりました。

Vibe Codingが指しているのは、自然言語を主なインプットとして、AIにコードを生成させる開発スタイルです。文法を知る必要も、開発環境のデバッグをする必要もありません。何が欲しいかを説明できれば十分です。アイデアから動くものになるまで、数時間で済むこともあります。

多くの人にとって、この魅力は明快です。以前は開発チームと数週間かけて検証していたアイデアが、一人で一週間末あれば試せるようになった。 私もすぐ試してみました。自分用の家計簿アプリを作ったんです——AIが明細を自動インポートして、カテゴリ分類して、月次レポートを出してくれるやつ。アイデアから使えるものになるまで、だいたい一週間末でした。 で、作ってから2週間ほど使って、やめました。 アプリに問題があったわけではありません。あることに気づいたからです……

変わった層

Karpathyは2023年にこう言っていました：英語は今、最もホットなプログラミング言語だ¹。LLMの能力が、人間が特定の構文を学ばなくてもコンピュータにタスクを実行させられるレベルに達した、という意味です——何が欲しいかを説明するだけでいい。

Vibe Codingはその論理の延長線にあります。本質的には、ある言語を別の言語へ、ある形式の情報を別の形式に変換する能力です。

最も基本的なレイヤーは、自然言語からコードへの変換。一段上になると、曖昧な説明をインタラクティブなUIに変換すること。さらにその上は、ドメインエキスパートの頭の中にあるロジックを、他の人が直接見て操作できる形にすること。

この3番目のレイヤーが、現時点でまだ過小評価されていると思っています。

具体例を挙げます。私はAIプロダクトを作っている人間として、技術的な背景のない人に「このAIソリューションは何なのか」「なぜそう設計したのか」「何の問題を解くのか」を説明しなければならない場面が多くあります。言葉だけの説明は、こういうコミュニケーションでは効果がかなり限られます——相手には参照系がないので、同じ言葉を聞いていても、頭の中で活性化する概念が違うんです。

以前はこれを解決するために、デモ用のプロトタイプを作って、開発サイクルを待っていました。今は、ビジネスロジックを理解している人が、数時間で「クリックして感触を確かめられるもの」を作り出せます。その「可視性」こそが、Vibe Codingが本当に圧縮しているコストです——開発コストではなく、「自分が言っていることを相手に理解してもらう」コミュニケーションコスト。

Karpathy自身も2026年初頭に自分の言葉を更新しています。今は「agentic engineering」という言葉でこの専門的な形態を表現していて、特に”engineering”という言葉を強調しています——つまり、ただ気ままにいじることではなく、判断力と専門性を必要とする仕事の仕方だということです²。この変化は、大事なことを示していると思います：ツールが強くなっても、ツールを使う側への要求は下がっていない。

変わっていない層

私が作った家計簿アプリで犯したミスは、典型的なものでした：「技術的に作れる」と「自分にこれが必要だ」を混同していたんです。

これはツールが高度かどうかとは関係ありません。起きた理由は、着手する前に自分に真剣に問いかけていなかったことにあります。本当に解きたい問題は何か？銀行の明細では不十分なのか？もし十分なら、追加で欲しいと思っていた機能は、本当に機能として必要なのか、それとも「あったら見栄えがいい気がする」という感覚に過ぎないのか。

個人プロジェクトでこのミスをした場合、代償は一週間末を無駄にした程度です。しかし組織レベルでは、構造は同じで、代償ははるかに大きくなります。

実際に見たことがあります。あるチームがかなりのリソースを投入して、ユーザー行動を分析するシステムを構築しました。データは綺麗に出て、レポートも整っていた。でも振り返りのミーティングで、ある人がこんな質問をしました：このユーザー層は、実際のビジネスで何パーセントを占めているんですか？答えは「ごくわずかで、しかもコアな成長ドライバーではない」でした。

そのシステムは、技術的には何も問題がありませんでした。要件の観点から見ると、それは存在しない問題に答えていたんです。

Vibe Codingのスピードは、そういう状況では、ただ速く間違った場所へ連れて行くだけです。

技術的負債は現実だが、最大のリスクではない

Vibe Codingによる技術的負債については、すでに多くの議論があります。2025年9月、Fast Companyがエンジニアたちの苦境を報じました——AI生成のコードベースを引き継いだはいいが、メンテナンスも拡張もままならない。生成プロセスに人間の理解とレビューが介在していないからです³。セキュリティも同様です。Veracodeの調査によると、AI生成コードの機能性はここ数年で大幅に向上しましたが、セキュリティの改善はそれに大きく遅れています⁴。

これらの問題は現実のものであり、真剣に向き合うべきです。でも私の見方では、これらは第二層の問題です。

第一層の問題はこうです：あなたは正しいことをしていますか？

技術的負債は「正しいことをしたが、やり方に問題があった」状態です。要件のズレは「間違ったことを、速くやった」状態です。前者は修正できますが、後者は最初からやり直しです。

Vibe Codingは実行コストを下げました。でも同時に、「着手する前にしっかり考える」プレッシャーも下げてしまっています。以前は開発コストが高かったので、動き始める前に要件を整理することを否応なく強いられていました——行き来のコストが大きかったから。今そのプレッシャーは小さくなりました。だからこそ、かつて「高さ」が強制していたことを、意識的にやる必要があります。

本当に希少になるもの

ツールの参入障壁が下がると起きることは、「より多くの人が物事を作れるようになる」だけではありません。「本来作るべきでなかったものが、どんどん作られる」ことでもあります。

では、この文脈で何が重要になるのでしょうか。

私の観察は一つです：ビジネスロジックと技術実装の間を行き来して翻訳できる人は、以前より希少になっています——希少でなくなるのではなく。

こういう人には、いくつかのことを同時に理解する能力が求められます。ビジネス上の本当の問題は何か。技術的に何が実現可能で、何にコストがかかるか。そして、その2つを相手に翻訳する方法——相手がビジネス言語しか話さない意思決定者であれ、技術実装しか見ない開発者であれ。

この「翻訳」の能力は、LLMがやっていることと実は同型です。LLMは自然言語をコードに変え、アイデアをUIに変えます。でもその前に、ある人間が別のことをしなければなりません：その「翻訳」の方向が正しいかどうかを判断すること。

ツールがどれだけ強くなっても、方向を判断するのは人間のままです。

最後に、あの家計簿アプリの話

結局、あのアプリは使い続けませんでした。でも、あの週末が無駄だったとは思っていません。

作って2週間使ったことで、初めて本当に考えられたからです——「家計管理」に対する自分の本当のニーズは何か。そのニーズは実は、毎月一度見るだけの表一枚で十分でした。AIすら必要ありませんでした。

Vibe Codingは、素早く答えを出す手段を与えてくれました。でもその答えの中で最も価値があったのは、ソフトウェアそのものではありません。自分のニーズに対する誤った思い込みを、露わにしてくれたことです。

これが起きるかどうかは、作り終えた後に、ちゃんと自分に問いかけるかにかかっています：これは、もともと自分が解こうとしていた問題を、本当に解いているか？

その問いは、ツールが強くなっても、自動的に答えられるものではありません。