Azure AD とテナントの関係 — Microsoft クラウドサービスを使うなら絶対に知っておくべきこと

この記事の内容

• Microsoft 365 を契約すると Azure Active Directory（Azure AD）が自動的に作成され、ライセンスとユーザー管理の基盤になります
• Azure はユーザー単位のライセンスではなく従量課金のため、Azure AD との紐付け方が M365 とは異なります
• Azure のサブスクリプションは別の Azure AD に付け替えができるという、他のサービスにはない特徴があります
• 何も意識せずに進めると Azure AD が複数作られてしまい、セキュリティ管理・コスト・運用に問題が生じます
• 組織では Azure AD を 1つに統一する ことが強く推奨されます

Microsoft 365 契約時に起きていること

Microsoft 365 を契約すると、まず Azure Active Directory（Azure AD）が1つ作成されます。これを意識していない方も多いですが、Microsoft 365 を使っている以上、Azure AD を使っていないということはありません。必ず紐付きます。

その構造は次のとおりです。

1. Azure AD が作成される
2. 購入したライセンスが Azure AD に紐付く
3. Azure AD 内にユーザー（組織アカウント）を作成する
4. ユーザーにライセンスを割り当てる
5. ライセンスを持つユーザーが各サービスを利用できるようになる

たとえば Exchange Online を契約すると、ライセンスを割り当てられたユーザーにメールボックスが作成されます。Dynamics 365 や Power BI を追加契約した場合も同様に、そのライセンスを Azure AD に紐付けてユーザーに割り当てることでサービスが使えるようになります。

この「テナント」と呼ばれる単位が、その企業が Microsoft のクラウドサービスを使っている範囲を表しています。

ポイントまとめ（M365 系サービス）

• Azure AD は 1つだけ 作成される
• ライセンスは Azure AD に紐付く
• ユーザーにライセンスを付与することでサービスが使えるようになる

Azure は仕組みが異なる

Microsoft 365 などユーザーライセンス型のサービスとは異なり、Azure は従量課金制です。そのため、考え方が少し異なります。

Azure を契約すると、サブスクリプションという課金単位を作成できます。このサブスクリプションの中に仮想マシンやストレージなどの Azure リソースを作成し、使った分だけ支払います。

ただし、Azure サブスクリプションも必ず Azure AD に紐付きます。サブスクリプション内のリソースを管理する「管理者アカウント」は Azure AD の中に存在します。

Azure だけの特徴：Azure AD の付け替えができる

Azure サブスクリプションには、M365 系サービスにはない大きな特徴があります。それは、サブスクリプションを別の Azure AD に付け替えられるという点です。

この「付け替え可能」という特性が、後述するトラブルの原因にもなります。Azure のサブスクリプションはどの Azure AD にも紐付けられるため、「テナントはどこか」と言い切るのが難しい構造になっています。

また、Azure の課金はユーザー単位ではなく、サブスクリプション単位の従量課金です。この点も M365 系とは根本的に異なります。

よくある失敗：Azure AD が複数できてしまう

何も意識せずに進めると、次のような状況になりがちです。

1. Microsoft 365 を契約 → Azure AD が1つ作成される（M365 用）
2. 後から Azure も契約 → 別の Azure AD が自動的に作成される
3. さらに別の Azure サブスクリプションを作成 → またも別の Azure AD ができる

気が付くと Azure AD が複数存在する 状態になってしまいます。動作はするものの、以下の問題が生じます。

問題1：同じ人が複数の Azure AD にアカウントを持つことになる

Aさん、Bさん、Cさんが M365 の管理と Azure の管理を両方担当している場合、それぞれの Azure AD に同じ人のアカウントを作ることになります。

• アカウントのドメインが異なる（例：a@contoso.com と a@contoso.onmicrosoft.com など）
• 複数のパスワードが発生する
• 管理が煩雑になる

問題2：セキュリティポリシーが分断される

多要素認証や条件付きアクセスなどのセキュリティ機能（Azure AD Premium が必要）を導入しようとしても、Azure AD が複数あると それぞれの Azure AD に個別にライセンスを購入して設定する 必要が生じます。

• M365 用の Azure AD にセキュリティポリシーを設定しても、Azure 用の別の Azure AD は守られない
• 同じメンバー（AさんBさんCさん）のために Azure AD Premium を複数購入することになり、コストが増大する

推奨構成：Azure AD は組織で1つに統一する

すべての Microsoft クラウドサービスを 1つの Azure AD に集約することが、シンプルで合理的な構成です。

この構成のメリットは以下のとおりです。

• シングルサインオン：1つのアカウントで M365 も Azure も他の SaaS も使える
• 一元的なセキュリティ管理：多要素認証・条件付きアクセスが全サービスに適用される
• コスト効率：Azure AD Premium などのライセンスを重複購入しなくて済む
• 管理の簡素化：ユーザーアカウントが1つで済む

Microsoft 自身もこの構成を推奨しています。

テスト環境を作るときの注意点

本番導入前にテストテナントを作成することはよくあります。しかし、無償のテストテナントでテストし、そのまま本番契約をテストテナントに紐付けてしまうケースが多く見られます。

テナント名が「なんとかテスト」のような名前になってしまい、本番で使うには見栄えが悪くなります。

正式に本番利用するときは、本番用の名前で Azure AD を作成し、そこにライセンスを紐付けることを心がけてください。

すでに Azure AD が複数できてしまっている場合

気づいたら すぐに対応する ことが重要です。Azure を使えば使うほど、付け替え作業は複雑になります。

対応の方針は以下のとおりです。

1. 新規のサブスクリプションは必ず M365 と同じ Azure AD に紐付ける
2. 既存の誤った Azure AD に紐付いているサブスクリプションは、順次切り替える（影響範囲を確認しながら慎重に）
3. システムのライフサイクルが終わるタイミングで廃止するという選択肢もある

なお、M365 のテナント（Azure AD）はドメイン名を実質的に変更できないため、最初から正しい名前で作ることが重要です。Azure サブスクリプション側は付け替え機能があるので、そちらで対応します。

放置すると Azure AD がどんどん増えて収拾がつかなくなります。気づいた時点が一番早いタイミングです。

まとめ

• Microsoft 365 を契約すると Azure AD が自動的に作成され、すべてのライセンスとユーザーの基盤になります
• Azure は従量課金でサブスクリプション単位の管理ですが、必ず Azure AD に紐付きます。また Azure AD の付け替えができるという特殊な仕様があります
• 何も意識しないと Azure AD が複数作成されてしまい、セキュリティの分断・コストの重複・管理の複雑化という問題が起きます
• 組織の Azure AD は1つに統一する ことが Microsoft も推奨するベストプラクティスです
• すでに複数の Azure AD ができてしまっている場合は、気づいた今すぐ対処を始めることが重要です。使えば使うほど修正コストは増大します