「Azure Active Directoryって結局なくなったの？」「Microsoft Entra IDという名前を急に目にするようになったけど、何が変わったのか分からない」──オンプレミスのActive Directoryを長年運用してきたインフラエンジニアほど、この名称変更に戸惑っている方は多いのではないでしょうか。社内ドメインコントローラーを守ってきた経験があるからこそ、クラウド側のID基盤が「Azure AD」から「Entra ID」へ変わったことの意味を正確に押さえておきたいところです。
この記事では、Microsoft Entra ID（旧Azure AD）について、オンプレのActive Directoryを扱ってきた経験者にもわかりやすく解説します。基本概念の整理から、ユーザー・グループ・アプリケーション管理の実務、料金体系、そしてAWS IAMとの違いまで、現場で判断に迷わないレベルの知識を網羅します。
なぜMicrosoft Entra IDなのか？（オンプレADとの違い・背景）
2023年7月、Microsoftは「Azure Active Directory」を「Microsoft Entra ID」へ正式に改称しました。機能が変わったわけではなく、Entraというアイデンティティ＆アクセス管理のファミリーブランドに統合された形です。Azure AD B2C、Microsoft Entra Permissions Management、Microsoft Entra Verified IDなど、関連製品群がEntraという傘の下に整理されたと理解すれば十分です。
オンプレミスのActive Directory Domain Services（AD DS）と混同しやすいのですが、両者は「別物」と考えた方が現場では安全です。違いを整理します。
| 観点 | オンプレAD DS | Microsoft Entra ID |
|---|---|---|
| プロトコル | Kerberos、LDAP、NTLM | OAuth 2.0、OpenID Connect、SAML、WS-Fed |
| 管理対象 | Windowsドメイン内のPC・サーバー | SaaSアプリ、Azureリソース、クラウドユーザー |
| 組織構造 | OU（組織単位）・GPO | フラット構造＋管理単位（Administrative Unit） |
| 参加方式 | ドメイン参加 | Entra参加・ハイブリッド参加 |
| 対象ネットワーク | 社内LAN中心 | インターネット前提 |
オンプレADは「社内にドメインコントローラーを立てて閉じたネットワークでKerberosを回す」世界観です。これに対しEntra IDは「インターネット越しのSaaS・クラウド資源に対して、OAuth/OpenID Connectで認証を仲介する」世界観です。両者を連携させる場合はEntra Connect（旧Azure AD Connect）でディレクトリ同期を行い、ハイブリッド構成を組むのが定石になります。
基本的な使い方（ユーザー・グループ・アプリ登録）
Entra IDの3大操作は「ユーザー作成」「グループ設計」「アプリ登録」です。順に押さえていきます。
1. テナントの確認とユーザー作成
Azureサブスクリプションを作成すると、自動的にEntra IDテナントが1つ割り当てられます。Azureポータルで「Microsoft Entra ID」を開き、左メニューの「ユーザー」→「新しいユーザー」→「内部ユーザーの作成」でユーザーを追加します。ユーザープリンシパル名（UPN）は「user@tenantname.onmicrosoft.com」の形式が初期値です。独自ドメインを検証済みなら「user@example.co.jp」として発行できます。
CLIで作成する場合は以下のコマンドです。
# Azure CLI でユーザー作成 az ad user create \ --display-name "山田太郎" \ --user-principal-name "yamada@example.co.jp" \ --password "InitialP@ssw0rd!" \ --force-change-password-next-sign-in true
2. グループによる権限設計
ユーザー単位で権限を付けると管理が破綻します。Entra IDでは「セキュリティグループ」と「Microsoft 365グループ」の2種類が使えますが、Azureリソースへの権限付与に使うのは前者です。オンプレADの「セキュリティグループ」と感覚は同じですが、割当方式が2通りある点に注意します。
・割り当て済み（Assigned）: メンバーを手動で追加する従来型
・動的ユーザー（Dynamic User）: ユーザー属性に応じて自動で所属させる（例: department eq “経理部”）
・動的デバイス（Dynamic Device）: デバイス属性に応じて自動所属させる
動的グループは便利ですが、Entra ID P1ライセンス以上が必要です。ライセンスを持っていない場合は、HRシステムと同期して自動プロビジョニングする設計に寄せると良いでしょう。
3. アプリ登録とサービスプリンシパル
自作アプリや外部SaaSにシングルサインオン（SSO）させるには「アプリの登録」を行います。登録すると2つのオブジェクトが生成されます。
・アプリケーションオブジェクト: アプリの定義（テンプレート）
・サービスプリンシパル: テナント内でアプリが実行される際のID（インスタンス）
AWSに置き換えると「IAMロール」に近い概念がサービスプリンシパルです。Terraformや自動化スクリプトをEntra ID経由でAzureリソースへ認証させる場合、サービスプリンシパルを作成してクライアントID・シークレットを発行します。
# Azure CLI でサービスプリンシパル作成（共同作成者ロール付与） az ad sp create-for-rbac \ --name "terraform-deployer" \ --role Contributor \ --scopes /subscriptions/00000000-0000-0000-0000-000000000000
料金の仕組み（コスト感覚）
Entra IDは無料（Free）でもかなりの機能が使えます。Azureサブスクリプション契約者は自動的に含まれるため、小規模な検証や単純なSSOであれば追加費用は発生しません。ただし、条件付きアクセスや動的グループを本番で使うならP1、特権ID管理（PIM）やリスクベース認証まで踏み込むならP2が必要です。
| エディション | 料金（2026年4月時点） | 主な機能 |
|---|---|---|
| Free | $0 | 基本ユーザー管理、SSO、MFA（基本）、B2Bコラボレーション |
| Microsoft Entra ID P1 | $6／ユーザー／月 | 条件付きアクセス、動的グループ、セルフサービスパスワード リセット（クラウド＋オンプレ書き戻し） |
| Microsoft Entra ID P2 | $9／ユーザー／月 | P1全機能＋Identity Protection（リスク検出）、Privileged Identity Management（PIM） |
| Microsoft Entra ID Governance | $7／ユーザー／月（P2との併用） | アクセスレビュー、エンタイトルメント管理、ライフサイクルワークフロー |
社内100名規模でP1を導入すると月額$600、年額で約$7,200（約108万円・1ドル150円換算）です。Microsoft 365 E3やE5にはP1・P2がバンドルされているため、既にEnterpriseライセンスを契約している組織は「実質ライセンス取得済み」のケースも多い点を見逃さないでください。
応用・実務Tips
1. 条件付きアクセスで境界型セキュリティを脱却する
オンプレAD時代は「社内ネットワークにいる＝信頼できる」というIPベースの境界型モデルが主流でした。Entra IDの条件付きアクセスは「ユーザー」「デバイス」「場所」「アプリ」「リスク」を複合的に評価し、ポリシーに沿って許可・ブロック・MFA要求を決定します。ゼロトラストの入口はここから始めるのが王道です。
典型的なポリシー例としては、管理者ロールを持つユーザーには常にMFAを要求、未管理デバイスからは機密アプリへのアクセスをブロック、海外IPからのサインインにはリスクベースでMFAを要求、といった組み合わせがよく使われます。
2. Entra ConnectでオンプレADと同期する
既存のオンプレAD DSを捨てずに併用する場合、Entra Connectをオンプレサーバーにインストールして同期設定を行います。パスワードハッシュ同期（PHS）・パススルー認証（PTA）・フェデレーション認証（AD FS）の3方式があり、運用負荷を考えるとPHSが第一候補です。AD FSサーバー群の運用工数が大きいため、新規導入でFSを選ぶ理由は減っています。
3. マネージドIDを活用する
Azure VMやApp Serviceに「マネージドID」を付与すれば、サービスプリンシパルのクライアントシークレットを管理せずにAzureリソースへアクセスできます。AWSで言う「EC2のIAMロール」とほぼ同じ発想です。シークレットの漏洩リスクを根本的に減らせるため、新規実装では必ず検討すべき機能です。
AWS IAMとの違い（移行・併用のポイント）
AWSを先に経験しているエンジニアほど、Entra IDとAWS IAMを同一視しがちですが、責務の範囲が異なります。
| 観点 | AWS IAM | Microsoft Entra ID |
|---|---|---|
| 主な役割 | AWSリソースへのアクセス制御 | ID基盤＋SaaS SSO＋Azureリソース認証 |
| SSO対象 | AWS IAM Identity Center（旧SSO）で別途提供 | 標準機能として組み込み |
| 外部ユーザー招待 | IAMユーザー発行か、Identity Centerで管理 | B2Bコラボレーション（ゲスト招待） |
| MFA | IAMユーザー個別設定 | 条件付きアクセスで一元管理 |
| 権限モデル | JSONポリシー（許可・拒否） | RBAC（ロール割当）＋ABAC |
大きな違いは、Entra IDは「Microsoft 365を含む全社ID基盤」として設計されている点です。AWS IAMはあくまでAWSアカウント内のアクセス制御に特化しています。マルチクラウド環境では、Entra IDを組織のマスターIDプロバイダーとし、AWS IAM Identity Centerと連携してSSOを実現する構成が現実解になります。
AWS IAMの設計思想については、姉妹サイトクラウドマスターズ.TOKYOの「AWS IAM入門」記事と併せて読むと理解が深まります。
よくあるトラブルと対処法
・「招待したゲストユーザーがサインインできない」: B2Bコラボレーションの招待リンクの有効期限切れか、招待先のメールが届いていないケースが大半です。まず「ユーザー」一覧でユーザータイプが「ゲスト」になっているか、招待の受理ステータスがPendingAcceptanceではないかを確認してください。
・「サービスプリンシパルのシークレットが切れた」: 既定の有効期限は2年です。期限切れ前にアラートを出す運用か、マネージドIDへの切り替えが根本対策です。
・「条件付きアクセスで管理者自身がロックアウトされた」: 緊急アクセスアカウント（Break Glass Account）を必ず2つ以上作成し、条件付きアクセスの適用対象から除外しておくのが鉄則です。
・「Entra Connectの同期が止まっている」: Synchronization Service Managerで最終同期時刻を確認し、イベントログのエラーを追います。dirsyncサービスの再起動で直る場合もありますが、スキーマ拡張の失敗が原因なら慎重な切り分けが必要です。
クラウド上のLinuxサーバー認証とEntra IDを連携させる場合の実装については、姉妹サイトLinuxMaster.JPでSSSD連携の手順を詳しく解説しています。
本記事のまとめ
Microsoft Entra IDはAzure ADの後継となるクラウドネイティブなID基盤で、オンプレADとは設計思想が根本的に異なります。SaaS SSO・条件付きアクセス・マネージドIDを使いこなせれば、境界型セキュリティから脱却してゼロトラストへ踏み出す土台になります。AWS IAMと併用するマルチクラウド構成では、Entra IDを組織のマスターIDプロバイダーに据える設計が現実解です。
まずは無料のFreeエディションでユーザー作成とアプリ登録を試し、条件付きアクセスが必要になったタイミングでP1へ、特権管理まで踏み込むならP2へ段階的に引き上げるのが、コストと運用負荷のバランスが取れた導入手順です。
オンプレADの知識をクラウド時代のID設計に活かしたい方へ
Entra IDや条件付きアクセスの設計は、現場経験の有無で設計品質が大きく変わる領域です。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
コメント