こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。
今回はGitHub ActionsのSelf-hosted runnerをAWSのEC2上に構築する方法について紹介します。
- 本記事のターゲット
- AI駆動開発とGitHub Actionsの需要
- GitHubのSelf-hosted runnerとは？
- Self-hosted runnerの動作の仕組み
- 本記事におけるSelf-hosted runnerの構成
- リポジトリに対するSelf-hosted runnerの登録手順
- Runnerの自動起動設定
- 最後に
本記事のターゲット
本記事はGitHub Actionsを利用していて、コストやパフォーマンスの観点からSelf-hosted runnerの導入を検討している方をターゲットとしています。
前提知識として、AWSのVPCやEC2、GitHub Actionsの基本的な知識があることを想定しています。
AI駆動開発とGitHub Actionsの需要
2025年は、AIによるソフトウェア開発が急速に進展した年でした。
一方で、AIが生成したコードの品質を確保するにはどうしたらよいか？というのは非常に重要なテーマとなったと考えています。
そうした時に、CI/CDパイプラインを支えるGitHub Actionsの重要性はますます高まるでしょう。
GitHub Actionsの利用が増えると、ジョブの実行時間や並列実行数が増加し、コストとパフォーマンスの最適化が重要になります。
この最適化の選択肢にSelf-hosted runnerがあります。
GitHubのSelf-hosted runnerとは？
Self-hosted runnerは、GitHub Actionsのワークフローのジョブを実行するための環境を自分で用意する仕組みです。
GitHub ActionsのRunnerとは？
GitHub Actionsは、ワークフロー＞ジョブ＞ステップの階層構造で構成されています。
graph TD
R["Repository<br>.github/workflows"] --> A["01_basic_workflow_1.yml"]
R --> D["02_basic_workflow_2.yml"]
A --> B[Job 1]
A --> C[Job 2]
D --> E[Job 1]
D --> F[Job 2]
B --> G[Step 1]
G --> H[Step 2]
H --> I[Step 3]
C --> J[Step 1]
J --> K[Step 2]
E --> L[Step 1]
L --> M[Step 2]
F --> N[Step 1]
N --> O[Step 2]
O --> P[Step 3]
style R fill:#f9f9f9
style A fill:#e1f5fe
style D fill:#e1f5fe
style B fill:#f3e5f5
style C fill:#f3e5f5
style E fill:#f3e5f5
style F fill:#f3e5f5
style G fill:#fff3e0
style H fill:#fff3e0
style I fill:#fff3e0
style J fill:#fff3e0
style K fill:#fff3e0
style L fill:#fff3e0
style M fill:#fff3e0
style N fill:#fff3e0
style O fill:#fff3e0
style P fill:#fff3e0
参考： GitHub Actions の構造と変数を整理して、AWSのデプロイ先を分岐させてみよう - サーバーワークスエンジニアブログ
このうち、ジョブ及びジョブの中のステップを実行する環境がRunnerです。
GitHub ActionsのRunnerは、GitHubが提供するホスト型Runner（GitHub Hosted Runner）があり、リポジトリの種類や契約しているプランに応じて無料利用枠が提供されています。
Self-hosted runnerを使用した場合、無料利用枠は提供されませんが、環境を自分で用意できるため、コスト削減やパフォーマンス向上が期待できます。
GitHub Actionsの価格改定
2025年12月、GitHub Actionsの価格改定が発表されました。
GitHub Hosted Runnerの価格が引き下げられています。
Self-hosted runnerの価格については保留となっています。
今後も価格改定が行われる可能性はありますが、AI駆動開発の隆盛などもあってSelf-hosted runnerの需要はキープされるだろうと考えています。
以上を踏まえて、今回は初めてのSelf-hosted runner構築として、AWSのEC2インスタンスをSelf-hosted runnerとして構築します。
Self-hosted runnerの動作の仕組み
Self-hosted runnerの動作や構築手順については、GitHubの公式ドキュメントの通りです。
本記事での構成におけるポイントだけかいつまんで説明します。
Self-hosted runnerは、GitHubリポジトリと通信するために、GitHubから提供される登録トークンを使用して登録されます。
登録されたRunnerは、GitHubに対してHTTPS接続でジョブを受け取ります。
ジョブが割り当てられると、Runnerはジョブを実行し、完了後に結果をGitHubに返します。
従って、Self-hosted runnerを稼働させるEC2インスタンスは、GitHubと通信できるようアウトバウンド通信が許可されている必要があります。
インバウンド通信は不要です。
本記事におけるSelf-hosted runnerの構成
本記事では、以下の構成でSelf-hosted runnerを構築します。
| 項目 | 内容 |
|---|---|
| VPC | パブリックサブネット1つ |
| EC2インスタンス | t4g.micro (ARM64), Ubuntu 24.04 |
| セキュリティグループ | アウトバウンドのみ全ての通信を許可 |
| IAMロール | Session Manager接続のためのマネージドポリシー（AmazonSSMManagedInstanceCore）をアタッチ |
EC2インスタンスは、GitHub ActionsのSelf-hosted runnerとして動作するために必要なソフトウェアのインストールが必要です。
この作業をSession Managerを使用して行うため、IAMロールに必要なマネージドポリシーをアタッチします。
セキュリティグループは、アウトバウンド通信のみ許可します。
本当はGitHubのエンドポイントに対してのみ通信を許可するのが望ましいですが、今回は簡易化のため全てのアウトバウンド通信を許可します。
リポジトリに対するSelf-hosted runnerの登録手順
ここから、実際にSelf-hosted runnerをEC2上に構築し、リポジトリに登録する手順を説明します。
基本的な手順はGitHubの公式ドキュメントに従います。
Adding self-hosted runners - GitHub Docs
リポジトリのSettings > Actions > Runnersに移動し、「New self-hosted runner」ボタンをクリックします。
先ほど、EC2のインスタンスタイプを「t4g.micro (ARM64)」、OSを「Ubuntu 24.04」としたため、以下のように選択します。
- Runner image: Linux
- Architecture: ARM64
すると、Self-hosted runnerの登録に必要なコマンド一式が表示されるので、これをSession Managerで接続したEC2インスタンス上で実行します。
「Configure」セクションのconfig.shを実行するコマンドで、リポジトリのURLと登録トークンを指定しているのがポイントです。
これにより、EC2インスタンス上のRunnerが特定のリポジトリに登録されるようになります。
config.shを実行すると、いくつかの質問が表示されますが、取り急ぎ全てデフォルトで進めて問題ありません。
最後のrun.shを実行すると、Runnerが起動し、ジョブの受け取りと実行が開始されます。
リポジトリのSettings > Actions > Runnersに戻ると、登録されたRunnerが表示されていることが確認できます。
この状態で、GitHub Actionsのワークフローで、ジョブのRunnerを以下の様に指定すると、EC2上のSelf-hosted runnerでジョブが実行されます。
jobs: build: runs-on: self-hosted steps: ...
Runnerの自動起動設定
run.shを実行すると、Runnerが起動しますが、これだとSession Managerで接続している間しか動作しません。
Session Managerのセッションが切れると、Runnerが停止し、リポジトリのSettings > Actions > Runnersでは「Offline」と表示されます。
起動しっぱなし、かつEC2インスタンスの再起動後も自動的に起動するように設定します。
「Configure」セクションにあるconfig.shを実行した後だと、svc.sh ができているはずです。
これを実行すると、Runnerがサービスとして登録され、自動起動するようになります。
sudo ./svc.sh install sudo ./svc.sh start
起動したサービスの状態は、以下のコマンドで確認できます。
sudo systemctl status actions.runner.*
最後に
以上が、EC2上にGitHub ActionsのSelf-hosted runnerを構築する手順の紹介でした。
今回は初めてのSelf-hosted runner構築ということで、基本的な構成と手順を紹介しましたが、この構成にはまだ改善の余地があります。
個人的に一番気になるのは、Self-hosted runnerの指定方法が以下のように曖昧である点です。
jobs: build: runs-on: self-hosted steps: ...
この指定方法だと、ジョブごとにSelf-hosted runnerを使い分けることができません。
使い分けなどを意識したより高度な構成については、別の機会に紹介したいと思います。
今回は以上です。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS3課所属
2025 Japan AWS Top Engineers (AI/ML Data Engineer)
2025 Japan AWS All Certifications Engineers
2025 AWS Community Builders
Certified ScrumMaster
PMP
広島在住です。今日も明日も修行中です。
X(旧Twitter)
