ひとり情シスのための生成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で販売しています。導入手順書の全文は無料サンプルとして公開しているので、雰囲気だけでも見ていってください。

無料サンプル：https://aiassist.booth.pm/items/8582988
キット本体：https://aiassist.booth.pm/

ここまで読んでいただき、ありがとうございました。質問・ツッコミはコメント欄へどうぞ。