バイブコーディングとは?わかりやすく解説

バイブコーディング(vibe coding)とは、作りたいものを普通の言葉でAIに伝え、出てきたものを実行し、コードを読むのではなく結果を見ながら方向を修正していく、ソフトウェアの作り方です。評価するのはアプリそのものです。ボタンは動くか、ページの見た目は合っているか。必要なものになるまで、変更を頼み続けます。この言葉は、AI研究者のアンドレイ・カルパシー(Andrej Karpathy)が2025年2月にXへの投稿で生み出したもので、雰囲気(vibes)に身をゆだね、コードの存在すら忘れる、と表現しました。

この言葉の由来

OpenAIの創設メンバーで、元Teslaのヘッド・オブ・AIでもあるカルパシーは、週末の小さなプロジェクトの作り方を説明するためにこの言葉を使いました。AIコーディングツールに話しかけ、変更の差分は読まずに受け入れ、エラーメッセージをそのまま貼り付けて、動くようになるまで繰り返すというやり方です。彼は、これが使い捨てのプロジェクト向きだと明言していました。

この言葉が広まったのは、多くの人がすでにやっていたことに名前を付けたからです。数か月のうちに、趣味のプロジェクトからスタートアップのプロトタイプまで、あらゆる場面で使われるようになり、Collins English Dictionaryは「vibe coding」を2025年の「今年の単語」に選びました。今では、AIがコードを書き、人が普通の言葉で指示を出す作り方全般を、ゆるやかにこう呼びます。

AIで作るなら、なぜ重要なのか

コードを書かない人にとって、バイブコーディングこそがAIアプリビルダーが役に立つ理由そのものです。創業者は午後のうちにアイデアを試せます。小規模事業のオーナーは、代理店に頼むほどではないと諦めていた予約フォームや在庫管理ツールを作れます。デザイナーは、モックアップをクリックできるものに変えられます。

ただし、この定義には最初から警告が含まれています。「コードの存在すら忘れる」というのは、コードが今日、自分のためだけに動けばよい間は問題ありません。顧客のデータを保存する、支払いを受け付ける、何年も動き続ける必要がある、という場面になると、そうはいきません。その境界線がどこにあるかを知ることが、バイブコーディングについて学べる最も役に立つことです。

身近なたとえ

キッチンのリフォームを、自分で図面を描くのではなく、大工さんに希望を伝えて進めてもらう場面を考えてみてください。「窓の下に長いカウンター、オープンシェルフ、冷蔵庫はドアの近く」と伝え、毎晩部屋に入って、できた部分を見て、直してほしいところを伝えます。

レイアウトや見た目については、これでうまくいきます。部屋に立つだけで判断できるからです。うまくいかないのは、壁の裏側です。配線、配管、ガス管が基準を満たしているか。見ただけではわからず、問題は何かが起きるまで表に出ないかもしれません。慎重なオーナーは、それでも検査を受けます。

バイブコーディングも同じです。画面は目に見える部屋で、セキュリティ、データの扱い、コードの構成が配線にあたります。

バイブコーディングの実際の流れ

たとえば、どの顧客が請求書を支払い済みかを管理する簡単なツールが欲しいとします。

コードのファイルは一度も開いていません。ただしステップ3に注目してください。アプリは、実際には何も保存していないのに、完成して見えていました。バイブコーディングは、ユーザーとしてテストし、見たものを正確に伝えられる人に報いてくれます。

メリット

• スピード。 動く最初のバージョンが、数週間ではなく数分から数時間でできます。
• アイデアを試すコストが低い。 同じものを3パターン作って、うまくいった1つを残せます。
• 直接コントロールできる。 課題を一番理解している人が製品の形を決められるので、開発者に伝える間に依頼内容が抜け落ちることがありません。
• やりながら学べる。 AIが作るものを眺めて「なぜ?」と尋ねるうちに、フロントエンドとバックエンド、データベース、APIなど、アプリの仕組みを自然に身に付ける人は多くいます。

本当のリスク

