GitLabの使い方：無料の範囲、CI/CD、GitHubからの移行

公開 2026年11月7日更新 2026年11月8日書いた人大林諒

取引先や開発会社から「GitLabで管理しています」と言われて、GitHubと何が違うのか分からないまま招待を受けることがあります。GitLabは読み方も仕組みも、知ってしまえば難しくありません。

ここでは、サンプル料理教室のホームページを例に、GitLabでプロジェクトを作り、人を招待し、変更を確かめて取り込み、自動チェックを動かすまでを順に書きます。後半で、自社サーバーに置く話と、GitHubから移す手順、移さない判断も扱います。

この記事の内容

先に答えると
GitLabとは：GitHubとの対応で読む
無料の範囲
Group と Project を作る
メンバーの招待とロール
Merge Requestの流れ
CI/CDの最小の例
Self-Managed：自社サーバーに置く話
GitHubからの移行
GitHubに残る判断
できないことと、その代わり
よく詰まるところ
次に読む

先に答えると

GitLab（ギットラボ）は、Gitの履歴を置いて共同作業するサービスで、GitHubと同じ種類のものです。GitHubを知っているなら、名前の対応を覚えれば使えます。無料で始められますが、非公開で6人以上になると読み取り専用になる点が、小さな会社で一番効きます。

無料の範囲は、非公開で5ユーザー、月400分のCI/CD、プロジェクトごとに10GiB（2026年11月時点）
プルリクエストに当たるものは Merge Request で、違いは名前と画面です
自動チェックは、リポジトリの直下に .gitlab-ci.yml を置くと動きます
自社サーバーに置く形もありますが、更新とバックアップは自分の仕事になります
GitHubからは公式の移行機能で移せます。GitHub Actionsの設定だけは書き直しです

GitLabとは：GitHubとの対応で読む

GitLabは GitLab Inc. が運営しています。使う形は大きく2つです。GitLabが運営するサーバーを借りる GitLab.com と、自分たちのサーバーに入れる Self-Managed です。この記事は、断りがなければ GitLab.com の話です。

Gitそのものは同じなので、git add、git commit、git push は変わりません。違うのは、Gitの外側の画面と呼び名です。

GitHubの呼び名	GitLabの呼び名	何か
リポジトリ	Project（プロジェクト）	ファイルと履歴の置き場。GitLabではIssueなども含む単位
Organization	Group（グループ）	会社やチームの単位
プルリクエスト（Pull Request、PR）	Merge Request（MR）	変更を取り込む前に確かめる場所
GitHub Actions	GitLab CI/CD	変更のたびに自動で動く仕組み
`.github/workflows`	`.gitlab-ci.yml`	自動処理の設定ファイル
ランナー	Runner	自動処理を実際に動かす担当
GitHub Enterprise Server	Self-Managed	自社サーバーに置く形

無料の範囲

2026年11月時点の GitLab.com の Free です。

項目	上限	超えたとき
人数	非公開のトップレベルグループで5ユーザーまで	グループ全体が読み取り専用になる
CI/CD	月400コンピュート分	共用のRunnerの利用に制限がかかる
ストレージ	プロジェクトごとに10GiB（Gitの履歴とLFSの分）	そのプロジェクトにpushできなくなる
トップレベルグループの数	2026年1月27日より後に作ったFreeアカウントは3つまで	増やすには有料プランが要る

コンピュート分は、自動処理を動かした時間に、Runnerの種類に応じた係数を掛けた値です。トップレベルグループは、一番上の階層のグループのことです。

人数の数え方が要注意です。そのグループの下にある全プロジェクトの、重複を除いた人数で数えます。サンプル料理教室は代表1名、講師3名、受付2名で6人います。全員を入れた時点で上限を超えます。外注エンジニアBを足すと7人です。実際のところ、講師はコードを触らないので入れる必要がありません。代表、受付A、外注エンジニアBの3人なら収まります。

上限を超えて読み取り専用になると、リポジトリへの新しい書き込み、Merge Request の作成と更新、パイプライン（自動処理の一連の流れ）の実行、新しいメンバーの招待が止まります。公式が示す解除の方法は、メンバーを減らす、無料トライアルを始める、有料プランを買う、の3つです。Free のまま上限を増やすことはできません。

この5ユーザーの制限は、公開グループ、個人のネームスペース（自分のアカウント直下の場所）、有料プラン、Self-Managed には掛かりません。ただ、個人の下に仕事のものを置くと、担当者が辞めたときに困ります。会社のものはグループに置きます。

有料の Premium は1ユーザー月$29（年額請求）で、CI/CD は月10,000分、ストレージはプロジェクトごとに500GiBです。Ultimate は個別見積です。

Group と Project を作る

GitLabは、Group の中に Project を入れる形です。グループに入れた人は、中の全プロジェクトに入れます。

