かみ砕き — 4 つの統制と 3 つのゲートウェイ層
| たとえ | 統制の意味 |
|---|
| 改札 | 誰が通れるか（認証・SSO） |
| 手荷物検査 | 何を送れるか（DLP） |
| 通行量制限 | いくらまで使えるか（予算・レート） |
| 防犯カメラ | あとから追えるか（監査ログ） |
図: 3 層ゲートウェイ（役割の分離）
図: 3 層ゲートウェイ（役割の分離）
図: 1 リクエストが通る 4 つのチェックポイント
図: 1 リクエストが通る 4 つのチェックポイント
ガバナンスモデルの全体像
LLM ゲートウェイのガバナンスは 4 つの管理領域 と 5 つの統制軸 で設計する。KEEL では社内利用と顧客案件を同一フレームで扱い、案件ごとに「上書きルール」を定義できる柔軟性を確保する。
4 つの管理領域
| 領域 | 定義 | オーナー | 主な成果物 |
|---|
| A. アクセス | 誰がゲートウェイを使えるか | セキュリティ + インフラ | ロール定義、仮想キー発行基準 |
| B. データ | 何を LLM に送ってよいか | セキュリティ + PM | データ分類表、禁止パターン |
| C. モデル | どのモデルをどの用途で使うか | SE リード + セキュリティ | 許可モデルリスト、ルーティング規則 |
| D. 運用 | ログ・インシデント・変更管理 | インフラ + PM | Runbook、変更申請テンプレ |
5 つの統制軸
| 軸 | 問い | 実装 |
|---|
| Identify | 利用者・プロジェクトを特定できるか | 仮想キーに team_id / project_code を必須付与 |
| Protect | 不適切な入力を防げるか | DLP、許可モデル、ネットワーク分離 |
| Detect | 異常利用に気づけるか | レート異常、DLP ヒット、コスト急増アラート |
| Respond | インシデント時に止められるか | キー即時失効、fail-closed、エスカレーション |
| Recover | 再発防止できるか | ポストモーテム、ルール更新、教育 |
5 軸は NIST CSF の考え方を LLM 文脈に適用したものである。第 14 章で NIST AI RMF との対応表を示す。
ロールと責任（RACI 概要）
| 活動 | 経営 | PM | SE | PG | セキュリティ | インフラ |
|---|
| ポリシー承認 | A | C | I | I | R | C |
| 利用申請審査 | I | A/R | C | I | C | I |
| 仮想キー発行 | I | C | I | I | C | R/A |
| DLP ルール変更 | I | I | C | I | A/R | R |
| インシデント一次対応 | I | C | C | C | A/R | R |
R = 実行責任、A = 説明責任、C = 協議、I = 情報共有。詳細テンプレは第 15 章。
ログポリシー
記録対象（必須）
| 項目 | 保持期間 | 備考 |
|---|
| リクエスト ID、タイムスタンプ | 1 年（最低） | 顧客契約で 3 年要求あり得る |
| 仮想キー ID（キー本体は不可） | 1 年 | ハッシュ化識別子 |
| モデル名、トークン数、レイテンシ | 1 年 | コスト配賦に使用 |
| DLP 判定結果（ブロック/許可） | 1 年 | 監査エビデンス |
| プロジェクトコード / チームタグ | 1 年 | 必須メタデータ |
記録しない／マスクする項目
- プロンプト全文・レスポンス全文（原則 保存しない。デバッグ時は 72 時間限定のサンプリングモード）
- API キー、パスワード、個人番号
- 顧客識別子（必要時はトークン化 ID に置換）
「デバッグのため全プロンプト保存」は Phase 1 でも原則禁止。例外はセキュリティ承認 + 限定キー + 自動削除 TTL 必須。
ログアクセス権
| ロール | 閲覧範囲 |
|---|
| 一般開発者 | 自分のキーの集計メトリクスのみ |
| PM | 担当プロジェクトの集計 |
| セキュリティ | DLP ヒット・異常検知ログ |
| インフラ | 基盤メトリクス・障害ログ |
| 監査人（内部） | 読み取り専用、全件サンプル |
RAG / MCP 連携のリスク
RAG（Retrieval-Augmented Generation）と MCP（Model Context Protocol）は、ゲートウェイの外側に 新たなデータ経路 を作る。
| リスク | 説明 | 統制 |
|---|
| データ過剰取得 | ベクター DB から機密チャンクが混入 | インデックス時の分類ラベル、検索フィルタ |
| ツール横断 | MCP サーバが外部 API・DB に無制限アクセス | 許可 MCP サーバリスト、スコープ制限 |
| ゲートウェイ迂回 | ローカル LLM + 直結 MCP で統制外 | エージェント構成の事前登録、ネットワーク egress 制御 |
| プロンプトインジェクション | 取得文書内の悪意ある指示 | 入力サニタイズ + 出力ガードレール |
Phase 2 で RAG/MCP を許可する場合、ゲートウェイだけでは不十分。データソース登録制と MCP サーバのセキュリティレビューをセットで義務化する。
変更管理
| 変更種別 | 承認者 | リードタイム |
|---|
| 新規仮想キー（標準モデル） | PM + 自動 | 即日〜1 営業日 |
| 新規モデル追加 | セキュリティ + SE リード | 3〜5 営業日 |
| DLP ルール変更 | セキュリティ | 2 営業日（緊急は即時） |
| 本番ゲートウェイバージョンアップ | インフラ + セキュリティ | 変更ウィンドウ週 1 回 |
ポリシー文書体系
- LLM 利用ポリシー（全社）— 禁止事項・違反時措置
- データ分類ガイドライン — 送信可否マトリクス
- モデル選定基準 — 用途別推奨モデル
- インシデント対応手順 — 第 6 章・第 13 章と整合
- ベンダー管理方針 — プロバイダ契約・サブプロセッサ
成熟度モデル
| レベル | 状態 | KEEL の目標 |
|---|
| L0 | 個人キー、ログなし | （現状の一部） |
| L1 | ゲートウェイ + 仮想キー + 基本ログ | Phase 1 完了 |
| L2 | DLP + コスト配賦 + インシデント Runbook | Phase 1 後半 |
| L3 | RAG/MCP 統制 + コンプライアンスマッピング | Phase 2 |
| L4 | 顧客案件テンプレ・継続的改善 | Phase 2 完了 |
ガードレール適用フック（ライフサイクル）
ゲートウェイ上のポリシーは、リクエストの 4 フック に割り当てると実装と監査が一致する（TrueFoundry / Engineering Playbook 等の収束パターン）。
| フック | タイミング | 検査対象 | 代表制御 |
|---|
llm_input | モデル呼び出し前 | ユーザープロンプト、添付 | インジェクション検知、PII マスク、長さ制限 |
llm_output | モデル応答後 | 生成テキスト | 漏えいパターン、毒性、ポリシー違反 |
mcp_pre_tool | ツール実行前 | 引数・ツール名 | 許可リスト、OPA/Cedar、レート制限 |
mcp_post_tool | ツール応答後 | 取得コンテンツ | 間接インジェクション（RAG 汚染）検知 |
| 層 | 典型レイテンシ増 | 備考 |
|---|
| Input Guard | +20〜100ms | 本番は段階的ロールアウト（flag → block） |
| Gateway Policy | +5〜20ms | 認証・テナント分離 |
| Tool Allow-list | +10〜30ms | MCP フェーズで必須 |
| Output Guard | +50〜200ms | ストリーミング時はバッファリングとトレードオフ |
間接インジェクションは llm_input だけでは防げない。mcp_post_tool または llm_output でツール/RAG 由来コンテンツを再検査する設計を Phase 2 の必須要件とする。
第 1・3・7 章とのつながり
| 本章の骨格 | 読者向けの入口 | 本番深掘り |
|---|
| 4 管理領域・5 統制軸 | 第 3 章（ルール・教育の具体） | 第 7 章（PII・監査・RAG ACL） |
| ログポリシー | 第 1 章（送ってはいけない 5 つ） | 第 7 章（監査 5 問い） |
| RAG/MCP リスク | 第 1 章（シャドー AI） | 第 7 章（チャンク ACL） |
v1.7 補強 — MCP / Agent 統制を管理領域に含める
MCP や Agent は「アプリから LLM へ送るリクエスト」ではなく、LLM が外部システムへ作用する経路である。したがって、通常の API ゲートウェイ設計に加えて、ツール定義と実行時認可を統制対象に含める。
| 統制対象 | 最低限の管理項目 | Phase |
|---|
| MCP サーバ台帳 | 所有者、用途、接続先、認証方式、データ分類 | Phase 1 設計 / Phase 2 実装 |
| Tool schema | 名称、説明文、引数、戻り値、危険操作、変更履歴 | Phase 2 |
| Tool 実行 | ユーザー、Agent、意図、対象リソース、承認有無 | Phase 2 |
| Tool 変更 | 差分レビュー、署名、承認者、ロールバック手順 | Phase 2 |
Tool poisoning は、ツールの「説明文」や「引数スキーマ」に隠れた命令で Agent の判断を誘導する。ソースコードレビューだけでは検出できないため、ツール定義を構成管理し、変更差分を監査ログへ残す。
統制判断の粒度
| 判断 | 粗すぎる例 | 推奨粒度 |
|---|
| 誰が使えるか | 全社員に MCP を許可 | 部門・プロジェクト・ユーザー単位 |
| 何を読めるか | RAG インデックス全体 | chunk ACL / 文書 ACL |
| 何を実行できるか | Agent に全ツール許可 | read / write / export / delete の操作別 |
| いつ止めるか | インシデント後に手動停止 | 予算・異常回数・外部送信で自動停止 |
v1.11 — リスト・レジストリと Registry / Gateway の責務分離
| 役割 | 正本 | リストの性質 | 更新トリガー |
|---|
| Registry（目録） | Git registry/mcp-servers.yaml | 承認済み MCP サーバの allow 台帳 | 新規 MCP 申請・四半期レビュー |
| Gateway（実行時） | GW policy/*.yaml | ツール名 · 引数 · egress の deny/audit | インシデント · 脅威インテル |
| Runtime AuthZ | OPA / 社内 RBAC マトリクス | ロール → L1〜L11 の束 | 組織変更 · プロジェクト追加 |
| クライアント | .cursor/permissions.json テンプレ | 端末コマンド allow + 破壊 deny | 新 IDE 標準 · iwaken71 型事故後 |
allow 主か deny 主か（層ごとの推奨）
| リスト種別 | 推奨 | 理由 |
|---|
| モデル · MCP サーバ | allow | 未知の追加を止める |
| DLP キーワード · メタデータ IP | deny | 既知の漏洩パターンを遮断 |
| 端末コマンド | allow 日常 + deny 破壊 | 日常は許可、破壊は二重で塞ぐ |
ツール引数（git clean 等） | deny + regex | GW で引数まで見る（Phase 2） |
RBAC の束ね方（例）
| IdP ロール / チーム | 仮想キー | 許可モデル | MCP | 端末 Auto-run |
|---|
eng-backend | team キー | gpt-4o-mini, claude-sonnet | github-mcp, internal-wiki | Allowlist モード |
pm-readonly | 個人キー | gpt-4o-mini のみ | なし | 手動承認のみ |
sec-audit | 監査用 | 全モデル read-only 用途 | 監査 MCP のみ | 禁止 |
Cursor Enterprise では複数グループ併属時 より permissive な設定が勝つ場合がある。LiteLLM MCP は intersection（厳しい方）。製品ごとに評価ロジックが違うため、台帳でトレースする（第 15 章 KEEL-LST）。
