2026.11.12 開発

GitLabとは：構成要素・CEとEEの違い・3つの提供形態とDockerで試す手順【2026年11月】

GitLabとは、Gitリポジトリの管理を中心に、課題管理（Issue）、コードレビュー（マージリクエスト）、CI/CD、コンテナレジストリまでを1つのアプリケーションで扱う開発プラットフォームです。本記事では、GitLabの中で動いている構成要素の役割、MITライセンスのCEとEEの違い、GitLab.com・Self-Managed・Dedicatedという3つの提供形態を、公式ドキュメントの該当箇所へのリンクつきで解説します。後半ではdocker composeで手元に起動して版を確かめる手順と、Self-Managedを採用する条件・見送る場面を示します。版や料金は2026年11月12日時点の公式情報です。

まとめ：GitLabとはGitを核に計画からCI/CDまでを1か所で回す開発基盤

GitLabは「Gitのホスティングサービス」として知られていますが、実体はIssue・マージリクエスト・CI/CD・パッケージ管理を同じプロジェクトの中でつなぐWebアプリケーションです。Issue番号がブランチ、マージリクエスト、パイプラインまで自動でひもづくため、依頼から本番反映までを1画面でたどれます。ブランチをどう分けて本番まで流すかの型は、GitLab Flowとは：環境ブランチの組み方とGit Flow・GitHub Flowとの違いで扱っています。

使い方は3通りあります。GitLab社がホストするGitLab.com、自社サーバーに入れるSelf-Managed、GitLab社が顧客専用に運用するDedicatedです。ソフトウェアはMITライセンスのCE（Community Edition）と、有料機能を後から有効化できるEE（Enterprise Edition）に分かれます。

迷ったらGitLab.comのFreeで始めてください。Self-Managedは毎月のマイナー版更新と、8 vCPU・16GBを基準とするサーバーの運用を引き受けられる場合に限って選びます。

GitLabとは何か：Gitリポジトリ管理から広がった開発プラットフォームの範囲

GitLabの定義と読み方、GitHubと同じGitを土台にする位置づけ

GitLabの読み方は「ギットラボ」で、「ギットラブ」と呼ぶ人もいます。開発元は米GitLab Inc.で、ソースコードの公開先もGitLab自身の上です。GitLab FOSSのリポジトリは、本体のコードから有料機能のコードを除いた読み取り専用のミラーで、MIT Licenseと明記されています。

Gitそのものは分散型のバージョン管理ツールで、GitLabやGitHubはその置き場所に機能を足したサービスです。GitHubとの機能・料金・CIの書き方の違いはGitHubとGitLabの違いとActions・GitLab CIの対応表で比較しているので、本記事ではGitLab単体の中身に絞ります。

1つのプロジェクトで扱える機能をIssue・MR・CI/CD・レジストリで整理

GitLabのプロジェクトを1つ作ると、次の機能が最初から同じ画面に並びます。どれも別製品として契約する必要はありません。

開発の工程	GitLabの機能	Freeで使えるか
計画	Issue・ラベル・マイルストーン・ボード	使える
コード管理	Gitリポジトリ・保護ブランチ	使える
レビュー	マージリクエスト（MR）	使える（承認の必須化はPremium以上）
ビルド・テスト	CI/CDパイプライン・Runner	使える（GitLab.comは月400分）
配布	コンテナレジストリ・パッケージレジストリ	使える
AI支援	GitLab Duo	アドオン購入が必要

表の上から順に使い始めるのが自然な流れで、実際の操作はGitLabの使い方（プロジェクト作成からIssue・MR・CI/CDまで）で手順化しています。CI/CDのジョブで静的サイトを公開する機能はGitLab Pagesとは：.gitlab-ci.ymlでの公開手順とGitHub Pagesとの違いで扱っています。AI機能のGitLab Duoは課金の仕組みが別立てで、GitLab Duo Agent Platformの料金とGitLab Creditsの見積もりに詳細があります。Claude CodeやCursorなど外部のAIツールからGitLabを操作する場合は、GitLab MCPサーバーの接続設定：Claude Code・Cursorでの使い方とツール一覧を参照してください。

GitLab構成要素：Rails・Gitaly・Sidekiq・Runnerの役割

WebとAPIを受けるPumaとWorkhorse、Git操作を担うGitalyの分担

