AI開発の終盤で最も揉めるのが「検収」である。納品物を受け取り、対価を支払うかどうかを判断するこの工程で、発注者は「思ったほど精度が出ていない」と感じ、開発会社は「仕様どおり完成している」と主張する。両者の言い分が噛み合わないのは、多くの場合「何をもって完成とするか」を発注前に決めていないからだ。

通常のシステム開発なら「機能が仕様どおり動くか」で検収できる。だがAIは確率的に出力するため、同じ入力でも結果が揺れ、100%正解にはならない。だからこそ「精度の合格ライン」を数値で合意していないと、検収は感覚論になり、最後は契約と感情の紛争になる。本記事では、AI開発の検収・受け入れ基準の決め方を、評価指標と評価データセットの観点から発注者向けに整理する。想定読者は、検収にサインする立場の経営者、情シス、調達・購買の担当者である。

結論：検収基準は「精度の合格ライン・評価指標・評価データ」を発注前に合意する

AI開発の検収で揉めないためには、納品後ではなく発注前（できれば見積・契約の段階）に、合格ラインを数値で文書化しておく必要がある。GXOが受け入れ基準の設計で確認するのも、技術構成より先に「何の指標で・どのデータで・どの水準なら合格か」である。

  • 合格ラインは「正解率◯%」のような単一の感覚値でなく、評価指標（精度・適合率・再現率など）を業務に合わせて選ぶ
  • 評価に使うデータセット（評価データ）を発注前に確定し、量・出所・正解ラベルの作り方まで合意する
  • 100%にはならない前提で「不合格時にどう扱うか」「合格後も劣化したらどうするか」を契約に書く
  • 検収は一発勝負でなく、合格判定の手順・期限・再判定の回数を事前に決める

この4点が空白のまま「完成したら払う」とだけ書くと、検収は「完成の定義」をめぐる紛争になりやすい。

なぜ「完成」で紛争が起きるのか

「動く」と「使える」が別物だから

デモやPoCの段階では「それらしく動く」ことに皆が満足する。だが本番の検収で問われるのは「業務で使える精度か」であり、これは別の話だ。連載第1回のPoCで終わる会社の共通点でも触れたとおり、検証段階の手応えと本番運用の合格条件を混同すると、検収で初めて落差に気づく。

「精度」という言葉が曖昧なまま発注されるから

発注者が「精度80%以上で」と口頭で伝えても、その80%が何を分母・分子に取った数字かは決まっていないことが多い。後述するように、同じ「80%」でも評価指標が違えば意味がまったく変わる。指標を決めずに数字だけ約束すると、納品時に「その計算方法では達成している」「いや別の計算なら達成していない」と平行線になる。

評価に使うデータが決まっていないから

精度は「どのデータで測るか」で大きく変わる。開発会社が学習・調整に使ったデータで測れば高く出やすく、本番に近い未知のデータで測れば下がりやすい。評価データセットを発注前に確定していないと、「都合のよいデータで測った精度」で合格を主張され、発注者は反証できない。

検収の手順と期限が決まっていないから

「いつまでに・誰が・どうやって合否を判定するか」が契約にないと、検収は宙に浮く。発注者の確認が遅れれば「みなし検収」で支払い義務だけ発生し、逆に開発会社が判定基準を示せなければ支払いが止まる。これは精度の問題以前の、手続きの設計不足である。

検収の遅延を防ぐには、誰が一次判定し、誰が最終承認するかという役割分担を発注前に決めておくことも有効だ。判定者が不在のまま納品日を迎えると、現場は「精度が物足りない」と感じつつも反論の根拠を示せず、開発会社は「期日どおり納めた」と主張して、合否の判断そのものが先送りになる。先送りは双方にとって損であり、検収期間と再判定の回数をあらかじめ区切っておくほど、議論は「合格か不合格か」ではなく「どの指標をどの水準まで詰めるか」という建設的なものに変わる。

評価指標を業務に合わせて選ぶ

AIの「精度」は一つではない。代表的な評価指標を正しく理解し、業務の性質に合わせて選ぶことが、合格ライン設定の出発点になる。

指標意味（分類タスクの場合）重視すべき業務の例
正解率（Accuracy）全判定のうち正しく判定できた割合正例と負例の数が偏っていない一般的な判定
適合率（Precision）AIが「該当」と判定したもののうち、本当に該当だった割合誤検知（空振り）のコストが高い業務。例：自動承認、自動送信
再現率（Recall）本当に該当するもののうち、AIが取りこぼさず拾えた割合見落としのコストが高い業務。例：不正・異常・リスクの検知
F値（F1スコア）適合率と再現率のバランスを一つにまとめた指標空振りも見落としもどちらも避けたい業務

