仕様書・設計書のドラフトをAIで作る｜叩き台の作り方と注意点

白紙のドキュメントに「仕様書」とだけ打って、そこで手が止まる。 何から書けばいいのか、見出しをどう並べればいいのか。書き始めさえすれば進むのに、その最初の一歩がいちばん重い——そんな経験、ありますよね。しかも仕様書や設計書は「作るのが仕事」ではなく「作った先で開発する」ためのもの。ここで時間を溶かすと、後ろの工程がまるごと押していきます。

そんなとき、「叩き台くらいAIに作ってもらえないか」と考えるのは自然なことです。 実際、見出しの構成、章立て、抜けがちな観点の洗い出し——形をつくる作業は、AIが得意とする所です。ゼロから書くより、AIが出した骨組みを直すほうが、人はずっと速く進めます。

ただ、ここには落とし穴があります。 AIは、それらしい仕様を、事実のように書いてしまう。あなたのプロジェクトの前提を知らないまま、「たぶんこうだろう」を断定口調で埋めてくる。それを気づかず本物の仕様書として通すと、間違った前提のまま開発が進むという、いちばん怖い事故になります。

結論：AIに任せていいのは、①構成・見出しの骨組み ②抜けがちな観点の洗い出し ③言い回し・体裁の整え ④既存メモからの下書き化まで。人が必ず埋めるのは、①このプロジェクト固有の要件・制約 ②数値・仕様・外部連携などの事実 ③採用/不採用の判断とその理由。AIは「白紙を埋める叩き台メーカー」、人は「事実と判断を入れる書き手」。AIが書いた文は、確認が済むまですべて仮として扱う。この一線さえ守れば、仕様書づくりは驚くほど軽くなります。

書き出しで止まるのは、あなたの段取りが悪いからではありません。 白紙から構成と中身を同時に立ち上げるのは、そもそも脳への負荷が高い作業です。だから「気合いで書き切る」の前に、骨組みはAIに作らせて、人は中身に集中する。今日はその進め方を、コピーして使えるプロンプトと一緒に整理していきます。

なぜ「AIに丸ごと書かせる」と事故るのか

仕様書を「全部AIに書いてもらう」と考えると、たいてい無理が出ます。 AIは、あなたのプロジェクトの事情を知りません。どんなユーザーがいて、どんな制約があって、過去にどんな失敗をしたか。そこを知らないまま「よくある仕様」を書くので、出てくるのは一般論としては正しいが、この案件には合っていない文章です。

やっかいなのは、それが堂々と、事実のように書かれることです。 「レスポンスは200ms以内とする」「対象ブラウザは主要4種」——本当は誰も決めていない数字を、AIがそれらしく埋めてしまう。これはハルシネーション（もっともらしい誤り）の一種で、仕様書という「事実が書かれているはずの文書」で起きると、後工程がまるごとその嘘を前提に進みます。

だから、AIの使いどころは「丸ごと書かせる」ではありません。 空欄つきの骨組みを作らせて、事実と判断は人が埋める。この二段階に分けるのが、事故らない基本の型です。

AIに任せていい部分（叩き台の守備範囲）

まず、安心して任せられる所から。 共通するのは、間違っていても人がすぐ気づけて、直すのが速いということです。

1. 構成・見出しの骨組み

「機能仕様書の一般的な章立てを出して」と頼めば、目的・スコープ・用語定義・機能一覧・画面・データ・非機能要件・制約……といった型をすぐ並べてくれます。 白紙から見出しを考えるのがいちばん重いので、ここをAIに任せるだけで体感が大きく変わります。出てきた章立ては、そのまま使うのではなく「うちの案件で要る/要らない」を削り足しする前提で見ます。

2. 抜けがちな観点の洗い出し

「この機能の仕様で、書き忘れやすい観点を挙げて」と頼むと、エラー時の挙動、権限、上限値、同時実行、移行、ログ——人が急ぐと飛ばしがちな所を並べてくれます。 これは埋める中身ではなく、埋めるべき欄を増やす使い方です。観点の抜けは後で仕様の穴になるので、叩き台の段階で候補を広げておくと、後の手戻りが減ります。設計の妥当性そのものを相談したいときは、設計の壁打ち相手としてAIを使う進め方も合わせて使えます。

3. 言い回し・体裁の整え

自分で書いた箇条書きのメモを渡して「仕様書の文体に整えて」と頼むのは、AIが得意で害の少ない使い方です。 中身は自分が持っているので、AIは表現の整形だけを担当します。「〜する。」の統一、曖昧語（適宜・など・随時）の指摘、重複の削除——読みやすさの底上げを、判断を渡さずにやってもらえます。

4. 既存メモ・議事録からの下書き化

打ち合わせのメモやチャットのやり取りを渡して「これを設計書のドラフトにまとめて」と頼むと、散らばった情報を章立てに沿って並べ直してくれます。 ここで大事なのは、元にした情報の範囲を超えて書かせないこと（後述のプロンプトで縛ります）。渡した材料の中で整理する分には、AIは頼れる清書係になります。

