仕様駆動開発

1. AI×仕様駆動開発の基本概念

仕様駆動開発の定義

• 人間が自然言語やモデルで定義した仕様を核としAIがその仕様からコードやテストやドキュメントを自動生成や同期させる開発手法
• 従来の開発では仕様書とコードの乖離が大きな課題だったがAIの登場により仕様書そのものが動く設計図として機能するようになっている

基本サイクル

• 仕様を入力としAIが実装と検証をサポートする形で行われる

仕様の定義と構造化

• 開発者が自然言語で要件を伝えるとAIがそれを構造化された仕様に変換する
• OpenAPIやGherkinやUMLやあるいは特定のDSLに変換
• AIの役割は曖昧な表現の検知や論理的矛盾の指摘や標準規格への落とし込み

コードの自動生成

• 構造化された仕様を基にAIがボイラープレートだけでなくビジネスロジックを含めた実装コードを生成する
• AIの役割は仕様に忠実な関数の作成やAPIエンドポイントの実装

テストの自動生成と整合性チェック

• 仕様から直接ユニットテストやE2Eテストを生成する
• AIの役割は仕様を満たしているかの自動検証やエッジケースの網羅

2. 従来手法との比較

信頼の源泉

• 従来の開発ではコードが実装が正義
• AI駆動SDDでは仕様が信頼の源泉

ドキュメント

• 従来の開発では実装後に作成され形骸化しやすい
• AI駆動SDDでは実装と常に同期し仕様がコードを生む

修正プロセス

• 従来の開発ではコードを直してから仕様を直す
• AI駆動SDDでは仕様を書き換えてコードを再生成する

開発スピード

• 従来の開発では手動コーディングに依存
• AI駆動SDDでは仕様定義に集中し生成は瞬時

3. 主なメリット

仕様とコードの不一致の解消

• 仕様を変更すればAIがコードを更新するため常に最新のドキュメントが維持される

品質の均一化

• AIが設計パターンを遵守するため開発者のスキルセットによるコード品質のバラツキを抑えられる

高速なプロトタイピング

• 画面遷移図やAPI定義から即座に動作するモックを作成可能

4. 留意点と不確実性

技術の発展途上性

• AI×仕様駆動開発は2026年現在急速に進化している分野
• 複雑な大規模システムにおける完全な自動同期の信頼性については依然として未知数な部分が多く発展途上の技術

人間の介在の必要性

• 現時点ではAIが生成したコードが仕様の行間を誤って解釈するリスクがあるため最終的なレビューには必ず人間のエンジニアの介在が必要

適用範囲の限界

• 小規模なプロジェクトでは絶大な効果を発揮する
• 歴史の長いレガシーシステムへの適用は既存コードとの整合性維持が難しく難易度が高い

5. 具体的なワークフロー

自然言語による要件の明文化

• 開発者が何を作りたいかをAIに伝える
• ビジネスロジックや制約事項を箇条書きなどで整理する
• AIの役割は入力された曖昧な要望を分析し考慮漏れを指摘して要件をブラッシュアップする

構造化された仕様の生成

• AIを使ってプログラムが理解可能な形式に変換する
• APIの場合はOpenAPI形式のYAMLやJSON
• 画面やUIの場合はUIコンポーネントの定義書や画面遷移図
• 振る舞いの場合はGherkin形式などのテストシナリオ
• データ構造はPrisma SchemaやSQL DDL

仕様に基づくコードの自動生成

• 作成した構造化仕様をAIエージェントに読み込ませコードを一括生成する
• 開発者が直接コードを書くのではなく仕様書を修正してAIにコードを再生成させるアプローチを取る
• これにより仕様と実装が常に同期する

仕様ベースのテスト自動生成と実行

• 仕様書からその仕様を満たしているかを検証するためのテストコードを生成させる
• AIの役割は仕様通りに動くかをチェックするためのテストを書き実際に実行してバグがあれば自動修正を試みる

フィードバックと仕様の更新

• テスト結果や実際の動作を確認し修正が必要な場合はコードではなく仕様を修正する
• サイクルは仕様変更からAIが影響範囲を特定しコードとテストを自動更新

6. ワークフロー比較

設計

• 従来のワークフローでは人間が設計書を書く
• AI駆動SDDワークフローではAIと対話して構造化データを生成

実装