ここで重要なのは「正解率が高い＝良い」とは限らない点だ。たとえば該当案件が全体の数%しかない異常検知では、すべてを「該当しない」と判定するだけで正解率は高く出る。しかしそれでは肝心の異常を一件も拾えていない。誤検知を嫌う業務なら適合率を、見落としを嫌う業務なら再現率を主指標に置くべきで、この選択を発注者と開発会社で合意することが、合格ライン設定の前提になる。

生成AIやRAGのように「正解／不正解」を単純に二分できないタスクでは、評価はさらに難しい。回答の事実正確性、出典の妥当性、業務ルールへの準拠、有害・不適切な出力の有無などを、人手のレビュー基準やサンプル評価で測ることになる。この場合も「誰が・どの観点で・何件を・どの基準で採点するか」を文書化しておかないと、検収は採点者の主観に左右される。

評価データセットを発注前に確定する

合格ラインと同じくらい重要なのが「どのデータで測るか」である。評価データセットの設計で、検収の信頼性が決まる。

  • 評価データは、学習・調整に使うデータとは分けて確保する（同じデータで測れば精度は実態より高く出る）
  • 本番で実際に入ってくるデータの分布に近づける（特殊な良いデータだけで測らない）
  • 正解ラベル（何が正解か）の付け方と、付ける担当を発注前に決める
  • 件数を決める。少なすぎると数字が偶然で上下し、合否が安定しない
  • 評価データは発注者側でも保持し、検収時に同じデータで再計算できる状態にする

「AI一式」のような曖昧な見積で発注すると、この評価データの準備工数が誰の負担かも不明確になりやすい。見積段階での切り分けについては見積書の「AI一式」が曖昧になる理由も参照してほしい。評価データの正解ラベル付けは発注者側の現場知識が要る作業であり、ここを「開発会社任せ」にすると、業務実態とずれた基準で合格判定されることになる。

受け入れ基準を契約と検収手順に落とす

評価指標と評価データが決まったら、それを契約上の合格条件と検収手順に落とす。AIは確率的に出力する以上「100%」を保証させる契約は現実的でないため、合格ラインの考え方そのものを契約類型と整合させる必要がある。請負と準委任のどちらで契約するか、成果を保証させようとして揉める論点は「成果」を保証させようとして揉める契約類型（請負と準委任）で扱っているが、検収基準はこの契約設計と一体で決めるべきだ。

検収を稟議に乗せ、社内で「なぜこの水準で合格と判断したか」を説明できる形に整理しておくことも欠かせない。投資の妥当性と合格基準をひも付けて承認まで通す進め方は、システム開発の稟議・ROI診断の観点が役立つ。合格ラインの根拠（業務上どの水準なら投資に見合うか）を稟議資料に書けて初めて、検収は「現場の感覚」から「会社の判断」になる。

合格ラインを下げすぎても上げすぎても、後で別の紛争を呼ぶ。低すぎる基準で形式的に合格させれば、本番で「使えない」という不満が運用フェーズに持ち越され、高すぎる基準は達成不能な約束として検収を膠着させる。だからこそ、業務目的と人の現状精度という二つの物差しで合格ラインを定め、その根拠を文書に残しておくことが、発注前準備の核心になる。

開発会社を選ぶ段階でも、受け入れ基準を一緒に設計できるかは見極めポイントになる。提案時点で評価指標・評価データ・合格ラインの考え方を提示できる会社かどうかを、開発会社選びの実務チェック特集の観点で確認しておきたい。「とりあえず作ってから精度を見ましょう」とだけ言う相手は、検収で揉めるリスクが高い。

発注前に確認すべきこと（チェックリスト）

検収・受け入れ基準で紛争を避けるために、発注前（見積・契約の段階）で次を確認しておく。

  • 合格を判定する主指標を決めたか（正解率・適合率・再現率・F値・人手評価など、業務に合うもの）
  • 主指標の合格ラインを数値で文書化したか（口頭の「高精度で」で済ませていないか）
  • 評価に使うデータセットを発注前に確定したか（出所・件数・正解ラベルの作り方）
  • 評価データを学習・調整用データと分けているか
  • 評価データの正解ラベルを誰が付けるか、その工数は見積に入っているか
  • 100%にならない前提で、不合格時の追加開発・再判定の扱いを契約に書いたか
  • 検収の手順・判定者・期限・再判定の回数を決めたか
  • みなし検収（一定期間で自動合格扱い）の条件を確認したか
  • 合格後に精度が劣化した場合の責任分界（運用フェーズ）を決めたか
  • 合格ラインの根拠を稟議で説明できる形に整理したか

