生成AIに個人情報を入力しても大丈夫？企業利用で注意すべきポイント

「顧客から届いたメールを生成AIで要約してもよい？」

「社員情報が含まれたExcelをChatGPTにアップロードして大丈夫？」

「生成AI APIへ顧客情報を送ると第三者提供になる？」

「RAGで顧客情報を検索できるようにしたいが、個人情報保護法が心配」

企業で生成AIを利用すると、個人情報を扱う場面が少なくありません。

例えば、

問い合わせメール
顧客管理データ
応募者情報
社員情報
議事録
契約書
アンケート

などです。

生成AIはこれらの情報を、

要約
分類
文章生成
データ抽出
検索

する用途に利用できます。

一方で、

業務上持っている個人情報だから、
そのまま生成AIへ入力しても問題ない

とは限りません。

個人情報保護委員会も、生成AIサービスへ個人情報を入力する際には、利用目的の範囲や、サービス提供者が入力情報を機械学習へ利用するかなどを確認するよう注意喚起しています。

この記事では、企業が生成AIで個人情報を扱う場合に確認したいポイント、個人情報保護法との関係、第三者提供・委託の考え方、データを最小化する方法、APIやRAGを利用するときのシステム設計について解説します。

※本記事は一般的な情報提供を目的としています。具体的な法的判断は、利用するサービス、契約内容、データの種類、利用目的などによって異なるため、必要に応じて個人情報保護委員会の情報や専門家へ確認してください。

生成AIに個人情報を入力すること自体が一律禁止ではない

まず重要なのは、

生成AI
+
個人情報
=
すべて禁止

ではないという点です。

企業では既にさまざまなクラウドサービスへ個人情報を預けています。

例えば、

クラウドCRM
メールサービス
オンラインストレージ
勤怠管理SaaS
問い合わせ管理

などです。

生成AIについても、

何のサービスを利用するか

どの契約・設定で利用するか

何の情報を入力するか

何の目的で利用するか

サービス提供者が情報をどう扱うか

を確認して判断する必要があります。

個人情報と個人データは同じではない

個人情報保護法を考える場合は、「個人情報」と「個人データ」などの用語を区別する必要があります。

実務上は、

氏名
メールアドレス
電話番号
住所
社員番号と他情報の組み合わせ
顧客履歴

など、特定の個人を識別できる情報を扱う場合には注意が必要です。

さらに、その情報が会社の個人情報データベース等を構成する「個人データ」に該当する場合、第三者提供などについて追加の規律があります。

そのため、

氏名が含まれているか

だけで判断するのではなく、

どのような形で管理しているデータか

も確認します。

企業が生成AIへ個人情報を入力する前に確認したい5項目

まず次の5つを確認すると整理しやすくなります。

1．何の情報を入力するか

2．何の目的で利用するか

3．どの生成AIサービスを利用するか

4．サービス提供者がデータをどう扱うか

5．本当に個人情報を入力する必要があるか

それぞれ見ていきます。

1．何の個人情報を扱うのか

同じ個人情報でも、内容によってリスクが異なります。

例えば、

顧客の氏名

と、

顧客の氏名
住所
電話番号
契約内容
健康情報
口座情報

では、漏えいした場合の影響が大きく異なります。

生成AI利用を検討するときは、

個人情報を扱う

という大きなくくりではなく、

具体的に何の項目をAIへ渡すのか

まで整理します。

2．利用目的の範囲を確認する

個人情報は、取得時などに特定した利用目的との関係を確認する必要があります。

個人情報保護委員会は生成AI利用についても、個人情報取扱事業者が個人情報を入力する場合、利用目的の達成に必要な範囲内かを確認するよう注意喚起しています。

例えば、

顧客から受け取った問い合わせ

を、

問い合わせ対応のために要約する

場合と、

別の商品開発用AIの学習材料として利用する

場合では、利用目的との関係が異なります。

「AIを使う」というだけでなく、

