AIに個人情報をどこまで扱わせるか エージェント時代の接続設計

「個人情報はAIに入れないでください」

社内ルールとしては、よく見かけます。分かりやすいし、間違ってもいない。

ただ、このルールが守っているのは入力欄だけです。AIが自分でファイルを開いたら、どうなるのか。

人が何も打ち込まなくても、いまのAIは共有フォルダを読み、メールを検索し、社内システムに接続します。入力欄を規制しても、そこに顧客名簿が置いてあれば同じことです。

この記事で言いたいことは1つです。個人情報をAIに扱わせるかどうかは、その都度の入力で決まるのではなく、何に触れられる状態にしてあるかで決まります。判断の場所が変わりました。だから要るのは禁止の一行ではなく、確認する項目のリストです。記事の最後に、そのリストを置きました。

判断の場所が、入力欄から接続設計に移った

まず、前提の変化を確認します。

数年前まで、AIに個人情報を渡すというのは、人がプロンプトに打ち込む行為でした。だから「入力しない」というルールが機能した。1件ずつ、人が判断できたからです。

いまは違います。AIが業務を代行する形が広がって、こういうことが起きます。

• 「先月の問い合わせを分類して」と頼むと、AIが接続済みの問い合わせ管理システムを検索して、必要と判断した範囲を読む
• 「この資料をレビューして」と頼むと、権限のある場所にある関連ファイルまで開きにいく
• 定型作業を任せると、人が見ていない時間帯にも同じ処理が走る

どこまで読めるかは、接続時に与えた権限、元のサービス側の権限設定、実行時の承認の有無で決まります。ただ共通しているのは、1件ごとに人が渡す瞬間がないことです。それでも扱われている。

量も変わりました。1件のメール校正と、顧客リスト全件の処理では、同じ「AIに個人情報を扱わせた」でも意味がまったく違います。前者は人が判断できる。後者は判断する前に終わっています。

ここで、押さえておきたい点が1つ。個人情報保護委員会が2023年6月2日に出した生成AIサービスの利用に関する注意喚起は、事業者向けの注意事項を個人データを含むプロンプトの入力という場面で書いています。

当時としては当然です。ただ、AIが自分でデータを取りに行く形について、この文書が個別に論じているわけではありません。エージェントを正面から扱っているのは、より新しいAI事業者ガイドラインのほうです。

だからといって規律が及ばないわけではなく、むしろ逆です。人が1件ずつ判断できないなら、先に決めておくしかない。何に接続させるか、どのフォルダを読ませるか、どの権限で動かすか。

入力時の判断が要らなくなったわけではありません。判断すべき場所が、入力欄より上流にも広がったということです。

「渡さない」は方針ではなく思考停止

そのうえで、公的機関が何と言っているかを見ておきます。

同じ注意喚起の、個人情報取扱事業者向けの節に書かれているのは次の2点です。

① 個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合には、特定された当該個人情報の利用目的を達成するために必要な範囲内であることを十分に確認すること

② (前略)このようなプロンプトの入力を行う場合には、当該生成AIサービスを提供する事業者が、当該個人データを機械学習に利用しないこと等を十分に確認すること

読み返してみてください。「入れてはならない」とは、どこにも書かれていません。書いてあるのは「確認すること」です。

①は、そもそも何のために集めた情報かという話です。採用のために集めた履歴書を、採用の判断を助けるAIに読ませるのは利用目的の範囲内かもしれない。同じ履歴書を営業リストの作成に使うなら範囲外です。AIに扱わせるかどうかより前に、その使い方が元の目的に収まっているかを見ろ、ということになります。

②は、入れた個人データが応答結果の出力以外の目的で扱われると違反になりうる、だから学習に使われないことを確認せよ、という構造です。

ここは慎重に読んでください。学習に使われないことの確認は、必要な条件のひとつであって、それだけで扱わせてよいと決まるわけではありません。利用目的の範囲、本人の同意が要るかどうか、委託や第三者提供にあたるか、安全管理措置は足りているか。判断すべきことは他にもあります。

それでも、禁止ではなく条件が示されている、という事実は大きい。

誤解のないように書いておくと、問題は「渡さない」と決めたこと自体ではありません。この記事も、最後にはチャット型のAIに個人情報を渡さないという結論を出します。問題は、その一行で終わりにして、AIが自分で読みにいく経路を見ないまま済ませてしまうことです。入力欄に鍵をかけても、隣のドアが開いていれば意味がありません。

