バイブコーディング・ラビリンス―複数プロジェクト並走で学んだ3つの失敗
ITエンジニアでもない。何者でもない。そんな初心者仲間に向けて書く。
直近、複数プロジェクトを同時並行で進めた。使ったツールはGoogle AI Pro、Kiro、Claude Code、Claude、Gemini。快適に動いている時期もあったが、気づけばラビリンスにいた。同じ轍を踏まないでほしいので残しておく。
1. 3回指示して治らないバグは、セカンドオピニオンを取れ
プロジェクトが小さいうちは大抵うまくいく。問題はコードベースが育ってきてからだ。ユースケースが増え、バグが出る。AIに「このバグを直して」と投げる。直ったように見えて別のところが壊れる。また投げる。また壊れる。
これがラビリンスの入り口で、本質はハルシネーションとの戦いだ。
抜け出す方法として有効だったのは2つ。
コードを自分で読んで、原因のあたりをつける。 どのファイルのどのロジックが怪しいか、ある程度絞り込んでから指示する。「このファイルのこの関数が原因だと思うので直して」という形にするだけで、的外れな修正が明らかに減る。
別のモデルに聞く。 同じAIに同じ文脈で何度も聞いても、出てくる答えは似たり寄ったりになりがちだ。ClaudeでハマったらGeminiへ。GeminiでハマったらClaudeへ。視点が変わるだけで一発で解決することがある。
3回同じバグと戦っているなら、やり方を変えるタイミングだ。
2. 修正範囲を明示し、サイドエフェクトの仮説を自分で持つ
「〇〇の機能を修正して」とざっくり指示を投げていないか。これも危ない。
AIは指示されていない箇所も平気で書き換える。気まぐれではなく、「より良くしようとした結果」なのだが、こちらからすれば想定外の変更だ。修正してほしくないファイルが変わっていて、別のバグが生まれる。
対策の基本は CLAUDE.md などのルールファイルに「修正箇所以外は触らない」と書いておくこと。ただしこれだけではロジック上のサイドエフェクトは防ぎきれない。
そこで有効なのが、自分の仮説を指示に添えることだ。「この修正って〇〇の機能と競合しない？」という一言でいい。AIはその観点を考慮した上で答えを返してくれる。自分で仮説を立てる分、トークン消費も減る。AIに全部考えさせるより、人間が論点を絞って投げるほうが効率がいい。
3. 仕様書なしの開発は、後半に必ずツケが来る
バイブコーディングの魅力はものができていく快感をすぐに味わえることだ。要件定義も設計もすっ飛ばして、とにかく動くものが出来上がる。
が、これもラビリンスの入り口だ。
行き当たりばったりで進めた開発は、後半になるほど苦しくなる。似た処理をする関数が各所に散乱し、ロジックは例外処理だらけになり、新機能を足すたびにどこかが壊れる。なぜエンジニアが要件定義から入るのか、身をもって理解した。
仕様書を自分でゼロから書く必要はない。AIと対話しながら作ればいい。「こういうアプリを作りたい。仕様書のドラフトを作って」と投げるだけで叩き台は出てくる。
最近導入した Kiro はこのあたりが特に優秀で、対話の中で要件・設計・タスクの分解まで自動でドキュメント化してくれる。ゴーストのアイコンも可愛い。
仕様書があれば、AIへの指示精度が上がり、別モデルへの引き継ぎも楽になり、リファクタリングコストが下がる。後から効いてくる投資だ。
バイブコーディングは確かに速い。ただ、ラビリンスに迷い込むポイントもある。一緒に学んでいこう。