EUから日本へデータを持ってくるとき、情シスが本当に困ること

Microsoft 365統合・監査ログ・権限管理の“現場のリアル”

「EUから日本にデータを移したいんだけど、M365ならすぐできますよね？」

情シス担当者なら、この一言に少し嫌な予感を覚えるかもしれません。

技術的には、メールボックスを移す、SharePointサイトを整理する、Teamsを統合する、OneDriveを移行する。たしかに作業としては可能です。

しかし、実際の現場で問題になるのは、移行そのものではありません。

問題になるのは、移行後です。

「そのデータ、いま日本の誰が見られますか？」「EU側の個人データは、どのSharePointサイトにありますか？」「外部共有リンクは残っていませんか？」「管理者がアクセスしたログは出せますか？」「監査法人に聞かれたら、証拠として何を出しますか？」

このあたりで、現場は一気にざわつきます。

本記事では、EUから日本へのデータ移転とMicrosoft 365グループウェア統合について、情シス担当者の目線で、現場の声・実例・課題・対応策を整理します。

なお、以下の「現場の声」や「実例」は、特定企業の実案件ではなく、複数の相談・支援現場でよく見られる課題をもとにした匿名化・複合化した事例です。

1. 「十分性認定があるから大丈夫ですよね？」で始まる危険な誤解

現場でよくあるのが、法務・経営側からのこの一言です。

「日本はEUの十分性認定を受けているんですよね？だったら、EUから日本にデータを移しても問題ないですよね？」

たしかに、日本はEUの十分性認定の対象国です。欧州委員会は、GDPR第45条に基づき、EU域外の国が十分なデータ保護水準を持つかを判断する制度を説明しており、日本も十分性認定の対象に含まれます。

また、日本の個人情報保護委員会も、日EU間の相互かつ円滑な個人データ移転の枠組みについて説明しています。

ただし、情シスとして強く押さえておきたいのは、次の点です。

「移転できる」ことと、「監査で説明できる」ことは別問題です。

十分性認定があるからといって、Microsoft 365上での保存場所、アクセス権、外部共有、監査ログ、証拠保全を何も設計しなくてよいわけではありません。

現場で本当に問われるのは、こういうことです。

「EUから日本に移したあと、誰が見られるのか」「その操作はログに残っているのか」「削除されたときに復元・保全できるのか」「監査時に、画面キャプチャではなく証跡として出せるのか」

つまり、EUデータ移転は、法務イベントであると同時に、M365運用設計イベントです。

2. 現場の声①：「Teamsを移しただけなのに、保全対象が多すぎる」

現場の声

「Teamsのデータを日本側に持ってきたんですが、監査で“Teamsのデータはどこに保存されていますか？”と聞かれて困りました。チャットはTeams、ファイルはSharePoint、個人チャットのファイルはOneDrive……。正直、説明する側も混乱しました。」

Teamsは、画面上は一つのアプリに見えます。しかし、実際にはExchange、SharePoint、OneDrive、Microsoft 365グループなどと連動しています。

MicrosoftのeDiscovery関連ドキュメントでも、TeamsやMicrosoft 365グループのコンテンツを保全する場合、関連するメールボックスとSharePointサイトを指定する必要があると説明されています。

さらに、Microsoft 365のeDiscoveryデータソースでは、Teamsについて、TeamsチャットやメールのExchangeメールボックス保存、チャネルやチームに関連するSharePointサイトが含まれると説明されています。

情シスが困るポイント

Teams移行でよくある落とし穴は、次のとおりです。

課題	現場で起きること
Teamsだけ見てしまう	実際にはExchange、SharePoint、OneDriveも関係する
ファイルの所在が曖昧	チャネルファイルとチャット添付ファイルの保存先が違う
eDiscovery範囲が不足	Teamsだけを対象にしたつもりで、OneDrive側を見落とす
監査説明が弱い	「Teamsにあります」としか説明できない
保全漏れ	メールボックス・サイト・OneDriveを横断して保全していない

情シス向けの対応

Teams統合時には、最低限、次の整理が必要です。

