AIが本当に成果を上げたか誰も知らない、利用量ではなく産出を測る道具

どんな問題か

会社はAIを使えと迫り、その成果を利用量で測る。席が何個、プロンプトが何回、コード提案の受け入れ率が何パーセント。問題は、利用量が産出ではないことだ。たくさん使ったからといって仕事が良くなった保証はなく、強制がかかれば利用量の指標はいちばん埋めやすいところで水増しされる。管理者はダッシュボードの青い線が伸びるのを見て順調だと信じるが、肝心のチームの成果物が以前より良くなったかは分からない。

証拠はこの錯覚をまっすぐ指す。役員約6,000人を調べたNBERの調査では、8割超の企業がAIの明確な生産性への影響を感じなかった。開発側のテレメトリはもっと厳しい。パロスAIが開発者2万2千人を2年追ったところ、75%がAIツールを使うのに大半の組織で成果改善が測定されず、処理量は66%伸びたが、事故やバグはそれより速く増えた。マージ済みPR1件あたりの本番障害の確率は1年で3倍を超え、開発者あたりのバグは54%増えた。利用量は上がるのに品質は下がる区間が実在する。管理者はその只中で目隠しのまま判断している。

なぜ今か

いま二つの流れが重なる。一つはAI義務化が主流になったこと。上から利用を強いる会社が増えるほど、利用量ではなく本当の効果を測ることへの渇きも増す。もう一つは既存ツールの死角だ。エンジニアリングにはすでに測定がある。パロスAIやDXのDX Core 4が、gitやPRのテレメトリから処理量と品質を拾う。だが二つが空いている。第一に、これらのツールも多くは依然として利用量と処理量を報告し、ある人がAIのおかげで本当に良くなったかを因果的に切り分けるのは苦手だ。第二に、営業・サポート・運用・マーケティング・法務のようにgitログのない知識労働には、対応する道具がほとんどない。義務化はその全職種にかかるのに、測定は開発チームで止まっている。

flowchart LR
  A[導入前のベースライン<br/>個人ごとの産出と品質] --> C[因果測定<br/>ホールドアウト・段階的展開]
  B[AI利用後の産出<br/>速度・手戻り・エラー率] --> C
  C --> D[個人ごとの実際の改善<br/>品質補正した差分]
  D --> E[管理者向けの正直な信号<br/>利用量ではなく産出]

どう作るか

産出が目に見える一つの職種から狭く始める。カスタマーサポートなら、解決までの時間、再問い合わせ率、品質評価スコアが産出になる。要は三つだ。第一に、導入前のベースラインを人ごとに残す。第二に、因果的に測る。誰かは先にAIを入れ、誰かは後に入れる段階的展開や、ホールドアウト集団を使い、相関ではなく実際の改善分を取り出す。第三に、品質で補正する。速くなっても手戻りやエラーや障害が増えたなら、その損失を産出から差し引く。そうして出た人ごとの差分を、管理者に静かに渡す。監視ではなくコーチングの信号として使われるよう、アクセス権と表示の仕方を狭めるべきだ。

収益はチーム単位や席単位のサブスクが自然だ。導入初期の抵抗を下げるには、初日から人を序列化しない。どの作業種別でAIが実際に効き、どこで空回りするかを、まずチーム単位の地図にして見せる。個人ランキングは信頼が積み上がった後でいい。

成功の条件

二つの条件が要る。第一に、ゲーミングに強く品質で補正した産出指標を、職種ごとに定義できること。指標がもろければ、この道具も結局もう一つの利用量ダッシュボードに堕ちる。第二に、組織が「この義務化は効かなかった」という正直な信号を受け入れられること。AI導入を推した経営陣に効果なしを突きつけるのは政治的に気まずく、その気まずさに耐える文化がなければ道具は引き出しに入る。この二つを越えたチームは、利用量ゲームを取り除き、AIがどこで本当に仕事を良くするかに初めて値をつける。次の問いは一つだ。うちのチームで、AIが実際に良くした作業は、いま何個あるか。