GitHub Actions self-hosted runnerを自宅で使う手順【2026年版】

「GitHub Actions の無料枠がすぐ減る」「macOS のビルドが高い」「ジョブの待ち時間が長い」——そんな悩みの答えのひとつが、GitHub Actions の self-hosted runner（セルフホストランナー）です。自宅の PC やサーバーに Runner アプリを入れておくと、GitHub のジョブを手元のマシンで実行できます。

結論から言うと、非公開のリポジトリで、ワークフローを動かすのが自分（信頼できる人）だけなら有力な選択肢です。self-hosted runner の利用料は 2026年11月13日時点で無料 で、無料枠も減りません。一方で、公開リポジトリでは使わないのが鉄則です。他人のプルリクエストで、自宅のマシンが乗っ取られるおそれがあるためです。

2026年は料金の話題でも揺れました。GitHub は self-hosted runner にも1分0.002ドルをかけると発表したあと延期しています。この記事では、標準 Runner との比較、2026年の料金の扱い、公式の手順での導入、安全に使うための対策を順に整理します。

Self-hosted runners

self-hosted runnerとは？一言でまとめると

self-hosted runner は、GitHub Actions のジョブを「自分で用意したマシン」で実行するしくみです。普段の Actions は GitHub が用意した仮想マシン（GitHub-hosted runner、この記事では「標準 Runner」）で動きますが、その代わりに自宅の PC・サーバー・仮想マシン・コンテナを使えます。

しくみはシンプルです。マシンに入れた Runner アプリが GitHub に外向きの HTTPS（443番）でつなぎ、ジョブを取りに行きます。家のルーターでポートを開けたり、固定 IP を用意したりする必要はありません。

Runner を登録できる単位は3つあります。個人で使うなら、まずはリポジトリ単位で十分です。

GitHub標準Runnerとの比較：料金・性能・手間の違い

標準 Runner と self-hosted runner の違いを、2026年11月13日時点の公式ドキュメントで並べました。

ひと言でいえば、標準 Runner は「お金で手間を買う」、self-hosted runner は「手間でお金と自由を買う」選び方です。速さは手元のマシン次第で、古いノート PC なら標準 Runner より遅くなることもあります。「タダになる」だけで選ぶと、管理の手間で損をする点は先に押さえておきたいところです。

2026年の料金：self-hosted runnerは今も無料？

① いまの料金のしくみ

2026年11月13日時点の GitHub の課金ページでは、非公開リポジトリの Actions は「毎月の含まれる計算量（ドル建て）」から差し引く方式です。self-hosted runner の利用は無料で、この枠も減らしません。

標準 Runner の単価は、Linux 2コアが1分0.006ドル、Windows が0.010ドル、macOS が0.062ドルです。Free の12ドルを Linux 2コアだけに使うと 2,000分、macOS だけなら約193分になります。macOS の単価は Linux の10倍を超えるため、iOS アプリのビルドがあると枠がすぐに尽きます。

なお、支払い方法を登録していないと、含まれる分を使い切った時点でジョブが止まります。月の途中で CI が動かなくなるのは、たいていこれが原因です。

② 0.002ドルの課金は「延期」のまま

GitHub は2025年12月16日、標準 Runner を2026年1月1日から最大39%値下げすると同時に、self-hosted runner にも2026年3月1日から1分0.002ドルをかけると発表しました。その後 GitHub は、「方針を見直すため延期する」と告知に追記しています。

「中止」ではなく「延期」なので、将来また課金の話が出る可能性はあります。self-hosted に乗り換えるなら、半年に1回くらいは課金ページを見直しておくと安心です。

③ どれくらい差が出る？試算

非公開リポジトリで、1回10分の CI を30日動かした場合を、公式の単価で試算しました（Free プラン、ストレージ代は含めない。実際の請求額ではありません）。

Linux で1日数回なら無料枠で足ります。差が大きく出るのは macOS のビルドが多い人と、1回が長いビルドを何度も回す人です。

クラウドの無料枠でサーバーを用意して Runner を置く方法もあります。各社の無料枠の比較はこちら。

あわせて読みたい

