ひとり情シスのための生成AI社内ルール整備 ―「全面禁止」以外の現実解
ひとり情シスのための生成AI社内ルール整備 ―「全面禁止」以外の現実解
中小企業で情シスを兼任していて、ある日「AIのルール、作っておいて」と言われた方へ。
この記事は、生成AIの社内ルールを 全面禁止以外の方法で 整備するための実務メモです。実際に企業内でルールを設計・運用した経験をもとに、以下をまとめます。
- なぜ「全面禁止」が情シス的に悪手なのか
- ルール全体の設計図（受け皿方式）
- ツール審査の5観点チェックリスト（確認場所つき） ← この記事の核です
- 申請フロー・インシデント初動の設計
1. なぜ「全面禁止」が悪手なのか
前提として、生成AIはすでに使われています。会社が認めていなくても、社員は個人のスマホや無料アカウントで、メールの下書きや調べものに使っています。いわゆる シャドーAI です。
ここで全面禁止を選ぶと、利用は水面下に潜ります。セキュリティの基本ですが、見えないものは守れません。
| 全面禁止 | 受け皿方式 | |
|---|---|---|
| 利用の可視性 | ゼロ（水面下に潜る） | 承認ツールに集約され見える |
| インシデント報告 | 来ない（報告＝違反自白） | 来る（責めない設計なら） |
| 情シスの管理コスト | 一見ゼロ、実際は把握不能 | 審査と記録の定常運用 |
| 現場の生産性 | 下がる or 隠れて使う | 公式に上げられる |
一番の問題はインシデント報告です。禁止環境では、うっかり顧客情報を入力した社員は絶対に報告しません。報告した瞬間、ルール違反が確定するからです。禁止はリスクをなくすのではなく、リスクを見えなくするだけです。
2. 全体設計：「受け皿」の3点セット
代わりに作るのは、次の3つです。
- 公式ルート … 会社が承認するツールと利用方法（アカウント種別まで）を明示する
- 申請窓口 … 新しいツールを使いたい人が、正規の手続きで申請できる
- 責めない記録 … 失敗を処罰ではなく、仕組みの改善につなげる
文書としては「全社員向けポリシー／管理者向け運用マニュアル／インシデント記録様式／外部公表前チェックリスト」の4点＋導入手順書、という構成に落ち着きます。ただ、文書の書き方より先に決めるべきなのが、次のツール審査基準です。
3. ツール審査の5観点（この記事の核）
「このAIツール、業務で使っていいですか？」に答えるための基準です。ひとり情シスでも回せるよう、確認場所までセットにしています。
| # | 観点 | 確認すること | 主な確認場所 |
|---|---|---|---|
| 1 | データの学習利用 | 入力内容がモデルの学習に使われない設定にできるか。個人向け無料プランは学習利用が前提のことがある | プライバシーポリシー、法人向けプラン説明、Trust Center、DPA |
| 2 | 提供元と規約 | 運営元が明確か。利用規約・プライバシーポリシーが公開されているか | 公式サイトの会社情報・規約ページ |
| 3 | 商用利用の可否 | 規約上、業務利用が認められているか（無料プランは商用不可の場合あり） | 利用規約、料金プラン比較表 |
| 4 | 生成物の権利 | 生成した文章・画像を業務資料に使ってよいと定められているか | 利用規約の知的財産条項 |
| 5 | 管理のしやすさ | アカウントの発行・削除を会社側で管理できるか（退職時対応）、費用と契約形態 | 法人向けプランの管理機能説明 |
最重要は観点1です。 ここを満たせないツールは、他が全部OKでも業務利用に向きません。
判断の型
- 5観点すべてOK → 承認（承認ツール一覧に用途と利用方法を明記して追加）
- 一部に不安 → 条件付き承認（例：機密情報を含まない用途に限定）
- 観点1がNG、または規約が確認できない → 非承認（理由と代替案を必ず返す）
- 調べても不明 → 保留（提供元に問い合わせ。回答期限を超えそうなら申請者に途中経過を一報）
回答期限は「原則5営業日」のようにSLAとして先に約束しておくと、申請が塩漬けになりません。
4. 申請フローは「貢献」として設計する
申請フロー自体はシンプルで構いません。
申請（ツール名・使いたい業務・期待効果の3点）
→ 責任者が5観点で確認
→ 5営業日以内に回答
→ 承認なら一覧に追加して全社周知
大事なのは技術面より心理面の設計です。ポリシーに「申請は面倒な手続きではなく、会社全体の道具箱を豊かにする貢献」と書き、非承認時も理由と代替案を返すと約束する。申請窓口が「却下される場所」ではなく「道が開く場所」だと伝わると、シャドーAIは公式ルートに吸い上がっていきます。
5. 入力禁止情報は「4分類＋習慣」で守る
DLPなどのソリューションを導入できない規模の会社では、分類と習慣で守ります。
入力禁止の4分類：①個人情報 ②自社の機密情報 ③取引先から預かった情報（NDA対象物、図面など） ④その他、社外に出せない情報すべて
そして、これだけで入力事故の大半を防げる習慣がひとつあります。
貼り付ける前に、伏せ字。
例：「田中様 090-1234-…」→「◯◯様（連絡先）」
メール本文をそのままプロンプトに貼る、が最頻出の事故パターンです。「貼り付け前に名前と連絡先を記号に置き換える」を全社の合言葉にしてください。
6. インシデント初動の5ステップ
報告が来たときの動きを、先に決めておきます。
- 感謝と事実確認 … まず報告に感謝。「何を・どのツールに・いつ」の3点から
- 影響の見立て … そのツールは学習利用オフの設定だったか、情報の機密度は
- 応急対応 … 会話履歴の削除、提供元へのデータ削除依頼、社外連絡の要否判断
- 記録 … 様式に沿って記録（後述の設計ポイント参照）
- 振り返りと共有 … 個人名・部署名を伏せて事例共有し、ルールや周知を改善
記録様式の設計ポイントは3つです。報告の経路（自主報告か否か）を記録すること、記入者は報告者ではなく責任者にすること（報告者に書類仕事を負わせない）、原因欄を「本人の不注意」で終わらせないこと。個人の注意力に頼る対策は、いずれ再発します。
7. 導入の進め方（目安：1〜2ヶ月）
- 現状把握 … 匿名アンケートで利用実態を知る（「犯人探しではない」と明言する）
- 責任者決定 … 「一番詳しい人」より「一番相談しやすい人」。兼任でOK
- 文書カスタマイズ … 完璧を目指さず、運用できる最小限で
- 説明会 … 「禁止ではなく、安心して使うためのルール」というメッセージを責任者の言葉で
- 施行と見直し … 初回は3ヶ月後、以降半年ごと。ルールは作って終わりではなく育てるもの
まとめ
- 全面禁止は、リスクを消すのではなく見えなくするだけ
- 公式ルート・申請窓口・責めない記録の3点で「受け皿」を作る
- ツール審査は5観点。最重要は「入力が学習に使われない設定にできるか」
- 事故対策の合言葉は「貼り付ける前に、伏せ字」
宣伝（すみません、少しだけ）
この記事の内容を、そのまま導入できる文書一式（Word形式・全10点）にしたテンプレートキットをBOOTHで販売しています。導入手順書の全文は無料サンプルとして公開しているので、雰囲気だけでも見ていってください。
ここまで読んでいただき、ありがとうございました。質問・ツッコミはコメント欄へどうぞ。
