2026.11.13 開発

GitLabの権限（ロール）：Guest〜Ownerの操作範囲と保護ブランチの設定手順【2026年11月】

GitLabの権限は、メンバーごとに付ける「ロール」と、ブランチごとに書き込みを絞る「保護ブランチ」の2層で決まります。この記事では、Guest・Planner・Reporter・Security Manager・Developer・Maintainer・Ownerなどロールごとにできる操作を早見表で整理し、メンバー追加とロール変更の手順、APIで使うaccess_levelの数値を示す構成です。後半では保護ブランチのAllowed to mergeとAllowed to push and mergeの設定をcurl例付きで扱い、外部委託メンバーへのロールの付け方とカスタムロールの要否まで判断します。仕様は2026年11月時点の公式ドキュメントにもとづいています。

まとめ：GitLabの権限はロールを最小で付け保護ブランチでmainの書き込みを絞る

開発メンバーの既定はDeveloperです。Developerはコードのpushとマージリクエストの作成ができ、プロジェクト設定・CI/CD変数・メンバーは触れません。設定を変える人だけをMaintainerにし、プロジェクトを消せるOwnerはグループの管理者に限ります。グループとプロジェクトの両方にロールがある人は、高い方のロールで動く点を先に押さえてください。

ロールだけでは「Developerがmainへ直接pushする」ことを止められません。mainは保護ブランチにして、Allowed to push and mergeをNo one、Allowed to mergeをMaintainersにします。この設定は、mainへの書き込みだけでなく、保護変数や手動パイプラインを動かせる人の範囲も定めるものです。Freeでも足り、個人単位の指定やカスタムロールが要るときだけ上位プランを検討します。

GitLabのロール8種とaccess_levelの数値：累積型5種と専門用途の3種

累積型のGuest〜Ownerと企画・脆弱性管理向けの専門ロールの違い

GitLabのRoles and permissionsでは、ロールを権限の少ない順にMinimal Access・Guest・Planner・Reporter・Security Manager・Developer・Maintainer・Ownerと並べています。このうちGuest・Reporter・Developer・Maintainer・Ownerは累積型で、上のロールは下のロールの操作をすべて含みます。

残りの3種は性格が違います。Plannerは17.7で加わった企画・進捗管理向けのロールで、Issueやエピックの管理に寄せてあり、18.7以降は非公開リポジトリのコードも閲覧できます。Security Managerは18.11でベータとして加わった脆弱性管理向けのロールで、パイプラインはDASTのオンデマンドスキャンしか動かせません。Minimal AccessはPremium以上でトップレベルグループにだけ付けられ、配下のプロジェクトへは何も届かない「在籍だけ」のロールです。GitLab自体の構成やCE・EEの違いはGitLabとは（構成要素・CEとEEの違い・3つの提供形態）で確認できます。

APIと保護ブランチ設定で使うaccess_level数値10〜50の対応表

ロールはAPIでは数値で指定します。Projects members APIと保護ブランチのAPIで使える値は次のとおりです。

ロール	メンバーAPIの値	保護ブランチAPIでの扱い
No access	なし	0（push・mergeのみ指定可）
Minimal Access	5（Premium以上・トップレベルグループのみ）	指定不可
Guest	10	指定不可
Planner	15	指定不可
Reporter	20	指定不可
Security Manager	25	指定不可
Developer	30	30
Maintainer	40	40（省略時の既定値）
Owner	50	指定不可
Administrator	なし	60（Self-Managedのみ）

保護ブランチで選べるのは0・30・40（Self-Managedは60も）だけで、Reporter以下には書き込みを許可できません。プロジェクト・グループのアクセストークンを発行するときに選ぶロールも同じ数値で、トークンの扱いはGitLabのアクセストークンの種類とスコープにまとめています。

ロール別にできる操作の早見表：コード閲覧・push・CI/CD変数・メンバー管理

プロジェクトで使う9操作の可否と条件をロールごとに並べた権限の早見表

公式の権限表から、プロジェクト運用で問い合わせの多い操作を抜き出しました。○は可、×は不可、△は条件付きです。

操作	Guest	Planner	Reporter	Developer	Maintainer	Owner
Issueの作成	○	○	○	○	○	○
非公開リポジトリのコード閲覧	×	○（18.7以降）	○	○	○	○
保護されていないブランチへのpush	×	×	×	○	○	○
保護ブランチへのpush・マージ	×	×	×	△（保護設定しだい）	△（既定で可）	△（既定で可）
パイプラインの実行	×	×	×	○	○	○
CI/CD変数の管理	×	×	×	×	○	○
メンバーの追加・ロール変更	×	×	×	×	○（Maintainerまで）	○
プロジェクト設定の変更	×	×	×	×	○	○
プロジェクトの削除	×	×	×	×	×	○

