Microsoft Entra ID（旧 Azure AD）のディレクトリ（テナント）を別アカウントに切り替えた後、元のメインアカウントへ戻せず「変更できるのは管理者のみ」エラーで詰まることがあります。本記事では切り分けポイントと、最短で復旧するための Microsoft サポート依頼手順をまとめます。
症状：ディレクトリ（テナント）を戻そうとしても「管理者のみ変更可能」で止まる
Microsoft Entra ID（旧 Azure AD）では、サインインしているディレクトリ（＝テナント）により、Azure ポータルで見えるユーザー・グループ・アプリ、そしてサブスクリプションの操作可否が変わります。ところが、一度「別アカウント側（別テナント）」に切り替えたあと、元のメインアカウントへ戻そうとしても、次のような状態になることがあります。
- ディレクトリ切り替え時に
only admins can do changes（変更できるのは管理者のみ）相当のエラーが表示され、元に戻せない - 対象アカウントに Azure 側の Owner（所有者） を付与しても改善しない
- サブスクリプション移管（Subscription transfer / テナント変更）を進めようとしても、途中で失敗して詰まる
この状況は、権限不足というより「既定（デフォルト）ディレクトリの紐づけ」や「ホームテナントの扱い」が絡んだ“詰み状態”になっているケースがあり、ポータル上のロール付与だけでは解けないことがあります。
結論：Microsoft サポートで既定（デフォルト）ディレクトリを本来のアカウントへ移管してもらう
本件の解決策はシンプルで、最終的にはMicrosoft サポートに連絡してチケットを起票し、サポート側で「既定（デフォルト）ディレクトリ」を本来のメインアカウントへ移管してもらう必要があります。
「Owner を付けたのにダメ」「Global Administrator も付けたはずなのにダメ」という場合でも、バックエンドでのテナント紐づけ調整が必要なことがあります。自力で無理にこねくり回すより、必要情報をそろえてサポートに依頼した方が結果的に早いです。
まず押さえるべき前提：Owner と テナント管理者は別物
トラブルを長引かせる最大の原因は、「Azure サブスクリプションの権限」と「Entra ID（テナント）の管理権限」を混同することです。よくある権限を整理すると、次のようになります。
| 権限（例） | 付与先 | できること（代表例） | できないこと（代表例） |
|---|---|---|---|
| Owner（所有者） | Azure サブスクリプション／リソース | リソース作成・削除、RBAC 付与、課金範囲内の操作 | Entra ID 側の管理者操作（テナント設定変更、ユーザーのテナント所属の変更など） |
| Global Administrator（全体管理者） | Entra ID（テナント） | ユーザー／グループ／アプリ登録、テナント設定、条件付きアクセスなど | Azure の課金・請求・移管の一部（契約形態に依存）、サブスクリプションの所有者権限そのもの |
| Billing / Account Administrator（請求・アカウント管理） | 課金アカウント（契約） | サブスクリプション移管や課金関連の操作 | テナントのセキュリティ設定、Azure リソース操作（RBAC が別途必要） |
今回のように「ディレクトリ（テナント）を戻せない」「サブスクリプション移管が失敗する」問題は、上記の権限が複合的に絡むうえ、さらに既定ディレクトリの“紐づけ情報”が関係します。そのため、Owner を付けただけでは改善しないことが普通に起こります。
「ディレクトリ切り替え」と「サブスクリプションのテナント変更」は別操作
似た言葉が多く、ここを取り違えると泥沼になります。代表的な操作を分けて考えましょう。
| 操作 | 意味 | 影響 | 失敗しやすいポイント |
|---|---|---|---|
| ポータルのディレクトリ切り替え | Azure ポータルの表示先（どのテナントの情報を見るか）を切り替える | 表示・管理対象のユーザー/グループ/アプリが変わる | 対象テナントに「メンバー」として存在しない／ゲスト扱いで制限がかかる |
| サブスクリプションのディレクトリ変更 | サブスクリプションが紐づくテナント（認証先）を変更する | RBAC、Managed Identity、アプリ登録、Key Vault 参照などに影響 | 移管先テナントの管理者権限、前提条件、サブスクリプション種別の制約 |
| サブスクリプション移管（transfer） | 課金アカウント／契約の移管（請求先変更） | 請求・支払い・契約管理に影響 | Billing 管理者の権限が必要、契約形態により不可 |
今回の症状は「テナント切り替えが戻せない」と見えますが、実際は既定ディレクトリの紐づけが壊れている／想定外の状態になっていることが多く、これがサブスクリプション移管失敗にも連鎖します。
サポートに出す前にできる切り分けチェック
最終的にサポート対応が必要なケースでも、事前に確認しておくとチケットが一発で通りやすくなる項目があります。できる範囲で次をチェックしてください（実際の復旧を保証するものではありません）。
アカウントとテナントが「正しく」選べているか
- Azure ポータル右上のアイコンから、「ディレクトリ + サブスクリプション」（表示名は環境により異なる）で現在のテナントを確認する
- 同じメールアドレスでも、別テナントではゲストとして登録されている場合がある
- 切り替えたい元テナントに、そのユーザーがメンバーとして存在するかを確認する（ゲストだと一部操作が制限されやすい）
テナント管理者ロールが本当に付いているか
「Owner を付けたのに戻せない」の典型は、テナント側で管理者権限が不足しているパターンです。
- 元に戻したいテナントで、対象ユーザーに Global Administrator（全体管理者） 相当が付いているか
- 付与したつもりでも、実際は別テナントに付与していた、というズレが起きやすい
- ロールを付与した直後は反映にラグが出ることがあるため、サインアウト／サインインで再確認する
サブスクリプション側の権限と契約形態を確認する
- サブスクリプションに対して Owner 以上が付いているか（共同管理者では足りないケースがある）
- 課金・契約（MCA/EA/CSP 等）の違いで、移管できる範囲が異なる
- 移管先テナント側で必要な前提（ユーザーが存在、管理者権限がある、ディレクトリ切り替え可能）が整っているか
Tenant ID / Subscription ID の確認方法（サポート提出用）
サポートに連絡する際は ID が重要です。画面で拾える場合は次の場所を確認します。
| 知りたいID | 確認場所（例） | メモ |
|---|---|---|
| Tenant ID（ディレクトリ ID） | Microsoft Entra ID > 概要（Overview） | 「ディレクトリ（テナント）」名が似ている環境ほど、ID で識別するのが安全 |
| Subscription ID | サブスクリプション > 対象サブスクリプションの概要 | 複数サブスクリプションがある場合、間違えると対応が遅れる |
CLI が使える場合は、ログインしているテナントがどこかをコマンドで確認できるため、切り分けに役立ちます。
az account show --query tenantId -o tsv
az account show --query id -o tsv「自力で直る可能性が高い」ケースと「サポート案件」っぽいケース
| 状況 | 見立て | 次の一手 |
|---|---|---|
| 単にテナントを間違えて開いていただけ | 表示の切り替え問題 | ポータルのディレクトリ切り替えで解決することが多い |
| 元テナントで Global Administrator を付けたら直った | 権限不足 | 管理者権限の付与と、再ログインで解決しやすい |
Global Administrator も Owner も揃っているのに only admins can do changes が消えない | 既定ディレクトリの紐づけ（バックエンド）が絡む可能性が高い | サポートに連絡して既定ディレクトリ移管を依頼 |
| サブスクリプション移管が途中で必ず失敗する | 前提条件不足 or 契約制約 or テナント紐づけ問題 | 公式手順の前提条件を再確認しつつ、早めにサポートへ |
サポート対応が必要になる理由：ポータルで触れない“紐づけ情報”がある
Azure ポータルで見えているロールや設定は、あくまで「表側」の設定です。ところが、アカウントとテナントの関係には、次のようなポータルから直接変更できない要素が含まれます。
- Azure アカウントの既定（デフォルト）ディレクトリの扱い
- ユーザーのホームテナント（主所属）の状態と、ゲスト/メンバーの判定
- 契約・課金アカウントとサブスクリプションの内部的な関連
これらが絡んで不整合が起きると、画面上では「管理者のみ変更可能」と出ていても、実際はロール付与では解けない制約に引っかかっていることがあります。ここが、今回のケースでMicrosoft サポートがバックエンド調整を行う必要がある理由です。
Microsoft サポートへ依頼する手順（最短で通る書き方）
サポートに依頼する際は、「何をしてほしいか」を一文で明確にするのが重要です。おすすめの依頼内容は次の通りです。
依頼したいこと：「誤って別アカウント側に切り替わった既定（デフォルト）ディレクトリを、本来のメインアカウント（元テナント）へ移管してほしい。ポータルで元に戻せず only admins can do changes が出る。」
窓口の選び方（迷ったらここだけ押さえる）
- Azure サブスクリプションや課金が絡む場合：まずはAzure ポータルのサポート要求が最短ルートになりやすい
- 契約が CSP の場合：パートナー経由のサポートが必要になることがある
- Microsoft 365 契約で Entra ID 側の問題として扱う場合：Microsoft 365 側のサポート窓口になることもある
どの窓口でも、最終的に必要なのは「既定ディレクトリ（デフォルト）の紐づけを戻す」という作業である点は同じです。チケット本文に“既定ディレクトリの移管が必要”を明記すると、適切なチームへエスカレーションされやすくなります。
チケット作成の流れ（迷ったらこの流れ）
- Azure ポータルでサインイン（該当サブスクリプションにアクセスできるアカウント）
- 「ヘルプ + サポート」から 「新しいサポート要求」 を作成
- 問題の種類は、まずはサブスクリプション管理／ディレクトリ（Entra ID）関連を選ぶ（選択肢は契約・環境で変わります）
- 本文に、元テナントと現在のテナントの情報、発生しているエラー、やったこと、希望する着地点を整理して書く
サポートに渡すと話が早い情報
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 元テナントの Tenant ID（ディレクトリ ID） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 「戻すべき先」を特定するため |
| 現在紐づいているテナントの Tenant ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 「いま何に紐づいているか」を特定するため |
| 対象サブスクリプション ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 影響範囲（どのサブスクリプションか）を特定するため |
| 対象ユーザー（ログインアカウント） | [email protected] | 既定ディレクトリの紐づけ対象を特定するため |
| エラー全文と発生画面 | スクリーンショット／時刻 | 制約の種類を切り分けるため |
| 実施済みの対処 | Owner 付与、Global Admin 付与、再ログイン等 | 二度手間を避けるため |
サポートへの依頼文テンプレ（コピペ用）
次の文面をベースに、Tenant ID と Subscription ID を置き換えて送ると通りやすいです。
Azure ポータルでディレクトリ（テナント）を切り替えた後、元のメインアカウント／元テナントに戻せなくなりました。ディレクトリ切り替えやサブスクリプションのディレクトリ変更を行おうとすると「only admins can do changes（変更できるのは管理者のみ）」が表示され、操作できません。
・戻したい（本来の）テナント：Tenant ID = 【元テナントID】
・現在紐づいているテナント：Tenant ID = 【現テナントID】
・対象サブスクリプション：Subscription ID = 【サブスクリプションID】
・対象ユーザー：【ログインアカウント】
Owner（所有者）付与や、テナント側管理者ロール付与、再ログイン等を試しましたが改善しません。バックエンド側で既定（デフォルト）ディレクトリの紐づけを本来のメインアカウント（元テナント）へ移管いただけないでしょうか。
サポート対応後にやるべき確認と“落とし穴”
サポートで既定ディレクトリが移管されると、ポータル上はスッと戻ることが多い一方で、次の確認をしないと「戻ったはずなのに、一部の操作だけ失敗する」が起きがちです。
まず確認すること
- ポータルでディレクトリを切り替え、元テナントが正しく選べること
- 対象サブスクリプションが元テナント側で表示され、開けること
- 「権限がない」と出る場合は、RBAC がテナント変更の影響を受けていないか（後述）
RBAC と ID 参照のズレに注意
テナントが変わると、同じ表示名のユーザーでも内部 ID（オブジェクト ID）が変わることがあります。次のようなポイントは、後から権限問題として噴き出しやすいです。
- リソースグループやサブスクリプションの RBAC 付与先（ユーザー／グループ／サービスプリンシパル）
- Managed Identity を参照している Key Vault アクセスポリシーやロール
- DevOps や CI/CD のサービス接続（Service Principal）
サポート対応で戻った直後は、「重要リソースにアクセスできるか」を優先して点検し、必要なら RBAC を付け直してください。
再発防止：同じ事故を起こさない運用のコツ
ディレクトリ（テナント）切り替えやサブスクリプション移管は、正しくやれば便利ですが、“誰が・どのテナントで・何を変更したか”が曖昧なまま進めると復旧コストが跳ね上がる作業です。再発防止として、次の運用をおすすめします。
テナント情報を資産として管理する
| やること | 狙い | 具体例 |
|---|---|---|
| Tenant ID とドメインを台帳化 | 切り替えミスを減らす | 「本番テナント」「検証テナント」「個人テナント」を明確に区別 |
| グローバル管理者の“非常用”アカウントを用意 | ロックアウト対策 | 多要素認証を前提に、日常利用しないアカウントを保持 |
| サブスクリプション操作は役割分担 | 事故の影響範囲を限定 | 課金管理者と運用管理者を分け、手順書に沿って実施 |
「切り替え」前のチェックリストを作る
- 今ログインしているのはどのテナントか（Tenant ID で確認）
- 切り替え先テナントで自分はメンバーかゲストか
- 切り替え先テナントに全体管理者が存在し、非常時に復旧できるか
- 対象サブスクリプションの契約形態と、移管の可否・制約を事前に把握したか
よくある質問
Owner（所有者）を付けたのに「管理者のみ変更可能」が消えません
Owner は Azure 側のリソース権限であり、テナントの管理者権限や既定ディレクトリの紐づけ問題には効かないことがあります。Global Administrator を確認しても改善しない場合は、今回のケースのようにサポートのバックエンド作業が必要な可能性が高いです。
サブスクリプション移管と、ディレクトリ（テナント）切り替えは同じですか？
同じではありません。ディレクトリ切り替えは「ポータルの表示先」を変える操作で、移管は「認証先や請求先の紐づけ」を変える操作です。目的が違うため、必要な権限も前提条件も変わります。混同したまま進めると、今回のように復旧が難しくなることがあります。
サポートに出すとき、どこまで情報を書けばいいですか？
最低限、元テナントID／現在のテナントID／サブスクリプションID／対象ユーザー／エラー文が揃っていると、やり取りが短くなります。スクリーンショットがあるとさらに早いです。
まとめ：詰み状態は早めにサポートへ、必要情報をそろえるのが最短ルート
Entra ID（Azure AD）のディレクトリ（テナント）を別アカウントに切り替えたあと、元に戻せない「変更できるのは管理者のみ」エラーに遭遇した場合、単なるロール不足ではなく既定（デフォルト）ディレクトリの紐づけ不整合が原因になっていることがあります。Owner 付与で粘るより、状況を整理して Microsoft サポートに依頼し、既定ディレクトリを本来のアカウントへ移管してもらうのが現実的な解決策です。
コメント