この4つに共通するのは、判断や事実を新しく生み出していないこと。だから安心して叩き台に回せます。

人が必ず埋める部分（AIに決めさせない中身）

ここが、この記事のいちばん大事な所です。 叩き台をAIに作らせても、次の3つは人が埋めます。これらはAIが「知らない」ことか、AIに「決めさせてはいけない」ことだからです。

1. このプロジェクト固有の要件・制約

対象ユーザーは誰か、既存システムとの関係、使っていい技術と使えない技術、予算やスケジュールの制約、過去のいきさつ——AIが知りようのないこの案件の事情は、人が入れます。 AIが「一般的にはこうです」と埋めた欄は、便利な出発点ですが、うちの事情に合っているかは必ず自分で上書きします。既存のコードや設計に馴染ませたいときは、既存コードベースにAIを馴染ませる文脈の渡し方も併せて使えます。

2. 数値・仕様・外部連携などの事実

「レスポンスは何ms以内か」「同時接続は何件か」「連携先APIの仕様は何か」「保持期間は何日か」——具体的な数字と外部の事実は、AIに書かせてはいけない代表格です。 AIはこれらを平気で創作します。決まっていない数字は「未定」と書き、決まっている数字は一次情報（決定の記録・公式ドキュメント・実測値）で裏を取ってから人が入れる。この文書は誰かがそのまま実装するので、ここの嘘は最も高くつきます。

3. 採用/不採用の判断とその理由

「A案とB案のどちらにするか」「この非機能要件をどこまで満たすか」といったトレードオフの判断は、人の仕事です。 AIに複数案を出させて比較材料にするのは有効ですが、決めるのは自分。判断の材料としてAIに案を並べさせる型はAIにアーキテクチャ案を出させて鵜呑みにしない比較の型に整理しています。仕様書に残すのは、選んだ案だけでなくなぜそれを選んだか。ここはAIには書けません。

この3つは、効率化の対象ではなくそもそも人が持っている責任です。叩き台を速く作るのは、ここに時間を残すためでもあります。

任せる/埋めるの早見表

迷ったときのために、一覧にしておきます。あくまで目安なので、案件に合わせて調整してください。

◎=任せやすい／○=人が確認しつつ活用／△=参考程度／×=任せない、の目安です。 表の上半分（形をつくる作業）をAIに寄せ、下半分（事実と判断）に人の時間を残す。これが叩き台づくりの設計です。

AIに叩き台を頼むときのプロンプトの型

「仕様書を書いて」とだけ頼むと、AIは足りない情報を勝手に埋めて、それらしい嘘を含んだ文書を返します。 コツは、知らないことは書かせない・仮のところは仮とわからせるの2つを、最初に指示することです。

渡すと良いもの：

• 何の仕様書か（対象システム・機能・読み手）
• 今わかっている材料（メモ・議事録・箇条書き。あるだけ）
• 章立ての希望（あれば。無ければAIに提案させる）
• 創作の禁止（「決まっていない事は書かず、未定と明記して」）
• 仮の明示（「推測で補った所は【要確認】と付けて」）

聞き方の例：

次の機能について、設計書のドラフト（叩き台）を作ってください。

## 対象
- システム／機能：（何についての設計書か）
- 読み手：（開発者／レビュアー／発注者など）

## いま渡せる材料
（決まっている事・メモ・議事録の要点を箇条書きで。無い項目は「未定」と書く）

## お願いしたいこと
1. まず章立て（見出し）だけを提案してください。合意してから中身に進みます。
2. 各章で「書き忘れやすい観点」も候補として挙げてください。
3. 私が渡していない事実（数値・仕様・外部連携など）は創作しないでください。
   決まっていない所は本文に「未定」と書いてください。
4. 一般論で補った箇所には、文末に【要確認】と付けてください。

判断（案の採否）は私がします。材料の範囲での整理と、抜けの洗い出しをお願いします。

ポイントは2つ。 1つは「まず章立てだけ」と段階を切ること。骨組みに合意してから中身に進むと、方向がずれたまま長文を書かせて丸ごと捨てる、という無駄が減ります。 もう1つは「創作の禁止」と「【要確認】の明示」。AIは自信のない補完も断定口調で書くので、仮の所を見た目で区別できる状態にしておくと、人の確認がぐっと速くなります。プロンプトの前提の渡し方はAIにコードを書かせる前に渡すべき前提・制約の伝え方と同じ考え方です。

叩き台を受け取ったあとの進め方

ドラフトが返ってきたら、全部信じるのでも全部疑うのでもなく、印をつけながら埋めます。

