バイブコーディングの「70%の壁」を
突破する5つの方法
あなたもこれを経験していませんか？
- AIの提案を試すたびに別の場所が壊れる
- 同じエラーが繰り返し出て、AIの解決策がループしている
- 最初はスムーズだったのに急に進まなくなった
- コードが複雑になってきて、AIが何をしているのか分からない
これが「70%の壁」です。
なぜ70%で止まるのか？
70%の壁の根本原因は「AIのコンテキストウィンドウの限界」です。 開発初期は全コードが数百〜数千行で、AIが全体を把握できます。 しかしコードベースが大きくなると、AIが一度に処理できる情報量（コンテキストウィンドウ）を超え、 全体像を見失った状態でコードを変更するようになります。
その結果「この変更は正しいが、他のファイルとの整合性が取れていない」という状態が増えていきます。 これは開発者の能力の問題ではなく、現在のLLMの技術的制約です。 理解した上で、この制約を回避する開発スタイルに切り替えることが解決策です。
5つの突破方法
1. 変更対象ファイルを1〜2個に絞る
AIへの1回の指示で変更するファイルを最大2個に制限します。「全体的にリファクタリングして」という指示は最悪です。「src/components/ShiftCard.tsx のこの部分だけを変更して」という形に分解することで、AIが既存コードを壊す確率が劇的に下がります。
2. コンテキストを明示的に渡す
AIは会話の文脈を忘れます。新しい会話を始めるときや、関連するファイルが複数あるとき、必要なコードを明示的に貼り付けて渡します。「前の会話で作ったコードを修正して」は機能しません。「以下のコードを修正して：[コード]」の形にします。
3. 差分指示に切り替える
「この機能を追加して」という指示より「このコードのXX行目からYY行目を、以下のように変更して」という差分指示の方が、既存コードへの影響が最小化されます。変更後のコードだけでなく「何を変えるか」を明示することが重要です。
4. 型情報を活用したデバッグ
TypeScriptを使っている場合、型エラーはAIへの強力なフィードバックになります。「型エラーが出ています：[エラー全文]」とそのまま渡すことで、AIは型の不整合を自己修正できます。JavaScriptよりTypeScriptの方がバイブコーディングに適している理由の一つです。
5. 小さくコミットして退路を確保する
Gitを使って、動く状態になったら必ずコミットします。AIが大きく壊してしまっても `git reset --hard` で戻れます。「試して壊れたら戻す」サイクルを高速で回せることがバイブコーディングの強みです。コミット頻度は従来の開発より高くすることを推奨します。
実際にShiftMatchで試した効果
筆者がShiftMatch開発で70%の壁に直面したとき、これらの方法を組み合わせて突破しました。 特に効果的だったのは「変更対象ファイルを1〜2個に絞る」と「差分指示」の組み合わせです。
詳しくはShiftMatch開発全プロセス記事で開発中の実際のAIとのやり取りを含めて解説しています。