この章でわかること（30 秒）
LLM ゲートウェイは 「会社専用の AI 改札口」 です。開発者やアプリはここを通るだけで、認証・料金・安全チェック・ログが一括で効きます。
個人キーの直結は「誰が何を送ったか」が見えない。ゲートウェイは会社の AI 専用改札口のイメージ。
覚えておく一言: ゲートウェイ = プロバイダ API の前に置く「逆プロキシ + 統制レイヤー」
LLM ゲートウェイとは何か
LLM ゲートウェイは、社内のあらゆる LLM クライアント（IDE、チャット UI、バッチ、RAG パイプライン）と 複数のモデルプロバイダ API の間に置く逆プロキシ兼統制レイヤー である。OpenAI 互換エンドポイントを提供することで、クライアント側の設定変更を最小化しつつ、認証・認可・ログ・レート制限・ルーティングを中央集約する。
KEEL のような SI 企業では、社内開発 と 顧客環境への展開提案 の両方で同じ参照アーキテクチャを使えることが重要である。
参照アーキテクチャ
図中の LiteLLM / APIM は代表例である。第 5 章で KEEL 向けの選定基準を比較する。
KEEL が直面する 3 大課題
1. シャドー IT とキー散乱
開発者が個人クレジットカードや無料枠で API キーを取得し、.env や IDE 設定に直書きするパターンが蔓延している。
| 症状 | 影響 |
|---|---|
| 退職者のキーが無効化されない | データ漏洩・不正利用 |
| 顧客ソースがパブリック API に送信 | 契約違反・損害賠償リスク |
| 部門ごとに別契約 | ボリュームディスカウント喪失 |
2. コストのブラックボックス化
トークン課金は リクエスト単位ではなく会話・ジョブ単位 で膨らむ。プロジェクトコードと紐づかない課金は、SI 企業の原価管理と相容れない。
- 高コストモデル（GPT-4 クラス）の無意識な既定利用
- リトライ・ループによるトークン倍増
- 開発／本番の区別なき同一キー利用
ゲートウェイなしでは「誰がいくら使ったか」を月末に手集計する運用になりやすい。KEEL 内の実工数は Phase 0/1 でベースライン計測する（UNRESOLVED: 実績待ち）。
3. 監査・説明責任の欠如
金融・製造・公共の顧客は、サプライヤーの AI 利用について データの所在・学習利用の有無・ログ保持 を問う。都度アドホックに回答する体制では、提案フェーズで不利になる。
ゲートウェイが解くこと — 機能マッピング
| 課題 | ゲートウェイ機能 | 期待効果 |
|---|---|---|
| キー散乱 | 仮想キー + プロバイダキー一元管理 | キーローテーションが 1 箇所で完結 |
| コスト不可視 | チーム／プロジェクト別メタデータタグ | 月次レポート自動化 |
| 監査不足 | 全リクエスト／レスポンスメタログ | 顧客監査へのエビデンス提示 |
| モデル乱用 | 許可モデルリスト + ルーティング | 用途に応じたコスト最適化 |
| データ漏洩 | DLP・入力検査 | 送信前ブロック（fail-closed） |
KEEL における利用シナリオ
| シナリオ | 利用者 | 統制レベル |
|---|---|---|
| 社内ツール開発 | PG / SE | 標準（社内コードは匿名化推奨） |
| 顧客システム保守 | SE | 厳格（顧客データは原則禁止） |
| 提案・ドキュメント作成 | PM / コンサル | 標準（個人情報マスキング） |
| PoC / デモ | SE | サンドボックス仮想キー、低コストモデル限定 |
導入しない場合の代替案と限界
| 代替案 | 限界 |
|---|---|
| 各クラウドのエンタープライズ契約のみ | IDE 直結は統制外、ログが分散 |
| プロキシなし VPN 出口制限のみ | 暗号化 HTTPS では内容検査不可 |
| 利用規約と啓蒙のみ | コンプライアンス証跡にならない |
ゲートウェイは 技術統制の要。ポリシー・教育・契約と三位一体で初めて効果を発揮する（第 4 章ガバナンス参照）。
他章への導線
- 統制の詳細設計 → 第 4 章
- 製品比較 → 第 5 章
- セキュリティ担当者向け防御策 → 第 6 章
- 開発者の接続手順 → 第 9 章
2026 年モデル — 3 層ゲートウェイ（単一 GW だけでは足りない）
多くの企業は「LLM 用リバースプロキシ」を 1 枚置いた時点で完了と誤認する。2026 年時点のエンタープライズ実務では、役割の異なる 3 層に分けて設計するのが推奨パターンになっている。
| 層 | 名称 | 主な責務 | KEEL Phase |
|---|---|---|---|
| 1 | Content Security Gateway | プロンプト/応答のインライン検査、DLP、インジェクション検知 | Phase 1 必須 |
| 2 | MCP / Connectivity Gateway | ツールサーバ台帳、スキーマ検証、MCP 経路の集中入口 | Phase 2 |
| 3 | Runtime Authorization Gateway | エージェント×ユーザー×意図に基づく実行時認可（OPA/Cedar 等） | Phase 2 以降 |
3 層は必ずしも別製品である必要はない（例: Azure APIM が LLM + MCP Content Safety を統合）。ただし 設計上の責務分離 は監査・障害切り分けに有効。
統一テレメトリ平面
フォレンジック調査では、プロンプトログ（層1）・ツール呼び出し（層2）・認可決定（層3）を 同一 trace_id で相関できることが必須。SIEM には非同期転送でよいが、ID スキームは Phase 1 から固定する。
用語ミニ辞典（初めて読む人向け）
| 用語 | かんたん説明 |
|---|---|
| Virtual Key（仮想キー） | 本物の OpenAI キーの代わりにアプリへ渡す「制限付き入館証」 |
| DLP | クレカ番号・個人情報などを送る前に止めるフィルタ |
| Guardrails | 有害な入出力やインジェクションを弾く安全柵 |
| MCP | AI が外部ツール（DB・API）を呼ぶための共通プロトコル |
| Shadow AI | 会社の承認なしに個人キーで LLM を使うこと |
| fail-closed | 安全装置が壊れたら「止める」。金融系ではこちらが標準 |
ストーリーで読む — 推奨順序（v1.7）
本パックには 2 つの読み方がある。通読ルートは経営・PM・セキュリティが全体設計を合意するための順序、役割別ルートは担当者が必要章だけ読むための順序である。
通読ルート（合意形成向け）
| 順番 | 章 | 目的 | 読者 |
|---|---|---|---|
| 1 | 第 0 章 | 投資判断・Phase 1/2 の全体像 | 経営・PM |
| 2 | 第 1 章 | 全社員が守る最低ライン | 全社員 |
| 3 | 第 2 章 | 何をゲートウェイで集中統制するか | 全員 |
| 4 | 第 3 章 | ルール・契約・教育を固める | PM・法務・情シス |
| 5 | 第 4 章 | 統制モデル・ログ・RACI を定義 | PM・セキュリティ |
| 6 | 第 5 章 | 製品選定と PoC 観点を決める | PM・インフラ |
| 7 | 第 6〜7 章 | 脅威モデルから本番品質へ落とす | セキュリティ・SE |
| 8 | 第 8〜15 章 | 構築・開発・運用・テンプレに展開 | 各担当 |
| 9 | 第 16〜17 章 | 根拠確認・未決事項の管理 | 全員 |
役割別ルート（実務向け）
| 立場 | 最短ルート | 到達点 |
|---|---|---|
| 全社員 | 第 1 章 | 送ってはいけない情報と相談先が分かる |
| 経営 | 第 0 → 11 → 17 章 | 投資判断・未決事項・KPI が分かる |
| PM | 第 0 → 3 → 10 → 12 → 15 章 | 申請・教育・ロールアウトを回せる |
| セキュリティ | 第 4 → 6 → 7 → 14 章 | 脅威モデル・DLP・監査証跡を設計できる |
| インフラ | 第 5 → 8 → 13 章 | 製品・ネットワーク・運用を設計できる |
| 開発者 | 第 1 → 9 章 | IDE/SDK を安全に接続できる |
第 5 章は章番号上はセキュリティ章より前にあるが、読む目的は「製品決定」ではなく PoC で何を検証するかを固定すること である。製品名だけで選ばず、第 6・7 章の防御要件を満たせるかで判断する。
脅威の現実化 — なぜ「入口統制」だけでは足りないか
近年の研究・事例では、攻撃者がチャット入力欄に直接命令を入れるだけでなく、メール、Web ページ、RAG 文書、MCP ツール説明文など、AI が読む周辺コンテキストに命令を埋め込むパターンが増えている。
| 攻撃面 | 典型例 | ゲートウェイで見るべき信号 |
|---|---|---|
| 直接入力 | 利用者プロンプト内の命令上書き | llm_input の分類・拒否・警告 |
| 間接入力 | メール・Web・添付・RAG 文書に隠れた命令 | 取得元 URL、文書 ID、検索クエリ、chunk ACL |
| ツール定義 | MCP tool の説明文・schema に隠れた命令 | ツール台帳、署名、差分レビュー、実行前承認 |
| 出力経路 | Markdown リンク、画像 fetch、外部 URL への誘導 | llm_output の URL/HTML/コード検査 |
このため、LLM ゲートウェイは単なる API キー集約ではなく、入力・検索・ツール・出力・認可判断を同じ trace_id でつなぐ監査平面として設計する。
v1.8 — Bedrock「だけ」では足りない論点（国内検証の収束）
エンタープライズが Bedrock 等の従量課金プロバイダへ移行するとき、推論 API 自体には次が 標準では揃いにくい。
| 要件 | Bedrock 単体の典型ギャップ | CF AIG で補える部分 | 依然として自前が要る部分 |
|---|---|---|---|
| 監査ログ | CloudWatch/S3 は設定次第。IDE 直結は分散 | リクエスト/レスポンスの集中ログ [71] | 保持期間・SIEM 形式・PII マスキング方針 |
| ガードレール | Guardrails はあるがアプリ統合が別途 | DLP・Guardrails・レート制限の一体 [9] | 社内データ分類とのマッピング |
| 個人/チーム予算 | CUR/Cost Explorer は 事後集計 が中心 [78] | Spend limits + metadata で リアルタイム 429 [72] | 請求確定額はプロバイダ正 |
| 予算超過の強制停止 | ネイティブな per-user ハードストップは弱い | ゲートウェイ側でブロック or 安価モデルへフォールバック [72] | 並行リクエストは eventually consistent |
| プロジェクト按分 | 2026-04 以降 IAM principal / session tag 按分 [78][79] | cf-aig-metadata で利用分析 [71] | AWS 請求タグと GW メタデータの突合 |
なぜ LiteLLM を選ばなかった企業もいるか
mediba では勉強会で LiteLLM プロキシのカスタム が他社事例として出てきた一方、自社では「構築・運用・OSS カスタム保守の隠れコスト」を理由に見送っている [71]。KEEL の Phase 1 推奨（LiteLLM）は 柔軟性と Azure 親和性 のトレードオフとして維持しつつ、運用リソースが乏しい部門向けの代替パターン として CF AIG を第 5・8・12 章に追記した。
参照アーキテクチャ — Pattern CF（コーディングエージェント向け）
[Claude Code / Cursor / SDK]
↓ cf-aig-authorization + cf-aig-metadata
[Cloudflare AI Gateway] — ログ · レート制限 · Spend limits · DLP
↓ BYOK（Bedrock API キー or IAM）
[Amazon Bedrock ap-northeast-1 等]
↓
[AWS 請求] ← IAM principal / タグ按分（事後）CF AIG の認証トークンは アカウントスコープ で、単一トークンが同一アカウント内の全ゲートウェイ（BYOK 含む）に使える [77]。テナント分離は Cloudflare アカウント分割 または Worker binding 等で設計する。
v1.10 — 露出は二方向に分けて考える
AI 利用時の「情報の露出」は、性質の異なる 2 つの問題に分けて整理します（Zenn: 開発現場のAIセキュリティを見直す）。
*出典: 開発現場のAIセキュリティを見直す（nenene01 / Zenn）*
| 方向 | 何が起きるか | 守り方 | KEEL での実装 |
|---|---|---|---|
| ① 事業者への露出 | プロンプト・ツール出力が OpenAI / Anthropic 等へ送信される | 契約・ガバナンス（学習オプトアウト、保持期間、Shadow AI 禁止） | 第 3 章 · 社内 GW · エンタープライズ契約 |
| ② 攻撃者への露出 | プロンプトインジェクション等でコンテキストが外部へ流出 | 技術・設計（致死的三要素を崩す、最小権限） | 第 6 章 · MCP 台帳 · Runtime AuthZ |
ARN やシークレットのキー名は「露出しても単体では悪用しにくい」メタデータ。個人情報は露出した時点でアウト — ①②の両方で遮断が必要です。
2026 年の進め方（4 ステップ）
*出典: 開発現場のAIセキュリティを見直す（nenene01 / Zenn）*
| Step | 内容 | 本パックの章 |
|---|---|---|
| 1 | ルールと契約を固める | 第 3 章 |
| 2 | エージェントに専用の身分を払い出す | 第 8・9 章 |
| 3 | 経路とデータを固める | 第 7・8 章 |
| 4 | 外部汚染対策を仕組みにする | 第 6・9・13 章 |
v1.11 — リスト・権限は「ゲートウェイの外」にもある
本パックは社内 LLM ゲートウェイが主題だが、iwaken71 氏の事故 が示す通り、端末の git clean や Remove-Item は GW を経由しない。統制は次の 4 層で考える。
| 層 | リスト例 | 権限（誰が編集） |
|---|---|---|
| クライアント | 端末 allow/deny · ワークスペーススコープ | PG（プロジェクト）+ Sec 雛形 |
| Content GW | モデル · DLP · 出力 URL | PM + Sec · 仮想キー RBAC |
| MCP GW | サーバ台帳 · ツール名 · 引数 regex | Sec · Registry 承認 |
| Runtime AuthZ | ロール → 上記の束 · HITL | PMO · IdP グループ |
denylist だけでは足りない — Backslash 分析の通り文字列 deny は回避されうる。allowlist + サンドボックス + 承認を併用する（第 6・9 章）。
