生成AIで設計書を作るプロンプト集｜要件定義から詳細設計まで

生成AIで設計書を作るときの要点は、「決まっていることを表にして渡す」「出力の章立てを指定する」「決まっていないことは推測させず一覧にさせる」の3つです。 文章で長く説明するより、項目のそろった入力シートを渡したほうが、AIの出力は安定し、人が確かめる範囲もはっきりします。

この記事は、設計書そのものの書き方ではなく、AIへの渡し方と、出てきたものの確かめ方に絞っています。要件定義・基本設計・詳細設計・API・テーブル定義・画面の6工程について、入力シート・プロンプト・章立てを1セットずつ、架空の「備品貸出システム」の記入例つきで載せました。ER図・シーケンス図・画面遷移図をMermaidで出させる指定と、表計算ソフトに貼れるチェック表も用意しています。

確認環境：Ubuntu 24.04、Node.js 22.22、@mermaid-js/mermaid-cli 12.0.0（Mermaid 12.1.0）、Chromium。記事中のMermaidのコードは、エラーになる例として示した2つを除き、この環境でSVGに描画できることを確かめています。エラー文もこの環境で出たものです。プロンプトと入力シートは特定のAI製品に依存しない書き方にしてあり、AIの出力例は載せていません。

工程別の早見表（渡すもの・出させるもの・確かめる点）

AIに設計書を書かせる前にそろえる3つのもの

入力シートは「項目・内容・確定度」の3列にするのがコツです。確定度に「確定」「仮」「未定」を書いておくと、AIに「仮と未定は未決事項の章へ回す」と指示でき、出力のどこを人が判断すべきかが一目でわかります。

すべての工程で先頭に貼る共通ルール

どの工程のプロンプトでも、最初に次のブロックを貼ります。工程別のプロンプトは、この続きに書く形です。

# 共通ルール
あなたは設計書の下書きを作る担当です。次のルールを守ってください。

1. 入力シートに書かれた内容だけを事実として扱う。
2. 入力シートにない内容を補うときは、文の先頭に【提案】と付ける。
3. 確定度が「仮」「未定」の項目、および判断に必要な情報が足りない点は、
   本文に書かず、最後の「未決事項」の章に質問の形で一覧にする。
4. 用語は「用語表」の表記だけを使う。同じものを別の言葉で呼ばない。
5. 要件・機能・画面・テーブル・APIには、指定した形式の番号を付ける。
6. 出力はMarkdown。見出しは指定した章立てのとおりにし、順番を変えない。
7. 図はMermaidのコードブロックで出す。ノードの文字に丸かっこや記号を
   含めるときは、二重引用符で囲む。
8. 文末は「です・ます」。1文は60字以内を目安にする。

# 用語表
| 用語 | 意味 | 使わない言い方 |
|---|---|---|
| 備品 | 貸出の対象になる物品 | 機材、物品、アイテム |
| 社員 | システムの利用者 | ユーザー、従業員、利用者 |
| 貸出 | 備品を社員に渡すこと | レンタル、貸与 |
| 返却 | 貸出中の備品を戻すこと | 返還、回収 |
| 管理者 | 備品の登録と状態の変更ができる社員 | 管理ユーザー、アドミン |

用語表を先に渡しておくと、用語の揺れを後から直す手間が減ります。 「使わない言い方」の列まで書くのがポイントです。

題材：架空の備品貸出システム

記入例は、次の架空のシステムを題材にします。社内のノートPCやプロジェクターなどの備品を、社員が画面から借りて返す小さなシステムです。

工程1：要件定義のプロンプトと入力シート

入力シート（記入例）

