テンプレートはダウンロードした。でも、真っ白なシートを前にして止まっている。
設計書づくりでいちばん時間を食うのは、様式を整えることではありません。項目を1つずつ埋めていく作業です。画面定義書なら、項目名・型・桁数・必須有無・初期値・入力チェック・表示条件を、画面の数だけ書くことになります。
この部分は、生成AIにかなりの割合を任せられます。ただし任せられる範囲と、任せてはいけない範囲がはっきり分かれます。この記事では、要件メモから画面定義書を起こす具体的な手順と、その境界線をまとめます。
なぜ設計書はAIと相性がいいのか
設計書の記述には、元になる情報が必ずどこかに存在しているという特徴があります。
業務のヒアリングメモ、既存システムの画面、Excelの管理台帳、あるいは口頭で決まった仕様のチャット履歴。設計書を書く作業の大部分は、ゼロから発明することではなく、散らばっている情報を決まった形式に整えることです。
そして「散らばった情報を、決まった形式に整える」は、生成AIが最も得意とする作業です。
逆に言えば、元になる情報が無い状態でAIに投げても、それらしい嘘が返ってくるだけです。ここが最初の分岐点になります。
用意するもの
手順に入る前に、入力を揃えます。ここが揃っていないと、後の工程がすべて空回りします。
| 入力 | 具体例 | 無いとどうなるか |
|---|---|---|
| 業務の説明 | 誰が、いつ、何のためにこの画面を使うか | 項目の要否を判断できない |
| 扱うデータ | 項目名の一覧、既存台帳のヘッダー行 | 項目が創作される |
| 画面のたたき台 | 手描きのラフ、既存画面のキャプチャ | レイアウトが一般論になる |
| 記入先の様式 | 使う設計書テンプレートの見出し行 | 出力形式が毎回変わる |
4つ目が意外と重要です。出力先の様式を先に見せておくと、そのまま貼り付けられる形で返ってきます。 様式を渡さずに書かせると、整形し直す手間が発生し、時短になりません。
様式は画面定義書のテンプレートをそのまま使えます。
手順
① 項目定義を起こさせる
最初に作るのは項目定義です。画面に載せる項目を、型・桁数・必須有無・初期値まで含めて一覧にします。
このとき、業務の説明と扱うデータを一緒に渡すのが要点です。項目名だけを渡すと、型や桁数は一般的な値で埋められます。「この項目は何のために存在するのか」が分かっていれば、AIは適切な型を選べます。
出てきた一覧は、そのまま採用せず次の3点だけを人が確認します。
- 桁数：業務上の最大値を反映しているか（AIは無難な値を置きたがります）
- 必須有無：運用上、空で登録される場面が本当に無いか
- 初期値：登録時と更新時で挙動が変わらないか
② 入力チェックと表示条件を詰める
項目が固まったら、チェック仕様と表示条件を書かせます。ここはAIが得意な領域です。
「この項目とこの項目は、どちらか一方が必須」「この区分のときだけ表示する」といった条件の網羅は、人が手で書くと必ず漏れます。AIに一度洗い出させてから、不要なものを削るほうが速く、そして漏れません。
足し算より引き算にするのがコツです。「考えられるチェックを全部挙げて」と依頼し、そこから落としていきます。
画面に出すメッセージの文言と、選択リストの値は、それぞれ別の資料に切り出しておくと後の変更が楽になります。
③ 画面間の整合を取る
1画面ずつ作っていくと、画面をまたいだところで必ず矛盾が出ます。同じデータなのに画面Aでは必須、画面Bでは任意。同じ項目名なのに桁数が違う。
ここでのAIの使い方は、書かせることではなく突き合わせさせることです。作成済みの複数画面の項目定義をまとめて渡し、「同じ項目で定義が食い違っているものを挙げて」と聞きます。
この用途は、人がやると見落とすがAIは見落とさない、という典型例です。画面全体の構成は画面一覧、遷移の流れは画面遷移図で管理し、そちらとも突き合わせます。
④ レビュー観点で自己点検させる
提出前に、レビューする側の視点で自分の成果物を点検させます。
「この設計書をレビューする立場で、指摘すべき点を挙げて」と依頼するだけです。実際のレビューで出る指摘の何割かは、この時点で潰せます。
観点を明示的に渡すと精度が上がります。何を見るべきかは設計・開発・テストのレビュー観点にまとめています。
AIに任せてはいけないところ
ここが本題です。次の3つを渡すと、成果物の価値そのものが失われます。
1. 業務上の判断
「この項目は必須にすべきか」は、技術の問題ではなく業務の問題です。必須にすれば入力漏れは防げますが、現場が値を持っていない場面があれば運用が止まります。
AIはこの判断を「一般的にはこうです」で埋めてきます。もっともらしく見えるので、そのまま通ってしまうのがいちばん危険です。
2. 決まっていないことを決めること
仕様が固まっていない箇所をAIに投げると、決まっていないという事実が消えます。何かが書かれた設計書は「決まったもの」として下流に流れ、実装され、テストで初めて食い違いが露見します。
未決事項は未決事項として残すのが正解です。空欄のままにする、あるいは「要確認」と明記して、決める場に持ち込みます。
3. 最終的な事実確認
出力された内容が、実際のデータや既存システムの挙動と一致しているか。ここは必ず現物で確認します。
AIは、それらしい嘘を、正しい文章と同じ自信で書きます。 設計書は下流の全工程の前提になるため、誤りが1つ紛れ込むと、実装とテストの両方をやり直すことになります。
うまくいかないときの原因
| 症状 | 原因 | 対処 |
|---|---|---|
| 項目が創作される | 元になるデータを渡していない | 既存台帳のヘッダー行など、実物を渡す |
| 出力形式が毎回変わる | 様式を見せていない | テンプレートの見出し行を先に渡す |
| 一般論しか返ってこない | 業務の説明が抜けている | 誰がいつ何のために使う画面かを書く |
| 整形し直す手間が大きい | 一度に多くを書かせすぎ | 1画面ずつ、項目定義→チェック→表示条件の順に分ける |
| レビューで大量に指摘される | 手順④を飛ばしている | 提出前に観点を渡して自己点検させる |
いちばん多いのは1番目です。入力の質が、そのまま出力の質になります。
この作業で何が変わるか
正直に書くと、AIを使っても設計書づくりが一瞬で終わるわけではありません。
変わるのは、時間の使い道です。項目を1つずつ書き写す作業と、様式を整える作業がほぼ無くなります。その分を、業務上の判断と、未決事項を決める場づくりに回せます。
設計書の品質を決めているのは、もともと後者です。前者に時間を取られて後者が薄くなっていたのが、多くのプロジェクトの実態でした。そこが入れ替わるというのが、この作業のいちばん大きな効果だと考えています。
まとめ
- 設計書は元になる情報が必ず存在するため、生成AIと相性がよい
- 入力を4つ揃える。出力先の様式を先に渡すと、貼り付けられる形で返ってくる
- 手順は項目定義 → チェックと表示条件 → 画面間の整合 → 自己点検の4ステップ
- 業務上の判断・未決事項の決定・事実確認は人が持つ。 ここを渡すと成果物の価値が消える
- 変わるのは総時間より時間の使い道。書き写す作業が減り、決める作業に回せる
実際にどう指示を組み立てるか、どこまで一度に投げるかは、扱うシステムや体制によって変わります。手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。
