GitHub Enterprise Serverは中国本土で使えるか：データレジデンシー、ICP、越境ルール
GitHub Enterprise Serverは自社運用できるエディションです——中国本土の内側でサーバー自体を動かし、リポジトリ・Issue・コントリビューターの個人情報を国内に留められます。SaaSのGitHub Enterprise Cloudには中国本土のリージョンがありません。ソースコードがどこにあるかは、速度のテストではなくPIPLのレジデンシーと越境の問いです。
GitHub Enterprise Serverは中国で使えるか
はい——GitHub Enterprise Serverは自社運用できるエディションなので、中国本土の内側の貴社自身のインフラ上で動かし、リポジトリ・Issue・それらを保持するコントロールプレーンを国内に留められます。本当の中国の問いは、上海からWeb UIに到達できるかではなく——貴社のソースコード（営業秘密であり、しばしば認証情報やコントリビューターの個人情報を伴う）とそのメタデータがデータレジデンシーと越境の問題であり、GitHub Enterprise Serverを国内で動かすことがそれに答える梃子だということです。
GitHubのドキュメントはGitHub Enterprise Serverを「GitHubプラットフォームの自社運用版」と呼び、自社のオンプレミスのデータセンターや自社のクラウドにデプロイすると述べます——だから答えは「不可」ではなく「要注意」です。ホスト型のGitHub Enterprise CloudはデータレジデンシーをEU・米国・オーストラリア・日本にしか提供せず、中国本土のリージョンはありません。したがってSaaSの経路はコードをオフショアに残します。リポジトリとコントリビューターの個人情報を国外に保持することは、PIPL 第38〜40条（英語）の下での越境移転（英語）です。重要情報インフラ運営者または大量取扱者には、サイバーセキュリティ法 第39条（旧第37条）（英語）が、中国で収集した個人情報を本土に保存することを求めます。
これはレジデンシーのリスクの見取り図であって、GitHubが「遮断されている」という判定ではありません。当社の中国チームがコードのレジデンシーのリスクを一緒に整理します →
コンプライアンス・スナップショット
- ! オフショアのサーバーでは、リポジトリ・Issue・メタデータが国外に置かれる
- ! GitHub Enterprise CloudはEU・米国・オーストラリア・日本を挙げる——中国本土のリージョンはない
- ! ソースコードは営業秘密・埋め込まれた認証情報・コントリビューターの個人情報を抱える
- ! UIの到達性ではなく保存されたコードが、レジデンシーの問い——PIPL 第38〜40条
- ! CIIOや大量取扱者なら、CSL 第39条（旧第37条）が中国のデータの国内保持を求める
- ✓ GHESは自社運用できる——国内で動かしてコードとメタデータを国内に留める
GitHub Enterprise Serverの公式ドキュメントが中国について述べていること
| 事実 | 一次情報源 |
|---|---|
| GitHub Enterprise Serverは自社運用できる——貴社自身のインフラにデプロイするので、中国本土の内側に置ける。GitHub自身のドキュメントは、GitHub Enterprise Serverを「GitHubプラットフォームの自社運用版」とし、「オンプレミスのデータセンター内の仮想化ハイパーバイザー、またはパブリッククラウドサービスにデプロイできる」と述べる。その自己管理の性質こそ、中国の答えが「不可」ではなく「要注意」である理由だ——リポジトリとそのコントロールプレーンを本土に置ける。 | GitHub Docs — About GitHub Enterprise Server（docs.github.com、2026-10-12 取得） |
| ホスト型エディションには中国本土のリージョンがない。データレジデンシー対応のGitHub Enterprise Cloudは、対象リージョンをEU・オーストラリア・米国・日本と挙げ、デフォルトではGitHub.comのデータを米国に保存する——いずれの選択肢もリポジトリを中国本土に置かない。GitHubでは、国内保存の経路はSaaSではなく自社運用のサーバーだ。 | GitHub Docs — About GitHub Enterprise Cloud with data residency（docs.github.com、2026-10-12 取得） |
| オフショアに保持するリポジトリとコントリビューターの個人情報は、PIPLの下での越境移転である。ソースコードに加え、コミット・Issue・コントリビューターのプロフィール内の個人情報が国境を越えることは、PIPL 第38〜40条（英語）が規律する越境移転（英語）であり、法令に沿った移転メカニズム——CACの安全評価、CAC標準契約、または認証——と、海外移転についての個別の同意を求める。 | 中国個人情報保護法 第38〜40条（21YunBox 訳、2026-10-12 取得） |
| CIIOと大量取扱者は、中国で収集した個人情報を本土に留めなければならない。サイバーセキュリティ法（英語）第39条（旧第37条）——2026年1月1日に施行された2025年改正でデータの国内保存の条項が第37条から第39条へ繰り下げられ、実質は変わらない——の下で、中国で生成された個人情報は国内に保存しなければならず、これはオフショアのSaaSには満たせないが、自社運用のGitHub Enterprise Serverのデプロイなら満たせる義務だ。 | 中国サイバーセキュリティ法 第39条（旧第37条）（21YunBox 訳、2026-10-12 取得） |
情報源は21YunBox コンプライアンスチームが2026年10月12日に確認しました。
中国本土のエンジニアリングチーム向けにGitHub Enterprise Serverを運用する企業にとって、重要な問いは、上海からWeb UIが素早く描画されるかではありません。GitHub Enterprise Serverは、貴社の最も凝縮された知的財産が置かれる場所です：製品のソースコード——営業秘密であり、しばしば認証情報やトークンがその中にコミットされています——に加え、Issue、プルリクエストの議論、Wiki、それらすべてをインデックスするコントロールプレーン、そして一行でも触れたすべてのコントリビューターの身元。それをオフショアのサーバーで動かせば、その全体と、そこに織り込まれた個人情報は国外に置かれ、開発者がcloneやpushをするたびに国境を越えます。ここでのコンプライアンスの軸はレイテンシではなく、レジデンシーと越境移転です。GitHub Enterprise Serverがホスト型エディションと異なるのは、それが 自社運用できる エディションだということ——つまり中国の問いに答える梃子が実際に存在します：サーバー自体を本土の内側で動かし、コードを国内に留められます。三つの論点が決め手です：コードとメタデータの全体＋コントリビューターの個人情報の、レジデンシーと越境のリスク。到達性チェックでは決して見えない特徴的な後半——オフショアに置かれるのは、それらへのアクセスではなく、リポジトリ・Issue・コントロールプレーンそのものだということ。そして、自己ホスト型ランナーはジョブを実行するだけで、コードを国内へ動かしはしないというDevOpsの教訓です。
中国でのGitHub Enterprise Server：ひと目で
| 決め手 | GitHub自身の言葉で——そして中国の法で |
|---|---|
| 何を保持するか | 貴社の最も凝縮された知的財産：製品のソースコード（営業秘密であり、しばしばその中にコミットされた認証情報やトークン）、Issue、プルリクエストの議論、Wiki、それらをインデックスするコントロールプレーン、そしてすべてのコントリビューターの身元——あらゆるコミットの氏名とメールアドレス。それらが人を名指し・描写するところは、どこでも個人情報です。 |
| 自社運用できる——その梃子（前提） | GitHub Enterprise Serverは自社運用のエディションです：GitHubのドキュメントはそれを"a self-hosted version of the GitHub platform"（GitHubプラットフォームの自社運用版）と呼び、"to a virtualization hypervisor within your on-premises datacenter, or to a public cloud service"（オンプレミスのデータセンター内の仮想化ハイパーバイザー、またはパブリッククラウドサービス）にデプロイすると述べます。つまり中国本土の内側で動かし、コードを国内に留められます。対照的にホスト型のGitHub Enterprise Cloudは、データレジデンシーの対象リージョンをEU・米国・オーストラリア・日本にしか挙げず——中国本土のリージョンはありません。 |
| コード全体がオフショア——特徴的な後半 | 到達性チェックでは決して見えない後半です。問いは、上海からWeb UIを開けるかではなく——リポジトリ・Issue・それらを保持するコントロールプレーンがオフショアに置かれ、cloneとpushのたびに国境を越えることです。ページ読み込みテストはサインイン画面の描画を見るだけで、どのホストがコードを保持するか、コミット履歴にどんな個人データがあるか、貴社のコードベース全体が国外に凝縮されているかは見えません。 |
| 自己ホスト型ランナーはコントロールプレーンではない | DevOpsの落とし穴です。自己ホスト型ランナーはジョブを実行するだけで、ソースコード・シークレット・Issue履歴・コントロールプレーンは依然としてサーバーが動く場所にあります。UIを到達可能にしたり、ランナーを国内に置いたりしても、コードは一切国内へ動きません。GitHub Enterprise Serverのインスタンス自体を本土で動かすことが、それを動かします。 |
| レジデンシーと越境 | リポジトリとコントリビューターの個人情報をオフショアに保持することは、PIPL 第38〜40条の下での越境移転（英語）（数据出境）であり、第13条・第23条の通知と、海外移転についての個別の同意が上に乗ります。重要情報インフラ運営者または大量取扱者には、サイバーセキュリティ法 第39条（旧第37条）（英語）が、中国で収集した個人情報を本土に保存することを求めます——オフショアのSaaSには満たせず、国内の自社運用インスタンスには満たせるものです。 |
| 到達性は軸ではない | 本土からWeb UIが素早く開くかは運用の問題であって、コンプライアンスの問いではありません。決め手は、コードと個人情報がどこにあり、どんな同意の下にあるかです。21YunBoxは、その規律対象の中身を国内インスタンスに留め、本土を離れるものの移転根拠を確保し、中国向けの表面をICP備案し、開発者のアクセスを法令に沿って配信すること——21YunBox Optimizer——を、すでに運用中のサーバーの前段で支援します。いかなる種類の不正な手段も用いません。 |
実際に保持するもの——貴社のソースコード、シークレット、コントリビューターの身元
GitHub Enterprise Serverは一般向けのマーケティングサイトではありません。それは貴社の最も凝縮された知的財産の在処であり、ソフトウェアがどう作られているかの驚くほど完全な記録を保持します。どのリポジトリも製品のソースコードであり——定義上の営業秘密で、実務上しばしば認証情報・APIキー・トークンが履歴にコミットされています。コードの周りにはIssue、プルリクエストの議論、コードレビュー、Wiki——何を作っているかの、そしてセキュリティ上の発見の中では、どこが最も弱いかの、現在進行形の地図——が並びます。さらにインスタンスは、貢献したすべての人の身元を抱えます：あらゆるコミットに結び付いた氏名とメールアドレス、そして誰が何をいつ変えたかのメタデータです。それらの記録が人を名指し・描写するところは、どこでも中国の個人情報保護法の下での個人情報です。総体として、GitHub Enterprise Serverのインスタンスは貴社のエンジニアリング組織の凝縮された姿であり——それが本土にあるかオフショアにあるかは、サーバーをどこで動かすかで決まります。GitHub Enterprise Serverは、貴社自身が中国に置ける自社運用エディションだからです。
二つの扉：レジデンシー、越境、そしてICPの表面
インスタンスをオフショアのサーバーに置くと——あるいは中国本土のリージョンを持たないホスト型のGitHub Enterprise Cloudを取ると——一つ目の扉が開きます。リポジトリ、コミット履歴、コントリビューターの身元が国外に置かれ、それが越境移転（数据出境）になります。義務はGitHubではなく、顧客である貴社にかかります：PIPL 第13条・第23条は収集の通知と根拠を求め、第38〜40条はオフショアへ送るための移転メカニズム——CACの安全評価、CAC標準契約、または認証——と、海外移転についての個別の同意を求めます。
重要情報インフラ運営者または大量取扱者には、サイバーセキュリティ法（英語）の第39条（旧第37条——2025年のサイバーセキュリティ法改正は2026年1月1日に施行され、データの国内保存の条項を第37条から第39条へ繰り下げましたが、実質は変わりません）が、中国で生成した個人情報を本土に保存することを求めます。オフショアのSaaSには中国リージョンがなくこの義務を満たせませんが、本土に置いた自社運用のGitHub Enterprise Serverのデプロイなら満たせます——だからこそ、ここでの中国の答えは「不可」ではなく「要注意」なのです。
そして、インスタンスに紐付いた一般向けの中国向けの表面を公開した瞬間——外部に提供する開発者ポータル、ドキュメントやリリースのサイト、本土のユーザーに提供するステータスページ——その表面はインターネット情報サービスであり、本土のホスティングリソースに紐付いたICP備案の義務を担います。純粋に社内向けのGitHub Enterprise Serverインスタンスは単体ではICPを発動させないかもしれませんが、中国のユーザーに提供する一般向けの表面はそれを発動させます。
自己ホスト型ランナーはコントロールプレーンではない
自己ホスト型ランナーを中国に置けばレジデンシーの問いに答えられる、と考えたくなります。答えられません。ランナーはジョブを実行するだけで、ソースコード・シークレット・Issue履歴・それらをインデックスするコントロールプレーンは、依然としてGitHub Enterprise Serverのインスタンスが動く場所にあります。Web UIを本土から到達可能にしたり、そこにランナーを置いたりしても、コードは一切国内へ動きません——ビルドがたまたま走る場所を変えるだけです。レジデンシーの問いは、サーバーとそのコントロールプレーンがどこにあるかで答えられるのであって、到達性でもランナーでもありません。GitHub Enterprise Serverのインスタンス自体を本土で動かすことが、リポジトリ・メタデータ・コントリビューターの個人情報を国内に留めます。
到達性チェックがこれを見逃す理由
中国の内側からのプローブは、GitHub Enterprise Serverのサインイン画面が描画されるのを見て「動く」と結論できます。その答えは的外れです。コンプライアンスのリスクは画面上にはなく——保存されたデータと、その動き方の中にあります：リポジトリ、埋め込まれたシークレットを含むコミット履歴、Issue、コントリビューターの身元が、すべてサーバー上にあり、そのサーバーがオフショアなら、cloneとpushのたびに国境を越えます。ページ読み込みテストはそのいずれも測れません。どのホストがコードを保持するか、個別の同意が取られたか、移転メカニズムがあるか、貴社のコードベース全体が国外に凝縮されているかは、見えません。それが、この問いの対手には再現できない後半であり——オフショアのサーバーを本土から単に 到達可能 にすることが答えにならない、まさにその理由です。自社運用エディションを国内で動かし、コードと個人情報をそこに留めること、それが答えです。
法令に沿った経路——map・localize・deliver
中国本土の運用向けにGitHub Enterprise Serverを動かす法令適合の方法があり、それはすでに運用中のインスタンスの前段に収まります——作り直しも移行もなく、データをひそかにオフショアへ送る経路も決してありません。
まず、map（整理）：当社の中国コンプライアンスチームが、インスタンスが何を保持するか——リポジトリ、履歴にコミットされたシークレット、Issueとプルリクエストの議論、コントリビューターの身元——を棚卸しし、サーバーとそのコントロールプレーンがどこでどんなレジデンシー根拠で動くか、中国向けの表面のICPの状況、そして凝縮されたコードと個人情報が国内保存義務を引き起こすかを確認します。技術的な全体像は当社が組み立て、法的な結論は専門家と詰めます。
次に、localize（国内化）：GitHub Enterprise Serverは自社運用できるので、ローカライズは本物の選択肢です——自己管理のインスタンスを国内インフラ上で動かし、コード・Issue・シークレット・コントロールプレーンを本土に留め、コミットとIssueに入る個人データを最小化し、コントロールプレーンを統制し、なお国境を越えるものについては第13条・第23条の通知と個別の同意を取得します。ローカライズとは、データを国内経路に留めることであり——データを国外へ送ったり、国境を越えて取りに戻ったりする、いかなる種類の経路でもありません。
次に、deliver（配信）：一般向けの中国向けの表面はいずれもインターネット情報サービスなので、ICP備案の義務を担い、法令に沿った国内からの配信を必要とします。そして開発者は、本土からインスタンスへの速く信頼できるアクセスを必要とします。21YunBoxはそれを国内から配信します——21YunBox Optimizer——すでに運用中のGitHub Enterprise Serverの前段で。これにより、開発者のアクセスと中国向けの表面は、中国のユーザーに対して合法かつ法令適合に稼働します。21YunBoxはいかなる種類の不正な手段も用いず、また推奨しません——法が留めよと言うものは国内に留め、残りは本土の内側から法令に沿って配信し、個人情報をひそかに国境を越えて移すことは決してありません。21YunBoxは、すでに運用中のプラットフォームへの、コンプライアンスのオーバーレイでありパートナーであって、競合ではありません。
これはいずれも、GitHub Enterprise Serverが中国で「遮断されている」または「違法」だという判定ではありません。リスクとレジデンシーの見取り図です。どの義務が貴社のケースに効くかは、貴社の法人、中国法上の役割、データ量、そしてインスタンスが実際に何を保持するかで変わります——貴社の組織のコードベース全体がそれに依存する前に、専門家と具体を詰める価値があります。
関連する読み物：
よくあるご質問
GitHub Enterprise ServerはGitHub.comやGitHub Enterprise Cloudと同じですか？
いいえ。GitHub Enterprise Serverは、貴社自身のインフラで動かす自社運用・自己管理のエディションです——GitHubのドキュメントはそれを、オンプレミスのハイパーバイザーや自社のクラウドにデプロイできる「GitHubプラットフォームの自社運用版」と呼びます。GitHub.comとGitHub Enterprise Cloudはホスト型のSaaSで、GitHub Enterprise CloudのデータレジデンシーはEU・オーストラリア・米国・日本しか挙げません——中国本土のリージョンはありません。この違いこそ中国にとっての要点です：自社運用のサーバーは本土の内側に置けてコードを国内に留められますが、SaaSはそれができません。
中国本土の自社サーバーでGitHub Enterprise Serverを動かせますか？
はい——それが自己管理モデルの要点です。GitHubは「オンプレミスのデータセンター内の仮想化ハイパーバイザー、またはパブリッククラウドサービスにデプロイできる」と述べるので、本土でのデプロイは可能であり、まさにそれがリポジトリ・Issue・シークレット・コントロールプレーンを本土に留める手立てです。自社運用が単体で与えないのは、中国向けの一般向け表面のICP備案、PIPLの同意、そして本土を離れるものの越境ルールの充足です——それらは運営者の義務として残り、専門家と詰めるべきものです。
自己ホスト型ランナーを中国に置けば、それで法令適合になりますか？
いいえ。自己ホスト型ランナーはジョブを実行するだけで、ソースコード・シークレット・Issue履歴・コントロールプレーンは依然としてGitHub Enterprise Serverのインスタンスが動く場所にあります。UIを到達可能にしたり、ランナーを国内に置いたりしても、コードは一切国内へ動きません——ビルドがたまたま走る場所が変わるだけです。レジデンシーの問いは、サーバーとそのコントロールプレーンがどこにあるかで答えられます。GitHub Enterprise Serverのインスタンス自体を本土で動かすことが、コードとコントリビューターの個人情報を国内に留めます。
