2026年8月18日以降、必要なセキュリティパッチが適用されていないGitHub Enterprise Server（GHES）では、コマンドラインからのサポートバンドル送信が拒否される可能性があります。
対象となるのは、ghe-support-bundle、ghe-cluster-support-bundle、ghe-support-uploadを使ったアップロードです。継続して送信するには、現在利用しているバージョン系列の最新パッチへ更新し、少なくともGitHubが指定する最小パッチ以上にする必要があります。
障害発生後にサポートバンドルを送れない事態を避けるため、期限直前ではなく、現在のGHESバージョン確認、更新計画の作成、バックアップ、パッチ適用までを早めに完了させておきましょう。(The GitHub Blog)
GHESサポートバンドル送信を継続するための必須パッチ一覧
GitHubが公表している、GHESのバージョン系列ごとの最小パッチは次のとおりです。
| GHESのバージョン系列 | 必要な最小パッチ | 判定例 |
|---|---|---|
| 3.21 | 3.21.3 | 3.21.2は更新が必要 |
| 3.20 | 3.20.5 | 3.20.4は更新が必要 |
| 3.19 | 3.19.9 | 3.19.9以上で要件を満たす |
| 3.18 | 3.18.12 | 3.18.11は更新が必要 |
| 3.17 | 3.17.18 | 3.17.17は更新が必要 |
期限は2026年8月18日です。この日以降、上記の最小パッチに達していない古いGHESアプライアンスからのコマンドラインアップロードは、GitHub側で拒否されるようになります。(The GitHub Blog)
ただし、表にあるバージョンは「推奨バージョン」ではなく、あくまで送信を継続するための最低ラインです。たとえば3.20系列を利用している場合、3.20.5で止めるのではなく、作業時点で公開されている3.20系列の最新パッチを選ぶのが基本です。
GitHubも、現在利用しているバージョン系列で利用可能な最新パッチへ更新するよう案内しています。最低ラインだけに合わせると、その後に修正された不具合やセキュリティ問題が残る可能性があります。(The GitHub Blog)
3.16以前を利用している場合
3.16以前のバージョンは、今回公表された最小パッチ一覧に含まれていません。
一覧にない古いバージョンへパッチを適用して対応するのではなく、サポート対象となっているGHESのバージョン系列へのアップグレードを検討してください。GitHubは、サポートが終了したGHESを利用している場合、サポート対象バージョンへ速やかにアップグレードするよう推奨しています。(The GitHub Blog)
GHES 3.17は期限直後にサポート終了予定
GHES 3.17では、3.17.18へ更新すれば今回のサポートバンドル送信要件を満たします。
一方、GHES 3.17は2026年8月25日にサポート終了予定です。サポートバンドル送信の制限開始日である8月18日から、わずか7日後にサポート対象外となります。(GitHub Docs)
そのため、3.17.18への更新は短期的な緊急対応としては有効ですが、中長期的な対応として十分ではありません。3.17を運用している組織は、次のように二段階で対応するのが現実的です。
- まず3.17.18以上へ更新し、8月18日の送信制限に対応する
- 続けてサポート対象の新しい機能リリースへのアップグレードを計画する
2026年8月18日から何が変わるのか
今回の変更は、GitHub Enterprise ServerからGitHub Supportへ診断データを送る際のセキュリティ強化です。
必要なパッチが適用されていないGHESから、対象コマンドを使ってサポートバンドルなどをアップロードすると、GitHub側で受け付けられない可能性があります。
GitHubの告知では、拒否時に表示される固定のエラーメッセージや終了コードまでは公表されていません。そのため、エラー表示を見てから判断するのではなく、GHESのバージョン番号を基準に事前確認することが重要です。(The GitHub Blog)
対象となる3つのコマンド
| コマンド | 主な用途 | 今回確認すべき処理 |
|---|---|---|
ghe-support-bundle | 単一インスタンスのログや診断情報を収集する | GitHub Supportへの直接アップロード |
ghe-cluster-support-bundle | クラスターまたはGeoレプリケーション構成の各ノードから情報を収集する | クラスターバンドルの直接アップロード |
ghe-support-upload | ローカルファイルや標準入力の情報をGitHub Supportへ送る | ファイルや診断情報のアップロード |
ghe-support-bundleは、サポートバンドルを生成するだけでなく、オプションを付けてGitHub Supportへ直接送信できます。
単一インスタンスでの直接送信例は次のとおりです。
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -u'クラスターまたはGeoレプリケーション構成では、ghe-cluster-support-bundleを使用します。
ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -u'既存ファイルをサポートチケットに関連付けて送信する場合は、ghe-support-uploadを利用できます。
ghe-support-upload -f FILE_PATH -t TICKET_IDghe-support-uploadはローカルファイルのほか、標準入力から受け取った診断情報の送信にも使用されます。(GitHub Docs)
なお、今回GitHubが明示している変更対象は、古い未修正アプライアンスからのコマンドラインアップロードです。サポートバンドルのローカル生成まで一律にできなくなると告知されているわけではありません。
ただし、手動アップロードなら必ず回避できるという意味でもありません。パッチを適用できない場合は、独自に回避方法を試すのではなく、GitHub Supportへ連絡する必要があります。
現在のGHESバージョンを確認する方法
GHESの管理シェルへSSH接続できる場合は、ghe-versionコマンドでバージョン、プラットフォーム、ビルド情報を確認できます。(GitHub Docs)
ssh -p 122 admin@HOSTNAME -- 'ghe-version'HOSTNAMEは、実際のGHESホスト名へ置き換えてください。
表示されたバージョン番号を、最小パッチ一覧と照合します。
| 確認結果の例 | 判定 | 必要な対応 |
|---|---|---|
| 3.21.2 | 最小パッチ未満 | 3.21系列の最新パッチへ更新 |
| 3.20.5 | 最小要件を満たす | より新しい3.20パッチがあれば更新を検討 |
| 3.19.8 | 最小パッチ未満 | 3.19.9以上へ更新 |
| 3.17.18 | 送信要件は満たす | 3.17のサポート終了を見据えて機能アップグレード |
| 3.16以前 | 一覧外 | サポート対象バージョンへのアップグレードを計画 |
単に「3.20だから問題ない」と判断してはいけません。今回の条件は機能リリース単位ではなく、パッチ番号まで含めて判定されます。
たとえば3.20.4と3.20.5では、メジャー番号とマイナー番号は同じですが、今回の送信要件では結果が異なります。
パッチ適用までの実務手順
現在の構成とバージョンを棚卸しする
最初に、組織内で運用しているすべてのGHESを確認します。
本番環境だけでなく、次の環境も確認対象に含めてください。
- ステージング環境
- 災害復旧用インスタンス
- 高可用性構成のレプリカ
- クラスター構成の各ノード
- 一時停止中だが復旧する可能性のあるインスタンス
サポートが必要になるのは、本番環境が正常に動作しているときとは限りません。障害時に切り替えたレプリカや災害復旧環境が古いままだと、切り替え後にサポートバンドルを送れない可能性があります。
更新先は最低バージョンではなく最新パッチを選ぶ
現在のバージョン系列を維持する場合は、同じ系列で利用可能な最新パッチを選択します。
たとえば3.19.8を利用している場合、最小条件は3.19.9ですが、作業時点で3.19.10以降が公開されていれば、特別な互換性上の理由がない限り、最新パッチを候補にします。
最新パッチを選ぶことで、今回のアップロード要件だけでなく、後続のバグ修正やセキュリティ修正もまとめて反映できます。
バックアップ、スナップショット、容量を確認する
アップグレード前には、少なくとも次の項目を確認します。
- 最新のバックアップが正常に完了している
- 仮想マシンのスナップショット取得計画がある
- 更新パッケージを保存できる空き容量がある
- システム容量チェックを完了している
- ステージング環境で更新手順を確認している
- メンテナンス時間と利用者への告知内容が決まっている
GitHubのアップグレード要件でも、最新パッチの利用、正常なバックアップ、スナップショット、容量チェック、ステージング環境でのテストが推奨されています。(GitHub Docs)
スナップショットだけをバックアップの代わりにするのではなく、GHES Backup Utilitiesなどによるバックアップの正常終了も確認してください。
hotpatchかアップグレードパッケージかを選ぶ
同じ機能リリース内のパッチ更新では、hotpatchまたはアップグレードパッケージを利用できます。
| 更新方法 | 主な特徴 | 向いているケース |
|---|---|---|
| hotpatch | パッチリリースへの更新に利用でき、通常はメンテナンスモードを必要としない | 同じバージョン系列内で影響を抑えて更新したい |
| アップグレードパッケージ | メンテナンスモードと作業時間の確保が必要 | hotpatchを利用できない構成や、通常パッケージで統制したい |
| 機能リリースへのアップグレード | アップグレードパッケージが必要 | 3.16以前やサポート終了が近い系列から移行する |
パッチリリースにはhotpatchまたはアップグレードパッケージを使用できますが、機能リリースをまたぐ更新にはアップグレードパッケージが必要です。hotpatchではメンテナンスモードが不要とされていますが、組織内の変更管理や動作確認時間まで不要になるわけではありません。(GitHub Docs)
高可用性構成やクラスター構成では、単一インスタンス向けの手順をそのまま適用せず、該当する構成の公式アップグレード手順に従ってください。
更新後にバージョンを再確認する
更新処理が完了したら、再度ghe-versionを実行します。
ssh -p 122 admin@HOSTNAME -- 'ghe-version'次の点を確認してください。
- 想定したパッチ番号になっている
- Web画面へ正常にアクセスできる
- Gitのclone、fetch、pushが正常に動作する
- GitHub Actionsや外部連携が正常に動作する
- HAやクラスターの各ノードが正常な状態に戻っている
- バックグラウンドの更新処理が完了している
サポートバンドルをローカルへ出力する確認例は次のとおりです。
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -o' > support-bundle.tgzただし、ローカル生成に成功しても、GitHub側へのアップロード成功まで証明できるわけではありません。また、サポートバンドルにはログや診断情報が含まれるため、動作試験だけを目的に本番データを送信することは避けましょう。
パッチ適用後もアップロードできない場合の確認項目
必要なパッチを適用していても、ネットワークや認証など別の理由で送信に失敗することがあります。
バージョン要件を再確認する
最初に、実際にコマンドを実行しているノードのバージョンを確認します。
HA構成やクラスター構成では、確認したノードとコマンドを実行しているノードが異なる可能性があります。管理台帳の記録だけでなく、対象ノード上のghe-version結果を確認してください。
アウトバウンドHTTPS通信を確認する
GHESからサポートバンドルを直接アップロードする場合、GitHubの公式ドキュメントでは、TCP 443による次の宛先へのアウトバウンド通信が必要とされています。
enterprise-bundles.github.com
esbtoolsproduction.blob.core.windows.netファイアウォール、プロキシ、DNSフィルタリング、TLSインスペクションなどによって通信が遮断されていないか確認してください。(GitHub Docs)
特に、2026年8月18日以降に送信できなくなったからといって、すべてをパッチ不足と決めつけるのは危険です。
バージョンが最小条件以上であれば、次の順番で切り分けます。
- 実行ノードのGHESバージョン
- コマンドとオプション
- TCP 443のアウトバウンド通信
- プロキシや名前解決
- サポートチケット番号やアップロード先
- GitHub Statusでの障害情報
- GitHub Supportへの問い合わせ
単一構成とクラスター構成でコマンドを使い分ける
単一インスタンスでは、通常ghe-support-bundleを使用します。
クラスターまたはGeoレプリケーション構成で、複数ノードをまとめたバンドルが必要な場合は、ghe-cluster-support-bundleを使用します。構成に合わないコマンドを使っていると、必要なログが含まれず、サポート担当者から再取得を求められる可能性があります。(GitHub Docs)
どちらを使うべきか不明な場合は、先にサポートチケットを作成し、GitHub Supportの指示に従うのが確実です。
2026年8月18日までに更新できない場合の対応
必要なパッチを期限までに適用できず、サポートバンドルを送信する必要がある場合は、GitHub Supportへ連絡してください。
GitHubは、2026年8月18日までに必要なパッチへ更新できない利用者に対して、今後の手順を案内するためGitHub Supportへ問い合わせるよう明記しています。(The GitHub Blog)
問い合わせ時には、次の情報を整理しておくと対応が進みやすくなります。
| 提供する情報 | 記載例 |
|---|---|
| GHESのバージョン | 3.18.10 |
| ビルド情報 | ghe-versionの出力 |
| 構成 | 単一、HA、クラスター、Geoレプリケーション |
| 更新できない理由 | 変更凍結期間、検証未完了、容量不足など |
| 更新予定日 | 2026年8月25日予定 |
| サポートバンドルが必要な理由 | レプリケーション障害の調査 |
| 希望する送信時期 | 障害調査のため至急 |
| 既存チケット | チケット番号があれば記載 |
GitHubの標準手順には、サポートバンドルを一度ダウンロードし、サポートポータルから手動でアップロードする方法もあります。(GitHub Docs)
しかし、手動アップロードを今回のセキュリティ制限の回避策として自己判断で利用するのは避けてください。更新できない場合について、GitHubはSupportへの連絡を正式な対応として案内しています。
よくある判断ミスと注意点
最小パッチと同じバージョンへ固定してしまう
3.20.5が最低条件だからといって、必ず3.20.5へ更新する必要はありません。
すでに3.20.6以降が公開されている場合は、通常は新しいパッチを選びます。最小パッチは「これより古いと要件を満たさない」という境界です。
本番環境だけ確認する
災害復旧用やレプリカが古いままだと、障害対応で切り替えた直後にサポートバンドルを送れない可能性があります。
構成図や資産台帳を使い、すべてのGHESインスタンスとノードを確認してください。
期限当日に更新する
アップグレードでは、容量不足、パッケージ取得失敗、バックグラウンド処理の長期化、外部連携の不具合などが発生することがあります。
8月18日当日の更新ではなく、更新後の監視期間を確保できる日程で実施しましょう。
3.17.18への更新だけで完了と考える
3.17.18は今回の最小要件を満たしますが、3.17系列は2026年8月25日にサポート終了予定です。
3.17.18へのパッチ適用と、サポート対象系列への機能アップグレードを別の作業として計画してください。
エラーが発生してから対処する
障害発生時には、通常時よりも変更作業が難しくなります。
サポートへ相談したい状況でアップロードまで拒否されると、原因調査の開始が遅れます。今回の対応は、通常のパッチ管理ではなく、障害対応経路を維持するための事前準備として扱うべきです。
期限前に実施すべきチェックリスト
2026年8月18日までに、次の作業を完了させてください。
ghe-versionで現在のバージョンを確認する- 全GHESインスタンスと全ノードを棚卸しする
- 最小パッチ一覧と照合する
- 現在の系列で利用可能な最新パッチを確認する
- バックアップの成功状態を確認する
- スナップショットと復旧手順を準備する
- 容量チェックを実施する
- ステージング環境で更新を検証する
- 本番環境へパッチを適用する
- 更新後にバージョンと主要機能を確認する
- TCP 443のアウトバウンド通信を確認する
- 3.17利用中の場合は後続の機能アップグレードを計画する
- 更新できない場合は期限前にGitHub Supportへ連絡する
今回の最優先事項は、GHESの現在のパッチ番号を確認することです。
3.21.3、3.20.5、3.19.9、3.18.12、3.17.18のいずれかの最低ラインを下回っている場合は、現在のバージョン系列の最新パッチへ更新してください。更新できない事情がある場合は、サポートバンドルが必要になってからではなく、2026年8月18日より前にGitHub Supportへ相談しておきましょう。
コメント