AI仕様書作成の手順とコツ｜品質とリスク対策まで徹底解説

• AI仕様書作成は「プロンプトを打てば済む」作業ではなく、与える情報・書かせる構成・評価と修正の3点で品質が決まる。
• 完璧を目指さず基本要件から「小さく始める」のが失敗を避ける近道。
• 品質チェックは正確性・網羅性・一貫性・可読性・トレーサビリティの5観点で見る。
• 機密情報の線引きとハルシネーション対策を決めてから渡すと、安全に運用できる。
• 既存コードやWeb画面からの逆算でも、人間へのヒアリングを挟むと精度が上がる。

AIで仕様書を作成するとは？基本と従来との違い

【2025年最新】エンジニアのための生成AI活用術【要件定義・設計・テスト仕様書作成の時短テクニック】

AIで仕様書を作成するとは、要件や既存資料をAIに与え、対話しながら仕様書のドラフトを生成し、人間が検証して仕上げる作業のことです。

ここを誤解している人が多い。AIに一言投げれば完成品が出てくる、ではありません。blastedgeのnote記事も、AI仕様書作成は「プロンプトを打てば済む」単純作業ではなく、与える情報・書かせる構成・評価と修正の3点が重要だと述べています。

仕様書と企画書・設計書の違い

企画書は「何を・なぜやるか」、仕様書は「何を満たすべきか（要件）」、設計書は「どう作るか（実装方針）」を書く文書です。

AIに渡すとき、この区別が曖昧だと出力もぼやけます。私の場合、企画段階のメモはあえて「これは意図であって要件ではない」と明記して渡します。混ぜると、AIが推測で仕様を埋めてしまうからです。

AIに丸投げでは使い物にならない理由

丸投げが失敗するのは、AIが手元の文脈を持たず、足りない前提を勝手に補完してそれらしい嘘を書くからです。

blastedgeのnote記事は、AIに仕様書を書かせる知識基盤として、過去の企画書・仕様書、要件定義や企画メモ、独自用語や構成ガイドの整備が必要だとしています。要は、土台がないと出力も土台なしになる。

AIが得意な作業と人間が担うべき作業

AIは構成の型起こし・用語調査・ドラフトの量産が得意で、人間は要件の真偽判断と取捨選択を担う、という分担が現実的です。

AIで仕様書を作成する手順（所要時間・難易度・準備）

基本要件から小さく始めれば、簡単な機能なら1〜2時間でドラフトに到達できます。難易度は中程度、特別なツールは不要です。

SIOSの技術記事は、要件整理→AIへの依頼→レビューと修正→反復改善の4段階を示し、完璧を目指さず基本要件から始める「小さく始める仕様書作成」を勧めています。私もこの順番に賛成です。最初から全部を書かせようとすると、たいてい破綻します。

準備：必要な道具と前提条件

必要なのは生成AI（ChatGPT・Claude等）と、過去の企画書・要件メモ・独自用語の一覧です。

• 生成AIのアカウント（ChatGPT、Claude、GitHub Copilotのいずれか）。
• 過去の仕様書や要件定義のサンプル1本（型を学ばせる用）。
• 独自用語・略語をまとめた用語集。
• 出力フォーマットの雛形（後述のテンプレート）。

手順1：業務フローを言語化してプロンプトを作る

最初に、対象の業務フローを箇条書きで言語化し、入力を2種類に分けてプロンプトに入れます。

Qiitaの記事は、入力を「Core Requirements（事実/制約）」と「Supplementary Info（意図/参考）」に分類する案を紹介しています。私はプロンプト冒頭でこの2見出しを立て、その下に箇条書きを貼るだけにしています。

確認の目安：プロンプトを読み返して、第三者が「何を満たせばいいか」を理解できれば合格です。意図と要件が混ざっていたら戻ってやり直します。

手順2：AIと対話しながら仕様書のたたき台を作る

次に、用意したフォーマットを指定してドラフトを出させ、抜けている項目をAIに質問させます。

CyberAgent記事の工程は、要件の概要理解→用語調査→構成把握→ドラフト作成→レビューと修正→完成報告です。調査結果は「要件サマリ」「関連用語」「設計上の考慮事項」の形で記録する例が示されています。一問一答で詰めると、抜け漏れが見える化されます。

