主な読者: PMセキュリティPGSE
テンプレート集の使い方
本章のテンプレートは コピー＆ペーストで即利用 できる形式とする。正式版は社内ドキュメント管理システムに登録し、版管理する。
テンプレート 1: LLM 利用申請フォーム（項目定義）
| フィールド | 入力者 | 必須 | 説明 |
|---|---|---|---|
| 申請者氏名 | 利用者 | ○ | Entra ID と照合 |
| 社員番号 | 利用者 | ○ | |
| 所属部門 | 利用者 | ○ | |
| プロジェクトコード | 利用者 | ○ | PRJ-YYYY-NNN 形式 |
| プロジェクト名 | 利用者 | ○ | |
| PM 氏名 | 利用者 | ○ | 承認者 |
| 利用目的 | 利用者 | ○ | 200 字以内 |
| 利用期間（開始〜終了） | 利用者 | ○ | 最長 1 年 |
| 要求キー種別 | 利用者 | ○ | dev-standard / dev-premium / ci-batch / poc-sandbox |
| 要求モデル | 利用者 | △ | 標準外の場合のみ |
| 送信データの分類 | 利用者 | ○ | 公開 / 社内限定 / 顧客機密（要レビュー） |
| 顧客名（該当時） | 利用者 | △ | 契約確認トリガー |
| ポリシー確認チェック | 利用者 | ○ | 「LLM 利用ポリシー vX.X を読んだ」 |
| PM 承認 | PM | ○ | 承認 / 条件付き / 却下 |
| セキュリティ承認 | セキュリティ | △ | 顧客機密・premium 時 |
| 発行キー ID | インフラ | ○ | 発行後記入 |
申請者向け記入例（利用目的）
【利用目的】
PRJ-2026-042 受注管理システムのリファクタリングにおける
コードレビュー支援・単体テスト生成のため。
【送信データ】
社内共通フレームワークのコード断片、エラーログ（顧客名・本番データは含めない）
【期間】
2026-04-01 〜 2026-09-30テンプレート 2: モデル分類表
| モデル | 分類 | 用途 | データ制限 | キー種別 |
|---|---|---|---|---|
| gpt-4o-mini | 標準 | 日常コーディング、要約 | 社内限定まで | dev-standard |
| gpt-4o | プレミアム | 複雑設計、長文解析 | 社内限定、顧客機密禁止 | dev-premium |
| claude-3-5-sonnet | プレミアム | 同上 | 同上 | dev-premium |
| claude-3-haiku | 標準 | 軽量タスク | 社内限定まで | dev-standard |
| text-embedding-3-small | 埋め込み | RAG（Phase 2） | インデックス時分類必須 | 要個別申請 |
新モデル追加時は 必ずこの表を更新 し、セキュリティ承認を得る。
テンプレート 3: インシデント報告アウトライン
# LLM ゲートウェイ インシデント報告
## 基本情報
- インシデント ID: INC-LLM-YYYY-NNN
- 検知日時:
- 報告者:
- 重大度: P1 / P2 / P3
## 概要
（何が起きたか 3 行以内）
## タイムライン
| 時刻 | イベント |
| --- | --- |
| | 検知 |
| | 封じ込め（キー失効等） |
| | 復旧 |
## 影響範囲
- 影響ユーザー数:
- 影響プロジェクト:
- 漏洩データの有無: あり / なし / 調査中
- データ分類:
## 根本原因
（技術・プロセス・人的要因）
## 実施した対応
1.
2.
## 再発防止策
| 施策 | Owner | 期限 |
| --- | --- | --- |
| | | |
## エスカレーション
- 経営通知: 要 / 不要
- 顧客通知: 要 / 不要（法務判断）テンプレート 4: RACI マトリクス（LLM ゲートウェイ）
| 活動 | 経営 | PM | SE | PG | セキュリティ | インフラ |
|---|---|---|---|---|---|---|
| 年間予算承認 | A | R | I | I | C | C |
| 利用申請 | I | A/R | I | R | C | I |
| 仮想キー発行 | I | C | I | I | C | A/R |
| 日常利用 | I | I | R | R | I | I |
| DLP ルール定義 | I | I | C | I | A/R | C |
| 障害対応 | I | I | C | I | C | A/R |
| インシデント調査 | I | C | C | C | A/R | R |
| 四半期レビュー | A | R | C | I | R | R |
| 新モデル評価 | I | C | R | I | A | C |
| ポリシー改定 | A | R | C | I | R | I |
テンプレート 5: 顧客向け AI 利用説明（1 段落）
当社では、生成 AI を利用する際、社内 LLM ゲートウェイを経由し、
認証・データ損失防止（DLP）・監査ログの取得を行っています。
お客様の機密情報は契約に基づき AI モデルへの送信を制限し、
エンタープライズ契約によりモデル学習への利用はオプトアウトしています。
利用状況はプロジェクト単位で管理し、ご要望に応じて監査ログの説明が可能です。テンプレート 6: 変更要求（DLP ルール追加）
| 項目 | 内容 |
|---|---|
| 要求者 | |
| 追加パターン | （正規表現 or 説明） |
| 根拠 | （インシデント番号、顧客要件等） |
| 想定誤検知 | |
| セキュリティ承認 | |
| 適用日 |
運用上の注意
- テンプレートの改変は CoE または PMO が版管理
- 顧客向け文言は 必ず法務レビュー
- インシデント報告は検知後 24h 以内にドラフト作成
他章参照: 申請フロー詳細 → 第 10 章、インシデント手順 → 第 6 章。
v1.11 — KEEL リスト・権限台帳（KEEL-LST）
四半期レビューする 1 枚のマトリクス。Sec が正本、PM がモデル行、Infra が GW 行を起票。
| リスト ID | 対象 | 方式 | 正本パス | 所有者 | 権限編集者 | 最終レビュー | 層 |
|---|---|---|---|---|---|---|---|
| KEEL-LST-001 | 許可モデル | allow | gateway/models.yaml | PM + Sec | proxy_admin | Content GW | |
| KEEL-LST-002 | MCP サーバ | allow | registry/mcp-servers.yaml | Sec | org_admin | MCP GW | |
| KEEL-LST-003 | 破壊的シェル引数 | deny | policy/destructive-shell.yaml | Sec | proxy_admin | IDE + GW | |
| KEEL-LST-004 | 外部 URL | allow/deny | policy/egress-url.yaml | Sec | proxy_admin | Content GW | |
| KEEL-LST-005 | DLP キーワード | deny | dlp/keywords.yaml | Sec | proxy_admin | Content GW | |
| KEEL-LST-006 | 端末コマンド | allow+deny | .cursor/permissions.json | PG + Sec 雛形 | 各リポジトリ maintainer | クライアント | |
| KEEL-LST-007 | IdP ロール束 | RBAC | authz/role-bindings.yaml | PMO | IdP 管理者 | Runtime |
レビュー時チェック
- [ ] denylist のみに依存する層はないか
- [ ] allow と deny で 矛盾していないか
- [ ] 新規 MCP / モデル追加時に どの KEEL-LST を更新するかが申請書に含まれるか
- [ ]
git clean/git reset --hard/rm -rf/Remove-Item -Recurseが LST-003 または LST-006 にあるか - [ ] 誰がリストを変更できるか（RBAC）が RACI と一致しているか
destructive-shell.yaml（抜粋）
# KEEL-LST-003 — 既知の破壊パターン（deny 加速弾）
patterns:
- id: git-clean
match: "git clean"
severity: critical
- id: git-reset-hard
match: "git reset --hard"
severity: critical
- id: rm-rf
match: "rm -rf"
severity: critical
- id: powershell-recurse
match: "Remove-Item -Recurse"
severity: critical