監視から始める段階導入プレイブック。最初の2〜4週間の進め方
いきなり止めず、監視だけで2〜4週間走らせてから警告とブロックへ移す。初期の監視ポリシー8本、記録の見方、3行で済む警告文、切り替えの基準まで。
生成AIの制御は、いきなり止めるところから始めないでください。まず監視だけで2〜4週間走らせて、記録を見てから警告、ブロックと強めていきます。この記事は、その2〜4週間で何をするかをまとめたものです。
いきなり止めない理由
2つあります。
- 業務が止まります。現場が反発すれば、運用そのものが続きません。
- 何が起きているか分からないまま、ルールだけが残ります。止めなくていい操作まで止めていないか、逆に見落としがないか。記録がなければ、どちらも判断できません。
検知したときの動作は3つから選べます。ブロックは操作を止める。警告は理由を表示して、続けるかどうかを本人に委ねる。監視は何も表示せず、記録だけ残す。この順に使っていきます。
| 段階 | やること | 次に進む判断に使うもの |
|---|---|---|
| 監視 | 止めずに記録する。個人情報、機密ワード、ファイルなど、広めの条件で網を張る | どのサービスに、どんな情報が、どのくらい送られているか |
| 警告 | リスクの高い操作だけ、理由を表示する | 警告を見て操作をやめた割合。現場からの指摘 |
| ブロック | 業務で認めたAIは残し、機密情報の送信につながる操作だけ止める | ブロック件数の推移。業務が止まったという問い合わせの数 |
ポリシーの作り
ポリシーは1本ずつ作ります。決めるのは、どの操作を見るか、そのうちどれを引っかけるか、引っかかったらどうするかです。
- 見る操作は、貼り付け、アップロード、ログイン、拡張機能のインストールなど。イベントと呼びます。
- 引っかける条件は、電話番号の形を含む、社外秘という語を含む、といった指定。
- 引っかかったときの動作は、ブロック、警告、監視のどれか。
たとえば、貼り付けを見て、電話番号の形が含まれていたら記録する。これで1本です。
始める前に揃えるもの
- 配布経路。Google WorkspaceやMicrosoft Intune、Jamf ProなどのMDM、SKYSEA Client ViewやLANSCOPE、SS1などの資産管理ツール、手動導入のいずれかを決めます。
- 検証端末。10〜50台。情報システム部門など、自分で判断できる部署から選びます。
- 入力してはいけない情報の一覧と、その検知条件。正規表現かキーワードで書きます。ガイドラインで定めたものをそのまま使います。
- 会社管理ドメイン。会社アカウントと個人アカウントを見分けるために、先に登録します。
- 従業員向けの通知設定。ロゴ、表示名、共通メッセージ。警告の段階で必要になります。
初期の監視ポリシー8本
最初は広めに網を張ります。絞るのは記録を見てからです。次の8本は、多くの会社で最初に置く構成です。動作はすべて監視にします。
| ポリシー名の例 | 見る操作 | 引っかける条件 | 検知レベル |
|---|---|---|---|
| 個人情報の貼り付け | ペースト、テキスト入力 | 正規表現（電話番号、メールアドレス、郵便番号） | 高 |
| 社外秘ワードの貼り付け | ペースト、テキスト入力 | キーワード（社外秘、Confidential、取扱注意） | 高 |
| ファイルのアップロード（全件） | アップロード | 条件なし | 低 |
| 社外秘資料のアップロード | アップロード | ファイル内容またはファイル名に社外秘ワード | 重大 |
| 個人アカウントでのログイン | ログイン | アカウント確認結果が「外部」 | 中 |
| 個人アカウントへの貼り付け | ペースト | アカウント確認結果が「外部」 | 高 |
| AI系拡張機能のインストール | 拡張機能 | 拡張機能名に「AI」「GPT」を含む | 中 |
| 危険判定された拡張機能 | 拡張機能 | ブラウザ危険判定 | 重大 |
対象サービスは、生成AIの自動タグでまとめて指定します。新しいサービスが出ても追従できます。
3本目は条件なしで、アップロードを全部記録します。無駄に見えますが、社外秘という語が入っていないファイルの傾向は、これでしか見えません。
2〜4週間の進め方
- 第1週。検証端末に入れる。会社管理ドメインを登録し、監視ポリシー8本を投入し、通知連携のテスト配信まで済ませます。
- 第2週。記録を取り、初回の確認。条件を調整します。
- 第3週。リスクの高い条件から警告に切り替えます。従業員向けの説明文を確定し、切り替え日を周知します。
- 第4週。本番展開の対象と、ブロックへの切り替え日を決めます。
週割りは目安です。実際の期間は、対象サービスの数と、記録を見る担当者の時間で決まります。変えないでほしいのは一点だけ。ブロックに切り替える基準と日付は、記録の実績で決めてください。
設定を変えても、端末に届くまで45分程度かかることがあります。検証は反映を待ってから行ってください。
記録の見方
週に30分あれば足ります。順に見ていきます。
- 止めなくていい操作まで引っかかっていないか。過検知と呼びます。電話番号の正規表現が、社内の識別子や日付まで拾っていることがあります。桁数やハイフンの形で絞ります。
- 逆に、引っかかるべき操作が漏れていないか。こちらは未検知です。多いのは、対象のサービスが「未管理」のままで、ポリシーの対象から外れているケース。サービス管理で管理済みにし、タグを付けます。
- 偏りがないか。特定の部署に検知が集中していれば、その部署の業務に合わせて条件を変えます。
1と2は、ポリシー検知ログとアクティビティログを見比べると分かります。3はレポート画面で見ます。
警告文の書き方
警告の段階で差が出るのは、文面です。長く書かないでください。上限は500文字ですが、使い切る必要はありません。書くことは決まっています。誰からの通知か、なぜ止まったか、どうすればいいか。
メッセージの例情報システム部（内線1234）からのお知らせです。貼り付けた内容に電話番号が含まれています。生成AIへの個人情報の入力は、社内ルールで止めています。消すか伏せ字にして、お試しください。
禁止です、で終わらせないでください。その場で止まっても、回避行動を生みます。代わりの手段と相談先を書くと、警告そのものが教育になります。
ロゴと表示名を会社のものにしておくと、会社からの通知として受け取られます。拡張機能の不具合と誤解されにくくなります。
ブロックへ移す基準
感覚ではなく数字で決めます。目安は次のとおりです。
- 過検知の割合。警告を出した件数のうち、実際には対象の情報でなかった割合。1割を切るまで条件を絞ります。
- 警告を見て操作をやめた割合。高いほど文面が効いています。低ければ、文面か対象を見直します。
- 業務が止まったという問い合わせの件数。警告を始めて1週間で数えます。
この3つが安定したポリシーから、順にブロックへ切り替えます。全部を同じ日に切り替える必要はありません。
本番展開の順序
- 情報システムなど、自分で判断できる部門から。20名前後。
- 次に、機密情報を扱う機会の多い部門。営業、開発など。
- 最後に、PCを使うホワイトカラー全体へ。端末を使わない業務は対象外にします。
報告に使う数字
トライアルが終わったら、次を揃えます。経営層への報告が、推測ではなく記録で書けるようになります。
- 監視期間中の検知件数と、その内訳。サービス別、情報区分別、アカウント確認結果別。
- 警告に切り替えた後、操作をやめた割合。
- ブロックに切り替えた後の問い合わせ件数と、業務影響の有無。
- AIサービスの内訳。新規発見、未管理、管理済みの数と、その推移。
レポート画面はPDFで出力できます。そのまま添付資料にできます。
Related
