AI PoC Guide

PoCの評価項目をどう決めるか

評価設計と判定基準

PoCの評価項目は、PoC終了時に下す判断から逆算して決定します。 AIの精度は評価項目の一つにすぎず、精度だけでは次の段階に進むかどうかを判断できません。

本稿では、評価が判断につながらない典型的なパターンを確認したうえで、評価項目の5つの観点、実際に測定する項目の一覧、効果見積もりで生じやすい楽観的前提、KPIの3階層、評価データの要件、判定基準の順に述べます。

最終更新:2026年9月21日

01

Patterns

評価が判断につながらない3つのパターン

評価項目の決め方に入る前に、PoCの評価が機能しない典型的なパターンを整理します。いずれも評価の工数が不足しているのではなく、評価を設計する順序に原因があります。

パターン1:評価項目の事後決定

結果を確認してから評価項目を定めた場合、出た結果に適合する項目が選ばれやすくなります。判断する側には、その評価が妥当かどうかを検証する手段がありません。

パターン2:精度への偏重

正答率85%という結果が出ても、その水準で十分なのか、本番化の費用はいくらか、残る15%の誤りがどの程度の支障になるのかが不明であれば、次に進むかは決定できません。

パターン3:手応えによる評価

担当者の手応えには価値があります。ただしそれは判断の根拠ではなく、次に確認すべき仮説の出発点です。手応えのまま判断に用いた場合、誰も反証できない材料で投資が決定されることになります。

PoC止まりの多くは、この3つのいずれかに該当します。

02

Five Aspects

評価項目の5つの観点

PoCの後に控えているのは、次の段階に人と資金を追加投入するかどうかの判断です。この判断には、次の5観点の材料が必要になります。

観点

問い

名前より広く取る範囲

① 業務効果

問い

誰に、どの価値が、どの程度生じるか

名前より広く取る範囲

自社の作業量に閉じない。業務・受け取る側・会社の損益の3階層で見る

② 品質・精度

問い

必要な品質・速度・安定性を実現できるか

名前より広く取る範囲

精度の数値だけでなく、評価データの妥当性と代表性を含む

③ 経済性

問い

初期・運用・改善まで含めて成立するか

名前より広く取る範囲

効果額が損益のどの科目へ届くかまで含む

④ リスク

問い

法務・セキュリティ・誤判断などを許容できるか

名前より広く取る範囲

対策の設計だけでなく、許容を判断するのが誰かの指定と、撤退コストを含む

⑤ 運用可能性

問い

本番化後に誰が維持・改善するか

名前より広く取る範囲

担い手だけでなく、現場が使い続けるか(定着)を含む

PoCの段階で5観点すべてを満たす必要はありません。重要なのは、どの観点が確認済みでどの観点が未確認かを明示し、未確認の項目に期限と担当者を付けることです。 未確認であること自体が見えなくなっている状態が、判断を最も困難にします。

運用可能性に含まれる定着(現場の人が使い続け、業務の手順に組み込まれるか)を組織全体で進める方法は、生成AIの社内浸透・定着ガイドで整理しています。

03

Evaluation Items

評価項目の一覧

5つの観点に測定項目を当てはめると次のようになります。問い合わせ対応AIを例としていますが、多くの案件に適用できます。

表の「つまずきやすい点」は、項目を設定したにもかかわらず判断材料にならなかったケースとして、複数の案件で共通して観察される事象です。

観点

評価項目

測定方法

つまずきやすい点

① 業務効果

評価項目

AIの出力の採用率

測定方法

修正なし・軽微な修正で使用できた割合(%)

つまずきやすい点

「使用できた」の定義が未確定だと集計できない

① 業務効果

評価項目

AIを適用できる業務の割合

測定方法

全件のうち実際にAIで処理できた件数の割合

つまずきやすい点

全件に適用できる前提で効果を計算してしまう

① 業務効果

評価項目

1件あたりの処理時間

測定方法

導入前の実測値との差(分・%)

つまずきやすい点

導入前を測定していないと比較できない

① 業務効果

評価項目

サービスの受け手への影響

測定方法

初回解決率、待ち時間、再問い合わせ率

つまずきやすい点

自社の効率のみ確認し、受け手側を見落とす

② 品質・精度

評価項目

全体の正確さ

測定方法

評価データでの正答率(%)。カテゴリ別にも算出

つまずきやすい点

平均のみでは特定カテゴリの低さが隠れる

② 品質・精度

評価項目

重大な誤りの発生

測定方法

重大度別の件数/評価した総件数

つまずきやすい点

