生成AIで設計書レビュー プロンプトと観点テンプレート集

生成AIに設計書をレビューさせるときは、1回のプロンプトで全部を見させず、「①用語と表記ゆれ → ②文書内の矛盾 → ③要件との突き合わせによる抜け漏れ → ④観点別チェック」の4段に分けると、指摘がそろい、人が確かめやすくなります。 「この設計書をレビューして」の1行では、AIは何をどこまで見るかを自分で決めることになり、指摘の粒度も毎回変わります。

この記事は、設計書・仕様書という文書を点検するプロンプトだけを扱います。4段それぞれのプロンプト全文、指摘を表で返させる出力テンプレート（Markdownとタブ区切り）、設計書の種類別の観点一覧30項目、人とAIの分担表を、架空の「備品予約システム」の記入例つきで載せました。設計書をAIに書かせる方法、レビュー会の進め方、ソースコードのレビューは対象外です。

確認環境：Ubuntu 24.04.4、Python 3.11.15（確認日 2026-10-05）。行番号を付けるコード、要件IDを照合するコード、指摘表を検査するコードは、この環境で実行した出力を載せています。プロンプトの組み立ては、同日に開いた Anthropic・OpenAI・Google の公式ドキュメントの記載に沿っています。この記事はテンプレート集で、指摘表は手で書いた記入例です（AIの回答例は載せていません）。

この記事の結論

• レビューは4段に分けて、1段につき1つのプロンプトで頼む（順番は 用語 → 矛盾 → 抜け漏れ → 観点別）
• 設計書は行番号つきで渡し、指摘には原文の引用を必ず付けさせる
• 出力は「箇所・種別・重大度・根拠の引用・修正案」の表に固定する
• 引用が本当に原文にあるかは、コードで機械的に照合できる
• 仕様として正しいかどうかの判断は人が行い、AIには照合と列挙を任せる

設計書レビュープロンプトの早見表

なぜ1回で全部を見させず4段に分けるのか

分ける理由は3つあります。

順番にも意味があります。用語がそろっていないと矛盾は探せず、文書の中が食い違ったままだと要件との突き合わせがぶれます。 文書の内側から外側へ、機械的に照合できるものから判断が要るものへ、という順に進めます。

公式ドキュメントにも、この分け方を支える記載があります。Google の Gemini API のガイドは、複雑なプロンプトについて「より単純な要素に分ける」ことと、順番につなぐやり方を挙げています。Anthropic のガイドは、途中の出力を確かめたいときにはプロンプトを段階に分けるやり方が引き続き役に立つとし、長い文書を扱うときは関連する部分を先に引用させることを勧めています。この記事の「引用を必ず付けさせる」はこの記載に沿ったものです。

準備：題材と行番号の付け方

題材（架空の備品予約システムの基本設計書）

説明用に、わざと表記ゆれ・矛盾・抜け漏れを入れた短い設計書を用意しました。ファイル名は design.md です。

# 備品予約システム 基本設計書（抜粋）

## 1. 用語
- 利用者：備品を予約する社員。
- 管理者：備品の登録と予約の承認を行う社員。

## 2. 画面：予約登録（SC-010）
- ユーザーは備品、開始日時、終了日時を入力して予約を登録する。[REQ-001]
- 予約できるのは利用日の30日前から。[REQ-002]
- 1回の予約は最長7日間とする。[REQ-003]
- 登録後、予約番号を画面に表示する。

## 3. テーブル：reservation
- 予約ID（reservation_id）：主キー。
- 状態（status）：申請中、承認済、取消の3種類。
- 利用期間は最長14日間とし、アプリケーションで検査する。

## 4. バッチ：リマインド通知（BT-020）
- 毎日 8:00 に起動し、当日に開始する予約の利用者へメールを送る。[REQ-005]
- 状態が「承認済み」の予約を対象とする。
- 送信できなかった場合は適切に処理する。

## 5. 非機能
- 画面の応答は速やかに行う。[REQ-006]

要件一覧はタブ区切りの requirements.tsv です。