元々取得した目的
↓
今回AIで行う処理

を確認します。

3．AIサービス側で入力情報がどう扱われるか確認する

特に重要です。

確認したいのは、

モデル学習へ利用されるか
データ保持期間
データ保存場所
再委託先
管理者機能
データ削除方法
法人向け契約の条件
API利用時の条件

などです。

個人情報保護委員会は、入力した個人データがサービス提供者において機械学習へ利用されることが予定されている場合には、個人データの第三者提供に関する規律との関係を確認する必要がある旨を注意喚起しています。

そのため、

ChatGPTだからOK

生成AIだからNG

とサービス名だけで判断するのではなく、

契約
設定
データ利用条件

まで確認します。

4．第三者提供・委託に該当するか確認する

企業が外部の生成AIサービスへ個人データを送る場合、

第三者提供なのか

委託なのか

そもそも「提供」に該当するのか

は重要な論点です。

個人情報保護法では、個人データの第三者提供は原則として本人同意が必要です。一方、利用目的の達成に必要な範囲で個人データの取扱いを委託する場合など、法上「第三者」に該当しないケースもあります。

ただし、

AIサービスだから自動的に委託

になるわけではありません。

契約やサービス提供者によるデータの利用方法など、実態に応じた確認が必要です。

クラウドサービスだから必ず委託になるわけでもない

個人情報保護委員会のFAQでは、クラウドサービスの利用について、クラウド事業者が個人データを取り扱わない契約・仕組みになっている場合など、「提供」に該当しないケースについても整理されています。

その場合でも、利用企業自身には安全管理措置を講じる必要があります。

つまり、

クラウドだから第三者提供

または

クラウドだから委託

と一律には判断できません。

5．そもそも個人情報をAIへ渡す必要があるか

ここが最も実践的なポイントです。

例えば問い合わせメールをAIで、

問い合わせカテゴリ

へ分類したいとします。

元メールには、

氏名：山田太郎
メール：xxx@example.com
電話：090-xxxx-xxxx
問い合わせ：商品の返品方法を知りたい

と含まれていても、分類に必要なのは、

商品の返品方法を知りたい

という文章だけかもしれません。

それなら、

元データ
↓
不要な個人情報を削除
↓
生成AI

とします。

「データ最小化」で生成AIのリスクを下げる

生成AIシステムを開発する場合、

DBにあるデータを全部AIへ渡す

のではなく、

AI処理に必要な項目だけ渡す

設計にします。

例えば顧客対応AIなら、

顧客ID
氏名
住所
電話番号
生年月日
契約プラン
問い合わせ内容
過去問い合わせ

というデータのうち、

AIに必要なのが、

契約プラン
問い合わせ内容
関連する過去問い合わせ

だけなら、その3つに限定します。

これは、

個人情報保護
+
セキュリティ
+
APIコスト削減

の面でも有効です。

経済産業省の最新「AI事業者ガイドライン第1.2版」でも、AI利用者を含む事業者がリスクを把握し、AIのライフサイクル全体で必要な対策を行う考え方が示されています。

氏名を仮IDへ置き換える方法

例えばAIに問い合わせ履歴を要約させる場合、

山田太郎

という氏名がAI処理に不要なら、

CUSTOMER_001

などへ置き換えることもできます。

顧客DB
↓
必要な情報を取得
↓
氏名等を仮IDへ変換
↓
生成AI
↓
要約
↓
顧客IDと紐付けてシステムへ表示

という構成です。

ただし、

名前を消したから
法律上必ず匿名加工情報になる

という意味ではありません。

他の情報との照合などによって個人を識別できる場合もあるため、法的な「匿名加工情報」等の概念とは区別して考える必要があります。

社員がChatGPTへ直接入力する場合の対策

企業の生成AI利用には大きく、

社員がAIサービスを直接利用する

方法と、

会社がAIをシステムへ組み込む

方法があります。

直接利用では、社員自身が入力内容を判断するため、