件数の記載がないと「0件」でも判断材料にならない

② 品質・精度

評価項目

検索と生成の分離

測定方法

社内文書などを検索して回答する構成では、必要な文書を拾えた割合と、拾った文書に沿って回答できた割合を分けて測定

つまずきやすい点

回答の正誤だけを見ると、改善すべき箇所が特定できない

② 品質・精度

評価項目

モデル・指示文の版

測定方法

評価時に使用したモデルと指示文の版を記録し、変更時は再測定

つまずきやすい点

提供元の更新で出力の傾向が変わり、評価結果が再現しなくなる

② 品質・精度

評価項目

応答時間・処理量

測定方法

秒、件/時。想定ピーク時も測定

つまずきやすい点

PoCの小規模では問題が表面化しない

② 品質・精度

評価項目

再現性

測定方法

同一入力を複数回試行したときのばらつき

つまずきやすい点

1回の結果のみで判断してしまう

③ 経済性

評価項目

想定件数での月額費用

測定方法

基本・上振れ・下振れの幅(円/月)

つまずきやすい点

初期開発費のみを確認し運用費が抜ける

③ 経済性

評価項目

利用量増加時の単価

測定方法

件数を増やしたときの1件あたり費用の変化

つまずきやすい点

PoC規模の単価をそのまま乗算している

③ 経済性

評価項目

改善・再学習の工数

測定方法

稼働後の精度改善・調整にかける月間時間

つまずきやすい点

提案書では実質ゼロで置かれていることが多い

③ 経済性

評価項目

人による確認の工数

測定方法

1件あたりの確認時間 × 想定件数

つまずきやすい点

効率化の効果から差し引かれていない

④ リスク

評価項目

データの取扱い条件

測定方法

入力・保存・学習利用・削除の可否

つまずきやすい点

PoC環境と本番環境で条件が異なる

④ リスク

評価項目

停止と復旧

測定方法

停止可能か、前の状態に戻せるか(実際に試行)

つまずきやすい点

設計上の可否と実際の可否は別

④ リスク

評価項目

自動操作の範囲

測定方法

AIが送信・更新・削除などを実行する場合、人の承認を挟む操作と自動で実行してよい操作の切り分け

つまずきやすい点

取り消しにくい操作を自動側に置いたまま検証していない

④ リスク

評価項目

外部入力による指示の乗っ取り

測定方法

不正な指示を含む文書やWebページを読ませ、権限を超えた操作や情報の持ち出しが生じないか試験

つまずきやすい点

重要案件でのみ必要な項目だが、そもそも項目として立っていない

⑤ 運用可能性

評価項目

利用者の手戻り

測定方法

差し戻し率、修正にかかる時間

つまずきやすい点

利用率のみ確認し手戻りを見ない

⑤ 運用可能性

評価項目

運用にかかる工数

測定方法

監視・問い合わせ対応・改善の月間時間

つまずきやすい点

PoC中は運用者が存在しないため可視化されない

この表は出発点であり、案件のリスクと規模に応じて取捨します。低リスクの案件で全項目を測定するのは過剰です。自動操作と乗っ取りの試験は、AIが送信・更新・削除などを実行する構成の場合にのみ対象になります。

項目に合格条件を付けて計画書の形式に落とす方法は、PoC計画書・企画書に何を書くかに記入例があります。

04

Assumptions

効果見積もりにおける2つの楽観的前提

①業務効果の見積もりでは、複数の案件で共通して次の2つの楽観的前提が観察されます。いずれも計算の誤りではなく、前提の置き方に起因します。

前提1:全件への適用可能性

実際には、例外的なケース、判断が困難なケース、AIに渡せない形式のデータが一定割合存在します。適用可能な割合を測定せずに全件で計算した場合、効果は実態より大きく算出されます。

したがってPoCでは、AIが処理できなかった件数とその理由を記録する価値があります。「85%正解した」よりも「全体の18%は適用不可、残る82%のうち85%が正解」のほうが判断に使用できます。

前提2:削減時間の価値転換

1件あたり3分短縮 × 月1,200件 = 月60時間。この計算は成立します。ただし、その60時間の用途が未確定であれば金額にはなりません。

現場が提示できるのは削減可能な時間までです。空いた時間を何に振り向けるかは、現場ではなく経営の判断にあたります。ここが未確定の提案は、効果の数値が大きいほど実現が困難になります。効果を金額換算する場合は、振り向け先とその意思決定者を併記する必要があります。

note

効果額が損益のどの科目に届くか、役員が何を効果として認めるかは、noteの記事で詳しく解説しています。