うまくいかないときは：出力が薄いなら、フォーマットの各項目に「ここに何を書くか」の一文を添えて渡し直すと、密度が上がります。

手順3：人間が良いシナリオを判断して仕上げる

最後に、AIが出した複数のシナリオから人間が良いものを選び、事実誤りを潰して確定します。

Zennの記事は、生成AIが読みやすい形式としてGherkin記法を採用し、良いシナリオを人間が判断する運用を紹介しています。判断する人がいない自動化は、私は勧めません。

完了状態：この手順で「要件サマリ・用語・機能要件・シナリオ」が揃った仕様書のドラフトが、レビュー可能な形で出来上がります。

読みやすい仕様書にするフォーマットと書き方のコツ

人にもAIにも伝わる仕様書にするには、Gherkin記法のような構造化された書き方と、用語集・画面遷移図の併用が効きます。

前述のZenn記事は、生成AIがソースコードだけでなくWeb画面とソースコードを踏まえて人間にヒアリングし、仕様書を作るワークフローを説明しています。形式が整っていると、AIの読み取り精度も上がります。

人もAIも理解しやすい記述方法を採用する

「前提・操作・結果」を分けて書くGherkin記法は、人間が読んでも曖昧さが残りにくく、AIにも解釈しやすい形式です。

API定義やデータモデルは自然文で書かない方がいい。Qiitaの記事は、出力形式としてOpenAPI 3.1やProtobufのような厳格なスキーマを使う方針を示しています。私もインターフェース部分はスキーマで固定します。曖昧さの入り込む余地を消せるからです。

画面遷移図や用語集をあわせて整える

仕様書本体に加え、用語集と画面遷移図を更新し続けると、AIに渡す文脈が安定します。

gruff記事のテンプレート例には、概要・用語定義・ユースケース・機能要件・非機能要件・API/インターフェース仕様・データモデル・依存関係/制約・テスト観点・リスク/未決事項・変更履歴が挙げられています。この一覧をそのまま雛形にすると、抜けが減ります。

プロンプトをテンプレート化して再利用する

よく使うプロンプトはテンプレート化してライブラリ化し、チームで使い回すと品質が安定します。

私の運用では、流動的な要件には期限を切ります。Qiitaの記事が提案するTTL（Time To Live）の考え方を借り、古い情報はナレッジベースから定期的に除去しています。放置すると、古い前提でAIが書き続けてしまう。

既存の資料やコードから仕様書を逆算して作る方法

【ひろゆき】【切り抜き】プログラミングに必要な能力は仕様書を書く力です！

既存コードやWeb画面をAIに読ませ、人間へのヒアリングを挟んで仕様書を逆算する方法は、ドキュメントが無い既存機能に有効です。

前述のZenn記事は、まさにこのリバースエンジニアリングのワークフローを扱っています。コードだけ渡すと意図が抜けるので、ヒアリングがセットになっている点が肝です。

既存機能の仕様書をAIで起こす手順

対象機能のコードと画面を渡し、まず「このコードが満たしている要件」をAIに列挙させ、それを人間が確認します。

1. 対象機能のソースコードとWeb画面を用意する。
2. AIに「実装が満たしている要件」を箇条書きで出させる。
3. 曖昧な点をAIから人間へ質問させ、口頭で補う。
4. Gherkin記法でシナリオに落とし込む。
5. 人間が良いシナリオを選び、確定する。

実装コードやテストとの整合性をチェックする

逆算した仕様書は、テストケースや実装と突き合わせて整合性を確認すると信頼度が上がります。

インターフェースをOpenAPIやProtobufで固定しておけば、定義とコードの差分チェックがしやすい。ここは前述のQiitaのスキーマ方針が活きます。仕様とテストがずれている箇所こそ、未決事項として残すべきです。

生成された仕様書の品質を担保するレビューと検証

AI生成仕様書は、正確性・網羅性・一貫性・可読性・トレーサビリティの5観点でレビューし、情報源を人間が辿って確認します。

