ハクソク

世界を動かす技術を、日本語で。

ウーバーのCOOが、トークンマキシングにかかる費用の正当化が難しくなっていると述べる

13時間前原文(businessinsider.com)

概要

  • Uberの幹部がAI投資の費用対効果に疑問を表明
  • AIトークン消費増加と消費者向け機能増加の関連性の薄さ
  • AI投資による人員削減などのトレードオフ
  • Duolingoなど他社もAI利用評価の見直し傾向
  • AI投資が企業経営に与える影響の再検討の動き

Uber幹部、AI投資の正当性に疑問

  • UberのCOO、Andrew Macdonald によるAI投資の費用対効果への懸念表明
  • AI関連コストの正当化が困難 との発言
  • CTO Praveen Neppalli Naga が「Claude Code予算2026年分をすでに消化」と発言し、社内議論が活発化
  • AIトークン消費増加 が 有用な消費者向け機能の増加と直結しない 状況
    • シニアエンジニアと協議した結果、 「直接的な相関が見られない」 との認識
  • AI投資によるコスト増加 と 人員削減などのトレードオフ が発生
  • CEO Dara Khosrowshahi が AI投資に伴い採用ペースを抑制 と発言

AI利用の現場と評価の見直し

  • AIは利用者には無料に見えても、企業が最終的な費用を負担
  • Big Tech各社はAI利用を最大化（tokenmaxxing） し、従業員評価にもAI利用を反映
  • Duolingo では AI利用を評価指標に含める方針を撤回
    • 従業員から「AI利用自体が目的化している」との声
    • CEO Luis von Ahn が「成果でなくAI利用自体を推進していた」と認める

AI投資の再考と今後の動向

  • AI投資の直接的な成果が不明確 なため、 コスト対効果の見直し が進行
  • 企業経営におけるAI活用の在り方 が再検討される流れ
    • 投資判断の透明性 や 実際の成果へのリンク強化 が今後の課題
  • AI利用の目的化 から 実質的な価値創出重視 への転換が求められる

Hackerたちの意見

もしどこかの会社が、トークン消費を従業員のパフォーマンスの指標として使うって発表したら、俺にとってはその会社から離れた方がいいっていう赤信号に近いね。良いエンジニアリングリーダーシップを持つ会社が、こんなことを良いアイデアだと思うはずがない。

└

トークンは新しい「エンジニアあたりのコード行数」だね。グラフにしやすいし、管理もしやすい。

└

先月、これをやってるYCの会社で働いてたけど、どこから始まったのか気になる。VCやテックエグゼクティブって、ほんとモノカルチャーだよね。

└

メタもそういうことやってるよ。最近のレイオフの基準の一つが何か、想像つく？

└

驚くかもしれないけど、すごく大きなテック企業にいる開発者を何人か知ってるよ。FAANGじゃないけど、みんな知ってる企業だよ。彼らはトークンのリーダーボードを持っていて、「もう手動でコードを書くな」って言われた開発者もいるんだ。経営者たちの視点は、上位20%の労働者がLLMを使って80%のコードを生産して、会社がまだ機能しているなら、下位80%の開発者を排除してコストを削減できるって感じなんだろうね。

└

2022年から2025年までUberで働いてたけど、エンジニアリング文化はかなりひどかったから、納得だね。

└

仕事でちょっと皮肉っぽく言ったんだけど、出張で食事手当を$100オーバーしたら、マネージャーか経理と嫌な話し合いをしなきゃいけない。でも、$500分のAIトークンを無駄に使ったら、トップのAI導入者として認められるんだよね。

もっと高いモデルを使わない方がいいんじゃない？AIは道具として使うべきで、願いをかなえてくれるブラックボックスじゃないんだから。

└

次のリストラに入りたいってこと？

└

