Cursor や Lovable にプロンプトを打ち込み始めて3時間ほど経ったとき、まるで魔法のような感覚を覚える瞬間がある。普通の言葉で要件を伝えただけなのに、画面には動作するUIが現れ、ログイン画面があり、データベースまで繋がっている。エンジニアを雇う必要もなく、会議も不要で、納期の交渉もいらない。
これがバイブコーディングだ。確かに印象的な体験である。そして同時に、確かに不完全でもある。
2026年、バイブコーディングはもはや目新しい技術ではなく、ひとつのワークフローとして定着した。スタートアップ創業者はMVP開発に使い、マーケターは社内ツール構築に活用する。米国のある学区はAIを使った独自開発によって、既製品ソフトウェアを購入するよりも20万ドルを節約した。この流れは本物であり、生産性向上の効果も実証されており、後退することはないだろう。
しかし、RedAccessが最近公開した調査結果は注目に値する。分析された38万のバイブコーディング製アプリのうち、約5,000件が企業または個人の機密データをインターネット上に公開していた。患者の医療記録、財務情報、フロントエンドのコードにそのまま書かれたAPIキー。これは開発者の不注意によるものではない。そもそも開発者がいなかったのだ。あったのはプロンプトと、AIと、デプロイボタンだけだった。
問題はバイブコーディングが機能するかどうかではない。特定の用途では明らかに機能する。問題は、それが何をしないのかということだ。
バイブコーディングが本当に得意なこと
公平に評価するならば、バイブコーディングはスピードとアクセシビリティにおいて卓越している。アイデアを持つことと、動くプロトタイプを持つことの間にあるハードルを取り除く。社内ツールや素早いデモ、コンセプト検証が目的のMVP開発においては、対抗できるツールはほとんどない。
また、技術的な背景を持たない創業者が自社プロダクトの方向性を主体的に決められるようにもなった。5年前には考えられなかったことだ。それは確かに価値がある。
バイブコーディングができないこと
率直に整理する。
将来を考慮しない。 AIは目の前のプロンプトを満たすコードを生成する。ユーザーが10人から1万人に増えたときどうなるか、来年の会計システムとどう統合するか、プロダクトがピボットしたときデータモデルはどうなるか――そういった問いを立てない。開発会社はそれを問う。コードを書く前に、その会話が行われる。
結果に責任を持たない。 AIで作ったアプリが本番環境で障害を起こしても、電話できる相手はいない。SLAも、説明責任もない。コードを生成したモデルはダウンタイムの責任を負えない。開発会社は負える。そして優れた会社は、その責任を契約上で明示する。
ビジネスを理解しない。 良いソフトウェアは機能の集合体ではない。特定の企業がどのように動いているか、顧客は誰か、何を達成する必要があるかに基づいて設計されたプロダクトだ。コンテキストを深く理解した開発会社のアーキテクチャ判断は、数年にわたってビジネスを支え続ける。AIはプロンプトを満たす判断をするだけだ。
セキュリティを担保しない。 これが最も深刻なギャップだ。セキュリティは後から追加する機能ではない――認証の設計、データの保管方法、APIの構造の中に組み込まれるものだ。AIが生成するコードは公開リポジトリで学習されており、良いパターンも悪いパターンも同様に学んでいる。出力を人間がレビューしなければ、モデルが生成したものをそのままシップすることになる。5,000件の情報漏洩は、これが理論上のリスクではないことを示している。
保守をしない。 リリースは始まりにすぎない。ソフトウェアを安定稼働させ続け、更新し、変化する依存関係と互換性を保つことは別の話だ。バイブコーディングで作ったアプリには保守計画がない。開発会社にはある。
「エンジニア不要」の本当のコスト
バイブコーディングは初期費用が安く見える。最初のビルドはそうかもしれない。しかしコストは後から現れる。コードベースが保守不能になったとき、セキュリティの脆弱性が表面化したとき、事業がプロトタイプの限界を超えたとき、そしてシステムを理解しているエンジニアが誰もいないとき。
最初からやり直す費用は高い。セキュリティインシデントの対処費用は高い。肝心な場面でシステムがダウンしてクライアントを失うことは、さらに高くつく。
プロフェッショナルな開発には費用がかかる。それは後に来るはるかに大きな請求書を回避するためだ。
開発会社がもたらす、AIには代替できないもの
開発会社が提供するのは判断力だ。コードだけではなく、判断力。誤ったアーキテクチャに向かうブリーフに異議を唱える能力。クライアントが求めた機能が、クライアントが本当に必要としている機能ではないと見抜く経験。2年後に別の誰かが読んで保守できるコードを書く規律。
また、説明責任も伴う。契約があり、チームがあり、担当者がいる。何か問題が起きたとき――ソフトウェアでは必ず何かが起きる――解決するための関係とプロセスが存在する。
TMNSolutionsには、バイブコーディングを試した企業からのご相談がある。自分たちで作ったプロトタイプを本番環境に移行したいという相談もあれば、実際のトラフィックに耐えられなかった後の相談もある。どちらの場合も、会話の中身は同じだ。実際に何をするものか、誰が使うのか、2年後もビジネスを支えられるようにどう作るか。
そのような会話は、プロンプトとは交わせない。
適切なツールを、適切な用途に
これはバイブコーディングを否定する主張ではない。社内ダッシュボード、素早い実験、コンセプト検証のプロトタイプには積極的に使うべきだ。そういった用途では本当に役立つ。
しかし、顧客が依存する何か、顧客のデータを扱う何か、事業の根幹となる何かを構築するなら――そこはプロを省略すべき場所ではない。
バイブコーディングの時代に成功する開発会社は、AIツールを積極的に取り入れながら、AIが提供できないものを守り続ける会社だ。アーキテクチャ、説明責任、セキュリティ、長期的な思考。
それらが自動化される日は、まだ当分来ない。