• 従来のワークフローでは人間が1行ずつコードを書く
• AI駆動SDDワークフローではAIが仕様からコードを一括生成

テスト

• 従来のワークフローでは実装に合わせてテストを書く
• AI駆動SDDワークフローでは仕様からテストを先に生成する

変更対応

• 従来のワークフローではコードを直し後で設計書を更新
• AI駆動SDDワークフローでは仕様を直しAIにコードを更新させる

7. 実務における不確実性

ドメイン知識の理解

• AIが複雑なドメイン知識を100%正確に理解できるかについては現在の技術でも不確実な部分が残っている

大規模システムへの適用

• 大規模で複雑な依存関係を持つモノリスなシステムにおいて仕様の変更が予期せぬ箇所に影響を与えるリスクは未知数

必須の対策

• 生成されたコードの最終的なレビューとカバレッジの高いテストスイートによるガードレールは必須

8. 要件定義から外部設計への変換

要件定義フェーズ

• AIを伴走者として使い要件の漏れや矛盾を解消する
• ユーザーとの対話で開発者がやりたいことを伝えるとAIがビジネスロジックやユーザー像を深掘りする質問を投げかける
• 対話結果からAIが誰がや何をやなぜしたいかをユーザーストーリー形式で整理する
• セキュリティ要件やパフォーマンス目標などを非機能要件としてAIがリストアップする

データモデルの設計

• 要件に登場する名詞を抽出しデータ構造を定義する
• AIへの指示でこれらのユーザーストーリーから必要なデータベースエンティティとそれらのリレーションシップを抽出してMermaid記法のER図で出力させる
• 成果物はER図やデータ辞書

インターフェース設計

• システム間の通信ルールを定義する
• AIへの指示でデータモデルに基づきCRUD操作を行うためのOpenAPI仕様書を作成させる
• 成果物はOpenAPI定義やGraphQLスキーマなど

UIやUX設計

• ユーザーが触れるインターフェースを定義する
• AIへの指示で主要なユースケースに基づき画面遷移図を作成し各画面に必要なUIコンポーネントをリストアップさせる
• 成果物は画面遷移図やワイヤーフレームを構成するコード

仕様の検証

• 外部設計が完了した時点でAIを使って設計が要件を満たしているかを自動検証する
• カバレッジ・トレースでこの画面設計は要件定義で挙げたどのユーザーストーリーに対応しているかをAIにマッピングさせ設計漏れを確認する
• 不整合の検知でAPI定義にあるデータがDB設計に含まれていないといった不整合をAIが自動で指摘する

9. 要件定義における留意点

ドメイン特有の暗黙の了解

• 業界の商習慣などをAIがどこまで汲み取れるかについては現時点でも限界がある

論理的整合性と実用性の乖離

• AIは論理的な整合性を保つのは得意
• ユーザーにとって本当に使いやすいかやそのビジネスモデルで法的に問題ないかといった高度な判断については未知数な部分が多く人間の専門家による最終判断が不可欠

10. AIと伴走する要件定義

壁打ちによる要求の深掘り

• 要件定義の初期段階では人間の頭の中にあるアイデアは断片的で曖昧
• AIをビジネスアナリストとして扱い対話を繰り返す
• 逆質問の活用でこのシステムの要件を定義したい漏れがないよう私に10個の質問を投げてくださいと指示する
• ペルソナ分析でAIに厳しいエンドユーザーや保守担当エンジニアの役割を与え設計上の懸念点を指摘させる

構造化とトレーサビリティの確保

• 対話で得られた断片的な情報をAIが即座に構造化されたドキュメントへ変換する
• これにより言ったや言わないの防止だけでなく実装へのスムーズな橋渡しが可能になる
• ユーザーストーリーへの変換で誰がや何をやなぜしたいのかを標準的なフォーマットに整理する
• 受け入れ基準の自動生成で各機能に対してどのような状態になれば完成かをAIに具体的なテスト条件として記述させる
• 用語集の構築でユーザーや注文や配送といった言葉がシステム内で何を指すのか定義の揺れをAIが監視や統一する

仕様の整合性チェックと矛盾検知

• 人間が見落としがちな論理的な矛盾やエッジケースをAIに特定させる
• 行間の指摘でAという操作をした後通信が切断された場合の挙動が定義されていませんといった正常系以外のケースをAIがリストアップする
• 競合する要件の発見でリアルタイム性を重視する要件と強固な整合性を求める要件が矛盾している場合AIが技術的なトレードオフを提示する

