仕様が消滅する恐怖
深夜2時、突如として発生した本番環境のクリティカルな障害。ログを追い、スタックトレースを解析し、ようやく該当箇所に辿り着いたものの、そこにあるのはAIが生成したと思われる、文脈を欠いたスパゲッティコードの山。なぜこのロジックが採用されたのか、なぜこのエッジケースを考慮していないのか。開発者に聞こうにも、その開発者はAIのプロンプトを叩いて「動くもの」を量産しただけで、実装の意図など微塵も覚えていない――。これが、現代のAI開発現場で頻発している「仕様の蒸発」という名のデッドロックです。
AIの進化により、コーディングのハードルは劇的に下がりました。いわゆる「バイブコーディング」で、プログラミング言語の深い知識がなくとも、それっぽいプロダクトが数時間で完成する。これは素晴らしい民主化ですが、同時に「プロダクトのインフレ」を招いています。しかし、エンジニアとして私が最も懸念するのは、コードの量ではなく「コードの寿命」です。AIが生成したコードは、生成された瞬間がピークであり、そこから先は負債として積み上がる一方です。なぜなら、そのコードの背後にある「なぜ(Why)」が、誰の脳内にも、そしてドキュメントにも存在しないからです。
かつては「面倒だから」という理由で省略されていたドキュメント作成ですが、今やAIという強力な武器があります。AIに仕様書を書かせ、設計書を生成させる。このプロセスを省略することは、もはや「忙しいから」という言い訳では済まされません。むしろ、AIを使いこなしてドキュメントを自動生成し、それをGitで管理することこそが、現代のエンジニアに求められる「保守性の担保」という名の防衛線なのです。仕様が言語化されていないプロダクトは、コードという名の「ブラックボックス」を抱えた時限爆弾に他なりません。
AIと共創する設計プロセス
では、具体的にどうすれば「AI時代のドキュメント駆動開発」を実務に落とし込めるのか。私が推奨するのは、まずdocsディレクトリを聖域化することです。開発の第一歩はコードを書くことではなく、product.mdという名の「プロダクトの憲法」をAIと対話しながら書き上げることです。ここで重要なのは、最初から完璧を目指さないこと。まずは「何ができるのか」「誰のための機能か」「コアとなる技術スタックは何か」といった大雑把なメモをAIに投げ、それをフォーマット化させます。この往復作業こそが、エンジニアとしての「思考の整理」そのものです。
設計ドキュメントへの展開も同様です。FE、DB、UI、BEの各レイヤーにおいて、AIに設計書を書き起こさせ、そこに潜む論理的な矛盾や、アーキテクチャ上のボトルネックを人間がレビューする。この「AIが書き、人間が判断する」というループこそが、設計の質を担保します。特にモノレポ構成を採用することで、設計と実装の距離を物理的に縮め、CLAUDE.mdのようなコンテキストファイルを活用してAIに常に最新の仕様を認識させる運用が極めて有効です。
以下の表は、AIドキュメント駆動開発における「従来の開発」との比較です。このコスト構造の変化を理解することが、プロジェクトの成否を分けます。
| 項目 | 従来の開発 | AIドキュメント駆動開発 |
|---|---|---|
| 仕様策定 | 人力で膨大な工数 | AIとの対話で高速化 |
| 設計の鮮度 | 陳腐化しやすい | Git管理でコードと同期 |
| オンボーディング | 口頭伝承が主 | ドキュメントで完結 |
| 手戻りリスク | 設計ミスが致命的 | 設計段階でAIと検証可能 |
もちろん、この手法にはコストも伴います。思いついた瞬間にコードを書き始めるスピード感は、ある程度犠牲になります。しかし、数ヶ月後に「このコード、誰が書いたんだ?」「なぜこの仕様にしたんだ?」と頭を抱える深夜の障害対応を回避できるのであれば、この先行投資は極めて合理的です。探索的なMVP開発には不向きな側面もありますが、長く生き残るプロダクトを目指すのであれば、この「言語化」のプロセスをスキップする選択肢は、プロフェッショナルとして取るべきではありません。
エンジニアへの痛烈な問い
最後に、我々エンジニアに突きつけられた現実について考えたいと思います。AIがコードを書く時代において、我々の価値は「コードを書くこと」から「コードの意図を定義し、管理すること」へとシフトしています。もしあなたが、AIにコードを書かせて満足し、その背後にある仕様をドキュメントとして残していないのであれば、あなたは単なる「AIのオペレーター」に過ぎません。それはエンジニアリングではなく、ただの「コードの使い捨て」です。
プロダクトのインフレが加速する中で、生き残るのは「最も速く作られたもの」ではありません。仕様が明確で、誰が引き継いでも改修可能な「最も正しく残されたもの」です。あなたは明日から、AIにコードを生成させる前に、そのコードがなぜ必要なのか、どのような設計思想に基づいているのかを、AIと共に言語化する時間を確保できますか?そして、そのドキュメントをコードと同じリポジトリで、同じ熱量で管理し続ける覚悟はありますか?
「動くもの」を作るのはAIでもできます。しかし、「生き続けられるもの」を作るのは、依然として人間の役割です。AI時代において、ドキュメントは単なる記録ではなく、プロダクトの生存権そのものです。あなたが今日書いたコードは、半年後の自分を救うための「遺言」になり得ますか?それとも、ただの負債として積み上げられますか?この問いに対する答えが、あなたのエンジニアとしてのキャリアの寿命を決定づけることになるでしょう。


コメント