AI開発の検収条件はどう決める？「精度が高い」ではなくテストセットと閾値を固定

AI開発の検収条件を「精度が高いこと」とだけ書くと、発注側と開発側で合格の意味がずれる。デモが自然に見えても、苦手な入力、応答時間、費用、禁止出力を確認していなければ、本番で使えるとは判断できない。

契約前に固定するのは、テストセット、指標、閾値、重大失敗の許容回数、実行条件、結果ファイルである。数値は業務によって変わるため、この記事では万能な合格点を置かない。

検収条件を1枚に固定する

次の表を仕様書または契約の添付資料にする。空欄を「開発後に協議」とせず、遅くとも評価開始前に合意する。

評価軸	指標	証拠
品質	正答、根拠、再現率、業務担当者の判定など	全入力・出力・判定理由
応答時間	初回応答、完了時間、タイムアウト率	時刻付き実行ログ
費用	1件当たり、月間想定、再実行を含む費用	利用量と計算式
安全性	禁止出力、情報漏えい、権限外操作	失敗例と対処結果
運用	障害検知、復旧、モデル変更後の再評価	手順書と再試験結果

「重大失敗の許容」は平均点と分ける。100件中95件が合格でも、残り5件で個人情報を漏らすなら、平均95%を理由に受け入れられない。業務上、一度でも起きてはいけない失敗は0件と明記する。

デジタル庁の2026年版ガイドラインは政府向けの調達規範として、利用目的と機能に沿ったテストシナリオを作り、入出力、安定動作、期待品質、仕様書要件、不適切な生成や偏りを確認するよう求めている。多様な方法や独立したテストも例示する。

民間の案件でも、汎用ベンチマークだけでなく実際の業務入力を使う。問い合わせAIなら、短い質問だけでなく、曖昧な質問、情報不足、誤った前提、権限外の要求、回答してはいけない内容を含める。

テストセットには版を付ける。開発側が調整に使ったデータと、最終検収だけに使うデータも分ける。すべての検収データを見ながらプロンプトを直せば、そのデータへの適合は上がっても、新しい入力への強さは分からない。

NIST AI RMFは、目的に合う指標と方法を選び、再現可能なテスト・評価・検証を文書化する考え方を示す。指標が一つでは、異なる失敗を区別できない。

正しい回答でも30秒かかれば、電話対応の補助には使いにくい。高品質でも1件当たり費用が予算を超えれば、対象範囲を変える必要がある。安全性を高めるために回答拒否を増やしすぎると、必要な質問にも答えなくなる。

AWSの評価パイプライン例は、テストデータと評価指標を使う反復評価に加え、モデル出力、応答時間、費用を記録する。最終検収では、採用予定のモデル、設定、検索データ、実行環境を固定し、同じ条件で全指標を測る。

Microsoft Foundryの評価機能は、モデル、エージェント、データセット、会話や個別ターンなど、評価対象とデータ源を分けている。何を採点した点数なのかが違えば、同じ「4点」でも意味は変わる。

LLMを採点役に使う方法もあるが、採点モデルの好みや誤りが入る。Google Cloudは、モデルによる評価指標を人が評価したデータと比較する手順を示している。

検収で自動採点を使うなら、業務担当者が判定した一部データで一致度を確認し、ずれた例を残す。採点モデルの結果だけをもって、発注側の受入判断を置き換えない。

合格点だけでなく、再現に必要な条件を残す。

モデルや設定を変更した後に古い結果を流用しない。検収後の更新でも同じテストを再実行できる形にしておけば、納品時だけ良かった状態と、運用中の品質低下を区別できる。

業務上の閾値をまだ決められない場合、開発会社へ「高精度なAI」を一括発注しない。まず小さなテストセットを作り、現在の人の処理、許容できる誤り、応答時間、1件当たり費用を測る工程をPoCにする。

その結果から閾値を決め、本開発の検収表へ移す。デモの印象を契約条件にするのではなく、同じ入力を同じ条件で再実行し、合否と失敗理由を確認できることが受入の基準になる。