更新日:2026年8月27日
4分で読めます
GitLabがお客様のGitLab Dedicatedリージョン内で、ホストされるRunnerのプロビジョニング、パッチ適用、スケーリングを担います。Runnerの保守運用をプラットフォームチームの手から切り離せます。

多くの企業がGitLab Dedicatedを選ぶ理由は明快です。セキュアでコンプライアンス要件を満たす単一テナントのGitLabインスタンスを、GitLab自身が運用する。この一点に尽きます。一方で、エージェント型のワークフローがパイプラインの実行量を押し上げるなかで、完全なデータ分離とRunnerインフラの運用負荷が新たな課題として浮上してきました。そこで生まれるのが、「Runnerフリートを自社で保有し続ける意味は、まだあるのか」という問いです。
GitLab Dedicatedであれば、Runnerフリートのプロビジョニング、パッチ適用、構築、スケーリングを自社で担う必要はもうありません。重い作業はGitLab Dedicated用のホストされるRunnerが引き受け、ソフトウェア開発ライフサイクル全体を通じてシームレスな体験を届けます。チームが向き合うのは、プロダクトを届けることだけです。
GitLab Dedicated用のホストされるRunnerは、他のお客様から完全に分離されたRunnerフリートを提供します。ジョブレベルのセキュリティを確保するため、各ジョブは新規にプロビジョニングされた独立した仮想マシン(VM)上で実行され、ジョブの完了とともにそのVMは削除されます。急激に増減するCI需要やレジリエンシー要件にも耐えられるよう、スケーラブルで信頼性の高いRunnerフリートをご用意しました。Runnerの作成と管理は、GitLab Dedicatedの管理コンソールであるスイッチボードからセルフサービスで行えます。
パイプラインの負荷は読みきれないものです。これに備えてRunnerインフラを過剰にプロビジョニングしておけば、待機時間を短く保ち、デベロッパーに最良の体験を届けられます。ただし、その代償として膨らむのがインフラコストです。逆にプロビジョニングを絞ればコストは抑えられるものの、今度はデベロッパーがCIジョブの実行開始をひたすら待つ羽目になります。そしてこのバランスの微調整に、プラットフォームチームの時間が丸ごと吸い取られていく。よくある光景です。
GitLab Dedicated用のホストされるRunnerは、フルマネージドのCI実行SaaSです。高いパフォーマンスと信頼性を備えたRunnerインフラが、その土台を支えています。主なメリットは次のとおりです。
GitLab Dedicated用のホストされるRunnerの実際の動作をご覧ください。
GitLab Dedicated用のホストされるRunnerはLinux x86-64およびLinux Arm64アーキテクチャに対応しており、次のマシンサイズからお選びいただけます。
| サイズ | vCPU数 | メモリ | ストレージ | タグの例(x86-64) |
|---|---|---|---|---|
| Small | 2 | 8 GB | 30 GB | linux-small-amd64(デフォルト) |
| Medium | 4 | 16 GB | 50 GB | linux-medium-amd64 |
| Large | 8 | 32 GB | 100 GB | linux-large-amd64 |
| X-Large | 16 | 64 GB | 200 GB | linux-xlarge-amd64 |
| 2X-Large | 32 | 128 GB | 200 GB | linux-2xlarge-amd64 |
GitLab Dedicated用のホストされるRunnerは、GitLab Dedicatedのアドオンとして提供されます。ご利用をご検討の際は、担当のGitLab営業チームまでお問い合わせください。
GitLab Dedicatedがコンプライアンス体制をどのように支えるのか、さらに詳しく知りたい方は、こちらからお気軽にご相談ください。
同じGitLab Dedicatedの境界内で推論まで完結させたい場合は、関連記事「GitLab Dedicated向けAIゲートウェイを提供開始:AI処理を自社テナント内で完結」をご覧ください。
無料の
30日間のGitLabトライアルを開始
クレジットカードなしでご登録いただけます。
このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。
フィードバックを共有する