サンプル料理教室なら、グループ sample-cooking の下に、プロジェクト website と reservation-mail を置きます。

先にグループを作ります。

右上の「Create new」（プラスのアイコン）を押す
「New group」を選ぶ
「Create group」を選ぶ
「Group name」に sample-cooking と入れる
「Group URL」に同じ文字を入れる
「Visibility level」で「Private」を選ぶ
「Create group」を押す

次に、グループの中にプロジェクトを作ります。

グループを開き、「Create new」を押す
「New project/repository」を選ぶ
「Create blank project」を選ぶ
「Project name」に website と入れる
「Project slug」が website になっているか確かめる
「Visibility Level」で「Private」を選ぶ
「Initialize repository with a README」にチェックを入れる
「Create project」を押す

最後から2番目のチェックを入れると、Gitのリポジトリと既定のブランチが作られ、すぐにクローン（手元に複製）できます。

公開範囲は Private（メンバーだけ）と Public（誰でも）から選びます。Internal（ログインした人全員）もありますが、GitLab.com では使えません。

メンバーの招待とロール

招待は、プロジェクトの左のメニューから行います。Maintainer か Owner の人だけができます。

上の「Search or go to」でプロジェクトを開く
左のメニューで「Manage」を開く
「Members」を選ぶ
「Invite members」を押す
相手のユーザー名かメールアドレスを入れる
ロールを選ぶ
必要なら「Access expiration date」に期限を入れる
「Invite」を押す

ロールは権限の段階です。よく使うのは5つです。

ロール	できること	サンプル料理教室なら
Guest	Issueの閲覧とコメント。リポジトリには入れない	非公開のコードを見せずに要望だけ受ける相手
Reporter	コードを見る、Issueを作る。pushはできない	内容を確かめるだけの受付A
Developer	保護されていないブランチへのpush、Merge Requestの作成、CI/CDの実行	修正もする受付A
Maintainer	ブランチ、Merge Request、CI/CD、メンバーの管理。プロジェクトの削除はできない	外注エンジニアB
Owner	削除と公開範囲の変更を含む全権限	代表

公式には、ほかに Minimal Access、Planner、Security Manager があります。小さな会社なら、最初は上の5つで足ります。

注意が2つあります。1つは、グループに入れた人は全プロジェクトに入れることです。外注エンジニアBに website だけ頼むなら、グループでなくプロジェクトに招待します。reservation-mail にはメールの送信に使う設定があるからです。グループ経由で入った人は、プロジェクト側では外せません。グループから外します。

もう1つは、既定のブランチ（普通は main）が最初から保護されていることです。既定の設定では、Developer は main に直接pushできず、Maintainer はできます。誰がマージできるかは「Settings」の「Repository」にある「Branch rules」で確かめます。

Merge Requestの流れ

Merge Request は、GitHubのプルリクエストと同じ役割です。違いは名前と画面だけで、流れは同じです。

まず手元でブランチ（枝）を切り、料金表を直して送ります。

$ git switch -c fix-menu-price
Switched to a new branch 'fix-menu-price'
$ git add menu.html
$ git commit -m "料金表を修正"
[fix-menu-price a4a20a3] 料金表を修正
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git push -u origin fix-menu-price
To https://gitlab.com/sample-cooking/website.git
 * [new branch]      fix-menu-price -> fix-menu-price
branch 'fix-menu-price' set up to track 'origin/fix-menu-price'.

実際のGitLabに送ると、これに remote: で始まる案内が足されることがあります。続きは画面です。

左のメニューで「Code」を開く
「Merge requests」を選ぶ
右上の「New merge request」を押す
変更元に fix-menu-price、取り込み先に main を選ぶ
「Compare branches and continue」を押す
説明を書き、「Reviewers」の「Edit」で確かめる人を選ぶ
「Create merge request」を押す

確かめる人は、差分を見てコメントを付けます。複数のコメントをまとめて出すなら「Start a review」、すぐ出すなら「Add comment now」です。問題なければ「Approve」、直してほしければ「Request changes」を選びます。最後に権限のある人がマージのボタンを押すと、main に取り込まれます。

Free では、Developer 以上なら誰でも承認できますが、承認は任意でマージを止めません。「承認がないとマージできない」設定は Premium と Ultimate の機能です。Free で運用するなら、代表が確かめてから外注エンジニアBがマージする、といった決めごとで補います。

CI/CDの最小の例

CI/CD は、変更が届くたびに決まった処理を自動で動かす仕組みです。チェックを動かすのが CI、公開まで進めるのが CD と考えると十分です。

設定は、リポジトリの直下に置く .gitlab-ci.yml だけで始められます。index.html と menu.html が消えていないか確かめる例です。

check-files:
  script:
    - test -f index.html
    - test -f menu.html

