Microsoft Entra IDとは？主要機能・料金プラン・Entra Suiteとの違いを解説

Microsoft Entra ID（旧Azure Active Directory）は、Microsoftが提供するクラウド型のID・アクセス管理サービスで、2023年7月にAzure ADから現在の名称へ変更されました。

Microsoft 365・Azure・外部SaaS・オンプレミスアプリまでを横断的にカバーする統合認証基盤として、法人向けIAM（Identity and Access Management）の中核を担っています。

本記事では、Entraファミリー全体の中でのEntra IDの位置づけ、主要機能、料金プラン、Entra Agent IDやGlobal Secure Access等の関連プロダクトとの使い分け、導入判断で迷う論点までを、2026年7月時点の最新情報で体系的に整理します。

Microsoft Entra IDとは？Azure ADの後継となるクラウドIAMサービス

Microsoft Entra ID（マイクロソフト・エントラ・アイディー）とは、Microsoftが提供するクラウド型のID・アクセス管理（IAM）サービスです。2023年7月にAzure Active Directory（Azure AD）から改称された正式後継にあたります。

Microsoft 365やAzureの認証基盤としてだけでなく、外部SaaSやオンプレミスアプリケーションまで含めた統合認証・認可の中核として位置づけられています。

Entra IDの守備範囲は「ユーザー・グループ・アプリケーション・デバイスの認証と条件付き認可」で、SSO・MFA・条件付きアクセスを土台にゼロトラスト設計・ハイブリッドAD運用・AIエージェントの統制まで一元的に担う基盤層です。

2026年時点では、Microsoft Entra Agent ID（AIエージェント向けID）・Microsoft Entra Suiteといった上位機能が追加され、Entra IDはEntraファミリー全体の「必ず持っておく基盤製品」の位置に固まっています。

Azure ADからの名称変更と互換性

Microsoftは2023年7月にAzure ADをMicrosoft Entra IDへ改称すると公式ブログで発表し、サービス再設計ではなく統一ブランディングの整理として機能・料金・SLA同一のまま名前だけを揃えました。

• リブランド時（2023-07）
  APIエンドポイント（login.microsoftonline.com等）・MSAL SDKは既存のまま利用可、既存アプリの認証接続コード書き換え不要
  
  
• 2025年以降
  AzureAD／MSOnlineの旧PowerShellモジュールは順次サポート終了、Microsoft Graph PowerShellまたはMicrosoft Entra PowerShellへの移行が必要

ポイントは、名称変更そのものはコード書き換えを伴わないが、その後2025年以降で別軸のPowerShellモジュール刷新が進んでいる、という点です。

管理者ポータルは「Microsoft Entra 管理センター」（entra.microsoft.com）へ集約が進んでおり、既存Azure AD運用組織は「名前の読み替え」＋「PowerShellモジュール移行」の2軸で時系列を整理して対応する必要があります。

---

Microsoft EntraファミリーとEntra IDの守備範囲

Microsoft Entraは単一の製品ではなく、複数の関連プロダクトを束ねるID・アクセスセキュリティのファミリーブランドです。

本セクションでは、2026年時点のファミリー構成を整理し、その中でEntra IDが担うスコープと、追加ライセンスが必要になる領域の境界を明示します。

Entraファミリーの構成要素

以下の表で、2026年時点のMicrosoft Entraファミリーの主要プロダクトと役割を整理しました。

製品	役割	主な提供形態
Microsoft Entra ID	クラウド型IAM基盤（ユーザー・アプリ認証、条件付きアクセス）	Free／P1／P2
Microsoft Entra ID Governance	権限のライフサイクル管理・アクセスレビュー・PIM	P1／P2のアドオン
Microsoft Entra Internet Access	インターネット・SaaS向け セキュアWebゲートウェイ（SWG）	Entra Suiteに包含
Microsoft Entra Private Access	社内リソース向け ゼロトラストネットワークアクセス（ZTNA）	Entra Suiteに包含
Microsoft Entra External ID	顧客・パートナー向けID管理（CIAM、旧Azure AD B2Cの後継）	独立サブスクリプション
Microsoft Entra Verified ID	分散型ID（DID／Verifiable Credentials）発行・検証。基本機能はEntra IDに同梱、Face Check等のプレミアム機能はVerified ID Premium／Suite	Entra IDに同梱／Premium別
Microsoft Entra Agent ID	AIエージェント向けID・アクセス管理（2026年4月GA）	プラットフォームはEntra顧客が利用可、Microsoft 365横断利用にはユーザー単位のAgent 365ライセンス、セキュリティ拡張はM365 E7またはM365 E5＋Agent 365、機能別にP1／P2／Governanceを組み合わせ

この表から見えるのは、Entra IDが「人・アプリ・デバイス」の認証基盤を担い、その周辺でSuite系（GovernanceやGlobal Secure Access）は運用・ネットワークセキュリティを、External IDは顧客IAMを、Agent IDはAIエージェントの認可を、Verified IDは分散型IDをそれぞれカバーする役割分担になっている点です。

「Entra ID＝Entraファミリー全体」ではなく、Entra IDはあくまで中心にある基盤層に位置しています。

Entra ID単体でカバーできる範囲と拡張が必要な範囲

Entra ID単体で担保できるのは、認証・条件付きアクセス・SSO・基本的なMFA・ハイブリッドAD連携までの領域です。

