テストエビデンスの取り方｜どこまで取るかの判断基準

2026 8/14

2026年8月14日 2026年8月14日

「この項目は画面全体を撮るべきか、それとも結果の数字の部分だけでいいのか」。テスト実行の手を止めて、キャプチャ範囲に何分も悩んだ経験はないでしょうか。

「そもそも全ケース撮る必要があるのか」という疑問を、聞ける相手がいないまま自己流で片付けてきた方もいるかもしれません。

テストエビデンスの取り方で迷う原因は、キャプチャの撮り方を知らないことではありません。「取る／取らない」を決める基準が手元にないことです。

基準がないから毎回ゼロから考えることになり、判断も人によってブレます。結果として、取りすぎて工数が膨らむか、足りずに指摘されるかの両極端になります。

この記事では、取得範囲の決め方を、現場でそのまま流用できる形で次の順に整理します。

どこまで取るかを決める3つの判断軸と、判断マトリクス
顧客に取得範囲を合意してもらう進め方
テストレベル別・OK/NG別の取得粒度の早見表
そのまま使える命名フォーマットとフォルダ構成
台帳での突合と、証跡を取れなかったときの対処

テストエビデンスの取り方は「範囲の合意」から始まる

先に結論をお伝えします。エビデンスの合格ラインは「きれいに撮れているか」ではなく、第三者が同じ結論に到達できるかの一点だけです。

その範囲を実行前に決めて関係者と合意しておけば、後出しの指摘も念のための撮りすぎも防げます。エビデンスは作業しながら考えるものではなく、テスト設計の一部として先に決めるものです。

エビデンスの合格ラインは「第三者が再現・検証できるか」

リー・コープランド『はじめて学ぶソフトウェアのテスト技法』では、事前に設計・文書化したテストが必要とされる条件として、再現性・客観性・監査性が挙げられています。原典での客観性は「作成者の非凡なスキルに依存せず、よく理解されたテスト設計原則に基づくこと」を指します。

これをエビデンスに置き換えると、合格ラインは次の3点です。

再現性: 撮った本人以外が読んでも、何をどう操作した結果なのかが分かる
客観性: 撮る人のセンスに頼らず、決めた基準どおりに期待結果と実際の値が写っている
監査性: どのテスト項目の証跡かが、ファイル名か台帳から一意にたどれる

迷ったら「初見の人が見て、同じ合否判定に至れるか」と自問してください。これが以降すべての判断の親ルールです。

「全部撮る」が最も危険な理由

基準がないときの安全策が「とりあえず全部撮る」ですが、もっとも失敗しやすい選択です。撮影とリネームが数百件積み上がれば実行を圧迫しますし、量が多すぎると必要な証跡が埋もれ、検収担当がどれも読まなくなります。

テスト実行前に決めておく3つのこと

決めること	決めないまま進めた場合に起きること	決めるタイミング
取得範囲（どの項目で取るか）	全件撮って工数超過、または重要項目の撮り漏れで差し戻し	テストケース作成時
取得物の種類（画面／ログ／DB）	画面だけ残り、バッチや裏側の処理を証明できない	テスト設計レビュー時
納品形式（Excel／フォルダ／PDF）	実行後に形式変更を求められ、数百件の再整形が発生	テスト計画の合意時

顧客に取得範囲を合意してもらう進め方

「取らない」判断が通るかは、社内基準の出来ではなく顧客と事前に合意できているかで決まります。実行後に説明しても「それは御社の基準ですよね」で終わります。

テスト計画書やテスト設計レビューの場で、後述の判断マトリクスと粒度4段階を先に提示して承認をもらう。実行前に出すのが要点です。
その場で基準を言葉にして確認する。「リスクの低い表示確認は結果部分のみ1枚、金銭処理は画面とログをセットで取得します。この基準でよろしいでしょうか」と具体例で聞きます
合意内容を計画書に一文残す。「エビデンスの取得範囲は別紙の判断基準に従う」と書いておけば、検収時の拠り所になります

エビデンスの定義や役割から固めたい場合は、エビデンス管理の基礎から確認すると、この先の判断基準が入りやすくなります。

エビデンスをどこまで取るかを決める3つの判断軸

取得粒度は「リスク × テストレベル × 契約・監査要件」の3軸で決めます。

