# CI Runnerとは? Managed対Self-Hostedを解説

> CI runnerとは、パイプラインのjobを実行するマシンのことです。runnerの仕組み、hosted・self-hosted・managed runnerの違い、そしてコストがどこから生じるのかを学びましょう。

Source: https://latchkey.dev/ja/learn/ci-cd-concepts/what-is-a-ci-runner  
Updated: 2026-06-25

runnerとは、単にCIのjobを実行するコンピュータのことです。選ぶ種類によって、パイプラインの速度、信頼性、コストが決まります。

継続的インテグレーションには、実際に作業を実行する場所 - checkout、build、テスト、deploy - が必要です。そのマシンが「runner」です。runnerはキューに入ったjobを取り上げ、各ステップを実行し、ステータスを報告し、(通常は)その後破棄されます。

## hosted runner

CIプロバイダがオンデマンドでエフェメラルなVMを提供します。簡単でメンテナンスが不要ですが、分単位で課金され、マシンサイズは固定で、毎回cold startから始まります。重いbuildや特殊なbuildは遅かったり高価だったりします。

## self-hosted runner

自分のマシン上でrunnerエージェントを動かします。サイズ、ツール、cacheをコントロールでき、スケール時には安くなることもあります - しかしパッチ適用、スケーリング、クリーンアップ、そして長期稼働のインフラに伴う信頼性の問題(ディスクが一杯になる、runnerが古くなる)は自分の責任になります。

## managed runner

managed runnerプラットフォームは、フリートを自分で運用することなく、self-hostedスタイルのコントロールと経済性をもたらします。プロバイダがプロビジョニング、スケーリング、cache、クリーンアップを処理します。最良のものはその上に信頼性機能を追加します - 例えば、一時的な失敗やリソース失敗から自動的に回復し、不安定なjobがbuildを失敗させないようにします。

## コストがどこから生じるか

- jobが実行されている間(一部の構成ではキュー中も)課金される分。
- すべてのjobを膨らませるcold startと遅い依存関係のインストール。
- 一時的な失敗によって引き起こされるre-run - 同じjobに二度支払う。
- 「念のため」使われる過大なrunner。

## FAQ

### What is What is a CI Runner? managed vs Self-Hosted explained?

Continuous integration needs somewhere to actually execute the work - checkout, build, test, deploy. That machine is the "runner". It picks up a queued job, runs each step, reports status back, and (usually) is torn down afterward.

### Hosted runners?

Your CI provider supplies ephemeral VMs on demand. They are easy and require zero maintenance, but you pay per minute, have fixed machine sizes, and start cold each time. Heavy or specialized builds can be slow or expensive.

### Self-hosted runners?

You run the runner agent on your own machines. You control the size, tools, and caching, and can be cheaper at scale - but you own patching, scaling, cleanup, and the reliability problems (disk fills up, runners go stale) that come with long-lived infrastructure.

### Managed runners?

A managed runner platform gives you self-hosted-style control and economics without operating the fleet yourself. The provider handles provisioning, scaling, caching, and cleanup. The best ones add reliability features on top - for example, automatically recovering from transient and resource failures so flaky jobs do not fail your build.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt