コーディングエージェントが浮き彫りにする「仕様を後回しにする開発」の弱点

日本のソフトウェア開発では、上流工程で十分に仕様を文書化せず、打ち合わせや口頭での説明、担当者間の認識に依存したまま開発を進め、納品時になって実装結果に合わせてドキュメントを整備するという開発が、以前から問題として存在してきました。

もちろん、すべての開発会社や開発現場がそうであるということではありません。しかし現在でも、仕様の詳細が担当者の頭の中にしか存在しなかったり、実装を進めながら仕様を決めたり、最後に実装されたものを基に設計書や仕様書を作成したりする開発は存在します。

これまでは、このような方法でも開発を成立させることができました。

経験のあるエンジニアであれば、顧客との打ち合わせ、過去の経緯、既存システム、ソースコード、業務知識などから、文書に書かれていない部分をある程度推測できます。

「前回と同じ」
「ここは通常こうする」
「この業務なら、この処理が必要になる」

そのような暗黙知を人間同士で補完しながら、システムを作ることができたからです。

しかし、コーディングエージェントが実装の一部、あるいは大きな部分を担うようになると、この開発方法そのものが大きな弱点になります。

AIにとって、伝えられていない仕様は存在しない

コーディングエージェントは、与えられた指示やドキュメント、既存のソースコードなどを基に実装します。

そのため、担当者の頭の中にしか存在しない仕様や、打ち合わせの場だけで共有された前提条件を、当然のこととして理解してくれるわけではありません。

AIに実装を任せるためには、単に「この機能を作ってほしい」と伝えるだけでは不十分です。

• 何を実現するのか。
• なぜその機能が必要なのか。
• 何を入力し、何を出力するのか。
• どのような条件で処理するのか。
• 何をしてはいけないのか。
• 既存システムとの整合性をどう保つのか。
• 異常が発生した場合にはどうするのか。
• 何をもって完成と判断するのか。

こうした要求、制約、設計上の意図、受入条件などを明確にする必要があります。

そして、ここにはもう一つ注意すべき問題があります。

仕様が曖昧でも、AIはコードを書けてしまう

コーディングエージェントの難しさは、仕様が不十分だからといって、必ずしも作業を止めてくれるわけではないことです。

与えられた情報や既存コードなどから不足している部分を推測し、それらしい実装を生成することがあります。

• そのコードはコンパイルできるかもしれません。
• 画面も正常に表示されるかもしれません。
• 用意されたテストにも通るかもしれません。

しかし、それが「本来作るべきもの」であるとは限りません。

要求が曖昧なまま実装速度だけが上がれば、正しいものを速く作れるだけでなく、間違ったものを速く作ることも可能になります。

コーディングエージェントによって実装速度が大きく向上するほど、この問題は無視できなくなります。

「コードを書く時間」が設計を考える時間でもあった

人間が一行ずつコードを書いていた開発では、実装そのものにも一定の時間が必要でした。

そして、その時間の中で、

「この条件の場合はどうするのか」
「このデータが存在しなかったらどうなるのか」
「既存機能に影響しないか」

といったことを考えながら実装していました。

つまり、コードを書く時間の一部は、実質的に設計を考える時間でもありました。

ところがコーディングエージェントは、数百行、場合によってはそれ以上のコードを短時間で生成します。

実装工程が短縮されること自体は大きな利点ですが、それまで実装過程の中に含まれていた「考える時間」まで一緒に短縮してよいわけではありません。

むしろ実装が速くなるほど、その前段階で、

• 要求を整理する。
• 要件を定義する。
• 仕様を明確にする。
• 制約条件を確認する。
• データ構造を考える。
• インターフェースを定義する。
• 受入条件を決める。

といった作業の重要性が高まります。

ドキュメントは「納品物」から「開発の入力」へ

これは、昔のような分厚い仕様書を大量に作成すべきだ、という話ではありません。

重要なのはドキュメントの量ではなく、その役割です。

従来の開発では、ドキュメントが「納品時に必要なもの」として扱われることがありました。

実装を先に進め、最後に完成したシステムに合わせて仕様書や設計書を整える。

この方法では、ドキュメントは実装結果を説明するための記録になります。

しかし、コーディングエージェントを活用する開発では、この関係を逆にする必要があります。

ドキュメントを最後に作るのではなく、ドキュメントを入力としてコードを作る。

要求、仕様、制約、設計方針などを人間とAIが共有し、それを基に実装する。

そして、出来上がったものが正しいかどうかも、最初に定義した仕様や受入条件を基準として確認する。

ドキュメントは単なる納品物ではなく、開発そのものを制御するための情報になります。

AI時代ほど上流工程が重要になる

コーディングエージェントが進化すると、「プログラムを書く」という作業の多くは、これまでより短時間で行えるようになります。

だからといって、ソフトウェア開発そのものが単純になるわけではありません。

むしろ重要になるのは、

「どう作るか」よりも、「何を作るべきか」を明確にすることです。

• 顧客が必要としているものは何か。
• その業務にはどのような制約があるのか。
• どこまでをシステム化するのか。
• どのような状態になれば完成なのか。

これらを整理し、曖昧な要求を実装可能な仕様へ落とし込む作業は、AIがコードを書けるようになったからといって不要になるものではありません。

むしろ、コードを書く速度が上がるほど、その重要性は高まります。

これまで人間の経験や暗黙知によって補うことができた「仕様を後回しにする開発」は、コーディングエージェント時代には大きなリスクになります。

AIによって「コードを書く力」の希少性が相対的に下がっていく一方で、「作るべきものを定義する力」の価値は高まっていくと考えられます。

コーディングエージェント時代に必要なのは、単純にドキュメントを増やすことではありません。

コードを書くために必要な情報を、コードを書く前に明確にすること。

AIを活用したソフトウェア開発では、この当たり前ともいえる開発工程を、これまで以上に大切にする必要があると考えています。