はじめに

各社で開発用途・業務用途に Azure OpenAI、Microsoft Foundry、Amazon Bedrock、OpenAI、Anthropic などの LLM を利用するケースが増えています。利用が広がるほど、次のような課題が同時に持ち上がります。

誰が、どのモデルを、どれだけ使っているか分からない
月末に費用が急増して原因が特定できない
開発者が個人の API キーで AI コーディングツールを使い、ソースコードが社外へ送信されている
監査のときに「いつ・誰が・何を投げたか」を示せない

この記事は、こうした課題に対する解決策として企業がどのようにLLM利用を統制しているかを、Azure / AWS 側のガバナンス設計と、OSS の LiteLLM を使った社内 LLM Gateway の実装設計の両面から整理したものです。

対象読者

社内の LLM 利用統制・コスト管理・セキュリティ設計を検討している方
Azure OpenAI / Amazon Bedrock の権限管理・監査ログの実装方法を知りたい方
LiteLLM を使って社内 LLM Gateway を構築しようとしている方
個人の API キー利用を社内 Gateway 経由に移行したいと考えている情報システム・セキュリティ担当の方

前提・この記事で分かること

この記事は2026年7月時点の公開情報をもとにしています。Azure・AWS の機能や LiteLLM の仕様は更新が速いため、実装時は各リンク先の公式ドキュメントで最新の挙動を確認することをおすすめします。

記事の前半（1〜9章）で、Azure / AWS 上の LLM をどう統制するかという設計論を扱います。後半（10〜13章）で、その設計論を LiteLLM で具体的にどう実装するかを、Phase1（アプリ・部署単位の予算管理）と Phase2（ユーザー単位課金・SSO連携）の2段階に分けて扱います。前半が「なぜ・何を管理すべきか」、後半が「どう実装するか」という関係になっています。

要点(最初に結論)

企業では、Azure OpenAI / Amazon Bedrock を各利用者が直接使うのではなく、社内に AI Gateway / LLM Gateway を置き、その下に各クラウドをぶら下げる構成が、有力な設計パターンになりつつあります。
統制すべき領域は「利用者制限・コスト管理・セキュリティ・監査」の4つに整理できます。
Azure は Entra ID / Azure RBAC、AWS は IAM / SCP が制御の中心になりますが、いずれも Gateway 層で集中管理する方向に機能を強化しています。
実装は最初から個人単位の厳密な管理を目指すのではなく、まずプロジェクト/アプリ単位の予算管理から始め、その後ユーザー単位・SSO連携へ拡張するという段階的なアプローチが現実的です。
OSS の LiteLLM は、この段階的な移行を Team → User という階層構造で自然に表現できるため、社内 Gateway の実装候補として有力です。

1. なぜ社内LLM Gatewayが必要か

結論として、企業では Azure OpenAI / Amazon Bedrock を各利用者が直接使うのではなく、社内の AI Gateway / LLM Gateway を作り、その下に Azure・AWS・OpenAI・Anthropic などをぶら下げる 形が、有力な設計パターンになりつつあります。実際、Azure API Management の AI Gateway も AWS の Multi-Provider Generative AI Gateway も、この構成を前提にした機能強化を進めています（詳細は2章で扱います）。

理由は、LLM が通常の API よりも次の点で管理が難しいためです。

コスト暴走
機密情報・個人情報の入力
モデル選択のばらつき
ログ監査
利用者別・部署別の費用按分
AI コーディングツール経由のソースコード送信
RAG / MCP / 社内DB連携による権限逸脱

通常の社内 API であれば、呼び出し回数やレスポンスサイズはある程度予測できます。一方 LLM は、1回のリクエストでもプロンプトの長さやモデルの選択によってコストが大きく変動し、さらに Agent 型のツールでは1つのタスクの中で何十回も LLM を呼び出すことがあります。この不確実性こそが、Gateway による集中管理が必要とされる背景です。

2. 全体像

典型的な構成は以下の通りです。

Microsoft も AWS も、この Gateway で集中管理する方向の機能強化を進めています。

Azure API Management の AI Gateway は、Azure OpenAI だけでなく Amazon Bedrock などの外部プロバイダー上のモデルも管理対象にでき、認証、承認、監視、トークン使用量、クォータ管理をまとめる設計です。

AWS 側も Multi-Provider Generative AI Gateway のリファレンスを提供しており、OpenAI 互換 API を入口にして、Bedrock、SageMaker、外部 LLM を統一的に扱い、利用量追跡、コスト管理、ガバナンスを実装する構成を示しています。

両クラウドとも「個別のプロバイダーAPIを直接使わせる」のではなく「Gatewayという1枚のレイヤーで受けて振り分ける」方向への機能強化が進んでいるのが分かります。

3. 利用者制限の設計(Azure/AWS)

主なやり方は、SSO グループ × ロール × モデル許可リスト です。

3.1 Azure / Microsoft Foundry / Azure OpenAI の場合

Azure の場合は、Microsoft Entra ID と Azure RBAC を使い、Azure OpenAI / Foundry のリソース単位で次のように権限を分けます。

使うだけの人
モデルをデプロイできる人
クォータを見られる人
リソース管理ができる人

Azure OpenAI には Cognitive Services OpenAI User、Contributor、Usages Reader などの役割があります。

たとえば User は推論 API の利用はできますが、モデルデプロイの作成やキー参照などはできない、という分離ができます。ただし、これらは classic の Azure OpenAI リソース単位のロールであり、Microsoft Foundry 全体で見た場合は project / resource 単位でスコープが分離される構造になっているため、粒度が異なる場合がある点には注意が必要です。

Microsoft Foundry の組織展開ガイドでも、以下を定義することが推奨されています。

誰がプロジェクトを作れるか
誰がモデルをデプロイできるか
誰が外部ツール接続をできるか
どのモデルプロバイダーを許可するか
どのツール接続を許可するか

3.2 AWS / Amazon Bedrock の場合

AWS Bedrock の場合は、IAM / IAM Identity Center / SCP で制御します。

Bedrock は IAM アクション、リソース、Condition Key を持つため、以下のような制御が可能です。

特定モデルの Invoke を拒否する
組織全体の SCP として「このモデルは使わせない」と制御する
チームやアプリ単位で利用可能モデルを変える
本番環境と検証環境で使えるモデルを分ける

AWS 公式ドキュメントにも、Foundation Model の推論を禁止する IAM ポリシー例があり、SCP として組織横断のモデル制限に使えると説明されています。

3.3 実務上の制御対象