要件ID    要件
REQ-001 利用者は備品と利用期間を指定して予約を登録できる
REQ-002 予約は利用日の30日前から受け付ける
REQ-003 1回の予約は最長7日間とする
REQ-004 管理者は予約を承認または差し戻しできる
REQ-005 利用開始日の朝にリマインドのメールを送る
REQ-006 予約登録画面は3秒以内に応答する

行番号を付けて渡す

指摘の「箇所」を1行単位で示させるために、設計書に行番号を付けてから渡します。

import sys

path = sys.argv[1]
with open(path, encoding="utf-8") as f:
    for no, line in enumerate(f, start=1):
        print(f"L{no:03d}: {line.rstrip()}")

python3 number_lines.py design.md

実行結果です。

L001: # 備品予約システム 基本設計書（抜粋）
L002: 
L003: ## 1. 用語
L004: - 利用者：備品を予約する社員。
L005: - 管理者：備品の登録と予約の承認を行う社員。
L006: 
L007: ## 2. 画面：予約登録（SC-010）
L008: - ユーザーは備品、開始日時、終了日時を入力して予約を登録する。[REQ-001]
L009: - 予約できるのは利用日の30日前から。[REQ-002]
L010: - 1回の予約は最長7日間とする。[REQ-003]
L011: - 登録後、予約番号を画面に表示する。
L012: 
L013: ## 3. テーブル：reservation
L014: - 予約ID（reservation_id）：主キー。
L015: - 状態（status）：申請中、承認済、取消の3種類。
L016: - 利用期間は最長14日間とし、アプリケーションで検査する。
L017: 
L018: ## 4. バッチ：リマインド通知（BT-020）
L019: - 毎日 8:00 に起動し、当日に開始する予約の利用者へメールを送る。[REQ-005]
L020: - 状態が「承認済み」の予約を対象とする。
L021: - 送信できなかった場合は適切に処理する。
L022: 
L023: ## 5. 非機能
L024: - 画面の応答は速やかに行う。[REQ-006]

Word や Excel の設計書は、章番号や表の行番号、セル番地（例：シート名とA5）がそのまま「箇所」になります。本文を文字として貼る場合は、章番号を先頭に残しておくと指摘の場所を追いやすくなります。

共通の出力テンプレート（指摘表）

4段すべてで同じ表を返させます。列をそろえておくと、段をまたいで1枚の表にまとめられます。

列の定義

重大度の基準は、プロンプトの中に書いて渡します。

出力形式の指定（Markdownの表で返させる場合）

次のかたまりを、各段のプロンプトの末尾に貼ります。

<output_format>
指摘を、次の列を持つ Markdown の表で返してください。表の前後に説明文は書きません。

| No | 箇所 | 種別 | 重大度 | 根拠の引用 | 指摘 | 修正案 |
|---|---|---|---|---|---|---|

- 箇所：行番号（L008 の形）。2か所にまたがるときは「L010 / L016」。
- 種別：表記ゆれ・矛盾・抜け漏れ・あいまい・誤り のどれか1つ。
- 重大度：高（そのまま作ると要件と違うものができる）・中（作る人で解釈が分かれる）・低（読み手が迷う）のどれか1つ。
- 根拠の引用：設計書の文をそのまま写す。言い換えや省略をしない。該当する記述が無いときは「（該当する記述なし）」と書く。
- 指摘：1〜2文。設計書に書かれていないことを補って述べるときは「推測：」で始める。
- 修正案：置き換える文をそのまま書く。決める人が要るときは「要確認：」で始めて、決めるべきことを書く。
- 指摘が無いときは、表の代わりに「指摘なし」とだけ書く。
</output_format>

出力形式の指定（タブ区切りで返させる場合）

表計算ソフトに貼りたいときは、こちらに差し替えます。

<output_format>
指摘を、タブ区切りのテキストで、コードブロックの中に返してください。
1行目は見出しで、次の7列です。
No  箇所  種別  重大度 根拠の引用   指摘  修正案
- 1つの指摘を1行に書く。セルの中で改行やタブを使わない。
- 種別は 表記ゆれ・矛盾・抜け漏れ・あいまい・誤り のどれか1つ。
- 重大度は 高・中・低 のどれか1つ。
- 根拠の引用は、設計書の文をそのまま写す。該当する記述が無いときは「（該当する記述なし）」と書く。
</output_format>

