なぜUberは単一モデルを捨てたのか。AI開発で必須となるマルチモデル運用とClaude Codeでの構築術

15,000都市の最適化を1つのAIに任せるのは無理があった

毎日4,000万回の乗車。1,000万人のドライバー。世界70カ国、15,000の都市。

Uberが動かしているこの巨大なリアルタイム・マーケットプレイスの裏側で、変化が起きている。

彼らは特定の巨大なAIモデルにすべてを委ねるのではなく、独自の機械学習エンジンを磨き続けてきた。

今、彼らが選んだ道は「OpenAIのフロンティアモデル」を、特定の業務コンテキストに最適化して組み込むマルチモデル戦略だ。

単一の最強モデルを追い求めるフェーズは終わった。

タスクごとに最適なモデルを使い分け、それをオーケストレーションする技術が開発者の生死を分ける。

これはUberだけの話ではない。AppleもiOSの次期アップデートで「ユーザーがAIモデルを選択できる」仕組みを導入する。

開発者である僕らが、この「モデルの多極化」にどう向き合うか。

最新の海外事例と、僕が愛用しているClaude Codeでの構築術を深掘りする。

Uber Assistantが解決した「認知負荷」という壁

Uberが導入したUber Assistantは、単なるチャットボットではない。

ドライバーが直面する「今、どこで走れば稼げるか？」「なぜ今日の報酬はこの金額なのか？」という問いに、リアルタイムのデータから答えを出す意思決定支援ツールだ。

Uberのマーケットプレイスは、天候、交通状況、イベント、空港の到着便数など、数えきれない変数で構成されている。

これまでのドライバーは、ヒートマップや複雑なデータを自分なりに解釈し、経験と勘で動いていた。

これをUberは「認知負荷」と呼び、AIによってこの負荷を下げることに成功した。

OpenAIのモデルを活用し、複雑なマーケット信号を要約して、自然言語でドライバーに伝える。

新人ドライバーだけでなく、ベテラン勢も繰り返し使っている。

新人の立ち上がりを早めるだけでなく、熟練者のパフォーマンスを引き出す「長期的な実用ツール」として機能している。

Uberは音声機能にもAIを統合し、ドライバーが運転中に手を離さずに情報を取得できる環境を整えた。

Uberは自社の膨大なリアルタイムデータと、外部の強力な言語モデルを「疎結合」させている。

特定のモデルに依存せず、自社のビジネスロジックを優先する。

しんたろー：
15,000都市で規制やユーザー行動が異なる中で、一つのプロンプトですべてを解決するのは無理がある。
Uberは「モデルの性能」を売るのではなく、自社の「ドメイン知識」をAIで使いやすくする設計をしている。
僕もThreadPostの開発で、SNSごとの仕様の差をどうAIに食わせるか悩むが、結局は「データの抽象化レイヤー」をどこまで作り込めるかに行き着く。

Appleが示す「AIの民主化」とモデル選択の自由

Uberが裏側でモデルを最適化する「自動ルーティング型」なら、Appleが目指すのは「ユーザー選択型」のマルチモデルだ。

次期OSのリリースに向けて、AppleはiPhoneユーザーがデバイス上で利用するAIモデルを、複数のサードパーティ製モデルから選択できるようにする計画を進めている。

内部で「Extensions」と呼ばれるこの機能は、Siriやライティングツールなどを通じて、ユーザーがインストールしたアプリの生成AI機能にオンデマンドでアクセスできるようにするものだ。

現在、GoogleやAnthropicのモデルがテストされている。

Appleの戦略は「自社で最強のモデルを作ること」ではなく、「すでに普及しているハードウェアを、AI中心の体験プラットフォームに変えること」だ。

彼らは「モデルのコモディティ化」を前提としたエコシステムを構築している。

ユーザーは、プライバシーを重視するならオンデバイスの軽量モデル、高度な推論が必要ならクラウド上の強力なモデルといった「使い分け」ができるようになる。

開発者にとって、自社のアプリが「どのモデルの拡張機能として選ばれるか」という新しい競争領域が生まれる。

開発者が直面する「オーケストレーター」への転換

UberとApple。アプローチは違えど、共通しているのは「単一モデルへの依存を回避している」点だ。

開発者に求められるスキルは、「特定のプロンプトを極めること」ではない。

タスクの性質に応じてモデルを切り替える「オーケストレーター」としての設計能力だ。

例えば、以下のような判断をリアルタイムで行うロジックが必要になる。

1. 軽量・高速な処理: ユーザー入力のバリデーションや単純な要約なら、安価な小型モデル。
2. 高度な推論: 複雑なビジネスロジックの生成やデータ分析なら、最新のフロンティアモデル。
3. プライバシー重視: 個人情報を含む処理なら、オンデバイスまたは自社VPC内のモデル。

これを実現するためのインフラとして、AWS Bedrockのようなマネージドサービスがある。

Bedrockを使えば、AnthropicのClaudeをはじめとする複数の基盤モデルを、単一のAPI体系で利用できる。

AnthropicのデスクトップアプリであるClaude Desktopのバックエンドに、このBedrockを接続できる仕組みも登場した。