ルール
+
教育

が特に重要です。

例えば、

入力可能

公開情報

一般的な文章作成

個人を特定できない情報

条件付き

社内情報

顧客対応内容

社内ファイル

入力禁止

パスワード

APIキー

秘密鍵

会社が指定した機密情報

利用が認められていない個人データ

のように整理できます。

「個人情報は禁止」だけでは運用しにくい

例えば、

個人情報はすべて生成AIへ入力禁止

と決める方法もあります。

ただし実際には、

問い合わせ対応
採用
人事
CRM

など、個人情報が業務そのものに含まれるケースがあります。

そこで、

どのサービスなら使えるか

どのデータまで使えるか

どのような処理なら許可するか

まで具体化することが重要です。

API経由で生成AIを利用する場合

既存Webシステムへ生成AI APIを組み込む場合は、社員が直接コピー&ペーストするより制御しやすくなります。

例えば、

問い合わせ管理システム
↓
問い合わせ取得
↓
AIに不要な個人情報を除去
↓
生成AI API
↓
要約
↓
元の問い合わせ画面へ表示

とします。

この構成なら、

どのデータを送るか

をプログラム側で制御できます。

フロントエンドからAI APIを直接呼び出さない

例えば、

ブラウザ
↓
生成AI API

とするのではなく、

ブラウザ
↓
自社バックエンド
↓
データ抽出・権限確認
↓
生成AI API

とします。

自社バックエンドを経由することで、

認証
権限管理
入力データ制御
ログ
API利用制限

などを実装できます。

RAGで個人情報を扱う場合

RAGでは、

社内文書
顧客資料
問い合わせ履歴

などを検索対象にできます。

ここで注意したいのが、

RAGへ登録したデータを
全社員が検索できる

状態です。

例えば営業担当者Aが、本来担当していない顧客Bの情報をAI経由で取得できてはいけません。

そこで、

社員
↓
認証
↓
ユーザー権限確認
↓
検索可能データを限定
↓
RAG検索
↓
生成AI

とします。

RAGでは回答時ではなく検索時に権限を適用する

例えば、

AIへ
「権限のない顧客情報は回答しないでください」

とプロンプトを書く方法だけでは不十分です。

できる限り、

権限外データ
↓
そもそも検索対象にしない

ようにします。

例えば、

営業A
→ 担当顧客のみ

営業部長
→ 部署の顧客

管理者
→ 全顧客

と検索範囲を変えます。

AIエージェントで個人情報を扱う場合

AIエージェントではさらに注意が必要です。

通常の生成AIは、

個人情報を読む
↓
回答する

だけですが、AIエージェントは、

顧客を検索

CRMを更新

メールを送る

予約を変更

などを実行する可能性があります。

そのため、

個人情報へのアクセス権限

だけでなく、

個人情報を変更する権限

も管理します。

読み取り・更新・削除を分ける

例えば、

get_customer()

と、

update_customer()

を別にします。

さらに、

閲覧
→ AIが自動実行

更新案作成
→ AIが可能

実際の更新
→ 人が承認

削除
→ AIには許可しない

とできます。

生成AI利用で第三者提供を確認したい場面

特に確認したいのが、

外部生成AIサービスへ
会社が保有する個人データを送信する

場合です。

個人情報保護法では、個人データの第三者提供は原則本人同意が必要ですが、委託など法上第三者に当たらない類型もあります。

AIサービスの利用については、

提供事業者が
入力データをどの目的で利用できるのか

が重要になります。

例えば、

自社のためだけに処理する

ケースと、

提供事業者自身のモデル学習等にも利用する

ケースでは、検討すべき内容が変わります。

個人情報保護委員会も、生成AI提供事業者が入力された個人データを機械学習へ利用することが予定されている場合について注意喚起しています。

海外の生成AIサービスを利用する場合

生成AIサービスの提供主体やデータ処理先が海外にある場合は、

外国にある第三者への個人データ提供

