導入
Active Directory（AD）、Microsoft 365（M365 / Entra ID）、あるいは Exchange Online をまたぐアカウント管理では、1回のリクエストに対して、複数の実行先へ整合性を保ちながらデータを反映しなければならない場面が多くあります。
この記事では、アイデンティティやメール管理が混在する「ハイブリッド環境」を想定したユーザー管理機能を題材に、どの操作を AD コマンドで行い、どこから Microsoft Graph API を使い、どこを Exchange Online PowerShell に任せるべきなのか、その役割分担と実装の注意点を整理します。
環境
この記事で扱うのは、オンプレミスと M365 を併用・同期しているハイブリッド運用環境です。
- ディレクトリ：オンプレミス AD と Entra ID の両方を扱う
- メール関連：オンプレミス側の Exchange 管理ツール と Exchange Online の両方を扱う
- 同期：AD に作成したオブジェクトは、Microsoft Entra Connect 等の同期を経て Entra ID / Exchange Online に反映される
つまり、管理システム側で1度「ユーザー作成」を実行するだけでも、オンプレミス側のコマンドだけで完結させることはできず、後段で Graph API や Exchange Online PowerShell を適切に使い分ける設計が必要になります。
本記事では、実装コードそのものよりも、各環境におけるコマンド・APIの役割分担と、操作ごとに「何を目的として、どの順番で流すか」という設計思想・実務的なTipsを主題にします。
利用ツール
-
AD操作：PowerShell (
ActiveDirectoryモジュール) - Exchange管理ツール：オンプレミス Exchange サーバー操作（PowerShell）
- Entra ID操作：Microsoft Graph API v1.0 (API)
- Exchange Online操作：Exchange Online PowerShell（リモート接続）
※以降 Entra ID 操作のパスについては、API v1.0 のパス：https://graph.microsoft.com/v1.0 を省略する。
本システムで実現したい操作（要件）
このユーザー管理機能では、単なるアカウントのCRUD（作成・削除など）にとどまらず、実際の組織運用に即した以下の一連の操作を一元管理・自動化することを目的としています。
ユーザーの新規作成と初期セットアップ
ユーザーを「業務ができる状態」にするため、複数のインフラ層にまたがる環境構築をワンストップで行います。
- アカウントの作成: オンプレミス AD または M365 上へのユーザーオブジェクトの生成
- メールボックス作成: ユーザーがメールを送受信できる環境（メールボックス）のプロビジョニング
- メールボックスの詳細設定: 組織のポリシーに合わせたクォータ（容量制限）や各種属性（アドレス帳非表示や転送など）の設定
- ライセンスの付与: クラウド機能を利用可能にするため、一般的な「Microsoft 365 E3」ライセンスの紐付け
ユーザー情報の更新・削除
人事異動や組織変更に伴う、従業員情報の変更や所属の変更に追従します。
- 部署、役職、従業員番号などの基本属性の更新
- メールアドレスの追加、更新
- 退職等に伴うアカウントの削除（データ保全を含むフェーズ管理）
各種ライフサイクル・運用保守操作
日々の運用で頻繁に発生するユーザーからのリクエストや、セキュリティ対応を迅速に行えるようにします。
- パスワードリセット: パスワードを忘れたユーザーへの初期化処理
- MFA（多要素認証）のリセット: デバイス紛失や機種変更に伴う、登録済み認証メソッド（Authenticator、SMSなど）の安全な初期化
1. ユーザー作成
パターンA：AD 起点（同期ユーザー）の作成フロー
オンプレミスADをマスターとして、クラウドへ同期するパターンです。以下の順序でコマンド・APIを制御します。
-
AD ユーザーの作成：
New-ADUser(AD) -
オンプレ側でのメール有効化：
Enable-RemoteMailbox(Exchange管理ツール) -
メール属性調整：
Set-RemoteMailbox(Exchange管理ツール) -
ライセンス付与：
POST /users/{id}/assignLicense(Graph API) -
クラウド側メール属性調整：
Set-Mailbox(Exchange Online PowerShell)
各コマンドの実装Tips
-
New-ADUser
-AccountPasswordで初期パスワードを設定します。このパスワードは同期によってM365に引き継がれるため、ADで登録した UPN (userPrincipalName) と初期パスワードでM365にサインイン可能になります。
ただし、-ChangePasswordAtLogon $true（初回ログイン時にパスワード変更を強制）を設定すると、パスワード再設定までM365へのサインインができない仕様があるため注意が必要です -
Enable-RemoteMailbox
ハイブリッド運用では、オンプレ側から見て「クラウドにメールボックスを作らせる」状態にするため、Remote メールボックス系コマンドを使います。この際、-RemoteRoutingAddressの設定が必須です。ここで有効化を噛ませないと、後続のメール属性調整コマンドが通りません -
Set-RemoteMailbox
メールボックスの基本設定を行います。プライマリメールアドレス（PrimarySmtpAddress）、セカンダリを含むアドレスリスト（EmailAddresses）、アドレス帳からの非表示設定（HiddenFromAddressListsEnabled）など、ディレクトリ同期の対象となるメール属性はここで担保します -
POST /users/{id}/assignLicense
ライセンス付与前にあらかじめ Microsoft Entra Connect 等による同期を完了させ、オブジェクトが Entra ID 側に反映されている必要があります。また、ライセンスを割り当てる前に、必ずユーザーの「利用場所（usageLocation）」を設定しておく必要があります。 AD側の属性であらかじめ設定を同期させるなら、msExchUsageLocationにJPなどを書き込んでおきます。{id}には、オブジェクトのGUID、またはUPNが使用可能です -
Set-Mailbox
メールの送信サイズ上限（MaxSendSize）、転送設定、各種メールボックスクォータ（容量制限）など、Exchange Online側で直接制御されている属性については、後段でこのコマンドを叩いて最終調整を行います
パターンB：M365 起点（クラウド専用ユーザー）の作成フロー
社内ドメインに参加しないアカウントや、特定のクラウド専用権限を持たせるパターンです。
-
クラウドユーザー作成：
POST /users(Graph API) -
ライセンス付与：
POST /users/{id}/assignLicense(Graph API) -
メール設定調整：
Set-Mailbox(Exchange Online)
各コマンドの実装Tips
- クラウド側に直接作成されたオブジェクトはオンプレミス AD へは逆同期されないため、ドメイン参加PCへのログオンなど、オンプレ側のリソース利用はできません
- クラウド起点の場合、
Enable-Mailboxのような明示的な有効化コマンドは不要です。「Exchange Online」プランを含むE3ライセンス等を付与した時点で、クラウド側で自動的にメールボックスがプロビジョニング（生成）されます。
※AD同期ユーザーであってもライセンス付与のみでメールボックス自体は作成されますが、オンプレ側の管理ツールを経由しておかないと、ルーティングやディレクトリ属性の不整合で後々事故の原因になります。
2. ユーザー情報更新
AD ユーザー（同期ユーザー）の属性更新：Set-ADUser
オンプレミス AD ユーザーの基本属性（EmployeeID, Department, Title など）の更新は Set-ADUser を利用します。
コマンド実装時の注意
- 空値（Null）の扱い
基本は属性値をそのまま上書きすれば問題ありませんが、「値を空（クリア）にしたい」場合に落とし穴があります。PowerShellの仕様上、単に$nullや空文字（""）を渡しても無視されるかエラーになります。確実に値を消去したい場合は、-Clearパラメータを明示的に指定するか、-Replaceパラメータに空のハッシュテーブルを渡す必要があります。
メールアドレスの追加・更新の罠：Set-RemoteMailbox
Exchange管理ツールの Set-RemoteMailbox でメールアドレス（-EmailAddresses）を変更する際は細心の注意が必要です。
配列で値をそのまま {"SMTP:primary@example.com", "smtp:secondary@example.com"} のように完全上書き指定してしまうと、システムやMicrosoft製品によって自動生成されていた古い形式のアドレス（X.500 や X.400 ）などが消えます。
これを防ぐため、以下のアプローチで安全に（既存のアドレスに影響を与えることなく）差分制御します。
-
プライマリアドレスの変更:
-PrimarySmtpAddressパラメータを使用して更新する（古いプライマリは自動的にセカンダリへ降格します） -
安全な削除: 完全に不要になった古い（降格された）セカンダリアドレスを削る場合は、ハッシュテーブルの型表現を用いて
@{Remove="smtp:old@example.com"}を使う -
安全な追加: 新しいセカンダリアドレスを追加する場合は、
@{Add="smtp:new_secondary@example.com"}を使う
クラウド専用ユーザーの更新
Graph API の PATCH /users/{id}、および Exchange Online の Set-Mailbox を使用します。メールアドレスの追加・更新に関する注意点（@{Add=...} や @{Remove=...} の利用など）は、オンプレ側と同様です。
3. ユーザー削除
ユーザーの退職等で、アカウントを削除する場合を想定します。
オンプレミス AD ユーザーの場合 Remove-ADUser を行い、それが M365 に同期されることでグループからの除外、ライセンスの剥奪、メールボックスの削除が連動して自動実行されます。
しかし、退職と同時にすべてを即時削除してしまうと、業務の引き継ぎや監査ログの確認の際に高確率で困ります。そのため、実務では以下のような「段階的なステップ」を踏むのが安全です。
ステップ1：アカウントの即時ロックとセッション強制切断（退職直後）
-
パスワードリセット：
Set-ADAccountPassword(AD) ※第三者のログインを遮断 -
アカウントの無効化：
Set-ADUserの-Enabled $false(AD) -
既存グループからの除外（権限の削除）：
Remove-ADGroupMember(AD)、DELETE /groups/{group_id}/members/{id}/$ref(Graph API) など -
クラウドセッションの強制切断：
POST /users/{id}/revokeSignInSessions(Graph API)
ステップ2：メールデータの保全（引き継ぎ期間）
メールボックスのデータを残しつつ、後続の担当者が確認できるように共有メールボックス化します。
-
共有メールボックスへの変換：
Set-RemoteMailbox(Exchange管理ツール)で-Type Sharedに上書き -
ライセンスのコスト削減：
POST /users/{id}/assignLicense(Graph API) でE3ライセンスを剥奪（ライセンスなしで保持可能）
ステップ3：完全削除（猶予期間経過後）
社内ポリシーで定めた保存期間やログの監査期間が過ぎた後、オンプレAD側で Remove-ADUser を実行し、ライフサイクルを完了させます。
クラウド専用ユーザーの削除
PATCH /users/{id} でのアカウント無効化や Set-Mailbox でのメールボックス共有化を実施、最終的な削除には DELETE /users/{id} を使用して同様のフェーズを実装します。
4. パスワードリセット
AD ユーザー（同期ユーザー）
Active Directory の Set-ADAccountPassword を使用します。
初回ログイン時の変更を強制する場合は、Set-ADUser を呼び出して -ChangePasswordAtLogon $true を設定します。
※パスワード変更強制時は、初回ログイン後に設定した新しいパスワードでないとM365へサインインできなくなります。
クラウド専用ユーザー
Graph API を使用し、PATCH /users/{id} のリクエストボディに含まれる passwordProfile オブジェクトに対して新しいパスワードと変更強制フラグを設定します。
5. MFA（多要素認証）のリセット
デバイスの紛失や機種変更の際、管理者側でMFAをリセットして再セットアップさせる処理です。M365（Entra ID）側でのみ発生する操作となります。
Microsoft Graph API の /users/{id}/authentication 配下にある認証メソッドのエンドポイントを利用し、登録されているID（認証ID）を取得した上で、以下の主要なメソッドごとに削除処理を実行します。
-
phoneMethods（電話番号・SMS） -
microsoftAuthenticatorMethods（Microsoft Authenticator アプリ） -
softwareOathMethods（サードパーティ製認証アプリなどのOTPコード）
リセットの流れ（例：電話番号認証の場合）
-
GET /users/{id}/authentication/phoneMethodsで登録されているIDを取得 -
DELETE /users/{id}/authentication/phoneMethods/{auth_id}で対象のメソッドを削除
※"phoneMethods"のパスを、各メソッド名に置き換えることでリセットできます
コマンド実装時の注意
デフォルト認証方法の順序制御
ユーザーが複数の認証メソッドを登録している場合、「デフォルトのサインイン方法」が裏で設定されています。
MFA情報を初期化したい場合、このデフォルトに指定されている認証メソッドを先に消そうとするとエラーを返します。デフォルト認証方法は「必ず一番最後」に削除しなければいけません。
しかし、ユーザーごとのデフォルト認証方法はユーザー情報から直接取得できません。以下の監査レポート用APIを中継します。
GET /reports/authenticationMethods/userRegistrationDetails
このAPIに、$filter=userPrincipalName eq '{user_principal_name}' などのフィルターを指定して叩くことで、対象ユーザーが何をデフォルト（userPreferredMethodForSecondaryAuthentication）にしているかを事前に判別し、削除のスタック順序を制御するロジックが必要になります。
ハイブリッド運用・実装上の注意
最後に、ハイブリッド環境のユーザー管理システムを構築・運用する上で、特に注意すべき点を2つ挙げます。
① メールボックス系操作は「待機とリトライ」が前提
AD から M365 へのディレクトリ同期（Entra Connect）にタイムラグがあるのは周知の事実ですが、注意すべきはクラウド側（Exchange Online）の挙動です。
ライセンスを付与（assignLicense）してから、クラウド上で実際にメールボックスのプロビジョニングが完了するまでには、数分程度の非同期な待ち時間が発生します。この生成処理が裏で完了する前に Set-Mailbox や訴訟ホールド（LitigationHold）の設定などを投げても、オブジェクトが見つからずエラーになります。
メールボックス関連の処理は「1発で成功する単発コマンド」とは見なさず、システム側で成否を監視し、バックオフ付きの非同期リトライ、あるいはキューによる遅延実行メカニズムを最初から組み込んでおくのが賢明です。
② 4つの系統を使い分ける
ここまで見てきた通り、「ユーザーの管理」という単一のビジネスロジックを通すために、内部的に全く異なる4つのインターフェースを使う必要があります。
- オンプレミス AD コマンド
- オンプレミス Exchange 管理ツール
- Microsoft Graph API
- Exchange Online PowerShell
これらを1つのベタ書きスクリプトやコントローラーに混在させると、接続管理やエラーハンドリングが地獄と化します。
システム実装の際は、各インターフェースを叩く処理を「ADリポジトリ」「GraphAPIクライアント」「EXOサービス」のようにレイヤーとして完全に分離（カプセル化）し、上位のビジネスロジック層からは「どの系統のコマンドが流れているか」を意識させない設計（関心事の分離）を徹底することを推奨します。
まとめ
ハイブリッド環境におけるユーザー管理は、単なる「データベースのCRUD操作」の延長線上にはありません。
- 作成時: AD起点とクラウド起点で必要なコマンド群が根本から異なる
- 更新時: 空値クリアの挙動や、メールアドレス変更時に既存の特殊アドレスを巻き添えにしない配慮が必要
- 削除時: 即時削除ではなく、セキュリティ確保とデータ保全（共有化）のためのフェーズに分けた制御を行う
- MFAリセット: デフォルト認証方法の削除順序に特有の仕様（罠）がある
- 非同期処理: ライセンス反映やメールボックス生成を待つ「リトライ」構造が必須
インフラの構成（オンプレとクラウドのハイブリッド）や Microsoft 製品の仕様が複雑であるからこそ、管理システム側の設計で「どこに、何を、どの順番でやらせるべきか」を整理整頓しておくことが、安定した運用への一番の近道です。