なぜ今、「仕様書」が復権するのか
少し前までの開発現場では、仕様書の地位は決して高くありませんでした。「仕様書より動くコード」という言葉に象徴されるように、重厚な仕様書は『遅い開発』の象徴のように扱われてきた時期もあります。
ところがAIの登場で風向きが変わりつつあります。理由はシンプルで、AIは仕様書を読んで動くからです。人間の開発者なら文脈を察して空白を埋めてくれましたが、AIは書かれていることに忠実で、書かれていないところは自分で解釈して埋める。仕様書の解像度が、そのままアウトプットの精度になるのです。
「察してもらう」発想の限界
日本の開発現場には、「察してもらう」文化が根強く残っています。「これくらいは分かるでしょう」という暗黙の合意が、チーム内の阿吽の呼吸として機能してきました。
問題はAIがこの「察する」を一切しないこと。書かれた指示を書かれたとおりに実行し、曖昧な部分は自分なりに解釈して埋めます。AI時代は「察してもらう」文化から「書き切る」文化へのシフトが避けられません。これはコミュニケーションの質を落とすことではなく、AIという新しいチームメンバーに合わせた言語を持つということです。
仕様駆動開発（Spec-Driven Development）とは何か
仕様駆動開発を一言で説明するなら、仕様書を開発の中心に据え、コードもテストもそこから派生させる考え方です。
従来の流れは「仕様書 → コード → テスト」でしたが、実態は「コードを書きながら仕様を確定させる」「テストは後付け」が多かった。仕様駆動開発では、仕様書が開発全体の起点になります。仕様書からAIへのプロンプトが生成され、仕様書からテストケースが導出され、仕様書の更新がコード変更のトリガーになる。
ウォーターフォールとの違いは、仕様書が固定ではないこと。プロジェクト進行とともに育てていきます。アジャイルの対立概念ではなく、アジャイルの精度を上げる補強策として機能します。
AI時代の要件定義書に書くべき4つの要素
要素1：機能要件と非機能要件の境界——機能要件は「何をするか」、非機能要件は「どう動くべきか」。「商品を検索できる」が機能要件なら、「3秒以内に結果を返す」「1万人同時アクセスに耐える」が非機能要件です。AIは機能要件に引っ張られる性質があるため、動き方・使い勝手の要件を明示することが重要です。
要素2：期待する振る舞いとエッジケース——「入力が空のとき」「最大値を超えたとき」「同時アクセスがあったとき」など、起こりうるケースを列挙。正常系の例しか与えないと、生成コードも正常系中心になります。
要素3：禁止事項・やらないことリスト——解像度を一気に上げる最強ポイント。「この画面では決済機能は扱わない」「このモジュールからはデータベースに直接アクセスしない」など。社内ルールの「やってはいけないことリスト」を開発でも作るイメージです。
要素4：テスト可能な受け入れ条件——「使いやすいUI」ではなく「3クリック以内で目的の画面に到達できる」のように、誰が見ても同じ判定ができる条件で書きます。「〜の状態で、〜をしたら、〜になる」という型が便利です。
要件定義書が「テストにもプロンプトにも効く」理由
4要素で書かれた要件定義書には、テストコードとAIプロンプトの共通の源泉になるという副次効果があります。
「〜の状態で、〜をしたら、〜になる」という形式は、そのまま自動チェックの仕組みに落とせる。同時に同じ要件定義書からAIプロンプトも生成できる。要件定義書は、品質四象限の象限①を固めるだけでなく、象限②（テスト）と象限③（プロンプト）に血液を送る動脈でもあるのです。
Galactic Brain の実務での運用例
参考までに、Galactic Brainでの実際の運用をお伝えします。要件定義書は、チームで共有し改訂履歴が見える形で管理しています（業界ではGitと呼ばれるツールで実現）。仕様書はAIに「前提知識」として読み込ませる仕組みに載せ、コード生成時に必ず参照される状態にしておきます。
このとき、仕様書に対しても「レビュー」を走らせます。コードだけでなく仕様書をレビューする文化を作ることで、解像度の低い部分が早期に発見されます。完璧な方法ではありませんが、従来の「コード中心・仕様書は参考資料」という運用よりも、手戻りが明らかに減りました。
明日から始められる3ステップ
ステップ1：既存の要件定義書を1本、4要素でチェックする——「機能/非機能の境界」「エッジケース」「やらないこと」「テスト可能な条件」が書かれているかチェック。最初の3つは抜けているはずです。
ステップ2：欠けている要素を1つだけ書き足してみる——全部を一気に整えようとしない。まず「やらないこと」だけ書き足してみる。これだけで仕様の輪郭がぐっと立ち上がります。
ステップ3：次の案件から、仕様書をAIに渡す前に4要素チェックを通す——新しい案件で仕様書ができたら、AIに渡す前に4要素のチェックをルーチン化する。これが組織としての仕様駆動開発の第一歩です。
まとめ — 導入前と導入後の風景
Before（導入前）：要件は「雰囲気」で共有される。AIに渡すプロンプトも個人の解釈で書かれる。コードは動くが「これで合っていますか？」と聞くと誰も答えられない。テストは通っているが何を保証しているかは曖昧。半年後、保守担当者が「この仕様、どこに書いてあります？」と困惑する。
After（導入後）：要件定義書に4つの要素がきちんと書かれている。AIはそれを読んで解像度の高いコードを出す。テストは要件定義書から派生しているので、何を保証しているかが明確。半年後に新メンバーが、要件定義書を読むだけでプロジェクトの全貌を再構築できる。
この違いは、時間が経つほど大きくなります。仕様駆動開発は、短期の効率化ではなく長期の知識資産を作る投資です。
著者プロフィール
町島 和徳（ギャラクティックブレーン合同会社 代表社員）
電気通信大学在学中からコンテンツ制作の現場でキャリアをスタート。エンタメ業界での経営実務を経て、現在はコンサルタント兼フルスタックエンジニアとして活躍。経営・マーケティング・技術の複眼的視点と、部門や階層を超えたファシリテーション力を強みに、スタートアップから大手企業まで幅広いDX支援を手がける。生成AI・RPAの実務活用を精力的に展開。成功・失敗双方の実践知を惜しまず発信する現場主義のプロフェッショナル。
