「顧客名を消せばAIに入れてよい」
「法人プランなら何でも安全」
「ローカルなら情報は漏れない」
どれも一部は正しく見えますが、実際の判断には足りません。
氏名を伏せても、契約条件や案件番号、取引履歴を組み合わせれば相手を推測できる場合があります。
法人向けサービスでも、履歴の保持、外部アプリ、Web検索、管理者設定によって情報の流れは変わります。
反対に、情報を含む文書を一律に禁止すると、従業員は公開情報だけで使うか、許可されていない個人アカウントへ流れるかのどちらかになりがちです。
必要なのは製品名だけの可否表ではなく「どの資料を、どの作業で、どの環境へ渡すか」を判断できる仕組みです。
本記事では、文書を4段階に分け、一般向けクラウド、法人向け環境、ローカルAIの特徴を整理します。
最終的な目的は最も閉じた環境を選ぶことではありません。
業務上の便益と漏えい時の影響を並べ、許可、条件付き許可、禁止を説明できる状態にすることです。
生成AIへの入力は、資料を別の処理環境へ渡す行為です。
チャット欄へ貼り付けるだけでも、入力内容、添付ファイル、生成結果、利用ログがサービス側または組織側に保存される可能性があります。
Web検索や外部アプリを有効にすれば、処理範囲はモデル提供者だけにとどまりません。
ただし、「クラウドに送る＝学習に使われる」とも限りません。
OpenAIはBusiness、Enterprise、Edu、APIなどの業務データを既定で学習に使わないと説明しています。
GoogleもWorkspaceデータを基盤モデルの学習・改善に使わないと案内し、Microsoft 365 Copilotはプロンプト、応答、Microsoft Graph経由のデータを基盤モデルの学習に使わないとしています。
ここで注意したいのは、学習利用の有無が安全性の全体ではないことです。
保存期間、障害対応時の閲覧可能性、データ所在、委託先、監査ログ、管理者の設定権限、退職者のアカウント停止、接続アプリの権限なども確認対象になります。
「学習しない」という一文だけで、高機密資料まで許可する判断はできません。
個人情報保護委員会は個人情報を含むプロンプトを入力する場合、利用目的に必要な範囲であるかを確認し、本人同意なく個人データを入力する場面では、提供者が応答以外の目的で扱わないことや機械学習に利用しないことを十分に確認するよう注意を促しています。
つまり、設定確認に加えて、自社がその情報を外部へ渡せる根拠も必要です。
ファイル名に「機密」と書かれているかだけで判定すると、分類漏れが起きます。
公開前の価格表、匿名化が不十分な顧客一覧、採用候補者の評価、未公開の提携交渉などは名称が普通でも漏えい時の影響が大きい資料です。
自社サイト、公開済みプレスリリース、一般公開された製品仕様などが該当します。
著作権や利用規約への配慮は必要ですが、秘密保持の観点では比較的扱いやすい範囲です。
社内手順、公開前ではない会議メモ、一般的な営業テンプレートなど、外部流出しても重大な損害へ直結しにくい情報を想定します。
ただし、複数資料を組み合わせると戦略が見える場合はレベルを上げます。
未公開の契約条件、価格戦略、顧客別の取引内容、ソースコード、営業秘密になり得る技術情報などです。
外部クラウドで扱うなら、契約、管理者設定、ログ、保持、削除、外部連携を確認し、用途ごとに承認を設けるべき領域です。
健康情報、人事評価、本人確認書類、認証情報、M&A交渉、重大インシデント資料などが含まれます。
原則禁止とし、処理が不可欠な場合だけ専用環境、最小権限、承認、記録を組み合わせます。
分類時には、漏えい時の金銭損失、法的責任、本人への不利益、競争力への影響、復旧可能性を見ます。
氏名を削除しただけでは十分とは限りません。
部署、役職、案件、日付、金額が揃えば再識別できるため、必要な部分だけを抽出し、仮名化したうえで入力する設計が欠かせません。
一般向けクラウドは導入が早く、最新モデルや検索、ファイル解析をすぐ使えるのが利点です。
一方、個人設定に依存しやすく、組織でアカウント停止、履歴、接続機能、ログを統制しにくい場合があります。
公開情報や低リスクの下書きには使えても、社内資料を個人アカウントへ入力する運用は避けるのが基本です。
法人向け環境では、業務データを学習へ使わない契約、SSO、管理者設定、監査、保持ポリシー、アクセス制御などを選べることがあります。
ただし、機能はプランや製品で異なります。
接続先のクラウドストレージに元から過剰な閲覧権限があれば、AIもその権限内の情報を提示し得ます。
導入前に権限棚卸しを行わなければ、AIが既存の設定不備を見えやすくするだけです。
ローカルAIは、モデルと文書処理を端末や社内サーバー内へ置き、外部送信を減らせます。
高機密資料の要約や検索には有力ですが、「ローカル」という名称だけで通信ゼロとは判断できません。
ライセンス認証、モデル更新、障害情報送信、Web取得、クラウド同期が残る場合があります。
端末紛失、マルウェア、バックアップ、共有フォルダの権限、古いモデルや実行環境の脆弱性も自社の責任になります。
同じ資料でも、全文要約と文章校正では送る情報量が違います。
検索付き回答では外部通信が増える可能性があり、翻訳では固有名詞を残す必要があるかもしれません。
資料レベルと作業を掛け合わせて条件を決めます。
判断表は固定ルールではなく、承認の入口です。
たとえば契約書の要約を法人環境で許可する場合も、取引先との秘密保持契約が再委託や国外処理を制限していないか、サービスの保持期間を設定できるかを確認します。
検索機能が不要なら切り、全文ではなく該当条項だけを渡します。
評価は「入力前」「処理中」「出力後」に分けると運用しやすくなります。
入力前は分類、最小化、承認。
処理中は利用環境と接続機能。出力後は誤り、出典、保存先、共有範囲、削除を確認します。
生成結果にも元資料の機密性が引き継がれる点を忘れてはいけません。
営業部門が提案書を作る場合、公開済み製品情報から構成案を出す作業は一般クラウドでも進めやすい一方、顧客名、予算、課題、競合情報を含む個別提案は法人環境へ限定します。
実名を「A社」に変えるだけでなく、業種や拠点、案件規模など再識別につながる情報も減らします。
人事部門では、求人票の表現調整と候補者評価を分けます。
公開求人の文章改善は低リスクですが、履歴書、健康情報、評価コメントを使う作業は高リスクです。
AIの出力を採用判断へ直接使わず、必要性、法的根拠、説明可能性を確認したうえで担当者を限定します。
法務・総務では、公開済みひな型のチェック観点を洗い出す用途と、締結前契約書の全文解析を分けます。
後者は秘密保持条件、保存、ログ、削除、外部連携を確認し、AIの指摘を法的判断として扱わない運用が必要です。
社内ルールは「禁止情報一覧」だけで終わらせず、利用可能なアカウント、許可された機能、文書レベル、承認者、例外申請、事故時の連絡、ログ保存、退職・異動時の権限変更まで含めます。
違反を責める文書ではなく、迷ったときに誰へ聞けばよいか分かる設計にすると、無許可利用を減らしやすくなります。
最初から全社で完璧な分類を目指す必要はありません。
利用頻度の高い3業務を選び、実際の入力例、許可環境、禁止事項、確認者を1枚にまとめます。
試行期間中に誤入力、再試行、人の確認時間、削除依頼を記録し、許可範囲を見直します。
機密資料をAIで扱う判断は、クラウドかローカルかの二択では解けません。
文書の機密度、作業内容、送信範囲、契約、管理機能、端末管理を組み合わせて初めて、許可条件が明確になります。
一般向けクラウドは公開情報、法人向け環境は組織管理が必要な社内資料、ローカルAIは外部送信を抑えたい高機密処理に向きます。
ただし、どの環境にも残存リスクがあります。
最小限の情報だけを渡し、不要な連携を切り、出力を同じ機密区分で管理し、削除と監査まで設計することが現実的な出発点です。
.png){kind=logo}
