生成AIに社内データを読ませる前の保全ルール【バックアップと権限の最低ライン】

生成AIに社内データを読ませると、検索、要約、議事録、問い合わせ対応はかなり楽になります。ただし、先に決めるべきなのはAIツール名ではなく、戻せるか、誰が見られるか、どこで止められるかです。

「学習されない設定にしたから安全」と考えると、重要な見落としが残ります。学習利用を止めても、既存の共有権限が広すぎれば、AIは見えている社内データを材料にできます。

この記事ではツール比較よりも、Google WorkspaceやMicrosoft 365を使う会社がAI接続前に確認したい保全ルールを整理します。先に守る順番が見えると、生成AIの導入判断はかなり落ち着きます。

まずはこの四つを同じ表に置き、投入前に止める場所を決めます。

生成AIに社内データを読ませる前に、まず保全を決める

社内データをAIに読ませる方法は1つではありません。ファイルをアップロードする、DriveやSharePointをコネクタでつなぐ、社内検索にAIを載せる、業務SaaSを連携するなど、入口が分かれます。

入口が違っても、最初に見る論点は同じです。AIに何を見せるかを決める前に、会社側のデータが整理されているかを確認します。

この時点で大事なのは、「AIに学習されるか」だけに話を寄せないことです。学習利用の確認は必要ですが、生成AIに社内データを学習させない設定の確認だけでは、共有権限や復元の問題までは解決しません。

バックアップは「戻せる場所・人・期限」で見る

AI導入前のバックアップ確認は、難しい専門用語から入る必要はありません。まず、どこに戻せるか、誰が戻せるか、いつまで戻せるかを1枚にします。

Google Workspaceのヘルプでは、Google Driveでユーザーがゴミ箱を空にした後、管理者が復元できる期間は25日以内と説明されています。削除ユーザーのDriveファイルについては、アカウント削除から20日以内という条件も示されています。

出典: Google Workspace Help「Recover deleted files and folders for Drive users」（英語）

つまり、標準の復元機能は便利ですが、いつでも何でも戻せるバックアップではありません。AIに社内文書を読ませる前に、重要ファイルが消えた時の戻し方を、管理者だけでなく業務責任者も理解しておく必要があります。

見る項目	確認すること	決めること
戻せる場所	Drive、共有ドライブ、外部保管	重要ファイルの保管先
戻せる人	管理者、業務責任者、委託先	復元依頼の窓口
戻せる期限	標準復元、保持、外部バックアップ	期限切れ前の対応
戻せる単位	ファイル、フォルダ、ユーザー単位	事故時の復旧範囲

Google Vaultを使っている会社でも、ここは混同しないでください。GoogleのVault FAQでは、Vaultはバックアップやアーカイブ用ツールとして設計されていないと明記されています。

出典: Google Vault Help「Google Vault FAQ」（英語）

権限はAI導入前に狭める

AIに社内データをつなぐ前に、権限を狭める理由は単純です。AIは魔法の境界線を作るのではなく、既存の閲覧権限を前提に答える場面があるからです。

Microsoft Learnでは、Microsoft 365 Copilotはユーザーが少なくとも閲覧権限を持つ組織データだけを表示すると説明されています。これは裏返すと、もともと権限が広い資料は、AI導入後も広く見える可能性があるということです。

出典: Microsoft Learn「Data, Privacy, and Security for Microsoft 365 Copilot」（英語）

Google Workspaceでも、管理者はDriveの外部共有オプションを設定できます。外部共有を止めるか、許可する相手を限定するか、リンク共有の初期値をどうするかは、AI接続前に確認したい項目です。

出典: Google Workspace Admin Help「Manage external sharing for your organization」（英語）

Copilotのように社内データへ深く接続するAIでは、AIコネクタ権限管理の棚卸しも合わせて進めると判断しやすくなります。さらに、アカウント、SaaS、APIキーまで見るなら、AIツールの権限棚卸し台帳へ展開できます。

Google Workspaceで最低限見るチェック項目

Google Workspaceを使っている会社では、最初から高度なセキュリティ設計を完成させるより、管理画面で見える項目を漏らさないことが先です。小さく始めるなら、次の5点で十分に実務の抜け漏れを減らせます。