判断が面倒だから禁止のほうが楽、という力学は実際にあります。

学習に使わせなくても、データは消えていない

次に、誤解の多い部分です。

「学習に使わない設定にしたから安全」。これは半分しか正しくありません。学習に使わないことと、データが残らないことは別の話です。

OpenAI。APIに送られたデータは2023年3月1日以降、モデルの学習には使われません(明示的にオプトインした場合を除く)。ただし公式ドキュメントには、不正利用監視のログがすべてのAPI利用について生成され、既定では最大30日間保持されると書かれています。法的義務やサービスの保護に必要な場合は、これを超えることもあります。Zero Data Retentionという設定もありますが、これは監視ログから顧客の入力内容を除外する仕組みで、対象外のエンドポイントや機能もあります。利用には事前承認が必要です。

Anthropic。保持期間の説明によれば、会話を削除するとチャット履歴からは即座に消え、バックエンドの保存システムからは30日以内に削除されます。ただし例外があって、自動の安全性システムに利用ポリシー違反の疑いありとフラグされた場合は、入力と出力を最大2年、分類スコアを最大7年保持するとあります。

違反が確定した場合ではなく、システムがフラグを立てた段階です。ここは読み違えやすい。

期間の長短より、判断の立て方が変わることのほうが大事です。「学習に使われないから何を扱わせてもいい」ではなく、「一定期間預ける相手として信用できるか」。他のクラウドサービスを選ぶときの考え方に近づきます。

設定そのものの手順はAIサービス別オプトアウト早見表にまとめました。この記事は、その先の話です。

エージェントが触ったものは、3つの軸すべてで確認する

ここが今回の中心です。

「チャットAIは危ないが、開発ツールなら手元で完結するから安全」。そう考えたくなりますが、事実は違います。クラウド型のAIサービスを使うなら、見るべき軸は3つあります。

そしてエージェントに任せる場合、この3つで確認すべき対象は、人が打ち込んだ文字だけではありません。AIが読んだファイルの中身も、同じ経路をたどります。ただし何がどこまで記録されるかは軸ごとに違うので、順に見ていきます。

軸1 サービス側に何がどれだけ残るか

当たり前のようでいて、見落とされます。AIが扱った内容は、応答を作るためにサービス提供者のサーバーへ送られます。手元で動くツールでも同じです。

Claude Codeの公式ドキュメントは、はっきり書いています。

Claude Codeはネットワーク経由でデータを送信します。このデータには、すべてのユーザープロンプトとモデル出力が含まれます。

エージェントが読み込んだファイルは、モデルに渡すためにプロンプトの一部になります。つまり人が打ち込んでいなくても、読ませた時点で送られています。

そして保持期間が、契約とプランで変わります。

アカウント	Anthropic側の保持
個人プランで学習利用を許可している	最大5年
個人プランで許可していない	30日
法人プラン(Team・Enterprise・API)	標準30日

5年のほうは範囲が決まっていて、Anthropicの説明によれば、設定を有効にしたあとの新規または再開した会話が対象で、匿名化された形式で訓練パイプラインに保持されます。それでも、個人のPro契約のまま業務で使っていて設定を確認していないなら、長い側に入っている可能性があります。法人プランなら標準30日で、Zero Data Retentionは有資格の組織のみが対象です。

「開発ツールだから外に出ていない」という感覚は、ここで崩れます。

軸2 端末に何が残るか

サービス側とは別に、手元にもログが残ります。ここは開発ツールで顕著です。

同じ公式ドキュメントによれば、Claude Codeは会話の全文を ~/.claude/projects/ の下に平文で保存し、既定では30日で自動削除します。ローカルデータの仕様には、さらに踏み込んだ記述があります。

トランスクリプトと履歴は保存時に暗号化されません。OSのファイル権限だけが保護手段です。

打ち込んだプロンプトを全件記録するファイルは、自動削除の対象外で無期限に残ります。タイムスタンプとプロジェクトのパス付きで。

エージェントの話として重要なのはここです。同じドキュメントには、ツールが設定ファイルを読んだりコマンドが認証情報を画面に出したりすると、その値がそのまま会話ログに書き込まれると明記されています。人が入力していない情報が、AIの行動の結果としてログに残るということです。読ませたファイルに個人情報が入っていれば、それも同じ経路をたどります。

端末の紛失、共有パソコンでの利用、退職者の端末回収。ここが手当てされていないと、サービス側をいくら固めても意味がありません。

