BLOG

「顧客からの問い合わせメールを要約させたい」
「稟議書の下書きを作らせたい」
「過去の取引記録から似た事例を探させたい」
生成AIを業務に入れようとすると、こうした場面で必ず同じ壁に当たります。

「入力しようとしている文章に、顧客や従業員の氏名が含まれている」

このとき確認すべきことは、情報セキュリティの話だけではありません。個人情報保護法上、その入力が何に該当するのか。本人の同意が必要なのか。同意を取らずに進めるとしたら、どの規定を根拠にするのか。そして、その根拠を維持するために、導入後どのような作業が続くのか。

本記事では、クラウドLLMに個人データを入力する場合の法的な整理を、条文とガイドラインに沿って順に確認します。あわせて、自社環境でLLMを動かすローカルLLMを選んだ場合に、何が懸念として残るのかを整理します。

💡規制産業向けに、閉域環境で動くローカルLLMの運用基盤を提供しています。金融機関での構築実績を含めた詳細は Athena Platform をご覧ください。

この記事でわかること

• クラウドLLMへの個人データ入力が、なぜ「クラウド例外」としにくいのか
• 「委託」として整理する場合に確認すべき4つの視点
• 国内リージョンを選んでも法28条の検討が不要にならない理由
• 委託先監督（法25条）として実際に発生し続ける作業
• ローカルLLMで発生しない論点と、残る論点の切り分け

クラウドLLMへの入力は、法律上どう扱われるのか

自社が保有する個人データをクラウドLLMに入力すると、そのデータは外部事業者のサービス上で処理されます。これは形式的には、個人情報保護法上の第三者提供に当たります。

第三者提供に該当すれば、原則として事前に本人の同意が必要です。しかし実務上、クラウドサービスの利用にあたって毎回本人同意を取得している企業はほとんどありません。ではどのような理屈で整理しているのか。ここを押さえておかないと、サービスを乗り換えたときに判断ができません。

「第三者提供」を2つに分けて考える

出発点は、「第三者提供」を「第三者」と「提供」の2つの要素に分解することです。

同意が不要になる道筋は2つあります。そもそも「提供」に当たらないと整理するか、提供先が「第三者」に当たらないと整理するか。前者が一般に「クラウド例外」と呼ばれるもので、後者が「委託」です。

クラウド例外が使いにくい理由

クラウド例外の根拠は、個人情報保護委員会のQ&A7-53です。クラウドサービスを提供する事業者において個人データを取り扱わないこととなっている場合には、「提供」に当たらないとされています。

典型例は、事業者が保存領域だけを提供し、データの内容にアクセスせず、分析も編集も行わないケースです。

クラウドLLMはここに当てはまりません。入力された文章をモデルで処理し、その内容に応じた応答を生成することがサービスの本質だからです。編集・分析等の処理を行っていると解さざるを得ないため、「個人データを取り扱わないこととなっている場合」には該当しないと考えられます。

一般的なストレージサービスと同じ整理は使えない、ということです。

「委託」として扱う

そこで実務上使われるのが、法27条5項1号です。

自社が定めた利用目的の達成に必要な範囲で個人データの取扱いを委託する場合、委託先は同項の「第三者」に該当しないものとして扱われます。したがって、法27条の第三者提供に関する本人同意は不要になります。

論理構造としては、「提供」ではあるが「第三者」への提供ではないから同意が要らない、という整理です。クラウド例外とは根拠が違うため、確認すべき事項も変わります。

たとえば、顧客への案内文を作成するという自社業務のために顧客情報をLLMに入力し、文面の生成を任せる。これは委託と判断しうる形です。

ただし、外部に渡せば何でも委託になるわけではありません。委託先が個人データを取り扱えるのは委託された業務の範囲内に限られ、受け取ったデータを自社の目的で利用する場合は、委託と判断することが難しくなります。

委託と判断できるかを確認する4つの視点

判断の軸は一つです。サービス事業者が、委託元の指示・目的の範囲を超えて自社目的でデータを利用しないこと。

これを確認するために見るべき点が4つあります。