記入例（題材の設計書に対する指摘表）

題材の設計書を人が読んで書いた記入例です。AIに頼むときも、この形で返ってくれば合格です。

同じ内容のタブ区切りです（findings.tsv）。

No  箇所  種別  重大度 根拠の引用   指摘  修正案
1   L008    表記ゆれ    低   ユーザーは備品、開始日時、終了日時を入力して予約を登録する。  1章の用語は「利用者」だが、ここだけ「ユーザー」になっている  「利用者は備品、開始日時、終了日時を入力して…」に直す
2   L011 / L014 表記ゆれ    中   登録後、予約番号を画面に表示する。   画面は「予約番号」、テーブルは「予約ID」。同じものか別のものかが読み取れない 同じなら「予約ID」に統一する。別なら1章に両方の定義を足す
3   L010 / L016 矛盾  高   利用期間は最長14日間とし、アプリケーションで検査する。    L010 は最長7日間、L016 は最長14日間で、上限が食い違っている    REQ-003 に合わせて L016 を「最長7日間」に直す
4   L015 / L020 矛盾  中   状態が「承認済み」の予約を対象とする  状態の値が L015 は「承認済」、L020 は「承認済み」で一致しない    L020 を「承認済」に直す
5   L021    あいまい    中   送信できなかった場合は適切に処理する。 再送の回数、間隔、記録先、通知先が決まっていない    「5分おきに3回まで再送し、3回とも送れないときはエラーログに記録して管理者へ通知する」のように書く
6   全体  抜け漏れ    高   （該当する記述なし）  REQ-004（承認・差し戻し）に対応する画面と処理が無い。状態にも「差し戻し」が無い 承認画面の節を追加し、L015 の状態に「差し戻し」を足す
7   L024    あいまい    中   画面の応答は速やかに行う。[REQ-006]  REQ-006 の「3秒以内」が設計書に引き継がれていない   「予約登録画面は3秒以内に応答する」と数値で書く

①用語と表記ゆれを点検するプロンプト

最初の段では、仕様の中身には踏み込ませず、語だけを見させます。

<role>
あなたは設計書の校正を担当します。仕様の良し悪しは判断せず、用語と表記だけを点検します。
</role>

<design_doc>
（ここに行番号つきの設計書を貼る）
</design_doc>

<task>
次の順に作業してください。
1. 設計書に出てくる名詞（画面名、項目名、テーブル名、列名、状態の値、役割の名前）を拾い、用語の一覧を作る。
2. 同じものを指していると読める語の組を探す（例：別の語、長音の有無、送り仮名の違い、英字と日本語）。
3. 用語の章で定義されていないのに本文で使われている語を探す。
4. 見つけたものを指摘表にする。種別は「表記ゆれ」とする。
同じものを指すかどうかが文脈から決められない組は、決めつけずに「要確認：」として修正案に書いてください。
</task>

<output_format>
最初に用語の一覧を、次の列の表で出します。
| 用語 | 初出の行 | 定義のある行（無ければ「なし」） | 別表記 |
|---|---|---|---|
続けて、指摘表を出します。
（ここに「共通の出力テンプレート」の出力形式を貼る）
</output_format>

この段の結果を見て、どの語に統一するかを人が決めます。決めた用語一覧は、次の段のプロンプトに貼って引き継ぎます。

②文書内の矛盾を点検するプロンプト

2段目は、設計書の中だけで食い違いを探させます。要件はまだ渡しません。

<role>
あなたは設計書の整合性を点検します。設計書の外にある知識で補わず、設計書に書かれている文どうしを比べます。
</role>

<glossary>
（①で決めた用語一覧を貼る。例：「予約番号」は「予約ID」と同じものとして扱う）
</glossary>

<design_doc>
（ここに行番号つきの設計書を貼る）
</design_doc>

<task>
設計書の中で、同じ対象について書かれた2か所以上の記述を比べ、食い違いを探してください。
比べる対象は次の5つです。
- 数値（上限、下限、日数、件数、時刻、桁数）
- 条件（いつ、誰が、どの状態のときに）
- 区分値（状態や種別の値の名前と個数）
- 名称とID（画面ID、テーブル名、列名）
- 処理の順序（Aの後にB、という記述の前後関係）
食い違いを見つけたら、両方の文を「根拠の引用」に「/」で区切って写し、「箇所」に両方の行番号を書いてください。
種別は「矛盾」とします。どちらが正しいかは決めず、修正案には「どちらかにそろえる」選択肢を書いてください。
</task>

（ここに「共通の出力テンプレート」の出力形式を貼る）

「どちらが正しいかは決めない」と書くのがポイントです。食い違いを見つけるのは照合で、どちらに合わせるかは仕様の判断だからです。

③要件との突き合わせで抜け漏れを点検するプロンプト

3段目で、はじめて要件一覧を渡します。

<role>
あなたは要件と設計書の対応を点検します。
</role>

<requirements>
（ここに要件一覧を貼る。要件IDと要件の文）
</requirements>

<design_doc>
（ここに行番号つきの設計書を貼る）
</design_doc>

<task>
要件を1件ずつ取り上げ、次の順に確かめてください。
1. その要件に対応する記述が設計書にあるかを探し、ある場合は行番号と原文の引用を示す。
2. 要件に数値・条件・対象者が含まれる場合、設計書の記述に同じ値で引き継がれているかを比べる。
3. 対応する記述が無い、または一部しか無い要件を指摘表にする。種別は「抜け漏れ」とする。
4. 逆に、どの要件にも対応しない設計書の記述があれば、最後に一覧にする（指摘ではなく確認事項として）。
設計書に要件IDが書かれていても、内容が要件と一致しているとは限りません。IDではなく文の内容で比べてください。
</task>

<output_format>
最初に、要件ごとの対応表を出します。
| 要件ID | 対応する行 | 設計書の引用 | 判定（あり・一部・なし） |
|---|---|---|---|
続けて、指摘表を出します。
（ここに「共通の出力テンプレート」の出力形式を貼る）
</output_format>

要件IDの対応をコードで先に確かめる

要件IDが設計書に書かれているなら、IDの有無はコードで数えられます。AIに頼む前に走らせておくと、AIの対応表と見比べる材料になります。

import csv
import re
import sys

req_path, doc_path = sys.argv[1], sys.argv[2]
doc = open(doc_path, encoding="utf-8").read()
used = set(re.findall(r"REQ-\d{3}", doc))

with open(req_path, encoding="utf-8", newline="") as f:
    reqs = list(csv.DictReader(f, delimiter="\t"))

for r in reqs:
    mark = "あり" if r["要件ID"] in used else "なし"
    print(f'{r["要件ID"]}\t{mark}\t{r["要件"]}')

defined = {r["要件ID"] for r in reqs}
print("設計書に出てこない要件:", sorted(defined - used) or "なし")
print("要件一覧に無いID:", sorted(used - defined) or "なし")

python3 check_req.py requirements.tsv design.md

実行結果です。

REQ-001 あり  利用者は備品と利用期間を指定して予約を登録できる
REQ-002 あり  予約は利用日の30日前から受け付ける
REQ-003 あり  1回の予約は最長7日間とする
REQ-004 なし  管理者は予約を承認または差し戻しできる
REQ-005 あり  利用開始日の朝にリマインドのメールを送る
REQ-006 あり  予約登録画面は3秒以内に応答する
設計書に出てこない要件: ['REQ-004']
要件一覧に無いID: なし

REQ-004 が設計書に出てこないことが分かります。一方で、REQ-006 は「あり」と出ますが、設計書の L024 は「速やかに行う」で、要件の「3秒以内」が引き継がれていません。IDの照合で分かるのは「触れているかどうか」までで、内容の一致は文を読んで比べる必要があります。 ここをAIに見させるのが3段目の役割です。

④観点別チェックのプロンプトと種類別の観点一覧

4段目は、設計書の種類ごとに決まった観点で点検させます。観点は一度に全部渡さず、その設計書の種類に合うものだけを貼ります。

<role>
あなたは設計書を、渡された観点の一覧に沿って点検します。一覧に無い観点での指摘はしません。
</role>

<checklist>
（ここに下の観点一覧から、設計書の種類に合う行を貼る）
</checklist>