| 項目 | 内容 | 確定度 |
|---|---|---|
| システム名 | 備品貸出システム | 確定 |
| 目的 | 備品の貸出状況を一覧で把握し、表計算ファイルでの管理をやめる | 確定 |
| 現在の困りごと | 誰が借りているか分からない。返却予定日を過ぎても気づけない | 確定 |
| 利用者と人数 | 社員 約200名、管理者 3名 | 確定 |
| 対象の備品 | ノートPC、プロジェクター、モニター、Webカメラ 計 約150点 | 確定 |
| 貸出の規則 | 同時に3点まで。期間は最長14日 | 確定 |
| 返却が遅れたとき | 本人と管理者に通知する | 仮 |
| 予約の機能 | 貸出中の備品を次に借りる予約 | 未定 |
| 利用する端末 | 社内のPCのブラウザ | 確定 |
| 認証 | 社内の認証基盤によるシングルサインオン | 仮 |
| 利用できる時間 | 平日 8時から20時 | 仮 |
| 範囲外 | 購入手続き、棚卸し、社外への貸出 | 確定 |
| 稼働の希望時期 | 2027年4月 | 仮 |

プロンプト

（共通ルールと用語表をここに貼る）

# 依頼
下の入力シートをもとに、要件定義書の下書きを作ってください。

# 章立て
1. 背景と目的
2. 利用者と役割（表：役割／人数／できること）
3. 業務の流れ（現在と導入後を、それぞれMermaidのflowchartで1つずつ）
4. 機能要件（表：番号 FR-001 形式／要件／優先度 高・中・低／もとにした入力シートの項目）
5. 非機能要件（表：番号 NFR-001 形式／分類／要件／測り方）
6. 範囲外（箇条書き）
7. 未決事項（表：番号 Q-001 形式／質問／決めないと進められない章／回答の選択肢）

# 条件
- 機能要件は「社員が〜できる」「管理者が〜できる」の形で、1行に1つの要件を書く。
- 数値が入力シートにない非機能要件は、値を入れずに未決事項へ回す。
- 「もとにした入力シートの項目」が書けない要件は、【提案】を付ける。

# 入力シート
（ここに入力シートを貼る）

「もとにした入力シートの項目」の列を出させると、AIが補った要件と、入力から導いた要件を人がすぐ見分けられます。

工程2：基本設計のプロンプトと入力シート

入力シート（記入例）

| 項目 | 内容 | 確定度 |
|---|---|---|
| もとにする要件 | FR-001 備品を検索できる／FR-002 貸出を申請できる／FR-003 返却を登録できる／FR-004 自分の貸出履歴を見られる／FR-005 管理者が備品を登録できる | 確定 |
| 構成 | Webアプリ（ブラウザ＋APIサーバー＋リレーショナルDB） | 確定 |
| 言語とフレームワーク | サーバーはJava、画面はTypeScript | 仮 |
| DB | PostgreSQL | 確定 |
| 外部との連携 | 社内の認証基盤（シングルサインオン）、メール送信 | 仮 |
| 権限 | 社員、管理者の2種類 | 確定 |
| バッチ処理 | 返却予定日を過ぎた貸出を毎朝抽出して通知 | 仮 |
| ログ | 操作ログを1年間保存 | 未定 |

プロンプト

（共通ルールと用語表をここに貼る）

# 依頼
下の入力シートをもとに、基本設計書の下書きを作ってください。

# 章立て
1. 全体構成（Mermaidのflowchartで、ブラウザ・APIサーバー・DB・外部連携を示す）
2. 機能一覧（表：番号 F-001 形式／機能名／概要／対応する要件の番号）
3. 画面一覧（表：番号 S01 形式／画面名／使う役割／対応する機能の番号）
4. データ一覧（表：データ名／概要／主な項目）※カラムの型はここでは決めない
5. 外部連携一覧（表：連携先／方向／タイミング／内容）
6. 権限の表（行＝機能、列＝役割、セル＝可・不可）
7. 未決事項（表：番号／質問／影響する章／回答の選択肢）

# 条件
- すべての要件の番号が、機能一覧のどれかの行に現れるようにする。
- 対応する要件がない機能を足すときは【提案】を付ける。
- 最後に「要件と機能の対応表」（行＝要件、列＝機能、対応する所に○）を付ける。

# 入力シート
（ここに入力シートを貼る）

工程3：詳細設計のプロンプトと入力シート

詳細設計は、機能を1つずつ依頼します。複数の機能をまとめて頼むと、処理の規則が薄くなりやすいためです。

