GitHub Actions セルフホスト Runner：プライベート環境デプロイ完全ガイド

2026 年 3 月、GitHub は地味なお知らせを出しました。プライベートリポジトリのセルフホスト Runner が有料化され、1 分あたり $0.002。少なく聞こえますが、1 時間で $0.12、月に 100 時間走らせれば $12 です。

「セルフホスト Runner はずっと無料じゃなかったの？」と戸惑う人も多いでしょう。一方で GitHub-hosted runners は約 40% 値下げされ、自前かクラウドかを改めて計算するチームが増えています。

価格だけが論点ではありません。社内 DB に触る必要がある、ビルドに 32 GB メモリが要る——こうした要件は GitHub-hosted では満たせません。そのときセルフホスト Runner は選択肢ではなく、必須です。

本記事では 3 つのデプロイ方式（従来サーバー、Docker、Kubernetes）を比較し、セキュリティの落とし穴と、オープンソース管理ツール Runner Fleet を紹介します。コスト、セキュリティ、環境のコントロール——目的に合った答えが見つかるはずです。

なぜセルフホスト Runner が必要か

セルフホスト Runner とは

一言でいうと、自分のマシン（物理サーバー、VM、Raspberry Pi でも可）で GitHub Actions のジョブを実行する仕組みです。GitHub-hosted runner は GitHub が用意したクラウド環境を使い捨て。セルフホストは自分で舞台を組み、好きなようにカスタマイズできます。

Runner 本体は actions/runner としてオープンソース公開されています。マシンに入れてリポジトリや Organization に登録すると、GitHub からタスクを取り、実行結果を返します。

GitHub-hosted との違い

違いは「誰がサーバーを出すか」だけではありません。

GitHub-hosted は毎回まっさらな環境で、終わったら破棄。クリーンで安全ですが、コールドスタートは 1〜2 分、入れられるソフトも限られます。マイナーなコンパイラは無理。社内テスト DB への接続も不可です。

セルフホストは逆です。環境は自分で構築し、プリインストールも自由。ビルド後も破棄せず、キャッシュはローカルに残るので速い。代わりに運用と障害対応は自分です。

観点	GitHub-hosted	セルフホスト
環境	毎回新規	永続利用
コールドスタート	1〜2 分	数秒
カスタマイズ	限定的	自由
セキュリティ	隔離済み	自前で強化
コスト	従量課金	マシン代＋運用

2026 年の価格変更

ここは少し細かく。

2026 年 3 月までは、プライベートリポジトリのセルフホスト Runner は無料でした。電気代もマシン代も自分持ちで、GitHub は課金しませんでした。3 月以降、プライベート向けセルフホストが $0.002/分 で課金されます。

例えば 1 日 50 回 CI、1 回 10 分なら月 15,000 分、約 $30。年間 $360 あれば、そこそこの VPS が買えます。

同時期に GitHub-hosted は約 40% 値下げ。クラウドへ誘導しているのか——と思いがちですが、結論は急がないでください。パブリックリポジトリのセルフホストは依然無料です。OSS ならこの課金は気にしなくて大丈夫です。

いつセルフホストを選ぶか

典型的なシナリオは次のとおりです。

シナリオ 1：社内サービスへのアクセス

CI が社内 DB、API、プライベートレジストリに届く必要がある。GitHub-hosted は公網側なので、社内には届きません。

シナリオ 2：特殊なハードウェア

GPU で学習したい、128 GB メモリで巨大プロジェクトをビルドしたい。GitHub-hosted の標準は 7 GB RAM・2 vCPU 程度で足りません。

シナリオ 3：大量ビルドでのコスト

1 日に CI が何百回も回るなら、GitHub-hosted の分課金は積み上がります。自前 Runner の方が安くなることもあります。

シナリオ 4：コンプライアンスとデータ主権

金融・医療などではデータの国外持ち出しが厳しい。ビルドは社内で完結させ、コードをデータセンターから出せない——そういう要件です。

小規模でビルドが少ないなら、値下げ後の GitHub-hosted が手軽です。上のどれかに当てはまるなら、セルフホストを検討するタイミングです。

3 つのデプロイ方式の比較

方式 1：従来のサーバー

いちばん素直な方法です。Linux サーバーに Runner パッケージを落として、解凍・設定・起動。

初回デプロイもこのやり方でした。CentOS 7 に SSH、GitHub ドキュメント通りにコマンド——30 分ほどで「オンライン」表示が出て、達成感がありました。

長所：Docker も Kubernetes も不要。環境が安定し、1 台が長く動きます。

