QAエンジニアを悩ませる仕様書の品質
生成AIで誤り・曖昧さ・考慮漏れ・矛盾を洗い出す
- AIソリューション
- ソフトウェアテスト・品質保証
Introduction
いざ開発チームから仕様書を受け取ってテスト計画や設計を進めようとした際、仕様書の誤り・曖昧さ・考慮漏れ・矛盾に気づくことはありませんか？
事前の仕様書レビューで解消されるのが理想ですが、実際にはすべてを取り除かれるとは限りません。 そのため、テスト工程に入った段階で初めて気づくケースも多いです。
本記事では、生成AIを使って仕様書の問題点を整理・洗い出す方法を解説します。
この記事でわかること
•仕様書に発生する4つの問題（誤り・曖昧さ・考慮漏れ・矛盾）
•生成AIによる課題の抽出方法と具体的なプロンプト
•アウトプットの活用方法
目次
なぜ仕様書の誤り・曖昧さ・考慮漏れ・矛盾が起きるのか
仕様書は複数の画面・機能に分かれ、複数人で分担して作成されることも多く、記述の粒度や観点が仕様書間、担当者間で統一しにくいです。加えて、仕様・要件の変更が部分的にしか反映されない反映漏れや、スケジュール制約により仕様変更の伝達が不十分なままテスト工程に進むケースも少なくありません。
これらはいずれも個人のミスではなく、プロジェクトの構造に起因します。そのため、テスト工程に入ってから仕様書の不整合に気づき、QAエンジニアを悩ませることは現場ではよく聞く話です。
仕様書の品質低下が引き起こすリスク
仕様書の品質が低い状態でテスト工程に進むと、解釈ずれ・観点漏れ・誤判定が発生しやすくなります。
曖昧な記述はテスター間の解釈差を生み、条件や例外の記載漏れはテスト漏れにつながります。また、誤記や矛盾は誤った不具合報告や見逃しを招きます。
その結果、未検出の不具合が本番環境に流出し、ユーザー報告で初めて発覚する事態につながります。仕様書の品質低下は、文書品質の問題にとどまらず、製品品質と事業リスクに直結します。
仕様書のレビュー観点を4つに整理する
仕様書の問題を可視化するために、まず「誤り」「曖昧さ」「考慮漏れ」「矛盾」の4つのレビュー観点を定義します。
この観点は、ISTQBが静的テストで検出すべき要件欠陥として定義する考え方をベースにしています。
以下のように仕様書に潜む課題を4つのレビュー観点に分類します。
1.誤り
例：「ユーザー名は0文字以内」
→入力可能な値が存在せず、テスト設計が成立しません。
2.曖昧さ
例：「3か月間ログインしていないユーザー」
→具体的な日数の閾値、ログイン、ログアウトどちらの起点なのか等が曖昧です。
3.考慮漏れ
例：「入力値が1以上で登録」
→0以下の扱いや、上限値について考慮されていません。
4.矛盾
例：「全画面スマホ対応」 vs 「管理画面はスマホ非対応」
→スマホの対応方針について、結局どちらが正しいのか判断できない状態です。
生成AIで仕様書の品質課題を洗い出すプロンプト例
4つのレビュー観点をプロンプトに組み込み、仕様書に潜む課題を抽出していきます。使用するAIモデルは、ChatGPT・Gemini・Claudeなどご自身の好みで問題ありません。
手順
1.仕様書を準備する（Excel・PDF・テキストなど）
2.プロンプトをAIへ入力
3.出力結果を確認する
1.仕様書を準備する（インプット例）
今回はテキストで用意した仕様メモをサンプルとして使います。
ExcelやPDFを渡してもよいです。
あなたは仕様書レビューを専門とする経験豊富なQAエンジニアです。
仕様書品質で問題となりうる箇所を「誤り」「曖昧さ」「考慮漏れ」「矛盾」の4つの観点で整理してください。
##仕様情報
資料：ユーザー登録
機能：新規登録機能
##機能要件
・ユーザー名は0文字以内
・パスワードは8文字以上で登録可能
・メールアドレスは必須項目
・「登録」ボタン押下で登録処理を行う
・登録完了後は一覧画面に遷移する
##条件定義
・3か月ログインがないユーザーは無効化する
・ログインしていない状態で一定期間経過した場合は通知メールを送る
・入力値が1以上の場合にポイントを付与する
・エラー時はエラーメッセージを表示する
##共通仕様
・管理画面はスマホ非対応
・全画面スマホ対応とする
2.プロンプトをAIへ入力
あなたは仕様書レビューを専門とする経験豊富なQAエンジニアです。
仕様書品質で問題となりうる箇所を「誤り」「曖昧さ」「考慮漏れ」「矛盾」の4つの観点で整理してください。
## 確認観点
**誤り**
値・条件が明らかに誤っている記述
– 論理的に成立しない条件（例：入力必須なのに最大文字数0）
– 機能名・画面名・ステータス値の誤字・脱字
**曖昧さ**
主観的な表現で解釈が複数に分かれる記述
– 基準・条件・範囲・境界・時間の具体的な値が不明瞭（例：「大きい場合」「しばらく後」）
– 動作・対象・条件の解釈が複数に分かれる（例：「適切に」「必要に応じて」）
**考慮漏れ**
必要な仕様がそもそも書かれていない
– エラー系・異常系・境界値・0件時の挙動
– UI/操作挙動（エラー表示・フォーカス制御・多重送信・権限制御・タイムアウト）
**矛盾**
別箇所の記述と食い違いにより正確性が不明なもの
– 入力制限・処理フロー・ラベル名・遷移処理の記述が箇所によって異なる
### 分類の優先順位
– 矛盾→誤り→曖昧さ・考慮漏れ
## 制約
– インプットドキュメントに書かれている内容のみを対象とすること。推測・補完は行わない
– 重要度はテストの実現可能性を軸に判断すること
## 出力フォーマット
| # | 重要度 | 分類 | 資料名 | 記載箇所 | 該当テキスト | 問題点 | 確認事項 |
|—|——–|——|———-|———-|—————–|——–|———-|
## インプットドキュメント／仕様情報
[ここに仕様書のドキュメントをマークダウン形式やテキストで貼り付け。またはファイル添付。]
3.出力結果を確認する（アウトプット例）
生成AIがプロンプトに従い、以下の表をチャット上にアウトプットします。こちらを仕様書と照らし合わせて精査してください。ExcelやConfluence などの任意ドキュメントに貼り付け、仕様書の確認事項リストとして使用できます。
| # | 重要度 | 分類 | 資料名 | 記載箇所 | 該当テキスト | 問題点 | 確認事項 |
|---|---|---|---|---|---|---|---|
| 1 | 高 | 矛盾 | ユーザー登録 | 共通仕様 | 「全画面スマホ対応とする」／「管理画面はスマホ非対応」 | 「全画面スマホ対応」と「管理画面はスマホ非対応」が両立していない。 | 「全画面」に管理画面を含むか。含む場合の正はどちらか。含まない場合は対象画面を明示するか。 |
| 2 | 高 | 誤り | ユーザー登録 | 機能要件 | 「ユーザー名は0文字以内」 | 空文字しか許容せず、正常系の入力値テストを設計できない。 | 上限値の誤記ではないか。最小・最大文字数を定義するか。 |
| 3 | 中 | 考慮漏れ | ユーザー登録 | 機能要件 | 「『登録』ボタン押下で登録処理を行う」 | 処理中の再押下可否や、多重送信防止の記載がない。 | 処理中のボタン状態、二重送信時の扱い、ローディング表示を定義するか。 |
| 4 | 高 | 曖昧さ | ユーザー登録 | 条件定義 | 「ログインしていない状態で一定期間経過した場合は通知メールを送る」 | 「一定期間」が不明で、通知条件の境界値テストができない。 | 期間、起算点、判定タイミングを具体的に定義するか。 |
| 5 | 中 | 考慮漏れ | ユーザー登録 | 条件定義 | 「エラー時はエラーメッセージを表示する」 | 対象エラー、表示場所、表示単位、文言が未記載。 | 対象エラー、表示位置、表示形式、メッセージ内容を定義するか。 |
生成AIの検出精度を上げる3つのコツ
1.インプットを画面や機能単位に絞る
大量の仕様書を一度に処理すると、見落としが増えます。画面や機能単位に分割して渡すことで検出精度が上がります。
2.マークダウンなど構造化された形式で渡す
マークダウンなど、見出し・箇条書きを持つ形式で渡すことで、文脈認識が向上します。
3.事前に気づいた点があれば一緒に渡す
人間が感じた疑問をインプットに含めることで、重要論点が強調されます。
仕様が複数の仕様書にまたがる場合
実務では、1つの機能や仕様が単一の仕様書に閉じているケースは少なく、画面仕様書、API仕様書、バッチ仕様書など複数の資料に分散して定義されることがあります。
このようなケースでは、インプット対象を調整することで対応できます。関連する仕様書を画面・機能単位に絞り、画面・API・バッチ仕様書をまとめてAIに渡します。また、アウトプットの情報量も増えますので、不整合が発生しやすい項目（入力制約・状態・遷移・条件）に絞って確認項目リストを確認します。
アウトプット活用：確認事項リストをどう使うか
AIが出力した確認事項リストは、主に2つの場面で活用できます。
1.開発チームへの確認事項／質問リストとして使う
確認事項を質問リストとして開発側に提示することで、認識が曖昧なままテストに着手することを防げます。事前に前提条件や期待動作を明確化することで、誤った解釈に基づくテスト設計や実行を抑制できます。
2.仕様書レビューの論点資料として使う
確認事項を開発・テストの関係者間で共有することで、仕様書レビュー時の論点整理に活用できます。曖昧さ、記載漏れ、矛盾、前提不足といった観点を明示した状態でレビューできるため、属人的な見落としを減らしやすくなります。
まとめ
仕様書には、誤り、曖昧さ、考慮漏れ、矛盾が一定程度含まれ得ます。これらを人手だけで短時間に見つけ切るのは容易ではありません。
生成AIを活用することで、仕様書の問題を体系的に洗い出し、確認事項として整理できます。これにより、認識齟齬を抱えたままテストを進めることを防ぎ、テスト品質の向上と不具合が本番環境へ流出するリスクの低減につなげられます。
まずは、AIが出力した確認事項リストを「開発チームへの質問リスト」または「仕様書レビューの論点整理」として活用するところから始めるのが有効です。
仕様書分析から設計までを一気通貫で
SHIFTの「ネムラナイ」は、仕様書を解析してテスト対象となる画面や機能を整理した上で、テスト観点の抽出から期待結果の生成までを支援します。
また、仕様書から十分な根拠が得られない箇所については、確認事項として明示されるため、仕様の曖昧さを早い段階で把握できます。
テスト設計の精度とスピードを両立したい方に最適なサービスです。
▶「ネムラナイ」 のサービス詳細・お問い合わせはこちら
https://contents.shiftinc.jp/nemuranai/
