最近の開発現場では、コードをGitHubにpushすると自動でテストやデプロイが走る「CI/CD」が当たり前になってきました。その中心にあるのがGitHub Actionsです。リポジトリの.github/workflows/フォルダにYAMLファイルを置くだけで、ビルド・テスト・デプロイの自動化が可能になります。
しかし、実際にその処理を「どこで」動かしているのか、考えたことはあるでしょうか？その答えが、GitHub Actions Runner（以下Runner）です。
Table of Contents
GitHub Actions Runnerとは？
Runnerは、GitHub Actionsのジョブを実際に実行する「マシン」のことを指します。
「GitHubが裏で自動的に動かしてくれている」ように見えますが、実はRunner上でワークフローが走っています。
Runnerには大きく分けて2種類あります。
- GitHubホストランナー（Hosted Runner）
GitHubが用意してくれるランナー。Linux、Windows、macOSの環境を選んで利用できます。
特に設定不要で、YAMLに書くだけですぐ使えるのが利点です。 - セルフホストランナー（Self-hosted Runner）
自分たちで用意したサーバやVMにRunnerをインストールして使う方法。
プライベート環境にアクセスが必要な場合や、独自のスペック・環境で実行したいときに便利です。
どうやって使うのか？
GitHub Actionsを動かす基本の流れは以下の通りです。
- YAMLファイルを用意
.github/workflows/ci.ymlのように配置。 - イベントを定義
例えば「pushされたとき」「PRが作られたとき」などをトリガーにする。 - ジョブを記述
runs-onでRunnerの種類を指定。name: CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: echo "Hello GitHub Actions"この例では、ubuntu-latestというGitHubが提供するRunner上でジョブが実行されます。
Hosted Runnerの特徴
GitHubが提供するランナーは無料枠があり、OSも選択可能です。
例えば runs-on: ubuntu-latest や runs-on: windows-latest と書けば、その環境でジョブが動きます。
メリットは次の通りです。
- セットアップ不要で即利用可能
- GitHub側がメンテナンスしてくれる
- OSSプロジェクトでは無料枠が広い
一方で、プライベートネットワークへのアクセスが必要な場合や、マシンスペックをカスタマイズしたい場合は不向きです。
Self-hosted Runnerの特徴
そこで登場するのがセルフホストランナーです。
自分で用意したサーバ（オンプレでもAWS EC2でも可）にRunnerをインストールして、GitHubリポジトリに登録します。
こうすることで、
- 社内ネットワーク内のDBやシステムに接続できる
- 高スペックのマシンやGPUを利用できる
- 実行環境を自由にカスタマイズできる
といった柔軟な運用が可能になります。
セットアップはGitHubのリポジトリ設定画面から「Actions → Runners → New self-hosted runner」を選び、インストールスクリプトを叩くだけです。
まとめ
- Runnerとは：「GitHub Actionsの処理を実際に動かすマシン」のこと。
- Hosted Runner：GitHubが提供する実行環境。設定不要で便利。
- Self-hosted Runner：自分で用意したサーバ上で動かす方法。プライベート環境や高性能リソースが必要なときに使う。
普段なんとなく使っているGitHub Actionsも、裏側ではRunnerという仕組みが動いています。開発の規模や要件に応じてHostedとSelf-hostedを使い分けることで、より効率的にCI/CDを運用できるでしょう。