Microsoft Entra IDでGitHub Enterprise Managed User（EMU）の自動ユーザープロビジョニングを使う場合、最初に確認すべき結論は「対象がEMUであること」「SAML SSOとSCIMの前提が整っていること」「小さな範囲で同期を検証してから本番展開すること」です。今回の公式情報は、GitHub EMUに対してMicrosoft Entra IDからユーザーとグループを自動作成・更新・無効化するための設定手順を整理したものです。公式ページは2026年5月26日に更新されており、管理者は変更点だけでなく、トークン、スコープ、属性マッピング、削除防止、監視ログまで確認しておく必要があります。(Microsoft Learn)
特に注意したいのは、この手順が通常のGitHub Enterprise Account向けではなく、GitHub Enterprise Managed User向けである点です。Microsoft Learnでも、EMUは通常のGitHub Enterprise Accountとは異なる種類であり、該当しない場合は別のプロビジョニング手順を参照するよう案内されています。既存のGitHub Enterprise環境にそのまま適用できるとは限らないため、設定前に自社のGitHub契約形態とID管理方式を確認しましょう。(Microsoft Learn)
Microsoft Entraのセキュリティ更新として確認すべき影響範囲
今回の内容は、CVE対応のような脆弱性修正というより、Microsoft Entra IDとGitHub Enterprise Managed Userを連携する際のIDライフサイクル管理を安全に運用するための設定確認と捉えるのが実務的です。
Microsoft Entraのプロビジョニングサービスを設定すると、GitHub Enterprise Managed Userに対して以下の処理を自動化できます。公式情報では、ユーザー作成、不要になったユーザーの削除、ユーザー属性の同期、グループとグループメンバーシップのプロビジョニング、SSO、長期Bearerトークン認証のサポートが示されています。(Microsoft Learn)
| 確認対象 | 影響を受ける人 | 確認すべき内容 |
|---|---|---|
| Microsoft Entra ID管理者 | エンタープライズアプリ、割り当て、属性マッピングの管理者 | GitHub EMU用アプリ、プロビジョニングスコープ、削除防止、通知メール |
| GitHub Enterprise管理者 | EMU、SAML SSO、SCIM設定の管理者 | Tenant URL、SCIMトークン、setup user、組織・チーム管理方針 |
| セキュリティ担当者 | 退職者・異動者のアクセス削除を管理する担当者 | 無効化・削除時の挙動、監査ログ、隔離状態、トークン管理 |
| 開発チーム責任者 | GitHub上のチームやリポジトリアクセスを運用する担当者 | グループ同期、ネストされたグループの扱い、メールアドレス変更の影響 |
Microsoft Entra IDのアプリプロビジョニングは、SaaSアプリ側にユーザーIDやロールを自動作成し、ユーザーの状態やロール変更に応じてIDの保守・削除も行う仕組みです。手作業のアカウント作成や退職者削除に依存している環境ほど、設定ミスがセキュリティリスクにつながりやすくなります。(Microsoft Learn)
2026年5月26日の公式更新で見ておきたい変更点
公開履歴から確認できる主な更新点は、2026年5月26日にドキュメントの日付が更新され、同日にnational cloudsの記載が共通includeに置き換えられていることです。GitHub上の履歴では、ms.dateが03/09/2026から05/26/2026へ変更され、national cloudの表がinclude参照に変更されています。(GitHub)
また、直前の2026年5月18日の変更では、Capabilities Supportedに「Long lived bearer token authentication supported.」が追加されています。現在のMicrosoft Learn上でも、GitHub Enterprise Managed Userの対応機能として長期Bearerトークン認証のサポートが掲載されています。(GitHub)
| 変更・確認ポイント | 実務上の意味 | 管理者が取るべき対応 |
|---|---|---|
| 更新日が2026年5月26日に変更 | 公式手順として参照すべき最新版であることを確認できる | 古い手順書や社内Runbookとの差分を確認する |
| national cloudの記載整理 | 利用可能なクラウド環境を確認する重要性が高い | Global、US Government、China operated by 21Vianetの対応状況を確認する |
| 長期Bearerトークン対応の記載 | SCIM認証に使うトークンの運用が重要になる | トークンの保管、権限、ローテーション、失効手順を決める |
| + New configurationを使う構成手順 | Entra管理センターのUIに沿った設定が前提 | 旧UI前提の社内手順を見直す |
| 削除防止と通知メールの設定 | 誤った大量削除や同期異常に気づくための保険 | 本番開始前に必ず有効化し、通知先を共有メールにする |
national cloudについて、Microsoft Learnの該当ページではGlobal serviceとUS Governmentにチェックがあり、China operated by 21Vianetは空欄として表示されています。一方で、GitHub DocsではGovernment Cloud環境におけるIdPギャラリーアプリの検証・サポート範囲に注意する記載もあります。米国政府系クラウドで使う場合は、Microsoft側の対応状況だけでなく、GitHub側のサポート範囲も事前に確認してください。(Microsoft Learn)
自動プロビジョニングで実現できること
この連携の目的は、Microsoft Entra IDを起点にGitHub Enterprise Managed Userのユーザーライフサイクルを自動化することです。設定後は、Microsoft EntraプロビジョニングサービスがGitHub EMUに対してユーザーやグループを作成し、不要になったユーザーやグループを削除または無効化し、属性を同期します。(Microsoft Learn)
実務では、次のような場面で効果があります。
| シーン | 手作業運用の課題 | 自動プロビジョニングの効果 |
|---|---|---|
| 新入社員・新規開発者の参加 | GitHubアカウント作成やチーム追加が遅れる | Entra IDの割り当てに基づいてGitHub側へ反映できる |
| 部署異動・プロジェクト変更 | 古いリポジトリアクセスが残りやすい | グループや属性の変更に応じてアクセス管理を更新しやすい |
| 退職・契約終了 | GitHub側の削除漏れが発生しやすい | Entra ID側の無効化・割り当て解除を起点にアクセスを外せる |
| 監査対応 | 誰がいつ作成・削除されたか追跡しづらい | プロビジョニングログで作成、更新、削除、無効化の状態を確認できる |
GitHub側のEMUでは、IdPがユーザーアカウントをプロビジョニングし、ユーザーはIdPで認証してGitHubのエンタープライズリソースにアクセスします。ユーザー名、プロフィールデータ、組織メンバーシップ、リポジトリアクセスもIdP側から管理する設計です。(GitHub Docs)
設定前に満たすべき前提条件
Microsoft Learnの手順では、Microsoft Entraテナント、Application Administrator・Cloud Application Administrator・Application Ownerのいずれかのロール、Microsoft Entraテナントを使ったSAML SSO設定済みのGitHub Enterprise Managed Users環境が前提とされています。(Microsoft Learn)
特に重要なのは、GitHub.comとGHE.comでTenant URLが異なる点です。公式手順では、GitHub.comの場合は次の形式を使います。
GHE.comの場合は次の形式です。
Secret Tokenには、enterpriseのsetup userで作成したscim:enterpriseスコープ付きトークンを入力します。Tenant URLやトークンが誤っていると、Test Connectionや初回同期で失敗します。(Microsoft Learn)
前提確認チェックリスト
| 確認項目 | OKの判断基準 | よくある失敗 |
|---|---|---|
| GitHubの種類 | GitHub Enterprise Managed Userである | 通常のGitHub Enterprise AccountにEMU用手順を適用しようとする |
| SSO方式 | Microsoft EntraテナントでSAML SSOが構成済み | OIDC用チュートリアルとSAML用チュートリアルを混同する |
| Entra管理者権限 | Cloud Application Administratorなど必要なロールがある | 権限不足でProvisioning設定や属性マッピングを変更できない |
| Tenant URL | GitHub.comまたはGHE.comに合うSCIM URLを使う | {enterprise}や{subdomain}を誤って入力する |
| Secret Token | scim:enterpriseスコープ付きトークンを使う | 個人用トークンのスコープ不足、期限切れ、保管場所不明 |
| 通知先 | 隔離や失敗通知を受け取れるメールアドレスを設定 | 個人メールだけを設定し、担当変更後に通知を見落とす |
設定手順は「小さく検証してから開始」が基本
公式手順では、まずプロビジョニング展開を計画し、誰をプロビジョニング対象にするか、どのデータをMicrosoft Entra IDとGitHub Enterprise Managed Userの間でマッピングするかを決める流れになっています。その後、アプリケーションギャラリーからGitHub Enterprise Managed Userを追加し、対象ユーザーやグループのスコープを定義します。(Microsoft Learn)
本番運用で安全に進めるなら、次の順序で進めるのが現実的です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 計画 | 対象ユーザー、グループ、属性、除外条件を決める | 「誰がGitHubに作成されるか」を説明できる |
| 接続準備 | Tenant URLとSecret Tokenを用意する | Test Connectionが成功する |
| パイロット | 1〜2名または小規模グループで検証する | GitHub側に想定通り作成・更新される |
| 属性確認 | userName、externalId、email、displayNameなどを確認する | 重複、空値、意図しない変更がない |
| 削除検証 | 割り当て解除や無効化時の挙動を確認する | 退職・異動時の運用手順が明確になる |
| 本番開始 | Start Provisioningを実行する | ログ、進行状況、通知先を監視できる |
公式手順でも、最初から全社展開せず、小さなユーザーやグループでテストしてから範囲を広げることが推奨されています。スコープを「assigned users and groups」にすれば、対象者をアプリへの割り当てで制御できます。(Microsoft Learn)
スコープ設計で失敗しやすいポイント
プロビジョニングのスコープは、ユーザーやグループの割り当て、または属性ベースのスコープフィルターで制御します。Microsoft Entra IDがソースシステムの場合、ユーザーとグループの割り当てで対象を決める方法が一般的で、同期対象が多いほど同期に時間がかかるため、対象を絞ることが推奨されています。(Microsoft Learn)
注意すべきなのは、スコープフィルターを保存すると新しいフル同期が開始される点です。以前は対象内だったユーザーがフィルター変更によって対象外になると、アプリ側で無効化またはデプロビジョニングされる可能性があります。条件を少し変えるだけでも影響が大きいため、本番環境では事前に対象者リストを確認してから保存しましょう。(Microsoft Learn)
スコープフィルターでは、単一フィルター内の複数句はAND、複数フィルターはORとして評価されます。また、IsMemberOf、グループのmembers属性、複数値属性のフィルタリングはサポートされていないため、グループ条件を複雑に組みすぎる設計は避けるべきです。(Microsoft Learn)
おすすめのスコープ設計例
| 段階 | 対象 | 設計例 |
|---|---|---|
| 検証 | IT管理者と数名の開発者 | github-emu-pilotのような検証用グループを割り当てる |
| 部門展開 | 特定部門の開発者 | 部門グループを割り当て、必要に応じて属性フィルターを追加する |
| 全社展開 | GitHub利用対象者全体 | 全員ではなく、GitHub利用者グループを明示的に管理する |
| 除外管理 | 休職者、外部委託、監査用アカウント | Entra ID側の属性や専用グループで除外条件を定義する |
「全社員を同期してからGitHub側で権限を絞る」よりも、「GitHubを使う人だけをEntra ID側で対象にする」方が、安全で監査しやすい設計になります。
属性マッピングで確認すべき項目
公式手順では、Attribute Mappingでユーザー属性とグループ属性を確認し、更新処理で使うMatching propertyを確認するよう案内されています。Matching target attributeを変更する場合は、GitHub Enterprise Managed User APIがその属性でフィルタリングできることを確認する必要があります。(Microsoft Learn)
現在の公式ページでは、ユーザーとグループの両方でexternalIdがフィルタリング対応として示されています。一方、userName、displayName、emails[type eq "work"].valueなどは同期属性として表示されていますが、フィルタリング対応欄にはチェックがありません。(Microsoft Learn)
| 属性 | 用途 | 注意点 |
|---|---|---|
externalId | Entra IDとGitHub側アカウントの照合 | Matching propertyとして特に慎重に扱う |
userName | GitHub側ユーザー名に関わる属性 | 変更や重複があるとユーザー体験に影響しやすい |
active | 有効・無効状態 | 退職、休職、割り当て解除の運用ルールと合わせる |
displayName | 表示名 | 日本語名、英字名、表記揺れを事前に確認する |
emails[type eq "work"].value | 業務用メールアドレス | メール変更時の影響を開発者へ説明しておく |
group displayName | GitHub側グループ表示 | チーム名・部署名の命名規則と合わせる |
group members | グループメンバーシップ | Entra IDのネストされたグループには注意する |
GitHub Docsでは、EMUのプロフィール名とメールアドレスはIdPから提供され、管理対象ユーザーはGitHub上でプロフィール名やメールアドレスを変更できないと説明されています。また、IdP側でユーザーのメールアドレスを変更すると、古いメールアドレスに関連付いたコントリビューション履歴との紐づきが外れる可能性があります。開発者への影響が大きいため、メールアドレス変更の運用ルールは事前に周知しましょう。(GitHub Docs)
さらに、GitHub DocsではEntra IDがネストされたグループのプロビジョニングをサポートしないことも明記されています。GitHubのチームやリポジトリアクセスをグループで自動管理する場合は、ネスト構造に依存せず、同期対象のフラットなグループを用意するのが安全です。(GitHub Docs)
トークン管理は「動けばよい」で終わらせない
今回の公式手順では、Secret Tokenとしてscim:enterpriseスコープを持つトークンを使うことが示されています。長期Bearerトークン認証のサポートも記載されていますが、長期トークンは便利な一方で、漏えい時の影響範囲が大きくなります。(Microsoft Learn)
運用では、最低限次のルールを決めておきましょう。
| 項目 | 推奨される運用 |
|---|---|
| 保管場所 | 個人メモやチケット本文ではなく、組織のシークレット管理基盤に保管する |
| 所有者 | 個人ではなく、GitHub EMU管理チームまたはIAM管理チームで管理する |
| ローテーション | 定期変更の頻度と、変更時のTest Connection手順をRunbook化する |
| 失効手順 | 漏えい・退職・管理者変更時に誰がどこで無効化するか決める |
| 監査 | いつ、誰が、どの目的でトークンを更新したか記録する |
長期Bearerトークンに対応していることは、長期間放置してよいという意味ではありません。同期停止を恐れてローテーションしない運用は、結果的に大きなセキュリティリスクになります。
誤削除を防ぐ設定と監視のポイント
公式手順では、プロビジョニング構成を作成した後、Propertiesで通知メールを有効化し、隔離メールを受け取るメールアドレスを設定し、accidental deletions preventionを有効化する流れが示されています。これは本番展開前に必ず確認すべき項目です。(Microsoft Learn)
Microsoft Entraのオンデマンドプロビジョニングは、ユーザーやグループを数秒でプロビジョニングし、構成問題のトラブルシュート、式の検証、スコープフィルターのテストに使えます。いきなりStart Provisioningを押すのではなく、まずオンデマンドプロビジョニングで少数ユーザーを検証しましょう。(Microsoft Learn)
本番開始前の確認手順
| 手順 | 確認内容 | 失敗時に見る場所 |
|---|---|---|
| Test Connection | Tenant URLとSecret TokenでGitHubに接続できるか | Admin credentials、Token、SCIM URL |
| On-demand provisioning | 1名または小規模グループで想定通り同期されるか | Provision on demandの詳細ステップ |
| 属性確認 | GitHub側のユーザー名、表示名、メールが想定通りか | Attribute Mapping |
| 削除防止 | 誤った大量削除を防ぐ設定が有効か | Provisioning Properties |
| 通知 | 隔離やエラー通知が届くか | Notification Email |
| ログ確認 | Create、Update、Disable、Deleteの状態を追えるか | Provisioning logs |
プロビジョニングログでは、Identity、Action、Source System、Target System、Statusなどを確認できます。ActionにはCreate、Update、Delete、Disable、StagedDeleteなどがあり、StatusにはSuccess、Failure、Skipped、Warningが表示されます。(Microsoft Learn)
Quarantine状態を放置しない
Microsoft Entraのプロビジョニングサービスは構成の正常性を監視し、多くの呼び出しが継続的に失敗すると、アプリケーションをquarantine状態にします。quarantine中は増分サイクルの頻度が徐々に下がり、最終的に1日1回になります。4週間を超えてquarantineが続くと、プロビジョニングジョブが無効化されます。(Microsoft Learn)
quarantineの原因としては、認証情報の不正、SCIM準拠の問題、失敗率が高すぎる状態などがあります。Microsoft Learnでは、40%を超えるプロビジョニングイベント失敗や40,000件を超える失敗などが、quarantine判定の例として説明されています。(Microsoft Learn)
quarantineを避けるには、通知メールだけに頼らず、次のような運用を用意しておくと効果的です。
| 監視項目 | 見るべきサイン | 対応 |
|---|---|---|
| 失敗件数の急増 | FailureやWarningが急に増える | 直近の属性変更、グループ変更、トークン変更を確認 |
| Test Connection失敗 | GitHubへの認証に失敗する | Secret Token、Tenant URL、setup userを確認 |
| Skipped増加 | 対象外や条件不一致が増える | スコープフィルターや割り当て条件を見直す |
| DeleteやDisableの増加 | 想定以上のユーザーが無効化される | すぐにスコープ変更履歴と削除防止設定を確認 |
| quarantine通知 | 同期頻度低下やジョブ停止の前兆 | 原因を修正し、次回同期で復旧を確認 |
移行・展開時に注意すべきこと
既存環境からGitHub Enterprise Managed Userへ移行する場合、単にMicrosoft Entra ID側でアプリを追加すれば完了するわけではありません。GitHub EMUは、ユーザーのライフサイクルと認証をIdPから管理する仕組みであり、ユーザーはIdPで認証してGitHubのエンタープライズリソースにアクセスします。(GitHub Docs)
特に、SSOとSCIMで異なるIdPを組み合わせる設計には注意が必要です。GitHub Docsでは、認証とプロビジョニングの両方に単一のpartner IdPを使うと構成を簡素化でき、GitHubのサポート対象としても扱いやすいと説明されています。さらに、OktaとEntra IDをSSOとSCIMで組み合わせる構成は明示的にサポートされていません。(GitHub Docs)
移行時の判断基準
| 判断ポイント | 推奨判断 |
|---|---|
| 既存GitHubアカウントをそのまま使いたい | EMUの制約と移行方式をGitHub側ドキュメントで確認する |
| SAMLとOIDCのどちらを使うか迷う | 今回の手順はSAML前提のGitHub Enterprise Managed User向けとして確認する |
| 複数IdPを使っている | 認証とプロビジョニングのIdPを分けない設計を優先する |
| グループ階層が深い | ネストされたグループに依存しないGitHub同期用グループを作る |
| メールアドレス変更が多い | コントリビューション履歴への影響を事前に説明する |
| 退職者処理を自動化したい | 割り当て解除、無効化、削除防止、ログ確認まで一連の手順にする |
開発者にとって大きいのは、アカウントがIdP管理になる点です。ユーザー名、プロフィール、メールアドレス、所属、アクセス範囲がGitHub上で自由に変更できるものではなくなります。導入前に「何が自動管理されるのか」「どの変更は申請が必要なのか」を開発チームへ共有しておくと、導入後の問い合わせを減らせます。
管理者が今すぐ確認すべき設定チェックリスト
最後に、既存環境と新規導入環境のどちらでも確認しやすいよう、実務用チェックリストに整理します。
| タイミング | 確認項目 | 完了の目安 |
|---|---|---|
| 導入前 | GitHub Enterprise Managed User環境である | 標準GitHub Enterprise向け手順と混同していない |
| 導入前 | SAML SSOがMicrosoft Entraテナントで構成済み | EMUユーザーがIdP認証でGitHubへアクセスできる |
| 導入前 | Tenant URLがGitHub.comまたはGHE.comに合っている | Test Connectionが成功する |
| 導入前 | scim:enterpriseスコープ付きトークンを用意した | Secret Tokenとして安全に登録できる |
| パイロット | 小規模ユーザーでオンデマンドプロビジョニングを実行した | GitHub側のユーザー・属性・グループが想定通り |
| パイロット | スコープフィルターと割り当てを確認した | 意図しないユーザーが対象に入っていない |
| 本番前 | accidental deletions preventionを有効化した | 誤削除対策を設定済み |
| 本番前 | quarantine通知メールを設定した | 個人ではなく運用チームで受信できる |
| 本番後 | provisioning logsを定期確認する | Failure、Warning、Skippedの増減を追える |
| 本番後 | トークン更新手順をRunbook化した | ローテーション時に同期停止を最小化できる |
次に取るべき対応
Microsoft Entra IDとGitHub Enterprise Managed Userの自動プロビジョニングは、GitHubアカウント管理を効率化するだけでなく、退職者や異動者のアクセス削除を確実にするための重要なセキュリティ設定です。一方で、スコープや属性マッピングを誤ると、意図しないユーザー作成、アクセス付与、無効化が発生します。
まずは、自社環境がGitHub Enterprise Managed Userであること、SAML SSOとSCIMの前提が整っていること、Tenant URLとscim:enterpriseトークンが正しいことを確認してください。そのうえで、検証用グループを使ってオンデマンドプロビジョニングを実行し、属性、グループ、削除時の挙動、ログ、通知メールまで確認してから本番展開するのが安全です。
コメント