日EU“通訳”としてのクラウド越境コンプライアンス

― SCC/TIAを「書類」から「構成」と「証跡」に変換する実務設計 ―

EU（フランスCNIL、イタリアGarante等）と日本企業の間で、Microsoft Azure / Microsoft 365 を使う越境案件が増えるほど、現場で起きるのはいつも同じ構図です。

• 法務は「SCCでOK」と言う

• 情シスは「構成はEUリージョンで組んだ」と言う

• 監査は「じゃあ“なぜ同等性が担保できるのか”証跡で示して」と言う

• 結果、誰も“説明”を完遂できない

この“説明崩壊”の原因は、単純に知識不足ではありません。条文（SCC/TIA）と、クラウド構成（Azure/M365）と、運用証跡（ログ・台帳）が、同じ座標系に落ちていないのが根本原因です。

本稿では、山崎行政書士事務所が担うべき立ち位置を「越境コンプライアンス通訳（Trans-Jurisdiction Compliance Interpreter）」と定義し、EUの期待値（SCC/TIA/EDPB）を、日本の実務（個人情報保護法・委託管理・運用慣行）とAzureのパラメータへ翻訳し、監査で“即答できる証跡”まで設計する方法を、実務テンプレ込みで解説します。

1. まず押さえる「EU側が本当に見ている基準線」

1-1. SCCは“契約書”ではなく「運用要件の定義書」

EU標準契約条項（SCC）は、条文の締結だけで終わりません。SCCの構造は、本文よりも Annex（付属書）、とりわけ Annex II（技術的・組織的対策） が実装の中心です。

ここが空疎だと、監査で必ず詰みます。なぜなら、EUの監査が見たいのは「条文を読んだこと」ではなく、

• どの制御を

• 誰が

• どの頻度で

• どのログ（証跡）で示すのか、だからです。

現場の落とし穴Annex IIが「ISO27001準拠」などの抽象語で埋まっていると、監査で即死します。SCCは“運用要件の定義書”であり、実装と証跡が書かれて初めて機能します。

1-2. TIAはEDPBの「6ステップ」が基本形

Schrems II以降、SCCを使うなら TIA（Transfer Impact Assessment） が前提になりました。TIAの作り方は、EDPBが「6ステップ」で提示しています。

1. 移転（transfer）の把握

2. 移転ツール（SCC等）の確定

3. 第三国法制・実務の評価

4. 補完措置（supplementary measures）の設計

5. 手続・形式要件

6. 再評価（re-evaluation）

この枠組みを外すと、文書は作れても、監査に耐える一貫性が出ません。

1-3. “国際移転”の線引きは「保管場所だけ」で決まらない

現場では「EUリージョンに置いたから越境じゃない」という会話が起きがちです。しかしEU側の線引きは、データの保管場所だけでなく、アクセス経路（運用・サポート・委託）を含めて判断します。

つまり、

• 物理的保管はEUでも

• サポートがEU外からアクセスできる

• 下請けがEU外にいる

• 運用者の権限がEU外で行使される――こうした要素があると、移転・開示の論点は残ります。

監査の急所「保管場所」ではなく「アクセス可能性」が問われます。データは動いていなくても、“見える”設計なら実務上のリスクは残る、という思想です。

1-4. EU→日本は適正性があるが「補則」で縛られる

EU→日本の移転は、EU側の適正性（adequacy）枠組みで通しやすい一方、日本側には 補則（Supplementary Rules） が乗ります。

ここを軽視すると、「日本は適正性だから大丈夫」という説明が、監査で崩れます。適正性は“入口”であり、実務は“補則＋運用”で固める必要があります。

2. なぜ“通訳”が必要になるのか：条文と構成の間の説明不能領域

越境案件で説明が崩れるのは、次の3層が分断されるからです。

1. 契約層：SCC / DPA / SCC Annex

2. 技術層：Azure/M365の設定（ネットワーク・鍵・権限・ログ）

3. 運用層：実際に誰が、どう承認し、どう変更し、どう証跡を残すか

EU監査で問われるのは、契約の有無ではなく、**“同等性（essentially equivalent）を実装で担保できているか”**です。

だから山崎行政書士事務所が提供すべき価値は、書類作成ではなく、

条文 → 実装要件 → 証跡を相互変換して説明責任を通す「通訳」

この一点に集約されます。

3. 日EU“通訳”マッピング：同じ意味を別の言語で言う

EU監査の質問を、そのまま日本企業の現場に投げると誤解されます。そこで「問い」を分解し、日本の運用・Azureの設定に翻訳します。

3-1. EU側の典型質問 → 日本側の翻訳先（例）