<design_doc>
（ここに行番号つきの設計書を貼る）
</design_doc>

<task>
観点を1行ずつ取り上げ、設計書がその観点を満たしているかを判定してください。
- 満たしている：根拠になる行番号と引用を示す。
- 満たしていない、または一部だけ：指摘表に書く。種別は「抜け漏れ」「あいまい」「誤り」から選ぶ。
- 設計書の範囲外で判定できない：「対象外」とし、理由を1文で書く。
数値や条件が書かれていない記述（「適切に」「速やかに」「必要に応じて」「など」）は、「あいまい」として指摘してください。
</task>

<output_format>
最初に、観点ごとの判定表を出します。
| 観点ID | 判定（満たす・一部・満たさない・対象外） | 根拠の行 |
|---|---|---|
続けて、指摘表を出します。指摘の「指摘」列の先頭に観点IDを付けます（例：[BT-3] …）。
（ここに「共通の出力テンプレート」の出力形式を貼る）
</output_format>

設計書の種類別の観点一覧（30項目）

画面・テーブル・IF（インターフェース）・バッチ・非機能の5種類に、6項目ずつ用意しました。右端の列は、そのままプロンプトに入れられる文にしてあります。

同じ内容のタブ区切りです。自分のチームの観点を足すときは、行を追加してください。

種類  観点ID    観点  AIへの聞き方（プロンプトに入れる1行）
画面  SC-1    項目の過不足  要件に出てくる入力・表示の項目が、画面項目の一覧にすべてあるか
画面  SC-2    型・桁・必須  各項目に型、桁数、必須かどうか、初期値が書かれているか。書かれていない項目を列挙する
画面  SC-3    入力チェック  入力チェックの条件と、条件に合わないときのメッセージが項目ごとに対になっているか
画面  SC-4    操作と遷移   ボタンやリンクごとに、押したあとの処理と遷移先が書かれているか
画面  SC-5    権限  画面と操作ごとに、使える利用者の区分が書かれているか
画面  SC-6    エラー時の表示 処理が完了しなかったときの表示と、入力内容が残るかどうかが書かれているか
テーブル    TB-1    画面項目との対応    画面で入力する項目に、保存先の列があるか。列の無い項目を列挙する
テーブル    TB-2    型・桁の一致  画面項目の型・桁と、対応する列の型・桁が食い違っていないか
テーブル    TB-3    キーと一意性  主キーと一意にしたい項目が書かれているか
テーブル    TB-4    NULL と既定値   列ごとに NULL を許すかどうかと既定値が書かれているか
テーブル    TB-5    区分値 状態や種別の列について、取りうる値の一覧が1か所に書かれ、他の章の表記と一致しているか
テーブル    TB-6    削除と保存期間 削除の方法（物理・論理）と保存期間が書かれているか
IF  IF-1    項目の対応   送る側の項目と受ける側の項目が1対1で対応しているか。片方にしか無い項目を列挙する
IF  IF-2    型・桁・文字コード   項目ごとの型・桁、文字コード、日時の書式とタイムゾーンが書かれているか
IF  IF-3    必須と省略時  必須かどうかと、省略されたときの扱いが項目ごとに書かれているか
IF  IF-4    エラー応答   エラーの種類ごとに、返す内容と呼び出し側の動きが書かれているか
IF  IF-5    再送と重複   再送の条件と、同じデータを2回受けたときの扱いが書かれているか
IF  IF-6    件数とサイズ  1回あたりの件数やサイズの上限、超えたときの扱いが書かれているか
バッチ BT-1    起動条件    起動の時刻・周期・前提となる処理が書かれているか
バッチ BT-2    対象の条件   処理対象を選ぶ条件が、列名と値で書かれているか。「対象のデータ」のような書き方を列挙する
バッチ BT-3    途中で止まったとき   途中で止まったときに、どこまで反映され、どう再実行するかが書かれているか
バッチ BT-4    再実行 同じ日に2回動かしたときに結果が重複しないかが書かれているか
バッチ BT-5    件数ゼロと大量 対象が0件のときと、想定より多いときの動きが書かれているか
バッチ BT-6    ログと通知   出力するログの項目と、異常時の通知先が書かれているか
非機能 NF-1    数値で書かれているか  応答時間、同時利用数、稼働時間などが数値と単位で書かれているか。「速やかに」「十分な」のような語を列挙する
非機能 NF-2    測り方 その数値をどの条件でどう測るかが書かれているか
非機能 NF-3    要件との一致  非機能要件の数値が、設計書に同じ値で引き継がれているか
非機能 NF-4    バックアップと復旧   取得の周期、保管期間、復旧にかける時間の目標が書かれているか
非機能 NF-5    ログと監視   記録する操作と保存期間、監視する項目としきい値が書かれているか
非機能 NF-6    権限と認証   認証の方法と、権限の区分ごとにできる操作が書かれているか

