受入テストのチェックリストの作り方 画面キャプチャが発注側を守る理由
要約： 受入テスト（UAT）のチェックリストは、利用者の言葉で書き、1項目に1つの操作と1つの期待する結果、そして実際の結果の画面キャプチャを残す形が基本です。VAONでは、合意済みの要件定義書からClaudeが下書きし、エンジニアが直したうえで、お客様に正しいバージョンで確認していただきます。キャプチャは、不具合を最初の報告で正確に伝え、どのバージョンをどう検収したかの記録になります。
目次
- 受入テストとは何か、なぜ自動テストだけでは足りないのか
- チェックリストはどのような順序でお客様に届くのか
- チェックリストのテンプレート：どの列を置き、よい項目はどう書くのか
- 画面キャプチャは、なぜ発注側を守るのか
- チェックリストを役に立たなくするよくある間違い
- チェックリストだけでは足りない場合
- よくあるご質問
1. 受入テストとは何か、なぜ自動テストだけでは足りないのか
受入テスト（UAT、User Acceptance Test）は、お客様側の利用者が実際にシステムを操作し、合意した内容どおりに動くかを確かめる工程です。自動テストでは、この工程を置き換えられません。
「AIがテストまで書いているなら、受入テストは軽くてもよいのでは」というご質問をいただくことがあります。私たちの考えは逆です。単体テストやE2Eテスト（利用者の操作を最初から最後までたどるテスト）が確かめているのは、開発側が仕様をどう理解したかです。理解がずれていれば、テストも同じようにずれたまま通ります。
しかもAIは、直前に書いたコードに合わせてテストを書きやすいため、このずれは開発側からは見えにくくなります。エンジニアがAIの書いたテストをどう読んでいるかは、プルリクエストに同梱するAI生成テストでご紹介しています。
ずれに気づけるのは、業務を知っている方が、実際の画面を実際の手順で触ったときです。受入テストのチェックリストは、Claude Codeを使った開発フローの9番目のステップにあたります。このフローは多くの案件で適用している基準ですが、すべての案件ではまだありません。
2. チェックリストはどのような順序でお客様に届くのか
受入テストのチェックリストは、コードが書き上がった直後ではなく、VAONのエンジニアが確認を終えたバージョンについてお届けします。流れは次の6つです。
- 反映：マージ後、CI/CDが新しいバージョンをテスト環境に自動で反映します。
- 社内での確認：VAONのエンジニアが先に確認し、明らかな不具合はお客様のお時間をいただく前に直します。
- 下書き：Claudeが、ソースコードではなく合意済みの要件定義書から下書きします。
- 手直し：エンジニアが開発者の言葉を外し、うまくいかない操作の項目を足し、各項目に要件IDを付けます。
- お客様による確認：実際の結果を記入し、キャプチャを添付し、確認したバージョンを書いていただきます。
- 修正と再確認：NGの項目は修正のタスクになります。修正後は、新しいバージョンで同じ項目を確認していただき、前のキャプチャも残します。
下書きの元を要件定義書にしているのは、コードから作ると、開発側の理解をなぞるだけのチェックリストになるからです。
AIが下書きできても、社内での確認と手直しは省いていません。2026年にお客様からいただいた質問で特に多かったものの一つが、「AIが書いたコードは誰が確認するのですか」でした。答えは何層かの人による確認で、その最後の層がお客様です。レビューとテストの記録はすべての案件で保存しており、いつでもご覧いただけます。
3. チェックリストのテンプレート：どの列を置き、よい項目はどう書くのか
VAONの受入テストのチェックリストは、項目、操作、期待する結果、実際の結果、キャプチャの5列です。表の上には、バージョン、環境、確認者、確認日を書きます。次の例は、架空の受注システムを使った説明用のもので、実際の案件ではありません。
バージョン：v1.4.0 ・ 環境：（テスト環境のURL）・ 確認者：（お名前）・ 確認日：（日付）
| 項目 | 操作 | 期待する結果 | 実際の結果 | キャプチャ |
|---|---|---|---|---|
| REQ-01 注文登録 | すべて入力して「保存」を押す | 注文一覧の先頭に新しい注文が表示される | （ご記入） | （添付） |
| REQ-01 注文登録 | 電話番号を空欄のまま「保存」を押す | 電話番号欄の下にエラーが表示され、保存されない | ||
| REQ-02 注文取消 | 注文を1件選び「取消」を押して確認する | 状態が「取消済み」になる | ||
| REQ-03 権限 | 一般スタッフのアカウントでログインする | 「管理」メニューが表示されない |
よい項目には、次の5つの条件があります。
- 1行に操作1つ、結果1つ。こうしておくと、失敗したときにどこで失敗したかがすぐ分かります。
- 画面に表示される言葉（ボタン名、項目名）で書きます。関数名やテーブル名は書きません。
- 期待する結果は、画面を見て判定できる書き方にします。「正しく処理される」は判定できませんが、「状態が取消済みになる」は判定できます。
- 要件ごとに、うまくいかない操作の項目を1つ以上入れます。入力漏れ、権限のない人の操作、途中での取り消しなどです。
- 各項目に要件IDを書きます。あとから、どの要件を誰が確認したかをたどれるようにするためです。
4. 画面キャプチャは、なぜ発注側を守るのか
画面キャプチャが発注側を守るのは、「確認しました」という言葉を、双方が照合できる記録に変えるからです。
一つ目の役割は、不具合が最初の報告で正確に伝わることです。エンジニアはお客様と同じ画面を見られるので、「その前にどこを押しましたか」と聞き直す必要がありません。時差や言語の違いがある場合には、やり取りの往復が減ります。
二つ目の役割は、どのバージョンを、誰が、どう確認したかが残ることです。情報システム部門の方は、社内に向けて「何を確認してリリースを認めたのか」を説明する立場にあります。口頭の「問題ありませんでした」では、その説明に使えません。
検収は、契約の上でも区切りになります。IPAと経済産業省がまとめた情報システム・モデル取引・契約書の見直しの整理（2019年12月）では、契約不適合責任の期間制限の起算点を、検収完了時とする考え方が維持されています。同じ資料は、十分な検査には仕様書の機能確認だけでなく多様なテストケースが必要になる場合があるとし、検査仕様書の作成でユーザとベンダが協力することを望ましいとしています。
これは参考資料であり、法的な助言ではありません。責任の範囲は案件ごとの契約で定めるもので、VAONは「AIが書いた」ことを理由に責任の範囲が変わるとは考えていません。契約で決めておくことは、AIが書いたコードに不具合が出たら、責任は誰にあるのかにまとめています。
5. チェックリストを役に立たなくするよくある間違い
受入テストのチェックリストが役に立たなくなる原因は、主に次の5つです。どれも、お客様にお渡しする前に直せます。
| 間違い | 例（説明用） | 直し方 |
|---|---|---|
| 開発者の言葉で書く | 「POST /orders が201を返す」 | 「保存を押すと、一覧に新しい注文が表示される」 |
| うまくいく操作しかない | すべて入力した注文登録だけを確認する | 入力漏れ、権限違い、途中取消の項目を足す |
| 違うバージョンで確認する | 古い環境、またはブラウザに前のバージョンが残っている | 表の上にバージョンを書き、キャプチャにバージョンか日時を写す |
| 期待する結果があいまい | 「正常に動作する」 | 画面に表示されることを書く |
| キャプチャに前後が写っていない | エラーメッセージだけを切り取っている | 画面全体を、画面名が分かる形で撮る |
いちばん手戻りが大きいのは、違うバージョンでの確認です。前日に直した不具合をもう一度報告したり、リリースしないバージョンを検収したりすることになります。
6. チェックリストだけでは足りない場合
受入テストのチェックリストが確かめられるのは、要件定義書に書いてあることだけです。そのため、次のような場面では足りません。
- 書かれていない業務の例外は、項目になりません。チェックリストにない違和感は、「実際の結果」の欄にそのまま書いていただくのがいちばん役に立ちます。
- 画面のないバッチ処理や、組み合わせの多い入力の網羅は、自動テストで確かめる部分です。
- キャプチャは結果を残すもので、正しいかどうかを判定するのは業務を知っている方です。
- 受入テストには、お客様側のお時間が必要です。業務を知っている方の時間が取れなければ、チェックリストは紙のままです。
文言の修正のようなごく小さな変更であれば、数項目の確認で足ります。
7. よくあるご質問
チェックリストは、発注側で作る必要がありますか？ 必要ありません。このフローを適用している案件では、合意済みの要件定義書からClaudeが下書きし、VAONのエンジニアが直してからお渡しします。お客様には、事前に目を通していただき、足りないと感じる業務の場面を追記したうえで、項目ごとに確認していただきます。追記する項目も、同じ書き方にそろえていただくと確認がスムーズです。
受入テストには、どのくらいの期間がかかりますか？ 要件の数や利用者の役割の数によって変わるため、一律の期間はお示ししていません。受入テストの日程は、最初の計画の段階で合意します。VAONのエンジニアが先に確認しているので、お客様のお時間は業務の確認に使っていただけます。明らかな不具合でつまずくことは減らせます。
チェックリストにない問題を見つけたら、どうすればよいですか？ 「実際の結果」の欄に、キャプチャを添えてご記入ください。合意済みの要件と違う動きであれば、VAONが直します。範囲外の新しい作業であれば、費用と納期への影響を書面でお伝えし、ご承認をいただいてから着手します。詳しくは追加費用が発生しない開発会社の見分け方をご覧ください。
キャプチャ付きのチェックリストは、検収書の代わりになりますか？ なりません。チェックリストは検収を裏付ける資料で、検収の手続きは案件ごとの契約で定めます。違いが出るのは、検収の根拠です。合意した要件のそれぞれに確認項目があり、各項目に特定のバージョンでの結果とキャプチャが残っているので、あとから双方が同じ記録を見て話せます。
受入テストで本番のデータを使ってもよいですか？ どのデータを使い、誰が見られるかは、案件を始める前に合意します。ご許可がない限り、VAONがお客様のデータやコードをAIツールに入れることはありません。チェックリストは要件定義書から下書きするので、本番のデータは不要です。本番のデータで確認される場合は、送る前にキャプチャに個人情報が写っていないかをご確認ください。
今日からできることが一つあります。直近の検収の記録を開き、どのバージョンを確認したかが書かれているかを見てください。書かれていなければ、次回のチェックリストの先頭に「バージョン」の行を足し、キャプチャにバージョンか日時が写るようにお願いしてみてください。
受入テストのチェックリストを貴社の案件に当てはめるとどうなるか、無料相談（60分）でご説明します。CEOが同席します。資料のご準備は不要で、ご契約を前提としたものではありません。
執筆者： ダン・ヴァン・ルアン（Đặng Văn Luân）、VAON 創業者・CEO。ハノイ工科大学 HEDSPI 卒業。FPT Softwareを経て、Digital Plus（東京）で5年間、1,000万人が利用するシステムの開発に携わる。その後8年間、従業員120名のITアウトソーシング企業でCOOを務め、ISO 9001・ISO 27001に基づく管理体制を構築。業界経験15年。
参考資料
- 独立行政法人情報処理推進機構・経済産業省「～情報システム・モデル取引・契約書～ 第一版及び追補版 DX推進のための見直しにおける民法改正を踏まえた整理にあたって」（2019年12月）：https://www.ipa.go.jp/archive/digital/model/ug65p90000001lgm-att/000079617.pdf（2026年10月29日確認）
