結論：効果測定は「導入前」に設計しないと、1年後に「で、いくら効いたのか」へ答えられない

AI開発で最も多く、最も気づかれにくい失敗のひとつが、「導入して終わり」である。システムは動いている。利用者もそれなりに使っている。だが1年後の予算会議で役員から「で、このAIはいくら効いたのか」と問われた瞬間、誰も数字で答えられない。削減できた時間も、増えた処理件数も、売上への効果も測っていないからである。成果を説明できないAIは「効果不明の経費」として扱われ、2年目の予算が削られるか、打ち切られる。

  • 検収の合格ライン（精度・品質）と事業KPI（導入後の業務効果）は別物で、検収に通っても成果は説明できない。
  • 事業効果は「導入前と導入後の差分」でしか示せず、導入前のベースライン計測がなければ永遠に測れない。
  • KPIは削減時間・処理件数・品質・売上効果など、対象業務の言葉で定義する必要がある。
  • 計測は人手の集計に頼ると続かないため、システム側に計測の仕込みを発注時から要件として入れる。
  • 月次レビューと役員報告のフォーマットまで決めて初めて、効果測定は「設計された」といえる。
  • 2年目の予算は精度ではなく「経営に説明できる成果」で決まる。

この連載は「AI開発発注の失敗図鑑」として、発注側がつまずきやすい論点を一つずつ分解している。第29回となる本稿が扱うのは、納品時の合否ではなく「導入後の事業効果を測れるか」である。納品物が合格かどうかを判定する基準づくりは検収・受け入れ基準の失敗で扱ったが、検収は「約束した品質で作られたか」を見るものであり、「業務にいくら効いたか」は答えてくれない。また、AIの個別の判断根拠を後から説明できるかという論点は説明可能性・トレーサビリティの失敗で扱ったが、本稿の「説明」は監査や苦情への説明ではなく、経営への成果説明である。時間軸でいえば、PoCで終わる失敗で扱った検証の合格基準、第21回の検収基準に続く三つ目の関門が、本稿の運用フェーズの事業KPIである。

なぜ「成果が説明できない」が起きるのか

検収の合格と事業の効果は別物である

発注側の多くは、検収で精度や品質の基準を満たせば「成功」だと考える。だが検収が確かめるのは「発注どおりに作られたか」であり、「業務に効いたか」ではない。回答精度9割のチャットボットが納品されても、問い合わせ対応の時間が減ったのか、対応件数あたりのコストが下がったのかは、別の測定をしなければ分からない。検収は納品時点の品質の話、事業KPIは運用が始まってからの効果の話で、測る対象も測る時期も異なる。前者だけを設計して後者を設計しないと、「正しく動いているが、効いたかどうかは誰も知らない」状態になる。

ベースラインは導入前にしか測れない

事業効果は、導入前と導入後の差分でしか示せない。問い合わせ1件の対応に何分かかっていたのか、月に何件処理していたのか、文書1本の作成に何時間かけていたのか。この「導入前の状態」がベースラインであり、導入してしまった後には二度と測れない。1年後に効果を測ろうと思い立っても、比較対象が存在しないため、「速くなった気がする」以上のことが言えない。効果測定の設計が発注前の論点である最大の理由がここにある。開発の要件定義と同じタイミングで、ベースラインの計測項目と計測方法を決めておく必要がある。

「使われている」と「効いている」は違う

利用回数やアクティブユーザー数は取りやすいため、効果の代わりに報告されがちである。だが「よく使われている」ことと「業務に効いている」ことは別である。検索AIが1日に何百回使われていても、探す時間が短くなっていなければ効果はない。むしろ、AIの回答を確認し直す手間が増え、トータルの作業時間が悪化している場合すらある。利用状況は前提条件にすぎず、事業KPIは削減時間・処理件数・品質・売上といった業務の結果で定義しなければならない。なお、そもそも利用が定着しないという手前の失敗は利用者リテラシー・定着の失敗で扱っており、本稿は「使われているのに効果を示せない」段階の話である。

1年後の予算会議で「効果不明の経費」になる

