GitHub Enterprise Serverとは？オンプレGitHubの要件・料金・サポート期限とCloudとの違い

GitHub Enterprise Server（GHES）は、GitHubを自社のデータセンターやクラウドの仮想マシン上で動かすセルフホスト版です。2026年10月15日時点の最新は3.22系（最新パッチ3.22.2・2026年10月6日公開）で、サポート中の版は3.19〜3.22の4つ。料金はGitHub Enterpriseプランとして1ユーザー月額21ドルからで、同じプランでクラウド版のGitHub Enterprise Cloud（GHEC）も使えます。この記事では、GHESを選ぶか判断するのに必要な要件・料金・版の管理とアップグレードの規則を、GitHub公式ドキュメントの記載に沿って整理します。

まとめ：GitHub Enterprise Serverの要点

• 正体：GitHubが配布する仮想アプライアンス。VMware ESXi・Hyper-V・OpenStack KVMか、AWS・Azure・Google Cloudに載せて自社で運用します。
• Cloudとの分かれ目：データの置き場所だけが要件なら、日本リージョンを選べるGHEC with data residencyが公式の推奨です。ネットワークやIAMまで自社で統制したい場合にGHESを選びます。
• 料金：GitHub Enterpriseプランが1ユーザー月額21ドルから（料金ページ表記は「最初の12か月」の価格）。GHESはこれに仮想基盤とストレージの費用が加わります。
• 要件：最小は4 vCPU・32GBメモリ・ルート400GB・データ500GB。1,000ユーザーまでなら8 vCPU・48GB。Actionsを有効にするならCPUとメモリを25%以上上乗せします。
• サポート期限：機能リリースは四半期ごと、各版のサポートは原則リリースから1年。3.19は2026年12月9日に終了します。
• アップグレード：1回で進めるのは2つ先の機能リリースまで（3.20→3.22は可）。同じ系列のパッチはホットパッチで当てられます。

以下、定義、Cloudとの比較、料金、要件、版の管理、運用（脆弱性・バックアップ・Copilot）の順に説明します。

GitHub Enterprise Server（GHES）の定義と動く環境

公式ドキュメントはGHESを「a self-hosted version of the GitHub platform」と説明しています。中身は自己完結型の仮想アプライアンスで、VMにインストールするとLinuxと専用のアプリケーションスタックが起動します。About GitHub Enterprise Serverには「Installing third-party software or making changes to the underlying operating system is not supported.」とあり、ウイルス対策ソフトや監視エージェントをOSに直接入れる運用はサポート対象外になります。監視は管理用SSH・REST/GraphQL API・外部へのメトリクス転送で組み立てる前提です。

GHE・GHES・GHECの呼び分け

「GHE」はGitHub Enterpriseプランの総称で、その中にセルフホストのGHES（Server）と、GitHubが運用するGHEC（Cloud）の2つの導入形態があります。GitHubのプラン説明も「GitHub Enterprise includes two deployment options」と書いており、ServerとCloudは同じGitHub Enterpriseプランで利用できる導入形態ですが、利用可能な機能と運用責任は異なります。GHECはさらに、github.com上で使う通常版と、GHE.comの専用サブドメインでデータ所在地を選べる「with data residency」版に分かれます。

対応する仮想基盤とクラウド

サポートされる基盤は、オンプレミスのMicrosoft Hyper-V・OpenStack KVM・VMware ESXi（5.5〜8.0）と、AWS・Google Cloud・Microsoft Azureです。イメージはGitHub Enterprise ReleasesかMicrosoft Marketplace（GitHubまたはMicrosoftが公開したもの）から取得したものだけが対象です。CPUはx86-64のみで、AArch64・arm64のVMでは動きません。Gravitonなどのarm系インスタンスで原価を下げる設計は使えないので、クラウドに置く場合も最初からx86系で見積もります。

GHESとGitHub Enterprise Cloudの違いと選び方

両者の差は機能の多寡より「誰が運用し、新機能がいつ届くか」にあります。公式の説明によると、新機能の多くはまずGitHub.comで公開され、GHESには機能リリースを通じて後から届きます。

データ所在地が要件ならGHEC with data residency

