UberとSpotifyに学ぶ企業のトークン・モデル管理
この記事で学べること
- Uberの事例に見る、AIモデルの一元管理と実際の業務に基づく評価
- Spotifyの事例に見る、大量の読み取り処理の分離と、AIに渡す情報の絞り込み
- Grabを含む3社の共通点と、企業での運用に必要な6つの管理項目
- トークン単価だけでなく、「品質基準を満たして完了した仕事あたりの費用」で判断する理由
生成AIの費用を左右する、仕事の進め方と情報の渡し方
生成AIの費用を抑えるには、モデルの単価だけでなく、仕事の進め方を見直す必要があります。安いモデルに替えても、回答の間違いや作業のやり直しが増えれば、仕事を終えるまでの費用はかえって高くなることがあるためです。
費用が増える原因は、プロンプト（AIへの指示文）の長さだけではありません。情報を何度も探し直す、使わないツールの説明を毎回渡す、失敗した処理を繰り返す、といった動作にもトークン（AIが処理する情報量の単位）を使います。品質を評価しないまま出力を増やしても、費用に見合う成果が得られたかは分かりません。
そこで必要になるのが、仕事の内容に合わせて、AIに渡すコンテキスト（指示、資料、会話履歴など、判断に必要な情報）と、使用するモデルを選ぶ設計です。本記事ではUber、Spotify、Grabの公開事例を比較し、費用と品質を一緒に管理する方法を整理します。自社で採用する際の判断基準や、導入後の確認事項も扱います。
なお、本記事のトークンは、入力・出力・推論・キャッシュで扱う情報量を指します。推論はAIが回答を導くための内部処理、キャッシュは処理済みの情報を再利用する仕組みです。認証に使うアクセストークンとは異なります。また、各社の削減率は、それぞれの環境と測定条件で得られた結果です。同じ効果が他社でも得られるとは限りません。
Uber：AIへの接続の一元化と、実際の業務に基づくモデル評価
中央ゲートウェイによる利用・費用・データの管理
Uberは、生成AIゲートウェイ（AIへのアクセスをまとめて受け付け、管理する共通の接続点）を設けています。外部ベンダーのモデルと社内モデルを、OpenAI互換の共通インターフェース（同じ形式でAIを呼び出せる接続方法）で扱う仕組みです。
このゲートウェイで、次の管理をまとめて行います。[1]
- 認証・認可（利用者の確認と、利用できる範囲の設定）
- 個人情報の秘匿化（個人を特定できる情報を隠す処理）
- 利用記録の保存と監査
- 費用配賦（利用したチームなどへの費用の割り当て）と予算管理
2024年の公開記事によると、約30チームが利用し、月間1,600万件、ピーク時には毎秒25件の問い合わせを処理していました。[1]
ゲートウェイの役割は、API（ソフトウェア同士が機能を呼び出すための接続点）の形式をそろえることだけではありません。利用目的やデータの取り扱いを審査したうえでアクセスを許可し、「どのチームが、どのモデルへ、どの経路で、どれだけ送ったか」を記録します。
ただし、管理のために追加した処理も評価が必要です。たとえば、個人情報を隠す処理は安全性を高める一方で、応答を遅くしたり、回答に必要な情報を減らして品質に影響したりする場合があります。[1]
費用の増加原因を見分ける6つの要因
Uberが2026年に公開したソフトウェア開発向けの運用では、費用を次の要因に分けています。[2]
利用者数 × 1人あたりのセッション数 × 1セッションあたりの対話回数 × 1対話あたりの要求数 × 1要求あたりのトークン数 × 1トークンあたりの価格
セッションとは、一連の作業や会話のまとまりです。要求とは、AIモデルへの個々の処理依頼を指します。
この分け方なら、請求額が増えたときに、利用者が増えたのか、AIによるツールの呼び出しが増えたのか、一度に渡す情報が増えたのか、モデルの単価が上がったのかを調べられます。
原因が分かれば、利用を制限する以外の対策も選べます。たとえば、繰り返し読む情報をキャッシュする、長い会話履歴を短くまとめる、ツールの説明を必要なときだけ読み込む、仕事を小さく分けて安いモデルに任せる、といった方法です。
品質基準を満たした仕事あたりの費用
Uberは、モデル名や公開ベンチマーク（共通の課題で性能を比べる試験）の結果だけでモデルを選びません。導入先の業務を模した課題を用意し、特定のモデルに依存しない試験環境で比較します。[2]
比較するのは、品質、完了率、信頼性、費用です。品質を維持できる選択肢の中から、完了した仕事あたりの費用が小さいモデルを選びます。
同記事では、補助作業には安い小型モデルを標準で使い、主モデルが仕事の分解と結果の確認を担う構成も紹介されています。すべての作業を同じモデルに任せず、役割に応じて使い分ける方法です。[2]
必要なツールだけの読み込み
AIに渡すツール定義（ツールの用途や使い方を記した説明）も、費用に影響します。Uberの記事では、約100個のツール定義が5万〜7万トークンを占める場合があるとしています。[2]
対策として紹介されているのが、必要なツールだけを検索して読み込む仕組みと、ツールが返した生の出力をそのまま会話履歴に残さない実行方式です。
モデルを替える前に、「AIに何を見せる必要があるか」を見直す方が、費用削減につながる場合もあります。
Spotify：大量の読み取り処理の分離と、必要な社内情報の提供
Shuntによる大量ファイルの読み取り処理の分離
Spotifyが公開するShuntは、コードエージェント（コードの調査や編集を行うAI）向けのプラグイン（機能を追加する拡張ソフトウェア）です。大量のファイルを読む処理を、別のAI基盤に任せます。[3]
処理は、次の3段階で進みます。
- フック（処理の前後に別の処理を差し込む仕組み）が、350行を超える読み取りを止める。
- 専用スクリプト（特定の処理を実行するプログラム）が対象の内容を読み取る。
- 必要な内容だけを整理して、元のエージェントに返す。
対象となるのは、大きなファイルの要約、複数ファイルをまたぐ調査、テストや依存関係（あるプログラムが別のプログラムなどに頼る関係）の抽出などです。
公開README（使い方や仕様を説明する文書）では、16万2,000行のJavaモノレポ（複数のプロジェクトを一つにまとめて管理するコード保管場所）を使った比較が紹介されています。3つの大量読み取り課題で、元のエージェントが消費したトークンを82〜94%、平均90%減らしたと報告しています。[3]
この数字は、元のエージェントのトークン削減率です。別のAI基盤の利用も含めた総費用の削減率とは、区別して読む必要があります。
一方、Shuntは、デバッグ（不具合の原因調査と修正）、小さなファイルの処理、設計判断、対話しながらの編集を別のAI基盤に任せないと明記しています。コード生成を任せるかどうかも、助言にとどめており、強制はしません。[3]
つまり、分離するのは、大量のI/O（データの読み書き）が発生し、その結果を短く整理できる仕事です。
Portalによる、探索に必要な社内情報の提供
AIに渡す情報は、少なければよいわけではありません。正しい情報を先に渡すことで、調査や試行錯誤を減らせる場合があります。
SpotifyのPortalは、サービスカタログ（社内サービスの一覧）、各サービスの所有者、社内標準への対応状況、社内ツールなどの情報をAIに接続する仕組みです。
Spotifyは、同じモデル、コードベース（対象となるコード一式）、課題を使い、条件をそろえた一つの比較を公開しています。組織コンテキスト（担当者や社内ルールなど、組織固有の判断に必要な情報）を先に与えたところ、次の結果が得られました。[4]
| 評価項目 | 公開された結果 |
|---|---|
| トークン費用 | 32%削減 |
| 完了までの時間 | 65%短縮 |
| 正答数 | 10件中4件から8件へ増加 |
一つの社内事例なので、この結果をそのまま他の業務に当てはめることはできません。ただし、探索や誤った試行を減らせる情報であれば、最初に渡すトークンが増えても、仕事全体の費用を下げられる可能性を示しています。
Xirpによる、作業情報を保ったモデルの切り替え
Xirpは、特定のAIベンダーに依存せず、モデルやツールを切り替えても作業コンテキストを維持できるエージェント環境として説明されています。
2026年8月の記事では、3万6,000件を超えるセッションで使われており、仕事に合う価格性能のモデルや、自己ホスト型モデル（自社などで用意した環境上で動かすモデル）へ切り替える運用が紹介されています。[5]
これらの事例から、Spotifyの取り組みには、モデルの価格以外に二つの着眼点があると読み取れます。
- 大量の読み取り・検索・整形を別の処理に任せ、元のエージェントの会話履歴に情報をためすぎないこと。
- 所有者、社内標準、依存関係など、探索を短くする情報を必要なときに渡すこと。
3社の共通点と、企業向けの6層運用モデル
GrabのAI Gatewayと、3社の比較
GrabのAI Gatewayも、複数の外部モデルと社内モデルへの認証をまとめています。あらかじめ確保した処理能力を共有しながら、要求、応答、トークン数、使用モデル、処理経路を記録する仕組みです。[6]
探索用と本番用で認証キー（アクセスに必要な認証情報）を分け、利用目的の審査、費用配賦、利用上限、状況に応じた処理経路の選択を組み合わせています。2025年の公開記事では、3,000人を超える従業員から利用申請があり、300件を超えるユースケース（具体的な活用用途）を扱ったと報告されています。[6]
3社は規模も実装方法も異なりますが、何を管理し、何を基準に判断するかを比べると、共通点を理解できます。
| 観点 | Uber | Spotify | Grab |
|---|---|---|---|
| 主な管理の仕組み | 全社共通のゲートウェイ | エージェントのフックと社内ポータル | 全社共通のゲートウェイ |
| 主な改善対象 | モデル、ツール、会話履歴、キャッシュ | 大量の読み書き、探索、組織固有の情報 | 処理能力、経路、予算、利用目的 |
| 作業の振り分け方 | 補助作業に安い小型モデルを使用 | 大量読み取りを別の処理に委譲 | 用途と処理能力に応じた経路を選択 |
| 主な評価項目 | 仕事の完了、品質、信頼性、費用 | 課題ごとのトークン数、時間、正答 | 利用者・モデル・経路ごとの利用量と費用 |
| 運用ルールを支える仕組み | 審査、個人情報の秘匿化、監査、予算 | 所有者、社内標準、ツールに関する情報 | 審査、環境の分離、費用配賦、上限 |
自社に適用する際の示唆は、次のように整理できます。
| 観点 | 自社での設計に生かせること |
|---|---|
| 管理の仕組み | 中央で共通ルールを適用しつつ、現場では仕事を分けてAIに任せる |
| 改善対象 | トークン単価に加え、情報量、探索、処理経路などを見直す |
| 作業の振り分け | 安いモデルを標準とし、高性能モデルへ切り替える条件を明確にする |
| 評価項目 | 品質を満たして仕事を終えられたかまで含めて費用を判断する |
| 運用ルール | 利用許可と費用管理に、共通の業務識別情報を使う |
仕事から成果までの6つの管理項目
3社の事例を基に、本記事では、企業のトークン・モデル管理を6つの層に分ける方法を提案します。各社が同じ名称の枠組みを採用しているわけではありません。
| 層 | 決めること | 最低限残す記録 |
|---|---|---|
| 1. 仕事 | 要約、抽出、生成、推論、検索、実行のどれを任せるか | 活用用途、担当チーム、成果物、業務への影響度 |
| 2. コンテキスト | 必須の指示、検索で取得する情報、必要時だけ読み込むツール、キャッシュする情報 | プロンプトの版、情報の取得元、ツール名、キャッシュへの書き込みと読み出し |
| 3. モデル | 標準モデル、高性能モデルへの切り替え条件、モデルを固定する例外 | 要求されたモデル、実際に使ったモデル、処理経路を選んだ理由 |
| 4. 制御 | 認証、データの区分、利用上限、停止条件、再試行、人による承認 | 利用者、部門、実行環境、ルールへの適合判定、例外の扱い |
| 5. 観測 | 入力・出力・推論・キャッシュのトークン数、応答時間、失敗、費用 | 一連の処理を追跡するID、適用単価の版、処理状態、推定費用と確定費用 |
| 6. 成果 | 品質、完了率、やり直しの回数、完了時間 | 評価課題一式の版、合格条件、完了した業務あたりの費用 |
固定・既定・昇格の3種類のモデル
モデルは、使う場面に応じて3種類に分けると管理しやすくなります。
| 種類 | 主な用途 |
|---|---|
| 固定モデル | 規制への対応、結果の再現性、認証済みの動作を優先する仕事 |
| 既定モデル | 日常の標準的な作業 |
| 昇格モデル | 品質不足や作業の複雑さを検知した場合に使う高性能モデル |
ルーター（処理を任せるモデルや経路を選ぶ仕組み）が自動で選ぶ場合も、「要求されたモデル」「実際に使ったモデル」「選択理由」を記録します。どのモデルが、なぜ使われたのかを後から確認するためです。
月額費用と、業務単位の費用の把握
予算管理では、月額の総費用に加えて、入力・出力・推論・キャッシュの費用内訳を確認します。また、次の単位でも費用を比較します。
- 1,000要求あたり
- 利用者あたり
- セッションあたり
- 完了した業務あたり
特に確認したいのが、完了した業務あたりの費用です。トークン単価が下がっても、この指標が改善しなければ、やり直しが増えて費用削減の効果が失われている可能性があります。
費用配賦に使うメタデータ（処理を分類・管理するための付加情報）は、AIへ要求を送る時点で付けます。利用者だけでなく、アプリ、部門、環境、ワークフロー（一連の業務手順）も記録します。
後からログ（処理の記録）を見て推測で分類するよりも、利用許可、予算、成果を同じ業務単位で追いやすくなります。
導入の出発点：費用上位20件の業務の整理
最初に、費用の大きいワークフローを上位20件選び、「大量読み取り」「反復検索」「生成」「複雑な推論」「ツール実行」に分類します。
次に、それぞれの業務について、以下の項目を一枚の表にまとめます。
- AIに必ず渡す必要がある情報
- 現在使っているモデル
- 仕事が完了したと判断する条件
- やり直しの回数
こうして整理すると、大量の読み書きを別の処理に分けられないか、不要なツール定義を渡していないか、誤った情報の探索がなぜ起きるのかを調べやすくなります。モデル単価の交渉に入る前に、業務の進め方から改善点を探せます。
ただし、業務の品質を代表する評価課題や完了条件を用意できない場合は、自動ルーティング（AIモデルや処理経路の自動選択）を本番の標準運用にはしません。まず中央ゲートウェイで利用状況を確認できるようにし、上限を設定します。モデルの変更は、人が承認する範囲にとどめます。
製品やOSS（ソースコードが公開され、ライセンスに従って利用・改変できるソフトウェア）の具体的な選び方は、企業向けAIゲートウェイ・モデルルーター選定ガイドで整理します。
まとめ：品質を満たした仕事あたりの費用
3社の事例から、生成AIの費用と品質を管理するには、モデルの選択に加えて、仕事の分け方と情報の渡し方を設計する必要があると分かります。安いモデルへの変更も、不要な情報の削減も、品質とやり直しを含めた「仕事を終えるまでの費用」が改善するかで判断します。
自社での検討は、費用上位20件の業務について、必要な情報、使用モデル、完了条件、やり直し回数を整理するところから始められます。評価課題と完了条件を用意できない業務では、利用状況の可視化と上限設定を先に進め、モデルの変更は人が承認する範囲にとどめます。
本記事は一般的な情報整理であり、法的・セキュリティ上の助言ではありません。実務判断は自社の専門担当者と確認してください。
参考文献
- Uber Engineering, Uber’s Gen AI Gateway, 2024年7月11日
- Uber Engineering, Running a Software Factory Efficiently at Uber Scale, 2026年8月27日
- Spotify, Shunt: Stop wasting Claude Code tokens, GitHub
- Spotify Portal, The Hidden Tax on Your AI Agents, 2026年8月28日（2026年9月3日更新）
- Spotify Portal, What we’ve learned scaling AI coding agents at Spotify, 2026年8月10日
- Grab Engineering, Grab’s AI Gateway, 2025年2月19日
最新の機能、料金、公開値は、各社の公式サイトと公式ドキュメントを確認してください。