ソースコードを変えていないのに、CIが突然失敗する。原因がアプリではなく、実行環境の更新にあることもあります。GitHub Actionsでubuntu-latestを使っているチームは、次のOS移行を確認しておきましょう。

GitHubは2026年9月17日、Ubuntu 26.04のGitHub-hosted runnerを一般提供に移したと発表しました。x64とarm64が対象です。本稿はこの発表を基に、実行環境を段階的に検証する方法を整理します。GitHub公式発表

<style> .u26-summary,.u26-note{padding:1.2rem;margin:1.5rem 0;border:1px solid #cad5e6;border-radius:16px;background:#eef4ff;color:#172d45}.u26-summary p:last-child,.u26-note p:last-child{margin-bottom:0}.u26-cards,.u26-timeline{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,210px),1fr));gap:12px;margin:1.5rem 0}.u26-card,.u26-stage{padding:1.15rem;border:1px solid #cad5e6;border-radius:14px;background:#fff;color:#172d45}.u26-stage strong{display:block;font-size:1.7rem;color:#a63713}.u26-stage h3,.u26-card h3{margin-top:0}.u26-table{overflow-x:auto;margin:1.5rem 0}.u26-table table{border-collapse:collapse;width:100%;min-width:650px}.u26-table th,.u26-table td{padding:.85rem;border:1px solid #cad5e6;text-align:left}.u26-table th{background:#e8effc;color:#172d45}.u26-note{background:#fff5e6;border-left:5px solid #9d5c00}.u26-flow{padding:1.2rem;border:1px solid #cad5e6;border-radius:16px;background:#f3f7fc;color:#172d45}.u26-flow li{margin:.65rem 0} </style>

日程：発表日と自動移行日は別

公式発表によると、ubuntu-latestはUbuntu 24.04から26.04へ、2026年10月19日～11月19日に段階移行する予定です。準備が間に合わない場合は、ubuntu-24.04の明示指定が案内されています。移行期間と回避策

これは24.04イメージ自体の廃止日を示すものではありません。また、一般提供は「自分たちのアプリが動作保証される」という意味でもありません。

GitHub Docsは、-latestをGitHubが提供する最新の安定イメージと説明しています。OSベンダーの最新リリースと常に一致するラベルではなく、実行されたランナーはワークフローログで確認できます。ランナー仕様とログの確認

何が変わる？ OS・ライブラリ・既定ツール

runner-imagesの公式告知では、選抜された比較項目として次の値が掲載されています。これは告知時点の表であり、以後のイメージ更新を固定するものではありません。公式のソフトウェア比較

数字が同じツールがあっても、システムライブラリやアーキテクチャまで同じとは限りません。例えば、ネイティブ拡張、配布バイナリ、ブラウザー試験の依存関係、aptで導入するパッケージなどを、検証対象として洗い出すのが実務上の出発点です。これは本稿の確認提案であり、特定の障害が発生したという報告ではありません。

Node24移行とは、別の確認対象

先日のNode20削除・Node24移行の記事では、JavaScript Actionの実行ランタイムを整理しました。今回の更新点はホストOSイメージの一般提供とlatestラベルの切替日程です。

Actionの更新を済ませても、OS互換性試験が終わったことにはなりません。逆にOSを24.04に固定しても、Actionの実行ランタイム移行への対応を代替できません。変更項目を分けて管理すると、失敗原因を切り分けやすくなります。

実践例：まず新旧イメージの診断を並べる

次は手動実行する環境診断専用のワークフロー例です。リポジトリのコードは取得せず、デプロイもしません。実際のアプリ試験を代替するものではなく、OSとツールの差を可視化する最初の一歩です。本記事制作時にこの例をGitHub Actions上で実行したわけではありません。

マトリクスは同じジョブ定義を複数条件で実行する仕組みです。fail-fast: falseを使い、一方で失敗しても他方の診断結果を取得できるようにします。GitHub Docsのマトリクス仕様

name: Compare Ubuntu runner environments
on:
  workflow_dispatch:
permissions: {}
jobs:
  inventory:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-24.04, ubuntu-26.04]
    runs-on: ${{ matrix.os }}
    timeout-minutes: 10
    steps:
      - name: Inspect OS and selected tools
        shell: bash
        run: |
          cat /etc/os-release
          uname -srmo
          for tool in git node npm docker; do
            if command -v "$tool" >/dev/null 2>&1; then
              "$tool" --version
            else
              printf '%s: not installed\n' "$tool"
            fi
          done

手動実行には、対象ワークフローをデフォルトブランチに置くなどGitHub側の要件があります。実行権限や組織のActionsポリシーも確認してください。手動実行の要件 環境変数を丸ごとログへ出す必要はありません。

診断後は、同じコミット・同じ依存関係でビルドと試験を比較します。既存のチェックアウト、ツール設定、インストール、テストの手順を検証用ジョブへ適用し、アクション参照や言語バージョンは比較の途中でむやみに変更しないようにします。

導入判断のチェックリスト

以下は本稿の実務提案です。「緑のチェックが出た」だけでなく、何を比較したかを記録します。

開発者と企業への影響

開発者は、同じアプリを新旧OSで比較するジョブを用意します。保守担当は、暗黙に使っているツールやパッケージを洗い出します。運用担当は、実際に使われたイメージをログから確認し、戻す際の承認と担当を決めます。

導入支援やコンサルでは、「最新へ変更した」だけで完了にせず、対象ワークフロー、試験範囲、未解決項目、固定期限を成果物として残すと、顧客の判断につながります。比較ジョブを増やす場合は、実行枠と利用時間の増加も計画に含めましょう。

リスクと限界：固定は完全な再現性ではない

ubuntu-24.04のようにOS世代を固定しても、その世代のイメージやパッケージが永遠に同じ内容になるわけではありません。再現性が重要なら、使用ツール、依存関係、コンテナイメージなども個別に管理する必要があります。

また、ホストOSを変えれば、コンテナ内でビルドするジョブでも影響が完全にゼロとは言えません。ホスト側で行うチェックアウト、Docker操作、マウント、ネットワークなど、実際の境界を確認してください。

本稿は速度や費用の改善を測定していません。一般提供になったことと、既存環境より速いことは別です。arm64での検証も、x64の成功結果から推測せず別に行います。

今後見るべきこと

公式の移行告知に変更がないか、runner-imagesのソフトウェア一覧や既知の問題、自社の実行ログを継続確認します。特に段階移行期間中は、latestという設定名だけで原因を判断しないことが重要です。

今日できる一歩は、26.04の検証ジョブを本番デプロイから分離して追加すること。 自動切替を待つ前に、動く条件と戻す条件を明確にしておきましょう。

最終確認日：2026年9月18日（日本時間）。日程と掲載バージョンは提供元の情報、検証手順と判断表は本稿の提案です。

参照元

• GitHub Changelog：Ubuntu 26一般提供とlatest移行（9月17日）
• runner-images：一般提供告知とソフトウェア比較
• GitHub Docs：GitHub-hosted runnersの仕様
• GitHub Docs：マトリクスによるジョブの条件別実行