要件定義書から利用者目線の受入テストチェックリストをAIで作り、キャプチャ欄つきで回す

はじめに

受入テストのチェックリストを、要件定義書からAIで下書きし、画面キャプチャの欄をつけて発注側と一緒に回す手順を書きます。チェックリストを書くのが開発者だと、どうしても開発者の言葉になり、業務担当の方が読んでも何を押せばよいか分からない、ということが起きます。そこを利用者の言葉に寄せるのが目的です。

内容は5つに分けました。表の列、AIに下書きさせるプロンプト、要件IDの抜けを確かめる小さなスクリプト、キャプチャの残し方、そしてこの方法でできないことです。テンプレートだけ欲しい方は「1.」だけ読んでもらえれば足ります。

私たちの案件では、合意済みの要件定義書からClaudeが下書きし、エンジニアが直してからお客様にお渡ししています。この記事のプロンプトやファイルは、その流れを説明するために新しく作った例です。

環境

macOS 26.6.2、Python 3.14.6。スクリプトは標準ライブラリだけで動きます。2026年10月29日に動作を確認しました。下書きにはClaude Codeを使っていますが、プロンプトは他のAIツールでも使える書き方にしています。

この記事をざっくり図解

1. チェックリストの列を決める

先に列を決めておくと、AIの出力も、人の手直しも、この形に揃えられます。この記事では列を9つにしました。

checklist-template.md

# 受入テスト チェックリスト

- 対象システム:
- テスト環境URL:
- バージョン(またはリリースタグ):
- 実施期間:

| No. | 要件ID | 画面・機能 | 操作 | 期待する結果 | 実際の結果 | 判定 | キャプチャ | 確認者・日付 |
|---|---|---|---|---|---|---|---|---|
| 1 | REQ-001 | 注文登録 | 電話番号を空欄のまま「保存」を押す | 電話番号欄の下にエラーが表示される | | | | |
| 2 | REQ-001 | 注文登録 | すべての項目を入力して「保存」を押す | 注文一覧に新しい注文が表示される | | | | |
| 3 | REQ-002 | 注文一覧 | 注文を1件選び「取消」を押す | 一覧の状態が「取消」になる | | | | |
| 4 | REQ-003 | ログイン | 一般ユーザーでログインする | 画面に管理メニューが表示されない | | | | |

列の意図は次のとおりです。

• 要件ID: 要件定義書のどの項目を確かめる行なのかを結びます。あとで「この要件は誰が確認したのか」を引けるようにするためです。
• 操作と期待する結果: 1行に1つずつにします。2つの操作を1行に詰めると、どちらで失敗したのかが分からなくなります。
• 実際の結果: 自由記述です。期待と違ったときだけでなく、チェックリストにない違和感もここに書いてもらいます。
• キャプチャ: ファイル名を書く欄です。画像そのものは別のフォルダに置きます(後述)。

表の上にバージョンを書く欄を置いているのは、どのバージョンで確認した結果なのかを、表だけで分かるようにするためです。

2. AIに下書きさせる

要件定義書を渡して、上の表の形で出力させます。ルールの中で効いているのは、「根拠のない行は作らない」と「決められないことは確認事項に分ける」の2つです。

uat-checklist-prompt.txt

添付の要件定義書(requirements.md)から、受入テスト用のチェックリストを作ってください。
読む人は、このシステムを使う業務担当の方です。開発者ではありません。

ルール:
- 1行に、1つの操作と1つの期待する結果だけを書く
- 画面に表示される言葉(ボタン名、項目名)で書く。関数名やテーブル名は書かない
- 正常な操作に加えて、入力漏れ、権限のない人の操作、取り消しの操作も含める
- 要件定義書の項目番号を「要件ID」列に書く。根拠になる記述がない行は作らない
- 要件定義書から期待する結果を決められない場合は、行を作らず、最後に「確認事項」としてまとめる
- 「実際の結果」「判定」「キャプチャ」「確認者・日付」の列は空欄にする

出力: checklist-template.md と同じ列のMarkdownの表と、確認事項の箇条書き

「確認事項」に出てきたものは、エンジニアが推測で埋めずに、発注側に確認します。チェックリストの段階で仕様の穴が見つかることもあるので、ここは捨てずに読みます。

3. 要件IDの抜けをスクリプトで確かめる

AIの下書きを人が直すとき、最初に機械で確かめておきたいのが、すべての要件がチェックリストに1回以上出てくるかどうかです。要件IDが REQ-001 の形になっている前提の、小さなスクリプトです。

