生成AI社内導入で最初に決める8つのセキュリティ・データ方針
生成AIを社内導入する際、契約前に決めておくべきデータの扱いとセキュリティ方針を8項目に整理。学習利用のオプトアウト、ログ保持期間、個人情報の入力範囲など、実務で揉めやすい論点を具体的に解説します。
「生成AIを業務で使いたいが、情報漏洩が怖くて踏み出せない」——私たちが受託開発の相談を受けるとき、最初に出てくる懸念はほぼこれです。そして多くの場合、この懸念は漠然としたまま社内稟議に持ち込まれ、「セキュリティが不安なので保留」という結論で止まります。
この記事は、情報システム部門の担当者や、部門主導で生成AI活用を進めたい実務責任者に向けて書いています。「何を決めておけば前に進めるのか」を8つの論点に分解し、それぞれで実際に揉めやすいポイントを整理します。抽象的なガイドライン論ではなく、契約書やツール設定の画面で実際に選択を迫られる項目に絞りました。
なぜ「漠然とした不安」で止まるのか
生成AIのセキュリティ議論が空回りする理由は、論点が3つの層に混在しているからです。
- 契約・約款の層：入力データが学習に使われるか、どこの国のサーバーで処理されるか
- システム設計の層：ログをどこに残すか、誰がアクセスできるか、社内システムとどう繋ぐか
- 運用ルールの層：何を入力してよいか、出力をどこまで信じるか、誰が責任を持つか
「AIは危ない」という議論は、この3層をまとめて扱おうとして結論が出なくなります。逆に言えば、層ごとに分けて一つずつ決めていけば、判断はかなり機械的にできます。
決めておくべき8項目
1. 入力データが学習に使われるか（オプトアウトの確認）
最も基本的で、かつ最も誤解が多い点です。同じ事業者のサービスでも、個人向けプランと法人向け・API利用でデータの扱いが異なることは珍しくありません。主要なクラウドAIサービスの法人向けプランやAPIでは、入力データをモデルの学習に使わない旨が規約で定められているケースが一般的ですが、これは契約形態とプランごとに必ず自分で確認すべき事項です。
確認すべきは以下です。
- 学習利用の有無は「デフォルトでオフ」か「申請してオフ」か
- その記述はどの文書（利用規約、DPA、セキュリティホワイトペーパー）にあるか
- プラン変更や無料枠併用で条件が変わらないか
稟議資料には「規約のどこに書いてあるか」をURLと該当条項名まで書いておくと、後任者が引き継げます。
2. データの保存場所（リージョン）
業種によっては、データが国外サーバーで処理されること自体が問題になります。金融、医療、公共分野の案件では、日本国内リージョンでの処理が要件になることがあります。
主要なクラウド事業者は日本リージョンでのAIサービス提供を進めていますが、モデルごとに利用可能リージョンが違う点に注意が必要です。「最新モデルは特定リージョンのみ」という状況は頻繁に起きるため、「国内リージョン限定」を要件にすると使えるモデルが絞られます。ここはトレードオフとして経営層に説明すべき論点です。
3. ログの保持期間とアクセス権限
見落とされがちですが、実務で最も揉めるのがここです。
生成AIを業務に組み込むと、入力プロンプトと出力結果のログが必ず溜まります。品質改善やトラブル調査には必要ですが、そこには社内の機微な情報が平文で並びます。
決めるべきは3点です。
- 保持期間：30日か90日か1年か。監査要件と調査実務のバランスで決める
- アクセス権限：誰がログを閲覧できるか。開発ベンダーは含むか
- マスキング：個人情報や顧客名を保存時に伏せるか
私たちが構築を担当する際は、ログを「操作メタデータ（誰が・いつ・どの機能を）」と「内容ログ（プロンプト本文）」に分け、保持期間とアクセス権を別に設定する構成を提案することが多いです。メタデータは長期保持、内容ログは短期という切り分けです。
4. 個人情報を入力してよいか、その範囲
「個人情報は入力禁止」と一律に決める企業は多いですが、これは運用が破綻しやすいルールです。顧客からの問い合わせメールを要約させる業務では、氏名や連絡先が本文に含まれているのが普通です。
現実的なのは、業務単位で許可範囲を定義するアプローチです。
例：カスタマーサポート部門の問い合わせ要約業務では、氏名・メールアドレス・購入履歴の入力を許可する。ただしクレジットカード番号、マイナンバー、健康情報は入力禁止とし、システム側で該当パターンを検知して警告を出す。
ここまで具体化すると、現場は判断に迷いません。逆に「機微情報は避けてください」という抽象的な通達だけでは、判断が現場任せになり、事故か過度な利用萎縮のどちらかに振れます。
なお、個人データを国外の第三者に提供する形になる場合、個人情報保護法上の対応（本人同意や体制整備）が必要になる可能性があります。この判断は法務部門または弁護士の確認を取るべき領域で、システム担当者が単独で決めるべきではありません。
5. 社内データとの接続方式
社内文書を検索して回答させる仕組み（RAG）を作る場合、権限設計が最大の設計課題になります。
よくある失敗は、社内の全文書を一つの検索インデックスに入れてしまい、本来アクセス権のない人事情報や役員資料が回答に混ざるケースです。検索基盤側で権限を持たせない設計にすると、後から権限を足すのは大規模な作り直しになります。
初期設計の段階で、
- 元システム（SharePoint、Google Drive等）の権限をどう引き継ぐか
- 権限判定は検索時に行うか、インデックス構築時に分離するか
- 権限変更（異動・退職）がどのタイミングで反映されるか \nを決めておく必要があります。ここは技術的な選択が業務要件に直結するため、情シスと業務部門が同席して決めるべき論点です。
6. 出力の取り扱いと責任の所在
生成AIの出力には誤りが含まれます。これは前提として受け入れた上で、「誰が確認して、誰が責任を持つか」を決めます。
実務では以下の3段階で整理すると運用しやすくなります。
| 用途 | 確認レベル |
|---|---|
| 社内の下書き・アイデア出し | 利用者本人の判断で足りる |
| 社外に出る文書の草案 | 作成者＋上位者のレビュー必須 |
| 契約・法務・医療・与信の判断 | AIの出力を判断根拠にしない |
3段目を明文化しておくことが重要です。「便利だから」で判断業務に染み出していくのが、最も事故が起きやすいパターンです。
7. シャドーIT（無許可利用）の扱い
正式導入を検討している段階で、すでに現場が個人アカウントで生成AIを使っている——これは非常によくある状況です。禁止通達を出しても、業務が楽になる道具を現場は使い続けます。
私たちの経験では、使える公式ルートを早く用意することが最も効果的な対策です。禁止だけを先に出すと、利用が地下化してログも残らなくなり、かえってリスクが上がります。
暫定的にでも「この用途、このツールなら使ってよい」という許可リストを出し、同時にネットワーク側で無許可サービスへのアクセスを可視化する。この2つを並行させる進め方が現実的です。
8. インシデント発生時の手順
「機微情報を誤って入力してしまった」という報告が上がったとき、何をするか決まっていますか。
- 誰に報告するか（窓口の明示）
- 事業者側にデータ削除を依頼できるか、その手順
- 報告した従業員を罰しない方針か
最後の点が実は重要です。報告者が責められる文化だと、インシデントは隠されます。「速やかに報告した場合は責任を問わない」旨を明記しておくと、実際の報告が上がってきます。
向かないケースも正直に書きます
ここまで整理しても、生成AIの導入を急ぐべきでない領域はあります。
規制上、判断根拠の完全な説明が求められる業務。与信判断や医療診断の一部など、「なぜその結論になったか」を再現可能な形で示す必要がある領域では、生成AIを判断主体に据えるのは適しません。補助的な情報整理に限定するのが現実的です。
入力データの機微性が極端に高く、外部送信が一切許容されない場合。この場合は自社環境で動くモデルの検討になりますが、運用コストと精度のトレードオフは相当に厳しくなります。「オンプレなら安全」という単純な話ではなく、モデル更新の負担や必要なGPUリソースを含めて評価すべきです。
業務プロセスが人によってバラバラで、正解が定義できない場合。AIの精度評価ができないため、導入しても効果を測れません。まず業務の標準化が先です。
まず何から始めるか
8項目すべてを完璧に決めてから始めるのは、現実には難しいでしょう。私たちが推奨する順番は次の通りです。
- 項目1・2（契約とリージョン）を先に確定する。これは後から変更が効きにくく、ツール選定を規定します
- 項目4（個人情報の範囲）を1つの業務に限定して定義する。全社ルールを先に作ろうとすると止まります
- その業務で小さく試し、項目3（ログ）と項目8（インシデント手順）を実運用に合わせて詰める
- 実績が出てから、他部門への展開ルールを整備する
「全社ガイドラインの完成」をゴールに置くと、たいてい半年経っても何も動きません。一つの業務で回し始めてから、そこで出た論点をルールに反映していくほうが、実効性のあるルールになります。
私たちは受託開発の立場から、この意思決定の整理段階からご相談を受けることが多くあります。技術的な選択とセキュリティ要件は密接に絡むため、要件を固めきる前の段階で技術側の意見を入れておくと、後戻りが減ります。導入検討で論点整理に迷われている段階でも、お気軽にご相談ください。