入力シート（記入例：F-002 貸出申請）

| 項目 | 内容 | 確定度 |
|---|---|---|
| 対象の機能 | F-002 貸出申請 | 確定 |
| 入力 | 備品ID、返却予定日 | 確定 |
| 出力 | 貸出ID、貸出日、返却予定日 | 確定 |
| 規則1 | 備品の状態が available のときだけ貸し出せる | 確定 |
| 規則2 | 同じ社員が同時に借りられるのは3点まで（未返却の貸出が3件あると申請できない） | 確定 |
| 規則3 | 返却予定日は、貸出日の翌日以降、貸出日から14日後まで | 確定 |
| 規則4 | 状態が retired の備品は一覧に出さない | 確定 |
| 同時に申請されたとき | 先に登録できた1件だけを成功にする | 確定 |
| エラーの返し方 | 入力の誤りは400、貸出中は409、上限超えは409 | 仮 |
| 通知 | 申請が完了したら本人にメール | 未定 |

プロンプト

（共通ルールと用語表をここに貼る）

# 依頼
下の入力シートの機能について、詳細設計書の下書きを作ってください。

# 章立て
1. 処理概要（3行以内）
2. 入力チェック（表：項目／型／必須／範囲／範囲外のときのエラー番号）
3. 処理手順（番号付きの手順。各手順に、参照・更新するテーブルを書く）
4. シーケンス図（MermaidのsequenceDiagram。成功と、エラーの分岐をaltで分ける）
5. エラー一覧（表：番号 E-001 形式／起きる条件／HTTPステータス／メッセージ）
6. トランザクションと同時実行（どこからどこまでを1つにするか、ロックの取り方）
7. 境目の確認表（表：規則／境目の値／その値のときの結果）
8. 未決事項

# 条件
- 入力シートの規則1〜4が、処理手順のどの番号で判定されるかを対応づける。
- 「以上・以下・より大きい・未満」を必ず書き分け、「〜まで」などの
  あいまいな言い方は境目の確認表で具体的な値にする。
- シーケンス図は、下の見本と同じ書き方にする（参加者の別名、autonumber、alt）。

# シーケンス図の見本
（後述の「シーケンス図の指定」のコードを貼る）

# 入力シート
（ここに入力シートを貼る）

「境目の確認表」を出させると、たとえば「14日後まで」が14日目を含むのかどうかを、AIがどう解釈したかが表に現れます。人はその表だけを見れば解釈のずれに気づけます。

工程4：API設計のプロンプトと入力シート

入力シート（記入例）

| 項目 | 内容 | 確定度 |
|---|---|---|
| 形式 | REST、JSON、文字コードはUTF-8 | 確定 |
| パスの先頭 | /api/v1 | 確定 |
| 認証 | Bearerトークン | 仮 |
| 項目名の書き方 | JSONはキャメルケース、日付は YYYY-MM-DD | 確定 |
| 操作1 | 備品の一覧を取得（分類・状態・キーワードで絞り込み、20件ずつ） | 確定 |
| 操作2 | 備品を1件取得 | 確定 |
| 操作3 | 貸出を登録（備品ID、返却予定日） | 確定 |
| 操作4 | 返却を登録（貸出ID） | 確定 |
| 操作5 | 自分の貸出の一覧を取得 | 確定 |
| 操作6 | 備品を登録（管理者のみ） | 確定 |
| エラーの形 | code、message、details の3項目 | 仮 |

プロンプト

（共通ルールと用語表をここに貼る）

# 依頼
下の入力シートをもとに、API設計書の下書きを作ってください。

# 章立て
1. 共通仕様（認証、日付の形式、ページ分割、エラーの形）
2. エンドポイント一覧（表：番号 API-001 形式／メソッド／パス／概要／使える役割）
3. エンドポイントごとの定義（以下を繰り返す）
   3.x.1 リクエスト（表：場所 path・query・body／項目／型／必須／範囲／例）
   3.x.2 レスポンス（表：項目／型／NULLの可否／説明／例）
   3.x.3 エラー（表：HTTPステータス／code／起きる条件）
   3.x.4 リクエストとレスポンスのJSONの例（1組）
