これにより採用判断の式が変わる。新機能や改修のために毎回エンジニアを増やすのではなく、AIコーディングエージェント、開発者向けツール、自動化、計算資源で一部の開発余力をつくる。コスロシャヒは、長期的には追加のエンジニア人員の一部をAIエージェントとGPUで置き換える可能性にも触れているが、現時点で報じられている実態は人間をループに残す運用だ 。
変化は、単なるオートコンプリートから、AIが作業単位を持って開発に参加する段階へ進んでいる。CTOのプラビーン・ネッパリ・ナガは、UberがAIコーディングに大きく踏み込み、エンジニアの95%が毎月AIツールを利用し、社内AIエージェントが週に約1,800件のコード変更を行っていると述べた 。
この取り組みはコードの下書きにとどまらない。DPE.orgに掲載されたUberの開発者生産性に関するセッション概要では、ソフトウェア開発ライフサイクル全体を対象に、巨大なモノレポを理解するコーディング支援のカスタマイズ、大規模コード移行向けのエージェント型システム、AIを使ったテストやコードレビューのワークフローが挙げられている 。
ただし、最終的な制御点はレビューにある。コスロシャヒは、AI生成コードはリポジトリに追加される前に社員がチェックすると説明している 。Uberが使っているのは、作業を作り、準備するエージェントであって、無監督で本番開発を任せる仕組みとしては語られていない。
数字が多いほど誤解も起きやすい。コスロシャヒの10%は、自律エージェントが生み出したコード変更の割合を指す 。
一方、The Pragmatic Engineerは、Uberの開発者の84%がエージェント型コーディングの利用者だと報じた。これはCLI型エージェントを使っているか、IDE内で単純なタブ補完よりも自律的な依頼を多く行っている開発者を指す 。同じ報告では、IDEベースのツール内で生成されたコードの65〜72%がAI生成だったともされている 。
つまり、これらは同じものさしではない。自律エージェントによるコード変更、エージェント型ワークフローの利用率、IDE内でAIが下書きしたコード量を別々に見ている。実務上の読み方は、AIがコード作成を助ける範囲はかなり広い可能性がある一方で、最終的に取り込まれる変更のうち自律エージェント由来として数えられる割合は別の指標だ、ということになる 。
AIで既存エンジニアの生産量が増えるなら、開発能力を伸ばしても人員を同じペースで増やす必要は薄れる。UberがAI投資を増やしながら採用を抑えている背景には、この経済計算がある 。
ただし節約だけではない。コストの一部は、人件費からAIツール、エージェント、計算資源へ移る。報道によれば、Claude Codeの利用急増で、Uberは2026年分のAIコーディング予算を想定より早く使い切り、Claude CodeやCursorといったツールを使っている 。この話だけでAI投資全体の採算を判断することはできないが、ソフトウェア開発能力が「人、エージェント、ツール、インフラ」の組み合わせとして計画されつつあることは示している。
UberのAI戦略はエンジニアリングだけではない。コスロシャヒは、同社がライドシェアの価格設定や、ドライバーと乗客のマッチングに何年もAIを使ってきたと述べている 。
最近の報道では、生成AIとエージェント型AIは、カスタマーサポート、ドライバーのオンボーディング、エンジニアリング開発ライフサイクルの一部にも適用され、一部のワークフローで人手による介入を減らしているとされる 。
これは採用抑制との関係でも重要だ。サポート対応を早める、オンボーディングを簡素化する、社内サービスの問題診断を助けるといった効果が出れば、以前なら人員増で解消していたボトルネックを、同じ人数またはより少ない追加人員で処理できる可能性がある 。
現時点のUberの姿は、「エンジニア不要」ではなく「監督付きAI開発」に近い。エージェントはコードの下書き、変更案の準備、移行作業、テストやレビュー支援を担うが、AIが書いたコードは人間が確認してから取り込む 。
影響が大きいのは、既存職の即時削減よりも、追加採用の伸び方だろう。AIツールが実際の開発フローで安定した効果を出し続けるなら、Uberは以前なら採用で補っていた開発能力の一部を、エージェントやツールでまかなえる 。
ただし、AIツールの利用率やAI生成コードの比率は、品質、信頼性、保守性、長期的な開発コストまで含めた正確な生産性向上を、そのまま証明する数字ではない。Uberの事例が示しているのは、AIが開発組織の人数計画に入り込み始めたことと、その運用がまだ人間の判断に強く依存していることだ。