GitHub ホステッドランナーの概要

ランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。たとえば、ランナーはリポジトリをローカルにクローンし、テストソフトウェアをインストールしてから、コードを評価するコマンドを実行できます。

GitHub は、ジョブの実行に使用できるランナーを提供します。または、独自のランナーをホストすることもできます。各 GitHub ホステッドランナーは、ランナーアプリケーションとその他のツールがプレインストールされた GitHub によってホストされる新しい仮想マシン (VM) であり、Ubuntu Linux、Windows、または macOS オペレーティングシステムで使用できます。 GitHubホストランナーを使用すると、マシンのメンテナンスとアップグレードが自動的に行われます。

標準の GitHub ホステッドランナーオプションのいずれかを選択できます。あるいは、GitHub Team プランまたは GitHub Enterprise Cloud プランの場合は、より多くのコアを持つランナー、または GPU または ARM プロセッサを搭載したランナーをプロビジョニングできます。これらのマシンは "より大きなランナー" と呼ばれます。詳しくは、「より大きなランナーの概要」を参照してください。

GitHub ホステッドランナーを使用するには、アップロードおよびダウンロード速度が 70 kbps 以上のネットワークアクセスが必要です。

GitHub ホステッドランナーの使用

GitHub ホステッドランナーを使用するには、ジョブを作成し、runs-on を使用してジョブを処理するランナーの種類を指定します (例: ubuntu-latest、windows-latest、または macos-latest)。ランナーの種類の完全な一覧については、「GitHub ホステッドランナーの概要」を参照してください。リポジトリに repo: write アクセス許可を持っている場合は、リポジトリ内のワークフローで使用できるランナーの一覧を表示できます。詳細については、「リポジトリの使用可能なランナーを表示する」を参照してください。

ジョブが開始されると、GitHub によって、そのジョブの新しい VM が自動的にプロビジョニングされます。ジョブ中のすべてのステップは VM で実行されるため、ランナーのファイルシステムを使用して、そのジョブにおけるステップで情報を共有することができます。ワークフローは、VM で直接実行することも、Docker コンテナーで実行することもできます。ジョブが完了すると、VM は自動的に使用停止になります。

次のダイアグラムは、2 つの異なる GitHub ホステッドランナーでワークフロー内の 2 つのジョブがどのように実行されるかを示しています。

2 つのジョブで構成されるワークフローの図。 1 つのジョブは Ubuntu で実行され、もう 1 つは Windows で実行されています。

次のワークフロー例には、Run-npm-on-Ubuntu および Run-PSScriptAnalyzer-on-Windows という名前のついた 2 つのジョブがあります。このワークフローがトリガーされると、GitHub ではジョブごとに新しい仮想マシンをプロビジョニングします。

Run-npm-on-Ubuntu という名前のジョブは Linux VM で実行されます。これは、ジョブの runs-on: で ubuntu-latest が指定されているためです。
Run-PSScriptAnalyzer-on-Windows という名前のジョブは Windows VM で実行されます。これは、ジョブの runs-on: で windows-latest が指定されているためです。

YAML

name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

ジョブの実行中、ログと出力は GitHub UI で表示できます。

ワークフロー実行のスクリーンショット。 [Run PSScriptAnalyzer on Windows] (Windows で PSScriptAnalyzer を実行する) ジョブのステップが表示されています。

GitHub Actionsランナーアプリケーションはオープンソースです。ランナーリポジトリでイシューを投稿およびファイルできます。

リポジトリで使用可能なランナーの表示

リポジトリに repo: write アクセス許可を持つ場合は、リポジトリで使用できるランナーの一覧が表示されます。

GitHub で、リポジトリのメインページに移動します。
リポジトリ名の下にある [アクション] をクリックします。
左サイドバーの [管理] セクションで、[ランナー] をクリックします。
リポジトリで使用可能な GitHub ホステッドランナーの一覧を確認します。
必要に応じて、ランナーのラベルをコピーしてワークフローで使用するには、ランナーの右側にあるをクリックし、[ラベルのコピー] をクリックします。

注: Enterprise オーナーと Organization オーナーは、このページからランナーを作成できます。新しいランナーを作成するには、ランナーの一覧の右上にある [新しいランナー] をクリックして、リポジトリにランナーを追加します。

詳細は、「より大きなランナーを管理する」または「自己ホストランナーの追加」を参照してください。

サポートされているランナーとハードウェアリソース