効果測定がないままでも、導入初年度は「導入したばかりだから」で乗り切れる。問題は2年目の予算編成である。役員が知りたいのは精度でも利用回数でもなく、「投じた金額に対していくら返ってきたのか」である。ここで数字を示せないと、AIはコスト削減の候補に載る。皮肉なことに、実際には効果が出ていても、測っていなければ「効果不明」として扱われる。逆に、効果が小さくても測定と改善のサイクルが回っていれば、「ここを直せば伸びる」という次の投資の議論ができる。予算を守るのは成果そのものではなく、成果を説明できる仕組みである。誰がこの測定と報告を担うのかという体制の論点は、推進体制・オーナー不在の失敗と地続きである。

業務別にみる事業KPIの例

事業KPIは「AIの指標」ではなく「業務の指標」で組む。代表的な業務について、ベースラインで測っておくべき項目とKPIの例を整理する。自社の対象業務に置き換えて使ってほしい。

業務ベースラインで測るもの事業KPIの例補助指標の例
問い合わせ対応1件あたり対応時間、月間対応件数、一次回答までの時間対応時間の削減、自己解決率の向上、有人対応件数の削減エスカレーション率、回答後の再問い合わせ率
文書作成（議事録・報告書・提案書）1本あたり作成時間、月間作成本数、手戻り回数作成時間の削減、レビュー指摘の減少修正率、テンプレート利用率
社内検索・ナレッジ参照1回の探索にかかる時間、見つからず人に聞く頻度探索時間の削減、有識者への割り込み質問の削減検索の解決率、参照された文書の範囲
受発注・帳票処理1件あたり処理時間、月間処理件数、入力ミス率処理時間の削減、処理可能件数の増加、ミス起因の手戻り削減例外処理（人手対応）の比率

表の左から右へ、「導入前に測る→効果として報告する→原因を分析する」という使い方になる。補助指標は、KPIが動かないときに「どこで詰まっているか」を見るためのもので、役員報告の主役にはしない。重要なのは、KPIを金額に換算する道筋を最初に決めておくことである。削減時間×時間単価、処理件数の増加×1件あたりの価値、といった換算式を役員と先に合意しておけば、報告のたびに数字の妥当性を議論し直さずに済む。

効果測定を設計する五つの手順

効果測定は導入後に考えるものではなく、発注と並行して設計するものである。手順は次の五つに整理できる。

  1. ベースライン計測：対象業務の現状を、導入前に数字で記録する。対応時間・件数・ミス率など、後でKPIの分母になる項目を、最低でも1〜3ヶ月分は取る。厳密な計測が難しければ、担当者へのヒアリングとサンプル実測の組み合わせでもよい。「測っていない」よりはるかに強い。
  2. KPI定義：ベースラインに対して「何が・どれだけ・いつまでに」変われば成功かを定義する。指標は欲張らず、役員報告の主役になる主要KPIを1〜2個、原因分析用の補助指標を数個に絞る。金額換算の式もここで役員と合意しておく。
  3. 計測の仕込み：KPIの元データが自動で残るよう、システム側に計測を仕込む。処理件数・処理時間・利用ログなどは、開発の要件として最初から入れれば安価に済むが、稼働後の後付けは改修になる。人手のアンケートや手集計に依存した計測は、ほぼ確実に数ヶ月で止まる。
  4. 月次レビュー：KPIを月次で確認し、未達なら補助指標で原因を切り分け、改善を打つ場を定例化する。レビューのオーナー（業務側の責任者）を決め、開発会社任せにしない。効果は導入直後より、改善を数回重ねた後に立ち上がることが多い。
  5. 役員報告のフォーマット：「投資額・効果額・差分・次の打ち手」が1枚で分かる報告様式を最初に作り、毎回同じ形式で更新する。報告のたびに資料を作り直す運用は続かないうえ、形式が変わると過去との比較ができなくなる。

この五つのうち、発注前に着手しなければならないのは1〜3である。とくに手順3の計測の仕込みは、見積もり・要件定義の段階で開発会社に伝えなければ盛り込まれない。投資対効果の枠組みを社内で通す段になったら、投資対効果（ROI）診断で換算の考え方を整理しておくと、稟議と役員報告の数字が一本につながる。

