第12章導入手順 | KEEL LLMゲートウェイ導入ガイド

主な読者: PMインフラセキュリティSE

導入の段階イメージ

図: Phase 2 → 4 の拡張イメージ

導入手順の全体像

本章は Phase 1 / Phase 2 の ステップバイステップ手順、LiteLLM 仮想キー設計、タイムラインを示す。インフラ・セキュリティ・PM が連携して実施する。

Phase 1 導入（12 週タイムライン）

週	マイルストーン	担当
W1-2	要件確定、ネットワーク設計	インフラ、セキュリティ
W3-4	ステージングデプロイ、IdP 連携	インフラ
W5-6	DLP ルール v1、ログ SIEM 連携	セキュリティ
W7-8	パイロット接続（Cursor 等）	SE、インフラ
W9-10	負荷試験、Runbook v1	インフラ
W11-12	本番切替、振り返り	PM、全員

Phase 1 チェックリスト

1. 準備

[ ] スポンサー・PM・技術リードのアサイン
[ ] Azure サブスクリプション・リソースグループ作成
[ ] 命名規則・タグ付けポリシー確定
[ ] パイロット参加者リスト（20〜30 名）

2. インフラ構築

[ ] Container Apps / AKS クラスタ準備
[ ] LiteLLM コンテナデプロイ（ステージング）
[ ] PostgreSQL / Redis（必要に応じ）
[ ] Key Vault + Private Endpoint
[ ] 内部 DNS レコード llm-gateway.keel.internal
[ ] Azure OpenAI リソース接続（Private Endpoint）

3. セキュリティ設定

[ ] プロバイダ API キーを Key Vault に格納
[ ] DLP 正規表現セット v1 適用
[ ] fail-closed 設定確認
[ ] 監査ログスキーマ定義
[ ] SIEM 転送パイプライン

4. ガバナンス

[ ] 利用申請フォーム公開（第 15 章）
[ ] 許可モデルリスト v1 公開
[ ] データ分類ガイド配布
[ ] 違反時措置の社内通達

5. パイロット

[ ] 仮想キー 30 本発行
[ ] IDE 設定ハンズオン実施
[ ] 日次スタンドアップ（2 週間）
[ ] フィードバック収集

6. 本番化

[ ] ステージング → 本番プロモーション
[ ] ヘルスチェック・アラート有効化
[ ] Runbook 引き渡し（第 13 章）
[ ] Gate G1 資料提出

本番切替前に ロールバック手順（旧来直結の一時許可はしない）を文書化する。

Phase 2 導入チェックリスト

[ ] 全社ロールアウト計画（第 10 章）
[ ] Auto-scale・マルチ AZ 強化
[ ] ML ベース DLP 追加
[ ] RAG/MCP 登録制導入
[ ] 顧客向け説明パッケージ（法務承認）
[ ] ISO 42001 / AI RMF マッピング完了（第 14 章）
[ ] CoE 月次運用レビュー開始
[ ] APIM 移行判断（第 5 章再評価）

LiteLLM 仮想キー設計

キー命名規則

sk-keel-{env}-{team}-{purpose}-{random}
例: sk-keel-prd-dev1-standard-a7f3

データモデル（論理）

フィールド	説明
`key_id`	内部 UUID
`team_id`	部門コード
`project_code`	プロジェクト（必須）
`models`	許可モデルリスト
`rpm_limit`	分あたりリクエスト
`tpm_limit`	分あたりトークン
`max_budget`	月次上限（USD）
`expires_at`	有効期限

キー種別テンプレ

テンプレ名	models	rpm	max_budget/mo
dev-standard	gpt-4o-mini, claude-3-haiku	60	50
dev-premium	+ gpt-4o, claude-3-5-sonnet	30	200
ci-batch	gpt-4o-mini のみ	20	30
poc-sandbox	mini/haiku のみ	30	20

ルーティング設定例

model_list:
  - model_name: gpt-4o-mini
    litellm_params:
      model: azure/gpt-4o-mini
      api_base: os.environ/AZURE_OPENAI_ENDPOINT
  - model_name: claude-3-5-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet

設定形式は LiteLLM バージョンにより異なる。導入時の公式ドキュメントを正とする（第 16 章）。

検証項目（Go-Live）

#	テスト	期待結果
T1	仮想キーで chat completion	200 OK
T2	未許可モデル指定	403
T3	DLP トリガー（ダミー秘密）	ブロック
T4	RPM 超過	429
T5	ログ SIEM 到達	5 分以内
T6	Key Vault 障害シミュレーション	fail-closed

役割別引き渡し

成果物	受け手
エンドポイント URL	全開発者
申請ポータル	PM
監視ダッシュボード	インフラ
DLP ルールセット	セキュリティ
月次コストレポート	PM、経営

よくある遅延要因

要因	対策
ネットワーク承認遅れ	W1 でファイアウォール申請
IdP 連携	既存 Entra ID アプリ登録を流用
プロバイダ契約	法務・調達を W1 に巻き込み

運用移行 → 第 13 章。

Phase 1 Go-Live 前のセキュリティゲート（2026 CVE 版）

#	チェック	合格基準
S1	LiteLLM バージョン	最新 stable または追補ハードニング済み系列（≥1.84.3 等）。`>=1.84.0` 単独は合格基準にしない。1.82.7/8 非使用を棚卸し確認
S2	Starlette	≥ 1.0.1（SBOM / lockfile で確認）
S3	インターネット直公開	なし（WAF/ALB/NGINX 経由のみ）
S4	Host ヘッダー	上流で正規化または拒否
S5	Custom Code Guardrail	登録一覧を監査。不要な `exec` ガードレール削除
S6	`proxy_admin` キー	2 名以下、Vault 保管、ローテーション手順文書化
S7	JWT auth	使う場合は最新パッチ適用済み
S8	プロバイダキー	Gateway のみが保持。開発者端末にない

カスタムガードレールに関する注意

CVE-2026-40217: Custom Code Guardrail の exec() サンドボックス逸脱が報告されている。本番ではビルトイン DLP/外部 Presidio 連携を優先し、カスタム Python ガードレールはセキュリティレビュー + 最小権限で限定する。

v1.8 — CF AIG 経路の Phase 1 パイロット（2〜3 週間）

LiteLLM 12 週計画と 並行または代替 で実施できる短縮パイロット。

週	マイルストーン	担当
W1	CF ゲートウェイ作成、BYOK、認証トークン、Spend/Rate 設定	インフラ
W1	Claude Code 設定配布（Win/Mac）、metadata 規約確定	インフラ + PM
W2	パイロット 10〜20 名接続、ログ・429 検証	SE
W2	AWS CUR 2.0 + IAM principal 按分の事後レポート試作	インフラ
W3	Go/No-Go: LiteLLM 本命継続 or S-CF 併用判断	PM + セキュリティ

Go-Live 検証（CF AIG 追加分）

#	テスト	期待結果
T7	Claude Code から 1 プロンプト	200、CF ログに request/response
T8	metadata `user_id` 付与	分析画面でフィルタ可能 [71]
T9	Spend limit 超過	429 [72]
T10	レート制限超過	429 [71]
T11	トークンなしリクエスト	401（Authenticated ON）[77]
T12	AWS CUR 突合	日次集計でプロジェクト概算が追える [78]

T12 は リアルタイム予算停止（T9）とは別系統。経営報告用の確定額は AWS、現場の暴走防止は CF AIG と役割分担する。