一方で、以下のような要件が業務要件に入ってくる場合は、Suite等の追加ライセンスに拡張する検討が必要になります。

• 権限の定期棚卸し・入退社ライフサイクル自動化・PIM
  PIMはEntra ID P2またはEntra ID Governanceで利用可。エンタイトルメント管理・アクセスレビューは一部P2でも可だが、Lifecycle WorkflowsはEntra ID Governance（またはSuite）が必要
  
  

• 社内ネットワーク／SaaSへのゼロトラストアクセス
  Global Secure Access（Internet Access／Private Access）を含むEntra Suiteが必要
  
  

• 顧客・パートナー向けの登録／サインイン画面提供
  Entra External ID（旧B2Cの後継）が必要
  
  

• AIエージェントに個別ID・認可を発行して業務システムへアクセスさせる
  Entra Agent IDの機能拡張が必要

逆に言えば、これら以外の要件（Microsoft 365ユーザー管理・SaaS SSO・条件付きアクセス・MFA）は、Entra ID単体（Free／P1／P2）の範囲で十分に対応できます。

自社の要件がどのレイヤーに属するかを最初に切り分けることが、後段の料金・プラン選定にも効いてきます。

---

Microsoft Entra IDの主要機能

Microsoft Entra IDが提供する機能は、ID発行・認証・認可・監査という4つの軸に整理できます。

本セクションでは、業務でよく使われる代表的な機能を6つに絞って、それぞれの役割と実務での使いどころを解説します。

シングルサインオン（SSO）

シングルサインオン（SSO）は、1回の認証で複数のクラウドサービスに横断ログインできる仕組みです。

Entra IDは、Microsoft 365・Azure・Salesforce・ServiceNow・Workdayなど数千規模のSaaSアプリと標準連携し、SAML・OpenID Connect・WS-Federation・パスワードベース等のプロトコルで統合できます。

SaaSごとにIDとパスワードを個別発行する運用と比べて、退職時のアカウント無効化・棚卸し・不正アクセス検知が一元化される利点があります。

BYOD／リモートワーク主体の職場では、この一元化がセキュリティ運用コストを大きく左右します。

多要素認証（MFA）

多要素認証（MFA）は、パスワードだけでなく追加の要素（電話認証・Authenticatorアプリ・FIDO2セキュリティキー等）を組み合わせて本人性を確認する認証方式です。

Entra IDでは、Freeプランでもセキュリティの既定値群（Security Defaults）によって全ユーザーを保護対象としてMFA登録を要求でき、テナント初期化直後から基本的なMFA運用を開始できます。対象となる管理者ロールのサインインでは毎回MFAを要求、一般ユーザーとゲストには場所・デバイス・ロール・タスク等から必要と判断された場合にMFAを要求する挙動です。

加えて2026年7月1日以降に作成された新規テナントでは、Security Defaultsによりデバイスコードフローもブロック対象になっています。

対象ユーザー・除外条件・場所やデバイスに応じたポリシー制御など「柔軟な条件でMFAを要求する」設計を行うには、後述の条件付きアクセス（P1以上）を組み合わせる必要があります。

FreeプランのMFAは「全ユーザーの登録要求＋Microsoft判断による発動」までがカバー範囲であり、業務要件でユーザーグループごと・接続元ごとに要求を分けるならP1へのアップグレードが実務上の前提になります。

条件付きアクセス

条件付きアクセス（Conditional Access）は、アクセス元・デバイス・アプリに応じて認証要件や許可・拒否を動的に判定するポリシーエンジンです。P1プランから利用可能で、ゼロトラスト設計の中核となる機能です。

例えば「社外IPからOffice 365へのアクセスはMFA必須」「未登録デバイスからのSharePointアクセスは拒否」「高リスクサインインは即ブロック」といった制御を、ルール群として管理できます。

また、Ignite 2025で発表されたAgent ID対応により、条件付きアクセスはAIエージェントの識別子にもポリシーを適用できるようになりました。

適用範囲は2段構造で、Agent ID本体に指定できる条件は「Agent Risk（プレビュー）」のみ・制御は「ブロック」のみに限定される一方、エージェントが動作するエージェントユーザーアカウント側にはプレビュー機能として実行環境・デバイス準拠・ネットワーク条件を指定できます。
人ユーザーと同じ幅広い制御を掛けたい場合は後者側で組む形になります。

ID保護（Identity Protection）

ID保護（Identity Protection）は、サインイン試行の異常検知とユーザーリスクの評価を行う機能です。P2プランで利用可能で、条件付きアクセスと組み合わせることでリスクベースの自動応答を構築できます。

非典型的な移動（Atypical travel）・匿名IPからのサインイン・漏洩認証情報を用いたサインインなどを検知し、リスクスコアに応じて自動対処（MFA要求・パスワードリセット強制・ブロック）を実行します（不可能な移動＝Impossible Travelはさらに Defender for Cloud Apps の併用が必要です）。

2026年時点では、Risky agents conceptとしてAIエージェントの異常挙動評価にも領域が広がっており、人／エージェント双方のリスク管理を一元化できるようになっています。

Passkeys（FIDO2）とセルフサービスアカウントリカバリ

Ignite 2025で公開された次世代の認証機能が、Passkeys（FIDO2）の同期対応と、パスワードレスのセルフサービスアカウントリカバリです。

