生成 AI のコストとユーザー管理の煩雑さを一挙に解決!! LiteLLM 導入の軌跡と成果
はじめに
こんにちは、弁護士ドットコム SRE 室の原口と申します。 F1 大好きなエンジニアです。
角田 裕毅 選手を自分のことのように応援しています。
私が所属する弁護士ドットコム SRE 室は、全社横断の組織として Platform SRE の役割も担っており、マルチクラウド環境で生成 AI を社内に提供しています。
生成 AI を提供・運用していく中で、費用対効果を最大化するためには、利用する各個人の利用量を把握する必要があると気がつきました。
またマルチクラウド環境下での利用申請・ユーザー管理が煩雑で運用負荷が大きく、これらの作業を削減する必要に迫られていました。
私たちは、この 2 つの課題を同時に解決する方法を模索していました。
とくに生成 AI の活用を全社的に進める中で、予算を最適化し、たくさんのメンバーがストレスなく利用するためには「各個人の利用量」の把握が急務と考え LiteLLM を導入しました。
今回は、導入に踏み切った経緯と運用してわかったことを紹介します。
LiteLLM Proxy Server とは
いろいろな生成 AI へのアクセスを、一元管理するためのプロキシサーバーです。
以下のような構成になっていて、LiteLLM 自体は AWS の ECS にセルフホスティングしています。
ECS にホスティングされた LiteLLM を経由して、各クラウドにデプロイされている生成 AI にアクセスします。
また Datadog にアクセスログを送信して、利用量をモニタリングしています。
| サービス | 説明 |
|---|---|
| Amazon ECS | AWS のコンテナサービス。LiteLLM をセルフホスティングしています |
| Amazon Bedrock | AWS の生成 AI プラットフォーム。多様な生成 AI を API 経由で利用できます |
| Vertex AI | Google Cloud の AI プラットフォーム。Gemini などの独自の生成 AI などを利用できます |
| Azure OpenAI | Microsoft Azure の OpenAI サービスプラットフォーム。GPT-5 など OpenAI のモデルが安全に利用できます |
| Datadog | インフラ、アプリケーション、ログの統合監視を提供する Observability プラットフォームです |
導入するメリット
- 利用者ごとの利用料金がモニタリングできる
- 「誰が」「どのモデルを」「どれくらい使ったか」をモニタリングできる（私たちの導入の主な目的）
- API キー管理の手間が減少する
- 各プラットフォームごとに API キーを発行したり認証情報を管理する必要がなくなる
- 負荷分散と安定化
- LiteLLM の Load Balancing 機能を用いることで
429が減少することが期待できる- 生成 AI を利用していると
429 Too Many Requestsがよく発生するため
- 生成 AI を利用していると
- LiteLLM の Load Balancing 機能を用いることで
- 各生成 AI を OpenAI 互換で呼び出せる
上記のとおりいろいろとメリットはありますが、今回私たちは「各個人の利用量」を把握して、予算を最大限活用することを目的にしていました。
導入の経緯について
以下の状況を改善するために、たくさんの生成 AI の利用料金をモニタリングできる LiteLLM Proxy Server の導入を決定しました。
導入前の状況
私たちは、AWS の Amazon Bedrock で Claude Sonnet などの提供を開始しました。
しばらく運用すると、思ったより利用料金が高くなってしまい、予算の最適化には利用者の利用量を把握する必要があると考えました。
利用量を把握できれば、適切なサービスを案内できると考えたからです。
しかし Amazon Bedrock の機能だけでは利用者ごとの利用量を把握できませんでした。
さらに、今後 Azure OpenAI や Google Vertex AI なども提供する予定になっていた事から、利用者と生成 AI の一元管理を行える製品が必要と考えていました。
具体的には、以下の 2 つの大きな課題がありました。
課題1 利用者単位での生成 AI 利用料金の把握ができない
LiteLLM 導入前は、個人レベルで生成 AI の利用量が把握できず、Amazon Bedrock なら Claude Sonnet 4 といったモデル単位での利用量がわかるのみでした。
利用状況を利用者単位でモニタリングできれば、全体の費用を抑えることができます。
たとえば、たくさん使う人を従量課金から定額プランに変更する（一定の利用量を超える利用者は Claude Max プランなどへ移行する）ことで、利用者の満足度はそのままに、費用を削減できます。
結果として、予算内でより多くの利用者にサービスを提供できることになります。
課題2 マルチクラウド申請・ユーザー管理が煩雑
LiteLLM 導入前、社内の利用者には AWS、Google Cloud、Azure の 3 つのプラットフォームそれぞれに申請してもらっていました。
利用者は、複数の申請が必要になり、運用している私たちも、各プラットフォームのユーザー管理が必要になり運用負荷が高まっていました。
そこで、ユーザー管理を LiteLLM に一本化することによって、利用者の申請の手間と私たちの運用負荷を軽減できると考えました。
スケジュール
プロジェクト発足から、全社導入までのスケジュールは以下のとおりでした。
当初はタイトなスケジュールで心配していましたが、いろいろなメンバーの協力もあり、無事に QCD (Quality, Cost, Delivery) を満たすことができました。
- 7/4: LiteLLM 実用化プロジェクト発足
- 7/17: SRE 室内でのベータテスト開始
- 7/25: 社内から立候補していただきベータテスト開始
- 8/4: 全社公開
運用をはじめてわかった点
最後に、運用開始して間もないですが、実際に運用していてわかった点を紹介します。
有志のベーターテスターは本当にありがたい
私個人としては「利用料金が監視される事への反発があるかも」と思っていましたが、ベーターテスターのみんなは、積極的にいろいろなテストやアドバイスを行ってくれました。
社内のヘビーユーザーのみんなに、いちはやく利用してもらいメリットを感じていただくことでその後の導入がスムーズに進みました。
振り返ると、ヘビーユーザーを巻き込むことが、全社展開の鍵だったと考えています。
また CTO の支援もあり、私たちも一丸となって「どんどん使ってもらえるようにするための施策です」とポジティブなメッセージを出すことができて良かったと考えています。
429 エラーが 90 ％ 以上減少した負荷分散機能の威力
生成 AI を利用していると 429 Too Many Requests がよく発生しますが、 Load Balancing 機能を用いて負荷を分散させ 429 の発生が 90 ％ 以上減少しました。
とくに、Claude Sonnet 4 などは、AWS の各リージョンへの振り分けのみならず、Google Cloud にも振り分けることができるため、負荷分散の効果が非常に高くなっています。
Datadog によるモニタリングが便利
LiteLLM は Datadog と連携でき、各利用者の利用量をモニタリングできます。
LiteLLM はレスポンスごとに Datadog へログを出力する設定ができます。
出力されるログの中にはコストが response_cost という項目で出力されています（単位はアメリカドル）。
このコストとユーザー ID などを利用することで Datadog のダッシュボードで簡単に利用料金をモニタリングできます。
タイミングが良いことに Sheets 機能がリリースされていました。
管理者はピボットテーブルなどを用い、各利用者の利用料金を集計したり、よく利用される生成 AI モデルを把握できます。
また CSV のエクスポート機能もあるので既存の強力な表計算ソフトなどを用いて、利用状況の分析も可能です。
この機能により、各利用者の利用状況を簡単に把握できるようになりました。 今後は、次の投資判断（定額プランの案内など）につなげていく予定です。
Datadog には LiteLLM インテグレーションもあり、LiteLLM のメトリクスも簡単にモニタリングできます。
モデルの追加に手間がかかる
先日 GPT-5 が発表されましたが、 LiteLLM の対応を待ってから利用を開始する必要がありました。
API の仕様が変わらない場合は、比較的スムーズに対応できますが、大きな変更があった場合は LiteLLM の対応状況を見ながらの対応となるため注意が必要です。
ただし LiteLLM の対応は非常に早く、すぐに対応してもらえることが期待できます。
またバージョンアップを待たなくても LiteLLM の設定でカバーできる部分もあり、私たちの工夫で補える部分があるのも良い点だと感じました。
運用の高度化に利用できる
私たちは、単にプラットフォームを提供するだけではなく「SRE x AI」で運用を高度化する環境も必要と考えていました。
たとえば、インシデント対応の支援やテスト・ドキュメント生成などを実験・検証する環境です。
そのような取り組みにも、さまざまなモデルを統一された API で呼び出せる LiteLLM の活用を始めています。
まとめ
LiteLLM を導入することで、利用料金のモニタリングを行うことができ、予算の最適化をはかるという当初の目的を達成できました。さらに、以下のような効果もありました。
- LiteLLM の負荷分散機能により、
429 Too Many Requestsが大きく減少できました - 利用者登録を自動化したことで申請や利用者の追加作業が不要になり、トイルを削減しました
- 利用者は
Amazon BedrockやAzure OpenAIなどの異なる生成 AI サービスの差異を意識することなく、同一の API で簡単に利用できるようになりました
使いたいときにすぐ利用できるのは、利用者にとって大きなメリットとなり、生成 AI の利用促進にもつながっています。私たち SRE 室にとっても利用者追加の手間がなくなり、運用負荷が軽減されました。
これからも生成 AI を利用した、いろんな技術やサービス、新しい考え方がたくさん出てくるはずです。生成 AI 利用者と SRE エンジニア、双方の視点を大切にしながらトレンドを追いかけていきます。
最後に
弁護士ドットコムではいろいろなポジションのエンジニアを募集をしています。
ぜひ一緒に働いてみませんか。ご応募をお待ちしております。
最後になりましたが、私には尊敬している Yuki が 3 人居ます。
- F1 オラクル・レッドブル・レーシングの角田 裕毅
- NBA シカゴ・ブルズの河村 勇輝
- 弁護士ドットコム SRE 室の櫛部 勇気
その櫛部さんが、環境構築で苦労した点や工夫した点を別途書いてくれる予定です。お楽しみに！