先に結論
今回の更新は、GitHub Actions の hosted runner を何となく *-latest で回しているチームほど影響があります。
Windows は 6月8日から、macOS は 6月15日から、動く OS と toolchain が段階的に変わります。
先にやることは3つです。
windows-latestとmacos-latestを使っている job を洗い出す- Windows は
windows-2025-vs2026で先に試す - macOS 15 を維持したい job は
macos-15へ固定する
Arm64 runner は設定を急いで変える話ではありません。ただし、今後どこで release note とサポート情報を見るかは変わります。
なぜ今見るべきか
この変更は日付つきです。
GitHub は 2026-05-14 の changelog で、windows-latest と windows-2025 を Visual Studio 2026 ベースへ移す予定を案内しました。開始は 2026-06-08 です。完了は 2026-06-15 とされています。
同じ告知で、macos-latest は 2026-06-15 から 30 日かけて macOS 26 へ移ります。
CI は動いている間ほど直しにくいので、移行当日に気づくより、今のうちにテスト用ラベルや固定ラベルを決めたほうが楽です。
GitHub Actions 全体の守り方を見直したいなら、GitHub Actions security roadmap 2026 で何が変わるか もつながります。
まず見るべき3つの変更
1. Windows は windows-latest が Visual Studio 2026 ベースへ寄る
一番先に確認したいのはここです。
windows-latest と windows-2025 は、2026-06-08 から 1 週間かけて Visual Studio 2026 ベースへ移ります。
影響を受けやすいのは、Windows 固有の build toolchain、MSBuild、C++ toolset、SDK バージョン差分に敏感な workflow です。
GitHub は事前検証用に windows-2025-vs2026 を案内しています。
このラベルは移行前の確認用です。移行後は windows-2025 と同じ先を指す想定なので、長期固定用ではなくテスト用として扱ったほうが安全です。
もし Visual Studio 2022 を維持したいなら、windows-2022 を明示します。
2. macos-latest は macOS 26 へ移る
macOS 側は、すぐ切り替わるというより、30 日かけてじわっと移ります。
つまり migration 期間中は、同じ macos-latest でも実行先が揺れます。
Xcode、署名、brew 依存、ネイティブ gem や CLI の挙動に差が出やすい job では、この揺れが地味に面倒です。
macOS 15 を維持したい job は、今のうちに macos-15 を明示したほうが混乱が少なくなります。
逆に macOS 26 へ早めに寄せたいなら、先に検証系 workflow を分けて通しておくと本番 deploy の事故を減らせます。
3. Arm64 runner は管理元が GitHub へ寄る
Arm64 runner で大きく変わるのは、機能そのものより運用窓口です。
GitHub によると、Windows 11 Arm image はすでに GitHub 管理へ移っています。Ubuntu 22.04 Arm64 と Ubuntu 24.04 Arm64 も GitHub の内部 pipeline へ移行中です。
この間、Ubuntu Arm64 image では actions/runner-images に新しい release note が出ない期間があります。
さらに、これまで Arm 系 image を扱っていた actions/partner-runner-images は最終的に archive 予定です。open issue や今後の問い合わせ先は actions/runner-images へ集約されます。
GitHub は breaking change なし、package の追加削除なしと案内しています。ただし、CVE や image 不具合を追う場所は変わるので、通知先だけでも見直しておく価値があります。
どの workflow から先に確認するべきか
優先順位は単純です。
1. *-latest を本番 deploy に使う job
一番危ないのは、ラベル変更がそのまま production release に当たる job です。
Windows build、notarization、署名、installer 生成、native test が絡むものから見たほうがいいです。
2. キャッシュや toolchain 差分に弱い job
次に見るのは、SDK や compiler の細かい差分で壊れやすい workflow です。
たとえば次のようなものです。
- C++ や .NET の Windows build
- Xcode を固定している iOS、macOS build
- native extension を含む Node、Ruby、Python build
- Arm64 で package 可用性に依存する test
3. AI agent や self-hosted 移行判断の前段になる job
最近は Copilot coding agent や self-hosted runner の導入を検討しつつ、GitHub-hosted runner はそのまま残すチームも増えています。
その場合、まず今の hosted runner 変更に耐えられるかを見ておくと、あとで実行基盤を比較しやすくなります。
実行場所まで含めて見直したいなら、Self-hosted、private network 前提のAI coding agent比較 や GitHub Agentic Workflows vs Copilot coding agent vs OpenClaw cron も参考になります。
今やるべき確認を Windows、macOS、Arm64 に分ける
Windows 利用者の確認
最初に windows-latest と windows-2025 を使う workflow を一覧化します。
そのうえで、代表的な build と test を windows-2025-vs2026 で一度流します。
見たいのは、compile error だけではありません。
- Visual Studio toolset 差分
- SDK や preinstalled tool の差分
- installer、packaging、signing の後工程
- キャッシュキーに OS 名や image を含めているか
もし今月中に切り替えたくない job があれば、逃がし先は windows-2022 です。
macOS 利用者の確認
macos-latest を本番 release や signing に使っているなら、いったん macos-15 固定の要否を決めたほうが早いです。
特に Xcode、simulator、notarization、brew package を前提にした workflow は、migration の途中で揺れるより、いったん固定してから別 branch で macOS 26 対応を見るほうが読みやすいです。
移行を前倒しで試したい場合は、検証 workflow を分けて macOS 26 側の build と test を先に通しておくと、本番 release job を静かに保てます。
Arm64 利用者の確認
Arm64 は label の付け替えより、監視先の変更が先です。
Ubuntu Arm64 image の release note が一時的に actions/runner-images に出ない期間があるので、更新を release note だけで追っていると変化に気づきにくくなります。
今後は actions/runner-images の issue と release を追う前提で整理したほうが安全です。
もし移行期間中に脆弱性や image 不具合へ当たったら、GitHub は actions/runner-images へ issue を開くよう案内しています。
迷ったらどう固定するか
固定の考え方はシンプルです。
- まず壊したくない本番 job だけ固定する
- 検証 job では新しい image を先に試す
- ずっと
*-latestを避けるのではなく、移行が落ち着いたら戻すか判断する
全部を即固定すると、今度は更新追従が止まります。
なので、今は「期限が近い workflow を読みやすくするための一時固定」と考えるのが現実的です。
まとめ
今回の GitHub Actions image migration は、*-latest を使う workflow の棚卸しを促す更新です。
優先順位ははっきりしています。
- Windows は
windows-2025-vs2026で先に試す - macOS 15 を維持したい job は
macos-15を明示する - Arm64 は設定変更より、監視先を
actions/runner-imagesへ寄せる
放置すると、同じ YAML でも来月から動く中身が変わります。
逆に今のうちにラベルを見直しておけば、CI の揺れをかなり減らせます。