データの扱いは大きく3類型に分かれる

クラウドLLMの入力データの取扱いは、サービスやモデルによって差があります。整理すると次の3類型です。

自社が使うサービスがどの類型かは、利用規約・DPA・サブプロセッサ一覧で確認できます。契約プランや設定によって類型が変わることもあるため、製品名ではなく実際の契約条件で判断してください。

1. モデルの学習に使われるか

入力した個人データが応答の生成だけに使われるのか、モデルの学習やサービス改善にも使われるのか。

委託元が定めた利用目的とは関係のない学習・改善に使われる場合、委託された業務の範囲内という整理は成り立ちにくくなります。ここは最も明確な線引きです。

2. どのように保存されるか

保存されるかどうかだけを見ても判断できません。見るべきは、保存の目的・期間・保存先・アクセス可能な者・削除方法です。

応答生成のために一時的に保持されるのと、不正利用の監視のために一定期間保存されるのとでは、性質が異なります。保存の目的と範囲が契約やサービス仕様の上で明確になっているかを確認します。

3. 人が内容を見る可能性があるか

不正利用の監視や障害対応のために、サービス事業者の担当者が入力内容を確認する可能性があるサービスがあります。

ここで誤解しやすい点があります。人による閲覧の可能性があること自体をもって、委託構成が直ちに否定されるわけではありません。

不正利用監視を目的とした限定的な保存とアクセスは、サービスの安全性確保や利用規約の執行のために行われる、サービス提供に付随した標準的な処理と評価できます。監視目的の閲覧可能性があるだけで委託スキームを採れないという見解は、個人情報保護委員会を含めて示されていません。

確認すべきは、閲覧がどのような場合に行われるのか、目的と範囲が限定されているのか、閲覧できる担当者が絞られているのか、という点です。

もっとも、人的な閲覧可能性が残ること自体は別の意味でリスク要素になります。後述する守秘義務の観点と、委託構成を保守的に評価する顧客への説明の観点です。機微性の高いデータを扱う場合には、監視のオプトアウトを取得しておくことが望ましい。必須の要件ではなく、より堅牢な整理のための推奨措置と位置づけるのが適切です。

4. ほかの事業者に共有されるか

クラウドLLMには、サービスの運営会社、モデルの提供会社、再委託先といった複数の事業者が関わる場合があります。

どの事業者にデータが渡り、それぞれが何のために取り扱うのか。共有先でも委託された業務の範囲内で扱われ、利用・保存・アクセスの条件が定められているか。共有先が独自の目的で利用できる場合、委託と判断することが難しくなります。

委託と判断したあとに確認すること

法27条5項1号による整理は、あくまで法27条の第三者提供についての整理です。これで終わりではありません。

提供先が「外国にある第三者」に当たるか

提供先が外国にある第三者に当たる場合、法28条の検討が必要になります。原則として、外国への提供を認める旨の本人同意が求められます。

ここで実務上、最も誤解が多い点があります。

法28条の該当性は、データの処理・保存場所（リージョン）ではなく、提供先の事業者が「外国にある」か否かで、法人単位で判断されます。（Q&A12-3・12-4）

個人情報保護委員会は、外国の事業者が運営するクラウドについて、サーバが国内にある場合でも外国にある第三者への提供に該当し得るとしています。逆に、外国法人であっても日本国内で個人データを取り扱い、国内で個人情報データベース等を事業の用に供している場合、つまり国内の個人情報取扱事業者に該当する場合には、該当しないとしています。

したがって「国内リージョンを選んだから法28条は関係ない」という理屈は成り立ちません。正確には、提供先すなわち契約主体である事業者が国内法人（または国内の個人情報取扱事業者）であれば、法28条は適用されないとなります。

確認すべきは、リージョンの設定画面ではなく契約書です。自社が契約している法人がどこの法人か。契約先とは別のモデル提供会社や再委託先が個人データを取り扱う場合は、それらの事業者についても確認が必要です。

