責任共有モデルの図はどこでも見かけます。下の層がクラウド事業者、上の層が利用者、と色分けされているあれです。ただ、あの図に署名した覚えはありません。署名しているのは利用規約とデータ処理の契約のほうです。
実際に何がどちらの責任なのかは、そちらに書かれています。読みに行くと、図では見えない境界がいくつも出てきます。バックアップは契約上も利用者の責任だとか、インシデント通知の対象になる「侵害」には定義があって、自分の設定ミスによる漏洩は入っていないとか。
契約文書を読んで、責任の分かれ目を確認します。本文で参照するのは次の3つで、いずれも執筆時点の版です。
| 文書 | 最終更新 |
|---|---|
| Google Cloud 利用規約 | 2026年6月1日 |
| Cloud Data Processing Addendum | 2026年6月8日 |
| サービス固有の規約 | 2026年7月29日 |
規約は更新されるので、判断に使うときは必ず当日の版を確認してください。
Google 自身が図の限界を認めている
そもそも Google は、責任共有モデルという枠組みだけでは足りないと書いています。アーキテクチャセンターの文書の一節です。
Google believes that the shared responsibility model stops short of helping cloud customers achieve better security outcomes. Instead of shared responsibility, we believe in shared fate.
（Shared responsibilities and shared fate on Google Cloud）
責任共有モデルは、より良いセキュリティの結果を顧客が得るには手前で止まっている。だから shared fate（運命共有）だ、という主張です。同じ文書には、責任共有モデルの難しさとして、サービスごとに設定項目も Google 側の保護範囲も違うので、どこまでが自分の担当かを見極めること自体が困難だ、という説明もあります。
責任分界の図が抽象的なのは、抽象的にしか描けないからです。IaaS と PaaS と SaaS で線の位置が変わり、同じ PaaS の中でも機能ごとに変わります。だからこそ、実際の約束を確認するには契約文書に当たるのが早い、ということになります。
契約文書の構成
Google Cloud を使うときに効いてくる文書は、役割が分かれています。
| 文書 | 何が書かれているか |
|---|---|
| 利用規約 | 全体の枠組み。データの権利、支払い、解約、サポートの分担、免責 |
| Cloud Data Processing Addendum（CDPA） | 顧客データの取り扱い。セキュリティ措置、インシデント通知、削除、サブプロセッサ、処理される場所 |
| サービス固有の規約 | サービスごとの追加条件。データロケーションのコミットメントはここ |
| SLA | 稼働率の保証と、下回ったときのクレジット |
| 利用制限ポリシー（AUP） | 禁止される使い方 |
セキュリティと責任分界の話は、ほぼ CDPA に集約されています。利用規約の本文にも書かれてはいますが、中身は CDPA に委ねられています。
Google will only access, use, and otherwise process Customer Data in accordance with the Cloud Data Processing Addendum and will not access, use, or process Customer Data for any other purpose. Google has implemented and will maintain technical, organizational, and physical measures to protect Customer Data, as further described in the Cloud Data Processing Addendum.
（Google Cloud 利用規約 5.2 Protection of Customer Data）
顧客データは CDPA に従ってのみ処理し、それ以外の目的には使わない。技術的、組織的、物理的な措置を実施し維持する。詳細は CDPA を見よ、という構造です。
なお、その手前の 5.1 に、データの知的財産権は顧客に残ると明記されています。ここは図でも説明される部分ですが、条項として存在することは確認しておく価値があります。
Google が約束していること
CDPA から、Google 側の義務として書かれているものを拾います。
セキュリティ措置の実施と維持は 7.1.1 にあります。偶発的または不法な破壊、喪失、改変、無断の開示やアクセスから顧客データを保護する措置を実施し維持する、と書かれています。措置の中身は Appendix 2 に列挙されていて、暗号化、機密性と可用性の維持、インシデント後の復旧、有効性の定期的なテストが含まれます。
この条項には、更新に関する制限も付いています。
Google may update the Security Measures from time to time provided that such updates do not result in a material reduction of the security of the Services.
措置は随時更新できるが、サービスのセキュリティを実質的に低下させる更新はできない。事業者側の裁量に対する歯止めがここに入っています。
インシデントの通知は 7.2.1 と 7.2.2 です。Data Incident を認識した後、速やかに遅滞なく通知する、と定められています。通知に含める内容も規定されていて、インシデントの性質と影響を受けた顧客リソース、Google が取ったか取る予定の対応、顧客に推奨する対応、追加情報の問い合わせ先の4点です。すべてを同時に出せない場合は、その時点で分かっている情報で初報を出し、続報を出すとされています。
監査と証明の維持は 7.4 です。ISO 27001 の認証と、SOC 2 および SOC 3 レポートを維持する。SOC レポートは12か月に1回以上の監査に基づいて年次で更新する、と書かれています。
サブプロセッサへの責任は 11.3 と 11.4 に書かれています。Google はサブプロセッサに契約で義務を課すだけでなく、その作為不作為について全面的に責任を負うと明記されています。
remain fully liable for all obligations subcontracted to, and all acts and omissions of, the Subprocessor.
新しいサブプロセッサを起用する場合は、顧客データの処理を始める30日以上前に通知するとも定められています。
顧客の責任として明記されていること
ここが本題です。CDPA の 7.3.1 に、顧客の責任が3つ列挙されています。
Customer is responsible for its use of the Services and its storage of any copies of Customer Data outside Google's or Google's Subprocessors' systems, including:
a. using the Services and Additional Security Controls to ensure a level of security appropriate to the risk to the Customer Data;
b. securing the account authentication credentials, systems and devices Customer uses to access the Services; and
c. backing up or retaining copies of its Customer Data as appropriate.
要点は3つです。リスクに見合う水準のセキュリティを、提供されている機能と追加のセキュリティ管理機能を使って自分で確保すること。サービスへのアクセスに使う認証情報、システム、デバイスを保護すること。そして、必要に応じて顧客データをバックアップし、または複製を保持すること。
3つ目が重いところです。マネージドサービスの冗長性は可用性のためのもので、利用者の誤操作や誤削除に対する保険ではありません。この区別は運用の常識として語られることが多いですが、契約文書にも顧客の責任として書かれています。バックアップを取っていなかったことによる損失を事業者側の責任として主張する余地は、この条項がある以上ほとんどありません。
もう1つ、7.3.2 には見落としやすい同意が入っています。
Customer agrees that the Services, Security Measures, Additional Security Controls, and Google's commitments under this Section 7 (Data Security) provide a level of security appropriate to the risk to Customer Data
Google の措置とコミットメントが、顧客データに対するリスクに見合った水準を提供している、と顧客が同意する条項です。技術水準やコスト、処理の性質を考慮したうえで、という但し書きは付いています。ここに同意している以上、事後に「Google 側の対策が不十分だった」と主張する出発点は限られます。
利用規約側にも顧客の責任が散っています。データの取り扱いについて必要な同意と通知を取得するのは顧客（3.2）。自分のアプリケーションとプロジェクトの技術サポートは顧客（6.1）。アカウントの不正利用に気付いたら速やかに Google に通知する、というのも顧客側の義務です。
境界が見える3つの定義
抽象的な線引きより、定義のほうが境界をはっきり示します。
Data Incident の定義
通知義務の対象になるのは Data Incident です。定義はこうなっています。
"Data Incident" means a breach of Google's security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Data on systems managed by or otherwise controlled by Google.
Google のセキュリティの侵害であること、そして Google が管理または制御するシステム上の顧客データに関するものであること。この2つが条件です。
つまり、自分たちが Cloud Storage のバケットを公開設定にしてしまった、サービスアカウントキーが流出して読み出された、といった事象はこの定義に入りません。Google 側の通知は来ませんし、来ないこと自体が契約どおりです。検知は自分で行うことになります。
顧客データの中身は評価されない
7.2.3 は短い条項ですが、意味は大きいです。
Google has no obligation to assess Customer Data in order to identify information subject to any specific legal requirements.
特定の法的要件の対象になる情報を識別するために顧客データを評価する義務は、Google にはありません。個人情報や規制対象データを置いたかどうかは、事業者が見て教えてくれるものではない、ということです。分類は顧客側の作業になります。
通知は過失の承認ではない
7.2.4 に、インシデントの通知や対応が Google の過失や責任を認めたことにはならない、と明記されています。通知が来たことと、責任の所在が確定することは別だという整理です。
データの場所と削除
責任分界とあわせて確認しておきたいのが、データがどこに置かれ、いつ消えるかです。
原則はどこでも処理されうる
CDPA 10.1 の書き出しはこうです。
Subject to Google's data location commitments under the Service Specific Terms and data transfer commitments under Appendix 3 (Specific Privacy Laws), if applicable, Customer Data may be processed in any country where Google or its Subprocessors maintain facilities.
サービス固有の規約のデータロケーションのコミットメントが適用される場合を除けば、顧客データは Google またはサブプロセッサが施設を持つどの国でも処理されうる、と読めます。既定の挙動は Appendix 2 にも書かれています。
Subject to any Instructions to the contrary (e.g. in the form of a data location selection), Google replicates Customer Data between multiple geographically dispersed data centers.
地理的に分散した複数のデータセンター間で複製する、というのが既定です。データロケーションの選択が、それに対する反対の指示として働きます。
コミットメントの範囲
サービス固有の規約のデータロケーション条項は、対象サービスを限定しています。
For any Service listed at https://cloud.google.com/terms/data-residency, Customer may select a specific Region or Multi-Region as detailed in the Cloud Locations Page, and Google will store Customer Data for that Service at rest only within the selected Region or Multi-Region.
データレジデンシーの一覧に載っているサービスについて、選択したリージョンまたはマルチリージョンの中にのみ保存する、という約束です。裏を返せば、一覧にないサービスにはこの約束が付きません。
同じ条項の続きに、例外と限界が3つ書かれています。
- バックアップ、信頼性、デバッグ、サポート、保守、セキュリティの目的で、選択したリージョンと同じ国内の他のリージョンに複製されることがある
- 顧客やエンドユーザーがどこからアクセスするか、どこへデータを移動するかは、サービス側では制限しない
- リソース識別子、属性、その他のデータラベルは Customer Data に含まれない
3つ目は具体的に効いてきます。バケット名、プロジェクト ID、ラベルといったものは、この条項でいう顧客データではありません。保存場所の約束の対象外だと読めます。命名に機微な情報を入れない、という運用上の作法には、契約上の裏付けもあることになります。
削除の期限
削除には具体的な日数が入っています。
期間中に顧客がサービスの機能を使ってデータを削除し、顧客側で復元できなくなった場合、それは Google のシステムから削除せよという指示として扱われます。Google はこの指示に合理的に実行可能な範囲で速やかに、かつ最長180日以内に従う、とされています（6.1）。
契約終了時は、まず最大30日の復旧期間があり、その後に同じく最長180日以内で削除されます（6.2）。
削除ボタンを押した瞬間に世界中から消えるわけではない、という当たり前の事実に日数が付いています。データ消去の証跡を求められる場面では、この日数がそのまま説明材料になります。
設計にどう落とすか
契約文書から読み取れることを、実務の判断に変えるとこうなります。
バックアップは自分で設計する。契約上も顧客の責任として明記されている以上、マネージドサービスの冗長性を根拠に省略する判断は成り立ちません。誤削除と誤操作に対する備えは別途必要です。
検知の仕組みを自分で持つ。自分の設定ミスや資格情報の流出は Data Incident の定義に入らないので、通知は期待できません。監査ログの監視や Security Command Center のような仕組みは、契約が埋めない部分を埋めるためのものだと位置づけられます。
データの分類は自分でやる。何が規制対象かを事業者が見つけてくれる前提には立てません。
リソースの名前に機微な情報を入れない。識別子とラベルはデータロケーションの約束の対象外です。
データの所在を約束させたいなら、対象サービスの一覧を先に見る。リージョンを選んだから大丈夫、という理解は、対象外のサービスでは成り立ちません。
まとめ
- 責任分界の図は契約ではない。実際の分界は利用規約と CDPA、サービス固有の規約に書かれている
- Google 自身、責任共有モデルだけでは顧客の安全につながらないと書いている
- Google 側の義務は、セキュリティ措置の実施と維持（実質的に低下させる更新は不可）、Data Incident の通知、ISO 27001 と SOC レポートの維持、サブプロセッサの行為への全面的な責任
- 顧客側の責任は、リスクに見合う水準の確保、認証情報とデバイスの保護、そしてバックアップの保持
- 顧客は、Google の措置がリスクに見合う水準であることに規約上同意している
- Data Incident の定義は Google が管理するシステム上の侵害。自分の設定ミスによる漏洩は対象外で、通知は来ない
- Google には顧客データの中身を評価する義務がなく、通知は過失の承認でもない
- 顧客データは原則としてどの国でも処理されうる。ロケーションの約束はデータレジデンシー一覧に載るサービスのみで、同一国内の他リージョンへの複製は認められている
- リソース識別子、属性、ラベルは Customer Data に含まれない
- 削除は、期間中の指示なら最長180日、契約終了時は最大30日の復旧期間の後に最長180日
図を見て納得するより、7.3.1 の3行を読むほうが早い、というのが読んでみた結論です。バックアップ、認証情報、そしてリスク水準の判断。この3つが自分の側にあると分かっていれば、残りは設計の問題になります。
最後に注意点です。ここで引用したのは執筆時点の英語版の条項で、契約の形態（オンラインの規約か、個別に締結した契約か）や地域、リセラー経由かどうかで適用される条件は変わります。実際の判断が必要な場合は、当日の版を確認したうえで、法務や専門家に相談してください。