AIの精度評価は誰がやるか。ベンダー・自社・第三者の3つの型を費用と独立性で比較

AI 開発の見積書を見ていると、「テスト」という行はあっても「精度評価」という行がないことが多い。あっても一式でいくら、としか書かれていない。

だが AI 案件の合否は、ほぼここで決まる。誰が、どのデータで、どの基準で測ったかによって、同じシステムでも出てくる精度の数字は変わる。そして誰がやるかによって、費用の出どころも変わる。

評価の担い手には、実務上 3 つの型しかない。開発したベンダーが測る「ベンダー評価」、発注者が自分で測る「自社評価」、どちらでもない相手が測る「第三者評価」である。3 つを費用・信頼性・現実性で並べて、案件ごとにどれを選ぶかを整理する。

まず、評価で何を測っているのか

型の比較に入る前に、何を測る作業なのかを揃えておく。AI の精度評価は、次の 3 つを用意して初めて成立する。

要素	中身	用意するのが難しい理由
評価データ	入力と、その正解の組。数百〜数千件	正解を人手で付ける必要がある。業務を知らないと付けられない
指標	正解率・適合率・再現率など、何をもって当たりとするか	用途によって見るべき指標が変わる
判定基準	何%を超えたら合格とするか	業務上の許容ラインから逆算する必要がある

3 つのうち、評価データと判定基準は業務側にしか決められない。指標の選び方は技術側の知識が要る。この分担が、そのまま 3 つの型の差になる。指標そのものの選び方は AIの精度をどう評価するか に分けて書いている。

型1. ベンダー評価 — 開発会社が測る

最も多い形である。開発会社が評価データを用意し、指標を決め、測定して結果を報告する。

費用

見積書に独立行がなければ、実質的に開発費に含まれている。独立行にさせると、評価データ作成の人手がそのまま金額になる。件数 × 単価で、数十万円から百万円台になることが多い。

強み

• 技術的な測定は確実にできる。指標の選定も適切なことが多い
• 開発中に何度でも測れる。改善のたびに数字が出るので、進捗が見える
• 発注者側の負担がほぼない

弱み

• 評価データを作った人と、システムを作った人が同じになる。 悪意の有無とは関係なく、作り手が想定した使い方に寄った試験になる
• 現場に実際に来る入力のうち、作り手が想像しなかったものが試験に入らない
• 数字が出てきても、発注者側でその妥当性を確かめる手立てがない

見分け方

ベンダー評価でも、次の 2 点が満たされていれば実用に足りる。

1. 評価データの中身を発注者が確認できること（件数だけでなく、実際のサンプルを見せてもらう）
2. 評価データの一部を発注者が提供していること

逆に「精度 95% でした」という結果だけが出てきて、何件のどんなデータで測ったか示されない場合は、数字として扱わないほうがよい。

型2. 自社評価 — 発注者が測る

発注者が評価用のデータを自分で用意し、納品されたシステムに投入して結果を見る型である。

費用

外部への支払いは発生しないが、社内工数がかかる。数百件の正解付けで、担当者 1 人あたり数日から 2 週間程度を見る。業務の合間に進めると 1 か月以上かかることもある。

強み

• ベンダーに渡していないデータで測れる。 これが最大の利点になる。作り手が想定していない入力が自然に混ざる
• 判定基準を業務の実態から決められる。「この誤りは許せるが、この誤りは許せない」という区別は業務側にしかできない
• 運用開始後もそのまま継続できる。実際の入力からサンプルを抜いて定期的に測る仕組みに発展させやすい

弱み

• 指標の選び方を誤りやすい。正解率だけを見て、見落としの多さに気づかない、といったことが起きる
• 測定の実行に技術的な手間がかかる。数百件をまとめて投入する仕組みが要る
• 社内工数が読みにくく、他業務に押されて後回しになりやすい

現実的な形

多くの案件で現実解になるのは、評価データを発注者が作り、測定の実行はベンダーが行うという折衷である。データの中身を知っているのは発注者だけ、測定を回す手段を持っているのはベンダーだけ、という分担に素直に従う形になる。契約上は「発注者が提供した未公開データによる最終測定」を検収条件に書く。手順は AI開発の検収 に詳しい。