「ソースコードを国内に置きたい」が主な理由なら、GHESより先にGHEC with data residencyを検討します。ただしデータ保管の説明によると、リージョン内に置かれるのはコードとユーザーデータで、一部のデータはリージョン外に保存・転送されます。たとえばCopilotのデータとログは既定でリージョン外に置かれ、専用のポリシーを有効にしたときだけリージョン内に留まります。公式ドキュメントが挙げる保存先リージョンはEU・Australia・US・Japanの4つで、GHESの説明ページ自身も「If your main compliance requirement is for your company’s data to reside in a specific region, you may want to consider GitHub Enterprise Cloud with data residency.」と案内しています。この形態はEnterprise Managed Usersが前提で、利用者はGHE.comの専用サブドメインからアクセスし、パブリックリポジトリは作れません。

GHESを選ぶ条件と避けるべき場面

GHESを選ぶのは、インターネットから隔離したネットワークで開発する、ファイアウォールやIAMを自社の統制下に置くことを規程で求められる、既存のLDAPで認証したい、といった「置き場所以外」の要件があるときです。反対に、Linuxを運用できる担当者がいない組織にはおすすめしません。公式も「people with Linux administration experience are more successful」と書いており、四半期ごとのアップグレード、ホットパッチの適用、バックアップの検証を回せる体制が前提になります。Copilotのエージェント機能を全社で使いたい場合も、GHESでは届く機能が限られるためGHECが向きます。

GHESとGitLabのセルフホスト版を比べている場合は、GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較で両者の自己ホスト時の差を整理しています。

GitHub Enterprise Serverの料金とライセンス

GitHubの料金ページでは、Enterpriseプランは「Starting at $21 USD per user/month」と表示され、価格の横に「for the first 12 months」の注記が付いています（2026年10月15日確認）。13か月目以降の単価はページ上の記載から読み取れないため、複数年で予算を組むときは営業に確認してください。このプランでGHECとGHESの両方を使えます。100ユーザーなら定価ベースで月額2,100ドル、年25,200ドルが出発点で、GHESではこれに次の費用が加わります。

• 仮想基盤：後述の要件表どおりのvCPU・メモリと、IOPSの高いSSD
• バックアップ先：内蔵バックアップサービスはデータディスク使用量の5倍以上の容量を推奨
• 高可用性を組む場合のレプリカ用VM（本番と同等の構成）
• GitHub Actionsを使う場合の外部Blobストレージとセルフホストランナー
• GitHub Secret Protection・GitHub Code Securityなどのアドオン

購入後は、GitHubが発行するライセンスファイルをインスタンスにアップロードして使います。ライセンスファイルの説明によると、ファイルには有効期限と利用人数が入っており、期限が切れるとブラウザからもGitからもアクセスできなくなります（コマンドラインからのバックアップは可能）。更新手続きの遅れがそのまま開発停止につながるので、期限日は契約管理の台帳に載せておきます。

評価用には45日間の無料トライアルがあります。ただしトライアルではDependabotアラートとGitHub Connectが使えません。この2つを前提に評価する場合は、営業経由でデモを依頼します。

システム要件とユーザー数別のサイジング

VMwareへのインストール手順に載っている最小推奨構成は次のとおりです（3.22時点）。ユーザー数はライセンス数で数えます。

見落としやすいのは次の3点です。

• ルートディスクの既定は200GB：クラスタ以外の構成では、デプロイ前にOVFテンプレートで400GBへ増やすよう推奨されています。起動後に使えるのはその半分で、残りはアップグレード用の予備領域です。
• 機能ごとの上乗せ：GitHub ActionsとGitHub Code Securityは、それぞれCPUとメモリを25%以上増やします。両方使う1,000ユーザー規模なら、8 vCPU・48GBを基準に余裕を見て積み増し、稼働後のリソース監視で調整します。
• vCPUを足すときのメモリ：16 vCPUまではvCPUごとに6.5GB以上のメモリ追加が推奨です。

GitHub ActionsをGHESで使うには、Azure Blob・Amazon S3・Google Cloud Storage・MinIOのいずれかの外部Blobストレージと、セルフホストランナーが別に必要です。ランナーの構成はGitHubセルフホストランナーとは？導入手順とhosted版の違いを参照してください。

GHESのバージョンとサポート期限（2026年10月時点）

GHESは「3.22」のような機能リリースを四半期ごとに出し、その間にパッチリリース（3.22.1、3.22.2…）を挟みます。GitHub Enterprise Server releasesには「GitHub supports at least the four most recent feature releases.」とあり、2026年10月15日時点の状況は次のとおりです。

サポート期間は原則としてリリースから1年ですが、延長された版もあります。3.14は2024年8月27日のリリースから2026年4月23日まで約20か月、3.17も約16か月サポートされました。延長は後から告知されるため、「1年後」と決め打ちで計画せず、四半期ごとにこのページを確認します。サポートが終わった版はセキュリティ修正が出なくなり、アップグレードパッケージの入手も難しくなります。