Q：第三国当局アクセスのリスクをどう評価した？→ A（翻訳）：委託先・運用者・サポートのアクセス経路と、法的強制力が及ぶ範囲を棚卸しし、鍵の支配権・分離・最小権限・監査証跡で“実害”を起こせない設計にしている。

Q：補完措置は技術的に実効か？→ A（翻訳）：暗号鍵の支配権が（少なくとも運用委託先やサポート事業者ではなく）自社側にあり、サポート経路でも復号・平文閲覧ができない、または例外時の手続・記録がある。

Q：Annex IIの対策はどの証跡で示す？→ A（翻訳）：PIM昇格ログ、Key Vault操作ログ、条件付きアクセスの適用結果、監査ログ保持設定、変更管理台帳で“一発回答”できる。

4. 実務テンプレ：TIA（6ステップ）をAzure案件に落とす

ここからは、EDPBの6ステップをAzure/M365の実務に直結する形に変換します。

Step 1：移転（transfer）の把握（データ流通図の作成）

最低限、以下を一枚絵にします。

• データ類型（個人データ、特別カテゴリ、認証ログ等）

• データ主体（EU居住者、従業員、顧客等）

• Exporter / Importer / Sub-processor（再委託）

• 保管リージョン・処理リージョン

• 運用アクセス（サポート、SIer、クラウド事業者の支援経路）

ポイント：「保管はEU」でも、運用・サポートアクセスがEU外なら論点は残ります。この棚卸が弱いと、TIAの残り全部が空転します。

Step 2：移転ツール（SCCか適正性か）を確定

• 適正性で進めるなら「補則」も含めて整理

• SCCで進めるなら、モジュール選定（C→P、P→P等）とAnnexの具体化

この段階で、契約の“型”を決めておくと、後工程（実装・証跡）がスムーズになります。

Step 3：第三国法制・当局実務の評価（文章の型を固定する）

ここは文章量が重く、属人化しやすいので、テンプレ化します。

• 強制開示の制度（一般論）

• 実務上の発動頻度や透明性（公開情報の範囲）

• 救済手段（裁判・行政救済）

• クラウド事業者への義務（保持命令等）の有無

重要なのは「制度があるか」だけではなく、実務上どの程度現実的なリスクかを言語化することです。そしてその評価が、Step 4の補完措置に接続している必要があります。

Step 4：補完措置（技術・契約・組織）を“実装要件”に変換

補完措置は、一般に「技術」「契約」「組織」に分けて整理します。本稿では、そのうち最も誤魔化せない「技術」を中心に、Azure設定へ落とします（次章）。

Step 5：手続・形式要件（“更新できる契約”にする）

• SCC締結、DPA整備

• Annex更新ルール（構成変更時に必ず更新）

• 例外時の承認・記録・保管先

監査は「あるか」ではなく「回るか」を見ます。だから最初から、更新前提の仕組みにします。

Step 6：再評価（Re-evaluation）を運用に埋め込む

TIAが一度作って放置になると、必ず事故ります。再評価は“イベント駆動”で回すと現場に馴染みます。

再評価トリガ（実務で効くもの）

• ベンダー追加・再委託追加

• リージョン変更、ログ保持変更、鍵管理変更

• サポート契約変更

• 重大インシデント、法改正、判例・当局見解の更新

5. SCC Annex II を“Azure設定パラメータ”まで落とす例

Annex IIは「技術的・組織的対策」を列挙する場所です。ここを抽象語で逃げず、Azureの設定・運用証跡まで落とします。

5-1. 暗号化と「鍵の支配権」

EU側の関心：復号が第三国の強制で現実化しない（少なくとも実害が起きない）設計かAzureへの翻訳（例）

• Customer-Managed Key（自社鍵）を採用

• Key Vaultのアクセス制御（RBAC、特権分離）

• 鍵ローテーションの運用（期限・手順・記録）

• 例外時の復号プロセス（誰が承認し、何を残すか）

監査で見せる証跡（例）

• Key Vaultのアクセス権一覧（ロール・対象者）

• PIM昇格ログ（誰がいつ特権を行使したか）

• 鍵操作ログ（作成・更新・ローテ）

• 鍵台帳（鍵ID、用途、責任者、更新履歴）

5-2. 特権アクセス最小化（“恒常管理者”を潰す）

Azureへの翻訳（例）

• Entra ID PIMでJIT（必要時のみ昇格）

• 条件付きアクセス（管理者は強制MFA、端末準拠、場所制限）

• 定期Access Review（権限棚卸）

監査で見せる証跡（例）

• PIM設定（常時割当なし、承認必須、時間制限）

• 条件付きアクセスのポリシー定義と適用結果

• Access Reviewの結果（是正履歴）

5-3. ログの完全性と保持（“後から追えない”を潰す）

Azureへの翻訳（例）

