設計書のレビューにAIをどう使うか｜AIに確かめさせる観点と、人が判断すること

設計書のレビューにAIを使うと、何が変わるのか

設計書のレビューでは、いくつもの資料を行き来します。要件一覧を見て、画面仕様に戻り、データ定義を開いて整合を確かめる。処理の流れは書かれていても、エラーが起きた場合はどうなるのか。資料が増えるほど、確認に時間がかかります。

生成AIで設計書のたたき台を作るようになって、別の悩みも生まれました。文章が整っているぶん完成度が高く見えて、どの記述を信用し、どこをレビューすればよいのか判断しづらい。チームでAIを使いたくても、何を確かめさせるかが担当者任せでは、指摘の質がそろいません。

私は技術責任者として、50件以上のプロジェクトでPLの進行管理や品質確保に関わってきました。生成AIを活用する開発でも、品質をどの段階で確かめるか、マイルストーンをどう置くかをPLに指導しています。

設計書のレビューでAIを活用しやすいのは、要件が設計に反映されているか、異常時の処理が書かれているか、資料同士が食い違っていないかといった確認です。その指摘を踏まえて、なぜその設計を採るのか、既存システムや顧客の運用に適しているかを判断するのは、設計を担う人の仕事です。

また、AIが作成した設計書では、元の資料と内容が一致しているか、決まっていない仕様をAIが補っていないかも確認します。

ここでは基本設計書・詳細設計書のレビューに絞り、当社のラボ型開発で使っている観点を紹介します。上流工程における役割分担は要件定義で生成AIに任せられる範囲、AIが出したコードの判断はAIが出したコードを、どう判断するかで扱っています。

設計書のレビューでAIに確かめさせるのは、書かれているかどうか

AIに「この設計書をレビューして」と頼むだけでは、一般的な指摘が並ぶことがあります。確認したい観点と比較対象の資料を指定すると、実務で扱いやすい結果になります。私たちがラボ型開発で確認に使っているのは、主に次の項目です。

当社の開発でAIの指摘から見つかることが多いのは、要件を設計に落としきれていない箇所や、データ構造の不足です。設計書を一通り読んだだけでは見落としやすい、資料をまたいだ対応関係を調べる場面で役立っています。

例えば、画面仕様には入力項目が定義されているのに、その値を保存するデータ項目が見当たらない場合。画面だけをレビューしていると気づきにくくても、画面仕様とデータ定義を照合すれば、不足している可能性を指摘できます。

指摘を受け取るときは、問題がありそうな箇所だけでなく、どの資料のどの記述を根拠にしたのかも示させたいところです。根拠が分かればPLや設計者がすぐに照合できます。比較資料に書かれていないことは、誤りと断定せず「確認が必要な事項」として切り分けます。

人が判断するのは、なぜこの設計にするのか

「既存構成との整合」はAIの確認観点にも入っています。ただし、資料に書かれた構成と矛盾していないことと、その構成を採用してよいことは別の話です。既存システムの制約、顧客の運用方法、将来の保守まで含めて考えて、初めて決まります。

例えば、外部システムへの連携が失敗したとき。一定回数の再試行を行うのか、処理を止めて担当者に知らせるのか、それとも後で再送できる状態にするのか。どれも設計案になり得ます。どれが適切かは、二重登録を避ける仕組みはあるか、業務はどの程度止められるか、誰が復旧するかで変わります。

AIには各案の長所やリスクを比較させられます。異常時の処理が未記載なら、それも指摘できます。そのうえで、顧客と何を合意するか、どの案を採るかを決め、選択の理由を説明するのが設計者やPLの役割です。

同じことは、データ構造にも当てはまります。項目不足を見つけるだけなら、要件とデータ定義を照らし合わせればよい。ただ、既存テーブルを拡張するのか、新しいテーブルを設けるのかは、データの持ち方だけでなく、移行方法や他システムへの影響、変更のしやすさも左右します。項目を一つ足せば解決、とはいかないことが多いのです。

