AI ROIのKPI設計、自己申告の時短を経営会議に出すのをやめる

AI活用のKPI設計で先に決めるべきは、指標の数や階層ではなく、その数字を誰が出したかである。国内の解説記事はすでに一段進んでおり、業務KPI・財務KPI・戦略KPIの3層に分ける枠組み、ROIの計算式、KPI設計シートのテンプレート、ダッシュボードの構成例までが揃っている。それでも経営会議でAIの効果報告が信用されないのは、階層の設計が足りないからではない。積み上げている数字のほとんどが、現場の自己申告だからだ。上位記事に共通するのは、時間の計測を現場の自己申告に委ねている点だ。粒度をそろえても、申告が膨らむ構造には手が付いていない。本稿はその一点に絞る。

利用率とライセンス配布数は何を測っていないのか

具体的な数字から入る。Microsoftは前四半期にCopilotの有料シートを1000万追加した。配布量としては圧倒的だ。ところが開発者のあいだではClaude CodeやCodexへの移行が進み、Claude Codeは2026年2月までの9か月で、Pragmatic Engineerの調査で最も使われるAIコーディングツールになってGitHub Copilotから首位を奪った（Copilot のライセンス配布数は AI 導入の成功指標になるのか — Copilot Studio の実力とユーザー流出の実態で扱った構図）。

この対比が示すのは、配布数という指標の性質だ。配布数は正確に測れる。改ざんの余地もない。それでも、開発者が自発的に別のツールへ移っている事実を一切捕まえられない。利用率も同じ弱点を持つ。ログインしたかどうかは分かるが、上手く使えているかは分からない。つまり利用率とライセンス配布数は、間違った数字ではなく、答えを持っていない数字である。

そこで多くの組織が次に足すのが、現場からの時短報告だ。週あたり何分削減できたかを担当者が申告し、それを部署ごとに積み上げる。だがこの数字は、担当者が自分の業務を思い出して申告したものである。ここに本稿の論点がある。

AIのKPIは「誰が出した数字か」でどう分かれるのか

結論を先に置く。AIのKPIは階層ではなく出所で3つに分けるべきで、経営会議に載せるのは後ろの2つだけである。

第一が自己申告の数字。 体感の時短、アンケート、業務改善の報告書がこれにあたる。作るのが最も安く、粒度も自由に決められる。

第二がシステムが出す数字。 同じ成果を出すのに要したトークン量・呼び出し回数・処理時間に加え、ワークフロー単位の再実行率、人手による差し戻し回数、自動完了率といった指標が、いずれも担当者の記憶を経由せずに記録される。

第三が事業の数字。 米メディア企業のEveryは年額625ドルの新メンバーシップ「All Access」の発売で、2日間にMRRを約9,000ドル積み増した。同社のグロース責任者は、購入意向を示しながら未購入だった層へのメールについてCodexに「できるか」と投げて外出し、戻ると4つの顧客セグメントとメール文面ができていた。翌朝までにそのメールで2万5,000ドルの売上が生まれている（AIエージェント活用のROIをどう測るか——メール1本で25,000ドルを生んだ「人が枠組み、AIが実行」の分業設計）。売上・原価・リードタイムは、AIを使ったかどうかとは独立に帳簿に残る。

第二と第三の共通点は、報告者の主観を通らないことだ。逆に第一は、測定者と評価される当事者が同一人物である。この構造上の差が、次章の問題に直結する。

誇張報告を構造的に防ぐ指標は何か

自己申告が膨らむのは、担当者が不誠実だからではない。圧力の経路がそうさせる。Lenny’s Newsletterに寄稿したElena Vernaは、「AI Confidence Theater」という名前でこの連鎖を名指ししている。投資家が経営層に、経営層が現場に「AIによる奇跡を証明しろ」と求め、現場はそれに応える形でAI活用の自信を演じる。SNSには「人生が変わった」級の話が並ぶが、実態の多くはSlackの要約やメール返信といった補助的なワークフローにとどまる（AI活用の誇張報告はなぜ生まれるのか ― 採用とROI評価を歪める「AI Confidence Theater」の構造）。

Vernaの処方は誠実さの回復であり、20分の時短は20分の時短として祝え、プロトタイプはプロトタイプと言え、というものだ。もう1つ、指標設計に直接効く指摘がある。

“The first prompt is the fun part. The next thousand prompts is where real value is created.”

（最初のプロンプトは楽しい部分だ。本当の価値が生まれるのは、その先の千回のプロンプトにある。出典: Lenny’s Newsletter by Elena Verna、2026-07-03）

AIシステムは設定して放置できるものではなく、継続的な監視と反復調整が本質だという指摘がこれに続く。だとすれば、初回の導入効果を一度申告させて終わる測定設計は、最も価値が生まれる領域をまったく見ていない。

構造的な対策は素朴だが効く。自己申告を廃止するのではなく、自己申告で出た数字には必ず第二か第三の数字で裏を取るという順序を決めることだ。週30分の時短が申告されたなら、その業務の処理件数や所要時間がログに現れているか、外注費や残業時間が実際に減っているかを突き合わせる。裏が取れない申告は、成果ではなく仮説として扱う。仮説であれば、検証対象として扱えるので誰も嘘をつく必要がない。誇張が生まれるのは、申告がそのまま成果として確定してしまう経路があるときだけだ。

今期の経営会議に何を出すか

決めることは1つに絞れる。経営会議に載せるAI指標のうち、現場の自己申告を経由しない指標をいくつ持つか、である。

具体的には、報告フォーマットを3列で作る。①申告された効果 ②それを裏付けるシステム側の数字 ③それが事業の数字に現れた痕跡。②と③が空欄の行は、成果ではなく検証待ちの仮説として色を変える。これだけで、報告の総量は減るが、残った数字は追及に耐える。空欄の多さ自体も情報になる。ログを取っていない業務、事業の数字に接続していない用途がどこかが一目で分かるからだ。

なお、用途ごとにゴールを定義して計算資源を再配分する話、およびROI測定を人事評価の意思決定ラインへ接続するかどうかの論点は、生成AIのROIをどう経営会議に通すかで扱っている。ゲーム会社Arkadiumが4桁安い専用モデルで同じゴールを満たした例のように、測定の単位を全社から用途へ下げる話もそちらが本題だ（AI の ROI はどう測るか——LLM より4桁安い専用モデルが最適解だった Arkadium の事例）。本稿が扱ったのはその手前、報告された数字が信用できるかという工程である。評価と報酬に跳ね返る部分はAI時代の人事評価制度、何を変えて何を変えないかと合わせて読める。

まとめ: 階層を増やす前に出所を分ける

AI ROIのKPI設計でつまずいている組織の多くは、指標が足りないのではなく、自己申告で作られた数字を階層に並べ替えているだけだ。Microsoftの1000万シートは何も証明していないが、少なくとも誇張ではない。危ういのは、誰の検証も通らずに成果として確定した時短の積み上げである。階層を増やす前に、その数字を誰が出したかで分ける。経営が今期中に決めるべきは、自己申告を経由しない指標をいくつ経営会議に載せるか、その一点だ。