クラウド無料枠を比較：AWS・GCP・Azure・OCI【2026年版】

自宅サーバーで使うべき？選び方のチェック

迷ったら、次の3つの質問で決めると失敗しにくいと考えています。

導入前の準備：対応OSと必要なもの

Runner アプリが動く OS は、2026年11月13日時点で次のとおりです。

用意するものは次の4つです。

• 権限: 個人のリポジトリならオーナー、Organization のリポジトリならオーナーか管理者権限
• 通信: GitHub への外向きの HTTPS（443番）。帯域は上り・下りとも 70kbps 以上
• Docker: Docker コンテナのアクションやサービスコンテナ（DB など）を使うなら、Linux に Docker が必要
• 専用のユーザー: Runner アプリは root（sudo）では設定できません。専用の一般ユーザーを作っておきます

ラズパイのような ARM64 の Linux でも動くので、余っている小型 PC を CI 専用機にするのは現実的な使い方です。

導入手順：リポジトリにRunnerを登録する

ここからは、GitHub 公式の手順（Linux の場合）を、迷いやすい点を補って並べ直しました。

① リポジトリの Settings を開く

リポジトリのページで Settings → 左のメニューの Actions → Runners を開き、「New self-hosted runner」を押します。Settings が見えないときは、タブの「…」の中にあります。

② OS と CPU を選ぶ

Linux・macOS・Windows と、x64 か ARM64 かを選びます。選ぶと、そのマシンで打つコマンドが画面に表示されます。

③ Runner アプリをダウンロードする

表示されたコマンドで、作業用のフォルダ（例: actions-runner）に Runner アプリをダウンロードして展開します。画面には SHA-256 を照合するコマンドも出るので、省かずに実行しておくと安心です。展開すると Node.js などが入った状態で 約680MB になるので、ディスクには余裕を持たせます。

Linux では、展開したフォルダの ./bin/installdependencies.sh を sudo で実行すると、足りないライブラリ（libicu など）が入ります。ここまでを実際に動かしたときの表示とつまずいた所は、下の「実際にセットアップしてみた」にまとめています。

④ config.sh で登録する

画面に出る ./config.sh --url <リポジトリの URL> --token <登録トークン> を実行します。登録トークンは1時間で失効するので、コピーしたらすぐに実行するのがコツです。途中で Runner の名前・グループ・ラベル・作業フォルダを聞かれ、Enter で既定値になります。

⑤ run.sh で起動する

./run.sh を実行し、「Connected to GitHub」「Listening for Jobs」と出れば待機状態です。GitHub の Runners の一覧にも表示されます。

⑥ サービスにして常駐させる

run.sh はターミナルを閉じると止まります。常に動かすなら、登録後に install → start の順に実行してサービス（Linux は systemd）にします。3行目は状態の確認です。

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

ワークフローで使う方法：runs-onとラベル

登録した Runner には、自動で self-hosted・OS（linux など）・CPU（x64 など）のラベルが付きます。ワークフローの runs-on にラベルを並べると、全部のラベルを持つ Runner にジョブが回ります。

name: ci
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npm test

実際の流れは「push → GitHub がジョブをキューに入れる → 自宅の Runner が取りに来る → 手元で npm test が動く → ログと結果が GitHub の画面に出る」です。条件に合う Runner が待機していないと、ジョブはキューで待ち続け、24時間で失敗します。

よく使う工夫は次の3つです。

• 独自ラベル: GPU があるマシンに gpu などのラベルを付け、runs-on: [self-hosted, gpu] で指定する
• 標準 Runner と使い分け: 軽いチェックは ubuntu-latest、重いビルドだけ self-hosted にする
• 依存の固定: 使うアクションのバージョンを固定しておくと、意図しないコードが自宅のマシンで動くのを防げる

アクションのバージョン固定については、GitHub Actions のロックファイルの記事で詳しく紹介しています。

あわせて読みたい

GitHub Actionsにロックファイル、依存をコミットで固定【2026年10月】

常駐・更新・片付けの方法

self-hosted runner は、入れっぱなしにすると「いつの間にか動かない」「古いまま」になりがちです。運用で知っておきたいルールをまとめます。

