結論から書きます。 AI の機能を開発会社に発注するとき、「どのくらい間違えてよいか」は発注側が決めるべき項目です。開発会社は業務の損失額も、間違えたときに誰が謝りに行くかも知りません。ここを空欄のまま発注すると、納品後に「思ったより当たらない」と揉めるか、逆に不要なほど高精度を追って費用と期間が膨らみます。この記事では、許容できる誤りの決め方と、仕様書への書き方を手順にして示します。
なぜ「許容する誤り」を発注側が決めるのか
従来のシステム開発であれば、仕様どおり動くか動かないかで検収ができました。消費税の計算は合っているか間違っているか、どちらかです。ところが AI を使った機能は、同じ入力に対しても確率的に答えを返します。「100%正しく動く」という前提が最初から成り立ちません。
そのため、AI 機能の検収では「どこまでなら正しく動いたとみなすか」という線が必要になります。この線は技術の問題ではなく、業務の問題です。たとえば請求書の金額読み取りを AI に任せる場合、1件の読み間違いが引き起こす損失は、業種によっても社内の確認体制によっても変わります。開発会社にはその損失が見えません。
経済産業省が公表している「AI・データの利用に関する契約ガイドライン」でも、AI 開発では成果物の性能を事前に保証することが難しい点が整理され、探索的に段階を踏む進め方が示されています。性能保証が難しいからこそ、「どの水準なら業務で使えるか」を発注側が言語化しておくことが、トラブル回避の前提になります。
そもそも「精度」とは何を指す？
打ち合わせで「精度95%を目指します」と言われたとき、その95%が何を数えた割合なのかを確認してください。AI の性能を語るとき、現場で意味が食い違いやすい用語が3つあります。
| 用語 | かみ砕いた意味 | 現場での言い換え |
|---|---|---|
| 正解率 | 全体のうち、正しく判定できた割合 | 「ざっくり何割当たるか」 |
| 適合率 | AI が「該当する」と答えたもののうち、本当に該当した割合 | 「騒がせすぎていないか」 |
| 再現率 | 本当に該当するもののうち、AI が拾えた割合 | 「見逃していないか」 |
この3つは同時には上げられません。拾う網を広げれば見逃しは減りますが、関係ないものまで引っかかります。網を絞れば誤検出は減りますが、見逃しが増えます。どちらの間違いが自社にとって痛いのかを決めるのが、発注側の仕事です。
たとえば次のような場面です。問い合わせメールから「クレームの可能性があるもの」を AI に拾わせるとします。見逃せば対応が遅れて大きな苦情になる一方、関係ないメールを拾いすぎても、担当者が確認するだけで済みます。この場合は見逃しを減らす側、つまり再現率を優先する設計になります。逆に、AI が自動で返信を送ってしまう仕組みなら、誤検出の方が危険です。
許容ラインはどう決める？ 損失から逆算する4ステップ
数字を先に決めようとすると、根拠のない「95%」が出てきます。業務の側から逆算してください。
- 誤りの型を2つに分ける。 その機能で起こりうる間違いを「見逃し」と「誤検出」に分け、それぞれ何が起きるかを1行で書きます。
- それぞれの後始末を書く。 誰が気づき、誰が直し、何分かかり、社外に影響が出るか。ここで「謝罪が必要かどうか」が分かれ目になります。
- 今の人手の水準を測る。 現在その作業を人がやって、どのくらい間違えているか。ここを測らずに AI だけ高い基準を課すと、永久に合格しません。
- 月あたりの件数を掛ける。 月500件の処理で誤りが2%なら月10件です。その10件を現場が吸収できるかを、現場の担当者に聞いて決めます。
この4ステップを踏むと、「95%」ではなく「見逃しは月3件まで、誤検出は月30件まで許容する」という、検収可能な形になります。割合ではなく件数で持つと、現場が判断できます。
仕様書と契約書に、何をどう書く？
決めた内容は、口頭ではなく文書に落とします。最低限、次の5項目を書いておくと検収で揉めにくくなります。
- 評価に使うデータ——自社の実データを何件、どの期間から取るか。開発会社が用意したサンプルではなく、自社データで測ることが重要です。この考え方はAIの検収は自社データ100件で足りるでも触れています。
- 評価の指標——正解率なのか、見逃し件数なのか。上の表のどれを使うかを明記します。
- 合格ライン——「誤検出は月30件以内」のように、件数または割合と母数をセットで書きます。
- 正解の定義——誰が「これは正解」と判断するか。判断が割れた場合の決め方も含めます。ここが曖昧だと、同じ結果を見て両者が別の解釈をします。
- 合格しなかったときの扱い——追加の改善を何回まで行うか、費用はどちらが持つか、それでも届かない場合にどうするか。
特に4つ目の「正解の定義」は抜けやすい項目です。文章の要約や分類のように、人によって答えが変わる作業では、まず社内で正解データを作る作業が必要になります。この作業は発注側しかできません。
なお、合格ラインを決めたあとも、進行中に前提がずれることはあります。打ち合わせごとの確認項目はAI開発で揉めないための毎回の打ち合わせ確認4点にまとめています。
納品後も同じ精度が続くとは限らない
検収時に合格しても、半年後に同じ水準とは限りません。AI の性能は、入力データの傾向が変わると落ちます。制度改正で書式が変わった、取引先が増えて文面の型が増えた、季節で問い合わせ内容が変わった——こうした変化で、作ったときの前提からずれていきます。
外部の AI モデルを使っている場合は、提供元の仕様変更やモデルの提供終了も影響します。契約の段階で、次の3つを決めておいてください。
| 決めること | 具体例 |
|---|---|
| いつ測り直すか | 四半期ごと、または処理件数が一定を超えたとき |
| 誰が測るか | 自社で測るのか、保守契約に含めるのか |
| 下回ったらどうするか | 調整の依頼先、費用の負担、人手に戻す判断基準 |
保守の範囲に精度の再測定が含まれているかどうかは、月額費用の内訳を見るときの確認点でもあります。費用側の確認項目はAI開発の月額費用、契約前に聞く8項目にまとめました。
明日からできること
大がかりな準備は要りません。発注を検討している機能について、A4用紙1枚に次を書いてみてください。
- この機能が間違える場面を3つ、具体的に書く
- その3つを「見逃し」と「誤検出」に分ける
- それぞれ、誰が気づいて誰が直すかを書く
- 月に何件までなら現場が吸収できるかを、実際にその作業をする人に聞く
- 今、人がやっていて何件くらい間違えているかを調べる（分からなければ「未測定」と書く）
この1枚を持って打ち合わせに行くと、会話の質が変わります。「精度はどのくらい出ますか」ではなく、「見逃しを月3件以内に抑えたい。この条件で実現可能か、必要なデータは何か」という聞き方ができるようになります。
まとめ
AI 機能の発注でもっとも揉めやすいのは、性能の基準を決めずに進めることです。開発会社は技術の実現方法を知っていますが、間違えたときの損失と、それを誰が引き受けるかは発注側にしか分かりません。
- AI は確率で答えるため、「100%正しい」を前提にできない
- 「精度」は正解率・適合率・再現率で意味が違う。どれを見るかを先に決める
- 許容ラインは割合ではなく、月あたりの件数に換算すると現場が判断できる
- 仕様書には、評価データ・指標・合格ライン・正解の定義・不合格時の扱いを書く
- 納品後も入力の傾向は変わる。測り直す時期と担当を契約時に決めておく
「どのくらい間違えてよいか」を決める作業は、AI の話をしているようでいて、実は自社の業務を点検する作業です。発注の前に手を動かしておくと、AI を入れるかどうかにかかわらず、現場の確認体制が1段強くなります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