3軸で決める最大のメリットは、「取らない」という判断にも根拠が付くことです。後から「なぜこの項目の証跡がないのか」と聞かれても、基準を示して説明できます。

軸1：リスク（壊れたときの影響と発生しやすさ）

金銭計算、個人情報の取り扱い、送信・確定・削除といった取り消せない処理は、影響が大きく後から検証を求められる可能性も高いため、証跡を最大限に残します。一方、表示崩れや文言確認、並び順の目視は復旧が容易で、同じ工数は要りません。

ある案件の振り返りでも「重要度・リスク・確認容易性で順位付けするところまでがテスト設計」という教訓が出ていました。エビデンスの要否も、項目一覧を作った時点で一緒に順位付けします。

評価軸そのものを整理したい場合は、リスクベースドテストの考え方を確認すると、優先度の付け方を押さえられます。

軸2：テストレベル（誰に対する証明か）

単体テストは、開発者が自分の実装を説明できれば足り、実行結果のログがあれば十分です。一方、受入テストは相手が顧客です。業務の言葉で「この操作をしたら、この結果になった」と読み取れなければ、証拠として機能しません。

相手を取り違えると、開発者向けのログを顧客に出して「これでは分かりません」と返されます。テストレベルごとの目的の違いを確認するところから整理すると迷いが減ります。

軸3：契約・監査要件（外から要求される最低ライン）

契約書や業界規制で「証跡を残すこと」が明示されていれば、判断の余地はありません。この軸は軸1・軸2より優先し、リスクが低い項目でも取ります。

受託開発では、テスト文書の提出そのものが契約要件になっているケースが珍しくありません。参照される枠組みは、現在は ISO/IEC/IEEE 29119 で、ドキュメントを規定するのは多部構成のうち Part 3 です。かつて広く使われた IEEE 829 は2013年にこの 29119-3 へ統合・置換された旧規格にあたります。社内規程やRFPの表記は「ISO/IEC/IEEE 29119-3（旧 IEEE 829）」に統一しておくのが安全です。

エビデンスに直結する文書種別は、実行の時系列記録であるテスト実行ログと、不具合を記録するインシデントレポートの2つです。どの文書を作るかは組織が選んでよく、作ると決めたなら定めた形式に従う、という考え方も共通しています。

テスト実行記録の一般的な定義は、JSTQB Foundation Level シラバス v4.0（日本語版）で確認できます。

3軸を1枚にした判断マトリクス

取得粒度は次の4段階に整理できます。

フル: 操作前後の画面＋ログ＋データの状態まで残す
標準: 操作後の画面全体（期待結果が写る範囲）を1枚
最小: 結果部分のみを1枚
不要: 取得しない（台帳に「不要」と記録する）

判断は、契約・要件の指定があればそれに従い、なければリスクで判定します。

リスク	操作前の状態	画面全体	結果部分のみ	ログ・データ	粒度
高（金銭・個人情報・不可逆処理）	◎必須	◎必須	○推奨	◎必須	フル
中（主要業務フロー・連携処理）	△更新系のみ必須	◎必須	○推奨	△任意	標準
低（表示・文言・並び順）	—不要	△任意	○推奨	—不要	最小
極低（他項目で結果が担保される）	—不要	—不要	—不要	—不要	不要

契約・監査要件がある場合は、この判定を上書きします。

テストレベル別・OK/NG別に見る取得粒度の目安

3軸を実務に当てはめると、テストレベルごとの標準形が見えてきます。さらに重要なのが、OK時とNG時で取得量を変える非対称ルールです。

テストレベル別の粒度早見表

テストレベル（JSTQB用語）	証明の相手	標準の取得物	NG時の追加取得
単体（コンポーネント）	開発者・レビュアー	実行結果ログ	スタックトレース、入力値
結合（コンポーネント統合）	開発チーム・リーダー	モジュール間の入出力、連携後のデータ	双方のアプリログ
システム	自社の品質責任者	業務シナリオ単位の画面、バッチ実行結果	環境情報、直前操作、DBレコード
システム統合	自社・連携先の担当者	外部システムとの送受信データ、API応答	通信ログ、連携先の受信記録
受入	顧客・検収担当	画面全体（URL・日時が写る形）	再現手順、入力データ、業務影響