短所：Runner が落ちたら手動再起動。マシン障害も自分で調査。増やすたびに新マシンと再設定。

向いているのは、小規模チームで Runner が 1〜2 台、コンテナ化までしたくないケースです。

方式 2：Docker コンテナ

Runner をコンテナに入れ、ジョブごとに捨てて次はクリーンなコンテナ——従来方式より安全です。コンテナが汚れても削除すれば済みます。

単一コンテナ：Runner もビルドも同じコンテナ内。多くの用途で十分です。

Docker-in-Docker（DinD）：コンテナ内で Docker daemon を動かし、イメージビルドやマルチコンテナテストができます。ただしリスクが大きく、公式も慎重利用を促しています。

長所：隔離と片付けが楽。Docker Compose で複数 Runner をまとめて管理できます。

短所：DinD のリスク。オーケストレーションはまだ手作業寄り。オートスケールは限定的です。

中規模で隔離を重視し、チームに Docker 経験があるとき向きです。

方式 3：Kubernetes + Actions Runner Controller（ARC）

GitHub 公式が推す大規模向けです。ARC は Kubernetes Operator で、Runner のライフサイクルを自動管理します。

必要数を宣言すれば Pod が立ち、ジョブが来れば実行、終われば破棄。キューが溜まればスケールアウト、暇ならスケールインします。

AWS は 2025 年 1 月のブログで、この構成を AWS 上で大規模利用する企業向けに紹介しています。

長所：オートスケール、自動化後の運用コストは低め。Kubernetes 周辺ツールがそのまま使えます。

短所：Kubernetes、Helm、CRD の理解が必要。導入は前 2 方式より重いです。

Runner が数十〜数百、K8s 基盤があり、運用自動化を狙う大規模チーム向けです。

比較と選び方

観点	従来サーバー	Docker	Kubernetes ARC
導入難易度	低	中	高
環境隔離	弱い	良い	とても良い
オートスケール	なし	限定的	フル対応
運用コスト	高い	中程度	低い（自動化後）
学習コスト	低い	中程度	高い
想定規模	1〜5 台	5〜20 台	20 台以上

目安：

• 1〜5 人・ビルド少なめ → 従来サーバーで十分。無理にコンテナ化しない。
• 10〜30 人・1 日数十回 → Docker ＋ Runner Fleet などの管理ツール。
• 30 人以上・CI 分数が桁違い → Kubernetes ARC。学習コストはあるが、自動運用のリターンは大きい。

「最適」はなく、「いちばん合う」だけです。規模・スタック・運用力で選び、新しさだけで追わないでください。

セキュリティのベストプラクティス

パブリックリポジトリは禁則

GitHub 公式の警告を先に。

“Self-hosted runners should almost never be used for public repositories.” — GitHub Docs

パブリックでは誰でも PR を出して Workflow を走らせられます。Runner が社内マシン上なら、悪意ある PR が社内で任意コマンド実行、機密ファイル読み取り、Token 窃取、横展開の入口になります。

2026 年 1 月、Sysdig はセルフホスト Runner を踏み台にした侵入事例を分析しています。理論ではなく、起きています。

パブリックでは GitHub-hosted を使うか、CI を使わない。セルフホストするなら、まずリポジトリをプライベートに。

Runner Groups で分離

プライベートでも、プロジェクトごとに信頼度は違います。本番コア用 Runner と実験用を混ぜないでください。

Runner Groups は Organization 単位で作り、プロジェクト・チーム・信頼レベルごとに分けます。どのリポジトリがどの Group を使えるかも制限できます。

例：

• critical-prod：コアリポジトリのみ、隔離ゾーンのマシン
• dev-team：開発チーム用、通常の社内ネットワーク
• sandbox：実験用、サンドボックス環境

1 リポジトリが破られても、当該 Group の Runner までに抑えられます。

環境の硬化

最小権限：専用ユーザーで動かし、root は使わない。必要ソフトだけ入れる。

ネットワーク：Runner をインターネットに直晒ししない。GitHub からタスクを取るだけなら、インバウンドの公開は不要です。

Token：登録 Token は期限付き。切れたら再発行。スクリプトに直書きせず Secrets で管理。

ログ：実行ログを残し、異常を追えるようにする。

Wiz の 2026 年 4 月ガイドでも、Runner 環境が緩すぎる事例が多いと指摘されています。硬化は一度きりではなく、継続的な見直しです。

セキュリティツール

GitHub 系の Harden-Runner を Workflow に入れられます。