Passkeysは、公開鍵暗号ベースのフィッシング耐性の高い認証で、macOSプラットフォームクレデンシャル・Windows Helloとの連携を含め、パスワード運用を段階的に置き換えることを目指しています。

2026年時点の主要マイルストーンは以下のとおりです。

• Synced Passkeys／Passkey ProfilesがGA（2026年3月）
  デバイス間で同期されるPasskeyと、プロファイル単位の細かなポリシー制御が正式提供へ
  
  
• セルフサービス アカウント リカバリがGA（2026年5月）
  パスワードレス環境でヘルプデスク介在なしにアカウント復旧できる仕組みが正式提供。ただし導入要件としてEntra ID P1・Verified ID／Face Checkの構成・Azureサブスクリプション・Microsoft Security Store経由の外部本人確認プロバイダー（有償料金プラン選択）が必要で、無条件で利用できるわけではない
  
  
• SMS／音声MFA利用者へのPasskey自動有効化開始（2026年9月1日）
  既定でPasskey登録を促す挙動へ移行
  
  
• Microsoft提供のSMS／音声MFA終了予定（2027年2月1日）
  それまでにPasskey・Authenticatorアプリ・FIDO2鍵などへの切り替えが必要

パスワードリセット依頼で疲弊しているヘルプデスクの現場から見ると、これらは実務的なコスト削減インパクトが大きい一連の変化で、SMS／音声MFA廃止までのロードマップを2026年内に組んでおくことが移行の前提になります。

ハイブリッドID連携（Entra Connect）

オンプレミスのActive Directoryとクラウド側のEntra IDを同期させるのが、Microsoft Entra Connect（旧Azure AD Connect）です。

社内ADのユーザー・グループ・パスワードハッシュをEntra ID側に同期し、単一IDでオンプレアプリとクラウドアプリの両方にアクセスさせる構成を実現します。

最近の更新として、Microsoftは、Entra Connect Syncのバージョン2.5.79.0未満を持つテナントは、2026年9月30日以降に同期サービスが停止することを公式に告知しています。

ただし2.5.79.0はあくまで最低要件（サポート終了は2026年10月23日）であり、2026年7月時点の最新はv2.6.84.0です。セキュリティ修正が含まれるため早期の最新化がMicrosoftから推奨されています。

加えてMicrosoftは2026年7月から、Entra Connect SyncからクラウドネイティブのMicrosoft Entra Cloud Syncへの移行時期の通知を開始しています。M365 Message CenterやEntra Connect Healthを通じてテナントごとに割り当てられた移行期間が案内され、その期間内に段階的な移行が進む運用です。単純構成のテナントから通知が始まる形になっており、高度な構成・大規模ディレクトリの組織は初期波の対象外です。

ハイブリッドAD運用組織にとって、この期限は避けて通れない更新ポイントです。
「最低2.5.79にする」ではなく「最新版に維持しつつCloud Syncへの移行タイミングを準備する」というスタンスで運用計画を組む必要があります。

---

Microsoft Entra Agent ID：AIエージェント時代のID管理

Microsoft Entra Agent IDは、AIエージェントに対して人と同じようにID・ロール・アクセス権限を発行し、条件付きアクセスやリスク検知の枠組みで統制するための新しいID管理カテゴリです。

2025年5月に基本コンセプトが発表され、Microsoft Ignite 2025で公開プレビューが大幅に拡張、その後 2026年4月にGA（一般提供）に到達しました。

GAリリース時点でOAuth 2.0・MCP・A2Aといった標準プロトコルを用いた認証・認可・ガバナンスの中核基盤が整備され、周辺機能が順次拡張されている状態になっています。

Agent IDが必要になった背景

AIエージェントが業務システムに直接アクセスして、メールを送信し、SharePointから資料を取り出し、Dynamics 365の受注データを更新する——こうした運用が始まると、「そのエージェントは誰の権限で動いているのか」を明示する必要が出てきます。

従来もサービスプリンシパルやワークロードIDを使えば個別ID・サインインログ・条件付きアクセスは付与できました。
ただしそれらは「汎用的なアプリ／自動化」を前提とした仕組みで、エージェント固有のオブジェクトやスポンサー関係、エージェントごとのライフサイクル管理を扱うには不十分でした。

Entra Agent IDは、この課題を「エージェント専用のオブジェクト（ブループリント・スポンサー関係・エージェント固有の監査ログ）をEntraディレクトリに一級市民として登録する」というアプローチで解決します。

各エージェントに固有のID（Agent ID）を発行し、そのIDにロール・アクセスパッケージ・条件付きアクセスポリシーを紐付けることで、エージェント固有の統制モデル（スポンサー人ユーザーとの関係、エージェント専用の監査、ライフサイクル）をID基盤の上で扱えるようになります。

Agent IDが提供する主要機能

Ignite 2025時点で公表されているAgent ID関連機能は多岐にわたりますが、代表的なものを4つに絞って整理します。

• Agent IDの発行と管理
  各エージェントに固有識別子を発行し、Entra管理センターで一覧・監査・無効化できる。エージェントの認証・アクティビティをサインインログ／監査ログで確認できる
  
  

• エージェント向け条件付きアクセス
  Agent ID本体に指定できる条件は「Agent Risk（プレビュー）」のみ・制御は「ブロック」のみ。エージェントのユーザーアカウント側には実行環境・デバイス準拠・ネットワーク条件をプレビュー機能として指定できる（Conditional Access and agent identities）
  
  