なお、法28条が適用される場合でも、提供先において基準適合体制が整備されていると評価できれば本人同意は不要と整理できます。DPA等の契約締結と、「外国にある第三者への提供編」ガイドラインが定める措置の担保が要件です（施行規則16条1号）。この方法を採る場合は、提供後も措置の実施状況を定期的に確認する必要があります。

リージョンの選択は、法28条ではなく安全管理措置との関係で意味を持ちます。具体的には「外的環境の把握」です（Q&A10-25、GL通則編）。外国において個人データを取り扱う場合、当該外国の個人情報保護制度等を把握したうえで安全管理措置を講じ、さらに保有個人データの安全管理措置として当該外国の名称等を本人の知り得る状態に置く必要が生じます。

処理を国内に閉じれば、この負担が発生しません。制度調査も、外国名の公表も不要になります。外国政府によるアクセスへの懸念が低減される点も、実務上の判断材料になります。

顧客との契約と、業界固有の要件

個人情報保護法上は委託と判断できても、顧客との契約に違反する可能性は別に残ります。

秘密保持契約や業務委託契約で、外部のクラウドサービスへの情報送信が明示的に禁止されている場合、その情報の入力はできません。外部事業者へ情報を渡す際に事前通知や承諾を求める条項が置かれていることもあります。個人情報保護法上の整理と、契約上の義務は別問題です。

利用するサービス側の利用規約やDPAに守秘義務条項が置かれているかも、あわせて確認します。

業界によっては追加の要件が生じます。金融分野では、個人情報の取扱いと安全管理について金融分野ガイドラインと実務指針が定められており、委託先選定基準の整備、委託契約への安全管理措置の明記、委託先における取扱状況を定期的または随時に確認することなどが求められます。

自社が金融機関でない場合も無関係ではありません。金融機関から業務を受託していれば、顧客側の外部委託管理態勢（監督指針・FISC準拠）に基づいて、監査権、報告徴収、再委託管理、データ所在の特定といった要求が契約に盛り込まれることが多くあります。

委託先監督として実際に何をするのか

委託と判断できる場合、法25条により委託先に対する必要かつ適切な監督が求められます。

監督で求められる3要素

GL通則編3-4-4は、次の3つを挙げています。

1. 適切な委託先の選定
2. 委託契約の締結
3. 委託先における個人データ取扱状況の把握

導入前の確認だけでは足りません。3つ目の「把握」は一時点で完結するものではないためです。

立入監査は必須ではない

大規模なクラウド事業者の施設に立ち入って個社監査を行うことは、現実的ではありません。

この点についてQ&A5-9は、取扱状況の把握について、必ずしも立入検査や実地監査を行わなければならないものではなく、委託する個人データの内容・規模に応じた合理的な方法で足りるとしています。書面による確認等も含まれます。

したがって、ハイパースケーラーのような委託先については、DPA等のデータ保護に関する契約を締結し、セキュリティ文書・監査レポート・第三者認証を確認し、その結果を記録して定期的に見直す。この組み合わせで監督義務を履行したと整理することが、実務上一般的です。

継続的に発生する作業

なお、「定期確認義務」という独立した法定義務があるわけではありません。ただし取扱状況の把握は継続的に行うべきものであり、レビューをルール化・記録化しておくことが求められます。目安としては年1回程度、加えて規約や仕様に重要な変更があったときです。

具体的には、次の作業が続きます。

1. 利用規約・サービス仕様の変更確認（入力データの利用目的、保存期間、人的閲覧の条件、処理地域、再委託先）
2. DPA・セキュリティ文書・監査レポート・第三者認証の更新確認
3. サブプロセッサの追加・変更の追跡
4. 確認結果の記録化と、社内での利用可否判断の更新
5. 変更が判明した場合の、設定・社内利用ルールの見直し

クラウドLLMで個人データを適切に扱うことは可能です。ただしそれは、この5項目を担当者と期限を決めて回し続けることによって成り立つ適法性です。 確認する時期と担当者をあらかじめ定め、記録を残す体制が必要になります。

ローカルLLMという選択肢

ローカルLLMは、自社が管理するサーバーや端末でLLMを動かす仕組みです。構成によっては、入力した個人データを外部のクラウド事業者へ送信せず、自社環境内で処理できます。