制御対象	よくある制御
利用者	社員ID、部署、プロジェクト、委託先区分で制御
モデル	高額モデル、外部共有が必要なモデル、画像生成モデルを別承認
用途	開発検証、社内文書要約、顧客向け本番利用を分離
データ	機密、個人情報、顧客データ、ソースコード投入可否を分類
ツール	RAG、社内DB検索、MCP、外部Web検索の利用可否を制御

Azure・AWS で使う仕組みの名前は違いますが、どちらも「利用者」「モデル」「用途」「データ」「ツール」という同じ5つの軸で権限を切り分けているのが分かります。この5軸は、後述する LiteLLM の設計でも共通の考え方として引き継がれます。

4. コスト管理の設計

コスト管理は、クラウド請求だけを見るのでは不十分です。

LLM では「誰が、どのモデルに、何トークン使ったか」まで取らないと、費用配賦や暴走検知ができません。

4.1 Azure側のコスト管理

Azure OpenAI のメトリクスとして、以下を Azure Monitor で取得できます。

リクエスト数
Processed Prompt Tokens
Generated Completion Tokens
Processed Inference Tokens
Prompt Token Cache Match Rate
エラー率

なお、レイテンシ系のメトリクスは Latency という名称のものは非推奨とされており、代わりに Time to Response、Time to Last Byte、Time Between Tokens、Normalized Time to First Byte を使う構成になっています。

診断設定を有効化すると Log Analytics にルーティングでき、KQL で分析したり、アラート、ダッシュボード、Grafana、Power BI などに連携できます。

Azure API Management の AI Gateway では、API 利用者ごとに TPM 制限や期間別トークンクォータを設定できます。カウンターキーには、サブスクリプションキーや IP アドレスといった組み込み属性のほか、任意のポリシー式を使えます。

ユーザーID・アプリID・部署ID単位でクォータを分けたい場合も、APIM がこれらを組み込み属性として持っているわけではありません。リクエストヘッダーや JWT の claim、subscription の metadata などから、ポリシー式（set-variable や rate-limit-by-key の counter-key など）で値を取り出して構成する形になります。

4.2 AWS/Bedrock側のコスト管理

Amazon Bedrock では、利用量・コストを次の単位で帰属させる方法があります。

ユーザー
チーム
アプリ
環境
実験
プロジェクト
プロンプト単位

公式ドキュメントでは、以下のような使い分けが示されています。

帰属対象	管理方法
ユーザー / チーム	IAM principal attribution
アプリ	Application Inference Profile / Projects
プロンプト単位	request metadata / model invocation logs
請求分析	Cost Explorer / CUR 2.0
詳細分析	CloudWatch Logs / S3 / Athena

Bedrock は IAM principal identity を推論リクエストごとに自動取得し、Cost Explorer や CUR 2.0 で IAM ユーザー・ロール・タグ単位の費用分析ができます。この IAM principal attribution は、現状 bedrock-runtime API を経由する呼び出しが中心であり、新しい呼び出し経路（Responses API 等）では対象外になる場合がある点に留意してください。

ただし、粒度は「使用タイプごと・日次」が中心です。プロンプト単位の詳細には、別途 model invocation logs が必要になります。

4.3 実務上のコスト管理レベル

レベル	管理方法
請求全体	Azure Cost Management / AWS Cost Explorer / CUR
部署別	タグ、IAM principal tag、Azure subscription / resource group 分離
アプリ別	AI Gateway の API キー、APIM subscription、Bedrock Projects / Inference Profiles
ユーザー別	SSO属性、session tag、x-user-id、gatewayログ
リクエスト別	prompt id、trace id、model、input/output tokens、latency
予算超過対策	月次予算、日次アラート、TPM制限、モデル別上限、遮断

特に重要なのは、クラウドの Budget Alert だけでは遅いという点です。

請求アラートや Budget は発生後の検知になりがちです。そのため、Bedrock 呼び出し前にトークン使用量をチェックして制限する cost sentry のような前段制御が紹介されています（AWS Blog「Build a proactive AI cost management system for Amazon Bedrock」）。事後の検知だけに頼らず、呼び出し前にブロックできる仕組みを持つかどうかが、暴走時の被害額を左右する要因になります。

5. セキュリティの設計

セキュリティは大きく5つの観点があります。

5.1 通信経路の閉域化

Azure OpenAI / Foundry では Private Endpoint / Private Link を使い、Public Network Access を無効化して、Private Endpoint 経由だけにできます。

AWS Bedrock でも、VPC と AWS PrivateLink を使って、データをインターネット経由にせず、VPC Interface Endpoint でプライベート接続する構成が推奨されています。

5.2 入力データの統制

多くの企業では、プロンプト投入前に次のチェックを行います。

DLP
PII 検知
秘密情報検知
ソースコード検知
認証情報検知
顧客情報検知
契約情報や社外秘文書の投入可否判定

Azure API Management の AI Gateway では、Azure AI Content Safety を使ったプロンプトモデレーション、Managed Identity による API キー不要化、OAuth 認可、MCP サーバー保護などが提供されています。

AWS 側では Bedrock Guardrails を使い、Guardrail 作成・管理・適用に IAM 権限を設定します。Guardrails は Bedrock モデルに対する推論時だけでなく、ApplyGuardrail API で独立したフィルタとしても使える点が特徴です。

5.3 プロンプト・レスポンスの保存方針

Azure の Foundry Models では、顧客データ、プロンプト、補完は他の顧客や OpenAI 等のモデルプロバイダーに利用可能ではなく、明示的な許可や指示なしに基盤モデルの学習にも使われない、とされています。

また、モデルはステートレスで、プロンプトや補完はモデル内に保存されないと説明されています。

Bedrock では、モデルプロバイダーは AWS 側のデプロイアカウントにアクセスできず、Bedrock ログや顧客のプロンプト・補完にもアクセスできないとされています。

一方で、Bedrock にはデータ保持モードがあります。

none（データを保持しない設定。いわゆる zero data retention に相当）
default
provider_data_share
inherit（親スコープの設定を継承する。組織・アカウント階層でモードを揃えたい場合に使う）

アカウント・プロジェクト単位でこれらを制御できます。provider_data_share はモデルプロバイダーごとに許容される設定が異なるため、利用するモデルの提供元が実際にこの設定を許可しているかを確認する必要があります。モデルによっては provider data sharing が必要な場合があり、IAM / SCP でデータ保持ポリシーを強制する設計も示されています。

5.4 ログの扱い

