自治体向けMicrosoft 365でテナント分離を検討するときは、最初に「分離ありき」で進めないのが正解です。結論から言うと、単一テナントで統制できる範囲を先に詰め、それでも越えられない管理境界があるときだけ分離するほうが失敗しにくいです。Microsoft Entra の管理単位は管理権限の委任には有効ですが、完全な隔離ではありません。一方で、条件付きアクセス、秘密度ラベル、DLP、Information Barriers を使うと、認証・共有・会話・ファイル持ち出しまでかなり細かく制御できます。複数テナントは有効な選択肢ですが、運用、ユーザー体験、共同作業、ライセンス確認が一段重くなります。 (Microsoft Learn)
しかも、自治体のネットワーク設計は近年「固定的な境界」から「ゼロトラスト前提の動的制御」へ寄っています。デジタル庁の検討資料では、Entra 条件付きアクセス、Intune 連携、ZTNA/SASE を前提条件として挙げる自治体意見や、SaaS 通信が中心になることで集約型 WAN が遅延や単一障害点になるという指摘が確認できます。つまり、「LGWAN 系とインターネット系を分けているから、Microsoft 365 も必ず別テナント」という発想は、そのままでは危険です。 (デジタル庁)
この記事では、自治体向けMicrosoft 365でテナント分離を検討するときの論点を、分離が向くケース、分離しない代替策、設計時の落とし穴、実際に確認すべき順番まで一気に整理します。
判断は「何を分けたいか」で決まる
Microsoft Entra のテナントは、顧客が作成して所有する分離されたディレクトリ オブジェクトの単位です。さらに、テナント作成時に選ぶ Country/Region は geo-location に割り当てられ、後から変更できません。新しいテナントを切る判断は、単なる試し打ちではなく、ID・ポリシー・運用体制を長く背負う設計判断です。 (Microsoft Learn)
| 目的 | まず見るべき手段 | 分離を検討する目安 |
|---|---|---|
| 管理権限を部局別に委任したい | 管理単位、ロール分離 | 部局管理者どうしが相互に見えてはいけない |
| 部局間の共有や外部共有を抑えたい | 秘密度ラベル、DLP、Information Barriers | ラベルや DLP では足りず、共有経路そのものを構造的に分断したい |
| 外郭団体・委託先と共同利用したい | B2B、共有チャネル、クロステナント設定 | 人事・ヘルプデスク・監査・インシデント対応まで運用主体が別 |
| データ所在地が気になる | データ所在地の確認、ADR | サービス単位で確認しても要件を満たせない |
とくに自治体で多い誤判定は、「部局が違う」「ネットワーク区分が違う」「自治体だから政府向け Microsoft 365 がそのまま使えるはず」という理由だけで分離を前提にしてしまうことです。日本の商用テナントでも、Country/Region、各サービスの実際のデータ所在地、Advanced Data Residency の適用可否を個別に確認する必要がありますし、Office 365 Government GCC/GCC High は米国公共部門向けに定義された別環境です。 (Microsoft Learn)
誤解しやすい論点
ネットワーク分離とテナント分離は別
自治体の現場では、三層分離や LGWAN 接続系の話から、そのまま Microsoft 365 のテナント分離に飛びがちです。ですが、デジタル庁の資料では、Entra 条件付きアクセスによるリスクベース MFA や端末状態確認、Intune 連携、ZTNA/SASE など、ネットワーク境界ではなく ID・端末・文脈で制御する方向が明確に出ています。別の検証では、Microsoft 365 と Entra ID の連携によって、厳格な認証・認可や DLP による庁外送信の検知・遮断が確認されています。 (デジタル庁)
つまり、自治体向けMicrosoft 365で本当に見るべきなのは、「どのネットワークにいるか」だけではありません。どの利用者が、どの端末から、どの情報に、どの権限で触るのかです。ここを設計しないままテナントだけ分けても、運用負荷が増えるわりに、期待した統制にならないことがよくあります。 (デジタル庁)
国内保存とテナント分離は別
テナントを分ければ国内保存が自動で満たせる、という理解も危険です。Microsoft 365 のデータ所在地は、テナントの既定 geography と、各サービスがどの geography に展開されているかの組み合わせで決まります。管理センターのデータの場所機能で実際の保存場所を確認できますし、日本は Local Region Geography の対象で、対象サービスでは Advanced Data Residency を利用できます。 (Microsoft Learn)
注意したいのは、ワークロードごとに事情が違うことです。公式の例では、日本が既定地域の商用テナントでも、Microsoft Forms の顧客データは Americas にプロビジョニングされるケースが示されています。要するに、「自治体向け Microsoft 365 を別テナントにした」だけでは不十分で、Exchange、SharePoint、Teams、Forms、Purview などを個別に確認しなければいけません。 (Microsoft Learn)
さらに、Office 365 Government GCC/GCC High は、顧客コンテンツを米国内に保存し、米国公共部門向けの要件に合わせた環境として定義されています。日本の自治体が考える「国内向けの行政クラウド」と同一視しないほうが安全です。 (Microsoft Learn)
管理委任と完全隔離は別
「部局ごとに管理者を分けたい」だけなら、まず管理単位を疑うべきです。管理単位は、たとえば地域や部門ごとにヘルプデスク管理者の権限を委任するような使い方に向いています。 (Microsoft Learn)
ただし、管理単位は管理権限のスコープに効く仕組みであって、管理者やメンバーが他のユーザーやリソースを完全に見えなくする仕組みではありません。ここを見誤ると、「分けたつもりなのに、実は相互可視性が残っていた」という状態になります。 (Microsoft Learn)
単一テナントで先に試すべき代替策
自治体向けMicrosoft 365でテナント分離を決める前に、少なくとも次の4つは PoC しておきたいところです。ここを飛ばすと、分離後に「実は単一テナントで十分だった」となりやすいです。 (Microsoft Learn)
管理境界を切るなら管理単位
本庁、教育委員会、議会、外部委託ヘルプデスクのように、管理対象を分けたいだけなら、まずは管理単位で十分なことが多いです。ロール委任をきちんと設計すれば、日常運用の分担はかなり整理できます。 (Microsoft Learn)
ただし、管理単位は hard isolation ではありません。相互に存在を見せたくない、証跡や管理画面への可視性まで切りたい、という要件なら、ここで単一テナント案は厳しくなります。 (Microsoft Learn)
共有制御なら秘密度ラベルと DLP
秘密度ラベルは、Teams や Microsoft 365 グループ、SharePoint サイトに対して、公開/非公開、外部ユーザーアクセス、SharePoint の外部共有、未管理端末からのアクセス、認証コンテキスト、共有チャネル招待の制御などを持てます。実務では、「庁内限定」「委託先参加可」「外部共有禁止」などをラベル設計で表現しやすいです。 (Microsoft Learn)
DLP も強力です。SharePoint と OneDrive では、機微情報を検出した時点で、ゲストに対するアクセスを先回りでブロックできます。Teams のファイル共有も SharePoint/OneDrive ベースなので、この統制が効きます。Teams チャット本文まで DLP で保護したい場合は、E5 系ライセンスが必要です。 (Microsoft Learn)
見落としやすいのは、ラベル設定の一部がサイト所有者の裁量を広げる点です。外部共有や認証コンテキストをラベルに含めると、サイト所有者がラベル変更を通じてそれらの設定を変えられるようになります。「管理者だけが変えられる想定」でラベルを設計すると事故りやすいです。 (Microsoft Learn)
会話や検索の制御なら Information Barriers
部局間の会話やファイル共有、検索を抑えたいなら、Information Barriers は有力です。Teams では検索、チャット、会議招待、画面共有、ファイル共有などを制御でき、SharePoint と OneDrive でもサイトやコンテンツへのアクセス・共有・検索を制御できます。 (Microsoft Learn)
ただし万能ではありません。Information Barriers は二方向の制限に対応する仕組みで、メール本文の制御は別論点です。公式にも、メールの通信制御が必要なら Exchange の mail flow rules を検討するよう案内があります。 (Microsoft Learn)
庁外アクセスの統制なら条件付きアクセス
庁外アクセスや BYOD、委託先端末の扱いが主論点なら、条件付きアクセスを先に詰めるべきです。条件付きアクセスは、ユーザー、場所、端末状態、アプリ、リスクなどのシグナルを使って、MFA 必須、準拠デバイス必須、特定の場所だけ許可、といった判断を行う Zero Trust のポリシーエンジンです。 (Microsoft Learn)
この領域は、今の自治体ネットワーク議論とも相性が良いです。実際、デジタル庁の検証でも、Microsoft 365 と Entra ID を含む組み合わせで、厳格な認証・認可や重要情報保護の検証が行われています。テナント分離に進む前に、まずここを詰めたほうが、利用者体験を壊さずに統制を上げやすいです。 (デジタル庁)
それでも分離が向くケース
テナント分離が向くのは、技術的な不安が大きいときではなく、運用境界が強いときです。
次の質問に「はい」が多いなら、自治体向けMicrosoft 365でも分離の優先度が上がります。
- 部局や関係団体ごとに、人事・委託終了時のアカウント停止責任が別ですか。
- 管理者、ヘルプデスク、監査担当が、相互のユーザー情報や証跡に触れられない必要がありますか。
- インシデント時の緊急管理者、証跡保全、例外申請、復旧判断を、別ラインで独立運用したいですか。
- 単一テナントの管理単位、秘密度ラベル、DLP、Information Barriers、条件付きアクセスを試しても、要件を満たせませんでしたか。 (Microsoft Learn)
具体例で言うと、本庁と外郭団体、あるいは本庁と大きな委託先運用を、ID 管理・ヘルプデスク・監査閲覧まできっちり分けたいケースは、分離の候補です。逆に、「庁内の部ごとに管理者を分けたい」程度なら、いきなり別テナントに行くより、単一テナントでの統制を詰めたほうが現実的です。 (Microsoft Learn)
なお、検証用途や破壊的なテスト用途では、別テナントが合理的なこともあります。Microsoft も、Exchange Online、SharePoint、Teams など一部のテストは別テナント前提になりやすいと案内しています。 (Microsoft Learn)
分離するなら見落とせない設計論点
ID の source of authority とライフサイクル
別テナントにした瞬間、最初に詰まるのはアカウントの二重管理です。Microsoft Entra のテナント間同期は、B2B コラボレーション ユーザーとグループの作成、更新、削除を自動化できます。退職や異動が多い自治体では、ここを手で回す設計はかなり危険です。 (Microsoft Learn)
さらに、マルチテナント組織では、同期されたユーザーは guest ではなく member として扱われ、Teams の体験に関わります。分離後も Teams 検索や会議体験をある程度シームレスにしたいなら、単なる招待運用ではなく、ライフサイクル設計まで踏み込む必要があります。 (Microsoft Learn)
Teams と SharePoint の共同作業モデル
テナント分離後も共同作業するなら、何でつなぐかを先に決めるべきです。Teams のリッチな MTO 体験は、クロステナント同期だけでは足りません。MTO の設定に加えて、Teams の external access と B2B direct connect の設定が必要です。 (Microsoft Learn)
共有チャネルも便利ですが、前提があります。外部組織との shared channels は guest アカウントを使わない一方で、両組織でテナント間アクセス設定を構成する必要があり、Teams の guest access も有効でなければ招待できません。しかも B2B direct connect は既定ではブロックされています。設計なしに「あとでつながるだろう」と考えると詰まります。 (Microsoft Learn)
加えて、shared channels の運用には罠があります。共有チャネル内のファイルに SharePoint 側で個別権限を付けた場合、チャネルやチームから外しても、そのファイルのアクセス権は残ることがあります。メンバー削除＝ファイルアクセス剥奪ではありません。 (Microsoft Learn)
共有リンクの意味が変わる
MTO を使うなら、「組織内リンク」の意味も変わります。公式 FAQ では、Anyone in my organization のリンクは、MTO ユーザーが B2B member user であるため、MTO 内の全ユーザーが利用可能になると案内されています。庁内向けのつもりで作ったリンクが、分離先テナントのユーザーにも届く前提になるわけです。 (Microsoft Learn)
このため、テナント分離後も SharePoint の共有リンク設計を従来のままにすると危険です。MTO を採るなら、「組織内リンク」は広がるものとして見直す必要があります。 (Microsoft Learn)
ライセンスは「機能ごと」に確認する
コストは「テナント数が増えたから単純に倍」とは限りませんが、確認項目は確実に増えます。MTO の利用には Entra ID P1 以上が必要で、原則として同一人物はホームテナント側のライセンスで扱う考え方が示されています。一方で、Microsoft も一般論として、複数テナントは複雑性とライセンスコスト増の可能性を挙げています。条件付きアクセスは P1、Teams チャットの DLP は E5 系が必要です。 (Microsoft Learn)
実務では、「MTO 自体の要件」「条件付きアクセス」「Purview DLP」「委託先アカウントの扱い」を別々に確認するのが安全です。ここを一括で「Microsoft 365 のライセンスで何とかなる」と考えると、あとで見積もりがずれます。 (Microsoft Learn)
データ所在地は作成前に決める
新テナントを作るなら、Country/Region は最初に慎重に決めるべきです。公式には、作成時に設定した場所は後から変更できません。さらに、実際のデータ所在地はサービスごとに異なるため、管理センターのデータの場所で確認しながら判断する必要があります。 (Microsoft Learn)
自治体向け Microsoft 365 でデータ所在地が主論点なら、分離前にまず 現テナントの実データ所在地確認 と ADR の適用可能性確認 をやるほうが順番として正しいです。そこを飛ばして新テナントを作ると、後から「欲しかったのは分離ではなく所在地確認だった」と気づきやすいです。 (Microsoft Learn)
失敗しやすいポイント
- 共有チャネルから外せば、関連ファイルも自動で見えなくなると思い込むこと。SharePoint 側で与えた個別権限は残る場合があります。 (Microsoft Learn)
- 秘密度ラベルは全部管理者だけが変えられると思い込むこと。設定次第では、サイト所有者が外部共有や認証コンテキストを変えられます。 (Microsoft Learn)
- クロステナント同期を入れれば、Teams 体験も自動でシームレスになると思い込むこと。MTO、external access、B2B direct connect は別に詰める必要があります。 (Microsoft Learn)
- MTO で「組織内リンク」は安全なままだと思い込むこと。
Anyone in my organizationは MTO ユーザーにも届きます。 (Microsoft Learn) - 管理単位を入れたから hard isolation できたと思い込むこと。管理単位は管理権限のスコープであって、完全隔離ではありません。 (Microsoft Learn)
迷ったらこの順で進める
まず、1 枚でいいので「何を絶対に越境させたくないのか」を書き出してください。ユーザーなのか、管理者権限なのか、共有リンクなのか、証跡なのか、庁外アクセスなのか。ここが曖昧なまま「自治体向け Microsoft 365 のテナント分離」を始めると、議論が拡散します。
次に、単一テナントで管理単位、条件付きアクセス、秘密度ラベル、DLP、Information Barriers を小さく試します。ここで要件を満たせるなら、分離しないほうが運用は軽くなります。満たせないなら、いきなり全庁分割ではなく、本庁 tenant + 1 境界のパイロットで始めるのが安全です。 (Microsoft Learn)
分離に進むなら、最後に必ず「共同作業のつなぎ方」「共有リンクの意味」「データ所在地」「ライセンス要件」「緊急管理者とインシデント対応」をセットで固めます。テナント分離はセキュリティ製品の選定ではなく、運用設計そのものです。ここを押さえれば、自治体向けMicrosoft 365でも、分離すべきケースと分離しなくてよいケースをかなり明確に切り分けられます。 (Microsoft Learn)
コメント