11. 従来の要件定義との違い

主導権

• 従来の要件定義では人間がゼロから書き出す
• AIと伴走する要件定義では人間が意図を伝えAIが具体化する

フィードバック

• 従来の要件定義ではレビュー会議まで待つ
• AIと伴走する要件定義ではその場でリアルタイムに得られる

網羅性

• 従来の要件定義では経験則に頼る
• AIと伴走する要件定義ではAIが標準的なチェックリストで検証する

成果物の形式

• 従来の要件定義では自然言語でWordやExcelなど
• AIと伴走する要件定義では構造化データでMarkdownやYAMLやGherkin

12. AIとの伴走における注意点

ハルシネーションのリスク

• AIがもっともらしい嘘をつく可能性
• 特定の業界独自の規制や社内固有の古いルールについてはAIが学習データを持っていない場合がある
• 出力された仕様が法的に正しいか社内規定に沿っているかは人間による最終確認が不可欠

行間の読み過ぎ

• 2026年時点においてもAIは行間を読みすぎることがあるため意図しない仕様が勝手に追加されていないか精査する必要がある

13. ランチ予約システムの具体例

アイデアの言語化

• 人間が社員が毎朝10時までに弁当を予約できるシステムを作りたい支払いは給与天引きにしたいと伝える
• AIの深掘りでキャンセル規定や在庫管理や例外ケースについて質問を投げる

ユーザーストーリーと受け入れ基準の作成

• 対話の結果を受けAIが実装可能なレベルまで要件を構造化する
• 社員として弁当を予約したいや社員として予約を取り消したいや管理者として注文集計を確認したいなどをユーザーストーリーとして整理
• 各ストーリーに対して具体的な受け入れ基準を定義

ドメインモデルの抽出

• 用語の揺れを防ぐためAIがシステム内で扱う主要な概念を抽出する
• 注文スロットや締め切り時刻などの用語を定義

非機能要件の自動提案

• 目に見える機能以外の重要なシステム特性をAIがリストアップする
• 10時直前にアクセスが集中する可能性があるため同時実行制御や二重予約の防止やピーク時のレスポンス性能を要件に含めるべきと提案
• 給与データと連携するため通信の暗号化は必須と提案

14. 伴走型要件定義の成果物

Gherkin形式のシナリオ

• テスト自動化に直結

OpenAPI定義

• API開発に直結

ER図

• データベース設計に直結

15. 伴走プロセスの限界

会社の文化や暗黙のルール

• AIは会社の文化や暗黙のルールについては無知
• 10時を過ぎても社長の注文だけは受け付けるといった政治的や文化的な例外は人間が明示的に教えない限りAIは考慮できない

長期的や大規模な整合性

• 2026年現在AIが生成した仕様書同士の長期的や大規模な整合性を保証する技術はまだ発展途上
• 最後に全体を俯瞰してチェックする役割は人間に残されている

16. 構造化プロンプトテンプレート

Role

• あなたは熟練のソフトウェアアーキテクトとして実装のガイドラインとなる厳密な外部設計書を作成する

Context

• 対象システムの全体像を共有

Business Requirements

• 目的や締め切りや決済方法や在庫制限やユーザー属性など

Task

• 生成すべき成果物を開発者がそのまま利用可能な形式で出力
• データモデルやAPI定義やビジネスロジックのガードレールなど

Constraints

• 技術スタックやセキュリティや可読性など

Output Format

• Markdownのコードブロックを使用して各セクションを明確に分けて出力

17. プロンプト構造の要素解説

Role

• AIの振る舞いを固定し一般的な文章ではなく技術的なドキュメントとして出力させる

Context

• システムの全体像を共有しランチ予約という文脈に沿った適切な変数名やデータ構造を選択させる

Input

• 必須機能の羅列でAIが勝手に仕様を捏造するのを防ぐ

Task

• 出力対象の明示でOpenAPIやSchemaなど構造化データを指定することで実装を自動化できる

Constraints

• 技術的やビジネス的制限で締め切り時間や特定技術スタックへの準拠を強制する

18. プロンプト活用の注意点

大規模なデータ移行や複雑な認証基盤

• コンテキストが膨大になる設計についてはAIが細部を簡略化してしまう傾向がある

検証の必要性

