AI活用で最も危険なのは、AIの出力を正解として扱うこと。社内展開では、利用ルール、証跡、責任範囲、禁止事項を明確化する必要がある。
Knowledge 索引（ガバナンス · リスク）
禁止事項・データ分類は risks.yaml。未決は open_questions.yaml。ルール変更時は notes/13_ガバナンス.md を先に更新する。
研修 — リスト・権限（ガバナンス追補）
機密投入禁止（13.1）に加え、端末の自動実行とリスト正本を PoC ガバナンスに含める。iwaken71 事例のように GW DLP では止まらない破壊操作がある。
| 統制 | 実装 | 証跡 |
|---|---|---|
| 端末 allowlist | .cursor/permissions.json | リポジトリにコミット |
| 破壊 deny | block_instructions + KEEL-LST-003 | Sec レビュー |
| リスト RACI | KEEL-LST-001〜007（GW 第15章） | 四半期レビュー日 |
| Run Mode | Auto-review（Run Everything 禁止） | オンボーディング記録 |
確認（3問）
| # | 正解 |
|---|---|
| 1 | denylist 単独は不十分 |
| 2 | リスト変更権限は RBAC で台帳化 |
| 3 | 曖昧な「整理して」は 2 段階（一覧→人間確認） |
設計正本: LLM GW v1.11 調査 · dev_docs
starter_kit/.cursor/permissions.json13.1 AIで品質が落ちる典型パターン
| パターン | 起きる問題 | 対策 |
|---|---|---|
| AI出力を鵜呑み | 仕様不一致、潜在バグ | 人間レビュー必須 |
| テストなしでマージ | 回帰バグ | CI必須 |
| 設計なしでコード生成 | 保守不能 | 実装前レビュー |
| セキュリティをAI任せ | 脆弱性見逃し | SAST/CodeQL必須 |
| 個人ごとに使い方が違う | 品質ばらつき | 標準プロンプト |
| 証跡がない | 後から検証不能 | PRに記録 |
| 生産性だけ測る | 品質悪化を見逃す | 品質指標も測る |
| インフラ本番操作をAIに任せる | 設定事故、停止、情報漏えい | 人間承認と検証環境必須 |
13.2 AI利用ルール
| 項目 | ルール |
|---|---|
| 機密情報 | 顧客名、個人情報、認証情報は投入禁止 |
| ソースコード | 契約・社内方針に従う |
| 設計書 | 機密度に応じて投入可否を判断 |
| AI出力 | 必ず人間が確認 |
| 証跡 | PR、課題、レビュー記録に残す |
| 成果物責任 | AIではなく担当者が負う |
| セキュリティ | AI修正後もスキャン必須 |
| テスト | AI生成コードはテスト必須 |
| インフラ作業 | 本番作業は承認・切り戻し手順必須 |
13.2b データ分類別AI利用可否
| 分類 | 例 | AI投入 | 条件 |
|---|---|---|---|
| Public | 公開資料、公開OSS情報 | 可 | 出典と確認日を残す |
| Internal | 社内手順、一般的な設計方針 | 条件付き可 | 社内許可済み環境を使う |
| Confidential | 顧客名、契約、非公開設計、障害情報 | 原則不可 | 必要時は匿名化・マスキング・承認を必須にする |
| Personal / HR | 勤怠、評価、意識調査、個人コメント | 原則不可 | 集計・匿名化し、個人評価には使わない |
| Secrets | 鍵、トークン、証明書、接続情報 | 禁止 | 検出時は即削除・ローテーションを検討する |
13.2c RACI / 承認マトリクス
| 対象 | R: 実行 | A: 承認責任 | C: 相談 | I: 共有 |
|---|---|---|---|---|
| PoCテーマ選定 | PoC担当 | 部門責任者 | 現場リーダー、品質担当 | 参加メンバー |
| AI利用ルール | 品質/セキュリティ担当 | 部門責任者 | 法務・情報システム | 利用者 |
| 公開スキル採用 | 技術リード | PoC責任者 | セキュリティ担当 | 利用チーム |
| 本番反映・顧客提出 | 担当者 | 案件責任者 | レビューア、顧客窓口 | 関係者 |
13.2d 公開スキル採用前チェック
- READMEだけでなく、実行される指示ファイルとスクリプトを確認する。
- 外部送信、ファイル削除、認証情報参照、ネットワークアクセスの有無を確認する。
- ライセンス、更新頻度、メンテナ、依存ツールを記録する。
- StarsやInstallsは人気の参考値に留め、品質保証の根拠にしない。
- PoCではバージョンまたはコミットを固定し、戻し方を決めてから使う。
13.3 禁止事項
- 顧客機密、個人情報、認証情報、秘密鍵、接続文字列をAIへ投入する。
- AI生成コードを理解せずにマージする。
- AI生成テストの期待値を確認せず採用する。
- AIレビューだけでセキュリティOKと判断する。
- AIに本番サーバやクラウドリソースを直接変更させる。
- AIにリリース可否、顧客合意、契約判断を任せる。
- AI出力を根拠なく確認済みとして扱う。
13.4 AI利用証跡
- AI利用有無
- AIを使った範囲
- AI出力に対して人間が確認した内容
- AI出力を採用しなかった理由
- テスト・レビュー・スキャン結果
AIが生成したコード、設計案、テストケース、手順書であっても、成果物責任は担当者とレビュー承認者にある。AIは責任主体にならない。
13.5 インフラ特有のリスク
| リスク | 例 | 対策 |
|---|---|---|
| 本番停止 | 誤ったsystemctl、FW設定、LB設定 | 検証環境、作業手順レビュー、切り戻し |
| 情報漏えい | 秘密鍵、証明書、接続情報の投入 | マスキング、投入禁止、ローカル処理 |
| 過剰権限 | IAM、sudo、DB権限の過剰付与 | 最小権限レビュー、Policy as Code |
| 公開範囲ミス | 0.0.0.0/0、不要ポート公開 | IaC scan、Security Groupレビュー |
| 復旧不能 | バックアップ未取得、リストア未検証 | 作業前バックアップ、復旧訓練 |
