--- title: "GitHub Enterprise Serverとは？オンプレGitHubの要件・料金・サポート期限とCloudとの違い" url: "https://www.issoh.co.jp/column/details/2959/" published: 2024-07-05 updated: 2026-10-15 categories: ["インフラ"] publisher: "株式会社一創" --- # 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](https://docs.github.com/en/enterprise-server@latest/admin/overview/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のプラン説明](https://docs.github.com/en/get-started/learning-about-github/githubs-plans)も「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](https://enterprise.github.com/releases/)かMicrosoft Marketplace（GitHubまたはMicrosoftが公開したもの）から取得したものだけが対象です。CPUはx86-64のみで、AArch64・arm64のVMでは動きません。Gravitonなどのarm系インスタンスで原価を下げる設計は使えないので、クラウドに置く場合も最初からx86系で見積もります。 ## GHESとGitHub Enterprise Cloudの違いと選び方 両者の差は機能の多寡より「誰が運用し、新機能がいつ届くか」にあります。[公式の説明](https://docs.github.com/en/enterprise-server@latest/admin/overview/about-github-enterprise-server)によると、新機能の多くはまずGitHub.comで公開され、GHESには機能リリースを通じて後から届きます。 | 比較項目 | GHES（Server） | GHEC（Cloud） | | -------------- | -------------------------- | --------------------- | | 運用主体 | 自社（VM管理・GHES更新・バックアップ） | GitHub | | データの置き場所 | 自社の基盤内 | 米国、またはEU・豪州・米国・日本から選択 | | 新機能の反映 | 四半期ごとの機能リリースで遅れて反映 | 随時 | | メンテナンス停止 | 自社で計画（アップグレード時） | 計画不要 | | GitHub Copilot | Copilot CLIのみ技術プレビュー（3.22） | 利用可 | | 外部認証 | CAS・LDAP・SAML | SAML・OIDC（EMU） | | ライセンス | GitHub Enterpriseプランに含まれる | 同左 | ### データ所在地が要件ならGHEC with data residency 「ソースコードを国内に置きたい」が主な理由なら、GHESより先にGHEC with data residencyを検討します。ただし[データ保管の説明](https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency/about-storage-of-your-data-with-data-residency)によると、リージョン内に置かれるのはコードとユーザーデータで、一部のデータはリージョン外に保存・転送されます。たとえばCopilotのデータとログは既定でリージョン外に置かれ、専用のポリシーを有効にしたときだけリージョン内に留まります。[公式ドキュメント](https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency/about-github-enterprise-cloud-with-data-residency)が挙げる保存先リージョンは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の対応表・料金・セルフホスト比較](/tech/details/4219/)で両者の自己ホスト時の差を整理しています。 ## GitHub Enterprise Serverの料金とライセンス [GitHubの料金ページ](https://github.com/pricing)では、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が発行するライセンスファイルをインスタンスにアップロードして使います。[ライセンスファイルの説明](https://docs.github.com/en/enterprise-server@latest/billing/concepts/enterprise-billing/ghes-license-files)によると、ファイルには有効期限と利用人数が入っており、期限が切れるとブラウザからもGitからもアクセスできなくなります（コマンドラインからのバックアップは可能）。更新手続きの遅れがそのまま開発停止につながるので、期限日は契約管理の台帳に載せておきます。 評価用には45日間の無料トライアルがあります。ただしトライアルではDependabotアラートとGitHub Connectが使えません。この2つを前提に評価する場合は、営業経由でデモを依頼します。 ## システム要件とユーザー数別のサイジング [VMwareへのインストール手順](https://docs.github.com/en/enterprise-server@latest/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-vmware)に載っている最小推奨構成は次のとおりです（3.22時点）。ユーザー数はライセンス数で数えます。 | ユーザーライセンス数 | vCPU | メモリ | ルート | データ | IOPS | | -------------- | ---- | ----- | ----- | ------- | ------ | | 試用・デモ・軽量10人 | 4 | 32GB | 400GB | 500GB | 600 | | 〜1,000 | 8 | 48GB | 400GB | 500GB | 3,000 | | 1,000〜3,000 | 16 | 64GB | 400GB | 1,000GB | 6,000 | | 3,000〜5,000 | 32 | 128GB | 400GB | 1,500GB | 9,000 | | 5,000〜8,000 | 48 | 256GB | 400GB | 3,000GB | 12,000 | | 8,000〜10,000以上 | 64 | 512GB | 400GB | 5,000GB | 15,000 | 見落としやすいのは次の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版の違い](/tech/details/7759/)を参照してください。 ## GHESのバージョンとサポート期限（2026年10月時点） GHESは「3.22」のような機能リリースを四半期ごとに出し、その間にパッチリリース（3.22.1、3.22.2…）を挟みます。[GitHub Enterprise Server releases](https://docs.github.com/en/enterprise-server@latest/admin/all-releases)には「GitHub supports at least the four most recent feature releases.」とあり、2026年10月15日時点の状況は次のとおりです。 | 版 | リリース日 | サポート終了日 | 状態 | | ---- | ---------- | ---------- | ------------- | | 3.22 | 2026-09-08 | 2027-09-08 | サポート中（最新） | | 3.21 | 2026-06-11 | 2027-06-11 | サポート中 | | 3.20 | 2026-03-17 | 2027-03-17 | サポート中 | | 3.19 | 2025-12-09 | 2026-12-09 | サポート中（残り約2か月） | | 3.18 | 2025-10-14 | 2026-10-14 | 終了 | | 3.17 | 2025-06-03 | 2026-09-24 | 終了 | サポート期間は原則としてリリースから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](https://support.github.com/enterprise/server-upgrade)で同じ経路が出るか確認します。 ## GitHub Enterprise Serverのバージョンを確認する方法 版の確認は管理用SSHか、REST APIで行います。管理用SSHはポート122に `admin` ユーザーで接続し、[コマンドラインユーティリティ](https://docs.github.com/en/enterprise-server@latest/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities)の `ghe-version` を実行すると、版・プラットフォーム・ビルドが表示されます。 ``` ssh -p 122 admin@ghes.example.co.jp ghe-version ``` SSH権限を持たない開発者やインベントリ収集のスクリプトからは、[REST APIのmetaエンドポイント](https://docs.github.com/en/enterprise-server@latest/rest/meta/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](https://docs.github.com/en/enterprise-server@latest/admin/upgrading-your-instance/preparing-to-upgrade/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](https://enterprise.github.com/releases)でサポート中の版向けに提供されます。サポート終了から時間がたった版は入手できないことがあり、その場合はGitHubのサポートへの問い合わせが必要です。上げ遅れるほど手順も増えるので、最低でも年1回、できれば機能リリースのたびに上げる運用にしておくと安全です。 ## 脆弱性情報の確認とセキュリティ修正の当て方 GHESの脆弱性は、各版の[リリースノート](https://docs.github.com/en/enterprise-server@latest/admin/release-notes)の「Security fixes」に、CRITICAL・HIGH・MEDIUMなどの深刻度付きで載ります。直近の例では、3.22.1（2026年9月22日）でCRITICALの修正がありました。ノートブックビューアのURLに明示的なポート番号を指定すると、アプライアンス内部のサービスに到達でき、応答時間の差から秘密情報を抜き出してリモートコード実行につなげられたという内容です。プライベートモードが無効なインスタンスでは認証なしで悪用できました。過去には[CVE-2024-9487](https://nvd.nist.gov/vuln/detail/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](https://github.com/github/backup-utils)（`ghe-backup`・`ghe-restore`）を置くのが標準でした。現在はGHESに組み込まれたバックアップサービスが3.20で一般提供になり、Backup UtilitiesのREADMEには「Backup Utilities will be retired starting in GitHub Enterprise Server 3.22.」と書かれています。新しく構築するなら内蔵サービスを選びます。 [バックアップサービスの設定手順](https://docs.github.com/en/enterprise-server@latest/admin/backing-up-and-restoring-your-instance/configuring-the-backup-service)が求める条件は、3.17以降の版であること、専用のストレージボリュームを用意すること、容量をデータディスク使用量の5倍以上にすることです。ファイルシステムはハードリンクとシンボリックリンクに対応し、大文字と小文字を区別する必要があり、NFSはタイムアウトの原因になるため避けるよう書かれています。3.22.2では、ElasticsearchのスナップショットをAzure Blob・Amazon S3・Google Cloud Storageへ増分で取る設定も追加されました。 ### HAレプリカで防げる障害と防げない障害 [HA構成](https://docs.github.com/en/enterprise-server@latest/admin/monitoring-and-managing-your-instance/configuring-high-availability/about-high-availability-configuration)は、Gitリポジトリ・MySQL・Redis・Elasticsearchを本番からレプリカへ一方向・非同期で複製するアクティブ/パッシブ方式です。ソフトウェアのクラッシュ、ハードウェア障害、仮想基盤の停止には効きますが、バックアップの代わりにはなりません。本番でデータが壊れると、その状態がすぐレプリカにも複製されるためです。無停止アップグレードの手段にもならず、切り替え時は本番をメンテナンスモードにしてから昇格させます。レプリカはパッシブ・ジオレプリカ・リポジトリキャッシュを合わせて最大8台です。なお、3.22でクラスタ構成のHAレプリケーションは廃止されました。 ## GHESでのGitHub CopilotとGitHub Connect GHESを選ぶ前に確認したいのがAI機能の扱いです。[Copilotのプラン説明](https://docs.github.com/en/copilot/get-started/plans)には「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非対応の代替構成とデータの扱い・料金](/tech/details/3673/)で詳しく扱っています。 GitHub.comの機能を一部取り込む手段が[GitHub Connect](https://docs.github.com/en/enterprise-server@latest/admin/configuring-settings/configuring-github-connect/about-github-connect)です。GHECのEnterpriseアカウントと接続すると、ライセンス使用数の自動同期、Dependabot、GitHub.comのアクションの利用、検索結果の統合などを個別に有効化できます。通信は443番か80番ポートのHTTPSで、GHESがインターネットに公開されるわけではありません。完全に閉じたネットワークではこれらが使えないため、Dependabotアラートを使えるかどうかがGHESの評価で差になります。 GHESの導入やGitHub Actionsを含むCI/CD基盤の構築を外部に相談したい場合は、[DevOps・CI/CD導入支援](/service/system/devops/)で設計から運用まで対応しています。 ## よくある質問 ### 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年版】](/tech/details/3673/) - [GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較](/tech/details/4219/) - [GitHubセルフホストランナーとは？導入手順とhosted版の違い【2026年版】](/tech/details/7759/) - [GitHub SSOの設定とログイン｜SAML連携とPAT・SSH・gh CLIの認可【2026年10月】](/tech/details/5717/) - [GitHub Actionsとは？できること・使い方とCI/CD自動化の活用例をわかりやすく解説](/column/details/3005/) --- 出典: [GitHub Enterprise Serverとは？オンプレGitHubの要件・料金・サポート期限とCloudとの違い]()（株式会社一創）