check-files は処理（ジョブ）の名前で、自分で決めます。script に書いたコマンドを Runner が順に実行します。段階（stage）を書かなければ test の段階に入ります。

左のメニューで「Build」を開く
「Pipeline editor」を選ぶ
上の内容を書く
「Commit changes」を押す
「Build」の「Pipelines」で結果を見る

「Pipeline editor」は、書いている間に文法を確かめてくれます。CI/CD の設定には Maintainer か Owner のロールが要ります。手元で作って git push しても同じです。

APIキーやパスワードは、このファイルに書いてはいけません。プロジェクトに入れる人全員に見えるからです。「Settings」の「CI/CD」にある「Variables」で「Add variable」を押して登録します。「Masked」にするとログで隠れ、「Protect variable」を付けると保護されたブランチでしか使えません。send_mail.py のメール送信キーを使うなら、ここに入れます。

Runnerとは何か

Runner は、ジョブを実際に動かすアプリです。GitLab.com には GitLab が用意した Runner があり、設定なしですぐ使えます。自分のマシンに入れて動かすこともできます。

項目	GitLabが用意する Runner	自分で用意する Runner
管理	GitLabが管理	自分で管理
準備	なしですぐ使える	Linux、macOS、Windowsなどに入れて登録する
向く場面	小さな会社の最初の一歩	社内のマシンでしか動かせない処理がある

GitLab.com のこの共用の Runner を使うときは、悪用を防ぐ目的でクレジットカードかデビットカードの情報を求められます。Self-Managed の Free は、料金表にも「Bring your own storage and runners」とあるとおり、Runnerを自分で用意します。

Self-Managed：自社サーバーに置く話

Self-Managed は、GitLabを自分のサーバーにインストールして管理する形です。料金表には Free、Premium、Ultimate があり、Free の人数の5ユーザー制限は掛かりません。

向くのは、社内の決まりでコードを社外に置けない会社、社内ネットワークの中だけで使いたい会社、サーバーを管理する担当者がいる会社です。サンプル料理教室のような規模なら、GitLab.com で足ります。

CE と EE は、検索するとよく見る言葉です。CE は Community Edition、EE は Enterprise Edition です。公式で確かめられた範囲はこうなります。

ライセンスなしで新しく入れると、Free の機能だけが有効になる
EE で上位の機能を使うには、アクティベーションコードを入れる
CE を使っていれば、あとから EE へ上げられる
gitlab-foss は、独自コードを除いたGitLabの読み取り専用ミラーで、MITライセンス

自社で持つ仕事は次のとおりです。

仕事	中身（2026年11月時点の公式の記載）
サーバーの用意	1台構成なら8 vCPU、メモリ16GBが基準。アプリに40GBと、全リポジトリの合計以上のディスク
更新	毎月第3木曜に新しい版、月2回の修正版。セキュリティ修正の対象は最新と過去2つの月次版まで
バックアップ	バックアップに設定ファイルは含まれない。`gitlab-secrets.json` と `gitlab.rb` は別に保管する
Runnerとストレージ	自分で用意する

gitlab-secrets.json を失うと、データベース内の暗号化された値を読めなくなります。誰がこれを毎月やるのかを決められないなら、Self-Managed は選ばないほうが安全です。なお、GitLabが専用環境を運営する GitLab Dedicated もありますが、規制の厳しい大企業向けです。

GitHubからの移行

公式の移行機能（インポーター）で、GitHubのリポジトリを移せます。始める前に、移行先のグループで Maintainer か Owner のロールと、GitHub側のアクセス権を用意します。

GitLabで移行先のグループ sample-cooking を作る
「Create new」を押す
「New project/repository」を選ぶ
「Import project」を選ぶ
「GitHub」を選ぶ
「Authorize with GitHub」を押す
website の横の「Import」を押す
「Status」の列が完了になるのを待つ

トークンで認証するなら、GitHubのクラシックのトークンを repo の権限で作り、「Personal access token」に貼ります。共同作業者や Git LFS も移すなら read:org も足します。

持っていけるもの	持っていけない・制限があるもの
全ブランチとGitの履歴	Outside collaborators（組織外の共同作業者）
Issue、コメント	「Require status checks to pass before merging」のルール
プルリクエスト、レビュー	カスタムロールの共同作業者（移行が一部で止まることがある）
Label、Milestone、Wiki	GitHubのOrganization（グループは自分で作る）
ブランチ保護ルール、Git LFS	GitHub Actionsの設定（書き換えが要る）
Collaborators、Release notes	本文の添付は「Import Markdown attachments」を選んだときだけ

ユーザーの対応づけの条件を満たさないと、レビュアーや承認はコメントとして残ります。結果は「Complete」「Partially completed」「Failed」のどれかで出るので、「Details」で落ちたものを確かめます。