単体テストで画面キャプチャが不要な理由は、証明の相手が開発者であり、実行結果ログのほうが入力値と戻り値を正確に示せるためです。カバレッジ出力は網羅度の指標であり個々の項目の合否は証明しないため、テストレベルの完了判定として別枠で取得します。

受入テストに含まれる運用受入（バックアップ・リストアなど）は、画面ではなく実行ログと手順の完了記録で残します。各レベルの定義はJSTQBの公式サイトでも確認できます。

OK時は「最小限」、NG時は「最大限」という非対称ルール

合格ケースで必要なのは「期待結果が満たされたこと」の1点だけです。それが確認できる画面が1枚あれば足り、途中の遷移を1枚ずつ撮る必要はありません。

ただし例外があります。OKでも、データ更新・金額計算・不可逆処理は操作前後をセットで残してください。差分が証拠であり、結果画面だけでは前回実行の残存データや別レコードと区別できません。

不合格ケースは逆です。後から再現調査をするのは、数日後の自分か事情を知らない別の担当者で、情報が欠けていると再現だけで半日溶けます。

OKは期待結果が写る最小限、NGは再現に必要な情報を全部。この非対称を意識するだけで、総工数は下がります。

NG時に追加で残す情報セット

不合格を見つけた瞬間に、次の情報を確保してください。あとから揃えるのはほぼ不可能です。

期待結果と実際結果: どちらも1行で明記する。画面だけでは差分が伝わらない
発生日時: 画面上に時刻が写る形で
環境: ブラウザとバージョン、OS、接続先の環境名
直前の操作手順: どの画面から、何を入力し、どのボタンを押したか
入力データ: 実際に入れた値（個人情報はマスキングする）
アプリログ: 発生時刻前後の該当行。全体ではなく抜粋
DBの該当レコード: 更新前後が比較できる形
再現頻度: 試行回数と発生回数（例: 3回中3回）。1回しか起きていない場合はその旨を書く

この情報セットは、そのまま不具合報告の材料になります。再現手順が伝わるバグ票の書き方を確認すると、集めた情報を無駄なく渡せます。

スクリーンショットとログ、それぞれの取り方の実務ルール

判断の分かれ目は「特定できるか」です。部分キャプチャは軽い反面、どの画面の、どの環境の、いつのものか特定できないと証拠の価値がゼロになります。

原則: ウィンドウ全体（URL・画面タイトル・日時が入る範囲）を1枚
補助: 判定箇所が読みにくい場合だけ拡大を追加（全体とセットで保存）
例外: 帳票やPDFなど、それ自体で対象が特定できる成果物

必ず写し込む4要素（日時・環境・対象データ・期待結果）

日時: OSの時計を常時表示にし、日付まで出る形式に設定する
環境: URLに環境を判別できるドメインが出ていれば、ウィンドウ全体の撮影で足りる。判別できない場合はキャプチャツールのタイムスタンプ焼き込み機能を使う
対象データ: テストデータのIDや注文番号が画面上に出る状態にする
期待結果の該当箇所: 判定対象の値が省略表示や折りたたみで隠れていないか確認する

環境名を出すヘッダを検証環境に仕込むのは確実ですが、開発側の改修が必要で、顧客環境なら申請も要ります。これは開発担当に依頼できる場合の上位手段と考えます。

画面以外に残すべきエビデンスと、加工の線引き

画面に出ない処理はキャプチャでは証明できません。別の手段で残します。

種類	取得する場面	保存形式	注意点
アプリログ	エラー発生時、非同期処理の確認	テキスト（該当行を抜粋）	個人情報・トークンを伏せる
DBデータ	更新・削除処理の結果確認	CSVまたは結果画面	更新前後をセットで残す
通信ログ	外部連携・API呼び出しの確認	テキストまたは開発者ツール	認証情報を必ず伏せる
バッチ実行結果	夜間処理・一括処理の確認	実行ログ＋処理件数	実行日時と対象件数を含める

本番相当のデータを扱う場合、マスキングは必須です。一方で、加工は改ざんを疑われる原因にもなります。線引きは3点で覚えてください。

許容: 個人情報・認証情報のマスキングのみ
不可: 判定対象の値、日時、URL、環境表示のトリミングや修正
記録: マスキングした場合は、台帳の備考に対象項目を記載する

テストエビデンスの取り方を仕組み化するファイル命名規則とフォルダ構成