GXOに相談する前に整理しておくとよい情報

受け入れ基準の設計を相談する際、次が手元にあると議論が早く具体的になる。

  • AIに任せたい業務と、その業務で「間違い」がどれだけ許容できるか（誤検知と見落とし、どちらがより困るか）
  • 現状その業務を人がどの程度の精度・速度でこなしているか（比較対象になる）
  • 評価に使えそうな過去データの有無と、その正解が分かる人が社内にいるか
  • 検収にサインする責任者と、判定に関わる現場担当者は誰か
  • いつまでに本番化したいか、検収の山場をどこに置くか

これらが曖昧なままだと、技術提案の前に基準設計で止まる。逆にここが整理できていれば、開発範囲と検収条件をセットで見積に落とせる。自社の業務がそもそもAI化・自動化に向くかを切り分けたい段階なら、AI導入可否アセスメントで実現性と合格ラインの当たりを付ける進め方もある。

補足：実務上の注意点

合格ラインは「高ければよい」ものではない。要求を上げるほど開発コストと期間は増え、ある水準を超えると費用対効果は急に悪くなる。人が今その業務でどの程度の精度なのかを基準に、「人より少し良ければ十分」なのか「人に匹敵する必要がある」のかを業務目的から逆算するのが現実的だ。

また、検収を一発合格／不合格の二択にすると硬直する。本番に近いデータで段階的に検証し、合格ラインに届かない場合は「どこまで改善するか・追加でいくらかかるか」を事前ルールに沿って協議できる形にしておくと、紛争ではなく交渉に収められる。AIの精度は本番データの変化で運用後に劣化しうるため、検収時点の合格はゴールではなく、運用フェーズの責任分界もあわせて決めておく必要がある。

自社のデータやプロセスが、そもそも明確な合格基準を設定できる成熟度にあるかを確認したい場合は、DX成熟度診断や、AI開発全体の進め方を整理するAI開発サービスの観点もあわせて検討するとよい。検収基準は、稟議・ROIと一体で設計してこそ意味を持つ。投資判断と合格ラインをひも付けるシステム開発の稟議・ROI診断、提案段階で受け入れ基準を一緒に描ける相手かを見る開発会社選びの実務チェック特集を、発注前の準備として活用してほしい。

関連記事

よくある質問

Q1. AI開発の検収では「精度何%」を合格ラインにすればよいか

一律の正解はない。まず、誤検知（空振り）と見落とし（取りこぼし）のどちらが業務上より困るかを決め、適合率・再現率・F値・正解率のうち主指標を選ぶ。そのうえで、現状その業務を人がこなしている精度を基準に「人より良ければ十分か、人に匹敵する必要があるか」を業務目的から逆算する。数字だけ先に決めるのではなく、指標の選択と評価データの確定とセットで合意することが重要である。

Q2. 「100%の精度を保証してほしい」と契約に書けるか

現実的ではない。AIは確率的に出力するため、同じ入力でも結果が揺れ、100%正解は技術的に保証できない。100%保証を求めると、応じられる開発会社はいないか、応じても達成不能な約束になり、結局検収で紛争になる。100%を求めるのではなく、業務に必要な合格ラインを定め、不合格時の改善手順と運用後の劣化対応まで契約に書く形が現実的である。

Q3. 評価に使うデータは誰が用意するのか

評価データの確保と正解ラベル付けには、その業務の実態を知る発注者側の知識が要る。出所・件数・正解の付け方は発注前に合意し、ラベル付けの担当と工数を見積に明記しておくべきだ。開発会社任せにすると、業務実態とずれたデータで合格判定され、本番で精度が出ないという結果を招きやすい。評価データは発注者側でも保持し、検収時に同じデータで再計算できる状態にしておくとよい。

Q4. 検収後に精度が下がったら誰の責任になるか

検収時点の合格は運用のゴールではない。本番データの内容や傾向が変わると精度は劣化しうるため、これは「開発の不具合」と「運用フェーズの保守」のどちらに属するかを事前に分けておく必要がある。発注前に、合格後の監視・再学習・チューニングを誰がどの費用範囲で担うかを契約に書いておけば、劣化時に責任の押し付け合いにならずに済む。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

AI開発の検収・受け入れ基準の設計や、合格ラインを稟議まで通す進め方に不安がある場合は、GXOの無料相談で発注前の整理から相談できる。