レビューする側が確認したいのは、図や文章がきれいに整っているかだけではありません。「なぜこの構成なのか」「別の方法では何が困るのか」を説明できるか。理由が曖昧なまま通してしまうと、実装が進んでから前提の違いが表面化します。

設計書に判断をどう残すか、実装経験から設計へ進む順番は、設計ができないエンジニアは、何から始めるかで詳しく紹介しています。

生成AIで作った設計書は、どこを確かめるか

生成AIに要件資料を渡し、基本設計書や詳細設計書のたたき台を作らせることもあります。厄介なのは、文章が自然で、章立ても整って見えることです。読みやすさは助けになりますが、それだけでは内容の正しさを判断できません。当社で人が必ず確かめるのは、次の三つです。

入力した情報と、出力された設計が一致しているか。 要件の意味が変わっていないか、処理条件や項目名が別のものに置き換わっていないかを確認します。元資料が「担当者による承認後に登録」としているのに、設計書では承認前に登録する流れになっていれば、文章が整っていても修正が要ります。

必要な記述に抜けや不足がないか。 AIは渡された情報を基に書くため、設計に必要な条件がすべて記述されるとは限りません。正常時の処理は詳しいのに、異常時の扱い、入力値の検証、データ更新時の条件が抜けていないかを見ます。何が書かれていないかを探す視点です。

資料にないことを、もっともらしく補っていないか。 ここが特に見逃しやすい。決まっていない保存期間やエラー時の動作を、AIが確定済みの仕様のように書くことがあります。合理的に見える案でも、顧客が決めた仕様と同じ扱いにはできません。

この三つは、設計書をAIで再レビューする際にも使えます。ただし、生成時と同じ不十分な資料だけを基に照合すれば、見落としまで引き継ぐことがあります。未確認の項目や根拠のない補完は明示し、最終的には元の要件と実際の業務条件に立ち返って確かめます。

ラボ型開発での進め方：設計書のAIレビューを具体例で見る

当社のラボ型開発では、顧客の開発案件をチームで進めながら、設計書の品質確認にも生成AIを使っています。レビューの基本的な観点は共通化しつつ、システムの構成や顧客の要件に合わせて、案件ごとに確認項目を調整しています。実際にどう進めるのか。業務システムに承認機能を追加するケースで見ていきます。

1. 要件と設計書をAIに渡す

次のような要件があるとします。

レビュー対象の設計書には、次の内容が書かれています。

• 基本設計書：承認ボタンを押すと、申請ステータスを更新して外部APIを呼び出す
• 詳細設計書：APIの呼び出し処理と、成功時の完了表示を定義
• データ定義書：申請ID、申請ステータス、承認日時を定義

ここで確認したいのは、要件が設計に反映されているか、異常時の処理や必要なデータ項目がそろっているかです。

2. 確認観点を指定してAIにレビューさせる

要件と設計書を渡したうえで、次のように指示します。

要件一覧、基本設計書、詳細設計書、データ定義書を照合してください。

以下の観点でレビューしてください。

• 各要件に対応する設計が記載されているか
• 正常時・異常時の処理が定義されているか
• 処理に必要なデータ項目が定義されているか
• 資料間で矛盾する記述がないか

指摘事項には要件ID、該当する設計書の箇所、問題点、判断の根拠を示してください。情報が不足している場合は推測で補わず、確認事項として挙げてください。

観点と出力形式をここまで指定しておくと、PLや設計者が指摘を検証しやすくなります。

3. AIの指摘を確認する

この例であれば、次のような指摘が考えられます。

当社の実際の開発でも、AIの指摘から要件の反映漏れやデータ構造の不足が見つかることは頻繁にあります。ただ、指摘が出た箇所がすべて設計の不備かというと、そうでもありません。

4. 人が指摘の採否と対応方法を決める

