vibe coding とは何か

vibe coding とは、コードを 1 行ずつ手で書くのではなく、自然言語で「こういうものを作りたい」と AI に伝え、返ってきたコードをほぼそのまま動かしながら開発を進めるスタイルのことです。生成されたコードの細部を読み込まず、出力の「雰囲気（vibe）」が合っているかどうかで判断して前へ進むのが最大の特徴です。

この言葉は 2025 年初頭に Andrej Karpathy がソーシャルメディアで使ったことで一気に広まりました。彼は「コードがあることすら忘れて、ただ AI に話しかけて作る」感覚をユーモアを込めて表現しています。日本語では「バイブコーディング」とカタカナ表記されることも増えました。

従来の開発では、エンジニアが構造を設計し、関数を書き、レビューを通すという積み上げが前提でした。vibe coding はその順序を逆転させ、まず動くものを AI に出させてから、必要なら手を入れるという進め方をします。Claude Code や Cursor のようなツールが、ファイル全体を読み込んで一括で生成・修正できるようになったことで、現実的な手法として成立しました。

ここで誤解しやすいのが、「vibe coding は雑な開発」という捉え方です。本質は雑さではなく、コードの正しさを行単位で人間が保証することを一旦手放し、動作の確認に判断を寄せている点にあります。だからこそ速く、だからこそ向き不向きがはっきり分かれます。この記事では、vibe coding の意味とやり方を押さえたうえで、実務でどこまで使えるのか、その境界線を実プロジェクトの経験から整理します。

vibe coding と AI 駆動開発の違い

「AI にコードを書かせる」という点だけ見ると、vibe coding と AI 駆動開発は同じに見えます。しかし目的と検証の厳しさがまったく異なります。混同したまま本番開発に持ち込むと事故につながるため、最初に違いをはっきりさせておきます。

vibe coding の目的は「速く動くものを作る」ことです。コードの中身や設計の妥当性は深く問いません。対して AI 駆動開発の目的は「本番品質のプロダクトを継続的に届ける」ことであり、テスト・型・レビュー・CI といった検証の仕組みを前提に AI を組み込みます。AI 駆動開発の全体像は AI 駆動開発とは？従来開発との違い・進め方 で詳しく解説しています。

両者を並べると、次のように整理できます。

観点vibe codingAI 駆動開発
主な目的速く動くものを作る（探索）本番品質を継続的に届ける
コードの理解中身を読み込まないことが多い人間が設計と判断を握る
検証動けば OK に寄りやすいテスト・型・レビュー・CI が前提
向くフェーズアイデア検証・プロトタイプ探索から本番運用まで
失敗したときの影響作り直せば済む障害・データ事故につながる

重要なのは、vibe coding は AI 駆動開発の対義語ではなく、その一部のフェーズで使う手法だということです。fixit でも、初期の探索では vibe coding 的に素早く動くものを作り、本番化の判断をした時点で AI 駆動開発の作法へ切り替えます。境界をどこに引くかが、品質とスピードを両立させる鍵になります。

vibe coding でできること・向くケース

vibe coding が最も力を発揮するのは、間違えても作り直せばよい領域です。コードの正しさを行単位で保証しない代わりに、圧倒的な速度で「とりあえず動くもの」を手に入れられます。具体的には次のようなケースが向いています。

アイデアの検証は典型例です。頭の中の構想を言葉で伝えるだけで画面が立ち上がるため、企画段階で「触れるモック」を数時間で用意できます。ステークホルダーに見せて方向性を固める用途では、コードの綺麗さより形になる速さが価値を持ちます。

社内向けの小さなツールや使い捨てのスクリプトも好相性です。データの一括変換、定型レポートの自動生成、ちょっとした集計ツールなど、利用者が限られていて壊れても影響が小さいものは、vibe coding で十分に実用に耐えます。

学習目的でも有効です。新しいフレームワークやライブラリを試すとき、まず AI に動く例を出させて、それを読みながら理解を深めるという使い方ができます。エンジニアでない職種の人が、業務の自動化を自分の手で試す入口としても機能します。

逆に言えば、これらに共通するのは「失敗のコストが低い」という条件です。次の章では、この条件が崩れたとき、つまり vibe coding を本番品質のシステムにそのまま持ち込んだときに何が起きるかを見ていきます。

実務で破綻しやすい3つの落とし穴

vibe coding の速さに惹かれて、そのまま業務システムや顧客向けプロダクトに使おうとすると、決まったパターンで破綻します。fixit が実プロジェクトで観測してきた、特に起きやすい 3 つの落とし穴を挙げます。これが「vibe coding の危険性」と呼ばれるものの正体です。

落とし穴1：誰も中身を理解していないコードが積み上がる

最初は快適です。指示を出すたびに機能が増え、画面が動きます。しかしある時点で AI が生成したコードの全体像を、もはや誰も把握していない状態になります。バグが出ても、どこを直せばよいか分からない。修正を頼むと別の場所が壊れる。この「触れないコード」が積み上がると、開発速度はむしろ手書きより遅くなります。雰囲気で進めた代償が、保守フェーズで一気に表面化するのです。

落とし穴2：非機能要件がまるごと抜け落ちる

vibe coding で「動くもの」を作ると、たいてい正常系だけが実装されます。入力の検証、権限のチェック、エラー時の挙動、ログ、レート制限といった非機能要件は、明示的に指示しない限りほとんど抜け落ちます。デモでは完璧に見えても、本番では想定外の入力で簡単に落ち、最悪の場合はセキュリティの穴になります。特に認証・認可まわりを雰囲気で実装したコードは、情報漏洩の温床になりやすく注意が必要です。

