Michael WegmüllerはAI分野で20年以上の経験を持つ。Artifact SAの共同創業者であり、広く知られたAIビジネスの専門家である。
クライアント向けのライブワークショップ中、私たちのアンケートアプリケーションが突然動作を停止した。ユーザーが質問の第5セクションを超えて進んだところで、テスト時には一度も遭遇しなかったハードコードされた値が管理パネルを破壊したのだ。
数十人の参加者が回答を送信しようとしている状況で、選択肢は1つしかなかった。リアルタイムで修正することだ。修復は3分もかからなかった。しかし、手に汗握るその数分間は、AIでソフトウェアを構築する際の驚異的なスピードと、見えにくい脆さの両方を露わにした。いまは「vibe coding」の時代である。
AI支援開発の台頭
2022年のChatGPTの急成長以来、大規模言語モデル（LLM）は開発者のコードの書き方を根本から変えてきた。GPT-4のリリースはこの変化を加速させ、構文に集中するのではなく会話を通じてアプリケーションを構築できる、ターミナルおよびブラウザベースのツールの新世代を生み出した。
Googleの2025年版「DORA State」レポートによれば、AIツールを使う開発者の80%超が生産性の向上を報告している。また、Stack Overflowの最近の調査では、回答者の84%がワークフローでAIツールを使用している、または使用する予定だと示されている。
2025年2月、Teslaの元AIディレクターであるAndrej Karpathyが「vibe coding」という言葉を広めた。これはAIを単なる補助として使うのではなく、モデルに完全に依存するというものだ。そのため、問題が表面化したら対処しつつ、出力だけを確認し、根底にあるコード自体は確認しない。Karpathyの表現には皮肉も込められていたが、いまやジョークから実際の開発手法へと進化している。
実験：「Poll-Patrol」の構築
私たちのAI特化型コンサルティング会社では、実プロジェクトでvibe codingの限界を試すことにした。日々の業務は、社内チャットボット、概念実証（PoC）、AI支援の自動化に及び、その多くは既製のソリューションではなくカスタムロジックを用いたPythonで構築されている。AIがコードのレベルだけでなく、アプリケーションのレベルでも開発を加速できるのかを理解したかった。
その成果が「Poll-Patrol」だ。これはフィードバックを収集し、ワークショップ中にモデレーターがLLM駆動のチャットインターフェースを介して対話的に質問できるように設計したアンケートアプリケーションである。初期プロトタイプはv0で設計し、それ以外のすべてには、ターミナルベースの人気コーディングツールであるClaude Codeを用いた。
アイデアから動作するプロトタイプまで、わずか2日で到達した。その後、このアプリケーションは複数のクライアントワークショップと社内セッションに展開され、現実的な条件下で機能性を証明している。追加開発を経て、コードベースは約5万行へと拡大した。
高速開発が可能だった大きな理由は、問題が明確に定義され、スコープが比較的狭かったことだ。そのため、従来の開発と比べてかなりの時間を節約できた。
しかし、ライブワークショップでのバグ、すなわち「5セクション」というハードコードされた上限は、このアプローチのアキレス腱を露呈させた。最初のテストでは、元のワークショップ草案は4セクションしか使っておらず、AIが生成したテストでもこのエッジケースは表面化しなかった。
私たちがこれを発見したのは、ユーザーがリアルタイムでクリックして進めたときだった。管理パネルは壊れたが、幸い参加者向けのインターフェースは動作し続け、ワークショップは継続できた。それでも、緊急デバッグの3分間は、現在のvibe codingの真実を示していた。スピードには見えないコストが伴う。
vibe codingの隠れたコスト
今回の経験から、vibe codingを検討するあらゆるチームが理解しておくべき難しさが明らかになった。
・バタフライ効果：UIのボタンを1つ変更するといった一見些細な変更が、別の箇所でコードベースを壊し得る。AIにボタン追加を依頼すると、そのボタンを動かすために状態管理をリファクタリングすることがある。この脆さは、適切に制御されなければ、相互接続されたモジュールを抱える大規模なコードベースでは指数関数的に増大する。
・セキュリティの死角：AI生成コードは、安全でない入力処理といった脆弱性を持ち込む可能性がある。モデルは機能性に最適化されており、明示しない限り必ずしもセキュリティに最適化されるわけではない。
・検証オーバーヘッド：書く時間の短縮は、出力を検証する時間によって相殺され得る。AIアシスタントが生成するのはコードであって、十分にテストされたアプリケーションではない。開発者は依然として、テストを書く（またはAIに書かせる）、統合チェックを実行する、正しさを検証する、実データやエッジケースに対応できていることを確認する必要がある。さらに、ドメイン固有の業務ロジックは、明確かつ慎重に指示しない限り、しばしば誤って解釈される。
vibe codingが有効な場面
「十分に良い」で許されるプロジェクト、すなわち社内ツール、プロトタイプ、既存の事例が何百万とある汎用的なアプリケーションにおいて、vibe codingには現実的な価値がある。デモまでの時間を短縮し、反復サイクルを高速化できる。
一方で、コードレベルで出力を注意深く点検しない限り、重要度の高い環境には依然として不向きだと私は考えている。医療アプリケーション、金融システム、規制下の本番環境などは、vibe codingではまだ提供できない水準の検証と信頼性が求められる領域である。
チームへの提言
経験に基づき、AI支援開発を探るチームに対して次の指針を提示したい。
・vibe codingは本番ではなく、土台作りに使う。AIはボイラープレート、プロトタイプ、単発のスクリプトのためのヘルパーとして扱うべきだ。顧客向けにリリースする前に、慎重な人間によるレビュー、テスト、リファクタリングを徹底することを約束する。
・検証パイプラインを早期に確立する。人間によるコードレビュー、自動テスト、セキュリティ監査を、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインに初日から組み込む。脆さや脆弱性を早期に捕捉すれば、それらが負債になることを防げる。
・コードレベルのテストと出力レベルのテストを区別する。vibe codingでは、UIの挙動、APIレスポンス、データフローといった「目に見えるもの」だけをテストしたくなる誘惑がある。本番投入の準備には、コードレベルの検証も必要だ。これには、テスト、保守性、例外処理、依存関係の健全性、セキュリティ強化にも取り組むことが含まれる。
・スコープについて現実的であること。セキュリティや重い保守よりも、スピードと柔軟性が重要なタスクでvibe codingを優先する。AIをあらゆる開発ニーズに対する魔法の解決策として扱ってはならない。
結論
動くアプリケーションまで2日。ライブでのホットフィックスに3分。包括的なテストを備えた5万行のコード。これらの数字は、vibe codingの可能性と危うさの双方を捉えている。
この技術は、適切なユースケースにおいては変革的になり得る。しかし変革には、能力と同じくらい明確に限界を理解することが必要だ。AIを自律的な代替ではなく強力な協働者として扱う意志のあるチームにとって、vibe codingは真の競争優位をもたらす。それ以外の人々にとっては、あの手に汗握る数分間が、はるかに長く続くかもしれない。