監査にはログが必要ですが、ログ自体が機密情報になるという点に注意が必要です。

Bedrock の Model Invocation Logging は、リクエスト、レスポンス、メタデータ、入力・出力トークン数を CloudWatch Logs または S3 に保存できます。ただし、デフォルトでは無効になっており、また現状は bedrock-runtime API を中心とした機能である点も踏まえておく必要があります。

Azure API Management でも、LLM API のログを有効化して、トークン使用量、プロンプト、補完を課金・監査目的で追跡できます。

そのため企業では、情報区分ごとに次を決める運用が一般的です。

ログ対象	運用判断
プロンプト全文	保存する / マスキングする / 保存しない
レスポンス全文	保存する / マスキングする / 保存しない
トークン数	原則保存
モデル名	原則保存
ユーザーID	原則保存。ただし閲覧権限を制限
Trace ID	原則保存
添付ファイル	保存しないか、別管理にすることが多い
保管期間	30日、90日、180日、1年などで定義

5.5 RAG/社内データアクセスの認可

LLM 本体よりも危険なのは、RAG や MCP 経由で社内文書、DB、チケット、GitHub、SharePoint、Confluence などにアクセスする部分です。

ここは「LLM が見てよい」ではなく、利用者本人が本来見てよいデータだけを検索対象にすることが重要です。LLM の認可設計をいくら厳格にしても、その先で参照する RAG のインデックスが利用者の権限を無視していれば、結局は情報漏洩につながってしまいます。

Microsoft Foundry の組織展開ガイドでも、外部ツール接続、トレースログ、ネットワーク、暗号化、データ分離を含めたガバナンス設計が重要視されています。

6. Azure/AWSの違い

観点	Azure / Microsoft Foundry / Azure OpenAI	AWS / Amazon Bedrock
ID管理	Entra ID / Azure RBAC が中心	IAM / IAM Identity Center / STS / SCP が中心
Gateway	Azure API Management AI Gateway が有力な選択肢	Multi-Provider Generative AI Gateway / LiteLLM / API Gateway 構成
利用者制限	RBAC、APIM subscription、Managed Identity	IAM policy、SCP、role、session tag
モデル制限	Foundry / APIM 側でモデル・バックエンドを制御	IAM で InvokeModel 制限、model ARN 制御
コスト配賦	Azure Monitor、Cost Management、APIMログ、Resource tag	Cost Explorer、CUR 2.0、IAM principal attribution、Bedrock logs
トークン制御	APIM の LLM token limit policy	Gateway 側制御、CloudWatch metrics、Cost Sentry 構成
閉域化	Private Endpoint / Private Link / VNet	VPC Endpoint / AWS PrivateLink
安全性	Azure AI Content Safety / Guardrails	Amazon Bedrock Guardrails
ログ	Azure Monitor / Log Analytics / App Insights	CloudWatch Logs / S3 / CloudTrail
データ保持	Azure geography、Global / DataZone / Regional の考慮	data retention mode、ZDR、provider_data_share の考慮

呼び方や機能名は異なりますが、「ID基盤で認可し、Gatewayで集約し、モニタリング基盤でコストとログを見る」という全体構造はどちらも共通しています。既に Azure か AWS のどちらかにガバナンス基盤を持っている企業であれば、その基盤の語彙のまま LLM 統制へ拡張していくのが現実的な選択になります。

7. 企業内運用ルール

実際には、技術だけでなく運用プロセスも合わせて作る必要があります。

項目	よくあるルール
申請	部署、用途、データ区分、想定月額、利用モデルを申請
承認	PoC は簡易承認、本番・顧客データ利用はセキュリティ審査
モデル	標準モデル、安価モデル、高性能モデル、禁止モデルを定義
上限	ユーザー / アプリ / 部署ごとに日次・月次トークン上限
ログ	個人情報を含む可能性があるため、保管期間と閲覧権限を制限
監査	誰が、いつ、何の用途で、どのモデルを使ったかを追跡
教育	入力禁止情報、生成物のレビュー責任、著作権・機密情報ルールを周知
例外	研究用途、高機密用途、外部公開用途は別審査

技術的な制御をいくら厳密にしても、申請・承認・教育といった運用プロセスが伴わないと、結局は「使っていい情報の境界」が現場の判断に委ねられてしまいます。Gateway はあくまで技術的な仕組みであり、それを支える運用ルールとセットで考える必要があります。

8. 開発者・AIコーディングツールの管理

開発者向けでは、さらに注意すべき点があります。

Cursor、Claude Code、OpenCode、Cline などの AI コーディングツールは、ソースコード、ログ、環境変数、エラー内容、設計情報を LLM へ送る可能性があります。

そのため企業では、主に次のどちらかの方式を取ることが多いです。

8.1 会社管理のAzure OpenAI/Bedrockエンドポイントだけを許可する方式

開発者は個人の OpenAI / Anthropic キーを使わず、社内 Gateway の OpenAI 互換エンドポイントを指定します。

これにより、次の管理ができます。

利用者認証
モデル制限
ログ取得
費用配賦
トークン上限
DLP
監査
利用停止

8.2 AIコーディング用の専用ワークスペース/VDI/開発環境を用意する方式

ローカル PC から外部 LLM へ直接送信させず、社内ネットワーク・閉域環境・許可済みリポジトリだけで使わせる方式です。

この方式では、以下を統制しやすくなります。

対象リポジトリ
送信可能なファイル
環境変数
認証情報
ローカルファイルアクセス
社内ネットワークアクセス
ログ取得範囲

AWS のコスト最適化記事でも、Claude Code、Kiro、Amazon Q Developer、Cursor BYOK、カスタムアプリなど、クライアントごとにテレメトリ経路は異なるものの、Bedrock native metrics、model invocation logging、OpenTelemetry を重ねる考え方が示されています。

どちらの方式を選ぶかは、開発者の自由度とセキュリティ要件のバランスで決まります。8.1の方式は既存の開発フローを変えずに導入できる一方、8.2の方式はより強い統制が可能になりますが、開発者の作業環境を変える負担が生じます。

9. 推奨構成と導入ステップ

9.1 推奨構成

社内で本格展開するなら、最小構成は以下になります。

特に重要なのは、最初から「使わせない管理」ではなく「安全に使わせる管理」にすることです。

個人利用を禁止するだけだと、開発者が個人アカウントや外部 SaaS を使い、逆に統制不能になってしまいます。

社内 Gateway を用意し、承認済みモデル、コスト上限、ログ、DLP、SSO をセットにして提供する方が現実的な落としどころになります。

