はじめに
生成AIを業務に導入すると、問い合わせ対応、議事録作成、契約書の要約、顧客データ分析などを効率化できます。その一方で、従業員が入力した文章やファイルに、氏名、住所、電話番号、取引履歴、健康情報などが含まれる可能性があります。
特に注意したいのは、氏名や電話番号を削除しただけでは、必ずしも個人を特定できない状態になるとは限らないことです。所属部署、役職、年齢、地域、相談内容などを組み合わせることで、本人が推測される場合があります。
生成AIの個人情報保護では、単純な文字の置き換えだけでなく、入力前の検知、利用目的に応じた加工、生成AIサービスへの送信制御、出力内容の再確認、ログ管理までを一体として設計する必要があります。
生成AIに個人情報を入力することで生じるリスク
生成AIに入力された情報の扱いは、サービスや契約プラン、管理設定によって異なります。入力内容がモデル改善に利用されるのか、保存期間はどの程度か、国外のサーバーに移転されるのか、管理者が利用状況を確認できるのかを事前に確認しなければなりません。
個人情報保護委員会は、生成AIサービスに個人データを入力する場合、サービス提供者がその情報を機械学習に利用しないことなどを十分に確認するよう注意を促しています。また、生成結果に不正確な個人情報が含まれる可能性にも留意が必要です。
参考：生成AIサービスの利用に関する注意喚起等について｜個人情報保護委員会
入力した情報が想定外の目的で利用されるリスク
業務用の生成AIサービスであっても、入力データの保存、監視、不正利用対策、品質改善などの条件はサービスごとに異なります。
個人データが入力内容への回答以外の目的で扱われる場合には、第三者提供に関する検討が必要になる可能性があります。一方、契約や処理条件によっては委託として整理される場合もあるため、サービス名だけで判断することはできません。
利用規約やプライバシーポリシーだけでなく、法人向け契約、データ処理契約、管理画面の設定を含めて確認することが重要です。
プロンプト以外から個人情報が入る可能性
生成AIへ送信される情報は、利用者が入力する文章だけではありません。
例えば、次のような場所に個人情報が残ることがあります。
- 添付ファイルの本文、コメント、変更履歴
- PDFや画像に含まれる氏名、顔、住所、署名
- ファイル名やフォルダ名
- メールのヘッダーや署名欄
- 音声データに含まれる会話や周囲の声
- システムの操作ログやエラーログ
- RAGの検索結果として取得された社内文書
生成AIへの入力欄だけを監視しても、添付ファイルや連携システムから情報が流入すれば、十分な対策にはなりません。
マスキング・仮名化・匿名化の違い
生成AIの個人情報対策では、「マスキング」「仮名化」「匿名化」という言葉が使われます。これらは同じ意味ではなく、加工後の情報から本人を識別できるか、元の情報へ戻せるか、どのような目的で利用するかが異なります。
マスキングとは
マスキングは、氏名や電話番号などを伏せ字や別の表現に置き換える方法です。
例えば、「山田太郎」を「顧客A」、「090-1234-5678」を「電話番号1」に置き換えます。生成AIに文章の構造や意味を維持したまま処理させたい場合に利用しやすい方法です。
ただし、マスキングしただけで法令上の匿名加工情報になるわけではありません。個人情報保護委員会も、個人データを単にマスキングしただけでは匿名加工情報にはならないと説明しています。
仮名化・仮名加工情報とは
仮名化は、氏名などの識別子を別の値に置き換え、対応表を使えば元の人物との関係を確認できるようにする方法です。
業務上、同じ顧客の問い合わせ履歴を継続して分析したい場合などに向いています。ただし、対応表や元データを保有し、容易に照合できる状態であれば、加工後の情報も個人情報に該当する場合があります。
個人情報保護法上の「仮名加工情報」には、識別行為の禁止や第三者提供の制限など、一定の取扱いルールがあります。単に顧客名を顧客番号へ置き換えただけで、直ちに法令上の仮名加工情報として扱えるわけではありません。
匿名化・匿名加工情報とは
一般的な意味での匿名化は、個人を識別しにくい状態へ加工することを指します。一方、個人情報保護法上の「匿名加工情報」は、特定の個人を識別できず、元の個人情報を復元できないように、定められた基準に従って加工した情報です。
匿名加工情報を作成した事業者には、加工方法などに関する情報の安全管理、含まれる情報項目の公表、第三者提供時の明示、本人識別行為の禁止などの義務があります。
生成AIへ入力するデータを「匿名化済み」と呼ぶ場合は、一般的な匿名化なのか、法令上の匿名加工情報なのかを区別する必要があります。
生成AI向けマスキングで検知すべき情報
生成AIへ送信する情報を安全に加工するには、正規表現だけでなく、辞書、自然言語処理、文脈判定を組み合わせる必要があります。
定型的な個人情報
電話番号、メールアドレス、郵便番号、クレジットカード番号などは、一定の文字パターンを持っています。そのため、正規表現を利用した検知が比較的有効です。
ただし、数字だけで構成される情報は、注文番号、商品番号、日付などと誤認されることがあります。数字の桁数だけではなく、前後の表現や項目名も含めて判断することが重要です。
日本語の氏名・住所・組織名
氏名、住所、会社名、部署名などは表記揺れが多く、単純な辞書照合だけでは検知しきれません。
日本語では、同じ文字列が人名にも地名にも使われることがあります。「岐阜」「大垣」のような地名だけでなく、建物名、店舗名、ランドマーク、最寄り駅などから個人が推測されることもあります。
固有表現抽出と呼ばれる自然言語処理を使い、文章の文脈から人名、地名、組織名などを判定する仕組みが必要です。ただし、AIによる判定にも見逃しや誤検知があるため、重要な業務では人による確認を残します。
要配慮個人情報と文脈による識別
病歴、障害、健康診断結果、犯罪被害などの要配慮個人情報は、氏名を削除しても慎重な取扱いが必要です。
例えば、「岐阜県内の小規模な事業所に勤務する57歳の女性管理職」といった情報は、一つひとつが氏名でなくても、組み合わせることで本人が特定される可能性があります。
生成AI向けのマスキングでは、単語単位の検知だけでなく、希少な属性の組み合わせや自由記述に含まれる事情まで評価する必要があります。
PDF・画像・音声に潜む個人情報への対応
生成AIが扱うデータは、テキストだけではありません。PDF、画像、録音データ、動画なども、個人情報の流入経路になります。
OCRによる読み取り誤りへの対策
スキャンした申込書や請求書では、OCRを利用して文字を抽出してからマスキングします。しかし、OCRが氏名や番号を誤認すると、個人情報を検知できないまま生成AIへ送信するおそれがあります。
特に注意したいのが、「0」と「O」、「1」と「I」、濁点の有無、旧字体、手書き文字です。OCR処理後のテキストだけでなく、元画像上の該当領域も塗りつぶすなど、二重の処理が求められます。
音声認識におけるマスキング
会議やコールセンターの録音には、氏名や住所だけでなく、声そのものや背景の会話が含まれます。
音声を文字起こししてマスキングする場合、音声認識の誤りによって個人情報が残る可能性があります。また、文字起こし結果を加工しても、元の音声ファイルには個人情報が残っています。
音声データの利用では、録音の目的、保存期間、アクセス権限、文字起こし後の音声削除、生成AIへ送る範囲をあらかじめ定めることが重要です。
AIゲートウェイで個人情報を一元管理する
生成AIの利用を従業員個人の注意だけに任せると、部門や担当者によって対策の水準がばらつきます。そこで有効なのが、利用者と生成AIサービスの間に「AIゲートウェイ」を設ける方法です。
AIゲートウェイは、生成AIへ情報を送る前に、認証、権限確認、個人情報検知、マスキング、送信可否判定などを行う中継機能です。
入力前に実施する処理
入力前には、次のような処理を行います。
- 利用者と所属部門の認証
- 利用可能な生成AIやモデルの制御
- プロンプトと添付ファイルの個人情報検知
- 機密区分に応じた送信可否の判定
- 氏名などを識別用トークンへ置き換える処理
- 高リスク情報を検知した場合の承認申請
例えば、氏名を「PERSON_001」、会社名を「COMPANY_001」に置き換えれば、生成AIは文章の関係性を保ったまま処理できます。必要に応じて、生成結果を社内環境で元の表記へ戻すことも可能です。
この場合、対応表は生成AIサービスへ送らず、社内の分離された環境で厳格に管理します。
出力後にも再検査する
入力時にマスキングしても、生成AIが推測した氏名や、事実と異なる個人情報を出力する可能性があります。そのため、出力結果にも個人情報検知を適用します。
外部向け文書、顧客への回答、人事評価、医療・介護記録など、本人への影響が大きい用途では、自動出力をそのまま利用せず、担当者が内容を確認する仕組みが必要です。
ログにも個人情報を残さない
入力内容をマスキングしていても、システムログ、エラーメッセージ、監視画面、利用分析データに元の情報が残る場合があります。
ログについても、保存する項目、閲覧できる担当者、保存期間、削除方法を定めます。監査に必要な証跡は残しつつ、プロンプト全文を無条件に保存しない設計が望まれます。
生成AIの個人情報保護を実装する手順
ステップ1：利用目的と対象業務を明確にする
最初に、生成AIで何を行うのかを明確にします。「業務効率化」のような広い目的ではなく、「問い合わせ文の分類」「議事録の要約」「契約書から期限を抽出」といった単位まで具体化します。
そのうえで、入力される可能性がある情報と、個人情報を使わなければ実現できない機能を整理します。
ステップ2：データをリスク別に分類する
データを、公開情報、社内情報、機密情報、個人情報、要配慮個人情報などに分類します。
リスクが高い情報ほど、利用できる生成AI、保存期間、承認者、マスキング方法を厳しくします。すべてのデータに同じ処理を適用すると、過剰なマスキングによって業務に必要な文脈まで失われるためです。
ステップ3：利用目的に合った加工方法を選ぶ
文章の要約だけであれば、氏名や住所を削除しても支障がない場合があります。一方、同一人物の履歴分析では、人物ごとに一貫した仮名を割り当てる必要があります。
匿名化の強度を一律に決めるのではなく、利用目的、本人への影響、外部送信の有無、再識別の必要性を踏まえて選択します。
ステップ4：検知精度を継続的に評価する
実際の業務データに近いテストデータを使い、見逃しと誤検知を確認します。
特に、珍しい氏名、旧字体、手書き文字、会話表現、業界固有の略語、OCR誤認を含むデータで評価することが重要です。検知率だけでなく、過剰なマスキングによって生成結果の品質が低下していないかも確認します。
ステップ5：人による確認と改善の流れを作る
自動検知だけで個人情報を完全に防ぐことは困難です。高リスクの入力を保留し、担当者が確認できる仕組みを設けます。
見逃しや誤検知が発生した場合は、その記録を辞書、ルール、検知モデルの改善に反映します。現場からの報告を責任追及に使うのではなく、改善材料として扱うことも継続運用には欠かせません。
中小企業が優先して確認したいチェックポイント
生成AI導入の初期段階から、大規模な匿名化システムを構築する必要はありません。まずは次の項目から整備します。
- 個人情報を扱う業務を洗い出しているか
- 生成AIへ入力してよい情報と禁止する情報を定めているか
- 法人向けサービスのデータ利用条件を確認しているか
- 添付ファイルや画像も検査対象にしているか
- マスキング後の再識別リスクを確認しているか
- 出力結果を人が確認する業務を決めているか
- プロンプトやログの保存期間を設定しているか
- インシデント発生時の報告先を明確にしているか
- サービスの仕様変更を定期的に確認しているか
まず入力禁止情報を明確にし、承認済みの生成AIだけを利用できる環境を整えます。その後、利用量や対象業務の拡大に合わせてAIゲートウェイや自動マスキングを導入する方法が現実的です。
まとめ
生成AIの個人情報保護は、氏名を伏せるだけでは完結しません。マスキング、仮名化、匿名化の違いを理解し、利用目的とリスクに合った加工方法を選ぶ必要があります。
また、日本語の氏名や住所、自由記述、OCR画像、音声データでは、単純なパターン検知だけでは個人情報を見逃す可能性があります。入力前の検知、生成AIへの送信制御、出力後の再検査、ログ管理、人による確認を組み合わせることが重要です。
生成AIの利便性と個人情報保護を両立するには、「従業員が注意する」という運用だけでなく、個人情報が不用意に外部へ送られない仕組みをシステム側に組み込まなければなりません。
小規模な対象業務から検証を始め、見逃しや誤検知を継続的に改善することが、安全で実用的な生成AI活用につながります。
コメント