粒度が決まったら、次は整理の仕組みです。ここを決めないと、正しく撮った証跡が後から使えなくなります。

命名規則はテストケースIDを起点にする

ファイル名の目的はただ一つ、テスト項目と1対1で対応させることです。日付だけ、連番だけの名前は、後から突き合わせるときに何の助けにもなりません。

『ソフトウェアテスト自動化の教科書』（技術評論社）では、命名規約を「テストケース名_機能名_テストケースNo」のような形式で定め、後から何の試験か分かる名前にしないと「新規作成したほうが早い」という事態を招くと指摘されています。名前から対応項目が分からないファイルは、あっても「無いのと同じ」です。

そのまま使える命名フォーマット

パターン	フォーマット例	向いているケース
基本形	`TC-0142_01_OK.png`	1項目あたり1〜2枚。もっとも汎用的
手順が多い場合	`TC-0142_03_受注確認画面.png`	画面遷移をたどる業務シナリオ
環境が複数ある場合	`chrome-win_TC-0142_01.png`	ブラウザ別・OS別に同じ項目を確認する
再テスト	`TC-0142_R1_01_OK.png`	不具合修正後の再確認（`R1` が1回目の再テスト）
ケース外（探索的・調査）	`EX-20260810_01_受注登録.png`	テストケースIDがない探索的テストや障害調査

探索的テストやアドホックな確認は、EX- で始まるセッション単位の行を台帳に起票し、目的・時間枠・発見事項を残します。ケースIDのない確認を「ルール外」にしないことが、管理外の証跡をなくすコツです。

次の点は先に合意します。あとから変えると全ファイルのリネームが発生します。

ゼロ埋め: 連番は2桁以上（10件を超えた瞬間に並び順が崩れる）
区切り文字: アンダースコアかハイフンのどちらかに統一する

フォルダ構成の型

階層は「テストレベル＞機能＞テストケースID」が基本形です。初回NGと再テストOKは同じフォルダに並べ、初回分を削除しません。

` evidence/ ├─ 01_システムテスト/ │ ├─ 受注登録/ │ │ ├─ TC-0142/ │ │ │ ├─ TC-0142_01_NG.png │ │ │ └─ TC-0142_R1_01_OK.png │ │ └─ TC-0143/ │ └─ 請求出力/ ├─ 02_受入テスト/ ├─ 90_不具合/ │ └─ BUG-021/ │ ├─ BUG-021_再現手順_01.png │ └─ BUG-021_エラーログ.txt └─ エビデンス台帳.xlsx `

不具合の証跡は複数ファイル・複数形式になりやすいため、テストケース配下に混ぜず独立させます。

1項目1〜2枚しか撮らない案件では、ケースID階層を作ると中身の薄いフォルダが並びます。その場合は機能フォルダ直下にファイルを置く簡略版で十分です。

` evidence/ ├─ 01_システムテスト/ │ ├─ 受注登録/ │ │ ├─ TC-0142_01_OK.png │ │ └─ TC-0143_01_OK.png │ └─ 請求出力/ └─ エビデンス台帳.xlsx `

自分のプロジェクト用ルールを決める5つの手順

テストケースIDの形式を確認する: 既存のテストケース表のIDをそのまま起点にする
区切り文字とゼロ埋めを決める: 決まっていることが重要で、内容は何でもよい
階層を決める: 上記の3階層か簡略版から、案件の規模に合わせて選ぶ
サンプルを1件作ってチームに共有する: 文章のルールより実物1件のほうが速く伝わる
エビデンス要否を書き込む場所を用意する: 自社のテストケース表なら「エビデンス要否」欄を1列追加する。顧客からフォーマットを指定されている案件は、提出用ファイルに列を足すと様式違反を指摘されるため、テストケースIDだけ揃えた作業用シートを別に作り、そちらに要否列を持たせる（列追加の可否はテスト計画の合意時に確認）

テスト項目と1対1で突き合わせる台帳と、納品形式の選び方

ファイル名だけでは取り漏れを検出できません。「撮ったもの」ではなく「撮るべきだったもの」を管理するのが台帳の役割です。

エビデンス台帳に持たせる項目

