# REST API を使用した SCIM でユーザーとグループのプロビジョニング GitHub の クロスドメイン ID 管理システム (SCIM) 用 REST API を使用して、お使いの ID プロバイダー (IdP) のユーザー アカウントのライフサイクルを管理します。 これらのステップを実行してください： > \[!NOTE] GitHub では、IdP と GitHub 上の運用データから分離された環境でプロビジョニングをテストすることをお勧めします。 これらのステップを実行してください： ## Enterprise Managed Users の IAM について GitHubの Enterprise がEnterprise Managed Users用に作成された場合、ユーザー アカウントをプロビジョニングして管理するため、外部 ID 管理システムを構成する必要があります。 ID 管理システムは、次の機能を提供する必要があります。 * 次の 2 つあるシングル サインオン (SSO) 規格のいずれかを実装したシングル サインオン認証 * Security Assertion Markup Language(SAML)2.0 * OpenID Connect (OIDC) は、Microsoft Entra ID (以前は Azure AD) を使用する場合にのみサポートされます。 * クロス ドメイン ID 管理システム(SCIM)でユーザー ライフサイクル管理 Enterprise の認証とプロビジョニングを構成するとき、パートナー IdP を使用するか、ID 管理システムの別の組み合わせを使用できます。 * [パートナー ID プロバイダーの使用](#using-a-partner-identity-provider) * [他の ID 管理システムの使用](#using-other-identity-management-systems) ### パートナー ID プロバイダーの使用 各パートナー IdP は、SSO とユーザー ライフサイクル管理の両方を実装する"舗装されたパス"アプリケーションを提供します。 GitHub では、構成を簡略化するために、認証とプロビジョニングの両方に 1 つのパートナー IdP アプリケーションを使うことを推奨しています。 パートナー IdP の詳細と一覧については、「[Enterprise Managed Users について](/ja/enterprise-cloud@latest/admin/identity-and-access-management/understanding-iam-for-enterprises/about-enterprise-managed-users#identity-management-systems)」をご覧ください。 パートナー IdP を使った SCIM プロビジョニングの構成について詳しくは、「[Provisioning users and groups with SCIM using the REST API](/ja/enterprise-cloud@latest/admin/identity-and-access-management/provisioning-user-accounts-for-enterprise-managed-users/configuring-scim-provisioning-for-enterprise-managed-users)」をご覧ください。 ### 他の ID 管理システムの使用 移行のオーバーヘッド、ライセンス コスト、または organization の慣性といった理由により、認証とプロビジョニングの両方に 1 つのパートナー IdP を使用できない場合は、別の ID 管理システム、または複数のシステムの組み合わせを使用できます。 システムは、SAML を使用した認証と SCIM を使用したユーザー ライフサイクル管理を提供し、GitHubの統合ガイドラインに従う必要があります。 GitHub は、認証とプロビジョニングのためにパートナー IdP の混在を明示的にサポートしていません。また、すべての ID 管理システムをテストしていません。 **GitHub のサポート チームは、混合または未テストのシステムに関連する問題を支援できない場合があります。** ヘルプが必要な場合は、システムのドキュメント、サポート チーム、またはその他のリソースを参照する必要があります。 > \[!IMPORTANT] SSO と SCIM に対する **Okta と Entra ID** の組み合わせ (順序は問いません) は、明示的に**サポートされていません**。 この組み合わせが構成されている場合、GitHub の SCIM API から、プロビジョニングの試行時に ID プロバイダーにエラーが返されます。 ## 前提条件 * GitHub Enterprise Cloud の使用を開始するときは、マネージド ユーザーを含む Enterprise を作成することを選んでいる必要があります。 詳しくは、「[GitHub Enterprise Cloud におけるエンタープライズ種別の選択](/ja/enterprise-cloud@latest/admin/identity-and-access-management/understanding-iam-for-enterprises/identifying-the-best-authentication-method-for-your-enterprise)」をご覧ください。 * プロビジョンニングを構成する前に、ユーザーに認証を構成する必要があります。 この構成は、ID 管理システムと GitHub の両方でセットアップする必要があります。 詳しくは、「[Enterprise Managed User の認証を構成する](/ja/enterprise-cloud@latest/admin/identity-and-access-management/configuring-authentication-for-enterprise-managed-users)」をご覧ください。 * Enterprise にオープンの SCIM 構成を有効にする必要があります。 詳しくは、「[Provisioning users and groups with SCIM using the REST API](/ja/enterprise-cloud@latest/admin/identity-and-access-management/provisioning-user-accounts-for-enterprise-managed-users/configuring-scim-provisioning-for-enterprise-managed-users#configuring-provisioning-for-other-identity-management-systems)」をご覧ください。 * SCIM の REST API エンドポイントへの要求を認証するには、エンタープライズの設定ユーザーに関連付けられた personal access token (classic) を使用する必要があります。 トークンには **scim:enterprise** スコープが必要です。 GitHubは、トークンに有効期限を構成しないことをお勧めします。 「[Enterprise Managed Users の概要](/ja/enterprise-cloud@latest/admin/managing-iam/understanding-iam-for-enterprises/getting-started-with-enterprise-managed-users#create-a-personal-access-token)」を参照してください。\* GitHubの REST API でユーザーとグループをプロビジョニングするには、ID 管理システムが SCIM 2.0 規格をサポートしている必要があります。 詳細については、IETF Web サイトにある次の RFC を参照してください * [RFC 7642: 定義、概要、概念、要件](https://tools.ietf.org/html/rfc7642) * [RFC 7643: コア スキーマ](https://tools.ietf.org/html/rfc7643) * [RFC 7644: プロトコル](https://tools.ietf.org/html/rfc7644) * 認証とプロビジョニングに使用するシステムのユーザー レコードは、一意の識別子を共有し、GitHub の一致条件を満たす必要があります。 詳細については、REST API ドキュメントの「[SCIM の REST API エンドポイント](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#mapping-of-saml-and-scim-data)」を参照してください。 ## GitHub の REST API を使った SCIM プロビジョニングのベスト プラクティス GitHub でユーザーまたはユーザーのグループをプロビジョニングするように ID 管理システムを構成する場合、GitHub では、次のガイドラインに従うことを強くお勧めします。 * [ID 管理システムが書き込み操作の唯一のソースであることを確認する](#ensure-your-identity-management-system-is-the-only-source-of-write-operations) * [REST API エンドポイントに有効な要求を送信する](#send-valid-requests-to-rest-api-endpoints) * [グループをプロビジョニングする前にユーザーをプロビジョニングする](#provision-users-before-you-provision-groups) * [GitHub のグループにアクセスを検証する](#validate-access-for-groups-on-github) * [GitHub のレート制限を理解する](#understand-rate-limits-on-github) * [監査ログ ストリーミングを構成する](#configure-audit-log-streaming) * [SCIM トークンのスコープを制限する](#limit-the-scope-of-the-scim-token) * [プロビジョニング解除の影響を理解する](#understand-the-effects-of-deprovisioning) ### ID 管理システムが書き込み操作の唯一のソースであることを確認する 環境に信頼できる唯一の情報源があることを確認するには、ID 管理システムから SCIM プロビジョニング用に REST API にのみプログラムで書き込む必要があります。 GitHubは、1 つのシステムのみが API に“`POST`“、“`PUT`“、“`PATCH`“、“`DELETE`“要求を送信することを強くお勧めします。 ただし、スクリプトの“`GET`“要求または Enterprise 所有者によるアドホック要求を使用し、GitHubの API から、情報を安全に取得できます。 > \[!WARNING] > SCIM プロビジョニングにパートナー IdP を使用する場合、IdP のアプリケーションが API への書き込み要求を行う唯一のシステムである必要があります。 “`POST`“、“`PUT`“、“`PATCH`“、“`DELETE`“メソッドを使用してアドホック要求を行った場合、後続の同期試行は失敗してプロビジョニングが Enterprise に対して正しく機能しません。 ### REST API エンドポイントに有効な要求を送信する SCIM でユーザーをプロビジョニングするGitHubの REST API エンドポイントには、適格な要求が必要です。 次のガイドラインに注意してください。 * REST API の期待に一致しない要求は、“`400 Bad Request`“エラーを返します。 * SCIM でユーザーをプロビジョニングする REST API エンドポイントには、`User-Agent` ヘッダーが必要です。 このヘッダーのない要求は、GitHub によって拒否されます。 * 自社が GHE.com 上にある場合は、`api.SUBDOMAIN.ghe.com` で自社のエンドポイントに API 要求を送信してください。 ### グループをプロビジョニングする前にユーザーをプロビジョニングする SCIM グループは、大規模なユーザー アクセスの管理に効果的です。 たとえば、ID 管理システムのグループを使って、GitHub のチームと organization メンバーシップを管理できます。 ID 管理システムでグループを持ったチーム メンバーシップを管理するには、順序に従って次の手順を完了する必要があります。 1. GitHub 上にユーザー アカウントをプロビジョニングします。 2. GitHub 上にグループをプロビジョニングします。 3. ID 管理システムのグループのメンバーシップを更新します。 4. ID 管理システム上のグループにマップされたチームを GitHub に作成します。 ### GitHub 上のグループのアクセスを検証する ID 管理システムのグループを使用してアクセスを管理している場合、任意でユーザーが必要なアクセス権を取得することを検証できます。 REST API を使用し、システムのグループ メンバーシップをGitHubがそれらのグループに対する解釈と比較できます。 詳しくは、「[外部グループの REST API エンドポイント](/ja/enterprise-cloud@latest/rest/teams/external-groups#about-external-groups)」と「[チームの REST API エンドポイント](/ja/enterprise-cloud@latest/rest/teams/teams#get-a-team-by-name)」 (REST API ドキュメント) をご覧ください。 ### GitHub のレート制限を理解する プラットフォームの可用性と信頼性を確保するため、GitHubはレート制限を実装します。 レート制限を考慮しない場合、初めてEnterprise Managed Usersで大企業がオンボーディングを行うと、制限を超える可能性があります。 GitHub のレート制限を超えないようにするには、IdP の SCIM 統合に 1 時間あたり 1,000 人を超えるユーザーを割り当てないでください。 グループを使って IdP アプリケーションにユーザーを割り当てる場合、1 時間あたり 1,000 人を超えるユーザーを各グループに追加しないでください。 これらのしきい値を超えると、ユーザーをプロビジョニングしようとすると、"レート制限" エラーが発生して失敗する可能性があります。 試した SCIM プロビジョニングまたはプッシュ操作がレート制限エラーに起因して失敗したかは IdP ログで確認できます。 プロビジョニング失敗に対する反応は IdP によって異なります。 詳しくは、「[REST API のレート制限](/ja/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api)」をご覧ください。 ### 監査ログ ストリーミングを構成する エンタープライズの監査ログには、エンタープライズでのアクティビティに関する詳細が表示されます。 監査ログを使用して、SCIM の構成をサポートできます。 詳しくは、「[企業の監査ログ](/ja/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterprise)」をご覧ください。 このログのイベント量により、GitHub ではデータを 180 日間保持します。 監査ログ データを失わないようにするため、また監査ログ内のアクティビティをより詳細に表示するには、GitHub で監査ログ ストリーミングを構成することをお勧めします。 監査ログをストリーミングするとき、SCIM プロビジョニングの REST API エンドポイントへの要求など、必要に応じて API 要求のイベントをストリーミングできます。 詳しくは、「[企業の監査ログのストリーミング](/ja/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise)」をご覧ください。 ### SCIM トークンのスコープを制限する セキュリティ態勢を向上させるために、SCIM 呼び出しを行うために必要な REST API エンドポイントへのトークンのアクセスを制限するには、`scim:enterprise` スコープのみを持つ personal access token (classic) を使用することをお勧めします。 現在、`admin:enterprise` スコープのトークンを使用している場合は、このトークンが Enterprise 上のすべてのアクションへのアクセス権を付与していることに注意してください。 中断することなく、`scim:enterprise` スコープだけでトークンを新しいトークンにスワップできます。 ### プロビジョニング解除の影響を理解する ユーザーを GitHub にアクセスできないようにするには、"論理的なプロビジョニング解除" または "物理的なプロビジョニング解除" の要求を SCIM プロバイダーに送信します。 物理的なプロビジョニング解除は元に戻せないアクションであり、ユーザーの GitHub アカウントは完全に一時停止されます。 API 統合を実装する前に、プロビジョニング解除の種類とその影響を理解しておく必要があります。 プロビジョニング解除のさまざまな種類、その影響、生成される監査ログ イベントについては、「[SCIM を使用したユーザーのプロビジョニング解除と復帰](/ja/enterprise-cloud@latest/admin/managing-iam/provisioning-user-accounts-with-scim/deprovisioning-and-reinstating-users)」をご覧ください。 ## REST API でユーザーのプロビジョニング ユーザーをプロビジョニング、リスト、管理するには、次の REST API エンドポイントに要求を行います。 関連付けられた API エンドポイントについては、REST API ドキュメントを参照してコード例を確認してください。また、各要求に関連付けられた監査ログ イベントも確認できます。 ID 管理システム上の ID を持つユーザーが企業にサインインできるようにするには、対応するユーザーを作成する必要があります。 Enterprise は、新規のユーザー アカウントをプロビジョニングするために利用可能なライセンスは必要ありません。 * ユーザーに対してサポートされている属性の概要については、REST API ドキュメントの [SCIM](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#supported-scim-user-attributes) に関するページをご覧ください。 * プロビジョニングされたユーザーは、GitHub UI で確認できます。 詳しくは、「[企業内の従業員を表示する](/ja/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-people-in-your-enterprise)」をご覧ください。 | アクション | メソッド | エンドポイントとその他の情報 | 監査ログのイベント | | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | エンタープライズにプロビジョニングされたすべてのユーザーをリストし、これには`active` を `false` に設定してソフトディプロビジョニングされたすべてのユーザーが含まれます。 | `GET` | [`/scim/v2/enterprises/{enterprise}/Users`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#list-scim-provisioned-identities-for-an-enterprise) | 該当なし | | ユーザーを作成します。 API の応答には、ユーザーを一意に識別するために `id` フィールドが含まれています。 | `POST` | [`/scim/v2/enterprises/{enterprise}/Users`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#provision-a-scim-enterprise-user) | | | ユーザーを作成するために送信した `id` 要求の `POST` フィールドを使用し、Enterprise の既存ユーザーを回収します。 | `GET` | [`/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#get-scim-provisioning-information-for-an-enterprise-user) | 該当なし | | ユーザーを作成するために送信した `id` 要求の `POST` フィールドを使用し、既存ユーザーのすべての属性を更新します。 “`active`“を“`false`“に更新してユーザーを論理的にプロビジョニング解除するか、“`true`“に更新してユーザーを再度有効にします。 詳細については、「[REST API でユーザーを論理的にプロビジョニング解除する](#soft-deprovisioning-users-with-the-rest-api)」と「[REST API でユーザーを再度有効にする](#reactivating-users-with-the-rest-api)」を参照してください。 | `PUT` | [`/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#set-scim-information-for-a-provisioned-enterprise-user) | | | ユーザーを作成するために送信した `id` 要求の `POST` フィールドを使用し既存ユーザーの個々の属性を更新します。 “`active`“を“`false`“に更新してユーザーを論理的にプロビジョニング解除するか、“`true`“に更新してユーザーを再度有効にします。 詳細については、「[REST API でユーザーを論理的にプロビジョニング解除する](#soft-deprovisioning-users-with-the-rest-api)」と「[REST API でユーザーを再度有効にする](#reactivating-users-with-the-rest-api)」を参照してください。 | `PATCH` | [`/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#update-an-attribute-for-a-scim-enterprise-user) | | | 既存のユーザーを完全に一時停止するには、ユーザーを物理的にプロビジョニング解除できます。 ハードウエア上のプロビジョニング解除後、ユーザーを再度有効にすることはできません。ユーザーを新規ユーザーとしてプロビジョニングする必要があります。 詳しくは、「[REST API でユーザーを完全にプロビジョニング解除する](#hard-deprovisioning-users-with-the-rest-api)」をご覧ください。 | `DELETE` | [`/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#delete-a-scim-user-from-an-enterprise) | | ## REST API でユーザーの暫定的なプロビジョニング解除 ユーザーがエンタープライズにアクセスしてログインすることを防止するために、`PUT` または `PATCH` 要求を `active` 宛に送信してユーザーの `false` フィールドを `/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}` に更新することで、ユーザーを仮のプロビジョニング解除することができます。 ユーザーを論理的にプロビジョニング解除すると、GitHub によってユーザー レコードの `login` と `email` の各フィールドが難読化され、ユーザーは一時停止されます。 ## REST API でユーザーを再度有効にする 仮のプロビジョニング解除されたユーザーがエンタープライズにアクセスできるようにするには、`PUT` または `PATCH` 要求を `/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}` 宛に送信してユーザーの `active` フィールドを `true` に更新することで、ユーザーを停止解除します。 ## REST API でユーザーの強制デプロビジョニングを行う > \[!IMPORTANT] 物理的なプロビジョニング解除は元に戻せないアクションであり、ユーザーの GitHub アカウントは完全に一時停止されます。 「[プロビジョニング解除の影響を理解する](#understand-the-effects-of-deprovisioning)」をご覧ください。 ユーザーを物理的にプロビジョニング解除するには、`DELETE` 要求を `/scim/v2/enterprises/{enterprise}/Users/{scim_user_id}` に送信します。 Enterprise は、ユーザーが作成したすべてのリソースとコメントを保持します。 ## REST API でグループのプロビジョニング Enterprise のリポジトリへのアクセスを管理するには、ID 管理システムのグループを使用して Enterprise のユーザーに対して組織とチームのメンバーシップを管理できます。 関連付けられた API エンドポイントについては、REST API ドキュメントを参照してコード例を確認してください。また、各要求に関連付けられた監査ログ イベントも確認できます。 エンタープライズでは、新しいユーザー アカウントをプロビジョニングするために使用可能なライセンスは必要ありませんが、組織にユーザーが追加されるグループをプロビジョニングする場合は、それらのユーザーに対して使用可能なライセンスが必要です。 エンタープライズで Visual Studio を持つ GitHub Enterprise サブスクリプション のみを使用している場合は、関連付けられているユーザーをサブスクライバーに割り当てる必要があります。 詳細については、「[GitHub Enterprise でのVisual Studio サブスクリプションについて](/ja/enterprise-cloud@latest/billing/managing-billing-for-your-products/managing-licenses-for-visual-studio-subscriptions-with-github-enterprise/about-visual-studio-subscriptions-with-github-enterprise#about-licenses-for-visual-studio-subscriptions-with-github-enterprise)」を参照してください。 * グループでサポートされている属性の概要については、REST API ドキュメントの [SCIM](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#supported-scim-group-attributes) に関するページをご覧ください。 * グループに関連する監査ログ イベントの概要については、「[企業向け監査ログイベント](/ja/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise#external_group)」をご覧ください。 * プロビジョニングされたグループは、GitHub UI で確認できます。 詳しくは、「[ID プロバイダー グループを使用したチーム メンバーシップの管理](/ja/enterprise-cloud@latest/admin/identity-and-access-management/provisioning-user-accounts-for-enterprise-managed-users/managing-team-memberships-with-identity-provider-groups#viewing-idp-groups-group-membership-and-connected-teams)」をご覧ください。 | アクション | メソッド | エンドポイントとその他の情報 | 監査ログの関連イベント | | :------------------------------------------------------------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Enterprise に定義されたすべてのグループをリストします。 | `GET` | [`/scim/v2/enterprises/{enterprise}/Groups`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#list-provisioned-scim-groups-for-an-enterprise) | 該当なし | | Enterprise に新しい IdP グループを定義するには、グループを作成します。 API の応答には、グループを一意に識別する `id` フィールドが含まれています。 | `POST` | [`/scim/v2/enterprises/{enterprise}/Groups`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#provision-a-scim-enterprise-group) | | | グループを作成するために送信した `id` 要求から返された `POST` を使用し、エンタープライズに対応する既存グループを取得します。 | `GET` | [`/scim/v2/enterprises/{enterprise}/Groups/{scim_group_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#get-scim-provisioning-information-for-an-enterprise-group) | 該当なし | | 既存グループのすべての属性を更新します。 | `PUT` | [`/scim/v2/enterprises/{enterprise}/Groups/{scim_group_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#set-scim-information-for-a-provisioned-enterprise-group) | | | 既存グループの個々の属性を更新します。 | `PATCH` | [`/scim/v2/enterprises/{enterprise}/Groups/{scim_group_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#update-an-attribute-for-a-scim-enterprise-group) | | | 既存グループを完全に削除します。 | `DELETE` | [`/scim/v2/enterprises/{enterprise}/Groups/{scim_group_id}`](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#delete-a-scim-group-from-an-enterprise) | | ### IdP グループへの変更に関する追加の監査ログ イベント ``` `PUT` または `PATCH` 要求を使って既存のグループのメンバーを `/scim/v2/enterprises/{enterprise}/Groups/{scim_group_id}` に更新すると、ユーザーの現在の organization メンバーシップに応じて、GitHub によってユーザーが organization に追加される場合や、organization から削除される場合があります。 ユーザーが既に組織内で少なくとも 1 つのチームのメンバーである場合、そのユーザーは組織のメンバーです。 ユーザーが組織内のチームのメンバーではない場合、そのユーザーはまだ組織のメンバーでもない可能性があります。 ``` お客様の要求が、ユーザーがまだメンバーになっていない organization (組織) 内のチームに対してリンクされたグループを更新した場合、`external_group.update` に加えて、以下のイベントが監査ログの中に表示されます。 * `org.add_member` * ユーザーがまだメンバーではない組織内のチームにリンクされたグループにユーザーを追加する要求がある場合、`org.add_member` * 要求が、組織のチームにリンクされたグループにユーザーを追加した場合、`team.add_member` 要求は、ユーザーが既にメンバーである組織のチームにリンクされたグループを更新した場合、`external_group.update` に加えて、次のイベントが監査ログに表示されます。 * 要求が組織のチームにリンクされたグループからユーザーを削除し、そのチームがその組織の中でユーザーがメンバーである最後のチームではない場合、`team.remove_member` * ユーザーが既にメンバーになっている organization (組織) の中で、要求が、その organization (組織) 内に存在する最後のチームにリンクされているグループからそのユーザーを削除する場合`org.remove_member` これらのステップを実行してください： ## 新しい SCIM プロバイダーへの移行 Enterprise の SCIM プロビジョニングを構成した後、新しい SCIM プロバイダーへの移行が必要になる場合があります。 詳しくは、「[新しい ID プロバイダーまたはテナントへの Enterprise の移行](/ja/enterprise-cloud@latest/admin/identity-and-access-management/reconfiguring-iam-for-enterprise-managed-users/migrating-your-enterprise-to-a-new-identity-provider-or-tenant)」をご覧ください。 ## SCIM プロビジョニングのトラブルシューティング * REST API への要求がレート制限される場合は、「[GitHub のレート制限を理解する](#understand-rate-limits-on-github)」をご覧ください。 * 成功した HTTP `GET` 要求を除き、GitHub が受信するすべての SCIM 要求により、[監査ログ](/ja/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise#external_identity) イベントが生成されます。 これらのログには、要求の結果、ペイロード情報、エラーに関する有用な情報が含まれます。 これらのログを使って、GitHub が SCIM 要求を受信したかどうかを判断し、API エラーのトラブルシューティングすることができます。 * ユーザーがプロビジョニングされているかどうかを確認するには、次の監査ログ クエリを使用できます: `action:external_identity.provision user:USERNAME_SHORTCODE` * 上記のクエリを使ってもユーザーが見つからない場合は、要求を受信したと思われる日付の `action:external_identity.scim_api_failure` イベントを検索することをお勧めします。 * SCIM 要求が失敗して原因を特定できない場合、ID 管理システムの状態をチェックしてサービスが利用可能だったことを確認します。 さらに、GitHub の状態ページを確認します。 詳細については、「[GitHub サポートについて](/ja/enterprise-cloud@latest/support/learning-about-github-support/about-github-support#about-github-status)」を参照してください。 * ユーザーをプロビジョニングする要求が `400` エラーで失敗し、ID 管理システムのログのエラー メッセージでアカウントの所有権またはユーザー名の書式設定に関する問題が示されている場合は、「[外部認証のユーザー名に関する考慮事項](/ja/enterprise-cloud@latest/admin/identity-and-access-management/iam-configuration-reference/username-considerations-for-external-authentication)」を確認してください。 * 認証が成功すると、GitHub により、認証されたユーザーは SCIM によってプロビジョニングされた ID にリンクされます。 認証とプロビジョニングの一意の識別子が一致している必要があります。 詳しくは、「[SCIM の REST API エンドポイント](/ja/enterprise-cloud@latest/rest/enterprise-admin/scim#mapping-of-saml-and-scim-data)」をご覧ください。このマッピングは、GitHub で確認することもできます。 [「AUTOTITLE」](/ja/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-and-managing-a-users-saml-access-to-your-enterprise#viewing-and-revoking-a-linked-identity)を参照してください。 * ID 管理システム上のグループを使ってアクセスを管理する場合は、REST API または GitHub の Web UI を使ってトラブルシューティングすることができます。 * REST API を使用し、ID 管理システムのグループ メンバーシップをGitHubのそれらのグループに対する解釈と比較できます。 「[外部グループの REST API エンドポイント](/ja/enterprise-cloud@latest/rest/teams/external-groups#about-external-groups)」と「[チームの REST API エンドポイント](/ja/enterprise-cloud@latest/rest/teams/teams#get-a-team-by-name)」を参照してください。 * Web UI を使ったトラブルシューティングについて詳しくは、「[ID プロバイダー グループを使用したチーム メンバーシップのトラブルシューティング](/ja/enterprise-cloud@latest/admin/identity-and-access-management/provisioning-user-accounts-for-enterprise-managed-users/troubleshooting-team-membership-with-identity-provider-groups)」をご覧ください。 トラブルシューティングのその他の提案については、「[Enterprise のアイデンティティおよびアクセス管理のトラブルシューティング](/ja/enterprise-cloud@latest/admin/identity-and-access-management/understanding-iam-for-enterprises/troubleshooting-identity-and-access-management-for-your-enterprise#scim-provisioning-errors)」をご覧ください。