生成AIに個人情報を入力してよい?社内ルールと確認手順

ビジネス戦略

2026.10.16

生成AIに個人情報を入力してよい?社内ルールと確認手順

目次

顧客メールの要約や議事録の整理、応募者の履歴書要約など、生成AIを業務で使いたい場面は増えています。しかし「学習オフだから安全」「氏名を消せば大丈夫」と単純に考えるのは危険です。本記事では、法的観点と社内運用の違いを明確にし、社員が即判断できる9項目チェックリスト、可・条件付き可・禁止の早見表、削除・置換・マスキング(実務的な加工)方法、部門別事例、誤入力時の初動手順を実務向けにまとめます。

結論(要点)

生成AIへ個人情報を送信することは法律で一律禁止されているわけではありません。ただし、利用目的、会社が承認したサービス・プラン・アカウント、送信後の保存・閲覧・再委託・処理国等の条件が確認できない場合は入力しないのが実務上の原則です。社内ルール(安全管理上の禁止事項)と、法令上の扱い(第三者提供・委託等の該当性)は分けて判断してください。(詳しくは「会社ルール」「法的観点」を参照)

個人情報入力の判断を左右する4要素

  • 情報の種類:氏名、連絡先、要配慮情報、認証情報など(法的リスクと漏えい影響は異なる)
  • 利用目的:要約・分析・応答生成など、取得目的との整合性
  • サービス・契約・設定:プラン単位での学習利用、保存期間、管理者設定、サブプロセッサ(再委託先)など
  • 削除・置換・マスキング(実務的加工):加工で目的を満たせるか、再識別リスクが残るか

社内向け運用は「入力可/条件付き可/入力禁止」の3段階がわかりやすい。ただし「可」でも必ず承認済みアカウントと範囲内利用が条件である点を明記してください。

法律上の扱いと社内ルールは別物

重要な前提:

  • 法的な分類(個人情報/要配慮個人情報/匿名加工情報など)は法令要件に基づく判断です。
  • 社内ルールはリスク低減のために企業が独自に設定するルールで、法令より厳しくすることが一般的です(例:マイナンバーは法令上厳格扱い、パスワードやAPIキーは認証情報として技術的理由で社内で入力禁止)。

したがって、本記事の「禁止」項目には法的禁止と社内での運用上の禁止が混在します。社外公開時には「法的根拠」と「社内運用例」を分けて表記してください。

「入力」に含まれる範囲(定義)

生成AIへの「入力」は、単にプロンプト欄に文字を貼り付けることに留まりません。以下の全てを含みます:

  • テキストの貼り付け、ファイル(PDF/Word/Excel/CSV等)のアップロード
  • スクリーンショットや画像、会議録音、動画の送信
  • メールやカレンダー、クラウドとの自動連携、ブラウザ拡張、プラグイン、API経由の送信
  • カスタムGPT等に取り込む知識ファイル、過去会話のメモリ機能への保存

また、ファイル名、メタデータ、コメントや変更履歴に個人情報が残る場合がある点に注意してください。

入力前の「9項目チェック」— 実務フロー(Yes/Noで判定)

以下は社内の誰でも使える実務フローです。どれか一つでも「No/不明」なら入力を止め、管理部門へ相談してください。

  1. 社内で明示的に入力禁止とされる情報が含まれていないか?
    (例:マイナンバー、要配慮個人情報、パスワード、秘密鍵、クレジットカード番号、NDAで禁止された情報) → 「含む」なら入力不可。
  2. データに個人を識別できる情報(氏名、メール、電話、顧客ID、顔写真等)は含まれているか?
    → 「含まない」なら通常の情報取扱で進める。含む場合は次へ。
  3. 生成AIへ送る目的は、データの取得時に通知・同意した目的の範囲内か?
    → 範囲外または不明なら入力しない(または同意を取得)。
  4. 契約・委託条件、取引先との約束(秘密保持等)に反していないか?
    → 反する/不明なら入力不可・相談。
  5. 送信先は会社が承認したサービス・プラン・アカウントか(個人アカウント不可)?
    → 承認済みでない場合は入力不可。
  6. 学習利用、保存期間、人による閲覧、再委託、処理国(海外での保存・処理)の条件を確認済みか?
    → 確認できない/否定的要素があるなら入力不可。確認方法は規約・管理画面・サービス確認票。
  7. 不要な個人情報を削除・置換・マスキングしても目的を達成できるか?
    → できるなら加工して再チェック。できないなら次の判断へ。
  8. 該当する業務が例外承認対象(人事評価、採否、与信、法的紛争など)ではないか?
    → 対象なら事前に所管部門の承認が必要。
  9. 入力・承認の記録を残せる体制があるか(利用者・日時・サービス・入力内容・承認者等)?
    → 記録が取れない場合は管理部門へ相談。