AIの費用対効果が経営に通らない理由

05

KPI Layers

KPIの3階層

①業務効果は、PoCの評価で最も抜けやすい領域です。KPIは「誰にとっての成果か」で3つに分けて設定します。

KPI

誰にとっての成果か

問い合わせ対応AIの例

役割

事業KPI

誰にとっての成果か

業務にとっての成果

問い合わせ対応AIの例

1件あたりの処理時間、AIの出力の採用率、リードタイム

役割

効果を金額に換算する基礎

サービスKPI

誰にとっての成果か

利用者・お客様にとっての成果

問い合わせ対応AIの例

初回解決率、待ち時間、再問い合わせ率、顧客満足度

役割

効率化と経営成果をつなぐ

経営KPI

誰にとっての成果か

会社にとっての成果

問い合わせ対応AIの例

対象チャネルの総対応コスト、解約率・継続率、売上・利益

役割

投資の目的への到達を確認する

多くのPoCは事業KPI(自社の作業量の減少)のみで評価されています。しかし処理時間が半減しても、回答品質が低下して再問い合わせが増加すれば、会社全体では改善していない可能性があります。

サービスKPIは、効率化が経営の成果につながっているかを確認する中間層です。 改善目標としてだけでなく、効率化によって受け手の体験が悪化していないかを監視する歯止めとしても設定します。

社内業務ではサービスの受け手が不明確な場合があります。その場合は、そのアウトプットを受け取る次工程または意思決定者を受け手とみなします。資料作成AIであれば、資料を受け取る上長や会議体が受け手にあたり、差し戻しの回数や意思決定までの時間がサービスKPIの候補になります。

なお、AIの精度や自動化率は事業KPIに含めます。これらは業務の変化を示す指標であり、顧客や会社にとっての成果そのものではないためです。

事後取得が不可能な指標の測定開始時期

顧客満足度や利用者アンケートなどの主観的指標は、導入後に導入前の値を取得し直すことができません。比較に用いる指標は、PoC開始前に測定を開始する必要があります。 これを逃した場合、PoC後の評価で改善の有無を示す手段が失われます。

測定開始のタイミングと構想段階の作業はAI PoCの進め方で解説しています。

06

Evaluation Data

評価データの要件

②品質・精度では、どのデータで評価したかが結果の信頼性を左右します。評価データについて確認する点は次の6つです。

1

誰が作成し、誰が正解を定義し、誰が最終承認したか

2

業務のカテゴリ分布、難易度、例外、重要ケースを代表しているか

3

開発・調整に使用していないデータ(ホールドアウトデータ)があるか

4

誤りを重大度別に分け、それぞれの許容値と評価件数を定めているか

5

人が評価する場合、評価基準を統一し、評価者間の判定一致を確認したか

6

品質に加え、速度、利用費用、セキュリティ上の耐性を確認したか

実際の案件で多く観察されるのは、2・3・1の不備です。評価データが容易なケースに偏り例外が含まれていない。開発に使用したデータでそのまま評価している。正解の定義者が記載されていない。

この3つが重なった場合、算出された数値が何を測定したものかを事後に検証できなくなります。精度の数値が良好であっても、判断材料としては使用できません。

4については、許容値と評価件数を一組で決めます。「重大な誤り0件」という結果は、何件のうち0件なのかが書かれていなければ判断に使えません。件数の少ない評価で0件が出ることと、必要な水準を満たすことは別です。

正解が一つに定まらない場合の評価

文章、要約、回答案のように、同じ入力に対する良い出力が複数ありうる場合、正解ラベルとの一致では測定できません。「何をもって良い出力とするか」の基準づくりが評価設計の中心になります。

観点を分ける:内容が正しいか、問いに答えているか、社内ルールに沿っているか、表現が適切か。一つの点数にまとめた時点で、どこを直せばよいかが分からなくなります

評価者の目線をそろえる:基準を文書化し、複数人で同じ出力を採点して判定が一致するかを確認します

AIに採点させる場合も確認を入れる:件数はこなせますが、その採点が人の判断と一致しているかを一部のデータで確かめる必要があります

誤りの性質にも注意が必要です。自信のある文体で事実と異なる内容が出力されることがあり、平均の正答率だけでは重大な誤りが埋もれます。誤りは重大度別に分け、重大なものには許容件数を個別に設定します。

評価者と作成者が同一の場合の扱い

評価データの作成者とAIの評価実施者が同一であることのみを理由に、評価を無効とする必要はありません。ただし、正解の定義、データの代表性、評価手順、結果について、業務部門または独立した立場からの確認が必要です。同一チームが評価する場合は、開発中に未使用のホールドアウトデータを追加する方法が有効です。

