この記事はラクス Advent Calendar 2025の4日目の記事です
はじめに
私のチームでは今年から新しいGitHubリポジトリの運用を開始しました。
その際、自部署のルールとして「mainブランチへマージする際にはマネージャーの承認が必須」という要件があり、この運用をGitHub上でどう実現するかを検討することになりました。
当初はその仕組みをCODEOWNERSを使って実現しようとしたのですが、実際に試してみると多くの課題が見えてきました。最終的にはGitHubの新しいRulesetsに移行することで、より自然でシンプルな形で要件を満たすことができました。
この記事では、その検討過程と結論についてまとめていきます。
CODEOWNERSとは ― コードの「責任者」を定義する仕組み
まず、CODEOWNERSの本来の役割を正しく理解しておく必要があります。
CODEOWNERS の目的
- 「このディレクトリ/ファイルは誰（どのチーム）が責任を持つのか」を明示するための仕組み
- GitHubはその情報をもとに、該当パスを変更するPRに自動でレビュー依頼を送る
挙動のポイント
- 対象パスを含むあらゆるPRにオーナーへレビューを要求
- ブランチ保護ルールで「CODEOWNERSの承認必須」をオンにすると、オーナーがApproveしない限りマージ不可
- CODEOWNERSに設定されたユーザー/チームには通知が自動で飛ぶ
本質的には、コードの所有と責任の整理が目的の機能です。
CODEOWNERSの具体例
例1：リポジトリ全体に特定チームのレビューを要求する
* @managers-team
リポジトリ内のすべてのファイルに対して、@managers-team がコードオーナーとして指定される例です。
どのファイルを変更してもこのチームにレビュー依頼が飛びます。
例2：ディレクトリごとにチームを分ける
/backend/ @backend-team
/frontend/ @frontend-team
/docs/ @documentation-team
ディレクトリ単位で責任範囲を明確にする例です。
例えば、 /backend/ 以下を変更すると @backend-team にレビュー依頼が送られます。
例3：特定のファイルだけ別チームをオーナーにする
/deployment/k8s.yaml @devops-team
デプロイ設定ファイルなど、特定の重要ファイルだけ別チーム（この場合はDevOpsチーム）に所有させたい場合の例です。
例4：個人をオーナーにする
/config/ @suzuki
特定の領域に詳しい個人をコードオーナーに指定する例です。
小規模なチームや、担当者がはっきりしている設定領域などで利用されることがあります。
今回の要件に当てはめたときのCODEOWNERSの問題点
私は、マネージャーだけのチームを作り、リポジトリ全体をCODEOWNERSに設定する案を検討しました。
例えば以下のような感じです。
* @managers-team
しかし、この運用は多くの問題があります。
1. 全PRにマネージャーレビューが設定される
mainだけに限定できないため、feature → developのような通常のPRにまでマネージャーレビューが設定されます。
2. マネージャーに通知が大量に飛ぶ
CODEOWNERSに設定した時点で、所有者は「対象パスのすべてのPRの通知」を受け取るようになります。
これにより、マネージャーのGitHubの通知が多くなってしまいます。
3. CODEOWNERSの本来用途とズレている
- 本来：コード責任の明確化
- 今回：役職ベースの承認フロー
まったく異なる目的に利用するため、副作用が大きかったです。
GitHubの新機能Rulesetsで問題がすべて解決した
そんな中、2025年11月にGitHubが以下の機能をリリースしました。
-
Rulesets: Required review by specific teams
https://github.blog/changelog/2025-11-03-required-review-by-specific-teams-now-available-in-rulesets/
これにより、
- mainブランチへのPRにだけ
- 特定チームの承認を必須にする
という設定がネイティブに実現できるようになりました。
結果、マネージャーへの余計な通知も消え、本来の意図に沿った形で承認フローを構築することができました。
CODEOWNERSとRulesetsの比較
今回のケースで比較したときの主要ポイントは以下の表にまとめます。
| 観点 | CODEOWNERS | Rulesets（特定チームレビュー必須） |
|---|---|---|
| 主目的 | コードの所有者（責任チーム）の管理 | ブランチへの変更を制御するポリシー管理 |
| レビューが走るタイミング | 対象パスを変更した全 PR | Ruleset が適用されるブランチに向いた PR のみ |
| 今回の要件（main のみ承認必須）への適合性 | ✕（main だけに限定できない） | ◎（main にのみ限定できる） |
| 通知の量 | 多い（対象パスの PR すべて） | 必要最低限（main だけ） |
| 柔軟性 | 低い（パスベースのみ） | 高い（ブランチ・条件・チーム単位） |
| コード責任との整合性 | ◎（本来用途） | –（承認フロー側の機能） |
| 承認者の役割 | コード責任者を想定 | マネージャーなど役割に応じた設定が可能 |
| 副作用 | 全 PR への大量通知・レビュー要求 | 副作用が少ない |
| 今回の要件に使う自然さ | 不自然（用途とズレる） | とても自然（要件に完全一致） |
結論：CODEOWNERSを使うのをやめて正解だった
今回の検証を通して、
- CODEOWNERSは コード責任の定義が目的の機能
- 役職ベースの承認フローに使うと副作用が大きい
- GitHubのRulesetsなら要件にぴったり合う
ということが明確になりました。
その結果、私のチームは CODEOWNERSを使ったレビュー制御を廃止し、Rulesetsへ全面移行しました。
おかげで、
- 不必要なレビュー要求がなくなり
- 通知も最適化され
- CODEOWNERSの本来の役割も守られた
という、より自然で健全な運用に落ち着くことができました。