こんにちは！日々のCI/CDパイプラインの構築や、デプロイの自動化に奮闘していませんか？
「SaaS型のCircleCIは、ビルドが速くて設定もスマートで最高なんだけど、うちの会社はセキュリティポリシーが厳格だから、社内データベースやプライベートなVPCの中にあるサーバーへは直接アクセスさせられないんだよね……」
そんな悩みを抱えて、頭を抱えているエンジニアのあなたへ。実は、CircleCIの「セルフホストランナー（Self-hosted Runner）」を使えば、その悩みは一発で解決します。
クラウドの快適なオーケストレーション機能と、オンプレミス（または社内VPC）の鉄壁のセキュリティ。この2つをいいとこ取りする極上のアーキテクチャを、今回は初心者の方にもわかりやすく、優しく丁寧に紐解いていきます。
これをマスターすれば、厳格なセキュリティを維持したまま、モダンで爆速なCI/CDライフを手に入れることができますよ。さあ、一緒に扉を開けましょう！
—
1. なぜ「セルフホストランナー」が必要なのか？
まず、CircleCIの基本を少しだけおさらいしましょう。通常、CircleCIでビルドやテストを行うとき、コードはCircleCI社が管理するクラウド上の仮想マシン（これを「クラウドランナー」と呼びます）で実行されます。
これは非常に便利ですが、以下のような要件がある現場では壁にぶつかります。
- 「本番・ステージング環境へのデプロイは、社内VPCのプライベートサブネットからしか実行できない」
- 「ライセンスの関係で、ビルドに使う専用の巨大なオンプレミスサーバー（GPU搭載機など）を活用したい」
- 「機密データを扱うため、外部のクラウドワーカーにソースコードやビルド成果物を渡したくない」
ここで登場するのがセルフホストランナーです。
仕組みはシンプルで、「コントロールタワー（司令塔）はCircleCIのクラウド、実際に手を動かす実行部隊（ワーカー）は自社ネットワーク内のサーバー」という形に分業します。
[CircleCI クラウド (SaaS)]
│
│ (安全なアウトバウンド通信のみ)
▼
[社内VPC / オンプレミス環境]
└─ [セルフホストランナー (社内サーバー)]
├─ 内部DBへのマイグレーション実行
└─ 閉域網内のサーバーへデプロイ
CircleCIクラウドから社内へインバウンド（外部からの侵入）の穴を開ける必要はありません。社内サーバーからCircleCIへ外向きにコネクションを張る（アウトバウンド）だけなので、ファイアウォールやセキュリティポリシーの観点からも非常に安全な設計が可能です。
—
2. 導入の全体像と準備
今回は、Linux（Ubuntuなど）が稼働する社内サーバー（またはVPC内のEC2インスタンスなど）を想定して、セルフホストランナーをセットアップしていきます。
必要なステップは以下の3つです。
1. CircleCI上で「リソースクラス」の作成とトークンの発行
2. 社内サーバーへのランナー（Agent）のインストール
3. 「Hello World」的な動作確認パイプラインの実行
それでは、順番に優しく進めていきましょう。
—
3. ステップ1：CircleCIでの事前準備
まずは司令塔であるCircleCI側で、「うちの会社にはこういう名前のランナーを使う予定の専用レーンがあるよ」と登録します。
1. CircleCIのWebアプリにログインし、対象の組織（Organization）の設定を開く。
2. サイドメニューから 「Resource Classes（リソースクラス）」 を選択する。
3. 「Create Resource Class」 ボタンをクリック。
4. 名前空間とクラス名をドット区切りで入力します。命名規則は `組織名/カスタム名` です。
- 例: `my-company/secure-internal-runner`
5. 作成完了後、そのランナー専用の「ランナー・トークン（Auth Token）」が発行されるので、控えておきます（※このトークンは後で使うので大切に保管してください）。
—
4. ステップ2：社内サーバーへのインストールとセットアップ
いよいよ実行部隊である社内サーバーでの作業です。ターミナルを開いて、以下の手順を進めていきましょう。
今回は一般的なLinux環境を想定し、システム管理を安全に行うために専用のユーザー（`circleci`）を作成して実行させます。
① ユーザーとディレクトリの作成
circleci専用ユーザーとグループを作成
sudo useradd –system –create-home –home-dir /opt/circleci –shell /bin/bash circleci
ランナー用のバイナリ等を格納するディレクトリを作成
sudo mkdir -p /var/opt/circleci
sudo chown circleci:circleci /var/opt/circleci
② ランナーパッケージのダウンロードと配置
CircleCIが提供するランナーの公式エージェントを取得し、適切な場所に配置します。
ランナーのインストールスクリプトをダウンロードして実行（アーキテクチャに応じて自動判別されます）
curl -s https://raw.githubusercontent.com/CircleCI-Public/runner-installation-files/main/download-launch-agent.sh | sudo bash -s — –dir /var/opt/circleci
③ 設定ファイルの作成
ランナーがどのCircleCI組織に所属し、どのトークンを使うのかを教える設定ファイル（`launch-agent-config.yaml`）を作成します。
sudo nano /var/opt/circleci/launch-agent-config.yaml
ファイルの中に、以下の内容を記述します（ご自身の環境に合わせて書き換えてください）。
launch-agent-config.yaml
api:
# CircleCIのAPIエンドポイント（通常はこのままでOKです）
auth_token: “先ほどCircleCI上で発行されたトークンをここに貼り付けます”
resource_class: “my-company/secure-internal-runner”
ログ出力先やワークスペースの設定
runner:
# ジョブの作業ディレクトリ
working_directory: /var/opt/circleci/workdir
# キャッシュの保存先など
cleanup_working_directory: true
保存したら、セキュリティのためにファイル権限を絞り込み、所有者を変更します。
sudo chown circleci:circleci /var/opt/circleci/launch-agent-config.yaml
sudo chmod 600 /var/opt/circleci/launch-agent-config.yaml
④ Systemdを使った常駐化（デーモン化）
社内サーバーが再起動しても自動でランナーが立ち上がるように、Systemdに登録します。
sudo nano /etc/systemd/system/circleci-runner.service
以下の内容を書き込みます。
[Unit]
Description=CircleCI Runner
After=network.target
[Service]
User=circleci
Group=circleci
ExecStart=/var/opt/circleci/launch-agent –config /var/opt/circleci/launch-agent-config.yaml
Restart=always
RestartSec=10
KillMode=process
TimeoutSec=infinity
[Install]
WantedBy=multi-user.target
サービスを有効化し、起動しましょう！
Systemdの再読込
sudo systemctl daemon-reload
サービスの有効化と起動
sudo systemctl enable circleci-runner
sudo systemctl start circleci-runner
状態の確認
sudo systemctl status circleci-runner
ステータスが `active (running)` になっていれば大成功です！これで社内サーバーがCircleCIクラウドとセキュアに接続されました。
—
5. ステップ3：精度高い「Hello World」動作確認
ランナーが無事に動いているか、実際にCircleCIのパイプライン（`.circleci/config.yml`）を書いてテストしてみましょう。
リポジトリのルートに `.circleci/config.yml` を作成し、以下のように記述します。
version: 2.1
jobs:
secure-hello:
# ここがポイント！先ほど作成したセルフホストランナーのリソースクラスを指定します
resource_class: my-company/secure-internal-runner
# セルフホストランナーは通常Linux環境なので、docker executorではなく machine または
# セルフホストランナー固有の実行コンテキストを使います（※今回はランナー本体が直接実行します）
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: 社内ネットワークからの接続テスト
command: |
echo “こんにちは！CircleCIクラウドから、社内サーバーへ安全に接続されました！”
echo “このビルドを実行しているホスト名:”
hostname
echo “内部IPアドレスの確認:”
hostname -I
- run:
name: 閉域網内のリソースにアクセスするシミュレーション
command: |
# 例: 社内DBやプライベートAPIへの疎通確認コマンドなどをここに書けます
echo “Internal DB Migration Simulation: SUCCESS”
workflows:
version: 2
hello-workflow:
jobs:
- secure-hello
この設定ファイルをコミットしてGitHub等にプッシュし、CircleCIでパイプラインを走らせてみてください。
数秒後、CircleCIの画面上でジョブが「クラウド」ではなく、「あなたの社内サーバー（セルフホストランナー）」の上で実行され、見事に成功している緑色のチェックマークを確認できるはずです！
—
6. 現場で役立つハック＆まとめ
お疲れ様でした！これで、SaaSの便利さを享受しながら、企業の厳格なセキュリティ要件をも満たす「セルフホストランナー環境」が手に入りました。
最後に、現場のプロとして知っておいてほしい「実践的な知見」をいくつか授けておきます。
- オートスケーリングの活用:
今回は1台のサーバーで手動構築しましたが、AWS環境であれば「Auto Scaling Group + UserDataによる自動ランナー登録」を組み合わせることで、ビルド量に応じてセルフホストランナーを自動増減させることも可能です。
- セキュリティの担保:
ランナーが動作するサーバーには、デプロイに必要な最小限の権限（IAMロールやSSH鍵、DBのアクセス権など）だけを持たせるようにしましょう。クラウド側にクレデンシャルを置く必要がなくなるため、セキュリティリスクが劇的に低下します。
これをマスターすれば、どんなにセキュリティがうるさい大企業の案件や、社内クローズドなシステム開発であっても、迷うことなくモダンなCI/CD環境を提案・構築できるようになります。
毎日のデプロイ作業が、安全で、そして劇的に楽しくなりますように。あなたのエンジニアライフを応援しています！