レビュー、サジェスチョン、マージリクエスト承認、コードオーナー
コードレビューの課題は明確です。レビュー待ちでマージリクエストが滞留し、レビュアーの負荷が偏り、承認プロセスが形骸化する。GitLabは、これらの課題に対して、レビュープロセスの可視化、変更提案の直接適用、承認ルールの自動化という3つのアプローチで応えます。本記事では、GitLabのコードレビュー機能を体系的に解説し、実践的な導入方法を示します。
1. レビュープロセスの全体像
GitLabのレビュー機能は、レビュー依頼から承認までを一貫してサポートします。
1.1. レビュアーの指定方法
適切なレビュアーを見つけることが、効率的なレビューの第一歩です。
基本的な指定（全エディション）
サイドバーの「Reviewers」セクションから名前で検索するか、クイックアクション /assign_reviewer @username を使用します。
承認ルールに基づく指定（Premium/Ultimate）
「Assign reviewers」ドロワーを使用すると、承認ルールやCode Ownersに基づいて適切なレビュアーを自動的に提案します。
例えば、「3人のCode Owner承認が必要」というマージリクエストでは、変更されたファイルのCode Ownerが自動的にリストアップされます。これにより、誰に依頼すべきか迷う時間を削減できます。
1.2. レビューの実施
レビュアーは、定められたプロセスに従ってレビューを進めます。
レビュー開始
- マージリクエストの「Changes」タブを開く
- 最初のコメントで「Start a review」を選択
- サイドバーのステータスが「Reviewer started review」に変更される
「Start a review」を選択することで、コメントは未公開状態（Pending）となります。これにより、レビュー途中の未完成なコメントが作成者に通知されることを防ぎます。
レビューステータスの可視化
サイドバーには、各レビュアーの状態がリアルタイムで表示されます。
| アイコン | 状態 | 説明 |
|---|---|---|
| ⊝ | レビュー未開始 | レビュー依頼を受けたが、まだ着手していない |
| ◷ | レビュー進行中 | レビューを開始し、コメントを追加している |
| ✓ | 承認済み | レビューを完了し、承認した |
| ≡ | 変更要求 | レビューを完了し、変更を要求（マージブロック中） |
この可視化により、マージリクエスト作成者は、誰がレビュー中で、誰がまだ着手していないかを一目で把握できます。
1.3. レビュー結果の提出
レビューを完了する際は、3つの選択肢から結果を選びます。
Approve（承認）
フィードバックを残しつつ、変更を承認します。必要な承認数が満たされると、マージリクエストはマージ可能になります。
Comment（コメント）
明示的な承認や変更要求を行わず、一般的なフィードバックのみを残します。軽微な指摘や、参考情報の共有に使用します。
Request changes（変更要求）
Premium/Ultimateでは、この選択によりマージリクエストが物理的にブロックされます。変更要求を行ったレビュアー自身が再承認するまで、マージボタンは無効化されます。
変更要求のバイパス
変更要求を行ったレビュアーが休暇中などで不在の場合、マージ権限を持つユーザーは「Bypass」機能でブロックを解除できます。ただし、マージ時に警告アイコンが表示され、どのチェックがバイパスされたかが記録されます。
2. 変更提案機能（Suggestions）
レビューコメントで「こう直すべき」と文章で説明するのではなく、具体的なコード変更を提案し、ワンクリックで適用できる機能です。
2.1. 変更提案の作成
単一行の提案
- 変更したい行にカーソルを合わせ、コメントアイコンをクリック
- ツールバーから「Insert suggestion」を選択
- 自動挿入されたコードブロックを編集
```suggestion:-0+0
修正後のコード
```
複数行の提案（最大200行）
行番号を選択してドラッグするか、オフセット値を手動で編集します。
```suggestion:-2+2
## 作成者による承認を防止
デフォルトでは、マージリクエストの作成者は自身のマージリクエストを承認できません。この設定を変更するには:
```
オフセット値の意味:
-
-2: コメント行の2行上から -
+2: コメント行の2行下まで
この例では、合計5行（上2行 + コメント行 + 下2行）を置き換えます。
リッチテキストエディタの活用
GitLab 16.2以降では、WYSIWYGエディタで行番号を視覚的に調整できます。「From line」の横にある「+」「-」ボタンをクリックするだけで、変更範囲を直感的に指定できます。
2.2. 変更提案の適用
作成者またはDeveloper権限以上のユーザーは、提案を適用できます。
個別適用
各提案の「Apply suggestion」ボタンをクリックすると、即座にコミットが作成され、マージリクエストのブランチにプッシュされます。
バッチ適用（推奨）
複数の提案をまとめて適用することで、コミット履歴を整理できます。
- 各提案で「Add suggestion to batch」を選択
- すべて選択後、「Apply suggestions」をクリック
- 必要に応じてコミットメッセージをカスタマイズ
注意点: バッチ適用では、複数の提案者がいる場合でも、適用者が単独のコミット作成者となります。プロジェクト設定で「コミット追加者による承認を防止」を有効にしている場合、適用者は承認者から除外されます。
2.3. コミットメッセージのカスタマイズ
プロジェクト設定（Settings → Merge requests → Merge suggestions）で、提案適用時のコミットメッセージテンプレートをカスタマイズできます。
利用可能な変数
| 変数 | 説明 | 出力例 |
|---|---|---|
%{suggestions_count} |
適用した提案の数 | 3 |
%{files_count} |
変更したファイル数 | 2 |
%{file_paths} |
変更したファイルのパス（カンマ区切り） | docs/index.md, docs/about.md |
%{username} |
適用者のユーザー名 | tanaka_taro |
%{user_full_name} |
適用者のフルネーム | 田中太郎 |
%{co_authored_by} |
提案者の共同作成者情報 | Co-authored-by: 山田花子 <yamada@example.com> |
カスタマイズ例
デフォルト:
Apply %{suggestions_count} suggestion(s) to %{files_count} file(s)
カスタマイズ:
%{username}のレビュー指摘に対応
%{co_authored_by}
出力:
tanaka_taroのレビュー指摘に対応
Co-authored-by: 山田花子 <yamada@example.com>
Co-authored-by: 佐藤次郎 <sato@example.com>
3. 承認ルールによる品質管理
承認ルールを設定することで、マージ前に必要なレビューを強制し、コード品質を担保します。
3.1. エディション別の機能比較
| 機能 | Free | Premium/Ultimate |
|---|---|---|
| 承認機能 | ○（任意） | ○（必須化可能） |
| 最小承認者数の設定 | × | ○ |
| 承認ルールの作成 | × | ○ |
| Code Owners承認 | × | ○ |
| カテゴリ別レビュアー | × | ○ |
| セキュリティポリシー連携 | × | ○（Ultimateのみ） |
3.2. 承認ルールの設定
設定手順
- プロジェクトの「Settings」→「Merge requests」を開く
- 「Merge request approvals」セクションで承認ルールを設定
- ルール名、最小承認者数、承認者を指定
実践的なユースケース
ケース1: 最小承認者数の設定
すべてのマージリクエストに対して、最低2人の承認を必須化します。
- ルール名:
最小レビュー - 最小承認者数:
2 - 承認者:
すべてのDeveloper以上
ケース2: カテゴリ別レビュアー
変更内容に応じて、専門家のレビューを必須化します。
| ルール名 | 対象 | 最小承認者数 | 承認者 |
|---|---|---|---|
| バックエンドレビュー | すべて | 1 | @backend-team |
| フロントエンドレビュー | すべて | 1 | @frontend-team |
| セキュリティレビュー | すべて | 1 | @security-team |
ケース3: テストカバレッジ低下の防止
テストカバレッジが低下した場合、QAチームの承認を必須化します。
- ルール名:
カバレッジ低下時の承認 - トリガー:
カバレッジ低下 - 最小承認者数:
1 - 承認者:
@qa-team
3.3. 承認ステータスの確認
マージリクエスト単体での確認
マージリクエストウィジェットに承認ステータスが表示されます。
| 表示 | 意味 |
|---|---|
| Approve | さらに承認が必要（マージ不可） |
| Approve additionally | 必要な承認数は満たしている（追加承認も可能） |
| Revoke approval | すでに承認済み（取り消し可能） |
「Expand eligible approvers」を選択すると、各承認ルールの詳細と、誰が承認可能かを確認できます。
マージリクエスト一覧での確認
プロジェクトやグループのマージリクエスト一覧では、各マージリクエストの承認状態がアイコンで表示されます。
| アイコン | 状態 |
|---|---|
| ○ | 承認が不足（マージ不可） |
| ✓ | 承認済み（マージ可能） |
| ● | 承認済み（自分も承認者の一人） |
3.4. 無効なルールの扱い
以下の場合、承認ルールは「Auto approved」として自動的に承認されます。
- 唯一の承認者がマージリクエスト作成者本人
- 承認可能なユーザーが割り当てられていない
- 必要な承認数が承認可能なユーザー数を超えている
例外: セキュリティポリシー
セキュリティポリシーで作成されたルールは自動承認されず、「Action required」と表示されてマージをブロックします。これにより、セキュリティ要件が確実に満たされます。
4. Code Owners機能
Code Owners機能は、コードベースの特定部分に対する責任者を明確化し、適切な専門家のレビューを保証します。
4.1. Code Ownersの役割
品質保証
特定のファイルやディレクトリに対して、専門知識を持つユーザーの承認を必須化できます。
責任の明確化
ファイルやディレクトリの所有者が、GitLab UIに表示されます。「このコードは誰に聞けばいいのか」という疑問を解消します。
4.2. Code Ownersと承認ルールの使い分け
Code Ownersと承認ルールは、異なる目的で使用します。
| 項目 | Code Owners | 承認ルール |
|---|---|---|
| 目的 | ファイル・ディレクトリ単位の所有者定義 | プロジェクト全体の承認プロセス定義 |
| 対象範囲 | 特定のファイルパターン | すべてのファイル、または条件付き |
| 設定場所 | CODEOWNERSファイル | プロジェクト設定 |
| 変更頻度 | 高（コードベースの変化に応じて） | 低（プロジェクトポリシーの変更時） |
実践的な組み合わせ例
| 種類 | 名前 | 対象範囲 | 説明 |
|---|---|---|---|
| 承認ルール | UX | すべてのファイル | UXチームメンバーがすべての変更をレビュー |
| 承認ルール | セキュリティ | すべてのファイル | セキュリティチームが脆弱性をレビュー |
| Code Owner承認ルール | フロントエンド: コードスタイル |
*.cssファイル |
フロントエンドエンジニアがCSSのスタイル規約をレビュー |
| Code Owner承認ルール | バックエンド: コードレビュー |
*.rbファイル |
バックエンドエンジニアがRubyファイルのロジックとスタイルをレビュー |
4.3. CODEOWNERSファイルの設定
配置場所
GitLabは以下の順序でCODEOWNERSファイルを検索し、最初に見つかったファイルを使用します。
- ルートディレクトリ:
./CODEOWNERS - docsディレクトリ:
./docs/CODEOWNERS - .gitlabディレクトリ:
./.gitlab/CODEOWNERS
基本的な記述例
# バックエンドチーム
*.rb @backend-team
/app/models/ @backend-team @database-team
# フロントエンドチーム
*.vue @frontend-team
*.css @frontend-team @design-team
# インフラチーム
/config/ @infra-team @security-team
/docker/ @infra-team
Dockerfile @infra-team
# ドキュメントチーム
*.md @doc-team
/docs/ @doc-team
# セキュリティチーム（機密情報）
/config/secrets/ @security-team
.env.* @security-team
複数承認の設定
特定のディレクトリに対して、複数のCode Ownerの承認を必須化できます。
# 2人の承認が必要
[2] /config/production/ @infra-team @security-team
# 3人の承認が必要
[3] /app/payments/ @backend-team @security-team @finance-team
4.4. 保護ブランチとの連携
Code Ownersの承認を強制するには、保護ブランチの設定が必要です。
設定手順
- プロジェクトの「Settings」→「Repository」→「Protected branches」を開く
- 保護するブランチ（例:
main）を選択 - 「Require code owner approval」を有効化
実用例: 機密情報の保護
プロジェクトのconfig/ディレクトリに機密情報が含まれている場合:
ステップ1: CODEOWNERSファイルの作成
# 機密情報の保護
/config/ @infra-team @security-team
# 本番環境設定は3人の承認が必要
[3] /config/production/ @infra-team @security-team @cto
ステップ2: 保護ブランチの設定
-
mainブランチを保護ブランチに設定 - 「Require code owner approval」を有効化
- 「Allowed to push and merge」を制限（Maintainer以上）
この設定により、config/ディレクトリを変更するマージリクエストは、指定されたCode Ownersの承認なしにはマージできなくなります。
「Allowed to push and merge」権限の注意点
この権限を持つユーザーは、マージリクエストを経由せずに直接ブランチにプッシュできます。その場合、Code Owner承認を含むマージリクエストの保護機能がバイパスされます。
推奨設定:
- 人間のユーザー: この権限を付与せず、すべての変更をマージリクエスト経由で行う
- 自動化アカウント: CI/CDやリリースツールなど、信頼できる自動化にのみ付与
4.5. Code Ownersの確認方法
ファイル・ディレクトリ単位での確認
- プロジェクトの「Code」→「Repository」を開く
- 確認したいファイルまたはディレクトリに移動
- ページ上部にCode Ownersが表示される
マージリクエストでの確認
マージリクエストの承認ステータスで「Expand eligible approvers」を選択すると、以下の情報を確認できます。
- どのCode Ownerルールが適用されているか
- 各ルールに対して誰が承認可能か
- 現在の承認状況
5. レビュー効率化のための機能
5.1. 再レビュー依頼
レビュアーがレビューを完了した後、作成者は再レビューを依頼できます。
依頼方法
方法1: クイックアクション
/request_review @yamada_hanako
方法2: サイドバーから
サイドバーのレビュアー名横にある「Re-request a review」アイコン（↻）をクリック
効果
- レビュアーに新しいTo-Doアイテムが作成される
- レビュアーに通知メールが送信される
- レビューステータスが「レビュー未開始」にリセットされる
5.2. レビュー中のスレッド解決
コメント返信時に、スレッドの解決・再オープンを同時に実行できます。
手順
- コメントを記入
- 「Resolve thread」または「Reopen thread」を選択
- 「Add comment now」または「Add to review」を選択
Pendingコメントには、レビュー送信時に実行される遅延アクションの情報が表示されます。これにより、レビュー完了時にどのスレッドが解決されるかを事前に確認できます。
5.3. レビュードロワー
画面右上の「Your review」をクリックすると、レビュードロワーが開きます。
機能
未公開コメントの管理
- すべての未公開コメントを一覧表示
- 各コメントの編集・削除
- コメントの対象行へのジャンプ
レビュー結果の選択
- Approve: 承認
- Comment: コメントのみ
- Request changes: 変更要求（Premium/Ultimate）
レビューサマリーの記入
- レビュー全体の総括コメント
- クイックアクションの実行
- AI生成サマリー（Premium/Ultimate）
レビューの破棄
「Discard review」を選択すると、未公開のコメントがすべて削除されます。この操作は取り消せないため、注意が必要です。
使用場面:
- レビューを中断し、後で最初からやり直したい場合
- 誤って大量のコメントを追加してしまった場合
5.4. キーボードショートカット
効率的なレビューのために、以下のショートカットを活用できます。
グローバルショートカット
| ショートカット | 機能 |
|---|---|
| Shift+m | マージリクエスト一覧を表示 |
| Shift+r | レビュー依頼ページを表示 |
コメント入力時のショートカット
| OS | コメント追加（即時公開） | レビューに追加（未公開） |
|---|---|---|
| macOS | Shift+Command+Enter | Command+Enter |
| その他 | Shift+Control+Enter | Control+Enter |
6. 段階的な導入戦略
GitLabのコードレビュー機能は、プロジェクトの成熟度に応じて段階的に導入することで、最大の効果を発揮します。
6.1. フェーズ1: 基本的なレビューフロー（Free版でも可能）
対象: チーム立ち上げ期、小規模プロジェクト
導入する機能:
- レビュアー指定
- 変更提案機能
- レビューステータスの可視化
期待される効果:
- レビューの抜け漏れ防止
- レビューコメントの適用時間の短縮（手動修正 → ワンクリック適用）
- レビュー進捗の可視化
導入のポイント:
まず、変更提案機能の使用をチーム内で推奨します。「こう直すべき」という文章コメントではなく、具体的なコード提案を行うことで、レビューの質が向上します。
6.2. フェーズ2: 承認ルールの導入（Premium/Ultimate）
対象: チームが成長し、コード品質の標準化が必要になった段階
導入する機能:
- 最小承認者数の設定（推奨: 2名）
- カテゴリ別承認ルール
期待される効果:
- コード品質の安定化
- レビュー責任の明確化
- 属人化の防止
導入のポイント:
最初は最小承認者数を2名に設定するだけで十分です。過度に厳格なルールは、開発速度を低下させる可能性があります。
6.3. フェーズ3: Code Ownersの活用
対象: コードベースが複雑化し、専門領域が明確になった段階
導入する機能:
- CODEOWNERSファイルの作成
- 保護ブランチでのCode Owner承認の必須化
- 複数承認ルール（機密情報など）
期待される効果:
- 適切な専門家のレビュー保証
- 責任範囲の明確化
- セキュリティリスクの低減
導入のポイント:
最初は主要なディレクトリのみをCode Ownersで管理し、徐々に範囲を拡大します。すべてのファイルをCode Ownersで管理しようとすると、メンテナンスコストが高くなります。
6.4. 導入時の注意点
過度な厳格化を避ける
承認ルールやCode Ownersを厳格にしすぎると、以下の問題が発生します。
- レビュー待ちでマージリクエストが滞留
- 緊急時の対応が困難
- チームメンバーのモチベーション低下
推奨: 最初は緩めに設定し、問題が発生したら段階的に厳格化します。
レビュアーの負荷分散
特定のメンバーにレビューが集中しないよう、Code Ownersやレビュアー指定を工夫します。
- Code Ownersにチーム全体を指定（個人ではなく）
- ローテーション制の導入
- レビュー負荷の可視化（GitLab Value Stream Analyticsを活用）
ツールに振り回されない
GitLabの機能は強力ですが、すべてを使う必要はありません。プロジェクトの規模と成熟度に応じて、必要な機能を選択してください。
7. まとめ
GitLabのコードレビュー機能は、レビュープロセスの可視化、変更提案の直接適用、承認ルールの自動化という3つの柱で、堅牢な開発ワークフローを実現します。
重要なポイント:
- 段階的な導入: 小さく始めて、徐々に機能を拡張する
- 適切な粒度: すべてを厳格化するのではなく、重要な部分に集中する
- チームの成熟度に合わせる: ツールに振り回されず、チームの実情に合わせて調整する
次のステップ:
- フェーズ1: 変更提案機能を使い始める
- フェーズ2: 最小承認者数を2名に設定する
- フェーズ3: 主要ディレクトリのCODEOWNERSファイルを作成する
コードレビューは、ツールだけでは完結しません。GitLabの機能を活用しつつ、チーム内でレビュー文化を育てることが、長期的なコード品質の向上につながります。