Microsoft Entra IDとは｜旧Azure ADとの違いと構築案件

Microsoft Entra IDとは（旧Azure AD）

Microsoft Entra IDは、クラウド上でユーザー・グループ・アプリケーション・デバイスのIDを保持し、サインインの認証と認可を担うサービスです。Microsoft 365を契約した時点でテナントが作られ、裏側で必ず動いています。つまり「Azureを使っていないから関係ない」ということはありません。

Microsoftは2023年7月11日に名称変更を発表し、8月15日から各種エクスペリエンスでの切り替えを開始、2023年末までにほとんどの表記変更を完了しています。目的は、マルチクラウド・マルチプラットフォームで動く製品であることを名前で示すことと、オンプレミスのWindows Server Active Directoryとの混同を避けることです。詳細はMicrosoft Learn「Azure Active Directory の新しい名称」に公式の対応表があります。

なお「Microsoft Entra」は製品ファミリの名前で、Entra IDはその中の1製品です。ファミリには外部ID、ID ガバナンス、ワークロードID、確認済みID、ネットワークアクセス系のInternet Access / Private Accessが含まれます。案件票に「Entra導入」とだけ書かれている場合、どこまでを指すのかは面談で確認が要ります。

名称変更で変わったもの・変わらなかったもの

結論から言うと、変わったのは表示名とアイコンだけです。ライセンス・契約条件・SLA・価格・サポート範囲に変更はありません。

一方、次のものは名称が変わっていません。現場のドキュメントやスクリプトを書き換える必要はない、という意味で実務上は重要な点です。

• 既存のログインURL、REST API、PowerShellコマンドレット、Microsoft Authentication Library（MSAL）

• Windows Server Active Directory、AD DS、AD FS といったオンプレミス側の製品名

• Azure AD B2C（ただしMicrosoftは2025年5月1日以降、新規顧客への販売を終了しています。既存テナントは引き続き利用できますが、これから顧客向けID基盤を新設する案件ではMicrosoft Entra External IDが選択肢になります。移行の要否と期限は公式の案内で確認してください）

開発者向けの周辺モジュールには廃止の動きがあります。Azure AD Graphは非推奨で、新機能への投資はMicrosoft Graphにのみ行われます。PowerShellもAzure AD PowerShell for Graphが非推奨となっており、Microsoft Graph PowerShellへの移行が推奨されています。古い運用スクリプトが残っている現場では、この移行自体が切り出された案件になることがあります。PowerShell側の仕事の広がりはPowerShell案件の実情｜フリーランス単価・情シス系の参入方法で整理しています。

オンプレミスのActive Directoryとの違い

同じ「ディレクトリ」でも設計思想が違います。ADはLDAPとKerberosを前提に、社内ネットワークの中でドメイン参加したWindows端末とサーバーを束ねる仕組みでした。Entra IDはHTTPSベースで、SAMLやOpenID Connect、OAuth 2.0といったWeb標準のプロトコルを使ってクラウドサービスへのアクセスを束ねます。

重要なのは、Entra IDがADの完全な置き換えにはならないケースがある点です。Kerberos認証を前提としたファイルサーバーや業務パッケージ、グループポリシーによる端末制御が残っていると、オンプレADを残したままのハイブリッド構成を選ぶことになります。認可の仕組みそのものを押さえたい場合はOAuth 2.0とは｜認可の仕組み・4つのグラントとPKCEを解説が参考になります。

ミニFAQ：Entra IDを入れればオンプレADは撤去できますか。

できるケースとできないケースがあります。端末がすべてMicrosoft Entra参加に移行でき、Kerberos依存の社内システムが残っていなければ撤去の検討対象になります。ファイルサーバーや古い業務システムが残る場合は、Entra Domain Servicesで代替できるか個別に判定が必要です。

ライセンス体系と機能の線引き

Entra IDの設計は、ほぼライセンスの線引きで決まります。使いたい機能がP2にしかないのに予算がP1までしか取られていない、という前提崩れは珍しくありません。参画初期に必ず確認する項目です。

