クラウドサービスの情報漏洩|共有責任モデル・ベンダーへの賠償請求・設定ミス対応を弁護士が解説
2026年06月23日

クラウドサービスで情報漏洩が発生した場合、「ベンダーの責任か、自社の責任か」は共有責任モデル(Shared Responsibility Model)によって決まります。
SaaSであっても、アクセス権管理や設定ミスは企業側の責任です。S3バケットの公開設定やGoogle Driveの全員閲覧可設定など、設定ミス起因の漏洩は企業が個人情報保護法上の安全管理義務違反を問われます。
本記事では、クラウドサービス種別ごとの責任分担、ベンダーへの損害賠償請求の壁(責任制限条項)、設定ミス時の対応手順、越境移転・GDPRへの対応、契約・DPA締結のリスク管理まで弁護士が解説します。
この記事を監修したのは
スポットで一括対応or顧問で伴走も!
お客様に合わせたプランをご用意しています
クラウドサービスと情報漏洩:責任の所在が複雑な理由
クラウドサービスに格納・処理した個人情報が漏洩した場合、「ベンダーの責任か、利用企業の責任か」という問題が生じます。クラウドサービスは「共有責任モデル(Shared Responsibility Model)」を採用しており、セキュリティ責任がベンダーとユーザー(企業)に分担されているためです。この分担を正確に理解せず、「クラウドはベンダーが守ってくれる」と誤解すると、漏洩時に自社の責任を問われる事態になります。
クラウドサービスの種類と責任分担の違い
クラウドサービスはIaaS・PaaS・SaaSの三層に分類され、各層によって企業とベンダーの責任範囲が大きく異なります。
サービス種別 | ベンダーの責任範囲 | 企業(ユーザー)の責任範囲 | 代表例 |
IaaS(インフラ) | 物理的インフラ・ネットワーク・ストレージ・仮想化レイヤー | OS・ミドルウェア・アプリ・データ・アクセス管理・暗号化設定など全て | AWS EC2, Azure VM, GCP Compute |
PaaS(プラットフォーム) | 物理インフラ+OS・ランタイム | アプリケーション・データ・アクセス管理・設定 | AWS RDS, Heroku, Google App Engine |
SaaS(ソフトウェア) | インフラ全体+アプリ本体のセキュリティ | アカウント管理・データ設定・利用者権限・データの利用範囲設定 | Salesforce, Microsoft 365, Slack |
SaaSであっても、企業はアクセス権管理・機密設定・データの取扱いに責任を持ちます。「ベンダーが管理しているから安心」は誤解です。設定ミスによる漏洩(S3バケットの公開設定、Google Driveの「リンクを知っている全員が閲覧可能」等)は企業側の責任になります。
個人情報保護法上のクラウドサービス利用の取扱い
企業がクラウドサービスに個人情報を保存・処理する場合、「第三者提供」(個人情報保護法27条)に該当するかどうかが重要な法的問題です。個人情報保護委員会のガイドラインQ&Aは、この点について明確な基準を示しています。
「第三者提供」非該当の要件:個人情報保護委員会の基準
要件 | 具体的な内容 |
①個人データを取り扱わない旨の契約締結 | クラウドベンダーとの間で、「ベンダーは個人データにアクセス・取り扱いをしない」旨の契約条項(処理委託契約等)を締結していること |
②適切な安全管理措置を講じていること | 企業自身がクラウド上のデータに対して暗号化・アクセス制御等の安全管理措置を講じること |
③ベンダーが実質的に個人データを取り扱っていないこと | ベンダーの従業員がアクセスできない仕組み(暗号化・鍵管理の企業側保持等)が確保されていること |
上記3要件を全て満たす場合は「委託」とみなされ(24条が適用)、満たさない場合は「第三者提供」として扱われます(27条が適用:原則として本人の同意が必要)。ほとんどの国内クラウドサービスはDPA(Data Processing Agreement)の締結を提供しており、第三者提供非該当とする運用が可能です。AWSやGoogle Cloudも日本語のDPAを提供しています。
越境移転の問題:外資系クラウドサービスの利用
AWSやGoogle Cloud、Microsoft Azureなど外資系クラウドサービスは、データを日本国外のサーバーに保存・処理することがあります。この場合、個人情報保護法28条の「外国にある第三者への提供」の規制が問題になります。
移転先の類型 | 日本の個人情報保護法上の対応 |
EU加盟国(GDPR対象地域) | 外国に移転しても「十分性認定」の対象外だが、GDPRの適切な保護措置があれば可。ベンダーのDPA・SCCの確認が必要 |
十分な保護措置を有する国・地域 | 移転に特別な手続きは不要だが、適切な安全管理措置の確保は必要(現在、規則で指定なし) |
その他の国・地域(米国含む) | ①本人の同意、または②個人情報保護委員会規則で定める基準を満たす体制整備が必要。DPA・SCCの締結が実務上の対応 |
クラウドベンダーへの損害賠償請求:規約上の壁
クラウドサービスの利用規約(Terms of Service)・サービスレベル合意書(SLA)には、通常、ベンダーの損害賠償責任を大幅に制限する条項が含まれています。漏洩が「ベンダー側の問題」であっても、実際に賠償を得ることは容易ではありません。
主要クラウドサービスの責任制限の傾向
制限の類型 | 内容と実務上の問題 |
賠償額の上限 | 「過去12ヶ月間の支払済み料金」を上限とするケースが多い。大量の個人情報を低コストで保存していた場合、被害総額との乖離が大きい |
間接損害の免責 | 逸失利益・信用低下・機会損失等の「間接損害・特別損害」を免責とする条項。実際の事業損害の多くが間接損害に分類される |
セキュリティ事故の免責事由 | 「正常なサービス提供に起因しない障害」「第三者の攻撃」等を免責とする場合がある。ゼロデイ攻撃の場合はベンダーの責任が問われないケースも |
SLA違反の救済手段 | サービスの稼働率保証(99.9%等)違反の場合は「クレジット(料金割引)」が付与されるが、損害賠償とは別物。クレジットでは実際の損害を補填できない |
日本法・消費者契約法との関係
外資系クラウドサービスの規約は準拠法を「デラウェア州法」等とするケースがありますが、日本の事業者が日本の個人情報を保存する場合、日本法の強行規定(消費者契約法・個人情報保護法)が適用される余地があります。また、消費者契約法10条は「消費者の利益を一方的に害する条項を無効とする」と定めており、中小企業が消費者として利用する場合は同法の適用が問題になります(BtoB取引では原則不適用)。
ベンダーへの請求が認められやすいケース
以下の状況ではベンダーの責任が認められる可能性が高くなります。弁護士とともに証拠を保全し、SLA違反・セキュリティ基準未達の立証を行うことが重要です。
■ ベンダー自身の設定ミス・脆弱性
ベンダーが提供するサービス自体の既知の脆弱性を放置した・ベンダー側のデータセンター設定ミスでデータが公開された等
■ SLAに定める保護義務の不履行
契約で約束した暗号化・アクセス制御・バックアップ等のセキュリティ措置を実際には実施していなかった場合
■ 通知義務の不履行
セキュリティ侵害を検知したにもかかわらず、契約で定める期限内に顧客へ通知しなかった場合
設定ミスによる情報漏洩:企業側の責任と対処法
クラウドサービスを利用した情報漏洩の多くは、ベンダーのセキュリティ問題ではなく「企業側の設定ミス」に起因します。IPAの調査では、クラウド関連セキュリティインシデントの過半数は設定ミスが原因とされています。
典型的なクラウド設定ミスの類型
設定ミスの類型 | 具体例 | 発生しやすいサービス |
ストレージの公開設定 | AWS S3バケット・Google Cloud Storage・Azure BlobをPublicアクセス可能にしてしまう | AWS, GCP, Azure(IaaS) |
アクセス権の過剰付与 | 「全員に編集権限」「リンクを知っていれば誰でも閲覧可」の設定のまま機密情報を保存 | Google Drive, SharePoint, Dropbox |
APIキー・認証情報の露出 | GitHubにAWSアクセスキーをコミット・Slackにパスワードを貼付け | 全クラウドサービス |
暗号化の未設定 | データベースの暗号化を有効にしていない・保存データ(at rest)の暗号化なし | RDB・ファイルストレージ全般 |
ログ・監視の無効化 | CloudTrailやアクセスログを無効にしたまま運用。不正アクセス時に証拠がない | AWS, GCP, Azure |
MFA(多要素認証)の未設定 | 管理者アカウントにMFAなし。パスワード一つで全データにアクセス可能 | SaaS全般・クラウドコンソール |
設定ミスによる漏洩時の企業の責任
設定ミスによる漏洩は「企業側の過失」として被害者・規制当局に評価されます。個人情報保護法20条・23条の「安全管理措置」義務違反として、個人情報保護委員会から是正勧告・命令を受けるリスクがあります。被害者からの損害賠償請求においても、「適切な設定を行うべき義務を怠った」として過失が認定されやすくなります。
クラウドサービスの選定・契約時のリスク管理
クラウドサービスの選定・契約時にセキュリティ要件と法的条件を確認することが、漏洩リスクの根本的な低減につながります。
契約前の確認事項
確認項目 | チェック内容 |
①データ所在地 | 個人情報が保存・処理されるサーバーの所在地(国)。越境移転の規制対応が必要か確認 |
②DPA(データ処理契約) | 個人情報保護法24条の委託として扱うためのDPAが用意されているか。日本語版の有無 |
③セキュリティ認証 | ISO27001・SOC 2 Type II等の第三者認証の取得状況。監査報告書(SOC 2レポート)の提供可否 |
④インシデント通知義務 | セキュリティ侵害発生時の顧客への通知期限(72時間以内が望ましい)が契約に明記されているか |
⑤データの削除・返還 | 契約終了時のデータ削除・エクスポートの方法と確認手段 |
⑥損害賠償条項 | 責任制限の上限額・免責事由。可能であれば個人情報漏洩の場合の特則を交渉 |
⑦準拠法・紛争解決 | 準拠法が外国法の場合、日本での訴訟・仲裁が可能かどうかの確認 |
日本に特有の確認事項
日本の個人情報保護法や業法(金融・医療等)に対応したクラウドサービスを選ぶ際に特に重要な点として、以下が挙げられます。
- 政府クラウドの利用:政府情報システムのためのセキュリティ評価制度(ISMAP)に登録されたサービスかどうか
- 金融機関の場合:金融庁「クラウドサービスの外部委託に関するガイドライン」(2023年)への準拠確認
- 医療機関の場合:厚生労働省「医療情報システムの安全管理に関するガイドライン」(第6.0版)への準拠確認
- 行政手続きデータ:特定個人情報(マイナンバー)を含む場合は番号法の規制とIPA基準の確認
SLA(サービスレベル合意書)の読み方と違反時の対応
クラウドサービスのSLAは、稼働率保証・データバックアップ・セキュリティ対応などを定める重要な文書です。しかし多くの企業はSLAの内容を十分に確認せず利用を開始しているため、問題発生時に不利な立場に置かれます。
SLAで確認すべき主要項目
SLA項目 | 確認ポイントと問題点 |
稼働率保証(SLO) | 「99.9%」=月間最大43.8分のダウンタイム許容。「99.99%」=約4.4分。セキュリティ事故による長期停止はSLA対象外のケースも |
セキュリティインシデント通知 | 「X時間以内に通知」と明記されているか。通知の対象範囲(軽微なもの含むか・個人データに影響するもののみか) |
データバックアップ | バックアップの頻度・保持期間・復旧所要時間(RTO・RPO)の保証 |
SLA違反時のクレジット | 違反時に付与されるクレジット(料金割引)の計算式。通常は損害賠償とは別物で実被害を補填しない |
除外事由 | 「天変地異・第三者の攻撃・ユーザーの設定ミス」等が除外される場合、実際のインシデントの多くが保証対象外になる可能性 |
漏洩発覚後の対応:クラウドベンダーとの連携
クラウドサービスからの情報漏洩が発覚した場合、ベンダーへの対応依頼と並行して、企業として自主的な証拠保全・被害者対応・報告を進める必要があります。
発覚後の初動フロー
Step 1:ベンダーへの緊急連絡と調査依頼
ベンダーのセキュリティインシデント窓口(Security Response Team)に連絡し、調査を依頼します。主要クラウドサービスは24時間対応の窓口を持っています。調査依頼は書面(メール等)で行い、記録を保存します。
Step 2:アクセスログの取得・保全
ベンダーから提供されるアクセスログ・変更履歴を直ちに取得します。ログには保存期間があり(90日等)、期限が切れると取得不可になります。ベンダーに「ログを延長保存するよう依頼」することも重要です。
Step 3:被害範囲の特定
どのデータが・いつ・どのような経路で漏洩した可能性があるかを特定します。クラウドの管理コンソール(AWS CloudTrail、Azure Monitor等)のログが調査の起点になります。
Step 4:設定の変更・被害の封じ込め
漏洩の原因となった設定(公開バケット・過剰権限等)を直ちに修正します。侵害されたアカウントの認証情報を無効化・ローテーションします。
Step 5:通知・報告義務の確認
個人情報保護法26条の要件を確認し、必要に応じて個人情報保護委員会への速報(3〜5日以内)・確報(30日以内)を行います。
ベンダーから情報を引き出すための交渉ポイント
ベンダーはセキュリティ事故に関する詳細情報の開示に消極的なケースがあります。以下の根拠で情報開示を求めることができます。
■ 契約上の根拠
SLAやDPA(データ処理契約)に「インシデント調査への協力義務」「調査報告書の提供義務」が定められている場合、これを根拠に情報開示を求めます
■ 個人情報保護法上の根拠
個人情報保護委員会への報告に必要な情報(漏洩件数・漏洩日時・漏洩経路等)の提供をベンダーに求めることができます(委託先のベンダーも情報提供義務を負う場合がある)
■ 弁護士からの正式要求書
弁護士を通じた正式な情報提供要求書を送付することで、ベンダーの対応が迅速化することがあります
GDPR(EU一般データ保護規則)と日本企業の義務
EU在住者の個人データを処理する日本企業は、クラウドサービス利用においてもGDPRの適用を受ける可能性があります。GDPRはデータ漏洩時の規制当局への72時間以内の通知義務や高額の制裁金(最大2,000万ユーロまたは全世界年間売上高の4%)を定めています。
日本企業がGDPRを意識すべきクラウド利用シナリオ
- EU向けECサイト・サービスの運営:EU在住者の購買データ・会員情報をクラウドに保存している場合
- EU拠点を持つグループ企業:本社(日本)がEU子会社の従業員データをクラウドで処理する場合
- EU向けSaaS事業者:日本のSaaS企業がEU企業に提供するサービスでEU在住者のデータを処理する場合
GDPRが適用される場合、クラウドベンダーとの間でDPA(Data Processing Agreement)の締結が必須です。また、クラウドベンダーのデータセンターがEU域外にある場合は「標準契約条項(SCC)」に基づく越境移転が必要です。
よくある質問(FAQ)
Q:弊社が使っているSaaSから顧客データが漏洩しました。弊社に責任がありますか?
A:はい、あります。SaaSはベンダーがアプリケーション本体のセキュリティを管理しますが、企業はアカウント管理・データ設定・利用者の権限管理に責任を持ちます。また、SaaSに個人情報を保存している場合、個人情報保護法上の委託先監督義務(24条)を果たしていたかが問われます。ベンダー側の問題(脆弱性・設定ミス)であれば一次的にはベンダーの責任ですが、被害者は企業に対して直接損害賠償を請求できます。
Q:AWS S3のバケットを誤って公開設定にしてしまい、顧客情報が閲覧可能な状態になっていました。どうすればよいですか?
A:直ちに設定を「非公開」に変更し、アクセスログでどの期間・どのIPアドレスからアクセスがあったか確認します。アクセスがあった場合、個人情報保護法26条の漏洩報告義務の有無を確認します。不正の目的によるアクセスが確認された場合や1,000件超の個人情報が含まれる場合は報告が必要です。弁護士・セキュリティ専門家と連携し、被害範囲を特定した上で本人通知・規制報告の対応を進めてください。
Q:クラウドベンダーの規約に「損害賠償の上限は過去12ヶ月の支払料金」とあります。この制限は有効ですか?
A:原則として有効です。ただし日本法上、「故意または重過失」がある場合に責任制限を適用する条項は公序良俗違反として無効になる余地があります。また、消費者契約法(BtoC取引での適用可能性)や独占禁止法上の不公正な取引方法として問題になる場合があります。多くの主要クラウドベンダーはエンタープライズ契約で責任上限の交渉に応じているため、大量の個人情報を扱う場合は契約交渉を検討してください。
Q:ベンダーがセキュリティ侵害を1ヶ月間も通知しませんでした。これは問題ではないですか?
A:問題です。多くのクラウドベンダーのSLAや利用規約には「セキュリティ侵害の通知義務」が定められています。通知が遅れた場合、①SLA違反としてのクレジット請求、②通知遅延により拡大した損害(遅れた分の漏洩継続・対応遅延による追加被害)をベンダーへ損害賠償請求する根拠になります。ベンダーへの通知義務については今後の契約交渉でも強化を求めてください。
Q:外資系クラウドサービスに個人情報を保存していますが、越境移転の問題はありますか?
A:あります。個人情報保護法28条は、外国にある第三者への個人データの提供を規制しています。ただし、多くの外資系クラウドベンダーは日本の個人情報保護法に対応したDPA(データ処理契約)を提供しており、「委託」として第三者提供に当たらないとする構成が可能です。ただし越境移転の実態がある場合は本人への適切な情報提供(プライバシーポリシーへの記載)が必要です。EU在住者のデータを処理する場合はGDPRのSCC(標準契約条項)も必要です。
Q:クラウドサービスを解約したいのですが、ベンダーがデータを削除してくれません。法的手段はありますか?
A:契約書にデータの削除義務・削除証明書の提供義務が規定されている場合、その履行を求める法的請求が可能です。個人情報保護法24条の委託関係が成立する場合、委託終了時のデータ削除・返還は法的義務です。ベンダーが応じない場合は弁護士を通じた内容証明送付・訴訟(不作為の差止・削除の強制)の手段があります。契約終了前にデータ削除・移行の手順を明確化しておくことが重要です。
Q:クラウドサービスにおける個人情報の安全管理措置として、最低限何をすればよいですか?
A:個人情報保護委員会のガイドラインが求める「安全管理措置」として最低限必要な対策は、①暗号化(保存データ・転送中データ)、②アクセス制御(最小権限の原則・MFA必須)、③アクセスログの保存・監視、④設定の定期レビュー(公開設定になっていないか等)、⑤ベンダーとのDPA締結、です。これらを実施していない状態で漏洩が発生した場合、「安全管理措置を怠った」として法的責任が大きくなります。
※内容によってはご相談をお受けできない場合がありますので、ご了承ください。
スポットで一括対応or顧問で伴走も!
お客様に合わせたプランをご用意しています





