背景
昨今仕様駆動開発が自分の観測する範囲で増えてきています。AI生成のコードが増えと、レビューがボトルネックになるため、コードレビューのウェイトを減らしていこうという風潮もあるのかなと感じています。
例に漏れず私のチームでも仕様駆動開発しており、1週間前に書いたフロントエンドのコードの記憶がない（初見のコードかと思ったらコミット履歴が自分だった）なんてことも増えてきました。これは一定仕方のないことだと思っています。
一方で、これによる問題も出てきています。既存のシステムだと今はまだ過去の貯金でコードベースを把握できているのですが、今後新規機能追加、新規サービスの開発などしていく上で、コードベースの理解がないと確かな判断ができなくなってしまうのではないかと懸念しています。
とはいえ、じゃあAIじゃなくて自分の手で書こうとはならないですし、コードをのんびり読んでる時間もないので、AIにコードベースを探索させ、理解しやすいドキュメントを作ってもらうとかそういう工夫が必要になるのかなと思っています。
聞きたいこと
みなさんはこの問題についてどう向き合ってますか？また、実践しているアプローチがあれば教えてください。
回答4件
#2
総合スコア12448
投稿2026/07/09 01:35
編集2026/07/09 02:01仕様駆動開発
なるものを全く知らないので，以下，多分に的外れなんでしょうけど……
この単語でググった感じだと，どうにも
ドキュメント
なるもの（：仕様）を 真っ先に 他のやり方とは比較にならんレベルできちんと詳細且つ誤読不能な形に用意して，それを唯一の正解とする，という話に見えます．
だとしたら
AIにコードベースを探索させ、理解しやすいドキュメントを作ってもらう
というのでは，（現在のコードの状態を正として→そこから何かしらの仕様情報を得ようとする，という話になりそうなので）やっていることと真逆の方向ではないのでしょうか？
「仕様駆動開発」という（素人目には夢物語のような）話によれば，とにかく 正解/情報源 として参照すべきは常に「何らかの形式で完璧に用意されている仕様ドキュメントのみだぞ！」ということになりそうなので，であれば，機能追加等々の仕様変更に際しては，現在のコードの状態etc なんてものは完全に無視すべき事柄なのではないでしょうか．
（新しい仕様を作りさえすれば，どうせあとはAIにやらせるっていう話みたいですし，影響範囲のコードは全部捨てれば良いのでは？）
それはそれとして， 理解/把握 のために必要な要素として挙げられていると見える｛レビュー，自分の手で書く｝についてはやりたくない，というのが根底の大前提としてある様子ですから，であれば，これはもう「理解/把握 しない」という方向に徹底的に舵を切るしかないのでは．
#3
（：仕様）を 真っ先に 他のやり方とは比較にならんレベルできちんと詳細且つ誤読不能な形に用意して，それを唯一の正解とする
どうやら唯一の正解（SSoT）はコード側のようで、というのもスペックと言われる仕様が必ずしもコードと整合が取れている保証もなければ、AIの確率的な出力もあるためのようです。
なので、自分としてはコードの理解はしたい、するべきと思っているのですが、作る時にはコードレベルでの実装を追うのが大変で（Specファイルのレビューだったり、AIエージェントとの対話だったり）、その解決策としてコードから人間理解用のドキュメントを起こすのがいいのかなと思っている次第です・・！
ちなみに、自分は会社がそういうやり方をとっているのでAI開発していますが、個人的には従来の開発の仕方の方がエンジニアとしては理想的だった思想です（AIの波は抗えないなと思っています）
#4
総合スコア1483
投稿2026/07/11 04:39
まずは、仕様に漏れや矛盾がないことをレビューで確認するのが最初のステップとして必須だと思います。
AIが吐いた大量のコードを人間がレビューするのは無理があるので、AI自身にレビューさせるしかないでしょうね。
レビューの観点を変えながら何回もレビューさせると信頼できる結果が得られるのではないでしょうか。
人間はそのレビュー結果をレビューしてAIがちゃんと働いていることを監視・改善するような運用になっていくのではないかと感じています。
あなたの回答
tips
プレビュー