07

Decision Criteria

判定基準の4区分

評価項目を決定したら、それぞれについてどの結果ならどう判断するかを事前に定めます。判定は次の4区分を用います。

判定

意味

次に行うこと

Go

意味

事前に定めた条件をすべて満たした

次に行うこと

次の段階へ進む

条件付きGo

意味

大筋で満たしたが、期限付きの残課題がある

次に行うこと

担当者・期限・未達時の扱いを定めて進む

保留・再設計

意味

例外扱い。設計そのものを変えないと判断できない

次に行うこと

成立要件をすべて記録する。再判定日の超過時は自動的にNo-Go

No-Go

意味

条件を満たさない項目がある、または何が不足しているかを項目名で書けない

次に行うこと

計画の見直し、または停止

ここで適用する原則は一つです。材料の不足は、Goの理由にはなりません。

「止める理由が見つからないため継続する」という判断は、継続を既定路線にします。中止のために効果の不在を証明するのではなく、Goの条件を満たした案件のみを次に進める。この順序により判断は明確になります。

保留・再設計を例外扱いとする理由

4区分のうち、保留・再設計だけは扱いが異なります。判断を先送りしても誰も責任を問われない唯一の選択肢であり、放置すると既定の出口になるためです。

複数の案件で共通して観察されるのは、保留・再設計が責任者の選択ではなく、材料が揃っていない状態の自動的な表示になっているケースです。評価シートの項目は「未確認」から始まります。未確認が1件でもあれば全体は未完成であり、そこに「保留」という名前が付いていると、開始時点から終了時点まで一貫して保留が正当化されます。責任者は自分で判定を選んだつもりでも、実際には表示された状態を追認しているだけになります。

判断が確定するまでの期間そのものが最大の損失である以上、保留・再設計は選ぶのに手間がかかる選択肢にしておく必要があります。

保留・再設計の使い分け

状況

正しい判定

材料の一部が遅れているだけ(見積書待ち、法務確認待ち、ベンダー回答待ち)

条件付きGo

設計そのものを変えないと判断できない(対象業務、体制、技術選定の見直しが必要)

保留・再設計

何が不足しているかを項目名で書けない

No-Go

多くの案件で保留・再設計とされている状態は、実際には1行目です。遅れている材料は条件として書けます。条件・期限・未達時の扱いを記録すれば、案件は止まりません。

3行目は判断が分かれるところです。ただし、何が足りないかを項目名で書けない状態は、待っても揃いません。 材料を特定できないこと自体が設計の不備であり、案件をやり直すほうが結果的に早くなります。

保留・再設計の成立要件

保留・再設計を選ぶ場合は、次の5つをすべて記録します。いずれかが書けない場合はNo-Goとします。

1

不足している材料の項目名 — 「情報不足」は不可。「本番規模での月額利用料(上振れ時)」のように、評価項目の名前で書く

2

項目ごとの担当者と提出期限

3

再判定日 — カレンダー上の日付。「揃い次第」は不可

4

再判定日を超過した場合の既定判定 — 原則No-Go。超過時は再審議せず確定させる

5

PoC開始前にこの材料を定義できなかった理由 — 一行でよい

5つのうち、保留を長引かせないために最も重要なのは4です。期限を過ぎたときに「あらためて会議で判断する」としておくと、保留は何度でも延長できてしまいます。超過=自動的にNo-Go(再申請は新規の案件として扱う)と決めておけば、放置がそのまま継続になることを防げます。

5は再発防止のための記録です。保留・再設計が発生したこと自体が、PoC開始時点で判断材料を定義できていなかったという事実を示します。この一行があると、次の案件の開始ゲートで同じ保留を繰り返さずに済みます。

同一案件での保留・再設計は原則1回とします。2回目を選ぶ場合は、判定者を一段上位の会議体へ引き上げます。保留を続けるほうが説明コストが高くなる構造にすることが目的です。

08

Hypothesis

手応えの検証仮説への変換

評価で扱いに迷うのは、「回答案の質が高く実務で使用できそうだ」といった手応えです。これは破棄する必要はありません。次の段階(実際の業務の一部で使用する限定実運用)で確認する仮説に変換します。

項目

記載例(問い合わせ対応AI)

観察・手応え

回答案の質が高く、実務で使用できそうだと感じた

効果が生じる仮説

回答案の質の向上により確認・修正の時間が減少し、初回解決率が上がる

事業KPI

