GitHub EMU アカウントと個人 GitHub アカウントの併用は利用規約上許されるか — ToS B.3「one free Account」条項を契約構造と公式ドキュメントから読み解く

勤務先で GitHub Enterprise Cloud の Enterprise Managed Users（EMU）を Microsoft Entra ID 経由で導入する話が進むと、必ず出てくる問いがあります。「このあと払い出される EMU アカウントと、自分が前から持っている個人 GitHub アカウントを、同じ人が両方持っていていいんでしたっけ」というものです。

一見、GitHub Terms of Service の「One person or legal entity may maintain no more than one free Account」に正面衝突しそうに見えます。ただ、この条項は読み方を間違えると、GitHub 自身が公式ドキュメントで案内している運用と逆向きの結論に至ります。本稿では、ToS・Customer Agreement・GitHub Enterprise Cloud Product Specific Terms・GitHub Docs を並べて、EMU と個人アカウントの併用がどの範囲で許容されているのかを整理します。

結論から書くと、条件付きで許容されるという読みが妥当です。条件は、個人アカウントが 1 つだけであること、EMU 側で勤務先ポリシーを守ること、業務コードを個人アカウントに持ち出さないこと、の 3 点です。

ToS B.3 が制限しているのは「free Account」

GitHub Terms of Service 第 B 章 3 項「Account Requirements」には、次の 2 つの条項があります。

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that’s fine, but it can only be used for running a machine).

You may maintain no more than one free machine account in addition to your free Personal Account.

ここで制限されているのは「free Account」です。ToS 自身が「Personal Account」を「an individual User’s authorization to log in to and use the Service」と定義しており、同じ節で free Personal Account と free machine account の併存をむしろ認めています。つまり ToS B.3 は、全種類のアカウント数を 1 つに縛る規定ではなく、無料枠を 1 人 1 つに縛る規定として書かれています。

日本語版の訳も同じで、「1 人の個人または 1 法人が維持できる無料アカウントは 1 つのみ」です。英語と日本語で実質的な差はありません。

EMU アカウントは free Account ではない

次に、EMU アカウントがそもそもどのタイプのアカウントなのかを確認します。GitHub Docs「Types of GitHub accounts」はユーザーアカウントを Personal accounts と Managed user accounts の 2 種類に分けたうえで、次のように書いています。

If your account was created for you by an enterprise on GitHub Enterprise Cloud, you are using a managed user account.

EMU アカウントはユーザー自身がサインアップで作るものではありません。企業の IdP（ここでは Microsoft Entra ID）が SCIM でプロビジョニングし、企業がユーザー名・プロフィール・所属組織・リポジトリアクセスを管理します。ライセンスの観点でも、GitHub Customer Agreement §1.3 Accounts に次の記述があります。

Customer may assign each Subscription License to one individual End User … End User accounts may not be shared by individuals. For GitHub’s cloud-based offerings, a Subscription License provides access to only one (1) cloud service at a time, such as to GitHub.com or to an enterprise-managed environment in GitHub Enterprise Cloud.

EMU アカウントは顧客企業が購入した Subscription License を割り当てた End User アカウントで、企業と GitHub の間の契約で扱われます。個人が GitHub に対して無料で作る Personal Account とは、契約の当事者も、ライセンスの性質も、所有・管理の主体も違います。

ここから「ToS の one free Account 条項は、free でも Personal でもない EMU アカウントには当てはまらない」という読みが導けます。注意しておくと、「この条項は EMU には適用されない」と直接書いた公式文書は、ToS・Customer Agreement・Docs のいずれにもありません。あくまで文言と契約構造からの解釈です。

公式ドキュメントが併用を前提にしている

抽象的な ToS 解釈だけでなく、GitHub が公式ドキュメントで EMU と個人アカウントの併用を複数ページで前提にしていることが、この読みをもっとも強く裏づけます。

「Choosing an enterprise type for GitHub Enterprise Cloud」には次の記述があります。

