社内で生成AIを使わせるとき、情シスが決めるべきことは「ChatGPTを許可するか」「Copilotを全員に配るか」だけではありません。実務で問題になるのは、誰が、どの業務で、どのデータを、どのAI機能に渡し、後からどのログで説明できるかです。
特にMicrosoft 365 Copilot、Google WorkspaceのGemini、ChatGPT Business／Enterpriseのような法人向けAIは、ID、ファイル権限、監査ログ、コネクタ、外部共有と結びつきます。便利さだけを見て全社展開すると、既存の共有フォルダの過剰権限や、部門ごとの例外運用がAI経由で表面化します。
この記事では、情シスが初期導入時にそのまま使えるように、利用者区分、入力データの線引き、ログ確認、権限拡張、申請ひな型を一つの運用フローに整理します。
まず「ツール単位」ではなく「業務単位」で許可する
AI利用ルールで失敗しやすいのは、「このAIツールは安全か危険か」という二択で決めてしまうことです。同じ要約でも、公開済み資料の要約と、顧客問い合わせ履歴の要約ではリスクが違います。同じ文章作成でも、社内勉強会の案内文と、顧客への障害回答文ではレビュー責任が違います。
最初は次の4点を1枚の表にして、業務ごとに許可・条件付き許可・禁止を決めます。
| 判断軸 | 確認すること | 許可しやすい例 | 慎重に扱う例 |
|---|---|---|---|
| 利用者 | 社員、管理職、委託先、開発担当、管理者のどれか | 一般社員による公開情報の文章校正 | 委託先による顧客データの要約、API連携 |
| 入力データ | 公開情報、社内情報、機密、個人情報、認証情報のどれか | 公開済みWebページ、社内一般手順書 | 契約書、個別見積、人事評価、APIキー |
| AI機能 | チャット、ファイル添付、社内検索、外部コネクタ、APIのどれか | チャットのみ、ファイル添付なし | Drive、SharePoint、Slack、CRMとの連携 |
| 説明可能性 | プロンプト、出力、利用者、承認者、共有先を追えるか | 法人環境で管理者がログを確認できる | 個人アカウント、ブラウザ拡張、私物端末のみ |
Microsoft 365 Copilotは、Microsoft Graph上のメール、チャット、文書など、ユーザーがアクセス権を持つ組織データを利用して回答を生成する仕組みです。また、Microsoftは、Copilotが個々のユーザーに少なくとも閲覧権限がある組織データのみを表示すると説明しています。したがって、Copilot導入前にSharePoint、Teams、OneDriveの共有範囲を見直すことは、AI対策ではなく通常の権限管理そのものです。
https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy
利用者区分は5つに分ける
全社員を同じ権限にすると、管理者・開発者・委託先・一般社員の境界が崩れます。最初は次の5区分で十分です。
| 区分 | 許可する範囲 | 最初は止める範囲 | 管理ポイント |
|---|---|---|---|
| 一般利用者 | 公開情報、社内一般情報の下書き・要約・翻訳 | 顧客情報、契約書、個人情報、ファイル添付 | 禁止データ教育、利用ログ確認 |
| 業務オーナー | 部門内の利用申請、出力レビュー、例外判断 | 無承認の外部連携、部門外データ利用 | 承認履歴、レビュー責任 |
| AI管理者 | アカウント発行、権限変更、ログ確認、利用停止 | 自分だけでの例外承認 | 管理者権限の棚卸し、操作ログ |
| 開発・自動化担当 | API、RPA、社内システム連携の検証 | 本番データでの未承認テスト | 検証環境、APIキー、停止手順 |
| 外部委託先 | 業務範囲を限定した会社管理アカウント | 個人アカウント、期間無制限、広範な共有ドライブ | 契約終了時の削除、アクセス期限 |
ChatGPTの公式価格ページでは、Free、Go、Plus、Pro、Business、Enterpriseがプランとして案内されており、BusinessとEnterpriseは業務向けの位置づけです。自社で使う場合は、正式なプラン名、管理機能、データ保持、契約条件を導入時点で確認してください。
https://chatgpt.com/pricing/
入力してよいデータは「例」と「代替入力」まで決める
現場からは必ず「名前を消せば問い合わせ文を貼ってよいですか」「契約書を要約するだけならよいですか」「社内議事録は大丈夫ですか」と聞かれます。答えを都度変えないために、禁止だけでなく代替入力例を用意します。
| データ区分 | 初期ルール | 禁止・注意例 | 代替入力例 |
|---|---|---|---|
| 公開情報 | 利用可 | 未公開資料と混ぜない | 公開済みFAQをもとに説明文を整える |
| 社内一般情報 | 会社管理の法人環境で利用可 | 部外秘資料、限定共有資料を含めない | 全社員向け手順書を要約する |
| 社外秘・機密 | 承認制 | 未公開計画、個別見積、契約条件、開発ロードマップ | 固有名詞・金額・日付を抽象化して相談する |
| 個人情報 | 原則禁止。必要時は利用目的・契約・保護措置を確認 | 氏名、住所、メール、電話、評価情報、採用候補者情報 | 「顧客A」「候補者B」などに置換し、本人を識別できる情報を外す |
| 認証情報 | 禁止 | パスワード、APIキー、秘密鍵、トークン、接続文字列 | エラー内容だけを抜き出し、キーやトークンは削除する |
個人情報保護委員会は、個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合、特定された利用目的の達成に必要な範囲内であることを十分確認するよう注意喚起しています。したがって「学習に使われない設定だから何でも入力してよい」とは考えず、利用目的、第三者提供、委託関係、契約条件を確認する必要があります。
https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
ログ監視は「全部読む」ではなく「見る条件」を決める
私は普段JP1で社内システムの運用監視をしています。監視で一番痛感するのは、「全部を見る」運用は必ず破綻するということです。大事なのは、どの条件でアラートを上げ、誰が一次対応するかを先に決めておくことです。AI利用ログもまったく同じで、上の検知条件を「閾値、通知先、一次対応者」に落とし込めば、ひとり情シスでも回せます。
AI利用の監視で重要なのは、全プロンプトを毎日読むことではありません。見るべき条件を先に決め、問題が起きたときに誰が止めるかを決めることです。
| 確認項目 | 見る理由 | 初期の検知条件 | 対応 |
|---|---|---|---|
| 利用者・日時・ツール | 誰がいつ使ったかを説明するため | 深夜帯の連続利用、退職予定者の急増 | 業務オーナーへ確認 |
| 添付ファイル・コネクタ利用 | 社内データの参照範囲を把握するため | 未承認のファイル添付、外部連携 | 一時停止、共有権限の確認 |
| 個人情報らしき文字列 | 個人情報の過剰入力を防ぐため | メールアドレス、電話番号、顧客番号、住所形式 | 本人・上長へ連絡し再教育 |
| 認証情報らしき文字列 | 漏えい時の影響が大きいため | APIキー、秘密鍵、トークン、パスワード | 即時失効、インシデント扱い |
| 管理者設定変更 | 設定変更が事故につながるため | アプリ有効化、権限変更、保持設定変更 | 変更者と承認履歴を確認 |
Microsoft Purviewの監査ログでは、Copilotにプロンプトを入力した操作が「CopilotInteraction」として記録対象に含まれます。また、Microsoft 365 Copilotのユーザー操作データには、ユーザーのプロンプトとCopilotの応答が含まれると説明されています。
https://learn.microsoft.com/en-us/purview/audit-log-activities
https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy
Google Workspaceについては、Gemini in Workspace appsのアクティビティイベントがAdmin SDK Reports APIで取得でき、Google公式ドキュメントでは2025年6月20日以降、最大180日のローリング履歴が維持されると説明されています。実際に管理画面で何が見えるか、保存期間を延長できるかは、契約エディションと管理設定で確認してください。
https://developers.google.com/workspace/admin/reports/v1/appendix/activity/gemini-in-workspace-apps
権限拡張は4段階で行う
AIは一度便利だと分かると、すぐに「全社で使いたい」「ファイル添付も開けたい」「社内データ検索も使いたい」という要望が出ます。情シスは、広げる条件と止める条件を先に決めておきます。
| 段階 | 許可する範囲 | 広げる条件 | 止める条件 |
|---|---|---|---|
| 第1段階 | 公開情報の下書き、要約、翻訳 | 利用者教育が完了、禁止データ入力なし | 個人アカウント利用が残っている |
| 第2段階 | 社内一般情報の利用 | ログ確認手順、ファイル権限棚卸しが完了 | 共有範囲不明のフォルダが多い |
| 第3段階 | 部門データを使う業務支援 | 業務オーナー承認、出力レビュー、例外対応がある | 顧客情報・個人情報の誤入力が続く |
| 第4段階 | API連携、コネクタ、自動実行 | 検証環境、監視、停止手順、責任者が明確 | APIキー管理、監査ログ、障害時の切戻しが未整備 |
権限拡張の判断では、「問題がなさそうだから広げる」ではなく、拡張してよい条件と停止する条件を数値で決めておきます。たとえば、禁止データの入力が一定期間発生していない、利用ログを定期確認できている、問い合わせ対応の担当者が決まっている、共有範囲不明のフォルダが解消されている、などを拡張条件にします。
一方で、禁止データの入力が発生した、ログを確認できない利用経路が見つかった、APIキーやコネクタの管理者が不明、障害時の停止手順が決まっていない、といった場合は、次の段階へ進めず条件整理を優先します。数値基準は自社の監査方針や利用規模に合わせて決めますが、少なくとも「誰が確認し、どの状態なら止めるか」までは社内ルールとして明文化しておきます。
そのまま使えるAI利用申請ひな型
この申請項目は、私は実際にプリザンターでフォーム化して運用しています。紙やメールの申請だと、「誰が、どのデータまで許可したのか」が後で追えなくなるため、入力必須、選択式、承認者欄、ログ欄をフォームに組み込み、申請ごとにレコードとして残るようにしています。
口頭相談でAI利用を許可すると、後から「誰が承認したのか」「どのデータまで許可したのか」が追えなくなります。最初はフォームやチケットで、次の項目だけ残せば十分です。
AI利用申請ひな型
1. 利用部署：
2. 業務名：
3. 利用目的：
4. 利用するAIツール・プラン：
5. 利用者区分：一般利用者／業務オーナー／管理者／開発担当／委託先
6. 入力するデータ：公開情報／社内一般情報／機密／個人情報／認証情報なし
7. ファイル添付・コネクタ・API利用の有無：
8. AI出力の使い道：下書き／要約／社内検索／顧客回答案／業務判断支援
9. 人による最終確認者：
10. ログ保存・確認方法：利用ログ、管理者操作ログ、プロンプト本文の保存有無、保存期間、閲覧権限、エクスポート方法を記録する。
11. 誤入力・誤出力時の停止手順：
12. 業務オーナー承認：
ログ保存や閲覧権限が確認できない場合は、個人情報・機密情報を含む業務利用は避け、公開情報またはテストデータでの検証に限定します。
ひとり情シスの最初の到達点
少人数の情シスで、最初からDLP、SIEM、全ログ分析、部門別承認、教育コンテンツを全部そろえる必要はありません。まずは次の5点に絞ります。
- 業務利用は会社管理のアカウント・法人環境に寄せる
- 個人情報、機密情報、認証情報の入力禁止を先に周知する
- ファイル添付、コネクタ、API利用は初期状態では開けない
- 利用部署、利用目的、承認者を申請フォームで残す
- 月1回、利用者、管理者、例外承認、退職者、ログ確認状況を棚卸しする
最小権限とは、AI活用を止めるための言葉ではありません。安全に広げるために、最初の利用範囲を小さくし、ログで実態を見ながら段階的に開ける考え方です。情シスは「禁止する人」ではなく、現場が安心して使える道筋を作る役割として、業務単位の許可、入力データの線引き、ログ確認、停止基準をセットで整備しましょう。
コメント