企業はAIが魔法のランプの精じゃないって、やっと気づき始めてると思う。あくまで道具なんだよね。すごく価値はあるけど、ツールの能力に合った戦略を持たないと。単に「魔法のランプをこすって利益を80%増やす」みたいな戦略じゃダメだよ。もし市場が「ランプをこする」戦略を取ってる企業を評価してるなら、株価を上げるためにそう言うだろうね。市場が、ほとんど戦略もなしにLLMに何十億も無駄遣いするのが良くないってやっと気づき始めたのかも。誰にもわからないけど。

└

でも、経営者たちは高価な労働コストを置き換えるために、最高のモデルが必要なんだよね。

トークンマキシングは意味がないよ。極端に非効率なSQLやSparkジョブを書くのと同じで、カーテシアン結合や超偏ったデータセットを使って、計算やメモリ、IOをできるだけ使おうとするだけ。指標が目標になるとこういうことが起きる。企業はAIをできるだけ効率的に使う環境を育てるべきで、「本当にエージェントが必要か？」ってまず考えるべきだし、必要ならどんなエージェントが必要か、どのモデル、推論レベルが必要かを考えるべき。トークンを節約したり、キャッシュヒットを増やしたり、できるだけ少ないコンテキストで情報をコーディファイするプロジェクトも推進すべきだね（知識のグラフはこれに結構いいよ！）。

└

幼児レベルの論理だよ。「Xを使えばポジティブな結果が得られる。だから、ポジティブな結果を最大化するためにXをできるだけ使う必要がある。」ガソリンスタンドに火をつけてレースに勝とうとしてるみたい。

└

「トークンマキシング」を支持する理由は、従業員がAIを活用したワークフローの広く新しい領域を自由に探求できるスペースを作ることだって言われてるよね。価値が生まれてるか疑問に思うユースケースもいくつか見たけど、他のチームがエージェントワークフローで長年の問題を解決した例もある。> 「トークンを節約することを目指すプロジェクト」や「キャッシュヒットを増やす」こと、できるだけ少ないコンテキストで情報をコーディファイすること（知識のグラフはこれに結構良い！）を推進すべきだと思う。私の理解では、大きな「トークンマキシング」企業のほとんどには、こういうことを裏で進めてるチームがいるみたい。

└

トークンマキシングが存在するのは、経営者が従業員が変化に抵抗していると思っているからだよ。それだけ。全ての従業員に新しい技術を試させるためのインセンティブを与える方法なんだ。みんながAIを使っていると思ったら、トークンマキシングの話は終わるだろうね。

LLMが出る前からソフトウェアスタックについていつも考えてたけど、今はなんかもっと関連性がある気がする。Uber（またはお気に入りの会社）はいつ「完成」するの？彼らは16年間ソフトウェアを書いてる。ドライバーと乗客をマッチングしてるけど、もっとソフトウェアを増やしたからって、バスや電車じゃなくて彼らを選ぶ確率が上がるわけじゃないよね。彼らのソフトウェアは20年後に完成するの？80年後？

└

コードベースの大部分は、ローカル市場向けのカスタム統合なんだよね。いくつかはシステム化できるけど、ほとんどの複雑さはそこから来てる。

└

常に新しい技術や手法を導入する余地があるよね。より良いアルゴリズム、大規模な展開、信頼性の向上。バグもほぼ常に修正しなきゃいけないし、ほんとにバグが多い。

└

彼ら、自社の自動運転をやろうとしてなかったっけ？重い投資を受けた企業には、こういう問題があると思う。ウーバーの価値は、彼らがやってることに基づいてるんじゃなくて、自分の車を持ったり公共交通機関を使うことが時代遅れになるっていうアイデアに基づいてるんだよね（誇張だけど、実際そうなる可能性はある）。

└

国際的なオペレーションや最適化がどれだけ複雑か、見落としてると思うよ。各国にはウーバーが何をしていいか悪いかの法律があるから、それをコードに正式に落とし込む必要がある。例えば、ウーバーのアプリを使ってタクシーを呼ぶと、支払う金額はマイル単位で、事前に決まった固定料金じゃないんだ。さらに複雑なのは、都市ごとに独自の法律があること。町Aから町Bにウーバーで移動したら、法律が違ったらどうなるの？弁護士なら答えがあるかもしれないけど、アプリはそれに従わなきゃいけない。しかも法律は常に変わるし。最適化は、何かを常に最適化できるから、スピード、コスト、ルートなど、終わりがない感じだよね。消費者として私たちが接する部分は、そのサービスが構築・運営しなきゃいけない複雑さのほんの一部に過ぎないと思う。