steps:
  - uses: step-security/harden-runner@v2
    with:
      egress-policy: audit

アウトバウンド接続を監視し、異常を報告します。Audit に加え Block モードもあり、未許可の外向き通信を遮断できます。

セルフホストでは Block が特に効きます。悪意あるスクリプトの外部送信を止められます。

Runner を入れたら放置、権限オープン、Token の直書き——よく見ます。事故後では手遅れです。

Runner Fleet オープンソース管理

Runner Fleet とは

Docker で複数 Runner を回しても、コンテナごとの状態・Token・ログはバラバラで、SSH しがちです。

Runner Fleet は soulteary 氏のオープンソースで、この散らばりを Web UI でまとめます。作者は Tencent Cloud 開発者コミュニティで実践記事を公開しています。

オンライン状態、実行中ジョブ、履歴、Token 設定、自己回復、一括操作——ブラウザで全体像が見えます。

主な機能

状態の集約：全 Runner のオンライン／ジョブ／履歴を一覧。

Token 統合：Web で設定し、更新を一括同期。

自己回復：コンテナ落ちを検知して再起動。手動復旧の手間が減ります。

コンテナ／ホストモード：純コンテナか、ホスト実行＋コンテナ管理かを選択。

一括操作：起動・停止・再起動、増設時のまとめ作成。

クイックデプロイ

Runner Fleet 自体も Docker で数行です。

# イメージを pull
docker pull soulteary/runner-fleet

# 起動（簡略）
docker run -d \
  --name runner-fleet \
  -p 8080:8080 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  soulteary/runner-fleet

http://<サーバーIP>:8080 で管理画面。GitHub Token、Runner 数、環境変数を設定して、クリックでまとめて作成できます。

K8s まで行きたくないが Docker で隔離したいチームには、コスパの良い中間案です。

デプロイ実践（Linux 5 ステップ）

従来サーバーで入れる場合の手順です。Ubuntu 20.04 を想定します。

ステップ 1：専用ユーザー

# root で Runner を動かさない
sudo useradd -m runner
sudo passwd runner  # パスワード設定

Runner は GitHub Token に触れます。root だと侵害時の被害が最大。専用ユーザーで一段隔離します。

ステップ 2：パッケージ取得

sudo su - runner
cd ~
curl -o actions-runner-linux-x64-2.321.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.321.0/actions-runner-linux-x64-2.321.0.tar.gz
tar xzf actions-runner-linux-x64-2.321.0.tar.gz

ステップ 3：登録 Token

リポジトリまたは Organization の Settings → Actions → Runners → New self-hosted runner に Registration Token が出ます。1 回限りで、登録後は無効です。

ステップ 4：設定・登録

./config.sh --url https://github.com/YOUR_ORG \
  --token YOUR_REGISTRATION_TOKEN \
  --name my-runner-01 \
  --labels linux,ubuntu

--labels でタグ付けし、Workflow 側は runs-on: [self-hosted, linux] で指定できます。

ステップ 5：systemd 化

sudo ./svc.sh install runner
sudo ./svc.sh start

起動時に自動起動、落ちたら systemd が再起動します。

Workflow で Runner を指定

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm run build

ラベルで絞る例：

jobs:
  test:
    runs-on: [self-hosted, linux, ubuntu]
    steps:
      - uses: actions/checkout@v4
      - name: Test
        run: npm test

同じラベルの Runner が複数あれば GitHub が割り当てます。ラベルが具体的なほど意図どおりに当たります。

デプロイ後は GitHub 上で状態を確認してください。「Offline」ならネットワークか Token 設定を疑います。

まとめ

小規模・ビルド少なめ → GitHub-hosted が手軽。値下げ後のコスパも悪くない。特例だけセルフホスト。

中規模・1 日数十回 → Docker ＋ Runner Fleet。隔離と一元管理のバランスが良い。

大規模・Runner 多数 → Kubernetes ＋ ARC。学習コストはあるが、自動運用の長期リターンは大きい。

セキュリティ重視 → プライベート ＋ Runner Groups ＋ Harden-Runner。パブリックでのセルフホストは推奨ではなく警告です。

2026 年の価格変更はコスト計算を変えましたが、セルフホストの価値は節約だけではありません。社内アクセス、ハードウェア、コンプライアンス——GitHub-hosted では永遠に満たせない領域です。要件を整理し、合う方式を選びましょう。

次の一歩：社内 DB、コスト、コンプライアンスで困っているなら、まず Docker ＋ Runner Fleet を試すのが現実的です。本当に大規模になったら K8s へ移行しても遅くありません。