Microsoft Entra の「Configure GitHub Enterprise Managed User (OIDC) for automatic user provisioning with Microsoft Entra ID」は、GitHub Enterprise Managed Users（EMU）に対して、ユーザーとグループの作成・更新・無効化を Microsoft Entra ID から自動化するための公式手順です。結論から言うと、2026年6月26日の更新履歴は設定手順の大幅変更ではなく、メタデータ整理に近い更新です。ただし、管理者にとって重要なのは、GitHub EMU OIDC 用アプリ、SCIM 用 Tenant URL、scim:enterprise トークン、属性マッピング、スコープ設定、監視設定を正しく見直すことです。特に SAML から OIDC へ移行する組織では、アクセス停止時間やチーム連携への影響を事前に整理しておく必要があります。(GitHub)
Microsoft Entra の「GitHub Enterprise Managed User (OIDC) 自動プロビジョニング」とは
Microsoft Entra の GitHub Enterprise Managed User (OIDC) 自動プロビジョニングは、Microsoft Entra ID のプロビジョニングサービスを使い、GitHub Enterprise Managed Users にユーザーやグループを同期する仕組みです。設定すると、Microsoft Entra ID 側の割り当てや属性に基づいて、GitHub EMU 側のユーザー作成、アクセス不要になったユーザーの削除または無効化、グループとグループメンバーシップの同期を自動化できます。(Microsoft Learn)
ここで混同しやすいのが、OIDC と SCIM の役割の違いです。OIDC は主にサインインや認証を扱い、SCIM はユーザー・グループのライフサイクル管理を扱います。Microsoft Entra のアプリプロビジョニングでは、SCIM がユーザーをアプリへ作成・更新・削除するための標準的な仕組みとして使われます。(Microsoft Learn)
| 項目 | 役割 | 実務上の意味 |
|---|---|---|
| OIDC | GitHub EMU へのシングルサインオン | Entra ID の条件付きアクセスなどを活用しやすい |
| SCIM | ユーザー・グループの作成、更新、削除 | 入退社や異動に合わせて GitHub 側のアカウントを自動管理できる |
| Microsoft Entra プロビジョニングサービス | Entra ID と GitHub EMU の同期処理 | 手動作成やCSV管理を減らし、権限管理の抜け漏れを抑えられる |
2026年6月26日の更新ポイント
2026年6月26日の GitHub 上の更新履歴では、「BULK UPDATE – METADATA ONLY」として、重複する所有者メタデータを削除する一括更新が記録されています。つまり、少なくとも公開されている履歴上は、プロビジョニング手順、Tenant URL、属性マッピング、移行手順そのものがこの日に大きく変わった更新ではありません。(GitHub)
ただし、Microsoft Learn のページ本文では GitHub Enterprise Managed User (OIDC) の自動プロビジョニングに必要な設定が整理されており、管理者は「更新がメタデータのみだったから確認不要」と考えるべきではありません。特に、既存の GitHub EMU 環境、SAML から OIDC への移行検討中の環境、複数 GitHub Enterprise を持つグローバル組織では、現在の設定が公式手順とずれていないかを確認する価値があります。(GitHub)
| 確認項目 | 今回の読み取り方 | 管理者が取るべき対応 |
|---|---|---|
| 2026年6月26日の更新 | メタデータのみの一括更新として記録 | 設定変更の強制対応ではないが、構成の棚卸しを行う |
| Microsoft Learn の手順 | EMU OIDC 向け自動プロビジョニング手順を説明 | Tenant URL、Secret Token、属性マッピングを再確認する |
| 移行期限 | 公式手順内で一律の移行期限は示されていない | SAML から OIDC へ移行する場合は自社計画で期限を決める |
| 影響範囲 | GitHub Enterprise Managed Users が主対象 | 標準 GitHub Enterprise Account と混同しない |
影響範囲：対象になる組織とならない組織
この手順の対象は、GitHub Enterprise Managed Users（EMU）を利用し、Microsoft Entra ID を IdP として OIDC SSO と自動プロビジョニングを構成する組織です。GitHub EMU は通常の GitHub Enterprise Account とは異なる仕組みであり、Microsoft Learn でも標準 GitHub Enterprise Account とは区別されています。標準 GitHub Enterprise Account ではエンタープライズアカウント単位のユーザープロビジョニングは対象外で、標準 Enterprise Account 配下の organization では別手順を確認する必要があります。(Microsoft Learn)
また、GitHub 側の公式情報では、Enterprise Managed Users は外部 IdP からユーザーのライフサイクルと認証を管理する仕組みであり、ユーザー名、プロフィール情報、organization メンバーシップ、リポジトリアクセスの管理も IdP と連動します。管理者が「GitHub 側で後から手作業で直せばよい」と考えていると、Entra ID からの再同期で意図しない状態に戻る可能性があります。(GitHub Docs)
特に確認すべき影響範囲は次のとおりです。
| 対象 | 影響 |
|---|---|
| GitHub EMU を新規導入する組織 | OIDC SSO と SCIM プロビジョニングを最初から設計できる |
| 既に GitHub EMU と SAML SSO を使っている組織 | OIDC へ移行する場合、移行中のアクセス停止や再プロビジョニングを考慮する |
| 複数の GitHub Enterprise を持つ組織 | Entra ID テナントと OIDC 統合の制約を確認する |
| US Government などクラウド環境が異なる組織 | Microsoft Learn の対応クラウド表と GitHub 側サポート範囲を確認する |
| 標準 GitHub Enterprise Account のみの組織 | この EMU OIDC 手順をそのまま適用しない |
設定前に確認すべき前提条件
Microsoft Learn の手順では、Microsoft Entra テナント、必要な管理ロール、GitHub Enterprise Managed Users 側で OIDC SSO が有効化・構成されていることが前提です。Entra 側では Application Administrator、Cloud Application Administrator、Application Owner のいずれかが前提として示されています。(Microsoft Learn)
一方で、GitHub Enterprise Managed User (OIDC) アプリケーションを Entra ID にインストールして同意する場面では、GitHub の公式手順上、Entra ID のグローバル管理者権限が必要とされています。実務では「プロビジョニング設定担当」と「テナント全体の同意を行う担当」が別部署になっていることが多いため、作業前に権限者を明確にしておくべきです。(GitHub Docs)
| 前提条件 | 確認ポイント | 失敗しやすい例 |
|---|---|---|
| Microsoft Entra テナント | GitHub EMU と接続する正式テナントか | 検証用テナントで設定し、本番 GitHub と接続できない |
| 管理ロール | Entra 管理センターで Enterprise apps を操作できるか | Cloud Application Administrator がなく設定画面に進めない |
| GitHub EMU | OIDC SSO が有効化されているか | 通常の GitHub Enterprise と EMU を混同する |
| SCIM トークン | scim:enterprise スコープを持つか | 権限不足のトークンで Test Connection が失敗する |
| Tenant URL | GitHub.com と GHE.com で形式が違う | GHE.com なのに GitHub.com 用 URL を入力する |
設定変更で特に重要なポイント
Microsoft Learn の手順では、Microsoft Entra アプリケーションギャラリーから「GitHub Enterprise Managed User (OIDC)」を追加し、Provisioning タブで新しい構成を作成します。SSO 用に既に GitHub Enterprise Managed User (OIDC) を設定している場合は同じアプリを使うこともできますが、初回テストでは別アプリを作成することが推奨されています。(Microsoft Learn)
Tenant URL は GitHub.com と GHE.com で違う
Tenant URL は、プロビジョニング設定の中でも最も間違えやすい項目です。Microsoft Learn では、GitHub.com の enterprise では https://api.github.com/scim/v2/enterprises/{enterprise}、GHE.com では https://api.{subdomain}.ghe.com/scim/v2/enterprises/{subdomain} の形式が示されています。(Microsoft Learn)
たとえば enterprise 名が octo-corp の場合、GitHub.com では次のようになります。
https://api.github.com/scim/v2/enterprises/octo-corpGHE.com のサブドメインが octo-corp の場合は、次の形式です。
https://api.octo-corp.ghe.com/scim/v2/enterprises/octo-corpこの URL が誤っていると、Secret Token が正しくても接続テストに失敗します。特にグローバル企業では、GitHub.com と GHE.com の両方を部署別に使っているケースがあるため、管理台帳に「どの Enterprise がどの URL 形式か」を残しておくと運用ミスを減らせます。
Secret Token は scim:enterprise スコープを確認する
Secret Token には、GitHub Enterprise の setup user 用に作成した scim:enterprise スコープのトークンを使います。Microsoft Learn では、この値を GitHub Enterprise Managed User アプリケーションの Provisioning タブにある Secret Token フィールドへ入力する流れが示されています。(Microsoft Learn)
実務では、トークンの保管場所と更新手順も決めておく必要があります。担当者個人のメモやブラウザ保存に依存すると、退職・異動・端末交換のタイミングで復旧できなくなります。少なくとも次の3点は運用ルールに入れておくと安全です。
- トークンを作成した setup user と作成日を記録する
- トークンの保管先を管理者チームで共有できる安全な場所に限定する
- 接続失敗時に、URL 誤り、トークン権限不足、トークン失効の順で切り分ける
属性マッピングとスコープ設定の注意点
GitHub Enterprise Managed User (OIDC) のプロビジョニングでは、ユーザー属性とグループ属性のマッピングを確認します。Microsoft Learn では、ユーザーの Matching properties は更新操作時に GitHub 側のユーザーアカウントと照合するために使われ、変更する場合は GitHub Enterprise Managed User API がその属性でのフィルターをサポートしているか確認する必要があると説明されています。(Microsoft Learn)
公式手順上、ユーザー属性では externalId がフィルター対応として示されています。グループ属性でも externalId がフィルター対応として示されており、displayName や members などの扱いとは区別して確認する必要があります。(GitHub)
| 項目 | 推奨される確認 |
|---|---|
| Matching property | 既存ユーザーと新規ユーザーの照合に使う属性が一貫しているか |
externalId | 既存環境で欠損や重複がないか |
userName | 表示名やメール変更時に想定外の別ユーザー扱いにならないか |
| グループ同期 | GitHub チームやライセンス割り当てと連動しているか |
| スコープ | 最初から全ユーザー同期にせず、少数ユーザーで検証できるか |
また、AppRoleAssignmentComplex の構成は、スコープで「Sync Only Assigned Users and Groups」を選択している場合にのみ期待どおり動作する旨が公式手順に記載されています。全ユーザー同期にしている環境でロール割り当てが反映されない場合は、属性式や GitHub 側だけでなく、まずスコープ設定を見直すべきです。(GitHub)
安全に展開するための手順
GitHub EMU OIDC の自動プロビジョニングは、いきなり全社展開すると影響範囲が大きくなります。Microsoft Learn でも、スコープを決め、少数のユーザーやグループでテストしてから広げる流れが示されています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前設計 | 誰を同期対象にするか決める | 正社員、委託先、開発者、管理者を分ける |
| アプリ追加 | Entra ギャラリーから GitHub Enterprise Managed User (OIDC) を追加 | 本番用と検証用を混同しない |
| 接続設定 | Tenant URL と Secret Token を入力 | Test Connection が成功するか |
| プロパティ設定 | 通知メールと誤削除防止を有効化 | 障害時の通知先が個人だけになっていないか |
| 属性マッピング | ユーザー・グループ属性を確認 | externalId、メール、表示名の扱いを確認 |
| 少数テスト | オンデマンドプロビジョニングで検証 | 1〜2名のテストユーザーで作成・更新・無効化を確認 |
| 本番開始 | Start Provisioning を実行 | 初回同期後のログと GitHub 側状態を確認 |
特に重要なのは、オンデマンドプロビジョニングで先に検証することです。Microsoft Entra のオンデマンドプロビジョニングでは、接続テスト、ユーザーのインポート、スコープ判定、ソースとターゲットの照合などを段階的に確認できます。これにより、「同期されない理由」が割り当て不足なのか、属性不足なのか、GitHub 側との照合失敗なのかを切り分けやすくなります。(Microsoft Learn)
SAML から OIDC へ移行する場合の注意点
今回の Microsoft Learn 記事自体は、GitHub Enterprise Managed User (OIDC) への自動ユーザープロビジョニング設定を説明するものです。一方で、既に GitHub EMU を SAML SSO で利用している組織では、「この機会に OIDC へ移行すべきか」が重要な判断になります。
GitHub の公式ドキュメントでは、SAML から OIDC へ移行すると、Microsoft Entra ID の Conditional Access Policy（CAP）サポートを活用できると説明されています。ただし、OIDC と CAP サポートは Enterprise Managed Users では Microsoft Entra ID 向けに提供されるものとして示されており、OIDC は IdP initiated authentication をサポートしない点、カスタム OIDC claims や属性がサポートされない点にも注意が必要です。(GitHub Docs)
| 判断軸 | OIDC 移行を検討しやすいケース | 慎重に進めるべきケース |
|---|---|---|
| 条件付きアクセス | GitHub アクセスに Entra ID の CAP を強く適用したい | 既存 SAML 構成が安定しており変更理由が弱い |
| 認証方式 | GitHub EMU を Entra ID 中心に統制したい | IdP initiated の動線に依存している |
| 移行影響 | 計画停止時間を確保できる | 開発チームが24時間利用しており停止調整が難しい |
| チーム同期 | 移行前後のチーム・外部グループ情報を棚卸しできる | IdP グループと GitHub チームの関係が文書化されていない |
移行時には、GitHub 公式手順で「移行には最大1時間かかる可能性があり、その間ユーザーは GitHub Enterprise にアクセスできない」とされています。また、移行中に新しいユーザーを Entra ID アプリからプロビジョニングしないよう警告されています。移行を行う場合は、開発チーム、セキュリティチーム、IdP 管理者、GitHub Enterprise 管理者が同じ作業計画を共有してから実施してください。(GitHub Docs)
移行期限はあるのか
公開されている Microsoft Learn の該当手順と GitHub の移行手順を見る限り、すべての組織に対して「いつまでに GitHub EMU を OIDC へ移行しなければならない」という一律の移行期限は示されていません。したがって、管理者は期限対応として慌てるよりも、自社の認証・アクセス制御方針に基づいて移行要否を判断するのが現実的です。(Microsoft Learn)
ただし、期限がないことは「検討不要」という意味ではありません。グローバル組織では、国・地域ごとに Entra テナント、GitHub Enterprise、ネットワーク制御、委託先アクセスの運用が異なることがあります。OIDC 化によって条件付きアクセスの適用範囲を広げたい場合は、移行期限を自社内で設定し、段階的に進めるべきです。
運用開始後に監視すべきポイント
プロビジョニング開始後は、Microsoft Entra のプロビジョニングログ、進行状況バー、隔離状態を確認します。Microsoft Learn では、プロビジョニングログで成功・失敗したユーザーを確認し、進行状況バーでサイクルの状態を把握し、構成が不健全な場合はアプリケーションが quarantine 状態になる可能性があると説明されています。(Microsoft Learn)
Quarantine 状態は、ターゲットシステムへの呼び出しが継続的に失敗した場合などに発生します。Microsoft Entra の公式説明では、無効な管理者資格情報が原因例として挙げられており、quarantine 中は増分サイクルの頻度が徐々に下がり、4週間を超えるとプロビジョニングジョブが無効化されるとされています。(Microsoft Learn)
| 監視項目 | 見る場所 | 異常時の対応 |
|---|---|---|
| 接続エラー | Provisioning の Test Connection | Tenant URL、Secret Token、GitHub 権限を確認 |
| ユーザー同期失敗 | Provisioning logs | 属性欠損、スコープ外、照合失敗を確認 |
| グループ同期失敗 | Provisioning logs | グループ属性、メンバー参照、GitHub 側制約を確認 |
| Quarantine | Provisioning 画面、監査ログ、通知メール | 原因修正後に再開または再同期 |
| 誤削除リスク | Properties | accidental deletions prevention を有効化 |
管理者が今すぐ確認すべきチェックリスト
GitHub EMU OIDC の自動プロビジョニングを安全に運用するには、設定画面を開いて「有効になっているか」だけを見るのでは不十分です。次のチェックリストで、構成・権限・運用の3層を確認してください。
- 自社の GitHub Enterprise が EMU なのか、標準 GitHub Enterprise Account なのかを確認する
- Microsoft Entra ギャラリーアプリが「GitHub Enterprise Managed User (OIDC)」になっているか確認する
- Tenant URL が GitHub.com 用か GHE.com 用かを確認する
- Secret Token が
scim:enterpriseスコープを持ち、管理された場所に保管されているか確認する - 同期対象が「全ユーザー」なのか「割り当て済みユーザーとグループ」なのか確認する
AppRoleAssignmentComplexを使う場合、スコープが要件に合っているか確認する- ユーザーとグループの
externalIdが重複・欠損していないか確認する - 通知メール、誤削除防止、プロビジョニングログの確認担当を決める
- SAML から OIDC へ移行する場合、最大1時間程度のアクセス不可を前提に作業計画を作る
- 移行前に GitHub チームと IdP グループの関係をエクスポートまたは文書化する
まとめ：更新対応よりも「構成の棚卸し」が重要
Microsoft Entra の「Configure GitHub Enterprise Managed User (OIDC) for automatic user provisioning with Microsoft Entra ID」は、GitHub EMU を Entra ID 中心で統制するための重要な公式手順です。2026年6月26日の履歴はメタデータ更新として記録されていますが、実務上は GitHub EMU、OIDC、SCIM、属性マッピング、スコープ、監視の設定を見直す良いタイミングです。(GitHub)
まずは現在の GitHub Enterprise が EMU かどうかを確認し、次に Entra 側のアプリ、Tenant URL、Secret Token、同期スコープ、属性マッピングを棚卸ししてください。そのうえで、少数ユーザーのオンデマンドプロビジョニングを実行し、ログで結果を確認してから本番展開するのが安全です。SAML から OIDC へ移行する場合は、期限に追われるのではなく、条件付きアクセスの活用価値、停止時間、チーム連携への影響を整理したうえで計画的に進めましょう。
コメント