AIを活用した“仕様駆動開発”をどう適用するべきか
TL;DR
- AIは大量に情報を生成するため、そのまま使うと判断が追いつかない
- だからこそ「仕様でAIの自由度を制限し、抽象化レイヤーで出力を要点化してから判断する」構造が必要になる
- 仕様で方向を定め、抽象化で量を捌くことで、AIを無理なく活用できる開発が実現する
AIを活用した“仕様駆動開発”をプロジェクトにどう適用するべきか
AIがソフトウェア開発に深く入り込むようになり、私たちの開発フローは大きく変わりつつあります。しかし、AIを導入すれば自動的に効率が上がるわけではありません。むしろ、AIが生成する膨大なアウトプットに人間側が振り回されてしまい、判断コストや管理コストが増えるケースも少なくありません。
本来、AIは意思決定者ではなく“作業者”として扱うべき存在です。人間の判断をサポートし、日々の開発を加速させるための道具として使う。そのためには、AIの出力を制御し、必要な部分だけを適切に抽象化して扱うプロセスが欠かせません。
この記事では、AI時代の開発手法として「仕様駆動開発（Specification Driven Development）」の課題と、AIを健全に活用するためのプロセス設計について整理します。
AI駆動開発の最大の課題：大量生成と判断のズレ
AIは優秀ですが、必ずしも「人間が意図した形」でアウトプットを生成するわけではありません。
また、AIはときに膨大な量のアイデアやコード、仕様案を一度に出力してしまいます。
その結果として起きる問題は大きく二つあります。
1つ目は「判断のズレ」。
AIは内部の推論で答えを導くため、人間が前提としている判断基準と噛み合わず、期待と大きく離れた結果を出してしまうことがあります。
2つ目は「情報量の過多」。
仕様、画面案、テストケースなど、100項目でも200項目でも平気で生成してきますが、人間がそれをすべてレビューして取捨選択するのは現実的ではありません。AIを使えば使うほど、かえって管理コストが増えるという逆転現象が起こります。
AIを活用するには、この“ズレ”と“過多”をどう扱うかが本質的なテーマになります。
重要なのは「事前に判断基準を狭めておくこと」
AIの自由度をそのまま許容してしまうと、アウトプットが広く散らばり、後工程での負担が爆発します。そこでまず重要になるのが、要件定義フェーズを徹底して構造化することです。
AIに渡す前段階で次のような情報を明確にしておきます。
- システム全体の要件
- 各業務と機能要件
- 業務や機能間の関係性
- 判断基準と優先度、ビジネスルール
- ユーザーストーリーとユースケース
- 画面遷移と画面定義
- 入出力のフォーマット
- 許容される範囲と、逆に禁止される範囲
これらがきちんと整備されていれば、AIの出力が大きくばらけることがなくなり、後工程での修正コストを大幅に減らすことができます。
つまり、人間が「最初のレール」をしっかり敷くことで、AIの判断は自然とレールに沿うようになります。
“抽象化レイヤー”を追加すると劇的に扱いやすくなる
もうひとつ重要なのが、AIが出した大量のアウトプットをそのまま人間が直接レビューしないことです。
ここで導入すべきなのが 抽象化プロセス です。
抽象化レイヤーには次の役割があります。
- AIが出した情報の要点だけを抜き出す
- 重複や枝葉を取り除く
- 判断すべき本質的な論点を整理する
- 大量の情報を「数個の重要ポイント」にまで圧縮する
この抽象化プロセスを AI → AI に任せることもできますし、人間が確認するためのフレームワークとして定義しておくこともできます。
重要なのは、
“AIの大量生成 → 抽象化 → 人間の判断”
という三段構えの構造を作ることです。
これにより、人間の認知負荷は劇的に下がり、重要な判断だけに集中できます。
仕様駆動開発のプロセス案
AIを前提にした新しい開発プロセスを、簡単にまとめるとこうなります。
- 人間が初期要件を定義する
- 要件をAIに渡し、必要な資料や設計案を生成させる
- AIから大量アウトプットが返ってくる
- 抽象化レイヤーで内容を整理し、本質だけ抜き出す
- 人間がその抽象化結果を評価し、必要に応じて詳細を参照する
- 確定した内容を次工程へ渡す
- このサイクルを繰り返して品質とスピードを両立させる
このように、AIを“作業の加速度装置”として扱う一方で、“判断は人間が行うための構造”をしっかり持つことが重要です。
画面設計の具体例
| # | 内容 | |
|---|---|---|
| 1 | 人 | 「初期要件」（目的・背景・業務内容・ビジネスポリシー）などを書き出す |
| 2 | AI | 初期要件から「機能要件」をAIから生成する |
| 3 | AI | 機能要件を「チェック」する（チェック内容はプロンプトを都度改善していく） |
| 4 | 人 | チェック内容を確認して、AIが生成したチェック内容のどれをどのように適用するかを指示する |
| 5 | AI | 4で指示した内容から機能要件を更新する |
| 6 | AI | 機能要件から「ユーザーストーリー」を生成する（アクターと業務の整理） |
| 7 | AI | ユーザーストーリーから「ユースケース」を生成する（アクター／業務／システム境界） |
| 8 | AI | ユースケースから「画面設計」と「画面遷移」を生成する（画面詳細と全体構成の整理） |
| 9 | AI | 画面設計と画面遷移から「HTMLモック」を生成する（人間が判断できるように視覚化&抽象化） |
| 10 | 人 | 生成されたHTMLモックを確認し、「修正指示」をする |
| 11 | AI | 修正指示から8~9を再構成する |
| 12 | - | 10~11 を指示がなくなるまで繰り返す |
| 13 | AI | 画面→ユースケース→ユーザーストーリー→機能要件のように逆伝播して仕様の整合性を整理する |
このように、ポイントで人間が確認して修正指示を出す、修正するとドキュメント間の整合性が崩れていくので逆伝播させて整合性を保つように整理していくことで、AIが大量生成してもプロセスが破綻することもなく、品質を保ちつつ、量を捌きながら開発を進めることができます。
まとめ：AI時代の開発は「量を出す力」と「量を捌く力」の両輪で成り立つ
AI時代のソフトウェア開発は、従来のプロセスとは明らかに違う性質を持っています。AIはとんでもない量の情報を生み出せる一方で、それを受け止める人間の処理能力には限界があります。
だからこそ重要なのが
・AIの自由度を適切に制限するための要件定義
・AIの大量出力を扱うための抽象化プロセス
この2つです。
AIは強力な道具ですが、正しく扱わなければ逆に開発を混乱させます。
しかし、人間側がプロセスを設計し、AIを“使いこなす側”に立てば、開発のスピードも品質もこれまでとは比べものにならないほど向上します。
この考え方をベースに、今後さらにプロセスを固めていけば、AIと人間が自然に共存しながら進む開発体制を実現できるはずです。
Discussion