1. 【要確認】が付いた所：AI自身が「補完した」と申告した箇所。ここを最優先で、事実確認して埋めるか消すかを決める。
2. 数値・固有名詞・外部仕様：【要確認】が付いていなくても、事実は全部裏を取る。決定の記録・公式ドキュメント・実測に当たる。取れないものは「未定」に戻す。
3. 案件固有の要件・制約：一般論で埋まっている欄を、うちの事情で上書きする。ここがドラフトの価値がいちばん出る所。
4. 判断が要る箇所：AIが並べた選択肢から、自分が理由を持って選ぶ。選んだ理由を一文添える。
5. AIが触れなかった所：骨組みに無い章が要らないとは限りません。AIが挙げなかった観点を、最後に自分で見に行きます。

この過程は「AIの文章を清書する」のではなく、「AIの下書きを土台に、自分が書く」感覚です。仕上がった文書の責任は、AIではなく書いたあなたにあります。だから最後は必ず、通しで自分の言葉として読み直す。この一手間が、そのまま仕様書の信頼になります。

ありがちな落とし穴と、その回避

叩き台をAIに作らせるとき、つまずきやすい所を先に潰しておきます。

• 【要確認】を消して事実にする：確認せずに印だけ外すと、嘘がそのまま仕様になる。埋めるか未定に戻すかの二択。
• もっともらしい数値を鵜呑みにする：「200ms」「99.9%」などAIが出した数字を、決定事項と勘違いしない。数字は必ず出どころを確かめる。
• 章立てを疑わずに全部埋める：AIの型に合わせて、要らない章まで無理に埋めると、実態と合わない仕様書になる。削る勇気を持つ。
• 材料を渡さず「書いて」と丸投げする：情報が無ければAIは創作で埋める。手元の材料は、少なくても全部渡す。
• 機密の要件をそのまま外部AIに入れる：仕様書には案件固有の情報が集まる。外部AIに渡してよいかは情報漏えい・取り扱いの線引きを確認してから。
• AIの文体をそのまま最終版にする：整った文章＝正しい仕様、ではない。読みやすさと正しさは別。中身の確認を省かない。

落とし穴のほとんどは、「叩き台」と「完成版」を混同した瞬間に生まれます。 AIが作るのは常に仮。確認して初めて本物。この一線を保つだけで、多くは避けられます。

明日からやること（小さく始める3つ）

いきなり全部の仕様書に適用しようとせず、まずこの3つから。

1. 次に書く小さめの仕様書で、章立てだけAIに出させる：中身は自分で埋め、骨組みだけ借りる。書き出しの重さが減る感触をつかむ。
2. プロンプトに「決まっていない事は書かず未定と明記して」を1行入れる：AIの創作を止める癖を、最初からつけておく。
3. 返ってきたドラフトの数値・固有名詞に、確認前は全部マーカーを引く：事実を「仮」として扱う習慣を、目に見える形で作る。

この3つだけでも、「白紙の仕様書が重い」朝が、少し進めやすくなります。

コピーして使う「叩き台チェックリスト」

AIに叩き台を作らせるとき、上から順に確認してください。一度に全部でなく、必要な所だけで十分です。

# 仕様書・設計書 叩き台チェック

## ① 頼む前
- 何の仕様書か（対象・読み手）を伝えたか：
- 手元の材料（メモ・議事録・決定事項）を渡したか：
- 外部AIに渡してよい情報か（機密・個人情報・契約）を確認したか：

## ② 頼むときに指示すること
- まず章立てだけ提案させたか：
- 「決まっていない事は書かず未定と明記」を入れたか：
- 「補完した所は【要確認】を付けて」を入れたか：
- 「判断（採否）は人がする」を明記したか：

## ③ 受け取ったあと
- 【要確認】の箇所を、埋めるか未定に戻したか：
- 数値・固有名詞・外部仕様の事実を、裏取りしたか：
- 案件固有の要件・制約を、自分の事情で上書きしたか：
- 選んだ案に、選んだ理由を添えたか：
- AIが触れなかった観点を、自分で見に行ったか：

## ④ 仕上げ
- 通しで、自分の言葉として読み直したか：
- この文書の責任は自分にある、と言える状態か：

最後に

白紙の仕様書を前に手が止まる夜は、しんどいものです。 書けないのは能力の問題ではなく、構成と中身を同時に立ち上げる負荷が高いから。その重さは、道具を変えれば少し軽くできます。

全部を変えなくて大丈夫です。今日ひとつ、次の仕様書の章立てだけAIに出させてみる。それだけで、白紙との向き合い方が少し変わります。 骨組みはAIに、事実と判断は自分に。その線引きさえ持っていれば、AIは仕様書づくりの頼れる下書き係になります。

よければ、こちらも

• 設計の壁打ち相手としてAIを使うときの問いの立て方
• AIにアーキテクチャ案を出させて鵜呑みにしない比較の型
• ハルシネーション（もっともらしい誤り）の見抜き方と前提

関連用語

• プロンプト
• LLM
• ハルシネーション