Microsoft Entra ID / hybrid sync を使っている組織にとって、Source of Authority（SOA）変換は単なる新機能ではありません。オンプレミス Active Directory（AD DS）に残り続ける同期ユーザーを、段階的にクラウド管理へ移すための現実的な選択肢です。
2026年4月16日時点で注目すべき更新は、Microsoft Entra ID で同期済みオンプレミス AD ユーザーの Source of Authority をクラウドへ変換できる機能が一般提供として案内されていることです。これにより、テナント移行、AD DS 縮小、ディレクトリ整理を「一括移行」ではなく、対象ユーザー単位で進めやすくなりました。Microsoft の 2026年3月の Entra 更新まとめでも、この機能は Microsoft Entra ID Governance の新リリースとして取り上げられています。(TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、「同期ユーザーをクラウドで編集できるようになる」という表面的な便利さだけではありません。SOA変換は、どのシステムがユーザー属性とライフサイクルの正本になるのかを切り替える機能です。Identity 管理者やテナント移行チームは、アプリ依存、Exchange、HRプロビジョニング、Kerberos/LDAP の有無を確認したうえで、段階的な移行計画に組み込む必要があります。
Source of Authority（SOA）とは何か
Source of Authority（SOA）とは、ユーザーやグループなどのディレクトリオブジェクトについて、どのシステムを正本として扱うかを示す考え方です。
従来のハイブリッド構成では、多くの場合、ユーザーはオンプレミス AD DS で作成・更新され、Microsoft Entra Connect Sync または Microsoft Entra Cloud Sync によって Microsoft Entra ID に同期されます。この場合、対象ユーザーの SOA は AD DS 側にあります。
そのため、Microsoft Entra 管理センターで同期ユーザーの属性を編集しようとしても、項目がグレーアウトしたり、次回同期で AD DS 側の値に戻ったりします。これは不具合ではなく、「AD DS が正本である」という設計上の動作です。
SOA変換では、この正本をユーザー単位で AD DS から Microsoft Entra ID へ移します。Microsoft Learn では、User SOA によってユーザーをクラウドで編集できるようにし、AD DS ユーザーを削除したり、Microsoft Entra ID Governance の機能でライフサイクルを管理したりできるシナリオが説明されています。(Microsoft Learn)
2026年4月16日時点の最新動向：同期ユーザーをクラウド管理へ移せる
Microsoft Entra のリリース情報では、object-level Source of Authority switching により、管理者が個別ユーザーを Active Directory 同期から Microsoft Entra ID のクラウド管理アカウントへ移行できると案内されています。対象ユーザーは AD 同期に結び付いた管理から離れ、クラウドネイティブユーザーに近い形で扱えるようになります。Microsoft Entra Connect Sync と Cloud Sync の両方がこの SOA 切り替えをサポートする点も重要です。(Microsoft Learn)
これまでハイブリッド環境の整理では、次のような悩みが起きがちでした。
- 退職・異動・組織変更の正本が HR やクラウド側に移っているのに、AD DS だけが残る
- すでに SaaS や SAML/OIDC 認証へ移したユーザーでも、同期の都合で AD オブジェクトを残し続ける
- M&A、カーブアウト、テナント統合後に「どのユーザーをどこで管理するか」が曖昧になる
- AD DS を廃止したいが、一部のアプリやグループ依存が残って一括移行できない
SOA変換は、こうした状況で「全ユーザーを一気にクラウド化する」のではなく、移行可能なユーザーから順にクラウド管理へ移すための仕組みです。
なぜクラウドファーストのディレクトリ整理で重要なのか
SOA変換が重要なのは、クラウドファーストの移行を「理想論」から「実行可能な移行手順」に落とし込めるからです。
AD DS 依存をユーザー単位で減らせる
AD DS は長年、企業 ID 管理の中心でした。しかし、クラウドアプリ、Microsoft 365、ゼロトラスト、条件付きアクセス、パスワードレス認証を中心に据える組織では、すべてのユーザーを AD DS で管理し続けることが運用負荷になります。
Microsoft のアーキテクト向けガイダンスでも、SOA transfer は AD を一度に廃止するのではなく、クラウドへ移せる ID から段階的に移行する方法として位置付けられています。特に、アプリケーションの認証を Microsoft Entra ID へ移し、AD DS への依存を減らしていく「AD-minimized」な状態への移行で効果があります。(Microsoft Learn)
テナント移行や組織再編後の後片付けがしやすくなる
テナント移行チームにとって、移行後のディレクトリ整理は見落とされがちな作業です。メールボックスや Teams、SharePoint の移行が終わっても、ID の正本が AD DS に残ったままだと、次のような問題が残ります。
| 課題 | SOA変換で改善できる点 |
|---|---|
| 移行済みユーザーの属性変更がオンプレAD経由でしかできない | 対象ユーザーをクラウド管理に移し、Entra ID 側で管理しやすくなる |
| 部門単位・拠点単位で移行時期が異なる | ユーザー単位、グループ単位で段階的に進められる |
| HRシステムはクラウド中心なのにAD同期が残る | HRからEntra IDへの直接プロビジョニングへ切り替えやすくなる |
| AD DS廃止の判断材料が不足する | どのユーザーがまだAD依存かを棚卸ししやすくなる |
SOA変換は、テナント移行ツールそのものではありません。メールボックス、Teams、SharePoint、アプリ設定を移す機能でもありません。しかし、移行後に残る「ID管理の正本問題」を整理するうえで、非常に重要な選択肢になります。
Microsoft Entra ID Governance を活用しやすくなる
クラウド管理へ移したユーザーは、Microsoft Entra ID Governance を中心にしたライフサイクル管理と相性が良くなります。
たとえば、入社、異動、退職に応じて Lifecycle Workflows を設計したり、Access Reviews でアクセス権を定期確認したり、Entitlement Management でアクセスパッケージを提供したりできます。Microsoft のガイダンスでも、Microsoft Entra ID Governance によるライフサイクル管理やアクセスガバナンスの活用が、クラウドファースト ID 管理の利点として示されています。(Microsoft Learn)
SOA変換でできること・できないこと
SOA変換を検討する際は、「同期ユーザーをクラウドユーザーに変換できる」という表現だけで判断しないことが大切です。実務では、できることとできないことを分けて理解する必要があります。
| 項目 | 内容 |
|---|---|
| できること | AD DS 同期済みユーザーの SOA を Microsoft Entra ID 側へ移す |
| できること | 対象ユーザーをクラウド側で編集・管理しやすくする |
| できること | ユーザー単位で段階的に AD DS 依存を減らす |
| できること | Microsoft Graph API で isCloudManaged を更新し、SOA を切り替える |
| 注意が必要なこと | すべての AD 依存アプリから自動的に解放されるわけではない |
| 注意が必要なこと | Exchange、HR、MIM、Kerberos、LDAP などの依存関係を事前に確認する必要がある |
| できないこと | テナント間移行、メールボックス移行、アプリ移行を自動実行すること |
| できないこと | パスワードベースの AD 依存アプリをそのままクラウド完結にすること |
特に重要なのは、SOA変換後もオンプレミスリソースにアクセスさせたい場合です。Microsoft の説明では、Cloud Kerberos Trust や Windows Hello for Business、FIDO2 セキュリティキーなどのパスワードレス認証を使うシナリオが示されています。一方で、パスワード依存があるユーザーや AD FS によるフェデレーション認証を使うユーザーについては、SOA transfer がサポートされない条件として明記されています。(Microsoft Learn)
SOA変換を検討すべき代表的なシーン
クラウドアプリ中心へ移行済みの部門
すでに業務アプリが Microsoft Entra ID の SAML または OpenID Connect に対応しており、AD DS のユーザー属性に依存していない部門は、SOA変換の候補になります。
たとえば、営業部門が SaaS、Microsoft 365、クラウドCRM中心で業務を完結しており、ファイルサーバーや古い LDAP 認証アプリを使っていない場合です。このような部門からパイロットを始めると、影響範囲を限定できます。
HRプロビジョニングを Entra ID 直結へ変えたい場合
HRシステムから AD DS にユーザーを作成し、その後 Entra ID へ同期する構成は、ハイブリッド環境では一般的です。しかし、クラウドファーストへ移行するなら、HRシステムから Microsoft Entra ID へ直接プロビジョニングする設計に変えたくなります。
Microsoft Learn では、SOA変換対象ユーザーを HR から Microsoft Entra ID へ直接プロビジョニングし、従来の HR to AD プロビジョニングから対象外にする流れが説明されています。部門、コストセンター、拠点などで段階的に対象を広げる考え方も示されています。(Microsoft Learn)
M&A・カーブアウト後に AD DS を縮小したい場合
企業買収、事業分離、海外拠点統合では、ID基盤が一時的に複雑になります。買収元 AD、買収先 AD、新テナント、旧テナントが併存し、どのディレクトリを正本にするかが曖昧になりやすいからです。
SOA変換は、移行済みユーザーから順に Microsoft Entra ID を正本にしていくための手段になります。全社一括の AD 統合を待たずに、移行が完了した部門や拠点からディレクトリ整理を進められます。
AD DS を完全廃止できないが、管理対象を減らしたい場合
多くの企業では、AD DS をすぐに廃止できません。Kerberos、NTLM、LDAP、古いファイルサーバー、ネットワーク機器、業務アプリが残っているためです。
それでも、すべてのユーザーを AD DS 管理に残す必要はありません。アプリ依存がないユーザー、すでにクラウド認証へ移ったユーザー、AD DS で属性更新する必要がないユーザーから SOA を切り替えることで、AD DS の管理範囲を縮小できます。
変換してよいユーザー・まだ変換しないほうがよいユーザー
SOA変換は強力ですが、対象選定を誤るとサインイン、アプリ利用、属性更新、メール管理に影響します。最初に確認すべき判断基準は次の通りです。
| 判断項目 | 変換候補にしやすいユーザー | 変換を保留すべきユーザー |
|---|---|---|
| アプリ認証 | SAML/OIDC など Microsoft Entra ID 認証が中心 | LDAP simple bind、NTLM、古いAD依存アプリを使う |
| パスワード依存 | パスワードレスやクラウド認証へ移行済み | ADパスワード認証が業務上必須 |
| Exchange | Exchange Online へ移行済み | オンプレミス Exchange 依存が残る |
| HR連携 | HRからEntra IDへ直接プロビジョニングできる | HR→AD→Entra の経路を変えられない |
| グループ管理 | クラウドグループやEntra ID Governanceへ移行可能 | ADグループを前提にした認可が残る |
| 移行単位 | 部門・拠点・職種で影響範囲を切れる | 依存関係が未整理で所有者も不明 |
判断の基本は、ユーザーではなくアプリから見ることです。Microsoft のアーキテクト向けガイダンスでも、SOA transfer の前にアプリケーションインベントリを作成し、AD 依存アプリに紐づくユーザーのアクセスを壊さないことが強調されています。(Microsoft Learn)
実務での進め方：いきなり本番ユーザーを変換しない
SOA変換は、必ず小さく始めるべきです。最初から全社ユーザーを対象にすると、アプリ依存や属性依存を見落としたときの影響が大きくなります。
まずアプリと認証方式を棚卸しする
最初にやるべきことは、ユーザー一覧の抽出ではありません。アプリケーションの棚卸しです。
| 認証・依存の種類 | 確認ポイント | 移行方針の例 |
|---|---|---|
| SAML/OIDC | Entra ID をIdPにできるか | Entra ID 認証へ移行し、SOA変換候補にする |
| AD FS | Entra ID へ直接フェデレーション移行できるか | AD FS依存を減らしてから判断 |
| Kerberos/NTLM | ファイルサーバー、IIS、社内Webの有無 | Cloud Kerberos Trust や Application Proxy を検討 |
| LDAP | LDAP bind、属性検索、ネットワーク機器連携 | Entra Domain Services など代替を検討 |
| AD属性書き込み | アプリがAD属性へ書き込むか | 原則としてSOA変換前に再設計が必要 |
| オフライン・閉域 | インターネット非依存が必須か | クラウド移行対象外として扱う場合がある |
Microsoft のガイダンスでも、Kerberos/NTLM、LDAP、SAML/OIDC、その他レガシー方式を分類し、アプリごとに移行方式を決める流れが示されています。LDAP 書き込みや特殊な AD 機能に依存するアプリは、SOA移行の対象外または慎重な扱いが必要です。(Microsoft Learn)
次にグループを先に整理する
ユーザーより先に、アプリのアクセス制御に使っているグループを整理します。理由は単純で、ユーザーの SOA を切り替えても、グループベースの認可が AD DS 側に残っていると、アクセス制御の運用が分断されるからです。
Microsoft の環境準備ドキュメントでも、SOAを切り替える手順の中で、グループはユーザーより前に切り替えることが推奨されています。(Microsoft Learn)
特に、アプリ移行では次の順序が安全です。
| 順序 | 作業 | 目的 |
|---|---|---|
| 1 | アプリが使うADグループを特定 | 認可の影響範囲を把握する |
| 2 | グループメンバーシップを確認 | 対象ユーザーを漏れなく洗い出す |
| 3 | グループのクラウド管理化を検討 | Entra ID Governance に寄せる |
| 4 | パイロットユーザーのSOAを変換 | アプリ利用に問題がないか確認 |
| 5 | 部門・拠点単位で拡大 | リスクを分散して移行する |
必要な権限・同期クライアントを確認する
Microsoft Learn の構成手順では、SOA の読み取り・更新には Hybrid Administrator が必要で、Microsoft Graph API の権限として User-OnPremisesSyncBehavior.ReadWrite.All が必要とされています。また、Connect Sync と Cloud Sync には最小バージョン要件が示されています。(Microsoft Learn)
| 確認項目 | 内容 |
|---|---|
| 管理ロール | Hybrid Administrator |
| 同意操作 | Application Administrator または Cloud Application Administrator |
| Graph権限 | User-OnPremisesSyncBehavior.ReadWrite.All |
| ライセンス | Microsoft Entra Free と案内されている |
| Connect Sync | 最小バージョン 2.5.76.0 |
| Cloud Sync | 最小バージョン 1.1.1370.0 |
バージョンや要件は変更される可能性があるため、本番適用前には Microsoft Learn の最新ページを確認してください。特にグローバル企業では、リージョン、クラウド環境、既存の同期方式、変更管理プロセスによって前提条件が変わることがあります。
Microsoft Graph での基本的な変換イメージ
SOA変換は、Microsoft Graph API の onPremisesSyncBehavior を使って行います。実際の運用では Graph Explorer や独自スクリプト、変更管理済みの管理アプリを使います。
まず、対象ユーザーの状態を確認します。
GET https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior?$select=isCloudManagedAD DS が SOA の同期ユーザーであれば、isCloudManaged は false です。
次に、対象ユーザーをクラウド管理へ切り替えます。
PATCH https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior
{
"isCloudManaged": true
}変換後は、再度 GET で isCloudManaged が true になっていることを確認します。Microsoft Learn の手順では、Audit Logs で “Change Source of Authority from AD to cloud” のアクティビティを確認し、その後にユーザー属性をクラウド側で更新できるか検証する流れが示されています。(Microsoft Learn)
変換後に確認すべきポイント
SOA変換は API 実行で終わりではありません。むしろ、変換後の検証が本番品質を左右します。
| 確認項目 | 確認内容 |
|---|---|
| SOA状態 | isCloudManaged が true になっているか |
| 監査ログ | SOA変更の監査イベントが記録されているか |
| 属性更新 | Entra ID 側で対象属性を更新できるか |
| 同期動作 | AD DS 側の変更が対象ユーザーへ流れないことを理解しているか |
| アプリサインイン | 業務アプリ、Microsoft 365、オンプレアプリに問題なくアクセスできるか |
| グループ | 必要なグループメンバーシップが維持されているか |
| HR連携 | 対象ユーザーがHR→Entra IDの経路で管理されるか |
| 運用手順 | ヘルプデスクが「どこで編集するユーザーか」を判別できるか |
Microsoft Learn では、SOA変換後の属性状態として、管理者が SOA をクラウドへ移すと isCloudManaged は true、onPremisesSyncEnabled は null になると説明されています。ここを理解していないと、「同期が壊れた」と誤認する可能性があります。(Microsoft Learn)
失敗しやすいポイント
アプリ依存をユーザー単位だけで判断してしまう
SOA変換で最も多い失敗は、「このユーザーはクラウドアプリしか使っていないはず」という思い込みです。
実際には、部署共通のファイルサーバー、古い経費精算システム、VPN、複合機のLDAP認証、ネットワーク機器の管理画面などが AD DS に依存していることがあります。ユーザー本人が意識していなくても、裏側で AD 認証を使っているケースは珍しくありません。
変換候補は、ユーザー属性だけでなく、アプリ、グループ、サインインログ、ネットワーク機器、業務部門ヒアリングを組み合わせて判断してください。
Exchange Hybrid の整理を後回しにする
Exchange 依存は SOA変換で特に注意が必要です。Microsoft の前提条件では、オンプレミス Exchange ワークロードがないこと、クラウドへメールボックスを移してからオンプレミス Exchange を取り除くことが示されています。(Microsoft Learn)
実務では、メールボックスだけでなく、メール属性、配布リスト、メール有効セキュリティグループ、受信者管理ツールの運用も確認します。Exchange Hybrid が残っている場合、ユーザーだけを先にクラウド管理へ移すと、メール関連属性の編集場所が不明確になる恐れがあります。
ロールバックを簡単に考える
SOA変換はロールバック可能ですが、単に isCloudManaged を false に戻せばすべて完了するわけではありません。
Microsoft Learn では、ロールバック前に、対象ユーザーがクラウド参照を持っていないことを確認し、SOA変換済みグループやアクセスパッケージから削除する必要があると説明されています。また、API 実行後、次回の同期サイクルで AD DS 側が再び対象オブジェクトを引き継ぐまで、ロールバックは完了しません。(Microsoft Learn)
ロールバック計画には、少なくとも次を含めてください。
| ロールバック項目 | 確認内容 |
|---|---|
| 対象ユーザー | どのユーザーを戻すか |
| クラウド参照 | アクセスパッケージ、グループ、アプリ割り当ての依存 |
| AD側属性 | 戻した後に正しい値で上書きされるか |
| 同期タイミング | 次回同期または強制同期の実行計画 |
| 監査 | 変更前後のログ保存 |
| 利用者影響 | サインイン、メール、業務アプリへの影響 |
ヘルプデスク向けの判別ルールを作らない
SOA変換後は、同じテナント内に次のようなユーザーが混在します。
- AD DS が正本の同期ユーザー
- Microsoft Entra ID が正本の SOA変換済みユーザー
- 最初からクラウド作成されたユーザー
- B2B や外部ユーザー
- 移行中で一時的な扱いのユーザー
ヘルプデスクがこの違いを判別できないと、「表示名はどこで直すのか」「部署名はどこで更新するのか」「退職処理はどのシステムから行うのか」で混乱します。
実務では、ユーザー種別ごとに編集場所を表にしておくと効果的です。
| ユーザー種別 | 編集場所 | 備考 |
|---|---|---|
| AD DS SOAの同期ユーザー | AD DS / 既存ID管理システム | Entra ID側で編集できない項目が多い |
| SOA変換済みユーザー | Microsoft Entra ID / Graph / HR直結 | クラウド側が正本 |
| クラウドネイティブユーザー | Microsoft Entra ID | AD DS 同期対象外 |
| 外部ユーザー | Entra ID の外部ID管理 | userType と認証元を混同しない |
2026年の移行計画で併せて注意したいハードマッチ変更
SOA変換と直接同じ機能ではありませんが、2026年のハイブリッドID管理では、ハードマッチのセキュリティ変更も確認しておくべきです。
Microsoft は、2026年6月1日以降、Microsoft Entra ロールを持つ既存のクラウド管理ユーザーに対して、AD から新しいユーザーオブジェクトをハードマッチさせて SOA を奪うような操作を既定でブロックすると案内しています。これは、AD の属性操作によって特権クラウドユーザーが乗っ取られるリスクを下げるための変更です。(TECHCOMMUNITY.MICROSOFT.COM)
テナント移行やディレクトリ再構成で、onPremisesImmutableId や sourceAnchor を使ったマッチングに頼っている場合は、SOA変換の計画とあわせて確認してください。特に、管理者ロールを持つアカウント、ブレークグラスアカウント、移行用特権アカウントは、通常ユーザーとは別の移行設計にするべきです。
SOA変換を導入するための実務チェックリスト
本番環境で SOA変換を始める前に、次のチェックリストを使って準備状況を確認してください。
| フェーズ | チェック項目 |
|---|---|
| 方針決定 | AD DS をどこまで縮小するか、完全廃止か最小化かを決める |
| 対象選定 | 部門、拠点、雇用形態、アプリ利用状況で候補を絞る |
| アプリ棚卸し | Kerberos、LDAP、SAML/OIDC、AD FS、RADIUSなどを分類する |
| グループ整理 | アプリ認可に使うADグループを特定し、先に移行可否を判断する |
| Exchange確認 | オンプレミス Exchange 依存が残っていないか確認する |
| HR連携 | HRからEntra IDへ直接プロビジョニングできる経路を設計する |
| 同期確認 | Connect Sync / Cloud Sync のバージョンと構成を確認する |
| 権限確認 | Hybrid Administrator と Graph 権限を準備する |
| パイロット | 影響が限定的なユーザーで検証する |
| 監査・復旧 | 監査ログ、変更記録、ロールバック手順を整備する |
| 運用移管 | ヘルプデスクとID運用チームに編集場所のルールを展開する |
パイロット設計の例
最初のパイロットは、技術的にシンプルで、業務影響を切り分けやすい単位にします。
たとえば、次のような条件を満たすユーザー群が候補です。
- Microsoft 365 と SaaS が主な業務環境
- 主要アプリが SAML/OIDC で Entra ID 認証済み
- オンプレミスファイルサーバーへの依存がない、または代替済み
- Exchange Online へ移行済み
- HR属性を Entra ID 側へ直接連携できる
- IT部門または移行プロジェクトに近く、検証協力が得やすい
反対に、最初のパイロットに向かないのは、工場、店舗、閉域ネットワーク、共有端末、古い業務アプリ、LDAP認証、AD連携プリンターや入退室システムが多い部門です。これらは技術検証の難易度が高く、失敗時の原因切り分けも複雑になります。
移行後の運用で決めておくべきルール
SOA変換の成功は、APIを実行できるかどうかではなく、変換後の運用が破綻しないかで決まります。
少なくとも、以下のルールを文書化してください。
属性の正本ルール
表示名、部署、役職、上司、所在地、電話番号、社員番号などの属性について、どのシステムを正本にするかを定義します。HR、Microsoft Entra ID、ServiceNow、Workday、SAP SuccessFactors などが関係する場合、属性ごとに責任システムが異なることがあります。
ユーザー作成・更新・削除の流れ
入社時にどこでユーザーを作るのか、異動時に何が更新されるのか、退職時にいつ無効化されるのかを決めます。SOA変換済みユーザーだけ例外的な運用になると、後から必ず混乱します。
同期スコープの見直し
SOA変換済みユーザーを同期スコープに残すべきか、外すべきかは構成によって変わります。Microsoft の準備手順では、AD や HR プロビジョニングの対象から SOA変換済みユーザーを除外し、Entra ID へ直接流す構成が説明されています。一方で、参照関係のために同期スコープへ残す必要があるケースもあります。(Microsoft Learn)
監査と変更管理
SOA変換は ID の正本を変える重要操作です。通常の属性変更よりも強い変更管理を適用してください。
具体的には、変更要求、対象ユーザー一覧、実行者、実行時刻、Graph API の結果、監査ログ、検証結果、ロールバック可否を記録します。グローバル企業では、リージョンごとのデータ管理ルールや内部監査要件も確認が必要です。
SOA変換は「AD廃止ボタン」ではなく、移行を現実的にする仕組み
Source of Authority conversion は、Microsoft Entra ID / hybrid sync 環境における大きな前進です。同期ユーザーをクラウド管理へ移せることで、AD DS に残っていた管理の重さを段階的に減らし、クラウドファーストの ID 管理へ移行しやすくなります。
ただし、SOA変換は万能ではありません。AD DS 依存アプリ、Exchange Hybrid、HRプロビジョニング、Kerberos、LDAP、グループ認可を整理しないまま実行すると、サインインや業務アプリに影響が出る可能性があります。
まずやるべきことは、APIを試すことではなく、アプリとグループを中心に依存関係を棚卸しすることです。そのうえで、影響範囲が小さいユーザーからパイロットを行い、監査ログ、属性更新、アプリ利用、ロールバック手順を確認します。
2026年以降の Microsoft Entra ID 移行では、SOA変換はハイブリッド環境の後片付け、テナント移行後の整理、AD DS 縮小を進めるための重要な実務要素になります。Identity 管理者とテナント移行チームは、クラウドファースト化のロードマップに SOA変換を組み込み、「どのユーザーを、いつ、どの条件でクラウド管理へ移すか」を具体的に決めるところから始めるべきです。
コメント