月5万ドルを燃やすエンジニアが無駄なのか、誰も答えられない

月に五万ドルを燃やしたそのエンジニアを、どうするのか

Ripplingでは一人のエンジニアが1か月にトークンで5万ドルを使った。会社全体ではAIトークン支出が毎月80%ずつ膨らみ、R&D人件費予算の40%を燃やす軌道に乗り、ピークの月には6,050億トークンが流れた。社員の10~15%が全体支出の60%を生んでいた（TechCrunch）。

ここで難しいのは支出を減らすことではない。5万ドルを使ったそのエンジニアをどうするか決めることだ。無駄なら止めるべきで、見合う成果物が出ているなら逆に、他の社員をその人のように使わせるべきだ。支出ランキングだけでは二つのケースは区別できないのに、ランキング以外に何も持っていない会社がほとんどである。

Ripplingはこの問いに答えるため社内ツールを作り、それをAI Spend Consoleという製品として出した（Rippling）。社員・チーム・職務単位の支出に、GitHubやSalesforceといった業務システムのシグナルを結合する。プルリクエスト数、コードベロシティ、コードレビューで手戻りを求められる頻度、貢献した売上までだ（Business Wire）。結果が興味深い。統制後のRipplingの7月のトークン使用量は6,000億個とピークに近いのに、コストは4月の37%だった。利用を減らしたのではなく、無駄だけを取り除いたということだ。

一社が自分の痛みから作った道具は、そのままカテゴリーの存在証明になる。ただしRipplingの製品は自社のHRスイートに結び付いていて、重心は支出統制側にある。帰属測定そのものを売る中立レイヤーの席は空いている。

定額制ではこの問い自体が成り立たなかった

昨年まではこの測定はそもそも成立しなかった。シートあたり定額の下では全社員のAIコストが同じで、個人別に見る理由がなかった。従量課金へ移ったことで同じ職務の中でも個人間の支出が数十倍に開き、そこで初めて「この差は成果物の差につながっているのか」という問いが成り立つようになった。

第一波の対応はすでに過ぎた。予算上限、低価格モデルへのルーティング、チーム別の枠。統制の道具は出そろい、導入も進んだ。統制が済むと次の問いがすぐ来る。残した支出のうち、どれを守り、どれを育てるのか。Ripplingの順序がまさにそうだった。先に止め、その後で測定ツールを作った。

成果物データが結合可能な形で貯まっているという条件も整った。エンジニアリング組織はプルリクエスト、サイクルタイム、レビュー手戻り率が全部APIで取れ、営業組織はCRMにパイプラインが残る。支出ログと成果物ログがそれぞれ存在するのに、両者をつなぐ結合が一つ欠けている状態。欠けている結合は製品になる。

支出ログと成果ログをつなぐ、たった一つの結合

flowchart LR
  A[ゲートウェイ・SSO<br/>利用ログ] --> C[帰属エンジン]
  B[GitHub・Jira・CRM<br/>成果物シグナル] --> C
  C --> D[チーム・コホート<br/>ROIビュー]
  D --> E[もっと使う場所と<br/>削る場所]
  E --> F[上位ユーザーの<br/>パターンを社内展開]

収集レイヤーは新設不要だ。多くの会社がすでにLLMゲートウェイやプロキシで呼び出しを束ねているから、そのログから身元・モデル・トークンを受け取り、GitHub・Jira・CRMは既存APIでつなぐ。難しいのは配管ではなく比較設計である。同じ職務、近い年次のコホートを組み、AI利用の強度によって成果物がどう違うかを見せること。個人ランキングから出すと監視ツールと読まれ、現場がデータを汚し始める。チームとコホート単位が初期値で、個人のドリルダウンは権限の後ろに置く。

第二層がこの製品の本当の差別化だ。成果物あたりの支出効率が良い上位ユーザーがどのモデルをどの作業に使っているかのパターンを抽出し、残りの組織へ展開できるプレイブックに変える。ここまで来ると買い手が変わる。コスト削減はCFOの関心事だが、人にどう働いてもらうかはCTOとピープル組織の関心事だ。FinOpsツールとピープルアナリティクスの間の空白がこの製品のポジションで、特定のHRISに縛られない中立性がRippling相手の防衛線になる。稟議で説明しやすい「測って初めて投資判断ができる」という筋は、AI投資の説明責任を問われ始めた日本企業でむしろ通りやすい。

相関を因果のように売れば、最初のデータレビューで崩れる

最も危険な仮定は、支出と成果物の相関を因果のように売れるという錯覚だ。もともと優秀なエンジニアがAIも多く使っているだけなら、この道具の推薦は最初の本気のデータレビューで崩れる。コホート設計を保守的に組み、断定の代わりに「このチームのこの期間でこの差が観測される」までしか言わない節度が、製品の信頼のすべてである。

二つ目はグッドハートの法則。プルリクエスト数が評価に入った瞬間、プルリクエストは細かく刻まれ始める。手戻り率、サイクルタイム、インシデント率のようにゲーム化しにくい指標を混ぜ、指標構成を定期的に入れ替える必要がある。最後は拡張の順序だ。成果物が測れるエンジニアリングから始めるべきで、測定が曖昧な職種へ急いで広げると数字の信頼が全体で崩れる。Ripplingの40%という数字が一社の事故だったのか、来年の全員の初期値になるのか。その答えがこの市場の大きさを決める。