発注前に確認すべきこと（チェックリスト）

  • 検収の合格ライン（精度・品質）とは別に、導入後の事業KPIを定義したか。
  • 対象業務のベースライン（対応時間・処理件数・ミス率など）を、導入前に計測する計画があるか。
  • KPIを金額に換算する式（時間単価・1件あたりの価値など）を役員と合意したか。
  • KPIの元データが自動で残るよう、計測機能を開発の要件・見積もりに含めたか。
  • 利用回数・ユーザー数だけを「効果」として報告しない方針を関係者で確認したか。
  • 月次レビューの場と、業務側のオーナーを決めたか。
  • 役員報告のフォーマット（投資額・効果額・差分・次の打ち手）を決めたか。
  • 2年目以降の予算判断に使う基準（継続・拡大・縮小の条件）を先に決めたか。

このチェックリストは、AIに限らず業務システム全般の投資判断にそのまま使える。基幹業務やDX全体の文脈で効果測定を設計したい場合は、DX・システム開発の進め方と合わせて、対象業務の選定から相談するのが現実的である。

GXOに相談する前に整理しておくとよい情報

相談前に次を整理しておくと、効果測定の設計が具体化しやすい。

  • 対象業務と現状の数字：対応時間・処理件数・かかっている人員など、いま分かる範囲の現状値。正確でなくても、当たりがあるだけで設計が速くなる。
  • 期待している効果の言葉：時間を減らしたいのか、件数をさばきたいのか、ミスを減らしたいのか、売上に効かせたいのか。
  • 報告の相手と頻度：誰に（役員会・経営会議・部門長）、どの頻度で成果を説明する必要があるのか。
  • 既存の計測手段：業務システムのログ、勤怠・工数データ、問い合わせ管理ツールなど、ベースラインに流用できる記録があるか。
  • 予算判断のタイミング：次の予算編成がいつで、それまでに何を示せれば継続・拡大の判断が得られるのか。

これらが揃っていると、ベースライン計測の範囲とKPIの候補を初回の打ち合わせで絞り込める。揃っていなくても、「何も測っていない」と分かっていること自体が出発点になる。

関連記事

参考一次ソース

よくある質問

Q1. 検収で精度基準を満たしていれば、成果は説明できるのではないか。

できない。検収が示すのは「発注どおりの品質で作られた」ことであり、「業務に効いた」ことではない。精度9割のAIでも、対応時間が減ったか、処理件数が増えたかは別の測定が要る。検収の合格ラインと事業KPIは、測る対象も測る時期も異なる二つの関門として、両方を設計する必要がある。

Q2. 導入前にベースラインを測り忘れた場合はどうすればよいか。

完全な事後測定は不可能だが、打てる手はある。導入前から残っている業務記録（問い合わせ管理ツールの件数、工数データ、処理ログなど）を遡って復元する、AIを使わない業務が残っていればその実測値を比較対象に使う、担当者ヒアリングで導入前の所要時間を推定する、といった方法である。精度は落ちるが、「何も示せない」状態よりは予算判断の材料になる。次の開発では、ベースライン計測を要件定義と同時に始めたい。

Q3. 事業KPIにはどのような指標を選べばよいか。

AIの指標（精度・利用回数）ではなく、対象業務の指標で選ぶ。問い合わせ対応なら1件あたり対応時間や有人対応件数、文書作成なら作成時間と手戻り、受発注なら処理件数とミス率といった具合である。主要KPIは1〜2個に絞り、金額換算の式まで先に決めておくと役員報告がぶれない。利用回数などは原因分析用の補助指標に位置づけ、効果の主役にしないことが重要である。

Q4. 効果測定の仕組みは誰が運用すべきか。

業務側の責任者がオーナーになるべきである。開発会社は計測機能の実装はできるが、KPIの妥当性を判断し、未達の原因を業務の文脈で切り分け、役員に説明する役割は社内にしか担えない。月次レビューの主催と役員報告を業務側オーナーの仕事として明示し、情報システム部門と開発会社がデータ面で支える分担が現実的である。オーナーが決まっていない場合は、効果測定より先に推進体制を固める必要がある。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

AIの投資は、導入した瞬間ではなく、成果を説明できたときに初めて社内で「成功」になる。ベースライン計測やKPI設計、役員報告の組み立てを発注と並行して進めたい場合は、無料相談から、対象業務の現状値の棚卸しを一緒に始めていただきたい。