GitHub ホストランナーは、パブリックリポジトリとプライベートリポジトリの両方で使用できます。

GitHub ホスト型 Linux ランナーは、Android SDK ツールのハードウェアアクセラレーションをサポートしています。これにより、Android テストの実行が大幅に高速化され、使用時間が短縮されます。 Android ハードウェアアクセラレーションの詳細については、Android Developers ドキュメントの「Android Emulator のハードウェアアクセラレーションを設定する」を参照してください。

Note

-latest ランナーイメージは、GitHub が提供する最新の安定したイメージであり、オペレーティングシステムベンダーから入手できるオペレーティングシステムの最新バージョンではない可能性があります。

警告: ベータ版および非推奨のイメージは、"現状のまま"、"保証なし"、"利用可能な状態" で提供され、サービスレベルアグリーメントと保証から除外されます。ベータ版のイメージは、カスタマーサポートでカバーされない場合があります。

パブリックリポジトリの標準の GitHub でホストされたランナー

パブリックリポジトリの場合、次の表に示すワークフローラベルを使用するジョブは、関連付けられた仕様を持つ仮想マシンで実行されます。パブリックリポジトリでのこれらのランナーの使用は無料で無制限です。

仮想マシン	プロセッサ (CPU)	メモリ(RAM)	ストレージ (SSD)	ワークフローラベル
Linux	4	16 GB	14 GB	`ubuntu-latest`、、、`ubuntu-24.04ubuntu-22.04ubuntu-20.04`
Windows	4	16 GB	14 GB	`windows-latest`、、`windows-2022windows-2019`
macOS	3	14 GB	14 GB	`macos-12`
macOS	4	14 GB	14 GB	`macos-13`
macOS	3 (M1)	7 GB	14 GB	`macos-latest`、`macos-14`、`macos-15`［パブリックプレビュー］

プライベートリポジトリの標準の GitHub でホストされたランナー

プライベートリポジトリの場合、次の表に示すワークフローラベルを使用するジョブは、関連付けられた仕様を持つ仮想マシンで実行されます。これらのランナーは、GitHub アカウントの無料の分の割り当てを使用し、分単位の料金で課金されます。詳しくは、「GitHub Actions の課金について」を参照してください。

仮想マシン	プロセッサ (CPU)	メモリ(RAM)	ストレージ (SSD)	ワークフローラベル
Linux	2	7 GB	14 GB	`ubuntu-latest`、`ubuntu-24.04`、`ubuntu-22.04`、`ubuntu-20.04`
Windows	2	7 GB	14 GB	`windows-latest`、`windows-2022`、`windows-2019`
macOS	3	14 GB	14 GB	`macos-12`
macOS	4	14 GB	14 GB	`macos-13`
macOS	3 (M1)	7 GB	14 GB	`macos-latest`、`macos-14`、`macos-15`［パブリックプレビュー］

ワークフローログには、ジョブの実行に使用されたランナーが一覧表示されます。詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。

arm64 macOS ランナーの制限事項

GitHub によって提供されるすべてのアクションは、arm64 GitHub ホストランナーと互換性があります。ただし、コミュニティアクションは arm64 と互換性がない場合があり、実行時に手動でインストールする必要があります。
Apple の仮想化フレームワークの制限により、入れ子になった仮想化と Metal Performance Shaders (MPS) はサポートされていません。
現在、macOS の大規模ランナーでは、Azure プライベートネットワークや静的 IP の割り当てなどのネットワーク機能は使用できません。
Apple ではこの機能がサポートされていないため、arm64 macOS ランナーには、静的 UUID/UDID が割り当てされていません。ただし、Intel MacOS ランナーには、静的 UDID、特に 4203018E-580F-C1B5-9525-B745CECA79EB が割り当てられます。ビルドをテストする予定の同じホストでビルドして署名する場合は、開発プロビジョニングプロファイルを使用して署名できます。静的 UDID が必要な場合は、Intel ランナーを使用して、その UDID を Apple Developer アカウントに追加できます。

より大きなランナー

GitHub Team プランと GitHub Enterprise Cloud プランのお客様は、標準の GitHub ホステッドランナーよりも多くのリソースを持つさまざまなマネージド仮想マシンから選択できます。これらのマシンは "より大きなランナー" と呼ばれます。これらには、次の高度な機能が用意されています。

追加の RAM、CPU、ディスク領域
静的 IP アドレス
Azure プライベートネットワーク
ランナーをグループ化する機能
同時実行ワークフローをサポートするための自動スケール
GPU 搭載ランナーと ARM 搭載ランナー