以下はMicrosoft Entra の価格ページに掲載されている金額で、年間サブスクリプション契約時のユーザーあたり月額です。価格もライセンスに含まれる機能の線引きも改定されるため、提案時は必ず公式の価格ページとライセンスガイドで確認してください。以下は2026年10月24日時点の表示です。

Freeでできること・できないこと

Freeでも無制限のSSOとセルフサービスのパスワード変更、基本的なMFAは使えます。ただし条件付きアクセスが使えないため、「国内からのアクセスのみ許可する」「未管理端末からのダウンロードを禁止する」といった制御はできません。Freeで実現できるのはセキュリティ既定値群による一律のMFA強制までで、例外も細かい条件も作れない点が設計上の制約になります。

P1とP2の分かれ目

P1で引ける線は「条件（ユーザー・場所・端末・アプリ）に応じてアクセスを許可・拒否・追加認証する」ところまでです。P2になると、サインインの挙動からリスクを算出し、リスクが高いときだけ追加認証を求めるといった動的な制御ができます。さらにPIMによって、管理者権限を常時付与ではなく申請と承認を経た時間限定の付与に変えられます。

管理者権限の常時付与をやめたい、監査でアクセス権の定期棚卸しを求められている、という要件が出てきたらP2またはID ガバナンスの検討に入ります。ゼロトラストの文脈でこの話が持ち込まれることも多く、全体像はゼロトラストとは｜境界型との違い・主要技術・案件動向を解説で整理しています。

Microsoft 365ライセンスに含まれる分

単体購入だけでなく、Microsoft 365のプランに同梱される形でも提供されています。Microsoft 365 E3にはMicrosoft Entra ID P1が、Microsoft 365 E5にはP2が含まれます。既にE5を契約している企業なら、PIMもID Protectionも追加費用なしで使える状態にあるのに設定されていない、という状況が起きます。これは参画初期に確認すると価値を出しやすいポイントです。

構築案件で中心になる機能

ここから先は、案件の作業項目として実際に登場しやすい機能に絞ります。製品全体を網羅するより、どの機能がどの工程で問題になるかを押さえるほうが現場では役に立ちます。

条件付きアクセス

Entra ID案件の中核です。「誰が」「どこから」「どの端末で」「どのアプリに」アクセスしたときに、許可・ブロック・MFA要求・セッション制御のどれを適用するかをポリシーとして定義します。

設計で揉めるのは、ほぼ例外処理です。サービスアカウント、業務委託の外部ユーザー、海外出張者、オフライン作業が必要な現場端末など、一律のポリシーで止まってしまう相手をどう扱うか。ここを曖昧にしたまま有効化すると、運用開始直後に問い合わせが集中します。

多要素認証とパスワードレス

MFAはEntra IDの標準機能ですが、どの認証方式を許可するかが設計項目です。SMSは利便性が高い反面、フィッシングやSIMスワップに弱く、パスキー（FIDO2）や証明書ベース認証へ寄せる判断がよく議論になります。

PIMとID Protection

PIMはP2の機能で、グローバル管理者のような強い権限を「必要なときに申請して、承認を経て、数時間だけ有効にする」運用に変えます。ID Protectionは、ありえない移動（短時間での地理的に離れた場所からのサインイン）や漏えい資格情報の検知をリスクスコアとして扱い、条件付きアクセスの条件に使えるようにします。

ID ガバナンス

エンタイトルメント管理でアクセスパッケージを定義し、入社・異動・退職に合わせて権限を自動で付け外しする仕組みです。アクセスレビューを組むと、定期的に上長へ棚卸しを促せます。監査対応やISMS・SOC 2の要求が起点になることが多く、ISMS・SOC2取得支援案件｜フリーランスの実装・証跡業務と単価の領域と地続きです。

SaaSへのSSO統合

