本提案の位置づけ
多くの会社では、社内開発の生産性向上と顧客プロジェクトへの AI 活用提案の双方で LLM 利用が急拡大している。一方で、開発者が個別に API キーを取得し、IDE プラグインやチャットツールへ直結する シャドー IT 型の LLM 利用 が常態化しつつある。本ガイドパックは、LLM ゲートウェイを中核とした統制基盤 を Phase 1（社内 PoC・限定本番）→ Phase 2（全社展開・顧客案件テンプレ化）の二段階で整備する提案である。
本資料は KEEL 社内向けの技術・ガバナンス提案であり、特定顧客向けの製品仕様書ではない。顧客案件への展開は、本パックのテンプレートをベースに契約・データ分類を個別調整する。
なぜ今か — 3 つのトリガー
| トリガー | 現状の兆候 | 放置した場合のリスク |
|---|---|---|
| 利用の爆発 | Cursor・GitHub Copilot・ChatGPT Enterprise 試用が部門横断で増加 | 契約・ログ・データ所在が部門ごとにバラバラ |
| 顧客要件の高度化 | 金融・製造・公共向け提案で「AI 利用の説明責任」が RFP に明記 | 提案時に統制ストーリーを即答できず失注 |
| コストの不可視化 | トークン課金がプロジェクト原価に紐づかない | 粗利悪化・予算超過が後追いで判明 |
「まずは小さく試す」だけでは、キー配布とログ欠落が先に固定化する。ゲートウェイは後付けより先に薄く入れる方が総コストが低い。
4 つのドメイン（本パックの全体構造）
本パックは次の 4 ドメインで一貫した設計を提供する。
| # | ドメイン | 目的 | 主な読者 |
|---|---|---|---|
| 1 | ガバナンス | 誰が・何を・どのモデルで使えるかを定義 | PM、セキュリティ |
| 2 | セキュリティ | DLP・ガードレール・インシデント対応 | セキュリティ、インフラ |
| 3 | プラットフォーム | 製品選定・ネットワーク・HA・監視 | インフラ、SE |
| 4 | 現場運用 | 開発者の使い方・申請・運用 Runbook | PG、SE、PM |
各ドメインは独立した章として詳述するが、承認フロー（申請 → 仮想キー発行 → ログ監査） が横断する共通スパインである。
Phase 1 / Phase 2 サマリー
Phase 1 — 統制の最小実装（目安 8〜12 週）
- スコープ: 社内 SE／PG 約 50〜100 名、対象モデルは OpenAI / Anthropic / Azure OpenAI の 2〜3 系統
- 製品: LiteLLM Proxy（コンテナ）+ 既存 IdP（Entra ID）+ ログ基盤（既存 SIEM または Cloud Logging）
- 必須機能: 仮想キー、RPM/TPM 制限、基本 DLP（正規表現 + 既知パターン）、全リクエスト監査ログ
- 成功基準: シャドー API キー利用の削減、月次コストレポートのプロジェクト別可視化、セキュリティレビュー 1 回パス
Phase 2 — 全社・顧客案件テンプレ（目安 Phase 1 完了後 6〜9 ヶ月）
- スコープ: 全社開発者 + 顧客案件向け「AI 利用パッケージ」として提案可能な水準
- 追加機能: モデルルーティング（コスト最適化）、RAG/MCP 経由の統制、高度 DLP、四半期コンプライアンスレビュー
- 組織: LLM 運用 CoE（Center of Excellence）の常設、顧客向け説明資料の標準化
- 成功基準: ISO 42001 / NIST AI RMF への対応マッピング完了、顧客監査への回答テンプレ整備
Phase 1 は「完璧な製品選定」より ログとキー集中の成立 を優先する。Phase 2 で製品のスケールアップまたはマネージド APIM への移行を判断する。
投資と効果（概算レンジ）
| 項目 | Phase 1 | Phase 2 |
|---|---|---|
| インフラ・ライセンス | 月 15〜40 万円 | 月 40〜120 万円 |
| 構築工数（社内 + パートナー） | 1.5〜3 人月 | 4〜8 人月 |
| 期待効果 | キー漏洩リスク低減、利用可視化 | 提案力向上、監査対応工数の削減（削減率は KEEL 実績で要検証） |
※ モデル利用料（トークン課金）は別途。ゲートウェイ導入により高コストモデル呼び出しを抑制できる可能性はあるが、削減率は利用部門・既定モデル・キャッシュ/ルーティング方針に依存する。KEEL では Phase 1 の月次レポートを根拠に効果を確定する（UNRESOLVED: 実績待ち）。
意思決定に必要な 5 項目
- Phase 1 開始の承認（予算・スポンサー・セキュリティ責任者の合意）
- データ分類ポリシー（社内ソースコード・顧客データの LLM 送信可否）
- クラウド選定（Azure 既存投資との整合 — KEEL 標準リージョン）
- パイロット部門（1〜2 プロジェクト、3 ヶ月）
- Phase 2 ゲート条件（Phase 1 KPI 達成定義）
次のアクション
| 役割 | アクション | 参照章 |
|---|---|---|
| 経営 | Phase 1 予算・スポンサー承認 | 第 11 章 |
| セキュリティ | DLP 要件・脅威モデル確認 | 第 6 章 |
| インフラ | ネットワーク・デプロイパターン選定 | 第 8 章 |
| PM | パイロットプロジェクト選定・申請フロー試行 | 第 10 章 |
| SE/PG | ゲートウェイエンドポイント接続（パイロット） | 第 9 章 |
本パックの読み方: 役割別に該当章を深読みし、第 17 章マスタサマリーで全体を俯瞰する。製品選定の詳細は第 5 章、導入手順のチェックリストは第 12 章を正とする。
2026-07 ブラッシュアップ — 調査で強化した論点
初版公開後、LiteLLM 公式アドバイザリ、GitHub Security Advisory、EU AI Act 公式テキスト、製品公式ドキュメントを優先して再確認し、本パック v1.1 に反映した。社外解説記事は補助情報として扱う。
| 強化領域 | 追加内容 | 参照章 |
|---|---|---|
| 3 層ゲートウェイ | Content / MCP / Runtime Authorization の分離 | 第 1・2・4 章 |
| ライフサイクルフック | llm_input / llm_output / mcp_pre_tool / mcp_post_tool | 第 2・4 章 |
| LiteLLM セキュリティ | Host Header 認証バイパス・供給網 2026-03・Guardrail/MCP 系 CVE | 第 9・10 章 |
| MCP 統制 | ツールレジストリ・OBO トークン・シャドー MCP 遮断 | 第 2・5 章 |
| EU AI Act 記録要件 | Article 12 の自動記録機能と Article 19 / 26(6) のログ保持を分離 | 第 14 章 |
2026 年の脅威トップ 3（業界調査の収束）: プロンプトインジェクション、データポイズニング（RAG 汚染）、シャドー AI。
v1.2 追記 — 製品バリエーションの拡大
2026 年の市場は 単一の「正解」製品は存在しない。用途別に次の 8 バリエーションに分類する。
| バリエーション | 代表製品 | KEEL で使う場面 |
|---|---|---|
| A. ゼロ運用マーケットプレイス | OpenRouter | PoC・個人検証（本番機密は通さない） |
| B. OSS セルフホスト（Python） | LiteLLM | Phase 1 本命 · カスタム重視 |
| C. OSS セルフホスト（Go・高速） | Bifrost | 高 RPS・低レイテンシ本番 |
| D. 既存 API 基盤拡張 | Kong AI GW · Azure APIM | 既存 Kong/Azure 投資の活用 |
| E. マネージド統制 | Portkey · TrueFoundry · Cloudflare | 運用負荷を下げたい |
| F. 観測特化（併用） | Helicone · Langfuse | GW の上に載せる分析層 |
| G. Agent/MCP 特化 | Lunar.dev · Tetrate Agent Router | Phase 2 の Agent 統制 |
| H. ML ルーティング | TensorZero | A/B・フィードバックループ重視 |
Helicone / Langfuse は ゲートウェイの代替ではなく補完。ルーティング本体は LiteLLM 等と併用するのが一般的。
v1.7 査読反映 — 経営判断で外さない論点
今回の査読では、章立てそのものは概ね維持しつつ、経営・PM・セキュリティ・開発者が同じ資料を読んだときに「どこまでが文化・ルールで、どこからが技術統制か」を誤解しないよう補強した。特に、近年の研究・標準で収束している論点は次の 4 つである。
| 論点 | 本パックでの扱い | 意思決定上の意味 |
|---|---|---|
| 間接プロンプトインジェクション | 第 6・7・9 章で、メール・Web・RAG 文書由来の攻撃として扱う | 入力欄だけを検査しても不十分。検索元・添付・ツール結果も検査対象 |
| MCP tool poisoning | 第 4・5・6 章で、ツール定義・説明文・スキーマの審査を統制対象に追加 | MCP は「便利な接続口」ではなく、承認済みツール台帳と実行時認可が必要 |
| GenAI 固有リスク管理 | 第 14 章で NIST AI 600-1 / AI 100-2 を正式な補助軸に追加 | AI RMF の Govern/Map/Measure/Manage を LLM ゲートウェイ証跡に落とす |
| 実被害ベースの説明 | 第 1・2 章で「詐欺・漏洩」だけでなく、ゼロクリック漏洩や過剰権限を説明 | 初心者向け表現を保ちつつ、経営には「現実化した攻撃」として説明できる |
v1.7 の結論: Phase 1 は引き続き「キー集中・ログ・DLP」を最小実装とする。ただし Phase 1 の時点で trace_id、データ分類、MCP ツール台帳の設計だけは先に固定する。Phase 2 で直すとログ相関と監査証跡が崩れやすい。
v1.8 追記 — 「自前 OSS」以外の立ち上げ経路
[mediba テックブログ（2026-07）][71] では、GitHub Copilot のシート課金と Amazon Bedrock 直利用の統制不足のあいだを、Cloudflare AI Gateway（CF AIG） で埋める検証が公開されている。KEEL が Phase 1 を急ぐ場合、選択肢は LiteLLM 自前ホストだけではない。
| 経路 | 向く条件 | トレードオフ |
|---|---|---|
| LiteLLM on Azure（既存推奨） | Azure OpenAI 中心・VNet 内完結・顧客提案で自前構成を示したい | 運用・CVE 対応・インフラ人員が必要 |
| CF AIG + BYOK（Bedrock 等） | Claude Code 等のコーディングエージェントを早く統制したい・マネージド優先 | リクエストが CF Edge を経由・メタデータは信頼モデル要設計 |
| Azure APIM AI GW | 既存 APIM・Entra ID・東日本 residency が最優先 | 立ち上げとマルチプロバイダ設定の工数 |
mediba 事例の結論は「証跡・レート制限は有効、BYOK のリクエスト単位コスト表示はベストエフォート」である [71][72]。Phase 1 の Go/No-Go では ログ到達・429 停止・メタデータ相関 を PoC 合格基準に含め、課金ダッシュボード一致は補助 KPI とする。
