GitHub Actions（GHA）は、CI/CD（継続的インテグレーション／デリバリー）を自動化するための強力な仕組みです。その中核を担うのが「ランナー（Runner）」です。
ランナーは、実際にワークフロー内のジョブを実行する実行環境のことを指し、GHAでは大きく2種類に分かれます。
Table of Contents
■ GitHubホストランナーとは
最も手軽に使えるのが「GitHubホストランナー」です。
これはGitHub社が管理する仮想マシン環境（Windows/Linux/macOS）上でジョブを実行するもので、ユーザーは環境構築を意識する必要がありません。
ワークフローでは次のように指定します：
runs-on: ubuntu-latestこの指定だけで、GitHubが自動的に最新のUbuntuランナーを割り当て、依存関係のインストールやビルドを実行してくれます。
中小規模のプロジェクトや、クラウド上での一時的なジョブ実行に最適な方式です。
■ セルフホスティッドランナーとは
一方、企業のセキュリティ要件や大規模プロジェクトでは、社内ネットワークやクラウド内に独自のランナーを構築するセルフホスティッドランナーが用いられます。
これにより、以下のようなメリットがあります。
- 社内リソース（社内サーバやデータベース）へ直接アクセス可能
- カスタムツールやライブラリを事前インストール可能
- 高いセキュリティポリシーを維持したままCI/CDを実行できる
設定画面では「新しいランナーを追加」から、OSやアーキテクチャ（例：Windows ×64）を選択し、提示されたコマンドを実行して登録します。
■ セルフホスティッドランナーの基本構成
エンタープライズ環境でセルフホスティッドランナーを構築する場合、アーキテクチャの概念は次のようになります。
つまり、GitHub Actionsがクラウド上でワークフローをトリガーし、
社内ネットワーク上にあるランナーが実際の処理を担当します。
このとき、GitHubとランナー間ではHTTPS（443ポート）通信のみで接続されるため、ファイアウォール環境下でも構築しやすいのが特徴です。
ランナー自身が アウトバウンド通信（外向き通信）を行うだけで動作します。
■ Windowsランナーのセットアップ例
エンタープライズ環境でよく採用されるのがWindowsサーバ上でのセットアップです。
実際の設定手順はGitHub管理画面上に表示されたコマンドを順に実行する形です。
# ランナー用ディレクトリを作成
mkdir actions-runner && cd actions-runner
# ランナーパッケージをダウンロード
Invoke-WebRequest -Uri https://github.com/actions/runner/releases/download/v2.328.0/actions-runner-win-x64-2.328.0.zip -OutFile actions-runner.zip
# 展開
Expand-Archive -Path .\actions-runner.zip -DestinationPath .\
# GitHubリポジトリと紐づけ
./config.cmd --url https://github.com/OrgName/RepoName --token <登録トークン>
# 起動
./run.cmdこれで、社内のWindowsサーバ上に「GitHub Actions Runner」サービスが常駐し、ジョブがキューイングされるたびに自動で処理を受け取ります。
■ エンタープライズ導入時の注意点
- セキュリティ境界の明確化
社内ネットワーク内で実行されるため、アクセス制御（ACL）やプロキシ設定を明確に定めていく。 - スケーラビリティ設計
ジョブ数が増える場合は複数ランナーを分散配置し、ロードバランサやキューイングで制御。 - 更新とメンテナンス
ランナーバージョンは定期的に更新が必要。GitHub Actionsのリリースノートに合わせて自動アップデートスクリプトを整備するとよい。
■ まとめ
GitHub Actionsランナーは「どこでワークフローを実行するか」を決定する要素です。
GitHubホストランナーは“即時で利用可能なサーバ”で利便性重視であり
セルフホスティッドランナーは“制御型”で信頼性・セキュリティ重視。
エンタープライズ環境では、両者を併用して
「クラウドの柔軟性 × 社内インフラの堅牢性」を両立する構成が最も理想的です。