指摘表の引用をコードで照合する

AIが返した「根拠の引用」が本当に設計書にあるかは、目で探さなくてもコードで確かめられます。種別と重大度が決めた値に収まっているかも同時に検査します。

import csv
import sys

doc_path, tsv_path = sys.argv[1], sys.argv[2]
doc = open(doc_path, encoding="utf-8").read()

COLUMNS = ["No", "箇所", "種別", "重大度", "根拠の引用", "指摘", "修正案"]
KINDS = {"表記ゆれ", "矛盾", "抜け漏れ", "あいまい", "誤り"}
LEVELS = {"高", "中", "低"}
NO_QUOTE = "（該当する記述なし）"

with open(tsv_path, encoding="utf-8", newline="") as f:
    reader = csv.reader(f, delimiter="\t")
    header = next(reader)
    if header != COLUMNS:
        sys.exit(f"列が違います: {header}")
    ng = 0
    for row in reader:
        problems = []
        if len(row) != len(COLUMNS):
            problems.append(f"列数が{len(row)}")
        else:
            no, place, kind, level, quote, text, fix = row
            if kind not in KINDS:
                problems.append(f"種別「{kind}」は一覧に無い")
            if level not in LEVELS:
                problems.append(f"重大度「{level}」は一覧に無い")
            if quote != NO_QUOTE and quote not in doc:
                problems.append("引用が設計書に見つからない")
            if quote == NO_QUOTE and kind != "抜け漏れ":
                problems.append("引用なしは抜け漏れだけ")
        result = "OK" if not problems else "要確認: " + " / ".join(problems)
        ng += bool(problems)
        print(f"No.{row[0]}\t{result}")
print(f"要確認 {ng} 件")

python3 check_findings.py design.md findings.tsv

記入例の指摘表を検査した結果です。

No.1    OK
No.2    OK
No.3    OK
No.4    OK
No.5    OK
No.6    OK
No.7    OK
要確認 0 件

次に、3行だけ書き換えた表（引用を言い換えたもの、種別と重大度を一覧に無い語にしたもの）を検査します。

No  箇所  種別  重大度 根拠の引用   指摘  修正案
3   L010 / L016 矛盾  高   利用期間は最長14日とする。  L010 は最長7日間、L016 は最長14日間で、上限が食い違っている    REQ-003 に合わせて L016 を「最長7日間」に直す
4   L015 / L020 不整合 中   状態が「承認済み」の予約を対象とする  状態の値が L015 は「承認済」、L020 は「承認済み」で一致しない    L020 を「承認済」に直す
5   L021    あいまい    重大  送信できなかった場合は適切に処理する。 再送の回数、間隔、記録先、通知先が決まっていない    「5分おきに3回まで再送し、3回とも送れないときはエラーログに記録して管理者へ通知する」のように書く

No.3    要確認: 引用が設計書に見つからない
No.4    要確認: 種別「不整合」は一覧に無い
No.5    要確認: 重大度「重大」は一覧に無い
要確認 3 件

No.3 は「最長14日間とし、アプリケーションで検査する。」を「最長14日とする。」と言い換えたために見つからなくなっています。引用が見つからない行は、言い換えか、設計書に無い内容を述べているかのどちらかなので、その行だけ人が原文と見比べれば済みます。

人のレビューとAIレビューの分担

分担の基準は2つです。機械的に照合できるかと、業務の判断が要るかで分けます。

判断基準の早見表です。

似たプロンプトとの違いと使い分け