確認項目	やること
Teams一覧	EU由来データを含むチームを洗い出す
関連SharePointサイト	各Teamsに紐づくSharePointサイトを確認
OneDrive	チャット共有ファイルの保存場所を確認
Exchange	Teamsチャット・会話履歴の保全範囲を確認
eDiscovery	Hold対象にメールボックスとSharePointサイトを含める
証跡	チーム名、所有者、メンバー、保存場所、保全状態を台帳化

現場での説明は、こう言い換えると通ります。

「Teamsの保全は、Teamsアプリだけでは完結しません。関連するExchange、SharePoint、OneDriveまで含めて、保全範囲を設計します。」

3. 現場の声②：「ログはあるはず、が一番怖い」

現場の声

「監査法人から“このファイルを誰がダウンロードしたか分かりますか？”と聞かれました。上司は“Microsoft 365だからログは残っているだろう”と言うんですが、実際に探したら保持期間やライセンスの制約があって、必要な期間のログが出せませんでした。」

これは本当に多いです。

Microsoft 365を使っていると、つい「ログは残っている」と思いがちです。しかし、監査対応では、ログがあるかどうかではなく、必要な期間・必要な粒度・必要な形式で取り出せるかが重要です。

Microsoft Purviewの監査ログ保持ポリシーでは、監査ログを最大10年まで保持できると説明されています。一方で、180日を超えて最大1年、さらに10年保持する場合には、Microsoft 365 E5、Office 365 E5、Microsoft Purview関連ライセンス、10年保持アドオンなどのライセンス要件が示されています。

情シスが困るポイント

監査ログで詰まるポイントは、だいたい決まっています。

よくある詰まり	何が起きるか
保持期間を決めていない	半年前・1年前の操作ログが出せない
ライセンスを見ていない	Premium前提の機能を使えると思い込む
対象サービスが曖昧	Exchangeだけ見てSharePoint/OneDriveを見落とす
管理者操作を見ていない	権限変更や保持ポリシー変更が追えない
エクスポート手順がない	監査時に誰がログを出すか決まっていない
ログ検索権限が広すぎる	ログを見る人の操作自体が統制されていない

情シス向けの対応

EU由来データを日本に移すなら、監査ログについては、次のように設計します。

項目	最低限の対応
保持期間	180日で足りるか、1年・3年・5年・10年が必要か判断
ライセンス	E3/E5/Purviewアドオンの差分を確認
対象操作	閲覧、DL、削除、共有、権限変更、管理者操作
対象サービス	Entra ID、Exchange、SharePoint、OneDrive、Teams、Purview
ログ取得者	誰が検索し、誰が承認し、誰が出力するか
証跡保存	CSV、検索条件、出力日時、担当者、承認記録を残す

現場で一番危ない言葉は、これです。

「たぶんログは残っています」

監査対応では、これは使えません。

正しくは、こうです。

「この操作については、Microsoft Purview Auditで取得対象です。保持期間は〇年に設定しています。検索権限者は〇名に限定し、出力時には承認記録を残します。」

4. 現場の声③：「グローバル管理者、多すぎませんか？」

現場の声

「監査で“Global Administratorは何人いますか？”と聞かれて確認したら、退職者、旧ベンダー、検証用アカウントまで残っていました。しかも常時権限付与。正直、冷や汗が出ました。」

EUデータを日本側で扱う場合、最も監査で突っ込まれやすいのが管理者権限です。

「誰が一般ユーザーとして見られるか」だけではありません。「誰が管理者として見られるか」も問われます。

MicrosoftのEntra IDロールに関するベストプラクティスでは、最小権限の原則、PIMによるジャストインタイムアクセス、管理者へのMFA、有効なアクセスレビュー、Global Administrator数の制限などが示されています。

また、Microsoft Entra Privileged Identity Management、いわゆるPIMは、重要リソースへのアクセスを管理・制御・監視するためのサービスで、時間ベース・承認ベースのロール有効化により、過剰または不要な特権アクセスのリスクを減らす機能として説明されています。

情シスが困るポイント

管理者権限でよくある課題は、次のとおりです。

