AI開発 受入不合格の是正期限ポリシー
AI受託開発の受入テストで不合格が出たとき、PM・品質保証・法務が使う是正期限の決め方、不合格区分、証跡、費用の見方を整理します。

結論
AI受託開発の受入テストで不合格が出たときは、その場の交渉で対応期限を決めるのではなく、不合格の区分ごとに是正期限を定めたポリシーに沿って進めることが重要です。開発PM、品質保証、法務が、受入テスト結果、是正計画書、再検査記録を証跡として残すと、検収の遅延と責任の曖昧さを防げます。
この記事は、不合格が出ても「いつまでに直すか」が決まらず検収が長引く発注者向けに、是正期限のルールと記録の残し方をまとめます。ポリシーがないと、軽微な指摘も重大な欠陥も同じ扱いになり、優先順位が付きません。
是正期限ポリシーとは何を決める取り決めか
是正期限ポリシーとは、受入で見つかった不合格を重大度で区分し、それぞれの是正期限、再検査の方法、期限超過時の措置を事前に定めた取り決めです。ベンダーを追い込むためではなく、検収の完了時期を見通し、業務開始を計画するための取り決めです。
ポリシーを作る前に、受入基準、テスト項目、合否の判定者を確定しておきます。受入基準が曖昧だと、そもそも合否が判定できず、是正期限も設定できません。受入テストの計画は契約段階で合意しておきます。
不合格区分と是正期限の対応表
不合格は重大度で区分し、期限と措置を変えます。表は業務リスクに合わせて調整します。
| 不合格区分 | 例 | 是正期限の目安 | 期限超過時 |
|---|---|---|---|
| 重大(業務停止級) | 主要機能が動作しない、重大な誤り | 短期・優先対応 | 検収保留、遅延責任の協議 |
| 中程度 | 一部機能の不具合、精度不足 | 合意した期間内 | 再検査、影響評価 |
| 軽微 | 表示崩れ、軽微な使い勝手 | まとめて対応可 | 次回リリースへ繰り越し可 |
| 保留・要協議 | 前提変更に起因する事象 | 原因確認後に判断 | 変更管理へ移送 |
表で区分するだけでなく、区分の判定基準(業務への影響度)を文章で明記します。重大と軽微を同じ期限で扱うと、優先対応が遅れます。前提変更に起因する事象は、不合格ではなく変更管理として扱うことも記録します。
是正と再検査の進め方
不合格は、指摘票に記録し、区分判定→是正計画の合意→是正実施→再検査の順で進めます。是正計画には、原因、対応内容、期限、担当を含めます。再検査では、同じテスト項目で合否を判定し、結果を記録します。是正が繰り返し不合格になる場合は、期限超過時の措置(検収保留、遅延責任、契約上の対応)を発動します。
データ・記録・ログの扱い
受入テストの結果、指摘票、是正計画、再検査記録は、版管理して集約します。誰がいつ合否を判定し、いつ是正が完了したかを追える状態にします。AI特有の指摘(精度不足、誤分類、例外処理)は、テストに使ったデータと条件も記録し、再検査で同条件を再現できるようにします。
費用と検収時期の見方
是正の費用は、原因が実装の欠陥なら通常はベンダー負担、前提変更なら変更管理として扱います。是正が長引くと検収と支払いが遅れ、業務開始も遅れます。検収の一部完了(部分検収)を認めるか、全体検収まで待つかを契約で決めておくと、遅延の影響を抑えられます。遅延の責任と費用負担も契約で確認します。
実務チェックリスト
- 受入基準・テスト項目・合否判定者を確定したか
- 不合格の重大度区分と判定基準を決めたか
- 区分ごとの是正期限を設定したか
- 期限超過時の措置を事前に定めたか
- 指摘票・是正計画・再検査記録を版管理しているか
- 前提変更起因の事象を変更管理へ移送する運用にしたか
- 部分検収の可否を契約で決めたか
- 是正費用の負担と遅延責任を契約で確認したか
チェックリストは、受入計画時、不合格発生時、再検査前に確認します。指摘票と是正記録を台帳化すると、検収の進捗を可視化できます。
図解で確認するポイント
この記事の画像は、受入不合格から区分判定、是正期限の設定、再検査までの流れを、複数のカードと接続線で表しています。文字や宣伝を入れず、どの段階でどの記録を残すかを視覚的に確認できるようにしています。
AllAI内での次の行動
まず AI発注診断 で受入基準と対象業務を整理してください。関連する実務は AI開発 PoCから本番移行ゲートの合格基準 と AI開発 セキュリティ指摘の是正完了証明 で確認できます。開発会社の比較は AI開発の発注支援、既製サービスの選択肢は AI/SaaS比較 も合わせて確認します。
FAQ
Q. 是正期限は不合格が出てから決めればよいですか? A. 事前にポリシーとして区分ごとの期限を決めておく方が確実です。発生後に交渉すると、優先順位が付かず検収が長引きます。
Q. 軽微な不合格でも検収を止めるべきですか? A. 業務への影響が小さい場合は、次回リリースへ繰り越すなど柔軟に扱えます。重大度で対応を分けるのがポリシーの目的です。
Q. 是正費用は誰が負担しますか? A. 実装の欠陥ならベンダー負担が基本です。前提変更に起因する場合は変更管理として扱い、費用を協議します。
Q. 是正が期限内に終わらない場合はどうしますか? A. 事前に定めた措置(検収保留、遅延責任の協議など)を発動します。曖昧なまま延長を繰り返さないようにします。
出典と確認日
- 独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- 経済産業省・総務省「AI事業者ガイドライン」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
- 公正取引委員会・中小企業庁「下請取引適正化」: https://www.jftc.go.jp/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受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。