GitHub Actionsがマルチクラウド計算を追加、対象のLinuxジョブはAWSでも動くためIP許可リストの更新が必要

GitHubは2026年10月28日、GitHub Actionsが対象のジョブを、より広いマルチクラウドの計算プールに振り分けるようになったと述べた。対象のLinuxジョブは、Microsoft Azureに加えてAmazon Web Services（AWS）でも動く場合がある。GitHubの狙いは、容量の増加、容量不足による待ち時間の短縮、ピーク時の耐障害性の向上だ。変更は段階的に展開され、Azureやマイクロソフトのアドレス範囲だけを許可するネットワーク許可リストが新しいランナーを遮断しうるという注意が付いている。

範囲は狭い。マルチクラウド計算は、標準の2コアと4コアのLinuxランナー、および特別な構成のない互換の2コアと4コアの大型ランナーに適用される。Windowsランナーや、プライベートネットワークなど特別な構成のランナーには適用されない。GitHubは、移るジョブの割合、アカウントごとの開始日、測定した待ち時間の改善を示していないので、利点は結果ではなく目標にとどまる。

誰が使うかはプランで決まる。GitHub Free、Pro、Teamの顧客では、対象のランナーが自動でマルチクラウド計算を使う。GitHub Enterprise Cloudの顧客は選択加入で、管理者がEnterprise settingsのActionsにあるHosted compute cloud providersでAWS計算を有効にする。GitHubによれば、対象ジョブは利用可能なプロバイダーに自動で振り分けられ、ランナーのラベルとワークフローの構文は変わらない。したがってチームがジョブごとにクラウドを選ぶことはない。Enterprise Cloudで選べるのは、AWS計算を許可するかどうかだけだ。

推奨される対応は、パイプラインを壊しうる部分だ。拡張されたプールのランナーは、追加の送信元IPアドレスを使う。Azureまたはマイクロソフト所有の範囲だけを許可するポリシー、Microsoft Entraの条件付きアクセスポリシーも含め、これらのランナーからの接続や認証を遮断することがある。典型的な被害は、ファイアウォールで守られたデータベース、プライベートなパッケージレジストリ、呼び出し元アドレスを確認するクラウドAPIにアクセスするジョブだ。展開は段階的なので、こうした失敗は一度に全部ではなく一部のジョブで断続的に現れ、原因の特定がかえって難しくなる。

GitHubの解決策は、クラウド別のリストを保守するのをやめることだ。新しいものを含むGitHub ActionsランナーのIP範囲はすべて、GET https://api.github.com/metaの応答にあるactions配列で公開されている。GitHubは、特定のクラウドの範囲に頼らずこのエンドポイントと許可リストを同期するよう勧め、ワークフローが拡張プールで動き始める前の今のうちに行うよう推奨している。公開リストは変わりうるので、同期をスクリプト化して定期的に動かすとよい。選択加入しないEnterprise Cloudの顧客は新しいアドレスを避けられるが、この選択がいつまで続くかは変更履歴にない。

多くのチームにとって作業は小さく具体的だ。GitHubホストのランナーを通すファイアウォール規則、条件付きアクセスポリシー、クラウドのセキュリティグループをすべて探し、固定の範囲をmetaエンドポイントのリストに置き換え、展開開始後にログで遮断された接続を確認する。Windowsランナー、特殊用途の大型ランナー、プライベートネットワークを使うチームは、これらが今回の発表の対象外であることを覚えておくとよい。