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

2026年3月、GitHub は目立たない発表を行いました。プライベートリポジトリのセルフホストランナーの課金が始まったのです。料金は1分あたり $0.002。少なく聞こえますか？計算してみると、1時間で $0.12、月に100時間実行すると $12 になります。

このニュースに多くの人が驚きました。セルフホストランナーはずっと無料だったはずでは？どうして急に課金が始まったのか？一方で、GitHub-hosted runners の価格は逆に約40%下がりました。多くのチームが考え直し始めました。セルフホストと GitHub ホスト、どちらを使うべきか？

正直なところ、価格変更は一つの側面に過ぎません。コードがイントラネットのデータベースにアクセスする必要がある場合や、ビルド環境に 32GB のメモリが必要な場合、GitHub-hosted では全く対応できません。このような状況では、セルフホストランナーは選択肢ではなく、必須要件になります。

この記事では、3つのデプロイ手法（従来のサーバー、Docker、Kubernetes）を比較し、セキュリティ強化の注意点を解説します。さらに、実用的なオープンソース管理ツール Runner Fleet も紹介します。コスト削減、セキュリティ、または単にビルド環境の制御を目指す場合でも、答えが見つかるはずです。

なぜセルフホストランナーが必要なのか？

セルフホストランナーとは

簡単に言えば、セルフホストランナーは自分で用意したマシン（物理サーバー、仮想マシン、さらには Raspberry Pi）で、GitHub Actions のビルドタスクを実行するものです。GitHub-hosted runner は GitHub がクラウドで用意した環境で、使い終わったら破棄されます。一方、セルフホストは自分で環境を用意し、自由にカスタマイズできます。

ランナー自体はオープンソースプロジェクトで、GitHub がコードを actions/runner リポジトリで公開しており、誰でもダウンロードできます。自分のマシンにインストールし、リポジトリや組織に登録すると、GitHub からタスクを取得して実行し、結果を返す仕組みです。

GitHub-hosted との核心的な違い

両者の違いは「誰がサーバーを用意するか」だけではありません。

GitHub-hosted runner は、毎回のビルドが新しい環境で行われ、使い終わったら破棄されます。メリットはクリーンで安全なこと、デメリットはコールドスタートが遅く、インストールできるソフトウェアが限られていることです。ニッチなコンパイラを使いたいですか？無理です。テストがイントラネットのテストデータベースに接続する必要がありますか？接続できません。

セルフホストランナーは正反対です。環境は自分で構築するため、何をプレインストールしても構いません。ビルド完了後に破棄する必要がなく、次回は直接使用でき、キャッシュもローカルにあるため高速です。ただし、代償として自分で運用管理を行い、問題が発生したら自分でトラブルシューティングする必要があります。

項目	GitHub-hosted	セルフホスト
環境	毎回新しい環境	永続的に利用可能
コールドスタート	1-2分	数秒
カスタマイズ性	限定	完全に自由
セキュリティ	完全に分離	自分で強化が必要
コスト	従量課金	マシンコスト+運用

2026年の価格変更解説

ここは詳しく説明する必要があります。

2026年3月以前、プライベートリポジトリのセルフホストランナーは無料でした。自分のマシン、自分の電気代、GitHub は関与しませんでした。しかし3月以降、GitHub はプライベートリポジトリのセルフホストランナーへの課金を開始しました。料金は $0.002/分。

少なく聞こえますか？計算してみましょう。チームが毎日50回 CI を実行し、平均10分かかるとすると、月に15000分、$30 になります。1年で $360、悪くない VPS が買えます。

しかし興味深いことに、同じ時期に GitHub-hosted runners の価格が約40%下がりました。これは人々をクラウドに誘導しようとしているのでしょうか？

結論を急ぐ必要はありません。パブリックリポジトリのセルフホストランナーは依然として無料です。プロジェクトがオープンソースなら、この問題を心配する必要はありません。

いつセルフホストが必要か？

これほど説明しましたが、どのような場合にセルフホストを検討すべきでしょうか？代表的なシナリオをいくつかまとめました。

シナリオ1：イントラネットサービスへのアクセスが必要

CI フローがイントラネットのデータベース、API、またはプライベートイメージレジストリに接続する必要がある場合。GitHub-hosted のマシンはパブリックネットワーク上にあり、イントラネットにアクセスできません。

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

GPU でモデルトレーニングを行う必要がある場合や、128GB メモリで大規模プロジェクトをコンパイルする場合。GitHub-hosted の標準構成は7GB メモリ、2コア CPU のみで、要件を満たせません。

シナリオ3：コスト重視（大量のビルド）

チームが毎日何百回も CI を実行する場合、GitHub-hosted の従量課金が積み重なります。独自のランナーを数台構築する方が、コストが低くなる可能性があります。

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

