『AI利用率』をKPIにしてはいけない: 目的が反転する評価設計の罠

Duolingoが示す「利用率KPI」の失敗

2024年、DuolingoはエンジニアチームにおいてAI活用を促進する目的でAI利用率をKPIに設定した。

結果: KPIの数値は達成された。しかし実際の成果である「ユーザーの言語習得率・アプリ継続率」との乖離が生じ、2025年にDuolingoはこの方針を転換した。

なぜこうなるのか。手段を目的にすると、手段を最大化することが仕事になるからだ。

「AIを使う」はツールの使用回数で計測できる。しかし「AIを使って何かを達成する」は成果で計測する必要がある。前者をKPIにすると、後者は自然と後回しになる。

tokenmaxxingという言葉が示すもの

シリコンバレーで「tokenmaxxing」という言葉が生まれた。AIの利用量（トークン数・呼び出し回数）を最大化することを指す。

典型例: DisneyがClaudeを9日間で46万コール実行した。しかし損益インパクトはゼロだった¹。

「46万コール」という数字は印象的だ。しかし何のために呼んでいたのか、何が改善されたのかを説明できない状態では、AIへの投資は「コスト」にしかならない。

なぜ企業は利用率をKPIにしてしまうのか

理由は単純だ。計測が簡単だからだ。

• AI利用率: 管理コンソールで即座に取れる数値
• 成果指標: 計測設計が必要で、効果を定量化するのに工数がかかる

工数をかけずに「AI活用が進んでいる」ことを示せる指標として利用率が選ばれる。しかしこれは「証明すべきこと」を「証明しやすいこと」に置き換える行為だ。

目的が反転するメカニズム

KPIに手段を設定すると、現場の努力が手段の最大化に向かう。本来の目的である「業務成果の改善」は後回しになる。

正しいKPI設計: 3階層で測る

McKinseyの研究では、AIでEBIT 5%以上の改善を達成している企業はわずか6%だという²。その6%に共通するのは「利用量」ではなく「事業成果」を経営指標に接続していることだ。

3階層KPI設計

階層	指標の種類	例	使い方
L1: 利用	活動量指標	月間利用回数・ツール起動数	モニタリングのみ（KPIにしない）
L2: 吸収	効果指標	作業時間短縮・品質改善率	中間証明（月次報告）
L3: 成果	事業指標	EBIT・売上・解約率・NPS	評価の本体（四半期報告）

具体的なKPI転換の例

営業チームの場合

悪いKPI設計:

• AI利用率（週に何回使ったか）
• AIアシストで作成した提案書の件数

良いKPI設計:

• 提案書の受注率（AIを使って品質が上がったか）
• 商談から受注までのサイクル時間（AIで提案書作成が速くなったか）
• 1人当たりの月間有効商談数（AIで創出した時間を活用できているか）

カスタマーサポートチームの場合

悪いKPI設計:

• AIチャット対応件数
• AI一次回答の実施率

良いKPI設計:

• 初回解決率（AIの回答品質が上がっているか）
• 顧客満足度スコア（体験が改善されているか）
• 1対応あたりの平均時間（エラー訂正含む実態を計測）

エンジニアチームの場合

悪いKPI設計:

• GitHub Copilot利用率
• AIが生成したコードの割合

良いKPI設計:

• リリースサイクル（AIで開発速度が上がったか）
• バグ発生率（AIの品質がどう変わったか）
• 機能実装1件あたりの工数

Meta型: 期待値として組み込む

Metaが採ったアプローチは「AIを使うことを評価基準の外の期待値として扱う」だった³。

具体的には: 「エンジニアとして生産性を発揮することが期待されており、その前提としてAI活用は標準的な仕事の仕方とする」という形だ。

これはAI利用率をKPIにするのではなく、AI活用を「この会社での仕事の基本的なやり方」として定義することだ。KPIではなくカルチャーとして位置付けることで、指標の数字ゲームを回避しながら活用を進める。

まとめ: 成果で測ることの徹底

AI活用のKPI設計で覚えておくべきことは1つだ。

計測すべきは「AIを使ったか」ではなく「AIを使って何が変わったか」だ。

変わったことを定量で示せるようになることが、AI投資の継続的な正当化と、組織の本当の変革につながる。

出典・参考

1. MIT Sloan: tokenmaxxingとCoE孤立 — AIネイティブ経営の失敗パターン（2024）
2. McKinsey: State of AI 2024 — EBIT 5%以上改善は6%のみ
3. Meta 2026: エンジニアの期待値にAI活用を明記（Zuckerberg社内メモ）