GitHub Actions の changelog は短く見えても、CI/CD を運用している現場では見逃しにくい更新があります。2026年4月2日付で公開された GitHub Actions Early April 2026 updates は、緊急の移行対応よりも、これまで回避策でしのいでいた運用を整理しやすくする内容が中心でした。先に見るべきなのは、services を使うテスト基盤、OIDC でクラウドにデプロイしている workflow、Azure private networking を使う GitHub-hosted runners の3つです。(The GitHub Blog)
今回の更新をひとことで言うなら、YAML の書き方が少し楽になっただけではありません。サービス起動の管理、クラウド権限の設計、障害時の runner 継続性まで、担当チームごとに見直す価値があるアップデートです。以下では、今回の変更点、既存ワークフローへの影響、早めに確認したい項目を実務目線で整理します。(The GitHub Blog)
GitHub Actions Early April 2026 updates の要点
- サービスコンテナで
entrypointとcommandを上書きできるようになりました。 これにより、サービス用イメージの既定ENTRYPOINT/CMDを workflow YAML 側から調整できます。GitHub は naming と挙動が Docker Compose に近いとも案内しています。(The GitHub Blog) - OIDC トークンで repository custom properties を claim として使える機能が一般提供になりました。
repo_property_接頭辞付きでリポジトリ属性をトークンに含められるため、クラウド側の trust policy を属性ベースで組みやすくなります。(The GitHub Blog) - Azure private networking で VNET failover が public preview になりました。 GitHub-hosted runners の primary subnet が使えなくなったときに、secondary subnet に切り替える設計を取りやすくなります。(The GitHub Blog)
今回の公開内容は、すぐに全 workflow を書き換えるタイプの変更ではありません。ただし、すでに services、OIDC、Azure VNET を使っているチームは、放置するより先に棚卸ししたほうが効果が出やすい更新です。(The GitHub Blog)
サービスコンテナの entrypoint / command 追加で、YAML に戻せる運用が増える
今回の中でも、もっとも広い利用者に効くのがサービスコンテナの改善です。command は Docker image の既定 CMD を上書きし、entrypoint は既定 ENTRYPOINT を上書きします。両方を指定した場合、command は custom entrypoint への引数として扱われます。(GitHub Docs)
たとえば「MySQL の起動フラグを少し変えたいだけ」のケースなら、専用の wrapper image を維持しなくても、workflow に寄せて管理しやすくなります。GitHub 公式 docs でも、mysql の起動オプション変更や etcd の entrypoint 差し替え例が案内されています。(GitHub Docs)
jobs:
integration-test:
runs-on: ubuntu-latest
services:
mysql:
image: mysql:8
command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M
env:
MYSQL_ROOT_PASSWORD: test
ports:
- 3306:3306この変更が効くのは、特に次のような workflow です。
- DB や Redis の起動引数を変えるためだけに service 用 image を分けている
docker runを step に直書きして後始末まで自前でやっている- テスト環境のミドルウェア設定差分を、Dockerfile 側に抱え込んでいる
つまり、今回の追加は「新しいことができる」よりも、今の回避策を減らせる価値が大きいアップデートです。(The GitHub Blog)
既存ワークフローへの影響
既存 workflow が自動で壊れる可能性は高くありません。今回の変更は追加機能なので、今の YAML がそのまま動いているなら、当面は現状維持でも問題になりにくいです。見直し対象になるのは、これまでの運用負債が目立つ repository です。(The GitHub Blog)
失敗しやすいポイント
- Linux ランナー前提です。 Docker container actions、job containers、service containers を使う workflow は Linux runner が必要です。GitHub-hosted runner なら Ubuntu、self-hosted runner なら Docker が入った Linux を前提に考えてください。(GitHub Docs)
- Composite action には閉じ込められません。 service containers は composite action 内で作成して利用できません。共通化したいなら、reusable workflow へ寄せるほうが整理しやすいです。(GitHub Docs)
- ポート公開の要否は実行方式で変わります。 job を container で動かす場合は service containers との通信に明示的な port mapping は不要ですが、runner 上で直接 job を動かす場合は
ports:が必要です。(GitHub Docs) - 自由度が無制限に増えたわけではありません。
entrypointは単一文字列で指定し、optionsでも--networkは引き続きサポートされていません。Docker Compose に近づいたとはいえ、完全に同じ感覚で書くとハマります。(GitHub Docs) - サービスは job 単位で使い捨てです。 service container は job ごとに新規作成され、job 完了時に破棄されます。状態を次の job に持ち越す前提の設計は、今回の更新後も向いていません。(GitHub Docs)
OIDC トークンへの repository custom properties 追加は、権限管理をリポジトリ名依存から外せる
OIDC を使って AWS、Azure、GCP などへデプロイしているなら、今回の一般提供はかなり実務的です。組織または enterprise の管理者が repository custom properties を OIDC 設定に追加すると、その値が repo_property_ 接頭辞付きの claim としてトークンに入ります。GitHub はこれにより、クラウド側で attribute-based access control を組みやすくなり、repository ごとの個別設定を減らせると説明しています。(The GitHub Blog)
実務では、たとえば environment=production の repository だけ本番向けロールを引き受けられるようにしたり、team=platform-eng を持つ repository だけインフラ権限を使えるようにしたり、といった設計に寄せやすくなります。今回の価値は、リポジトリ名や ID の列挙から、属性での権限制御へ寄せられることです。(The GitHub Blog)
既存デプロイへの影響
ここで注意したいのは、この変更が workflow YAML だけで完結しないことです。custom properties は組織または enterprise レベルで定義されている必要があり、OIDC claim に含める property は settings UI か REST API で admin が追加します。しかも一度追加すると、その property に値が設定された repository のトークンには自動で claim が入ります。つまり、deploy workflow だけ直しても不十分で、repo metadata の設計ルールまで合わせないと運用が整いません。(GitHub Docs)
先に確認したい項目
- property の命名が揺れていないか。
prodとproductionのような表記ゆれがあると、クラウド側の trust policy が一気に扱いづらくなります。最初はenvironment、team、data_classificationのような少数の property に絞るほうが安全です。(The GitHub Blog) - multi-select の扱いを誤らないか。 multi-select property は OIDC token ではカンマ区切り文字列として入り、true/false も
"true"/"false"の文字列になります。クラウド側で完全一致だけを前提にすると、想定どおり評価できないことがあります。(GitHub Docs) - 開発チームだけで進めないこと。 property 定義と OIDC claim への追加は org / enterprise admin の作業です。platform 担当と security 担当を巻き込まないと、workflow 側だけ先に変えても着地しません。(GitHub Docs)
Azure private networking の VNET failover は、障害対策の運用まで見直す必要がある
Azure private networking を使う GitHub-hosted runners では、network configuration に failover network を持てるようになりました。secondary subnet は primary と別 Azure region に置くこともでき、regional outage や subnet 側の障害時に runner traffic を切り替えられます。なお、この機能は public preview です。(The GitHub Blog)
この更新が関係するのは、Azure private networking を使っている enterprise / organization アカウントです。通常の GitHub-hosted runner だけを使っているチームには影響は限定的ですが、対象環境では runner の可用性設計に直結するので優先度は高めです。network configuration を runner group に関連付けると、その group の runners が Azure VNET を使う構成になります。(The GitHub Blog)
早めに確認したい項目
- まだ preview です。 public preview なので、運用ルールや UI の変化を見越して、いきなり本番依存を強めすぎないほうが無難です。(GitHub Docs)
- 切り替えだけでなく切り戻しも必要です。 failover は UI や REST API から手動で切り替えられます。regional outage 時には GitHub が自動で failover する場合もありますが、primary に戻す操作は手動です。audit log イベントとメール通知も入るため、runbook に切り戻し担当まで書いておくべきです。(The GitHub Blog)
- secondary subnet を作るだけでは足りません。 primary / failover の両 subnet に必要な Azure リソースと network settings resource がそろっていること、failover subnet が supported region にあることが前提です。(GitHub Docs)
- 境界防御の思い込みに注意です。 GitHub-hosted runner の NIC は Azure VNET 内にデプロイされるため、GitHub 側が inbound を遮断してくれるわけではありません。GitHub は inbound 接続を必要としないため、明示的に block することを推奨しています。(GitHub Docs)
- 送信元 IP の扱いも確認してください。 Azure の default outbound access に依存すると outbound IP は予測できないため、allow-list 前提の構成なら Azure 側で安定した egress 設計が必要になります。(GitHub Docs)
あなたの運用なら優先度はどれくらいか
今回の3項目を、現場での緊急度に置き換えると次のようになります。これは公式の機能範囲を前提にした、実務目線の優先度です。(The GitHub Blog)
| 今の運用状況 | 緊急度 | 理由 | 今やること |
|---|---|---|---|
| DB / Cache / MQ などの service containers を CI で使っている | 高 | wrapper image や docker run の回避策を減らせる | services: を使う workflow を棚卸しする |
| OIDC でクラウドデプロイしている | 高 | trust policy を repo 名依存から属性ベースへ寄せられる | custom properties の命名ルールを決める |
| Azure private networking で GitHub-hosted runners を使っている | 最優先 | failover が障害運用に直結する | secondary subnet と切り戻し手順を確認する |
| 単純な lint / format / unit test だけで回している | 低 | 今回の更新の恩恵が比較的小さい | まずは changelog の監視だけで十分 |
いまやるべき確認手順
今回の更新は、全部を一気に触るより、関係する部分だけを先に棚卸ししたほうが早く終わります。次の順で確認すると、無駄な改修を増やしにくいです。(The GitHub Blog)
.github/workflowsでservices:を検索し、wrapper image やdocker runを step に書いている箇所を洗い出します。command/entrypointに置き換えられるなら、差分管理を YAML 側へ戻せます。(GitHub Docs)- OIDC デプロイを使う repository では、まず custom properties の命名を統一します。property を OIDC claim に追加すると、値が設定された repository の token に自動反映されるため、命名ゆれは早めに潰すほど楽です。(GitHub Docs)
- Azure private networking 利用組織では、secondary subnet、supported region、切り戻し手順の3点を先に固めます。regional outage 時に GitHub が自動 failover した場合も、primary へ戻す操作は手動です。(The GitHub Blog)
- 変更後の運用手順まで更新します。今回のアップデートは YAML だけで終わらず、権限管理やネットワーク運用の責任分界にも影響するため、「誰が設定するか」まで決めておくと事故が減ります。(GitHub Docs)
まとめ
GitHub Actions の 2026年4月前半アップデートで本当に見るべきなのは、新機能の数ではなく、運用負債をどこから減らせるかです。services の起動制御追加は CI の回避策を減らし、OIDC custom properties の一般提供はクラウド権限を repo 名依存から属性ベースへ寄せやすくし、Azure VNET failover は hosted runner の障害対応を前提にした設計を求めます。(The GitHub Blog)
まずは services: を使う workflow、OIDC を使う deploy workflow、Azure private networking の network configuration の3か所を棚卸ししてください。今回の更新は、全部に同じ温度感で対応するより、自分の運用に関係する部分だけを早めに押さえるほうが成果につながります。(GitHub Docs)
コメント