選び方の全体像
製品は 12 種類以上 に細分化されていますが、最初に決めるのは「自社でホストするか / クラウド SaaS か」だけで十分です。
図: デプロイ形態の 4 パターン
図: 製品選定フロー（簡易）
図: 12 製品 — 運用の軽さ × 統制の強さ（概念マップ）
製品選定の目的
KEEL が評価すべき LLM ゲートウェイ製品は、社内の既存 Azure 投資、SI としての顧客提案のしやすさ、Phase 1 の迅速な立ち上げ のバランスで選ぶ。本章では Phase 1 向け 5 候補の詳細比較 と 12 製品の拡張比較表 の両方を示し、意思決定フローと選定基準を整理する。
候補製品比較
| 観点 | Azure API Management (+ AI Gateway) | AWS API Gateway + Bedrock | Cloudflare AI Gateway | LiteLLM Proxy | Portkey |
|---|---|---|---|---|---|
| 形態 | マネージド PaaS | マネージド + Bedrock 統合 | SaaS / Edge | OSS セルフホスト | SaaS / セルフホスト |
| OpenAI 互換 | ポリシーで実現 | カスタム統合 | あり | ネイティブ | あり |
| マルチプロバイダ | 可能（設定工数大） | Bedrock 中心 | 複数対応 | 100+ モデル | 多数 |
| DLP / ガードレール | ポリシー + WAF 連携 | IAM + カスタム | 基本 + ログ | プラグイン + 外部連携 | 組み込み |
| コスト（基盤） | 中〜高 | 中 | 低〜中（従量） | 低（インフラのみ） | 中（シート+従量） |
| 運用負荷 | 低（マネージド） | 低〜中 | 最低 | 中〜高 | 低〜中 |
| ログ・監査 | Azure Monitor 統合 | CloudWatch | Cloudflare ログ | カスタム（OTel 等） | ダッシュボード |
| 日本リージョン | 東日本あり | 東京あり | Edge（東京 POP） | 任意（AKS 等） | 要確認 |
| ベンダーロックイン | Azure | AWS | Cloudflare | 低 | 中 |
| Phase 1 向き | ○（既存 Azure なら） | △ | ○（手軽） | ◎ | ○ |
2026 年時点の機能は各ベンダーのリリースノートで要確認。本表は KEEL の選定ディスカッション用のたたき台である。
KEEL 向け推奨方針
| フェーズ | 推奨 | 理由 |
|---|---|---|
| Phase 1 | LiteLLM Proxy on Azure（AKS / Container Apps） | 立ち上げ速度、OpenAI 互換、マルチプロバイダ、コスト |
| Phase 2 判断点 | Azure APIM への移行 or LiteLLM 継続強化 | 顧客要件・運用負荷・マネージド要求を再評価 |
| エッジ補完 | Cloudflare AI Gateway（オプション） | 海外リモート開発者のレイテンシ改善時のみ |
意思決定フロー（ステップ）
Step 1 — 要件固定
- [ ] 同時接続ユーザー数（Phase 1: 〜100、Phase 2: 〜500）
- [ ] 必須プロバイダ（Azure OpenAI、OpenAI、Anthropic のどれか）
- [ ] ログ保持要件（期間、SIEM 連携）
- [ ] データ residency（日本リージョン必須か）
Step 2 — 既存投資との整合
- [ ] Azure テナント／サブスクリプションの有無
- [ ] 既存 APIM インスタンスの空きキャパシティ
- [ ] Entra ID 連携の前提
Step 3 — セキュリティ要件マッピング
- [ ] DLP の must-have / nice-to-have
- [ ] プロンプト保存の可否
- [ ] Private Link / VNet 統合の要否
Step 4 — PoC（2〜3 週間）
- [ ] LiteLLM をステージングにデプロイ
- [ ] Cursor / 1 つの社内アプリから接続試験
- [ ] ログ・コストレポートのサンプル生成
- [ ] DLP ブロックの動作確認
Step 5 — スコアリング
| 基準 | 重み | LiteLLM | Azure APIM | Portkey |
|---|---|---|---|---|
| Phase 1 立ち上げ速度 | 25% | 8 | 3 | 6 |
| マルチプロバイダ | 20% | 8 | 3 | 8 |
| 運用負荷の低さ | 20% | 5 | 5 | 6 |
| セキュリティ拡張性 | 20% | 6 | 5 | 6 |
| コスト | 15% | 8 | 3 | 5 |
| 加重（例） | 4.40 | 3.80 | 4.05 |
加重計算例: LiteLLM = 5×25% + 5×20% + 3×20% + 4×20% + 5×15% = 4.40。Azure APIM = 3×25% + 3×20% + 5×20% + 5×20% + 3×15% = 3.80。Portkey = 4×25% + 5×20% + 4×20% + 4×20% + 3×15% = 4.05。
Step 6 — 経営承認
- Phase 1 製品・概算コスト・Phase 2 移行条件を第 11 章フォーマットで承認
選定時の落とし穴
| 落とし穴 | 対策 |
|---|---|
| 機能比較だけで決める | PoC で IDE 接続とログを必ず試す |
| マネージド万能論 | DLP 要件が高度ならセルフホスト + カスタムが有利な場合あり |
| OSS = 無料 | 運用工数・セキュリティパッチは隠れコスト |
| 単一プロバイダ前提 | 顧客案件で Bedrock / Azure OpenAI が指定される |
SaaS 型ゲートウェイにプロンプトを通す場合、データ処理契約（DPA） と 学習オプトアウト を契約書レベルで確認する。
LiteLLM 選定時の前提アーキテクチャ（Phase 1）
[開発者] → [Private Endpoint] → [LiteLLM on AKS]
↓
[Azure Key Vault]
↓
[Azure OpenAI] [OpenAI] [Anthropic]
↓
[Log Analytics / SIEM]次のステップ
- セキュリティ要件の詳細 → 第 6 章
- インフラデプロイパターン → 第 8 章
- 導入チェックリスト → 第 12 章
MCP ゲートウェイ選定の追記（2026-07）
MCP 単体は 相互運用プロトコル であり、認証・監査・一括ポリシーは仕様外。2026 年時点の業界予測として、API ゲートウェイベンダーの MCP 統合が進む、という見方がある（UNRESOLVED: 出典・数値は案件選定時に再確認）。
| アプローチ | 例 | KEEL 向け評価 |
|---|---|---|
| クラウド統合型 | Azure APIM（MCP Content Safety）、Google Agent Gateway | Azure 標準なら有力 |
| 統合 AI 基盤 | TrueFoundry、Bifrost（LLM+MCP+Agent 一体） | 運用負荷低・ベンダー依存 |
| OSS 自作 | LiteLLM + リバースプロキシ + OPA | Phase 1 と整合・自社運用力が必要 |
選定時の追加チェック（MCP 対応製品）:
- ツール単位 RBAC（サーバ単位だけでは不十分な場合がある）
- OAuth 2.1 + PKCE / OBO トークン交換
- 監査ログに 引数・レスポンス要約・latency・エラーコード が残るか
- シャドー MCP をネットワークで遮断できるか（直接 agent→tool を禁止）
拡張比較表 — 12 製品（2026-07 調査）
| 製品 | 形態 | ベストな用途 | 統制/DLP | MCP | 日本 residency | KEEL Phase |
|---|---|---|---|---|---|---|
| LiteLLM | OSS 自前 | 柔軟な自社 GW | 拡張可（Enterprise） | 進行中 | Azure 東京可 | P1 本命 |
| Bifrost | OSS Go | 高スループット本番 | Guardrails あり | ネイティブ | 自前 | P1 代替候補（性能値は公式公称） |
| OpenRouter | SaaS | 最速 PoC・400+ モデル（公式公称） | 弱い | — | 要確認 | PoC のみ |
| Portkey | SaaS/自前 | ガードレール一体 | 強 | 部分 | Enterprise 要確認 | P1/P2 |
| Cloudflare AI GW | Edge SaaS | CF 利用チーム | DLP あり | 限定的 | Edge POP | 補完 |
| Azure APIM AI | Azure PaaS | Azure 標準企業 | Content Safety | 拡張済 | 東日本 | P2 移行候補 |
| AWS MP GenAI GW | AWS ガイダンス | Bedrock 中心 | Guardrails | 要設計 | 東京 | AWS 案件 |
| Kong AI Gateway | OSS+Enterprise | 既存 Kong 利用 | API 中心 | プラグイン | 自前 | Kong ありなら |
| TrueFoundry | VPC マネージド | Agent+デプロイ一体 | 強 | ネイティブ | VPC | 大規模 P2 |
| Tetrate Agent Router | Envoy 系 | ゼロトラスト Agent | FINOS 系 | あり | 自前 | 金融系顧客 |
| Helicone | OSS/SaaS | 可観測性 | 弱（観測） | — | 自前可 | GW 併用 |
| Lunar.dev | 自前 CP | LLM+MCP+API 統合統制 | 強 | あり | 自前 | Phase 2 検討 |
選定バリエーション — 3 つの典型パターン
パターン S（Small / KEEL Phase 1 推奨）
開発者 → LiteLLM on Azure → Azure OpenAI + OpenAI
↳ Log Analytics · Entra ID（将来）パターン M（Medium / 高負荷 or MCP 早期）
開発者 → Bifrost on AKS → 複数プロバイダ
↳ MCP GW 内蔵 · Prometheusパターン E（Enterprise / 顧客提案テンプレ）
開発者 → Azure APIM AI GW → Foundry + 外部モデル
↳ Private Link · Content Safety · MCP 統制OpenRouter をどう位置づけるか
| 使っていい | 使わない |
|---|---|
| 個人のモデル比較・プロトタイプ | 顧客データ・ソースコード |
| 営業デモ（ダミーデータ） | 本番バッチ |
| クレジット少額の実験 | 監査が必要な案件 |
手数料: クレジット購入時 5.5%（OpenRouter 公式ブログの 2026 年時点公開情報）。自社 GW 経由にすればプロバイダ直課金で markup なし。
Bifrost vs LiteLLM — いつどちらか
| 選 LiteLLM | 選 Bifrost |
|---|---|
| Python チーム · 既存事例多 | Go · 5,000 RPS で ~11µs オーバーヘッド（Bifrost 公式公称） |
| PostgreSQL エコシステム成熟 | MCP GW を早期に本番投入 |
| コミュニティ記事・Qiita ベース設計 | レイテンシがボトルネック |
出典: OpenRouter LLM Gateway Guide · Bifrost GitHub · Tetrate Enterprise Comparison
v1.8 — Cloudflare AI Gateway 深掘り（mediba 検証 + 公式機能の蒸留）
記事が検証した「欲しかった機能」と結果
[mediba（ずーん, 2026-07-02）][71] は次を CF AIG で確認した。
| 機能 | 検証結果 | KEEL への示唆 |
|---|---|---|
| 監査ログ | リクエスト/レスポンス・metadata が記録 | Phase 1 PoC の必須合格項目 |
| レート制限 | 3 req/min 超過で HTTP 429 | IDE バースト時の UX 設計が必要 |
| Spend limits（metadata.user_id） | 上限超過で 429 | 個人枠の強制停止として有効 |
| コスト表示（リクエスト単位） | 表示されず（BYOK は best-effort）[71][72] | 予算ゲートは GW、確定課金は AWS CUR |
| 分析ダッシュボード | metadata フィルタ可能 | PM 向けコスト会議のたたき台に使える |
CF AIG vs LiteLLM vs Bedrock 直 — 意思決定マトリクス（2026-07）
| 観点 | CF AIG + BYOK | LiteLLM 自前 | Bedrock 直 + 自前プロキシ |
|---|---|---|---|
| 立ち上げ速度 | ◎ ダッシュボード中心 | ○ コンテナ・DB 要 | △ 認証・ログ・予算を自前実装 |
| 運用負荷 | ◎ マネージド | △ CVE・スケール自前 | × 最大 |
| OpenAI 互換 | プロバイダ別エンドポイント | ◎ ネイティブ | △ |
| Claude Code 統合 | ◎ 公式手順あり [76] | ○ base_url 差し替え | ○ Bedrock モード |
| per-user 予算停止 | ◎ Spend limits [72] | ○ Virtual Key budget | △ 事後集計中心 [78] |
| データ経路 | CF Edge 経由 | 自社 VNet 内に閉じられる | AWS 内 |
| マルチプロバイダ | ○ 20+ BYOK [9] | ◎ 100+ | × Bedrock 中心 |
| エンタープライズ監査 | ログエクスポート等は一部有料 [71] | Enterprise で SSO/監査 [81] | 自前 |
| ロックイン | Cloudflare | 低 | AWS |
KEEL 向け選定パターンの更新
| パターン | 構成 | いつ選ぶか |
|---|---|---|
| S（既存） | LiteLLM on Azure → Azure OpenAI | Azure 標準・顧客提案で自前 GW を見せたい |
| S-CF（新規） | CF AIG → BYOK Bedrock | Claude Code 先行・インフラ人員最小・東京 Bedrock |
| M | Bifrost on AKS | 高スループット + MCP 早期 |
| E | Azure APIM AI GW | 東日本 residency + Entra 一体 |
併用も可: Azure OpenAI 利用者は LiteLLM、AWS Bedrock 利用のコーディングエージェントは CF AIG、と プロバイダ別にゲートウェイを分ける のは mediba が示した現実解に近い。ただしログ相関用に trace_id / project_code の命名規則は全経路で統一する（第 4 章）。
PoC で CF AIG を評価するときのチェックリスト（追加分）
- [ ] Authenticated Gateway 有効 + トークン漏洩時のローテーション手順 [77]
- [ ] BYOK（Bedrock API キー or IAM JSON）登録 [75]
- [ ] Spend limit: metadata
user_idを split by value で設定 [72] - [ ]
cf-aig-metadataにuser_id/project_codeを付与 [71] - [ ] Claude Code:
CLAUDE_CODE_SKIP_BEDROCK_AUTH=1+ 日本リージョンのモデル ID [76][71] - [ ] 429（レート・予算）の IDE 側エラーメッセージを確認
- [ ] BYOK コスト表示が期待どおりか ベストエフォート前提 で検証 [72]
- [ ] アカウントスコープトークンの漏洩影響範囲をセキュリティレビュー [77]
LiteLLM Enterprise との位置づけ（記事が触れた代替）
mediba は LiteLLM Enterprise の費用感が不透明なため CF AIG を選択 [71]。KEEL では OSS LiteLLM を Phase 1 本命とするが、SSO・監査ログ保持・タグ予算をマネージドで揃えたい 場合は Portkey / TrueFoundry / LiteLLM Enterprise を同じ比較表で再スコアリングする（公開レンジは第 5 章 v1.8.1・[84][85]、正確な額は公式見積）。
v1.8.1 — UNRESOLVED 解消: 料金境界と TCO 試算
U-CF-01 解消 — CF AIG のログ・DLP・ガードレール料金（公式 [82][83]）
| 機能 | プラン | 料金・上限 | KEEL Phase 1 の読み |
|---|---|---|---|
| コア GW（分析・キャッシュ・レート制限・Spend limits） | 全プラン | 無料 | PoC は追加ライセンス不要 |
| 永続ログ（ダッシュボード内） | Workers Free | 10 万件/アカウント（全 GW 合算）[83] | パイロット上限の目安 |
| 永続ログ | Workers Paid（$5/月〜） | 1,000 万件/GW、超過時は削除 or 保存停止 [82][83] | 本番は Paid 前提 |
| Logpush（S3 等へエクスポート） | Workers Paid のみ [82] | GW 自体の従量課金なし。Logpush 先ストレージは別途 | SIEM 連携は Paid + S3 |
| DLP スキャン | 全プラン | スキャン自体は無料 [82] | 基本プロファイル 2 種が利用可 |
| DLP カスタムプロファイル | Zero Trust 契約あり [82] | Cloudflare One DLP と共有。カスタム語句・EDM・OCR は ZT 機能 | 高度 DLP は ZT 見積が別途 |
| Guardrails | 全プラン | Workers AI 推論の トークン従量（@cf/meta/llama-guard-3-8b）[82] | 常時 ON にしない。Phase 2 で試算 |
| Enterprise | カスタム | ログ上限・Logpush・価格は営業確認 [82] | 全社展開時のみ検討 |
結論（U-CF-01）: Phase 1 パイロットは Workers Free + BYOK で開始可能。SIEM 恒久連携や 10 万ログ超は Workers Paid（最低 $5/月） を見込む。Enterprise は全社規模まで不要なら見積不要。
U-CF-04 解消 — LiteLLM vs CF AIG TCO（公開情報ベース試算）
公式の LiteLLM Enterprise 公開価格はないため、第三者整理 [84][85] をレンジとして扱い、社内見積で上書きする。
| 構成 | ソフトウェア | インフラ/プラットフォーム | 運用工数（目安） | 月次 TCO レンジ（100 名パイロット想定） |
|---|---|---|---|---|
| LiteLLM OSS on Azure | $0 | AKS/ACA $300–700 [84] | 20–40h/月（構築後も保守）[84] | $2,000–3,500（人件費込み試算） |
| LiteLLM Enterprise Basic | ~$250/月 [84][85] | 同上 | 10–20h/月（SSO/監査は同梱） | $2,300–3,800 |
| LiteLLM Enterprise Premium | ~$30,000/年（$2,500/月） [84][85] | 同上 | 同上 | $4,500–6,000 |
| CF AIG + BYOK | $0（GW コア）[82] | Workers Paid $5/月〜 + Bedrock 従量 | 2–8h/月（設定中心） | $5–50（GW）+ Bedrock 利用料 |
判断ルール（KEEL 向け）:
| 条件 | 推奨 |
|---|---|
| 利用 < 50 名・Bedrock/Claude Code 中心・インフラ人手が乏しい | CF AIG（S-CF） — TCO 最小 |
| Azure OpenAI 中心・VNet 内完結・顧客に自前 GW を見せる | LiteLLM OSS |
| SSO・監査ログ S3 エクスポート・RBAC をマネージド寄りに | LiteLLM Enterprise 見積 or Portkey [7] と比較 |
| リクエスト > 500 万/月 で自前運用が回っている | LiteLLM OSS のスケールメリット [84] |
[84][85] の LiteLLM Enterprise 単価はベンダー非公開のため 要公式見積。CF 側も Enterprise ログ上限は営業確認。
