業務システムにAI機能を組み込む案件で、開発そのものより揉めやすいのが検収（受け入れテスト）です。従来のシステムなら「この入力を入れたらこの値が返る」と書けば済みました。ところが生成AIや機械学習を使った機能は、同じ入力でも出力の表現が変わります。「期待通りでない気がする」という感覚と、「仕様は満たしている」という主張がぶつかり、検収が止まる。これは発注側の準備不足でも開発側の手抜きでもなく、検収条件の書き方そのものが従来型のままだから起きます。
この記事では、出力が固定値で比較できない機能について、どう合否を線引きし、どう契約書と仕様書に落とすかを整理します。
なぜ従来の検収条件が通用しないのか
原因は三つに分けられます。
- 出力が確率的である：大規模言語モデル（LLM、大量の文章を学習し次に来る語を確率的に選ぶモデル）は、同じ指示でも語順や言い回しが変わります。temperature（出力のばらつきを制御する設定値。0に近いほど安定する）を下げれば揺れは減りますが、ゼロにはなりません。
- 正解が一つでない：議事録要約や問い合わせ返信の下書きは、複数の「正しい答え」が存在します。
- 外部要因で変わる：クラウドのAIサービスはモデルが更新・廃止されます。検収時に通ったテストが、半年後に通らなくなることがあり得ます。
つまり「期待値と一致するか」ではなく、「許容できる範囲に収まっているか」を測る設計に切り替える必要があります。経済産業省・総務省の「AI事業者ガイドライン」（2024年公表）でも、AIの特性としてこうした不確実性を前提に、開発・利用の各段階で品質を検証する考え方が示されています。
検収条件を3層に分けて書く
すべてを人間の目視で判定しようとすると破綻します。判定方法が違うものを混ぜないことが出発点です。
| 層 | 対象の例 | 判定方法 | 合否の性格 |
|---|---|---|---|
| 第1層：決定論的条件 | 出力がJSON形式として壊れていない、必須項目が欠けない、禁止語を出さない、応答3秒以内、APIエラー率 | 自動テストで機械判定 | 100%必達 |
| 第2層：正解集合との照合 | 文書の分類、金額・日付・取引先名の抽出、該当/非該当の判定 | 正解付きテストデータとの一致率を集計 | しきい値で判定 |
| 第3層：人間による採点 | 要約、メール文面、説明文などの生成 | 評価観点ごとの採点表（ルーブリック）で複数人が採点 | 平均点と下限点で判定 |
発注側が書けずに詰まるのは第2層と第3層です。しかし実務上は、第1層をどこまで厳密に書けるかが揉めごとの大半を防ぎます。「請求書から金額を抽出する」機能なら、金額が合っているかは第2層ですが、「数値以外の文字列を返さない」「桁区切りを含めない」「抽出できなければ空ではなくnullを返す」は第1層で機械判定できます。
合否ラインの決め方 — 二段構えで書く
「正解率90%以上で合格」とだけ書くのは危険です。残り10%に何が含まれるかが定義されていないからです。実務では必達条件（1件でもあれば不合格）と目標条件（全体の比率で判定）を分けます。
たとえば、問い合わせメールを内容別に振り分ける機能を想定すると、次のような書き方になります（あくまで条件の書き方の例であり、水準は業務のリスクに応じて決めるものです）。
| 区分 | 条件の例 | 基準 |
|---|---|---|
| 必達 | 個人情報・社内限定情報を出力に含めない | 0件 |
| 必達 | クレーム系の問い合わせを「対応不要」に分類しない | 0件 |
| 必達 | 出力スキーマ違反・処理タイムアウト | 0件 |
| 目標 | 200件の評価データに対する分類の正解率 | 85%以上 |
| 目標 | 同一入力を3回実行したときの判定一致率 | 95%以上 |
| 目標 | 要約品質（5段階評価、3名の平均） | 平均3.5以上かつ1点が1件以下 |
ポイントは、業務上「起きてはいけない間違い」を必達側に隔離することです。分類を外すのは許せるが、重大クレームの見落としは許せない。この線引きは発注側にしか決められません。開発側が勝手に決めると、検収時に「そこが一番大事だったのに」となります。
もう一つ重要なのがサンプル数の扱いです。50件のテストで正解率88%だったとしても、母集団の真の正解率が88%である保証はありません。件数が少ないほど測定値の幅は大きくなります。目安として、重要な判定機能では100件以上、可能なら200〜300件の評価データを用意し、「この件数で測った値である」ことを検収書に明記しておくと、後日の水準議論が噛み合います。
評価データセットは発注側の資産として作る
正解付きのテストデータ（ゴールデンデータセットと呼ばれます）は、検収のためだけのものではありません。運用後にモデルを差し替えたり、プロンプト（AIへの指示文）を改善したりするたびに、同じ物差しで再測定するために使います。
- 実データから抽出する：想定で作った綺麗なデータでは、現場の崩れた入力を評価できません。
- 難易度を混ぜる：典型例だけでなく、判断に迷う境界事例、明らかな異常データを一定割合入れます。
- 正解は業務担当者が付ける：ここを開発側に丸投げすると、業務上の正解とずれます。
- 学習・調整用と評価用を分ける：プロンプト調整に使ったデータで評価すると、点数が実力より高く出ます。
- 個人情報の扱いに注意する：実データを開発環境に持ち出す場合、個人情報保護法（2022年4月全面施行の改正法）を踏まえ、匿名化の範囲や委託先での取扱いを契約で定めておく必要があります。
見積段階で「評価データ200件の作成に、業務担当者が何時間必要か」を工数として見込んでおくと、検収直前に慌てずに済みます。
実装・運用で詰まりやすい箇所
条件を決めても、次の点を契約・設計時に詰めていないと再び揉めます。
- モデル更新時の責任範囲：外部AIサービスのモデルが変更・提供終了になった場合、再チューニングは保守契約の範囲か別見積かを明記します。AIを含む開発の契約の考え方は、経済産業省「AI・データの利用に関する契約ガイドライン」（2018年公表、2019年改訂）が参考になります。
- AIによる自動採点の扱い：別のLLMに採点させる方法（LLM-as-a-judge）は効率的ですが、採点者側も揺れます。検収の最終判定に使うなら、人間採点との一致度を事前に確認したうえで使う、という手順を決めておきます。
- 人間が確認する前提の設計：精度100%を求めるより、AIの出力を人が確認・修正する画面を作り、修正率をKPIにする方が現実的な場面が多くあります。修正ログは次の改善材料にもなります。
- 検収後の計測を止めない：本番データは評価データと分布が違います。運用開始後も一定期間、サンプリングして精度を測る運用を設計に入れておきます。
- 再現性の確保：temperature、モデルのバージョン、プロンプトの版数を記録し、検収時と同じ条件を再現できるようにしておきます。これがないと「前は通ったはず」の水掛け論になります。
まとめ
AI機能の検収は、「出力が毎回変わるから判定できない」のではなく、判定できる形に条件を分解していないから揉めるのです。整理すると次の順序になります。
- 機械判定できる第1層（形式・制約・性能）を洗い出し、100%必達として書く
- 業務上「起きてはいけない間違い」を必達条件として列挙する
- 残りを正解率・一致率・採点平均などの目標値として、測定件数とセットで定める
- 評価データセットを業務担当者が作り、検収後も同じ物差しで測り続ける
- モデル更新時の責任範囲を契約に書いておく
数値の水準そのものに絶対的な正解はありません。重要なのは、発注側が「どこまでの間違いなら業務が回るか」を言語化することです。そこさえ決まれば、開発側はそれを測れる形に落とす作業に集中できます。検収条件の設計は、開発着手後ではなく、要件定義と同じタイミングで始めてください。