コードを書く人はDeveloper、設定とCI/CD変数を預かる人はMaintainer。ReporterはコードとCIの結果を読むだけの人（QA担当や監査役）向けです。

DeveloperとMaintainer：設定・CI/CD変数・メンバー管理の境目

Developerはコードのpush、マージリクエストの作成とマージ、パイプラインの実行までできますが、プロジェクト設定は変更できません。CI/CD変数の追加・閲覧、保護ブランチの設定、Webhookやデプロイキーの登録もMaintainer以上の操作です。本番の認証情報をCI/CD変数に置くなら、Maintainerは「本番の鍵を見られる人」です。

Maintainerにもできないのはプロジェクトの削除とOwnerの付与です。Maintainerが付けられるロールはMaintainer（40）までで、Ownerのアクセス申請も承認できません。なお個人の名前空間に作ったプロジェクトでは、作成者がMaintainerと表示されながらOwnerと同じ権限を持ちます。

Guestが非公開コードを読めない制約とPlanner・Reporterへの切り替え

Guestは非公開プロジェクトでIssueを書けても、リポジトリは開けず、コンテナレジストリのイメージもpullできません（GitLab.comでコードを見られるのは公開プロジェクトだけ）。顧客に要望をIssueで書いてもらうならGuest、コードの確認まで頼むならReporterです。

企画・PM担当がボードやマイルストーンを動かしたい場合は、Reporterより先にPlannerを検討します。なおGuestはPremiumではシートを消費し、Ultimateでは消費しません。

メンバーを追加してロールを付ける手順：画面操作・グループ招待・API

Manage > Membersでロールと有効期限を指定して招待する画面の操作

メンバーの追加にはMaintainer以上のロールが必要です。Members of a projectの手順は次のとおりです。

プロジェクトを開き、左サイドバーのManage > Membersを選ぶ
右上のInvite membersを選ぶ
ユーザー名（GitLabアカウントがある人）かメールアドレス（まだ無い人）を入力する
Select a roleでロールを選ぶ
必要ならAccess expiration dateに期限日を入れ、Inviteを押す

期限日を入れると、その日以降はプロジェクトにアクセスできなくなり、7日前に本人へメールが届きます。外部メンバーの外し忘れを防ぐための設定が、契約終了日を期限日に指定する方法です。ロールごとに何が止まるかは、GitLabの使い方（プロジェクト作成からIssue・MR・CI/CDまで）の流れを別ロールで試すと確認できます。

グループ継承では高い方のロールが勝つ仕組みと招待時の最大ロール

グループに入れたメンバーは、配下のサブグループとプロジェクトへ同じロールで継承されます。グループとプロジェクトの両方に追加されている場合は、高い方のロールが使われます。親グループでMaintainerの人をプロジェクトでDeveloperに「下げる」ことはできず、その人はプロジェクトでもMaintainerのままです。

逆向きの制限は、グループごとプロジェクトへ招待するときの最大ロール（Maximum role）で掛けます。Sharing projects and groupsによると、招待されたメンバーには「所属グループでのロール」と「最大ロール」の低い方が適用されます。外部委託会社の社員をまとめたグループを最大ロールDeveloperで招待すれば、そのグループ内でMaintainerの人もプロジェクトではDeveloperです。なお18.0以降、グループの招待はOwnerに限られます。

Projects members APIでロールの付与・変更・棚卸しをするcurl例

プロジェクトが増えたら、継承分まで含めた一覧とロールの変更をAPIで回します。apiスコープで、Maintainer以上の人のトークンを使います。

# 前提: GITLAB_TOKEN は api スコープのトークン（Maintainer 以上の人が発行したもの）
GITLAB=https://gitlab.example.com/api/v4
PID=123

# 1) 継承・招待グループ分も含めて全メンバーのロールを一覧する（複数ある人は最も高いロールだけが返る）
curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB}/projects/${PID}/members/all?per_page=100" \
  | jq -r '.[] | [.username, .access_level, (.expires_at // "-")] | @tsv'

# 2) 外部委託のメンバーを Developer（30）で、契約終了日を期限にして追加する
curl --request POST --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  --data "username=partner_dev&access_level=30&expires_at=2027-03-31" \
  "${GITLAB}/projects/${PID}/members"