課題	現場の実態
Global Adminが多い	「昔からの運用」で増え続けている
常時管理者	必要なときだけ昇格する仕組みがない
ベンダー権限が残る	移行後も委託先アカウントが有効
共有管理者アカウント	誰が操作したか分からない
MFA未徹底	管理者だけ例外扱いになっている
承認理由がない	なぜ権限を使ったか説明できない

情シス向けの対応

EUデータ移転前に、必ず以下をやるべきです。

対応	内容
管理者棚卸し	Global Admin、Exchange Admin、SharePoint Admin、Teams Admin、Compliance Adminを確認
常時権限の削減	PIMで一時昇格制にする
MFA必須化	管理者は例外なくMFA対象にする
共有アカウント禁止	個人IDで操作させる
ベンダー権限期限	移行作業後に自動失効させる
承認フロー	権限昇格時に理由・承認者・時間を記録する
アクセスレビュー	四半期または半期で権限を見直す

監査で聞かれたときの理想回答は、こうです。

「管理者権限は常時付与していません。必要時のみPIMで昇格し、MFA、理由入力、承認、時間制限をかけています。権限利用履歴は監査ログで確認できます。」

この回答ができるかどうかで、監査側の印象は大きく変わります。

5. 現場の声④：「外部共有リンクがどこにあるか分からない」

現場の声

「欧州拠点の資料を日本側SharePointに移したあと、“外部共有されていないですよね？”と聞かれました。でも、過去に誰がゲストを招待したか、誰がリンクを作ったか、すぐには分かりませんでした。」

SharePointとOneDriveの外部共有は、便利な一方で、監査では大きなリスクになります。

Microsoftは、SharePoint管理者がMicrosoft 365でSharePointおよびOneDriveの組織レベルの共有設定を変更でき、必要に応じて特定サイトでより制限的な設定を構成できると説明しています。

また、Microsoft 365監査ログの共有監査を使うことで、組織外ユーザーと共有されたリソースの一覧を作成できると説明されています。

情シスが困るポイント

外部共有で詰まるのは、次のパターンです。

課題	現場の実態
Anyoneリンクが残っている	昔のプロジェクトで作った匿名リンクが残存
ゲストが多すぎる	取引先、退職者、旧ベンダーが残る
サイト単位で設定が違う	組織設定とサイト設定が不一致
所有者任せ	サイトオーナーが外部共有を自由に許可
棚卸し頻度がない	共有状態を誰も定期確認していない
監査ログ検索が属人化	共有履歴を出せる人が限られている

情シス向けの対応

EU由来データを扱うサイトでは、外部共有は特に厳しく見るべきです。

対応	内容
サイト分類	EUデータを含むSharePointサイトを特定
外部共有制限	EUデータサイトは原則ゲスト限定または外部共有禁止
Anyoneリンク禁止	匿名リンクを禁止または例外承認制
共有リンク棚卸し	既存リンクを定期確認
ゲスト棚卸し	Entra IDのゲストユーザーを確認
アクセスレビュー	外部ゲストの定期レビューを設定
共有監査	Microsoft 365監査ログで外部共有履歴を確認

Microsoft Entraでは、Microsoft 365グループ内のゲストユーザーについて、グループごとのレビューや、全Microsoft 365グループにまたがる自動・定期的なアクセスレビューを設定できると説明されています。

現場では、こう言える状態を作るべきです。

「EU由来データを含むサイトでは、外部共有設定を制限しています。ゲストユーザーは定期的にアクセスレビューし、共有リンクの作成・変更は監査ログで確認できます。」

6. 現場の声⑤：「秘密度ラベルを作ったけど、誰も使っていない」

現場の声

「EU Personal Dataというラベルを作ったんですが、現場のユーザーが付けてくれません。結局、どれがEU由来データなのか分からないままです。」

これはよくあります。

ラベルは作るだけでは意味がありません。運用に乗って初めて意味があります。

Microsoft Purviewの秘密度ラベルは、組織のデータを分類・保護するための機能です。

さらに、Teams、Microsoft 365グループ、SharePointサイトなどのコラボレーションワークスペースに秘密度ラベルを適用することで、グループやサイトの分類・保護にも使えます。

