生成 AI に「この機能の設計書を書いて」と投げた経験がある方は、結果が思い通りとならなかったことも多いのではないでしょうか。
返ってきた文書は、見た目は設計書の体裁をしていても、中身を読むと肝心なところが空白だったり、前提が想像だったり、意図とは違う実装を前提にしていたり・・・
最初は「AI の能力が足りないからだ」と思っていました。でも、いろんなモデルで、いろんな書き方で試すうちに、だんだん別の見方になってきます。
AI が書けないのは、多くの場合、私たち人間側が「仕様を決めきれていない」からです。AI はその曖昧さを、容赦なく可視化してきます。
本稿では、設計書を AI に任せてみて見えてきた「人間側の課題」と、そこから仕様定義の筋力をどう鍛え直すかを、実務の視点で整理します。
1. AI が書けない設計書は、たいてい「前提が欠けている」
AI が生成する設計書が期待外れになるとき、原因の多くは AI 側ではなく、投げた情報の側にあります。人間同士なら「当然分かっているだろう」で済む部分を、AI は文字通りしか処理しません。
自分がよく遭遇してきた「足りていない」のパターンは、以下のあたりです。
- 暗黙の前提: ユーザーはログイン済み、決済は別システム、既存 API を使う想定、などが書かれていない
- 用語の揺れ: 同じ概念に「注文」「オーダー」「購入」を混在させる、主要用語の定義がない
- 非機能要件の不在: 性能、セキュリティ、ユーザビリティの目安が書かれていない
- 例外処理の未定義: 正常系しか書かれず、エラー時の挙動が空白のまま
人間の設計書でも、これらが抜けていた時点で開発はぶれ始めます。
ただ、人間同士なら「行間」を読む能力で賄っていた部分が、AI に頼むと全部が露わになる。これが冒頭で述べた、AI が人間の曖昧さを可視化してくるということです。
2. AI へのプロンプトに入れるのは、結局「仕様そのもの」
AI に期待通りの設計書を書かせようとすると、プロンプトに入れるべき情報は、従来「仕様書」に書かれていたものとほとんど同じだと分かります。
試行錯誤の末にたどり着いたのは、以下の 5 要素をプロンプトの中で先に整えておく書き方です。
- 目的: この機能が解決すべき課題、ビジネス上のゴール
- 制約: 使う技術スタック、既存システム、期間や予算の上限
- 前提: 利用環境、ユーザー像、認証・認可の状態
- 出力形式: 設計書の章立て、必要な粒度、使う用語の指定
- 評価基準: 仕上がりをどう判定するか（必須項目チェックリスト等）
要するに、AI への指示とは、「仕様を先に整えた状態で渡す」ことに近い。「AI に書かせるためのプロンプト設計」は、実質的に「AI 以前から人間がやっていた仕様定義」そのものです。
AI に設計書を書かせるスキルは、従来の仕様を定義するスキルの延長線上にあって、曖昧さ・ヌケモレを許さない書き方への再訓練に近いのではないかと思います。
3. AI を「壁打ち相手」にすると、自分の仕様が整う
AI に設計書を「書かせる」方向でばかり使うと、消耗します。もうひとつの使い方として、自分が書いた仕様を AI に読ませて整える方向が、実は効きます。
現場で手応えを感じている使い方は、次の 4 つです。
- 矛盾点の洗い出し: 書いた仕様を貼り付けて、「論理的に矛盾している点、曖昧な点を列挙して」と頼む
- ユースケース生成: 仕様から想定される利用シナリオを網羅的に出してもらい、考慮漏れを確認
- 異なる解釈の提示: 「この仕様を別の読み方で解釈した場合、どんな設計になるか」と聞く
- 抽象 → 具体の落とし込み: 抽象的に書いた要件に対し、具体的な機能要件・非機能要件の例を出してもらう
AI に「書かせる」だけでなく、自分の仕様を AI に読ませて壁打ちするところまで使い方を広げると、仕様を固めるまでの時間が短くなります。
AI との往復が、自分の定義の雑さを指摘してくれる工程に変わるような感覚ではないでしょうか。
まとめ
AI に設計書を書かせて、期待外れの結果が返ってきたとき、いちばん得られる学びは「AI の限界」ではなく「自分が仕様をどこまで決めきれていないか」の可視化だと感じます。
次に AI に設計書を投げるときは、プロンプトを書き始める前に、目的・制約・前提・出力形式・評価基準の 5 要素を、自分の言葉で一度書き出してみる。
それを整えたうえで AI に渡し、返ってきたものを今度は壁打ち相手にする。この流れを一度試してもらえると、出力の質が変わるはずです。
