【完全ガイド】Microsoft 365／Azure（Microsoft Entra ID）の別テナント新規作成とカスタムドメイン重複制限の回避策

既存の Microsoft 365（Microsoft Entra ID）テナントを持つ組織が、別テナントを新規に作成しつつ同じメールドメイン（@company.com）を維持できるか――この問いは、合併・分社・環境分離・外部委託など多様な場面で必ず浮上します。本記事は、ドメインの原理と制約を出発点に、「できること／できないこと」、最適な回避策、実務的な手順、運用設計のポイントまでを一気通貫で解説します。

結論と前提（要点の先出し）

カスタムドメイン（例：company.com）は、同時に複数テナントへは紐付けられません。一度検証（TXT レコードで所有権証明）されたドメインは、そのテナントに占有されます。
別テナント自体の新規作成は可能です。新テナントには一意の *.onmicrosoft.com 既定ドメイン（例：company2.onmicrosoft.com）が自動割り当てされます。
@company.com を新テナントに登録せずに管理者として使うことは可能です。作成に利用した ******@company.com は「外部 ID（B2B）」として扱われます（新テナントへ company.com が追加されるわけではありません）。
同じブランド名でメールを使いたい場合の現実的な代替策は、サブドメイン（例：apps.company.com）の新テナント側検証・運用、または別ドメイン（例：company2.com）の採用です。
目的が「ワークロードの分離」だけなら、ドメイン移行は不要。サブスクリプション分割、B2B 招待、クロステナント同期、マルチテナントアプリなどで要件を満たせることが多いです。

なぜ同一カスタムドメインは複数テナントで使えないのか

Microsoft Entra ID の「カスタムドメイン」機能は、DNS の TXT レコードで所有権を検証し、検証済みドメインは 1 テナントに排他的に所属させる仕組みです。これはログイン ID（UPN）、メールアドレス（SMTP）、アプリの SSO、各種クラウドサービスの URL 命名や証明書バインドなど、セキュリティと一貫性を維持するために不可欠です。

そのため 同一のルートドメイン（company.com）を同時に別テナントへ登録することはできません。新テナント側で登録を試みても、既存テナントに検証済みとして存在する限りはブロックされます。

用語の整理（混同しやすいポイント）

用語	概要	補足
UPN（ユーザープリンシパル名）	サインイン名（例：`[email protected]`）	UPN のドメイン部分は、テナントに検証済みのドメインである必要があります。
SMTP（メールアドレス）	メール配送アドレス（例：`[email protected]`）	Exchange Online の「受信ドメイン（Accepted Domain）」としての設定が必要です。
既定ドメイン	`*.onmicrosoft.com`（例：`company2.onmicrosoft.com`）	テナント作成時に必ず一意のドメインが割り当てられます。これは移管不可でユニークです。
カスタムドメイン	所有権検証した独自ドメイン（例：`company.com`）	同時に複数テナントへは紐付け不可。移行するには「元テナントで完全削除」が前提です。

別テナント（Microsoft Entra ID）を新規作成する手順

Azure ポータル右上のテナントスイッチャーから[テナントの作成]を選択。
種別で「Microsoft Entra ID」を選択し、組織名と国/地域を指定。
初期ドメイン名（*.onmicrosoft.com）は自動的に一意な値が予約されます（例：company2.onmicrosoft.com）。
申請に使用したメールアドレス（例：******@company.com）が、新テナントの初期管理者として扱われます。
このアカウントは外部 ID（ゲスト/B2B）として新テナントに存在し得ますが、それ自体は company.com を新テナントへ登録する行為ではありません。
テナント作成後、テナントスイッチャーで新テナントへ切り替え、全体管理者でサインインできることを確認します。

作成直後の状態（よくある疑問の整理）

項目	状態	実務ポイント
メールドメイン	`company2.onmicrosoft.com` のみ	`company.com` は存在しません。追加したい場合は所有権検証が必要ですが、既存テナントに存在する限り不可。
管理者	作成に用いた @company.com アカウントが管理権限	新テナント側のユーザータイプ（メンバー/ゲスト）は環境により異なる場合があります。いずれにせよ管理操作は可能です。
ライセンス	別テナントとして独立	ライセンスはテナント間で共有されません。必要に応じて別途割り当てが必要です。

@company.com アカウントを新テナントの管理者として使う

@company.com をサインイン ID として維持したまま、新テナントに管理者として参加する典型的な手順です。

新テナントで 外部ユーザーの招待（B2B 招待）を有効化。
既存テナントの管理者（******@company.com など）を新テナントへ招待し、全体管理者や特権ロール管理者など適切なロールを割り当て。
必要に応じて クロステナントアクセス設定で「外部ユーザーの MFA 信頼」や「準拠デバイスの信頼」を構成（管理者操作時の多要素認証再実行を減らすなどの運用最適化）。

