Vibe Codingの光と影：AI生成アプリが本番環境で直面する5つの問題と「ソフトウェア・サニテーション」という処方箋

2025年初頭、Andrej Karpathy氏が広めた「Vibe Coding」という言葉をご存じでしょうか。AIとの対話だけでソフトウェアを組み立て、生成されたコードをほとんど読まずに受け入れ、動いたように見えればそのまま先へ進む開発スタイルを指します。わずか1年余りで、この手法は趣味の世界から実際のビジネスの現場にまで広がりました。約20年この業界に身を置くエンジニアとして申し上げますが、私はAI否定派ではございません。私たちのチームもClaudeやGPTを日常的に活用しております。日常的に使っているからこそ、これらのツールが真価を発揮する領域と、静かに地雷を埋め込む領域の境界線がはっきり見えるのです。本稿では、その境界線をできる限り誠実に描き出します。

まず公平に：AIはプロトタイプ作りにおいて非常に優秀です

エンドユーザーの視点に立てば、Vibe Codingは小さな革命と申し上げてよいでしょう。プログラミング経験のない創業者が、半日で資金調達用のデモを用意できます。事業部門がIT部門の順番待ちをせず、自ら業務ツールを作れます。プロダクトのアイデアを、数ヶ月ではなく数日で実際のユーザーに検証できます。

これらの目的においては、内部のコード品質はほとんど問題になりません。プロトタイプの使命はただ一つ、「このアイデアは追求に値するか」という問いに答えることだからです。答えが出れば役目は終わりです。問題が始まるのは、そのプロトタイプが破棄されず、実際の顧客、実際のデータ、実際の売上に直結されたときです。その瞬間から、以下の5つの問題が順番に姿を現します。

1. 技術的負債の爆発（Technical Debt Explosion）

なぜAIはこれほど速く負債を積み上げるのでしょうか。LLMは「現在の文脈で正しく動くこと」に最適化されており、「半年後も変更しやすいこと」には最適化されておりません。プロンプトのたびにほぼ独立した生成が行われ、モデルは前回採用した規約を記憶していないため、同じロジックが3通りも4通りも異なる書き方でコードベース中に散在します。共通関数への抽象化は行われず、コードを読まないVibe Coderには重複を発見する機会もありません。

その帰結は複利のように膨らみます。1箇所のバグを直しても、他の場所にある4つの複製は古いバグを抱えたままです。テストがないため、誰もデッドコードを消す勇気を持てません。変更のコストは非線形に増大し、やがて小さな機能追加がモジュール全体の書き直しより高くつく地点に到達します。金融の世界では、この状態を債務不履行と呼びます。

2. 無秩序なアーキテクチャ（Spaghetti Architecture）

AIは「回答」という単位でコードを生成し、「システム」という単位では生成しません。プロンプトで明示的に要求されない限り、モジュール境界を定めることも、プレゼンテーション層とビジネスロジックを分離することもありません。そしてVibe Coderは、それを要求すべきだと知らないのです。典型的な結果は、3,000行に達したutils_final_v3.js、あらゆるファイルが相互にimportし合う構造、そして静的解析ツールさえ音を上げる循環依存の連鎖です。

最も深刻な影響は見た目の問題ではございません。階層がなければ、一部分だけを差し替えることができず、データベースの変更が30ファイルの修正になり、通知チャネルの追加が全フローの再調査になります。地図が存在しないため、新しいエンジニアはオンボーディングできません。コードベースは、作った本人にとってさえブラックボックスと化します。

3. 金太郎飴アプリ、差別化の喪失（Cookie-Cutter Applications）

モデルは数百万の公開リポジトリと最も普及したテンプレートから学習しているため、出力は最大公約数に収束します。同じランディングページ構成、同じCRUDフロー、同じデフォルトのコンポーネントライブラリ。業種の異なる3社がそれぞれVibe Codingで製品を作れば、ロゴ以外は驚くほど似通った3つのアプリが出来上がります。

デモであれば実害はありません。しかし商用製品にとって、これは戦略上の問題でございます。ソフトウェアとは本来、自社固有の業務ルールと競争優位、すなわち業界特有のエッジケースや競合が持たない運用ロジックをコードとして結晶化したものであるはずです。テンプレートの土台は、その深さのカスタマイズに耐えられません。実際の業務に合わせて標準フローを曲げようとした瞬間、AIが勝手に選んだフレームワークと格闘する羽目になります。

4. 拡張性の欠如（Zero Scalability）

AIは、開発者のノートPCで動く最も単純な解を選びます。本番用データベースではなくSQLite、キューではなく同期処理、キャッシュではなく直接の読み書き、そして古典的なN+1クエリのループ。モデルの能力不足ではありません。プロンプトに「このシステムは同時1万ユーザーに応える」と書かれていなかっただけであり、非専門家はそれを書くべきだと知らないのです。