• 専用ロール（Agent ID Administrator/Agent ID Developer/Agent Registry Administrator）
  エージェント管理を専門にした3つのロールがRBACに追加され、開発者・運用者・レジストリ管理者の職務分掌を明示できる
  
  

• Agent OAuth Protocols
  エージェント特有の3つのOAuthフロー——Agent on-behalf-of flow（エージェントがユーザーに代わって呼び出す）／Autonomous app flow（自律実行）／Agent's user account flow（エージェントのユーザーアカウント経由）——が定義され、Microsoft Graphや外部APIを呼び出す際の認可設計が標準化される

これらの機能により、AIエージェントの導入が「野良運用」に陥らず、既存のID統制プロセス（アクセスパッケージ・スポンサー管理・ライフサイクルワークフロー・アクセスレビュー）と同じフレームで管理できるようになります。

実務で押さえるべきAgent IDの位置づけ

GA範囲と条件付きアクセスの制限

2026年4月にGAしたのはAgent IDプラットフォーム（ID基盤・認証・認可の中核）で、Agent ID本体の条件付きアクセスはAgent Risk・ブロックのみ、エージェントのユーザーアカウント側の条件付きアクセスや、アクセスパッケージのスポンサー／エンドユーザー申請フローの一部などにプレビュー段階の機能が残ります。

Entra IDとAgent 365の役割分担

Entra IDはID基盤と個別IDのポリシー管理を担当し、エージェントの統合レジストリ・コントロールプレーンは同時期に登場した Agent 365 側に移されているという役割分担も押さえておく必要があります。

導入タイミング

導入判断としては、Microsoft 365 Copilot・Copilot Studio・自社エージェント（Foundry Agent Service経由等）の運用が始まった段階でAgent IDのID発行・アクセスパッケージ設計を並行して整えるのが現実的です。

既にMicrosoft Copilot Studioでエージェントをカスタムで作り始めている企業では、Agent IDでの権限管理・監査ログ取得へ順次切り替えることで、既存のIDガバナンスプロセスに乗せた統制が可能になります。

ライセンス構成の組み合わせ

Entra IDでの人ユーザー統制と、Agent IDでのエージェント統制は同じ「Microsoft Entra 管理センター」から扱えますが、利用できる条件・ロール・権限にはエージェント固有の制限があり、レジストリ側はAgent 365と組み合わせて設計する必要があります。基本設計とエージェント設計は分けて考えるのが実務的で、ライセンス条件は以下の組み合わせで整理できます。

• Agent IDプラットフォーム：Entra ID顧客が利用可能（ID基盤・認証・認可の中核）
• Microsoft 365横断でのエージェント利用：ユーザーごとのAgent 365ライセンスが必要
• セキュリティ拡張（Agent Risk連動・エージェント固有の保護）：Microsoft 365 E7、またはM365 E5＋Agent 365
• 単体構成：Agent 365にP1／P2等を組み合わせる
• ID Governance for agents（エージェントのライフサイクル・アクセスパッケージ）：公式概要ではP1が基本条件、Lifecycle WorkflowsやAgent Sponsorship Tasksなど機能別に権利が異なる

---

Microsoft Entra IDと関連プロダクトの使い分け

Entra IDだけでは足りない要件が出てきたとき、次に検討するのがEntra Suiteへの拡張か、個別アドオン（GovernanceやExternal ID）の追加です。

本セクションでは、代表的な4つの関連プロダクトについて、Entra IDにどんな価値を上乗せするか、どんな企業に適するかを整理します。

Entra Suite——ID＋ネットワークセキュリティの統合パッケージ

Microsoft Entra Suiteは、Entra IDに加えてGlobal Secure Access（Internet Access＋Private Access）・ID Governance・Verified ID Premium（Face Check等）などをまとめた統合パッケージです。

Suiteの守備範囲

Microsoft Entra Suiteの守備範囲（あらゆる従業員・拠点・端末から、AI・IaaS/PaaS・SaaS・オンプレまでを保護）（出典：Microsoft Mechanics: New Microsoft Entra Suite）

公式ページの位置づけ図は、Suiteの守備範囲を「左側＝アクセス主体（Any employee／location／platform／device）」「右側＝保護対象（AI／IaaS・PaaS・Datacenter／SaaS・websites／On-premises）」の2軸で整理しています。

誰から何へのアクセスをID基盤で一括制御するという設計思想が読み取れ、SaaS単体のIDaaS製品ではカバーしきれない社内リソース・オンプレアプリまで含めた統合制御が可能になります。

Global Secure AccessでSSE・ZTNAを統合

Global Secure Accessは、Microsoftが提供するSecurity Service Edge（SSE）ソリューションで、SaaSアクセスを保護するSecure Web Gateway（SWG）と、社内リソースへのゼロトラストアクセス（ZTNA）を1つのクライアントで提供します。

ゼロトラスト・SASE構想を進めている企業にとっては、別ベンダー（Zscaler・Netskope・Cloudflare等）のSSE製品を導入する代わりに、Entra Suiteで完結させるという選択肢が現実味を帯びる構成です。

2026年時点の機能ラインナップ

2026年時点でAIプロンプトインジェクション対策（Prompt Injection Protection）・クラウドファイアウォール・MIMEタイプによる基本コンテンツフィルタリングがGA、Microsoft Purview連携による本文検査・機密情報検査・ネットワークDLPはプレビュー段階と、機能ラインナップが順次揃ってきています。