• 外部共有: 取引先共有、公開リンク、個人アカウント共有が残っていないか。
• 全社員共有: 昔の全社フォルダに、給与、契約、顧客情報が混ざっていないか。
• 共有ドライブ管理者: 管理者が退職者のまま、または1人だけになっていないか。
• 退職者データ: 所有権移管、アカウント削除、保持方針が決まっているか。
• 復元とバックアップ: 標準復元期限と外部バックアップの有無を分けて説明できるか。

この5点は、完璧なゼロトラスト設計ではありません。それでも、生成AIに読ませる対象を広げる前の足場としては十分に効きます。

AIツール側は学習・保存・接続・ログに分ける

会社側の権限を整えたら、次はAIツール側を見ます。ここでも、学習利用だけを見て終わりにしないことが大切です。

OpenAIはEnterprise privacyページで、Business、Enterprise、API等のビジネスデータをデフォルトでは学習に使わないと説明しています。Microsoft 365 Copilotについても、Microsoftはプロンプト、応答、Microsoft Graph経由データを基盤LLMの学習に使わないと説明しています。

出典: OpenAI「Enterprise privacy at OpenAI」（英語）

ただし、これはすべての生成AIツールで同じという意味ではありません。契約プラン、管理設定、利用地域、ログ保持、外部アプリ接続によって扱いは変わります。

確認軸	見る内容	社内で決めること
学習	モデル改善に使われるか	許可するデータ範囲
保存	履歴、ログ、保持期間	削除・閲覧の担当
接続	Drive、SaaS、OAuth連携	許可アプリと解除方法
ログ	管理者が見られる利用履歴	監視ではなく改善に使う方針

ChatGPTなどの外部アプリ連携を使う場合は、接続アプリ権限の細分化も合わせて確認します。連携を許可する前に、どの操作で人が止めるかを決めておくと、情報漏洩と誤更新の両方を減らせます。

OWASPのLLM Top 10でも、Sensitive Information Disclosureは主要リスクとして扱われています。生成AIの入力欄だけでなく、コネクタや外部ツール接続まで含めて見るのが安全です。

出典: OWASP「OWASP Top 10 for LLM Applications」（英語）

試験運用は低リスクデータから始める

保全ルールは、紙で決めただけでは現場に残りません。最初の試験運用で、AIに読ませてよいデータだけを選ぶ練習をします。

データ分類は難しくしすぎない方が続きます。最初は次の3つで十分です。

1. 公開可: 会社案内、公開済み資料、一般的な手順書。
2. 社内限定: 社内マニュアル、議事録、見積テンプレート、業務ナレッジ。
3. 投入禁止または要承認: 顧客情報、個人情報、契約書、給与、採用、士業案件、医療・金融・法務に関わる資料。

この分類は、生成AIの社内ルールを禁止業務から決める考え方と相性が良いです。禁止ツール名ではなく、入力してはいけない業務とデータを決めると、現場が迷いにくくなります。

試験運用後は、利用ログを社員監視に使うのではなく、危ないリクエストを早く直す材料にします。月次で見る項目は、生成AIの利用ログ管理のように、禁止入力、外部公開、承認漏れへ絞ると運用しやすくなります。

よくある誤解を先に潰す

生成AIの安全確認で議論が止まる会社は、だいたい同じ誤解で迷います。次の表を、社内説明のたたき台にしてください。

誤解	実務上の見方	先にやること
学習されなければ安全	権限、保存、連携も見る	4項目チェック
Vaultがあれば戻せる	バックアップ用途ではない	復元期限確認
全社員共有は便利	AI接続後に見えすぎる	共有範囲を狭める
情シスだけで決める	禁止データは経営判断	責任者を決める

社内データの保全は、AIを止めるための作業ではありません。AIを安心して使える範囲をはっきりさせる作業です。

すぐに全社展開へ進めるより、低リスクデータで試し、戻し方と止め方を確認する方が、結果的に導入は速くなります。権限を狭めながら対象を広げる順番が、現場の不安を減らします。

よくある質問