ここまで見てきた確認と管理の負担は、この構成の違いによって大きく変わります。

外部提供の規定は外れ、事業者としての義務は残る

外部事業者が個人データを取り扱わない構成であれば、外部への提供を前提とする規定は原則として適用されません。一方で、個人データを扱う主体としての義務は当然に残ります。

切り分けると次のようになります。

あわせて、入力データが外部で保存されるか、学習に使われるか、人が閲覧するか、他事業者へ共有されるかを継続的に確認する作業も生じません。外部サービスの規約変更や仕様変更によって、いったん行った判断が覆る影響も受けにくくなります。

前節の5項目を長期にわたって負い続けることが現実的でない場合、この差は実務上大きく効いてきます。

ローカルLLMを選ぶ場合に設計すべきこと

ローカルLLMは、導入すれば安全になる仕組みではありません。設計段階で決めておくべき点がいくつかあります。

個人データへのアクセス制限と利用者管理。 自社環境内での処理であっても、誰がどのデータにアクセスできるかの制御は必要です。

利用目的の範囲の管理。 事前に特定した利用目的の範囲内で使うという原則は変わりません。生成AIは用途を広げやすいため、目的の逸脱が起きやすい領域です。

顧客との契約の確認。 自社環境内で処理する場合でも、契約で認められていない目的に情報を使うことはできません。

保守を外部に委ねる場合の設計

最も見落とされやすいのが保守運用です。

ローカルLLMの保守や運用を外部事業者に任せ、その事業者が個人データにアクセスできる構成であれば、個人データの取扱いを外部に委託していることになります。この場合、委託先の選定、契約の締結、取扱状況の把握が改めて必要です。

ここは運用設計で対応できます。

当社が地方銀行向けに構築したローカルLLM基盤では、行内ネットワークの閉域性を維持する必要があったため、遠隔接続による保守ではなく、定期的な訪問による運用保守体制を採っています（構築事例）。閉域を前提に運用体制まで含めて設計すれば、保守を外部に委ねる場合にも対応できます。

扱うデータの機微性、業務の性質、保守運用の体制を踏まえて構成を選ぶ。ここまでが設計の範囲です。

まとめ

クラウドLLMに個人データを入力する場合、クラウド例外は使いにくく、法27条5項1号の委託と判断できるかを確認することになります。確認すべきは、モデル学習への利用、保存の目的と範囲、人的閲覧の条件、他事業者への共有です。人による閲覧の可能性があること自体で委託構成が否定されるわけではない点は、正確に押さえておく必要があります。

そのうえで、提供先が外国にある第三者に当たるか（法28条）を確認します。この判断はリージョンではなく契約主体の法人で決まります。国内処理を選ぶ意義は法28条の回避ではなく、「外的環境の把握」に伴う負担が生じない点にあります。

委託として利用を続ける場合は、法25条の監督として、規約・仕様の変更確認、第三者認証の更新確認、サブプロセッサの追跡、記録化、判断の更新という作業が継続します。クラウドLLMで個人データを適切に扱うことはできますが、それは管理を回し続けることで維持される状態です。

ローカルLLMでは、外部事業者が個人データを取り扱わない構成を選ぶことで、第三者提供、越境移転、外部クラウド事業者に対する委託先監督の規定が原則として適用されず、確認すべき項目そのものを減らせます。一方、安全管理措置や利用目的の管理、保守を外部に委ねる場合の委託先監督は残ります。

扱うデータの機微性が高く、確認と記録の作業を長期にわたって負い続けることが現実的でない場合、ローカルLLMの相対的な利点は大きくなります。 残る部分についても、閉域を前提とした運用体制まで含めて設計すれば対応が可能です。

自社にとってどの構成が適切かは、取り扱うデータの内容、業務の性質、契約条件、運用体制から判断してください。

本記事は一般的な情報提供を目的としたもので、個別の事案に対する法的助言ではありません。記載内容は2026年7月時点の法令、ガイドラインおよび個人情報保護委員会の公表資料に基づいています。個別の判断については弁護士にご相談ください。