アプリギャラリーに登録済みのSaaSならSAMLまたはOpenID Connectでの連携がテンプレート化されていますが、実務の時間を食うのは属性マッピングとプロビジョニングです。SCIMでユーザーを自動作成・削除できるSaaSなのか、手動運用を残すのか。この判断が運用コストを大きく左右します。Microsoft 365側の移行とセットで動く案件も多く、周辺の仕事はSharePoint案件の単価と実務｜Microsoft 365移行と参入ルートにまとめています。

ミニFAQ：条件付きアクセスのポリシーは何本くらいが適正ですか。

本数そのものに正解はありませんが、同じ条件を複数ポリシーに分散させると調査が難しくなります。レポート専用モードで影響を確認してから有効化し、除外対象は個別ユーザーではなくグループに寄せておくと、後任への引き継ぎが楽になります。

オンプレADとのハイブリッド構成

既存ADが残る環境では、ADとEntra IDの間でユーザーを同期します。同期方式の選択は後から変えるコストが高いため、設計フェーズで決め切る必要があります。

Entra Connect SyncとCloud Syncの選び方

Entra Connect Sync（旧Azure AD Connect）は、オンプレミスのサーバーに同期エンジンを置く従来型です。属性フローを細かくカスタマイズでき、複雑な要件に対応できます。

Cloud Syncは、オンプレミスには軽量のプロビジョニングエージェントだけを置き、同期の構成と処理はMicrosoft側のサービスが担います。Microsoft Learnのクラウド同期の解説によれば、同期はスケジューラベースで動作し、既定では2分ごとに実行されます。

判断の順番としては、まずCloud Syncで要件を満たせるかを移行判断ガイドで確認し、満たせない部分があればConnect Syncを継続する、という進め方が公式に案内されています。「新しいほうを選ぶ」ではなく「要件が収まるか」で決める論点です。

よくある詰まりどころ

• UPNとメールアドレスの不一致：オンプレADのUPNが社内ドメインのままで、クラウド側のサインイン名と揃っていない。移行前の棚卸しで最も工数を食う部分

• 重複属性：proxyAddressesやUPNの重複で同期エラーになり、原因の特定に時間がかかる

• 認証方式の選択：パスワードハッシュ同期、パススルー認証、フェデレーション（AD FS）のどれを採るか。AD FSが残っている場合、その撤去までをスコープに含むかで工数が変わる

• デバイス参加の状態：Microsoft Entra参加、ハイブリッド参加、登録済みの違いが整理されていないまま条件付きアクセスの「準拠デバイス」を条件にすると、広範囲でサインインが弾かれる

フリーランスのEntra ID案件はどう切り出されるか

Entra IDの仕事が独立した案件として立つ背景のひとつに、Microsoftによる管理者MFAの必須化があります。Microsoft Learnの必須MFAの解説によると、適用は2段階です。

• フェーズ1（2024年10月以降）：Azure portal、Microsoft Entra 管理センター、Microsoft Intune 管理センターへのサインインでCRUD操作を行うアカウントにMFAが必要。Microsoft 365 管理センターは2025年2月から段階適用

• フェーズ2（2025年10月1日以降）：Azure CLI、Azure PowerShell、Azureモバイルアプリ、IaCツール、REST APIからの作成・更新・削除操作にMFAが必要。読み取り操作は対象外

マネージドIDやサービスプリンシパルといったワークロードIDは対象外ですが、ユーザーIDを自動化のサービスアカウントとして使っている環境は影響を受けます。この棚卸しと移行が、情シス側の手に余って外部に出るケースがあります。なお、複雑な環境向けにフェーズ2の開始を2026年7月1日まで延期できる申請窓口が用意されていましたが、その期限は本記事の更新時点（2026年10月24日）ではすでに過ぎています。延期していた環境も適用済みの前提で、自動化処理が止まっていないか、MFAに対応できないサービスアカウントが残っていないかを確認する段階に入っています。

案件の形は、おおむね次の3つに分かれます。

設計・構築

