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

GitHub では、ワークフローを実行するためのホストされた仮想マシンを提供します。 仮想マシンには、GitHub Actions で使用できるツール、パッケージ、および設定の環境が含まれています。

この記事の内容

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

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

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

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

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

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

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [アクション] をクリックします。

    "github/docs" リポジトリのタブのスクリーンショット。 [アクション] タブがオレンジ色の枠線で強調表示されています。

  3. 左サイドバーの [管理] セクションで、[ランナー] をクリックします。

  4. リポジトリで使用可能な GitHub ホステッド ランナーの一覧を確認します。

  5. 必要に応じて、ランナーのラベルをコピーしてワークフローで使用するには、ランナーの右側にある をクリックし、[ラベルのコピー] をクリックします。

Note

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

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

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

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

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

Note

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

Warning

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

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

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

仮想マシン プロセッサ (CPU) メモリ(RAM) ストレージ (SSD) ワークフロー ラベル
Linux 4 16 GB 14 GB ubuntu-latest、ubuntu-24.04、ubuntu-22.04、ubuntu-20.04
Windows 4 16 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［パブリック プレビュー］

プライベート リポジトリの標準の 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

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

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

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

Shell
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

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

Shell
*.actions.githubusercontent.com

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

Shell
*.pkg.github.com
ghcr.io

Git Large File Storage に必要

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

Dependabot updates のジョブに必要です

Shell
dependabot-actions.githubapp.com

etc/hosts ファイル

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

ファイル システム

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

ディレクトリ環境変数説明
homeHOMEユーザ関連のデータが含まれます。 たとえば、このディレクトリにはログイン試行からの認証情報を含めることができます。
workspaceGITHUB_WORKSPACEアクションとシェルコマンドはこのディレクトリで実行されます。 このディレクトリの内容は、アクションによって変更することができ、後続のアクションでアクセスできます。
workflow/event.jsonGITHUB_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

参考資料