GitHub Actions macOS 14 Runnerの退役に備えるなら、まず組織全体の旧ラベル依存を一覧化し、設定と実行記録を照合してからワークロードごとに移行を検証してください。既定ブランチのYAMLだけを検索しても、全タスクを洗い出した証拠にはなりません。
GitHub組織管理者：各リポジトリに旧Runnerラベルが残っていないか確認したい方。
CI基盤担当者：再利用ワークフローや動的設定、実行履歴まで把握したい方。
開発・リリース責任者：ビルド、テスト、公開処理の移行を証拠に基づいて承認したい方。
最終更新：2026年10月8日。退役日、対象ラベル、brownoutと代替ラベルの情報はGitHub公式の退役告知で確認しています。公開前にも告知内容と関連するRunner情報を再確認してください。
GitHub Actions macOS 14 Runner退役の前に、何を証拠として残すべきですか？
GitHubの告知では、macOS 14 Runnerイメージは2026年11月2日に退役予定です。対象として示されたラベルはmacos-14、macos-14-large、macos-14-xlargeです。退役日と対象範囲は公式告知を基準にし、退役前のbrownout期間や代替ラベルも変更がないか確認します。
洗い出しの完了条件は、単にラベル検索の結果がゼロになることではありません。対象リポジトリ、確認できなかった範囲、設定の定義元と利用箇所、実際の実行結果、未解決の例外が追跡できる状態にすることです。
注意：退役告知の対象はGitHubが管理するmacOS 14 Runnerイメージです。この発表だけを根拠に、自社運用のMacや別の実行環境まで退役すると判断しないでください。
どこを探すと、旧ラベルの見落としを減らせますか？
検索対象は、ワークフローファイルだけでなく、ラベルが定義・加工・受け渡しされる場所まで広げます。GitHubのワークフロー構文ではジョブの実行先を指定でき、コンテキストと式や式の構文を使った値の組み立ても確認対象になります。
| 確認箇所 | 見落としやすい依存 | 残す記録 |
|---|---|---|
| 各リポジトリのワークフロー | runs-onに直接書かれた旧ラベル |
リポジトリ、ファイル、ジョブ |
| 再利用ワークフロー | 呼び出し側の入力と、呼び出される側の実行先 | 呼び出し元、定義元、渡される値 |
| マトリックス・式 | 変数や条件から組み立てられるラベル | 値の定義元、条件、展開後の値 |
| 生成・配布される設定 | テンプレートや生成処理が作るワークフロー | 生成元、反映先、更新担当 |
| 実行記録 | 特定ブランチや手動実行に限られるジョブ | イベント、ラベル、確認できた最新の実行 |
再利用ワークフローでは、呼び出し側だけを直しても、再利用先で旧ラベルを固定していれば依存は残ります。反対に、再利用先の定義だけを変更しても、呼び出し側から古い値が渡される設計なら同様です。再利用ワークフローの仕様を確認し、値の受け渡しを両方向から追ってください。
GitHub Actionsのワークフロー盤点を進める手順
次の順で、作業者が変わっても範囲と判断根拠を再確認できる記録を作ります。
第一段階：対象範囲を固定する
- [ ] 組織内のリポジトリ一覧を作り、対象・対象外と判断理由を記録する。
- [ ] 既定ブランチに加え、保守中のブランチやリリース用ブランチを確認対象に含める。
- [ ] 権限不足、アーカイブ、アクセス不能など、確認できなかったリポジトリを別枠で記録する。
一度のコード検索を、全組織の確認完了として扱わないでください。対象外や未アクセスの範囲を明示すれば、後から監査範囲を説明できます。
次の段階：定義元から実行記録まで追う
- [ ] ワークフロー、再利用ワークフロー、入力値、マトリックス、式、生成テンプレートを検索する。
- [ ] 旧ラベルの定義元と、値を利用するジョブを対応付ける。
- [ ] ワークフロー名、イベント、Runnerラベル、確認できた最新の実行結果を記録する。
- [ ] 定期実行、特定ブランチ限定、手動実行など、通常のPR確認では動かない条件を洗い出す。
- [ ] 重要なビルド、テスト、署名・公開処理について担当者と業務影響を記す。
実行結果の補完には、ワークフロー実行のREST APIも利用できます。取得できる履歴だけで対象範囲を推定するのではなく、実行記録がないタスクも「未確認」として残すのが要点です。
補足：最近の実行に失敗がないことは、退役の影響がない証拠ではありません。条件付きでしか走らないジョブや、長期間実行されていないリリース工程も個別に確認します。
最終段階：代替ラベルとリスクを検収する
GitHubのRunner選択に関する公式ドキュメントと退役告知を参照し、代替候補とその状態を確認します。ただし、公式に推奨される候補であっても、あなたのプロジェクトでビルド、テスト、署名、成果物の公開まで成功するとは限りません。
移行前後の設定差分、実行結果、失敗項目、未解決の互換性問題を保存してください。待ち時間や性能を実測していない場合は、代替Runnerのキューや速度を推測で評価せず、実際のパイプライン結果を判断材料にします。
どの依存を先に解消し、何をもって完了としますか？
優先度はラベルが見つかった件数ではなく、止まった場合の業務影響と、代替環境での検証状況で決めます。PRの通常検証とリリースを止める署名・公開工程は分けて扱い、責任者と未解決事項が不明なタスクを移行済みにしないでください。
完了の承認前に、一覧の各項目を「検証済み」「承認済みの一時例外」「未解決」に分類します。未検証の重要タスク、担当者不在の例外、設定差分と実行結果の紐付け漏れが残る場合は、全体完了ではなく保留として扱うのが安全です。
よくある確認事項
既定ブランチの検索で旧ラベルが見つからなければ十分ですか？
十分ではありません。保守中のブランチ、再利用ワークフロー、動的に渡される値、生成設定、手動や定期実行のタスクも対象になり得ます。検索対象とアクセスできなかった範囲を記録し、静的な検索結果を実行履歴と照合して初めて、組織内の確認範囲を説明できます。
代替ラベルへ置き換えた時点で移行完了ですか？
置換だけでは完了と判断できません。プロジェクト固有のツールチェーン、テスト、署名、公開まで実行し、差分と結果を保存します。失敗したタスクや実行できていない工程は未解決として残し、一般的な検証の成功をリリース経路全体の成功と混同しないことが重要です。
旧ラベルを使うジョブが最近動いていなければ、一覧から外せますか？
実行されていないことは、依存が存在しないことを意味しません。リリース時や特定ブランチ、手動操作でのみ起動するジョブは、通常の開発サイクルでは記録に現れない場合があります。ワークフローの起動条件と担当者を確認し、不要と承認されるまでは未確認の依存として管理してください。
移行後のMac CIをどのように運用へつなげますか？
GitHub ActionsのホストRunnerを継続するか、自社で管理するMac環境を使うかは、業務上の制御要件と運用負荷を分けて判断します。ホストRunnerでは組織の設定やRunnerイメージの変更に追随する必要があり、実行環境の永続状態や社内依存へのアクセスを自分で完全に制御できるわけではありません。一方、自前のMacは調達・保守・アクセス管理が必要で、稼働責任も自社に残ります。
署名や社内ネットワークへの接続など、検証済みの特定タスクに管理下のMacが必要なら、まず対象工程を切り分けてください。Mac CIの用途とリモートMacの利用条件を照らし合わせ、短期検証や一時的な環境需要にはKVMFLUXの料金周期も比較材料にできます。実際の構成、接続方式、社内要件との適合は契約前に確認し、長期の常時高負荷や物理接続が必要な用途では、自社保有も含めて判断してください。
まずは組織・リポジトリ・再利用設定・実行記録をつなぐ一覧を作り、未検証の重要工程を移行完了に含めないことが先決です。そのうえで特定のMac CIワークロードに別の承載環境が必要なら、管理要件と運用責任を比較して選択してください。
関連記事
よくある質問
GitHub ActionsのmacOS 14 Runnerはいつ退役しますか？
GitHubの公式告知では、macOS 14 Runnerイメージの退役日は2026年11月2日です。対象としてmacos-14、macos-14-large、macos-14-xlargeが示されています。退役日だけを予定表に登録するのではなく、告知に記載された一時的なbrownout期間と代替ラベルも、作業開始時に公式情報で再確認してください。
macos-14を使うワークフローを漏れなく見つけるには？
既定ブランチのYAML検索だけでは不十分です。組織内の対象リポジトリと保守中のブランチを記録し、再利用ワークフロー、呼び出し元の入力値、マトリックスや式で生成されるラベルも追跡します。そのうえで実行履歴と照合し、検索できなかったリポジトリや未実行のタスクを未確認項目として残します。
再利用ワークフローのRunnerラベルはどこまで調べるべきですか？
呼び出し元のジョブだけでなく、再利用される側のワークフローと、Runnerラベルを渡す入力や式の定義元まで確認します。設定の所在と実際に消費するジョブを対応付けると、テンプレートだけ直して呼び出し側が旧ラベルを渡し続ける、といった見落としを発見しやすくなります。
移行が全リポジトリで完了したと証明するには？
対象範囲、検索方法、例外、未アクセスのリポジトリを記録し、静的な設定一覧に実際の実行結果を結び付けます。重要なビルドや署名・公開処理は、対象プロジェクトのパイプラインで新しいラベルを使って検証してください。失敗が最近なかったことや、設定ファイルを一度検索したことだけでは、移行完了の証拠になりません。