セキュリティ対策：自宅で使う前の6つのチェック

自宅のマシンで他のコードを動かす以上、セキュリティがいちばん大事な節です。GitHub のセキュリティガイドの内容を、自宅で使う場合に置き換えて整理しました。

① 公開リポジトリでは使わない

GitHub は、self-hosted runner を公開リポジトリで使うことはほぼ避けるべきとしています。誰でもフォークしてプルリクエストを出せるため、悪意のあるコードが自宅のマシンで動くおそれがあるからです。

手順のページの冒頭にも、非公開リポジトリだけで使うことを勧める警告が最初に出ています。

② 非公開でも「誰が動かせるか」を絞る

非公開リポジトリでも、読み取り権限がある人はフォークしてプルリクエストを出せます。その結果、シークレットや GITHUB_TOKEN が盗まれるおそれがあります。共同作業者を招くときは、この点を考えて権限を決めます。

③ 専用のマシンかコンテナで動かす

Runner はジョブが終わっても前の状態が残ります。普段使いの PC で動かすと、SSH 鍵・API トークン・写真などの個人のファイルにジョブから手が届きます。専用の小型 PC・仮想マシン・Docker のコンテナに分けるのが基本です。

④ ephemeral で1ジョブごとに使い捨てる

config.sh に --ephemeral を付けると、1つのジョブを終えたら自動で登録が外れます。コンテナと組み合わせて「毎回まっさらな環境で登録し直す」形にすると、前のジョブの痕跡を引き継がずに済みます。Kubernetes を使う人なら、GitHub が案内している Actions Runner Controller（ARC）が、ジョブごとにコンテナの Runner を作って消すしくみです。

⑤ 家の LAN から切り離す

ジョブからは家の NAS やルーターの管理画面にも通信できてしまいます。ゲスト用のネットワークや VLAN に置く、ファイアウォールで外向きの通信を GitHub などに絞るなど、届く範囲を小さくしておくと安心です。

⑥ デプロイの鍵を置かない

クラウドへのデプロイに使うなら、長く使える鍵をマシンに置かず、GitHub が勧める OpenID Connect（OIDC）で短時間だけ使える認証情報を発行する方法を検討します。

他の人の導入事例：自宅サーバー・Kubernetes・Mac mini

実際に self-hosted runner を動かした人の公開記事から、3つの例を紹介します（いずれも筆者・チームの環境での話です）。

Zenn の inunekousapon さんは、自宅サーバーの VM に Ansible と Docker で Runner を立てた記録で、config.sh が root で動かないことや libicu の不足でつまずきやすいと書いています（出典）。

Zenn の tochiman さんは、ラズパイを含むリソースの少ない Kubernetes に ARC を入れ、ジョブごとに Pod ができて終わると消える点が限られたマシンに向いていると述べています（出典）。

@IT の記事によると、英 Guardian のチームは iOS アプリの CI を社内の Mac mini に移し、月約400ポンドを削減した一方、ディスク容量や Xcode・シミュレーターの片付けを自分たちで管理する手間が増えたと振り返っています（出典）。

3つに共通するのは、「動かすまで」より「動かし続ける」ほうに手間がかかるという点です。自宅のマシンが止まれば CI も止まるので、電源・回線・ディスクの面倒を見られるかを先に考えておきたいところです。

自宅に置くのが難しい場合は、VPS に Runner を置く方法もあります。VPS の選び方はこちら。

あわせて読みたい

【2026年版】VPSおすすめの選び方｜失敗しやすいポイントと候補まとめ

実際にセットアップしてみた

2026年11月13日に、テスト用の Linux 環境（Docker の Ubuntu 24.04.5 LTS）で次の手順を実際に動かしました。動かしたのは GitHub への登録の手前までで、Runner アプリのダウンロード・展開・準備と、登録前のコマンドの動きです。GitHub への登録（登録トークンを使う config.sh）とジョブの実行はしていません。

① Runner アプリをダウンロードして照合する

2026年11月13日時点の最新版 v2.338.2（Linux x64）を、リリースページから取ってきました。