Managed user accounts can only contribute to repositories within your enterprise.

For a managed user to collaborate outside your enterprise, they must also maintain a separate, personal account. The complexity of regularly switching between accounts can increase the risk of mistakenly leaking internal code to the public.

EMU 利用者が社外の OSS などに貢献するには「別個の個人アカウントを維持しなければならない」と書かれています。「維持しても構わない」ではなく must です。

「Getting started with Enterprise Managed Users」にも対応する節があります。

Developers may need to maintain separate, personal accounts for their work outside of your enterprise with managed users. You can help them manage multiple accounts by providing the following resources

その資料として、Managing multiple accounts の Git 設定と、Switching between accounts の Web アカウントスイッチャーが挙げられています。アカウントスイッチャーの説明には次のとおりあります。

You can use the account switcher … if you need to switch between your personal account and managed user accounts in an enterprise that uses Enterprise Managed Users.

さらに、GitHub CLI の複数アカウント案内では gh auth login で複数アカウントを認証し gh auth switch で切り替えられると説明しています。SSH と HTTPS については、前述の Managing multiple accounts に手順があります。同じ SSH 鍵を両方のアカウントには登録できないので、~/.ssh/config に別名ホストを定義して git config --global url."[email protected]:octocat-emu/".insteadOf ... で切り替えるか、HTTPS 用に credential.https://github.com.useHttpPath true を設定してアカウントごとに PAT を使う運用が案内されています。

同じ GitHub が、ToS でもライセンス契約でも Docs でも、EMU と個人アカウントの併用を前提にした UI・CLI・設定手順を公式に用意しているのに、ToS B.3 だけが「それでも 2 つ持つのは違反」と読める、というのはかなり不自然な解釈です。GitHub Docs「Personal account management」も直接的で、「OSS 貢献のために個人アカウントを持ち、雇用主が別途ユーザーアカウントを作成・管理することがある」と書いたうえで、「managed user account では GitHub.com の public project に貢献できないので、個人アカウント側で貢献する必要がある」と続けています。

EMU 側の制約が、個人アカウントの必要性そのものを作っている

EMU と個人アカウントの併用が公式に想定されている理由は、EMU 側に課されている機能制約から直接出てきます。「Abilities and restrictions of managed user accounts」にまとまっている主な制約は次のとおりです。

区分	EMU アカウントの制約（公式記述の要約）
貢献範囲	企業内の private・internal リポジトリと、自分の private リポジトリにしか contribute できない。GitHub.com 全体に対しては読み取りのみ
外部リポジトリ	企業外のリポジトリへの push、issue/PR 作成、コメント、リアクション、star、watch、fork ができない
公開コンテンツ	public リポジトリ、gist（公開範囲を問わず）、企業外に公開される Pages サイトを作れない
招待・可視性	企業外の org やリポジトリ、他の enterprise に招待されない。企業外のユーザーからは見えず、メンションもされない
その他	企業外のユーザーをフォローできない。個人プロフィールを作れない。Copilot Pro/Free に申し込めない。GitHub Certifications を受けられない

OSS に PR を投げる、公開 gist を書く、自分の作ったライブラリを個人として公開する、といった活動は、EMU 側では一切できません。これらが必要な人にとっては、「個人アカウントも持つ」が選択肢ではなく事実上の前提になります。

契約文書のレイヤーで何が書かれているか

ユーザーが読む ToS と、企業が読む契約文書では、EMU の扱いが対になっています。

GitHub General Terms（Version: March 2025）

§1.3 Accounts に「Customer may assign each Subscription License to one individual End User … End User accounts may not be shared by individuals」。
§1.4 End Users に「Customer controls access to and use of the Products by End Users. Customer is responsible for its End Users’ use」。

GitHub Enterprise Cloud Product Specific Terms（Version: October 2024）