公式リリース表に基づくサポート残日数・更新経路の計算

社内のインスタンスが複数あると、表を目で追うのは手間です。GitHub DocsはMarkdown本文を返すAPIを公開しているので、次のPythonスクリプトでサポート状況と残り日数、現在の版からのアップグレード経路を出せます。標準ライブラリだけで動きますが、GitHub DocsへのHTTPS接続が必要です。表の書式が変わって解析できないときは、エラーで止まるようにしています。

import re, sys, urllib.request, datetime

URL = "https://docs.github.com/api/article/body?pathname=/en/enterprise-server@latest/admin/all-releases"
req = urllib.request.Request(URL, headers={"User-Agent": "Mozilla/5.0"})
md = urllib.request.urlopen(req, timeout=30).read().decode()

rows = []
for line in md.splitlines():
    m = re.match(r"\|\s*(3\.\d+)\s*\|\s*([\d-]+)\s*\|\s*([\d-]+)\s*\|\s*([\d-]+)\s*\|(.*?)\|", line)
    if m:
        ver, _, rel, close, cell = m.groups()
        rows.append((ver, rel, close, "octicon-check" in cell))

today = datetime.date.today()
current = sys.argv[1] if len(sys.argv) > 1 else "3.18"
if not rows:
    sys.exit("リリース表を解析できません。取得内容と表の書式を確認してください。")
if current not in [r[0] for r in rows]:
    sys.exit("現在の版は、取得した表に含まれる機能リリース番号で指定してください（例: 3.18）。")
print(f"基準日 {today} / 現在の版 {current}")
for ver, rel, close, ok in rows[:6]:
    left = (datetime.date.fromisoformat(close) - today).days
    print(f"{ver:5} release {rel} closing {close} {'supported' if ok else 'ended':9} 残り{left}日")

# 1回のアップグレードで進めるのは最大2つ先の feature release まで
order = [r[0] for r in rows][::-1]
latest = rows[0][0]
i, path = order.index(current), [current]
while path[-1] != latest:
    i = min(i + 2, order.index(latest))
    path.append(order[i])
print("経路:", " -> ".join(path))

2026年10月15日に python3 ghes_support.py 3.18 で実行した結果です。

基準日 2026-10-15 / 現在の版 3.18
3.22  release 2026-09-08 closing 2027-09-08 supported 残り328日
3.21  release 2026-06-11 closing 2027-06-11 supported 残り239日
3.20  release 2026-03-17 closing 2027-03-17 supported 残り153日
3.19  release 2025-12-09 closing 2026-12-09 supported 残り55日
3.18  release 2025-10-14 closing 2026-10-14 ended     残り-1日
3.17  release 2025-06-03 closing 2026-09-24 ended     残り-21日
経路: 3.18 -> 3.20 -> 3.22

3.18で止まっているインスタンスは、3.20を経由して3.22へ上げる2段階になります。経路の計算は公式の「2つ前まで」の規則を当てはめただけなので、実行前に公式のUpgrade assistantで同じ経路が出るか確認します。

GitHub Enterprise Serverのバージョンを確認する方法

版の確認は管理用SSHか、REST APIで行います。管理用SSHはポート122に admin ユーザーで接続し、コマンドラインユーティリティの ghe-version を実行すると、版・プラットフォーム・ビルドが表示されます。

ssh -p 122 [email protected]
ghe-version

SSH権限を持たない開発者やインベントリ収集のスクリプトからは、REST APIのmetaエンドポイントが返す installed_version を読みます。GHESのAPIはホスト名の後ろに /api/v3 が付く点がGitHub.comと違います。

curl -s -H "Authorization: Bearer $TOKEN" \
  https://ghes.example.co.jp/api/v3/meta | jq -r .installed_version

取得した版を前章のサポート表と突き合わせれば、終了が近いインスタンスを機械的に洗い出せます。

アップグレードの規則と手順

Upgrade requirementsで必須とされている規則は次の4つです。

• 2つ前の機能リリースまでしか直接上げられない：3.22へ上げられるのは3.21か3.20から。3.19以前は中間の版を経由します。
• 系列内のパッチはホットパッチで当てられる：3.22.1→3.22.2のような同系列の更新はホットパッチで済みます。機能リリースをまたぐ更新（3.21→3.22）はアップグレードパッケージが必要です。
• アップグレードパッケージの適用時はメンテナンス時間を取る：利用者に告知した停止時間内で行います。
• 事前に容量チェックを行う：プリフライトチェックでメモリ・CPU・ディスクが足りないと、アップグレードは中断されます。