新規テナントの設計、条件付きアクセスのポリシー体系づくり、MFA方式の選定と展開。要件定義からの参画だと、情シス部門や監査部門との調整が業務の半分を占めることもあります。

移行・統合

オンプレADからのハイブリッド化、AD FSの撤去、他社IdP（Okta、PingFederateなど）からの移行、M&Aに伴うテナント統合。期間が区切られやすく、短期で切り出されやすい型です。

運用・ガバナンス

アクセスレビューの運用設計、PIMの申請承認フロー構築、Intuneと組み合わせた端末準拠ポリシーの維持。常駐または週2〜3日の継続案件になりやすい領域です。

探し方としては、エージェントのスキルタグでAzureを選び、キーワードに「Entra」と「Azure AD」の両方を入れるのが実務的です。名称変更から時間が経った現在でも、案件票の表記は両方が混在しています。フリコンでもAzureスキルの案件やセキュリティエンジニアの案件から辿れます。

単価の目安と必要スキル

単価レンジの内訳は認証基盤・IDaaS領域としてまとめているため、ここでは接続点だけ示します。認証基盤・IDaaSエンジニアのフリーランス案件動向｜単価・必要スキル・主要製品では、国内フリーランスエージェント各社の公開案件（週3〜5日・業務委託・リモートと常駐の混在）を横断して観測した目安として、IDaaSの導入やSSO統合を担うミドル層で月額80〜110万円前後、設計リードやゼロトラスト連携まで持つシニア層で月額110〜130万円前後というレンジを整理しています。公開案件ベースの目安であり、商流・稼働・スキルで変動する数字です。

このレンジに届く人の像としては、Windows Serverとネットワークの基礎があったうえで、SAMLまたはOpenID Connectの連携を自分でトラブルシュートでき、条件付きアクセスの影響範囲を事前に説明できる、という水準が一つの線になります。自分の経験でどのくらいの単価を狙えるか確かめたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価の上げ方を体系的に整理したものは【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にあります。

資格では、Azure全体の基礎としてAZ-104（Azure Administrator Associate）、ID領域の専門資格としてSC-300が参照されます。SC-300は「Microsoft 認定: アイデンティティおよびアクセス管理者アソシエイト」に対応する試験で、Microsoft Learnの認定ページによれば試験時間は100分、認定の更新頻度は12か月です。出題は、ユーザーIDの実装と管理、認証とアクセス管理、ワークロードIDの計画と実装、ID ガバナンスの計画と実装の4領域に分かれます。Azure系資格の取得順はAzure認定資格おすすめ一覧｜AZ-900からのロードマップ・難易度・受験料で整理しています。

資格が案件獲得にどう効くかは職種によって差があります。ID基盤領域は顧客が金融・公共を含むことが多く、提案書に記載できる資格が評価されやすい部類に入ります。とはいえ資格だけで通過するわけではないので、スキルシートに「どの規模のテナントで、どの機能を、どこまでの責任範囲で担当したか」を書けることのほうが重要です。書き方はインフラエンジニアのスキルシートの書き方｜構築・運用実績の数値化と職種別テンプレを参照してください。

参画前チェックリスト

面談と参画直後に確認しておくと手戻りが減る項目です。

• 対象テナントのライセンスはFree・P1・P2・ID ガバナンスのどれか。Microsoft 365のプラン同梱分を含めて確認したか

• オンプレADは残るのか、撤去まで含むのか。残る場合の同期はConnect SyncかCloud Syncか

• 認証方式はパスワードハッシュ同期・パススルー認証・フェデレーションのどれか。AD FSの撤去はスコープに入るか

• 条件付きアクセスの既存ポリシーは何本あり、レポート専用モードで影響を測れる環境があるか

• 管理者ロールの付与状況。グローバル管理者が何人いるか、PIM化の合意は取れているか

• MFA必須化のフェーズ2が適用済みか。延期申請をしていた場合、対応が完了しているか

• 自動化に使っているユーザーIDのサービスアカウントは洗い出されているか