に関する規律との関係も確認が必要になるケースがあります。

個人情報保護委員会は、外国にある第三者への提供について、委託を含む個人データの取扱いや必要な監督などをガイドラインで整理しています。

そのため企業導入時には、

サービス提供会社の所在地

データ保存地域

再委託先

契約内容

なども確認します。

生成AIサービス導入時のチェック項目

企業で個人情報を扱う場合、例えば次を確認します。

データ利用

□ 入力データがモデル学習等へ利用されるか

□ AI処理以外の目的で利用されるか

□ オプトアウト等の設定があるか

データ保持

□ データ保持期間

□ 削除方法

□ ログの保存期間

契約

□ 法人向け契約の有無

□ データ処理条件

□ 再委託先

□ 海外へのデータ移転

セキュリティ

□ 通信暗号化

□ アクセス制御

□ SSO・MFA

□ 管理者機能

□ インシデント時の対応

社内運用

□ 利用可能なAIサービス

□ 入力可能データ

□ 禁止情報

□ 社員教育

□ 問い合わせ窓口

生成AIへ個人情報を入力する前の実務フロー

迷った場合は、次のように判断できます。

STEP1
個人情報が含まれるか確認
↓
STEP2
AI処理の利用目的を確認
↓
STEP3
個人情報が本当に必要か確認
↓
STEP4
不要情報を削除・置換
↓
STEP5
利用するAIサービス・契約条件を確認
↓
STEP6
第三者提供・委託等との関係を確認
↓
STEP7
社内ルール上利用可能か確認
↓
STEP8
必要なら法務・個人情報保護担当へ確認
↓
STEP9
利用

具体例1．問い合わせメールをAIで要約

元メール：

山田太郎です。

東京都○○区に住んでいます。
電話番号は090-xxxx-xxxxです。

先日購入した商品Aを返品したいのですが、
手続きを教えてください。

要約に氏名・住所・電話番号が不要なら、

先日購入した商品Aを返品したい。
手続きを知りたい。

だけをAIへ渡します。

具体例2．CRMの顧客履歴を要約

CRMに、

氏名
住所
電話
商談履歴
契約内容

があるとします。

AIへ渡すのは、

商談履歴
契約プラン

だけにします。

CRM
↓
権限確認
↓
必要項目のみ取得
↓
AI
↓
要約

です。

具体例3．採用応募者情報

履歴書には、

氏名
住所
電話番号
生年月日
学歴
職歴

などが含まれます。

例えば、

職務経歴を300文字で整理する

だけなら、氏名・住所・電話番号が必要とは限りません。

不要な情報を除いたうえでAIへ渡す方法を検討します。

また、採用可否のような重要な判断については、生成AIの出力だけで自動決定するのではなく、人が最終判断する設計も重要です。

生成AIの個人情報対策でよくある失敗

「会社契約だから何を入力してもよい」と考える

法人向けサービスでも、社内の利用目的や情報管理ルールを確認する必要があります。

「氏名を消せば完全匿名」と考える

他の情報から個人を識別できる場合があります。

単なる氏名削除と、法令上の匿名加工情報は別物です。

AIへDBの全データを送る

必要な情報だけ取得します。

個人情報の判断を社員だけに任せる

利用可能・禁止・条件付きのルールを用意します。

AIの学習利用だけ確認する

学習利用だけでなく、

保持期間
保存場所
再委託
ログ
削除

なども確認します。

RAGに登録したら全社員から検索できる

RAGでも既存のアクセス権限を維持します。

個人情報をAIで扱う際の社内チェックリスト

□ AIへ渡す情報に個人情報が含まれるか

□ 利用目的との関係を確認したか

□ 個人情報をAIへ渡す必要があるか

□ 不要な項目を削除できないか

□ 利用サービスのデータ利用条件を確認したか

□ 第三者提供・委託等との関係を確認したか

□ 海外へのデータ移転を確認したか

□ 社内ルール上利用可能か

