AI開発受入テスト不合格の是正期限ポリシー
受入テスト不合格時の再検証、是正期限、ペナルティ、再検収のルールを整理する。

結論
AI開発の受入テストで不合格が出た場合、再検証の期限、是正の責任、ペナルティ、再検収の条件を事前に定めておく必要がある。本記事では、是正期限ポリシーの設計と運用を解説する。特にAI開発では、再学習や追加データが必要なケースもあるため、通常のIT開発とは異なる対応が必要になる。
定義・判断すべきこと
受入テスト不合格の是正期限ポリシーとは、AI開発の成果物が契約やRFPで定めた受入基準を満たさなかった場合に、ベンダーが是正を行う期限、再検証の方法、費用負担、遅延時の対応を定めたルールである。判断すべきことは、不合格の種類と深刻度、是正因の所在、再検証の方法と期限、費用負担である。
比較表と確認観点
| 不合格の種類 | 是正期限の目安 | 再検証方法 | 費用負担 |
|---|---|---|---|
| 軽微なバグ | 1〜2週間 | 該当テストの再実行 | ベンダー負担 |
| 精度未達 | 2〜4週間 | 追加データ投入・モデル再学習・再評価 | 協議 |
| 性能未達 | 2〜4週間 | 負荷テスト・最適化の再実施 | 協議 |
| セキュリティ不備 | 1〜2週間 | 脆弱性診断・対策実施・再診断 | ベンダー負担 |
| 機能不足 | 協議 | 追加開発・仕様合意・再検収 | 発注者負担が多い |
| ドキュメント不備 | 1週間 | 文書の追加・修正・再レビュー | ベンダー負担 |
表を見る際のポイントは、各項目が「契約書やRFPにどう落とし込まれているか」である。数値だけではなく、責任の所在と証跡の形式を確認すると、後からのトラブルを減らせる。特にAI開発では、技術的な確認だけでなく、業務・運用・法務の観点も同じテーブルに載せることが重要である。
運用・契約・管理の進め方
受入テスト不合格が発生したら、まず不合格の内容を具体的に記録し、発注者とベンダーで原因を分類する。是正因ベンダー起因か発注者起因かを判断し、費用負担と期限を合意する。再検証は、当初のテストと同じ条件で行い、結果を文書化する。実務では、不合格の再発防止策も合意し、プロジェクトの品質管理に反映する。
データ・権限・ログの扱い
AI開発の受入テストでは、定量的な評価指標と、定性的な確認観点の両方を定める。精度、再現率、F値、応答時間、エラー率などに加えて、倫理的配慮、バイアス、説明可能性も確認する必要がある。推論ログや評価データの保存期間も定め、再検証時に参照できる状態にする。
コスト・測定・見直し
再検証の費用は、ベンダー起因の場合はベンダー負担が原則。発注者起因の場合は追加費用として発注者が負担する。期限遅延が発生した場合は、違約金の適用やプロジェクト全体のスケジュール調整が必要になる。精度未達で再学習が必要な場合、追加データ取得費や計算コストも考慮する。
よくある失敗パターン
よくある失敗は、受入基準が曖昧で「不合格」の定義が不明確なこと、再検証の期限を定めていないこと、是正因の責任分界が曖昧で費用トラブルになること、AI特有の再学習工数を見積もりに入れていないことである。
実務チェックリスト
- 受入基準を数値化し、RFPや契約に定めている
- 不合格時の是正期限を種別ごとに定めている
- 再検証のテスト条件を合意している
- 費用負担と遅延時の対応を契約に定めている
- セキュリティ・倫理・バイアスの確認項目を含めている
- 検収後のクレーム対応ルールを定めている
- 再検証結果を文書化している
図解で確認するポイント
この記事の画像は、AI開発受入テスト不合格の是正期限ポリシーを示している。図解では「受入テスト → 不合格判定 → 原因分類 → 是正計画 → 再検証 → 合格・再不合格」という流れを描くとよい。
AllAI内での次の行動
AllAIでは、AI開発知財契約、AI教材販売比較、生成AI講座選びへ進める。
FAQ
Q. 再検証の期限は何回延長できますか? A. 契約で定める。原則として2回までとし、それ以上は追加契約や仕様変更扱いとするケースが多い。
Q. 再検証でも不合格の場合はどうなりますか? A. 契約解除、違約金、代替策の協議などを定めておく。AI開発では再学習が必要な場合もある。
Q. 発注者側のデータ不足が原因の場合は? A. 発注者起因と判断し、追加データ提供と期限の見直しを合意する。
出典と確認日
- ISO/IEC 42001 AI management system explained: https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html (確認日: 2026-07-10)
- デジタル庁 政府情報システムのためのセキュリティ評価制度(ISMAP): https://www.digital.go.jp/policies/isms/ (確認日: 2026-07-10)
- 日本弁護士連合会 契約書作成のポイント: https://www.nichibenren.gr.jp/ (確認日: 2026-07-10)
- 経済産業省 下請法ガイドライン: https://www.meti.go.jp/policy/commerce/shitauke/ (確認日: 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受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。