LLM Gateway 製品ガイド — 用途・OSS/有償・機能・AWS 構成¶
作成日: 2026-09-15 出典 / きっかけ: llm_gateway_組織ガバナンス_国内外事例_整理 の続き。「で、結局どの製品を使うのか・いくらかかるのか・AWS でどう組むのか」を一次資料で確認した回 関連: llm_gateway_組織ガバナンス_国内外事例_整理 / layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理 / 社内mcp共通基盤_認証認可ログ_整理 / ai_ガバナンス_誰がnoと言えるか_整理 / エアークローゼット_46リポジトリ知識グラフとllm_observability_整理
0. 要点（3行）¶
- 選択肢は「OSS を自前運用」対「マネージド」の二択ではなく、実際には OSS 本体は無料 / ガバナンス機能だけ有償 という共通の切り方をしている。LiteLLM・Kong・Portkey いずれも、ルーティングやフォールバックといった技術的な機能は無料で、SSO・監査ログ・PII・トークン単位のレート制限といった「組織で使うための機能」が有償の壁の向こうにある。つまり課金ラインは機能の難易度ではなく「個人で使うか、組織で統制するか」に引かれている。
- 迷ったら LiteLLM（MIT・100+ provider・AWS 公式 Guidance が LiteLLM 前提）。ただし Python ランタイムなので高負荷でのオーバーヘッドが弱点で、そこが効く規模なら Go 製の Bifrost や Envoy ベースの Agent Router を測って選ぶ。Claude Code だけなら Claude apps gateway が無料で、そもそも製品選定が要らない。
- AWS には公式のリファレンス実装がある — 「Guidance for Multi-Provider Generative AI Gateway on AWS」が CDK / Terraform で LiteLLM を ECS Fargate か EKS に立てる構成を配布している。ゼロから設計しない。
1. 何のために置くのか（利用目的・用途）¶
1-1. 用途は 5 つに割れる¶
| # | 用途 | 誰が嬉しいか | これだけなら gateway は要るか |
|---|---|---|---|
| ① 鍵の集約 | provider の鍵をサーバ側に閉じ、開発者には gateway の資格情報だけ渡す | セキュリティ / 情シス | 要る（これが本命） |
| ② コスト統制 | ユーザー・チーム・プロジェクト別の予算上限と可視化 | 管理職 / FinOps | 要る（上限を効かせるなら） |
| ③ モデルの抽象化 | アプリを書き換えずにモデル・provider を差し替える | アプリ開発者 | 要る |
| ④ 信頼性 | フォールバック・リトライ・ロードバランス・レート制限回避 | アプリ開発者 / SRE | 要る |
| ⑤ 監査・コンプライアンス | 全リクエストの記録、PII マスク、ガードレール | 法務 / 監査 | 要る |
※ 「どのモデルが安いか比較したいだけ」なら gateway は過剰。それは評価基盤（Langfuse 等）の仕事。gateway は通り道に立って強制するのが価値で、見るだけなら OpenTelemetry で足りる。cf. llm_gateway_組織ガバナンス_国内外事例_整理 の §7
1-2. トラフィックの種類で要件が変わる¶
同じ gateway でも、通すものによって効く機能が違う。ここを混ぜて設計すると失敗する。
| 通すもの | 特徴 | 効く機能 |
|---|---|---|
| アプリケーション（自社プロダクトの LLM 機能） | リクエストが定型・量が読める | セマンティックキャッシュ、フォールバック、レイテンシ |
| コーディングエージェント（Claude Code / Copilot / Cursor） | 巨大なプロンプト・長時間・バースト。1人が1日で数十ドル使う | 人単位の予算上限、プロンプトキャッシュ、大きいボディの許容（Kong 検証では上限を 512KB へ引き上げ） |
| 非エンジニアの社内チャット | 少量・多人数・PII 混入リスク大 | PII マスク、監査ログ、モデル allowlist |
| バッチ / 評価ジョブ | 大量・非同期。オンラインのクォータを食う | 専用キー・キュー分離（Grab が課題として明記） |
2. 機能の全体像（何がある製品なのか）¶
gateway の機能は 6 レイヤに整理できる。製品比較はこの粒度で見ると横並びになる。
| レイヤ | 機能 | 補足 |
|---|---|---|
| ① 統一 API | OpenAI 互換 / Anthropic 互換のインタフェース、provider 間の形式変換 | 「アプリを書き換えずに差し替え」の土台。どの形式を喋るかでクライアント設定が provider に縛られるか決まる |
| ② 認証・認可 | 仮想キー（Virtual Key）、SSO / OIDC、SCIM、チーム/組織、モデル allowlist | 有償の壁が立つのはほぼここ |
| ③ コスト・流量 | 予算上限（日/週/月）、レート制限（RPM/TPM）、ロードバランス、コスト按分 | トークン単位のレート制限は有償なことが多い（Kong は明確に Enterprise） |
| ④ 信頼性 | フォールバック、リトライ、複数 provider 間の冗長化、キャッシュ（完全一致 / セマンティック） | セマンティックキャッシュは有償寄り |
| ⑤ 安全性 | PII マスク、プロンプトインジェクション検知、入出力フィルタ、シークレット検知 | OSS は Presidio 連携等で自作余地あり |
| ⑥ 可観測性 | リクエストログ、監査ログ、Prometheus / OTLP、ダッシュボード | ログ保持期間がマネージド課金の主軸 |
3. メリット / デメリット¶
メリット¶
| 効くところ | 具体的に |
|---|---|
| offboarding が 1 本の revoke で済む | 退職・異動時に provider 鍵を回収して回る運用が消える。最大の実利 |
| モデル差し替えのコストが「設定変更」になる | Okta のアーキテクトいわく「コード変更・調達サイクル・セキュリティレビューの再実施が不要」。技術ではなく手続きのコストが消えるのが本体 |
| 上限を効かせられる | 可視化だけの手法と違い、超過したら止まる（429）。暴走エージェント1台が全社コミットを溶かす事故を防ぐ |
| 計測点が 1 つになる | ツールが増え続けても（Claude Code / Copilot / Cursor / Codex…）見る場所は 1 つ |
| PII 処理をアプリから剥がせる | Uber は redact / un-redact を gateway の責務にして、アプリに PII 対応を書かせない |
デメリット（見落としがち）¶
| コスト | 具体的に |
|---|---|
| 単一障害点になる | 全 LLM トラフィックが通る。gateway の可用性 = 全社の AI 可用性。Claude apps gateway は DB 障害時に fail-open か fail-close かを設定で選ばせている |
| 追従コストが恒久的にかかる | クライアント側（Claude Code 等）は毎リリースで機能が増え、gateway が新ヘッダを転送しないとその機能が壊れる。Anthropic 公式も「gateway 製品を更新し続ける必要がある」と明記。Grab も「SDK 固有のエッジケースや未実装パスが出続ける」を課題に挙げている |
| レイテンシが乗る | Bifrost が「5k RPS で 11µs」を売りにするのは裏返せばここが差別化点になる程度には効くということ（※自社ベンチ） |
| 請求の粒度が落ちることがある | 共有アップストリーム鍵を使う構成では、provider 側の請求書から個人が消える。gateway 側の計測で持つ設計に切り替わる |
| 運用者が要る | クォータ障害・provider 障害の on-call 経路、spend ログと請求の突合を誰が持つか |
4. 製品マップ — OSS（自前ホスト）¶
| 製品 | ライセンス | 実装 | provider 数 | 無料に含まれるもの | 有償の壁 | 向く相手 |
|---|---|---|---|---|---|---|
| LiteLLM | MIT | Python | 100+ | 仮想キー、ユーザー/チーム、予算・支出追跡、レート制限、フォールバック、req/res ログ、Prometheus | SSO + SCIM、OIDC/JWT、監査ログ、シークレットマネージャ連携と鍵ローテーション、組織/チーム管理者、マルチリージョン制御プレーン、エアギャップ、SLA 付きサポート | 迷ったらここ。provider 網羅性と実績。AWS 公式 Guidance も LiteLLM 前提 |
| Portkey Gateway | MIT | TypeScript | 45+（1,600+ モデル） | ルーティング、フォールバック、リトライ、ロードバランス、ガードレール、基本ダッシュボード | セマンティックキャッシュ、プロンプト管理、高度な可観測性、組織統制（※README は v2.0 で Enterprise 機能の OSS 統合を示唆） | 軽量・設定ファイル志向。Node 系スタック |
| Agent Router（旧 Envoy AI Gateway） | Apache 2.0 | Go / Envoy | 16 | provider ルーティング、チーム/アプリ/モデル別トークン上限、フォールバック、モデル名の仮想化、MCP ルーティング | （ホスト版 Tetrate Agent Router Service） | 既に Kubernetes / Envoy がある組織。CRD で宣言的に管理 |
| Bifrost | Apache 2.0 | Go | 23+ | フェイルオーバー、ロードバランス、セマンティックキャッシュ、階層的な予算管理、レート制限、MCP、Prometheus・分散トレース | adaptive load balancing、クラスタリング、ガードレール等の Enterprise | 性能が効く規模。自社ベンチで「5k RPS・11µs 追加レイテンシ」 |
| Kong AI Gateway | Apache 2.0（本体） | Lua / OpenResty | — | AI プラグイン 6 種（3.6 / 2024-02 以降）: LLM プロキシ、プロンプトガード、req/res 変換 | AI Proxy Advanced、AI Semantic Cache、AI Rate Limiting Advanced（＝トークン単位の制限）、AI Semantic Prompt Guard、AI PII Sanitizer、AI MCP Proxy、AI LLM-as-Judge | 既に Kong を運用中なら自然な拡張 |
| Claude apps gateway | Anthropic 提供（claude バイナリ同梱） |
— | Claude のみ | SSO（OIDC）、IdP グループ別モデル allowlist、managed settings 配信、spend limit、OTLP 中継、マルチクラウドのフェイルオーバー | — | Claude Code だけで良いなら最短。ただし Claude 以外へのルーティングは非対応 |
選定の勘所: provider 網羅性なら LiteLLM、性能なら Bifrost、既存基盤との統合なら Agent Router / Kong、Claude 専用なら Claude apps gateway。「OSS だから無料」ではなく「OSS の どこまで が無料か」で比較する。
5. 有償・マネージド¶
| 製品 | 形態 | 価格（2026-09 時点・公式） | 何を買っているのか |
|---|---|---|---|
| LiteLLM Enterprise | 自前ホスト + ライセンス | 年額・リクエスト容量ベース（トークン課金ではない）。公開価格なし・要商談。30日間の Enterprise トライアルキーあり（クレカ不要） | SSO/SCIM、監査ログ、鍵ローテーション、エアギャップ、最大 24/7 の SLA |
| Portkey | マネージド（Enterprise は VPC 可） | Developer $0（月 10k ログ・保持3日）/ Production $49/月（月 100k ログ・超過 $9 per 100k・保持30日）/ Enterprise 要商談（月 1,000万ログ〜） | ログ保持量が課金軸。Enterprise で SSO・SOC2 Type2 / GDPR / HIPAA・VPC |
| Kong Enterprise / Konnect | 自前ホスト or SaaS | 要商談 | 上表の Enterprise 専用 AI プラグイン群。トークン単位のレート制限が要るならここが分岐点 |
| Cloudflare AI Gateway | 完全マネージド | 全プランで利用可（無料プラン含む） | 分析・ログ・キャッシュ・レート制限・リトライ/フォールバック。自前運用ゼロが最大の価値 |
| Tetrate Agent Router Service | マネージド（Agent Router のホスト版） | 要商談 | OSS 版の運用を肩代わり |
| Claude apps gateway | 自前ホスト | 追加費用なし（推論費は provider へ） | Claude Code 専用の統制。PostgreSQL の運用だけ自前 |
⚠ 第三者が出している価格推計は割り引いて読む。LiteLLM Enterprise を「$250〜$2,500/月」とする記事があるが、出典は競合ベンダー（TrueFoundry）のブログで、LiteLLM 公式は価格を公開していない。
6. AWS での構成¶
6-1. AWS 公式リファレンス（そのまま使える）¶
Guidance for Multi-Provider Generative AI Gateway on AWS — CDK / Terraform で LiteLLM Proxy を ECS(Fargate) か EKS に配る公式構成。自前設計する前にこれを読む。
[クライアント / 社内ツール]
Claude Code・Copilot・自社アプリ
│ HTTPS（OpenAI 互換 or Bedrock 形式）
▼
┌───────────────────────────────────────────────┐
│ ① Route 53 → CloudFront → AWS WAF │ ← 公開面の保護
└───────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ ② ALB（ACM の TLS 証明書で終端） │
└───────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ ③ ECS on Fargate / EKS │
│ ├── LiteLLM Proxy コンテナ │ ← 本体
│ └── API/middleware コンテナ │ ← Bedrock ネイティブ I/F、
│ （イメージは ECR から） │ Managed Prompts、チャット履歴、
└───────────────────────────────────────────────┘ Okta OAuth2 JWT 認証を追加
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────┐ ┌──────────────────┐
│ ⑥ ElastiCache│ │ ⑥ RDS │ │ ⑥ Secrets Manager│
│ (Redis OSS) │ │(Postgres)│ │ provider 鍵 │
│ 設定配布・ │ │仮想キー・ │ │ │
│ プロンプト │ │設定の永続化│ │ │
│ キャッシュ │ │ │ │ │
└──────────────┘ └──────────┘ └──────────────────┘
│
▼ ⑦ S3（アプリ/監査ログ）→ CloudWatch Logs
── 推論先 ────────────────────────────────────────
④ Amazon Bedrock（+ Nova）/ SageMaker AI ← ガードレール・
⑤ 外部 provider（OpenAI / Anthropic / Vertex） プロンプトキャッシュも活用
※ ⑤ は LiteLLM Admin UI から追加
各コンポーネントの役割:
| # | サービス | 役割 |
|---|---|---|
| ① | Route 53 / CloudFront / WAF | エンドポイント公開と、一般的な Web エクスプロイト・ボットからの保護 |
| ② | ALB + ACM | ECS タスク / EKS ポッドへの分散。TLS 終端 |
| ③ | ECS on Fargate / EKS + ECR | LiteLLM 本体と API/middleware をコンテナ実行。middleware が OSS 版に無い Bedrock 機能を補う |
| ④ | Bedrock / SageMaker AI | モデル本体。Bedrock 側のガードレール・プロンプトキャッシュ・ルーティングも併用できる |
| ⑤ | 外部 provider | LiteLLM Admin UI から追加。既存設定は LiteLLM API で取り込み |
| ⑥ | ElastiCache(Redis) / RDS / Secrets Manager | 設定配布とプロンプトキャッシュ / 仮想キーと設定の永続化 / provider 鍵の保管 |
| ⑦ | S3 → CloudWatch | ログの保管と分析 |
6-2. 最小構成（PoC・小規模）¶
公式 Guidance はフル装備なので、検証や小規模ならここまで要らない。落とせるもの:
[クライアント] → [ALB] → [ECS Fargate: LiteLLM 1〜2 タスク] → [Bedrock]
├── RDS（Aurora Serverless v2 でも可）… 仮想キー永続化に必須
└── Secrets Manager … provider 鍵
- CloudFront / WAF は社内限定なら省略可（ALB を internal にして VPN / PrivateLink 経由）
- ElastiCache はキャッシュが要らなければ後回し。ただし複数タスクで設定を共有するなら要る
- 規模の目安: Zalando は 250+ チーム / 月間 2,000 MAU を 6 pod（各 2 CPU・4GB） で捌いている。gateway 自体は驚くほど軽い
- 注意: コーディングエージェントを通すならリクエストボディ上限を上げる（Kong の検証例では 512KB）。ALB 自体に上限は無いが、間に挟むプロキシ設定で詰まる
7. 選び方の早見表¶
| 状況 | 推奨 | 理由 |
|---|---|---|
| Claude Code だけ統制したい | Claude apps gateway | 無料・claude バイナリ同梱。製品選定が不要 |
| AWS で複数 provider・複数ツール | LiteLLM（AWS 公式 Guidance をベースに） | CDK/Terraform が配られており、ゼロから設計しなくていい |
| 既に Kubernetes / Envoy 基盤がある | Agent Router（旧 Envoy AI Gateway） | CRD で宣言的に管理。既存の Envoy 運用に乗る |
| 既に Kong を運用中 | Kong AI Gateway | プラグイン追加で済む。ただしトークン単位の制限は Enterprise |
| スループット・レイテンシがボトルネック | Bifrost を候補に入れて自分の traffic で測る | Go 製。ただし公称値はベンダー自社ベンチ |
| 運用したくない・小さく始めたい | Cloudflare AI Gateway or Portkey Production（$49/月） | 自前運用ゼロ。ログ保持期間が実質の制約 |
| SSO・監査ログが今すぐ要る | LiteLLM Enterprise（まず 30日トライアル）or Portkey Enterprise | OSS 版では埋まらない部分。ここが各社の課金ライン |
| 個人・数人 | 不要 | 鍵配布問題が存在しない。OTel だけで足りる |
一言で: OSS の「どこまでが無料か」を見る。ルーティングやフォールバックはどこも無料で差がつかず、SSO・監査ログ・トークン単位の制限・PII という「組織で使うための機能」で各社が課金してくる。そこが要るかどうかが、そのまま予算の分岐点になる。
参考リンク¶
AWS 公式¶
- Guidance for Multi-Provider Generative AI Gateway on AWS（構成図・7ステップのフロー）
- 同 GitHub（CDK / Terraform 実装）
- aws-samples/sample-resilient-llm-inference（Bedrock クロスリージョン推論・アカウントシャーディング・gateway による知的ルーティング）
製品公式¶
- LiteLLM / pricing / Enterprise docs
- Portkey Gateway（OSS・MIT） / pricing
- Agent Router（旧 Envoy AI Gateway・Apache 2.0） / サイト
- Bifrost（Apache 2.0・Go）
- Kong AI Gateway 発表
- Cloudflare AI Gateway
- Claude apps gateway / 発表ブログ
- Other LLM gateways（Claude Code を他 gateway に繋ぐ公式手順）
作成: 2026-09-15 ／ 最終更新: 2026-09-15