こんにちは！CI/CDやインフラ自動化の世界へようこそ。
毎日のビルドやテスト、デプロイの自動化……CI/CDパイプラインがスムーズに動くと、開発は本当に楽しくなりますよね。
しかし、チーム開発が進むにつれて、多くのエンジニアが必ずぶち当たる「ある深刻な問題」があります。
- 「前のジョブが残したファイルやプロセスが原因で、テストが謎の失敗をする（環境汚染）」
- 「共有ランナーのセキュリティリスクが心配……」
- 「使っていない時間もサーバ代がかかっていてコストが高い」
これらの悩みを根本から、美しく解決する技術が、今回紹介するGitHub Actionsの「Ephemeral Runners（使い捨てランナー）」です。
一見難しそうに思えるかもしれませんが、仕組みは驚くほどシンプルでエレガントです。これをマスターすれば、あなたの開発環境の安定性とセキュリティは飛躍的に向上し、毎日の作業が劇的に楽になりますよ。
私と一緒に、基礎から1ステップずつ体験してみましょう！
—
1. Ephemeral Runner（使い捨てランナー）とは？
まずは言葉の意味と、なぜこの仕組みが必要なのかをサクッと整理しましょう。
「使い捨て」が最高である理由
「Ephemeral（エフェメラル）」とは、英語で「短命な」「はかない」という意味です。
従来のセルフホストランナー（自前で用意する実行用サーバ）は、一度立ち上げたらずっと起動し続け、複数のジョブを同じ環境で順番に処理していました。これは例えるなら、「前の住人が掃除していない部屋に、次の住人がそのまま泊まる」ような状態です。ファイルが残っていたり、ポートが埋まっていたりして、トラブルの原因になります。
一方でEphemeral Runnerは、「1つのジョブ（仕事）が終わったら、その瞬間にサーバごと爆破・削除される」というアプローチを取ります。
【従来のランナー】
[ジョブ1実行] ➔ [環境汚染が残る] ➔ [ジョブ2実行（謎のエラー発症…）]
【Ephemeral Runner】
[まっさらな環境生成] ➔ [ジョブ1実行] ➔ [完全に破棄！]
[まっさらな環境生成] ➔ [ジョブ2実行] ➔ [完全に破棄！]
Ephemeral Runnerがもたらす3つの大勝利
1. 環境汚染リスクが「ゼロ」：毎回100%新品のクリーンな環境でテストが走ります。
2. 圧倒的なセキュリティ：万が一、テスト中に悪意あるコードがランナー内で実行されても、ジョブ終了と同時に消滅するため後を引かしません。
3. 無駄なコストの削減：クラウド（AWSやGCPなど）と組み合わせることで、「必要な時だけ瞬時に起動し、終わったら消す」ため、インフラ費用を極限まで削れます。
—
2. アーキテクチャの全体像
「どうやってジョブが終わったことを検知して消えるの？」という仕組みを図でイメージしてみましょう。
1. GitHub Actionsでワークフローが発火
│
2. 「ジョブが来たぞ！」と検知し、クラウド上にランナー（コンテナ/VM）を即座に起起
│
3. `./config.sh –ephemeral` オプションを付けてGitHubに登録
│
4. ジョブ（テストやビルド）を実行
│
5. ジョブ完了！
│
6. GitHubから自動で割り当て解除され、ランナープロセスが自爆（終了）
│
7. インフラ側がそれを検知してコンテナ/VMを完全削除
GitHub公式のランナープログラムに `–ephemeral` という魔法のフラグを渡すだけで、ランナー自身が「自分は1回仕事をしたら死ぬ運命（定命）である」ことを自覚してくれるのです。
—
3. ハンズオン：Ephemeral Runnerを体験してみよう！
概念がわかったところで、実際に手を動かしてみましょう！
今回は高価なクラウドを用意しなくても、手元のPC（Mac/Linux/Windows WSL2）やDocker環境で完璧に動作確認ができる「最もシンプルなセットアップ手順」を用意しました。
前提条件
- GitHubのアカウントと、テスト用のリポジトリがあること
- ターミナル操作ができること
—
Step 1: GitHubで登録用トークンを発行する
まずは、あなたのリポジトリに自前のランナーを接続するためのトークンを取得します。
1. GitHubでテスト用リポジトリを開きます。
2. Settings ➔ 左メニューの Actions ➔ Runners を選択。
3. 右上の New self-hosted runner ボタンをクリック。
4. OS（Linux や macOS など）を選ぶと、画面下にダウンロードスクリプトが表示されます。その中にある `–token XXXXXX` の トークン文字列 をコピーしておきます。
—
Step 2: Ephemeral Runnerを起動する
ターミナルを開き、以下のコマンドを順番に実行してみましょう。GitHubの画面に表示された手順にたった1つ「魔法のフラグ」を追加するだけです。
まずはランナー用のフォルダを作成してダウンロードします（以下はLinux/x64の例です）。
1. ワークスペースの作成と移動
mkdir actions-runner && cd actions-runner
2. 最新のランナーパッケージをダウンロード（バージョンは適宜最新に読み替えてください）
curl -o actions-runner-linux-x64-2.314.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.314.0/actions-runner-linux-x64-2.314.0.tar.gz
3. 解凍
tar xzf ./actions-runner-linux-x64-2.314.0.tar.gz
次に、ここが一番重要なセットアップです！設定コマンドを実行します。
4. ランナーの設定（–ephemeral フラグを忘れずに！）
./config.sh \
–url https://github.com/あなたのユーザー名/あなたのリポジトリ名 \
–token Step1で取得したトークン \
–name my-ephemeral-runner \
–ephemeral # 👈 これが超重要！「使い捨てモード」を有効化する設定です
設定が完了したら、ランナーを待機状態（起動）にします。
5. ランナーの実行
./run.sh
ターミナルに `Listening for Jobs` と表示されれば準備完了です！
GitHubの画面（Settings -> Actions -> Runners）を見ると、`my-ephemeral-runner` が Idle（待機中）として表示されているはずです。
—
Step 3: テスト用ワークフローを作成する
では、この使い捨てランナーを呼び出すGitHub Actionsのワークフローを書きましょう。
リポジトリ内に `.github/workflows/ephemeral-test.yml` を作成します。
name: Ephemeral Runner Test Workflow
手動でWeb画面から実行できるようにするトリガー設定
on:
workflow_dispatch:
jobs:
hello-ephemeral:
# 自分で立ち上げたランナーを指定するために ‘self-hosted’ を指定します
runs-on: self-hosted
steps:
- name: 1. 挨拶を出力
run: |
echo “🎉 こんにちは！Ephemeral Runner上でジョブが実行されています！”
- name: 2. 環境の隔離テスト（ファイルを作成してみる）
run: |
echo “このファイルはジョブ終了後に消滅する運命です” > dirty_data.txt
ls -la
ファイルをリポジトリのメインブランチにコミット＆プッシュしてください。
—
4. 運命の「HelloWorld」動作確認と検証
いよいよ実験です！1回限りの儚くも美しい挙動を確認しましょう。
実行手順
1. GitHubリポジトリの Actions タブを開きます。
2. 左サイドバーから Ephemeral Runner Test Workflow を選択。
3. Run workflow ボタンをクリックして手動実行します。
ここを観察してください！（感動の瞬間）
1. ジョブの開始: ターミナル側で `Running job: hello-ephemeral` と表示され、ワークフローのステップが次々と実行されます。
2. ジョブの完了: テストが成功すると、ターミナルに以下のようなメッセージが流れます。
Job hello-ephemeral completed with result: Succeeded
Runner connect error: The server disconnected unexpectedly.
Runner replacement completed.
Exiting runner…
3. プロセスの自動終了: なんと、`./run.sh` が自動的に終了（自爆）してターミナル制御が戻ってきます！
もう一度 GitHubの Settings ➔ Actions ➔ Runners 画面を開いてみてください。
先ほどまで存在していた `my-ephemeral-runner` が、一覧から綺麗さっぱり消え去っているはずです。
手動で削除コマンドを叩いたわけでもないのに、です。これが `–ephemeral` の力です！
—
5. 次のステップ：実践（クラウド自動プロビジョニング）に向けて
今回体験したのは「1回走ったら消えるランナー」の最小単位です。
実際のプロダクション環境では、この仕組みを以下のようなコンテナ管理ツールやクラウド機能と組み合わせます。
- Kubernetes (ARC: Actions Runner Controller):
GitHubのイベント（ジョブ追加）を検知して、Kubernetes上にEphemeral Podを自動でポンポン立ち上げ、終わったら即座にPodを削除してくれる標準的な手法です。
- AWS (EC2 / Auto Scaling Group / Fargate):
Webhookを受けてLambdaを発火させ、一時的なEC2やFargateコンテナを立ち上げて実行させます。
「ジョブが来たら生成し、`–ephemeral` で実行し、終わったら自爆する」という基本原理は、規模が大きくなっても全て今回学んだことの応用に過ぎません。
—
まとめ
最後に、今回学んだポイントを振り返りましょう。
- 環境汚染ゼロ: ジョブごとに使い捨てるため、テストの再現性が100%保たれる。
- 設定は簡単: `./config.sh` に `–ephemeral` をつけるだけ。
- 自動クリーンアップ: ジョブが完了すると、自身をリポジトリから登録解除して安全に終了する。
いかがでしたでしょうか？
「毎回使い捨てる」というシンプルな発想転換で、CI/CDの最も厄介な敵である「環境依存の謎エラー」を完全にシャットアウトできる強力なアプローチです。
まずは個人プロジェクトや小さなチームの環境から、この安全で快適な使い捨てランナーの世界を試してみてくださいね。あなたのエンジニアライフが、より洗練された素晴らしいものになりますように！