【入門編】GitHub Actionsの「GitHub-hosted runners」でネットワーク制限を回避する！静的IPアドレス管理とPrivate Network接続の仕組み – バージョン管理・CI/CD活用バイブル

こんにちは！日々のCI/CDパイプラインとの格闘、本当にお疲れ様です。

「GitHub Actionsでテストを自動化したいけれど、テスト対象のデータベースやステージング環境が社内LANやAWSのプライベートサブネット（VPC）の奥深くにあって、ランナーからアクセスできない……」
そんな壁にぶつかって、頭を抱えた経験はありませんか？

「じゃあ、社内に常時起動の仮想マシンを自前で用意して（セルフホステッドランナー）、そこで動かせばいいか」
……ちょっと待ってください。それ、マシンの保守運用コストやセキュリティパッチの当て忘れなど、新たな技術的負債を生む悪手になりかねません。

実は、GitHubが管理してくれる安全でクリーンな環境（GitHub-hosted runners）を使いながら、社内のプライベートリソースに安全にアクセスするスマートな方法があるんです。

今回は、初心者の方でも迷わず実装できるように、この「ネットワークの壁」を華麗に突破する仕組みと具体的なアプローチを、優しく丁寧に解説していきますね。これをマスターすれば、毎日のデプロイ作業が劇的に楽になりますよ！

—

1. なぜGitHub-hosted runnersはプライベート環境に繋がらないのか？

まず敵を知ることから始めましょう。私たちが普段何気なく使っているGitHub-hosted runners（`ubuntu-latest`など）は、GitHubがクラウド上に一時的に用意してくれる使い捨ての仮想マシンです。

このランナーには、大きく分けて2つの「もどかしい仕様」があります。

1. IPアドレスが毎回変わる（動的IP）
GitHubのランナーは世界中のAzureなどのデータセンターで動いており、そのIPアドレス範囲は公開されているものの、実行のたびに変動します。そのため、ファイアウォール（セキュリティグループ）で「このIPからのアクセスだけ許可する」という静的な設定ができません。
2. デフォルトでは「外側」のインターネットにしか出られない
ランナーは外の世界（パブリックなインターネット）には自由に出られますが、企業のファイアウォールの内側や、VPCのプライベートサブネットといった「閉じたネットワーク」から見ると、完全に部外者です。

セキュリティをガチガチに固めたインフラほど、外からの侵入を拒むため、GitHub Actionsからのアクセスが弾かれてしまうのです。

—

2. 解決へのアプローチ：3つの選択肢を比較する

この問題を解決するためには、ランナーから社内・VPC内へ「安全なトンネル」を掘る必要があります。代表的な3つの手法を、現場のエンジニア目線で比較してみましょう。

今回は、あらゆる環境（AWS、GCP、オンプレミス）で最も手軽かつセキュアに導入できる「Tailscale」を用いたアプローチを、「Hello World」的な動作確認レベルまで一緒に見ていきましょう！

—

3. 実践！Tailscaleを使ってプライベートリソースに安全にアクセスする

Tailscaleとは？

一言で言うと、「複雑なVPNの設定をすべて自動化してくれた、魔法のようなメッシュネットワーク構築ツール」です。これを使うと、GitHub Actionsのランナーと社内サーバーが、あたかも同じ部屋のLANケーブルで繋がっているかのように安全な通信ができるようになります。

全体の流れはこうです。
1. Tailscaleのアカウントを作り、社内サーバーにTailscaleをインストールする。
2. GitHub Actionsのワークフロー内で、ステップの途中にTailscaleを「参加」させる。
3. ランナーから社内サーバーのプライベートIPで通信する！

ステップ1：ワークフローの基本形を作る

まずは、ごく普通のGitHub Actionsのワークフローファイルを用意します。ここでは、プライベート環境にあるサーバー（例: `10.0.1.50`）に対して、Pingや疎通確認を行うシナリオを想定しましょう。

プロジェクトの `.github/workflows/connect-private.yml` を作成し、以下のように記述します。

name: Secure Private Network Access

on:
workflow_dispatch: # 手動でいつでも実行できるようにします

jobs:
access-private-resource:
runs-on: ubuntu-latest

steps:
# 1. リポジトリのコードをチェックアウト

name: Checkout repository

