ACS事業部の瀧澤です。

2026年1月末、Actionsで使えるランナーについてGitHubから嬉しいアップデートが発表されました。

これまでプライベートリポジトリでarm64環境を利用するには、コストや運用面でのハードルがありましたが、今回のアップデートで「標準ランナー」として手軽に選択できるようになりました。

今回は、これまでの課題がどう改善されたのか簡単に紹介します。

これまでの課題

これまでGitHub Actions（プライベートリポジトリ）でarm64向けのビルドを行うには、主に2つの選択肢がありました。しかし、それぞれに実運用上の課題がありました。

① QEMUによるエミュレーション

amd64のランナー(ubuntu-latest等)上でdocker/setup-qemu-actionを使い、エミュレーション経由でarm64ビルドを行う手法です。

課題: 設定は簡単で便利である一方、エミュレーションのコストが高く、ビルド時間が大幅に伸びます。特に依存関係が多いアプリケーションでは1時間以上かかることもあり、生産性低下につながっていました。

② macOSランナーを利用

GitHubでは以前からmacOSランナー（macos-latest等）が提供されていました。

課題: macOS上でDockerを動かすにはColimaなどのコンテナランタイムを自前でセットアップする必要があります。しかし、GitHub Actionsの仮想マシン上でさらに仮想化を行う「VM in VM」の制約により、パフォーマンスが出なかったり、動作が不安定だったりと、運用ハードルが高いものでした。

補足: Large Runnerについて

実は「Large Runner」を使えば以前からUbuntuのarm64版は利用可能でした。しかし、Large Runnerは「使った分だけ課金」の割高なプランであり、小規模なプロジェクトやコスト感に厳しい現場では手が出しにくい存在でした。今回のアップデートは、これがStandard Runner（標準ランナー）として利用可能になったことが画期的といえます。

ネイティブ環境による高速化

今回のアップデートにより、以下スニペットのようにワークフロー定義を変更するだけでネイティブなarm64環境が利用可能です。（GitHubホステッドランナーで利用可能なイメージ一覧はこちら）

jobs:
  build-arm64:
    # ネイティブなarm64ランナーを指定(QEMUセットアップ不要)
    runs-on: ubuntu-24.04-arm
    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          # プラットフォームでarm64指定
          platforms: linux/arm64
          tags: ghcr.io/${{ github.repository }}:latest-arm64

従来の方法と比較したメリット

ビルド速度の劇的な向上: エミュレーションなしのネイティブビルドになるため、QEMU利用時に比べて数倍〜十数倍の高速化が期待できます。
コスト最適化: Standard Runnerの料金体系で利用できるため、Large Runnerを契約するほどではないプロジェクトでも導入可能です。

実際にチームで開発しているTypescriptアプリのイメージビルド時間も大幅に短縮されました

元々: 50分経っても終わる気配がなかったためキャンセル・・・（amd64版は数分で終了）修正後: 5分程度で終わるように

おまけ：マルチプラットフォームイメージについて

マルチプラットフォームイメージとは、単一のイメージタグ（例：:latest）でありながら、実行環境のOSやアーキテクチャに応じて最適なバイナリを自動的に選択・実行できる仕組みです。(Multi-platform | Docker Docs)

開発環境としてApple Silicon（Mシリーズチップ）搭載のMacを利用している場合、Rosettaによるエミュレーションでamd64イメージを動作させることも可能ですが、CPUヘビーなワークロードを稼働させようとすると動作が不安定・低速になります。

linux/arm64 イメージをネイティブビルドして配布することで、これらの環境でも安定かつ高速にコンテナを動作させることが可能になります。

マルチプラットフォームイメージをビルドするには？

Docker公式（Distributed Build）では、amd64とarm64それぞれのランナーで並列にビルドを実行し、最後にそれらを統合したマニフェストを作成する手法が推奨されています。

ubuntu-latest (amd64) でビルド＆Push
ubuntu-24.04-arm (arm64) でビルド＆Push
docker buildx imagetools create で1つのタグにまとめる

これにより、ユーザーは docker pull するだけで、自分の環境に最適なイメージを自動で取得できるようになります。

利用可能なプラットフォームを確認する

自分が使っているイメージがどのプラットフォームに対応しているかは、以下のコマンドで簡単に確認できます。

docker manifest inspect ghcr.io/your-repo/your-app:latest

試しにpostgresの公式イメージを確認してみると、linux/amd64,linux/arm64を含めた複数アーキテクチャに対応していることがわかります

$ docker manifest inspect postgres 
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "manifests": [
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "size": 3439,
         "digest": "sha256:2ccc3d98b960df5ed1ee2d32d3d5338a3c688cf899c0e951ce6d45fb07395abc",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
・・・(略)・・・
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "size": 3441,
         "digest": "sha256:36f212504f71344d58644644fbf325d40e0b36b091ae8c1ed9a567a77a430320",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      },
・・・(略)・・・
   ]
}

まとめ

プライベートリポジトリでもarm64標準ランナーが提供されたことにより、これまでトレードオフとなっていたビルド速度・コストのバランスが劇的に改善されました。

ビルド時間の長さやLarge Runnerのコストに悩まされていた方はぜひubuntu-24.04-armランナーの利用を検討してみてください。

ACS 事業部のご紹介

私達 ACS 事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering などを活用し、攻めの DX 成功に向けた開発者体験の向上・内製化のご支援をしております。
www.ap-com.co.jp www.ap-com.co.jp また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。 www.ap-com.co.jp