└

ウーバーは十分な規模があるから、この分析は通用しないよ。私たちが「Eats for the Way」っていう、ウーバーブラックの乗客が自分のスターバックスのコーヒーを指定できる機能に対して、ちょっとも興味ないでしょ（https://www.uber.com/us/en/newsroom/go-get-2026/）。でも、もし0.01%のユーザーがこれのおかげで月に1回追加で乗車するなら、年間で約20万回の乗車になる。それが開発コストを正当化するのに十分かもしれないね。

└

新しいツールがたくさん出てきたけど、みんな同じ古い問題にしか使いたがらないよね。CRUDアプリの開発をもっと革新するにはどうすればいいんだろう？それがしばらくの間、ウェブ開発の世界を悩ませてたんだ。常に新しい手抜きの方法を探して、同じ古い製品を作り続ける。魅力はあるけど、もし企業が開発の手間や労力に縛られなくなったら、自分たちの失敗の原因をただ考えるだけになっちゃうよ。

└

いつも新しい書き直しが待ってるよ。

└

まあ、維持管理のコストはかなりかかるからね。マッチングの面ではまだ少しの改善の余地があるかもしれないし、新しい製品も出す必要がある。だから、特定のソフトウェアがほぼ完成しても、企業全体のソフトウェアは常に変わっているんだ。

└

Uber（またはあなたのお気に入りの会社）はいつ「終わる」の？彼らは16年間ソフトウェアを書いているけど、ブラウザやAndroid、iOSが16年以上も凍結されていると、たぶん楽になるんじゃないかな。規制の変化や新製品のことは気にしないで（Uber Eatsはいつ始まった？）。その16年間の間に、Covid-19が出現したし、自動運転やWaymoとの提携も実現した。ネットワーク化された人向けアプリは、完璧な予知がない限り「終わる」ことはないよ。内部の技術スタックは生きているものだから、外見上変わらないサービスを維持するのは大変な作業なんだ！スケーリングは本当に大変だよ！スケーリングサービスとメンテナンスはお互いに影響し合うからね。

└

テック企業が「完了」するのは死を意味するから、成長がなくなるってことだよね。だから、彼らは崩壊するか吸収されるまで無限に膨張し続けるんだ。それがVC資金で成り立つスタートアップの運命だよ。

空にある巨大な融合炉の下では、新しいことはあまりないよ。最近、ジェームズ・グリックの「情報」という本の中で、電信業界のトークンマキシングについての章を読んだんだ。昔は、電報の文字数料金を減らすためのコードブックが大きな市場を持っていた。圧縮はお金になるからね。電信会社はそのやり方を嫌がったけど、受け入れざるを得なかった。電信コード業界は電信の商業化が始まった時から1920年代まで続いたけど、その代償もあった。コードは冗長性を大幅に減らして、ほんの小さなエラーから大きな誤解を生んだ。グリックが説明するように、これはアフリカのドラムのリズムと模倣する言語の関係を強化するために冗長性を加えるという慣習とは逆のことなんだ。

└

面白いけど、トークンマキシングはトークン使用の「効率」を最大化しているわけじゃないよ。単にその使用を最大化しているだけ。

└

それってトークンマキシングの真逆じゃない？むしろ、電信の例えで言うと、電信オペレーターがどれだけ毎日電信回線を占有したかでランク付けされる（トークン消費が多いほど勝ち）って感じで、顧客にサービスを提供した数（機能を提供するプログラマー）で評価されるわけじゃない。君が言ってるのは、トークンを最小化することだよ、マキシングじゃなくて。

