AI設計書の自動生成は可能？後から困らない残し方

AIで設計書やドキュメントを自動生成することは、すでに現実的な選択肢になっています。ただし、AIが作れるのは「今のコードや仕様がどうなっているか」の説明が中心で、「なぜそう決めたのか」は人が残さない限り消えてしまいます。この記事では、AIに任せられる範囲、後から困りやすい場面、残しておきたい記録の種類、確認の進め方を順に整理します。

AIで設計書は自動生成できる？任せられる範囲

結論から言うと、設計書の「下書き」や「現状の説明」はAIが得意です。一方で、設計書の価値を決める「判断の背景」は、AIだけでは作れません。まず、何ができて何ができないのかを分けて考えます。

AIが得意な書類づくり

生成AI（GPTやClaudeなどの大規模言語モデル、LLM）は、文章やコードを読み取って別の形に整理し直す作業が得意です。設計書まわりでは、たとえば次のようなものを短時間で下書きできます。

• ソースコードの構成や、各機能の役割の説明文
• データベースの定義（テーブルを作る命令文など）をもとにした、項目の一覧と説明
• 画面の遷移や処理の流れを、テキストで図にする記法（Mermaidなど）で書いた図
• APIの入出力をまとめた仕様書（OpenAPIなどの記述形式）の下書き
• 仕様のやりとりをまとめた議事録や、要件の箇条書きの整理

人が一から書くと手間がかかる、地味だが量の多い書類ほど、AIに向いています。書く負担が下がるぶん、「書類がないまま開発が進む」という昔からの問題は減らしやすくなります。

AIだけでは作れないもの

反対に、コードや資料に書かれていない情報は、AIには読み取れません。たとえば次のような内容です。

• この機能を、なぜ今回は作らないと決めたのか
• 事業として何を確かめたくて、その機能を入れたのか
• 候補が複数あったなかで、なぜその方式を選んだのか
• 運用で守るべき取り決めや、社内の事情

AIはそれらしい理由を文章にすることはできますが、実際の経緯とは違う「もっともらしい説明」になる危険があります。資料にない理由を補って書いてしまうことがあるため、判断の背景は人が記録する前提で考えるのが安全です。

自動生成した設計書で後から困る3つの場面

設計書を自動生成できても、使えない書類が増えてしまうと意味がありません。新規事業のシステムでは、特に次の3つの場面で困りやすくなります。

コードの「何を」は書かれても「なぜ」が残らない

コードから生成した設計書は、「この関数は注文データを受け取り、在庫を確認する」といった、事実の説明になります。これ自体は有用です。しかし半年後に「なぜ在庫確認をこの順番にしたのか」「なぜこの項目は持たないことにしたのか」を知りたくなったとき、答えがどこにも残っていません。

新規事業では、仕様が頻繁に変わります。変えた理由が記録されていないと、後任の担当者や別の開発会社が「前の判断を知らずに、同じ検討をやり直す」「過去に外した案を、また採用する」といった無駄が起きます。

実装と設計書がズレていく

AIで素早く作れるようになると、コードの変更も速くなります。設計書だけが古いまま取り残され、実装とズレるのは、AI時代でも変わらない課題です。むしろ変更の頻度が上がるぶん、ズレるスピードも上がります。

ズレた設計書は、無いよりも厄介です。読み手は正しいと思って判断するため、誤った前提で改修を進めてしまいます。「いつ時点のコードをもとに作った書類か」を、書類の側に残しておく必要があります。

量が多すぎて、誰も読まなくなる

AIは文章をいくらでも生成できるため、各ファイルの説明まで網羅した大量の書類ができあがりがちです。分量が多いと、本当に重要な情報が埋もれます。

読まれない書類は、更新もされません。「全部を残す」ことよりも、「後から困る情報を、探せる形で残す」ことが大切です。システムの保守や引き継ぎの観点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点でも整理しています。

後から困らないために残したい5種類の記録

では、何を残せばよいのでしょうか。新規事業のシステム開発では、次の5種類を押さえておくと、後から困る場面をかなり減らせます。どれも大がかりな書類である必要はなく、1〜2ページでも役に立ちます。

1. 目的と前提の記録

「このシステムで何を確かめたいのか」「誰のどんな課題を解くのか」「成功をどう判断するのか」を短くまとめた書類です。新規事業では、システムそのものが事業の形になることがあるため、事業の仮説とシステムの機能が結びついていることが大切です。

