こんにちは、FLINTERS新卒エンジニアの野崎です。
先日、社内で開催された「AI強化会」というLT会で、「仕様駆動開発でAIレビューを強化したい」というテーマで登壇させていただきました 。
今回は、そのLTでお話しした内容と、その後のアップデートも踏まえて、登壇内容をブログとしてご紹介させていただきます。
「仕様書」というドキュメントの可能性
現在、私のチームでは仕様駆動開発（SDD）の導入を進めています。
SDDとは、「仕様書を唯一の信頼できる情報源（Single Source of Truth）とする」開発手法です 。
導入にあたり、Spec kitやOpenspecといった様々な仕様駆動開発支援ツールを調査していました。（ちなみにチームでは、色々と検討した結果、Openspecを導入することに決まりました。）
これらのツールは、開発プロセスの中でAIとの対話を通じてspec.md（機能の仕様書）のような、「その機能が何をすべきか」を定義したドキュメントを生成します 。
この「仕様書」は、本来AIがコードを"作る"ために参照するものです。私はこの開発プロセスを学ぶ中で、『この仕様書を、実装以外の目的にも活用できないか？』 と考えるようになりました 。
そこで思い至ったのが、『AIがコードを"レビューする"時にもこの仕様書を読ませたら、もっと本質的なレビューをしてくれるんじゃないか？』というアイデアです 。
この「気づき」が、今回のLTの核心的なアイデアとなりました。
AIレビューの「現在地」と「伸びしろ」
このアイデアについて考えるために、まず「AIレビューの現在地」を整理しました 。
私たちが現在使っているAIレビューも、（偉大な先達の方々が作ってくれたプロンプトのおかげで）すでに非常に優秀です。
AIは、
- 技術的な正しさ（バグ、パフォーマンス、セキュリティなど）
- リポジトリのルール（命名規則、コーディング規約など）
の2点については、高い精度で指摘してくれます 。
しかし、もう一つの重要な観点である 「機能仕様」、つまり「このコードが、そもそも"仕様"通りに正しく動くか？」という点については、現在のレビュープロセスではAIの観点から抜け落ちがちな気がしていました 。
これはAIの能力が低いからではなく、レビューのプロセスに原因があります。
開発の現場では、コードを書く人（Author）とレビューする人（Reviewer）が分かれています。これはAIエージェントを使った開発でも同じです。
コードを"作る"（生成する）AIは、そのセッションのコンテキストとして仕様書の情報をインプットされます。しかし、そのコードを"レビューする"AIは、全く別のセッションで呼び出されることが多いため、「その機能が何を実現したかったのか」という"意図"（＝仕様書）を知らないのです。
その結果、AIレビューは「機能仕様に合っているか」という最も重要な観点を考慮することが難しくなってしまう。これが、私の見つけたAIレビューの「伸びしろ」です。
AIに仕様書を読ませてみる
そこで、私の提案は非常にシンプルです。
「AIレビューのプロンプトに、SDDのプロセスで作られるspec.md（機能仕様書）を追加で読み込ませよう」
上記をレビュー用プロンプトファイルに追加してみる
これにより、これまで「？」だった 「機能仕様」 との整合性もチェックしてもらう、というわけです 。
こうすることで、AIレビュー担当者は、一般的な正しさしか判断できなかった「外部コンサルタント」から、プロジェクトの背景や機能の意図まで理解した「頼れるチームメンバー」へと進化してくれるのではないかと考えています。
実際にこのアプローチを試してみたところ、今のところ好感触です。 レビューの中で「仕様書ではこう定義されていますが、この実装ではそのケースが考慮されていません」といった、仕様に対する過不足をAIが指摘してくれるようになったと感じています。
仕様書は「資産」である
仕様駆動開発のツールを調査したことで得られた最大の気づきは、「仕様駆動開発のメリットは、実装段階の効率化だけじゃない」ということでした。
SDDのフローで生成されるspec.mdのようなドキュメント群は、一度コードを生成したら終わり、という使い捨てのものではありません。
これらは、コードレビュー、テスト、将来のドキュメント更新など、開発ライフサイクルのあらゆる場面で再利用できる、まさに「資産」です 。
AIとの協業が当たり前になるこれからの時代、こうした「仕様」という名の共通言語をチームの資産として蓄積し、活用していくていく文化こそが、開発の質を本質的に高めていく鍵になるのではないかと感じています。
新卒としてまだまだ学ぶことばかりですが、こうした「AIをどう活用すればチームがもっと良くなるか」という視点を持ち続け、これからも色々試していきたいと思います。
Discussion
とても、興味深い記事です。
気になるのは、AIはリファレンスがあってそれに足りていないものは的確に見つけてくれるけど、機能とか仕様のヌケ・モレを見つけるのは、あまり得意でない気がします。
それと、AI向けの仕様書はとても回りくどいものにはならないですかね。
ごくごく当たり前の部分は、仕様書に記述しないことが多いので。
結果には、非常に興味があります。
ぜひ引き続き紹介いただけたらと思います。
コメントいただきありがとうございます！
仕様駆動開発（今回の記事ではSpec kitやOpenspecをイメージしています）の最初の段階である仕様書を作る段階の時点でどれだけ内容を詰め、良い仕様書を作ることができるかによってレビューの質も変わってくるように感じています。
当たり前の部分をどこまで記述するかは確かに課題に感じています。現状のフローでは、AIとの対話を通じて仕様を明確にしていくプロセスなので、人間にとっても明確な仕様書が作られている感覚ですが、ご指摘の点は意識し続ける必要がありそうです。 また、作業途中で仕様変更が発生した場合にspec.mdと実装とレビューの足並みをどう揃えるかなど、作業フロー自体の見直しや改善は必要そうだと感じています。
結果に興味を持っていただき、とても嬉しいです。 この取り組みはまだ始めたばかりなので、今後も継続して使っていく中でわかったことやより良い使い方などがあれば、引き続き発信していきたいと考えています。 これからも頑張ってまいります！🙇♂️
仕様書の2次利用として、生成AIに読ませて説明書やヘルプを造れないかと考えていたことは有ります。いけそうな感触はあるのですが、まだ実践投入はしたことないです。