軸3 会話や作業をまたいでコンテキストを持つか

3つ目は、独立した保存場所ではありません。会話や作業をまたいで文脈を持つ機能のことで、その中身はサービス側か端末、あるいは両方に置かれます。見えにくいぶん、抜けやすい。

先に押さえておくと、メモリは触れたものを全部覚えるわけではありません。Claudeの公式説明では、役割やプロジェクト、作業の進め方といった仕事の文脈を選んで記録する、とされています。全件保存ではなく、選ばれたものが持ち越される。だからこそ、何が選ばれたのかが見えにくい。

ChatGPTのメモリに関する公式FAQに、こういう記述があります。

ChatGPTが覚えている可能性のあるものを完全に削除するには、それが現れるすべてのソースを削除する必要があります。過去のチャット、アーカイブされたチャット、ファイル、メモリサマリー、そしてその情報を含む可能性のある接続アプリの切断も含みます。

さらに、メモリをオフにしても過去のチャットは消えず、後でオンに戻すと残っている履歴から新しいメモリが作られることがあるとも書かれています。

逆に言えば、その会話にだけメモリを使わせない手もあります。ChatGPTの一時チャットは、既存のメモリを参照せず、新しいメモリも作りません。

Claudeのメモリはプロジェクトごとに空間が分かれていて、混ざりにくい設計です。記録を残したくない会話にはIncognitoも使えます。ただしTeam・EnterpriseプランのIncognitoチャットは標準のデータエクスポートに含まれ、組織のデータ保持ポリシーに従います。個人の感覚で「残らない」と思っていても、会社としては残っている。

そして開発ツールにもメモリはあります。Claude Codeにはプロジェクト単位で蓄積される自動メモリが既定で有効になっていて、セッションをまたいで読み込まれます。エージェントが業務を覚えていくということは、その業務で扱った内容も持ち越しうる、ということです。

CodexにもComputer Historyという似た仕組みがあります。こちらは既定でオフで、法人利用なら管理者の許可に加えて本人のオプトインが要ります。有効にすると、操作イベントは一時ファイルとしてOpenAIのサーバーで処理され、そこから作られたメモリが端末にプレーンテキストで保存されます。このファイルは暗号化されません。詳しくはComputer Historyの記事に書きました。

開発ツールに変えても、サービス側は消えない

3つの軸を並べると、こうなります。

点検軸	何を確かめるか
サービス側	プランと設定で保持期間がどう変わるか
端末	何が平文で残り、誰が触れるか
会話や作業をまたぐ機能	有効になっているか、消し方を知っているか

チャット型か開発ツールかで、どの軸が重くなるかは変わります。ただどちらか一方だけを見ればよい、という話にはなりません。開発ツールに切り替えてもサービス側は消えず、そこに端末側のログという論点が加わります。

チャット型でも、デスクトップアプリやダウンロードした出力が端末に残ることはあります。逆に開発ツールでも、設定で履歴の記録を抑えられます。厚さは構成しだいなので、3つとも見るのが早い。

保管するクラウドと、処理するAIは分けて考える

ここで一度、足元を見ておきたい。

「個人情報を外部に出さない」という方針を掲げている会社が、実際には何を使っているか。メールと予定表はGoogle WorkspaceかMicrosoft 365。給与と勤怠はクラウドの人事労務サービス。顧客管理はSalesforceやkintone。会計もクラウド。社内の連絡はSlackやChatwork、Teams。

このどれもが、個人情報を自社の外のサーバーに置く行為です。

法律上の扱いには、判断の枠組みがあります。個人情報保護委員会のQ&Aは、クラウドサービスの利用が第三者提供に当たるかどうかの基準をこう示しています。基準は、保存する電子データに個人データが含まれるかどうかではなく、そのクラウド事業者が個人データを取り扱うことになっているかどうかである、と。

取り扱わないことになっていれば、第三者提供にも委託にも当たらない。だから本人の同意も要らず、委託先としての監督義務も生じません。ただし別のQ&Aで、自ら果たすべき安全管理措置は必要だと補足されています。海外のサーバーでも、契約で事業者が取り扱わないと定められ適切にアクセス制御されていれば、外国にある第三者への提供にはあたらないとされています。ただしこれは第三者提供にあたるかどうかの話で、その国の制度を把握し安全管理措置を講じる義務は別に残ります。

ここで注意が要ります。この枠組みを、そのまま生成AIに当てはめることはできません。