この記録がないと、機能を追加するときに「事業の目的から見て必要か」を判断できません。検証の指標の決め方はMVP検証の指標を先に決める方法｜判断基準の作り方が参考になります。

2. 要件と、作らないことの記録

作る機能の一覧だけでなく、「今回は作らないと決めたこと」と、その理由を残します。後回しにした機能が記録されていれば、次に何を作るかを議論するときの出発点になります。

要件の整理そのものは、AIが下書きを作り、人が決める役割分担が現実的です。詳しくはAI要件定義で変わること｜AIが整理し人が決める範囲で触れています。要件の考え方の基本は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方も参考になります。

3. 構成図とデータ設計

システムがどの部品で構成され、データをどう持つかを示す図と一覧です。ここは、AIがコードや定義から自動生成しやすい領域です。ただし、データの持ち方は後から変えるのが大変なため、「なぜその持ち方にしたか」の一言も添えておくと安心です。

データ設計の考え方は新規事業のデータ設計｜最初に決めたい5つの持ち方に、AIとの役割分担はAI設計でDB設計はどこまで任せる？役割分担の考え方にまとめています。

4. 判断の記録（決定ログ）

設計や仕様で「何を選び、何を選ばなかったか、その理由」を1件ずつ残すものです。ソフトウェア開発の世界では、ADR（Architecture Decision Record、設計判断の記録）と呼ばれる考え方があり、1つの判断を短い文章で残していきます。

書き方は、次の4点があれば十分です。

• 決めたこと（例：会員情報と決済情報を別のデータとして持つ）
• 検討した他の案
• 選んだ理由
• 決めた日と、決めた人

この記録は、AIが自動で作れない部分を補う、いちばん価値の高い書類です。打ち合わせの後に、人が数行書くだけで構いません。AIに議事録を要約させ、人が内容を確認して決定ログに転記する、という使い方なら負担も小さく済みます。

5. 運用と引き継ぎの情報

開発環境の構築手順、システムが外部のどのサービスとつながっているか、誰がどんな権限を持つか、障害時に誰が何をするか、といった情報です。これが欠けると、担当者が変わったり、開発会社を切り替えたりするときに、システムを動かし続けること自体が難しくなります。

開発会社の切り替えを考えるときの確認点は、システム開発会社の乗り換え前に確認したい引き継ぎの要点にまとめています。パスワードなどの機密情報は書類に直接書かず、管理方法だけを記録するのが基本です。

AIに設計書を作らせる進め方

書類の種類が決まったら、AIに作らせる手順を整えます。思いつきで依頼するのではなく、入力・形式・確認・更新を決めておくと、品質が安定します。

入力をそろえる

AIに渡す材料の質が、設計書の質を決めます。コードだけを渡すと「何を」の説明にとどまるため、目的と前提の記録や、要件の一覧も一緒に渡します。そうすると、機能の説明が事業の目的と結びついた形になります。

仕様の伝え方については、AI開発の仕様の伝え方｜作りたいものを言葉にする手順が参考になります。なお、設計書づくりに外部のAIサービスを使う場合は、事業のアイデアや顧客情報などの機密が含まれていないかを事前に確認してください。確認の観点は生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアに整理しています。

書式（テンプレート）を決めておく

AIに毎回自由に書かせると、書類ごとに見出しや粒度がバラバラになります。あらかじめ、次のような項目の枠を決めて渡します。

• 概要（1〜3行）
• 対象範囲と、対象外のこと
• 入力と出力
• 主な処理の流れ
• 関連する決定ログへの参照
• 作成日と、もとにしたコードの版（バージョンや日付）

「もとにしたコードの版」を入れておくと、前述の「実装とのズレ」に気づきやすくなります。

「分からないことは分からないと書く」よう指示する

AIは、情報が足りないときにも、それらしい文章で埋めてしまうことがあります。そのため、「資料から読み取れない点は推測せず、『不明』として一覧にする」と指示します。不明点の一覧は、そのまま人が確認すべき項目になります。

この指示を入れるだけで、AIが作った書類の「もっともらしい誤り」を見つけやすくなります。

コードの近くに置く

書類は、コードと同じ管理場所（リポジトリ）に、文章ファイルとして置くのが扱いやすい方法です。コードを変更するたびに書類の更新も一緒にレビューでき、変更の履歴も残ります。Mermaidのように、図もテキストで書いておけば、差分が分かりやすくなります。

人が確認したいポイントと更新の習慣