9.2 導入ステップ

Step1: 利用経路を一本化する

まず、開発者や業務アプリが直接 Azure OpenAI / Bedrock / OpenAI / Anthropic を叩かないようにします。

入口を社内 AI Gateway に統一します。

この時点では、以下ができれば十分です。

OpenAI 互換 API
API キーまたは SSO による認証
モデルルーティング
ユーザー / アプリ単位のログ
トークン数の取得

Step2: モデルと用途を分類する

モデルを自由選択にすると、コストとリスクが読めなくなります。

そのため、以下のように分類します。

区分	例
標準モデル	一般業務・開発支援に使うモデル
安価モデル	大量処理、分類、要約、軽量チャット
高性能モデル	設計、複雑な推論、重要文書生成
制限モデル	画像生成、音声、外部連携、Web検索付きモデル
禁止モデル	データ保持や契約条件が合わないモデル

Step3: コスト上限を設定する

初期段階では、ユーザー単位よりも プロジェクト / アプリ単位の API キー + 部署タグ + 月次トークン上限 から始めるのが現実的な進め方です。

例:

単位	上限例
個人検証	月1,000円〜5,000円相当
PoC	月5万円〜30万円
本番小規模	月10万円〜100万円
本番大規模	個別見積もり・個別承認

Step4: セキュリティルールを定義する

LLM 利用ルールは、技術制御と利用者教育の両方が必要です。

最低限、以下を定義します。

入力禁止情報
個人情報の扱い
顧客データの扱い
ソースコード投入可否
認証情報や秘密鍵の投入禁止
生成物のレビュー責任
著作権・ライセンスの扱い
ログ保管期間
外部モデル利用条件

Step5: 監査と可視化を行う

最後に、管理者が以下を見られるようにします。

月次コスト
部署別コスト
アプリ別コスト
ユーザー別利用量
モデル別利用量
高額リクエスト
エラー率
レイテンシ
DLP 検知件数
禁止モデル利用試行
異常利用

9.3 社内AI Gatewayで持つべき機能

機能	内容
OpenAI互換API	Cursor、Claude Code、OpenCode、独自アプリから接続しやすくする
認証	SSO、APIキー、サービスアカウント
認可	部署、プロジェクト、用途、モデル単位の制御
ルーティング	Azure OpenAI、Bedrock、OpenAI、Anthropic などへ振り分け
モデル抽象化	`standard`, `fast`, `reasoning`, `coding` のような論理名を提供
トークン計測	input / output / cached tokens を記録
コスト換算	モデル別単価をもとに概算費用を算出
クォータ	ユーザー / アプリ / 部署ごとの日次・月次上限
レート制限	RPM / TPM / 同時実行数の制限
DLP	PII、秘密情報、認証情報、社外秘文書の検知
Guardrails	禁止内容、出力制御、プロンプトインジェクション対策
ログ	Prompt / Response / Metadata / Trace ID
マスキング	ログ保存前の個人情報・秘密情報マスク
監査	管理者向け検索・エクスポート
可観測性	OpenTelemetry、Prometheus、CloudWatch、Azure Monitor 連携
フェイルオーバー	Azure 障害時に Bedrock へ逃がすなど
キャッシュ	同一プロンプトや埋め込みの再利用
モデル評価	モデル品質・コスト・速度の比較

ここまでが、Azure・AWS を利用する上で企業が実際に検討している統制の全体像です。ここからは、この機能一覧を実際にどう実装するかを、OSS の LiteLLM を例に見ていきます。

10. LiteLLMによる実装: Phase1(アプリ/部署単位)

LiteLLM は、Azure OpenAI、Amazon Bedrock、OpenAI、Anthropic、Vertex AI など複数の LLM を、OpenAI 互換 API として統一的に呼び出せる AI Gateway / Proxy です。

公式にも、OpenAI 互換形式で100以上の LLM プロバイダーを扱う Gateway として説明されています。

全体構成は以下の通りです。

LiteLLM のリクエストフローでは、まず Virtual Key の存在確認と予算チェックを行い、その後にグローバル、Virtual Key、User、Team のレート制限を確認し、最後に LiteLLM Router がロードバランシング、フォールバック、リトライを処理します。

レスポンス後には、利用量・コスト・ログが非同期で DB に記録されます。

ここからは、この LiteLLM を使って、9章で見た「社内 AI Gateway が持つべき機能」を段階的に実装していく流れを見ていきます。まずは Phase1、プロジェクト・アプリ単位の API キーと部署タグによる月次トークン上限の管理から始めます。

10.1 Phase1の目的

Phase1 の目的は、個人単位の厳密な管理よりも先に、社内利用を安全に開始することです。

つまり、最初から全社員 SSO や個人別課金まで作り込まず、まずは以下を実現します。

項目	Phase1で実現すること
認証	プロジェクト/アプリ単位のVirtual Key
費用管理	部署・アプリ・プロジェクト単位の月次上限
モデル制御	アプリごとに利用可能モデルを制限
コスト可視化	key / team / model単位で利用額を見る
暴走防止	RPM / TPM / 月次予算で制限
セキュリティ	実LLMプロバイダーのAPIキーを利用者に渡さない
ログ	プロンプト本文は原則保存せず、メタデータ中心で記録

10.2 Phase1の設計方針

LiteLLM には、Organizations、Teams、Internal Users、Virtual Keys という階層があります。

Team は複数の Internal User を含み、Virtual Key は user_id、team_id、またはその両方に紐づけられます。

Phase1 では、まだ個人単位までは追わないので、基本は以下の設計にします。

Phase1 では、Team = 部署またはプロジェクト、Virtual Key = アプリまたはPoC単位 と考えるのが分かりやすいです。

10.3 Phase1のキー設計

LiteLLM では、Virtual Key によって Spend Tracking とモデルアクセス制御ができます。

Virtual Key を使うには PostgreSQL などの DB と Master Key が必要で、Spend は key、user、team 単位で追跡できます。

Phase1 では、次のようなキーを発行します。以下の sk-* はキー値そのものではなく、LiteLLM の key_alias（キーの識別名）として運用するものです。実際のキー値は別途発行・秘匿管理し、alias だけを台帳や画面表示に使います。

Key名	所有単位	用途	紐づけ
`sk-app-sales-support-prod`	アプリ	営業支援Bot本番	team: 営業DX
`sk-app-contract-review-poc`	PoC	契約書要約PoC	team: 法務DX
`sk-dev-coding-assistant`	開発環境	AIコーディング検証	team: R&D
`sk-batch-minutes-summary`	バッチ	会議議事録要約	team: 業務改革