エンジニアリングの生産性向上のためのAIは、同じ結果をより早く、安く生み出す魔法のボタンだと誤解されがちだよね。だから、従業員にトークンマキシングを強要したくなるのも分かるけど、もっと早く安く結果を得たいなら、そうしない理由がないからね。でも、もっと微妙な見方をすると、* AIはあなたのロードマップを少し早く達成させるけど、* 一時的に開発者を雇った時と同じような技術的負債が発生する。新しいコードを理解しているメンバーがチームにいるとは限らないし、* 同様に、ジュニアメンバーのスキルアップもできない。だから、以前ほどスキルや賃金のアービトラージが得られない。* 製品が複雑になる。P2機能はP2である理由があるけど、AIがそれを含めることで、低い限界利益のために製品が複雑になることもある。

制限は有益だよね。単なる一時的なものじゃなくて、デザインの一部として扱うべきだと思う。何かが豊富にあると、人はそれを無駄にしがちだから。自分は基本的なサブスクリプションに満足してるよ。Claude CodeとCodexの月額サブ、あとクラウドストレージプランからの論理的なアップグレードとして年額のGoogle AI Proアカウントも持ってる。AI機能のために月に10ドルくらいの追加料金だったかな。週の間はそれらをうまく使い回して、トークンを管理し、セッションやコンテキストをできるだけ早くクリアにして、使い方に気をつけてる。正直、あの超高額なマックスサブスクリプションの魅力がわからない。数年前に子供たちのために買った飛ぶオーブのおもちゃを思い出すよ。バッテリーは10分くらいしか持たなくて、動いてる間は子供たちが大騒ぎしてた。その後は30分の充電が必要で、自然なクールダウン期間ができたんだ。実際、それはいい機能だと思ってた。ずっと動いてるなんて、絶対に嫌だな。

2007年から2009年頃のGoogleを思い出すな。Googleがデータセンターを大規模に拡張してた時、特にオフピークの時間帯には使われていない容量がたくさんあった。エンジニアは優先度ゼロで好きなだけジョブを走らせられたから、もっと重要なタスクがリソースを必要としたら、そのジョブは真っ先に殺されることになる。夜間に実行されるMapReduceを使った面白い実験をたくさんしたよ。しばらくの間は、優先度0で走らせてたから、基本的に「無料」の内部サービスを作ってた。時間が経つにつれて、全体の使用量が増えてきたから、そのサービスはだんだん信頼性が低くなっていったけど、それは良いことだったと思う。AIトークンの使用に関しても似たようなモデルが良いと思う。大手テック企業は自社のニーズを満たすために、自分たちのLLMデータセンターを持つべきだし、従業員がオフピークの容量を使って実験できるようにすべきだよ。実験以外では、日常のタスクに対してトークンの効率を促進するべきだと思う。特定のトークン数を持つのではなく、エンジニアは実際にどれだけの成果を上げたかで評価されるべきだよ。毎週数時間の人間の労働を自動化するために多くのトークンを使うのは良い使い方だし、奨励されるべきだと思う。でも、簡単なフロントエンドのバグをデバッグするために多くのトークンを使って、手で直せたのに4時間もかかったら、それはトークンの無駄だから、やめた方がいいよね。

└

「簡単なフロントエンドのバグをデバッグするために多くのトークンを使って、手で直せたのに4時間もかかったら、それはトークンの無駄だから、やめた方がいいよね。」ハハハ、頑張って！今起きてることは、私たちの多くにとっては超明白だったよ。新しくできたクラック中毒者（中毒になってほしいと思ってた）に、消費をもっと考えろって言っても、うまくいかないよね。

トークンマキシングが良いアイデアだと思った人がいるなんて、驚きだよ。AIマキシマリストはこの技術を電気に例えるのが好きだけど、電化の初期にCEOがスタッフにビジネスに影響を与える方法を見つけるのではなく、消費量を増やすことを奨励していたらどうなっていたか想像してみて。あの頃は精神的な病の兆候を示す人を制度化するのが流行ってたから、そんな結果になってたんじゃないかな。

本当に不思議なんだけど、なんで従業員一人あたり月$100の上限を設けないんだろう。それで80%の人には十分だと思うんだけど。