金融、医療などの業界では、データの越境に関する厳格な要件があります。ビルドプロセスはイントラネットで完了する必要があり、コードは自社のデータセンターを離れることができません。

小規模チームでビルド量が少ない場合、GitHub-hosted は非常に魅力的です。手間がかからず、価格も下がりました。しかし、上記の状況に遭遇した場合、セルフホストを検討する必要があります。

3つのデプロイ手法の比較

手法1：従来のサーバーデプロイ

最もシンプルで直接的な方法です。Linux サーバーを1台用意し、ランナーパッケージをダウンロード、解凍、設定して実行します。

初めてセルフホストランナーをデプロイした時はこの方法でした。CentOS 7 を1台用意し、SSH で接続して、GitHub ドキュメント通りにコマンドを入力しました。30分で完了し、GitHub ページでランナーが「オンライン」と表示されるのを見て、達成感がありました。

メリット：デプロイがシンプルで、Docker や Kubernetes の知識が不要。環境が安定しており、1つのランナーが長期間実行可能。

デメリット：メンテナンスが面倒。ランナーがクラッシュしたら手動で再起動。マシンに問題が発生したら手動でトラブルシューティング。スケーリングには新しいマシンの購入と再設定が必要。

適したシナリオ：小規模チーム、1-2台のランナー、予算制限、コンテナ化を避けたい場合。

手法2：Docker コンテナ化

ランナーを Docker コンテナに入れ、各ビルドタスクが完了したら破棄し、次回は新しいクリーンなコンテナを作成します。これは従来の方法よりもはるかに安全です。悪意あるスクリプトがコンテナを汚染しても、削除してやり直せばいいだけです。

Docker 手法には2つのアプローチがあります。単一コンテナモードと Docker-in-Docker（DinD）。

単一コンテナモード：ランナーがコンテナ内にあり、ビルドもコンテナ内で実行。ほとんどのシナリオに適しています。

DinD モード：ランナーコンテナ内でさらに Docker daemon を実行し、イメージをビルドしたり、マルチコンテナテストを実行したりできます。ただし、DinD には多くのセキュリティリスクがあり、公式も慎重に使用するよう警告しています。

メリット：環境の分離が良く、クリーンアップが簡単。Docker Compose で複数のランナーを一括管理可能。

デメリット：DinD のセキュリティリスク。コンテナオーケストレーションには依然として手動介入が必要。自動スケーリング能力が限定。

適したシナリオ：中規模、セキュリティ分離に関心、チームに Docker の経験がある場合。

手法3：Kubernetes + Actions Runner Controller (ARC)

これは GitHub 公式が推奨する大規模デプロイソリューションです。Actions Runner Controller（略称 ARC）は Kubernetes Operator で、ランナーのライフサイクルを自動管理します。

ARC の動作は非常にスマートです。必要なランナー数を定義すると、自動的に Pod を作成。ビルドタスクが来ると Pod が実行。タスクが終了すると Pod が破棄されます。キューの滞留に応じて自動的にスケールアウトし、アイドル時には自動的にスケールインします。

AWS は2025年1月のブログでこのソリューションを特集し、AWS で大規模に使用する企業に推奨しました。

メリット：自動スケーリング、運用コストが最も低い。Kubernetes のエコシステムツールがすべて利用可能。大規模デプロイに適している。

デメリット：ハードルが高い。Kubernetes、Helm、CRD を理解する必要がある。デプロイの複雑さは前の2つの方法よりはるかに高い。

適したシナリオ：大規模チーム、数十から数百のランナー、Kubernetes インフラがあり、自動運用を追求。

手法の比較と選択の推奨

次の表で、どの手法が適しているかを素早く判断できます。

項目	従来のサーバー	Docker	Kubernetes ARC
デプロイ難易度	低	中	高
環境分離	弱	良	非常に良い
自動スケーリング	なし	限定	完全サポート
運用コスト	高	中	低（自動化後）
学習ハードル	低	中	高
適用規模	1-5台のランナー	5-20台	20台以上

推奨：

小規模チーム（1-5人）、ビルド量が少ない場合：従来のサーバーで十分。コンテナ化を避けてください。

中規模（10-30人）、毎日数十回のビルド：Docker コンテナ化、Runner Fleet または類似ツールで管理。

大規模チーム（30人以上）、CI/CD の分数が数千：Kubernetes ARC。学習コストを投資し、自動運用を手に入れる。

正直なところ、「最適な」手法はありません。「最も適した」手法だけです。チームの規模、技術スタック、運用能力を見て、新しい技術を盲目に追わないでください。

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

パブリックリポジトリ：絶対禁止