GitLabの中身を構成要素で見ると、1つのプログラムではなく、役割の違う複数のサービスが集まった構造だと分かります。GitLabのアーキテクチャ文書では、ブラウザやAPIからのリクエストを受けるのがPuma（Ruby on RailsのGitLab本体）、その手前で大きなHTTPリクエストを処理する「賢いリバースプロキシ」がWorkhorse、GitLabからのGit操作をすべて引き受けるRPCサービスがGitalyと説明されています。

リポジトリのファイルに直接触るのはGitalyだけです。画面でファイルを開くときも、Pumaはディスクを読まずにGitalyへ問い合わせます。SSHでのgit pushはGitLab Shellが受け、こちらもGitalyに処理を渡します。リポジトリが巨大でGitLabが重いとき、まずGitalyのディスクI/Oを疑うのはこの構造があるからです。

PostgreSQLとRedisとSidekiqがIssueや通知の裏で処理する内容

Issue・MR・ユーザー・権限といったGit以外のデータはPostgreSQLに入ります。インストール要件によると、サポートするデータベースはPostgreSQLだけで、GitLab 19.x系が対応するのはPostgreSQL 17.x〜18.xです。18.x系が対応するのはPostgreSQL 16.5〜17.xなので、PostgreSQL 16で動かしているSelf-Managedは、19.x系へ上げる前にデータベースの版上げを済ませる必要があります。

Redisはキャッシュとジョブの待ち行列、Sidekiqはバックグラウンドジョブの処理役です。メール通知、MRの差分計算、プロジェクトのインポートなど、画面の応答を待たせたくない処理はSidekiqに回ります。「MRを作ったのに差分がしばらく出ない」という現象は、たいていSidekiqの処理待ちです。

CIジョブを動かすGitLab Runnerを本体と別にインストールする理由

GitLab Runnerのドキュメントの定義は「GitLab CI/CDと連携してパイプラインのジョブを実行するアプリケーション」です。Linuxパッケージに同梱されるのはPuma・Workhorse・Gitaly・Sidekiq・PostgreSQL・Redis・GitLab Shell・NGINXで、Runnerは含まれず手動でインストールします。

分かれているのは、ビルドやテストの負荷をGitLab本体のサーバーに載せないためです。Runnerは別のマシンやKubernetes上に置き、実行方式（executor）をDocker・Shell・Kubernetesなどから選びます。GitLab.comでは共有Runnerが用意されているので、自前で立てる必要が出るのはSelf-Managedのときか、社内ネットワークの中でジョブを動かしたいときです。自前Runnerの登録手順とexecutorの選び方はGitLab Runnerとは：executorの選び方と登録手順で扱っています。

GitLab.com・Self-Managed・Dedicatedの提供形態とエディション

GitLab.com・Self-Managed・Dedicatedの3形態と運用責任

GitLabの提供形態とエディションは別の区分です。同じGitLabでも、誰がサーバーを持ち、誰が更新するかで3つの提供形態に分かれます。GitLab Dedicatedのドキュメントでは、Dedicatedを「GitLabがホストと保守を行うシングルテナントのSaaS」で、顧客が選んだAWSリージョンに置かれ、Ultimateプランが前提と定義しています。

形態	サーバーの所有	更新作業	向く組織
GitLab.com	GitLab社（共有）	GitLab社	まず試したい、保守要員がいない
Self-Managed	自社	自社	閉域網・社内サーバーにコードを置く規程がある
Dedicated	GitLab社（顧客専用）	GitLab社	専有環境が要るがサーバー運用はしたくない

Self-Managedを選ぶと、更新の責任が自社に移ります。リリースと保守のポリシーでは、マイナー版は毎月第3木曜に出て、2026年11月12日時点の保守対象は19.5（不具合とセキュリティ修正）、19.4と19.3（セキュリティ修正のみ）です。次の19.6は11月19日の予定で、出た時点で19.3は保守対象から外れます。

MITライセンスのCEと有料機能を後から有効化できるEEの違い

Self-Managedで入れるソフトウェアには、CE（Community Edition）とEE（Enterprise Edition）の2種類があります。CEは有料機能のコードを含まないMITライセンス版、EEは有料機能のコードを含む版です。EEもライセンスを登録しなければFreeの機能だけで動きます。

