概要
https://zenn.dev/flinters_blog/articles/25ffbe3c511967
詳細内容
## AIに「仕様書」を読ませたら、レビューの質が爆上がりする？
https://zenn.dev/flinters_blog/articles/25ffbe3c511967
仕様駆動開発で作成した仕様書をAIコードレビューのプロンプトに加えることで、AIレビューの質が機能仕様レベルで飛躍的に向上すると提案します。
**Content Type**: ⚙️ Tools
**Language**: ja
**Scores**: Signal:4/5 | Depth:3/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 81/100 | **Annex Potential**: 80/100 | **Overall**: 80/100
**Topics**: [[AIコードレビュー, 仕様駆動開発, プロンプトエンジニアリング, 開発ワークフロー改善, AI活用]]
FLINTERSの新卒エンジニアである野崎氏が、社内LT会で発表した「仕様駆動開発でAIレビューを強化する」というアイデアと、その後のアップデートについて解説しています。
同氏のチームは現在、仕様書を唯一の信頼できる情報源（Single Source of Truth）とする仕様駆動開発（SDD）を導入しており、Spec kitやOpenspecのようなツールで機能仕様書（spec.md）を生成しています。通常、これらの仕様書はAIがコードを生成するために参照されますが、筆者はこれをAIがコードを「レビューする」際にも活用できないかと考えました。
現在のAIレビューは、技術的な正しさ（バグ、パフォーマンス、セキュリティ）やリポジトリのルール（命名規則、コーディング規約）に関しては高い精度で指摘できます。しかし、「このコードがそもそも仕様通りに正しく動くか」という機能仕様に関する観点が見落とされがちです。これは、コードを生成するAIがセッションのコンテキストとして仕様書をインプットされる一方、コードをレビューするAIが別のセッションで呼び出されるため、その機能の「意図」（＝仕様書）を知らないことが原因だと筆者は指摘します。
この課題を解決するため、筆者はAIレビューのプロンプトにSDDプロセスで作成されるspec.mdを追加で読み込ませるというシンプルなアプローチを提案。これにより、AIレビュー担当者は、一般的な正しさしか判断できない「外部コンサルタント」から、プロジェクトの背景や機能の意図まで理解した「頼れるチームメンバー」へと進化すると主張しています。実際に試したところ、「仕様書ではこう定義されていますが、この実装ではそのケースが考慮されていません」といった、仕様に対する過不足をAIが指摘するようになり、好感触を得ているとのことです。
筆者は、SDDのフローで生成される仕様書は一度コードを生成したら終わりではなく、コードレビュー、テスト、将来のドキュメント更新など、開発ライフサイクルのあらゆる場面で再利用できる「資産」であると強調します。AIとの協業が当たり前になるこれからの時代において、「仕様」という共通言語をチームの資産として蓄積し活用する文化こそが、開発の質を本質的に高める鍵となるだろうと締めくくっています。