gruff記事はこの5項目を品質チェックの観点として挙げ、AIが出した情報源を実際に辿り、事実に基づく記述か、必須項目の漏れがないかを人間が確認する方法を説明しています。私はこの5観点をそのままレビュー表の列にしています。

受け入れ基準と品質評価の目安を決める

レビュー前に「何が満たせていれば合格か」を決めておくと、評価がぶれません。

人間による検証プロセスを組み込む

AIの出力は必ず人間が情報源を辿って検証する工程を、フローに固定します。

検証を「あとでまとめて」にすると、量が溜まって形骸化します。私はドラフトが1セクション出るたびに、その場で出典を辿るようにしています。地味ですが、これが一番効きます。

事実誤り（ハルシネーション）への対処

ハルシネーション対策の基本は、AIに事実を生成させず、与えた事実の範囲内で書かせることです。

セキュリティと情報漏洩のリスク対策

機密情報は渡す前に線引きを決め、非機能要件も仕様書に明記して、生成物の責任範囲をルール化します。

正直に言うと、ここを曖昧にしたまま現場でAIを使い始めるのが一番危ない。便利さに引っ張られて、何でも貼ってしまう人を私は何人も見てきました。

AIに渡してよい情報・渡してはいけない情報

個人情報・認証情報・未公開の事業機密は原則として外部AIに渡さない、という線引きを先に決めます。

Qiitaの記事が示すTTLの考え方は、情報衛生にも使えます。古い社内情報をナレッジベースに残し続けないこと。渡す情報は最小限にして、必要なら匿名化やマスキングをかけます。

非機能要件（性能・可用性）の仕様化

性能・可用性・セキュリティなどの非機能要件は、機能要件と同じ重みで仕様書に明記します。

gruff記事のテンプレートにも非機能要件の項目が含まれています。AIは指示しないと機能要件ばかり書くので、「応答時間」「同時接続数」「障害時の挙動」を具体的に問う一文をプロンプトに入れておくと埋まります。

生成物の責任範囲とルール整備

AIが書いた仕様書の最終責任は人間（レビュー担当）にある、と組織のルールに明記します。

出力をそのまま承認する運用は危険です。誰がレビューし、誰が承認したかを変更履歴に残す。これだけで、責任の所在が曖昧になる事故を防げます。

チーム・組織で運用を定着させる仕組み

マニュアル作成はAIを使えば一瞬で終わります！マニュアル作成が簡単にできるツールやスクショ付きで作れるエージェントAIなどご紹介いたします

フォーマットを標準化し、変更履歴を追える形にし、レビューにAIを補助として使うと、組織での運用が定着します。

個人が我流で使うと品質がばらつきます。私のチームでは、テンプレートとプロンプトを共有リポジトリに置き、誰が書いても同じ骨格になるようにしました。

フォーマットの標準化と運用ルール

gruff記事のテンプレート項目を組織の標準フォーマットに採用すると、属人化を防げます。

標準化のコツは、項目を欲張らないこと。最初は概要・機能要件・非機能要件・テスト観点・変更履歴の5つくらいから始め、運用に乗ってから増やします。SIOS記事の「小さく始める」と同じ発想です。

変更履歴の管理と追跡のしやすさ

変更履歴の欄を必須にし、要件→実装→テストを辿れるトレーサビリティを確保します。

仕様書をテキストベースで管理し、バージョン管理ツールに乗せると差分が追えます。誰が・いつ・なぜ変えたかが残るだけで、後の議論が驚くほど楽になります。

ステークホルダーの合意形成にAIを活かす

AIには、立場の異なる関係者向けに同じ仕様を要約し直させると、合意形成の下地づくりに使えます。

技術者向けの詳細版と、非技術者向けの概要版をAIに書き分けさせる。これは私が実際にやって効果を感じている使い方です。ただし要約版でも、事実の確認は人間が行います。

AI仕様書作成のよくある質問（費用・始め方など）

費用は使う生成AIの料金が中心で、始め方は基本要件から小さく試すのが正解です。

最後にひとつ。AIに仕様書を任せて時短する最大のコツは、AIを賢くすることではなく、渡す情報と検証の手順を整えることです。まずは小さい1機能で、今日試してみてください。