「取り扱わない」クラウドとは、事業者がデータの中身に関与しない構成のことです。ところが生成AIは、応答を作るために入力内容を処理します。学習に使わないことと、取り扱わないことは別です。学習させない設定にしても、そのAIサービスは個人データを取り扱っていると評価される可能性が高い。つまり委託にあたるかどうか、監督義務を負うかどうかを、あらためて整理する必要があります。

分けて考えるなら、こうなります。

• 保管が中心のクラウド。事業者が中身を取り扱わない構成なら、Q&Aの枠組みで整理できる
• 処理をする生成AI。中身を扱う前提なので、委託や第三者提供の整理が必要になる
• 端末で動くエージェント。上の整理に加えて、端末そのものの管理と、何に接続させるかの設計が加わる

そのうえで言えるのは、人事労務サービスには何年も個人情報を預けているのに、AIには1行も入れさせないという不均衡があるなら、その理由を説明できるようにしておくべきだ、ということです。

説明できるなら構いません。実際、AIには保管型のサービスにはないリスクがあります。入力が出力に再現されること、メモリを介して別の文脈に持ち出されること、外部ツールを呼び出すこと、プロンプトインジェクション。慎重になる理由は十分あります。

ただ、それらを挙げられないまま「AIだから」で止まっているなら、判断ではなく気分です。

法律の話なので添えておきます。自社の契約と使い方が実際にどう評価されるかは、個別の事情で変わります。踏み込んだ判断が必要な場面では、弁護士など専門家に確認してください。

人の手渡しはやめる、エージェントは設計で縛る

ここまでを踏まえた、私たちの結論を2つ書きます。人が渡す場合と、AIが自分で取りに行く場合で、打つ手が違うからです。

結論1 チャット型のAIに、個人情報は渡さない

ChatGPTやClaude.aiのようなチャット型のAIに、個人情報は渡さないほうがいいと考えています。

設定を知っていれば使える、とは書きません。軸3が、知識ではなく運用で決まるからです。

1つ目。プランによっては、メモリの扱いが使う人ひとりひとりの設定に委ねられます。ここはプラン差が大きいので、公式の記載を並べます。

プラン	メモリの組織単位の制御
ChatGPTの個人プラン	なし。各自が設定
ChatGPT Business	あり。ワークスペース所有者がオフにでき、既存のメモリも削除される
Claudeの個人プラン	なし。各自が設定
Claude Team	なし。組織単位の制御がなく、各メンバーが自分で管理する
Claude Enterprise	あり。組織全体で無効化でき、全ユーザーのメモリが完全に削除される

見落としやすいのはClaude Teamです。法人向けの有料プランなのに、メモリについては組織単位の制御がありません。公式ヘルプにも、Teamプランのメンバーは自分のメモリ設定を各自で管理する、と明記されています。「法人契約したから会社で管理できている」とは限らない。

削除の手間もあります。ChatGPTのメモリは削除が複数箇所にまたがり、オフに戻しても残った履歴から再生成されることがある。組織単位で制御できるプランを選び、実際にその設定を入れているなら管理できます。入れていないなら、個人の設定と徹底度に戻ります。

2つ目。1つのログイン情報を複数人で使い回すと、一気に崩れます。同じアカウントで動く以上、誰かが入れた顧客情報が別の人の会話に文脈として出てきます。法人ワークスペースに各自のアカウントを作るのは正規の使い方なので、そちらとは別の話です。

ログイン情報の共有はそもそも規約違反でもあって、Anthropicは週次制限を導入したときに、アカウントの共有と転売を名指しで問題として挙げています。

3つ目。個人プランのままだと、学習利用の設定しだいで保持が長くなります。軸1で見たとおりです。

3つとも、技術というより運用の問題です。一時チャットやIncognitoという逃げ道はありますが、その都度選ぶのは個人なので、これ単体を会社の管理策にはできません。

チャット型を使いたいなら、個人情報を外してから渡す。これは禁止に戻ったのではなく、点検した結果として渡すものを選んだ、ということです。

結論2 エージェントには、触れる範囲を先に決める

こちらは人の心がけでは守れません。設計で縛るしかないからです。

最低限、決めておくのは3つ。

• 何に接続させるか。メール、ファイル共有、顧客管理、会計。つなぐたびに、その先にある個人情報がAIの視野に入ります
• どの範囲を読ませるか。フォルダ単位でもアカウント単位でもいい。「全部見える」状態を既定にしない
• どの権限で動かすか。読み取りだけで足りる作業に、書き込みや送信の権限を渡さない

