AIシステムの発注を検討しているとき、開発会社からこう言われたことはないでしょうか。「AIの精度は学習データやシステム環境に依存するため、数値での保証はできません」。この言葉に困惑し、「それでは検収の基準を何にすればいいのか」と悩む担当者は少なくありません。
AIは一般的なソフトウェアと異なり、確率的に動作します。「ボタンを押したら必ず動く」という保証の仕方ができない以上、開発会社が「精度100%は保証できない」と言うこと自体は正しいのです。しかし、それで思考を止めてしまうと、後々大きなトラブルの種になります。
精度が期待外れだった場合に「なぜ責任の所在が曖昧になるのか」「契約前に何を明確にしておけばよかったか」——このような後悔を防ぐための枠組みは確かに存在します。
本記事では、AI機能を含むシステムを発注する担当者に向けて、「業務目標からAI精度基準を設定し、契約書に落とし込む実務フレームワーク」を解説します。技術的な知識がなくても、開発会社と対等に議論できるようになることを目指しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AIの精度保証が難しい3つの理由
AIシステムの精度保証が難しいとされる背景を理解することが、問題解決の出発点です。
一般ソフトウェアとAIの根本的な違い
従来のソフトウェアは「もし〇〇なら××をする」という明確なルールで動作します。テストで「このインプットに対してこのアウトプットが返ってくるか」を確認すれば、品質を客観的に担保できます。
AIはまったく異なる仕組みで動きます。大量のデータから「パターン」を学習し、そのパターンに基づいて予測や分類を行います。同じインプットでも、学習データが変われば出力が変わりますし、「正解」に近い出力を確率的に選ぶため、100%の精度を保証することは原理的に不可能です。
確率的出力・データ依存性・環境変化の3つの壁
AI精度保証を難しくする要因は主に3つあります。
1. 確率的出力：AIは「最も可能性が高い答え」を出力しますが、それが常に正解とは限りません。精度95%のモデルは、100件中5件は誤った出力をするということです。
2. データ依存性：AIの精度はトレーニングデータの質と量に直結します。「類似データが少ない」「ラベル付けにミスがある」などの場合、どれだけ優秀な開発チームが作っても精度に限界が生じます。経済産業省の「AIの利用・開発に関する契約チェックリスト（2025年2月）」（経産省公式）でも、「AIモデルは学習データに基づく帰納的な手法で開発されるため、学習データそのものに精度の限界が内包されてしまっている可能性がある」と明記されています。
3. 環境変化（コンセプトドリフト）：本番環境で扱うデータが、学習時のデータの分布とずれていく現象が起こります。たとえば「季節や市場環境の変化で購買パターンが変わる」ような場合、定期的な再学習を行わないと精度が時間とともに劣化します。
それでも合意できる枠組みがある
この3つの特性を理解した上で重要なのは、「だから精度保証はできない」で終わりにするのではなく、「何を、どのデータで、どの指標で測定するか」を事前に合意することです。この枠組みさえ決まれば、検収基準を定量的に設けることは十分に可能です。
発注者が理解すべき3つの精度指標
「精度」という言葉は日常会話では「正確さ」の意味で使われますが、AI開発では複数の異なる評価指標が存在します。発注者が知っておくべき指標は3つです。
再現率（Recall）= 見逃しコストの指標
再現率とは「本来ポジティブなものをどれだけ正しく検出できたか」を示す割合です。
業務の言葉に置き換えると：見逃した場合のコストが高い業務では再現率が重要となります。
- 医療の診断補助AIで病変を見逃す → 治療機会の損失
- 製品の不良品検査AIで不良品を見逃す → クレームや製品回収
- セキュリティ監視AIで不正アクセスを見逃す → 情報漏洩
このような業務では、再現率を高い水準（例: 97%以上）で設定することが優先されます。
適合率（Precision）= 誤検知コストの指標
適合率とは「ポジティブと判定したもののうち、本当にポジティブなものの割合」です。
業務の言葉では：誤検知した場合のコストが高い業務では適合率が重要となります。
- スパムフィルターが重要なメールも誤ってスパム判定する → 業務への支障
- レコメンドAIが無関係な商品を頻繁に勧める → ユーザー体験の低下
- 書類審査AIが通過すべき申請を誤って却下する → 再審査の工数増加
誤検知が多すぎると、AIが出した「要確認」を人間が追うコストが膨らみます。
F1スコア = バランスの指標
F1スコアは再現率と適合率の調和平均です。どちらか一方が極端に低いとF1スコアも低くなります。
- 不正検知AI（見逃しも誤検知も許容できない）
- 書類仕分けAI（どちらのコストも無視できない）
このような業務ではF1スコアを主要指標として設定するのが適切です。
ポイント：どの指標を重視するかは「どちらのミスのコストが大きいか」をビジネス側が判断する事項です。技術者任せにせず、発注者が業務の性質から判断して開発会社に伝えることが重要です。
業務目標から精度基準を設定する方法
「精度90%以上で」と書いても、何の指標で90%なのか、何のデータで測るのかが不明では検収基準になりません。正しいアプローチは「業務目標から逆算する」です。
ステップ1 業務目標を数値化する（「何件のエラーが許容できるか」）
まず業務の観点から「どこまでの誤りが許容できるか」を数値で定義します。
例1：受発注書類のAI仕分けシステム
- 月間処理件数: 1,000件
- 現在の人手での誤仕分け率: 2%（= 月20件）
- AIに求める誤仕分け許容数: 月5件以下
この業務条件が決まれば、「1,000件のテストデータで5件以下の誤分類」という検収基準が設定できます。これはF1スコア換算で約0.99に相当します。
例2：製品外観検査AIカメラ
- 月間検査品数: 10,000個
- 許容できる不良品見逃し数: 月3個以下（安全規格上の要件）
- 誤検知（良品を不良品と判定）の許容: 月50個まで（廃棄コストとのバランス）
この場合、再現率と適合率の両方に要件があります。再現率は 99.97%以上（10,000件中3件以下の見逃し）、適合率は不良品と判定したもののうち本当の不良品が一定以上、という形で設定します。
ステップ2 業務目標から指標値に換算する
業務目標（「月何件のエラーまで許容か」）が決まったら、開発会社と一緒に対応する指標値を算出します。この換算作業は開発会社の支援を受けながら行うのが現実的です。
重要なのは「発注者が業務目標を明確に持っておくこと」であり、技術的な換算は協力して行えます。要件定義の全体像についてはAIプロジェクトの要件定義ガイド【発注者向け】も参考にしてください。
テストデータの準備は発注者の責任でもある
見落とされがちなのが「テストデータ」の問題です。
どれだけ精緻な精度要件を設定しても、評価に使うデータが実際の業務データとかけ離れていては意味がありません。たとえば「画像認識AIの精度検査を整った撮影環境で行ったが、本番環境では照明条件が悪くて精度が大幅に低下した」というケースは珍しくありません。
テストデータは「本番環境と同じ分布のデータ」を用意することが原則です。このデータ準備には発注者側の業務知識と現場データが不可欠であり、開発会社だけに任せることはできません。
契約書に盛り込むべき精度保証条項
業務目標から精度基準が決まったら、それを契約書に落とし込みます。
明記すべき4つの契約項目
1. 評価指標と目標値 「どの指標を、何%（または何件以下）で検収とするか」を具体的に記載します。
- 例: 「テストデータセット（別紙Aに定義）に対して、F1スコア0.92以上を達成した場合に検収完了とする」
2. テストデータの定義 誰が、どのようなデータを用意し、評価に使うかを明確にします。
- 「別紙Aのテストデータセット（甲が提供する実際の業務データ1,000件。構成比率および収集方法は別途合意する）を使用する」
3. 精度不達時の対応 目標値に達しなかった場合に、開発会社がどこまで対応する義務を負うかを定めます。
- 修正期間（例: 検収後30日以内に再提出）
- 再学習の費用負担（どちらが負担するか）
- 最終的に達成できなかった場合の違約・返金条件
4. 本番後のドリフト対応（保守契約） AIシステムは本番運用後も精度が変化します。この対応責任を保守契約で明確にします。
- 定期的な精度モニタリングの実施義務
- 精度が一定水準を下回った場合の再学習義務と費用負担
請負型と準委任型の使い分け
AI開発契約には大きく2つの方式があります（経産省の解説参照）。
請負型（完成義務あり） 精度基準が明確に定義でき、開発会社がその達成に自信を持てる場合に適します。目標精度に達しない場合は無報酬での修正義務が生じます。
準委任型（善管注意義務のみ） AIの精度が事前に保証しにくい場合（学習データが不十分、要件が不確定）に選ばれます。「最善の努力をするが結果は保証しない」形態です。
発注者にとっては請負型の方が安心ですが、「精度要件が技術的に達成可能であること」「テストデータが適切であること」が前提です。これらが曖昧な状態では、開発会社が請負を断るか、割増コストを設定することが一般的です。
精度が達成できなかった場合の費用負担と再学習義務
精度未達が判明した場合、その責任は一律に開発会社にあるわけではありません。原因によって対応が変わります。
精度未達の原因は3パターンある
パターンA：開発会社の技術力・実装の問題 モデルの設計ミス、アルゴリズム選択の誤り、バグなどが原因で目標精度に届かない場合です。これは開発会社の責任であり、無償修正が原則となります。
パターンB：本番データが学習データと大きく異なった 学習に使ったデータと実際の業務データの分布が乖離していた場合です。「提供されたサンプルデータが実際の業務を代表していなかった」というケースがこれに当たります。この場合、発注者側（データ提供側）にも一定の責任があるため、費用負担の協議が必要です。
パターンC：テストデータの準備が不十分だった 評価データが実際の業務環境を再現していなかった場合、「テスト環境では合格したが本番では機能しない」という状況が起こります。発注者側でのデータ準備プロセスが不十分だった場合の責任は発注者が負う形になります。
再学習費用の負担ルールを事前に決める
AIは「作って終わり」ではなく、本番環境の変化に合わせた追加学習（ファインチューニング）が定期的に必要です。この費用を誰が負担するかを契約時に決めておかないと、後々の交渉が難航します。
一般的なパターンとしては：
- 初期契約内の保証期間（例: 本番稼働後6か月）における性能維持は開発会社負担
- 保証期間後の再学習は別途費用として発注者負担
- ただし「データの質が大幅に変化した場合は協議」という条項を設ける
PoCで精度要件を確定させてから本開発に入る方法
精度の達成可能性に大きな不確実性がある場合は、PoC（概念実証）フェーズを設けることを検討してください。
PoCは小規模な試験的開発を準委任型で行い、「この業務データ・この要件でどの程度の精度が見込めるか」を事前に検証するフェーズです。PoCの結果を踏まえて本開発の精度要件と契約方式（請負 or 準委任）を確定させるアプローチは、発注者にとっても開発会社にとってもリスクの低い進め方です。
AI開発の進め方全体についてはAI受託開発とは？成功させるポイントや外注先の選び方などを紹介で詳しく解説しています。
まとめ：発注者が最初にやるべき5つのアクション
AIシステムの精度保証は複雑に見えますが、押さえるべきポイントは5つです。
-
AI固有の特性を理解する：確率的出力・データ依存性・環境変化の3つの理由から、100%保証は原理的に不可能です。それを踏まえた「合意の枠組み」を作ることが目標です。
-
業務のどちらのミスが痛いかを判断する：見逃しコストが大きければ再現率、誤検知コストが大きければ適合率、どちらも重要ならF1スコアを主要指標として選びます。
-
業務目標を数値で表す：「月何件のエラーまで許容か」という業務言語での数値を先に決め、指標値への換算は開発会社と一緒に行います。
-
4項目を契約書に明記する：評価指標と目標値、テストデータの定義、精度不達時の対応、本番後のドリフト対応（保守契約）を漏れなく定めます。
-
不確実性が高い場合はPoCから始める：精度の見通しが立ちにくい場合は、準委任型のPoCで検証してから本開発の請負契約に入るアプローチをとります。
これらを事前に整理しておくことで、「納品後に精度が不十分だったがどちらの責任か分からない」という状況を防ぐことができます。開発会社との打ち合わせの前に、まず自社の業務目標を数値化するところから始めてみてください。
参考資料
- 経済産業省「AIの利用・開発に関する契約チェックリスト」（2025年2月）: https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html
- 特許庁 IP BASE「AI開発を受託する際の契約方式の選び方」: https://ipbase.go.jp/learn/point/ai/page05.php
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