PowerShell（Microsoft Graph）での簡易確認例

新テナントで外部ユーザーの状態やドメイン状態を確認する例です。

# サインイン（同意ウィンドウで必要スコープを許可）
Connect-MgGraph -Scopes "User.Read.All, Directory.Read.All, Domain.Read.All"

# 外部ユーザー（ゲスト）の確認

Get-MgUser -Filter "userType eq 'Guest'" | Select-Object DisplayName,UserPrincipalName

# ドメインの一覧（新テナントに 'company.com' が存在しないことの確認）

Get-MgDomain | Select-Object Id, IsVerified, IsDefault

同じブランドでメールを使いたい場合の代替策

ルートの company.com を既存テナントに残しつつ、新テナントでブランド整合性を保ちたい場合は、次の 2 つが実務的です。

代替策 A：サブドメイン（例：apps.company.com）を新テナントに登録

サブドメインはルートドメインの所有権を持つ管理者が自由に切り分けられます。ルートを既存テナント、サブドメインを新テナントへ割り当てれば、衝突なく共存できます。

DNS に TXT 検証レコードを追加（apps.company.com）。
新テナントの Entra ID 管理センターで サブドメインを追加 → 検証。
メール運用も行う場合、Exchange Online で 受信ドメインに追加し、必要な DNS（MX/CNAME/SRV/TXT）を構成。

レコード種別	ホスト名	値（例）	目的
TXT	@（apps.company.com）	MS=ms########	所有権検証（Entra ID）
MX	@（apps.company.com）	`apps-company-com.mail.protection.outlook.com`	メール受信（Exchange Online）
TXT	@	v=spf1 include:spf.protection.outlook.com -all	SPF（なりすまし対策）
CNAME	autodiscover	autodiscover.outlook.com	自動検出（クライアント設定）
CNAME/TXT	selector1/selector2	selector1-domainkey.<テナント固有>	DKIM（署名）

利点：ブランドを保ちながら、テナントを厳密に分離可能（@apps.company.com など）。
注意：ユーザーのメールアドレスがサブドメインに変わるため、対外表示のルール整理が必要です。

代替策 B：別ドメイン（例：company2.com）を新テナントに登録

新規ドメインを取得し、新テナントで検証・メール受信設定を行います。既存テナントの運用に影響を与えません。ただし、ブランド一貫性の観点での周知・広報・UI 表示（署名・名刺・Web）調整が必須です。

ルートドメインを新テナントへ移す場合のリスクと手順（非推奨）

「どうしても company.com を新テナントへ移したい」場合は、旧テナントからの完全削除が前提です。現実には停止影響が大きく、周到な計画・段階的移行・暫定運用を伴います。

停止・影響の代表例

旧テナントのユーザー UPN/メールが *.onmicrosoft.com に戻る（一時的にも）。
Exchange Online：受信ドメインの削除と再構成、MX 切替期間の配送影響。
SharePoint/OneDrive：URL 命名衝突（contoso.sharepoint.com はテナントにひもづく）とリンク切れ。
Teams/会議/招待リンク/ボイス：SBC・電話番号割当の影響、外部連携再設定。
Azure/Entra：アプリ登録（リダイレクト URI のドメイン）、アプリプロキシ、証明書、SAML/OIDC 構成の見直し。

完全削除に向けた実務チェックリスト

カテゴリ	確認・実施項目	補足
ユーザー/グループ	すべての UPN/エイリアスから `@company.com` を除去	UPN を暫定で `@<onmicrosoft>` へ変更
Exchange Online	受信ドメインから削除、すべての SMTP プロキシから除去	配布リスト/M365 グループ/共有メールボックスも対象
SharePoint/OneDrive	URL/共有リンクの影響洗い出し	リンク切替計画・周知・リダイレクト策（可能な範囲）
アプリ	アプリ登録/エンタープライズアプリのリダイレクト URI・証明書更新	SAML/OIDC のメタデータ更新が必要
DNS	TXT 検証、MX/SPF/DKIM/Autodiscover、各種 CNAME 切替	TTL 事前短縮で切替ウィンドウを最小化

PowerShell での「使途残り」検索例（Exchange Online）

# Exchange Online へ接続
Connect-ExchangeOnline

# ドメインを含むメールアドレスを検索

$domain = "company.com"
Get-ExoMailbox -ResultSize Unlimited | Where-Object {$_.EmailAddresses -match $domain} |
Select-Object DisplayName,PrimarySmtpAddress,EmailAddresses

Get-DistributionGroup -ResultSize Unlimited | Where-Object {$_.EmailAddresses -match $domain} |
Select-Object DisplayName,PrimarySmtpAddress