その代償は最悪のタイミング、つまり製品が顧客を獲得し始めた瞬間に訪れます。トラフィックが2倍になると応答時間は8倍になります。すべてが溶接されているため、ボトルネックを独立サービスとして切り出せません。残された道は垂直スケール、つまりより大きなサーバーを借りることだけで、アーキテクチャの脆さは据え置きのままインフラ費用だけが増えていきます。私たちが引き継いだあるイベントチケット販売システムは、2週間のVibe Codingで作られ、50名のテストユーザーでは完璧に動きましたが、初回販売の夜、同時800アクセスで停止いたしました。

5. 深刻なセキュリティ脆弱性（Security Vulnerabilities）

私が最も重く見ているのがこの問題です。UIには一切現れないからです。モデルの学習データには鮮度の限界があり、公開済みCVEを抱えた古いライブラリや非推奨のパターンを平然と提案します。文字列連結のSQL、ソースに直書きされたAPIキー、入力バリデーションの欠落、全オリジンに開かれたCORSも珍しくありません。スタンフォード大学の研究（Do Users Write More Insecure Code with AI Assistants?）は、さらに憂慮すべき事実を示しました。AIアシスタントの利用者は安全性の低いコードを書くだけでなく、自分のコードは安全だとより強く確信する傾向があるのです。

Vibe Codingにはレビュー工程そのものが存在しないため、あらゆる脆弱性が顧客データとともにそのまま本番環境へ出荷されます。影響は技術の範囲を超えます。個人データの漏洩は、市場に応じてGDPR、日本の個人情報保護法（APPI）、ベトナムの政令13/2023号に基づく法的責任を招き、金額では測れない信頼の毀損を残します。

処方箋：「ソフトウェア・サニテーション」でプロトタイプを本番システムへ

朗報がございます。多くの場合、答えはゼロからの作り直しではありません。AIで作られたアプリケーションは、最も価値のある資産である「ビジネス上の有効性」をすでに証明しています。欠けているのは、その下を支えるエンジニアリングです。OKAXIではこれを補う工程をソフトウェア・サニテーション（Software Sanitation）と呼び、ソフトウェア受託開発チームが測定可能な3つのステップで実施いたします。品質と安全性を、感覚ではなく数値で回復させる工程です。

ステップ1：Code Audit & Refactoring（コード監査とリファクタリング）

第一の原則は「切る前に測る」です。静的解析を実行し、依存関係グラフを構築し、テストカバレッジを計測した上で、技術的負債をリスク別に地図化します。コードに手を入れる前に、現在の挙動を固定するcharacterizationテストを整備し、リファクタリングが構造だけを変え、業務ロジックを一切変えないことを保証します。その後に初めて清掃を進めます。重複ロジックの統合、単一責任によるモジュール分割、そしてCI/CDへの組み込みにより、品質が二度と静かに後退しない体制を築きます。

ステップ2：Architecture Re-design & Scaling（アーキテクチャ再設計と拡張性確保）

清掃と並行して、業務境界に沿ったアーキテクチャの再設計を行います。明確な階層分離、重い処理のメッセージキューへの移行、キャッシュとコネクションプーリングの導入。マイクロサービス化は流行だからではなく、独立したスケールが本当に必要な部分に限って道筋を用意します。インフラはInfrastructure as Codeへ移行し、可観測性を組み込みますので、次のトラフィック急増への対応は書き直しではなくインスタンス追加で済みます。複雑なシステムの場合、ロードマップを確定する前に独立したシステムアーキテクチャコンサルティングから始めることも可能でございます。

ステップ3：Security Hardening & Optimization（セキュリティ強化と最適化）

最後のステップで、氷山の水面下に対処します。SCAスキャンと依存関係の全面更新、シークレットのVault移行と漏洩済みキーのローテーション、文字列連結SQLのパラメータ化クエリへの置換、入力バリデーション、レートリミット、セキュリティヘッダー、認可モデルの引き締め、そして仕上げのペネトレーションテスト。パフォーマンス最適化も同じステップで行います。作業が重なるためです。N+1クエリの解消、インデックスとキャッシュの追加により、p95レイテンシは多くの場合当初の数分の一まで下がり、インフラ費用もそれに連動して下がります。

結論：AIは加速装置であり、エンジニアリングの代替ではありません

すべてを踏まえた上での私の立場は一貫しております。Vibe Codingは悪役ではありません。ソフトウェアの歴史上、最も安価なアイデア検証の仕組みであり、企業は大いに活用すべきです。唯一の誤りは、下書きを製品と取り違えることです。AIはコードを非常に速く書きますが、アーキテクチャ、負荷耐性、データの安全性に及ぶエンジニアリングの責任は、依然として経験豊富なエンジニアが担うべきものです。

貴社がAIで構築されたアプリケーションを運用しており、上記の症状に心当たりがおありでしたら、最初のインシデントを待たないでください。OKAXIのソフトウェア受託開発サービスがシステムを監査し、現状の明確な評価レポートと段階的なサニテーションのロードマップをご提示いたします。アイデア検証の段階で貴社を勝たせたプロトタイプが、運用の段階でも勝ち続けられるように。