企業法務、プライバシー法務、SaaS契約で問題になるSub-processor条項を、定義、承認方式、変更通知、同等義務、責任、越境移転、AI利用まで一体で整理します。
再委託を単に許すか禁じるかではなく、処理チェーンを見える化する契約設計が出発点です。
再委託を単に許すか禁じるかではなく、処理チェーンを見える化する契約設計が出発点です。
Sub-processor条項の書き方で最も重要なのは、再委託の可否だけを短く置かず、誰が、どこで、何のために個人データ等を処理するのかを契約上追跡できる形にすることです。クラウド、ホスティング、ログ管理、サポート、決済、メール配信、監視、バックアップ、AI解析、外部開発会社は、現代のデジタルサービスで実務上登場しやすい相手方です。
次の強調表示は、この条項が何を実現するものかを示しています。委託元の説明責任とベンダー側の運用可能性を両立させることが重要であり、読むべきポイントは、承認、通知、異議、責任、監査が一体で機能しているかです。
Sub-processor条項は、ベンダーを過度に縛るためではなく、データ処理チェーンを見える化し、委託元やControllerが説明責任を果たせるだけの情報、統制、救済手段を契約上確保するために置きます。
次の一覧は、Sub-processor条項に含める主要要素を整理したものです。抜けがあると承認だけ、通知だけ、監査だけの片手落ちになりやすいため、各行をチェックリストとして読み、契約案に反映されているかを確認することが重要です。
| 要素 | 条項で決める内容 | 読み取るポイント |
|---|---|---|
| 定義 | 再委託先、単なるインフラ利用、独立した第三者提供、共同利用、グループ内処理を切り分けます。 | 個人データへのアクセス可能性と処理目的が基準になります。 |
| 承認 | 個別承認、一般承認、高リスク処理だけ個別承認のいずれかを定めます。 | サービス運用と顧客審査のバランスを確認します。 |
| 一覧管理 | 名称、所在地、処理内容、対象データ、移転国、認証、更新日を管理します。 | 監査やDPIAで説明できる粒度が必要です。 |
| 通知と異議 | 追加・交代時の通知期間、通知手段、異議理由、協議手順を置きます。 | 顧客が実際に検討できる仕組みかを見ます。 |
| 同等義務 | DPAや主契約と実質的に同等以上の義務をSub-processorへ課します。 | 処理目的、秘密保持、安全管理、削除まで届くかが焦点です。 |
| 責任と監査 | Processorの責任、監査報告、認証、デューデリジェンス資料の提供を定めます。 | 事故時に責任の空白が生じないかを確認します。 |
| 越境移転と終了 | SCC、TIA、TRA、日本法第28条対応、削除・返却・緊急時対応を接続します。 | 国境をまたぐ処理と契約終了時の残データを見ます。 |
Sub-processor、再委託先、下請業者、関連会社、クラウド事業者を同じ言葉で処理しないことが重要です。
Sub-processorとは、広くいえば、個人データ等の処理を受託したProcessorまたは委託先が、その処理の全部または一部をさらに第三者に行わせる場合の相手方です。GDPRでは、Processorが関与させる another processor という表現が用いられ、日本法では再委託先、再受託者、復受託者と呼ばれることが多いです。
次の比較一覧は、Sub-processor条項で対象に含めるべき相手方と、機械的に含めると過剰になりやすい相手方を整理しています。定義が曖昧だと監督対象が広がり過ぎたり、逆に重要な処理者が抜けたりするため、どの列に当たるかを実態で読み分けることが重要です。
クラウドIaaS、CDN、ログ解析、メール配信、決済、カスタマーサポート、障害監視、バックアップ、外部開発会社など、顧客データやログ、認証情報へアクセスする者です。
個人データへアクセスせず、一般的な事務、施設、通信、配送などの補助サービスだけを提供する者は、Sub-processor一覧の対象外とすることがあります。
同一グループでも別法人が個人データを処理する場合は管理対象になり得ます。サポートアクセスやバックアップ復元により実質的アクセス可能性がある場合も確認が必要です。
次の表は、Sub-processorが問題になりやすい典型場面を示しています。重要なのは、契約上の名称ではなく、個人データ、顧客データ、ログ、サポートチケット、通信内容、認証情報にどのように触れるかを読み取ることです。
| 場面 | 典型的な相手方 | 条項上の注意点 |
|---|---|---|
| SaaS・クラウド | IaaS、CDN、メール配信、決済、監視、バックアップ、サポート | 標準的なSub-processorを一般承認で管理しつつ、変更通知と異議機会を置きます。 |
| BPO | 入力作業、本人確認、コールセンター、翻訳、帳票出力 | 処理対象データ、処理場所、再々委託の有無を一覧化します。 |
| システム開発 | 海外開発拠点、外部開発会社、テスト会社、保守会社 | 本番データ、認証情報、開発環境へのアクセス制限を確認します。 |
| AI・データ分析 | アノテーション、モデル評価、GPUクラウド、データクレンジング | 学習利用、ログ保存、人的レビュー、削除可能性を別途明確にします。 |
| グローバル企業 | 海外グループ会社、共通IT基盤、HRシステム、CRM | 関連会社を一律除外せず、処理チェーンと越境アクセス国を把握します。 |
GDPR、EU SCC、日本の個人情報保護法、UK GDPR、CCPA/CPRAを同じ条項に接続します。
Sub-processor条項が必要になる理由は、法令上の承認・監督義務、委託先管理の説明責任、越境移転の統制、情報漏えい時の責任分界、契約交渉コストの削減にあります。単なる再委託禁止条項では、これらの要求を満たしにくくなります。
次の比較表は、主要な法規制と一次情報がSub-processor条項に求める内容を整理したものです。各制度の列を横に見比べることで、承認、通知、同等義務、責任、越境移転が共通の設計軸になっていることを読み取れます。
| 制度・資料 | 条項に反映する内容 | 実務上の読み方 |
|---|---|---|
| GDPR第28条 | Processorが別のProcessorを関与させるには、Controllerの事前の個別または一般の書面承認が求められます。一般承認では追加・交代予定の通知と異議機会が必要です。 | 承認、通知、異議、同等義務、Processorの責任を最低限入れます。 |
| EU SCC 2021/914 | 第三国移転がある場合、Module Two と Module Three でSub-processor承認、事前通知、Annex III更新、同水準保護が問題になります。 | DPAだけでなく国際移転SCCとの整合性を確認します。 |
| EU SCC 2021/915 | GDPR第28条7項に基づくController-Processor間の標準契約条項ですが、国際移転SCCとしては使えません。 | DPA条項と移転SCCを分け、Sub-processor条項で接続します。 |
| EDPB Opinion 22/2024 | ControllerがProcessor、Sub-processor、さらに下層の処理者情報を把握し、必要情報を利用可能にしておく方向性を示しています。 | 名称、住所、連絡先、処理内容、移転国、保証内容を追跡できる構造が望まれます。 |
| UK GDPR・ICO | 事前承認、変更通知、異議機会、同等義務、Processorの責任、国外移転時のリスク評価協力が中心です。 | 英国データではTRAや data protection test への協力義務も検討します。 |
| 日本の個人情報保護法 | 委託先の選定、委託契約、取扱状況の把握、再委託先の事前報告または承認、監査等による確認が重要です。 | 再委託先、再委託業務、取扱方法、外国取扱いを契約で確認できるようにします。 |
| CCPA/CPRA | 販売・共有禁止、特定されたbusiness purpose、目的外利用禁止、同水準保護、合理的な確認権、義務不履行時通知、是正権が問題になります。 | 米国消費者データを扱うSaaS、広告、EC、分析、ID連携では追加条項を検討します。 |
次の重要ポイントは、国外処理と法改正動向の扱いを示しています。データがどの国に保存され、どの国からアクセスされるかは、承認方式と同じくらい重要であり、契約レビューでは移転根拠とリスク評価協力を読み取ります。
全面禁止ではなく、顧客の透明性とベンダーの運用可能性を調整する発想が実務的です。
大企業の委託契約では、受託者は委託者の事前書面承諾なく再委託できない、という一文だけが置かれることがあります。しかし、クラウド、SaaS、データ処理では、この一文だけでは実態に合わないことが多いです。
次の比較一覧は、顧客側とベンダー側が何を気にしているかを並べたものです。双方の関心を先に整理すると、条項交渉でどこまで透明性を出し、どこから標準運用を認めるかを読み取りやすくなります。
誰が、どこで、何のために自社データを処理するのかを知り、高リスクな国、事業者、処理へ異議を述べられることを重視します。
標準的なSub-processorを顧客ごとに個別交渉せず利用し、契約全文開示や無制限監査を避ける必要があります。
一覧公開、通知購読、第三者監査報告、合理的な責任制限を使い、透明性と事業運営を両立します。
次の表は、リスク階層ごとの管理強度を示しています。すべてのSub-processorを同じ強度で審査すると運用が重くなるため、処理データ、権限、本人への影響、海外アクセスを見て強度を読み分けることが重要です。
| 階層 | 対象例 | 推奨される管理 |
|---|---|---|
| 高リスク | 要配慮個人情報、金融・医療・子どもデータ、大量データ、本番DB、認証情報、管理者権限、海外アクセス、AI学習 | 個別承認、詳細なデューデリジェンス、監査権、厳格な通知を検討します。 |
| 中リスク | 標準的なクラウド基盤、メール配信、ログ管理、サポート、監視 | 一般承認、一覧公開、事前通知、異議申立て、SOC 2やISO 27001等の資料で管理します。 |
| 低リスク | 個人データにアクセスしないインフラ、匿名化後データのみ扱う業者、物理施設の一部サービス | 秘密保持やセキュリティで管理し、一覧対象外にすることもあります。 |
次の注意要素は、リスク判断で見落としやすい観点をまとめています。契約上アクセスしないと書かれていても、実際の管理者権限や障害対応でアクセス可能性が生じる場合があるため、ここから実態確認の優先順位を読み取ります。
障害対応や問い合わせ対応で本番データを閲覧できる場合、低リスクとは言い切れません。
復元作業時にログや複製データへ触れる場合、削除・返却条項との接続が必要です。
保存場所が国内でも、保守や監視のアクセス国が国外なら越境移転の検討が必要になります。
定義から終了時削除まで、条項の部品を抜けなく並べます。
Sub-processor条項は、定義、承認、一覧、通知、異議、フローダウン、責任、監査、越境移転、インシデント、終了時措置を分解して設計します。どれか一つを厚くしても、他が薄いと実務上の統制が途切れます。
次の表は、11項目の目的と書き方の要点を整理しています。契約案をレビューするときは、左列の項目が存在するかだけでなく、中央列の実質が条文に入っているかを読み取ることが重要です。
| 項目 | 書き方の要点 | 不足した場合のリスク |
|---|---|---|
| 定義 | ProviderのためにCustomerの個人データを処理する第三者を対象にし、一般的な事務・施設サービスは必要に応じて除外します。 | 対象が広がり過ぎるか、重要な処理者が抜けます。 |
| 事前承認 | 個別承認、一般承認、ハイブリッド方式のいずれかを明確にします。 | 使える再委託先と審査手順が不明になります。 |
| 一覧 | 名称、所在地、処理概要、データ種類、処理場所、アクセス国、移転根拠、認証、更新日を管理します。 | 委託先管理や規制当局対応で説明できません。 |
| 変更通知 | 30日前通知を基本に、メール、管理画面、通知購読など実際に届く方法を定めます。 | 顧客が変更を知らないまま処理が始まります。 |
| 異議申立て | 15日以内などの期限、合理的な理由、代替措置、部分解除を定めます。 | 拒否権が無制限になったり、救済が解除だけになったりします。 |
| 同等義務 | 処理目的、指示遵守、秘密保持、安全管理、再々委託制限、請求対応、通知、監査、削除を下流へ課します。 | DPAの義務がSub-processorで途切れます。 |
| 責任 | ProcessorがSub-processorの作為・不作為について自己と同様に責任を負う旨を置きます。 | 事故時に責任分界で争いが生じます。 |
| 監査・情報提供 | 第三者監査報告、認証、セキュリティ資料、質問票、デューデリジェンス概要を提供対象にします。 | 顧客側の委託先管理資料が不足します。 |
| 越境移転 | SCC、補完的措置、TIA、TRA、日本法第28条対応、アクセス国の情報提供を定めます。 | 保存国とアクセス国の差を見落とします。 |
| インシデント | Sub-processorや下位委託先で起きた漏えい、不正アクセス、可用性喪失も通知対象にします。 | 事故発生場所を理由に通知が遅れます。 |
| 終了時措置 | 返却、削除、匿名化、バックアップ削除サイクル、復元時の再削除を定めます。 | 契約終了後も複製やログが残ります。 |
次の一覧は、条項例に入れるべき文言の方向性を示しています。文例は契約本文にそのまま使うものではなく、どの義務をどの相手方へ届けるかを読み取るための整理です。
Sub-processorには、関連会社、クラウドインフラ提供者、サポート事業者、データ処理事業者など、個人データへのアクセスまたは処理を行う第三者を含めます。
対象範囲追加または交代を行う場合は、少なくとも30日前までに、名称、所在地、処理内容、処理開始予定日、越境移転の有無、異議申立て方法を通知します。
30日前Sub-processorが義務を履行しない場合でも、ProcessorはCustomerに対する契約上およびDPA上の義務を免れない形にします。
責任分界Sub-processorが保持する複製、バックアップ、キャッシュ、ログも、合理的な期間内に削除または不可逆的に匿名化されるよう確保します。
削除・返却一般承認を採用する場合でも、通知と異議の実効性を確保します。
承認方式は、個別承認、一般承認、ハイブリッド方式に分かれます。金融、医療、公共、重要インフラ、訴訟資料、従業員情報などでは個別承認が合いやすく、標準SaaSでは一般承認と通知・異議の組み合わせが現実的です。
次の判断の流れは、どの承認方式を選ぶかを整理するものです。処理データの感度、事業上の変更頻度、顧客審査の重さによって分岐するため、上から順に確認して自社契約に合う方式を読み取ります。
要配慮データ、大量データ、認証情報、本番DB、AI学習、海外アクセスを確認します。
本人への影響、規制業種、監査要求、社内ポリシーを合わせて見ます。
詳細な情報提供、監査資料、明示承認を置きます。
一覧公開、30日前通知、15日以内の異議、代替措置を組み合わせます。
次の時系列は、一般承認方式で変更通知を受けた後の実務対応を表しています。期限を条項に書く理由は、社内レビューの担当者と判断期限を明確にし、異議や代替措置の検討を遅らせないためです。
名称、所在地、処理内容、変更理由、処理開始予定日、越境移転の有無、異議申立て方法を確認します。
安全管理措置、処理国の公的アクセスリスク、過去の重大事故、規制上の義務との抵触、処理範囲の逸脱を見ます。
代替Sub-processor、追加的安全管理措置、処理対象データの限定、暗号化、アクセス制限、地域限定処理を検討します。
当該Sub-processorの使用に依存するサービス部分だけを解除できる設計にすると、全面解除より実務的です。
顧客側、SaaS提供者、日本法中心の業務委託契約で、重さと運用を変えます。
推奨ドラフトは、顧客・Controller・委託元に有利な条項、SaaS・クラウド事業者に適した標準条項、日本法中心の業務委託契約向け条項で異なります。共通するのは、承認、通知、異議、同等義務、責任、監査資料を外さないことです。
次の比較表は、立場別の条項の強さを整理しています。どの立場でも同じテンプレートを使うのではなく、データの感度、取引上の力関係、運用可能性を踏まえて、どの列に寄せるかを読み取ります。
| 立場 | 推奨される書き方 | 注意点 |
|---|---|---|
| 顧客・Controller・委託元 | 既存一覧を別紙で承認し、新規追加は30日前通知、15日以内の異議、同等義務、契約要約または関連部分の提供、監査資料を求めます。 | 標準SaaSに過度な個別承認を求めると運用不能になりやすいです。 |
| SaaS・クラウド提供者 | Sub-processor一覧を最新に維持し、顧客がアクセス可能な方法で提供し、変更時は通知購読や管理画面で知らせます。 | 単にウェブページへ掲載するだけでは、顧客が実際に知る方法として弱い場合があります。 |
| 日本法中心の業務委託 | 再委託先の名称、所在地、業務内容、取扱データ、取扱方法、安全管理、再々委託、外国取扱いを報告し、承認を得る形にします。 | 海外DPAやSaaS契約と接続する場合は、再委託先（Sub-processor）と併記すると明確です。 |
次の文例群は、条項の方向性を立場別に示すものです。読者にとって重要なのは、文言の長さではなく、承認、通知、異議、同等義務、責任がどの程度強く置かれているかを読み取ることです。
Processorは、Controllerの事前書面承認を得ることなく、本個人データの処理をSub-processorに委託しません。ただし、別紙記載の相手方は承認済みとして扱います。
Customerは、ProviderがSub-processor一覧に記載された相手方を使用することを一般的に承認します。Providerは一覧を最新に維持し、変更時に合理的な方法で通知します。
受託者は、個人データの取扱いを再委託する場合、再委託先、業務内容、取扱方法、安全管理、外国取扱いの有無を報告し、委託者の承認を得ます。
関連会社、再々委託、契約写し、Trust Center、AI利用を別枠で確認します。
条項作成時には、事前承認と通知だけでなく、関連会社の扱い、再々委託以降の把握、Sub-processor契約の写し、公開ページの有効性、AI・機械学習用途を確認します。これらは事故時や規制当局対応で問題になりやすい論点です。
次の一覧は、実務上の論点と落としどころを整理しています。各項目は契約交渉で揉めやすいため、どこまで情報を出し、どこから要約や監査報告で代替するかを読み取ります。
グループ会社を一律に除外すると、海外サポート会社、共有IT基盤、グループDPO機能が管理対象から漏れます。個人データを処理するなら対象に含めます。
全下層の名称開示が難しい場合でも、処理カテゴリ、地域、セキュリティ管理、再委託管理方針の概要を確認します。
価格、技術構成、営業秘密、他顧客情報を含むため、表明保証、要約、関連部分のマスキング開示、限定閲覧を段階的に検討します。
Trust Centerやウェブページを使う場合は、一覧の最新性、変更履歴、通知購読、異議期限、処理内容、所在地が明確かを見ます。
モデル改善、プロンプト保存、アノテーション、人的レビュー、海外GPUクラウド、ログ保存、削除可能性をSub-processor条項とは別に明確化します。
保存場所が限定されても、サポートや監視のアクセス国が広い場合があります。保存地域とアクセス地域を分けて確認します。
次の表は、契約写しを求める場合の段階を示しています。全文開示だけを求めると交渉が止まりやすいため、必要性と秘密保持のバランスを見ながら、どの段階で十分かを読み取ります。
| 段階 | 求める資料 | 使いどころ |
|---|---|---|
| 1 | 同等義務があることの表明保証 | 標準SaaSや低リスク処理での初期確認に使います。 |
| 2 | データ保護条項の要約または抜粋 | 社内審査やDPIAで義務内容を確認したい場合に使います。 |
| 3 | 秘密情報をマスキングした関連部分 | 規制業種、高リスクデータ、重要Sub-processorで検討します。 |
| 4 | 重大インシデント時や当局対応時の限定開示 | 平時は要約で足りるが、有事には詳細確認が必要な場合に使います。 |
| 5 | 外部監査人や専門家による閲覧 | 営業秘密を守りつつ、客観的な確認が必要な場合に使います。 |
個別承認、異議理由、通知期間、責任上限、監査権、処理国を落としどころで調整します。
Sub-processor条項の交渉では、顧客側が統制を求め、ベンダー側が標準運用を求めます。どちらか一方に振り切るより、高リスク処理だけ強くし、標準処理は一般承認と監査資料で管理する設計が実務的です。
次の表は、交渉でよく揉める論点と落としどころを整理しています。左右の違いを見比べることで、どの項目を強くし、どの項目を標準化するかを読み取れます。
| 論点 | 顧客側の要望 | ベンダー側の要望 | 落としどころ |
|---|---|---|---|
| 承認方式 | 個別承認を求めます。 | 一般承認を求めます。 | 既存は包括承認、新規は通知・異議制、高リスク処理だけ個別承認にします。 |
| 異議理由 | 自社ポリシー上の理由も含めたいと考えます。 | 合理的なデータ保護上の理由に限定したいと考えます。 | 合理的なデータ保護上、情報セキュリティ上、法令遵守上または規制上の理由と書きます。 |
| 通知期間 | 45日から60日前を求めます。 | 10日から15日前または合理的期間を求めます。 | 標準は30日前、高リスクは45日から60日、低リスクは15日、緊急時は事後速やかにします。 |
| 責任上限 | Sub-processor起因の事故は上限除外を求めます。 | 主契約の責任上限内に収めたいと考えます。 | 通常違反は主契約上限、個人データ侵害は12か月から24か月分の利用料または固定上限、故意・重過失や目的外利用は別枠にします。 |
| 監査権 | 直接監査を求めます。 | マルチテナント環境や営業秘密を理由に限定したいと考えます。 | 第三者監査報告、質問票、説明会、重大時追加資料、規制当局要請時の限定的オンサイト監査を段階化します。 |
| 国・地域 | 国内処理または特定地域内処理を求めます。 | グローバルサポートのため複数国アクセスを求めます。 | 保存場所とサポートアクセス地域を分け、アクセス制御、ログ、最小権限、暗号化、秘密保持を条件にします。 |
次の重要ポイントは、責任上限と監査権を分けて考える理由を示しています。損害賠償の上限だけでは説明責任は満たせず、監査資料だけでは事故時の救済が足りないため、両方を連動させて読み取ります。
契約本文、Sub-processor一覧、社内運用を分けて確認します。
Sub-processor条項は、契約に入れただけでは足りません。レビュー時には、契約本文の条項、Sub-processor一覧、社内の通知・棚卸し運用を分けて確認する必要があります。
次の表は、契約レビュー時に確認する項目を整理したものです。左列を順に見て、契約案やDPAのどこに根拠があるかを確認し、未記載の項目を交渉対象として読み取ります。
| 確認項目 | 見るべき内容 |
|---|---|
| 定義 | Sub-processorの定義が明確で、個人データ処理に実質的に関与する第三者を対象にしています。 |
| 一覧 | 既存一覧が提供され、名称、所在地、処理内容、対象データ、処理場所、アクセス国が分かります。 |
| 承認と通知 | 個別承認か一般承認か、変更通知の期限・方法・記載事項、異議申立て期限と理由が明確です。 |
| 下流管理 | 同等義務、再々委託以降の管理、Processorの責任、監査・報告資料の提供が入っています。 |
| 有事対応 | インシデント通知、契約終了時の削除・返却、バックアップ、越境移転、SCC、TIA、TRA、日本法第28条対応が接続されています。 |
| AI・二次利用 | 学習利用、モデル改善、ログ解析、サポートアクセス、目的外利用制限が明確です。 |
次の表は、Sub-processor一覧そのものを確認するための項目です。一覧は単なる名称リストではなく、処理の実態と変更履歴を説明する資料です。そのため、列ごとの意味を読み取ることが重要です。
| 項目 | 確認内容 |
|---|---|
| 名称 | 法人名、ブランド名、関連会社名が分かります。 |
| 所在地 | 登記所在地、処理場所、サポートアクセス国が分かります。 |
| 処理内容 | ホスティング、メール配信、決済、監視、サポート等の役割が分かります。 |
| データ種類 | 顧客データ、メタデータ、ログ、認証情報、決済情報等が分かります。 |
| データ主体 | 顧客、従業員、ユーザー、取引先、患者、子ども等が分かります。 |
| 移転根拠 | SCC、十分性認定、同意、CBPR等が分かります。 |
| セキュリティ | ISO 27001、SOC 2、暗号化、アクセス制御等が分かります。 |
| 再々委託 | さらに下層の委託があるか、管理方針が分かります。 |
| 変更履歴 | 追加、削除、交代日が追えます。 |
| 異議手続 | 通知方法、期限、連絡先が分かります。 |
次の運用一覧は、契約締結後に社内で整備する項目を示しています。条項の実効性は運用で決まるため、担当者、通知先、棚卸し頻度、台帳連携を読み取り、契約管理へつなげることが重要です。
Sub-processor一覧、セキュリティ資料、越境移転情報を取得します。
審査契約管理システムに通知先メールアドレスを登録し、Trust Centerの変更通知を購読します。
通知情報セキュリティ、法務、プライバシー担当、事業部が変更通知を確認できる手順を作ります。
体制主要ベンダーのSub-processor一覧を年1回以上確認し、DPIA、委託先管理台帳、越境移転台帳と連動させます。
棚卸し再委託禁止だけ、一覧なし、関連会社除外、越境移転の分離、AI二次利用の見落としを避けます。
Sub-processor条項の失敗は、条文が短すぎる場合だけでなく、条文と実態がずれている場合にも起こります。クラウドやAIサービスでは、契約上の表現よりも実際のデータ処理チェーンが問題になります。
次の一覧は、実務で起こりやすい失敗例をまとめています。各項目は、どのような管理の抜けにつながるかを示しているため、自社の契約案に同じ構造がないかを読み取ります。
クラウドIaaS、サポート、ログ管理、メール配信が実際に使われていれば、形式的な禁止よりも実際の管理が問題になります。
一般承認しているのに一覧URL、更新通知、担当者が不明だと、委託先管理の証跡が残りません。
海外サポート、共有IT基盤、グループ会社の運用が管理対象から漏れる可能性があります。
Sub-processorが国外にいる場合、承認条項だけでは足りず、移転根拠、SCC、TIA、TRA、暗号化、アクセス国の確認が必要です。
Sub-processorや下位委託先で発生した漏えい等が通知対象か争いになるため、明示的に含めます。
モデル改善、評価、アノテーション、ログ解析、人的レビューに顧客データが使われる可能性を別途確認します。
中庸型の条項では、一般承認を基本にしながら高リスク領域を補強します。
完成形に近いSub-processor条項は、定義、一般承認、一覧記載事項、追加・交代通知、異議、緊急変更、同等義務、再々委託、監督、責任、越境移転、インシデント、終了時措置を順に置きます。実際には、DPA、主契約、SCC、セキュリティ別紙、サービス仕様、責任制限条項と整合させます。
次の表は、中庸型の完成形サンプルを条項構成として整理したものです。各行を読むと、条項本文に何を書くべきか、どの契約文書と整合させるべきかが分かります。
| 条項 | 書く内容 | 整合させる文書 |
|---|---|---|
| 1. 定義 | ProviderがCustomerのために行う個人データ処理を実施する第三者を定義します。 | DPA、サービス仕様 |
| 2. 一般承認 | 指定一覧に記載されたSub-processorの使用を一般的に承認します。 | DPA別紙、Trust Center |
| 3. 一覧記載事項 | 名称、所在地、処理概要、データ種類、処理場所、アクセス国、移転メカニズム、更新日を含めます。 | 委託先管理台帳 |
| 4. 追加・交代通知 | 30日前通知、通知方法、異議申立て方法を定めます。 | 通知運用、管理画面 |
| 5. 異議申立て | 15日以内、合理的なデータ保護・情報セキュリティ・法令遵守・規制上の理由、代替措置、部分解除を定めます。 | 解除条項、サービス仕様 |
| 6. 緊急変更 | セキュリティ、サービス継続、法令遵守、既存相手方の急な利用不能に備えます。 | BCP、インシデント対応規程 |
| 7. 同等義務 | 処理目的、指示遵守、秘密保持、安全管理、再々委託制限、請求対応、漏えい通知、監査、越境移転、返却・削除を課します。 | DPA、セキュリティ別紙 |
| 8. 再々委託 | 下位委託先にも同等義務を課し、処理チェーン概要を提供します。 | Sub-processor契約 |
| 9. 監督・情報提供 | 選定時と契約期間中の確認、第三者監査報告、認証、セキュリティ資料を定めます。 | 監査条項、セキュリティ資料 |
| 10. 責任 | Sub-processorの義務履行について、Providerが自己と同様に責任を負います。 | 責任制限条項、補償条項 |
| 11. 越境移転 | SCC、補完的措置、TIA、TRA、日本法対応への協力を定めます。 | SCC、移転台帳 |
| 12. インシデント | Sub-processorや下位委託先での漏えい、不正アクセス、可用性喪失も通知対象にします。 | 漏えい通知条項 |
| 13. 終了時措置 | 返却、削除、匿名化、バックアップ削除サイクル、隔離を定めます。 | 終了条項、データ削除手順 |
次の調整表は、条項の強度を顧客側、中庸型、ベンダー側で比較しています。交渉では、すべての項目を同じ方向に寄せるのではなく、データの感度と商流に応じて強弱を読み取ることが重要です。
| 論点 | 顧客側に強い書き方 | 中庸型 | ベンダー側に強い書き方 |
|---|---|---|---|
| 承認方式 | 全Sub-processor個別承認 | 既存は一般承認、新規は通知・異議 | 一般承認のみ |
| 通知期間 | 60日前 | 30日前 | 10日から15日前または合理的期間 |
| 異議 | 任意の理由で拒否できます。 | 合理的なデータ保護・法令遵守上の理由にします。 | 重大な法令違反リスクに限定します。 |
| 契約写し | 全文開示 | 関連部分のマスキング開示 | 要約または表明保証のみ |
| 監査 | 直接監査権 | 第三者監査報告と重大時追加監査 | 標準資料のみ |
| 責任 | 上限除外 | データ侵害のみ別上限 | 主契約上限内 |
| 再々委託 | 全下層の名称開示 | 処理チェーン概要開示 | 管理方針のみ開示 |
| 越境移転 | 事前個別承認 | 許可地域と通知 | グローバル処理を一般承認 |
FAQは一般的な制度説明として整理し、個別の法的判断は専門家への相談が必要です。
一般的には、必要になる場面が多いとされています。日本法だけを見ても、個人データの取扱いを委託する場合、委託元には委託先の監督が求められます。ただし、取扱データ、再委託の有無、海外SaaS、EUデータ、英国データ、米国消費者データの有無によって必要な条項は変わります。具体的な対応は、契約書と処理実態を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、全面禁止だけで安全になるとは限らないとされています。クラウド基盤、メール配信、監視、バックアップ、サポートがサービス提供に不可欠なことがあるためです。ただし、高リスク処理では個別承認が適する場合もあります。具体的には、処理データの種類、アクセス権限、サービス仕様、代替可能性によって判断が変わります。
一般的には、契約別紙に限らず、Trust Center、ウェブページ、管理画面、通知購読システムで提供されることもあります。ただし、一覧へのアクセス方法、記載事項、更新通知、異議申立て方法を契約上明確にしておく必要があります。個別契約で足りるかは、取引内容や規制上の要請によって変わります。
一般的には、条項の設計次第です。多くの契約では、合理的なデータ保護上、情報セキュリティ上、法令遵守上または規制上の理由に基づく異議に限定し、両当事者が代替措置を協議します。解決しない場合は、該当サービス部分の解除や代替機能の提供を定めることがあります。
一般的には、GDPR型の考え方では、ProcessorはSub-processorのデータ保護義務の履行についてControllerに責任を負うとされています。契約上も、Sub-processorの作為・不作為についてProcessorが自己と同様に責任を負う形が基本です。ただし、損害賠償責任の上限、補償範囲、行政罰の扱いは契約全体で個別に設計する必要があります。
一般的には、重なる部分はありますが完全には同じではありません。日本の再委託条項は業務の再委託全般を対象にしやすい一方、Sub-processor条項は個人データ等の処理チェーン、DPA、SCC、越境移転、データ主体請求、監査、削除と接続します。国際契約では、再委託条項とは別にSub-processor条項を置くと明確になる場合があります。
一般的には、顧客データをAIサービス提供者のために処理する場合、Sub-processorに該当する可能性があります。ただし、外部モデル提供会社が独自目的でデータを利用する場合は、独立Controller、第三者提供先、共同利用先など別の法的構成になる可能性があります。学習利用、ログ保存、モデル改善、目的外利用、本人同意、匿名化、削除可能性を含めて専門家へ確認する必要があります。
データガバナンスの中核として、契約締結後の更新確認まで設計します。
Sub-processor条項は、契約書の片隅に置かれる一条項ではなく、クラウド、SaaS、AI、グローバルBPO、海外開発、グループ共通IT基盤におけるデータガバナンスの中核です。実際のデータ処理は多層化しているため、契約締結時だけでなく、一覧更新、通知確認、年次棚卸しまで運用する必要があります。
次の一覧は、最終的に確認する実務上の着地点を示しています。各項目が契約本文、別紙、DPA、SCC、セキュリティ資料、社内台帳のどこで担保されているかを読み取ることが重要です。
必要なSub-processorを認めながら、承認、通知、異議、代替措置を置きます。
基本方針名称、所在地、処理内容、アクセス国、移転根拠、認証、更新日を確認します。
透明性DPAと同等以上の義務を下流へ課し、ProcessorがSub-processorの履行について責任を負う形にします。
責任SCC、TIA、TRA、日本法第28条、学習利用、ログ保存、サポートアクセスを別途明確にします。
移転・AI変更通知を受け取り、年1回以上主要ベンダーの一覧を確認し、委託先管理台帳と連動させます。
運用