ID基盤とネットワークセキュリティが同じダッシュボードから運用できる強みが増しつつある局面です。

Entra ID Governance——権限のライフサイクル管理

Microsoft Entra ID Governanceは、Entra IDの上に「権限のライフサイクル管理」を付与するアドオンです。

提供する4つの機能

具体的には、以下のような機能を提供します。

• エンタイトルメント管理
  アクセスパッケージ（複数リソースへの権限セット）を定義し、承認ワークフロー経由で付与する
  
  

• アクセスレビュー
  定期的な権限棚卸し（マネージャー承認・セルフレビュー）を仕組み化する
  
  

• ライフサイクルワークフロー
  入退社・異動に応じた権限自動付与／剥奪を自動化する
  
  

• PIM（Privileged Identity Management）
  特権ロールの一時付与・時間制限・承認要件を厳格化する（PIMはEntra ID P2でも利用可能）

アクセスレビュー画面の運用イメージ

Entra My Accessのアクセスレビュー画面（Group and app membership・Access package assignment・Multi-resourceの3タブで棚卸しを実施）（出典：Microsoft Entra Suite）

エンドユーザー側のMy Access画面では、レビュー対象が「グループ／アプリメンバーシップ」「アクセスパッケージの割当」「複数リソース横断（プレビュー）」の3カテゴリに分かれて表示され、担当者は自分に割り当てられたレビュータスクだけを1画面で処理できます。

管理者は各カテゴリごとにレビュー頻度・自動失効ルール・エスカレーション先を設定できるため、棚卸しの実施率が上がらないという定番の運用課題をワークフロー化して解消できます。

導入が効く組織／効きにくい組織

Governanceは、内部統制・監査対応の負荷が大きい業種（金融・製造・上場企業）や、マネージドサービス提供者（MSP）・大手SIerのように委託先が多層化する組織で特に効果を発揮します。

反対に、権限関係が単純で、入退社・棚卸しの自動化要件が少ない小規模組織では、Entra ID P1／P2の範囲で十分なケースが多く、Governanceは早期導入の必要性が薄い傾向にあります。

Entra External ID——顧客・パートナー向けIAM（CIAM）

Microsoft Entra External IDは、社内従業員ではなく顧客・パートナー・エンドユーザーに向けたID管理を担うCIAM（Customer IAM）製品で、2024年5月にGAしました。

旧Azure AD B2Cの後継としての提供機能

旧Azure AD B2Cの後継として位置づけられ、セルフサービス登録・カスタマイズ可能なサインイン画面・Face Check with Verified ID・ネイティブ認証等を、Entra管理センターの中で統合的に扱えます。

国内導入事例と移行検討ライン

NSK（日本精工）はEntra External IDの日本での早期導入企業として、2024年6月から導入を開始し、2025年からは新規開発アプリの認証・認可を段階的にExternal IDへ移行しています。社内Entra IDとUIを揃えることで顧客体験の改善・個人情報管理の統合を進めている事例です。

自社SaaS・顧客ポータル・パートナーサイトを運営している企業で、Azure AD B2Cを利用中の場合はExternal IDへの移行検討が優先論点になります。

Entra Verified ID——分散型ID（Verifiable Credentials）

Microsoft Entra Verified IDは、W3C標準のDID／Verifiable Credentialsに準拠した分散型IDの発行・検証基盤で、基本的な発行・検証機能はEntra IDサブスクリプションに同梱されています。

Face Checkによる顔認証マッチングなどのプレミアム機能を利用する場合のみ、Verified ID PremiumまたはEntra Suiteの追加購入が必要です。

免許証・卒業証明書・従業員証などのデジタル資格情報を発行し、検証者が発行者に問い合わせずに真正性を確認できる仕組みで、Ignite 2025ではQuick Setup機能がGAし、テナントへの導入がワンクリックで完了できるようになりました。

顧客本人確認（KYC）を強化したいFinTech・大量の資格情報発行をコスト圧縮したい教育機関・入館証明を分散化したい大企業などで、実装検討が進んでいます。

一方、一般的な社内IAM要件だけであれば、Verified IDまで導入する必要はありません。要件があるかどうかを最初に切り分けるのが実務的です。

---

Microsoft Entra IDの料金プラン

Microsoft Entra IDには、無料プランに加えて2つの有償プラン（P1／P2）があり、さらに周辺機能を束ねたEntra Suiteとアドオン形式のID Governanceが用意されています。

本セクションでは、2026年7月時点の公式pricingページの情報をもとに、料金体系と選定判断軸を整理します。

主要プランとアドオンの料金

以下の表で、2026年7月時点のMicrosoft Entra IDの主要プランおよびアドオンの料金水準をまとめました。

プラン／アドオン	料金（USD）	主な位置づけ
Microsoft Entra ID Free	$0（Azure／M365購入で自動付帯）	基本のディレクトリ・SSO・Security Defaults（全ユーザーへのMFA登録要求＋Microsoft判断による発動）
Microsoft Entra ID P1	$7.00／ユーザー／月（年払い）	条件付きアクセス・ハイブリッドID・SSPR等の主力プラン
Microsoft Entra ID P2	$10.00／ユーザー／月（年払い）	P1＋ID Protection＋PIM＋アクセスレビュー
Microsoft Entra ID Governance	$7.00／ユーザー／月（年払い、P1／P2必須のアドオン）	エンタイトルメント管理・アクセスレビュー・ライフサイクルワークフロー
Microsoft Entra Suite	$12.00／ユーザー／月（年払い、P1必須のアドオン）	Global Secure Access（Internet／Private）・Governance・Verified ID Premium（Face Check等）をまとめて追加