AIが書いた設計書は、人が確認して初めて「使える書類」になります。確認の観点と、更新を続けるための習慣を整理します。

確認したい5つの観点

すべてを読み込む必要はありません。次の観点に絞ると、確認の負担を抑えられます。

• 事業の目的と、書類に書かれた機能の説明が食い違っていないか
• 「不明」とされた点に、人が答えを埋められているか
• 実際の画面やデータの動きと、書類の記述が合っているか
• 「作らないこと」や制約が、書類に反映されているか
• 機密情報や認証情報が、書類に書き込まれていないか

とくに3つ目は、実物を触って確かめるのが最も確実です。文章だけを読んで「合っているはず」と判断すると、見落としが残ります。AI開発で人が確認する範囲の考え方は、AI開発でも品質には人の確認が必要な理由でも触れています。

更新を「作業の一部」にする

書類は、作った直後がもっとも正確で、放っておくと古くなります。更新を続けるためには、特別な作業にせず、次のような流れに組み込むのが現実的です。

• 仕様変更や機能追加の作業に、「関連する書類の更新」を含めて完了とする
• 更新の下書きはAIに作らせ、人が差分を確認する
• 月に一度など、書類の日付と実際のシステムのズレを見直す機会を設ける

仕様変更が多い新規事業では、変更の扱い方をあらかじめ決めておくことも大切です。システム開発の仕様変更への対応｜追加要望の扱い方が参考になります。

書類を増やしすぎない

更新を続けるためには、書類の数を絞ることも大切です。最初は「目的と前提」「要件」「構成とデータ」「決定ログ」「運用情報」の5種類に絞り、足りないと感じたものだけを足していく形が続けやすくなります。プロトタイプや小さな検証の段階であれば、1つのファイルにまとめても構いません。

発注するときに確認したいドキュメントの扱い

自社で作る場合だけでなく、開発会社に依頼する場合にも、書類の扱いは確認しておきたい項目です。AIで開発のスピードが上がるほど、書類が後回しになりやすいためです。

契約前に聞いておきたいこと

開発を依頼する前に、次のような点を確認しておくと、納品後に困りにくくなります。

• どんな書類が、どの形式で納品されるのか
• 書類は、コードと一緒に引き渡されるのか
• 判断の記録や、運用情報は含まれるのか
• 書類の更新は、改修のたびに行われるのか
• 書類を作るときに、外部のAIサービスへどんな情報を渡すのか

この確認の観点は、AIシステム開発の依頼前に確かめたい6つのことともつながります。権利の面では、書類やコードの帰属も確認しておきたい点です。システム開発の著作権帰属は誰のもの？契約前の確認点で整理しています。

納品時の確認に書類を含める

納品の確認（検収）では、動作の確認に意識が向きがちですが、書類の確認も同じくらい大切です。引き継ぎの情報がそろっていれば、別の担当者や別の会社でも改修を続けられます。システム開発の検収とは｜納品時の確認項目と進め方に、確認項目の考え方があります。

AI生成コードの保守については、AI生成コードの保守は可能か｜引き継ぎと改修の確認点もあわせて読むと、書類とコードを一体で考えやすくなります。

まとめ

AIによる設計書の自動生成は、構成の説明、データ定義の一覧、図、API仕様の下書きなど、「今どうなっているか」を整理する用途では十分に実用的です。一方、「なぜそう決めたか」「何を作らないと決めたか」といった判断の背景は、人が残さなければ消えてしまいます。

後から困らないための要点は、次の4つです。

• 残す書類を「目的と前提」「要件と作らないこと」「構成とデータ設計」「決定ログ」「運用と引き継ぎ」の5種類に絞る
• AIには、入力・書式・「不明は不明と書く」という指示を決めて下書きを任せる
• 人は、事業の目的との整合や、実物との一致を確認する
• 書類の更新を、仕様変更や機能追加の作業に組み込む

AIで開発が速くなるほど、決めた理由を残す習慣の価値は高まります。書類は量よりも、後から探せて、今のシステムと合っていることが大切です。

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。複数の専門AI（要件定義・設計・DB設計・実装・テスト・レビュー）がチームで開発を進める独自の基盤「LAF」を使い、人は「何を作るかを決めること」と「品質の最終判断」を担います。AIの仕組みの違いはAI開発フレームワークとは｜LLMだけの開発との違いで解説しています。仕様が固まっていない段階でも相談できますので、どんな資料を残しておくべきか迷うときは、JustFitのサービス紹介から、お気軽にご相談ください。