こんにちは、てつです！
前回の第1回記事「【自宅サーバー自動化】Docker ComposeをGitHubで管理する手順と.gitignoreの書き方」では、自宅サーバーの設定ファイルをリポジトリ化し、安全にGit管理下へ置くという「インフラの資産化（IaC）」の基礎を構築しました。
皆さん、無事に最初のコミットは完了しましたか？
前回の記事[【自宅サーバー自動化】Docker ComposeをGitHubで管理する手順と.gitignoreの書き方【第1回：GitHubで『自宅DevOps』構築編！】]
無事にファイルをGitHubへプッシュできたあなたなら、きっと次にこんな壁を感じているはずです。
「コードを書き換えるたびに、毎回自宅サーバーにSSHログインして docker compose up -d を手動で叩き直すの、地味に面倒だな……」
せっかくGitで管理を始めたのですから、プロの開発現場のように、PCから git push した瞬間に、自宅サーバー内のコンテナがフルオートで最新化される未来を体験したくありませんか？
通常、外部のクラウド（GitHub）から自宅内にある物理サーバーへ命令を飛ばそうとすると、ルーターのポートを開放してSSHやWebhookを外部公開するという極めて高いセキュリティリスクが伴います。しかし、企業のシビアな開発現場でそんな危険な真似は絶対にしません。
そこで登場するのが、今回の主役である「Self-hosted Runner（セルフホストランナー）」です。これを使えば、ルーターのポート開放を1つもすることなく、完全なプライベート環境を維持したまま、GitHub Actionsの自動化命令を自宅サーバーへ届けることが可能になります。
まさに「趣味」を超えた、エンタープライズ基準のプロ仕様環境をあなたの自宅ホームラボへ引き込みましょう！
１．Self-hosted Runnerとは？自宅サーバーを安全に自動化できる仕組み
まずは、なぜ外部から自宅サーバーを叩かないのに自動化が成り立つのか、そのロジックをプロのインフラエンジニアの視点から解説します。
従来の考え方（プッシュ型）では、GitHubから自宅サーバーに向けて通信を「投げ込む」ため、壁となるルーターに穴（ポート）を開ける必要がありました。
しかし、Self-hosted Runnerは真逆の「プル型（引き込み型）」という仕組みを採用しています。
なぜポート開放なしで外部のGitHubから命令が届くのか？
自宅サーバー側に「エージェント」と呼ばれる常駐プログラム（ランナー）を置いておき、そのランナーが自発的に「GitHubさん、私に実行すべき自動化ジョブはありますか？」と、内部から外（インターネット）へ向かって定期的に確認（ロングポーリング）しに行きます。
通信の起点が常に「自宅から外」であるため、ルーターのファイアウォールを一切変更することなく、安全にクラウドからの命令だけを持ち帰ることができるのです。
これは金融系インフラなど、最高峰のセキュリティが求められる現場でも定番の手法です。
自宅サーバー自動化に必要な前提環境チェックリスト
GitHubリポジトリ: 第1回で作成した、Docker Compose管理用のプライベート（非公開）リポジトリ。
自宅サーバー環境: Linux OS環境（Ubuntu / Debianなど）で、DockerおよびDocker Composeが導入済みであること。
インターネット接続: 通常のネット接続環境（グローバルIPの固定、DDNS、ポート開放はすべて不要）。
２．GitHub Actionsと自宅サーバーを繋ぐ！3ステップ構築手順
それでは、具体的に手を動かしてパイプラインを構築していきましょう。手順は大きく分けて3つだけです。
【ステップ1】GitHub側での設定（ランナー登録情報の取得）
まずは、自宅サーバーをあなたのリポジトリの「専属作業員」として登録するためのキー（トークン）をGitHubから取得します。
１．GitHub上で、第1回で作成したDocker Compose管理用のリポジトリを開きます。
２．画面上部のメニューから Settings（設定）タブをクリックします。
３．左側のサイドバーメニューを少し下にスクロールし、Actions ＞ Runners の順に選択します。
４．画面右上に表示される緑色の New self-hosted runner ボタンをクリックしてください。
５．環境選択画面が出るので、Runner Imageで「Linux」、Architectureで「x64」（お使いの環境がRaspberry Piなどの場合はARM）を選択します。
すると、画面下部に「Download」と「Configure」という項目で、実行すべきコマンド群がずらりと表示されます。
このコマンド一式は後ほどサーバー側でそのままコピー＆ペーストして使いますので、画面を開いたままにしておくか、テキストエディタに控えておいてください。
【ステップ2】自宅サーバー（Linux）側の設定と自動起動（systemd）
次に、自宅サーバーにSSHログインし、先ほどGitHubから提示されたコマンドを流し込んでいきます。
まずは安全のため、ランナー専用の作業用ディレクトリを作成して移動します。
$ mkdir actions-runner && cd actions-runner続いて、GitHubの画面に表示されている「Download」のコマンド（curlでのパッケージダウンロードやハッシュチェック）を1行ずつ順番に実行してください。無事に展開が終わったら、以下の設定コマンド（Configure）を実行します。
$ ./config.sh --url https://github.com/YOUR-USERNAME/YOUR-REPO --token XXXXXXXXXXXXXXXXXXXXXXXXX※ --url や --token の中身は、各自のGitHub画面に表示されている固有の値をそのまま使用してください。
コマンドを実行すると、対話式のセットアップ（プロンプト）が始まります。基本的にはすべてデフォルト（そのままEnterキー）で問題ありませんが、以下の点を意識するとプロっぽい綺麗な管理ができます。
- Enter the name of the runner group: そのままEnter（Defaultグループ）
- Enter the name of runner: 識別しやすい名前（例：
home-server-runner）を入力してEnter - Enter any additional labels: 今回は
home-serverと入力してEnter（このラベルを元に、後々ジョブを割り振ります） - Enter name of work folder: そのままEnter（
_workフォルダが自動生成されます）
🛠️ プロ仕様の極意：systemd（Linuxのサービス）に登録して自動起動させる
対話セットアップが終わった後、./run.sh を叩けばその場でランナーが起動しますが、これではSSHのセッションを切ったり、サーバーを再起動した瞬間に自動化が止まってしまいます。
現場のインフラ運用では、OSのデーモン管理システムである systemd（システムディー） にサービスとして登録するのが常識です。
以下のコマンドを叩いて、サーバー起動時にバックグラウンドで永続常駐するように設定しましょう。
# ランナーをsystemdのサービスとしてOSにインストール
$ sudo ./svc.sh install
# サービスを開始する
$ sudo ./svc.sh start【ステップ3】接続確認（GitHub上でStatusが緑色になれば成功）
サーバー側でサービスが正常に開始されたら、再びGitHubの画面に戻りましょう。
先ほどの Settings ＞ Actions ＞ Runners の画面をリロードすると、今セットアップした自宅サーバーの名前（例: home-server-runner）がリストに出現しているはずです。
この時のステータス表示が 「● Idle（緑色）」 になっていれば、クラウドと自宅の物理サーバーが安全な一本のパイプラインで結ばれた証拠です！これで、いつでもGitHubからの自動化命令を自宅サーバーが受け取れる「無敵の体制」が整いました。
３．インフラエンジニアが警告！パブリックリポジトリでの運用は絶対にNGな理由
ここで、現役インフラエンジニアとして、あなたの自宅のネットワーク資産を守るための極めて重要なセキュリティ仕様についてお話しします。
今回の設定を行うにあたり、リポジトリの設定が確実に「Private（非公開）」になっていることを、今一度確認してください。
セキュリティ警告：パブリックリポジトリにSelf-hosted Runnerを紐付けるリスク
もし、誰でも閲覧・コード提案ができる「Public（公開）」リポジトリに自宅サバのSelf-hosted Runnerを紐付けてしまうと、悪意ある第三者が「不正な自動化コードを含んだプルリクエスト（コード変更提案）」を送りつけるだけで、あなたの自宅サーバー内で任意のコマンドを勝手に実行できてしまいます。
最悪の場合、自宅サーバーを踏み台（サイバー攻撃の身代わり）にされて外部を攻撃されたり、内部の個人データを盗まれたり、仮想通貨のマイニング（採掘）にCPUを100%酷使されて電気代を搾取されるといった恐ろしい被害に直結します。
手軽にプロと同じ環境が作れるからこそ、「自宅DevOpsのリポジトリは絶対にPrivate（非公開）で運用する」というプロの鉄則を肝に銘じておきましょう。
４．Self-hosted Runner構築でよくあるエラーと対処法（トラブルシューティング）
インフラの構築にトラブルは付き物です。もし途中でうまく進まなかった場合は、以下の「あるあるエラー」と対処法を確認してください。
エラー①トークンの有効期限切れ（Expired）でセットアップが失敗する
./config.sh の実行時にトークンエラー（Expiredなど）で失敗することがあったら以下の点を確認してください。
原因: GitHubの画面で発行される登録用のトークン（Token）には、セキュリティ上の理由から「数分間」という非常に短い有効期限が設定されています。画面を出してからコマンドを叩くまでに時間が空くと、期限切れになります。
対策: 一度GitHubの Runners 画面をブラウザでリロード（再読み込み）してください。新しいトークンを含んだコマンドが再生成されますので、それを即座にコピーしてサーバー側で実行すれば解決します。
エラー②GitHub Actions実行時にDockerコマンドの権限不足で落ちる
後々の自動化実行時、Dockerコマンドの権限でエラーになってジョブが落ちることがあったら、以下の点を確認してみてください。
原因: Linuxでは、初期状態だと一般ユーザーは sudo（管理者権限）を付けないとDockerコマンドを叩けません。Self-hosted Runnerのエージェントは一般ユーザー権限で動くため、将来的にGitHub Actionsからコンテナを立ち上げようとした際、権限不足で弾かれてしまいます。
対策: ランナーを実行しているユーザーを docker グループに所属させ、管理者権限なしでもDockerを扱えるようにします。以下のコマンドを実行後、一度ログアウトして再ログイン（またはサービス再起動）してください。
# 現在のユーザーをdockerグループに追加
$ sudo usermod -aG docker $USERまとめ次回はGitHub Actionsによる「YAML構文チェック（CI環境）」を構築！
お疲れ様でした！
これで、ルーターを傷つける（ポートを開ける）ことなく、安全にクラウドから自宅サバへコマンドを届けるための「心臓部」が完成しました。手動でSSHログインを繰り返す退屈な運用からの脱却まで、あと一歩です。
次回（第3回）は、この繋がったパイプラインをいよいよ実戦投入します。プッシュされた docker-compose.yml にインデントのズレや記述ミスがないかを、デプロイ前に自動で検知して教えてくれる「YAMLミスの自動検知（CI環境の構築）」に挑戦します！
設定ミスで自宅サーバーのコンテナが不意に停止し、家族や自分自身のサービスが落ちて絶望する……そんなトラブルを未然に防ぐプロの防衛策を学びましょう。お楽しみに！
💡 あなたの自宅サバのステータスは無事に「緑色」になりましたか？
「繋がった！」「systemd化で少し詰まったけど動いた！」など、構築の感想やホームラボの様子をぜひコメントやSNSで #てつログ をつけて教えてください！この記事が役に立った方は、ぜひブックマークやシェアをお願いします！
また、今回の連載で構築する「自宅自動化環境」のより高度なエラーハンドリング集や、ワンクリックで環境を爆速構築できる「自動化シェルスクリプトの完成版テンプレート」は、将来的にnoteにて販売も予定しています。
気になる方は今のうちにブログのブックマークとnoteのフォローをお願いします！
それでは、また次回の記事でお会いしましょう！
コメント