GitLab Community Editionの公式ページは、CEから有料機能へ移るには先にパッケージの変換が必要で、将来有料機能を試す予定があるなら新規導入はEEを推奨すると書いています。Freeの範囲でも使えるRegistration Features（一部の有料機能の無償開放）はEEだけが対象です。社内規程でMIT以外のライセンスを入れられない場合を除けば、EEで入れておくのが無難な選択です。

Free・Premium・Ultimateの違いは5ユーザー上限と月400分から見る

エディションとは別に、利用できる機能の範囲は契約するプランによって決まります。GitLabの料金ページによると、GitLab.comのFreeは「トップレベルグループあたり5ユーザー」「CI計算分数月400分」「ストレージ10GiB」が上限です。Premiumは1ユーザー月29ドル（年払い）で計算分数は月10,000分、Ultimateは個別見積もりで月50,000分です。

プラン選びで最初に効いてくるのは人数です。6人目を招待した時点でGitLab.comのFreeは使えなくなるため、5人を超えるチームはPremiumの費用を前提に比較してください。他のCI/CDサービスの無料枠と並べた比較はCI/CDツール比較の無料枠と料金にまとめています。

GitLabをDockerで試す手順：Self-Managedの起動から版の確認まで

docker composeでGitLab CEを起動する設定ファイルと必要なメモリ

Self-Managedの中身を確かめるなら、Dockerで1台立てるのが手軽です。Docker版のインストール手順の設定をもとに、検証用にCEイメージを使い、ホストのSSHと衝突しないようGitのSSHポートを2222へずらしたのが次の例です。ポートの変え方はDocker版の設定ドキュメントにあるgitlab_shell_ssh_portの例に沿っています。

# 事前準備：データを置くディレクトリを作り、環境変数に入れる
sudo mkdir -p /srv/gitlab
export GITLAB_HOME=/srv/gitlab

# docker-compose.yml（<version> は 19.5.3 のように保守対象の版を入れる）
services:
  gitlab:
    image: gitlab/gitlab-ce:<version>-ce.0
    container_name: gitlab
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2222
    ports:
      - '80:80'
      - '443:443'
      - '2222:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

# 同じディレクトリで起動する
docker compose up -d

EEで試すときは、イメージ名をgitlab/gitlab-ee:<version>-ee.0に変えます。インストール要件ではシングルノードの基準が8 vCPU・16GBで、メモリが限られる環境でも最低8GBが必要です。ノートPCで動かすならDocker Desktopに割り当てるメモリを先に8GB以上へ上げておかないと、起動途中でコンテナが落ちます。HTTPS化・バックアップと復元・版を固定した更新まで含めた本番運用の手順は、GitLabオンプレ構築：Docker Composeで本番運用する手順で扱っています。

初期rootパスワードの取り出しとgitlab-ctlで各サービスの状態確認

初回の起動には数分かかります。ブラウザでログイン画面が出たら、ユーザー名rootと、コンテナ内に生成された初期パスワードでログインします。

# 初期 root パスワードを表示する
sudo docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

# 構成要素ごとの稼働状態を一覧する（puma・sidekiq・gitaly・postgresql・redis など）
sudo docker exec -it gitlab gitlab-ctl status

# 設定や接続を一括で点検する Rake タスク
sudo docker exec -it gitlab gitlab-rake gitlab:check

初期パスワードのファイルは、24時間経過後の最初のコンテナ再起動で自動的に消えます。ログインしたらすぐにrootのパスワードを変更してください。Linuxパッケージの保守コマンドにあるとおり、gitlab-ctl statusは前の章で触れた構成要素がそれぞれ動いているかを稼働秒数つきで返すので、構成を目で確かめる教材にもなります。

APIのmetadataエンドポイントでバージョンとEEかどうかを確かめる

動いているGitLabの版とエディションは、画面のヘルプからも見られますが、APIで取ると監視や棚卸しのスクリプトに組み込めます。Metadata APIのドキュメントのリクエストは次の形です。

# アクセストークンは「ユーザー設定 ＞ Access tokens」で read_api スコープつきで発行する
curl --request GET \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "http://gitlab.example.com/api/v4/metadata"

応答のJSONには、版を示すversion、ビルドのリビジョンを示すrevision、Kubernetes連携用エージェントの情報kas、EEかどうかを示すenterpriseが入ります。複数のSelf-Managedを抱える組織なら、この値を定期的に集めて保守対象外の版が残っていないかを見るだけで、更新漏れを早く見つけられます。

