AI開発の受入テスト不合格時の是正期限ポリシー設計
AI開発の受入テストで不合格が出たときに、欠陥の重要度別の是正期限、再テストの範囲、期限超過時の措置を事前に決めておく是正ポリシーの作り方を解説します。

結論
受入テストで不合格項目が出ること自体は正常です。問題は、不合格が出た後の是正期限・再テスト範囲・期限を守れなかった場合の措置が決まっておらず、「修正します」「いつまでに?」の交渉が検収期限の圧力の下で行われることです。是正ポリシーは、欠陥をS/A/B/Cの4段階に分類し、段階ごとに是正期限と検収可否への影響を事前に定義した文書として、受入テスト開始前に(理想は契約時に)合意します。期限超過時の措置(検収延期、遅延損害、減額受入)まで書いて初めて機能します。
是正期限ポリシーとは
是正期限ポリシーとは、受入テストの不合格項目(欠陥)について、重要度分類の基準、重要度ごとの是正期限、再テストの方法、期限超過時の措置を定めた合意文書のことです。テスト計画書の一部として作る場合と、契約の検収条項の別紙にする場合があります。法的効力を持たせるなら契約別紙が確実です。
AI開発では、機能バグのほかに「精度が基準を下回る」「特定入力パターンで誤出力する」という統計的な不合格が発生します。この2種類は是正の性質が異なるため、ポリシーでも扱いを分けます。機能バグは修正で確実に直りますが、精度未達は再学習やデータ追加をしても目標に届く保証がないため、期限だけでなく「改善アプローチの合意」と「打ち切り条件」が必要です。
欠陥の重要度分類と是正期限の標準
| 重要度 | 定義 | 是正期限の目安 | 検収への影響 |
|---|---|---|---|
| S: 致命 | 業務停止、データ破損、セキュリティ欠陥、誤処理が金銭・個人情報に影響 | 5営業日以内 | 全件解消まで検収不可 |
| A: 重大 | 主要機能が代替手段なしで使えない、精度が合格基準を明確に下回る | 10営業日以内 | 全件解消まで検収不可 |
| B: 中程度 | 代替手段あり、限定的な入力パターンでの誤動作 | 20営業日以内 | 是正計画合意で条件付き検収可 |
| C: 軽微 | 表示崩れ、メッセージ不備、運用で回避可能 | 次回定期リリース | 残存リストで検収可 |
重要度の判定者を決めておくことが重要です。ベンダーが判定すると重要度が下がる方向に流れるため、判定は発注側テスト責任者が行い、異議がある場合の協議手順を添えます。判定基準の解釈例(このケースはA、このケースはB)を5件ほどポリシーに書いておくと、判定の揉め事が大きく減ります。
再テストの範囲を決めておく
是正後の再テストは「修正した項目だけ確認」では不十分です。修正が他の機能を壊すリグレッションと、AIモデルの再学習が既存の正答ケースを崩す劣化の両方を確認する必要があります。ポリシーには、S/A欠陥の是正後は影響範囲分析書の提出とリグレッションテストの実施、モデル再学習を伴う是正後は固定評価データセットでの全項目再評価、と書きます。
再テストの費用負担も明記してください。ベンダー起因の欠陥に対する再テストはベンダー負担が原則ですが、発注側のテスト環境・データ提供の工数は発注側に残るため、再テスト1回あたりの発注側工数も見込んでおきます。
期限超過時の措置
是正期限を書いても、超過時の措置がなければ督促の根拠にしかなりません。措置は段階的に定めます。第一段階は是正計画の再提出と週次進捗報告の義務化。第二段階は検収期限の延期に伴う遅延損害金(契約の遅延条項と接続)。第三段階は、S/A欠陥が長期化する場合の契約解除権と既払金の精算ルールです。
逆に、C欠陥の残存を理由に発注側が検収を引き延ばすことも紛争源になります。民法の契約不適合責任の枠組みでも、軽微な不適合と重大な不適合で買主が取れる手段は異なります。「Cランクのみ残存なら検収し、残存リストを保守フェーズの課題管理へ引き継ぐ」というルールは、ベンダー側にとっても合理的で合意しやすい条件です。
精度未達の特別ルール
精度が合格基準に届かない場合、是正期限内に「再学習で+3ポイント」を約束させることは技術的にできません。実務的な落とし所は、是正試行の回数上限(例: 2回)と1回ごとの改善レビューを決め、上限到達時の選択肢を「基準緩和+減額受入」「対象範囲縮小での受入」「契約解除と精算」の3つから事前合意しておくことです。経済産業省のAI契約ガイドラインが指摘するとおり、AIの性能は契約時に確約できない性質があるため、未達時の出口を最初から契約に組み込むことが発注側の防御になります。
実務チェックリスト
- 欠陥の重要度分類(S/A/B/C)と判定基準の解釈例を文書化したか
- 重要度別の是正期限と検収可否への影響を決めたか
- 重要度の判定者を発注側に置き、異議手続きを定めたか
- 是正後のリグレッションテストと再評価の範囲を決めたか
- 再テストの費用負担を明記したか
- 期限超過時の段階的措置(報告義務・遅延損害・解除)を契約と接続したか
- C欠陥残存時の条件付き検収ルールを決めたか
- 精度未達時の試行回数上限と出口の選択肢を合意したか
図解で確認するポイント
この記事の画像は、テスト結果が重要度別に分類され、それぞれ異なる経路で是正・再確認へ進む流れを文字なしで図解しています。すべての不合格を同じ扱いにせず、分類が処理経路を決める構造を示しています。
AllAI内での次の行動
受入テスト全体の計画は受入テスト計画ガイド、検収基準の作り方は検収基準テンプレートが前段になります。保守フェーズへの課題引き継ぎは保守契約ガイドを確認してください。これから発注する場合はAI発注診断で検収要件を整理し、AI開発パートナーで品質管理体制を比較できます。
FAQ
Q. 是正期限ポリシーはいつ合意すべきですか? A. 理想は契約時、遅くとも受入テスト計画の承認時です。不合格が出てから決めようとすると、検収期限とベンダーの請求タイミングの圧力で発注側が譲歩しやすくなります。
Q. ベンダーの標準の欠陥管理プロセスに合わせてよいですか? A. 分類基準や管理ツールはベンダー標準で構いませんが、是正期限、判定者、期限超過時の措置の3点は発注側の要求を反映させてください。ベンダー標準には超過時措置が入っていないことがほとんどです。
Q. 検収後に見つかった欠陥はどう扱いますか? A. 契約不適合責任(担保期間)の範囲です。受入テストの是正ポリシーとは別に、検収後の通知期間と対応義務を契約で確認してください。担保期間開始前の確認は保守契約開始前の欠陥担保確認として整理するのが安全です。
Q. 是正期限を長めに求められたら受けるべきですか? A. 期限の長さ自体より、その根拠(原因分析と作業見積)を提出させることが重要です。根拠つきの現実的な期限は受け、その代わり進捗報告の頻度と中間マイルストーンを設定してください。
出典と確認日
- IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.html (確認日: 2026-07-10)
- 法務省「民法(債権関係)改正」: https://www.moj.go.jp/MINJI/minji06_001070000.html (確認日: 2026-07-10)
- 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。