情シスが困るポイント

秘密度ラベルで失敗する原因は、だいたい次のどれかです。

課題	現場の実態
ラベルが多すぎる	ユーザーが選べない
名前が法務用語	現場が意味を理解できない
自動適用がない	すべて人力でラベル付け
サイト単位の分類がない	ファイル単位だけで運用しようとする
教育不足	なぜ付けるのか伝わっていない
例外処理がない	誤ラベル時の修正ルールがない

情シス向けの対応

EUデータ向けには、シンプルなラベル設計から始めるのが現実的です。

ラベル	用途
Internal	通常の社内情報
Confidential	顧客情報、契約、重要業務情報
EU Personal Data	EU由来の個人データ
Restricted	人事、役員、係争、要配慮情報

現場に説明するときは、こう言います。

「ラベルは法務のためではなく、誰が見てよいか、共有してよいか、監査で説明できるかを判断するための目印です。」

ラベル運用で重要なのは、最初から完璧を狙わないことです。

まずは、EU由来データを含むSharePointサイトやTeamsに対して、サイト単位・チーム単位で分類する。その後、重要ファイルにラベルを広げる。この順番の方が、現場では定着しやすいです。

7. 現場の声⑥：「DLPを入れたら業務が止まりました」

現場の声

「EU個人データの持ち出しを止めるためにDLPを入れたら、営業資料の共有まで止まって、現場からクレームが来ました。結局、ポリシーを緩めすぎて意味がなくなりました。」

DLPは強力ですが、いきなり厳格に適用すると、業務影響が大きくなります。

Microsoft Purview DLPでは、Microsoft Teamsのチャネルやチャットで機密情報を共有することを防ぐポリシーを定義できます。

また、Teams上に表示されるファイルの保護では、SharePointとOneDriveをDLPポリシーに含める必要があると説明されています。

情シスが困るポイント

DLPで失敗するパターンは、次のとおりです。

課題	現場で起きること
いきなりブロック	業務停止・問い合わせ増加
検知条件が粗い	誤検知が多く、現場が無視する
例外申請がない	正当な業務共有まで止まる
法務と情シスの認識ズレ	何を止めるべきか決まっていない
レポートを見ていない	検知後の改善がない
Teamsだけ対象	実際にはSharePoint/OneDrive側も必要

情シス向けの対応

DLPは段階導入が現実的です。

フェーズ	対応
監視のみ	まずはブロックせず検知状況を見る
警告表示	ユーザーに注意喚起する
例外理由入力	業務上必要な共有には理由を残させる
一部ブロック	高リスク情報だけ停止
本格適用	法務・現場合意後に厳格化

現場では、こう説明すると通りやすいです。

「DLPは最初から止めるための仕組みではありません。まず、どこで危ない共有が起きているかを見るために使います。そのうえで、止める範囲を業務影響とセットで決めます。」

8. 現場の声⑦：「移行ベンダーの作業ログが監査資料に使えない」

現場の声

「移行作業はベンダーに任せました。でも監査で“誰が、いつ、どのデータを、どこへ移したか”を聞かれたとき、ベンダーの作業報告書には“移行完了”としか書いてありませんでした。」

これは、技術移行プロジェクトではよくあります。

ベンダーの作業報告書は、プロジェクト完了確認としては十分でも、監査証跡としては不十分なことがあります。

情シスが困るポイント

課題	現場で起きること
移行対象一覧が粗い	どのメールボックス・サイトを移したか分からない
作業者IDが不明	誰が実行したか追えない
失敗ログがない	再実行・例外処理が説明できない
承認記録がない	誰が移行を許可したか不明
移行後確認がない	権限・共有設定が変わったか分からない
監査用の粒度でない	「完了」だけでは証跡にならない

情シス向けの対応

移行ベンダーには、最初から監査証跡として使える成果物を求めるべきです。

成果物	必要な内容
移行対象一覧	メールボックス、サイト、Teams、OneDrive、グループ
作業ログ	実施日時、作業者、使用ツール、対象件数
エラーログ	失敗理由、再実行、未移行データ
権限差分	移行前後のアクセス権
外部共有差分	移行前後の共有リンク・ゲスト
完了確認	情シス、法務、業務部門の確認記録
例外一覧	残置データ、削除不可データ、要追加対応