check_coverage.py

#!/usr/bin/env python3
"""要件定義書の要件IDが、受入テストのチェックリストに1回以上出てくるかを確かめる。"""
import re
import sys

ID_PATTERN = re.compile(r"\bREQ-\d{3}\b")


def ids_in(path):
    with open(path, encoding="utf-8") as f:
        return set(ID_PATTERN.findall(f.read()))


def main():
    if len(sys.argv) != 3:
        print("usage: check_coverage.py requirements.md checklist.md")
        return 2
    required = ids_in(sys.argv[1])
    covered = ids_in(sys.argv[2])
    missing = sorted(required - covered)
    unknown = sorted(covered - required)
    for req_id in missing:
        print(f"チェックリストにない要件: {req_id}")
    for req_id in unknown:
        print(f"要件定義書にないID: {req_id}")
    if not missing and not unknown:
        print(f"OK: {len(required)}件の要件がすべてチェックリストにあります")
    return 1 if missing or unknown else 0


if __name__ == "__main__":
    sys.exit(main())

REQ-001からREQ-003まである要件定義書に対して、REQ-002の行がなく、要件定義書にないREQ-009の行が混ざったチェックリストを渡すと、こうなります。

$ python3 check_coverage.py requirements.md checklist.md
チェックリストにない要件: REQ-002
要件定義書にないID: REQ-009
$ echo $?
1

REQ-009のような行は、AIが根拠のない項目を足したか、IDを書き間違えたかのどちらかです。どちらにしても人が見る必要があります。直したあとはこうなります。

$ python3 check_coverage.py requirements.md checklist.md
OK: 3件の要件がすべてチェックリストにあります

このスクリプトが見ているのは、IDが出てくるかどうかだけです。1つの要件に対して、正常な操作の行しかない、といった偏りは見つけられません。そこは人が読みます。手直しのときに見る点は、たとえば次のとおりです。

• 権限の違う利用者ごとに行があるか
• 入力漏れや取り消しなど、うまくいかない操作の行があるか
• 期待する結果が、画面を見れば判定できる書き方になっているか(「正しく処理される」は判定できません)

4. キャプチャを残す

キャプチャの欄には、画像そのものではなくファイル名を書いてもらいます。ファイル名に入れるのは、行の番号と、確認したバージョンです。

uat/
  v1.4.0/
    003_注文一覧_取消_20261204.png
    004_ログイン_一般ユーザー_20261204.png

キャプチャを残す理由は2つあります。不具合が最初の報告で正確に伝わり、「その前にどこを押しましたか」と聞き直す必要がなくなること。そして、どのバージョンを誰がどう確認したかが、発注側と開発側の双方に残ることです。

判定が「NG」になった行は、そのままチケットにします。チケットに写すのは、行の番号、操作、期待する結果、実際の結果、キャプチャのファイル名です。直したあとは、同じ行をもう一度確認してもらい、新しいバージョンのフォルダにキャプチャを残します。前のバージョンのキャプチャは消しません。

5. この方法でできないこと

• チェックリストが確かめるのは、要件定義書に書いてあることだけです。書かれていない業務の例外は行になりません。
• キャプチャは結果を残すものです。結果が正しいかどうかを判定するのは、業務を知っている人です。
• 画面のないバッチ処理や、組み合わせの多い入力の網羅は、このチェックリストの役割ではありません。自動テストで確かめる部分です。
• 要件IDのない要件定義書には、スクリプトがそのままでは使えません。先にIDを振るところから始めることになります。

また、私たちもこのやり方をすべての案件で同じ形で使っているわけではありません。多くの案件で使っている開発フローの中の、受入テストの工程の話です。

最後に

受入テストのチェックリストは、作るのにも回すのにも手間がかかります。下書きをAIに任せ、抜けの確認を機械に任せると、人は「この期待する結果で業務が回るか」を読むことに時間を使えます。列とスクリプトは、それぞれの現場のIDの付け方に合わせて変えて試してみてください。

参考文献

• VAON ブログ「Claude Codeを使った開発フロー　実案件の10ステップと人の判断」(受入テストがフロー全体のどこに入るか): https://vaon.com.vn/ja/blog/claude-code-development-workflow-client-projects?utm_source=qiita&utm_medium=referral&utm_campaign=claude-code-workflow
• Python ドキュメント「re: 正規表現操作」
• Qiita「Qiitaコミュニティガイドライン」(AIが生成した内容の検証について)