• Azure Activity Log / M365監査ログの集中保管

• Sentinel/Log Analytics等で保持期間を固定化

• 改ざん耐性（書き込み権限の分離、保護機構）

監査で見せる証跡（例）

• ログ保持設定の画面・設定値

• ログ閲覧権限のロール一覧

• 代表的な監査クエリの実行結果（誰が何をしたか）

5-4. データレジデンシーと透明性（“どこまでEU内か”を説明可能にする）

EU Data Boundary等、事業者側が提供する透明性情報は、TIAの補助資料として有効です。ただし「それだけでTIAが不要」にはなりません。

本体は常に

• 自社の構成がどうなっているか

• 誰がアクセスできるか

• どう証跡で示すかです。

6. 監査・取引先質問に“即答”する Evidence Navigation Guide

監査対応で最も差が出るのはここです。質問に“文章で答える”のではなく、見せる証跡を決めておく。

6-1. 「質問 → 見せる証跡 → 合格ライン」の型（例）

Q：鍵は誰が管理し、復号は誰ができる？

• 見せる：Key Vaultアクセス権、PIM昇格ログ、鍵操作ログ、鍵台帳

• 合格ライン：運用委託先やサポートで復号できない／できるなら例外プロセスと記録がある

Q：管理者が勝手にアクセスできない仕組みは？

• 見せる：PIM設定、条件付きアクセス、監査ログ

• 合格ライン：恒常権限なし、昇格は承認・時間制限、記録が残る

Q：データ移転の再評価はいつやる？

• 見せる：再評価トリガ表、変更管理台帳、Annex更新履歴

• 合格ライン：構成変更が起きたらTIA/SCC付属書が更新される運用鎖がある

7. “一枚マトリクス”で、条文・構成・証跡を同じ座標に置く

EU期待値	日本側の翻訳	Azure/M365実装	監査で見せる証跡
Annex II：暗号化	鍵の支配権を保持	CMK＋Key Vault RBAC＋特権分離	鍵台帳、鍵操作ログ、PIMログ
アクセス最小化	恒常権限を排除	PIM/JIT＋条件付きアクセス	ポリシー設定、昇格履歴
追跡性	いつ誰が何をしたか	監査ログ集中管理	保持設定、検索結果
再評価	変化を監視	変更検知→台帳更新→Annex更新	変更申請→承認→更新証跡

この一枚があると、監査での“質問攻め”が「確認作業」になります。逆にこれがないと、監査は「想起ゲーム」になり、現場が疲弊します。

8. 90日で“監査対応まで”持っていく進め方（現場型）

• Day 1–14：データ流通図、再委託棚卸、国際移転該当性判定

• Day 15–45：TIAドラフト（6ステップ準拠）＋SCC/適正性の整理

• Day 46–75：Annex IIをAzure実装要件へ変換、ログ・台帳の証跡設計

• Day 76–90：監査想定問答（Evidence Navigation Guide）＋経営向け要約

9. 山崎行政書士事務所としての提供物（商品設計）

9-1. TIAワークブック

• データ流通図

• 第三国リスク評価テンプレ

• 補完措置の実装要件

• 再評価トリガと運用ルール

9-2. SCCパッケージ

• モジュール選定表

• Annex II（技術的措置）をAzure設定へ落とした文面

• サブプロセッサ更新ルール（Annex III運用）

9-3. 監査即答キット

• 想定問答集

• 証跡ナビ（どの画面/ログを出すか）

• 変更管理→Annex更新→証跡保管の運用鎖

10. よくある失敗と、避け方

失敗1：SCCを締結して満足する→ Annex IIが抽象語だと監査で敗北します。SCCは運用要件です。

失敗2：EUリージョンに置いたから安心する→ 重要なのは保管場所ではなくアクセス可能性です。委託・サポート・運用を棚卸します。

失敗3：TIAが一度作って放置になる→ 再評価トリガを運用に埋め込み、構成変更と連動して更新します。

結論：条文を“構成”へ、構成を“証跡”へ、証跡を“説明責任”へ

SCC/TIAは、書類で勝つゲームではありません。構成と運用で“同等性”を担保し、それを証跡で即答するゲームです。

山崎行政書士事務所が担うべき役割はここです。

Trans-Jurisdiction Compliance Interpreter「条文を設計へ。設計を監査証跡へ。そして説明責任へ。」

参照根拠

• EU標準契約条項（SCC）2021年版（欧州委員会 決定）

• EDPB Recommendations 01/2020（補完措置・TIA 6ステップ）

• EDPB Guidelines 05/2021（国際移転の概念、Art.3とChapter Vの関係）

• EU→日本の適正性決定（2019）および補則（Supplementary Rules）

• 各監督機関のTIA関連ガイダンス（例：CNIL）