IDディレクトリ・テナントは絶対に1つがいい！その理由と背景

この記事の内容

Azure AD（Microsoft Entra ID）のテナントを複数作ってしまう問題とその背景を解説します
オンプレミスのActive Directory時代から繰り返されてきた「複数ディレクトリ」の失敗パターンを振り返ります
テナント分散がなぜ後々の大きな苦労につながるのかを具体例とともに説明します
Microsoftが推奨するシングルテナント・シングルドメインのベストプラクティスについて解説します
短期的な個別最適が長期的な全体最適を妨げる構造的な問題を考察します

テナントが複数に分散してしまうよくある相談

最近、「グローバルにテナントが複数あります。これを1つに統合できますか？」という相談が増えています。さまざまな方がそれぞれに作ってしまったテナントを、あとから修正したくないという状況です。

統合が可能かどうかという話になると、「めちゃくちゃ大変ですよ」という答えになります。そもそもなぜ複数のAzure ADを作ってしまったのか、という話になると、「複数テナントにしたらあとで苦労する」というのは最初から分かりきっている話なのです。

オンプレミスActive Directory時代から続く同じパターン

この問題はクラウドに限った話ではありません。オンプレミスのActive Directory（AD）の時代から、まったく同じことが繰り返されてきました。

NTドメインからActive Directoryへと移行し、フォレストと呼ばれる木構造でドメインを管理するようになりました。複数のフォレスト間で信頼関係を設定することもできましたが、結局どんなテクノロジーでも、「何かを作り、その有効な範囲がある」という構造は変わりません。

グローバルな企業グループでも複数テナントを作ってしまうと、後からの統合作業は非常に困難です。実際に、日本・アメリカ・ヨーロッパにそれぞれADが存在していたものを1つに統合する大プロジェクトが行われた事例もあります。その作業内容は以下のようなものです。

親フォレストとなる集約用フォレストを作成する
ADMT（Active Directory Migration Tool）でユーザーアカウントを移行する
アクセス権を継承・付与し直す
コンピューターを新しいドメインに参加させる
プロファイルを移動する
ローカルのSIDをマッピングして書き換える

世界中の拠点を回りながらこれだけの作業をすることになります。最初からMicrosoftが推奨する「シングルドメイン」のベストプラクティスに従っていれば、必要なかった作業です。何年もかけて、膨大な人数を投入して実施するはめになりました。

クラウド時代にも繰り返される同じ失敗

オンプレミスの苦労を経てクラウドの時代になり、「同じ失敗を繰り返すのはやめましょう」と言い続けているにもかかわらず、Azure ADでも同じことが起きています。

よくあるパターンの1つが、「Office 365を使うためのAzure ADを新しく作った」というものです。既存のオンプレミスADとは別にテナントを作り、後から同期しようとするケースです。これが後々の混乱の元になります。

また、Azure ADにはリージョン（地域）の属性があります。日本のテナント、アメリカのテナントというように、リージョンによって使えるサービスや契約できる機能が異なる場合があります。「このユーザーではこのサービスが使えないけれど、別のリージョンのテナントなら使える」という理由で別テナントを作り出す人たちが出てくると、どんどんカオスな状態になっていきます。

テナントを1つに保つことが正解である理由

グループ企業でも、テナントは1つに統一してみんなが仲良く使うのが正しい姿です。Azure ADのガバナンスをきちんと管理し、誰がどのアプリケーションを作れるかをコントロールする仕組みを整えることが重要です。

特にMicrosoftのクラウドサービスを中心に利用していく場合は、Azure AD（Microsoft Entra ID）に寄せることを強くおすすめします。考え方は明確です。

テナントは1つ
すべてのSaaSサービスをそのAzure ADと連携させる
1つのIDで複数のサービスを使う

これが間違いのない構成です。

短期的な個別最適が長期的な全体最適を妨げる

狭い視点だけを見て個別最適に走ってしまうと、全体を眺めたときに最適な状態が実現できません。「なぜ最初からそう考えなかったのか」という話になります。

ベンダーの思想や方向性を理解した上で、どこを中心に据えるかを最初に決めることが大切です。多少の不便があっても受け入れ、長い目でサービスの流れに沿った使い方をしておけば、長期的には幸せになれます。

逆に、短期的・局所的な問題を解決するために本来の方向性に沿わない実装を追加してしまうと、どんどん複雑化します。その結果、本来の方法でその問題が解決された時期が来ても、独自の実装があるために新しい解決策を取り入れられない状況になります。「新しい機能を使いたいけれど、この構成のままでは使えない」という問題がずっと続くことになります。

まとめ

オンプレミスのActive Directory時代から現在のAzure AD（Microsoft Entra ID）に至るまで、「ディレクトリを複数に分散させてしまう」失敗は繰り返されています。後から統合しようとすれば、膨大な工数とコストがかかることは最初から目に見えています。

Microsoftは一貫して「シングルドメイン・シングルテナント」をベストプラクティスとして推奨しています。Microsoftのクラウドサービスを中心に使っていくのであれば、テナントは1つに統一し、すべてのサービスをそのIDと連携させる構成が最善です。

短期的な不便や個別の事情から複数テナントを作る誘惑は常にありますが、長い目で見て本筋の流れに沿った構成を最初から選ぶことが、本質的な苦労をしないための近道です。