移したら、手元のリポジトリの送り先を変えます。

$ git remote set-url origin https://gitlab.com/sample-cooking/website.git
$ git remote -v
origin	https://gitlab.com/sample-cooking/website.git (fetch)
origin	https://gitlab.com/sample-cooking/website.git (push)

GitLabに送るには、GitHubとは別に認証の設定が要ります。SSH鍵なら、GitLabのプロフィールの「Access」にある「SSH keys」で登録します。

GitHub Actions の設定は、そのままでは動きません。書き換えの対応はこうです。ただし1対1ではありません。

GitHub Actions	GitLab CI/CD
`on`	`rules`
`run`	`script`
`uses`	`include`（同じものがあるとは限らない）
`runs-on`	`tags`

main に届いたときにファイルを確かめる処理なら、次のように変わります。先が GitHub Actions、後が .gitlab-ci.yml です。GitLabのジョブはプロジェクトのコードに直接アクセスできるので、取得の行がなくなります。

on:
  push:
    branches:
      - main
jobs:
  check-files:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: test -f index.html

check-files:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  script:
    - test -f index.html

シークレット（APIキーなど）は公式の持っていける一覧にないので、GitLabの「Variables」に入れ直します。移行のあとしばらくは、GitHub側を消さずに読み取り専用（archive）で残すと、見落としに気づけます。実際に移してみると、外部サービスの通知先や公開先の設定のように、リポジトリの外にある設定が漏れやすいところです。先に一覧を作ってから移します。

GitHubに残る判断

困っていないなら、GitHubに残るのは正しい判断です。GitLabが悪いのではなく、移す手間に見合う理由があるかどうかです。

残る理由	移す理由
無料のCI/CDを多く使う（Actionsは月2,000分）	取引先や開発会社がGitLabで揃えている
有料でも安く済ませたい（Teamは1ユーザー月$4）	社内の決まりで自社サーバーに置く必要がある
依頼先や道具がGitHub前提で動いている	複数人の開発をGitLabの1つの画面にまとめたい
Actionsの設定が多く、書き直す手間が大きい	上の条件があり、設定が少ないうちに移せる

Copilot のように GitHub と組み合わせて使っている道具があるなら、移行後の動き方まで確かめます。ホームページの修正を1人で続けるだけなら、今ある方のままで困りません。

できないことと、その代わり

Free で5ユーザーの上限は増やせません。人数を絞るか、Premium へ上げるか、Self-Managed にするかです
Free で承認を必須にはできません。運用の決めごとで補うか、Premium にします
Secret Detection（秘密情報の検出）は Free では機能が限られ、push を止める Secret push protection は Ultimate のみです。.env を入れない運用は Free でも自分で守ります
GitLab Duo（AIの機能）は、Free では GitLab Credits の追加購入になります

よく詰まるところ

症状	原因	直し方
急にpushもMerge Requestもできず、`404` も出る	非公開で6人以上になり読み取り専用	グループの「Settings」の「Usage quotas」にある「Seats」で人を確かめ、減らす
`main` にpushできない	`main` は既定で保護。Developer は直接pushできない	ブランチを切って Merge Request を出す
pushできないのが1つのプロジェクトだけ	容量の10GiBを超えて読み取り専用	「Settings」の「Usage quotas」の「Storage」で見る。追加の容量を買うか減らす
パイプラインが動かない	ファイルの場所か名前が違う、Runnerが使えない、カード情報が未登録	直下の `.gitlab-ci.yml` を確かめ、「Settings」の「CI/CD」の「Runners」を見る
設定を書いたのにエラーになる	YAMLの字下げや書き方の誤り	「Pipeline editor」で確かめる
`Variables` の値が空のまま	「Protect variable」が付いていて、保護されていないブランチで動かしている	チェックを外すか、対象のブランチを保護する
メンバーをプロジェクトから外せない	グループ経由で入っている	親のグループから外す
移行が「Partially completed」で止まる	カスタムロールなど未対応のもの	「Details」で落ちたものを見て、手で足す

次に読む

どちらを選ぶかを費用まで含めて比べるなら「GitHubとGitLabの違い：料金・機能・自社サーバーで比べる選び方」です。「GitHubの料金：Free・Team・Enterpriseと無料でできる範囲」も合わせると判断が早くなります。レビューの進め方は「プルリクエストとは：作り方・レビュー・マージの流れ」、自動処理の考え方は「GitHub Actionsの使い方：自動で動かす仕組みと無料枠」に、GitHubの場合で書いてあります。

CI/CDを動かすRunnerを自分で立てる話は「GitLab Runnerとは：CI/CDを動かす仕組みと、自分で立てる場面」です。

あわせて読む

画面に出てくる言葉の意味はGit用語集で引けます。