# 3) Maintainer（40）の人を Developer（30）へ下げる（USER_ID は 1) の一覧とは別に users API で確認）
curl --request PUT --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB}/projects/${PID}/members/${USER_ID}?access_level=30"

3)のPUTで変えられるのはプロジェクトの直接メンバーだけです。グループから継承したロールは、Groups members APIでグループ側を直します。ページネーションやレート制限の扱いはGitLab APIの使い方（トークン認証とcurl例）を参照してください。

保護ブランチの設定手順：直接pushとマージを許可するロールの指定

Branch rulesでmainへの直接pushを禁じマージ担当を絞る操作

保護ブランチの設定を行えるのはMaintainer以上のロールを持つ人です。Protected branchesでは、従来のProtected branches画面に代えてSettings > Repository > Branch rulesから設定する手順が案内されています。Add branch ruleでブランチ名かパターン（例：release/*）を入れ、次の3項目を決めます。

Allowed to merge：マージリクエストでこのブランチへマージできる人
Allowed to push and merge：直接pushとマージの両方ができる人
Allowed to force push：pushできる人に強制pushも許すか（既定はオフ）

Freeで選べる値はNo one・Developers + Maintainers・Maintainersの3つで、ユーザーやグループを個別に指定するのはPremium以上です。mainは作成時点で保護されており、既定ではDeveloperは直接pushできません。マージリクエストを必ず通す運用なら、Allowed to push and mergeをNo oneにします。承認数やCODEOWNERSの設定はGitLabのマージリクエストの承認ルール設定で扱っています。

APIでrelease/*を一括保護するcurl例と設定値を確認する手順

複数プロジェクトに同じ規則を入れるときは、Protected branches APIを使います。省略した項目はpush・merge・保護解除のいずれもMaintainer（40）が既定値になります。

# release/* を「直接 push は誰も不可（0）、マージは Maintainer（40）、保護解除も Maintainer（40）」で保護する
curl --request POST --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  --data-urlencode "name=release/*" \
  --data "push_access_level=0&merge_access_level=40&unprotect_access_level=40" \
  "${GITLAB}/projects/${PID}/protected_branches"

# 保護されているブランチと、push・merge できる人の一覧を確かめる
curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB}/projects/${PID}/protected_branches" \
  | jq '.[] | {name, push: [.push_access_levels[].access_level_description], merge: [.merge_access_levels[].access_level_description], allow_force_push}'

既に保護済みのブランチ（mainなど）にPOSTを送ると重複で失敗します。既存の規則を変えるときはPATCH /projects/:id/protected_branches/:nameを使い、allowed_to_pushなどの配列で指定します。保護解除の細かい制御（unprotect_access_level）は画面に無く、APIでしか設定できません。

保護ブランチが決める範囲：保護変数・保護ランナー・手動パイプライン

保護ブランチは、CI/CDで秘密情報に触れられる範囲も決めます。GitLabのCI/CDパイプラインの「Pipeline security on protected branches」では、保護ブランチでの手動・スケジュールパイプラインの実行やジョブのリトライは、そのブランチにマージかpushを許可された人に限られます。

Protectedを付けたCI/CD変数は保護ブランチのパイプラインにしか渡らず、Protectedを付けたランナーも保護ブランチのジョブしか実行しません。本番の認証情報をProtected変数に置き、mainのAllowed to mergeをMaintainersにすれば、Developerは本番デプロイのジョブを動かせない構成になります。変数の書き方はGitLab CI/CDのrules・needs・変数の設定例、環境ごとのブランチを保護する運用はGitLab Flowの環境ブランチの組み方が詳しいです。

新規プロジェクトのmainに適用する初期保護の5段階と初回pushの扱い

新しく作るプロジェクトのデフォルトブランチの保護は、Default branchの「Initial default branch protection」で決まります。Fully protected・Fully protected after initial push・Protected against pushes・Partially protected・Not protectedの5段階で、既定はFully protected（Developerはpush不可、強制pushは誰も不可）です。設定はAdmin > Settings > Repository > Default branch（インスタンス全体）かグループのSettings > Repository > Default branchで行います。Developerが雛形を入れる運用だけ、初回pushを許すFully protected after initial pushを選びます。Self-Managedの管理画面はGitLabオンプレ構築（Docker Compose）も参照してください。

ロール設計の判断：外部委託の付け方・カスタムロールの要否・失敗例

外部委託メンバーにMaintainerを付けない条件とDeveloperでの組み方

外部委託のメンバーには、原則Developerを付けます。Maintainerを付けると、CI/CD変数に置いた本番の認証情報の閲覧、保護ブランチの解除、Webhookの追加まで届くためです。Maintainerを渡してよいのは、委託先がCI/CDやインフラの設定作業そのものを請けていて、本番の鍵を預ける契約になっている場合に限ります。

Developerのまま回す組み方は、mainのAllowed to push and mergeをNo one、Allowed to mergeをMaintainers、本番の変数をProtected、委託先はグループごと最大ロールDeveloper・期限日つきで招待、の4点です。委託先がマージリクエストを出し、自社のMaintainerがマージします。既存プロジェクトのロール・保護ブランチ・CI/CD変数をまとめて整理し直したい場合は、一創のDevOps・CI/CD導入支援で現在の権限を棚卸しして設定案を作成できます。

カスタムロールが要るのはUltimateの場合だけ：read_codeと変数管理

既定のロールで足りない場合に使うCustom rolesはUltimate限定です。GitLab.comではトップレベルグループのOwner、Self-Managedでは管理者が作り、既存ロールの1つをベースロールにして権限を足します。代表例は、Guestにread_codeだけを足したロールで、この構成はシートを消費しません。

一方、CI/CD変数の管理権限を足したカスタムロールは、MaintainerやOwnerが登録した変数まで管理できてしまいます。DeveloperとMaintainerの中間を作るつもりで変数管理を足すと、本番の鍵に届く点はMaintainerと変わりません。Premium以下では、カスタムロールを探すより、保護ブランチと最大ロールの組み合わせで足りるかを先に検討してください。

全員Maintainerと広いワイルドカード規則で起きる権限の失敗パターン

最も多い失敗は「詰まるたびにMaintainerへ上げ、最後は全員Maintainer」になる形です。保護ブランチは誰でも解除でき、Protected変数も全員から見えるので、保護は意味を失います。Developerでpushが拒否されたら、ロールを上げる前に保護ブランチへの直接pushを疑ってください。

もう1つは、ワイルドカードの規則を重ねたときの読み違いです。1つのブランチに複数の規則が一致すると、最も緩い規則が勝ちます。mainをMaintainersに絞っていても、*のような広いパターンでDevelopers + Maintainersにpushを許す規則があれば、Developerはmainへpushできます。規則を足したら、前の節のAPIで一覧を出し、mainのpush_access_levelsを確かめてください。

よくある質問

GitLabの権限（ロール）について、設定と運用の段階でよく出る質問をまとめました。

GitLabのMaintainerとOwnerの違いは何ですか？

プロジェクトでMaintainerにできないのは、プロジェクトの削除とOwnerロールの付与・Owner申請の承認です。CI/CD変数、保護ブランチ、Maintainerまでのメンバー管理はMaintainerでも操作できます。グループの招待（18.0以降）やグループ単位のデフォルトブランチ保護の上書きもOwnerの操作です。

GitLabで権限が無いと表示されてpushできないのはなぜですか？

原因は2つに分かれます。ロールがReporter以下でpush自体ができない場合と、Developerでも保護ブランチ（既定ではmain）へ直接pushしている場合です。後者なら、作業ブランチへpushしてマージリクエストを出すのが正しい手順です。Manage > Membersで自分のロールを、Settings > Repository > Branch rulesで対象ブランチの規則を確認してください。

Freeプランでもロールと保護ブランチは使えますか？

使えます。Guest〜Ownerのロール、プロジェクト単位の保護ブランチ、No one・Developers + Maintainers・Maintainersの指定はFreeの範囲です。Premium以上が必要なのは、保護ブランチでのユーザー・グループの個別指定、コードオーナー承認の必須化、グループ単位の保護ブランチ（17.6でGA）、Minimal Accessです。カスタムロールを使いたい場合は、Ultimateを選ぶ必要があります。

グループとプロジェクトでロールが違うとどちらが使われますか？

高い方のロールが使われます。親グループでMaintainer、プロジェクトでDeveloperの人は、そのプロジェクトでもMaintainerとして動きます。APIのmembers/allが返す値も同じで、複数のロールを持つ人については最も高いロールだけが取得の対象です。特定のプロジェクトだけ権限を下げたい場合は、その人をグループから外してプロジェクトに直接追加するか、グループ招待の最大ロールで上限を掛けます。

GitHubのロールとGitLabのロールはどう対応しますか？

1対1には対応しません。GitLabは保護ブランチやCI/CD変数の設定にMaintainerが要るなど境目が異なるため、ロール名で置き換えず、コードの読み書き・設定変更・メンバー管理の操作単位で照合してください。サービス全体の違いはGitHubとGitLabの違い、GitHub側のトークン権限はGitHub Actionsのpermissionsの設計が参考になります。