• 検証用テナントが用意されているか。本番テナントで試すしかない状況になっていないか

• 障害時の切り戻し手順と、緊急用アクセスアカウント（ブレークグラス）の運用が決まっているか

このうち検証用テナントの有無は、参画後の進め方を大きく左右します。用意がない場合、条件付きアクセスの変更は全社のサインインに直結するため、レポート専用モードでの事前確認を前提に段取りを組み直すことになります。案件を比較する段階での優先順位の付け方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位にまとめています。

よくある失敗と対策

条件付きアクセスを一気に本番適用する

レポート専用モードを使わずに有効化し、想定外のアプリやサービスアカウントが弾かれるパターンです。対策は、レポート専用で数日分のサインインログを取り、影響を受けるユーザーとアプリを一覧化してから有効化すること。緊急用アクセスアカウントを除外対象に入れておくことも併せて必要です。

ライセンス前提の確認漏れ

設計書にPIMとリスクベースの条件付きアクセスを書いたあとで、契約がP1だったと判明するケース。追加購入の予算承認に時間がかかり、設計のやり直しになります。初回の面談で「使えるライセンスは何か」を聞いておくと避けられます。

名称の混在で認識がずれる

顧客は「Azure AD」と呼び、ベンダーは「Entra ID」と呼び、資料によってはAADと書かれている。同じものを指しているのか、オンプレADのことなのかが曖昧になり、要件が食い違います。キックオフの資料で呼称を1つに決めておくと、以降の会話が整理されます。

旧PowerShellモジュール前提の運用が残る

Azure AD PowerShellのコマンドレットを使った運用スクリプトが残っている現場では、Microsoft Graph PowerShellへの移行が必要になります。参画後に「既存スクリプトが動かない」と発覚すると、スコープ外の作業が発生します。既存の自動化資産の棚卸しを初期タスクに入れておくのが安全です。

まとめ

Microsoft Entra IDは旧Azure ADの新しい名称で、機能は変わっていません。実務で効いてくるのは名称そのものより、ライセンスの線引きとオンプレADとの同期方式の選択です。

• 名称変更は2023年7月11日に発表、サービス プランの表示名は2023年10月1日に切り替え。ログインURL・API・PowerShellコマンドレット・MSALは変更なし

• 条件付きアクセスはP1から、PIMとID ProtectionはP2から。Microsoft 365 E3にはP1、E5にはP2が含まれる

• ハイブリッド構成は、Cloud Syncで要件を満たせるかを先に判定し、満たせない場合はConnect Syncの継続か段階的な移行計画を検討する

• 管理者MFAの必須化はフェーズ1が2024年10月以降、フェーズ2が2025年10月1日以降。フェーズ2の延期申請の期限（2026年7月1日）も過ぎており、現在は適用済みの前提で確認する

• 案件は設計・構築、移行・統合、運用・ガバナンスの3つの型に分かれる。短期で切り出されやすいのは移行・統合

• 参画前には、ライセンス・同期方式・AD FSの扱い・検証用テナントの有無の4点を最低限確認する

次の一歩としては、検証用テナントを1つ作り、条件付きアクセスをレポート専用モードで動かしてログを読むところまでやってみることをおすすめします。手を動かした範囲はそのまま面談で話せる材料になります。ID基盤領域の案件全体の相場やキャリアの広がりは認証基盤・IDaaSエンジニアのフリーランス案件動向｜単価・必要スキル・主要製品を、インフラ領域からの独立手順はインフラエンジニア独立の全手順｜必要経験・単価相場・案件動向をあわせて確認してください。

参照した一次情報は次のとおりです。

• Azure Active Directory の新しい名称（Microsoft Learn）

• Microsoft Entra の価格（Microsoft）

• 必須の Microsoft Entra 多要素認証 (MFA) を計画する（Microsoft Learn）

• Microsoft Entra クラウド同期とは（Microsoft Learn）

• Microsoft 認定: アイデンティティおよびアクセス管理者アソシエイト（Microsoft Learn）