GitLabで「信頼はするけど、仕組みで担保する」を実現する機能まとめ

Last updated at 2026-08-04Posted at 2026-08-04

はじめに

ソフトウェア開発チームでよく聞く言葉に「性善説でいこう」と「ルールで縛ろう」があります。どちらも極端だと問題が起きますが、GitLabには 「信頼はする、でも仕組みで担保する」 を実現するための機能が豊富に揃っています。

この記事では、そうした機能をティア別（Free / Premium / Ultimate）に整理して紹介します。

前提: この記事は GitLab Self-Managed を対象にしています。19.1時点。

機能	Free	Premium	Ultimate	概要
Protected branches	✅	✅	✅	重要ブランチへのpush/merge制御
MR必須承認ルール	△※	✅	✅	マージに承認を必須化（※Freeでも承認操作自体は可能だが、必須ルールとしての強制はPremium+）
CODEOWNERS	—	✅	✅	パス単位の責任者定義
Code Owner approval 必須化	—	✅	✅	CODEOWNERSの承認を強制
Pipelines must succeed	✅	✅	✅	CI成功をマージの前提条件に
Merged results pipelines	△	✅	✅	マージ結果を先読みしてCIを実行（merge前に衝突を検知）
Push rules	—	✅	✅	コミット・ブランチ名などをpre-receiveで制御
Reject unsigned commits	—	✅	✅	署名なしコミットを拒否
DCO必須化	—	✅	✅	`Signed-off-by:` trailerを必須化
Secret push protection	—	—	✅	secretをpre-receiveで検知・ブロック
MR approval policies	—	—	✅	セキュリティ結果などに応じた追加承認を強制
Protected environments	—	✅	✅	本番環境などへのdeployを制限
Deployment approvals	—	✅	✅	deploy前に追加承認を要求
Audit events / audit log	—	✅	✅	DB/UI/API での記録・参照は Premium+、外部ストリーミングは Ultimate

△ = Free Self-Managed + Registration Features Program の条件付きで利用可（Merged results pipelines）
△※ = Freeでも承認操作自体は可能。ただし「必須承認ルール」としての強制はPremium+

Free でも Protected branches と Pipelines must succeed という2つの強力な機能が使えます。

Protected branches は、特定ブランチへの push / merge / force push / 削除を制御できます。「main ブランチには直接pushさせない」という最も基本的なガードレールがここで実現できます。

Pipelines must succeed は、CIが成功しない限りマージできないようにする merge check です。テストが通らないコードを本番に入れてしまうリスクを、仕組みとして防げます。

✅ Free でできる最低限のガードレール

main ブランチ
├── 直接push禁止（Protected branches）
└── CI通過必須（Pipelines must succeed）

Premiumになると、開発フローをルールとして明示する機能が一気に増えます。

レビュアーの数や特定ユーザーの承認を必須化できます。「誰かがLGTMを押した」という運用ではなく、条件を満たすまでマージボタン自体が押せない状態を作れます。

CODEOWNERS ファイルでパス・ディレクトリごとの責任者を定義し、そのオーナーの承認を protected branch 設定でロックできます。

# CODEOWNERS の例
/backend/  @backend-team
/infra/    @sre-team @lead-engineer
*.tf       @sre-team

インフラファイルを変更したときに、SREチームの承認が必ず必要になる、といった設定が可能です。

pre-receive フックをGUIで設定できます。代表的なルール例：

これらはすべてpushの時点でサーバー側でチェックされるため、ローカルでのhookを無効化しても迂回できません。

本番環境へのデプロイを特定ロール・ユーザーに制限しつつ、さらにデプロイ前に承認を必要とする運用フローを組めます。「CIは通った、でも本番反映には人間の目が必要」というよくある要件をGitLabのフローに組み込めます。

APIキーやトークンなどのシークレット情報を含むコミットを、pushの時点で自動検知してブロックします。「うっかり .env をコミットしてしまった」という事故を防ぐ最後の砦です。

スキャン結果（SAST、依存関係の脆弱性など）やライセンスチェックに基づいて、条件付きで追加承認を自動的に強制できます。例えば「高リスクの脆弱性が検出されたMRにはセキュリティチームの承認が必要」といったポリシーをコードとして管理できます。

Free
└── 「入れさせない / 通らせない」の基本制御

Premium
└── 「誰が / どんな条件で / 承認するか」を明文化・強制

Ultimate
└── 「セキュリティスキャン結果」を承認フローに組み込む

GitLab Free + Self-Managed + Enterprise Edition の組み合わせでは、Service Ping を有効にすると一部の有償機能を無料で利用できる「Registration Features Program」があります。

この表の中で該当する代表例は Merged results pipelines です。

ただし公式ドキュメントには以下の通り明記されています：

"Features introduced here do not remove the feature from its paid tier."

あくまで特例であり、機能の正式ティアが変わるわけではありません。Service Ping を許容できる環境かどうかを確認した上で判断してください。

課題	対応機能
重要ブランチに直接pushさせたくない	Protected branches
CIが通らないとマージできないようにしたい	Pipelines must succeed
コードの責任者に必ずレビューさせたい	CODEOWNERS + Code Owner approval
コミットの形式・内容を強制したい	Push rules
本番デプロイに承認フローを設けたい	Protected environments + Deployment approvals
シークレットの誤pushを防ぎたい	Secret push protection
セキュリティスキャン結果を承認に連動させたい	MR approval policies

「性善説でいこう」と「ルールで縛ろう」の間にある 「信頼はするけど、仕組みで担保する」。GitLabのこれらの機能を組み合わせることで、チームの自律性を保ちながら品質・セキュリティの底上げができます。

チームの規模やリスク許容度に合わせて、まずはFreeの機能から試してみてはいかがでしょうか。

この記事はGitLab Self-Managedを前提にしています。GitLab.comやDedicatedでは一部挙動が異なる場合があります。