開発者はセキュアなAWS環境を維持したまま、最新のAIモデルをデスクトップから叩ける。

僕がメインで使っているClaude Codeも、こうしたマルチモデル時代における武器だ。

CLIから直接コードを生成・修正できるこのツールは、開発者が「どのモデルを使うか」という低レイヤーの悩みを抽象化してくれる。

「このファイルを修正して」と投げるだけで、裏側で最適な処理が行われ、結果だけが返ってくる。

僕らは「何を開発するか」という本質的な問いに集中できる。

しんたろー：
AWS Bedrock経由でClaudeを使えるのは、エンタープライズ開発だと必須級のアップデートだ。
データの国内保存やセキュリティ要件をクリアしつつ、最新のClaude 3.5 Sonnetを動かせる。
僕も個人開発でBedrockを使っているが、Cost Explorerでモデルごとの料金が丸見えになるのが、精神衛生上すごくいい。

マルチモデル時代の具体的なアクションアイテム

今作っているプロダクトのAI実装を「ハードコードされたAPI呼び出し」から卒業させる準備を始める。

以下の3つのステップを意識する。

1. プロバイダーの抽象化レイヤーを作る

特定のSDKに依存せず、設定一つでモデルを切り替えられるラッパーを挟む。

AWS BedrockやAzure OpenAI Serviceのような、複数のモデルを束ねるプラットフォームを介するのが定石だ。

新しいモデルが登場した際に、コードを書き換えずに性能向上を享受できる。

2. タスクを「推論コスト」で分類する

すべてのリクエストを最強モデルに投げるのは、お金を浪費する行為だ。

「このタスクはClaude 3 Haikuで十分か？」「ここはSonnetじゃないとダメか？」という基準を自分の中に持つ。

Uberのように、ユーザーの「認知負荷」を下げるためだけの要約なら、中間層のモデルで十分なケースが多い。

3. CLIツールを開発フローに組み込む

Claude CodeのようなCLIベースのAIツールを使い倒して、「AIと一緒に開発する」感覚を体に叩き込む。

チャット画面にコードをコピペしている時間は、マルチモデル時代には「無駄なオーバーヘッド」だ。

ターミナルから直接、AIにプロジェクト全体のコンテキストを把握させ、モデルの切り替えすらもAIに提案させる。

このスピード感に慣れておかないと、これからの開発競争にはついていけない。

しんたろー：
AIは「道具」だ。
Uberが15,000都市のデータを武器にしたように、僕らも「自分のプロダクトにしかないデータ」をどうAIに料理させるかに集中する。
モデルの性能差で一喜一憂するフェーズは卒業して、いかに効率よく「使い分けるか」のフェーズに移行する。

FAQ：マルチモデル運用の疑問に答える

Q1: マルチモデル構成にする際、コスト管理はどうすればいいですか？

AWS Bedrockのようなマネージドサービスを利用するのが効率的だ。

BedrockはAWSの請求体系に統合されているため、モデルごとの利用量やコストをCost Explorerで一元管理できる。

各モデルのAPIを直接叩くのではなく、ルーティング層を設けて「安価なモデルで済むタスク」と「高性能モデルが必要なタスク」を明確に分離することで、全体コストを最適化できる。

モデルごとのトークン単価を常に意識し、必要十分な性能を選択する設計が重要だ。

Q2: ユーザーにモデルを選ばせるべきか、自動でルーティングすべきか？

Uberのような業務特化型アプリであれば、ユーザーの認知負荷を下げるために「自動ルーティング」が正解だ。

ユーザーは「タスクを完了させたい」のであって、AIの専門家ではない。

一方、Appleのように汎用的なOSやプラットフォームであれば、ユーザーの好みやプライバシー設定を尊重する「選択型」が適している。

自社プロダクトのターゲットユーザーが「AIの知識を持っているか」「単にタスクを完了させたいだけか」で判断する。

Q3: Claude Codeのようなツールを導入するメリットは？

最大のメリットは、コンテキストの共有速度だ。

従来のチャットUIでは、関連するファイルを一つずつアップロードする必要があったが、Claude Codeはローカルのファイルシステムを直接参照できる。

マルチモデル構成の複雑なルーティングロジックを実装する際も、プロジェクト全体の構造をAIが把握した状態で提案を受けられる。

「モデルを使い分ける」という複雑な作業を、CLIを通じて抽象化・自動化できるのは、開発者にとって大きなアドバンテージだ。

AIモデルの「使い分け」が当たり前になる時代へ

Uberが単一モデルへの依存を捨て、マルチモデルのオーケストレーションへと舵を切ったのは、それがスケールするための道だからだ。

Appleも自社で囲い込むのではなく、エコシステム全体でAIの力を活用する方向に進んでいる。

開発者に求められているのは、最新モデルを追いかけることではなく、それらをどう組み合わせて、ユーザーに価値を届けるかという設計力だ。

AIモデルの使い分けが当たり前になる時代、あなたの開発スタックはマルチモデル対応できているか。

まずはClaude Codeをターミナルにインストールして、次世代の開発体験を肌で感じてみてほしい。

そこから、新しい設計のヒントが見つかるはずだ。

👉 ThreadPostでSNS運用を自動化する