RFPや見積段階で、次の一文を入れておくと有効です。

本移行作業では、監査対応を前提として、移行対象、作業者、作業日時、移行結果、失敗・再実行履歴、権限差分、外部共有差分を証跡として提出すること。

9. 情シスが最低限そろえるべき「監査保全セット」

EUから日本へのデータ移転で、情シスが最低限そろえるべきものは、次の7点です。

No	監査保全セット	内容
1	データ移転台帳	どのデータを、どこからどこへ移したか
2	M365保存場所一覧	Exchange、SharePoint、OneDrive、Teamsの所在
3	管理者権限台帳	誰がどの管理者ロールを持つか
4	外部共有一覧	ゲスト、共有リンク、外部公開範囲
5	監査ログ設計	保持期間、対象操作、検索権限、出力手順
6	保全手順	eDiscovery Hold、Retention、Legal Hold相当運用
7	移行証跡	移行ログ、承認記録、例外記録、完了確認

情シスとしては、これを「監査対応のための余計な書類」と考えない方がよいです。

むしろ、これは自分たちを守るための証拠です。

障害、情報漏えい、監査指摘、内部通報、退職者トラブル、ベンダー作業ミス。何か起きたときに、情シスが「やるべきことをやっていた」と説明できる材料になります。

10. レベル別に考える：全部を一気にやらない

現実には、すべての企業がいきなり完璧な監査保全を作れるわけではありません。

そこで、情シス向けにはレベル別に整理するのが有効です。

Lv1：まず“見える化”する

対象は、基準がまだない企業です。

やることは、次の5つです。

• EU由来データがどこにあるか確認する

• 管理者権限を棚卸しする

• 外部共有を確認する

• Microsoft 365監査ログの状態を確認する

• 移行作業ログと承認記録を残す

このレベルのゴールは、「聞かれても何も分からない」状態を脱することです。

Lv2：監査に出せる証跡を作る

対象は、親会社、監査法人、取引先から説明を求められる企業です。

やることは、次のとおりです。

• Purview Auditの保持期間を設計する

• PIMで管理者権限を一時昇格制にする

• 条件付きアクセスを強化する

• 秘密度ラベルを設計する

• DLPを監視モードから始める

• eDiscovery Holdの運用手順を作る

• ゲストユーザーのアクセスレビューを行う

このレベルのゴールは、「やっています」ではなく「証拠を出せます」と言える状態です。

Lv3：EU本社・当局・高リスク監査に耐える

対象は、欧州本社、金融、医療、人事データ、重要顧客データ、係争・M&Aがある企業です。

やることは、次のとおりです。

• Multi-Geo / PDLを設計する

• EU由来データ専用のラベルを運用する

• 長期監査ログ保持を検討する

• eDiscoveryケース運用を整備する

• 法務・情シス・監査部門で証跡運用を統一する

• 委託先・再委託先のアクセスを管理する

• 監査回答テンプレートを作る

Microsoft 365 Multi-Geoは、Exchange Online、SharePoint/OneDrive、Microsoft TeamsなどのMicrosoft 365 Core Servicesについて、ユーザーレベルで対象データを管理・保存する機能として説明されています。

また、OneDriveとSharePointのMulti-Geo機能では、SharePointチームサイトやMicrosoft 365グループメールボックスなどの共有リソースを指定された地理的場所に保存・制御でき、各ユーザー、グループメールボックス、SharePointサイトにはPDL、つまり優先データ所在地があると説明されています。

このレベルのゴールは、契約・規程・M365設定・監査ログがつながっている状態です。

11. 情シス担当者が会議で使える説明テンプレート

法務・経営・監査部門との会議では、技術用語を並べるより、次のように説明すると伝わりやすくなります。

説明テンプレート1：監査ログ

Microsoft 365には監査ログ機能がありますが、保持期間や検索範囲はライセンスと設定に依存します。EU由来データを扱う場合、何年分のログを保持するかを先に決める必要があります。