この3つは出発点です。決めたあと、実際に何が読まれて何が送られているかを見る仕組みと、接続を足したときに見直す運用がないと、設計は形だけになります。

支援に入って実際に詰まるのは、もっと手前です。法人契約を結んでいるつもりで、現場では個人アカウントが混ざっている。管理者が削除の方法を知らない。この2つは、聞けばすぐ分かる割に、聞かないと出てきません。エージェントに業務を任せる前に、ここだけは潰しておいたほうがいい。

もう1つ、入口の話も足しておきます。個人情報を取得するときに特定した利用目的が、いまエージェントにやらせている範囲をカバーしているか。ここは見落とされます。

整理しておくと、通常の取得で基本になるのは、利用目的の特定と、その通知または公表です。本人の同意が必要になるのは、目的外で使うとき、要配慮個人情報を取得するとき、第三者に提供するときなど、場面が限られます。取得のたびに必ず同意が要る、というわけではありません。

そして、扱う情報の種類でも線は変わります。氏名とメールアドレスだけの文面校正と、健康状態や信条を含む相談記録では、扱いを分けるべきです。後者は要配慮個人情報にあたり、原則として取得の時点で本人の同意が要ります(法定の例外はあります)。同じ「個人情報」でひとくくりにしないほうがいい。

最後に。社員に使わせないという選択には副作用があります。一律に禁止すると、見えないところで使われることがある。この構図はシャドーAIに書いたとおりです。

まとめ AIに個人情報を扱わせる前に、この8項目を確認する

AIエージェントが実務を代行するようになって、「個人情報には一切触れさせない」という線の引き方は、現実的でなくなりました。顧客名も、担当者名も、問い合わせの中身も触らせないとなれば、任せられる仕事はほとんど残りません。

はっきり書いておきます。私たちは、AIに個人情報を扱わせることに賛成の立場です。ただし条件があって、設計とルールを徹底すること。この2つを飛ばして便利だからと使い始めるのも、確認を面倒がって一切禁止にするのも、どちらも取りません。

では何を徹底するのか。その中身を確認事項としてまとめました。上から順に見てください。

	確認すること	どこを見るか
触れる範囲	① AIが読める場所に、何が置いてあるか	接続先、共有フォルダ、メール、社内システム
扱う情報	② いまの用途は、取得時に特定した利用目的の範囲に収まるか	自社の利用目的の記載
	③ 要配慮個人情報が混ざっていないか	健康状態、信条、病歴など
渡す先	④ 学習に使わない契約・設定になっているか	プランと設定画面
	⑤ サービス側にどれだけ残るか	各社の保持ポリシー。個人プランと法人プランで違う
残ったあと	⑥ 端末に何が平文で残り、誰が触れるか	ログの保存先と、その端末の管理状況
	⑦ 会話や作業をまたいでコンテキストを持つ機能が有効か、消し方を知っているか	メモリの設定と削除手順
入口	⑧ 取得時の説明が、いまの業務をカバーしているか	利用目的の通知・公表の内容

①を先頭に置いたのが、この記事でいちばん言いたかったところです。AIが読める場所に置いた時点で、扱われる可能性と、その管理責任が生じます。実際に読まれたかどうかは、そのあと確かめる話です。まずここを見てください。

②も早い段階で見ます。①と②が外れていると、④から⑦をどれだけ固めても意味がありません。

答えられない項目が出るのは、最初は当然です。ただし「分からないまま進める」と「分かってから決める」は、まったく別のことです。扱うのが機微な情報なら、その項目が埋まるまで止めたほうがいい。

なお、この8項目は一次スクリーニングです。委託や第三者提供の整理、海外への移転、再委託先、漏えい時の対応まで含めた判断が要る場面では、専門家に確認してください。

冒頭に戻ります。「個人情報はAIに入れないでください」というルールは、いま入力欄しか守っていません。人が打ち込まなくても、AIは読みに行きます。

すぐ動くなら、いま社内でAIが読める場所に何が置いてあるかを洗い出してみてください。禁止しているつもりの会社ほど、そこに驚くはずです。

そして、この棚卸しは一度きりでは足りません。接続を足したとき、権限を変えたとき、新しいツールを入れたとき。そのたびに①へ戻る。増えるのはたいてい、誰も点検していないタイミングです。