GitLabを選ぶ判断：Self-Managedを採用する条件と見送るべき場面

GitLabを採用するのは閉域網の要件か開発工程を1か所にまとめたい場合

GitLabを選ぶ理由がはっきりしているのは2つの場合です。1つは、Issue・レビュー・CIを別々のSaaSで契約していて、連携設定の保守に手間を取られている場合です。GitLabならIssue番号からパイプラインの結果まで1つのプロジェクトでたどれます。

もう1つは、ソースコードを社外のSaaSに置けない規程がある場合です。Self-Managedなら閉域網の中にGitLabとRunnerを置けます。サーバーを持たずに専有環境だけが欲しいなら、Ultimate前提のDedicatedも候補に入ります。

逆に、開発をGitHubで回していて不満がないチームが、機能の多さだけを理由に移る必要はありません。軽いGitサーバーだけが目的なら、GitBucketをDockerで構築する手順のような小さな選択肢のほうがサーバー資源を食いません。

保守担当がいないSelf-Managedと5人超のFree運用は見送る

次のどれかに当てはまるなら、その形での導入はいったん止めます。

Self-Managedを入れたいが、毎月の更新と緊急パッチを当てる担当者を決められない
開発メンバーが6人以上いるのに、GitLab.comのFreeで運用しようとしている
8 vCPU・16GBのサーバーを用意できず、4GB程度の仮想マシンで動かそうとしている

いちばん危ないのは1つ目です。保守対象は直近3つのマイナー版だけなので、3か月更新を止めるとセキュリティ修正すら届かない版になります。緊急の修正が出たときの判断はGitLab脆弱性の対応手順と修正版の判断基準、古い版からの段階的な上げ方はGitLab 18.10から19.4・19.5への移行経路で扱っています。更新やRunnerの構築まで社内で回せない場合は、GitLab.comへ寄せるか、一創のDevOps・CI/CD導入支援のように開発基盤の構築と保守を外部に任せる形を検討してください。CI/CDの考え方から整理したい場合はCI/CDの仕組みとパイプライン構成が入口になります。

よくある質問

GitLabとは何かを調べている方から多い質問に、2026年11月時点の公式情報をもとに回答します。

GitLabの読み方は何ですか？

日本では「ギットラボ」と読むのが一般的で、「ギットラブ」と読む人もいます。開発元は米GitLab Inc.で、製品名・社名とも英字表記はGitLabです。社内の資料ではどちらで書いても通じますが、検索や公式ドキュメントでは英字のGitLabで調べると情報が見つかりやすくなります。

GitLabは無料で使えますか？

無料で使えます。GitLab.comのFreeプランはクレジットカード不要で、Issue・マージリクエスト・CI/CDなどの基本機能が使えます。上限はトップレベルグループあたり5ユーザー、CIの計算分数が月400分、ストレージ10GiBです。Self-ManagedのCEもMITライセンスで無償ですが、サーバー代と更新作業の人件費は自社で負担します。

GitLabとGitHubの違いは何ですか？

どちらもGitのリポジトリを置くサービスですが、GitLabはIssue・レビュー・CI/CD・レジストリを1つのアプリケーションに統合している点と、CEをMITライセンスで自社サーバーに入れられる点が大きな違いです。GitHubはOSSの集まる場所としての強さと、Marketplaceの連携の多さが特徴です。料金やCIの書き方の違いは比較記事で詳しく扱っています。

GitLabのCEとEEはどちらを入れればよいですか？

将来有料機能を使う可能性が少しでもあるならEEを入れてください。EEはライセンスを登録しなければFreeの機能で動き、有料プランを契約したらアクティベーションコードを入れるだけで機能が有効になります。CEから有料機能へ移るにはパッケージの変換作業が必要です。社内規程でMITライセンスのソフトウェアしか入れられない場合はCEを選びます。

GitLabのSelf-Managedにはどのくらいのサーバーが必要ですか？

公式のインストール要件では、1台構成の基準が8 vCPU・メモリ16GBです。メモリが限られる環境でも最低8GBが必要とされています。データベースはPostgreSQLのみ対応で、19.x系ならPostgreSQL 17.x〜18.xを使います。利用者が数百人を超える規模では、公式のサイジングガイドに沿って複数台構成を検討してください。