§7 に「If you use GitHub Enterprise Cloud with the “Enterprise Managed Users” feature, the portions of these terms that relate to Public Repositories do not apply to you」。
定義として「“Enterprise Managed Users” means the product functionality in GitHub Enterprise where the Customer manages the lifecycle and authentication of Customer’s End Users」。
§1.C に「Customer’s End Users must comply with the Acceptable Use Policies」。

重要なのは、契約の当事者と責任の所在が ToS と GCA で分かれている点です。個人アカウントは個人と GitHub の間の ToS で管理されます。EMU アカウントは顧客企業と GitHub の間の契約で、企業がアカウントとコンテンツに責任を負います。GCA にも GHEC Product Specific Terms にも、「同じ人物が別途個人 GitHub アカウントを持つことを禁じる」条項は見当たりません。

なお、Microsoft の契約（EA・MCA・CSP など）経由で GitHub Enterprise を購入している場合は、GitHub の GCA ではなく、Microsoft Product Terms for GitHub Offerings が適用されます。こちらにも、EMU の Licensed User に個人 GitHub アカウント保有の禁止条項は確認できません。ただし、個別の Order Form や Enterprise Agreement の修正条項は非公開の可能性があるため、契約面での最終確認は自社の契約担当に閉じるのが安全です。

Microsoft Entra ID 連携固有の注意点

Microsoft Entra ID と EMU の連携自体は、Microsoft Learn のチュートリアルが SAML 版と OIDC 版の両方を提供しています。Entra ID から GitHub EMU へ、ユーザー作成・無効化・属性同期・グループプロビジョニング・SSO を行うのが基本構成です。ここに「既存の個人 GitHub アカウントを EMU に変換・統合する」という流れは含まれていません。EMU アカウントは新規に払い出される別の managed user account です。

「About Enterprise Managed Users」によると、EMU 側では次の制約があります。

プロフィール名とメールアドレスは IdP が提供し、ユーザー自身は GitHub 上で変更できない。
IdP が提供できるメールアドレスは 1 つだけ。
IdP でメールを変更すると、古いアドレスに紐づくコントリビューション履歴とのリンクが外れる。
ユーザー名は IdP の識別子を正規化して GitHub が自動生成する。Username considerations for external authentication によると、GitHub.com では末尾にアンダースコアと enterprise の shortcode が付き、IDP-USERNAME_SHORT-CODE の形式（例: mona-cat_octo）になる。個人アカウントとはユーザー名の名前空間が別で、衝突しない。

メールアドレスの扱いで特に注意が要るのは、2024 年 8 月 1 日以降に作られた EMU アカウントではメールが自動検証されなくなった点です（Email addresses reference に記載）。GitHub Docs「Email addresses」に次のとおりあります。

Once you verify an email with a managed user account, you won’t be able to use the email to sign up for a personal account on GitHub.com.

同じメールを両方のアカウントで使う必要がある場合は、EMU 側でそのメールの検証を外す（unverify）運用が案内されています。実務上は、個人アカウントには私用メールを、EMU には会社のメールを、と分けておくのが最もトラブルが少ないです。この運用を義務づける公式文書はありませんが、プロビジョニング由来の属性書き換えとぶつからないメール設計としては素直です。

勤務先ポリシーとネットワーク制限は別レイヤー

GitHub の規約上は併用が許容されても、勤務先の情報セキュリティ規程や、社用端末・社内ネットワーク上でのアカウント運用が別に制限されることがあります。GitHub 側も、企業がそれを技術的に適用する仕組みを公式に用意しています。

「Enterprise access restrictions with corporate proxies」は、企業のプロキシで sec-GitHub-allowed-enterprise ヘッダーを付与することで、社内ネットワークからの GitHub.com 通信を自社 EMU enterprise に限定する機能です。GitHub Changelog の 2025-09-15「Enterprise access restrictions with corporate proxies is now generally available」には「enterprise owners may allow only EMU enterprise traffic to github.com via their existing corporate proxies, while blocking any unapproved traffic」とあります。2025-10-06「Enterprise access restrictions now supports multiple enterprises」の更新で、1 つのヘッダーに「a comma-separated list of up to 20 valid EMU enterprise IDs」を指定できるようになりました。