最終判断:

  • すべて「Yes」→ 承認済み環境で入力可(ただし必要最小限)
  • 加工で解決するものがある→ 削除・置換・マスキング後に再評価
  • 一つでも「No」または「不明」→ 入力せず、管理部門(法務・情報システム・個人情報保護担当)へ相談
  • 社内禁止情報に該当→ 入力不可

入力可/条件付き可/禁止の早見表(実務向け)

区分

具体例

社内運用(推奨)

入力可(低リスク)

架空データ、会社が公開した一般説明文、個人を含まない業務文書

承認済みサービスで利用可

条件付き可(加工で可)

顧客メール、問い合わせ履歴、議事録(氏名・連絡先等を削除・置換すれば可)

匿名化(削除・置換・マスキング)後、承認済み環境で入力

原則禁止(個別審査)

履歴書・人事評価・購入履歴・通話録音・健康診断結果

原則入力不可、業務上不可欠な場合は個別承認と厳格な管理で検討

入力禁止(即禁止)

マイナンバー、要配慮個人情報(※場合による)、パスワード、秘密鍵、クレジットカード番号

いかなる形でも送信不可

注:公開情報であっても、契約や取扱規約によって送信が制限される場合があります。「公開=自由に送信可」ではありません。

「学習オフ(学習利用しない)」は必要条件の一つだが十分ではない

学習オフ設定は、入力データがモデル改善に使われないことを意味する場合がありますが、次の点は別途確認が必要です:

  • 保存:会話ログやバックアップに残るかどうか(保存期間)
  • 人の閲覧:サポートや不正利用調査のため事業者の担当者が閲覧可能か
  • 再委託:サブプロセッサ(第三者事業者)による処理が行われるか
  • 処理国:どの国で保存・処理されるか(海外移転の法的影響)
  • 管理者制御:管理者が学習設定や外部連携を強制できるか

結論:学習オフは確認項目の一つに過ぎず、保存・閲覧・再委託・処理国等の条件を合わせて評価する必要があります。

個人を特定しにくくする「削除・置換・マスキング」の実務例と注意点

注:本項の「削除/置換/マスキング」は実務的な加工方法の説明です。個人情報保護法上の「匿名加工情報」「仮名加工情報」は法令上の要件を満たす必要があり、ここでの加工が法的に匿名加工情報等と同等であるとは限りません。

実務で使える置換例

  • 山田太郎 → 顧客A
  • 株式会社○○ 人事部長 → 取引先担当者
  • 1985年4月10日 → 40代
  • 東京都○区○町1-2-3 → 東京都内
  • 契約額1,280万円 → 1,000万〜1,500万円
  • taro@example.jp → 顧客メールアドレス
  • 2026年10月16日15時 → 2026年10月中旬

実務的な加工手順(推奨)

  1. 利用目的に必要な最小限の項目を特定する
  2. 不要情報は契約者側で完全に削除する
  3. 固有名詞は仮名化・置換(対応表は別管理)
  4. 日付・金額・地域は粒度を粗くする
  5. ファイルのメタデータ、変更履歴、非表示セルを削除する
  6. 別担当者による再識別チェックを行う(少なくとも1人)
  7. 加工後データのみを承認済み環境へ入力する

注意点:仮名化して対応表を社内に保持している場合、対応表の管理が不十分だと再識別リスクが残ります。加工だけで安心せず、第三者照合の可能性も評価してください。

部門別:実務での入力可否・代替案(抜粋)

営業

  • 顧客メール:条件付き可(氏名・連絡先・注文番号等は削除・仮名化)
  • 商談記録:条件付き可(案件名や企業名を仮名化)
  • 顧客リスト(一覧):不可(一覧のまま外部AIへ送信しない)

人事・採用

  • 履歴書・面接メモ・評価:原則不可または個別承認。テンプレ—項目のみを架空データで検証する代替案を推奨。

経理

  • 請求書・振込先等:実データは送信しない。書式改善は架空データで実施。

カスタマーサポート(CS)

  • 問い合わせ履歴:必要最小限の抜粋を作成し、氏名・連絡先・注文番号を削除して利用。

開発/情報システム

  • ログ・エラーログ:IP、ユーザー識別子、メール等の削除を行い、APIキーや秘密情報は絶対に投入しない。

マーケティング

  • CRM個票:個票投入は避け、集計データや匿名化済みサンプルを利用。

管理部門が生成AIサービスを承認する際のチェック項目(管理者向け)

承認は「サービス名」だけでなく「プラン」「契約主体」「設定可能な管理機能」単位で行うべきです。必要な記録(サービス確認票)を残してください。

