Insight 2026.06.13

個人情報取扱条項とは？委託契約・SaaS契約で確認すべきポイント

この記事を書いた人 朝戸統覚 Legal Agent法律事務所代表弁護士 / Founder & CEO

企業法務、M&A、スタートアップ法務、契約レビュー、生成AIを活用した法務体制づくりを支援しています。

こんにちは。LegalAgent 代表弁護士の朝戸です。

「乙は、個人情報保護法を遵守する」。契約書に並ぶ個人情報条項が、この一文だけで終わっている場面を見かけます。法令を守ることは契約に書かれていなくても当然の義務です。個人情報取扱条項では、その取引で双方が行うことを具体的に決めます。誰が、どの個人情報を、どの目的でどこまで扱い、再委託や事故の際にどう動くのかを取引の実態に合わせて特定していきます。

SaaSの導入、業務委託、マーケティング施策など、現代の企業活動では個人情報や個人データの取扱いが日常的に発生します。SaaSの利用でも、データの扱いによっては法律上の委託に当たります。サービス名や契約の表題から決めつけず、利用の実態を確認します。

取引実態とデータフローの把握

個人情報取扱条項とは、契約に関連して個人情報や個人データを取り扱う場合に、その取扱方法や安全管理義務、漏えい時の対応などを定める条項です。企業間の取引では、採用支援や人材紹介、給与計算や労務管理の外部委託、SaaSへの顧客情報登録、AIサービスへのデータ入力、M&Aや法務デューデリジェンスにおける資料共有など、多様な場面で登場します。

条項の文言を整える前提として、実際のデータの流れを把握することが欠かせません。どのデータを、誰がどのシステムで扱い、どこにどの期間保管するのかという事実関係が曖昧なままでは、条項の文言だけを修正しても実態との乖離が残ってしまいます。データの流れを図や表にすると、確認が必要な保存先や共有先を把握しやすくなります。その取扱いが利用目的の達成に必要な範囲での委託（個人情報保護法27条5項1号による国内第三者提供同意の例外）に当たるのか、同意を要する第三者提供なのか、共同利用なのかなどを、確認した事実に基づいて判断します。第三者提供にも法定の同意不要の例外があるため、適用条件を確認します。

扱うデータの種類と自社の立場の確認も欠かせない視点です。個人情報といっても、氏名やメールアドレスにとどまらず、購買履歴、採用応募者情報、健康情報など、サービスによって内容は大きく異なります。要配慮個人情報が含まれる場合には、取得時の同意など、追加で適用される法令上の要件も確認します。あわせて自社が委託者なのか受託者なのか、共同利用者なのか第三者提供を受ける側なのかという立場も見極めます。利用目的や取得経路の確認の力点は、この立場によって変わります。表面的な文言の修正に終始せず、どの種類のデータをどの構成で扱うのかまで詰めてから条項の検討に入ると、実態に合わないひな形の形式的な交換を避けられます。

委託契約における管理義務と再委託の設計

個人データの取扱いを委託する場合、委託元には委託先に対する必要かつ適切な監督が法律上課されます（同法25条）。契約では、監督に必要な措置と、受託者が実施する内容を具体的に決めます。

条項では委託業務の範囲と安全管理措置を決め、監査を受け入れる条件や契約終了後の返還・削除の方法も定めます。委託者側は自社が負う監督責任を果たすためにどこまでの義務を受託者に課すかを確認し、受託者側はその義務が自社の管理体制で現実に対応できるかを見極めます。履行できない義務を形式的に引き受けてしまうと、義務の開始時点から対応できないおそれがあります。開始日と必要な準備も確認しておきます。

再委託は、実務上の調整が特に難航しやすい論点です。SaaSの利用やBPO業務では、クラウド事業者、外部ツール、海外拠点が関与することが一般的です。再委託を一律禁止とするか、事前承諾制とするか、通知制にとどめるかは、事業実態に合わせて選択します。クラウドサービスの利用が不可避な業務において一律禁止を定めると、現実には遵守できず、監督の基準としても形骸化してしまいます。承諾制を採用する場合も、再委託先を個別に承諾するのか、類型や一覧表を用いた包括承諾とするのか、一覧更新時の通知方法をどうするかまで決めておきます。多数の事業者が関与するサービスでは、包括承諾と一覧更新通知の組み合わせが現実的な落としどころになることが多いです。

