Microsoft 365 Multi-Geoの要点は、1つのMicrosoft 365テナントを維持したまま、ユーザーや共有リソースのデータ保存先を複数の地理的リージョンに分けられることです。海外拠点、法規制、顧客契約、データ所在地要件に対応するための機能であり、単なるパフォーマンス改善機能ではありません。管理者が最初に確認すべきなのは、対象ライセンス、Preferred Data Location（PDL）、SharePoint/OneDriveの移行、TeamsやCopilotの保存先、eDiscoveryと検索の挙動です。Microsoft Learnの公式情報では、Multi-GeoはExchange Online、SharePoint/OneDrive、Microsoft Teams、Microsoft 365 Copilot、Copilot ChatなどのMicrosoft 365 Core Servicesを対象に、ユーザー単位または共有リソース単位でデータ所在地を制御する機能として整理されています。(Microsoft Learn)
Microsoft 365 Multi-Geoで何が変わるのか
Microsoft 365 Multi-Geoを導入すると、Microsoft 365の管理単位が「国や地域ごとの複数テナント」ではなく、単一テナント内の複数Geography管理に変わります。つまり、ID、グループ、組織内共有の基本設計は1つのテナントに集約しつつ、データの保存先だけを拠点やユーザー属性に合わせて分けられます。
特に重要なのは、次の4点です。
| 確認ポイント | 管理者への影響 |
|---|---|
| 対象サービス | Exchange Online、SharePoint/OneDrive、Teams、Microsoft 365 Copilot、Copilot ChatなどがMulti-Geo構成の対象 |
| ライセンス | 対象ユーザーの5%以上のMulti-Geoライセンスが必要。サテライトGeographyに配置するユーザーごとにライセンスが必要 |
| PDL | ユーザーやグループの保存先を決める中心設定。未設定または無効な値の場合、Primary Provisioned Geographyに配置される |
| 移行方式 | Exchange OnlineとTeamsはPDL変更後に移行キューへ入るが、既存のOneDriveは自動移行されない |
Multi-Geoは、Primary Provisioned Geographyと1つ以上のSatellite Geographyで構成され、Geography、ユーザー、グループ情報はMicrosoft Entra IDを中心に管理されます。これにより、データ保存先を分けても、組織内の共有やコラボレーション体験は単一テナントとして維持されます。(Microsoft Learn)
対象になる組織と、導入しない方がよいケース
Microsoft 365 Multi-Geoは、グローバル企業や規制産業向けの機能です。たとえば、日本、EU、米国、英国などに拠点があり、各地域のユーザーのメール、OneDrive、Teamsチャット、Copilotの対話履歴を特定地域に保存したい場合に有効です。
導入を検討すべきケース
| ケース | 具体例 |
|---|---|
| データ所在地要件がある | EU拠点のユーザーデータを欧州に、日本拠点のデータを日本に保存したい |
| 複数国の監査・契約要件に対応する | 顧客契約で「特定地域内での保存」を求められる |
| 複数テナント管理を避けたい | 国別テナントを増やさず、IDと管理を1テナントに集約したい |
| Copilot利用時のデータ所在地も整理したい | Copilot/Copilot Chatのプロンプトや応答などの対話コンテンツの保存先をPDLに基づいて管理したい |
導入しない方がよいケース
Multi-Geoは「海外拠点からのアクセスが遅いから入れる」という目的だけでは適していません。Microsoftは、Microsoft 365のパフォーマンスは単純にユーザーとデータセンターの距離だけで決まるものではないと説明しており、性能課題はネットワーク設計、プロキシ、名前解決、クライアント環境なども含めて切り分ける必要があります。(Microsoft Learn)
また、Small Business製品は対象プランの要素を含んでいてもMulti-Geoの対象外とされています。ライセンス要件や契約チャネルを満たせない場合は、Advanced Data Residency（ADR）やProduct Termsによるデータ所在地コミットメントと比較して判断するのが現実的です。(Microsoft Learn)
ライセンスと契約で確認すべきこと
Microsoft 365 Multi-Geoはアドオンライセンスとして提供されます。公式情報では、Microsoft 365 F1/F3/E3/E5/E7、Office 365 F3/E1/E3/E5、Exchange Online Plan 1/2、OneDrive Plan 1/2、SharePoint Plan 1/2、Microsoft Teams Enterprise/EEA/Essentialsなどが対象として示されています。(Microsoft Learn)
管理者が特に見落としやすいのは、次の条件です。
| 項目 | 確認内容 |
|---|---|
| 最小購入数 | Enterprise Agreementでは、対象Microsoft 365ユーザー総数の5%以上のMulti-Geoライセンスが必要 |
| CSPの場合 | CSPパートナーも、顧客の対象ユーザー総数の5%以上を購入・割り当てる必要がある |
| ユーザー単位 | Satellite GeographyにホストするユーザーごとにMulti-Geoライセンスが必要 |
| 共有リソース | SharePointサイト、Microsoft 365グループ、共有メールボックス、Teamsチーム専用のMulti-Geoライセンスはない |
| 契約面 | Enterprise Agreement、Web Direct、CSPチャネルなどを通じてライセンス取得が必要 |
実務では、「全社員に必要か」ではなく、Satellite Geographyに配置するユーザーと、それに伴って作成・利用される共有リソースを洗い出すことが出発点です。たとえば、日本本社のテナントに対して、英国・EU・米国のユーザーだけをSatellite Geographyに配置する場合、その対象ユーザー数と5%条件の両方を満たす必要があります。
EU Data BoundaryやADRとの違いを誤解しない
Multi-Geoを購入または利用しているテナントは、EUまたはEFTAの国・地域にテナントが表示される場合でも、EU Data Boundaryの対象外とされています。また、Multi-Geoを購入または利用している顧客には、Microsoft 365管理センターのFlex routing設定が表示されません。(Microsoft Learn)
これは大きな注意点です。Multi-Geoは「複数地域にデータを置ける」機能ですが、EU Data BoundaryやADRと同じ制度ではありません。コンプライアンス資料を作成するときは、次のように分けて説明すると誤解を避けられます。
| 用語 | 目的 |
|---|---|
| Product Terms | Microsoft 365サービスごとの基本的なデータ所在地コミットメント |
| Advanced Data Residency | 対象テナント全体に対する追加のデータ所在地コミットメント |
| Microsoft 365 Multi-Geo | 単一テナント内でユーザーや共有リソースの保存先を複数Geographyへ分ける機能 |
| EU Data Boundary | EU/EFTAに関するMicrosoftのデータ境界コミットメント |
さらに、Microsoft 365管理センターのData Location Cardは、Multi-Geo利用時にSatellite Geographyの詳細までは表示せず、テナントの中央の場所に関連する情報のみを反映すると説明されています。Satellite側の確認は、サービス別の管理画面やPowerShell、Graph、移行状態の確認手順と組み合わせる必要があります。(Microsoft Learn)
PDLがMulti-Geo設計の中心になる
Microsoft 365 Multi-Geoで最も重要な設定が、Preferred Data Location（PDL）です。PDLは、ユーザーやグループ、共有リソースのデータをどのGeographyに保存するかを示す属性です。
たとえば、代表的なPDL値には次のようなものがあります。
| Geography | PDL値 |
|---|---|
| 日本 | JPN |
| 米国 | NAM |
| 英国 | GBR |
| 欧州 | EUR |
| フランス | FRA |
| ドイツ | DEU |
| アジア太平洋 | APC |
日本企業で注意したいのは、JPNとAPCを混同しないことです。日本国内保存を要件にするならJPNを検討します。一方、アジア太平洋のマクロリージョンでよいのか、国単位のLocal Region Geographyが必要なのかは、法務・セキュリティ・顧客契約の観点で決める必要があります。
PDLが未設定、または無効な値の場合、ユーザーのデータはPrimary Provisioned Geographyに配置されます。Microsoftの計画ガイドでは、新規ユーザーはMicrosoft 365ライセンスを割り当てる前にPDLを設定すると、OneDrive、Exchange Onlineメールボックス、TeamsチャットストアがそのPDLに基づいてプロビジョニングされると説明されています。一方、既存ユーザーの場合、Exchange OnlineメールボックスとTeamsチャットストアはPDL変更後に自動移行されますが、既存のOneDriveサイトは自動では移行されません。(Microsoft Learn)
クラウドのみのユーザーであれば、Microsoft Graph PowerShellでPDLを確認・更新できます。
Get-MgUser -UserId [email protected] | Format-List UserPrincipalName,PreferredDataLocation
Update-MgUser -UserId [email protected] -PreferredDataLocation JPNオンプレミスActive Directoryから同期しているユーザーは、Microsoft Graph PowerShellで直接PDLを変更するのではなく、Active Directory側の属性を設定し、Microsoft Entra Connectで同期する必要があります。(Microsoft Learn)
サービス別の影響範囲
Microsoft 365 Multi-Geoは、サービスごとに「何が保存先制御の対象か」「何が自動移行されるか」が異なります。ここを整理しないまま展開すると、メールは移動したがOneDriveが旧地域に残る、TeamsチャットとSharePointファイルの場所がずれる、といった問題が起きます。
| サービス | Multi-Geoで管理される主なデータ | 管理者が確認すべき点 |
|---|---|---|
| Exchange Online | ユーザーメールボックス、アーカイブ、共有メールボックス、Microsoft 365グループメールボックスなど | PDL変更後にメールボックス移行キューへ入る。プライマリとアーカイブを別Geographyにはできない |
| SharePoint | サイトコンテンツ、サイト内ファイル | サイト作成時のPDL、Geo Locations、サイト移動の可否を確認 |
| OneDrive | ユーザーの個人ファイル | 既存OneDriveは手動移行が必要。移行中は読み取り専用時間が発生 |
| Microsoft Teams | プライベートメッセージ、チャネルメッセージ、チャット内画像など | TeamsファイルはSharePoint/OneDrive側に保存されるため、Teamsデータとサイト移動を分けて確認 |
| Microsoft 365 Copilot / Copilot Chat | ユーザーのプロンプト、応答、根拠情報への引用などの対話コンテンツ | ユーザーまたはグループのPDLに基づいて保存先が決まる |
| eDiscovery | 調査対象の検索・エクスポート | Regionフィルター、Premium機能、調査担当者の権限設計を確認 |
Exchange Onlineでは、PreferredDataLocationがMailboxRegionに反映され、メールボックスの配置先を決めます。PDL未設定ならPrimary Provisioned Geography、PDL値が誤っている場合もPrimary Provisioned Geographyに配置されるため、PDLコードの入力ミスは移行前に必ず検出するべきです。(Microsoft Learn)
Teamsでは、ユーザーのチャットデータはユーザーPDL、チームのチャネルメッセージはMicrosoft 365グループのPDLに基づきます。グループのPDLを変更してTeamsデータを移行しても、関連するSharePointサイトやファイルは自動では移動しないため、チーム単位の展開ではSharePointサイト移動もセットで計画する必要があります。(Microsoft Learn)
Microsoft 365 CopilotとCopilot Chatでは、プロンプトや応答などの「対話コンテンツ」の保存先がPDLに基づきます。たとえば、フランスに保存されたWord文書をカナダのユーザーがCopilotで書き換える場合、元文書はフランスに残り、カナダユーザーのプロンプトと応答はカナダ側に保存される、という考え方です。(Microsoft Learn)
管理者が最初に実施すべき設定確認
Multi-Geo導入前は、いきなり全社展開せず、テストユーザーとパイロットグループで検証します。Microsoftの計画ガイドでも、テストユーザーで初期検証を行い、その後IT部門などのパイロットグループへ進める流れが推奨されています。(Microsoft Learn)
確認手順
| 順序 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | 対象ユーザーと対象地域を一覧化 | 拠点名だけで判断し、法的な保存要件を確認していない |
| 2 | Multi-Geoライセンス数を確認 | 5%条件とSatellite配置ユーザー分の両方を満たしていない |
| 3 | PDL値を設計 | JPN、APC、EURなどの意味を混同する |
| 4 | テストユーザーにPDLを設定 | ライセンス割り当て後に設定し、初期プロビジョニング先が想定と異なる |
| 5 | SharePoint/OneDriveのGeo Locationを追加 | フォールバックonmicrosoft.comドメインの確認を忘れる |
| 6 | 検索、eDiscovery、DLP、共有設定を確認 | 既存の単一Geography前提の運用ルールを流用する |
| 7 | パイロット展開 | OneDriveやSharePointサイトの読み取り専用時間をユーザーに伝えていない |
SharePointとOneDriveで特定のGeographyにデータを保存したい場合、そのGeographyを事前にSharePoint/OneDrive向けに構成する必要があります。SharePoint管理センターのGeo LocationsタブでSatellite Geographyを追加し、プロビジョニング完了後にユーザーのPDL設定へ進みます。プロビジョニングには数時間から最大72時間かかる場合があるため、移行当日に追加するのは避けるべきです。(Microsoft Learn)
また、過去にフォールバックの.onmicrosoft.comドメインを変更している場合、SharePoint URLに使われるドメインと一致する状態に戻してから最初のSatellite Geographyを作成する必要があります。これは見落とすと初期構成で詰まりやすいポイントです。(Microsoft Learn)
OneDriveとSharePoint移行の注意点
既存ユーザーのOneDriveは、PDLを変えただけでは自動移行されません。SharePoint管理者がOneDrive Geography moveを実行し、ユーザーに事前周知する必要があります。
OneDrive移行では、移行中におおむね2〜6時間の読み取り専用時間が発生します。ユーザーはファイルにアクセスできますが、編集は避けるべきです。移行完了後、OneDrive同期アプリは新しい場所を自動検出しますが、iOS版OneDriveモバイルアプリではサインアウト・サインインが必要になる場合があります。(Microsoft Learn)
SharePointサイト移動では、約4〜6時間の読み取り専用時間が発生する可能性があります。移動できるサイトには、Microsoft 365グループ接続サイト、Teamsに関連付くサイト、モダンサイト、クラシックサイト、コミュニケーションサイトなどがあります。一方、Business Connectivity Services、InfoPathフォーム、IRMテンプレートが適用されたサイトは移動対象としてサポートされません。サイトサイズは最大5TB、リスト項目数は100万未満といった条件もあります。(Microsoft Learn)
移行前のユーザー通知には、少なくとも次の内容を含めます。
- 移行開始予定時刻と想定時間
- 移行先Geographyと新しいURL
- 移行中はファイルを閉じ、編集しないこと
- 既存の権限や共有リンクは基本的に維持されること
- 移行完了後に作業を再開できること
特に役員、営業、法務、開発部門など、外部共有や共同編集が多い部門は、業務時間外または低負荷時間帯に移行するのが安全です。
検索とeDiscoveryは展開前に必ず検証する
Multi-Geo環境では、各Geographyに検索インデックスがあります。OneDrive、Delve、SharePointホーム、Search Center、SharePoint Search APIを使うカスタム検索アプリでは、複数Geographyの結果を集約できます。ただし、Search Centerは各垂直検索ごとに設定が必要であり、カスタム検索アプリではEnableMultiGeoSearch=trueやClientTypeなどの指定が必要です。(Microsoft Learn)
開発者が注意すべき点は、Document IDがGeographyをまたいで一意ではないことです。検索駆動アプリで一意性が必要な場合は、Geographyを識別するGeoLocationSourceを組み合わせて扱います。また、Multi-Geo検索は全Geographyから結果を集約するため、単一Geography検索より遅延が増える場合があります。(Microsoft Learn)
eDiscoveryでは、既定ではPrimary Provisioned Geographyのみを対象にできるケースがあります。Satellite Geographyを対象にするには、Microsoft PurviewポータルでeDiscovery Manager権限を割り当て、PowerShellでCompliance Security FilterのRegionパラメーターを設定します。1ユーザーに設定できるRegionセキュリティフィルターは1つだけです。イタリア、ニュージーランド、スペイン、スウェーデンのセキュリティフィルター利用にはeDiscoveryのPremium機能が必要とされています。(Microsoft Learn)
New-ComplianceSecurityFilter -Action All -FilterName "JPN eDiscovery Managers" -Region JPN -Users [email protected]複数地域を調査する担当者が必要な場合は、地域ごとに別アカウントを用意する設計も検討します。監査や訴訟対応の担当者だけでなく、セキュリティ運用チームにも早めに共有しておくべきポイントです。
管理センターとサービス設定で変わる運用
Microsoft 365 Multi-Geoでは、すべてが中央管理だけで完結するわけではありません。SharePoint管理センターにはGeo locationsタブがあり、Geographyごとの管理が必要です。監査ログは全Satellite Geographyを横断して確認できますが、BCS、Secure Store、AppsはSatelliteごとに個別インスタンスを持つため、SharePoint管理者が場所ごとに管理・構成する必要があります。(Microsoft Learn)
共有設定もGeography単位で管理できます。たとえば、Primary側では外部共有を許可し、特定のSatellite Geographyでは外部共有を制限するといった運用が可能です。ただし、Geography間の共有制限を細かく設定する機能として考えるのではなく、各場所のSharePoint/OneDrive共有ポリシーを個別に設計する必要があります。(Microsoft Learn)
Power AppsとPower AutomateはMulti-Geoサービスではありません。Satellite場所で作成されたPower Appsやフローも、テナントの中央または既定のエンドポイントを使うと説明されています。業務アプリ連携を含む展開では、「Microsoft 365の主要データはMulti-Geoで分けたが、周辺サービスは中央側に残る」ことを前提に、データフロー図を更新してください。(Microsoft Learn)
開発者が確認すべきポイント
Multi-Geo対応で開発者が見落としやすいのは、URL、検索、ID、権限、地域別エンドポイントです。
| 項目 | 確認内容 |
|---|---|
| SharePoint URL | Geographyごとに異なるURLになるため、固定URL前提の処理を避ける |
| 検索API | Multi-Geo検索ではEnableMultiGeoSearchとClientTypeを指定する |
| Document ID | Geographyをまたいで一意ではないため、GeoLocationSourceを組み合わせる |
| 権限 | 各GeoのルートWebサイトに必要な読み取り権限があるか確認 |
| Exchange Online PowerShell | Satellite Geographyを管理する場合、対象地域のメールボックスを示す?email=付きConnectionUriを使う |
| Graph/PowerShell | クラウドユーザーと同期ユーザーでPDL設定方法が異なる |
Exchange Onlineでは、構成済みGeographyの一覧やメールボックスの地域をPowerShellで確認できます。展開後の検証スクリプトに組み込んでおくと、PDL設定ミスや移行漏れを早期に検出できます。(Microsoft Learn)
Get-OrganizationConfig | Select -ExpandProperty AllowedMailboxRegions | Format-Table
Get-Mailbox -Identity [email protected] | Format-List Database,MailboxRegion*カスタム検索アプリでは、検索結果が部分的に返る場合や、集約結果の件数が完全ではない場合を想定してUIを設計します。検索結果ページでは500件を超えてページングできない制約もあるため、大量データを前提にした監査・レポート用途では、Geography単位での個別クエリも検討します。(Microsoft Learn)
Exchange OnlineでIn-Region Routingを使う場合の注意点
Exchange Onlineの受信メールルーティングまで地域要件に合わせたい場合は、関連機能としてMulti-Geo In-Region Routing（IRR）も確認します。IRRは、受信者の承認済みドメインを使って受信メールルーティングを制御する機能です。(Microsoft Learn)
IRRを使う場合、対象ユーザーは次の条件を満たす必要があります。
- ユーザーのプライマリメールアドレスがIRR有効ドメインに属している
- ユーザーのPreferredDataLocationがドメインのMailFlowRegionと一致している
- PDL値がMicrosoft 365 Multi-Geoでサポートされる3文字コードである
- ユーザーにMulti-Geoライセンスとメール機能を付与するライセンスがある
設定例は次のとおりです。
Set-OrganizationConfig -InRegionRoutingEnabled $true
Set-AcceptedDomain -Identity contoso.jp -MailFlowRegion JPNただし、オンプレミスExchangeからExchange Onlineへのコネクタで使う証明書やIPアドレスと、外部組織向けのインターネット送信用証明書・IPアドレスを共用している場合、メール帰属で問題が起きる可能性があります。IRRはメールフローに直結するため、DNS、MX、コネクタ、監視、障害時の切り戻し手順まで含めて検証するべきです。(Microsoft Learn)
失敗しやすいポイントと回避策
Microsoft 365 Multi-Geoの導入失敗は、機能そのものよりも「前提整理不足」で起きます。以下の表を移行前チェックリストとして使うと、初期トラブルを減らせます。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| OneDriveが期待した地域に移らない | PDL変更だけで既存OneDriveも移ると誤解した | OneDrive Geography moveを別タスクとして計画する |
| Teamsデータとファイルの場所がずれる | Teamsデータだけ移行し、SharePointサイトを移していない | チーム単位でGroup PDLとSharePointサイト移動をセット管理する |
| Satelliteで共有設定が想定と違う | 新しいSatellite Geographyが既定設定のまま | 共有、DLP、ストレージクォータ、管理者権限を地域ごとに確認する |
| eDiscoveryで結果が出ない | Regionフィルターや権限が未設定 | 調査担当者ごとにRegion、Premium要件、エクスポート先を確認する |
| PDL値の誤入力に気づかない | 手入力やCSV管理でコードを誤った | 設定前にサポートされるPDL値と照合し、設定後にPowerShellで検証する |
| Data Location Cardだけで判断する | Satellite Geographyの詳細が表示されない | サービス別管理画面、PowerShell、移行状態確認を併用する |
| パフォーマンス改善目的で導入する | データ所在地機能を性能改善機能と誤解 | まずネットワーク計画、プロキシ、DNS、Microsoft 365接続性を調査する |
導入時の実務フロー
Microsoft 365 Multi-Geoを安全に展開するには、次の順序で進めるのが現実的です。
| フェーズ | 実施内容 |
|---|---|
| 設計 | 対象国、法的要件、対象サービス、対象ユーザー、共有リソースを整理 |
| ライセンス確認 | 5%条件、Satellite配置ユーザー数、契約チャネルを確認 |
| PDL設計 | ユーザー、Microsoft 365グループ、共有リソースのPDL値を決める |
| テスト | テストユーザーでOneDrive、Exchange、Teams、検索、共有、Copilotを確認 |
| パイロット | IT部門や一部拠点で先行展開し、ヘルプデスク問い合わせを記録 |
| 移行 | OneDrive、SharePointサイト、Teams関連サイトを業務影響の少ない時間に移す |
| 運用化 | 監査、eDiscovery、DLP、共有ポリシー、ストレージクォータ、スクリプトを更新 |
最後に行うべきことは、対象ユーザー一覧とPDL一覧を作ることです。そこから、Multi-Geoライセンス数、SharePoint/OneDriveのGeo Locations、OneDrive・SharePoint移行計画、TeamsグループのPDL、Copilotの対話データ保存先、eDiscovery担当者のRegion設定を順番に確認します。Microsoft 365 Multi-Geoは便利な機能ですが、導入後に直すより、展開前に「どのデータを、誰の責任で、どのGeographyに置くか」を決める方がはるかに安全です。
コメント