Microsoft が Entra テナント作成クイックスタートを更新したことで、Microsoft Entra テナントの作成は単なる初期設定手順ではなく、「新しいテナントを作った瞬間からどう統制するか」まで含む話になりました。現行のクイックスタートでは、従来の Workforce/B2C に加えて、Governed Workforce を使う「セキュリティで保護されたアドオン テナント作成（プレビュー）」が案内され、ガバナンスポリシーテンプレートを定義しておけば、新規テナントとホームテナントのガバナンス関係を自動で張れる流れが示されています。 (Microsoft Learn)
結論から言うと、今回の更新の本質は「追加テナントを作れるようになった」ことではありません。子会社、部門、検証環境、地域分離などで複数テナントが必要になる前提で、テナントスプロールを防ぎながら最初から統制下に置く設計が、Microsoft の公式ガイドに明確に組み込まれたことです。この記事では、現行ガイドの要点、Governed Workforce を選ぶべき場面、そしてテナント乱立を防ぐ実務ルールをまとめます。 (Microsoft Learn)
Microsoft が Entra テナント作成クイックスタートを更新して変わったこと
公開履歴を見ると、GitHub 上では 2026年4月9日に quickstart の更新があり、現行の Microsoft Learn ページは 2026年3月19日更新表示です。さらに、テナントガバナンスに直結する secure add-on tenant creation の追加は 2026年3月12日の履歴で確認できます。つまり、4月の更新だけを見るより、現行ドキュメント全体が「テナント作成とガバナンスを接続する内容」になっている点を読むのが重要です。 (GitHub)
現行ガイドで押さえるべき実務ポイントは4つあります。1つ目は、作成フローが Workforce / B2C と Secure add-on tenant creation (preview) に分かれ、後者では Governed Workforce を選ぶ構成になったことです。2つ目は、自動でガバナンス関係を張るには default のガバナンスポリシーテンプレートが必要なこと。3つ目は、作成時に MCA サブスクリプションとリソースグループを選び、Microsoft Entra ID Free の課金資産がひも付くこと。4つ目は、作成後にホームテナントとのガバナンス関係が形成され、related tenants inventory にも現れることです。 (Microsoft Learn)
なぜこの更新がテナントスプロール対策に直結するのか
そもそも複数テナントは異常ではありません。Microsoft 自身も、複数の子会社や事業部、M&A、会社分割、複数クラウド、地理的境界、テスト/ステージング、さらには部門や従業員が開発や検証のために作ったテナントまで、複数テナントが生まれる主な理由として挙げています。 (Microsoft Learn)
問題は「複数テナントであること」ではなく、「中央 IT が把握していない複数テナントが増えること」です。Tenant Governance の概要では、大規模組織の多くが複数テナントで運用している一方で、中央 IT が管理していない shadow IT テナントや、ユーザーが新たに作成したテナントもリスクになると説明されています。Tenant Governance は、既存の管理対象テナントだけでなく、こうした未知のテナントも含めて可視化し、セキュリティとコンプライアンス要件に照らして管理できるようにする位置付けです。 (Microsoft Learn)
ここで重要なのが Related tenants です。これは「自社保有テナントの確定台帳」ではなく、ID、アプリ、課金のシグナルから関連性を示す situational awareness です。Microsoft の説明でも、related tenants は所有権の断定ではなく、B2B 登録やサインイン、管理アプリへのサインイン、マルチテナントアプリ、共有課金アカウントなどの観測可能なシグナルを手掛かりに、どこから調べるべきかを示すものだとされています。 (Microsoft Learn)
Microsoft の Zero Trust ガイダンスが「非管理者によるテナント作成を制限するべきだ」と強く言うのも同じ文脈です。制限がないと、悪意ある攻撃者だけでなく、善意だが理解不足の従業員でも新しいテナントを作れてしまい、その作成者は既定で Global Administrator になります。Microsoft は、こうした孤立テナントが組織のガバナンスや可視性の外に出て、brand impersonation や consent phishing などの足場になるリスクを指摘しています。 (Microsoft Learn)
要するに、今回の quickstart 更新は「新規テナントをどう作るか」の説明ではなく、「新規テナントを野良化させない」ための設計思想が公式手順に降りてきたものと見ると理解しやすいです。 (Microsoft Learn)
Governed Workforce を使うと何が自動化されるか
Governed Workforce を使うと、追加 workforce tenant の作成が単独イベントで終わりません。ガバナンスポリシーテンプレートを用意しておけば、新しいテナントの作成と同時にホームテナントとのガバナンス関係が作られ、クロステナント委任管理のロール、必要に応じたマルチテナントアプリ、そして課金資産までまとめて整えられます。 (Microsoft Learn)
違いをざっくり整理すると、次のようになります。 (Microsoft Learn)
| 観点 | 従来の Workforce/B2C 作成 | Governed Workforce |
|---|---|---|
| 主な用途 | 一般的な workforce tenant または B2C tenant の作成 | ガバナンス前提の追加 workforce tenant 作成 |
| ガバナンス関係 | 別途設計・構築が必要 | default テンプレートがあれば自動形成 |
| 管理者アクセス | 新テナントごとに管理設計が必要になりやすい | governing tenant の資格情報で委任管理しやすい |
| アプリ管理 | テナントごとに個別対応しやすい | テンプレート経由でマルチテナントアプリを展開しやすい |
| 課金と所有の追跡 | 通常の管理に依存 | Microsoft Entra ID Free 課金資産がサブスクリプションにひも付く |
| 向くケース | 単純な新規作成、B2C など | 部門、子会社、地域、検証環境の追加テナントを中央統制したい場合 |
実務で特に大きいのは、ローカル管理者や B2B 管理者アカウントを各テナントに増やさなくてよくなる方向へ寄せられることです。Cross-tenant delegated administration では、governing tenant の資格情報で governed tenant にサインインでき、アクセスは GDAP ベースで最小権限化されます。さらに、governed tenant 側のサインインログや監査ログに委任管理者の操作が残るため、「中央集権的なのに現場から見えない」という不信も生みにくい設計です。 (Microsoft Learn)
もう一つ見逃せないのが、Microsoft Entra ID Free の課金資産です。これは単なる課金上の痕跡ではなく、どのサブスクリプション配下で追加テナントを作ったのかを追えるため、新規テナントのインベントリ管理や ownership の裏取りに役立ちます。Microsoft は、この課金資産がテナント所有の証明や、将来管理アクセスを失った場合の復旧にも役立つと説明しています。 (Microsoft Learn)
ただし、Governed Workforce も Tenant Governance も現時点ではプレビュー扱いです。設計に取り込む価値は高い一方、UI 名称や要件、機能の細部は今後変わる可能性があります。本番運用に入れるなら、まずは 1 つの統制された追加テナントで検証し、その後に横展開する進め方が無難です。 (Microsoft Learn)
新しいテナントを作る前に確認したい判断基準
Microsoft が挙げる複数テナントの妥当な理由は、M&A、子会社運営、法規制やデータ所在の要件、複数クラウド、地理的分離、テスト/ステージングなどです。逆に言うと、これらの理由が曖昧なら、新しいテナントを増やす前に「既存テナント内の分離で足りないか」を疑った方が失敗しにくくなります。テナントは ID とアクセス管理の境界であり、増やすほど運用と監査の負荷も増えるからです。 (Microsoft Learn)
判断の目安は次のとおりです。 (Microsoft Learn)
| 質問 | Yes なら | No なら |
|---|---|---|
| 独立した ID 境界が本当に必要か | 新規テナント候補 | 既存テナント内の分離を優先 |
| 子会社、地域、買収先、検証環境など継続的な複数テナント前提か | Governed Workforce を検討 | 単発用途なら増やさない方向を検討 |
| 中央 IT が継続運用と監査を引き受けられるか | ガバナンス設計へ進む | 作成前に運用責任を明確化 |
| related tenants / billing / audit で後追いできるか | sanctioned tenant として作成 | 野良化リスクが高いので作成を止める |
特に「アプリを 1 つ試したいだけ」のケースで、すぐ新規テナントを作るのは危険です。Microsoft のガイダンス全体が示しているのは、追加テナントは組織境界や統制要件があるときに選ぶもので、思いつきの分離策として増やすものではない、という考え方です。 (Microsoft Learn)
テナントスプロールを防ぐ実務ルール
Microsoft Entra テナント管理で重要なのは、作成手順より前に「誰が作れるか」「作った後に誰が見えるか」「怪しいテナントをどう止めるか」を決めることです。最低限、次の運用ルールまではセットで考えるべきです。 (Microsoft Learn)
| 統制項目 | 最低限やること | 失敗しがちな点 |
|---|---|---|
| 作成権限 | Restrict non-admin users from creating tenants を有効化し、必要者だけ Tenant Creator を付与 | 作成権限を全員に残す |
| 監査 | Audit log の DirectoryManagement / Create Company を監視 | 誰がいつ作ったか追えない |
| sanctioned 追加テナント | Governed Workforce を既定ルートにする | 通常フローで孤立テナントを増やす |
| テンプレート | default ガバナンスポリシーテンプレートを事前に定義 | テンプレート未設定で自動ガバナンスが効かない |
| 棚卸し | Related tenants を有効化し、Known / Requires governance / Risky で分類 | Related tenants を所有台帳扱いする |
| 封じ込め | 不明テナントは cross-tenant access や tenant restrictions v2、quarantine を検討 | 見つけても放置する |
| 緊急時 | sanctioned tenant ごとに cloud-only の emergency access accounts を 2 つ用意 | 作成者 1 人だけが唯一の GA になる |
作成権限は Tenant Creator へ絞る
Default user permissions の説明では、非管理者によるテナント作成を制限する設定を Yes にすると、少なくとも Tenant Creator ロールを持つユーザーだけが新規テナントを作成できます。監査ログでは Category が DirectoryManagement、アクティビティが Create Company として残るため、まずはこの設定を有効にし、誰に Tenant Creator を渡しているかを明文化するのが出発点です。 (Microsoft Learn)
default テンプレートを「先に」作る
Governed Workforce を使うなら、作成前に default のガバナンスポリシーテンプレートを定義しなければいけません。しかも、他のテンプレートが存在していても default が未設定なら secure add-on flow はガバナンス関係を自動で作りません。加えて、テンプレートの更新は既存のガバナンス関係へ自動反映されず、反映には再リクエストと承認が必要です。ここを見落とすと、「ガバナンス付きで作ったつもりの孤立テナント」や「テンプレート更新したのに現場へ効いていない」という事故が起きます。 (Microsoft Learn)
Related tenants は台帳ではなく調査起点
Related tenants discovery は一度有効にすると元に戻せず、データが出そろうまで数日かかります。見えたテナントは、Known and acceptable、Requires governance、Potentially risky に分類して扱います。ただし、signals は descriptive であって prescriptive ではありません。つまり、見つかったから自社保有と断定するのではなく、「どのシグナルでつながっているのか」「最近も活動があるのか」を見て次のアクションを決める必要があります。 (Microsoft Learn)
怪しいテナントは隔離まで考える
不明なテナントが見つかった場合、Microsoft は cross-tenant access settings や tenant restrictions v2、Global Secure Access を使ってインバウンド/アウトバウンドのサインインやアクセスを制限し、quarantine するアプローチを案内しています。quarantine の考え方は、怪しいテナントとの間に意図的に friction を作り、本当に業務上必要なら管理者から連絡が来る状態にすることです。放置より、可逆的に絞る方が安全です。 (Microsoft Learn)
緊急アクセスアカウントは最初に作る
新しいテナントの作成者は既定で Global Administrator になり、Microsoft は cloud-only の emergency access account を 2 つ用意することを推奨しています。追加テナントを作った直後にここを怠ると、作成者の退職、MFA 事故、アカウント停止だけでテナント全体が管理不能になる可能性があります。 (Microsoft Learn)
失敗しやすいポイント
- 4月9日の更新だけを見て、大きな機能追加がその日に入ったと思い込むことです。公開履歴上、4月9日に更新はある一方、secure add-on tenant creation の追加は 3月12日、Learn ページの表示更新日は 3月19日です。現行ドキュメント全体で判断した方が正確です。 (GitHub)
- サブスクリプション条件を見ずに始めることです。追加の workforce tenant は有料顧客向けで、
Governed Workforceでは MCA サブスクリプションが必要、EA は現時点で非対応です。 (Microsoft Learn) default以外のテンプレートを作って満足することです。secure add-on flow が自動で参照するのはdefaultです。 (Microsoft Learn)- テンプレートを更新すれば既存のガバナンス関係も自動で変わると思い込むことです。既存関係へ反映するには再リクエストと承認が必要です。 (Microsoft Learn)
- Related tenants を ownership 台帳として扱うことです。Microsoft は一貫して、これは authoritative inventory ではなく、関連性を示す discovery 情報だと説明しています。 (Microsoft Learn)
Governed Workforceと CIAM 向け external tenant 作成を混同することです。今回の quickstart は、consumer-facing apps 向け external tenant 構成の説明ではありません。 (Microsoft Learn)- 作成者 1 人だけを唯一の Global Administrator にして終えることです。追加テナントでは最初の 30 分で emergency access accounts まで作るくらいの感覚がちょうどいいです。 (Microsoft Learn)
今すぐやるべきこと
すぐ着手するなら、順番はこの4つで十分です。 (Microsoft Learn)
- 既存テナントで
Restrict non-admin users from creating tenantsを確認し、Tenant Creator の対象者を絞る。 defaultガバナンスポリシーテンプレートを作り、どの built-in role と role-assignable group を渡すかを最小権限で決める。- sanctioned な追加テナントが必要なら、通常フローではなく
Governed Workforceで 1 件だけ試す。 - Related tenants discovery を有効化し、数日後に Known / Requires governance / Potentially risky で分類し、不明テナントは quarantine まで含めて対処する。
Microsoft が Entra テナント作成クイックスタートを更新した意味は、テナント作成を「申請の終点」ではなく「ガバナンスの起点」として扱い始めたことにあります。複数テナント時代の運用では、「作れるか」より「作った瞬間から見えるか、守れるか、戻せるか」が重要です。まずは作成権限の制限、default テンプレート、Related tenants の有効化、そして emergency access accounts の整備から着手すると、テナントスプロール対策はかなり前に進みます。 (Microsoft Learn)
コメント