SaaSやAIサービスにおける利用範囲と規約の整合

SaaSやAIサービスを利用する場合、個人情報取扱条項は利用規約、プライバシーポリシー、データ処理規約（DPA）などに分散して規定されていることが一般的です。利用者側として慎重に見極めたいのは、入力データや利用ログを提供者側がどこまで二次利用できるかという点です。

サービス改善、AIモデルの学習、サポート対応などを目的としてデータが利用される設計は珍しくありません。しかし、利用目的が過度に広範であると、利用者側としては受け入れが難しくなります。入力データの利用目的とモデル学習への利用可否を確かめ、ログやメタデータの扱いも確認します。保存期間と保存先、外国のサーバーやサブプロセッサーの関与を把握したうえで、解約後の削除やエクスポートの手順を確認します。なお、規約上に「統計化」や「匿名化」と記載されていても、それが直ちに法律上の匿名加工情報に該当するとは限りません。どの程度の加工が施され、復元可能性が排除されているのかを確かめ、必要に応じてベンダーに質問した記録を残しておくと、後日の社内説明や本人対応に役立ちます。

また、すべてのSaaSやAIサービスの利用が法律上の「委託」に該当するわけではありません。事業者がデータを取り扱わない契約になっており、適切なアクセス制御が施されている場合には、第三者提供や法25条の委託監督に該当しない構成もあり得ます。ただし、その場合であっても自社が講ずべき安全管理措置（法23条）が免除されるわけではない点に留意します。外国サーバの利用についても、サーバの物理的な所在地だけで判断するのではなく、外国にある第三者への提供や委託として法28条の要件（本人の同意、基準適合体制と継続的な措置、同等水準として指定された国か、法定の例外に当たるかなど）を個別に確認します。

AIサービスでは、プロンプトや添付ファイルに個人データが含まれる可能性があります。契約書レビュー、カスタマーサポート、採用業務といった具体的な場面ごとに、個人データが混入しないか、学習利用や外部提供が制限されているか、自社のプライバシーポリシーにおける本人への説明と矛盾していないかを確認します。氏名や連絡先だけでなく、相談記録や職務経歴、問い合わせ履歴も個人に関する情報になり得ることを意識して社内運用と突き合わせます。

漏えい発生時の初動手順と社内台帳の運用

「漏えい等の事故が発生した場合は速やかに報告する」という抽象的な定めだけでは、緊急時に迅速な行動を取ることは困難です。誰が、いつまでに、何を報告するのか、原因調査への協力範囲や、本人への通知・個人情報保護委員会等への報告の分担があらかじめ定まっていなければ、発覚直後の貴重な時間を役割調整に費やすことになります。

条項では、漏えい等の定義と、初動報告の期限・内容を決めます。原因調査への協力や被害拡大防止措置に加え、本人通知と当局報告を誰が行うかも定めます。費用負担と損害賠償の上限を確認し、再発防止策の報告まで手順を決めておきます。法26条に基づく当局報告や本人通知は、法令所定の事態やその発生のおそれがある場合などが対象です。契約上の通知義務は、法定報告の対象より広い範囲について定めることもできます。一方で、法律上の義務を契約によって一方的に免除したり他方へ移転したりすることはできないため、法令遵守と契約上の役割分担を切り分けて考えます。委託先が委託元に所定の通知をした場合の法定報告義務の例外なども、法令の条件に沿って確認します。受託者の立場では、報告期限を事象覚知からの現実的な時間で区切り、軽微なインシデントまで無制限に即時報告の対象とならないよう範囲を限定することが考えられます。ただし、必要な初動連絡や法定対応を妨げる範囲にしないようにします。

あわせて、DPAやプライバシーポリシーとの整合性も確認します。英文のDPAが存在する場合、契約書本文と矛盾した際の優先関係、セキュリティ基準、監査手順などを読み落とさないようにします。また、自社のプライバシーポリシーで本人に公表している利用目的と、委託契約における許容範囲に食い違いがないかを確認します。すべての委託先を個別に公表したり同意を得たりすることが法律上義務付けられているわけではありませんが、本人に対する説明内容と契約や実際の運用との間に齟齬がない状態を整えることが基本となります。

契約締結後は、社内台帳を用いた継続的な運用管理へと進みます。委託先が増加すると実態把握が形骸化しやすいため、以下の項目を台帳で一覧化して管理します。