設計書を書くのに毎回何時間もかかって、本来の開発に集中できていない…そんな経験はありませんか？
仕様書、API設計書、DB設計書、クラス設計書——エンジニアの仕事には「書かなければいけないドキュメント」が山ほどあります。でも、コードを書く時間と同じくらい、あるいはそれ以上の時間をドキュメント作成に費やしてしまっている現実があります。
この記事では、ChatGPTやClaudeなどのAIを活用して、設計書作成を10倍速くするための具体的なプロンプトと手順をまとめています。読み終わる頃には「明日から使える」実践的な方法が手に入ります。
結論：AIへの「伝え方」を変えるだけで設計書作成は劇的に速くなる
設計書の作成で悩んでいませんか？
- 「何を書けばいいかわかってはいるけど、文章にするのが面倒」
- 「毎回ゼロから書くのが辛い」
- 「レビューで指摘されるたびに書き直しが発生する」
こうした悩みの根本は、「AIの使い方が曖昧なまま使っている」 ことにあると私は感じています。
AIは「なんとなく使う」だけでもそこそこ役に立ちますが、設計書に特化したプロンプトの型を持つことで、出力の質とスピードが一気に変わります。
結論として、AIで設計書を10倍速く書くためのポイントは以下の3つです。
| ポイント | 内容 |
|---|---|
| ① 設計書の種類を明示する | 何の設計書かをAIに正確に伝える |
| ② 背景・制約をセットで渡す | システム概要・技術スタックを一緒に伝える |
| ③ 出力フォーマットを指定する | 表形式・Markdown・見出し構成を先に指示する |
なぜ「AIに丸投げ」では設計書が使い物にならないのか
AIを使えば設計書が一瞬でできると思っていたのに、実際に出てきたものは「なんか違う」「使えない」——そう感じた経験がある方も多いと思います。
原因はシンプルです。AIはコンテキストがないと、汎用的で表面的な設計書しか作れないからです。
たとえば「API設計書を作って」とだけ伝えると、AIはどんなシステムか、どんなチームか、どんな技術スタックかを知らないまま回答します。結果として出てくるのは、どこにでもある教科書的な設計書です。
逆に言えば、適切な情報をAIに渡せば、実務で使えるレベルの設計書が数分で作れます。私自身、この方法に切り替えてから設計書作成の時間が体感で1/5以下になりました。
ポイントは「AIを賢くしようとするのではなく、AIが賢く動けるように情報を整えること」です。設計書作成において、AIはあくまでも優秀なライティングアシスタントです。判断や設計の主体はあくまでエンジニアである自分自身。その役割分担を意識するだけで、AIの使い方が大きく変わります。
設計書の種類別・AIプロンプト実践集
ここからが本題です。設計書の種類ごとに、そのまま使えるプロンプトテンプレートを紹介します。
① 機能設計書（仕様書）
プロンプト例：
以下の情報をもとに、機能設計書をMarkdown形式で作成してください。
【機能名】ユーザーログイン機能 【概要】メールアドレスとパスワードによる認証 【システム】Webアプリ（React + Node.js + PostgreSQL） 【留意事項】セッション管理、エラーハンドリング、ロック機能（5回失敗でロック）
出力形式：
機能概要
処理（フロー番号付きリスト）
入出力定義（表形式）
エラーケース一覧（表形式）
留意事項・留意事項
ポイント： 「出力形式」を明示することで、レビュアーが求める構成に近い設計書が一発で出てきます。
② API設計書
プロンプト例：
以下の仕様をもとに、REST APIの設計書をMarkdown形式で作成してください。
【エンドポイント】POST /api/v1/users/login 【用途】ユーザー認証 【リクエスト】メール（string, 必須）、パスワード（string, 必須） 【応答】成功時：JWT トークン / 失敗時：エラーコードとメッセージ 【認証】不要（ログイン前のため）
出力形式：
エンドポイント情報（表形式）
リクエスト仕様（表形式：パラメータ名/型/必須/説明）
応答仕様（表形式：ステータスコード/説明）
エラー一覧（表形式）
サンプルリクエスト・レスポンス（JSON形式）
ポイント： サンプルのJSONまで出力させることで、フロントエンドエンジニアとの認識齟齬が大幅に減ります。
③ DB設計書（テーブル定義書）
プロンプト例：
以下の要件をもとに、ユーザーテーブルのDB設計書をMarkdown形式で作成してください。
【システム】ECサイト 【フォルダデータ】ユーザーID、メールアドレス、パスワード（ハッシュ）、氏名、日付、最終ログイン日時、登録ステータス（アクティブ/非アクティブ） 【DB】PostgreSQL 【留意事項】削除対応、タイムスタンプ管理
出力形式：
テーブル概要
カ定義ラム（表形式：カラム名/データ型/NULL確実/確実値/説明）
インデックス定義
備考・メモ
④ クラス設計書
プロンプト例：
以下の要件をもとに、TypeScriptのユーザークラスの設計書をMarkdown形式で作成してください。
【役割】ユーザーエンティティの管理 【言語】TypeScript 【主な処理】ユーザー情報の保持、バリデーション、パスワードのハッシュ化
出力形式：
クラス概要
プロパティ一覧（表形式：名前/型/アクセス修飾子/説明）
メソッド一覧（表形式：メソッド名/引数/戻り値/説明）
依存関係
エンジニアなら読むべき本を紹介しています。
→記事を読む
AIで設計書を書く際の「よくある失敗」と対策
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| 内容が薄くて使えない | コンテキストが不足している | システム概要・技術スタックを必ず添える |
| フォーマットがバラバラ | 出力形式を指定していない | テンプレートで形式を明示する |
| 何度も修正が発生する | 要件を曖昧に伝えている | 「考慮事項」「制約」を事前にまとめておく |
| レビューで大幅に差し戻される | チームの設計書の型と合っていない | 既存の設計書のサンプルをAIに渡してフォーマットを学習させる |
既存の設計書をAIに渡すのは特に効果的な方法です。「このフォーマットに合わせて書いて」と伝えるだけで、チームのルールに沿った設計書が出力されます。
AIを使った設計書作成の全体ワークフロー
私が実際に使っているワークフローをまとめると、以下のようになります。
要件をメモ書きレベルで箇条書きにする（5〜10分）
設計本の種類を決める
テンプレートプロンプトに情報を埋め込む（3〜5分）
AIに出力させる（30秒〜1分）
出力をチェックして不足部分を追記・修正（10〜20分）
レビュー提案
全体で30〜40分 あれば、以前なら半日かかっていた設計書が完成します。ポイントは「ステップ1の箇条書き」をしっかりやること。ここに時間を使うほど、AIの出力精度が上がります。
まとめ
- AIで設計書を速く書くには**「設計書の種類・背景・出力形式」の3点セット**をプロンプトに含めることが重要
- 汎用プロンプトではなく、設計書の種類に特化したテンプレートを持つことが実用化のカギ
- AIは「賢くさせる」のではなく「賢く動ける環境を整える」という発想で使うと効果的
- 既存の設計書をサンプルとして渡すことで、チームのフォーマットに合わせた出力が可能
設計書作成は「エンジニアの本来業務じゃない」と感じている方も多いと思います。でも、チームで開発する以上、ドキュメントの質はプロダクトの質に直結します。AIをうまく活用して、書く時間を減らしながらも、質の高い設計書を残せるエンジニアを目指してみてください。
おすすめ本の紹介
エンジニアとして基礎力がつくおすすめの技術本を下記の記事で紹介しています。
→記事を読む