推奨事項として、ステージング環境での事前検証、VMスナップショットの取得、直近のバックアップの確認が挙がっています。複数段階で上げるときは、ghe-migrations と ghe-check-background-upgrade-jobs で裏のデータ移行が終わったのを確かめてから次の版へ進みます。リリース候補版（RC）は本番に入れてはいけません。RCから正式版へ上げることもできず、検証環境ごと作り直す扱いです。

3.21.2からは、停止を伴わない事前処理（pre-upgrade）だけをメンテナンス時間の外で先に流せるようになり、3.22で機能とドキュメントが拡充されました。リリースノートによると、これでメンテナンス時間内の作業を最大20分短縮できます。

ghe-upgrade --phase pre-upgrade GITHUB-UPGRADE.pkg
# メンテナンス時間に入ってから
ghe-upgrade --phase upgrade GITHUB-UPGRADE.pkg

アップグレードパッケージはenterprise.github.comでサポート中の版向けに提供されます。サポート終了から時間がたった版は入手できないことがあり、その場合はGitHubのサポートへの問い合わせが必要です。上げ遅れるほど手順も増えるので、最低でも年1回、できれば機能リリースのたびに上げる運用にしておくと安全です。

脆弱性情報の確認とセキュリティ修正の当て方

GHESの脆弱性は、各版のリリースノートの「Security fixes」に、CRITICAL・HIGH・MEDIUMなどの深刻度付きで載ります。直近の例では、3.22.1（2026年9月22日）でCRITICALの修正がありました。ノートブックビューアのURLに明示的なポート番号を指定すると、アプライアンス内部のサービスに到達でき、応答時間の差から秘密情報を抜き出してリモートコード実行につなげられたという内容です。プライベートモードが無効なインスタンスでは認証なしで悪用できました。過去にはCVE-2024-9487（CVSS v4.0で9.5）のように、暗号化アサーションを有効にしたSAML SSOの署名検証を回避してユーザーを作れる脆弱性もあり、3.11.16・3.12.10・3.13.5・3.14.2で修正されています。3.22.2（2026年10月6日）でも、シークレットスキャンの有効性チェックを悪用したSSRFがHIGHで修正されています。

こうした修正の多くはパッチリリースで届くので、運用で押さえるのは次の2点です。

• パッチはホットパッチで早く当てる：ホットパッチは再起動不要な場合が多く、パッチリリースの停止時間は通常5分未満です。カーネル・MySQL・Elasticsearchが対象のときは再起動が必要になり、その旨が通知されます。自動更新チェックを有効にすると、対象のホットパッチを自動で適用できます。
• サポート外の版は修正が出ない：終了した版で新しい脆弱性が見つかっても修正は提供されません。前章のサポート表で、終了日の前に上げ終える計画を立てます。

リリースノートを定期的に確認する担当を決めておき、CRITICALの修正が出たら直ちに影響と悪用条件を確認し、対象インスタンスには緊急適用できる手順を用意します。

バックアップと高可用性の組み方

GHESのデータ保護にはバックアップを用意し、障害時に許容できる停止時間が短い場合は高可用性（HA）レプリカを併用します。両者は役割が異なり、HAだけでは過去の正常な状態へ復元できません。

内蔵のバックアップサービスとBackup Utilities

以前は別ホストにGitHub Enterprise Server Backup Utilities（ghe-backup・ghe-restore）を置くのが標準でした。現在はGHESに組み込まれたバックアップサービスが3.20で一般提供になり、Backup UtilitiesのREADMEには「Backup Utilities will be retired starting in GitHub Enterprise Server 3.22.」と書かれています。新しく構築するなら内蔵サービスを選びます。

バックアップサービスの設定手順が求める条件は、3.17以降の版であること、専用のストレージボリュームを用意すること、容量をデータディスク使用量の5倍以上にすることです。ファイルシステムはハードリンクとシンボリックリンクに対応し、大文字と小文字を区別する必要があり、NFSはタイムアウトの原因になるため避けるよう書かれています。3.22.2では、ElasticsearchのスナップショットをAzure Blob・Amazon S3・Google Cloud Storageへ増分で取る設定も追加されました。

HAレプリカで防げる障害と防げない障害

