Microsoft Entra ID でのアプリケーション プロビジョニングのしくみ
自動プロビジョニングとは、ユーザーがアクセスする必要のあるクラウド アプリケーションのユーザー ID とロールを作成することです。 自動プロビジョニングには、ユーザー ID の作成に加えて、状態または役割が変化したときのユーザー ID のメンテナンスおよび削除が含まれます。 デプロイを開始する前に、この記事を参照して Microsoft Entra プロビジョニングのしくみを学習し、構成に関する推奨事項を確認することができます。
Microsoft Entra プロビジョニング サービスでは、アプリケーション ベンダーまたはオンプレミス プロビジョニング エージェントによって提供されるクロスドメイン ID 管理システム (SCIM) 2.0 ユーザー管理 API エンドポイントに接続することによって、SaaS アプリや他のシステムにユーザーがプロビジョニングされます。 Microsoft Entra ID では、この SCIM エンドポイントを使って、プログラムによってユーザーが作成、更新、削除されます。 一部のアプリケーションについては、ID に関連する他のオブジェクト (グループなど) をプロビジョニング サービスで作成、更新、削除することもできます。 Microsoft Entra ID とアプリケーションの間のプロビジョニングに使われるチャネルは、HTTPS TLS 1.2 暗号化を使って暗号化されます。
図 1: Microsoft Entra プロビジョニング サービス
図 2: Microsoft Entra ID から主要 SaaS アプリケーションへの "出力方向" のユーザー プロビジョニング ワークフロー
図 3: 主要な人材管理 (HCM) アプリケーションから Microsoft Entra ID および Windows Server Active Directory への "入力方向" のユーザー プロビジョニング ワークフロー
SCIM 2.0 を使用したプロビジョニング
Microsoft Entra プロビジョニング サービスでは、自動プロビジョニングに SCIM 2.0 プロトコルが使われます。 このサービスは、アプリケーションの SCIM エンドポイントに接続され、SCIM ユーザー オブジェクト スキーマおよび REST API を使用してユーザーとグループのプロビジョニングとプロビジョニング解除を自動化します。 Microsoft Entra ギャラリーでは、ほとんどのアプリケーションに対して SCIM ベースのプロビジョニング コネクタが用意されています。 開発者は、Microsoft Entra ID で SCIM 2.0 ユーザー管理 API を使って、プロビジョニング サービスに統合するアプリのためのエンドポイントを構築します。 詳細については、SCIM エンドポイントの構築とプロビジョニングの構成に関するページを参照してください。 また、オンプレミス プロビジョニング エージェントは、Microsoft Entra SCIM の操作を、LDAP、SQL、REST または SOAP、PowerShell、カスタム ECMA コネクタの呼び出し、またはパートナーによって構築されたコネクタとゲートウェイに変換します。
自動 Microsoft Entra プロビジョニング コネクタが現在ないアプリに対してこのコネクタを要求するには、Microsoft Entra アプリケーション要求に関するページを参照してください。
認可
Microsoft Entra ID をアプリケーションのユーザー管理 API に接続するには、資格情報が必要です。 アプリケーションの自動ユーザー プロビジョニングを構成している間に、有効な資格情報を入力する必要があります。 ギャラリー アプリケーションの場合、アプリケーションの資格情報の種類と要件については、アプリのチュートリアルを参照してください。 ギャラリー以外のアプリケーションの場合は、SCIM のドキュメントを参照して、資格情報の種類と要件を理解することができます。 Microsoft Entra 管理センターで、資格情報をテストできます (Microsoft Entra ID により、指定された資格情報を使用してアプリのプロビジョニング アプリへの接続が試行されます)。
属性のマッピング
サード パーティの SaaS アプリケーションでユーザー プロビジョニングを有効にすると、Microsoft Entra 管理センターでは属性マッピングによってその属性値が管理されます。 マッピングにより、ユーザー アカウントをプロビジョニングまたは更新するときに Microsoft Entra ID とターゲット アプリケーションの間でフローするユーザー属性が決定されます。
Microsoft Entra ユーザー オブジェクトと各 SaaS アプリのユーザー オブジェクトの間には、事前構成済みの一連の属性と属性マッピングが存在します。 アプリによっては、ユーザーに加えてグループなど他の種類のオブジェクトを管理するものもあります。
プロビジョニングを設定するときは、どのユーザー (またはグループ) プロパティが Microsoft Entra ID からアプリケーションに提供されるかを定義する属性マッピングとワークフローを確認して構成することが重要です。 2 つのシステム間でユーザーまたはグループを一意に識別して照合するために使用される照合プロパティ (この属性を使用してオブジェクトを照合します) を確認して構成します。
既定の属性マッピングをビジネスのニーズに合わせてカスタマイズできます。 そのため、既存の属性マッピングを変更、削除したり、新規の属性マッピングを作成したりすることができます。 詳細については、SaaS アプリケーションに対するユーザー プロビジョニング属性マッピングのカスタマイズに関するページを参照してください。
SaaS アプリケーションに対してプロビジョニングを構成するときに指定できる属性マッピングの種類の 1 つは、式マッピングです。 これらのマッピングでは、ユーザーのデータを SaaS アプリケーションが許容可能な形式に変換することができる、スクリプトのような式を記述する必要があります。 詳細については、属性マッピングの式の書き方に関するページを参照してください。
スコープ
割り当てベースのスコープ
Microsoft Entra ID から SaaS アプリケーションへの送信プロビジョニングでは、ユーザーまたはグループの割り当てに依存することが、プロビジョニングの対象となるユーザーを特定する最も一般的な方法です。 ユーザー割り当てはシングル サインオンの有効化にも使用されるため、アクセスとプロビジョニングの両方を管理するのに同じ方法を使用できます。 割り当てベースのスコープは、Workday や Successfactors などの受信プロビジョニング シナリオには適用されません。
グループ。 Microsoft Entra ID P1 または P2 ライセンス プランを利用すると、グループを使って SaaS アプリケーションにアクセスを割り当てることができます。 プロビジョニング スコープが、割り当てられているユーザーおよびグループのみを同期するように設定されている場合、Microsoft Entra プロビジョニング サービスでは、ユーザーがアプリケーションに割り当てられているグループのメンバーであるかどうかに基づいて、ユーザーがプロビジョニングまたはプロビジョニング解除されます。 アプリケーションでグループ オブジェクトがサポートされていない場合、グループ オブジェクト自体はプロビジョニングされません。 アプリケーションに割り当てられているグループで、プロパティ "SecurityEnabled" が "True" に設定されていることを確認します。
動的グループ。 Microsoft Entra ユーザー プロビジョニング サービスでは、動的メンバーシップ グループのユーザーの読み取りとプロビジョニングを行うことができます。 次の注意事項と推奨事項に留意してください。
動的グループは、Microsoft Entra ID から SaaS アプリケーションへのエンドツーエンドのプロビジョニングのパフォーマンスに影響を与えることがあります。
SaaS アプリケーションで動的グループのユーザーをプロビジョニングまたはプロビジョニング解除する速度は、動的グループがメンバーシップの変更を評価する速さによって決まります。 動的グループの処理状態を確認する方法については、メンバーシップ ルールの処理状態のチェックに関するページを参照してください。
動的グループのユーザーのメンバーシップが失われると、プロビジョニング解除イベントと見なされます。 動的グループのルールを作成する場合は、このシナリオを検討してください。
入れ子になったグループ。 Microsoft Entra ユーザー プロビジョニング サービスでは、入れ子になったグループのユーザーの読み取りやプロビジョニングを行うことはできません。 このサービスでは、明示的に割り当てられたグループの直接のメンバーであるユーザーだけを読み取ってプロビジョニングすることができます。 "アプリケーションへのグループベースの割り当て" のこの制限は、シングル サインオンにも影響を与えます (「SaaS アプリケーションへのアクセスをグループで管理する」を参照)。 代わりに、プロビジョニングする必要のあるユーザーを含むグループを明示的に割り当てるか、またはスコープ設定します。
属性ベースのスコープ
スコープ フィルターを使用して、アプリケーションにプロビジョニングするユーザーを決める、属性ベースのルールを定義できます。 この方法は、一般的に、HCM アプリケーションから Microsoft Entra ID および Active Directory への受信プロビジョニングに使われます。 スコープ フィルターは各 Microsoft Entra ユーザー プロビジョニング コネクタの属性マッピングで設定されます。 属性ベースのスコープ フィルターの構成の詳細については、「スコープ フィルターを使用した属性ベースのアプリケーション プロビジョニング」を参照してください。
B2B (ゲスト) ユーザー
Microsoft Entra ユーザー プロビジョニング サービスを使って、Microsoft Entra ID の B2B (ゲスト) ユーザーを SaaS アプリケーションにプロビジョニングすることは可能です。 ただし、B2B ユーザーが Microsoft Entra ID を使って SaaS アプリケーションにサインインするには、Microsoft Entra ID を Security Assertion Markup Language (SAML) ID プロバイダーとして使うように SaaS アプリケーションを手動で構成する必要があります。
B2B (ゲスト) ユーザー用に SaaS アプリを構成する場合は、こちらの一般的なガイドラインに従います。
- ほとんどのアプリでは、ユーザー セットアップを手動で起動する必要があります。 アプリでユーザーも手動で作成する必要があります。
- Dropbox のように、自動セットアップをサポートしているアプリでは、アプリから個別の招待が作成されます。 ユーザーは各招待に確実に応じる必要があります。
- ゲスト ユーザーの壊れたユーザー プロファイル ディスク (UPD) の問題を緩和するには、常にユーザー属性のユーザー識別子を user.mail に設定します。
注意
B2B Collaboration ユーザーの userPrincipalName では、外部ユーザーのメール アドレス alias@theirdomain は "alias_theirdomain#EXT#@yourdomain" と表されます。 userPrincipalName 属性がソース属性として属性マッピングに含まれていて、B2B ユーザーがプロビジョニングされている場合、#EXT# とドメインは userPrincipalName から削除されるため、元の alias@theirdomain のみが照合またはプロビジョニングに使用されます。 #EXT# とドメインを含む完全なユーザー プリンシパル名が存在する必要がある場合は、userPrincipalName をソース属性として originalUserPrincipalName に置き換えます。
userPrincipalName = alias@theirdomain
originalUserPrincipalName = alias_theirdomain#EXT#@yourdomain
プロビジョニング サイクル: 初回と増分
Microsoft Entra ID がソース システムである場合、プロビジョニング サービスでは、Microsoft Graph データの変更を追跡するためにデルタ クエリを使って、ユーザーとグループを監視します。 プロビジョニング サービスは、ソース システムとターゲット システムに対して初回サイクルを実行した後、増分サイクルを定期的に行います。
初回サイクル
プロビジョニング サービスが開始されたときの初回サイクルでは、次の処理が実行されます。
ソース システムのすべてのユーザーとグループにクエリを実行し、属性マッピングで定義されているすべての属性を取得します。
返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープ フィルターを使用してフィルター処理します。
ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲット システムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。 例: ソース システムの userPrincipal 名が一致属性であり、ターゲット システムの userName にマップされる場合、プロビジョニング サービスは、ターゲット システムにクエリを実行し、ソース システムの userPrincipal 名の値と一致する userName がないかどうかを確認します。
一致するユーザーがターゲット システムで見つからない場合、ソース システムから返された属性を使用してユーザーが作成されます。 ユーザー アカウントが作成されると、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
一致するユーザーが見つかった場合、そのユーザーは、ソース システムによって提供された属性を使用して更新されます。 ユーザー アカウントが照合されると、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
属性マッピングに "参照" 属性が含まれている場合、サービスは、ターゲット システムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。 たとえば、あるユーザーがターゲット システムで "Manager" 属性を持ち、それがターゲット システムで作成された別のユーザーにリンクされている場合があります。
初回サイクルの終了時に基準値を保持します。これは、以降の増分サイクルの始点になります。
ServiceNow、G Suite、Box など、アプリケーションの中には、ユーザーのプロビジョニングだけでなく、グループとそのメンバーのプロビジョニングをサポートしているものがあります。 このような場合、グループのプロビジョニングがマッピングで有効になっていると、プロビジョニング サービスは、ユーザーとグループを同期したうえで、動的メンバーシップ グループを同期します。
増分サイクル
初回サイクルの後、他のすべてのサイクルでは以下が行われます。
ソース システムにクエリを実行し、前回の基準値が保存された後に更新されたユーザーおよびグループがないかどうかを確認します。
返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープ フィルターを使用してフィルター処理します。
ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲット システムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。
一致するユーザーがターゲット システムで見つからない場合、ソース システムから返された属性を使用してユーザーが作成されます。 ユーザー アカウントが作成されると、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
一致するユーザーが見つかった場合、そのユーザーは、ソース システムによって提供された属性を使用して更新されます。 照合されたのが新しく割り当てられたアカウントである場合、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
属性マッピングに "参照" 属性が含まれている場合、サービスは、ターゲット システムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。 たとえば、あるユーザーがターゲット システムで "Manager" 属性を持ち、それがターゲット システムで作成された別のユーザーにリンクされている場合があります。
以前プロビジョニングの対象であったユーザーが対象から外れた場合 (割り当てられていない場合を含む)、このサービスでは、更新を通じてターゲット システムでこのユーザーが無効化されます。
以前プロビジョニングの対象だったユーザーが、ソース システムで無効にされた場合、または論理削除された場合、サービスは、更新によってターゲット システムのユーザーを無効にします。
以前プロビジョニングの対象だったユーザーが、ソース システムから物理的に削除された場合、サービスは、ターゲット システムのユーザーを削除します。 Microsoft Entra ID では、論理削除されたユーザーは、削除されてから 30 日後に物理的に削除されます。
増分サイクルの終了時に新しい基準値を保持します。これは、以降の増分サイクルの始点になります。
注意
[マッピング] セクションの [対象オブジェクトのアクション] チェック ボックスを使用して、[作成]、[更新]、または [削除] 操作を必要に応じて無効にできます。 更新中にユーザーを無効にするロジックは、accountEnabled などのフィールドの属性マッピングでも制御されます。
プロビジョニング サービスでは、バックツーバック増分サイクルが、各アプリケーションに固有のチュートリアルで定義された間隔で無期限に実行され続けます。 増分サイクルは、次のいずれかのイベントが発生するまで続行されます。
- Microsoft Entra 管理センターまたは適切な Microsoft Graph API コマンドを使用してサービスが手動で停止された。
- Microsoft Entra 管理センターの [プロビジョニングを再起動] オプション、または適切な Microsoft Graph API コマンドを使用して、新しい初回サイクルがトリガーされた。 このアクションにより、保存された基準値がクリアされ、すべてのソース オブジェクトが再評価されます。 また、このアクションはソース オブジェクトとターゲット オブジェクト間のリンクを中断しません。 リンクを解除するには、次の要求で同期ジョブの再起動を使用します。
POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Authorization: Bearer <token>
Content-type: application/json
{
"criteria": {
"resetScope": "Full"
}
}
- 属性マッピングまたはスコープ フィルターの変更によって、新しい初回サイクルがトリガーされた。 また、この操作では、保存された基準値がクリアされ、すべてのソース オブジェクトが再評価されます。
- 高いエラー率によりプロビジョニング プロセスが検査に移行し (以下を参照)、そのまま 4 週間を超えて検疫にとどまっている。 この場合、サービスは自動的に無効になります。
エラーと再試行
ターゲット システムでのエラーが原因で個々のユーザーの追加、更新、または削除がターゲットシステム上で行えない場合、その操作は次の同期サイクルで再試行されます。 エラーは継続的に再試行され、再試行頻度は徐々に減らされます。 エラーを解決するには、管理者がプロビジョニング ログを確認し、根本原因を特定して、適切な対応を取る必要があります。 たとえば、次のような一般的なエラーがあります。
- ターゲット システムで必要な属性がソース システムのユーザーに設定されていない
- ソース システムのユーザーの属性値に対して、ターゲット システムに一意の制約があり、同じ値が他のユーザー レコードに存在する
このようなエラーを解決するには、ソース システムで影響を受けるユーザーの属性値を調整するか、競合が発生しないように属性マッピングを調整します。
検疫
ターゲット システムに対する呼び出しのほとんどまたはすべてが、常にエラー (管理者の資格情報が無効である場合など) が原因で失敗する場合、プロビジョニング ジョブは "検疫" 状態になります。 この状態は、プロビジョニング概要レポート、または電子メール (電子メール通知が Microsoft Entra 管理センターで構成されている場合) で示されます。
検疫状態であると、増分サイクルの頻度は徐々に減少し、最終的には 1 日 1 回になります。
問題を引き起こしているすべてのエラーが修正されたら、プロビジョニング ジョブは検疫から削除され、次の同期サイクルが開始されます。 プロビジョニング ジョブが検疫にとどまっている期間が 4 週間を超えると、そのプロビジョニング ジョブは無効になります。 検疫の状態の詳細については、こちらを参照してください。
プロビジョニングにかかる時間
プロビジョニング ジョブで実行されているのが初期プロビジョニング サイクルか増分サイクルかによって、パフォーマンスが異なります。 プロビジョニングにかかる時間、およびプロビジョニング サービスの状態を監視する方法について詳しくは、ユーザー プロビジョニングの状態の確認に関するページをご覧ください。
ユーザーが正しくプロビジョニングされているかどうかを確認する方法
ユーザー プロビジョニング サービスによって実行された操作はすべて、Microsoft Entra のプロビジョニング ログに記録されます。 このログには、ソース システムとターゲット システムに対して実行されたすべての読み取りおよび書き込み操作と、各操作の際に読み取られたり書き込まれたりしたユーザー データが含まれます。 Microsoft Entra 管理センターでプロビジョニング ログを確認する方法については、プロビジョニング レポートに関するガイドを参照してください。
プロビジョニング解除
Microsoft Entra プロビジョニング サービスでは、ユーザー アクセスが削除された場合に、アカウントをプロビジョニング解除することによってソースおよびターゲット システムの同期が維持されます。
ユーザーの削除と無効化 (論理的な削除とも呼ばれます) の両方が、このプロビジョニング サービスによってサポートされています。 無効化と削除の厳密な定義は、ターゲット アプリの実装によって異なりますが、一般に、無効化とはユーザーがサインインできないことを示します。 削除とは、ユーザーがアプリケーションから完全に削除されたことを示します。 SCIM アプリケーションの場合、無効化は、ユーザーに対して active プロパティを false に設定する要求です。
ユーザーを無効にするようにアプリケーションを構成する
更新のチェックボックスが選択されていることを確認します。
ご利用のアプリケーション用の active のマッピングを確認します。 アプリ ギャラリーからのアプリケーションを使用している場合は、マッピングが若干異なることがあります。 このケースでは、ギャラリー アプリケーションの既定のマッピングを使用します。
ユーザーを削除するようにアプリケーションを構成する
次のシナリオでは、無効化または削除がトリガーされます。
- Microsoft Entra ID でユーザーが論理的に削除される (ごみ箱に送られる/AccountEnabled プロパティが false に設定される)。 Microsoft Entra ID でユーザーが削除されてから 30 日後に、テナントから完全に削除されます。 この時点で、プロビジョニング サービスによって削除要求が送信されて、アプリケーション内のユーザーが完全に削除されます。 30 日間の期間中はいつでも、ユーザーを手動で完全に削除することができます。これにより、削除要求がアプリケーションに送信されます。
- ユーザーを Microsoft Entra ID のごみ箱から完全に削除または除去する。
- ユーザーをアプリから割り当て解除する。
- ユーザーがスコープ内からスコープ外に移動する (スコープ フィルターを通過しない)。
既定では、Microsoft Entra プロビジョニング サービスにより、スコープ外になったユーザーが論理的に削除または無効化されます。 この既定の動作をオーバーライドする場合は、スコープ外の削除をスキップするようにフラグを設定します。
4 つのイベントのいずれかが発生し、ターゲット アプリケーションで論理的な削除がサポートされていない場合は、プロビジョニング サービスによって削除要求が送信されて、アプリからユーザーが完全に削除されます。
属性マッピングに IsSoftDeleted がある場合は、これが使用されて、ユーザーの状態と、active = false を指定した更新要求を送信してユーザーを論理的に削除するかどうかが判別されます。
プロビジョニング解除のイベント
この表に、Microsoft Entra プロビジョニング サービスを使ってプロビジョニング解除アクションを構成する方法が説明されています。 これらの規則は、ギャラリー以外またはカスタムのアプリケーションを考慮して記述されていますが、一般的にはギャラリー内のアプリケーションに適用されます。 ただし、ギャラリー アプリケーションの動作は、アプリケーションのニーズに合わせて最適化されているため、異なる場合があります。 たとえば、ターゲット アプリケーションで論理的な削除がサポートされていない場合、Microsoft Entra プロビジョニング サービスは、論理的な削除を送信するのではなく、物理的な削除の要求を送信してユーザーを削除する可能性があります。
| シナリオ | Microsoft Entra ID で構成する方法 |
|---|---|
| ユーザーがアプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた。 何も実行されないようにする。 | 属性マッピングから isSoftDeleted を削除するか、またはスコープ外の削除をスキップするプロパティを true に設定するか、あるいはその両方を行います。 |
ユーザーがアプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた。 特定の属性を true または false に設定する必要がある。 |
false に設定する必要がある属性に isSoftDeleted をマップします。 |
| ユーザーが Microsoft Entra ID で無効になったか、アプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた。 ターゲット アプリケーションに削除要求を送信する必要がある。 | これは現在、この機能を必要とする限定されたギャラリー アプリケーションのセットでサポートされています。 顧客がこれを構成することはできません。 |
| ユーザーは Microsoft Entra ID で削除されます。 ターゲット アプリケーションで何も実行されないようにする。 | 属性構成エクスペリエンスで、ターゲット オブジェクトのアクションの 1 つとして [削除] が選択されていないことを確認します。 |
| ユーザーは Microsoft Entra ID で削除されます。 ターゲット アプリケーションで属性の値を設定する必要がある。 | サポートされていません。 |
| ユーザーは Microsoft Entra ID で削除されます。 ターゲット アプリケーションでユーザーを削除する必要がある | 属性構成エクスペリエンスで、対象オブジェクトのアクションの 1 つとして [削除] が選択されていることを確認します。 |
既知の制限事項
- ユーザーまたはグループがアプリから割り当て解除され、プロビジョニング サービスで管理されなくなると、無効化要求が送信されます。 その時点で、ユーザーはサービスによって管理されておらず、ユーザーがディレクトリから論理的に削除されたときに削除要求は送信されません。
- Microsoft Entra ID 内で無効になっているユーザーのプロビジョニングはサポートされていません。 プロビジョニングされるには、事前に Microsoft Entra ID 内でアクティブになっている必要があります。
- ユーザーが論理的に削除された状態からアクティブになると、Microsoft Entra プロビジョニング サービスによってそのユーザーはターゲット アプリ内でアクティブにされますが、動的メンバーシップ グループは自動的には復元されません。 ターゲット アプリケーションによって、ユーザーの動的メンバーシップ グループは非アクティブ状態で維持されます。 非アクティブ状態の管理がターゲット アプリケーションでサポートされていない場合は、プロビジョニングを再起動して動的メンバーシップ グループを更新することができます。
推奨事項
アプリケーションを開発する場合は、論理的な削除と物理的な削除の両方を常にサポートしてください。 そうすることで、顧客は、ユーザーが誤って無効にされた場合でも回復することができます。