4. 未決事項

# 条件
- 項目名は、別に渡す「テーブル定義のカラム一覧」と対応がわかるようにし、
  対応表（JSONの項目／テーブル.カラム）を最後に付ける。
- 入力シートにない操作は足さない。必要だと考える場合は未決事項に質問として書く。
- JSONの例に書く値は、入力シートと矛盾しない値にする。

# テーブル定義のカラム一覧
（工程5の出力のうち、カラム定義の表を貼る）

# 入力シート
（ここに入力シートを貼る）

APIとテーブル定義は、片方の出力をもう片方の入力に貼ると、項目名の食い違いを減らせます。順番は、テーブル定義を先に作り、APIを後にするのが扱いやすい進め方です。

工程5：テーブル定義のプロンプトと入力シート

入力シート（記入例）

| 項目 | 内容 | 確定度 |
|---|---|---|
| DB製品 | PostgreSQL | 確定 |
| 名前の付け方 | テーブルは単数形の英小文字、カラムはスネークケース | 確定 |
| 扱う情報1 | 社員（社員番号、氏名、権限） | 確定 |
| 扱う情報2 | 分類（分類名） | 確定 |
| 扱う情報3 | 備品（管理番号、備品名、分類、状態） | 確定 |
| 扱う情報4 | 貸出（備品、社員、貸出日、返却予定日、返却日） | 確定 |
| 一意にしたい項目 | 社員番号、管理番号、分類名 | 確定 |
| 状態の値 | available、on_loan、retired | 確定 |
| 件数の見込み | 社員200、備品150、貸出は年に約3,000 | 仮 |
| 削除の扱い | 備品は削除せず状態を retired にする | 確定 |
| 保存期間 | 貸出の記録を何年残すか | 未定 |

プロンプト

（共通ルールと用語表をここに貼る）

# 依頼
下の入力シートをもとに、テーブル定義書の下書きを作ってください。

# 章立て
1. テーブル一覧（表：番号 T-001 形式／テーブル名／日本語名／概要）
2. ER図（MermaidのerDiagram。下の見本と同じ書き方）
3. カラム定義（テーブルごとの表：カラム名／日本語名／型／NULLの可否／既定値／キー PK・FK・UK／説明）
4. 制約（表：テーブル／種類 外部キー・一意・CHECK／内容）
5. インデックス（表：テーブル／カラム／理由になる検索）
6. CREATE TABLE文（章3・4と同じ内容で、入力シートのDB製品向けに）
7. 未決事項

# 条件
- カラム定義の表とCREATE TABLE文の内容を一致させる。
- インデックスは「理由になる検索」が書けるものだけにする。
- ER図の属性の説明は二重引用符で囲み、丸かっこを使わない。

# ER図の見本
（後述の「ER図の指定」のコードを貼る）

# 入力シート
（ここに入力シートを貼る）

工程6：画面設計のプロンプトと入力シート

入力シート（記入例）

| 項目 | 内容 | 確定度 |
|---|---|---|
| 画面 S01 | ログイン | 確定 |
| 画面 S02 | 備品一覧（分類・状態・キーワードで絞り込み） | 確定 |
| 画面 S03 | 備品詳細 | 確定 |
| 画面 S04 | 貸出申請（返却予定日を入力） | 確定 |
| 画面 S05 | 申請完了 | 確定 |
| 画面 S06 | 貸出履歴（自分の貸出の一覧、返却の登録） | 確定 |
| 画面 S07 | 備品登録（管理者のみ） | 確定 |
| 遷移の条件 | S04でキャンセルするとS03へ戻る。S07は管理者だけがS02から開ける | 確定 |
| 入力項目 S04 | 返却予定日（日付、必須、翌日から14日後まで） | 確定 |
| 入力項目 S07 | 管理番号（必須、半角英数字10字以内）、備品名（必須、50字以内）、分類（選択） | 確定 |
| メッセージの文体 | です・ます。操作の次の一手を書く | 確定 |
| 画面の幅 | PCのブラウザのみ | 仮 |

