AIに資料をアップロードしても大丈夫？個人情報・機密・公文書の判断ガイド

アップロード前に聞く5つの質問

1. 個人情報や機微情報が含まれていないか。 氏名だけでなく、ID番号、電話番号、メールアドレス、住所、案件番号、珍しい職位、日時と場所の組み合わせでも、個人や案件を推測できることがあります。
2. 入力や出力は保存されるのか。保存期間は分かるか。 NISTはデータ保持を生成AIのリスク管理項目に含めています。
3. 商用利用、再処理、サービス改善などの二次利用があるか。止める手段はあるか。 NISTは商用利用、データ保護、データ保持、オプトアウトを治理項目として挙げています。
4. 誰が使い、何を入力したか追跡できるか。 NISTは匿名利用の抑制、利用者の資格・適格性、監視などに触れています。
5. 影響評価、インシデント対応、リスクベースの管理が用意されているか。 これらもNISTの生成AIリスク管理文書で示されている項目です。

1つでも答えられないなら、原文を入れる前に立ち止まるのが安全です。

データの種類別：基本の考え方

赤黄緑で考える：入れてよい資料、止める資料

緑：検討できるが、規約確認は必要

• すでに公開され、低リスクで、利用権限を確認できる資料。
• 個人、顧客、案件、社内機密に合理的に結び付かない形まで匿名化・要約した資料。
• 目的に必要な背景だけを抜き出した質問文。丸ごとの契約書、公文書、顧客表、コードベースではなく、最小限の説明にする。

ただし、公開情報だから無条件に安全とは限りません。公開資料の中に個人情報や機微情報が含まれるなら、プライバシーリスクとデータ保護の観点で扱う必要があります。

黄：先にマスキング、要約、承認フローへ

• 顧客、従業員、取引先、案件関係者、市民などの情報を含む資料。
• 契約草案、財務資料、社内プレゼン、議事録、法務意見、政策案。
• ソースコード、技術文書、システム構成図。特にAPIキー、パスワード、証明書、脆弱性情報が混ざる可能性があるもの。
• 政府・行政機関の内部文書、未公開公文書、決裁資料、評価・選定資料、機関間の協議資料。

この種類の資料は、AI利用が常に不可能というわけではありません。ただし、承認、保存ルール、監視、事故対応がない状態で一般公開型AIに投げ込むべきではありません。

赤：一般公開型AIに入れない

• 法令や社内規程で外部提供が禁じられている資料。
• 機密指定の文書、国の安全保障、調査、執行、調達評価などに関わる高機微資料。
• パスワード、APIキー、秘密鍵、証明書、アクセストークンなど、システムに入るための情報。
• 出所、権限、保存、削除、再利用の条件を確認できない資料。

匿名化は「名前を消す」だけでは足りない

氏名を消しても、電話番号、メールアドレス、住所、社員番号、顧客ID、案件番号、日付、場所、まれな肩書きが残っていれば、個人や案件を推測できる場合があります。EDPBの文書が焦点を当てるのも、LLMシステムにおけるプライバシーリスクとその緩和です。

比較的安全な進め方は、実名や会社名を仮名に置き換える、必要な箇所だけを抜き出す、原文を抽象化した相談文にする、名簿や表は集計値にする、原文処理が必要な場合は組織が承認したツールと手順に切り替えることです。

公的文書は「公開資料」と「内部資料」を分ける

公共部門で生成AIを使うこと自体は、単純に禁止か解禁かで片付く話ではありません。欧州委員会の共同研究センター（JRC）による生成AI Outlook報告は、公共部門での生成AI利用を専門項目として扱っています。

検討できるのは、すでに公開され、低リスクで、利用条件を確認できる公式資料です。一方で、未公開公文書、内部決裁資料、政策草案、調査・執行関連資料、調達評価資料、個人情報や機微情報を含む文書は、一般公開型AIに直接入れるべきではありません。欧州議会資料の事例一覧にも、公式Bundestagデータを使いつつ個人情報や機微情報を避ける例が示されています。

最後の判断基準

その資料が漏れたとき、個人、組織、公共の利益、法令順守に損害が出るなら、一般公開型AIに原文を渡さない。まず削る、ぼかす、要約する、最小限にする。どうしても原文処理が必要なら、承認済みの環境で、データ保護、保存期間、アクセス権限、監視、インシデント対応を確認してから使う。

AIに聞く前に、資料そのもののリスクを見極めることが、いちばん確実な安全策です。