AI面接シリーズ15：Vibe Codingのよくある落とし穴とは？

Vibe Codingの「感覚/雰囲気駆動」モードは、高速プロトタイピングやクリエイティブな探索には非常に便利ですが、制御しないといくつかの典型的な落とし穴に陥りやすいです。以下、コード品質、保守性、セキュリティ、要件の進化、チーム協力の5つの次元からまとめます。

一、コード品質の落とし穴

Vibe Codingは会話型の反復に依存しているため、ユーザーが曖昧な修正要求（例：「このボタンをもっとテクノロジー感あふれるものにして」）を出すたびに、AIは既存のロジックをリファクタリングするのではなく、新しいコードを追加する傾向があります。どの古いコードが無効になったかを認識できず、削除することにも慎重になるため、冗長なコードやデッドコードが蓄積されます。同時に、AIには統一された「コードスタイルの記憶」がなく、生成のたびに異なる命名規則（トレーニングデータのランダム性による）に従う可能性があり、ユーザーが明確なルールを強制することもほとんどないため、最終的なコードは乱雑で予測不能になります。まとめると以下の通りです。

冗長コードとデッドコード：何度も修正を重ねた後、AIは古い実装、コメントアウトされたコードブロック、未使用のインポートを残します。削除のリスクが高いため、保持することを選択します。
命名とスタイルの不統一：AIは異なるラウンドでトレーニングデータからランダムにスタイルを抽出するため、ユーザーが規範を強制しないと、キャメルケース、スネークケース、スペースが混在します。
隠れたロジックエラー：AIは「一般的なパス」で正しいコードを生成する傾向がありますが、境界条件（null値、極値、並行処理）はしばしば無視されます。なぜなら、トレーニングデータにそのような例が少ないからです。

二、保守性の落とし穴

Vibe Codingの反復速度は非常に速く、ユーザーとAIはどちらも「現在の機能が使えるかどうか」に集中し、ドキュメントやコメントを書いたりリファクタリングする時間はほとんどありません。AIには長期記憶がなく、関数にdocstringを積極的に追加したり、次に引き継ぐ開発者を考慮したりすることはありません。また、AIは「目の前の要件を満たす」ことに偏り、汎用フレームワークを過剰に設計してしまうか（ユーザーが後で必要になると思い込む）、コピー＆ペーストで素早く実装するかで、抽象化の階層が乱れます。まとめると以下の通りです。

ドキュメントとコメントの不足：AIはデフォルトで「自己説明的なコード」を出力しますが、実際には複雑な正規表現やアルゴリズムは理解しづらいです。ユーザーが要求しない限り、ドキュメントは書きません。
過剰抽象化または抽象化不足：AIは時には一般的なデザインパターン（ファクトリ、ストラテジーなど）を問題が簡単でも適用し、また時には共通関数を抽出するのを怠ってコードブロックを直接コピーします。

三、セキュリティの落とし穴

AIのトレーニングデータには多くのオープンソースコードが含まれており、その中には歴史的な脆弱性（SQLの連結、ハードコードされた鍵など）が含まれています。Vibe Codingでは、ユーザーが「パラメータ化クエリを使用して」や「環境変数から鍵を読み取って」と積極的に要求することはほとんどなく、AIは最も一般的で（そしてしばしば安全でない）パターンを採用します。さらに、AIには「脅威モデル」の意識がなく、入力フィルタリングや最小権限を積極的にチェックしません。機能の実装にしか関心がないからです。まとめると以下の通りです。

インジェクション脆弱性：AIはデフォルトで文字列連結を用いてSQL/コマンドを構築します。なぜなら、この方法がシンプルなチュートリアルで最も一般的だからです。
機密情報のハードコード：トレーニングサンプルではAPIキーを直書きする例がよくあり、AIはそのパターンを模倣します。
過剰な権限：AIは便宜上、sudoやw+モードでファイルを開くことが多く、最小限の必要な権限を考慮しません。

四、要件の進化の落とし穴

Vibe Codingには明確な境界がありません。ユーザーが「もう一つ機能を追加して」と言えば、AIはできる限り応えようとしますが、何が「範囲外」かを認識しません。また、AIには優先順位の概念がなく、3つの追加機能を同時に実装してしまい、コア機能が埋もれてしまう可能性があります。同時に、新しいバグを修正するたびに、AIは古い機能を振り返らず、Aを直してBを壊すという回帰問題が頻繁に発生します。まとめると以下の通りです。

スコープクリープ：AIは「ユーザーを満足させる」ために、関連しているように見えるが必須ではない機能（例：電卓に履歴機能を追加）を積極的に追加します。
機能退行：AIが特定のバグを修正する際、全体のロジックを理解していないため、共通関数を変更し、それに依存する他の機能が異常になることがあります。

五、チーム協力の落とし穴

Vibe Codingの会話プロセスは個人とAIのプライベートな対話であり、伝達可能な仕様書や設計決定の記録は残りません。異なるチームメンバーがそれぞれAIと対話すると、各自のスタイルのコードが得られ、マージ時に多数の衝突が発生します。さらに、AIは自動的にコミットメッセージや変更ログを生成しないため、コードの進化の理由が失われ、後の保守担当者は推測するしかありません。まとめると以下の通りです。

再現不可能なビルド：異なる人、異なる時間に同じプロンプトを使用しても、AIは異なる実装を出力します（サンプリングのランダム性のため）。
変更追跡の欠如：設計ドキュメントがなく、コミットメッセージも「なぜ変更したのか」を説明しないため、コードはブラックボックスになります。