落とし穴3：テストがないため、変更が常に怖い

最大の問題は、検証の土台がないことです。テストがないコードは、変更するたびに「壊れていないか」を人間が手で確認するしかありません。プロトタイプのうちは許容できても、機能が増え、関わる人が増えると、この確認コストが指数的に膨らみます。AI に修正を頼んでも、テストがなければ AI 自身も「直ったかどうか」を判断できません。検証可能性の欠如こそが、vibe coding を本番に持ち込んだときの本質的なリスクです。本番投入時に確認すべき具体的なレビュー観点は vibe coding を本番投入する前のレビュー基準 にまとめています。

vibe coding を本番品質に引き上げる手順

では、vibe coding で素早く作ったものを、安心して本番運用できる状態へ引き上げるにはどうすればよいか。fixit が実務で踏んでいる手順を 5 ステップで示します。ポイントは、雰囲気で作った段階のコードに固執しないことです。プロトタイプはあくまで「要件を可視化する道具」と割り切り、本番化では作り直しも選択肢に入れます。

flowchart LR
  P["1. プロトタイプで<br/>要件を可視化"]
  S["2. 仕様を文書化<br/>(人間)"]
  T["3. 受け入れテスト設計<br/>(人間)"]
  I["4. テストを満たす実装<br/>(AI / 人間レビュー)"]
  G["5. 非機能要件 + CI 整備"]
  P --> S --> T --> I --> G

ステップ 1：プロトタイプで要件を可視化する。 vibe coding で作った動くものを叩き台に、本当に必要な機能とそうでない機能を見極めます。この段階のコードは捨てる前提で構いません。

ステップ 2：仕様を文書化する。 何を作るのかを言葉で確定させます。曖昧なまま AI に渡すと、AI が勝手に解釈を埋めてしまうため、ここは人間が握ります。仕様を先に固めてから AI に手綱を渡す進め方は、探索フェーズと本番フェーズを橋渡しする要になります。

ステップ 3：受け入れテストを設計する。 「何が満たされていれば正しいのか」をテストとして人間が定義します。テストの設計まで AI に丸投げすると、AI が自分の実装に都合のよいテストを書きはじめるため、ここは人間の仕事です。

ステップ 4：テストを満たす実装を AI に書かせる。 テストが Red の状態から、それを Green にする実装を AI に任せます。プロトタイプのコードを再利用するか、書き直すかも、このテストを基準に判断します。

ステップ 5：非機能要件と CI を整える。 認証・入力検証・エラー処理・ログ・監視といった抜けがちな要件を埋め、CI と静的解析を整備します。これでようやく、AI に追加開発を任せても壊れにくい土台が完成します。

この手順を体系立てて学びたい方は、入門から本番運用までを一冊にまとめた vibe coding 完全ガイド もあわせて参照してください。

プロトタイプから本番へ：fixit の進め方

fixit は「AI 駆動開発で爆速・高品質のプロダクト開発」を掲げる AI 駆動開発のクリエイティブスタジオです。クライアントワークでは、vibe coding の速さと AI 駆動開発の堅牢さを、フェーズで明確に切り替えながら進めています。

立ち上げの初期は、あえて vibe coding に近いスピード重視で「触れるもの」を一気に作ります。ここで関係者の認識をすり合わせ、本当に作るべきものを確定させます。そして本番化の意思決定をした瞬間に、前章の手順へ切り替えます。仕様の文書化、受け入れテストの設計、CI の整備までを通すことで、その後は AI に開発を任せても品質が崩れない状態を作ります。

この「探索は速く、本番は堅く」という切り替えこそが、AI 時代の開発で速度と品質を両立させる現実的な解だと考えています。詳しい開発体制やプロセスは AI 駆動開発サービス のページで紹介しています。

プロトタイプは作れたが本番化で行き詰まっている、社内で vibe coding を試したものの保守できる形に落とせない、といった課題があれば、ぜひ一度ご相談ください。AI 駆動開発の無料相談 で、どこに境界線を引き、どの順番で本番品質へ引き上げるかを一緒に整理します。

よくある質問

Q. vibe coding は危険なのでやめたほうがよいですか？

A. 領域を選べば危険ではありません。アイデア検証・社内ツール・使い捨てスクリプトなど、壊れても影響が小さい領域では非常に有効です。危険になるのは、検証の土台がないまま本番システムへそのまま持ち込んだときです。「探索で作ったものを、検証なしに本番へ流さない」という線引きさえ守れば、安全に活用できます。

Q. エンジニアでなくても vibe coding はできますか？

A. 動くものを作る入口としては可能です。Claude Code や Cursor を使えば、コードを書けなくても画面を立ち上げられます。ただし、本番運用や業務利用を考えるなら、生成コードのレビューやテスト、セキュリティ確認が必要になり、ここはエンジニアリングの知見が要ります。プロトタイプは自分で、本番化は専門家と、という分担が現実的です。

Q. vibe coding でセキュリティは大丈夫ですか？

A. 明示的に指示しない限り、認証・認可・入力検証といったセキュリティ要件は抜け落ちがちです。プロトタイプでは許容できますが、本番では必ず人間によるセキュリティレビューを挟んでください。特に顧客データや課金が絡むシステムでは、雰囲気で実装した認証まわりが情報漏洩の温床になり得るため注意が必要です。