プロンプト

（共通ルールと用語表をここに貼る）

# 依頼
下の入力シートをもとに、画面設計書の下書きを作ってください。
見た目のデザインは対象外とし、項目・動作・遷移を定義します。

# 章立て
1. 画面一覧（表：番号／画面名／使える役割／概要）
2. 画面遷移図（Mermaidのflowchart LR。下の見本と同じ書き方）
3. 画面ごとの定義（以下を繰り返す）
   3.x.1 項目定義（表：番号／項目名／種類 表示・入力・ボタン／型／必須／桁数や範囲／初期値）
   3.x.2 イベント（表：きっかけ／処理／呼び出すAPIの番号／成功時の行き先／エラー時の動き）
   3.x.3 メッセージ（表：番号 M-001 形式／出る条件／文言）
4. 遷移の一覧（表：遷移元／操作／条件／遷移先）
5. 未決事項

# 条件
- 画面遷移図の矢印と、章4の遷移の一覧を1対1で対応させる。
- どの画面にも、戻る・キャンセル・エラー時の行き先のいずれかがあるようにする。
  行き先が入力シートから決められない場合は未決事項に書く。

# 画面遷移図の見本
（後述の「画面遷移図の指定」のコードを貼る）

# 入力シート
（ここに入力シートを貼る）

図をMermaidで出させる指定（ER図・シーケンス図・画面遷移図）

図は「Mermaidで描いて」と頼むだけでなく、書き方の見本を1つ渡すと、記法のぶれが小さくなります。次の3つは、プロンプトの「見本」の欄にそのまま貼れるコードです。いずれも確認環境でSVGに描画できています。

ER図の指定

