バイブコーディングは、開発のスピードを大きく変えました。Claude Code や Codex などに「この機能を作って」「ここを直して」と頼めば、数分で実装が進みます。しかし、便利さの裏には見落としやすい危険があります。それは、AI が修正を繰り返すうちに、以前は動いていた実装を静かに壊してしまうことです。
Microsoft の文献（LLMs Corrupt Your Documents When You Delegate）でも、LLM にドキュメントやコードの編集を繰り返し任せると、一定の確率で内容が破壊されることが示されています。しかも、この問題は性能の低いモデルだけで起きるわけではありません。GPT、Claude、Gemini のような高性能モデルでも発生します。むしろ高性能モデルほど、見た目には自然で、すぐには気づきにくい形で意味を変えてしまうことがあります。
特に怖いのは、失敗が少しずつ起きるとは限らない点です。ある修正までは順調に見えても、何度目かの変更で突然、認証処理、API の返却形式、DB スキーマ、設定ファイル、条件分岐などが壊れることがあります。削除のように目立つ失敗なら気づけますが、変数名、数値、条件、JSON、型定義が微妙に変わる「紛れる改ざん」は発見が難しい。
AI には得意不得意があります。Python のように学習データが豊富な領域では比較的安定していても、JSON、DB スキーマ、Graphviz、スプレッドシート、設定ファイルなどでは精度が落ちやすい。長いファイル、散らかったプロジェクト、余計なファイルが多い状態でも、AI の判断は不安定になります。ツールを使った差分編集であっても、必ず安全になるわけではありません。
バイブコーディングでは「AIに書かせる力」だけでなく、「AIの変更を管理する力」が必要です。大きな修正前には必ず Git で commit する。触ってよいファイルと触ってはいけないファイルを明示する。いきなり実装させず、まず変更計画を出させる。既存機能を壊さない条件を毎回伝える。そして lint、型チェック、テストを通す。会話が長くなったら、新しいチャットに仕様を整理して渡す。
AI は優秀な開発者のように見えますが、まだ完全に任せきれる存在ではありません。
バイブコーディングの本質は、ノールックで任せることではなく、AI の速度と人間の監督を組み合わせることにあります。速く作るほど、壊れ方も速くなる。速く作れる時代だからこそ、変更を確認し、守るべき実装を管理する姿勢が欠かせません。AIの速度を活かしながら、人間が要所を監督する。それが、バイブコーディングを安全に使いこなすための基本です。
