Vibe Coding 最大の落とし穴：要件ドリフト

Sun, 14 Jun 2026 23:11:10 +0800

Vibe Coding のリスクを語るとき、多くの人はまずコード品質の低さ、セキュリティホール、保守の難しさを挙げます。どれも実際に起こる問題です。しかし一人で長期プロジェクトを進める場合、より致命的なのは別の問題です。要件ドリフトです。

要件ドリフトは、単一の bug でも、明らかに間違ったコミットでもありません。むしろ、プロジェクトの方向感覚が少しずつ鈍っていく現象です。機能は増え続け、コードは動き、ドキュメントも残っている。それでも、なぜ当初そのようにモジュールを分けたのか、なぜその制約を残したのか、次の変更をどこにつなげるべきなのかを説明できなくなっていきます。

問題は、簡単そうに見える新機能を追加しようとしたときに一気に表面化します。ここを直すと別の場所が壊れる。そこを修正すると今度はこちらが崩れる。AI に何度もパッチ的な修正を頼んだ末に、本当に足りなかったのはコードではなく、自分の中にあるプロジェクト全体の地図だったと気づきます。

長期プロジェクトが漂いやすい理由

Vibe Coding の気持ちよさは速度にあります。曖昧な要望を一言伝えるだけで、AI はすぐにコードを生成します。もう一言補足すれば、そのまま先へ進みます。短いタスクでは非常に効率的ですが、長期プロジェクトでは二つの問題が重なります。

一つ目は、モデルが忘れることです。ここでいう「忘れる」は、文脈が完全に見えなくなるという意味ではありません。長いコンテキストの中で、重要な情報の重みが下がっていくということです。初期のプロダクト目標、アーキテクチャ上の判断、命名規則、境界条件は、対話が長くなるほど、大量のデバッグ情報、一時的な修正、中間状態に埋もれていきます。コンテキストが騒がしくなるほど、モデルは重要な点を取り違えやすくなります。

二つ目は、人間も忘れることです。AI はコードを書く抵抗を大きく下げるため、本来なら立ち止まって考えさせられる過程を飛ばしてしまいます。以前なら、要件が曖昧だと手が止まりました。今は要件が曖昧でも、AI はまず一版を書けます。曖昧な意図が素早くコードに固定され、後から説明するのがどんどん難しくなります。

これが、一人プロジェクトで特に壁にぶつかりやすい理由です。あなたは同時にプロダクトマネージャーであり、開発者であり、テスターであり、運用担当者でもあります。コードを書くときは速く進めたい。一方で、プロダクト判断では「本当に何を作りたいのか」を考えるために速度を落とす必要があります。AI が加速するのは前者であって、後者を代わりにやってくれるわけではありません。

最大の問題は AI の書き間違いではなく、意図の喪失

コードはシステムが何をするかを表せますが、なぜそうしているのかを説明するのは苦手です。

プロジェクトが制御不能になる原因は、特定のコードが極端に悪いことではない場合が多いです。むしろ、意思決定の背後にあった意図が、長い会話、一時的なプロンプト、頭の中の記憶、断片的なコミットに散らばってしまうことが問題です。再びプロジェクトを開いたとき、結果は見えますが、理由は見えません。

この状況では AI もあまり助けになりません。コードを読み、呼び出し関係を追い、テストを追加することはできます。しかし当初のトレードオフを確実に復元することはできません。さらに、現在見えている局所的なコードをもとに誤った方向を「合理化」し、ドリフトを深くしてしまう可能性もあります。

だから Vibe Coding の重要な問いは、「どうすれば AI に永遠に忘れさせないか」ではありません。「プロジェクトの記憶を会話だけに置かないにはどうするか」です。

プロジェクトの記憶をファイルへ移す

要件ドリフトに対抗する最も有効な方法は、意図、制約、状態をリポジトリに残し、毎回の新しいセッションで読み直せるようにすることです。