主な確認事項(記録必須)

  • 契約主体・プラン名(対象とするアカウント種別)
  • 学習利用の有無(規約、管理画面で確認)
  • 保存期間・データ所在地(処理国)
  • 人による閲覧の可否・サブプロセッサ一覧(再委託先)
  • 削除方法・削除の可視性(ログ・バックアップへの反映)
  • 認証方式(SSO/MFA)・権限管理・監査ログの取得可否
  • インシデント通知・対応手順
  • 承認済み用途・入力可能な情報区分の明確化

運用例:承認後も半期またはプラン変更時に再審査を行い、サブプロセッサや処理国の変更があれば即再確認を義務付ける。

社内ルールに必須で盛り込む項目(テンプレ例)

社員向け(A4で1〜2枚に要約)

  • 利用可の生成AI一覧(プラン含む)と利用できるアカウント種別
  • 入力可能・条件付き可・禁止情報の早見表
  • 入力前の9項目チェックリスト(紙・電子で配布)
  • 簡易な削除・置換・マスキング手順
  • 誤入力時の連絡先と報告フォーマット

管理者向け(詳細別紙)

  • サービス審査フロー・サービス確認票テンプレ
  • アカウント管理・SSO/MFA・権限運用方針
  • 例外承認手続き(申請書、保持期間、ログ取得義務)
  • 定期的な監査・再審査スケジュール

誤って個人情報を生成AIへ入力したときの初動:順序と注意点

重要:自己判断で「削除で終わり」とせず、まずは証拠保全と社内窓口への報告を行ってください。削除は事実確認後、管理部門の指示に基づくのが安全です。

推奨される初動手順(優先順)

  1. 追加送信・共有を直ちに止める。
  2. 社内の緊急連絡先(法務/情報システム/個人情報保護担当)へ即報告する。
  3. 入力した画面のスクリーンショット、日時、利用者、サービス名・プラン・アカウントの記録を保全する。(証拠保全)
  4. 対象データの範囲(対象者名・件数・ファイルの有無)を特定する。
  5. 学習設定・保存期間・人の閲覧可否・再委託の有無を確認する。
  6. 管理部門の指示に従って、必要に応じて事業者へ削除依頼や調査依頼を行う。
  7. 本人通知や個人情報保護委員会等への報告の要否を、法務と連携して判断する。
  8. 再発防止策を策定・実施し、関係者へ周知する。

報告テンプレ(最低限伝える項目):発生日時/利用者/サービスとプラン/会社・個人アカウントの別/入力内容の概要/対象人数/ファイル有無/現在の削除状況/学習・保存設定/外部共有の有無

よくある質問(FAQ)

Q:法人版なら個人情報を入力してよいですか?

A:名称(法人版)だけで判断できません。プランごとの学習利用、保存期間、人による閲覧、再委託、処理国、削除手続きなどを確認し、社内で承認したプラン・アカウントでのみ利用してください。

Q:学習オフなら安全ですか?

A:学習オフは重要な確認項目の一つですが、保存ログやサポート閲覧・再委託・処理国は別途確認が必要です。学習オフだけで安全と判断しないでください。

Q:氏名を消せば入力できますか?

A:単に氏名を消すだけでは不十分な場合が多いです。役職・地域・年齢・案件内容などの組合せで再識別されることがあります。削除・置換・マスキング後も第三者照合で特定されないか評価してください。

Q:公開情報なら入力してよいですか?

A:公開情報であっても、利用目的・権利関係(転載制限など)・サービス側の取扱限制を確認する必要があります。「公開=自由に送信可」とは限りません。

Q:本人同意があれば問題ありませんか?

A:本人同意は重要ですが、同意の内容(第三者提供の可否、利用目的の範囲)、契約上の制約、社内規程、安全管理措置は別途確認が必要です。場合によっては同意だけでは不十分です。

まとめ(実務での要点)

  • 生成AIへ個人情報を送信することは法律上一律禁止ではないが、実務上は慎重に判断する必要がある。
  • 社内ルールと法的な要件を明確に分け、社員向けは簡潔に、管理者向けは詳細基準で運用する。
  • 入力前は9項目チェックを実施し、承認済みサービス・アカウントのみで必要最小限を送信する。
  • 学習オフは必要項目の一つだが、保存・閲覧・再委託・処理国の確認が不可欠。
  • 誤入力時はまず証拠を保全して社内窓口へ報告し、管理部門の指示で対応を行う。

参考・出典(確認推奨)

注:これらの文書は更新されます。公開時点の最新版と確認日を記事内に明記してください。法的判断が必要な場合は弁護士や個人情報保護担当に相談してください。

最終更新:2026-10-16。この記事は実務で使える判断フローとテンプレを優先して作成しています。内容は各社の業務実態や法改正により変わります。疑義がある場合は専門家に相談のうえ、社内ルールを整備してください。