列名	内容	記入タイミング
テストケースID	テストケース表と完全に一致させる	ケース作成時
テスト項目名	何を確認するかの要約	ケース作成時
エビデンス要否区分	フル／標準／最小／不要	ケース作成時
実施日・実施者	実行した日付と担当者名	実行時
環境	環境名・ブラウザ・バージョン	実行時
結果	OK／NG／保留	実行時
エビデンスファイル名	実際のファイル名（複数なら列挙）	実行時
不具合ID	NG時に起票した番号	NG判定時
再テスト日	修正後に再確認した日付	再テスト時
再テスト結果	再確認の結果（OK／NG）	再テスト時
確認バージョン	修正が適用されたリビジョン・リリース番号	再テスト時
備考	未取得の理由、マスキング対象など	随時

再テストの3列は、初回のNG行を上書きせずに埋めます。上書きすると不具合があった事実が消え、検収でもっとも見られる「NG → 修正 → 再テストOK」の追跡が切れます。

『ソフトウェアテストの教科書』（布施昌弘ほか著、SBクリエイティブ）では、テスト設計仕様書で重視すべき点として「追跡性・関連性（要件→仕様→テスト→結果の紐付け）」と「誰が読んでも同じ解釈ができる記述の粒度」が挙げられています。台帳が担うのが、この追跡性です。

「エビデンス要否」はテストケース作成時に決めておく

実行しながら考えるから迷います。要否欄を1列用意するだけで、実行時の判断コストはほぼゼロになります。

3軸の判断は、テストケースを書いている段階で前倒しします。その時点でリスクも証明の相手も契約要件も分かっているはずです。全体の流れは次のとおりです。

` テストケース表（または作業用シート）を作成 → 3軸で「エビデンス要否」を記入 ↓ テスト実行・取得（要否欄に従って撮る＝迷わない） ↓ 命名規則に従ってファイル名を付ける（テストケースID起点） ↓ 台帳に実施日・実施者・環境・結果・ファイル名を記録 ↓ 台帳とフォルダを突合してから顧客提出 `

台帳で「要」の行にファイル名が入っていなければ、それが取り漏れです。突合の手順は2つだけで、目視で数百件を追う必要はありません。

フォルダのファイル名一覧をテキストに書き出す（Windowsは dir /b /s > list.txt、Macは ls -R > list.txt）
一覧を台帳の別シートに貼り、COUNTIF でテストケースIDごとの件数を数え、要否が「不要」以外なのに件数0の行を抽出する

Excel（エクセル）貼り付けかフォルダ納品か

納品形式に唯一の正解はありません。相手がどう読むかで選びます。

形式	メリット	デメリット	向いている場面
Excel（エクセル）貼り付け	項目と証跡が並び1ファイルで完結	枚数が増えると重い	件数が少なく上から順に確認する
フォルダ納品＋台帳	差し替えが容易。原寸で確認できる	台帳を見ないと構造が分からない	件数が多い。特定項目だけ見に来る
PDF一括	改変しにくく閲覧環境を選ばない	更新が事実上できない	検収や監査で「確定版」として渡す
テスト管理ツール	項目と証跡が自動で紐づく	相手にアクセス権が必要	顧客と同じツールを使っている

保存期間は、契約や社内規程に明記があればそれに従い、なければ「次回改修時に参照できるか」を判断軸にします。保管場所は共有ストレージにします。個人のPCに残した証跡は、異動や機器交換で失われます。

報告フェーズまで整えたい場合は、テストレポートへのまとめ方を確認すると、台帳から報告書までがつながります。

やってはいけないアンチパターンと、取れなかったときの対処

差し戻されるエビデンス6パターン

アンチパターン	なぜダメか	代わりにどうするか
①後撮り（テスト後にまとめて撮る）	実行時の状態ではなく証跡にならない	実行と同時に撮る。撮れていなければ再実施可否を判定する
②加工しすぎ（トリミング）	どの画面・いつ・どの環境か特定できない	全体1枚を残し、拡大は補助にする
③時刻・環境が写っていない	実施日・環境を証明できない	OS時計の常時表示、URLでの環境判別
④同一画面の使い回し	実施の事実を示せない	項目ごとに撮る。共通画面は台帳で参照を明記
⑤NGなのに結果画面しかない	再現調査に時間がかかる	NG時の情報セットを必ず揃える
⑥ファイル名が `無題1.png`	項目と突き合わせられない	テストケースID起点の命名規則を適用する