生成AIに入れて良い情報、入れちゃダメな情報まとめ
生成 AI時代の「情報取扱い」はどう読み解くべきか
0. はじめに - 生成AIを“安心して攻めに使う”ために -
生成AIが業務に入り込むスピードは、もはや「実験」や「PoC」の段階を超えました。社内文書の下書き、チャットボット、データ要約、プロンプトベースの業務自動化……その応用範囲は広がり続けています。
しかし同時に、「この情報、AIに入力して大丈夫?」「外部サービスに預けてリスクはない?」「契約的にアウトでは?」といった “情報の取扱い”にまつわる不安も、現場では急増しています。
• どこまで入力していい?
• 社外に出していい情報/ダメな情報は?
• 法令・ガイドラインに準拠するには何をすべき?
• 自社サービスや開発での配慮点は?
本ガイドは、こうした現場の疑問や不安に答えるためにまとめました。
⸻
本ガイドの特徴
✅ 利用者/提供者/開発者の3視点で整理
✅ 国内法・ガイドラインだけでなく、越境移転・SCCなどの国際的要素も反映
✅ NG例・よくあるミスまで含んだ**「即使えるチェックリスト」形式**
⸻
こんな方におすすめです
• 社内で「生成AI活用方針」を考えている情報システム・法務・リーダー職の方
• 実際に生成AIを業務で使っている営業・CS・開発メンバー
• LLM を活用したアプリやサービスを開発しているエンジニア・PdM
⸻
今後ますます重要になる「生成AI × 情報保護」の実務知識。
ぜひこの記事を、“迷ったときに立ち返れるガイド”としてご活用ください。
では、まずは「情報の分類」と「どこまで入力して良いか」の判断軸を、実務で使える具体例とともに見ていきましょう。
本情報は2025.7月時点の調査結果であり、今後各国の法制度の変更などにより記事の内容と異なる場合があります。
1. 情報の3分類 ―― “色分け”でリスクを一目で判別
区分 | 定義 | 代表例 | 推奨ハンドリング |
---|---|---|---|
✨ 公開 OK | 既に公知・公開を前提とした情報 | プレスリリース、報道記事、特許公報 | 出典を明示すれば自由利用可 |
⚠️ 要注意 | 社内限定・未確定データ・個人情報断片 | ドラフト売上、部署構成、顔写真のみ | 公開時は要約・マスクでリスク低減 |
🆖 絶対 NG | 機密・本人特定・契約縛り情報 | NDA案件数値、顧客名+担当者、未発表仕様 | 外部共有禁止。社内も最小限の権限で |
上記は一般的な分類です。
自社内で取り扱う情報の分類は法務部門などに確認すると良いでしょう。
2. “5問テスト”で即席ジャッジ
- 既に公開済み? ➜ Yes ⇒ ✨
- 社内限定・未確定数字? ➜ Yes ⇒ ⚠️
- 個人が特定できる? ➜ Yes ⇒ 🆖
- 契約・法で守秘? ➜ Yes ⇒ 🆖
- 公開で事業リスクゼロ? ➜ Yes ⇒ ✨/No ⇒ ⚠️
迷ったら⚠️、確信が得られるまで🆖 が鉄則。
特に3,4については、現場担当者が勝手に判断することはやめましょう。判断が誤っていた場合、会社としての信頼失墜や法律違反につながる恐れがあります。
3. 個人情報を安全に扱う 7 ステップ — 実務シーン別の具体例
# | ステップ | 具体例 (GOOD) | NG 例 |
---|---|---|---|
1 |
目的限定 「何に使う?」を書き出す |
社内 FAQ ボット学習用として、顧客の問い合わせ内容を使う → “FAQ 強化” と明記 | 「今後の参考に」とだけメモして無目的収集 |
2 |
最小化 必要データだけ残す |
問い合わせログから 氏名・電話番号を削除、要件とカテゴリだけ保持 | 氏名・連絡先・社内メモを丸ごと残す |
3 |
仮名/匿名加工 再識別キーを別保管 |
顧客 ID=1234 を CID-abc に変換、対応表は暗号化フォルダへ | 仮名キーを同じ Excel シートに置く |
4 | 本人同意 or 法的根拠 | EC サイトの利用規約で「注文履歴をレコメンド AI に使う」同意を取得 | 利用規約に書かず、あとから AI に学習させる |
5 |
技術的安全管理 暗号化・RBAC |
データベースは AES-256 で暗号化、アクセス権は “AI チーム” グループのみ | 開発者全員が root 権限で閲覧可 |
6 | 第三者提供 & 越境移転管理 | U→JP は十分性認定、US→EU は 2025 SCC+TIA。送信日時・項目・相手国を 3 年記録 | 欧州個人データを契約なしで米国へ転送 |
7 | 期限到来で消去 | 「FAQ 用ログは 90 日後に自動削除」ジョブを設定 | データを “念のため” 永久保存 |
Tips: 移転根拠は Adequacy → SCC → 明示同意 の順で検討すると迷いにくい。
4. 立場別チェックリスト – 典型シナリオで理解する
立場 | よくある業務 | やること (OK) | やらないこと (NG) |
---|---|---|---|
利用者 (営業・カスタマーサポート等) |
新規提案書を ChatGPT に下書きさせたい | ❶ 企業名を “【大手小売A社】” に置換 ❷ 最終案は 自分でレビュー |
顧客正式名+担当者名+売上見込みを貼り付け即送信 |
提供者 (SaaS 事業者・情シス) |
社内向け “生成AI ポータル” を構築 | ❶ エンタープライズ契約+VPC 接続/リージョン固定 ❷ UI に「AI 生成」タグ自動付与 ❸ 十分性認定・SCC・送信ログ 3 年保存 |
パブリック環境の無料 API を直結 |
開発者 (アプリ/モデル開発) |
音声議事録アプリで LLM 要約 | ❶ 音声→テキスト化時に 社員名をイニシャル化 ❷ CI で Prompt Injection テスト |
生音声+人名をそのまま外部 LLM へ送る |
5. “生データを加工せず入力”する 最終手段 – 手順と例
手順 | 具体例 | ミスしやすい落とし穴 |
---|---|---|
① 本人同意を再確認 | カスタマーサクセスが「個別サポートの自動化」のため、顧客同意書に “生成AI 利用” を追記し再署名 | 「過去の同意でカバーできるはず」と思い込み、追加同意を取らない |
② 閉域/専用プランを使う | Azure OpenAI Enterprise で “0 retention モード” を有効化 | 無料・試用版に投入しログが 90 日残る |
③ 暗号化&RBAC 設定 | ストレージ Key Vault で鍵管理、アクセスは担当5名のみ | S3 バケットを公開設定のまま接続 |
④ 保持期間を強制 | S3 Lifecycle ルールで 30 日後自動削除 | “検証用にもう少し置くかも” と無期限延長 |
⑤ 監査ログ+72h 通報体制 | CloudTrail で API イベントを保存、漏えい時は CSIRT が 3 日以内に PPC と本人通知 | ログ未取得で「誰が触ったか分からない」 |
ポイント
最終手段ルートは “例外プロセス” としてワークフロー化し、利用時は 情報セキュリティ部門の承認 を必須にすると安全です。
6. 社内運用チートシート
- 「迷ったら⚠️ → 確信するまで🆖」
- 「目的・最小化・暗号化」=“三種の神器”
- 「同意・契約・ログ」=“三段ロック”
- 越境移転は Adequacy ⇒ SCC ⇒ 明示同意
これらの具体例を業務マニュアルや e-ラーニングに組み込めば、現場レベルで「生成AI × 情報保護」の勘所を共有しやすくなります。
補足:規制 & 標準の“最新トピック”
トピック | ポイント |
---|---|
EU AI Act | GPAI 透明性義務:2025‑08‑02発効。システミックリスク AI:2026‑08‑02までにリスク評価・重大事故報告義務 (Reuters) |
ISO/IEC 42001 | AI向けマネジメントシステム規格、組織全体でAIリスクを管理 (日本規格協会 JSA GROUP Webdesk) |
Deepfake規制(スペイン案) | 未ラベルAI生成物に最大 €35 M の罰金 (PetaPixel) |
日本版 AI 事業者ガイドライン v1.1 | “人間中心・説明責任” など 10 原則を提示 (経済産業省) |
参考リンクまとめ
- 欧州委「GPAI ガイドライン」(2025‑07‑18)(Reuters)
- ISO/IEC 42001 邦訳版発行告知(JSA, 2024‑04‑19)(日本規格協会 JSA GROUP Webdesk)
- Azure OpenAI Service FAQ(30 日保管)(Microsoft Learn)
- PPC「仮名加工情報」ガイドライン (PDF) (PPC)
- OWASP Top 10 for LLM Apps 2025 (PDF) (OWASP Foundation)
- スペイン Deepfake 法案 (2025‑03‑24) (PetaPixel)
- METI/MIC「AI Guidelines for Business v1.1」(2025‑04‑04) (経済産業省)
Discussion