KPI可視化

AI開発発注の失敗図鑑｜事業KPI・効果測定を設計せず「成果が説明できない」失敗

2026年6月10日20分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・自動化

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

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

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

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

MANUFACTURING DX

Excel限界から受発注システムへ、同規模の概算は？

中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。

製造業DXの概算を見る

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

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

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

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

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

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

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

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

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

業務別にみる事業KPIの例

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

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

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

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

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

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

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

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

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

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

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

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

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

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

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

参考一次ソース

実務判断のポイント

この記事を読むべきなのは、経営者、情シス、業務責任者、発注担当です。単に情報を把握するだけでなく、要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築の相談に進めるべきかを判断するための材料として整理する必要があります。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。AI開発発注の失敗図鑑｜事業KPI・効果測定を設計せず「成果が説明できない」失敗に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

観点	放置した場合	整備した場合
業務影響	属人的な判断が増え、対応の優先順位がぶれやすい	影響範囲、期限、責任者を決めて進められる
投資判断	ツール導入や外注費だけが先行し、効果測定が曖昧になる	売上、工数削減、リスク低減の指標にひも付けられる
現場運用	例外処理や承認フローが残り、定着しにくい	権限、ログ、教育、改善サイクルまで設計できる
経営報告	問題が発生してから説明資料を作ることになる	月次で状況、課題、次の打ち手を説明できる

導入・改善前のチェックリスト

対象業務、対象部門、対象データを明文化しているか
現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
例外処理、承認、差し戻し、監査証跡まで確認しているか
社内で判断できる範囲と外部支援が必要な範囲を分けているか
初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
経営判断に必要な資料を1枚で説明できる状態にしているか
次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。

GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。

GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。

相談につながる進め方

現在の業務、データ、ツール、担当者を棚卸しする
売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
初期対応、90日以内の改善、半年以上の投資を分ける
必要な社内体制、外部支援、予算、セキュリティ確認を整理する
小さく検証し、効果測定後に本番化や横展開を判断する

よくある質問

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

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

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

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

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

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

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

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