最も軽い方法は、CLAUDE.md、AGENTS.md、または同種のルールファイルを書くことです。長くする必要はありませんが、次の点は明確にしておきます。

このプロジェクトが解決する問題。
現在最も重要なプロダクト目標。
気軽に変更してはいけないアーキテクチャ上の境界。
命名、ディレクトリ、テスト、リリースの基本ルール。
明確に禁止するやり方。

このファイルの価値は、「より高度なプロンプト」であることではありません。漂いやすい制約を、毎回のセッションの冒頭に固定することに価値があります。短く、安定していて、人間が読める内容にし、一時的な詳細を詰め込みすぎないことが大切です。

次の段階は、仕様駆動で進めることです。AI にいきなり「この機能を作って」と頼むのではなく、まず要件を検証可能な仕様に分解します。

ユーザーシナリオは何か。
入力と出力は何か。
成功条件は何か。
やらないことは何か。
既存のどのモジュールに影響するか。
どのテストや検証が必要か。

仕様は、AI を明確な意図の周りで作業させるためのものです。思いつきの一段落のプロンプトを中心に進めるためのものではありません。一人プロジェクトでは特に重要です。曖昧な考えを明確な要件へ圧縮してくれるプロダクトマネージャーがいないからです。

セッション終了前に引き継ぎを書く

長期プロジェクトを一つの長い会話で最後まで押し切るべきではありません。会話が長くなるほどデバッグのノイズが増え、判断の質が落ちやすくなります。

より安定したやり方は、作業を終える前に状態をファイルへ書くことです。たとえば PROGRESS.md、TODO.md、またはタスクログです。

今回完了したこと。
変更した重要なファイル。
まだ解決していない問題。
次回どこから始めるべきか。
壊してはいけない現在の制約。

そのうえでコードをコミットします。次に新しいセッションを開いたとき、AI は長いチャット履歴からプロジェクト状態を推測する必要がありません。リポジトリ内の引き継ぎ資料を直接読めます。

地味に見えますが、効果があります。記憶を、漂いやすい会話から、バージョン管理できるファイルシステムへ移すからです。

立ち止まって整理すべきタイミング

次のような兆候があるなら、新機能の生成を止め、まずプロジェクトを整理するべきです。

同じ問題を何度も直しているのに、別の場所で再発する。
AI がタスクと関係のないモジュールを頻繁に変更する。
あるディレクトリ、インターフェース、状態フィールドがなぜ存在するのか説明できない。
新機能が明確な設計ではなく、パッチに依存するようになっている。
ドキュメント、コード、実際の動作が互いに合わなくなっている。
プロジェクト状態を取り戻すのに長い時間がかかる。

この状態で Vibe Coding を続けると、混乱がさらに積み上がります。よりよい順序は、まずプロジェクトの地図を補修し、その後でコードを書くことです。モジュール説明を整理し、仕様を追加し、放置された経路を削除し、テストを補い、重要な判断を ADR や短い設計メモとして残します。

一人プロジェクトで本当に守るべきもの

AI はコードを書き、bug を調べ、テストを追加し、局所的な実装をリファクタリングできます。しかし、長期にわたってプロダクトの意図を保持することはできません。

一人でプロジェクトを進めるときに守るべきものは、「毎回 AI にもう少し多く書かせること」ではありません。そのプロダクトがなぜ存在するのか、次にその作業をする理由は何か、どの境界は譲れないのかを、自分が常に理解していることです。そこが明確である限り、AI は加速器です。そこが漂い始めると、AI はずれをより速く広げるだけです。

だから Vibe Coding で最も大切な習慣は、完璧なプロンプトを追い求めることではありません。要件、進捗、制約、意思決定を定期的にリポジトリへ書き戻すことです。会話は速くてかまいません。プロジェクトの記憶は安定していなければなりません。

元記事リンク：

Zhihu: https://www.zhihu.com/question/2006474721647157414/answer/2041532900202508861