--- title: "GitLabとは：構成要素・CEとEEの違い・3つの提供形態とDockerで試す手順【2026年11月】" url: "https://www.issoh.co.jp/tech/details/19631/" published: 2026-11-12 updated: 2026-11-12 categories: ["開発"] publisher: "株式会社一創" --- # 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との違い](https://www.issoh.co.jp/tech/details/19637/)で扱っています。 使い方は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のリポジトリ](https://gitlab.com/gitlab-org/gitlab-foss)は、本体のコードから有料機能のコードを除いた読み取り専用のミラーで、MIT Licenseと明記されています。 Gitそのものは分散型のバージョン管理ツールで、GitLabやGitHubはその置き場所に機能を足したサービスです。GitHubとの機能・料金・CIの書き方の違いは[GitHubとGitLabの違いとActions・GitLab CIの対応表](https://www.issoh.co.jp/tech/details/4219/)で比較しているので、本記事では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まで）](https://www.issoh.co.jp/tech/details/18874/)で手順化しています。CI/CDのジョブで静的サイトを公開する機能は[GitLab Pagesとは：.gitlab-ci.ymlでの公開手順とGitHub Pagesとの違い](https://www.issoh.co.jp/tech/details/19639/)で扱っています。AI機能のGitLab Duoは課金の仕組みが別立てで、[GitLab Duo Agent Platformの料金とGitLab Creditsの見積もり](https://www.issoh.co.jp/tech/details/10660/)に詳細があります。Claude CodeやCursorなど外部のAIツールからGitLabを操作する場合は、[GitLab MCPサーバーの接続設定：Claude Code・Cursorでの使い方とツール一覧](https://www.issoh.co.jp/tech/details/19635/)を参照してください。 ## GitLab構成要素：Rails・Gitaly・Sidekiq・Runnerの役割 ### WebとAPIを受けるPumaとWorkhorse、Git操作を担うGitalyの分担 GitLabの中身を構成要素で見ると、1つのプログラムではなく、役割の違う複数のサービスが集まった構造だと分かります。[GitLabのアーキテクチャ文書](https://docs.gitlab.com/development/architecture/)では、ブラウザや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に入ります。[インストール要件](https://docs.gitlab.com/install/requirements/)によると、サポートするデータベースは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のドキュメント](https://docs.gitlab.com/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の選び方と登録手順](https://www.issoh.co.jp/tech/details/19633/)で扱っています。 ## GitLab.com・Self-Managed・Dedicatedの提供形態とエディション ### GitLab.com・Self-Managed・Dedicatedの3形態と運用責任 GitLabの提供形態とエディションは別の区分です。同じGitLabでも、誰がサーバーを持ち、誰が更新するかで3つの提供形態に分かれます。[GitLab Dedicatedのドキュメント](https://docs.gitlab.com/subscriptions/gitlab%5Fdedicated/)では、Dedicatedを「GitLabがホストと保守を行うシングルテナントのSaaS」で、顧客が選んだAWSリージョンに置かれ、Ultimateプランが前提と定義しています。 | 形態 | サーバーの所有 | 更新作業 | 向く組織 | | ------------ | ------------- | ------- | ---------------------- | | GitLab.com | GitLab社（共有） | GitLab社 | まず試したい、保守要員がいない | | Self-Managed | 自社 | 自社 | 閉域網・社内サーバーにコードを置く規程がある | | Dedicated | GitLab社（顧客専用） | GitLab社 | 専有環境が要るがサーバー運用はしたくない | Self-Managedを選ぶと、更新の責任が自社に移ります。[リリースと保守のポリシー](https://docs.gitlab.com/policy/maintenance/)では、マイナー版は毎月第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の公式ページ](https://about.gitlab.com/gitlab-community-edition/)は、CEから有料機能へ移るには先にパッケージの変換が必要で、将来有料機能を試す予定があるなら新規導入はEEを推奨すると書いています。Freeの範囲でも使えるRegistration Features（一部の有料機能の無償開放）はEEだけが対象です。社内規程でMIT以外のライセンスを入れられない場合を除けば、EEで入れておくのが無難な選択です。 ### Free・Premium・Ultimateの違いは5ユーザー上限と月400分から見る エディションとは別に、利用できる機能の範囲は契約するプランによって決まります。[GitLabの料金ページ](https://about.gitlab.com/pricing/)によると、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ツール比較の無料枠と料金](https://www.issoh.co.jp/tech/details/1834/)にまとめています。 ## GitLabをDockerで試す手順：Self-Managedの起動から版の確認まで ### docker composeでGitLab CEを起動する設定ファイルと必要なメモリ Self-Managedの中身を確かめるなら、Dockerで1台立てるのが手軽です。[Docker版のインストール手順](https://docs.gitlab.com/install/docker/installation/)の設定をもとに、検証用にCEイメージを使い、ホストのSSHと衝突しないようGitのSSHポートを2222へずらしたのが次の例です。ポートの変え方は[Docker版の設定ドキュメント](https://docs.gitlab.com/install/docker/configuration/)にある`gitlab_shell_ssh_port`の例に沿っています。 ``` # 事前準備：データを置くディレクトリを作り、環境変数に入れる sudo mkdir -p /srv/gitlab export GITLAB_HOME=/srv/gitlab # docker-compose.yml（ は 19.5.3 のように保守対象の版を入れる） services: gitlab: image: gitlab/gitlab-ce:-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:-ee.0`に変えます。インストール要件ではシングルノードの基準が8 vCPU・16GBで、メモリが限られる環境でも最低8GBが必要です。ノートPCで動かすならDocker Desktopに割り当てるメモリを先に8GB以上へ上げておかないと、起動途中でコンテナが落ちます。HTTPS化・バックアップと復元・版を固定した更新まで含めた本番運用の手順は、[GitLabオンプレ構築：Docker Composeで本番運用する手順](https://www.issoh.co.jp/tech/details/19667/)で扱っています。 ### 初期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パッケージの保守コマンド](https://docs.gitlab.com/omnibus/maintenance/)にあるとおり、`gitlab-ctl status`は前の章で触れた構成要素がそれぞれ動いているかを稼働秒数つきで返すので、構成を目で確かめる教材にもなります。 ### APIのmetadataエンドポイントでバージョンとEEかどうかを確かめる 動いているGitLabの版とエディションは、画面のヘルプからも見られますが、APIで取ると監視や棚卸しのスクリプトに組み込めます。[Metadata APIのドキュメント](https://docs.gitlab.com/api/metadata/)のリクエストは次の形です。 ``` # アクセストークンは「ユーザー設定 ＞ Access tokens」で read_api スコープつきで発行する curl --request GET \ --header "PRIVATE-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で構築する手順](https://www.issoh.co.jp/tech/details/3808/)のような小さな選択肢のほうがサーバー資源を食いません。 ### 保守担当がいないSelf-Managedと5人超のFree運用は見送る 次のどれかに当てはまるなら、その形での導入はいったん止めます。 - Self-Managedを入れたいが、毎月の更新と緊急パッチを当てる担当者を決められない - 開発メンバーが6人以上いるのに、GitLab.comのFreeで運用しようとしている - 8 vCPU・16GBのサーバーを用意できず、4GB程度の仮想マシンで動かそうとしている いちばん危ないのは1つ目です。保守対象は直近3つのマイナー版だけなので、3か月更新を止めるとセキュリティ修正すら届かない版になります。緊急の修正が出たときの判断は[GitLab脆弱性の対応手順と修正版の判断基準](https://www.issoh.co.jp/tech/details/18332/)、古い版からの段階的な上げ方は[GitLab 18.10から19.4・19.5への移行経路](https://www.issoh.co.jp/tech/details/11561/)で扱っています。更新やRunnerの構築まで社内で回せない場合は、GitLab.comへ寄せるか、一創の[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)のように開発基盤の構築と保守を外部に任せる形を検討してください。CI/CDの考え方から整理したい場合は[CI/CDの仕組みとパイプライン構成](https://www.issoh.co.jp/column/details/13002/)が入口になります。 ## よくある質問 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を使います。利用者が数百人を超える規模では、公式のサイジングガイドに沿って複数台構成を検討してください。 ## 関連記事 - [GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較](https://www.issoh.co.jp/tech/details/4219/)：GitLabとGitHubのどちらを選ぶかを機能・料金・CIの書き方で比べられます - [GitLabの使い方：プロジェクト作成からIssue・MR・CI/CDまでの手順【2026年10月】](https://www.issoh.co.jp/tech/details/18874/)：GitLabを触り始めたら最初の1周をこの手順でたどれます - [GitLab 19.2とは？Duo CLI・カスタムフローGAで変わる開発運用](https://www.issoh.co.jp/tech/details/15769/)：最近のマイナー版で増えた機能の例を確認できます - [PR-AgentをGitLabで使う手順｜CI・Webhook・Lambdaの設定と自動レビューの制御【v0.49対応】](https://www.issoh.co.jp/tech/details/2575/)：マージリクエストのレビューをAIで補う構成を扱います - [CI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】](https://www.issoh.co.jp/tech/details/1834/)：GitLab CI以外のCI/CDサービスと無料枠を比較できます --- 出典: [GitLabとは：構成要素・CEとEEの違い・3つの提供形態とDockerで試す手順【2026年11月】]()（株式会社一創）