変更要約: Professional Cloud Security Engineer 第5章を新規作成（ドメイン5「コンプライアンス」: 技術的ニーズの判断・責任共有モデル・スコープ特定・要件→サービス/制御のマッピング・Access Transparency/Access Approval、Assured Workloads・組織ポリシー(事前ビルド/カスタム)・データとサービスのリージョナリゼーション(リソースロケーション制約)・ネットワーク/アクセスのセグメンテーション・監査ログの網羅）。
5.1規制要件と責任共有モデル
コンピュート/データ/ネットワーク/ストレージに関する技術的ニーズの判断、責任共有モデルの評価、規制コンプライアンスの対象となる Google Cloud 環境（スコープ）の特定、コンプライアンス要件を Google Cloud のサービスとセキュリティ制御（ネットワーク/アクセスのセグメンテーション、監査ログの網羅）へマッピングすることを理解します。
コンプライアンスは「何が自分の責任で、どの環境が対象か」を正しく区切ることから始まります。要件を具体的な Google Cloud の制御へ翻訳します。
5.1.1責任共有モデルとスコープ
クラウドのセキュリティは 責任共有モデル で分担します。物理基盤やハイパーバイザーは Google、データ/ID/構成/アクセス制御は顧客の責任で、IaaS/PaaS/SaaS で境界が変わります（マネージドほど顧客責任が減る）。さらに Sovereignty（主権） の観点で、Google が運用に関与した記録を見る Access Transparency、Google のアクセスに事前承認を要求する Access Approval があります。規制対応ではまず スコープ（対象となる Google Cloud 環境＝プロジェクト/フォルダ/データ）を特定し、技術的ニーズ（コンピュート/データ/ネットワーク/ストレージ）を整理します。「Google のアクセスを可視化＝Access Transparency」「Google のアクセスに承認を要求＝Access Approval」を結びます。
5.1.2要件のマッピング
コンプライアンス要件は、具体的な Google Cloud のサービスとセキュリティ制御 へマッピングします。例：データ分離→VPC Service Controls/ネットワークセグメンテーション、アクセス分離→IAM/最小権限/職務分掌、証跡→Cloud Audit Logs の網羅（データアクセスログ含む）、暗号化→CMEK/EKM、機微データ→Sensitive Data Protection。要件ごとに「どの制御が証拠になるか」を対応づけ、監査で提示できるようにします。「ネットワーク/アクセスのセグメンテーション＋監査ログ網羅」がマッピングの定番軸です。