ここは先に説明する必要があります。GitHub 公式が明確に警告しています。

“セルフホストランナーはパブリックリポジトリではほとんど使用すべきではありません” — GitHub Docs

なぜでしょうか？パブリックリポジトリは誰でも PR を提出でき、あなたのワークフローをトリガーできます。このランナーがイントラネットのマシンで実行されている場合、悪意のある PR はあなたの環境で任意のコマンドを実行できます。機密ファイルの読み取り、トークンの窃取、さらには他のイントラネットサービスへの横方向攻撃も可能です。

2026年1月、Sysdig のセキュリティ分析記事がこの問題を特別に取り上げました。攻撃者がセルフホストランナーをバックドアとして利用し、企業のイントラネットに侵入しました。これは理論上のリスクではなく、実際に発生した事実です。

したがって、パブリックリポジトリでは GitHub-hosted runner を使用するか、CI を使用しないでください。セルフホストを使用したいですか？まずリポジトリをプライベートにしてください。

Runner Groups による分離戦略

プライベートリポジトリも完全に安全ではありません。異なるプロジェクト、異なるチーム、信頼レベルが異なります。コアビジネスコードのランナーは、実験プロジェクトのランナーと混在させるべきではありません。

Runner Groups はこの問題を解決するためにあります。組織レベルで複数の Runner Group を作成し、プロジェクト、チーム、信頼レベルで分類できます。各 Group はアクセス範囲を設定できます。どのリポジトリが使用でき、どれが使用できないか。

例えば、典型的な構成です。

• critical-prod Group：コアリポジトリのみ使用可能、マシンはイントラネットの隔離ゾーン
• dev-team Group：開発チームのリポジトリが使用可能、マシンは通常のイントラネット
• sandbox Group：実験プロジェクト用、マシンは隔離されたサンドボックス環境

このように、あるリポジトリが侵害されても、攻撃者は対応する Group のランナーにしかアクセスできず、コアシステムには影響しません。

環境強化措置

ランナー自体のセキュリティ強化には、いくつかの基本原則があります。

最小権限の原則：ランナープロセスは専用ユーザーで実行し、root を使用しない。必要なソフトウェアのみをインストールし、攻撃面を減らす。

ネットワーク分離：ランナーマシンを直接パブリックネットワークに公開しない。GitHub の webhook でタスクを受信し、インバウンドのパブリックネットワーク接続は不要。

トークン管理：ランナー登録に使用するトークンには有効期限がある。期限切れたら再生成が必要。トークンをスクリプトにハードコードせず、Secrets で管理。

ログ監査：ランナーの実行ログを保存。異常な動作を追跡可能に。

Wiz は2026年4月のセキュリティガイドで、多くの企業のランナー環境が緩すぎると指摘しました。攻撃者に多くの便宜を提供しています。強化は一度の作業ではなく、継続的なチェックが必要です。

セキュリティツール推奨

GitHub は Harden-Runner というセキュリティツールをリリースしており、ワークフローで直接使用できます。

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

この Action はランナーのネットワークアウトバウンド接続を監視し、異常な動作を報告します。Audit モードと Block モードがあり、Block モードは未承認のアウトバウンド接続を直接ブロックします。

セルフホストランナーの場合、Block モードが特に有用です。悪意あるスクリプトが外部ネットワークに接続してデータを盗もうとすると、直接ブロックされます。

セキュリティについては絶対に油断しないでください。多くのチームを見てきましたが、ランナーをインストールしたら放置し、権限を自由に開き、トークンを設定ファイルにハードコードしています。本当に問題が発生したら、後悔しても遅いです。

Runner Fleet オープンソース管理ソリューション

Runner Fleet とは

前述の Docker コンテナ化デプロイについて説明しましたが、複数のランナーコンテナの管理はまだ面倒です。各コンテナのステータス、トークン、ログが散在し、手動で確認する必要があります。

Runner Fleet はこの問題を専門に解決するオープンソースプロジェクトです。作者の soulteary は Tencent Cloud Developer Community で詳細な実践記事を書き、このプロジェクトの誕生背景と機能を紹介しました。

簡単に言えば、Runner Fleet は Web インターフェースを提供し、すべてのランナーコンテナを一元管理できます。ステータス監視、一括操作、トークン統合管理、障害自己回復。1つ1つのコンテナに SSH する必要がなく、Web ページを開くだけで全体像を確認できます。

主な機能紹介

Runner Fleet には特に気に入っている機能がいくつかあります。

ステータス集約監視：すべてのランナーのオンラインステータス、現在のタスク、履歴実行記録が一目でわかります。1つ1つコンテナログを確認する必要がありません。