この価格体系の要点は、P1がゼロトラスト設計の入り口として最も一般的な選択肢であり、P2は「リスクベース認証・PIMの自動化」を求める組織向けの上位プランという棲み分けです。

Entra SuiteはP1に対する追加ライセンス（$12）で、P1を単体購入する場合の合計負担は $7＋$12＝**$19／ユーザー／月**になります。

M365 E5顧客向けには特別価格が用意されるため、実際の見積もりはM365ライセンス構成と合わせて営業窓口で確認するのが実務的です。

M365 E3／E5バンドルでの実質価格

Entra IDのP1／P2は、単体購入するよりもMicrosoft 365 E3／E5にバンドルされているケースが多く、実質的な負担額はバンドル価格を軸に判断するのが現実的です。

• Microsoft 365 E3
  Entra ID P1が同梱される標準的な法人向けバンドル
  
  

• Microsoft 365 E5
  Entra ID P2と高度なMicrosoft 365セキュリティ機能を同梱する上位バンドル（Entra SuiteやAgent 365は別ライセンス）

Microsoft 365を既に契約している場合、そこに含まれるEntra ID機能を最大限使いこなす方が、コスト効率上は有利です。

反対に、Google Workspace＋別のSSO製品を利用している組織がEntra IDだけを単独導入するケースでは、P1／P2の単体購入となり、費用対効果の見立てが変わります。

ID Governanceのアドオン価格

Microsoft Entra ID Governanceは、P1／P2を前提とする$7／ユーザー／月のアドオンとして提供されます（公式pricingページの定価表示）。

Governanceを検討する場合は、エンタイトルメント管理・アクセスレビュー・ライフサイクルワークフローの3つが業務上どの程度必要かを先に洗い出し、それに応じて全社適用にするか特定部門・特定ロールに限定するかを決めるのが現実的です。

「Governanceの必要性が薄いのに、E5バンドルに寄せた結果としてGovernance相当の機能を持て余す」構成にならないよう、業務要件との突き合わせが重要です。

P1とP2の選び方

P1とP2の選び方は、リスクベース認証（ID Protection）とPrivileged Identity Management（PIM）を業務で使うかどうかが主な分岐点です。

以下の判断軸で切り分けると、実務の推奨が組み立てやすくなります。

• P1で十分なケース
  Microsoft 365ユーザー管理・SaaS SSO・条件付きアクセス・MFA・ハイブリッドID連携が中心で、リスクベースのサインイン制御は必要ないか、優先度が低い
  
  

• P2に上げるべきケース
  金融・大手製造業のように特権アカウントの一時付与・時間制限が内部統制上必要／リスクベースの自動対処（非典型的な移動・匿名IP検知）を運用したい／アクセスレビューを定期的に回したい

実務では「Microsoft 365 E5を全社導入している大企業＝P2」「E3＋一部E5＝混在」「E3のみ＝P1中心」のように、M365ライセンス構成と揃うことが多いです。

Entra ID単体でP2に上げる判断は、リスクベース認証を実運用する意思決定とセットで行うのが妥当です。

---

Microsoft Entra IDの導入・設計で押さえるべきポイント

Microsoft Entra IDの導入は、テナント作成そのものよりも初期の設計判断が後々のセキュリティ運用に直結する局面が多く、順序を間違えると再設計コストが跳ね上がります。

本セクションでは、初期導入時に必ず押さえておきたい設計ポイントを4つに絞って解説します。

テナント設計とネームスペースの決定

Entra ID導入の最初のステップは、テナントの作成と初期ドメイン（自社略称の後ろに「.onmicrosoft.com」が付く形）の登録です。

企業がMicrosoft 365やAzureを新規契約した時点でテナントは自動的に1つ発行されます。追加テナントを手動で作成する標準経路は「Microsoft Entra 管理センター」またはAzure Portalで、Microsoft 365管理センターは主に既存テナントのユーザー・ライセンス管理に使う形です。

ここで重要になるのが、カスタムドメイン（自社の独自ドメイン）の登録とverify（DNS TXTレコード検証）です。

IDトークンの発行者・テナント識別には主にGUIDが使われるため「.onmicrosoft.com」が認証応答に必ず残るわけではありませんが、ユーザーのUPN（サインイン名）や既定のB2B招待メール送信元には初期ドメイン文字列が現れます。
カスタムドメインを登録・既定化しておくことで、利用者に分かりやすいサインイン名を提示でき、B2B招待メールも企業アイデンティティに揃えられます。

招待メールをカスタムドメインから送る場合はExchange Onlineの構成やDNS設定（SPF・DKIM等）も併せて必要になる点は押さえておきましょう。

条件付きアクセスの初期ポリシー設計

条件付きアクセスは、ゼロトラスト設計における最重要ポイントで、初期段階から意識的に組み立てないと、後から遡って設計し直すコストが大きくなる領域です。

Microsoftが推奨する初期ポリシーテンプレート（Common Conditional Access policy templates）には、以下のような基本セットが含まれています。