有人対応の平均処理時間を15%以上短縮

サービスKPI

初回解決率を5ポイント以上改善し、顧客満足度を低下させない

経営KPI

対象チャネルの総対応コストを10%以上削減

比較の方法

導入前の値、または同期間の比較グループ。対象・期間・件数を明記

Goの条件

3つのKPIと、リスク・費用の条件をすべて満たす

条件付きGoの条件

効果は確認できるが、品質・運用の一部が未達。担当者・期限・未達時の扱いを付けて進む

No-Goの条件

処理時間の短縮が5%未満、重大なリスクが許容範囲外など

責任と期限

指標の確定者、測定者、判定者、判定日

※数値は記載例です。案件ごとに設定します。

この形式で書き出すことにより、「使用できそう」が「何がどれだけ変化すれば進むのか」に置き換わります。PoCの評価報告の末尾にこの表があれば、判断する側は追加の確認を要しません。

09

Checklist

PoC評価チェックリストの構成(20項目のうち11項目を抜粋)

本稿の内容を、PoCの開始前・実施中・終了時に分けて確認できるようにしたものが、AnchorXのPoC評価チェックリストです。20項目を6つの評価領域に分け、項目ごとにOKの目安と確認資料を付けています。以下はそのうち11項目の抜粋です。

開始前

PoCで確認する内容を、測定する数値・対象・合格条件に分解したか

評価データ、期間、利用条件、現行業務との比較方法を決定したか

学習・検索・評価に使用するデータの欠損、偏り、重複を確認したか

実施中

実際の利用者が主要な業務でAIを試行したか

AIの誤りを人が検出し、修正し、差し戻せるか試行したか

役割分担が実際に機能したか、変更と課題を記録したか

終了時

精度に加え、時間・件数・品質・費用などの業務効果を測定したか

重要ケース別の結果があるか

応答時間、処理量、費用、再現性など、本番での使用見込みを確認したか

重要案件において、開発担当以外が結果と合否を確認したか

残存リスクと、次の判断案(本番設計・追加確認・停止)をまとめたか

残る9項目は、データの返却・削除、想定外入力への耐性、ベンダーからの引継ぎ、運用工数の見込みなどを扱います。

案件リスク(低・中・高)に応じて確認項目を絞り込めるほか、判定欄の入力により、材料の充足状態が「材料そろう/条件付きGo候補/材料不足/No-Go候補」のいずれかで自動表示されます(対象項目をすべて対象外にした場合は「判定不能」)。自動表示は材料が揃っているかどうかを示すものであり、判定ではありません。 最終判定は責任者が4区分から選びます。

10

Summary

まとめ

PoCの評価項目は、PoC終了時に下す判断から逆算して決定します

評価は業務効果/品質・精度/経済性/リスク/運用可能性の5観点で行い、未確認の観点を可視化します

名称より範囲は広く取ります。業務効果は自社の作業量に閉じず、運用可能性は定着を含み、リスクは許容の判断者の指定と撤退コストを含みます

測定項目は本稿の一覧を出発点とし、案件の規模とリスクで取捨します

効果見積もりでは、全件への適用可能性削減時間の価値転換の2つの前提に注意します

KPIは事業・サービス・経営の3階層で設定します。サービスKPIは効率化と経営成果をつなぐ層です

正解が一つに定まらない出力では、良い出力の基準づくりが評価設計の中心になります

判定は Go/条件付きGo/保留・再設計/No-Go の4区分です

保留・再設計は例外扱いです。 材料の遅れは条件付きGo、項目名で書けない不足はNo-Go。保留を選ぶ場合は成立要件5つを記録し、再判定日の超過時は自動的にNo-Goとします

PoCの全体の流れはAI PoCの進め方、PoCの基本はAI PoCとは何かで解説しています。個別の疑問への短い回答はAI PoCのよくある質問にまとめています。

note

5観点それぞれの難所と、報告会で判断が出ない構造は、noteの連載で解説しています。

本番化を決める前に確認する5つの観点

Download

PoC評価チェックリスト(20項目)

PoCの開始前・実施中・終了時に確認する20項目を、OKの目安と確認資料つきでまとめたExcelです。案件リスクに応じた絞り込みと、材料の充足状態の自動集計に対応しています。AnchorXが無料で配布しています。

チェックリストをダウンロード

Free Consultation

PoCの論点を、第三者と無料で整理する

目的・評価項目・判定基準が決めきれていないPoCを、60分の無料相談で整理します。AIセカンドオピニオンのページ(so.anchorx.co.jp)が別タブで開きます。

無料相談のページへ