トークン統合管理：ランナー登録に使用するトークンを Web インターフェースで設定でき、各マシンで手動設定する必要がありません。トークンが更新されたら、ワンクリックで同期。

自己回復パトロール：ランナーコンテナがダウンすると、システムが自動的に検出して再起動します。デプロイ時にランナーが時々切断される問題に遭遇しましたが、毎回手動でトラブルシューティングする必要がありました。自己回復機能のおかげで、多くの時間を節約できました。

コンテナモードとホストモード：純粋なコンテナ実行、またはランナーをホストで実行しつつコンテナで管理するかを選択可能。両方のモードにそれぞれ利点があり、ニーズに応じて選択できます。

一括操作：すべてのランナーの開始、停止、再起動をワンクリックで実行。スケーリング時に新しいランナーを一括作成し、1台ずつ設定する必要がありません。

クイックデプロイガイド

Runner Fleet 自体は Docker でデプロイされ、数行のコマンドで実行できます。

# イメージをプル
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 トークンを設定、ランナー数を選択、環境パラメータを設定し、数回クリックするだけでランナーを一括作成できます。手動で1つ1つダウンロード、解凍、設定するよりもはるかに時間を節約できます。

チームが Docker を使用しているが Kubernetes を学びたくない場合、Runner Fleet は非常にコストパフォーマンスの高い選択です。コンテナ化分離の利点を享受しながら、複雑な手動運用を気にする必要がありません。

デプロイ実践ステップ

Linux デプロイ5ステップ

従来のサーバーデプロイを使用したい場合、完全なステップは以下の通りです。Ubuntu 20.04 サーバーがあると仮定します。

ステップ1：専用ユーザーの作成

# runner ユーザーを作成、root でランナーを実行しない
sudo useradd -m runner
sudo passwd runner  # パスワードを設定

なぜ専用ユーザーが必要なのか？ランナープロセスはあなたの GitHub トークンにアクセスする権限があります。root で実行すると、侵害された場合、攻撃者は root 権限を取得します。専用ユーザーを使用することで、少なくとも分離層があります。

ステップ2：ランナーパッケージのダウンロード

GitHub の Runner リリースページに行き、最新バージョンのダウンロードリンクを見つけます。

# runner ユーザーに切り替え
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：登録トークンの取得

GitHub リポジトリまたは組織の 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 でランナーにタグを付けられます。後でワークフローで runs-on: [self-hosted, linux] を使用すると、このランナーを指定できます。

ステップ5：systemd サービスのインストール

# システムサービスとしてインストール（root 権限が必要）
sudo ./svc.sh install runner
sudo ./svc.sh start

これにより、ランナーはシステム起動時に起動し、クラッシュしたら systemd が自動的に再起動します。

ワークフローでのランナー指定

ランナーをインストールした後、ワークフローで runs-on で指定します。

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

複数のランナーに同じタグがある場合、GitHub は自動的にタスクを割り当てます。タグのマッチングが正確であればあるほど、割り当てが正確になります。

デプロイ完了後、GitHub ページでランナーステータスを確認することを忘れないでください。「Offline」と表示された場合、ネットワークの問題かトークン設定エラーの可能性があります。

結論

これほど説明しましたが、どう選ぶべきでしょうか？

小規模チーム、ビルド量が少ない：GitHub-hosted を直接使用。値下げ後、コストパフォーマンスが良く、手間がかからない。特殊な状況に遭遇したらセルフホストを検討。

中規模、毎日数十回のビルド：Docker コンテナ化 + Runner Fleet。環境を分離しながら一元管理でき、運用コストが管理可能。

大規模チーム、ランナー数が多い：Kubernetes + ARC。学習コストを投資し、手に入れる自動運用能力は長期的なリターンが高い。

セキュリティ重視のシナリオ：プライベートリポジトリ + Runner Groups 分離 + Harden-Runner 監視。パブリックリポジトリでは絶対にセルフホストを使用しない。これは推奨ではなく、警告です。

2026年の価格変更は確かにコスト計算を変えましたが、セルフホストの価値は単にコスト削減だけではありません。イントラネットアクセス、ハードウェアカスタマイズ、データコンプライアンス。これらの要件は GitHub-hosted では永遠に満たせません。したがって、自分の要件を明確にし、最も適した手法を選択し、流行を追ったり躊躇したりしないでください。

次のステップは？チームがちょうど特定の痛点に直面している場合（イントラネットアクセス、コスト圧力、コンプライアンス要件）、まず Docker + Runner Fleet の組み合わせを試してみてください。デプロイコストが低く、効果はすぐに現れます。本当に大規模なニーズに遭遇したら、Kubernetes ソリューションに移行しても遅くありません。

8 min read · 公開日: 2026年4月23日 · 更新日: 2026年4月25日