この機能が有効な社内ネットワークでは、個人アカウントでの GitHub.com アクセスがネットワーク層でブロックされます。規約上の併用は可能でも、勤務先が社内規程として社用端末・社内ネットワーク上での個人アカウント利用を制限している場合は、その規程が優先します。副業規程や OSS 貢献規程がある場合も、合わせて確認対象です。

実務上のチェックリスト

ここまでの整理を踏まえて、デイリースタンドアップやチームミーティングで並べて確認しやすい順にまとめます。

個人アカウントが 1 つだけになっていることを確認する。 「仕事用の個人 free アカウント」をもう 1 つ作って運用しているなら、ToS B.3 と正面衝突します。EMU とは別に、個人の free アカウントを 2 つ持つのはやめて 1 つに統合します。
勤務先ポリシーと Enterprise access restrictions の設定を確認する。 規約上許容でも、社内規程やプロキシ設定で社用端末・社内ネットワークからの個人アカウント利用が制限されていることがあります。副業・OSS 貢献の規程も同時に確認します。
メールアドレスを分ける。 個人アカウントには私用メール、EMU には会社のメール（Entra ID の UPN かメール属性）を使います。コミット用メール（user.email）もリポジトリごとに分け、EMU リポジトリでは会社のメール、個人リポジトリでは私用メールか noreply アドレスを使います。
SSH キーと PAT をアカウントごとに分ける。 同じ SSH キーを両方のアカウントに登録することはできません。~/.ssh/config のホスト別名と insteadOf、HTTPS なら useHttpPath と PAT の分離、gh auth switch で切り替える前提で設計します。
業務コードを個人アカウントに push しない。 GitHub 自身が「The complexity of regularly switching between accounts can increase the risk of mistakenly leaking internal code to the public」と警告しています。ディレクトリ単位の includeIf 設定や、push 前に remote を確認する手順で防ぎます。
Copilot などの機能差を把握する。 EMU アカウントは Copilot Pro/Free に申し込めません。会社が割り当てる Copilot Business/Enterprise を使い、個人で Copilot を契約するなら個人アカウント側で行います。

まだ明記されていないこと

ここまでの読みには、1 つだけ公式文書で直接宣言されていない前提があります。「ToS B.3 の one free Account 条項は managed user account には適用されない」と明示的に書いた公式ページは、ToS・Customer Agreement・Docs のどれにも存在しません。本稿の結論は、ToS が free アカウントを対象にしていること、EMU が企業所有の有償ライセンスアカウントであること、GitHub Docs の複数ページが併用を前提に手順を案内していること、の 3 点からの整合的な解釈です。

GitHub Community Discussion #78043「Having two free accounts as an enterprise employee」（2023 年 12 月）では、モデレーターが EMU 担当 PM に質問を回したうえで、GitHub スタッフが、EMU と個人の 2 アカウント体制は問題なく、個人の free アカウントを 2 つ作るのは「not in the spirit of our general terms」だ、という趣旨で回答しています。その後も法務へのエスカレーション結果の伝聞や反論が続いており、公式見解として扱うには限界があるやりとりですが、この区別の付け方は ToS と Docs の読み方と整合しています。

法務・監査対応で書面回答が必要な場合は、GitHub Enterprise Support か自社の GitHub アカウントマネージャーに直接問い合わせるのが確実です。ToS B.3 と EMU の関係について「EMU は Enterprise Subscription License 下の managed user account として別扱いである」ことを書面で確認できれば、社内の情報セキュリティ規程や監査報告にそのまま載せられます。

以上、GitHub EMU アカウントと個人 GitHub アカウントの併用を ToS B.3 と公式ドキュメント・契約文書から読み解いて、条件付きで許容されるという結論に至った、現場からお送りしました。

サイト内検索