これらはバイブコーディングを避ける理由ではありません。雰囲気だけでは確認してくれないことです。

見えないセキュリティの穴

アプリは完璧に見えても、ログインしている誰もが他のユーザーの記録を読めたり、訪問者のブラウザで動くコードに秘密鍵がむき出しになっていたりすることがあります。自分としてクリックして回っているだけでは、どちらも見つかりません。よくある問題は、サーバー側の権限チェックの欠如、フロントエンドのコードに置かれたAPIキー、何でも受け付けてしまうフォームです。

誰も理解していないコード

誰もコードを読んでいなければ、誰もその構成を知りません。小さいうちは問題ありません。アプリが大きくなるにつれ、変更のたびに無関係な部分が壊れる恐れが出て、AIが1つのバグを「直す」ことで別のバグを作り始めることもあります。何か月もレビューなしでバイブコーディングされたアプリは、時間をかけて作ったアプリより変更しにくいことがよくあります。

「完成」の意味がわからない

AIは「直しました」と気軽に言います。本当に直ったかどうかは、テストしてはじめてわかります。テストを省くと、デモでは動くのに、実際のデータでは失敗する機能が残ります。長い名前、空の項目、同じ枠を2人が同時に予約する、といったケースです。

隠れた依存関係とコスト

AIが作るアプリは、メールプロバイダー、決済サービス、AI APIといった外部サービスを取り込むことがよくあります。それぞれに独自のアカウント、キー、上限、請求があります。公開する前に、アプリが何に依存しているかを把握しておきましょう。

よくある誤解

責任を持ってバイブコーディングするには

いくつかの習慣で、リスクの大半をカバーできます。

1. 変更は小さく保つ。 1回の依頼で1つの変更をし、テストします。大きくあいまいな依頼は、大きくあいまいな結果を生みます。
2. チェックポイントを使う。 危ない変更を試す前に、最後に動いていたバージョンに戻せることを確認します。
3. AIに説明させる。 「この変更は何をする?何が壊れる可能性がある?」と聞くのは、手間が少なく、多くの問題を見つけられます。
4. 他人としてテストする。 2人目のユーザーとしてログインし、1人目のデータが見えてしまわないか試します。
5. 秘密情報をコードやチャットに入れない。 APIキーは環境変数やプロジェクトのシークレットに置きます。
6. 実際のユーザーに使ってもらう前にレビューする。 支払いや個人データを扱うものは、セキュリティチェックリストを確認するか、開発者に見てもらいましょう。

AIビルダーに頼むべきこと

雰囲気を確認に変える、役に立つプロンプトです。

• 「作る前に、計画と、保存するデータを教えて」
• 「このアプリがユーザーデータを保存または送信している場所をすべて挙げて」
• 「ログインしているユーザーが他のユーザーの記録を見たり変更したりできる?ページだけでなく、サーバー側のコードを確認して」
• 「ブラウザで動くコードにAPIキーが見えている箇所はある?」
• 「2人が同時にこのフォームを送信したらどうなる?」
• 「直近3回の編集で何が変わったかをまとめて」

さらに多くのパターンはAIアプリビルダー向けプロンプトの書き方を、うまくいかないときはAIで作ったアプリのデバッグ方法をご覧ください。

Mythex でのバイブコーディング

Mythex は、この作り方のために作られたAIアプリビルダーです。チャットでアプリを説明すると、エージェントがコードを書いてライブプレビューで実行し、公開URLに公開できます。上記のリスクに対応する機能もいくつか用意しています。Plan モードでは、エージェントがファイルに触れる前にアプローチを示します。Ask モードでは、何も編集せずに質問に答えます。そして、成功したターンごとにチェックポイントが保存され、いつでも戻せます。Proでは、開発者にレビューしてもらいたいときに、フルのコードエディタを開いたり、プロジェクトをエクスポートしたり、GitHubと同期したりできます。モードとチェックポイントについてはチャットのドキュメントで説明しています。白紙から始めるのが大変なら、テンプレートが出発点になります。

よくある質問