説明テンプレート2：管理者権限

管理者であっても、常時すべてを見られる状態はリスクです。必要なときだけ権限を昇格し、MFA、承認、理由入力、時間制限をかける設計にします。

説明テンプレート3：Teams

TeamsのデータはTeamsだけで完結しません。チャット、ファイル、グループ、メールボックス、SharePoint、OneDriveを横断して保全範囲を設計する必要があります。

説明テンプレート4：外部共有

EU由来データを含むサイトでは、外部共有設定を通常サイトより厳しくします。ゲスト、共有リンク、アクセスレビューをセットで管理します。

説明テンプレート5：法務との連携

法務上の移転根拠だけでは、監査証跡としては足りません。実際のM365設定、ログ、権限、保全手順まで合わせて説明できる状態にします。

12. 情シスが一人で抱え込まないために

EUから日本へのデータ移転は、情シスだけで完結する仕事ではありません。

関係者は多いです。

関係者	役割
情シス	M365設定、ログ、権限、移行、保全
法務	移転根拠、契約、規程、補完的ルール
監査部門	証跡確認、運用評価
業務部門	対象データ、利用目的、例外判断
経営層	リスク許容度、投資判断
ベンダー	移行作業、設定支援、ログ提出
DPO/個人情報管理部門	個人データ管理、本人対応、漏えい対応

情シスがやるべきことは、全部を一人で判断することではありません。

むしろ、情シスがやるべきなのは、こういう整理です。

「技術的には可能です。ただし、監査で説明するには、ログ保持、権限管理、外部共有、証拠保全、法務根拠をセットで決める必要があります。」

この一言が言えるだけで、プロジェクトの位置づけは大きく変わります。

13. 山崎行政書士事務所ができること

山崎行政書士事務所は、EUから日本へのデータ移転を、単なる法律論だけでなく、Microsoft 365の実務運用・監査保全まで見据えて支援します。

多くの企業では、法務と情シスの間にギャップがあります。

法務はこう言います。

「GDPRと個人情報保護法上、説明できるようにしてください。」

情シスはこう思います。

「それをM365のどの設定に落とせばいいんですか？」

この間を埋めるのが、山崎行政書士事務所の役割です。

支援メニュー例

支援内容	情シスにとってのメリット
EU→日本データ移転診断	何をどこまで対応すべきか整理できる
M365監査保全チェック	Audit、Purview、Entra ID、Teams、SharePointの抜け漏れを確認
管理者権限レビュー	Global Adminやベンダー権限のリスクを見える化
外部共有レビュー	ゲスト、共有リンク、匿名共有のリスクを整理
監査ログ設計支援	保持期間、出力手順、証跡保管を決められる
Purview運用設計	ラベル、DLP、eDiscovery、Retentionを実務に落とせる
規程・台帳整備	技術設定を法務文書・監査資料に変換できる
ベンダー連携支援	移行会社・SIerに監査証跡を求める要件を作れる

山崎行政書士事務所は、情シス担当者を責めるためではなく、情シス担当者が監査・法務・経営に対して説明できる状態を作るために支援します。

まとめ：EUデータ移転は「移行」ではなく「証明」のプロジェクト

EUから日本にデータを持ってくることは、技術的にはできます。

しかし、情シスが本当に備えるべきなのは、移行作業そのものではありません。

本当に備えるべきなのは、次の問いです。

どのデータを移したのか。どこに保存されているのか。誰が見られるのか。誰が管理者なのか。外部共有は残っていないか。ログは何年残るのか。監査時に証跡として出せるのか。インシデント時に保全できるのか。

これらに答えられて初めて、EUデータ移転は「完了した」と言えます。

Microsoft 365統合は、単なるグループウェア移行ではありません。監査ログ、権限管理、外部共有、証拠保全、法務根拠をつなぐプロジェクトです。

山崎行政書士事務所は、EUデータ移転を「法律上できる」で終わらせません。

情シスが監査で困らない。法務が説明責任を果たせる。経営がリスクを判断できる。

そのために、Microsoft 365と企業法務の両面から、実務に耐える監査保全を設計します。