3行まとめ
このテーマをもう少し広げて見るなら、GitHub code scanningが非アクティブリポジトリの30日周期スキャンに対応：default setupと管理者の確認ポイント と GitHubの第三者コーディングエージェント安全検証が一般提供：CodeQL、依存関係、Secret scanningの確認ポイント も合わせて確認してください。IP許可リストで接続元を絞った後、休眠リポジトリのセキュリティ検査を継続する観点につながる。
GitHub Enterprise Cloud with Enterprise Managed Usersで、managed user account側の名前空間にもIP許可リストを適用できるようになりました。
Web UI、Git、API、PAT、OAuth app token、SSH key、GitHub App token、ActionsのGITHUB_TOKENまで確認します。
匿名アクセスの公開リソースや一部のGitHub App、Copilot機能など、IP許可リストだけでは止まらない経路があります。
IP許可リストはアクセス制御の土台ですが、token、アプリ連携、公開リソースの扱いまで合わせて見る必要があります。
GitHubは2026年6月8日、GitHub Enterprise Cloud with Enterprise Managed Usersで、GitHubネイティブのIP許可リストをEMUのユーザー名前空間にも適用できる機能を一般提供にしました。組織所有リポジトリだけでなく、managed user accountが所有するリポジトリやforkも、許可されたIPアドレスからのアクセスに寄せやすくなります。
確認すべき範囲は、ブラウザからのWeb UIだけではありません。Git、API、personal access token、OAuth app token、SSH key、GitHub App token、GitHub ActionsのGITHUB_TOKENなど、開発者と自動化が使う経路をまとめて棚卸しする必要があります。
一方で、匿名アクセスの公開リソース、一部のGitHub App server-to-server token、GitHub Copilotの一部機能、匿名化された画像・動画URLなど、IP許可リストだけでは止まらない例外もあります。この記事ではGitHub ChangelogとGitHub Docsを2026年6月9日JSTに確認し、事実認定は公式情報に限定しています。
EMUユーザー名前空間にもIP許可リストが効くとはどういうことか
- 1Organization-owned repositories
本番コード、内部ライブラリ、Actions workflowなど、多くの企業資産が置かれる領域です。
- 2Managed user account
IdPから管理される企業ユーザーで、ユーザー名、プロフィール、組織メンバーシップ、リポジトリアクセスも管理対象になります。
- 3User-owned repositories and forks
検証用リポジトリ、fork、個人単位の作業コピーにも業務情報が残る可能性があります。
- 4User-level enforcement
ユーザー所有リソースにもIP許可リストの制限を広げ、見落としやすい作業領域を管理対象にできます。
EMUではユーザーアカウント自体も企業管理の一部です。組織所有リポジトリだけでなく、ユーザー名前空間の扱いを明確にすることが重要です。
今回の更新は、GitHub Enterprise CloudをEnterprise Managed Users、つまりEMUで使っている企業向けのアクセス制御強化です。GitHub Changelogは2026年6月8日、EMUのユーザー名前空間にもGitHubのnative IP allow list configurationを適用できる機能が一般提供になったと発表しました。
ここでいうユーザー名前空間は、企業が管理するmanaged user accountにひもづく領域です。GitHubの企業利用では、組織所有のリポジトリだけがコードの置き場とは限りません。開発途中の検証、fork、個人単位の作業リポジトリ、プロフィール上の表示など、ユーザー側の名前空間にも業務上の情報が残ることがあります。
「組織リポジトリだけ守る」から一段広がる
従来のIP許可リストを読んでいると、企業管理者はどうしてもorganization-owned repositoriesを中心に考えがちです。もちろん、それは重要です。多くの本番コード、内部ライブラリ、Terraformやデプロイ設定、Actions workflowは組織所有リポジトリに置かれます。
ただ、EMUを使う企業では、ユーザーアカウントも企業がIdPから管理します。GitHub Docsは、EMUではIdPがユーザーアカウントをプロビジョニングし、ユーザーはIdPで認証して企業リソースにアクセスし、ユーザー名、プロフィール情報、組織メンバーシップ、リポジトリアクセスもIdP側から管理できると説明しています。
その管理対象ユーザーが持つリポジトリやforkにアクセス制御の穴が残ると、企業としては「組織リポジトリは制御できているが、ユーザー所有の作業コピーは見落としている」という状態になり得ます。今回の一般提供は、この見落としを埋めるための更新として読むのが自然です。
user-level enforcementの対象
GitHub DocsのIP許可リスト文書では、EMUを使う企業向けにuser-level enforcementが説明されています。既定では、企業のIP許可リストはmanaged user accountが所有するリポジトリやその他リソースへのアクセスを制限しません。そこでuser-level enforcementを有効にすると、ユーザー所有リソースにも制限を広げられます。
公式Docsで例示されている対象は、ユーザー所有リポジトリとそのfork、ユーザープロフィールページです。つまり、単に「組織配下のprivate repositoryを守る」機能ではなく、企業のコードが存在し得る場所をもう一段広く見る機能です。
根拠として押さえる表現
Changelogは、EMUユーザーが自分のアカウントのリポジトリへアクセスできるのは許可されたIPアドレスからに限られる、と説明しています。Docs側は、企業コードが存在し得る場所をorganization-owned repositoriesだけに限らず、user-owned resourcesにも広げて扱う必要を示しています。
ここは導入説明でかなり大事です。「GitHub全体がIP制限される」と雑に言うと誤解を招きます。正しくは、GitHub Enterprise Cloud with EMUの企業設定として、企業リソースと、設定時に対象化されるmanaged user account側のリソースに対して、IP許可リストの制御を広げる話です。
何が保護対象になるのか
IP許可リストの影響は人間のログインだけではありません。Git操作、API、bot、CI/CDを同じ棚卸し表で確認すると抜け漏れを減らせます。
IP許可リストの導入判断で最初に見るべきなのは、画面上のログインだけではありません。GitHub Docsは、許可リストがWeb UI、API、Gitを通じた保護リソースへのアクセス可否を判定すると説明しています。開発者がブラウザでGitHubを開く場面だけを見ていると、Git clone、CI/CD、bot、外部連携の確認が抜けます。
特にGitHub Enterprise Cloudでは、人間の利用と自動化の利用が混ざります。リポジトリの閲覧、pull request、Git fetch、package取得、Actionsのworkflow、社内bot、セキュリティスキャン、デプロイ連携が同じリポジトリに触れることもあります。IP許可リストは、そうした経路をまとめて棚卸しするきっかけになります。
Web UI、API、Gitの3経路で見る
まずWeb UIです。これは企業管理者が想像しやすい経路で、ユーザーがブラウザからGitHubにアクセスし、リポジトリ、issue、pull request、settings、profileなどを見る場面です。EMUではユーザーがIdPで認証するため、Entra IDなどの条件付きアクセスと組み合わせて考えたくなる領域でもあります。
次にAPIです。GitHub CLI、社内ツール、セキュリティスキャナ、ダッシュボード、棚卸しスクリプト、GitHub Apps、OAuth AppsがAPIを使います。開発者本人が意識していなくても、組織の周辺ツールがAPI tokenを持っていることは珍しくありません。
最後にGitです。Git clone、fetch、pull、push、submodule、deploy key、SSH key、Actionsからのcheckoutなどが関係します。リポジトリの中身そのものに触る経路なので、IP許可リストを入れるなら最も慎重にテストすべき領域です。
資格情報ごとに確認する
GitHub Docsは、IP許可リストの対象となる非対話アクセスとして、personal access token、OAuth app tokens、SSH keys、GitHub App user-to-server tokenまたはinstallation tokenを挙げています。GitHub ActionsのGITHUB_TOKENも、この文脈で確認対象になります。
ただし、例外もあります。Docsは、GitHub Appがユーザーアカウントにインストールされ、server-to-server installation tokenでorganizationまたはenterpriseへアクセスする場合、IP許可リストが現在は制限しないと説明しています。これは実務上かなり見落としやすい点です。
確認表
| 確認対象 | 代表例 | まず見ること |
|---|---|---|
| Web UI | ブラウザでのリポジトリ閲覧、settings変更 | IdP認証、接続元IP、管理者の緊急時アクセス |
| Git | clone、fetch、push、deploy key | 開発者端末、CI runner、外部ビルド環境の接続元 |
| API | GitHub CLI、社内ツール、棚卸しスクリプト | token種別、実行場所、失敗時の復旧手順 |
| PAT | classic/fine-grained token | 所有者、期限、利用中の自動化 |
| OAuth app token | 社内外アプリ連携 | アプリの接続元と権限 |
| SSH key | 個人キー、deploy key、GitHub Appsで使うSSH key | キー所有者、利用元、ローテーション |
| GitHub App token | user-to-server、installation token | インストール先がorganizationかuser accountか |
GITHUB_TOKEN | GitHub Actions workflow | runner、checkout、deployの失敗影響 |
この表で重要なのは、「人間のログイン」と「機械のアクセス」を分けすぎないことです。IP許可リストはセキュリティ機能ですが、同時に開発基盤の可用性にも直結します。許可漏れがあると、コードを守れる一方で、通常の開発や自動化も止まります。
保護されないものを先に知っておく
匿名でアクセスされる公開リソースはIP許可リストの対象外です。公開してよい情報かどうかの管理は別に必要です。
ユーザーアカウントにインストールされたGitHub Appのserver-to-server installation tokenでは、制限されないケースがあります。
privateまたはorganizational dataをGitHubから直接取得しないCopilot機能は、IP許可リストで制限されない場合があります。
画像や動画のURLなど、IP許可リストの外側で扱われるリソースも確認対象に含めます。
対象外があることは機能の弱さではなく、設計上の境界です。公開設定、GitHub Apps、Copilot管理設定を合わせて確認します。
IP許可リストという名前だけを見ると、「許可したIP以外からはGitHub上の企業情報に一切触れない」と期待したくなります。しかしGitHub Docsは、保護対象と対象外を分けて説明しています。導入前の社内説明では、この対象外を曖昧にしない方が安全です。
匿名アクセスの公開リソース
Docsは、匿名でアクセスされるpublic resourcesはIP許可リストの対象外としています。これは、サインインしているユーザーがpublic resourceに触る場合とは分けて読む必要があります。
EMUのmanaged user accountsは、通常の個人アカウントとは異なり、公開コンテンツ作成や企業外コラボレーションに制限があります。それでも、公開リソースの匿名アクセスという例外は、IP許可リストの万能感を削る重要な材料です。企業のコードや内部情報をそもそも公開リソースに置かない、という基本は変わりません。
GitHub AppsとCopilotの例外
GitHub Appsも注意が必要です。Docsは、ユーザーアカウントにインストールされたGitHub Appのserver-to-server installation tokenについて、IP許可リストが制限しないケースを示しています。すべてのGitHub App連携をIP許可リストで一律に止められると考えるのは危険です。
GitHub Copilotについても、Docsは、GitHubからprivateまたはorganizational dataを直接取得する必要がないCopilot機能はIP許可リストで制限されないと説明しています。Copilotの利用制御、データ境界、モデルへの送信内容は、Copilot側の管理設定や組織ポリシーと合わせて見る必要があります。
導入説明で避けたい言い方
「IP許可リストを入れればGitHubのすべてのアクセスを閉じられる」という説明は避けるべきです。より正確には、「保護対象リソースに対する、Web UI、API、Gitなどのアクセスを、許可したIPアドレスへ制限する。ただし公式Docsが示す対象外がある」という説明になります。
この一文の差は小さく見えますが、セキュリティ監査では大きな差になります。対象外を明示していれば、別の対策を検討できます。明示していなければ、実際には制御できていない経路を制御済みとして扱ってしまいます。
有効化前に棚卸しすべき運用リスク
- 接続元IPを集める
オフィス、VPN、ゼロトラストプロキシ、委託先拠点、サポートチーム、IPv6の利用有無を確認します。
- 緊急時アクセスを決める
管理者が入れない、重要なworkflowが止まる、外部連携が失敗する場合の復旧経路を決めます。
- CI/CDを分解する
GitHub-hosted runner、self-hosted runner、社内ネットワーク、クラウド上のビルド環境を分けて確認します。
- アプリ連携を棚卸しする
GitHub Apps、OAuth Apps、セキュリティスキャン、依存関係管理、デプロイ、通知、監査ログ取得を確認します。
- 試験導入で止まり方を見る
pull、push、checkout、API request、bot実行がどこで止まるかを事前に確認します。
セキュリティ機能は有効化そのものより、許可IP、token、runner、外部SaaSを先に並べることが導入成功の分かれ目です。
user-level enforcementは、企業コードの置き場を広く守れる一方で、有効化するとユーザー所有リソースへのアクセスにも影響します。GitHub Docsは、有効化前にmanaged user accountsが企業に接続するために使うすべてのIPアドレスをenterprise IP allow listへ追加するよう注意しています。許可リストにないIPアドレスから接続するユーザーは、user-owned resourcesへアクセスできなくなります。
この注意書きは、導入時の最重要ポイントです。セキュリティ機能は「オンにする」だけなら簡単に見えます。しかしGitHubの開発基盤は、在宅勤務、VPN、ゼロトラストプロキシ、外部委託先、CI/CD、SaaS連携、緊急時の管理者アクセスまで含みます。許可リストの漏れは、開発停止や障害対応遅れにつながります。
接続元IPとネットワーク経路
まず、開発者の接続元を棚卸しします。オフィスの固定IP、VPN出口、ゼロトラストネットワークの出口、委託先拠点、サポートチーム、出張時の利用可否を分けます。IPv6も無視しない方がよいです。GitHub Docsは、GitHub servicesがIPv6 supportを広げるにつれて、必要なIPv6アドレスも許可リストに入れるよう注意しています。
次に、緊急時アクセスです。設定ミスで管理者自身が入れなくなる、重要なworkflowが止まる、外部連携が失敗する、といった場面に備え、誰が、どの経路で、どの手順で復旧するかを決めておく必要があります。
CI/CDと外部連携
CI/CDは、人間の利用より複雑です。GitHub-hosted runnerだけで完結しているのか、self-hosted runnerを使っているのか、社内ネットワーク内で走るのか、クラウド上のビルド環境からGitHubへアクセスするのかで、許可すべきIPの考え方が変わります。
GitHub AppsやOAuth Appsも同じです。セキュリティスキャン、依存関係管理、issue同期、監査ログ取得、デプロイ、通知、社内ポータル連携など、管理者が直接触っていないアプリがリポジトリへアクセスしている場合があります。IP許可リストの設定前には、使っているtokenとアプリを棚卸しし、接続元と権限を確認します。
有効化前チェックリスト
- EMUを使うenterpriseであることを確認したか
- 対象をorganization-owned resourcesだけでなくuser-owned repositories、forks、profile pagesまで広げて見たか
- 許可するIPv4/IPv6アドレスまたはCIDR範囲を洗い出したか
- 在宅勤務、VPN、ゼロトラストプロキシ、委託先、サポート担当の経路を確認したか
- GitHub CLI、社内スクリプト、セキュリティスキャナ、デプロイツールのtokenを確認したか
- GitHub Appsがorganizationに入っているのか、user accountに入っているのかを見たか
- GitHub Actions workflowとrunnerの接続元を確認したか
- 許可漏れ時の問い合わせ窓口と復旧手順を決めたか
- 小さい対象でテストし、pull、push、API、Actions、外部連携の失敗を確認したか
Entra ID/OIDC Conditional Access Policyとはどう分けて考えるか
人間のサインインをIdPで固めても、アプリ連携やinstallation tokenが同じ条件で守られるとは限りません。
EMU環境では、IdP側の制御も重要です。GitHub Docsは、EMUではIdPがユーザーライフサイクルと認証を管理し、OIDC SSOを使う場合にはGitHubがIdPのConditional Access Policy、CAPを使ってアクセスを検証できると説明しています。Microsoft系の企業環境では、Entra IDとの組み合わせでこの話が出やすいはずです。
ただし、GitHubネイティブのIP許可リストとIdP側のallow listやCAPは、同じものではありません。どちらも「どこからアクセスできるか」に関係しますが、効く場所、効くtoken、例外、設定主体が違います。
IdP allow listを使える条件
GitHub DocsのIP許可リスト文書では、Enterprise Managed UsersとEntra ID、OIDCを使っている場合に、IdPのallow listを使えると説明されています。この設定では、GitHub側の組織ごとのIP許可リスト構成や、IP許可リスト管理用のGraphQL APIが無効化される点も示されています。
つまり、IdP allow listは「GitHubにもEntra IDにもそれぞれ似た設定を置けばよい」という単純な足し算ではありません。どちらを使うのか、どの単位で管理するのか、既存のGraphQL API運用に影響があるのかを確認する必要があります。
CAPが効く範囲と効かない範囲
Docsは、既定ではIdPのCAPがGitHubへの初回の対話的なSAMLまたはOIDCサインインで実行されると説明しています。また、OIDC CAPはWeb requestや、OAuth token、GitHub Appのuser access tokenなど、ユーザーtokenを使ったAPI requestに適用されます。
一方で、GitHub Appがinstallation access tokenを使う場合にはOIDC CAPが適用されないと説明されています。ここは、GitHub App連携を多く使う企業ほど注意が必要です。人間のサインインをEntra IDで固めても、アプリ連携のすべてが同じ条件で守られるとは限りません。
判断基準
GitHub native IP allow listを中心にするか、IdP allow listやCAPを中心にするかは、社内のネットワーク設計で決めます。GitHub上の保護対象リソースをGit、API、Web UIまで広く見たいならGitHub nativeの制御が重要です。IdP上のサインインポリシー、端末準拠、場所条件、ユーザー状態と合わせたいならCAPの設計も欠かせません。
実務では、どちらか一方で終わりにしない方がよい場面が多いです。GitHubのIP許可リストでリポジトリとユーザー名前空間へのアクセスを制限し、Entra ID側でユーザー認証、端末条件、リスクベース条件を管理する。さらにGitHub Apps、Actions、bot、外部サービスは個別に棚卸しする。この三層で見ると、説明が破綻しにくくなります。
導入企業が今日決めるべきこと
- 1管理対象を定義する
ユーザー所有リポジトリやforkをどこまで企業管理の対象として扱うかを決めます。
- 2関係者を集める
enterprise owner、organization owner、セキュリティ担当、IdP管理者、CI/CD担当、GitHub App管理者、開発者代表で確認します。
- 3接続元とtokenを棚卸しする
managed user account、ユーザー所有リソース、接続元IP、PAT、GitHub App、OAuth App、自動化tokenを並べます。
- 4許可IPを説明付きで整理する
CIDR表記に加えて、拠点名、用途、所有部署、更新担当を残します。
- 5試験導入と復旧手順を決める
失敗時の切り戻し、管理者アクセス、workflow停止時の対応を先に確認します。
今回の更新は即時有効化の合図ではなく、EMU環境でユーザー名前空間をどう統制するかを決める合図として読むのが現実的です。
今回の一般提供は、すべての企業が今日すぐ本番で有効化すべき、という話ではありません。むしろ、EMUを使っている企業が「ユーザー所有リポジトリやforkをどこまで管理対象として扱うか」を決めるタイミングです。
GitHub Enterprise Cloudは、ソースコード管理だけでなく、Copilot、Actions、Security、Packages、Issues、Projects、社内開発者ポータルの基盤になっています。IP許可リストの変更は、セキュリティ担当だけで完結しません。開発者体験、CI/CD、AI開発支援、外部連携に影響します。
誰が確認するべきか
enterprise ownerは、設定の所有者として全体の方針を決める必要があります。organization ownerは、組織リポジトリとチーム運用への影響を見ます。セキュリティ担当は、コード持ち出しリスク、監査、許可IP、例外管理を見ます。IdP管理者は、Entra ID/OIDC/CAPとの役割分担を確認します。
CI/CD担当は、Actions、runner、deploy key、外部ビルド環境の接続元を見ます。GitHub App管理者は、インストール先、token種別、権限、接続元を棚卸しします。開発者代表も必要です。実際にpullやpushが止まるのは開発者なので、運用テストに入れた方が早く問題が見つかります。
試験導入の順番
最初の手順は、設定画面を開くことではなく、棚卸しです。どのmanaged user accountが、どのユーザー所有リポジトリやforkを持っているか。どの接続元からアクセスしているか。どのtokenやGitHub Appが自動化に使われているか。ここを出さずに有効化すると、失敗時の原因切り分けが難しくなります。
次に、許可IPの候補を作り、CIDR表記と説明を整えます。Docsは、IPアドレスや範囲をCIDR notationで追加する手順を示しています。説明欄には、単に「office」ではなく、拠点名、用途、所有部署、更新担当を入れておくと後で効きます。
最後に、小さくテストします。代表ユーザー、代表リポジトリ、代表workflow、代表GitHub Appで、Web UI、Git、API、Actionsを試します。失敗したログ、問い合わせ、復旧手順も含めて確認できてから、本番範囲を広げる方が現実的です。
本番有効化を急がない条件
- 在宅勤務や委託先の接続元が整理できていない
- 重要なGitHub Appのインストール先とtoken種別が不明
- GitHub Actionsやself-hosted runnerの接続元が不明
- 管理者の緊急時アクセス経路がない
- 許可IP変更の承認フローが決まっていない
- 失敗時に誰がGitHub、IdP、ネットワークを切り分けるか決まっていない
これらが残っている場合、機能が一般提供になったことと、本番で即有効化できることは分けて考えた方がよいです。GAは利用判断の材料ですが、運用設計の代わりにはなりません。
2026年6月のMicrosoft/GitHub更新として見る意味
- AI開発支援の拡張
GitHub Copilot、VS Code、MCP、enterprise managed plugins、sandboxes、Copilot SDKなどの更新が続いています。
- 自動化経路の増加
AIやエージェント基盤がコードを読み、提案し、実行し、外部サービスやリポジトリへアクセスする場面が増えます。
- EMU名前空間の境界管理
誰が、どのコードに、どの経路から、どのtokenで触れるかを管理するため、ユーザー側リソースの保護も重要になります。
- 継続確認する情報源
GitHub Changelog、IP許可リスト文書、Enterprise Managed Users文書、OIDC/CAP文書、AppsとActionsの認証関連Docsを追います。
AI開発体験の更新は便利さだけでなく、アクセス境界、token、アプリ連携、ユーザー名前空間の管理と合わせて評価します。
Microsoft Watch Japanの文脈では、今回の更新は地味に見えても重要です。2026年6月は、GitHub Copilot、VS Code、MCP、enterprise managed plugins、sandboxes、Copilot SDKなど、開発者向けAIとエージェント基盤の更新が続いています。AIがコードを読み、提案し、実行し、外部ツールへつながるほど、基盤側のアクセス制御はより重要になります。
たとえば、GitHub CopilotのEnterprise-managed pluginsは、企業がMCP、hooks、skillsを標準化する話でした。GitHub Copilot sandboxesは、ローカル/クラウド実行と権限、課金の話でした。GitHub Copilot SDKは、自社アプリへCopilotを組み込む話でした。関連する製品更新を続けて追う場合は、製品・サービス・ソリューションカテゴリから確認できます。
これらは一見、AI開発体験のニュースです。しかし、企業導入では「誰が、どのコードに、どの経路から、どのtokenで触れるか」を管理できなければ、本格導入に進みにくい。今回のEMUユーザー名前空間へのIP許可リスト適用は、その土台側の更新です。
月次トピックとして追うポイント
2026年6月のMicrosoft/GitHub関連更新をまとめて追う場合は、Microsoft 2026年6月重要トピックまとめも確認してください。GitHub Changelogは短い発表が多いため、本文だけで完結させず、Docsの対象範囲と例外、既存設定への影響を合わせて読むのが安全です。
今後見るべき資料は、GitHub Changelog、GitHub DocsのIP許可リスト文書、Enterprise Managed Users文書、OIDC/CAP文書、GitHub AppsとActionsの認証関連Docsです。とくにAppsとActionsは、AI開発基盤の自動化にも直結するため、IP許可リストの例外と重ねて見た方がよいでしょう。
次に読むなら
参照した主な情報源
- GitHub Changelog, "IP allow list coverage for EMU namespaces in general availability"（確認日: 2026年6月9日JST）
IP allow list coverage for EMU namespaces in general availability
- GitHub Docs, "Restricting network traffic to your enterprise with an IP allow list"（確認日: 2026年6月9日JST）
https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list
- GitHub Docs, "About Enterprise Managed Users"（確認日: 2026年6月9日JST）
https://docs.github.com/enterprise-cloud@latest/admin/concepts/identity-and-access-management/enterprise-managed-users
- GitHub Docs, "Configuring OIDC for Enterprise Managed Users"（確認日: 2026年6月9日JST）
https://docs.github.com/en/enterprise-cloud@latest/admin/managing-iam/configuring-authentication-for-enterprise-managed-users/configuring-oidc-for-enterprise-managed-users
Microsoft Watch JapanはMicrosoftおよびGitHubとは非提携の情報整理サイトです。この記事は公式情報の確認を目的としており、投資助言や売買推奨ではありません。
更新通知を受け取りたい場合は、ニュースレターでMicrosoftの公式発表、GitHub Changelog、製品更新、噂確認の追跡をまとめて受け取れます。