Microsoft Entra ID（旧Azure AD）に自社ドメインを追加しようとしたら「このドメインはすでに別のディレクトリ（テナント）で使用されています」と表示されて詰まる――そんなときに、原因の切り分けから解決までの現実的な手順をまとめます。
よくある症状：「このドメインはすでに別のディレクトリで使用されています」
Entra 管理センター（または Microsoft 365 管理センター）でカスタムドメイン（独自ドメイン）を追加し、DNS の検証を進めようとすると、次のような状態になります。
- 追加しようとするとエラーになり、検証画面まで進めない
- 「このドメインはすでに別のディレクトリで使用されています」「This domain is already in use in another directory」などのメッセージが出る
- 過去に誰かが別の Microsoft 365 / Entra テナントでそのドメインを登録した覚えがあるが、当時の管理者が退職・委託先で不明
結論から言うと、そのドメインが“どこかのテナントに紐づいたまま”なので、今使いたいテナントで検証できないのが原因です。まずは「どのテナントに紐づいているか」を特定し、状況に応じて旧テナントからドメインを外す、もしくはMicrosoft サポート（Data Protection チーム）に解除してもらうという二択になります。
前提知識：同じドメインは複数テナントで同時に使えない
カスタムドメイン（例：example.com）は、Entra ID では「検証済み（Verified）」になることで、そのテナントのユーザー UPN（サインイン名）や Microsoft 365 のメールアドレス等に利用できるようになります。
重要なのは、同じ独自ドメインを同時に 2 つ以上のテナントで “検証済み” にすることはできないという点です。さらに厄介なのは、ドメインが “追加済み（未検証）” であっても、テナント側にぶら下がっている限り、別テナントで追加できないケースがあることです。
| 項目 | オンプレ/ローカルの感覚 | Entra ID（テナント）の挙動 | 実務上の注意 |
|---|---|---|---|
| ドメインの唯一性 | DNS を触れれば取り合い可能に見える | 1 ドメイン＝1 テナントに紐づく（排他） | 旧テナントから外さない限り、新テナントで検証できない |
| 管理者不在 | 社内で権限を付け替えれば復旧できる | そのテナントの管理者に入れないと操作不能 | 最終的に Microsoft サポートへの依頼が必要になる |
| 影響範囲 | メールだけの問題に見えがち | サインイン、Teams、SharePoint、Intune、アプリ連携など広範囲 | 解除・移行の前に「どこで使っているか」の棚卸しが重要 |
最初にやるべき棚卸し：何がどこまで影響するか
「とにかく外して新テナントへ」へ走る前に、次の 2 点を短時間でもよいので確認してください。
- そのドメインで運用していた（している）サービス：Microsoft 365（Exchange Online/Teams/SharePoint）、Azure サブスクリプション、アプリの SSO など
- 旧テナントを作った可能性のある人物・組織：退職者、委託先、グループ会社、過去の SIer 等
| 確認したいこと | 確認のヒント | 分かると何が嬉しいか |
|---|---|---|
| 旧テナントが本当に存在するか | 過去の請求メール、クレカ/請求書、社内の共有メールボックス、情シス台帳 | サポート依頼の “正当性” と “優先度” が決まる |
| どのユーザーがそのドメインでサインインしていたか | 過去の手順書、端末の資格情報、サインイン画面の入力履歴 | ログイン復旧できる可能性が上がる（自力解除ルート） |
| メール運用の有無 | MX レコード、メールサーバー、Exchange Online の利用履歴 | ドメイン解除でメールが止まるリスクを事前に把握できる |
| 社外アプリ連携の有無 | SAML/OIDC の設定資料、SaaS 側の SSO 設定（IdP が Microsoft になっていないか） | ドメイン移行時のログイン障害を最小化できる |
ドメインが紐づいているテナント ID を特定する
「どのテナントに紐づいているか」が分からないと、次のアクション（ログイン復旧・サポート依頼）が進みません。代表的な特定方法は次のとおりです。
方法A：テナントID検索サイトで調べる
whatismytenantid.com のような “ドメイン → テナントID” を引けるサイトに、自社ドメイン（例：example.com）を入力すると、紐づいているテナント ID が表示されることがあります。
- メリット：手早い、ログイン不要
- 注意点：第三者サイトに自社ドメインを入力することになるため、社内ポリシーに従う
方法B：OpenID 構成エンドポイントから推測する
外部サイトの利用を避けたい場合、サインイン基盤の公開エンドポイントから、テナント情報の手がかりを得られることがあります。たとえば次の URL は、ドメインを指定して OpenID Connect の構成情報を返します。
https://login.microsoftonline.com/<ドメイン>/v2.0/.well-known/openid-configuration返ってきた JSON の中に、issuer や authorization_endpoint などの値として、テナント GUID が含まれる場合があります（環境・設定により必ず出るとは限りません）。
補足として、検索結果がうまく出ない／情報が揃わない場合でも焦る必要はありません。実務では「テナント ID が分かった時点で勝ち筋が見える」ことが多く、残りは ログイン復旧 か サポート手続き のどちらかに整理できます。
旧テナントに入れないときに試すログイン復旧のチェック
サポートへ進む前に、社内でできる “合法かつ現実的” な確認をまとめます。ここで入れるようになると、ドメイン削除まで自力で進められる可能性があります。
| チェック項目 | 具体的なやり方 | 見つかること |
|---|---|---|
| 管理者候補のメールアドレスを洗い出す | admin@、it@、info@、support@ など過去の命名規則を確認。過去の手順書・パスワード管理ツール・退職者引き継ぎ資料も検索 | サインインできる可能性が高いアカウント |
| Microsoft からの通知メールを探す | 請求書、試用版開始、サブスクリプション更新、セキュリティ通知などを社内メールで全文検索 | テナント名（*.onmicrosoft.com）や管理者の痕跡 |
| Azure/Microsoft 365 の請求元を確認する | 法人クレカの明細、経理の支払い履歴、購買システムの発注書を確認 | 契約主体、購入チャネル、サポート窓口の手がかり |
| テナント指定でサインインを試す | https://portal.azure.com/<テナントID> を開き、心当たりアカウントでサインイン。必要なら “パスワードを忘れた” を試す | 誤ったテナントへ入っていた問題の切り分け |
| 委託先・SIer の関与を確認する | 過去の契約書/見積書/作業報告書で「テナント作成」「初期構築」の記載を探す | 誰が作成し、どこに引き継ぎがあるか |
ここで注意したいのは、心当たりのないテナントに対して推測でログインを試し続ける行為は、セキュリティ的にも監査的にも望ましくありません。あくまで “自社の正当な管理範囲で、根拠のあるアカウント候補” に絞って確認し、判断に迷う場合はサポートに切り替えるのが安全です。
ログインできるなら自力で解除できる：旧テナントからドメインを外す
テナント ID が分かり、かつ管理者としてサインインできるなら、解決は比較的シンプルです。旧テナント側でドメイン参照をすべて外し、最後にドメイン削除を実行します。
サインインのコツ：テナントを指定して入る
https://portal.azure.com/<テナントID>（テナントを明示して Azure ポータルへ）https://entra.microsoft.com（Entra 管理センター）
サインインに成功しても、複数テナントを持っている場合は意図せず別テナントが開くことがあります。画面右上のアカウントメニューから “ディレクトリの切り替え” を確認し、必ず該当テナントにいる状態で作業します。
ドメイン削除でつまずく原因：依存関係が残っている
ドメインは「ぶら下がっているもの」が 1 つでもあると削除できません。特に Microsoft 365 を併用していると、Entra だけでなく Exchange/Teams 側にも依存が潜みます。
| よくある依存関係 | 具体例 | 外し方（代表例） |
|---|---|---|
| ユーザーの UPN（サインイン名） | [email protected] でサインインしている | 一時的に *.onmicrosoft.com へ変更してから削除 |
| メールアドレス（Exchange Online） | プライマリ SMTP / エイリアスにドメインが残っている | メールアドレスポリシーや受信ドメインを整理してから削除 |
| Microsoft 365 グループ/共有メールボックス | グループのメールが @example.com | メールアドレス/プライマリを別ドメインへ変更 |
| アプリの Reply URL / Identifier URI | SAML/OIDC で https://example.com/... | アプリ登録やエンタープライズアプリの設定を修正 |
| 条件付きアクセス/証明書系 | ドメインに依存したルールや証明書の CN | 影響を確認し、段階的に切り替え |
“最後の 1 ユーザー” 問題を避けるためのブレークグラス設計
ドメインを外す作業中に「管理者が自分しかいない」「UPN を変えたらサインインできなくなった」という事故が起きがちです。安全策として次を用意してから触るのが鉄則です。
- 少なくとも 2 つの全体管理者（Global Administrator）を用意する
- そのうち 1 つは
*.onmicrosoft.comの管理者アカウント（ドメイン解除の影響を受けない）にする - MFA/条件付きアクセスで締めすぎて自分で詰まないよう、緊急用の例外設計をする
参考：UPN を一括で退避する例
運用環境により手段は異なりますが、「一時的に UPN を *.onmicrosoft.com に戻す」作業は発生しがちです。以下はイメージです（実行は環境検証のうえで）。
# 例：PowerShell で UPN を置換するイメージ（実行前に必ず検証）
# [email protected] → [email protected]作業の実体は「参照の棚卸し → 置換 → 再確認」です。削除ボタンを押す前に、管理センター側の “削除要件チェック” を通るまで丁寧に潰します。
ログインできない場合：公開情報だけでは解決できない
本題のケースはここです。
- テナント ID は特定できた
- しかしそのテナントの管理者アカウントやパスワードが分からず、サインインできない
- 「誰が作ったテナントか知りたい」「とにかくドメインだけ外したい」
残念ながら、外部から勝手にテナント情報を開示・変更することはできません。これはセキュリティとプライバシー保護のためで、当然の制約です。よって、この状況で現実的に進める手段は次の一択になります。
Microsoft サポートにチケットを起票し、Data Protection（データ保護）チームへエスカレーションしてもらう
Microsoft サポートに依頼する手順：Data Protection へのエスカレーション
ポイントは「サポートに丸投げ」ではなく、サポートが動けるだけの材料を最初から揃えることです。準備が整っているほど、やり取りの往復が減り、結果として解決が早まります。
サポート対応で起きやすい流れ
「管理者不明のテナントに残ったドメインを外したい」ケースでは、一次サポートだけで完結せず、データ保護の専門チームに引き継がれることが多いです。実際の流れは概ね次のイメージになります。
- サポートが状況を整理し、対象ドメインと該当テナントを特定する
- ドメイン所有者であることの確認を実施する（DNS TXT 追加、契約情報、必要に応じて電話などのオフライン確認）
- 確認が取れたら Data Protection チームへエスカレーションされ、ドメイン解除や必要な調整がチケット経由で進む
重要なのは、サポートはセキュリティ手続きを省略して「すぐ外す」ことはできないという点です。逆に言えば、証明材料が揃っていれば、正規手続きとして前に進みます。
チケット起票前に用意したい情報
| 用意するもの | 具体例 | なぜ必要か |
|---|---|---|
| 対象ドメイン | example.com（サブドメインもあれば併記） | 問題の特定の起点になる |
| 紐づいているテナント ID（判明分） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | サポート側が “どのディレクトリに刺さっているか” を追える |
| 現在使いたいテナント ID | 新テナントの GUID / tenant.onmicrosoft.com | 解除後に “どこへ移すのか” が明確になる |
| ドメイン所有の証明 | DNS TXT 追加、レジストラ画面、契約書/請求書、登記情報など | なりすまし防止。Data Protection チームが最重視する |
| 影響範囲の整理 | メール運用の有無、利用予定サービス（M365/SSO 等） | 解除に伴う影響説明・判断材料になる |
サポートへの伝え方：文章テンプレ
チケット本文は、次の 3 点を短く明確に書くのがコツです。
- 何ができないか：新テナントでカスタムドメインを追加・検証できない
- なぜ困るか：ユーザーのサインイン名/メールを統一できない、個人アカウントとの混在が解消できない
- どこに紐づいているか：判明している旧テナント ID（分かる範囲で）
件名例：
カスタムドメインが別テナントに登録されており Entra ID に追加できない（管理者不明）
本文例：
当社所有の example.com を Microsoft Entra ID テナント（新テナント：<新テナントID>）に追加しようとすると、
「このドメインは既に別ディレクトリで使用されています」となり検証できません。
調査の結果、example.com は別テナント（旧テナントID：<旧テナントID>）に紐づいていることが分かりましたが、
旧テナントの管理者アカウントが不明でサインインできず、ドメイン削除ができません。
ドメイン所有者である証明（DNS TXT 追加など）は可能です。
Data Protection チームへのエスカレーションのうえ、ドメインの解除/移行手続きの支援をお願いします。証明で求められがちなもの：実務目線
Data Protection 側は「あなたが本当にドメイン所有者か」を確認します。最も強いのは DNS を直接操作できることです。
- DNS TXT レコードの追加（指定された文字列を公開する）
- レジストラ（ドメイン管理会社）の管理画面の情報
- 法人の場合：会社情報（登記・契約） など、組織としての正当性が分かる資料
社内稟議やセキュリティ審査で詰まらないよう、DNS 変更の承認フローも早めに確保しておくとスムーズです。
ドメインが外れたら：新テナントに追加して検証する
旧テナントからドメインが完全に削除（解除）されると、新テナント側で追加・検証が通るようになります。ここからは “やっと通常運用の手順” です。
追加・検証の基本ステップ
- Entra 管理センター（または Microsoft 365 管理センター）で「カスタムドメインの追加」へ進む
- 表示される DNS レコード（多くは TXT）をドメインの DNS に追加する
- 検証を実行し、Verified になったことを確認する
- 必要に応じて、ユーザーの UPN を新ドメインへ切り替える
ドメイン検証が完了したら、次に多い作業が ユーザーの UPN 切り替え です。UPN を変えると、利用者側では次のような影響が出ます。
| 変更内容 | 利用者に起きやすいこと | 事前にやると安全なこと |
|---|---|---|
| サインイン名（UPN）変更 | Office/Teams/OneDrive で再サインインが求められる、保存済み資格情報が効かなくなる | 周知文を用意し、切替後のサインイン手順を統一する |
| メールアドレスの主ドメイン切替 | 外部への通知が必要、差出人表記が変わる | エイリアス運用期間を設け、転送・受信テストを実施する |
| SSO 連携の切替 | SaaS で再連携が必要になることがある | SaaS 側の IdP 設定、証明書更新手順、緊急時のローカル管理者を確認 |
| レコード種別 | 主な用途 | よくあるつまずき |
|---|---|---|
| TXT | ドメイン所有確認（検証） | 追加先のゾーン間違い、反映待ち、重複レコード |
| MX | メール受信（Exchange Online 等） | 旧メールサービスの MX が残り続ける |
| SPF（TXT） | 送信ドメイン認証（なりすまし対策） | 複数 TXT の統合ができず SPF が壊れる |
| DKIM/DMARC | 送信メールの信頼性向上 | 運用の責任者が曖昧で放置されがち |
個人用アカウントを「会社の組織アカウント」に切り替えたい場合の考え方
ここが地味にハマりどころです。個人用 Microsoft アカウント（MSA）と、職場/学校アカウント（Entra ID）のアカウントは別物で、原則として “変換” はできません。できるのは、混在を解消し、社内利用を組織アカウントに寄せることです。
まず整理：同じメールアドレスに「個人」と「職場」がぶら下がっていないか
過去に社員が会社のメールアドレスで個人用 Microsoft アカウントを作ってしまうと、サインイン時に「個人アカウント」「職場または学校アカウント」を選ばされることがあります。運用を安定させるには、会社のアドレスは “職場アカウント専用” に寄せるのが基本です。
| 状況 | 症状 | おすすめ対応 |
|---|---|---|
| 会社メールで個人用 Microsoft アカウントを作っている | サインイン時にアカウント選択が出る／個人側にデータが散らばる | 個人アカウントのサインインID（エイリアス）を私用メールに変更し、会社メールを外す |
| 会社の Entra ID に同じアドレスのユーザーを作る予定 | ユーザー作成はできても利用者が混乱する | 社内周知＋移行手順を作る（Teams/OneDrive/Office のサインイン手順を統一） |
| 既に Teams Free 等を個人で使っている | 会議履歴やファイルが個人側に残る | 必要データをエクスポート/移行し、業務利用は職場アカウントへ切替 |
会社メールが個人用 Microsoft アカウントに紐づいている場合の外し方
混在を解消するうえで、実務的に最も効果が高いのが「個人用 Microsoft アカウントのサインインIDを私用メールへ寄せる」対応です。一般的には次の流れになります。
- 個人用 Microsoft アカウントにサインインし、アカウント情報の画面を開く
- 「サインイン方法の管理」などのメニューから 別のメールアドレスをエイリアスとして追加する
- 追加したエイリアスを プライマリ（優先） に設定する
- 会社メール（例：[email protected]）がエイリアスとして登録されている場合は、業務影響を確認したうえで 削除 する
この操作により、個人側のサインインは私用メールへ寄り、会社メールは “職場アカウント専用” として整理しやすくなります。なお、業務で使っていた個人側データがある場合は、削除前にバックアップや移行を行ってください。
OneDrive/Office データ移行の現実解
個人用 OneDrive から法人用 OneDrive（OneDrive for Business）への移行は、「ボタン 1 つで全移行」というより、共有→コピー または ローカル同期→アップロード のような現実的な手段になります。移行対象の量や権限設計にもよりますが、よく使われる流れは次の通りです。
- 個人用 OneDrive で対象フォルダを職場アカウントに共有（閲覧だけでなく編集可能に）
- 職場アカウント側で “コピーして自分の OneDrive に保存” を実施
- 移行後、共有リンクや外部共有の設定を見直す（情報漏えい対策）
再発防止：ドメインとテナントを「属人化」させない運用
今回の問題は、技術というより運用で再発しやすいトラブルです。次のルールを決めておくと、数年後の自分（または後任）が助かります。
最低限の運用ルール：チェックリスト
- 全体管理者は 2 名以上。うち 1 名は
*.onmicrosoft.comの緊急用アカウントを用意する - 管理者の退職・委託終了時に “テナント管理権限の返却” をチェック項目に入れる
- ドメイン追加・削除の履歴（いつ・誰が・なぜ）をチケット/台帳に残す
- DNS 管理（レジストラ）のアカウントも属人化させない（社用共有で管理）
- 「会社メールで個人用 Microsoft アカウントを作らない」ことを周知する
事故を減らすための設計ポイント
ドメインは “サインインの入口” です。入口が壊れると、メールだけでなく、SSO している業務システム全体が止まります。次のような設計をしておくと、障害時の復旧が段違いです。
- SSO 連携している SaaS を一覧化し、IdP（Entra）変更時の手順を用意する
- 条件付きアクセスは強化しつつ、緊急復旧ルート（管理者のサインイン）を残す
- 社外委託先には “テナントを作らせない/作るなら契約で引き渡しを義務化” を明記する
よくある質問
テナント ID が分かれば、DNS を操作して強制的に取り戻せますか？
できません。DNS の所有は重要な証明材料ですが、テナント側のドメイン登録を外す操作は、管理者権限または Microsoft の正式手続きが必要です。
旧テナントを削除すればドメインも自動的に外れますか？
ケースによります。サブスクリプション状態や保持期間等で挙動が変わるため、「削除すれば解決する」とは考えない方が安全です。基本は “旧テナントからドメインを削除する” をゴールに据えます。
サポートは旧テナントの管理者情報を教えてくれますか？
プライバシーとセキュリティの観点から、他テナントの詳細情報が開示されないことが一般的です。目的は「ドメインを正しいテナントで使える状態にする」ことに置き、開示に期待しすぎない方が進みやすいです。
まとめ：最短で解決するためのロードマップ
最後に、やることを一直線にまとめます。
| ステップ | やること | ゴール |
|---|---|---|
| 特定 | ドメインが紐づくテナント ID を把握する（検索サイト/公開エンドポイント） | “どこで詰まっているか” が明確になる |
| 自力解除を試す | ログイン復旧（心当たりの管理者アカウント、パスワードリセット、社内調査） | 旧テナントに入れれば、自分でドメイン削除まで進める |
| サポート依頼 | ログインできないなら Microsoft サポートへ。Data Protection へエスカレーション | 正規手続きでドメインを解除してもらう |
| 新テナントへ追加 | 新テナントでドメイン追加・DNS 検証・UPN 切替 | 会社の組織アカウント運用に統一できる |
| 整理と再発防止 | 個人アカウント混在の整理、管理者・DNS・台帳の運用整備 | 次回同じ事故を起こさない |
コメント