AIで仕様書を作るPoC｜2週間で測る5指標
目次
会議の録音を渡すと、数分後には仕様書らしい文書ができる。初回のデモでは、たいてい歓声が上がる。
ところが、候補ツールを3つ並べると評価が割れる。「文章が自然」「画面が使いやすい」「要約が速い」。感想は増えるが、導入判断には使いにくい。
そこで、同じ20要件を全候補へ渡し、2週間だけ実務に近い変更を加える。測るのは生成速度ではない。抽出、レビュー、変更追跡、安全性、引き渡しの5指標である。
AI仕様書の作成ツールを比べるなら、製品ごとに得意なデモを見ない。同じ入力、同じ変更、同じ失格条件を置く。この小さな実験で、AIが書けるかではなく、チームが管理できるかを判定できる。
AI仕様書の作成PoCは「20要件」を先に作る
PoCを始める前に、正解データを人間側で用意する。題材は、終了済みの小規模案件がよい。顧客名や個人情報を匿名化し、次の4点をそろえる。
- 60〜90分の会議記録
- 会議で参照した現行業務資料
- 人間が確定した要件20件
- 要件に対応する受け入れ条件と決定理由
20件は多すぎず、少なすぎない。正常な要求だけで埋めず、判断が難しいものを混ぜる。
| 種類 | 件数 | 例 |
|---|---|---|
| 明確な機能要件 | 8 | 申請者が下書きを保存できる |
| 非機能要件 | 4 | 検索結果を3秒以内に返す |
| 例外・禁止条件 | 4 | 権限外の申請は表示しない |
| 未確定・矛盾あり | 4 | 保存期間が資料ごとに違う |
ここで作った20件を基準値とする。AIの出力を正解にしてはいけない。そうすると、抽出漏れや不自然な統合まで「仕様」として採点してしまう。
ツールの一般的な選定軸は、既存のAI要件定義ツールを選ぶ5つの軸で確認できる。今回のPoCでは機能表を増やさず 、実際に同じ作業を通した数字だけを残す。
2週間で測る5つの指標
PoCでは、次の5指標を開始前に固定する。生成物の見栄えだけでなく、レビュー・変更・停止・引き渡しまで測る。
指標1：要件抽出の正確さを3つに分ける
会議記録と資料を入力し、AIに要件候補を作らせる。採点は「何件出たか」だけでは足りない。
- 再現率：人間が確定した20件のうち、AIが拾えた割合
- 適合率：AIが出した候補のうち、採用できた割合
- 分割修正数：複数の判断を一つに混ぜ、人が分け直した件数
たとえば、基準値20件のうち18件を拾い、AIが24件を提案し、採用は18件なら、再現率90％、適合率75％である。数が多い方を優秀としない。余計な候補が増えるほど、レビュー負担も増えるからだ。
各要件には、ID、本文、要求元、決定理由、受け入れ条件を付ける。RaQuestの公式機能一覧でも、ID、版、状態、担当者、関連テスト、更新履歴などを要件の属性として扱っている。AIを使った仕様書作成でも、長い文章より、後から 識別できる単位が役に立つ。
合格の目安は再現率90％以上、適合率80％以上とする。ただし、数値は案件のリスクに合わせて変える。権限や法令に関わる4件は、1件でも見落としたら失格とする。
指標2：レビュー工数を分単位で測る
AIの下書きが速くても、人間の修正に時間がかかれば得をしない。
業務担当、開発担当、承認者の3役を置き、それぞれが使った時間を計る。
| 役割 | 確認すること | 記録する時間 |
|---|---|---|
| 業務担当 | 意図、業務用語、例外 | 内容修正と質問への回答 |
| 開発担当 | 実現性、境界、テスト可能性 | 分割、制約、受け入れ条件の修正 |
| 承認者 | スコープ、責任、未決事項 | 差し戻しと承認 |
コメント数ではなく、正味の作業分数を残す。同じ20要件を従来手順でも一度処理し、PoCとの差を比べる。従来120分、AI利用後90分なら25％減である。生成に5分しかかからなくても、確認が180分なら改善とは呼べない。
Confluenceの公式PRDテンプレートは、目的、成功指標、前提、スコープ外、Jira課題を一つの文脈で扱う。PoCでも、文章の読みやすさだけでなく、レビュー時に前提と未決事項へ戻れるかを確かめる。
指標3：変更影響の見落としを数える
PoCの6日目に、要件を3件変更する。
- 検索応答を3秒以内から1秒以内へ変える
- 保存期間を1年から3年へ変える
- 承認者を部長から部門管理者へ変える
変更前に、人間が影響先の正解一覧を作る。画面、API、データ、権限、テスト、見積もりのどこが変わるかを記す。その後、ツールが示した影響先と照合する。
測るのは、見落とし数、余計な候補数、確認時間の3つだ。リンクが多いこと自体に点を与えない。「なぜ影響するのか」を説明でき、担当者が確定リンクとAIの候補を区別できることが条件になる。
IBM Engineering Requirements Managementは、成果物の関連付け、変更追跡、ベースライン、構成管理を案内している。Jama Connectの公式機能説明も、上流・下流の関係から変更影響やテスト網羅性を確認し、ベースラインを管理する機能を示す。専用製品と同じ深さが不要な案件でも、変更とテストのつながりは試しておきたい。
重大な変更の見落としは0件を合格条件にする。余計な候補は許容できるが、人が10分以内に除外できる量へ抑える。
指標4：根拠なし断定と停止率を見る
試行データには、わざと矛盾を入れる。
- 会議では保存期間が1年
- 現行規程では3年
- 担当者メモでは法務確認中
良い出力は、どれかを選んで仕様書を完成させることではない。出典を並べ、「未確定」として法務担当へ質問を返すことだ。
次の3項目を数える 。
- 根拠なしに確定した件数
- 矛盾を検出して止まれた割合
- 出典から元の記述へ戻れた割合
根拠なし断定は1件でも失格にする。停止率は100％を求める。一方、出典の表示形式は製品によって違ってよい。会議の時刻、文書名と章、元コメントなど、人が30秒以内に確認できればよい。
根拠付き出力の評価は、RAGを構築する前の評価設計と同じ発想で進められる。正答したかだけでなく、情報を取得できなかった場面と、答えずに止まれた場面を分けて記録する。
指標5：引き渡し後の欠落項目を数える
PoCの終盤で、20要件をすべてエクスポートする。PDFだけで終わらせず、CSVやJSONなどの構造化形式も出す。
確認するのは、次の情報が残るかだ。
- 要件IDと親子関係
- 決定理由と出典
- 版と変更履歴
- コメントと承認状態
- 受け入れ条件、テスト、課題へのリンク
そのデータをJiraやGitHubなど、開発側の管理先へ渡す。1件ずつコピーする必要があった項目、欠落した関係、IDが変わった件数を記録する。
生成コードの試行まで進めるなら、バイブコーディングのデバッグ手順のように、再現条件と期待値を小さく固定する。要件IDがテストや不具合へ渡れば、修正のたびに経緯を探し直さずに済む。
合格条件は、必須項目の欠落0件、手作業での補正30分以内とする。契約終了時に取り出せない情報は、導入した瞬間から負債になる。
5指標は重み付きで採点する
5指標を100点へ換算する。
| 指標 | 配点 |
|---|---|
| 要件抽出 | 20点 |
| レビュー工数 | 20点 |
| 変更影響 | 25点 |
| 根拠と停止 | 25点 |
| 引き渡し | 10点 |
75点以上を候補に残す。ただし、失格条件を平均点で相殺しない。権限・法令要件の見落とし、根拠なし断定、重大変更の見落とし、必須データの取り出し不能は、その時点で不採用とする。
SIer案件では、業務担当が基準値を作り、開発担当が変更影響を確認し、PMが時間と失格条件を管理する。ツール提供会社には、操作説明より先に同じ20要件を渡す。これで比較が営業デモから共同検証へ変わる。
2週間のPoCで知りたいのは、最も自然な仕様書を書く製品ではない。誰が直し、どこで止まり、変更後も開発とテストへ渡せる製品である。
Atsumellでは、実案件を匿名化した評価データ作りから、AIが読める仕様構造、レビュー、変更管理までを一続きで設計している。自社の20要件で試行計画を作りたい場合は、お問い合わせから相談してほしい。