Get-Recipient -ResultSize Unlimited -Filter "EmailAddresses -like '*$domain*'" |
Select-Object Name,RecipientTypeDetails,PrimarySmtpAddress

目的が「分離」なら、ドメイン移行はしない（選ぶべき設計）

ブランド（メールドメイン）を動かさずに、「権限」「コスト」「責任範囲」「実験環境」などの分離を実現するパターンが多数あります。

代表的パターン

サブスクリプション分割（同一テナント内）：Azure リソースを課金・RBAC 単位で分離。Entra 側の ID・ポリシーは共有できるためシンプル。
B2B 招待（外部ユーザー）：別テナントのアカウントをゲストとして招待し、最小権限で役割付与。MFA/デバイス準拠の相互信頼で UX 改善。
クロステナント同期：人事ソースに基づきユーザー/グループ属性を自動同期。招待と属性整合を自動化。
マルチテナントアプリ：アプリ側をマルチテナント許可にし、各テナントの管理者同意で利用。
Microsoft Teams のマルチテナント組織（MTO）：会議・チャットの越境をシームレス化（メール/ドメインは共有せず）。

構成パターン比較（意思決定の参考）

パターン	主目的	利点	留意点	おすすめ度
新テナント＋サブドメイン	強い境界＋ブランド近似	ドメイン衝突なし／明確な分離	メール表記がサブドメインに	高
新テナント＋別ドメイン	強い境界＋最小衝突	既存環境へ無影響	ブランド統一の課題	中-高
単一テナント＋サブスクリプション分割	運用・課金分離	ID/ポリシー一元化・シンプル	境界は論理的（強制力は設計次第）	高

「ドメイン制限」をめぐる設計：越境サインインの制御

組織によっては「従業員が無制限に他テナントへサインアップ/サインインすること」を制限したい場合があります。代表的な対策は次の通りです。

テナント制限（Tenant Restrictions）：プロキシ/セキュリティアプライアンスで、許可テナント以外へのサインインを抑止。クライアントからの発行者（issuer）を検証します。
クロステナントアクセス設定：B2B 招待・コラボの既定/例外ルール。MFA・準拠デバイス・ハイブリッド参加の信頼継承も調整。
条件付きアクセス：来訪者（外部ユーザー）や管理者操作に対し、MFA・デバイス準拠・場所・リスクベースなどの制御を付与。

ライセンスと課金、責任分界

ライセンスはテナントごとに独立します。別テナントにまたがって「使い回し」はできません。
運用保守や監査ログ、データ所在地（Geo）、DLP/情報保護のポリシーはテナント単位で別管理になります。
クロステナント同期や B2B 招待のユーザーに対し、必要なサービスを利用する側のテナントでライセンスを割り当てるのが基本です。

メール運用の現実解：サブドメインで役割分担する

「グループ会社の一部業務のみを別テナントで運用したい」「外部委託先の専用テナントでプロジェクト運用したい」など、メールの到達性とブランドの折衷案としてはサブドメイン分割が最も現実的です。

社内向け/対外向けに @company.com、プロジェクト/アプリ用に @apps.company.com。
社外の受け取りやすさを重視する宛先にはエイリアス（転送）や自動応答でガイド。
マーケメールや通知系はサブドメインに寄せることで、DMARC/SPF/DKIM 設計がシンプルに。

よくある誤解（FAQ）

Q：「@company.com のまま、別テナントに同時ログインできますか？」
A：company.com を両テナントに同時登録することはできません。新テナントでは @company.com のユーザーを「外部 ID（ゲスト）」として扱うか、サブドメイン/別ドメインを利用します。
Q：「company.com を新テナントへ移すのは簡単ですか？」
A：旧テナントからの完全削除が必要で、メール・SSO・アプリに大きな停止を伴います。よほどの理由がなければ非推奨です。
Q：「UPN だけ @company.com にして、メールは @onmicrosoft.com にできますか？」
A：技術的には可能ですが、ユーザー体験や外部表示の一貫性を損なうため慎重に。サポートや運用が複雑になります。
Q：「B2B ユーザーに全体管理者ロールを付けても安全ですか？」
A：必要最小権限・PIM（特権アクセスの時間制）・MFA・準拠デバイス条件を併用してください。監査・アラートも必須です。

移行/導入プロジェクトの実務チェックリスト

ステークホルダー（情報システム・法務・広報・CSIRT・外部委託）合意形成
命名規則（UPN/SMTP/グループ/サイト/チーム）とライフサイクル管理
DNS 設計（サブドメイン階層、TTL、権限委譲、SPF/DKIM/DMARC）
条件付きアクセス・クロステナントアクセス・テナント制限の整合
ライセンス配賦・課金コード・コスト配分・ガバナンス
監査ログ保持・アクセスレビュー・アラート設計
ユーザーコミュニケーション（メール署名・名刺・Web・対外説明）
ローリングプラン（パイロット→段階展開）、バックアウト手順

