目次
LiteLLMの活用事例(弁護士ドットコム株式会社)
参考になった
0
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
弁護士ドットコム株式会社 / 櫛部勇気
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
最終更新日投稿日
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
LiteLLM OSS | LiteLLM Proxy | 101名〜300名 | 2025年7月 | B to B |
| 利用プラン | LiteLLM OSS |
|---|---|
| 利用機能 | LiteLLM Proxy |
| ツールの利用規模 | 101名〜300名 |
| ツールの利用開始時期 | 2025年7月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
- クライアントからのリクエストは ALB 経由で ECS Fargate 上の LiteLLM に到達し、各 LLM プロバイダーへルーティングが行われます。
- 公式から提供されている LiteLLM は、Docker Compose を確認すると LiteLLM および PostgreSQL の 2 コンテナ構成となっています。当社では安定稼働とデータ保全のため、PostgreSQL はコンテナから Aurora に移行しました。
- 具体的な設定例の抜粋は SRE Magazine にも寄稿しておりますので、そちらもご参照ください。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
主に社内のエンジニア向けに、生成 AI(Amazon Bedrock/Azure OpenAI/Google Vertex AI)へアクセスするための基盤を提供していますが、次のような課題を抱えていました。
- 利用者単位で、生成 AI の利用料金の把握ができない
- 利用者側はマルチクラウド申請が必要
- 管理者側はユーザー管理が煩雑
どのような状態を目指していたか
- LLM の利用量には個人差があったため、ユーザー単位で費用をモニタリングし、利用量の多いユーザーには定額プランへの移行を促すといったコスト最適化を目指していました。
- 生成 AI の利用者からは、AWS/Azure/Google Cloud それぞれに利用申請を出してもらっていました。また、管理者側である私たちは各プラットフォームでユーザー管理が必要なことから運用負荷が高く、利用者・管理者双方の負荷を減らしたいと考えていました。
比較検討したサービス
- Amazon Bedrock の追跡ログからの使用量計算
- Azure OpenAI/Google Vertex AI のコストをモニタリングするには別の仕組みが必要な点や、ログ収集・クレンジング処理の煩雑さから、この方法は採用を見送りました。
- Eden AI / Portkey
- ユーザーごとのコストを把握したいという要件に対して、どちらも高機能過ぎるため採用を見送りました。
- LiteLLM LLM Gateway (Proxy Server) ※SaaS 版
- 機能としては十分ですが、OSS 版を自社運用する形で十分と判断し、導入は見送りました。
比較した軸
- 利用者単位でコストの把握が可能であるか
- 専任の担当者をアサインしなくとも運用できるものであるか
- 費用対効果
選定理由
- OSS 版の LiteLLM を検証したところ、ユーザー単位でのコスト把握が可能でした。また、専任担当者をアサインせずとも運用できる見込みが立ち、費用対効果も高いと判断したため導入を決定しました。
導入の成果
改善したかった課題はどれくらい解決されたか
- 利用者ごとのコストモニタリングについては LiteLLM/Datadog を合わせて実現していますが、上記の課題はほぼ解決されました。
どのような成果が得られたか
- LiteLLM を LLM プロキシとして導入し、ログを Datadog に転送し、メトリクスフィルターを用いて「ユーザー × モデル × トークン」の粒度でモニタリングしました。
- 生成 AI を利用していると
429 Too Many Requestsというエラーがよく発生します。LiteLLM の Load Balancing 機能を用いて負荷を分散させることで、導入前と比較してエラーの発生を 90 ％ 以上減少させることができました。
導入時の苦労・悩み
- LiteLLM は OSS であり、Docker Compose ベースで提供されています。構築作業を行っていた 2025 年 7 月時点では、公式ドキュメント以外に有益な情報がほとんど得られず、ECS への移植は手探りでの作業でした。
- Claude Code や Codex といった既存製品との組み合わせで、初めて LiteLLM を動作確認した際には予期しない問題が少なからず発生し、対応に追われました。
- 利用者への設定案内や問い合わせ対応といった、サポート業務にも工数を要しました。
導入に向けた社内への説明
上長・チームへの説明
- 利用者ごとのコストが把握できていない、最適化が行えていないという点は組織全体で課題であると認識していました。このため、LLM プロキシ基盤の構築は急務でした。
- LiteLLM は OSS 製品であるため、当社の場合は速やかにスモールスタートを切ることができました。また、推進にあたって CTO からの後押しや、一部のユーザーにご協力いただいた β テストが早期リリースに繋がりました。
活用方法
以下、2025 年 10 月時点でのレビュー内容です。
- 社内ユーザー向けに、LLM プロキシとして公開しています。
- Datadog と組み合わせることで、ユーザー毎のトークン使用量・利用料金をモニタリングし、特に利用量の多いユーザーには定額プランへの変更を打診しています。
よく使う機能
- LiteLLM のルーティング機能を利用しています。ある生成 AI モデルが複数のリージョンや LLM プロバイダーで提供されている場合、各リージョンまたはプロバイダーへルーティングさせることができ、アクセス過多のエラーを避けることができています。
- LiteLLM は API が用意されており、ユーザーの新規作成などで利用しています。
ツールの良い点
- 開発が活発で、日々改良されています。
- 上述のとおり、ルーティング機能によりアクセス過多のエラー発生率を大幅に下げることができました。
ツールの課題点
- LLMプロバイダーから新しいモデルが提供された際、LiteLLM 経由で新しいモデルを利用するにはLiteLLM での対応を待つ必要があり、迅速に対応できないことがあります。
- モデル追加を反映したい場合、定義ファイルの更新やコンテナの再起動といったメンテナンス作業が必要です。
- LiteLLMは開発が活発で、頻繁にバージョンアップが行われます。多数の更新の中から、都度バージョンアップを判断・実行していく運用工数が必要です。
ツールを検討されている方へ
- ユーザーごとの詳細なコスト把握には Datadog 等の外部ツールとの連携が必要ですが、マルチクラウド環境における生成 AI へのアクセスを集約し、セキュアな基盤を構築したいと考えている方には、有効な選択肢になると考えます。
今後の展望
- ユーザー数/利用量増加に伴うスケーラビリティ対応
- コストとパフォーマンスを考慮した、より戦略的なモデル選択・ルーティングの最適化検討
- 運用ノウハウの体系化と社外への知見共有
弁護士ドットコム株式会社 / 櫛部勇気
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
弁護士ドットコム株式会社 / 櫛部勇気
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法