• 管理者ロールに対するMFA必須化
• 全ユーザーに対するMFA必須化（除外条件付き）
• 高リスクサインインのブロック
• レガシー認証（IMAP／POP／SMTP等のBASIC認証）のブロック
• 未管理デバイスからのアクセス制限

まずは動作確認モードReport-onlyから開始してログを見ながら本番モードへ移行するのがセオリーで、除外リストの妥当性・緊急アクセスアカウントの動作・想定外の業務停止が起きないかを段階的に検証します。

いきなり本番モードで有効化して業務停止を招くケースがあるため、Report-onlyで影響範囲を確認する工程は省略しない方がよい局面です。

オンプレADとの連携設計

社内ADを持つ組織では、Entra Connectを導入して、オンプレADとEntra IDを同期します。

同期対象・同期方式（パスワードハッシュ同期／パススルー認証／フェデレーション）・OU（Organizational Unit）フィルタリング・プロビジョニング設定を決めた上で、Connectサーバーを構築するのが基本フローです。

ここでの落とし穴は、Microsoft Entra Connect Syncのバージョン管理です。

前述のとおり、v2.5.79.0以降を持たないテナントは、2026年9月30日に同期サービスが停止します。この期限に間に合わないと、オンプレADの変更がEntra IDに反映されなくなり、認証系全体に影響が出ます。

導入プロジェクトの中で、Connectサーバーの初期構築と同時に「定期バージョンアップの運用計画」まで決めておくことが、長期運用の安定性を左右します。

権限設計とRBAC

Entra IDのロール割当は、Azure RBAC（リソースへのアクセス制御）と、Entra IDロール（ディレクトリへの管理権限）の2種類が並列で存在します。

グローバル管理者・特権ロール管理者・条件付きアクセス管理者などの高権限ロールは、PIMで一時付与にするか、そうでない場合でも常時付与するアカウント数を最小限に抑えることが原則です。

初期導入時は「グローバル管理者を2〜3名確保」「別枠で2つ以上の専用クラウドオンリー緊急アクセスアカウント（Microsoft推奨）を用意」「日常運用は職務別のロール（ユーザー管理者・ヘルプデスク管理者等）を使う」という設計にしておくと、後々のセキュリティ監査で説明しやすくなります。

Entra IDのロールを増やしすぎると棚卸しコストが跳ね上がるため、Governanceのアクセスレビュー導入と合わせて設計する視点が有効です。

---

Microsoft Entra IDの導入判断で迷う論点

Entra IDそのものは「Microsoft 365やAzureを使うなら実質必須」の製品ですが、どのプランで導入するか・どの周辺プロダクトまで拡張するかの判断で迷う場面が多くあります。

本セクションでは、実務でよく相談される4つの論点について、SIerとしての推奨判断軸を示します。

P1か、P2か、Suiteか

最も相談が多い論点が、有償プランの選定です。判断のフレームとしては、以下のように切り分けるのが分かりやすい形になります。

• P1で十分
  Microsoft 365ユーザー管理・SaaS SSO・条件付きアクセス・ハイブリッドAD連携が主要要件で、従業員数が中規模まで
  
  

• P2に上げる価値がある
  金融・大手製造業のように特権アカウントの一時付与・時間制限が内部統制上必要／リスクベースの自動対処を運用したい／M365 E5を導入済み
  
  

• Suiteまで拡張する価値がある
  別ベンダーのSSE製品（Zscaler・Netskope等）と競合検討中／ゼロトラストネットワーク構想を全社で進めている／Global Secure Access＋Governance＋Verified ID Premiumをまとめて調達したい

Suiteは「ID＋ネットワーク＋ガバナンス」の3レイヤーを1製品で持ちたい組織にとってコスト効率が良く、逆に「ネットワークセキュリティは既存製品で満足」という組織では過剰投資になります。

External IDの採用タイミング

顧客向けID（CIAM）を検討している組織では、Azure AD B2Cを継続利用するか、External IDへ移行するかが判断ポイントです。

Microsoftは2025年5月1日にAzure AD B2Cの新規顧客への販売を終了しており、新規案件はExternal IDが実質的な選択肢になっています。

既存B2C顧客はテナントやユーザーフローを引き続き作成・運用でき、サポートは少なくとも2030年5月まで継続予定ですが、External IDへの移行ガイドが公式に整備されており、移行タイミングを見計らって計画する必要があります。

実務的には、以下のように優先度をつけて進めるのが現実的です。

• 新規顧客IAMプロジェクト
  External IDで開始する（B2C選択の実質的余地はない）
  
  

• 既存B2Cテナントを運用中
  既存機能で満たされている間はB2C継続、大規模改修・機能追加のタイミングでExternal IDへ移行
  
  

• B2Cで実装しきれない機能が必要
  Face Check with Verified ID・ネイティブ認証等が要件なら、External IDへの前倒し移行を検討

B2Bゲストアクセスの認可設計

外部組織との共同作業でゲストユーザー（B2Bゲスト）を招待するとき、ゲストにも社内ユーザー同等のMFA・条件付きアクセスを適用するかの設計判断が必要になります。

Microsoft公式ドキュメントの Security Defaults では、B2Bゲストも一般ユーザーと同様に扱われ、対象管理者ロールには毎回、一般ユーザーとゲストには場所・デバイス・ロール・タスク等から必要と判断された場合にMFAを要求する挙動と説明されています。

