企業AIプロジェクトWiki · テスト・検収
検収基準
別名受入基準 · Acceptance criteria · 合格基準
検収基準とは、指定した成果物またはバージョンを受け入れられるか判断するため、関係者が事前に合意する検証可能な条件です。対象、適用場面、期待結果、許容範囲、検証方法、必要な証拠、判定権限を定め、その場の感覚ではなく記録に基づいて合否を決められるようにします。
検収基準が解決すること
要件は実現すべき能力や制約を示し、検収基準は確認すべき結果を判定条件へ変えます。顧客、実施チーム、テスト担当が完成の意味を共有し、範囲、見積もり、日程、テスト、問題処理を同じ根拠で扱えるようにします。
基準は実装と正式検収の前に合意します。承認済み要件変更に伴う修正は可能ですが、理由、影響、承認者、適用版を記録し、結果を見た後に都合よく判定方法を変えてはいけません。
対象は機能、データ、連携、納品版、案件フェーズ全体などです。対象が広いほど個別に検証できる条件へ分割し、一つでも失敗すれば不合格となる重要条件を明確にします。
実行可能な検収基準の構成
すべてを八つの欄に分ける必要はありませんが、基準または参照する検収資料から次の情報を確認できる必要があります。
基準IDと要件の出所
安定した識別子を付け、要件、範囲、業務規則、リスクと結び付け、変更と結果を追跡できるようにします。
明確な検収対象
機能、API、データ、文書、モデル設定、具体的な版を示し、変更前後の結果が混ざらないようにします。
前提条件と場面
利用者役割、権限、環境、データ状態、外部依存、通常・境界・異常・情報不足の場面を示します。
観測可能な期待結果
画面、データ、システム動作、業務状態、人への引き継ぎに何が起きるかを直接記述します。
しきい値と許容範囲
時間、件数、誤差、成功率、品質水準について単位、母集団、算出方法、サンプル、許容差を定めます。
検証方法
テスト、デモ、検査、分析、資料レビューのいずれで、誰またはどの自動化が確認するかを定めます。
証拠と保存場所
報告書、ログ、画面、サンプル版、課題票、承認記録を定め、結論を再確認できるようにします。
判定権限と例外
誰が合格を決め、どの失敗が検収を止め、どの逸脱を条件付きで受け入れ、誰が例外を承認するかを示します。
通常、基準が必要になる観点
業務・機能結果
各役割が目的の業務を完了でき、規則、状態遷移、計算、異常表示が確認済み要件と一致するか。
データ・連携結果
項目、形式、マッピング、重複排除、同期、再試行、突合が正しく、差異を発見し処理できるか。
性能・容量・可用性
合意した負荷と条件で応答、処理量、同時実行、資源消費、連続運転、復旧を確認し、条件のない数値だけを書きません。
セキュリティ・権限・監査
各役割の許可・禁止操作、機密操作の確認、追跡可能性、既知リスクの処理を検証します。
運用・保守性
デプロイ、設定、監視、アラート、バックアップ、復旧、連絡方法が機能し、引受チームが運用を継続できるか。
納品物の完全性
コード、設定一覧、配備手順、操作資料、ライセンス、アカウント、研修を範囲と照合し、正式版と対応させます。
要件を検収基準へ変える手順
対象と判定者を固定する
今回の範囲、正式版、結論を出す権限を持つ人または会議体を確認します。
業務結果とリスクから始める
利用者が完了すべき仕事、起きてはならない誤り、失敗時の業務影響を列挙します。
場面を分ける
通常、境界、異常、権限不足、情報不足、外部依存障害を別々の結果として記述します。
測定方法としきい値を決める
サンプル、環境、反復回数、算出方法、許容差を定め、定量化しにくい場合は人の評価尺度を作ります。
証拠と停止条件を定める
結果の保存方法と、セキュリティ、データ破損、権限外操作などで検収を即時停止する条件を示します。
共同確認して版を固定する
業務、技術、テスト、案件責任者が理解可能性、実行可能性、費用を確認し、実装前に版付きで合意します。
変更の追跡を保つ
要件、基準、テスト、課題を一緒に更新し、旧結果で変更後の基準や版の合格を証明しません。
曖昧な表現と検証可能な表現
右欄は構造の例です。具体的な数値は案件の要件、リスク、検証可能な根拠から決定します。
| そのままでは判定できない | テストへ展開できる |
|---|---|
| システムは速く応答する | 合意した環境と負荷で、指定した主要操作が合意済み算出方法による目標応答時間を満たし、報告書を保存する。 |
| AIの回答は正確である | 固定した層別サンプルで、事実、引用、情報不足、機密場面、高リスク操作を別々の指標、しきい値、重大失敗規則で評価する。 |
| 権限機能が正常である | 役割ごとの許可・禁止操作を列挙し、権限外アクセスを拒否して監査に残し、許可操作後の業務状態が正しく更新される。 |
| API連携が完了した | 成功、重複、タイムアウト、不正データ、依存障害で合意項目を確認し、変換、再試行、冪等性、アラートがAPI合意に従う。 |
| 案件資料を納品した | 一覧の名称、版、可読性、必要権限、受領者を確認し、指定された引受担当者が配備手順で一度管理された検証を行う。 |
結果から検収結論を出す方法
総合点だけでなく項目別に記録
合格、不合格、阻害、非該当を実結果と証拠付きで残し、総合点でセキュリティ、データ、主要業務の失敗を隠しません。
重大基準には独立したゲート
権限外操作、データ破損、誤業務処理、復旧不能は、低リスク項目との平均ではなく即時停止または不合格条件にできます。
課題を閉じる
失敗の重要度、影響、担当、修正版を記録し、識別可能な対象で再テストと影響範囲の回帰確認を行います。
条件付き受入を明示
未解決課題を残して受け入れる場合、逸脱、リスク、暫定対策、担当、期限、承認者を記録します。沈黙は承認ではありません。
結論を版に結び付ける
版、環境、サンプル、基準版、実施日、確認者を記録し、その後の重要変更では影響範囲を再判定します。
企業AIで追加すべき検収基準
- サンプルは実利用と高リスク場面を表すか
業務、役割、資料品質、リスクで層別し、出所、版、適用限界を記録します。
確認：サンプル一覧、ラベル分布、抽出方法、業務レビュー。
- 異なる結果を別々に測っているか
事実性、引用、完全性、拒否、ツール実行、人への引き継ぎには別々の指標とゲートが必要です。
確認：場面別指標、人の評価尺度、重大失敗一覧。
- 情報不足を検収場面に含めたか
根拠不足、矛盾、範囲外では、捏造ではなく合意した確認、拒否、引き継ぎ動作を行います。
確認：情報不足サンプル、期待動作、引用・拒否記録。
- 業務を変更する操作に強い制御があるか
注文変更、通知、書込み、承認、支払は、引数、権限、確認、冪等性、監査、失敗復旧を検証します。
確認：ツール権限表、操作ログ、重複・失敗結果。
- 変動と版変更を扱っているか
必要に応じて反復し、モデル、プロンプト、知識、パラメータの版と、再評価を起動する変更を定めます。
確認：実行設定、反復結果、版差異、再検収規則。
- 人の判断と異議申立て経路があるか
高リスクまたは主観品質の場面では業務評価者を指定し、利用者が訂正、異議申立て、人への引き継ぎを行えるようにします。
確認：評価者、採点説明、引継記録、フィードバック処理。
検収基準と混同しやすい概念
| 関連概念 | 検収基準との違い |
|---|---|
| 要件 | 必要な能力や制約を示します。検収基準は指定結果が要件を満たしたと判断する方法を示します。 |
| 検収計画 | 対象、担当、環境、時期、サンプル、手順、結論方法を組織します。基準は計画が判定に使う条件です。 |
| テストケース | 前提、入力、手順を具体化します。複数ケースが一つの基準を検証し、一つのケースが複数基準の証拠になる場合があります。 |
| 完成の定義（Definition of Done） | 通常はすべての増分に共通するチーム品質基準です。検収基準は特定機能、成果物、案件結果に固有です。 |
| 受入テスト | 検証を実行する活動です。検収基準はその結果を評価する判定根拠です。 |
| サービスレベル目標 | 継続運用中のサービス性能を示します。検収で引用できますが、一度のテストだけで長期性能は証明できません。 |
出典と適用範囲
本項目は、企業向けソフトウェア・AI案件で成果物を受け入れられるか判断する検収基準を説明します。契約、調達規程、業界規制、法的助言に代わるものではありません。基準数、しきい値、優先度、承認方法、例外処理は案件ごとに合意する必要があり、一つのユーザーストーリーの受入条件を案件全体の最終検収条件と同一視することはできません。