GitHub Actions で windows-11-arm を使っている場合は、2026年9月21日〜9月30日の Visual Studio 2026 への段階移行に備え、既存のビルドとテストを先に確認してください。Windows 11 arm64＋VS2026 のイメージは、標準・larger runner ともに一般提供されています。
標準 runner の先行確認には runs-on: windows-11-vs2026-arm を使います。移行をそのまま受け入れるなら操作は不要ですが、VS2022 に依存するワークフローが動くことを保証するものではありません。移行期間中は、同じ windows-11-arm 指定でも実行環境が切り替わります。日程と対象は GitHub の2026年8月20日告知に基づきます。
最初に確認する runner ラベルと移行内容
Windows の x64 と Arm64 は異なる実行環境です。VS2022 を維持するための x64 向け案内を、Arm64 の同等環境を維持する手順として扱わないようにします。2026年9月11日時点の整理は次のとおりです。
| 使用中のラベル | 変更・現在の位置付け | 確認すること |
|---|---|---|
windows-11-arm | Windows 11 Arm64。9月21日から30日に既定の VS が2026へ移行 | 新ラベルで同じビルド・テストを先行確認 |
windows-11-vs2026-arm | Windows 11 Arm64＋VS2026 の GA イメージ | VS2022 前提のツール・パス・依存関係 |
windows-latest／windows-2025 | x64。VS2026 への移行は6月の告知対象 | Arm64 の9月移行と区別して実行ログを確認 |
macos-latest | 現行の一覧では macOS 26 Arm64 | OS・Xcode・アーキテクチャの前提 |
使用可能なラベルとアーキテクチャは、GitHub-hosted runners の公式一覧でも確認できます。リポジトリから見える runner を調べる場合は、［Actions］→［Runners］の案内を参照してください。
Windows 11 Arm64＋VS2026 を先行確認する
まず .github/workflows 内の runs-on を調べます。直接指定だけでなく、matrix の値、inputs、vars、再利用ワークフローの呼び出し先まで確認してください。共通テンプレートだけを直しても、既存リポジトリのワークフローに反映されるとは限りません。
検証用のブランチなどで、対象ジョブのラベルを次のように変更します。これはrunner 選択部分だけの YAML 抜粋です。既存の steps にあるチェックアウト、セットアップ、ビルド、テストはそのまま残して比較します。
jobs:
build:
runs-on: windows-11-vs2026-armジョブ名が build 以外なら、実際の対象ジョブで変更します。matrix からラベルを渡している場合は、runs-on の式を壊さず、対応する matrix の値を変更してください。実行する検証ジョブに本番公開や配布のステップが含まれる場合は、その実行条件も先に確認します。
確認対象は「ジョブが緑になったか」だけではない
| 確認項目 | 比べる内容 |
|---|---|
| Visual Studio の検出 | VS2022 の固定パス、vswhere の絞り込み、MSBuild の選択が新環境でも妥当か |
| CMake・C++ の設定 | Visual Studio 17 2022 などの Generator、toolset、Windows SDK、必要なコンポーネント |
| 依存ツールと Actions | 利用している実行ファイルや Action が Windows Arm64 に対応するか。x64 向け前提が残っていないか |
| テスト・成果物 | 既存テスト、署名、パッケージ作成、インストーラ、生成物の対象アーキテクチャと動作 |
| 失敗した段階 | ツール検出・依存関係の復元・コンパイル・テスト・配布のどこで変化したか |
インストール済みソフトウェアは Windows 11 VS2026 Arm64 の公式構成一覧と照合します。VS2026 という名称だけで、必要な SDK や全ワークロードがそろっているとは判断できません。
Visual Studio の検出結果をログに残すなら、既存の steps に次の診断用ステップを追加できます。これは環境情報の出力であり、ビルドや互換性のテストは行いません。
- name: Show Visual Studio information
shell: pwsh
run: |
& "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -latest -products * -format json必要なツールが見つからなければ、その不一致を確認してからセットアップ手順や検出条件を修正します。失敗を無視する設定を加えて CI の成功だけを得ると、移行確認として使えなくなります。
移行を受け入れる場合と、別の runner に変える場合
windows-11-arm から VS2026 への自動移行を受け入れる場合、ラベル変更は必須ではありません。ただし、9月21日以降の実行結果と使われたイメージを確認できるようにしておきます。
Windows 11 Arm64 イメージの利用をやめる場合、標準 runner と larger runner で変更場所が異なります。変更先は、OS・アーキテクチャ・ツールチェーンの要件を満たすものから選びます。
| 種類 | 変更場所・確認点 |
|---|---|
| 標準 runner | ワークフローの runs-on を別の使用可能な runner に変更。Arm64 から x64 へ変えるなら、ビルド方式や成果物の差も確認 |
| larger runner | 管理画面で対象 runner に割り当てたイメージを変更。使用可能な選択肢と利用権限を確認 |
Organization の larger runner は、管理権限を持つ人が次の順に確認します。Enterprise 管理の runner では、Enterprise の［Policies］→［Actions］→［Runners］から対象を開きます。
- Organization の［Settings］→［Actions］→［Runners］を開く。
- 変更する runner を選ぶ。
- ［Image］に表示される、要件を満たすイメージを選んで［Save］する。
- その runner を使用するワークフローを確認し、変更後の環境でビルド・テストを行う。
この編集手順は GitHub 所有のイメージを対象とし、選択肢にも制約があります。詳しくは larger runner のイメージ変更手順を参照してください。Windows Arm64 の VS2022 環境を維持できる旧ラベルは、今回の告知では案内されていません。
x64 の Windows Server 2025 と VS2022 の扱い
windows-latest と windows-2025 は x64 の Windows Server 2025 イメージです。GitHub は2026年6月8日〜15日に既定の Visual Studio を2026へ移行すると告知しました。現行の公式一覧でも、両ラベルと windows-2025-vs2026 は同じイメージに対応しています。
x64 で VS2022 を必要とする場合、5月の公式告知では windows-2022 が案内されています。対象ジョブの runner 指定を次のように変更し、既存のステップで検証します。これは Arm64 を維持する指定ではなく、OS も Windows Server 2022 に変わるため、その差を含めて確認してください。
runs-on: windows-2022当初の移行日程と VS2022 向けの案内は 2026年5月14日のイメージ移行告知に記載されています。日付が過ぎた案内を「これから6月に移行する」と読み替えず、実行ログと現在の構成一覧を基準に判断します。
macOS は OS とアーキテクチャをそろえて比較する
macos-latest は、現行の一覧で macOS 26 Arm64 を指しています。5月の告知では、macOS 15 から26への移行を6月15日開始、30日間で進めるとされていました。macOS 15 のジョブを維持する場合は macos-15 を明示し、macOS 26 への対応を別途確認できます。
次は OS 比較用の YAML 抜粋です。実際の steps は既存のビルド・テストを残します。fail-fast: false は、一方の失敗だけでもう一方の matrix ジョブが打ち切られることを避ける設定です。
jobs:
test:
strategy:
fail-fast: false
matrix:
os: [macos-15, macos-26]
runs-on: ${{ matrix.os }}これらのラベルは Arm64 です。Intel の実行環境が必要なら、公式一覧の macos-15-intel や macos-26-intel など、対応するラベルを確認してください。OS の比較と CPU アーキテクチャの変更が同時に起きると、失敗原因を切り分けにくくなります。
macOS では Xcode、SDK、署名、Homebrew 経由のツールなども確認します。sw_vers や xcodebuild -version で環境を記録し、プロジェクト固有の scheme やテスト手順を用いて比較してください。
移行後もイメージの実体と更新を追う
各実行で使われたイメージとソフトウェアのバージョンは、ジョブログの ［Set up job］ を確認します。actions/runner-images の main にある構成一覧だけでは、特定の実行時点の環境と一致しない場合があります。公式リポジトリも、個々のビルドではこのログを参照するよう案内しています。
OS バージョンを含むラベルを指定しても、イメージ内のソフトウェアが丸ごと固定されるわけではありません。GitHub は通常、イメージのソフトウェアを週次で更新します。必要なツールのバージョンをセットアップ手順で明示し、公式リポジトリの構成一覧・移行告知と リリース情報を追ってください。
5月の Arm64 保守移管では、保守主体の変更に伴う機能・互換性は変わらないと案内され、Ubuntu Arm64 の移管期間中には更新の一時停止も告知されました。これは当時の保守移管の説明です。Windows 11 Arm64 の9月の VS2026 移行には、VS2022 依存による破損の可能性が別途明記されています。また、5月の告知だけを根拠に現在も Ubuntu Arm64 の更新が止まっているとは判断しないでください。
よくある質問
何も変更しなければ、Windows 11 Arm は使えなくなりますか？
告知されているのは windows-11-arm の既定環境を VS2026 へ移行する変更です。移行を受け入れるだけなら操作は不要ですが、ワークフローの VS2022 依存によっては修正が必要になる可能性があります。
windows-2022 にすれば Windows Arm64 の環境を残せますか？
残せません。windows-2022 は x64 の Windows Server 2022 です。Arm64 の検証を続ける要件がある場合は、単純な代替とせず、新しい Arm64 イメージでの対応可否を調べてください。
先行テストが成功したら、移行の確認は終わりですか？
その実行で確認したビルド・テストの範囲では有用な結果です。対象アーキテクチャ、署名、パッケージ、成果物の動作まで要件に合わせて確認し、移行後も実行イメージと結果を追います。ここで示した手順は確認方法であり、個別プロジェクトの互換性を実測・保証したものではありません。
コメント