GitHub Actionsの2026年4月アップデートで、Azure Private Networkingを使うホステッドランナーにVNETフェールオーバー機能がパブリックプレビューとして追加された。地味なアップデートに見えて、エンタープライズのCI/CD可用性にとっては結構デカい話だ。

何が変わったのか

Azure Private Networking に VNET フェールオーバーが来た

これまでGitHub ActionsのAzureプライベートネットワーク接続は、プライマリのAzureサブネットに障害が発生すると、その時点でワークフローが止まる仕組みだった。今回のアップデートで、セカンダリサブネット（別リージョンも可）をあらかじめ設定しておくことができるようになり、プライマリが落ちたときに自動または手動でフェールオーバーできるようになった。

フェールオーバーのトリガーは2種類:

  • 手動: ネットワーク設定UIまたはREST APIから明示的に切り替える
  • 自動: GitHubがリージョン障害を検知した際に自動で切り替え

フェールオーバーが発生すると、エンタープライズ・組織管理者に対して監査ログイベントとメールで通知が届く。手動フェールオーバーを実施した場合は、プライマリリージョンが復旧したあとの切り戻しも手動で行う必要がある点は覚えておきたい。

対象はAzureプライベートネットワークを使用しているエンタープライズ・組織アカウント。

OIDC トークンにリポジトリカスタムプロパティが正式対応（GA）

パブリックプレビューだったGitHub Actions OIDCトークンのリポジトリカスタムプロパティ対応がGAになった。

これによって、クラウドプロバイダー側のOIDCトラストポリシーを、個別のリポジトリ名やIDではなく「環境タイプ」「チームオーナーシップ」「コンプライアンスティア」のようなカスタムプロパティの値で制御できるようになる。リポジトリが増えるたびにクラウド側のロール設定を更新する手間が減り、組織のガバナンスモデルとクラウドアクセス制御を一致させやすくなる。

サービスコンテナのエントリポイント・コマンドのオーバーライドも追加

サービスコンテナのエントリポイントとコマンドをワークフローYAML内から上書きできるようになった。entrypointとcommandキーを使い、記法はDocker Composeと同様なので、馴染みのある書き方でそのまま使える。地道だが、今まで無理やりな回避策を取っていたユーザーには嬉しいアップデートだろう。

実務への影響

エンタープライズCI/CDの可用性要件が現実的に満たせる

Azureプライベートネットワーク経由でGitHub Actionsを動かしている環境は、セキュリティ要件上どうしてもパブリックランナーが使えない場面が多い。金融・官公庁・大手製造業などでは、このフェールオーバー機能があるかないかで、DR（ディザスタリカバリ）要件の充足度が変わってくる。

実務的には以下の点を押さえておきたい:

  • セカンダリサブネットのリージョン選択: プライマリと同一リージョンに置くのか別リージョンにするかで、RTO（目標復旧時間）が大きく変わる。コスト増を許容してでも別リージョンを選ぶ判断が必要な場合がある
  • 監査ログの設計: フェールオーバーイベントが監査ログに記録されるので、SIEMへの連携設計を事前にやっておく
  • 切り戻し手順の文書化: 手動フェールオーバー時の切り戻しは自動ではない。手順書とRunbookを今のうちに用意する

OIDC カスタムプロパティは今すぐ採用を検討すべき

リポジトリ数が多い組織では、個別リポジトリをクラウドロールにマッピングする運用がそのうち破綻する。OIDCカスタムプロパティの仕組みを使えば、リポジトリのタグ付け（例: env=production, team=platform）をそのままアクセス制御ポリシーに反映できる。スケーラブルなアクセス管理の基盤として、早めに設計を見直す価値がある。

筆者の見解

VNETフェールオーバー機能そのものは技術的に特別新しい概念ではない。Azure Load BalancerやTraffic Managerで散々やってきたことをGitHub Actionsのランナー基盤に持ち込んだというだけだ。ただ、これが「ようやく来た」という感覚は正直ある。

エンタープライズ導入の文脈でGitHub Actionsを提案するとき、必ずCI/CDパイプラインの可用性を問われる。「Azureリージョンが落ちたらビルドも止まるんですか？」という質問に対して、今まではフェールオーバーの仕組みがなかったので、正直に「止まります」と言うしかなかった。それが今後は「セカンダリ設定しておけば継続します」と答えられる。地味だが導入のハードルを下げる効果は大きい。

OIDCカスタムプロパティのGA化については、これが本当に正しい方向性だと思っている。**「禁止ではなく安全に使える仕組みを」**という観点から言えば、個別リポジトリを列挙してアクセス制御するのはスケールしないし、結局管理できなくなって「全部禁止」に振れる組織が出てくる。組織のガバナンスモデルを軸にアクセス制御を設計できる仕組みが整うことで、GitHub Actionsをガンガン使い倒せる組織が増えるはずだ。

AzureとGitHubの統合がじわじわと深まっているのを感じるアップデートだった。Microsoftがプラットフォームとしての安全な基盤を着実に固めている、その一端として評価している。

出典: この記事は Azure private networking for GitHub Actions hosted runners: failover networks in public preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。