AI DECISION GUIDE契約・検収

AI開発の検収・受入基準

検索意図:AI開発を何で合格とするか、契約前に基準を決めたい

1行で回答

AI開発の検収は、固定した評価セットで正答・重大誤り・回答不能・引継ぎ・速度・権限を用途別に判定します。

対象:AI開発の受入テストと検収条件を決める担当者 最終更新:2026.08.18 根拠区分を各主張に表示
ライブラリ内を探す

DECISION CRITERIA

発注前に確認する3つの判断基準

「精度」の一語で済ませず、対象入力、期待結果、許容誤り、回答不能、人の修正、速度、権限、再試験を受入条件にする。

01再現性

同じ入力で再試験できるか

判断できる状態
発注側管理の評価セットと手順がある。
見送りのサイン
ベンダーが選んだ成功例だけで検収。
02影響

重大な誤りを分けたか

判断できる状態
用途別に許容・不許容を定義している。
見送りのサイン
全項目を平均精度だけで判定。
03救済

不合格時の扱いがあるか

判断できる状態
修正、再試験、費用、期限を合意済み。
見送りのサイン
納品後に基準を協議する。

DECISION FLOW

評価セットから不合格時の再試験までを契約前にそろえる

01COVER

評価セットを固定

検収では、発注側が確認した代表入力と期待結果を固定し、提案時とは別の評価セットを使う。

accept.dataset
02INSIGHT

重大誤りを分ける

正答率だけでなく、重大な誤り、回答不能、人への引継ぎ、根拠表示を用途別に判定する。

accept.failure
03FRAMEWORK

非機能も検収する

応答時間、同時利用、権限、ログ、障害時の動作など、業務継続に必要な非機能条件も受入対象にする。

accept.nonfunctional
04ACTION

再試験を決める

不合格時の修正範囲、再試験、追加費用、検収期限を契約前に合意し、評価後の解釈差を減らす。

accept.remedy

CLAIMS & EVIDENCE

判断の根拠と成立条件

外部統計のように見える根拠なしの数値は置かず、各判断がどの実務フレームに基づき、どの前提で成立するかを明示します。

01

発注側の評価セットを固定する

検収では、発注側が確認した代表入力と期待結果を固定し、提案時とは別の評価セットを使う。

根拠区分
BlueAI実務フレーム
更新日
2026-08-18

成立条件:業務担当者が評価セットをレビューできる。

02

誤りと回答不能を分けて判定する

正答率だけでなく、重大な誤り、回答不能、人への引継ぎ、根拠表示を用途別に判定する。

根拠区分
BlueAI実務フレーム
更新日
2026-08-18

成立条件:誤りの種類と業務影響を分類できる。

03

非機能条件も受け入れる

応答時間、同時利用、権限、ログ、障害時の動作など、業務継続に必要な非機能条件も受入対象にする。

根拠区分
BlueAI実務フレーム
更新日
2026-08-18

成立条件:想定利用人数とピーク条件が定まっている。

04

不合格時の再試験を合意する

不合格時の修正範囲、再試験、追加費用、検収期限を契約前に合意し、評価後の解釈差を減らす。

根拠区分
BlueAI実務フレーム
更新日
2026-08-18

成立条件:契約・見積・RFPで同じ受入基準を参照する。

RELATED CASES

判断条件を事例で確かめる

全ケースを見る →
モデルケースBlueAI試算

卸・商社 / 従業員80名想定

問い合わせメールの一次回答をAIが下書き

返信作成時間を1通15分から3分へ短縮できる規模感。

根拠と条件を見る →
モデルケースBlueAI試算

製造 / 従業員200名想定

社内規程・マニュアルを横断検索できるナレッジAI

一次回答の7〜8割を自動化できる規模感。

根拠と条件を見る →
モデルケースBlueAI試算

小売・EC / 年商3億円想定

ECの商品問い合わせ・レビュー返信をAI化

CS工数を半減できる規模感。

根拠と条件を見る →

DEFINE ACCEPTANCE

受入基準を、RFPへ入れる。

評価方法と不合格時の扱いを含むRFPドラフトを作成します。

RFPを作成する →