これらのより大きなランナー (larger runner) は、GitHub によってホストされ、ランナーアプリケーションとその他のツールをプレインストールしています。

詳しくは、「より大きなランナーの使用」を参照してください。

サポートされているソフトウェア

GitHub ホストランナーに含まれているソフトウェアツールは毎週更新されます。更新プロセスには数日かかり、main ブランチのプレインストール済みソフトウェアのリストは、デプロイ全体が終了した後で更新されます。

プレインストール済みソフトウェア

ワークフローログには、正確なランナーにプレインストールされているツールへのリンクが含まれています。ワークフローのログでこの情報を見つけるには、Set up job セクションを展開します。そのセクションの下で、Runner Image セクションを展開します。 Included Software の後のリンクで、ワークフローを実行したランナーにプレインストールされているツールが示されています。

詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。各ランナーオペレーティングシステムに含まれるツールの全体的なリストについては、ランナーイメージリポジトリの使用可能なイメージドキュメントを参照してください。

GitHubホストランナーには、オペレーティングシステムのデフォルトの組み込みツールに加え、上のリファレンスのリスト内のパッケージにが含まれています。たとえば、Ubuntu と macOS のランナーには、他の既定のツールと共に grep、find、which が含まれます。

Windows と Ubuntu のランナーイメージのビルドごとにソフトウェア部品表 (SBOM) を表示することもできます。詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。

プレインストール済みソフトウェアを使用する

アクションを使用して、ランナーにインストールされているソフトウェアと対話することをお勧めします。この方法には、いくつかの利点があります。

アクションでは通常、バージョンの選択、引数を渡す機能、パラメータなどの機能が提供されています
これにより、ソフトウェアの更新に関係なく、ワークフローで使用されるツールのバージョンが同じままになります

要求したいツールがある場合は、actions/virtual-environments で issue を開いてください。このリポジトリには、ランナーに関するすべての主要なソフトウェア更新に関するお知らせも含まれています。

追加ソフトウェアをインストールする

GitHub ホステッドランナーに追加のソフトウェアをインストールできます。詳細については、「GitHub ホステッドランナーのカスタマイズ」を参照してください。

GitHub ホステッドランナーによって使用されるクラウドホスト

GitHub は、Microsoft Azure の仮想マシン上で GitHub Actions ランナーアプリケーションがインストールされた Linux および Windows ランナーをホストします。 GitHubホストランナーアプリケーションは、Azure Pipelines Agentのフォークです。インバウンドのICMPパケットはすべてのAzure仮想マシンでブロックされるので、pingやtracerouteコマンドは動作しないでしょう。 GitHub は、Azure データセンターで macOS ランナーをホストします。

Linux および Windows ランナーの場合には、GitHub は仮想マシン Dadsv5-series 使用します。詳細については、Microsoft Azure ドキュメントの「Dasv5 および Dadsv5 シリーズ」を参照してください。

GPU ランナーでは、 NCasT4_v3-series 仮想マシンを使用します。詳しくは、Microsoft Azure ドキュメントの「NCasT4_v3シリーズ」をご覧ください。

ワークフローの継続性

GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。

さらに、ワークフロー実行が正常にキューに入れられても、45 分以内に GitHub ホステッドランナーによって処理されない場合、キューのワークフロー実行は破棄されます。

管理者特権

Linux と macOS のどちらの仮想マシンでも、パスワードレスの sudo が実行されます。現在のユーザーより高い特権が必要なコマンドやインストールツールを実行する必要がある場合は、パスワードを入力する必要なく、sudo を使うことができます。詳しくは、Sudo のマニュアルをご覧ください。

Windowsの仮想マシンは、ユーザアカウント制御（UAC）が無効化されて管理者として動作するように設定されています。詳しくは、Windows のドキュメントの「ユーザーアカウントの制御のしくみ」をご覧ください。

IP アドレス

GitHub Actions で GitHub ホステッドランナーに使われる IP アドレス範囲のリストを取得するには、GitHub REST API を使用できます。詳しくは、actions エンドポイントの応答で GET /meta キーをご覧ください。詳しくは、「メタデータ用 REST API エンドポイント」を参照してください。

Windows及びUbuntuのランナーはAzureでホストされており、そのためAzureのデータセンターと同じIPアドレスの範囲を持ちます。 macOSランナーはGitHub独自のmacOSクラウドでホストされます。