HA構成は、Gitリポジトリ・MySQL・Redis・Elasticsearchを本番からレプリカへ一方向・非同期で複製するアクティブ/パッシブ方式です。ソフトウェアのクラッシュ、ハードウェア障害、仮想基盤の停止には効きますが、バックアップの代わりにはなりません。本番でデータが壊れると、その状態がすぐレプリカにも複製されるためです。無停止アップグレードの手段にもならず、切り替え時は本番をメンテナンスモードにしてから昇格させます。レプリカはパッシブ・ジオレプリカ・リポジトリキャッシュを合わせて最大8台です。なお、3.22でクラスタ構成のHAレプリケーションは廃止されました。

GHESでのGitHub CopilotとGitHub Connect

GHESを選ぶ前に確認したいのがAI機能の扱いです。Copilotのプラン説明には「Copilot is not currently available for GitHub Enterprise Server.」とあり、IDEの補完・チャット・コーディングエージェントはGHESのアカウントでは使えません。公式もCopilotなどの最新機能をGHECの利点として挙げています。3.22で入ったのは、GitHubのクラウドに接続せずにCopilot CLIを使う機能の技術プレビューです。管理者が ghe-config でOpenAI互換・Azure・Anthropicのいずれかのモデル提供元を設定すると、利用者はGHESの認証情報でCopilot CLIを使えます。完全な閉域運用には、モデル提供元も閉域内に置く必要があります。またGitHubのクラウドに依存する機能は使えず、GitHub MCPサーバーのツール、Web検索とWebページ取得、GitHubがホストするモデルの選択、自動更新などは対象外です。プレビュー段階なので、本番の開発基盤の前提にするのはまだ早いと判断します。オンプレミス環境でCopilotを使う構成の選択肢はGitHub Copilotはオンプレミスで使える？GHES非対応の代替構成とデータの扱い・料金で詳しく扱っています。

GitHub.comの機能を一部取り込む手段がGitHub Connectです。GHECのEnterpriseアカウントと接続すると、ライセンス使用数の自動同期、Dependabot、GitHub.comのアクションの利用、検索結果の統合などを個別に有効化できます。通信は443番か80番ポートのHTTPSで、GHESがインターネットに公開されるわけではありません。完全に閉じたネットワークではこれらが使えないため、Dependabotアラートを使えるかどうかがGHESの評価で差になります。

GHESの導入やGitHub Actionsを含むCI/CD基盤の構築を外部に相談したい場合は、DevOps・CI/CD導入支援で設計から運用まで対応しています。

よくある質問

GHESとは何の略ですか？

GitHub Enterprise Serverの略です。GitHub Enterpriseプランのうち、自社の仮想基盤で動かすセルフホスト版を指します。GitHubが運用するクラウド版はGHEC（GitHub Enterprise Cloud）と呼ばれます。

GitHub Enterprise Serverの価格はいくらですか？

料金ページの表示ではGitHub Enterpriseプランが1ユーザー月額21ドルからで、「最初の12か月」の価格として表示されています。このプランでServerとCloudの両方を使えます。GHESではさらにVM・ストレージ・バックアップ先・HAレプリカの費用がかかります。

GitHubをオンプレミスで使えますか？

使えます。GHESをVMware ESXi・Hyper-V・OpenStack KVMに載せれば自社のデータセンター内で動きます。データを国内に置くことだけが目的なら、日本リージョンを選べるGHEC with data residencyも候補です。

GitHub Enterprise Serverのダウンロードはどこからできますか？

イメージとアップグレードパッケージはGitHub Enterprise Releases（enterprise.github.com/releases）から入手します。起動後にライセンスファイルをアップロードしないと使えないため、購入前なら45日間のトライアルを申し込みます。

GitHub Enterprise Serverのサポート期限はどのくらいですか？

各機能リリースのサポートは原則としてリリースから1年で、少なくとも直近4つの機能リリースがサポート対象です。2026年10月時点では3.19〜3.22がサポート中で、3.19は2026年12月9日に終了します。延長される版もあるので、公式のリリース一覧で確認してください。

関連記事

• GitHub Copilotはオンプレミスで使える？GHES非対応の代替構成とデータの扱い・料金【2026年版】
• GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較
• GitHubセルフホストランナーとは？導入手順とhosted版の違い【2026年版】
• GitHub SSOの設定とログイン｜SAML連携とPAT・SSH・gh CLIの認可【2026年10月】
• GitHub Actionsとは？できること・使い方とCI/CD自動化の活用例をわかりやすく解説