型3. 第三者評価 — 開発にも発注にも関わらない相手が測る

独立した事業者に評価を依頼する型である。モデル開発の世界では、2026年9月18日に Anthropic が Accenture と評価者を社内に常駐させる提携を結び、両社が 5 年間でそれぞれ 10 億ドル以上を投じると発表した。背景は 第三者評価の動き で整理している。

費用

受託開発の AI システムを独立に評価する事業者は、国内ではまだ層が薄い。相場として示せる公開価格帯はほぼない。監査法人やコンサルティング会社の品質検証サービスとして見積もりを取る形になり、開発費とは別枠の費用になる。

強み

• 作り手にも発注部門にも利害がない立場で数字が出る
• 社内の承認資料として通しやすい。数字の出どころを説明できる
• 評価設計そのものの妥当性を含めて見てもらえる

弱み

• 頼める先を探すところから始まる。 今すぐ手配できる案件は限られる
• 業務の文脈を外部が理解するまでに時間がかかる。結局、評価データは発注者が作ることになる
• 費用対効果が合う案件が限られる

3 つの型の比較

観点	ベンダー評価	自社評価	第三者評価
外部への支払い	開発費に含む／独立行で数十万〜百万円台	なし	別枠。案件ごとの個別見積もり
社内工数	ほぼなし	大きい（正解付けで数日〜2週間）	中程度（文脈の説明と正解付け）
作り手からの独立性	低い	高い	高い
業務文脈の反映	低い〜中	高い	中
技術的な確かさ	高い	低い〜中	高い
開発中の反復	できる	しにくい	しにくい
手配のしやすさ	すぐできる	すぐできる	難しい

3 つのうちどれか 1 つを選ぶ、という設問にはならない。開発中はベンダー評価で回し、最終判定は自社評価で行うが基本形になる。第三者評価は、それでも足りない案件にだけ足す。

案件ごとの選び方

判断の分かれ目は、誤ったときに誰がどれだけ損をするかである。

案件の性質	推奨する組み合わせ	理由
社内文書検索、下書き生成、要約	ベンダー評価＋自社評価	人が最終確認する前提。誤りが直接損害にならない
顧客への自動応答、社外に出る文章	ベンダー評価＋自社評価（件数を増やす）	誤りが社外に出る。件数を厚くして分布を見る
帳票の自動読み取り、在庫・発注の自動化	ベンダー評価＋自社評価＋運用後の定期測定	誤りが数字として累積する。運用後の監視が要る
与信、品質保証、契約・医療・法務に関わる判定	上記＋第三者評価	誤判定の損害が大きく、説明責任が問われる

人が最終確認する用途なら、第三者評価まで入れる必要はない。 費用をかける先を間違えると、評価に使った予算の分だけ開発の中身が薄くなる。どこを削ってよく、どこを削ってはいけないかの考え方は AI運用費を下げる10の方法 と同じ筋で判断できる。

見積書で確認する 5 点

相見積もりを取っている段階で、各社に同じことを聞く。

1. 精度評価は見積書のどの行に含まれているか。独立行がなければ、内訳の件数と工数を出させる
2. 評価データは何件で、誰が用意するか。ベンダー側が用意する場合、中身を事前に見せてもらえるか
3. どの指標で判定するか。正解率だけか、見落としと誤検出を分けて出すか
4. 発注者が別に用意したデータでの測定に応じるか。応じる場合、その工数は見積もりに入っているか
5. 運用開始後の定期測定は契約に含まれるか。含まれないなら月額いくらか

4 番目で渋る会社は避けたほうがよい。技術的に難しい要求ではないからだ。この種の兆候は 避けたほうがよいAI開発会社の12の兆候 にまとめている。

複数社の見積書を同じ土俵に乗せる手順は AI開発の相見積もりを比較する方法、手元の見積書を相場と突き合わせたい場合は 見積書チェック を使ってほしい。まだ予算感を掴む段階であれば 費用診断 から始めるとよい。