curl -sSL -o r.tar.gz https://github.com/actions/runner/releases/download/v2.338.2/actions-runner-linux-x64-2.338.2.tar.gz
sha256sum r.tar.gz

baebf204307bac6193480852732f0aba2ae97b6c5597c244f4d5558390147c40  r.tar.gz

ファイルは 228,071,396 バイトで、SHA-256 はリリースページに載っている値と一致しました。

② 展開して、足りないライブラリを入れる

tar xzf r.tar.gz
ls externals
du -sh .
sudo ./bin/installdependencies.sh

node20
node20_alpine
node24
node24_alpine
683M    .
... Setting up libicu74:amd64 ... Finish Install Dependencies

展開すると中に Node.js 20 と 24 が入っていて、フォルダ全体で 約683MB になりました。小さな SD カードのラズパイなどでは容量に気をつけてください。installdependencies.sh で、足りなかった libicu74 が入りました。

③ 一般ユーザーで config.sh を開く

./run.sh --version
./config.sh --help

バージョンは 2.338.2 と表示されました。root（sudo）のまま ./config.sh を実行すると「Must not run with sudo」と出て止まるので、Runner 用の一般ユーザーを作って、そのユーザーで動かします。

一般ユーザーで --help を開くと、--ephemeral（1ジョブで登録を外す）、--labels（独自ラベル）、--disableupdate（自動更新を止める）、--unattended（質問なしで登録）などの設定が並んでいました。既定のラベルは self-hosted,Linux,X64 です。

④ 登録前に run.sh を動かしてみる

./run.sh

An error occurred: Not configured. Run config.(sh/cmd) to configure the runner.

登録前の run.sh はこのエラーで終わります。このメッセージが出たら、config.sh での登録がまだ済んでいないということです。

この先は公式の手順

GitHub への登録（./config.sh --url … --token …）、run.sh での待機、svc.sh でのサービス化、ワークフローからのジョブの実行は、今回は行っていません。上の「導入手順」の④〜⑥で、GitHub 公式の手順として説明しています。

よくある質問

Q. self-hosted runner は本当に無料ですか？ A. 2026年11月13日時点の GitHub の課金ページでは、self-hosted runner の利用は無料で、プランに含まれる計算量も減りません。ただし2025年12月に発表された1分0.002ドルの課金は「延期」で、中止ではありません。マシン代・電気代は自分持ちです。

Q. 無料の GitHub Free プランでも使えますか？ A. 使えます。課金ページでは Free プランも含めて self-hosted runner は無料と書かれています。個人のリポジトリならオーナーが Settings から登録できます。

Q. 自宅のルーターでポートを開ける必要はありますか？ A. ありません。Runner から GitHub への外向きの HTTPS（443番）でジョブを取りに行くしくみです。

Q. Windows や Mac でも動きますか？ A. 動きます。Windows 10・11（64ビット）と Windows Server 2016〜2022、macOS 11 以降に対応しています。ただし Docker コンテナのアクションを使うなら Linux が必要です。

Q. PC の電源を切っている間はどうなりますか？ A. ジョブはキューで待ち、24時間で失敗します。14日以上つながらないと Runner の登録も自動で消えるので、再開時は登録し直します。

まとめ

GitHub Actions の self-hosted runner のポイントをまとめます。

• しくみ：自宅などのマシンの Runner アプリが、外向きの HTTPS（443番）でジョブを取りに行く
• 料金：self-hosted runner の利用は無料（2026年11月13日時点）。1分0.002ドルの課金は延期中
• 標準 Runner の無料枠：Free は月12ドル分（Linux 2コアなら2,000分、macOS なら約193分）
• 向いている人：非公開リポジトリ・macOS や重いビルドが多い・家の機器を使いたい人
• 導入手順：Settings → Actions → Runners → New self-hosted runner → config.sh（トークンは1時間）→ svc.sh
• いちばんの注意：公開リポジトリでは使わない。専用マシンか ephemeral のコンテナで動かす

まずは今の Actions の使用量を Settings の課金画面で確かめ、無料枠が足りているかを見てから、余っている小型 PC と非公開リポジトリの組み合わせで1台から始めるのがおすすめです。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。