本番アプリや CI/CD、共有サービスには、個人に紐づかない Service Account Key を使うのが適しています。

LiteLLM の Service Account は、特定ユーザーではなく本番プロジェクト用の Virtual Key を作るための仕組みで、ユーザー削除時にキーが消えず、Team 単位の制限が適用される点が特徴です。

10.4 Phase1のBudget設計

Phase1 では、まず Team Budget を使います。

例:

Team	月次予算	用途
R&D AI Coding	$1,000/月	開発支援
Sales DX	$500/月	営業支援Bot
Legal DX PoC	$300/月	契約書レビューPoC
Back Office	$200/月	議事録・社内文書要約

LiteLLM では Team に max_budget と budget_duration を設定でき、budget_duration="30d" のようにすれば月次相当のリセット運用ができます。

設計イメージは以下です。

10.5 Phase1のモデル設計

クライアント側に実モデル名を直接見せない方が、モデル切り替えやフォールバック時の影響を吸収しやすくなります。

たとえば、アプリには以下のような 論理モデル名 を使わせます。

論理モデル名	実体	用途
`standard-chat`	Azure OpenAI GPT系 / Bedrock Claude系	一般チャット
`fast-chat`	軽量モデル	大量処理
`reasoning`	高性能推論モデル	設計・分析
`coding`	コード生成向けモデル	AIコーディング
`embedding`	Azure / OpenAI / Bedrock embedding	RAG

LiteLLM の config では、同じ model_name に複数のバックエンドを設定してロードバランシングやフォールバックに使えます。

LiteLLM のモデル設定では、deployment ごとに rpm や tpm を設定でき、Rate Limit やロードバランシングに使われます。

サンプルは以下の通りです。

model_list:
  - model_name: standard-chat
    litellm_params:
      model: azure/gpt-4o
      api_base: os.environ/AZURE_OPENAI_API_BASE
      api_key: os.environ/AZURE_OPENAI_API_KEY
      api_version: "2024-10-21"
      rpm: 120
      tpm: 200000

  - model_name: standard-chat
    litellm_params:
      model: bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0
      aws_region_name: ap-northeast-1
      rpm: 60
      tpm: 100000

  - model_name: fast-chat
    litellm_params:
      model: azure/gpt-4o-mini
      api_base: os.environ/AZURE_OPENAI_API_BASE
      api_key: os.environ/AZURE_OPENAI_API_KEY
      api_version: "2024-10-21"

  - model_name: embedding
    litellm_params:
      model: azure/text-embedding-3-small
      api_base: os.environ/AZURE_OPENAI_API_BASE
      api_key: os.environ/AZURE_OPENAI_API_KEY
      api_version: "2024-10-21"

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

litellm_settings:
  set_verbose: false
  json_logs: true

10.6 Phase1のデプロイ構成

本番では PostgreSQL を使う前提にするのがよいです。

LiteLLM 公式ドキュメントでも、本番デプロイでは PostgreSQL が主要サポート DB とされ、Virtual Key や Spend Tracking には DB 接続が必要とされています。

小さく始めるなら VM + Docker Compose でもよいですが、社内基盤として使うなら以下が望ましい構成です。

公式の Production Best Practices では、DB コネクション数、Slack アラート、batch write、デバッグログ抑制、JSON ログなどが推奨設定として示されています。

また、1000 RPS 以上の高トラフィックでは Redis が必要とされ、DB 接続枯渇やデッドロック対策として Redis を使う構成が説明されています。

10.7 Phase1で作るべき管理テーブル

LiteLLM の DB だけでも基本の運用はできますが、社内管理には薄い業務テーブルを別に持つと運用しやすくなります。

テーブル	内容
`llm_projects`	プロジェクトID、名称、責任者、部署、費用コード
`llm_apps`	アプリID、環境、用途、本番/検証区分
`llm_api_keys`	LiteLLM Virtual Keyのalias、team_id、app_id
`llm_budget_policy`	月次予算、TPM/RPM、許可モデル
`llm_approval`	申請者、承認者、承認日、データ区分
`llm_cost_allocation`	月次の部署別・アプリ別費用配賦

LiteLLM の Virtual Key metadata には、以下を入れておくとよいです。

{
  "department": "R&D",
  "project_id": "poc-agent-runtime",
  "app_id": "coding-assistant",
  "env": "dev",
  "cost_center": "RD-AI-001",
  "data_class": "internal"
}

ただし、クライアントが自由に metadata.tags を送れる設計にすると、利用者がタグを変えて予算や監査を回避できてしまうリスクがあります。

LiteLLM には reject_clientside_metadata_tags があり、クライアント側の metadata.tags を拒否して、API キー側の metadata だけを信頼する設定ができます。運用に乗せる際は、この設定を有効化しておくと改ざんリスクを抑えられます。

10.8 Phase1のログ設計

Phase1 では、プロンプト全文を保存しない運用から始めるのが安全です。

LiteLLM の UI Logs では、成功ログ・エラーログはデフォルトで追跡されますが、Request/Response 本文はデフォルトでは保存されず、store_prompts_in_spend_logs を有効化した場合のみ保存されます。

推奨は以下の通りです。

ログ項目	Phase1
user_id	原則なし。アプリIDのみ
team_id	保存
key_alias	保存
model	保存
prompt tokens	保存
completion tokens	保存
estimated cost	保存
latency	保存
status code	保存
prompt本文	原則保存しない
response本文	原則保存しない
trace_id	保存
data_class	保存

Prometheus 連携では、LiteLLM は Spend、total tokens、input tokens などを end_user、hashed_api_key、api_key_alias、model、team、user などのラベルで出力できます。

10.9 Phase1の完成条件

Phase1 の完了条件は、以下の通りです。

項目	完了条件
Gateway	LiteLLM経由でAzure OpenAI / Bedrockを呼べる
APIキー	アプリ/プロジェクト単位でVirtual Key発行
予算	Team単位で月次予算設定
モデル制限	Keyごとに許可モデルを制限
レート制限	RPM / TPMを設定
可視化	key/team/model別のSpendを確認可能
監査	少なくとも誰のアプリキーで使ったか分かる
セキュリティ	プロバイダーAPIキーを開発者に渡さない
ログ方針	プロンプト本文は原則保存しない

11. LiteLLMによる実装: Phase2(ユーザー単位・SSO)

11.1 Phase2の目的