この既定挙動を前提に、要件別に以下の方針が選ばれます。

• 既定のまま運用
  場所・デバイス・ロール・タスク等に基づくMFA要求で足りるケース。外部組織との軽量な共同作業や、内部統制要件がSecurity Defaults相当で満たせる場合に採用する
  
  

• 条件付きアクセスで細分化
  ゲスト向け専用の条件付きアクセスポリシーを組み、パートナー種別・接続元IP・アクセス対象アプリごとに要求を変える（P1以上必須）
  
  

• クロステナントアクセス設定で信頼を絞る
  「クロステナント アクセス設定」で信頼できる特定組織との間のみゲストのMFA・デバイス コンプライアンスの引き継ぎを許可し、他組織からの招待を制限する

ゲスト運用は「摩擦を下げるかセキュリティを厳格化するか」のトレードオフになるため、業種の統制要件・共同作業の頻度・扱う情報の機密性を軸に、既定＋条件付きアクセス＋クロステナント設定の3つを組み合わせて設計するのが実務的です。

Entra Agent IDを導入するタイミング

Entra Agent IDはプラットフォームが2026年4月にGAしており（Agent ID本体の条件付きアクセスはAgent Risk・ブロックのみ／エージェントのユーザーアカウント条件・一部アクセスパッケージフロー等はプレビュー継続）、AIエージェントの業務利用が本格化する中で、本番運用の設計に組み込むタイミングに入っています。

導入タイミングの目安は、以下のシナリオに該当するかどうかで判断します。

• Microsoft 365 Copilotで社内固有エージェントを本番運用しはじめている
  Copilotエージェントの統制がガバナンス上必要になった段階でAgent ID対応を組み込む
  
  

• Copilot Studioで大量のカスタムエージェントを開発中
  運用フェーズに入った段階で、Agent IDによる権限管理・監査ログ取得へ順次移行
  
  

• 自社アプリからLLM経由で業務システムを操作するエージェントを構築中
  Foundry Agent Service経由の実装なら、Agent IDでの認証設計と初期から接続

Entra IDでの人ユーザー統制と、Agent IDでのエージェント統制は同じ「Microsoft Entra 管理センター」で扱えるため、既存の運用体制に無理なく追加できます。ただし統合レジストリ・コントロールプレーンはAgent 365側に移されており、エージェント運用が本格化するならAgent 365の導入とM365 E7またはM365 E5＋Agent 365の組み合わせ、機能別に必要なP1／P2／Governance等のライセンス条件を合わせて設計する必要があります。

GA済みの認証・認可基盤に乗せることで、独自のサービスアカウント運用よりも監査・棚卸しの負荷が軽くなるのが実務的なメリットです。

---

Entra IDの認可基盤をAIエージェントの業務展開につなげるなら

Microsoft Entra IDで整えたID・アクセス制御は、Microsoft 365 Copilotや自社AIエージェントの認可基盤にそのまま接続できます。

ただし実際に業務にエージェントを組み込む段階では、「どの業務からエージェント化するか」「Entraの権限体系とAgent単位の権限をどう整合させるか」といった設計論点が新たに出てきます。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、Entra IDの認可基盤と連携して業務プロセスに載せる運用基盤として機能します。

• Entra IDと連携したAgent単位の権限設計
  Entra IDのユーザー・グループ・条件付きアクセスを、Agent単位のアクセス範囲と紐付けて設計。Entra Agent IDプラットフォーム（2026年4月GA）とも整合的に運用できます。
  
  
• 業務特化Agentを部門別ユースケースから立ち上げ
  経費精算・議事録・受発注などの事前構築Agentから始められるため、Entraの権限体系に沿った業務Agent展開の第一歩を短期間で切れます。
  
  
• 構築基盤が違っても管理は1つ
  Copilot Studioやn8nなど複数の構築基盤で作ったAgentを1つのダッシュボードに集約。実行ログ・アクセス権限・セキュリティスキャンを一元管理します。
  
  
• データは100%自社Azureテナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、Entra IDの認可基盤設計から業務Agent展開まで一貫して支援します。AI Agent Hubのサービスページで、Entra ID×Agentの実装例をご確認ください。

---

まとめ

本記事では、Microsoft Entra IDについて、Entraファミリー全体での位置づけ・主要機能・料金プラン・関連プロダクトとの使い分け・導入設計・判断で迷う論点までを、2026年7月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• Entra IDはAzure ADの正式後継（2023年7月改称）で、Suite・Governance・External ID・Verified ID・Agent IDを土台に成立させるEntraファミリー中心の基盤製品
• 主要機能はSSO・MFA・条件付きアクセス・ID Protection・Passkeys・Entra Connectで、2026年時点でPasskeysとセルフサービスアカウントリカバリが大幅拡張、Entra Agent IDは2026年4月GA
• 料金はFree/P1 $7/P2 $10/Suite追加$12で、M365 E3にP1・E5にP2がバンドルされる形が実務上一般的
  
  

Entra IDはMicrosoft 365やAzureを使うなら実質必須の製品ですが、どのプランで導入するかは業務要件と将来のAIエージェント展開まで見据えて決める価値があります。まずは自社の要件がFree/P1/P2/Suiteのどのレイヤーに属するかを整理し、Entra Agent ID対応の設計まで見通したロードマップを描くのが、AI時代の統合IAM基盤を構築する第一歩になります。