erDiagram
    EMPLOYEE ||--o{ LOAN : "借りる"
    EQUIPMENT ||--o{ LOAN : "貸し出される"
    CATEGORY ||--o{ EQUIPMENT : "分類する"

    EMPLOYEE {
        bigint employee_id PK "社員ID"
        varchar employee_code UK "社員番号"
        varchar name "氏名"
        varchar role "権限 user か admin"
    }
    CATEGORY {
        bigint category_id PK "分類ID"
        varchar name UK "分類名"
    }
    EQUIPMENT {
        bigint equipment_id PK "備品ID"
        bigint category_id FK "分類ID"
        varchar asset_code UK "管理番号"
        varchar name "備品名"
        varchar status "状態 available か on_loan か retired"
    }
    LOAN {
        bigint loan_id PK "貸出ID"
        bigint equipment_id FK "備品ID"
        bigint employee_id FK "社員ID"
        date loaned_on "貸出日"
        date due_on "返却予定日"
        date returned_on "返却日 未返却は空"
    }

指定に添える文の例です。

- テーブル名は英大文字、属性は「型 カラム名 キー "日本語名"」の順に書く。
- 関連の線には、動詞のラベルを二重引用符で付ける。
- 1対多は ||--o{ を使い、「1」の側を左に書く。

シーケンス図の指定

sequenceDiagram
    autonumber
    actor U as 社員
    participant W as 画面
    participant A as 貸出API
    participant D as DB

    U->>W: 備品を選び返却予定日を入力
    W->>A: POST /loans
    A->>D: 備品の状態を取得（行ロック）
    D-->>A: status
    alt status が available
        A->>D: LOAN を追加し EQUIPMENT を on_loan に更新
        D-->>A: 完了
        A-->>W: 201 Created
        W-->>U: 貸出完了を表示
    else status が on_loan
        A-->>W: 409 Conflict
        W-->>U: 貸出中のメッセージを表示
    else 入力が範囲外
        A-->>W: 400 Bad Request
        W-->>U: 入力欄にエラーを表示
    end

- 参加者は「participant 別名 as 表示名」で宣言し、矢印では別名を使う。
- 呼び出しは ->>、戻りは -->> にする。autonumber で番号を付ける。
- 成功とエラーは alt / else で分け、エラーごとにHTTPステータスを書く。

画面遷移図の指定

flowchart LR
    S01[S01 ログイン] -->|認証成功| S02[S02 備品一覧]
    S02 -->|行を選択| S03[S03 備品詳細]
    S03 -->|貸出を申請| S04[S04 貸出申請]
    S04 -->|登録成功| S05[S05 申請完了]
    S04 -->|キャンセル| S03
    S05 -->|一覧へ戻る| S02
    S02 -->|自分の貸出| S06[S06 貸出履歴]
    S06 -->|返却を登録| S06
    S02 -->|管理者のみ| S07[S07 備品登録]
    S07 -->|保存| S02
    S02 -->|ログアウト| S01

- ノードは「画面番号[画面番号 画面名]」の形にし、番号は画面一覧と一致させる。
- 矢印には必ず、操作または条件のラベルを付ける。
- 同じ画面にとどまる操作は、自分自身への矢印で書く。

描けないコードが出たときの直し方

AIが出したMermaidのコードが描画できないことがあります。日本語の設計書でよく当たるのが、ラベルの中の丸かっこです。次のコードを mermaid-cli に通すと、構文エラーになります。

flowchart LR
    S01[S01 ログイン(社員)] --> S02[S02 備品一覧]

Error: Parse error on line 2:
... LR    S01[S01 ログイン(社員)] --> S02[S02 備品
----------------------^
Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

ラベルを二重引用符で囲むと描画できます。

flowchart LR
    S01["S01 ログイン(社員)"] --> S02[S02 備品一覧]

ER図でも、属性の説明を引用符なしで書くとエラーになります。

erDiagram
    LOAN {
        date returned_on 返却日（未返却は空）
    }

Error: Parse error on line 3:
...d_on 返却日（未返却は空）    }
----------------------^
Expecting 'ATTRIBUTE_WORD', '?', got 'BLOCK_STOP'

エラー文をそのままAIに貼り、「このエラーが出ないように、該当の行だけを直してください」と頼むのも有効です。全体を作り直させると、ほかの部分まで変わってしまうことがあります。

AIの出力を人が確かめるチェック表

AIの出力は下書きです。採用するかどうかは、人が次の表で確かめてから決めます。 観点は、抜け・矛盾・未決事項・用語の揺れの4つに、番号の対応と図を加えた6区分です。

表計算ソフトに貼るためのタブ区切りです。結果とメモの列を足してあります。

No  区分  確かめること  確かめ方    結果  メモ
1   抜け  入力シートのすべての行が、出力のどこかに反映されている 入力シートを上から順に、出力内を検索する        
2   抜け  指定した章立てがすべてあり、順番も同じ 見出しだけを抜き出して並べる      
3   抜け  エラー時・キャンセル時・0件のときの動きが書かれている 各機能や画面で3つを探す        
4   抜け  権限ごとの違い（社員と管理者）が書かれている  権限の表と各章を見比べる        
5   抜け  範囲外が明記されている 範囲外の章と入力シートを見比べる        
6   矛盾  数値（上限、日数、件数）が入力シートと一致している   数字だけを検索して拾う     
7   矛盾  境目の書き方（以上・以下・未満）が章の間で同じ 境目の確認表と本文を見比べる      
8   矛盾  項目名と型が、API・テーブル定義・画面で一致している 対応表で1行ずつ確かめる        
9   矛盾  図と表の内容が一致している（矢印の数と遷移の行数など） 図の矢印と表の行を数える        
10  矛盾  HTTPステータスやエラー番号が、章の間で同じ エラー一覧を基準に検索する       
11  未決事項    確定度が「仮」「未定」の項目が、すべて未決事項にある  入力シートの確定度で絞って数える        
12  未決事項    【提案】が付いた文を、採用・不採用のどちらかに決めた  【提案】で検索する       
13  未決事項    未決事項に、回答する人と期限を書き足した    表に2列を足して埋める     
14  未決事項    本文の中に「想定」「一般的に」「通常は」が残っていない 3語で検索する     
15  用語の揺れ   用語表の「使わない言い方」が出力に現れない   使わない言い方で検索する        
16  用語の揺れ   同じ画面・機能・テーブルが、別の名前で呼ばれていない  番号ごとに名前を並べる     
17  用語の揺れ   英字の表記（大文字・小文字、単数・複数）がそろっている テーブル名とJSONの項目名を並べる      
18  番号の対応   すべての要件の番号が、機能のどれかに対応している    対応表の空の行を探す      
19  番号の対応   対応する要件のない機能・画面・APIがない   対応表の空の列を探す      
20  図   Mermaidのコードが描画できる   描画ツールやエディタの表示で確かめる      
21  図   図の中の番号と名前が、一覧表と一致している   図のノードと表を見比べる        
22  根拠  入力シートにない数値や固有の名前が書かれていない    数字と英字の名前を拾って入力と照らす      

確かめる作業をAIに手伝わせるプロンプト

検索や数え上げの部分は、AIに下調べをさせると速くなります。判定そのものは人が行います。

（用語表、入力シート、確かめたい設計書をここに貼る）

# 依頼
上の設計書を、入力シートと用語表に照らして点検してください。設計書は書き換えません。

# 出力（表を4つ）
1. 抜け：入力シートの行ごとに、設計書の該当する章と文を引用する。該当がなければ「なし」。
2. 矛盾：同じ対象について、章の間で値や言い方が違う箇所を、両方の文を引用して並べる。
3. 未決事項の漏れ：確定度が「仮」「未定」なのに、本文で決定事項として書かれている箇所。
4. 用語の揺れ：用語表の「使わない言い方」が現れた箇所と、同じものを指す別の呼び名。

# 条件
- 必ず設計書の文をそのまま引用し、章の番号を付ける。引用できない指摘は書かない。
- 直し方の案は書かず、事実の指摘だけにする。

「引用できない指摘は書かない」と指定すると、人が設計書の該当箇所をすぐ開いて判定できます。

渡し方で変わる点の比較

工程をまたぐときは、前の工程で人が確定させた表だけを、次の工程の入力シートに貼るのが基本です。AIの出力をそのまま次の入力に流すと、【提案】のまま残った内容が決定事項として広がってしまいます。

よくある質問

Q. 入力シートを埋めきれない場合はどうすればよいですか？ A. 空欄のまま渡さず、確定度を「未定」にして項目だけ書いておきます。共通ルールにより未決事項の章に質問として出てくるので、それを関係者に確かめる一覧として使えます。

Q. 既存のソースコードから設計書を作りたいときも同じ方法で使えますか？ A. 章立てと未決事項の指定はそのまま使えます。入力シートの代わりに対象のコードを渡し、「コードから読み取れない意図は書かず、未決事項に質問として出す」と加えます。チェック表のうち、根拠の区分（No.22）を重点的に確かめてください。

Q. 一度に全部の工程を頼んでもよいですか？ A. 工程ごとに分けることをおすすめします。前の工程の未決事項が残ったまま先へ進むと、後の工程で推測が重なります。1工程ずつ、人が確定してから次へ渡すと、手戻りが小さくなります。

Q. 社内の情報をAIに渡してよいか迷います。 A. 利用するAIサービスの契約と、所属先の利用ルールを先に確かめてください。この記事のように、名前や数値を架空のものに置き換えた入力シートで型を作っておくと、渡せる範囲が決まった後にすぐ使えます。

まとめ

• 入力シート・章立て・未決事項の出し方の3つをそろえてから依頼する
• 入力シートは「項目・内容・確定度」の3列にし、仮と未定は未決事項へ回させる
• 用語表と「使わない言い方」を先頭に貼り、用語の揺れを最初から抑える
• 図はMermaidの見本を1つ渡す。ラベルの記号は二重引用符で囲ませる
• 要件・機能・画面・テーブル・APIに番号を付けさせ、対応表で追えるようにする
• 出力は下書きとして扱い、抜け・矛盾・未決事項・用語の揺れをチェック表で確かめる
• 次の工程へは、人が確定させた表だけを渡す

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