GitHubは2026年6月11日、GitHub Enterprise Server 3.21の一般提供を告知しました。GHESを自社運用している管理者にとって、今回の更新は新機能を眺めるだけのリリースではありません。REST APIの新しいversion、self-hosted runnerの最低版、OpenTelemetry metricsの既定化、secret scanningやDependabotの権限設計まで、アップグレード前に見る場所がかなり多いリリースです。
本稿は2026年6月15日JST時点のGitHub公式情報をもとに、GHES 3.21.0を本番へ入れる前後で何を確認するかに絞ります。Microsoft Watch JapanはMicrosoftおよびGitHubとは非提携の独立サイトです。
- GHES 3.21は、2026年6月11日のGitHub Changelogで一般提供が告知されたfeature releaseです。
- 管理者は、3.19または3.20からのアップグレード条件、REST API
2026-03-10、Actions runner2.331.0、OpenTelemetry既定化を先に棚卸しする必要があります。 - Secret scanning、CodeQL、Dependabot、Actions policyの更新は便利機能として一括展開せず、組織単位で負荷と権限を見ながら段階導入するのが安全です。
まず見る順番は、現在バージョン、ステージング、runner、API統合、監視、セキュリティ設定です。月内のMicrosoft/GitHub更新をまとめて追う場合は、公開済みの<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月重要トピックまとめ</a>も併せて確認してください。
GHES 3.21でまず何が変わったのか
3.19または3.20から3.21へ進めるか、現在version、patch level、staging、maintenance windowを確認します。
2026-03-10 versionとbreaking changesを、社内統合、GitHub Apps、外部SaaSごとに棚卸しします。
GitHub Actions runner 2.331.0をminimum application versionとして、runner fleetの更新順を確認します。
OpenTelemetry metricsのenabled化と、Collectd metrics依存の残り方を監視基盤ごとに確認します。
Secret scanning、CodeQL、Dependabot、rulesets、Actions policyを、段階展開できる単位に分けます。
3.21は新機能一覧ではなく、Upgrade、API、Runner、Observability、Securityの確認順に直すと作業に落とし込みやすくなります。
GitHub Changelogは、GHES 3.21について「deployment efficiency、monitoring capabilities、code security、policy management」を強化するリリースとして紹介しています。見出しだけを見ると幅広い機能追加に見えますが、管理者が最初に押さえるべき項目は五つに絞れます。
| 最初に見る項目 | 3.21での意味 | 管理者の確認 |
|---|---|---|
| アップグレード経路 | feature releaseとして3.19または3.20から上げる前提 | 現在version、patch level、staging、maintenance window |
| REST API | 2026-03-10が利用可能になり、breaking changesを含む | API version header、社内統合、GitHub Apps、外部SaaS |
| GitHub Actions runner | 3.21のminimum runner applicationが2.331.0 | ephemeral runner、自動更新停止、ARCやrunner group |
| OpenTelemetry | metricsがenabled、Collectdがdisabled by default | 監視dashboard、alert、Prometheus endpoint、外部監視 |
| セキュリティ運用 | Secret scanning、CodeQL、Dependabot、Actions policyが拡張 | 例外、担当割り当て、enterprise一括適用の負荷 |
根拠
GitHub Changelogのハイライトには、organization custom propertiesの一般提供、Projectsのhierarchy view一般提供、REST API version 2026-03-10、300 jobsを超えるActions workflow pageの表示改善、secret scanning governance、MySQLとrepository data向けmultiple data disksの一般提供が並びます。これらはどれも重要ですが、GHES管理者の記事としては「今すぐ使う機能」より先に「本番アップグレードの停止条件」を決めるべきです。
GA告知と実運用の間には準備がある
Changelogの日付は2026年6月11日です。Release notes側にも3.21.0の情報が掲載されています。ここで注意したいのは、一般提供が告知されたことと、自社のGHESをすぐ本番更新できることは別だという点です。
注意点
GHESはGitHub.comのSaaS更新とは違い、管理者がupgrade package、backup、snapshot、maintenance mode、post-upgrade taskを計画します。特に、社内統合やself-hosted runnerが多い環境では「本体だけ先に上げる」より、ステージングでrunner、API、監視を先に通すほうが手戻りを減らせます。
機能紹介より確認順に直す
Projects hierarchy viewやissue custom fieldsは、開発チームにとって分かりやすい改善です。一方で、運用リスクが大きいのはREST API、runner、OpenTelemetry、security configurationです。便利になった順ではなく、止まると困る順に見ていきます。
既にGitHub ActionsやCopilot code reviewのrunner運用を見直している組織は、公開済みの<a href="https://msft-watch.blog.mo-gmo.com/msft-50-github-copilot-code-review-org-runner-content-exclusion-custom-instructions/">Copilot code reviewのrunner設定記事</a>も参考になります。ただし、今回の3.21記事ではGitHub.comやGitHub Enterprise Cloudの設定ではなく、GHES本体のfeature releaseとして分けて考えます。
アップグレード判断は3.19/3.20から始める
- 1現在version
本番instanceが3.19または3.20から3.21へ進める状態かを最初に確認します。
- 2Patch level
最新patch release、既知不具合、security fixを見て、古いpatchのままfeature upgradeへ進まないようにします。
- 3Backup Utilities
GHES本体との対応関係が、同versionまたは最大2つ先の範囲に収まるかを確認します。
- 4Staging
staging、support bundle、maintenance window、rollback判断を先に揃えます。
- 5Known issues
custom firewall rules、Admin stats REST API timeout、大規模security configurationの負荷、Actions同梱更新の不整合を作業表にします。
3.18以前にいる場合は、3.21へ直接進む前に中間のfeature releaseを挟む計画が必要です。
GHES 3.21へ進む前に、現在の本番versionを確認してください。GitHub Docsのupgrade requirementsでは、3.21へ上げるには、feature releaseとして少なくとも3.20または3.19からのアップグレードである必要があります。3.18以前にいる場合、3.21へ直接進む前に中間のfeature releaseを挟む計画が必要です。
まず現在versionとpatch levelを見る
アップグレード計画の起点は、リリース名ではなく現在の稼働状態です。
確認項目
| 確認対象 | 見る理由 | 止める条件 |
|---|---|---|
| GHES本体version | 3.21へ直接上げられるかを判断するため | 3.18以前で中間計画がない |
| 最新patch release | 既知不具合やsecurity fixを取り込むため | 古いpatchのまま本番feature upgradeへ進む |
| Backup Utilities | GHES本体との対応関係を見るため | backup utilitiesが同versionまたは最大2つ先の範囲から外れる |
| background jobs | 複数upgradeを続ける場合の安全確認 | migrationやupgrade taskが完了していない |
| support window | 古いreleaseのサポート終了を避けるため | 廃止済みversionに残る計画になっている |
停止条件
GitHub Docsは、複数のfeature upgradeを実行する場合、background migrationやupgrade taskが完全に終わってから次へ進むよう促しています。ghe-migrationsやghe-check-background-upgrade-jobsで状態を確認する運用を、作業手順書に入れておくとよいでしょう。
ステージングとmaintenance windowを先に確保する
3.21はfeature releaseです。Patch releaseにhotpatchを当てる話とは分けてください。Upgrade requirementsではcapacity checkが必須で、upgrade packageを使う場合はend users向けのmaintenance windowを計画する必要があります。
確認項目
本番前のステージングで確認したい項目は次の通りです。
- Data disk、root disk、CPU、memoryのpre-flight checkが通るか。
- HA構成ではreplication statusが
OKか。 - Custom firewall rulesを再適用できる形で控えているか。
- Backup snapshotとVM snapshotを直前に取得できるか。
- Actions、Packages、Search、API、認証、通知、監視の基本動作が戻るか。
注意点
Upgrade overviewでは、feature releaseでdata migrationsを含む場合、storage performanceやdata量によって数時間のdowntimeが発生しうると説明されています。Patch release using upgrade packageは通常5分未満とされますが、feature releaseとは条件が違います。この差を社内告知に入れないと、利用者側の期待値がずれます。
Known issuesは該当環境の作業表にする
Release notesのKnown issuesは、読んで終わりにするより、該当する環境だけを作業表に落とすのが実務的です。3.21.0では、upgrade中にcustom firewall rulesが削除される点、Admin stats REST API endpointsが大規模applianceでtimeoutしうる点、大規模enterpriseでsecurity configurationを全repositoriesへ一括適用すると負荷が高くなる点などが挙がっています。
特にsecurity configurationは注意が必要です。Secret scanningやCode scanningをenterprise全体に一度に適用すると、全organizationにenablement jobsが同時投入され、大規模環境では性能劣化の可能性があります。GitHub Docsは大規模enterpriseではorganization levelで段階的に有効化することを勧めています。
REST API 2026-03-10は互換性棚卸しとして読む
すべての統合が自動で新versionへ切り替わるわけではありません。2022-11-28のretirementは、2028-03-10後の次のEnterprise Server releaseで予定される扱いとして期限管理します。
GHES 3.21では、REST API version 2026-03-10が利用可能になります。Release notesはこれを、最初のcalendar-based breaking-change versionと説明しています。つまり、新しいAPI versionを指定すれば終わりではなく、統合ごとに影響を確認する必要があります。
2026-03-10はbreaking changesを含む
根拠
GitHubのREST APIは、X-GitHub-Api-Version headerでversionを指定します。3.21 release notesによると、2026-03-10は複数のREST API endpointsにbreaking changesを含みます。どのendpointが影響するかは、breaking changes docsで公開前に再確認してください。
注意点
本文で重要なのは、すべての統合が自動的に新versionへ切り替わるわけではない点です。Requests that do not specify the X-GitHub-Api-Version: 2026-03-10 header will continue to use 2022-11-28 version、とrelease notesは説明しています。既存統合がすぐ壊れるという読み方は正確ではありません。
2022-11-28は残るが、期限管理は始まる
一方で、2022-11-28はclosing down periodに入り、2028-03-10後の次のEnterprise Server releaseでretireされる計画です。これは「2028年3月10日に即停止」とは違いますが、長期保守の社内ツールを持つ組織にとっては十分に具体的な移行期限です。
確認項目
棚卸しの単位は、endpointではなく統合です。
| 統合の種類 | 最初に見るもの | 影響が大きい失敗 |
|---|---|---|
| 社内管理スクリプト | API version header、認証方式、owner | 管理処理の失敗、未処理のrepositoryやteam |
| CI/CD連携 | workflow内のAPI call、GitHub App permission | releaseやdeployの停止 |
| 監査ログ収集 | pagination、schema、rate limit | 監査ログの欠落 |
| SCIMやIAM連携 | user/group管理endpoint、権限 | provisioningのずれ |
| 外部SaaS連携 | vendor側の対応version | 失敗時に自社で直せない |
評価基準
読み取り系から新versionを試し、低リスクな書き込み系、管理者権限系へ進めるのが安全です。API response schema、HTTP status、pagination、permission error、audit logを比較し、影響が分かるまで全統合に一斉適用しないでください。
Password authenticationの終了も同じタイミングで見る
3.21 release notesのClosing downでは、GitHub APIsへのprogrammatic accessに対するpassword authenticationが、このversionからsupportedではなくなったと説明されています。Production appsはweb applications flowを使うべきで、PATは限定的なテストなどに使う位置づけです。
API version移行とpassword authentication終了は別の論点ですが、どちらも社内統合の棚卸しで一緒に見つかります。古いスクリプトがbasic password認証、古いPAT、version header未指定のまま残っていないかを、同じ台帳で確認するとよいでしょう。
Actions runner 2.331.0は本体アップグレード前に見る
GitHub.comやGHECのrunner enforcementと、GHES 3.21のminimum runner application versionは別の確認として扱います。
GHES 3.21では、GitHub Actionsを有効化しているinstanceについて、self-hosted GitHub Actions runnerのminimum application versionが2.331.0になります。All releasesの表にも、3.21のminimum runner versionとして2.331.0が示されています。
Ephemeral runnerと自動更新停止環境は先に確認する
多くのinstanceではrunner applicationは自動更新されます。ただし、ephemeral self-hosted runnersを使い、automatic updatesをdisabledにしている環境では、GHES本体を3.21へ上げる前にrunnerを更新する必要があります。
確認項目
確認する台帳は、runner group単位で作ると見やすくなります。
| Runner群 | 事前確認 | 3.21前の判断 |
|---|---|---|
| persistent self-hosted runner | 現在version、自動更新、OS/arch | 自動更新で2.331.0へ届くか |
| ephemeral runner | image内runner version、更新手順 | 本体upgrade前にimage更新 |
| ARC managed runner | scale set、label、network、image | stagingでworkflowを流す |
| restricted network runner | download経路、checksum、proxy | 手動配布手順を先に検証 |
| legacy runner | owner、利用workflow、廃止可否 | 更新不能なら利用停止計画 |
根拠
actions/runner v2.331.0 release notesには、case function support、DockerやBuildx更新、Node version更新、checksumsなどが含まれます。また、Actions Runnerはprogressive release policyに従うため、最新releaseがenterprise、organization、repositoryですぐ利用可能とは限らない、と明記されています。download instructionは自分の環境のrunner追加画面や公式手順で確認してください。
GitHub.com/GHECのrunner enforcementと混同しない
直近ではGitHub.comやGitHub Enterprise Cloud向けのself-hosted runner minimum version enforcementも話題になっています。公開済みの<a href="https://msft-watch.blog.mo-gmo.com/msft-49-github-actions-self-hosted-runner-minimum-version-enforcement/">self-hosted runner最低版適用の記事</a>ではData ResidencyやEnterprise Cloudのスケジュールを扱いました。
今回のGHES 3.21で見る2.331.0は、GHES releaseごとのminimum runner versionです。名前は似ていますが、対象環境と判断軸が違います。社内説明では「GitHub.com側の期限」と「GHES 3.21に必要なrunner version」を分けて書いてください。
Actionsのセキュリティ変更も同時に試す
3.21のGitHub Actions関連では、workflow pagesが300 jobsを超える大規模workflowをlazy loadingで扱えるようになり、job status filterも使えるようになります。Release notesには、skipped jobのlogにif: conditionalがどう評価されたか表示される変更、Expressionsのcase functionやternary operator、private .github repositoryにorganization workflow templatesを置ける変更もあります。
セキュリティ面では、pull_request_target eventでworkflow filesとcheckout commitがrepository default branchから取得されるようになる変更が重要です。これは安全側の改善として読めますが、secretやenvironmentへのアクセス設計を不要にするものではありません。Bot作成PRの承認運用を確認する場合は、公開済みの<a href="https://msft-watch.blog.mo-gmo.com/msft-51-github-actions-bot-created-pr-workflows-approval-github-token/">github-actions[bot]とGITHUB_TOKENの記事</a>も合わせて読むと、承認ゲートとworkflow実行の分離が見えやすくなります。
OpenTelemetry既定化は監視移行の入口にする
- 1Collectd inventory
Collectd receiver、Prometheus scrape設定、Grafana dashboard、alert ruleの残り方を確認します。
- 2OpenTelemetry metrics
3.21でOpenTelemetry metricsがenabledになる前提で、metric名、SLO、runbookを照合します。
- 3Prometheus endpoint
外部監視をPrometheus endpointで受けるのか、custom pipelineで受けるのかを分けます。
- 4Dashboard and alert
OpenTelemetry側で必要なdashboard、alert、retention、監視データの保存期間を確認します。
- 53.23 readiness
Collectd metrics stackのretire予定を見据えて、3.21の時点で移行の予行演習にします。
3.21でOpenTelemetryを確認することは、3.23へ向けた監視移行の準備にもなります。
3.21 release notesでは、GitHub Enterprise Server 3.21からOpenTelemetry metricsがenabled、Collectd metricsがdisabled by defaultになると説明されています。新規インストールだけでなく、アップグレードでもOpenTelemetry metricsがenabledになります。
Collectd依存を3.23前に洗い出す
Closing downには、Collectd metrics stackがGHES 3.23からretireされる予定も記載されています。つまり、3.21でOpenTelemetryを確認することは、3.23へ向けた監視移行の予行演習です。
確認項目
棚卸しでは、次を確認してください。
- Collectd receiverやPrometheus scrape設定が残っているか。
- Grafana dashboardやalert ruleがCollectd前提になっていないか。
- SLOやrunbookで使うmetric名がOpenTelemetry側で再現できるか。
- 監視データのretentionを何日にするか。
- 外部監視へ送る場合、network bandwidth、TLS、認証、IP allowlistをどうするか。
評価基準
OpenTelemetry設定Docsは、collection frequency、data retention、custom exporters、network bandwidthが負荷に影響すると説明しています。Metrics dataはdefaultで30 days retainedとされ、Management Consoleまたはcommand lineでretentionを変更できます。長く残せば安心、短くすれば軽い、という単純な話ではなく、障害調査に必要な期間とstorage負荷を合わせて決めるべきです。
外部監視はPrometheus endpointかcustom pipelineで分ける
External monitoring docsは、OpenTelemetry metricsを外部監視に渡す方法として二つを示しています。既存のPrometheus基盤があるならPrometheus endpoint、複数監視先へpushしたい、変換やfilterを挟みたい、OTLPを好むcloud-native monitoringへ送るならcustom OpenTelemetry pipelinesです。
条件
Prometheus endpointは、https://[hostname]:8010/metricsでmetricsを出し、ghes-metrics usernameと設定したpasswordで認証します。Trusted IPv4/IPv6 addressesやCIDR blocksによるアクセス制御も用意されています。設定保存時にはsystem services restartによりuser-visible downtimeが起きうるため、本番変更はmaintenance作業として扱ってください。
注意点
Custom OpenTelemetry pipelinesは、default observability stackにadditiveな構成として使います。Docsは、reserved pathsである/ghesと/internalを使わないこと、本番前に非本番環境で十分テストすること、追加pipelineがCPUやmemory consumptionを増やす可能性があることを注意点に挙げています。
セキュリティとガバナンス変更は一括適用しない
push protection enforcementのexempt actorは、trusted automationと一般ユーザーを分けて扱います。
alertをdismissまたはreopenできる人、assigneesの追加・削除、alert ownerを確認します。
security campaignやalert担当者を、repository owner、security team、運用担当で分けます。
enterprise-wide security configurationは、organization単位やrepository群ごとに段階展開します。
allowed actions、reusable workflows、rulesetsを、例外処理と監査ログまで含めて確認します。
セキュリティ設定は強ければよいという話ではなく、例外を誰が扱い、alertを誰が閉じ、どの単位で展開するかが重要です。
GHES 3.21はcode securityとpolicy managementにも多くの更新を含みます。ここで大事なのは、強い設定を全社一括で入れることではなく、誰が例外を扱い、誰がalertを閉じ、どの単位で展開するかを決めることです。
Secret scanningは例外と一般ユーザーを分ける
Release notesでは、organization ownersとenterprise administratorsが、secret scanning push protection enforcementから特定のroles、teams、GitHub Appsをexempt actorとして指定できるようになったと説明されています。Migration botやservice accountのようなtrusted automationでは有効ですが、一般ユーザーのpush protectionを弱める話ではありません。
根拠
Fine-grained permissionsの改善もあります。Alertをdismissまたはreopenできる人がassigneesを追加・削除できること、alert assigneesがresolveなどの変更を行えること、enterprise teams、roles、appsをbypass reviewersに追加できること、enterprise ownersやenterprise security managersが任意のcustom patternsを編集できることが含まれます。
注意点
例外管理では、actor、理由、期限、対象repository、再評価日、監査ログの見方を必ず残してください。例外を作るほど便利になりますが、棚卸しなしの例外は、push protectionを静かにすり抜ける経路にもなります。
CodeQLとDependabotは担当者割り当てを見る
3.21にはCodeQL 2.24.3が同梱されます。Release notesには、Java 26、Kotlin 2.3.10まで、.NET 10とC# 14、Go 1.26、Swift 6.2.2/6.2.3、新しいPython向けprompt injection queryなどが挙がっています。言語対応そのものは開発チームの関心ですが、GHES管理者が見るべき中心は、code scanning alertsを誰に割り当て、どう通知し、どう閉じるかです。
確認項目
Dependabotでも、alertsをspecific usersに割り当てる運用、delegated dismissal controls、monorepoでのversion updates grouping、pre-commit、OpenTofu、uv、private registries向けOIDC authenticationなどが入ります。どの機能を使うかより前に、alert owner、dismiss権限、例外理由、再オープン条件、SLAを決めると、セキュリティ更新が「通知が増えただけ」で終わりにくくなります。
Enterprise-wide security configurationは段階展開にする
Known issuesで明記されている通り、大規模enterpriseでenterprise security configurationを全repositoriesへ一括適用すると、各organizationへenablement jobsが同時投入され、system loadが大きくなる可能性があります。大規模環境ではorganization levelでincrementalに有効化し、system performanceを監視しながら広げる方針が現実的です。
段階展開の確認項目
| 設定領域 | 先に決めること | 一括適用のリスク |
|---|---|---|
| Secret scanning | 対象repo、bypass reviewer、exempt actor | 大量job、例外管理の漏れ |
| Code scanning | default setup、alert owner、CodeQL version | 大量analysis、通知過多 |
| Dependabot | ecosystem、grouping、private registry auth | PR増加、owner不明 |
| Actions policy | allowed actions、reusable workflows、SHA pinning | 既存workflow停止 |
| Rulesets | bypass actor、対象branch、例外期限 | 正常なrelease作業の停止 |
「3.21にしたから全社で全部オンにする」ではなく、代表organization、重要repository、影響が小さいrepositoryの順で広げるのがよいでしょう。
インフラ構成の変更は自社トポロジーで読む
deployment efficiencyに効く変更ほど、自社のtopologyに当てはめて読まないと適用可否を誤りやすくなります。
3.21には、deployment efficiencyに効くインフラ関連の変更もあります。ここは、自社のtopologyに当てはめて読まないと誤解しやすい部分です。
Multiple data disksとdedicated log diskを見る
MySQLとrepository dataをhostするためのmultiple data disksは、GHES 3.21および3.17から3.20の最新patch versionsで一般提供されています。対象はstandaloneとhigh availability topologiesです。
Dedicated log diskは、/var/logへmountし、LVM volumeとしてconfiguredすることでroot diskからlog storageを分離する機能です。Release notesは、standaloneとhigh availability topologiesに適用され、cluster topologyには適用されないと説明しています。
適用条件
| 変更候補 | Standalone | High availability | Cluster |
|---|---|---|---|
| MySQL/repository data向けmultiple data disks | 対象 | 対象 | 対象外として扱う前にDocs再確認 |
| Dedicated log disk | 対象 | 対象 | 対象外 |
| Additional HA nodes | 対象外 | 対象 | 対象外 |
| Custom firewall rules再適用 | 対象 | 対象 | 対象 |
注意点
Storage構成変更は、GHES本体upgradeと同じmaintenanceに詰め込まないほうが安全です。容量、IO、backup、restore、snapshot、監視の設計が変わるため、ステージングでrestoreまで試してから本番計画に入れてください。
HA additional nodesは実測がある時に検討する
3.21では、high-availability datacenterにadditional nodesを追加し、CPU-intensive tasksをprimary data nodeからoffloadできる機能も説明されています。対象はhigh availability topologyで、standaloneやcluster topologyには適用されません。
評価基準
これは「入れれば速くなる」機能ではなく、CPU bottleneck、job scheduling、search/indexing、Actions、Git trafficなどの実測がある場合に検討するものです。導入判断には、既存monitoring、support bundle、staging検証、failover時の扱いを含めてください。
Custom firewall rulesの控えを残す
Release notesのKnown issuesでは、GHES upgrade中にcustom firewall rulesが削除されるとされています。該当環境では、現在のrules、適用スクリプト、owner、再適用タイミング、外部監視やbackup先の許可元を事前に保存してください。
確認項目
Post-upgradeで接続確認する相手は、開発者のGit/HTTPSだけではありません。Actions storage、Packages、external monitoring、identity provider、backup destination、webhook receiver、メール配送、proxyも含めて、疎通確認表を作る必要があります。
公開後の運用確認をアップグレード手順に入れる
background jobs、migrations、upgrade log、system logs、support bundleを確認します。
代表的な社内統合、GitHub Apps、外部SaaSで、API versionと認証方式の挙動を確認します。
runner更新、large workflow、pull_request_target、allowed actionsのpolicyを分けて確認します。
OpenTelemetry dashboard、alert rule、retention、外部監視への接続を確認します。
security configuration、alert担当者、ユーザー向け告知、管理者runbookを更新します。
ghe-migrationsとghe-check-background-upgrade-jobsで完了を確認するまで、次の大きな変更へ進まないほうが安全です。
GHESのfeature upgradeは、画面が戻った時点で終わりではありません。3.21ではAPI、Actions、OpenTelemetry、security configurationなど、アップグレード後に初めて違いが見える項目が多いため、post-upgrade validationを手順書に入れておくべきです。
Post-upgrade jobsとmigrationsを確認する
本番適用後は、background jobs、migrations、upgrade log、system logs、support bundle、monitor dashboardsを確認します。複数feature releaseを続ける予定がある場合でも、ghe-migrationsとghe-check-background-upgrade-jobsで完了を確認するまで、次の大きな変更へ進まないほうが安全です。
検証は一つの巨大PRに詰め込まないでください。API、Actions、Monitoring、Security、Infra、User noticeを分けると、失敗時の原因を切り分けやすくなります。
確認項目
| 検証領域 | 成功条件 | 失敗時に見る場所 |
|---|---|---|
| API | 主要統合が期待するstatusとschemaを返す | API logs、integration logs、audit log |
| Actions | runner 2.331.0で代表workflowが通る | runner log、workflow log、Actions storage |
| Monitoring | OpenTelemetry dashboardとalertが動く | OTel collector、Prometheus endpoint、Grafana |
| Security | alert assignmentやbypass reviewerが期待通り | security settings、audit log |
| Infra | firewall再適用後に外部連携が戻る | system logs、network logs、proxy |
| User notice | downtime告知と解除が一致する | announcement banner、helpdesk tickets |
ユーザー向け告知と管理者runbookを分ける
Release notesの全文を利用者へ流しても、ほとんどの人は何をすべきか分かりません。開発者向けには、Actions runnerやworkflow挙動、API version、Projects/Issues/PRの使い勝手変更を短く伝えます。セキュリティ担当には、Secret scanning、CodeQL、Dependabot、bypass、alert assignmentの変更を別紙にします。管理者runbookには、backup、snapshot、firewall、monitoring、post-upgrade jobsを残します。
実務への落とし込み
記事を読んだ後の実務としては、次の三つに分けると始めやすいはずです。
- 現在のGHES version、runner version、API統合、監視方式を台帳化する。
- ステージングで3.21 upgrade、runner
2.331.0、REST API2026-03-10、OpenTelemetryを別々に確認する。 - 本番後にsecurity configurationをorganization単位で段階展開し、負荷とalert運用を見ながら広げる。
Microsoft/GitHubの公式発表や製品更新を継続的に追いたい場合は、記事末のニュースレター導線も利用できます。ここまでの確認事項を自社チェックリストに写すほうが先で、購買や投資判断を急ぐ記事ではありません。
次に読むなら
参照した主な情報源
- GitHub Changelog「GitHub Enterprise Server 3.21 is now generally available」
GitHub Enterprise Server 3.21 is now generally available
- GitHub Docs「Enterprise Server 3.21 release notes」
https://docs.github.com/en/enterprise-server%403.21/admin/release-notes
- GitHub Docs「GitHub Enterprise Server releases」
https://docs.github.com/en/enterprise-server%403.21/admin/all-releases
- GitHub Docs「Upgrade requirements」
https://docs.github.com/en/enterprise-server%403.21/admin/upgrading-your-instance/preparing-to-upgrade/upgrade-requirements
- GitHub Docs「Overview of the upgrade process」
https://docs.github.com/en/enterprise-server%403.21/admin/upgrading-your-instance/preparing-to-upgrade/overview-of-the-upgrade-process
- GitHub Docs「OpenTelemetry metrics」
https://docs.github.com/en/enterprise-server%403.21/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics
- GitHub Docs「Setting up external monitoring with OpenTelemetry」
https://docs.github.com/en/enterprise-server%403.21/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/setting-up-external-monitoring-with-opentelemetry
- GitHub actions/runner release
v2.331.0
https://github.com/actions/runner/releases/tag/v2.331.0
更新履歴
- 2026年6月15日JST: GitHub Changelog、GHES 3.21 release notes、upgrade docs、OpenTelemetry docs、actions/runner
v2.331.0release notesを確認し、初稿を作成しました。