実施手順サマリー（コピーして使える運用メモ）

新テナント作成：テナントスイッチャー → テナント作成 → Entra ID → 既定ドメイン確認。
管理者確保：@company.com を B2B 招待 → 全体管理者ロール付与（PIM/条件付きアクセス併用）。
ドメイン戦略：サブドメイン（推奨）または別ドメインを取得・検証。DNS/Exchange Online を構成。
セキュリティ・越境制御：クロステナントアクセスの既定/例外、MFA/準拠デバイス信頼、テナント制限。
運用設計：プロビジョニング（クロステナント同期）、ライセンス、監査、命名規則、周知。
（非推奨）ルート移行：旧テナントの完全除去 → 新テナントで検証 → MX 切替 → 影響復旧。

まとめ

company.com を既存テナントに残したまま、別テナントで同じドメインを併用することはできません。これは Entra ID がドメインの所有権をテナント単位で排他管理するためです。一方で、別テナントの新規作成自体は可能であり、管理者は @company.com のまま B2B として新テナントを運用できます。ブランドを保ちながら安全に分離を実現するには、サブドメインの新テナント側検証や別ドメインの採用が現実解です。目的がワークロード分離なら、ドメイン移行は避け、B2B 招待、クロステナント同期、サブスクリプション分割、マルチテナントアプリといったパターンを優先すべきです。ガバナンス・セキュリティ・DNS 設計を押さえれば、ユーザー体験と運用負荷のバランスを崩さずに、安全で拡張性の高いアーキテクチャを構成できます。

要点（再掲）

できない：company.com を既存テナントに残したまま、新テナントに重複登録。
できる：新テナント作成／@company.com の管理者参加（外部 ID）／サブドメイン or 別ドメイン運用。
代替策：サブドメイン検証＋メール DNS 構成／別ドメイン採用／分離目的なら B2B/クロステナント同期。

実装のヒント：クロステナント同期の最小構成

新テナント（宛先）で「受信（Inbound）」プロビジョニングを準備。属性マッピングとスコープ（OU/セキュリティグループ）を定義。
既存テナント（送信元）で「送信（Outbound）」プロビジョニングを設定。人事ソース（雇用形態・開始/終了日）を条件に。
同期ポリシーで displayName、mail、userPrincipalName、employeeId など必要十分な属性に限定。
承認フロー（Power Automate 等）と組み合わせ、最小権限の自動付与（グループベースライセンス）を実装。

実装のヒント：条件付きアクセス（管理者向け）

対象：外部ユーザー + 管理者ロール（新テナント）
制御：MFA 必須、準拠デバイス、高リスクサインインのブロック、国/場所制限
セッション：サインイン頻度の短縮、ブラウザ永続化の禁止、デバイスごとの再認証強化

運用テンプレ：DNS 変更の進め方

切替 3～7 日前：対象レコードの TTL を短縮。
切替当日：TXT 検証 → MX/SPF/DKIM → Autodiscover/CNAME → クライアント動作確認。
切替後：バウンス/遅延/迷惑判定のモニタリング。SPF の include ミスや DKIM の selector 不整合を重点確認。

障害を避けるためのアンチパターン

同一ドメインを両テナントに同時登録しようとする（構造的に不可）。
段取りなしにルートドメインをいきなり移す（広範囲の停止）。
DNS/メール/ID の責任分界を曖昧にする（運用事故の温床）。
外部管理者に恒久の高権限を付ける（PIM 不使用、監査なし）。

チェックできる「できる/できない」一覧

要件	可否	代替策/補足
@company.com を 2 つのテナントで同時利用	不可	サブドメイン/別ドメインを新テナントで利用
新テナント作成	可能	自動で `*.onmicrosoft.com` が割当
@company.com のまま新テナント管理	可能	B2B（外部ユーザー）＋ロール割当。ドメイン登録は不要
ルートドメインの移行	可能（非推奨）	旧テナントから完全削除 → 新テナントで検証 → DNS 切替

最後に

「別テナントを作りたい」「同じドメインを使いたい」という要望は、しばしば単一の解に収束しません。本記事の枠組み（排他制約 → 代替策 → 運用設計）に沿って、リスクの小さい順に検討し、サブドメインまたは別ドメインでの運用・B2B/同期の活用を第一選択肢に据えることをおすすめします。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

【完全ガイド】Microsoft 365／Azure（Microsoft Entra ID）の別テナント新規作成とカスタムドメイン重複制限の回避策

結論と前提（要点の先出し）