退職者のオフボーディングをEntra ID（Azure AD）ライフサイクル ワークフローで自動化する際、「グループから削除」だけでなく「ユーザーのメールボックスを共有メールボックスへ変換」まで、Logic Apps＋Microsoft Graph APIだけで完結させたい場面があります。本記事では、仕様上の限界と、実務で詰まらないための現実解をまとめます。
結論：Microsoft Graph APIだけでは「ユーザーメールボックス→共有メールボックス」変換はできない
最初に結論から言うと、Microsoft Graph API単体（およびLogic AppsからGraph APIを呼ぶだけ）で、Exchange Online上の「メールボックス種別（ユーザー／共有）」を切り替える操作は実現できません。MicrosoftのQ&Aでも、Graph関連ドキュメント上に“変換のための更新機能がない”ことが明示され、機能要望（フィードバック）を案内する回答が採用されています。
つまり、退職ユーザーのオフボーディングで以下を同一ワークフローに入れたい場合、
- グループから削除する
- アカウントを無効化する／サインインを止める
- （重要）ユーザーメールボックスを共有メールボックスに変換する
このうち「メールボックス変換」だけは、Graph APIの範囲を超えたExchangeの管理操作になります。
なぜGraph APIだけでは無理なのか
Graphで更新できるのは mailboxSettings など“メールボックス設定の一部”
Graphには「ユーザーの mailboxSettings を更新する」APIがありますが、ここで扱えるのは自動返信、言語／ロケール、タイムゾーン、勤務時間などの設定です。メールボックスの“種別（共有化）”を切り替える項目は含まれていません。
実務的には、次のようなイメージです。
| 分類 | Graph APIでできること | Graph APIでできないこと |
|---|---|---|
| Outlook/Exchangeの“利用設定” | 自動返信、ロケール、タイムゾーン、勤務時間などの更新 | メールボックス種別（User/Shared/Room等）の変換 |
| メールデータ操作 | メール／予定表／連絡先の読み書き（適切な権限が前提） | 管理者向けの“受信者タイプ変更” |
Graphは“共有メールボックスを扱える”が、“共有メールボックスへ変換する”APIではない
Microsoft GraphのOutlook Mail APIは、ユーザーのプライマリメールボックスだけでなく、共有メールボックス内のデータにもアクセスできる、と整理されています。これは「共有メールボックスのメールを読んだり送ったりできる」話であり、「ユーザーメールボックスを共有メールボックスへ作り替える（受信者タイプを変える）」話とは別物です。
“変換のupdate操作はない”ことが明言されている
Graph APIだけで変換したい、という質問に対して「Graph関連ドキュメント上、ユーザーメールボックスを共有メールボックスに変換するupdate機能がない」と回答され、参照として mailboxSettings の更新ドキュメントが提示されています。
共有メールボックスの“作成”もGraphでは直接できない
2025年の別Q&Aでも、共有メールボックスの作成はGraphでは直接サポートされず、Exchange Online PowerShellまたはExchange管理センターで実施する必要がある、という整理がされています（変換も同様に“Exchange管理領域”です）。
公式にサポートされる「ユーザーメールボックス→共有メールボックス」変換方法
管理画面（EAC）での変換
Exchange管理センター（EAC）では、ユーザーメールボックスと共有メールボックスの相互変換が案内されています。
Exchange Online PowerShell（Set-Mailbox）での変換
自動化（プログラムから実行）を考えると、基本はExchange Online PowerShellの Set-Mailbox が軸になります。Microsoft Learnでも、PowerShellでの変換構文として Set-Mailbox -Type <... | Shared> が示されています。
# 代表例（ユーザーメールボックス → 共有メールボックス）
Set-Mailbox -Identity [email protected] -Type Shared「Automation Account＋PowerShellは避けたい」という気持ちはよく分かりますが、“変換コマンド自体”は現状ここに寄せるのが最も確実です。
Microsoft 365 管理センター（ユーザー画面）での変換
UI操作であれば、Microsoft 365 管理センターのユーザー画面から「共有メールボックスに変換」を実行できます。加えて、変換後に条件を満たす場合はライセンスを外せる、アカウントは“アンカー”として残す必要がある、など運用上の注意点が明確に記載されています。
オフボーディング自動化で“メールボックス変換”が難所になる理由
変換前にライセンスが必要（外す順番を間違えると詰む）
ユーザーメールボックスを共有メールボックスに変換するには、変換前にライセンスが割り当てられている必要があります。ライセンスを外してしまうと変換オプションが出ないため、いったん戻してから変換する、という手戻りが起きます。
共有メールボックスは“無ライセンスだと50GB制限”が前提
共有メールボックスは無ライセンスで運用できるケースが多い一方、無ライセンスの場合はサイズが50GBに制限される、と明記されています（大きい場合は整理が必要になり得ます）。
ユーザーアカウントを削除すると困る（共有メールボックスのアンカー問題）
変換後も、元ユーザーのアカウントは共有メールボックスの“アンカー”として必要なので、削除しないよう注意が促されています。
パスワードをリセットしないと“元の資格情報でアクセス可能”になり得る
変換そのものの操作とは別に、セキュリティ上の落とし穴があります。変換後もパスワードをリセットしないと、元のユーザー名／パスワードが共有メールボックスに対して引き続き機能し得る、と明記されています。退職者対応では特に重要なポイントです。
訴訟ホールド／保持要件がある場合はライセンス前提になり得る
共有メールボックスに対してホールド（In-Place Hold / Litigation Hold）を設定するには、特定のExchangeライセンス構成が必要になる、と案内されています。コンプライアンス要件がある組織ほど、単純に「共有化してライセンスを外す」だけでは終わりません。
Graph＋ライフサイクル ワークフローでできること／できないことを実務目線で整理
| やりたいこと | Graph / ライフサイクル ワークフローで完結 | 補助が必要 | 補足 |
|---|---|---|---|
| 退職ユーザーをグループから削除 | 可能 | 不要 | 「Remove users from all groups」タスクが用意されています。 |
| ユーザーアカウントの無効化 | 可能 | 不要 | 「Disable user account」タスクが用意されています。 |
| Logic Appsをワークフローから呼び出す | 可能 | 不要 | カスタム タスク拡張でLogic Appsにコールアウトできます。 |
| ユーザーメールボックスを共有メールボックスに変換 | 不可 | 必要（Exchange管理） | 変換のupdate機能がGraphにない旨が回答されています。 |
| 共有メールボックスの新規作成 | 不可 | 必要（Exchange管理） | PowerShellまたはEACが必要という整理があります。 |
| 共有メールボックス内のメール操作（読み書き） | 可能（権限前提） | 権限設計が必要 | Graphは共有メールボックスのデータアクセスをサポートします。 |
現実解：ライフサイクル ワークフロー＋Logic Appsで“変換だけExchange PowerShellに逃がす”
全体アーキテクチャ（おすすめの分割）
「別リソースを増やしたくない」という制約があっても、メールボックス変換はExchange側の管理操作なので、どこかでExchange Online PowerShell（もしくは同等の管理手段）を実行する必要があります。そこで、ワークフロー全体はEntra側に寄せつつ、変換の一点だけを“外だし”にするのが現実的です。
Entra ID ライフサイクル ワークフロー（Leaver）
├─ グループ削除（組み込みタスク）
├─ アカウント無効化（組み込みタスク）
└─ カスタム タスク拡張（Logic Appsを起動）
└─ （変換処理）Exchange Online PowerShell 実行
└─ Set-Mailbox -Type Sharedライフサイクル ワークフロー側：組み込みタスク＋カスタム拡張
ライフサイクル ワークフローには「Run a Custom Task Extension（外部システムへコールアウト）」があり、Logic Appsと統合できます。
たとえば、Leaverシナリオでは以下の順序が運用上トラブルが少ないです（組織の要件で調整してください）。
| 推奨順 | タスク例 | 意図 |
|---|---|---|
| 早い | アカウント無効化（Disable user account） | 退職者のサインインを止める（最優先）。 |
| 次 | グループ削除（Remove users from all groups） | アクセス権を広く剥奪する。 |
| 次 | カスタム タスク拡張（Logic Apps呼び出し） | メールボックス変換など、組み込み外の処理へ。 |
| 遅め | ライセンス削除（必要なら） | 変換前に外すと変換できないため、順序に注意。 |
Logic Apps側：呼び出し方式は「Launch and continue」か「Launch and wait」を選ぶ
カスタム タスク拡張には、Logic Appsを起動して待たずに次へ進む方式と、結果を待って成否をワークフローへ返す方式があります。メールボックス変換のように“確実に終わったか”を追いたい処理は、運用的には待機方式（Launch and wait）を推奨することが多いです。
ただし、待機方式はタイムアウト設計（どのくらい待つか）や、再実行時の冪等性（同じユーザーに対して二重変換しない）まで含めて作り込む必要があります。
Exchange Online PowerShellを実行する“器”をどうするか（比較）
Graphだけで完結できない以上、現実には「PowerShellを実行できる場所」が必要です。代表的な選択肢を比較します。
| 選択肢 | 追加リソース | 向いているケース | 注意点 |
|---|---|---|---|
| Azure Automation（Runbook） | 必要 | 運用が枯れている／ジョブ管理が欲しい | 「リソースを増やしたくない」要件に抵触しやすい |
| Azure Functions（PowerShell） | 必要 | HTTPで呼び出して小さく実行したい | 実行権限（アプリ／証明書等）と秘密情報管理が肝 |
| 既存の運用基盤に“相乗り” | 追加を最小化 | すでにAutomation/Functionsが存在する | 責任分界・変更管理を整理しておく |
「どうしても新規リソースを増やしたくない」場合でも、既存のFunction AppやAutomation Accountに“相乗り”できるなら、実質的な増加を抑えられます（新規デプロイはしても、新しい運用品目を増やさない発想です）。
退職者オフボーディングで最低限押さえるセキュリティ手順
メールボックスを共有化して残す運用は一般的ですが、同時に「退職者本人が入れない状態」を作ることが必須です。Microsoftの手順でも、まずパスワードリセットやセッションサインアウトを行い、その後にサインインブロックを検討する流れが示されています。
- パスワードをリセットする（緊急停止として有効）
- 全セッションからサインアウトさせる（トークン猶予がある点に注意）
- サインインをブロックする（反映に時間がかかる可能性がある）
- ライフサイクル ワークフロー側でもアカウント無効化を入れておく（漏れ防止）
ここを曖昧にすると、「共有メールボックスに変換したのに、元ユーザーがアクセスできてしまう」という事故になりやすいので、ワークフロー設計では“セキュリティ手順を先に固定”するのがおすすめです。
どうしても「Logic Apps＋Graphだけで完結」させたいときの代替案
要件によっては、“共有メールボックス化”にこだわらず別のゴールへ置き換える方が、実装の複雑さを下げられます。
代替案：共有化せず、ユーザーメールボックスを保持（ライセンス維持）
最も単純ですが、ライセンスコストが継続します。短期間だけ引き継ぎ用途で必要、など限定的なケースでは合理的です。
代替案：Inactive mailbox（非アクティブメールボックス）で保持する
“受信は不要で、監査・検索・保全が目的”なら、非アクティブメールボックスが適する場合があります。非アクティブメールボックスは、退職者のメールを保持し、権限を与えられた担当者がコンプライアンス（eDiscovery等）目的でアクセスできる一方、メールを受信できず、アドレス帳にも表示されない、と説明されています。
非アクティブ化の基本は「ホールドをかけてからユーザーアカウントを削除する」流れで、Microsoft 365保持（retention）を使うのが推奨されています。
| 観点 | 共有メールボックス | 非アクティブメールボックス |
|---|---|---|
| 受信（退職者アドレスに届くか） | 届く（運用設計次第） | 届かない |
| 引き継ぎ（後任がOutlookで見続ける） | 得意 | 目的が違う（監査・保持寄り） |
| 実装難易度（Graph完結） | 変換が壁（Exchange管理が必要） | 保持設計が壁（Purview/保持要件の設計が必要） |
「共有化が必須」なのか、「退職者メールの保全・検索ができれば良い」のかで、ゴールを見直す価値があります。
よくあるハマりどころ（失敗を防ぐチェックリスト）
- ライセンスを先に外してしまい、変換できない：変換前にライセンスが必要である点を前提に、タスク順序を固定する。
- アカウントを削除してしまい、共有メールボックスのアンカーを失う：削除ではなく無効化・サインイン停止を優先する。
- パスワード未変更で退職者がアクセスできる状態が残る：パスワードリセット／セッションサインアウト／ブロックをセットで扱う。
- 共有メールボックスが50GBを超えてライセンスが外せない：サイズ見込みと、Plan 2付与の判断を事前に決める。
- カスタム拡張の“待機方式”がタイムアウトする：Launch and waitを選ぶ場合は待機時間と再実行設計を作る。
- ハイブリッド構成で管理経路を誤る：ハイブリッドではオンプレ側の管理ツールが必要になるケースがある。
Graph APIへの機能追加要望を出すなら
メールボックス変換をGraphでやりたい、というニーズは複数のユーザーが持っており、Microsoft側もフィードバック投稿を案内しています。要望を出す場合は、以下の情報を添えると“ユースケースが伝わる”要望になります。
- 対象：Entra ID ライフサイクル ワークフロー（Leaver）で完結させたい
- 理由：Automation Account等の別リソース追加を避けたい（ガバナンス・コスト・運用負担）
- 必要な最小機能：ユーザーメールボックスを共有メールボックスへ変換（受信者タイプ変更）
- 副作用：ライセンス、アンカー、セキュリティ停止（サインイン不可）まで含めた整合性
“変換のupdate機能がない”という前提と、フィードバック導線はQ&Aでも示されています。
まとめ：設計の着地点
Microsoft Graph APIは、共有メールボックスのデータアクセスや mailboxSettings の更新などは得意ですが、メールボックス種別の変換はサポート範囲外です。
退職者オフボーディングを自動化するなら、次の方針が現実的です。
- グループ削除・アカウント無効化などは、ライフサイクル ワークフローの組み込みタスクで実装する
- メールボックス変換だけは、Logic AppsからExchange Online PowerShell（Set-Mailbox）を実行できる仕組みに接続する
- 変換後の「ライセンス」「アンカー」「パスワード／サインイン停止」をワークフロー設計に組み込み、事故を防ぐ
「Graphだけで完結」という理想は魅力的ですが、退職者データとセキュリティを扱う領域ほど、公式にサポートされる管理経路（Exchange管理）を前提に組む方が、長期的に運用が安定します。
コメント