Phase2 では、Phase1 の「アプリ単位管理」を壊さずに、ユーザー単位の帰属を追加します。

つまり、同じアプリキーを使っていても、以下を追えるようにします。

誰が使ったか
どの部署の人か
どのプロジェクト文脈か
どのセッションか
どの操作画面から呼んだか
どのチケット・案件・会議・文書に紐づくか

11.2 Phase2で追加する構成

LiteLLM には Admin UI 向けの SSO 設定があり、Okta などの OIDC アプリを作成し、https://<proxy-base-url>/sso/callback をリダイレクト URI に設定する流れが説明されています。

一方で、SSO、SCIM、OIDC/JWT Auth、Team/Org Admin、Key/Team-based Guardrails などは Enterprise 機能として提示されています。この点は導入前に確認しておく必要があります。

そのため、Phase2 には現実的に3つのパターンがあります。

11.3 Phase2の実装パターン

パターンA: アプリ側でSSOし、LiteLLMには `user` パラメータを渡す

最も導入しやすい方式です。

業務アプリ側は Entra ID や Okta でログイン済みなので、LiteLLM にリクエストする際に user を渡します。

LiteLLM では、/chat/completions の user パラメータを使ってユーザー別 Spend Tracking ができます。

公式の Spend Tracking 例でも、user="palantir" のように指定してユーザー単位で追跡する例が示されています。

例:

{
  "model": "standard-chat",
  "user": "tanaka.jiro@company.example",
  "messages": [
    {
      "role": "user",
      "content": "この設計をレビューしてください"
    }
  ],
  "metadata": {
    "session_id": "sess-20260706-001",
    "trace_id": "trace-abc123",
    "tags": [
      "department:R&D",
      "project:agent-runtime",
      "app:design-review",
      "env:prod"
    ]
  }
}

この方式のメリットは、既存の業務アプリに組み込みやすいことです。

デメリットは、クライアントが渡す user や metadata を信用しすぎると改ざんの余地があることです。

そのため、業務アプリや中間 Adapter で SSO 済み情報からサーバー側で注入し、クライアント入力をそのまま使わない設計にすることが望ましいです。

なお、上のサンプルでは分かりやすさのため user にメールアドレスを直接入れていますが、実運用ではメールアドレスより Entra ID の oid のような不透明な ID を使う方が安全です。メールアドレスはログや外部 Observability（Langfuse、Prometheus 等）に転記される可能性があり、そこから漏えいすると個人情報の流出につながります。oid を主キーにして、メールアドレスとの対応表は別途権限制限された内部システムで管理する構成が望ましいです。

パターンB: User + Team Keyを発行する

LiteLLM の RBAC では、Virtual Key は user_id のみ、team_id のみ、または user_id + team_id の両方に紐づけられます。

User + Team Key は、Team 予算内で個人の accountability を持たせたい場合に使うものとして説明されています。

この方式では、各ユーザーに自分のキーを発行します。

メリット	デメリット
ユーザー単位の追跡が明確	キー管理が増える
開発者向けには使いやすい	退職・異動時の棚卸しが必要
Team予算と個人利用を両方見られる	SSO自動発行なしだと運用が重い

AI コーディングツールや開発者向け API では、個人単位の accountability が重要になるため、この方式が向いています。

パターンC: OIDC/JWT Authで一時トークン化する

最もエンタープライズ向けの方式です。

ユーザーは Entra ID / Okta でログインし、社内 Gateway または LiteLLM 側で JWT を検証し、claim から以下を取り出します。

claim	用途
`sub`	ユーザー一意ID
`email`	監査用ユーザーID
`groups`	部署・権限判定
`department`	費用配賦
`cost_center`	会計連携
`project_id`	プロジェクト予算
`session_id`	セッション監査
`purpose`	利用目的

LiteLLM の設定には enable_jwt_auth、enforce_user_param、allowed_routes などの JWT/Auth 関連設定があり、enforce_user_param では OpenAI endpoint リクエストに user パラメータを必須化できます。

この方式では、アプリ側は固定 API キーではなく、SSO に基づく一時的な認証情報を使います。

11.4 Phase2におけるsession tagの考え方

ここでいう session tag は、AWS STS の session tag そのものに限定せず、SSO 済みユーザーの利用文脈を LLM リクエストに伝播するための監査属性 と捉えると、LiteLLM の metadata.tags や Langfuse のトレース属性への割り当てが分かりやすくなります。

例:

{
  "user": "user12345",
  "metadata": {
    "session_id": "session-20260706-143000-xyz",
    "trace_id": "trace-9f8e7d",
    "tags": [
      "department:R&D",
      "cost_center:RD-AI-001",
      "project:bizplan",
      "app:ai-coding",
      "environment:prod",
      "data_class:internal",
      "purpose:code-review"
    ]
  }
}

Langfuse 連携では、LiteLLM Proxy 経由の LLM call について、token usage、cost、latency をリクエスト単位で取得でき、userIds、tags、sessionIds などの属性を追加してトレースをグルーピングできます。

Phase2 では、session tag を以下のように使います。

tag	用途
`user_id`	個人単位の監査
`department`	部署別費用配賦
`cost_center`	会計処理
`project_id`	プロジェクト予算
`app_id`	アプリ別費用
`session_id`	一連の会話・作業単位
`trace_id`	分散トレース
`data_class`	情報区分
`purpose`	利用目的
`client_type`	Cursor / Web app / Batch / API

11.5 Phase2の予算設計

Phase2 では、予算を3階層にします。

LiteLLM は、Global Proxy、Team、Team Members、Internal User、Virtual Key、Customer など複数単位で Budget / Rate Limit を設定できる構造を持っています。

ユーザーに対しては user を渡して予算を適用する方式もあり、LiteLLM のドキュメントでは、Budget を作成し、Customer に紐づけ、/chat/completions に user を渡す手順が示されています。

推奨設計は以下の通りです。

階層	例	目的
Global	全社 $50,000/月	全社上限
Team	R&D $5,000/月	部署別配賦
App	coding-assistant $2,000/月	アプリ別上限
User	userA $100/月	個人暴走防止
Session	1セッション $2	Agent暴走防止

特に Agent や AI コーディングでは、1回のタスクで何十回も LLM を呼ぶため、session 単位の上限 が重要になります。ただし、この session-level cap は通常の /chat/completions にそのまま効く汎用機能ではなく、LiteLLM の Agent Gateway 向け機能（max_budget_per_session 等）に該当するものです。通常の LLM 呼び出しでセッション単位の予算制御を実現するには、業務アプリや Auth Adapter 側で session_id を発行・追跡し、外部の Policy Engine やミドルウェアで上限をチェックする実装が前提になります。

