GitHub-Hosted vs Self-Hosted vs Managed Runners (2026)

GitHub Actions のジョブを実行する方法は3つあります。コスト、速度、そして自分がどれだけ基盤を保有するかがトレードオフになります。

すべての GitHub Actions ジョブはランナー上で実行されます。ランナーモデルの選択は、CI のコスト、速度、信頼性に対する最大のレバーです。3つの選択肢がどう比較されるかを見ていきます。

3つのモデル

	GitHub-hosted	Self-hosted	Managed (例: Latchkey)
分単価	最も高い	最も安い (生のコンピュート) + 運用時間	低い (hosted 比約70%減)
基盤の保守を自分で行う	いいえ	はい - スケーリング、パッチ、クリーンアップ	いいえ
コールドスタート / 速度	まあまあ	高速 (ウォームに保てば)	高速 (ウォームプール)
キャッシュ	基本のみ	自前対応	標準搭載
失敗の自己修復	なし	なし	あり (Latchkey)
適する用途	小規模/たまの CI	完全な制御、大規模	低コスト + 低運用

GitHub-hosted

セットアップ不要で、プレミアム料金の分単位課金。低ボリュームには最適ですが、規模が大きくなると高価で柔軟性に欠けます。

Self-hosted

自社マシン上でランナーエージェントを実行します。コンピュートは最安で完全な制御が得られますが、スケーリング、パッチ、クリーンアップ、ディスクフルや古くなったランナーの問題、そして長寿命の基盤に伴う信頼性の頭痛の種はすべて自分で担います。

マネージドランナー

プロバイダがフリートを運用してくれます。運用なしで self-hosted 並みの経済性が得られます。優れたものは信頼性機能を加えます。Latchkey は自己修復を加え、一時的な失敗が自動で回復します。

結論

小規模またはたまにしか動かないパイプラインには GitHub-hosted を使いましょう。完全な制御が欲しく運用チームがある場合にのみ self-hosted を選びましょう。運用負担なしに低コストを求め、不安定な失敗から自力で回復するパイプラインが欲しいほとんどのチームには、Latchkey のようなマネージドランナーが最適解です。