R02については、実際に送信失敗時の処理が抜けているなら、設計を修正します。といっても、「再送処理を追加する」と書き足せば済む話ではありません。二重送信をどう防ぐか、どの画面から誰が再送するのか、外部システム側で登録済みだった場合はどう扱うのか。既存の構成や顧客の運用を踏まえて決めます。

R03は、承認履歴を既存の共通ログ機能で保存している可能性があります。その場合、新しいデータ項目を追加するまでもなく、設計書に既存機能への参照を追記するのが適切かもしれません。

AIが見つけた疑問点を、人が設計上の問題かどうか判断する。 必要なら顧客と確認し、どう修正するかを決めます。

5. 修正した設計書を再レビューする

設計書の修正後は、指摘された箇所だけでなく、変更に伴ってほかの資料に食い違いが生じていないかもAIに確かめさせます。再送機能を追加したなら、基本設計書の画面仕様、詳細設計書の処理、データ定義書の連携状態が対応しているかを確認します。最終的なレビュー完了の判断はPLや設計者が行います。

役立った観点はチーム内に残し、次の案件でも使えるようにしていきます。採用しない指摘もあります。当社では、AIが出す工数見積が一般的な工数より多めになることがあり、そのまま採らないケースが少なくありません。前提情報が不足していると、AIが出力した未決事項一覧を使えないこともありました。AIに何を確認させ、どの指摘を採用するか。その経験をチームの中で積み重ねていくことが、レビューの効果を高めます。

設計書のレビューにAIを使い始める、最初の一歩

最初から網羅的なレビュー基準を作る必要はありません。まず、自分が過去に受けた設計書の指摘を二、三件取り出してみてください。「エラー時の処理がない」「画面の項目がデータ定義にない」といった指摘を、次の設計書でも確認できる問いに直します。

例えば「要件一覧と画面仕様を根拠に、対応する処理やデータが見つからない項目を挙げてください。指摘には該当箇所と根拠を示し、資料だけでは判断できないものは未確認としてください」とAIに渡す。範囲を絞るほうが、出力の妥当性を確かめやすくなります。

最後に、自分ならその指摘を採用するかを考えます。AIが作った設計書なら、元資料にない仕様が書き足されていないかも確認する。自分が一度つまずいた点を次のレビューで繰り返さないことから始めれば十分です。

設計を判断できる人が、AIを使う現場で担えること

設計書のレビューにAIを取り入れると、資料を照らし合わせる作業の一部をAIに任せ、その設計を採用する理由や品質上のリスクに目を向けやすくなります。指摘を多く挙げる人よりも、指摘の意味を理解し、関係者と合意して設計を前に進められる人の役割が広がります。

当社が掲げる「開発推進力」を構成する能力の一つが「判断する力」です。正解が一つに決まらないとき、技術的な選択肢と顧客の事情を踏まえ、何を採るか決める。AIを活用する開発でも、この力を磨く機会は設計やレビューの中にあります。

実装を中心に経験してきた人なら、まずは自分が関わる機能の設計を確認し、指摘に答える経験を増やす。その先には、基本設計や受入観点の整理を担うSE・PLの仕事があります。当社では上流SE・PL候補（AI活用）を募集しています。

さらに、複数のラボ型開発案件を見渡し、PM・PL・テックリードを助言とレビューで支える立場もあります。レビューの経験をチームの品質向上につなげたい方には、開発部長候補（AI活用型ラボ開発責任者）という役割があります。

AIを使って設計書を確かめる経験は、自分が設計する力を磨くことにも、チームの判断を支える役割に進むことにもつながります。

この記事のテーマについて、もっと話を聞いてみたい方へ：

• カジュアル面談を申し込む — 30〜45分のオンライン面談
• 募集職種を見る — AIを活用した開発に関わる求人を含む一覧
• 要件定義で生成AIに任せられる範囲 — 上流工程でのAIの使い方
• 設計ができないエンジニアは、何から始めるか — 設計書を書く側の順番
• 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事