11.6 Phase2の監査ログ設計

LiteLLM には Audit Logs 機能があり、store_audit_logs: true を設定すると、キー削除などの変更を UI で確認でき、S3 など外部ストレージへ非同期エクスポートする設定も可能です。

Phase2 では、監査ログを次の4種類に分けて考えます。

ログ種別	内容	保存先
管理操作ログ	key発行、削除、budget変更、team変更	LiteLLM DB + S3/SIEM
利用ログ	user、team、model、token、cost、trace_id	LiteLLM DB + Prometheus/Langfuse
セキュリティログ	DLP検知、禁止モデル、拒否リクエスト	SIEM
生成内容ログ	prompt/response本文	原則保存しない。必要時のみマスキング保存

LiteLLM では、ログ連携時に User API Key 情報、hashed token、user_id、team_id などを redact する設定もあります。

Langfuse、OpenTelemetry、Logfire、ArizeAI logging でサポートされています。

11.7 Phase2のSSO連携設計

企業で使うなら、Entra ID を前提に以下のように設計します。

Claim Mapper でやることは以下の通りです。

入力	変換先
Entra `oid`	LiteLLM `user_id`
Entra `mail`	監査用email
Entra `department`	`team_alias`
Entra `groups`	許可モデル・管理権限
社内人事DB	cost_center
業務アプリ	project_id / app_id
セッション管理	session_id / trace_id

12. Phase1→Phase2移行手順とロードマップ

重要なのは、Phase1 のキー体系を捨てないことです。Phase2 は Phase1 の上に積み重ねる形で設計します。

12.1 移行手順

Step1: Phase1でTeamとApp Keyを作る

Step2: Phase2でUser属性を追加する

Step3: User Budgetを追加する

Step4: Observabilityで個人・部署・アプリ単位に集計する

集計軸	Phase1	Phase2
app_id	あり	あり
team_id	あり	あり
user_id	なし	あり
session_id	任意	必須
cost_center	metadata	SSO/人事DB連携
purpose	任意	必須
data_class	任意	必須

12.2 実装ロードマップ

Phase1-1: 最小構成

作業	内容
LiteLLM起動	Docker or Helm
DB	PostgreSQL接続
Master Key	管理者用key設定
Azure/Bedrock接続	model_list設定
Virtual Key	アプリ単位で発行
Team	部署/プロジェクト単位で作成
Budget	Teamごとに月次上限
Logs	spend/token/model/keyを記録
Prompt保存	無効のまま

Phase1-2: 社内利用可能な状態

作業	内容
内部DNS	`https://llm-gateway.company.local`
TLS	社内証明書 or Private CA
Reverse Proxy	Nginx / APIM / ALB
IP制限	社内ネットワーク/VPNのみ
モデル名抽象化	`standard-chat`, `fast-chat`, `coding`
APIキー棚卸し	owner, app, env, cost_centerを管理
Dashboard	Prometheus/Grafana or Langfuse
Alert	月次予算80%、95%、100%で通知

Phase2-1: ユーザー帰属追加

作業	内容
SSO済みアプリ対応	app側で `user` をLiteLLMへ渡す
`enforce_user_param`	user未指定を拒否
session_id	すべてのリクエストに付与
trace_id	アプリログとGatewayログを紐付け
user budget	個人ごとの上限を設定
user dashboard	個人/部署/アプリ別利用量を可視化

Phase2-2: SSO/JWT統合

作業	内容
Entra ID連携	OIDC / JWT
Claim Mapping	user/team/cost_center/projectへ変換
一時トークン	固定APIキーから段階的に移行
グループ制御	Entra groupでモデル許可
監査強化	SIEM連携
DLP連携	禁止情報検知
例外申請	高額モデル・高機密用途の承認

12.3 Phase1/Phase2の違い

項目	Phase1	Phase2
認証単位	アプリ/プロジェクトAPIキー	ユーザー + アプリ + セッション
主なキー	Service Account Key	User Key / JWT / user param
費用配賦	部署・アプリ単位	部署・アプリ・個人単位
監査	どのアプリが使ったか	誰が・何の目的で使ったか
SSO	不要または管理UIのみ	Entra ID / Okta連携
session tag	任意	必須
DLP	Gateway前段または簡易	ユーザー/用途別ポリシー
ログ	token/cost中心	user/session/trace中心
対象	PoC、本番アプリ初期	全社展開、本番統制

12.4 推奨する最終アーキテクチャ

これまでの整理を踏まえると、最初に作るべきは以下の5点です。

LiteLLM + PostgreSQL + Azure OpenAI / Bedrock接続
Team = 部署/プロジェクト、Virtual Key = アプリ単位
Team Budget + RPM/TPM + モデル許可リスト
Prometheus または Langfuse で token/cost/latency 可視化
Phase2に備えて、すべてのリクエストに app_id, team_id, trace_id を付ける

その後、Phase2 で以下を足していきます。

SSO済みユーザーIDを user に入れる
session_id, cost_center, purpose, data_class をmetadataに入れる
enforce_user_param を有効化する
ユーザー別Budgetを設定する
SIEM / 監査ログ / DLPと連携する

最初から SSO/JWT まで作り込むと、構築の負荷も運用の負荷も重くなります。そのため現実的には、Phase1で LiteLLM の Team + Service Account Key + Team Budget から開始し、Azure OpenAI / Bedrock / Anthropic / OpenAI を1つの社内 OpenAI 互換 API に統一するところから始める進め方が現実的です。

Phase2では、業務アプリ側またはAuth Adapterで SSO済みユーザー情報を注入し、LiteLLM には user、metadata.session_id、metadata.tags を渡して、個人・部署・アプリ・セッション単位の監査と費用配賦に広げていきます。

特に社内AIコーディング基盤として使うなら、Phase1の時点で次の統制を先に作っておくことが重要です。

プロバイダーAPIキーを開発者に渡さない
個人のOpenAI/Anthropicキーを使わせない
必ず社内Gatewayを通す

その上で、Phase2でEntra ID連携とUser Budgetを足すのが、最も安全で移行もしやすい進め方です。

13. 実装候補の比較

社内 AI Gateway には、LiteLLM 以外にもいくつかの選択肢があります。