「設計書」と「AI」が出てくるプロンプトには、目的の違うものがあります。

確かめて分かったこと

• 要件IDの照合だけでは内容の抜けは分からない：check_req.py は REQ-006 を「あり」と出しましたが、設計書の文には要件の「3秒以内」がありませんでした。IDの有無と内容の一致は別々に確かめます。
• 引用の照合は1文字の違いで外れる：「最長14日間とし、…」を「最長14日とする。」と書き換えただけで「見つからない」になりました。プロンプトに「言い換えや省略をしない」と書く理由がここにあります。
• 句点の有無は部分一致なら通る：記入例の No.4 は引用の末尾に句点がありませんが、原文の一部として見つかるため OK になりました。引用は文の途中まででも照合できます。
• 種別と重大度は値を決めておくと検査できる：「不整合」「重大」のように一覧に無い語は、コードですぐ見つかりました。値を決めずに頼むと、集計のたびに手で直すことになります。
• 行番号を付けると空行にも番号が付く：L002 や L006 のような空行も数えられます。指摘の行番号と原文を見比べるときは、番号つきの出力のほうを見ます。

よくある質問

Q. 設計書レビューを生成AIに任せると、人のレビューは要らなくなりますか？ A. 要ります。AIに任せられるのは、設計書と要件の中に答えがある照合と列挙までです。その仕様で利用者の業務が回るか、どちらの記述に合わせるかは人が決めます。AIの指摘表は、人のレビューの前に粗い指摘を片づけるための下ごしらえとして使います。

Q. 設計書が長くて1回で貼れないときは？ A. 章ごとに分けて、①の用語一覧を毎回いっしょに渡します。章をまたぐ矛盾を見る②では、各章から数値・条件・区分値だけを抜き出した表を先に作らせ、その表どうしを比べさせると、全文を一度に渡さなくても照合できます。

Q. AIの指摘が正しいかどうかは、どう確かめればよいですか？ A. まず引用が原文にあるかをコードで照合し、見つからない行から確かめます。引用が合っている行は、行番号の原文を読み、指摘の内容がその文から言えることかを見ます。「推測：」で始まる指摘は、設計書の外の知識で補ったものなので、書いた人に確認します。

Q. 仕様書のチェックで、矛盾と抜け漏れの違いは何ですか？ A. 矛盾は「書いてあるものどうしが食い違う」こと、抜け漏れは「書くべきものが書かれていない」ことです。矛盾は設計書だけで見つけられますが、抜け漏れは要件一覧や観点一覧のような比べる相手が必要です。そのため、この記事では②と③④を別のプロンプトにしています。

Q. 社内の設計書をAIに貼ってもよいですか？ A. 利用するサービスの契約と、自社の規程で決まります。貼る前に、入力した内容の扱いと、持ち出してよい情報の範囲を確かめてください。固有の名前を置き換えてから貼る方法もあります。

まとめ

• 設計書のレビューは4段に分ける：用語と表記ゆれ → 文書内の矛盾 → 要件との突き合わせ → 観点別チェック
• 設計書は行番号つきで渡し、指摘には原文の引用を付けさせる
• 出力は「箇所・種別・重大度・根拠の引用・修正案」の表に固定し、種別と重大度の値を決めておく
• 観点は設計書の種類に合うものだけを渡す（画面・テーブル・IF・バッチ・非機能の30項目）
• 引用と要件IDはコードで照合し、見つからない行から人が確かめる
• 照合と列挙はAI、どちらが正しいかと業務の判断は人が受け持つ

参考・出典

• Anthropic「Prompting best practices」（Claude Platform Docs、2026-10-05 閲覧）：XMLタグで指示と資料を分けること、長い文書では関連部分を先に引用させること、途中の出力を確かめたいときにプロンプトを段階に分けること
• OpenAI「Prompt engineering」（OpenAI API ドキュメント、2026-10-05 閲覧）：Markdown の見出しと XML タグでプロンプトの区切りを示すこと、出力の形を指定すること
• Google「Prompt design strategies」（Gemini API ドキュメント、2026-10-05 閲覧）：複雑なプロンプトを単純な要素に分け、順番につなぐこと、応答の形式を指定すること

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。