• 生成されたOpenAPI定義などは必ずSwagger Editorなどの検証ツールを通し構文エラーや論理的な矛盾がないか人間がレビューする必要がある

19. AIに与えるべき情報の分類

ビジネスやドメイン知識

• 用語集でそのプロジェクト特有の用語定義
• PRDで解決したい課題やターゲットユーザーや成功の定義
• 既存の業務フロー図で現状のプロセスやシステム関連図

技術的憲法と制約

• 技術スタック定義で言語やフレームワークのバージョン
• コーディング規約で命名規則やディレクトリ構造や推奨するデザインパターン
• 禁止事項リストで使用を禁止するライブラリや避けるべきアンチパターン
• 既存のAPI定義やDBスキーマで連携が必要な既存資産のインターフェース情報

機能や振る舞い仕様

• ユーザーストーリーと受け入れ基準でGiven-When-Then形式の具体的な動作条件
• エッジケースや異常系シナリオでエラー時の挙動やタイムアウト時の処理方針
• UIデザインシステムやトークンで使用すべき色やフォントやコンポーネントライブラリの定義

既存資産

• お手本となるコード片でこの既存コンポーネントのスタイルに従って作成してといった指示用のサンプル

20. 情報管理のベストプラクティス

構造化されたファイル群

• constitution.mdでプロジェクト全体の開発原則や技術選定を記述
• spec.mdで特定機能の振る舞いとビジネスロジックを記述
• plan.mdでAIが生成したこれからどう実装するかの実行計画を記述

プロジェクト内の専用ディレクトリ

• これらをバラバラに渡すのではなくプロジェクト内に専用ディレクトリを設けて管理する手法が一般的

21. 情報提供における留意点

コンテキスト過多

• 情報が多すぎるとAIが重要な制約を忘れるまたは混乱する現象が発生することがある

情報の鮮度

• ドキュメントと実態が乖離している場合AIは古い情報を優先してしまい誤ったコードを生成する

情報のモジュール化

• 何でも与えれば良いわけではなくAIのコンテキストウィンドウに合わせた情報のモジュール化が2026年現在の高度なエンジニアリングスキルとされている

22. AIフレンドリーなフォルダ構成

基本原則

• 不変のルールと可変の仕様を分離しAIがRAGで情報を拾いやすい構造にする

専用コンテキストフォルダ

• プロジェクトのルートディレクトリに.aiやdocs/specsといった専用のコンテキストフォルダを作成

.cursorrules

• Cursor等に常時読み込ませるプロジェクトの憲法

standards

• 技術標準やコーディング規約でtypescript.mdやtailwind.mdやtesting.mdなど

domain

• ビジネス知識や用語定義でglossary.mdやmodels.mdなど

features

• 各機能の仕様でSDDの核でauth/spec.mdやlunch-order/spec.mdやapi.yamlなど

blueprints

• コードの雛形でお手本でこの通りに作れというコンポーネント例

23. 各ディレクトリの役割

standardsの効能

• AIが古い書き方や好ましくないライブラリを使うのを防ぐ
• AIが生成するコードのレビュー工数を激減させる

domainの効能

• AIにこのプロジェクトにおける言葉の意味を教える
• AIが仕様の行間を読み違えてとんちんかんなロジックを組むのを防ぐ

featuresの効能

• 実装対象の設計図
• 仕様を直してコードを再生成するというSDDのサイクルを高速化する

blueprintsの効能

• AIに最高のサンプルを見せ模倣させる
• Few-shot学習の効果で出力の質が劇的に向上する

24. .cursorrulesの活用

効果的な記述

• 実装を行う前に必ず.ai/standards/と対象機能の.ai/features/にある仕様を確認しそれらに矛盾しない計画を作成してからコーディングを開始してくださいと添える

25. フォルダ構成における留意点

コンテキスト読み込みアルゴリズム

• AIエージェントのコンテキスト読み込みアルゴリズムはツールベンダーによって頻繁にアップデートされており2026年現在もこれが唯一の正解という構成は確立されていない

ロスト・イン・ザ・ミドル現象

• ファイル数が多すぎるとAIが重要な情報を見落とす中だるみ現象が起きる可能性がある

メンテナンスの必要性

• 関連性の低い古いドキュメントは積極的にアーカイブまたは削除し常に最新の真実だけをAIに見せるメンテナンスが必要