GitHub ホステッドランナーには非常に多くの IP アドレス範囲があるため、内部リソースの許可リストとしてこれらを使うことはお勧めしません。代わりに、静的 IP アドレス範囲またはセルフホステッドランナーでより大きなランナーs の使用をお勧めします。詳細については、「より大きなランナーの使用」または「自己ホストランナーの概要」を参照してください。

このAPIが返すGitHub ActionsのIPアドレスのリストは、週に1回更新されます。

GitHub ホステッドランナーと GitHub

の通信要件

GitHub でホステッドランナーは、重要な通信操作を実行するために、GitHub 所有のエンドポイントへの接続を確立する必要があります。さらに、ランナーは、アクション内で指定または利用する追加のネットワークへのアクセスを必要とする場合があります。

構成内のネットワーク間の GitHub ホステッドランナーに対する適切な通信を確保するには、次の通信が許可されていることを確認します。

Note

一覧表示されているドメインの一部は、CNAME レコードを使用して構成されます。ファイアウォールによっては、すべての CNAME レコードに対して規則を再帰的に追加する必要がある場合があります。 CNAME レコードは今後変更される可能性があり、一覧表示されているドメインのみが一定のままであることに注意してください。

重要な操作に必要:

Shell

github.com
api.github.com
*.actions.githubusercontent.com

github.com
api.github.com
*.actions.githubusercontent.com

ダウンロードアクションに必要:

Shell

codeload.github.com
ghcr.io
*.actions.githubusercontent.com

codeload.github.com
ghcr.io
*.actions.githubusercontent.com

ジョブサマリー、ログ、ワークフローアーティファクトのアップロード/ダウンロードに必要:

Shell

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

ランナーバージョンの更新に必要:

Shell

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

OIDC トークンを取得するために必要:

Shell

*.actions.githubusercontent.com

*.actions.githubusercontent.com

パッケージまたはコンテナーを GitHub パッケージにダウンロードまたは発行するために必要です。

Shell

*.pkg.github.com
ghcr.io

*.pkg.github.com
ghcr.io

Git Large File Storage に必要

Shell

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

`etc/hosts` ファイル

GitHub ホストランナーは、さまざまな暗号化マイニングプールや悪意のあるサイトへのネットワークアクセスをブロックする etc/hosts ファイルでプロビジョニングされます。 MiningMadness.com や cpu-pool.com などのホストは、重大なセキュリティリスクが存在しないように localhost に再ルーティングされます。

ファイルシステム

GitHubは、仮想マシン上の特定のディレクトリでアクションとシェルコマンドを実行します。仮想マシン上のファイルパスは静的なものではありません。 home、workspace、workflow ディレクトリのファイルパスを作成するには、GitHub で提供される環境変数を使います。

ディレクトリ	環境変数	説明
`home`	`HOME`	ユーザ関連のデータが含まれます。たとえば、このディレクトリにはログイン試行からの認証情報を含めることができます。
`workspace`	`GITHUB_WORKSPACE`	アクションとシェルコマンドはこのディレクトリで実行されます。このディレクトリの内容は、アクションによって変更することができ、後続のアクションでアクセスできます。
`workflow/event.json`	`GITHUB_EVENT_PATH`	ワークフローをトリガーした Webhook イベントの `POST` ペイロード。 GitHubは、アクションを実行してアクション間でファイルの内容を隔離するたびにこれを書き換えます。

ワークフローごとに GitHub によって作成される環境変数の一覧については、「変数に情報を格納する」をご覧ください。

Dockerコンテナのファイルシステム

Docker コンテナーで実行されるアクションには、/github パスの下に静的なディレクトリがあります。ただし、Dockerコンテナ内のファイルパスを構築するには、デフォルトの環境変数を使用することを強くお勧めします。

GitHub では、/github パスプレフィックスが予約されており、アクション用に 3 つのディレクトリが作成されます。

/github/home
/github/workspace - メモ: GitHub Actions は既定の Docker ユーザー(root) で実行しなければなりません。 Dockerfile で USER 命令が設定されていないことを確認します。されている場合は、GITHUB_WORKSPACE にアクセスできません。
/github/workflow

参考資料

GitHub Actions の支払いを管理する
マトリックス戦略を使用して、複数のイメージでジョブを実行できます。詳しくは、「ワークフローでのジョブのバリエーションの実行」を参照してください。

GitHub ホステッド ランナーの概要

この記事の内容

GitHub ホステッドランナーの概要