候補	特徴
Azure API Management AI Gateway	Azure 中心の企業では最も自然。Entra ID、Azure Monitor、Private Link と統合しやすい
AWS Multi-Provider Generative AI Gateway	AWS 中心の企業で Bedrock を軸にする場合に有力
LiteLLM	OSS でマルチプロバイダー対応。OpenAI互換API、コスト集計、モデルルーティングに強い
Portkey	LLM Gateway / observability / guardrails 系のSaaS
Kong / Envoy / NGINX + 自作	既存API Gateway基盤がある企業向け
自社開発	要件が複雑な企業向け。SSO、DLP、費用配賦、監査と深く統合できる

どの候補を選ぶかは、すでに Azure か AWS のどちらかに強く依存しているか、マルチクラウド・マルチプロバイダーを前提にするか、SSO や DLP まで含めてどこまで自前で作り込む余力があるかによって変わってきます。LiteLLM は OSS でありながら、Phase1からPhase2への段階的な拡張がTeam/User/Virtual Keyの階層構造にそのまま乗るため、まず小さく始めて後から広げたい企業には合いやすい選択肢だと考えています。

まとめ

ここまで見た内容を踏まえると、企業でのLLM管理はだいたい次の形に収束しつつあります。

領域	実装の中心
利用者制限	SSO、RBAC / IAM、部署・プロジェクト単位の権限
モデル制限	モデル許可リスト、高額 / 高リスクモデルの別承認
コスト管理	トークン計測、ユーザー / 部署別配賦、月次上限、アラート
セキュリティ	Private Link、DLP、PII 検知、Guardrails、Content Safety
監査	Prompt / Response / Token / Model / Trace ID のログ
開発者管理	社内 OpenAI 互換 Gateway、個人 API キー禁止、AI コーディングツール統制
本番運用	Gateway 経由、監視、レート制限、サーキットブレーカー、SLA 設計

社内導入の初期段階では、Azure API Management AI Gateway か LiteLLM ベースの社内 LLM Gateway を置き、Azure OpenAI と Amazon Bedrock を両方バックエンドにするのが妥当な選択になります。

その上で、最初は利用者単位ではなく、まず プロジェクト / アプリ単位の API キー + 部署タグ + 月次トークン上限 から始めるのが現実的です。

ユーザー単位の課金・監査は、第2段階で SSO 連携と session tag に広げていくのがよいでしょう。

LiteLLM を例に見た通り、この2段階のアプローチは「アプリ単位で安全に使わせる（Phase1）」→「誰が使ったかまで追える（Phase2）」という進化として設計でき、Team・Virtual Key・User という階層構造のおかげで、Phase1の設計を壊さずにPhase2へ拡張できます。最初から抜け漏れのない統制を目指すのではなく、まず安全に使い始められる最小構成を作り、実運用で見えてきた要件に応じて段階的に広げていくアプローチが、現実的な進め方です。

参考文献

Microsoft Learn: Azure API Management の GenAI Gateway 機能 https://learn.microsoft.com/ja-jp/azure/api-management/genai-gateway-capabilities
AWS Solutions: Multi-Provider Generative AI Gateway on AWS https://docs.aws.amazon.com/solutions/multi-provider-generative-ai-gateway-on-aws/
Microsoft Learn: Azure OpenAI role-based access control https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/role-based-access-control
Microsoft Learn: Plan and manage costs for Azure AI Foundry https://learn.microsoft.com/en-us/azure/foundry/concepts/planning
AWS Docs: Amazon Bedrock identity-based policy examples https://docs.aws.amazon.com/bedrock/latest/userguide/security_iam_id-based-policy-examples.html
Microsoft Learn: Azure OpenAI monitoring reference https://learn.microsoft.com/en-us/azure/foundry/openai/monitor-openai-reference
Microsoft Learn: Monitor Azure OpenAI https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/monitor-openai
AWS Docs: Amazon Bedrock cost management https://docs.aws.amazon.com/bedrock/latest/userguide/cost-management.html
AWS Docs: Track Amazon Bedrock cost by IAM principal https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-iam-principal-tracking.html
AWS Blog: Build a proactive AI cost management system for Amazon Bedrock https://aws.amazon.com/blogs/machine-learning/build-a-proactive-ai-cost-management-system-for-amazon-bedrock-part-1/
Microsoft Learn: Azure OpenAI networking https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/network
AWS Docs: Use Amazon Bedrock with AWS PrivateLink https://docs.aws.amazon.com/bedrock/latest/userguide/usingVPC.html
AWS Docs: Amazon Bedrock Guardrails permissions https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-permissions.html
Microsoft Learn: Azure OpenAI data privacy and security https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy
AWS Docs: Data protection in Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html
AWS Docs: Data retention in Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html
AWS Docs: Model invocation logging https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html
AWS Blog: Optimize LLM costs on Amazon Bedrock https://aws.amazon.com/blogs/aws-cloud-financial-management/optimize-llm-costs-on-amazon-bedrock-from-billing-attribution-to-operational-telemetry/
LiteLLM GitHub https://github.com/BerriAI/litellm
LiteLLM Proxy Architecture https://docs.litellm.ai/docs/proxy/architecture
LiteLLM Access Control https://docs.litellm.ai/docs/proxy/access_control
LiteLLM Virtual Keys https://docs.litellm.ai/docs/proxy/virtual_keys
LiteLLM Service Accounts https://docs.litellm.ai/docs/proxy/service_accounts
LiteLLM Team Budgets https://docs.litellm.ai/docs/proxy/team_budgets
LiteLLM Proxy Configs https://docs.litellm.ai/docs/proxy/configs
LiteLLM Proxy Deploy https://docs.litellm.ai/docs/proxy/deploy
LiteLLM Production Best Practices https://docs.litellm.ai/docs/proxy/prod
LiteLLM Config Settings https://docs.litellm.ai/docs/proxy/config_settings
LiteLLM UI Logs https://docs.litellm.ai/docs/proxy/ui_logs
LiteLLM Prometheus Integration https://docs.litellm.ai/docs/proxy/prometheus
LiteLLM Admin UI SSO https://docs.litellm.ai/docs/proxy/admin_ui_sso
LiteLLM Enterprise https://www.litellm.ai/enterprise
LiteLLM Cost Tracking https://docs.litellm.ai/docs/proxy/cost_tracking
LiteLLM Users / Customer Budget https://docs.litellm.ai/docs/proxy/users
LiteLLM Multiple Admins / Audit Logs https://docs.litellm.ai/docs/proxy/multiple_admins
LiteLLM Logging https://docs.litellm.ai/docs/proxy/logging
Langfuse LiteLLM Integration https://langfuse.com/integrations/gateways/litellm