□ ユーザー権限を適用しているか

□ RAGでは検索時に権限制御しているか

□ ログへ不要な個人情報を残していないか

□ AI出力を人が確認しているか

生成AIと個人情報に関するよくある質問

ChatGPTなどへ顧客名を入力すると違法ですか？

顧客名を入力したという事実だけで一律に適法・違法とは判断できません。

利用目的、データの性質、利用するサービスの契約・設定、サービス提供者による利用方法などを確認する必要があります。

個人情報保護委員会も、生成AIサービス利用時には利用目的やサービス提供者によるデータ利用を確認するよう注意喚起しています。

個人情報を入力するなら本人同意が必ず必要ですか？

必ずとは限りません。

第三者提供に該当するか、委託等に該当するか、利用目的との関係などによって判断が変わります。

個人データの第三者提供は原則本人同意が必要ですが、委託など法上第三者に該当しないケースもあります。

氏名を削除すれば生成AIへ入力しても大丈夫ですか？

氏名を削除することはリスク低減に役立ちますが、それだけで個人情報に該当しなくなるとは限りません。

他の情報との組み合わせで個人を識別できる可能性も確認します。

APIなら個人情報を送っても問題ありませんか？

APIだから自動的に問題がなくなるわけではありません。

ただし、APIを自社システムへ組み込むことで、

必要項目だけ送る

権限を確認する

ログを管理する

といった制御をしやすくなります。

社内RAGに顧客情報を登録できますか？

技術的には可能ですが、閲覧権限などを設計する必要があります。

AI経由で本来閲覧できない顧客情報へアクセスできないようにします。

個人情報を含むデータはすべて生成AI利用禁止にすべきですか？

企業の方針として禁止することはできますが、一律禁止だけが選択肢ではありません。

業務上の必要性、利用環境、契約条件、データの重要度などを踏まえて利用範囲を設計します。

hiro-dev-labの生成AI・業務システム開発

hiro-dev-labでは、既存Webシステムや業務データと生成AIを連携する際の設計・開発を支援しています。

例えば、

OpenAI APIなどを利用したAI機能開発
既存システムへの生成AI組み込み
AIへ渡すデータ項目の制御
顧客情報の要約
問い合わせ対応支援
RAGによる社内文書検索
ユーザー権限を考慮したRAG
AIエージェント
MCPによる社内システム連携
Human in the Loop
AI処理ログ
Python・TypeScriptによるAI機能開発

などを検討できます。

例えば、

CRM
↓
ユーザー権限確認
↓
必要データだけ取得
↓
不要な個人情報を除去
↓
生成AI API
↓
結果をCRMへ表示

という構成です。

社員が毎回顧客情報を外部AIへコピーするのではなく、

システム側で
AIへ送信できる情報を制御する

こともできます。

企業の生成AI利用では「個人情報を送らない設計」を最初に考える

生成AIで個人情報を扱う場合、

個人情報を送っても大丈夫か？

だけを考えるより、

そもそも個人情報を送らずに
目的を達成できないか？

を最初に考えることが重要です。

例えば、

顧客データ
↓
必要項目だけ取得
↓
氏名など不要情報を除去
↓
生成AI

とします。

それでも個人情報が必要なら、

利用目的
↓
サービスの契約・データ利用条件
↓
第三者提供・委託等との関係
↓
安全管理措置
↓
社内ルール

を確認します。

生成AIの企業利用では、

使うか
使わないか

の二択ではありません。

どのデータを

どのAIへ

何の目的で

どのような仕組みで

どこまで渡すか

を設計することで、安全性と業務効率化を両立しやすくなります。

「顧客情報を生成AIで処理したい」

「AIへ渡すデータをシステム側で制御したい」

「個人情報を含む社内データをRAGで扱いたい」

「既存業務システムへ安全に生成AIを組み込みたい」

このような段階からでも、お気軽にお問い合わせください。

生成AI・業務システム開発について相談する