Uber COO、tokenmaxxingに使う金を正当化するのがますます難しくなっていると語る
(businessinsider.com)- UberのCOOは、AI支出が投入コストに見合う成果を出しているのかを正当化するのがますます難しくなっていると見ている
- UberのCTOが2026年のClaude Code予算をすでに使い切ったと明かした後、社内議論が拡大した
- より多くのトークン使用量が有用な消費者向け機能の増加に比例してつながるという結び付きは、まだ確認されていない
- UberのCEOは、AI投資を相殺するためにUberが採用ペースを落としていると明らかにした
- Big Techのtokenmaxxingの流れとは対照的に、Duolingoは従業員の反応を受け、AI利用を人事評価に組み込もうとしていた決定を撤回した
Uber社内におけるAIコスト正当化の問題
- Uberの最高執行責任者 Andrew Macdonald は、社内でAIコストを正当化することがますます難しくなっていると見ている
- 土曜日に公開された Rapid Responseのインタビュー で、AIが会社の支出に見合うだけの効果を生んでいないと述べた
- UberのCTO Praveen Neppalli Naga が4月のThe Informationのインタビューで、Uberが2026年のClaude Code予算をすでに使い切ってしまったと明かした後、社内議論が広がった
- この発言は、Macdonaldが「頭が爆発しそうな瞬間」と表現した状況につながり、社内では AIトークン消費 と人員規模のあいだのトレードオフが議論された
トークン使用量と製品成果の結び付きの欠如
- Macdonaldは、Uberの上級エンジニアリングリーダーたちと話した結果、より多くのトークン使用量が有用な消費者向け機能の比例的な増加につながってはいないと判断した
- 「その結び付きはまだない」という表現で、より多くの機能がリリースされている可能性はあるものの、特定の指標と「今や実際に25%多くの有用な消費者向け機能を作っている」という結論を直接結び付けるのは難しいと見ている
- AI支出は、成果と直接結び付けにくいほど、トレードオフのコストを正当化しにくくなる
- CEO Dara Khosrowshahi は今月初めの決算説明で、UberがAI投資を相殺するために 採用ペースを落としている と明らかにした
ユーザーには無料のように感じられても、企業がコストを負担する
- Macdonaldは、ユーザーが費用を負担せずに「興味深いユースケース」を思い付く立場であれば、AIは無料のように見えるかもしれないと見ている
- しかし最終的には、企業がコストを支払うことになる
- AI利用の拡大は、単なる生産性実験ではなく、予算と人員運用に影響するコスト構造として扱われている
Big Techのtokenmaxxingとは異なる流れ
- Big Techは、AIを可能な限り多く使うtokenmaxxingを強力に推し進めており、一部の企業は従業員のAI利用量を評価に反映している
- Meta, Google, JPMorgan は、AI利用を人事評価、目標、昇給、昇進と結び付ける企業として挙げられている
- 一方で、一部の企業はAI利用そのものを押し進めるやり方から後退し始めている
- Duolingo は、従業員が「AIを使うためにAIを使わなければならないのか」と問いかけたことを受け、AI利用を人事評価に含めようとしていた決定を撤回した
- DuolingoのCEO Luis von Ahn は4月のポッドキャストインタビューで、実際の結果に責任を持たせるというより、場合によっては合わないものを無理に押し付けている感覚だったと述べた
1件のコメント
Hacker Newsの意見
2007〜2009年にGoogleがデータセンターを大幅に拡張していた頃、特に業務時間外には遊休容量がかなりあった
エンジニアなら誰でも優先度0で好きなだけジョブを回せて、より重要なジョブが資源を必要とすると真っ先に停止される仕組みだった
一晩中走るMapReduce実験をよく行っていて、しばらくの間は社内サービスを優先度0で動かし、事実上「無料」のように運用していたこともあった
利用量が増えるにつれてそうしたサービスは次第に不安定になり、最終的には資源利用を正当化するか規模を縮小する必要が出てきたが、それは良い方向だったと思う
AIのトークン利用も似たモデルがよさそうだ。大手テック企業は自前のLLMデータセンターを持ち、社内需要を処理したうえで、業務外の遊休容量を従業員の実験用に開放できる
日常業務ではトークン数そのものよりもトークン効率を奨励すべきだ。毎週、人の労働を何時間も減らす自動化に多くのトークンを使うのは良い使い方だが、手で直せる簡単なフロントエンドのバグをデバッグするのに大量のトークンを使って4時間かかるのは無駄だ
https://developers.openai.com/api/docs/guides/batch
仕様駆動開発のように人間がループの中に入り続けるのではなく、ループの上から確認する方式にはこのアプローチのほうがずっと自然だが、少なくともGoogleのフロントエンドの経験では、まだ十分に対応しているところを見たことがない
今起きていることは、多くの人にとって非常に明白だった。一部の人が意図的に依存させようとして作った新しい依存者に「もう少し慎重に消費しろ」と言っているようなもので、あまり効果は期待できない
AIを使うのは好きではないし、あまり役に立つとも感じていない
それでも会社が利用を強制し、指標を追跡するので、毎日どうでもいい雑用を投げて使っているように見せている
問題を直す以上に問題を増やしていたとしても、指標上はAIを使っている人間になる
どんな会社であれ、トークン消費量を従業員の成果シグナルとして使うと公表したら、その会社は避けるべき危険信号に近いと思う
優れたエンジニアリングリーダーシップを持つ会社なら、これをまともなアイデアのように扱うべきではない
なのにAIトークンを500ドル分、非生産的に使うと、最上位のAI導入者として認められるのだと、会社で皮肉交じりに言われることがある
ある会社では開発者に「もうコードを1行も自分で書かないでほしい」とまで言っている
経営陣の視点はおそらくこうだろう。上位20%の社員がLLMでコードの80%を作り、会社がなお回るなら、下位80%の開発者を減らしてコストを節約できる、という発想だ
従業員評価にトークン使用量を使うのは、その一例にすぎない
空の巨大な核融合炉の下に、まったく新しいものはあまりない
James Gleickの『The Information』で、電信業界におけるトークンマキシングのような話を読んだ
電報は1文字ごとに課金されたため、送信文字数を減らすコードブック市場が大きかった。圧縮はそのまま金であり、電信会社はこれを嫌ったが受け入れるしかなかった
電信コード産業は電信の商用化初期から始まり、1920年代まで続いた
ただしコストもあった。コードは冗長性を大きく削り、ごく小さな誤りが大きな誤解につながった
Gleickの説明によれば、これはアフリカの太鼓演奏がリズムと、太鼓が模倣する言語との関係を強めるために冗長性を加えるやり方と正反対だった
つまり燃やしたトークン数やコストが最大の人が勝つのであって、機能を納品したプログラマー基準ではない
説明されているのはトークン最大化ではなく、トークン最小化に近い
LLM以前からソフトウェアスタックについてずっと気になっていたことだが、今はさらに関係が深そうに見える。
Uberのような会社はいつ「完成」するのだろうか。16年間ソフトウェアを作り続けてきた。
ドライバーと乗客をマッチングする会社であり、ソフトウェアをさらに作ったからといって、自分がバスや電車の代わりにUberを選ぶ可能性が大きく上がるわけではない。
20年後にはソフトウェアは終わるのだろうか。80年後だろうか。
変わり続ける規制環境や新製品も無視できない。Uber Eatsがいつ登場したかを見ればいい。
その16年の間にCovid-19が起き、実用的な自動運転やWaymoとの提携も生まれた。
ネットワークでつながった一般消費者向けアプリは、完璧な予知能力でもない限り決して「完成」しない。
内部技術スタックは生きた生物のようなもので、見た目には変わらないサービスを維持するだけでも非常に多くの作業がある。スケールも大変で、スケールと保守は互いを増幅し続ける。
各国にはUberにできることとできないことについてそれぞれ法律があり、それをコードとして形式化しなければならない。
たとえば、ある地域ではUberアプリを通じて実際にはタクシーを呼んでおり、料金も事前確定額ではなくマイル単位の計算かもしれない。
そこに都市ごとの法律まで加わる。法律が異なるA町からB町へUberで移動する場合はどうすべきか。弁護士は答えを知っているだろうが、アプリはそれに従わなければならない。
しかも法律は絶えず変わる。
最適化にも終わりはない。速度、コスト、ルートなど、常に改善対象がある。
消費者として触れている部分は、そのようなサービスが構築・運用しなければならない複雑さのごく一部にすぎないと思う。
ほぼ常に直すべきバグもある。本当にたくさんのバグがある。
これは巨額の投資を受けた会社の問題でもある。Uberの価値は、今やっている事業そのものよりも、自家用車の所有や公共交通機関の利用といった概念を時代遅れにするだろうという期待に基づいている。
誇張ではあるが、それでも思ったほど誇張でもない。
トークンマキシングは筋が通らない。できるだけ多くの計算、メモリ、入出力を使おうとして非効率なSQL/Sparkジョブを書くのに近い。
デカルト積や極端に偏ったデータセットのようなものを、わざわざ大量に入れるようなものだ。
指標が目標になると、こういうことはいつも起きる。会社はAIを可能な限り効率的に使う環境を育てるべきで、まず「この仕事に本当にエージェントが必要なのか」と問うべきだ。
必要なら、どのエージェント、どのモデル、どの推論レベルが必要かを決めるべきだ。
トークン節約、キャッシュヒット率の向上、より少ないコンテキストで情報を使えるようにする情報構造化も奨励すべきだ。ナレッジグラフはここでかなり有効だ。
レースに勝つためにガソリンスタンドに火をつけるようなものだ。
すべての従業員が新技術を試すよう促す、あるいは強制する手段にすぎない。
全員がAIを活用していると判断されれば、トークンマキシングのようなものは当然終わるだろう。
価値を生んでいるのか疑わしいユースケースも多く見たが、コスト審査委員会の前では正当化が難しかったであろうエージェント型ワークフローで長年の問題を解決したチームも見てきた。
トークン節約、キャッシュヒット率向上、少ないコンテキスト利用のための情報構造化作業は、大規模なトークンマキシング企業の多くで裏側に別チームが担っている、という理解だ。
企業がAI支援開発に資金を投じるのは分かる。だが全体の投資収益率はどうなのだろうか。主張される効率向上に見合う価値はあったのだろうか。
AIブームで本当に興味深い点はここだけなのに、なぜ誰も話さないのか分からない。
Claudeで1日に役に立たない、あるいは悪い機能を5つ作ることもできるし、2日で有用な機能を1つ作ることもできる。どちらが投資収益率により良い影響を与えるだろうか。
例だけ見ると簡単な答えに思えるが、現実ははるかに微妙で、測定もずっと難しい。
だから多くの企業は測定を諦め、誇大宣伝に乗るという単純な選択をしているように見える。
コードレビューまで含めて適切に運用した場合、AI利用による持続可能な最大改善幅は、適切な熟練度を持つシニアエンジニア基準でおおよそ**20%**だと確信している。
どのエンジニアのトークン予算もそれ以上であるべきではない。
トークンマキシングをしているエンジニアが本当に生産的だとは思わないし、その証拠もまったく見ていない。むしろ逆に近いかもしれない。
正しいフローとコードベースの知識があれば、持続可能な努力レベルでそれくらいは可能だと自分で実感した。
エンジニアリング生産性のためのAIは、同じ結果をより速く安く出す魔法のボタンだと広く誤解されているように見える。
その論理なら、従業員にトークンマキシングを強制したくなるのも当然だ。より多くの結果をより速く安く得られるなら、なぜやらないのかという話になる。
もっと微妙に見ると、実態はこうだ。AIはロードマップ達成をある程度早めてくれるが、臨時の開発者を雇って機能を作ったのと似た技術的負債を生む。
チーム内に新しいコードを理解している人が必ずしも生まれるわけではない。
同様に、ジュニアメンバーの熟練度向上も起こりにくくなる。以前ほど熟練度と賃金差の裁定を得にくくなる。
製品も複雑化しうる。P2機能がP2であるのには理由があり、AIのせいで限界利益の低い機能まで含まれ、製品を複雑にしてしまう可能性がある。
トークンマキシングが良い考えだと信じた人がいたこと自体が衝撃的だ。
AIマキシマリストはこの技術を電気になぞらえがちだ。電化の初期に、CEOが従業員に事業成果につながる電気の使い方を見つけさせる代わりに、電力消費量の増加に報酬を与えたと想像してみればいい。
当時は精神疾患の兆候を示す人を施設に収容することがよくあり、たぶんそういう結末になっていただろう。