Microsoft Entra のユーザー プロビジョニングに対するクラウド人事アプリケーション
従来、IT スタッフは、手動による社員の作成、更新、削除の方法に依存していました。 これらは、CSV ファイルのアップロードや、カスタム スクリプトなどの方法を使用して社員データを同期しています。 これらのプロビジョニング プロセスは、エラーが発生しやすく、安全でなく、管理が困難です。
従業員、ベンダー、臨時社員の ID ライフサイクルを管理するために、Microsoft Entra ユーザー プロビジョニング サービスは、クラウドベースの人事 (HR) アプリケーションとの統合を提供します。 アプリケーションの例には、Workday や SuccessFactors などがあります。
Microsoft Entra ID は、この統合を利用して、次のクラウド人事アプリケーション (アプリ) プロセスを有効にします。
- Active Directory へのユーザーのプロビジョニング: クラウド人事アプリから選択したユーザーのセットを、1 つ以上の Active Directory ドメインにプロビジョニングします。
- クラウドのみのユーザーの Microsoft Entra ID へのプロビジョニング: Active Directory が使用されていないシナリオでは、クラウド人事アプリから Microsoft Entra ID にユーザーを直接プロビジョニングします。
- クラウド人事アプリへの書き戻し: メール アドレスやユーザー名の属性を Microsoft Entra からクラウド人事アプリに書き戻します。
次のビデオでは、人事主導のプロビジョニング統合の計画に関するガイダンスを提供します。
Note
この展開プランは、Microsoft Entra ユーザー プロビジョニングを使用してクラウド人事アプリをデプロイする方法を示します。 サービスとしてのソフトウェア (SaaS) アプリへ自動ユーザー プロビジョニングをデプロイする方法については、「自動ユーザー プロビジョニングのデプロイを計画する」を参照してください。
任意の HR システムからの API 駆動型プロビジョニング
API 駆動型プロビジョニングを使用すると、"任意" のレコード システムから Microsoft Entra ID に ID を取り込むことができます。 "任意" の自動化ツール使用をして、レコードのシステムから従業員データを取得し、Microsoft Entra ID に取り込むことができます。 IT 管理者は、属性マッピングを使用してデータを処理および変換する方法を完全に制御できます。
有効な人事シナリオ
Microsoft Entra ユーザー プロビジョニング サービスを使用すると、次に示す人事ベースの ID ライフサイクル管理シナリオを自動化できます。
- 新しい従業員の採用: クラウド人事アプリに従業員を追加すると、Active Directory と Microsoft Entra ID にユーザーが自動的に作成されます。 ユーザー アカウントの追加には、メール アドレスとユーザー名の属性をクラウド人事アプリに書き戻すオプションが含まれています。
- 従業員の属性とプロファイルの更新: クラウド人事アプリで名前、役職、上司などの従業員レコードが更新されると、そのユーザー アカウントが Active Directory と Microsoft Entra ID で自動的に更新されます。
- 従業員の退職: クラウド人事アプリで従業員が退職すると、そのユーザー アカウントが Active Directory および Microsoft Entra ID で自動的に無効になります。
- 従業員の再雇用: クラウド人事アプリで従業員が再雇用されると、その古いアカウントが自動的に再アクティブ化されるか、Active Directory および Microsoft Entra ID に再プロビジョニングされます。
この統合が最も適している組織
クラウド人事アプリの Microsoft Entra ユーザー プロビジョニングとの統合は、次のような組織に最適です。
- クラウド人事のユーザーをプロビジョニングするための、事前構築済みのクラウドベースのソリューションを必要としている。
- クラウド人事アプリから Active Directory または Microsoft Entra ID に直接、ユーザーをプロビジョニングする必要がある。
- クラウド人事アプリから取得したデータを使用してユーザーをプロビジョニングする必要がある。
- 入社、異動、退職するユーザーの同期。 同期は、クラウド人事アプリで検出された変更情報のみに基づいて、1 つ以上の Active Directory フォレスト、ドメイン、OU の間で行われる。
- 電子メールに Microsoft 365 を使用する。
学習する
ユーザー プロビジョニングによって、継続的な ID ガバナンスの基盤が作成されます。 これにより、正規の ID データに依存するビジネス プロセスの品質が向上します。
用語
この記事では、次の用語を使用しています。
- ソース システム: Microsoft Entra ID のプロビジョニング元であるユーザーのリポジトリ。 例として、Workday や SuccessFactors などのクラウド人事アプリがあります。
- ターゲット システム: Microsoft Entra ID のプロビジョニング先であるユーザーのリポジトリ。 例として、Active Directory、Microsoft Entra ID、Microsoft 365、その他の SaaS アプリがあります。
- 入社/異動/退職プロセス:クラウド人事アプリを記録システムとして使用する新規雇用、異動、退職に対して使われる用語。 プロセスが完了するのは、サービスによって必要な属性がターゲット システムに正常にプロビジョニングされた時点です。
主な利点
ここで説明する人事ベースの IT プロビジョニング機能は、次に挙げるような大きなメリットをビジネスにもたらします。
- 生産性の向上: ユーザー アカウントや Microsoft 365 ライセンスの割り当てを自動化し、重要なグループへのアクセスを提供できるようになります。 割り当ての自動化により、新しい社員は各自の業務ツールにすぐにアクセスできるため、生産性が向上します。
- リスクの管理: 従業員の状態またはグループ メンバーシップに基づいて変更を自動化して、セキュリティを強化します。 この自動化により、ユーザー ID とキー アプリへのアクセスが自動的に更新されます。 たとえば、ユーザーが異動したり退職したりしたときに、人事アプリの更新が自動的に流れます。
- コンプライアンスとガバナンスへの対応: Microsoft Entra ID は、ソースとターゲットの両方のシステムのアプリによって実行されるユーザー プロビジョニング要求のネイティブ プロビジョニング ログをサポートします。 監査によって、誰がアプリにアクセスできるかを 1 つの画面から追跡できます。
- コスト管理: 自動プロビジョニングを使用すると、手動プロビジョニングに関連した非効率性や人的エラーを回避することでコストが削減されます。 従来の陳腐化したプラットフォームを使用して、長らく構築されてきた、カスタム開発のユーザー プロビジョニング ソリューションを不要にします。
ライセンス
クラウド人事アプリと Microsoft Entra ユーザー プロビジョニングの統合を構成するには、有効な Microsoft Entra ID P1 または P2 のライセンスと、Workday や SuccessFactors などのクラウド人事アプリのライセンスが必要です。
クラウド人事アプリから入手し、Active Directory または Microsoft Entra ID にプロビジョニングされるすべてのユーザーについても、Microsoft Entra ID P1 以上の有効なサブスクリプション ライセンスが必要です。
プロビジョニング プロセスでライフサイクル ワークフローやその他の Microsoft Entra ID ガバナンス機能を使用するには、Microsoft Entra ID ガバナンス ライセンスが必要です。
前提条件
- Connect プロビジョニング エージェントを構成するためのハイブリッド ID 管理者ロール。
- プロビジョニング アプリを構成するためのアプリケーション管理者ロール。
- クラウド人事アプリのテストおよび運用インスタンス。
- クラウド人事アプリの管理者権限。システム統合ユーザーを作成したり、テスト目的でテスト用社員データを変更したりするために必要です。
- Active Directory へのユーザー プロビジョニングについては、Microsoft Entra Connect プロビジョニング エージェントをホストするために、Windows Server 2016 以降を実行しているサーバーが必要です。 このサーバーは、Active Directory 管理層モデルに基づいた階層 0 のサーバーである必要があります。
- Active Directory と Microsoft Entra ID の間でユーザーを同期するための Microsoft Entra Connect。
トレーニング リソース
ソリューションのアーキテクチャ
次の例では、一般的なハイブリッド環境に向けた、エンド ツー エンドのユーザー プロビジョニング ソリューションのアーキテクチャについて説明し、次のものが含まれます。
- 正規の人事データ フロー - クラウド人事アプリから Active Directory へ。 このフローでは、クラウド人事アプリのテナントで人事イベント (入社/異動/退職プロセス) が開始されます。 Microsoft Entra プロビジョニング サービスおよび Microsoft Entra Connect プロビジョニング エージェントが、クラウド人事アプリのテナントから Active Directory にユーザー データをプロビジョニングします。 イベントによっては、Active Directory での作成、更新、有効化、および無効化操作が発生する可能性があります。
- Microsoft Entra ID と同期し、オンプレミスの Active Directory からクラウド人事アプリにメール アドレスとユーザー名を書き戻します。 Active Directory でアカウントが更新されると、Microsoft Entra Connect 経由で Microsoft Entra ID と同期されます。 メール アドレスやユーザー名の属性は、クラウド人事アプリ テナントに書き戻すことができます。
プロビジョニング プロセスの説明
次の主要な手順を図に示します。
- 人事チームは、クラウド人事アプリのテナントでトランザクションを実行します。
- Microsoft Entra プロビジョニング サービスが、スケジュールされたサイクルをクラウド人事アプリのテナントから実行し、変更を識別して、Active Directory との同期を処理します。
- Microsoft Entra プロビジョニング サービスが、Active Directory アカウントの作成、更新、有効化、無効化の操作を含む要求ペイロードを指定して、Microsoft Entra Connect プロビジョニング エージェントを呼び出します。
- Microsoft Entra Connect プロビジョニング エージェントが、サービス アカウントを使用して Active Directory アカウントのデータを管理します。
- Microsoft Entra Connect が、デルタ同期を実行して Active Directory 内の更新をプルします。
- Active Directory の更新が、Microsoft Entra ID と同期されます。
- Microsoft Entra プロビジョニング サービスが、Microsoft Entra ID からクラウド人事アプリのテナントにメール属性とユーザー名を書き戻します。
デプロイ プロジェクトを計画する
お客様の環境でこのデプロイの戦略を決定するときは、お客様の組織のニーズを考慮してください。
適切な関係者を関わらせる
テクノロジ プロジェクトが失敗した場合、その原因は通常、影響、結果、および責任に対する想定の不一致です。 これらの落とし穴を回避するには、適切な利害関係者が担当していることを確認します。 また、プロジェクトの利害関係者のロールを十分に把握していることを確認します。 利害関係者とそのプロジェクト入力と責務を文書化します。
既存の人事ビジネス プロセスや、社員の ID および職務データの処理要件について意見できる、人事部門の代表者を含めます。
連絡を計画する
コミュニケーションは、新しいサービスの成功に必要不可欠です。 エクスペリエンスの変化について、ユーザーに事前に通知します。 問題が発生した場合にサポートを受ける方法について説明します。
パイロットを計画する
人事ビジネス プロセスと ID ワークフローをクラウド人事アプリからターゲット システムに統合するには、ソリューションを運用環境にデプロイする前に、大量のデータ検証、データ変換、データ クレンジング、そして徹底的なテストが必要です。
運用環境のすべてのユーザーに初期構成を適用する前に、パイロット環境でその構成を実行します。
HR データ フローと属性マッピングを計画する
適切な HR レコードが Microsoft Entra ID (Entra ID) とオンプレミスの Active Directory (AD) のユーザーに確実にマップされるように、HR および IT の各チームと協力してデータの一貫性を確保し、データ クレンジング タスクを計画します。 作業を開始するためのベスト プラクティスの一覧を次に示します。
一致する識別子の存在と一意性: プロビジョニング サービスでは、一致する属性を使用して、HR システム内のユーザー レコードを一意に識別し、AD または Entra ID 内の対応するユーザー アカウントとリンクします。 既定の一致する属性は、従業員 ID に基づいています。 完全同期を開始する前に、従業員 ID の値が Entra ID (クラウド専用ユーザーの場合) およびオンプレミスの AD (ハイブリッド ユーザーの場合) に設定されていること、ユーザーを一意に識別することを確認します。
スコープ フィルターを使用して、関連性がなくなった HR レコードをスキップする: HR システムには、おそらく 1970 年代まで遡った数年間分の雇用データが保存されています。 一方、IT チームが関心を持つのは、現在アクティブな従業員の一覧と、稼働後に発生する退職レコードのみである可能性があります。 IT チームの観点から関連性がなくなった HR レコードを除外するには、HR チームと協力して、Microsoft Entra プロビジョニングのスコープ フィルターで使用できる HR レコードにフラグを追加します。
ユーザー名における特殊文字の処理を計画する: ユーザーの一意の
userPrincipalNameを作成するには、従業員の名と姓を使用するのが一般的な方法です。userPrincipalNameでアクセント記号は使用できません。使用できる文字は A - Z、a - z、0 - 9、 ' . - _ ! # ^ ~ のみです。 関数 NormalizeDiacritics を使用してアクセント文字を処理し、適切なuserPrincipalNameを作成します。長い文字列の処理を計画する: HR データに、Entra ID またはオンプレミスの AD 属性の設定に使用する HR フィールドに関連付けられた長い文字列値があるかどうかを確認します。 すべての Entra ID 属性には、最大文字列長があります。 Entra ID 属性にマップされた HR フィールドの値にさらに多くの文字が含まれている場合、属性の更新が失敗する可能性があります。 1 つのオプションは、属性マッピングを確認し、HR システムで長い文字列値を切り捨てたり更新したりする可能性があるかどうかを確認することです。 それが選択肢にならない場合は、Mid などの関数を使用して長い文字列を切り捨てるか、Switch などの関数を使用して長い値を短い値または省略形にマップすることができます。
必須の属性での null または空の値を処理する: Entra ID またはオンプレミスの AD でアカウントを作成する場合、
firstName、lastName、CN、UPNなどの属性を設定することは必須です。 そのような属性にマップされた対応する HR フィールドが null の場合、ユーザー作成操作は失敗します。 たとえば、AD のCN属性を "表示名" にマップした場合、"表示名" がすべてのユーザーに対して設定されていない限り、エラーが発生します。 1 つのオプションは、このような必須の属性マッピングを確認し、対応するフィールドが HR に入力されていることを確認することです。 式マッピングで null 値をチェックするオプションを検討することもできます。 たとえば、表示名が空の場合は、名と姓を連結して表示名を作ります。
クラウド人事プロビジョニング コネクタ アプリの選択
クラウド人事アプリから Active Directory への Microsoft Entra プロビジョニングを容易にするために、Microsoft Entra アプリ ギャラリーから複数のプロビジョニング コネクタ アプリを追加できます。
- クラウド人事アプリからAzure Active Directory へのユーザー プロビジョニング:このプロビジョニング コネクタ アプリは、クラウド人事アプリから 1 つの Active Directory ドメインへのユーザー アカウントのプロビジョニングを容易にします。 複数のドメインがある場合は、プロビジョニングする必要がある Active Directory ドメインごとに 1 つ、Microsoft Entra アプリ ギャラリーからこのアプリのインスタンスを追加できます。
- クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニング: Microsoft Entra Connect は、オンプレミスの Active Directory ユーザーを Microsoft Entra ID に同期するために使用されるツールです。 クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングは、クラウドのみのユーザーをクラウド人事アプリから 1 つの Microsoft Entra テナントにプロビジョニングするために使用するコネクタです。
- クラウド人事アプリへの書き戻し: このプロビジョニング コネクタ アプリを使用すると、Microsoft Entra ID からクラウド人事アプリへのユーザーのメール アドレスの書き戻しが簡単になります。
たとえば、次の図に、Microsoft Entra アプリ ギャラリーで入手できる Workday コネクタ アプリが一覧表示されています。
意思決定フロー チャート
以下の決定フロー チャートを使用して、お客様のシナリオに関連しているクラウド人事プロビジョニング アプリを特定します。
Microsoft Entra Connect プロビジョニング エージェントのデプロイ トポロジを設計する
クラウド人事アプリと Active Directory 間のプロビジョニング統合には、次の 4 つのコンポーネントが必要です。
- クラウド人事アプリのテナント
- プロビジョニング コネクタ アプリ
- Microsoft Entra Connect プロビジョニング エージェント
- Active Directory ドメイン
Microsoft Entra Connect プロビジョニング エージェントのデプロイ トポロジは、統合を計画しているクラウド人事アプリのテナントおよび Active Directory 子ドメインの数によって異なります。 複数の Active Directory ドメインがある場合、Active Directory ドメインが連続しているか分離しているかによっても異なります。
決定に基づいて、次のいずれかのデプロイ シナリオを選択します。
- 1 つのクラウド人事アプリのテナント -> 信頼されたフォレスト内の 1 つまたは複数の Active Directory 子ドメインがターゲット
- 1 つのクラウド人事アプリのテナント -> 分離された Active Directory フォレスト内の複数の子ドメインがターゲット
1 つのクラウド人事アプリのテナント -> 信頼されたフォレスト内の 1 つまたは複数の Active Directory 子ドメインがターゲット
次の運用環境の構成をお勧めします。
| 要件 | 推奨 |
|---|---|
| デプロイする Microsoft Entra Connect プロビジョニング エージェントの数。 | 2 つ (高可用性とフェールオーバー)。 |
| 構成するプロビジョニング コネクタ アプリの数。 | 1 つの子ドメインあたり 1 つのアプリ。 |
| Microsoft Entra Connect プロビジョニング エージェントのサーバー ホスト。 | geo 配置された Active Directory ドメイン コントローラーへの見通し線を備えた Windows Server 2016。 Microsoft Entra Connect サービスと共存できます。 |
1 つのクラウド人事アプリのテナント -> 分離された Active Directory フォレスト内の複数の子ドメインがターゲット
このシナリオでは、クラウド人事アプリから分離された Active Directory フォレスト内のドメインにユーザーをプロビジョニングします。
次の運用環境の構成をお勧めします。
| 要件 | 推奨 |
|---|---|
| オンプレミスにデプロイする Microsoft Entra Connect プロビジョニング エージェントの数 | 分離された Active Directory フォレストあたり 2 つ。 |
| 構成するプロビジョニング コネクタ アプリの数 | 1 つの子ドメインあたり 1 つのアプリ。 |
| Microsoft Entra Connect プロビジョニング エージェントのサーバー ホスト。 | geo 配置された Active Directory ドメイン コントローラーへの見通し線を備えた Windows Server 2016。 Microsoft Entra Connect サービスと共存できます。 |
Microsoft Entra Connect プロビジョニング エージェントの要件
クラウド人事アプリから Active Directory へのユーザー プロビジョニング ソリューションは、1 つ以上の Microsoft Entra Connect プロビジョニング エージェントのデプロイを必要とします。 これらのエージェントは、Windows Server 2016 以上を実行するサーバーにデプロイする必要があります。 サーバーは、4 GB 以上の RAM と .NET 4.7.1 以降のランタイムを備えている必要があります。 ホスト サーバーが、ターゲット Active Directory ドメインへのネットワーク アクセスを持っていることを確認します。
オンプレミス環境を準備するために、Microsoft Entra Connect プロビジョニング エージェントの構成ウィザードは、エージェントを Microsoft Entra テナントに登録し、ポートを開き、URL へのアクセスを許可し、送信 HTTPS プロキシ構成に対応します。
Active Directory ドメインと通信するために、プロビジョニング エージェントによってグローバル管理サービス アカウント (GMSA) が構成されます。
プロビジョニング要求を処理する必要のあるドメイン コント ローラーを選択できます。 地理的に分散されたドメイン コント ローラーが複数ある場合は、優先ドメイン コント ローラーと同じサイトにプロビジョニング エージェントをインストールします。 この配置により、エンド ツー エンドのソリューションの信頼性とパフォーマンスが向上します。
高可用性のために、複数の Microsoft Entra Connect プロビジョニング エージェントをデプロイできます。 エージェントを登録して、同じオンプレミスの Active Directory ドメインのセットを処理します。
HR プロビジョニング アプリのデプロイ トポロジを設計する
受信ユーザー プロビジョニング構成にかかわる Active Directory ドメイン数に応じて、次のいずれかのデプロイ トポロジを検討できます。 各トポロジ図では、デプロイ シナリオの例を使用して、構成の側面を強調しています。 実際のデプロイの要件によく似た例を使用して、ニーズを満たす構成を判断します。
デプロイ トポロジ 1: クラウド人事から 1 つのオンプレミスの Active Directory ドメインにすべてのユーザーをプロビジョニングする単一アプリ
デプロイ トポロジ 1 は、最も一般的なデプロイ トポロジです。 クラウド HR からすべてのユーザーを 1 つの AD ドメインにプロビジョニングする必要があり、すべてのユーザーに同じプロビジョニング ルールが適用される場合は、このトポロジを使用します。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
- プロビジョニング エージェント構成ウィザードを使用して、AD ドメインを Microsoft Entra テナントに登録します。
- プロビジョニング アプリを構成するときに、登録されているドメインのドロップダウンから AD ドメインを選択します。
- スコープ フィルターを使用している場合は、アカウントが誤って非アクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
デプロイ トポロジ 2: クラウド人事から 1 つのオンプレミスの Active Directory ドメインに個別のユーザー セットをプロビジョニングする個別のアプリ
このトポロジでは、ユーザーの種類 (従業員または請負業者)、ユーザーの所在地、またはユーザーの事業単位に基づいて、属性マッピングとプロビジョニング ロジックの異なるビジネス要件がサポートされます。 また、このトポロジを使用して、部門または国やリージョンに基づいて受信ユーザー プロビジョニングの管理と保守を委任することもできます。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
- プロビジョニングする個別のユーザー セットごとに HR2AD プロビジョニング アプリを作成します。
- プロビジョニング アプリでスコープ フィルターを使用して、各アプリで処理されるユーザーを定義します。
- マネージャーの参照を個別のユーザー セット間で解決する必要があるシナリオでは、個別の HR2AD プロビジョニング アプリを作成します。 たとえば、請負業者は従業員であるマネージャーに報告します。 個別のアプリを使用して、manager 属性のみを更新します。 このアプリのスコープをすべてのユーザーに設定します。
- アカウントが誤ってアクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
注意
テスト用の AD ドメインがなく、AD で TEST OU コンテナーを使用している場合は、このトポロジを使用して、2 つの個別のアプリ "HR2AD (運用) " と "HR2AD (テスト) " を作成することができます。 "HR2AD (テスト) " アプリを使用して、属性マッピングの変更をテストしてから、"HR2AD (運用) " アプリに昇格させます。
デプロイ トポロジ 3: クラウド人事から複数のオンプレミスの Active Directory ドメインに個別のユーザー セットをプロビジョニングする個別のアプリ (ドメイン間の可視性なし)
トポロジ 3 を使用して、同じフォレストに属する複数の独立した子 AD ドメインを管理します。 マネージャーは常にユーザーと同じドメインに存在するようにしてください。 また、userPrincipalName、samAccountName、mail などの属性に対する一意の ID 生成ルールで、フォレスト全体の検索を必要としないようにしてください。 トポロジ 3 には、各プロビジョニング ジョブの管理をドメイン境界ごとに委任することができる柔軟性も備わっています。
たとえば、この図では、プロビジョニング アプリは、北米 (NA)、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) の各リージョンに設定されています。 場所に応じて、ユーザーはそれぞれの AD ドメインにプロビジョニングされます。 プロビジョニング アプリの委任管理が可能なため、"EMEA の管理者" が EMEA リージョンに属するユーザーのプロビジョニング構成を個別に管理できます。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
- プロビジョニング エージェント構成ウィザードを使用して、すべての子 AD ドメインを Microsoft Entra テナントに登録します。
- ターゲット ドメインごとに個別の HR2AD プロビジョニング アプリを作成します。
- プロビジョニング アプリを構成するときに、使用可能な AD ドメインのドロップダウンからそれぞれの子 AD ドメインを選択します。
- プロビジョニング アプリでスコープ フィルターを使用して、各アプリで処理されるユーザーを定義します。
- アカウントが誤ってアクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
デプロイ トポロジ 4: クラウド人事から複数のオンプレミスの Active Directory ドメインに個別のユーザー セットをプロビジョニングする個別のアプリ (ドメイン間の可視性あり)
トポロジ 4 を使用して、同じフォレストに属する複数の独立した子 AD ドメインを管理します。 ユーザーのマネージャーが別のドメインに存在する場合があります。 また、userPrincipalName、samAccountName、mail などの属性に対する一意の ID 生成ルールで、フォレスト全体の検索が必要です。
たとえば、この図では、プロビジョニング アプリは、北米 (NA)、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) の各リージョンに設定されています。 場所に応じて、ユーザーはそれぞれの AD ドメインにプロビジョニングされます。 ドメイン間マネージャーの参照とフォレスト全体の検索は、プロビジョニング エージェントで参照の追跡を有効にすることで処理されます。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
- プロビジョニング エージェントで参照の追跡を構成します。
- プロビジョニング エージェント構成ウィザードを使用して、親 AD ドメインとすべての子 AD ドメインを Microsoft Entra テナントに登録します。
- ターゲット ドメインごとに個別の HR2AD プロビジョニング アプリを作成します。
- それぞれのプロビジョニング アプリを構成するときに、使用可能な AD ドメインのドロップダウンから親 AD ドメインを選択します。 親ドメインを選択することで、フォレスト全体の参照が保証され、userPrincipalName、samAccountName、mail のような属性に対する一意の値が生成されます。
- parentDistinguishedName と式マッピングを使用して、正しい子ドメインと OU コンテナーにユーザーを動的に作成します。
- プロビジョニング アプリでスコープ フィルターを使用して、各アプリで処理されるユーザーを定義します。
- ドメイン間マネージャーの参照を解決するには、manager 属性のみを更新するための個別の HR2AD プロビジョニング アプリを作成します。 このアプリのスコープをすべてのユーザーに設定します。
- アカウントが誤ってアクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
デプロイ トポロジ 5: 1 つのアプリで、クラウド HR からすべてのユーザーを複数のオンプレミスの Active Directory ドメインにプロビジョニングする (ドメイン間の可視性あり)
1 つのプロビジョニング アプリを使用して、すべての親と子 AD ドメインに属するユーザーを管理する場合は、このトポロジを使用します。 プロビジョニング ルールがすべてのドメインで一貫性があり、プロビジョニング ジョブの委任管理の要件がない場合は、このトポロジをお勧めします。 このトポロジは、ドメイン間マネージャーの参照の解決をサポートしており、フォレスト全体の一意性の確認を実行できます。
たとえば、この図では、1 つのプロビジョニング アプリで、北米 (NA)、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) のリージョン別にグループ化された 3 つの異なる子ドメインに存在するユーザーを管理しています。 parentDistinguishedName の属性マッピングは、適切な子ドメインにユーザーを動的に作成するために使用されます。 ドメイン間マネージャーの参照とフォレスト全体の検索は、プロビジョニング エージェントで参照の追跡を有効にすることで処理されます。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
- プロビジョニング エージェントで参照の追跡を構成します。
- プロビジョニング エージェント構成ウィザードを使用して、親 AD ドメインとすべての子 AD ドメインを Microsoft Entra テナントに登録します。
- フォレスト全体に対して 1 つの HR2AD プロビジョニング アプリを作成します。
- プロビジョニング アプリを構成するときに、使用可能な AD ドメインのドロップダウンから親 AD ドメインを選択します。 親ドメインを選択することで、フォレスト全体の参照が保証され、userPrincipalName、samAccountName、mail のような属性に対する一意の値が生成されます。
- parentDistinguishedName と式マッピングを使用して、正しい子ドメインと OU コンテナーにユーザーを動的に作成します。
- スコープ フィルターを使用している場合は、アカウントが誤って非アクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
デプロイ トポロジ 6: 個別のアプリで、クラウド HR から個別のユーザーを接続解除されたオンプレミスの Active Directory フォレストにプロビジョニングする
IT インフラストラクチャが AD フォレストを接続解除または分離し、事業所属に基づいてユーザーを別のフォレストにプロビジョニングする必要がある場合は、このトポロジを使用します。 たとえば、子会社 Contoso に勤務しているユーザーを contoso.com ドメインにプロビジョニングする必要があり、子会社 Fabrikam に勤務しているユーザーを、fabrikam.com ドメインにプロビジョニングする必要がある場合です。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、フォレストごとに 1 つずつ、2 つの異なるプロビジョニング エージェント セットを設定します。
- フォレストごとに 1 つずつ、2 つの異なるプロビジョニング アプリを作成します。
- フォレスト内のドメイン間参照を解決する必要がある場合は、プロビジョニング エージェントで参照の追跡を有効にします。
- 接続解除されたフォレストごとに個別の HR2AD プロビジョニング アプリを作成します。
- それぞれのプロビジョニング アプリを構成するときに、使用可能な AD ドメイン名のドロップダウンから適切な親 AD ドメインを選択します。
- アカウントが誤ってアクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
デプロイ トポロジ 7: 個別のアプリで、複数のクラウド HR から個別のユーザーを接続解除されたオンプレミスの Active Directory フォレストにプロビジョニングする
大規模な組織では、複数の人事システムを使用することも珍しくありません。 企業の M&A (合併と買収) のシナリオでは、オンプレミスの Active Directory を複数の人事ソースに接続する必要がある場合があります。 複数の人事ソースを持ち、これらの人事ソースから同じまたは異なるオンプレミスの Active Directory ドメインに ID データを送る場合は、このトポロジをお勧めします。
注目すべき構成の側面
- 高可用性とフェールオーバーのために、フォレストごとに 1 つずつ、2 つの異なるプロビジョニング エージェント セットを設定します。
- フォレスト内のドメイン間参照を解決する必要がある場合は、プロビジョニング エージェントで参照の追跡を有効にします。
- 各人事システムとオンプレミスの Active Directory の組み合わせごとに個別の HR2AD プロビジョニング アプリを作成します。
- それぞれのプロビジョニング アプリを構成するときに、使用可能な AD ドメイン名のドロップダウンから適切な親 AD ドメインを選択します。
- アカウントが誤ってアクティブ化されないように、スコープ外の削除をスキップするフラグを構成します。
スコープ フィルターと属性マッピングの計画
クラウド人事アプリから Active Directory または Microsoft Entra ID へのプロビジョニングを有効にすると、Microsoft Entra 管理センターは属性マッピング経由で属性値を制御します。
スコープ フィルターの定義
スコープ フィルターを使用して、クラウド人事アプリから Active Directory または Microsoft Entra ID にプロビジョニングするユーザーを決定する属性ベースのルールを定義します。
入社プロセスを開始するときに、次の要件を収集します。
- クラウド人事アプリを社員と臨時社員両方のオンボードに使用しているか。
- クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングを使用して、従業員と臨時労働者の両方を管理することを計画しているか。
- クラウド人事アプリのユーザーの一部のみを対象に、クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングを実行することを計画しているか。 例として、社員のみが考えられます。
要件に応じて、属性マッピングを構成するときに [ソース オブジェクト スコープ] フィールドを設定して、クラウド人事アプリのどのユーザー セットを Active Directory へのプロビジョニングのスコープに含めるかを選択できます。 一般的に使用されるスコープ フィルターの詳細については、クラウド人事アプリのチュートリアルを参照してください。
一致属性の決定
プロビジョニングでは、ソース システムとターゲット システムの間で既存のアカウントを一致させることができます。 クラウド人事アプリを Microsoft Entra プロビジョニング サービスと統合するときに、属性マッピングを構成して、クラウド人事アプリから Active Directory または Microsoft Entra ID に渡すユーザー データを決定できます。
入社プロセスを開始するときに、次の要件を収集します。
- 各ユーザーの識別に使われる、このクラウド人事アプリでの一意 ID は何か。
- ID のライフサイクルの観点から、再雇用をどのように処理するか。 再雇用時に古い社員 ID が保持されるか。
- 将来の日付の雇用を処理し、対象者の Active Directory アカウントを事前に作成するか。
- ID のライフサイクルの観点から、社員から臨時社員への (またはその逆の) 転換をどのように処理するか。
- 変換されたユーザーが、古い Active Directory アカウントを保持するか、それとも新しいアカウントを取得するか。
Microsoft Entra ID は要件に応じて、定数値を提供するか、属性マッピングの式を記述することで、属性から属性への直接マッピングをサポートします。 この柔軟性により、ターゲット アプリの属性に設定される内容を完全に制御できます。 Microsoft Graph API と Graph Explorer を使用して、ユーザー プロビジョニングの属性マッピングとスキーマを JSON ファイルにエクスポートし、それを Microsoft Entra ID にインポートして戻すことができます。
既定では、一意の社員 ID を表すクラウド人事アプリの属性が、Active Directory の一意の属性にマップされる一致属性として使用されます。たとえば、Workday アプリのシナリオでは、Workday の WorkerID 属性が Active Directory の employeeID 属性にマップされます。
複数の一致属性を設定し、一致の優先順位を割り当てることができます。 一致の優先順位に従って評価が行われます。 1 件でも一致が見つかると、一致する属性の評価はそれ以上行われません。
また、既存の属性マッピングの変更や削除など、既定の属性マッピングをカスタマイズすることもできます。 また、ビジネスのニーズに合わせて新しい属性マッピングを作成できます。 マップするカスタム属性の一覧に関する詳細については、クラウド人事アプリのチュートリアル (Workday など) を参照してください。
ユーザー アカウントの状態の決定
既定では、プロビジョニング コネクタ アプリは、人事のユーザー プロファイルの状態をユーザー アカウントの状態にマッピングします。 状態は、ユーザー アカウントを有効または無効にするかどうかを決定するために使用されます。
入社および退職プロセスを開始するときに、次の要件を収集します。
| Process | 必要条件 |
|---|---|
| 入社 | ID のライフサイクルの観点から、再雇用をどのように処理するか。 再雇用時に古い社員 ID が保持されるか。 |
| 将来の日付の雇用を処理し、対象者の Active Directory アカウントを事前に作成するか。 これらのアカウントが有効または無効どちらの状態で作成されるか。 | |
| ID のライフサイクルの観点から、社員から臨時社員への (またはその逆の) 転換をどのように処理するか。 | |
| 変換されたユーザーが、古い Active Directory アカウントを保持するか、それとも新しいアカウントを取得するか。 | |
| 退職 | Active Directory において、社員と臨時社員で退職の処理方法が異なっているか。 |
| ユーザーの退職の処理にあたり、どのような発効日が考慮されるか。 | |
| 社員および臨時社員の変換は、既存の Active Directory アカウントにどのように影響するか。 | |
| Active Directory で取り消し 操作をどのように処理するか。 将来の日付の雇用が Active Directory で作成される場合、入社プロセスの中で取り消し操作を処理する必要があります。 |
要件に応じて、Microsoft Entra の式を使用して、Active Directory アカウントがデータ ポイントの組み合わせに基づいて有効または無効になるようにマッピング ロジックをカスタマイズできます。
クラウド人事アプリを Active Directory ユーザー属性にマップする
クラウド人事アプリごとに、クラウド人事アプリから Active Directory への既定のマッピングが存在します。
入社、異動、退職プロセスを開始するときに、次の要件を収集します。
| Process | 必要条件 |
|---|---|
| 入社 | Active Directory アカウントの作成プロセスは手動、自動、一部自動のどれか。 |
| クラウド人事アプリから Active Directory にカスタム属性を引き継ぐことを計画しているか。 | |
| 異動 | クラウド人事アプリで異動操作が発生するたびに、どの属性を処理するか。 |
| ユーザーの更新時に特定の属性検証を実行するか。 はいの場合は、詳細を指定します。 | |
| 退職 | Active Directory において、社員と臨時社員で退職の処理方法が異なっているか。 |
| ユーザーの退職の処理にあたり、どのような発効日が考慮されるか。 | |
| 社員および臨時社員の変換は、既存の Active Directory アカウントにどのように影響するか。 |
要件に応じて、統合の目標を満たすようにマッピングを変更できます。 マップするカスタム属性の一覧に関する詳細については、特定のクラウド人事アプリのチュートリアル (Workday など) を参照してください。
一意の属性値の生成
CN、samAccountName、UPN などの属性には、一意の制約があります。 入社プロセスを開始する際に、一意の属性値を生成する必要がある場合があります。
Microsoft Entra ID 関数 SelectUniqueValues は、各ルールを評価し、生成された値のターゲット システムでの一意性を確認します。 例については、「userPrincipalName (UPN) 属性用に一意の値を生成する」を参照してください。
Note
この関数は現在、Workday から Active Directory、SAP SuccessFactors から Active Directory へのユーザー プロビジョニング、およびオンプレミスの Active Directory への API 駆動型プロビジョニングでのみサポートされています。 他のプロビジョニング アプリでの使用はサポートされていません。
Active Directory OU コンテナーの割り当てを構成する
事業単位、所在地、部門に基づいて Active Directory ユーザー アカウントをコンテナーに配置することは一般的な要件です。 異動プロセスを開始し、監督組織の変更があった場合、Active Directory 内で、ある OU から別の OU にユーザーを移動することが必要な場合があります。
Switch() 関数を使用して、OU 割り当てのビジネス ロジックを構成し、Active Directory の parentDistinguishedName 属性にマップします。
たとえば、人事アプリの Municipality (市町村) 属性に基づいて OU にユーザーを作成する場合、次の式を使用できます。
Switch([Municipality], "OU=Default,OU=Users,DC=contoso,DC=com", "Dallas", "OU=Dallas,OU=Users,DC=contoso,DC=com", "Austin", "OU=Austin,OU=Users,DC=contoso,DC=com", "Seattle", "OU=Seattle,OU=Users,DC=contoso,DC=com", "London", "OU=London,OU=Users,DC=contoso,DC=com")
この式では、Municipality の値が Dallas、Austin、Seattle、または London の場合、ユーザー アカウントは対応する OU に作成されます。 一致するものがない場合、アカウントは既定の OU に作成されます。
新しいユーザー アカウントのパスワード交付の計画
入社プロセスの開始時に、新しいユーザー アカウントの一時パスワードを設定して交付する必要があります。 クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングでは、Microsoft Entra ID のセルフサービス パスワード リセット (SSPR) 機能を初日からユーザーに提供できます。
SSPR は、パスワードのリセットやアカウントのロック解除を IT 管理者がユーザーに許可するための簡単な手段です。 携帯電話番号属性をクラウド人事アプリから Active Directory にプロビジョニングし、Microsoft Entra ID と同期できます。 携帯電話番号属性が Microsoft Entra ID に追加されたら、ユーザーのアカウントに対して SSPR を有効にできます。 その後、新しいユーザーは初日に認証に登録および検証された携帯電話番号を使用できます。 認証の連絡先情報を事前設定する方法の詳細については、SSPR のドキュメントを参照してください。
初期サイクルの計画
Microsoft Entra プロビジョニング サービスを初めて実行すると、クラウド人事アプリに対して初期サイクルが実行され、クラウド人事アプリ内のすべてのユーザー オブジェクトのスナップショットが作成されます。 初期サイクルにかかる時間は、ソース システムに存在するユーザーの数に正比例します。 ユーザーが 10 万人を超えるようなクラウド人事アプリのテナントでは、初期サイクルに長い時間がかかることがあります。
大規模なクラウド人事アプリテナント (>3 万人以上のユーザー) の場合、最初のサイクルを段階的に実行します。 増分更新を開始するのは、異なるユーザー プロビジョニングのシナリオに応じて Active Directory で正しい属性が設定されていることを検証した後のみにしてください。 この順序に従ってください。
- スコープ フィルターを設定して、限られたユーザーのセットのみを対象に初期サイクルを実行します。
- 最初の実行のために選択したユーザーについて、Active Directory アカウントのプロビジョニングと属性値の設定を確認します。 結果が期待どおりである場合、スコープ フィルターを拡張してユーザーを徐々に増やし、2 回目の実行の結果を確認します。
テスト用のユーザーに対する初期サイクルの結果に問題がなければ、増分更新を開始します。
テストとセキュリティを計画する
デプロイは、初期パイロットからユーザー プロビジョニングを有効にするまでのステージで構成されます。 各段階で、期待される結果を得るためのテストが行われていることを確認します。 また、プロビジョニング サイクルを監査します。
テストを計画する
クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングを構成したら、テスト ケースを実行して、このソリューションが組織の要件を満たしているかどうかを確認します。
| シナリオ | 予想される結果 |
|---|---|
| クラウド人事アプリで新しい社員が採用されている。 | - ユーザー アカウントが Active Directory にプロビジョニングされます。 - ユーザーが Active Directory ドメインのアプリにログインして目的のアクションを実行できます。 - Microsoft Entra Connect 同期が構成されている場合、Microsoft Entra ID にもユーザー アカウントが作成されます。 |
| クラウド人事アプリでユーザーの退職処理が行われる。 | - ユーザー アカウントが Active Directory で無効になります。 - ユーザーは Active Directory によって保護されているエンタープライズ アプリにログインできません。 |
| クラウド人事アプリでユーザーの監督組織が更新される。 | 属性マッピングに基づいて、ユーザー アカウントが Active Directory 内のある OU から別の OU に移動します。 |
| 人事がクラウド人事アプリでユーザーの上司を更新する。 | 新しい上司の名前を反映するよう Active Directory の [上司] フィールドが更新されます。 |
| 社員を新しい役職に再雇用する人事 | 動作は、社員 ID の生成に関するクラウド人事アプリの構成内容によって異なります。 再雇用にあたって古い社員 ID を利用する場合、コネクタはユーザーの既存の Active Directory アカウントを有効化します。 再雇用にあたって新しい社員 ID を使用する場合、コネクタはユーザーの新しい Active Directory アカウントを作成します。 |
| 人事が社員を臨時社員に (またはその逆に) 転換する。 | 新しいペルソナ用に新しい Active Directory アカウントが作成され、古いアカウントは転換の発効日をもって無効になります。 |
以上の結果を用いて、また確定したスケジュールに基づいて、自動ユーザー プロビジョニングの実装を運用環境に移行する方法を決定します。
ヒント
プライバシーおよびセキュリティ標準に準拠するために、運用データを使用してテスト環境を更新するときは、データ整理やデータ スクラビングなどの手法を用いて、機密な個人データを削除またはマスクします。
セキュリティを計画する
通常、新しいサービスのデプロイの一環としてセキュリティ レビューが必要になります。 セキュリティ レビューが必要であるか、未実施の場合は、サービスとしての ID の概要を説明している Microsoft Entra ID の多くのホワイト ペーパーを参照してください。
ロールバックを計画する
クラウドの人事ユーザー プロビジョニングの実装は、運用環境では期待通りに動作しない可能性があります。 その場合、次のロールバック手順を使用すると、以前の正常な状態に戻すことができます。
- プロビジョニング ログを確認して、影響を受けたユーザーやグループに対して実行された誤った操作を判別します。 プロビジョニングの概要レポートとログの詳細については、クラウド人事アプリのユーザー プロビジョニングの管理に関するページを参照してください。
- 影響を受けるユーザーやグループの最後の既知の良好な状態は、プロビジョニング ログ経由で、またはターゲット システム (Microsoft Entra ID または Active Directory) を確認することで判定できます。
- アプリの所有者と協力し、最新の既知の正常な状態の値を使用して、アプリで直接影響を受けたユーザーやグループを更新します。
クラウド人事アプリのデプロイ
ソリューションの要件に合ったクラウド人事アプリを選択します。
Workday: Workday から Active Directory および Microsoft Entra ID に労働者プロファイルをインポートするには、「チュートリアル: Workday を構成し、自動ユーザー プロビジョニングに対応させる」を参照してください。 必要に応じて、メール アドレス、ユーザー名、電話番号を Workday に書き戻すことができます。
SAP SuccessFactors: SuccessFactors から Active Directory および Microsoft Entra ID に労働者プロファイルをインポートするには、チュートリアル: SAP SuccessFactors を構成し、自動ユーザー プロビジョニングに対応させる方法に関する記事を参照してください。 必要に応じて、メール アドレスとユーザー名を SuccessFactors に書き戻すことができます。
構成の管理
Microsoft Entra ID は、プロビジョニング ログとレポートを介して、組織のユーザー プロビジョニングの使用状況と運用の正常性について追加の分析情報を提供します。
レポートとログから分析情報を得る
初期サイクルが正常に完了すると、Microsoft Entra プロビジョニング サービスは、次のいずれかのイベントが発生するまで、各アプリに固有のチュートリアルで定義された間隔で、増分更新を次から次へと無期限に実行し続けます。
- サービスは手動で停止されます。 Microsoft Entra 管理センター、または該当の Microsoft Graph API コマンドを使用して、新しい初回サイクルがトリガーされる。
- 属性マッピングまたはスコープ フィルターの変更によって、新しい初期サイクルがトリガーされます。
- エラー率が高いため、プロビジョニング プロセスは検査に入ります。 4 週間を超えると、検査は自動的に無効になります。
これらのイベントと、プロビジョニング サービスによって実行されるその他のすべてのアクティビティを確認するには、ログを確認してプロビジョニング アクティビティのレポートを取得する方法を参照してください。
Azure Monitor ログ
プロビジョニング サービスによって実行されたアクティビティはすべて、Microsoft Entra のプロビジョニング ログに記録されます。 Microsoft Entra プロビジョニング ログを Log Analytics ワークスペースにルーティングできます。これにより、データを Azure Monitor ログと Microsoft Entra ブックに送信し、データのクエリを行ってイベントを検索し、傾向を分析して、さまざまなデータ ソース間の相関を実行できます。 実践的なユーザー シナリオで Microsoft Entra ログに対して Azure Monitor ログを使う利点については、この動画をご覧ください。
Log Analytics と Microsoft Entra のブックを有効にするには、Log Analytics ワークスペースを構成する必要があります。 次に、診断設定を構成して、適切なエンドポイントにデータをルーティングします。 詳細については、以下を参照してください:
- Log Analytics ワークスペースの構成
- Microsoft Entra アクティビティ ログを Azure Monitor ログと統合する
- Microsoft Entra ブックの使用方法
- プロビジョニング分析情報ブック
個人データを管理する
Windows サーバーにインストールされた Microsoft Entra Connect プロビジョニング エージェントは、Windows イベント ログにログを作成しますが、これには、クラウド人事アプリから Active Directory への属性マッピングの設定によっては、個人データが含まれる場合があります。 ユーザーのプライバシー義務を遵守するために、イベント ログを消去するように Windows のスケジュールされたタスクを設定し、48 時間を超えてデータが保持されないようにすることができます。
Microsoft Entra プロビジョニング サービスは、30 日を超えたレポートの生成、分析の実行、分析情報の提供を行いません。サービスが 30 日を超えてデータを格納、処理、保持しないためです。
Joiner-Mover-Leaver ライフサイクル ワークフローの管理
人事主導のプロビジョニング プロセスを拡張して、新規採用、人事上の変更、退職に関連するビジネス プロセスとセキュリティ制御をさらに自動化できます。 Microsoft Entra ID Governance ライフサイクル ワークフローでは、次のような Joiner-Mover-Leaver ワークフローを構成できます。
- 新規採用者が入社する日の "X" 日前に、マネージャーに電子メールを送信し、ユーザーをグループに追加し、初回ログインの一時的なアクセス パスを生成します。
- ユーザーの部署または役職またはグループ メンバーシップに変更がある場合は、カスタム タスクを起動します。
- 在籍最終日に、マネージャーに電子メールを送信し、グループとライセンスの割り当てからユーザーを削除します。
- 退職の "X" 日後、Microsoft Entra ID からユーザーを削除します。
トラブルシューティング
プロビジョニング中に発生する可能性がある問題のトラブルシューティングについては、次の記事を参照してください。
- Microsoft Entra ギャラリー アプリケーションへのユーザー プロビジョニングの構成に関する問題
- アプリケーションにプロビジョニングするためにオンプレミスの Active Directory から Microsoft Entra ID に属性を同期する
- Microsoft Entra ギャラリー アプリケーションへのユーザー プロビジョニングを構成している間の管理者の資格情報の保存に関する問題
- Microsoft Entra ギャラリー アプリケーションにユーザーがプロビジョニングされない
- 間違ったユーザー グループが Microsoft Entra ギャラリー アプリケーションにプロビジョニングされる
- エージェントのトラブルシューティングのための Windows イベント ビューアーの設定
- サービスのトラブルシューティングのための Microsoft Entra 管理センター プロビジョニング ログの設定
- AD ユーザー アカウントの作成操作のログの概要
- マネージャーの更新操作のログの概要
- よく発生するエラーの解決