uses: actions/checkout@v4

# 2. ここが核心！Tailscaleをランナーに一時参加させる

name: Connect to Tailscale

uses: tailscale/github-action@v2
with:
# GitHubのSecrets（後述）から認証用キーを読み込みます
oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }}
oauth-secret: ${{ secrets.TS_OAUTH_SECRET }}
tags: tag:ci-runner
# 接続完了を少し待つ設定
version: 1.60.0

# 3. 接続確認！社内プライベートIPへアクセスしてみる

name: Test connection to private server

run: |
echo “Tailscale経由でプライベートリソースにアクセスします…”

# 例: 社内プライベートIP (10.0.1.50) の特定のポートにアクセスできるか確認
nc -zv 10.0.1.50 5432 || echo “接続テスト失敗（環境に合わせてIPを変更してください）”

ステップ2：GitHub Secretsの設定

上記のワークフローを動かすためには、Tailscaleの認証情報が必要です。Tailscaleの管理画面（Admin Console）から「OAuth Clients」を発行し、以下の2つの値をGitHubリポジトリの Settings > Secrets and variables > Actions に登録してください。

`TS_OAUTH_CLIENT_ID`
`TS_OAUTH_SECRET`

たったこれだけです！これで、GitHub Actionsが実行される瞬間に、この使い捨てランナーがあなたのプライベートネットワークの「一時的な一員」になります。

—

4. 精度高い「HelloWorld」的動作確認：実際にデプロイしてみよう

理論がわかったところで、本当にプライベート環境と通信できているかを確かめる「HelloWorld」的なミニ検証をしてみましょう。

社内にポツンと置いた（あるいはAWSのプライベートサブネットに立てた）検証用サーバー（踏み台でもOKです）にTailscaleをインストールしておきます。

社内サーバー側でのTailscaleインストール例 (Ubuntu)
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg | sudo tee /usr/gring-keys/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale
sudo tailscale up –authkey=tskey-auth-… # 認証キーを使って参加

この状態で、先ほど作成したGitHub Actionsのワークフローを「Run workflow」で手動実行してみてください。

ログ画面を開き、Tailscaleのステップが緑色になり、プライベートIPへの通信テストが成功しているログを見届ける瞬間……。エンジニアとして、ちょっとアドレナリンが出る瞬間ですよ！

—

5. スペシャリストからの現場の教訓（知見）

最後に、この構成を本番運用する上で、知っておくべき「現場の泥臭い知見」をいくつかシェアします。

オート・オーソライゼーション（自動承認）の活用

GitHub Actionsのランナーは使い捨てのため、実行のたびに新しいTailscaleのノードとして登録されます。Tailscaleの管理画面で「毎回手動承認」するのは面倒なので、タグ（`tag:ci-runner`）を利用して、自動でネットワークに参加・退出できる設定を必ず行っておきましょう。

セキュリティグループの最小化

Tailscaleを導入したからといって、社内ネットワークのすべてが丸見えになって良いわけではありません。「GitHub Actionsのランナーからアクセスしてよいのは、特定のデータベースサーバーの特定のポート（例: PostgreSQLの5432）だけ」といったように、ファイアウォール（セキュリティグループ）のルールは極限まで絞り込みましょう（最小権限の原則）。

コストと運用のバランス

セルフホステッドランナーの管理コスト（OSアップデート、セキュリティ担保）に比べれば、こうしたマネージドなトンネリングツール（Tailscaleなど）を組み合わせるアプローチは、クラウド時代において圧倒的にコスパが高い選択肢です。

—

まとめ

いかがでしたでしょうか？
「GitHub-hosted runnersだから社内リソースに繋がらない」というのは、もう過去の話です。

動的IPの課題は、TailscaleのようなセキュアなVPNトンネルをステップ内で動的に張ることで華麗にクリアできる。
自前サーバーの保守地獄から解放され、常に最新でクリーンなGitHubの環境をそのままプライベート接続に活用できる。

これをマスターすれば、あなたのチームのCI/CDパイプラインは、セキュリティを一切妥協することなく、社内のあらゆるシステムとシームレスに連携できるようになります。

毎日の開発・デプロイ作業が、もっと安全に、もっと楽しくなりますように。それでは、良きCI/CDライフを！