はじめに：もうレビュー依頼で迷わない！CODEOWNERSと保護ルールで開発を自動化する方法
「このコードの変更、誰にレビューしてもらえばいいんだっけ…？」
私自身、リーダーになりたての頃、あるプロジェクトで苦い経験をしました。新メンバーがな何気なく修正した1行の設定ファイル。それが本番環境のデータベース接続設定に関わる超重要ファイルだとは誰も気づかず、レビューを通過させてしまいました。
結果は、リリース直後のサービスダウン。深夜の緊急対応に追われて、チーム全員が疲弊しきってしまいました…
「なぜ、あの時もっと慎重にレビュー担当者を確認しなかったんだ…」と
この失敗から自分が学んだのは、個人の注意力だけにに頼るのではなく、「仕組み」でミスを防ぐことの重要性です。プロジェクトが大きくなるほど、こうした小さな見落としが、取り返しのつかない問題に繋がりかねません。
このような問題を解決し、チームの規模が拡大しても「誰が責任者なのか」を明確にし、コードの品質を保つために、GitHubには「ルールを自動で適用する仕組み」が備わっています。
この記事では、その中核となるCODEOWNERSと、これまでにも触れてきたブランチ保護ルールの連携について深く学びます。これらは、チームの「暗黙の了解」を、誰もが従う「明確なルール」へと変えるための強力なツールです。
この記事の対象読者
- チームでの開発を始めたばかりで、GitHubの運用ルールに悩んでいる方
- Pull Requestのレビュー依頼を誰にすれば良いか、いつも迷ってしまう方
- コードの品質を個人の頑張りではなく、仕組みで担保したいと考えている方
- 新メンバーがスムーズに開発に参加できるような体制を整えたいチームリーダー
目次
本編の前に：基本用語をおさらい
この記事では、いくつかの専門用語が出てきます。初めて見る方もご安心ください！
- Pull Request (PR): 「この変更どうですか？」と提案し、レビューしてもらうための機能です。
- マージ: レビューでOKが出た変更を、正式なコードに取り込むことです。
- リポジトリ: コードやファイルを保管しておく「倉庫」のような場所です。
- mainブランチ: プロジェクトの最も中心的で安定したコードが保管されている、幹となるブランチのこと。通常、このブランチのコードが本番環境にリリースされます。
機能の概要
結論から言うと、これから紹介する2つの機能を組み合わせることで、「担当外のコードが、専門家のレビューなしにマージされてしまう事故」を防ぎ、鉄壁の品質保証ルールを自動で実現できます。
この設定で完成する、安全なワークフローの全体像を先に見てみましょう。
このように、CODEOWNERSでファイルごとの「所有者」を定義し、ブランチ保護ルールで「所有者の承認」を必須にすることで、専門家のチェックを確実に経た安全な開発プロセスが実現します。
それぞれの役割をもう少し詳しく見てみましょう。
- CODEOWNERS: ファイルやディレクトリに「担当者ラベル」を貼るような機能です。「このコードの責任者は、この人（チーム）です」という所有権を明確にします。
- 役割: 特定のファイルが変更されたPull Requestが作成された際に、定義された所有者を自動でレビュー担当者として割り当てます。これにより、専門家が必ず変更に目を通すことを保証します。
- Branch Protection Rules (ブランチ保護ルール):
mainブランチのような重要なブランチを守るためのガードレールです。- 役割: 「レビューでの承認がなければマージできない」「テストが成功しなければマージできない」といったマージの条件を強制します。
各機能の内容と設定手順
1. CODEOWNERS：コードの責任者を明確にする
目的:
- レビュー依頼が特定の人に集中してしまう「属人化」を防ぎます。これにより、「あの人がいないとレビューが進まない…」といった開発の停滞（ボトルネック）を防ぎます。
- 特定のコード領域に対する変更が、その領域に最も詳しい専門家の知らないうちに行われるのを防ぎます。
- 新しくチームに参加したメンバーでも、コードのどの部分を誰が管轄しているのかが一目でわかります。
設定手順:
- リポジトリのルート、
.github/、またはdocs/ディレクトリのいずれかに、CODEOWNERSという名前のファイルを作成します。（拡張子はいりません！）。
作成場所は、リポジトリのルート、.github/、またはdocs/のいずれかですが、.github/CODEOWNERSを強く推奨します。
理由は、GitHub Actionsのワークフローファイルなど、他のGitHub関連の設定もこのディレクトリに置かれるため、一箇所にまとまっていると管理しやすいからです。
（ファイルが整理されていると、後から見返したときに分かりやすいですよ。） - ファイル内に、
ファイルパスのパターン @GitHubのユーザー名または@organization/チーム名という形式で所有者を記述します。
- 書式は
.gitignoreファイルと似ており、*（ワイルドカード）などが利用できます。
（※ワイルドカード：*のように、任意の文字列にマッチする特殊な記号のこと。「なんでもOK」という意味で使えます。） - （ワンポイント：
@organization/チーム名のようにチームを指定するには、まずGitHubのOrganization内でチームを作成しておく必要があります。また、ユーザー名やチーム名は入力ミスがないように注意しましょう。存在しない名前を指定しても、レビューは自動で割り当てられませんよ。） - 重要：ルールはファイルの下に書かれたものほど優先されます。
あるファイルが複数のルールに一致した場合、最後にマッチした（＝最も下に記述された）ルールが常に適用されます。 これはCSSのスタイルが後から読み込まれたもので上書きされるのと似ていますね！
CODEOWNERS の書式をマスターする
CODEOWNERSファイルはシンプルなテキストファイルですが、いくつかのルールを覚えることで、より柔軟に担当者を設定できます。ここでは、公式ドキュメントで定められている書式を詳しく見ていきましょう。
基本の形:
# パターン オーナー1 [オーナー2 ...]
/path/to/file @username @org/team-name- 行の先頭に、対象となるファイルやディレクトリのパターンを記述します。
- 1つ以上のスペースを空けて、オーナーとなるGitHubユーザー名、チーム名、またはメールアドレスを記述します。
- オーナーは複数指定可能です。その場合もスペースで区切ります。
コメント:
- 行頭に
#を付けると、その行はコメントとして扱われます。設定の説明などを記述するのに便利です。
パターンの書き方:
- 書式は
.gitignoreファイルとほぼ同じです。 *: 任意の文字列に一致（例:*.jsはすべてのJavaScriptファイルに一致）。**: 任意の階層のディレクトリに一致（例:**/test/はsrc/test/やsrc/components/test/などに一致）。.gitignoreの一部の構文（!による否定や[]による文字範囲指定など）はサポートされていない点に注意してください。
オーナーの指定方法:
- ユーザー名:
@を付けた個人のGitHubユーザー名（例:@octocat）。 - チーム名:
@を付けた組織名/チーム名（例:@my-org/frontend-team）。そのチームへの書き込み権限(write access)が必要です。 - メールアドレス: GitHubアカウントに登録されているコミットメールアドレス（例:
user@example.com）。
ルールの優先順位:
- 重要: ファイルの下に書かれたルールほど優先されます。あるファイルが複数のパターンに一致した場合、最後にマッチした（＝最も下に記述された）ルールが適用されます。
特殊文字のエスケープ:
- ファイル名やディレクトリ名にスペースが含まれる場合は、バックスラッシュ
\を使ってエスケープする必要があります。
# "file with space.md" というファイル名を指定する例
file\ with\ space.md @usernameこれらのルールを組み合わせることで、プロジェクトの構造に合わせて、きめ細やかなオーナー設定が可能になります。
CODEOWNERSファイルの記述例:
# CODEOWNERS: このファイルでコードの担当者を定義します。
# ルールは上から順に評価され、より下に書かれた具体的なルールが優先されます。
# [1] デフォルトの担当者を設定
# どのルールにも一致しないすべてのファイル(*)は、core-teamがレビューします。
* @my-org/core-team
# [2] ディレクトリ単位で担当者を設定
# /docs/ ディレクトリ以下のファイルは、docs-teamがレビューします。
/docs/ @my-org/docs-team
# [3] より具体的なディレクトリで担当者を上書き
# /src/components/ui/ 以下のファイルは、frontend-teamがレビューします。
/src/components/ui/ @frontend-team
# [4] ファイルの種類で担当者を設定
# /db/migrations/ ディレクトリ内のSQLファイル(*.sql)は、db-admin-userがレビューします。
/db/migrations/*.sql @db-admin-user
# [5] ファイル単位で複数の担当者を設定
# package.jsonとyarn.lockは、core-teamとfrontend-teamの両方がレビューします。
# (この場合、ブランチ保護ルールで必要なレビュー数が1に設定されていれば、どちらか一方の承認でマージ可能です)
package.json @my-org/core-team @frontend-team
yarn.lock @my-org/core-team @frontend-team（グローバルな視点： VS Code (CODEOWNERS) のような世界的なオープンソースプロジェクトでも、CODEOWNERSは品質を維持するために不可欠な役割を果たしています。これらの実例を見ることで、より複雑な設定の参考になりますよ。）
動作:
この設定があるリポジトリで、/src/components/ui/Button.jsを変更するPull Requestが作成されると、GitHubは自動的に@frontend-teamをレビュー担当者として追加します。
2. ブランチ保護ルールとの連携：所有権を強制する
CODEOWNERSファイルを置くだけでレビュー依頼は自動化されますが、そのレビューを無視してマージできてしまっては意味がありません。そこで、ブランチ保護の出番です。
現在、GitHubのブランチ保護は「ルールセット(Rulesets)」という機能に統合されており、より強力で柔軟な設定が可能になっています。
目的
CODEOWNERSで定義された所有者からの承認を、マージの必須条件にします。
設定手順
- リポジトリの「Settings」>「Rules」を開き、ドロップダウンから「Rulesets」を選択します。
- 「New ruleset」ボタンをクリックして、新しいルールセットの作成画面を開きます。
- Generalセクションで、以下を設定します。
- Ruleset name:
main branch protectionのような分かりやすい名前を付けます。 - Enforcement status: ルールの適用方法を選びます。まずは「Evaluate」で試すのがおすすめです。（各ステータスの詳細は後述の「補足事項」で解説します）
- Ruleset name:
- Targeting criteria (ルールの対象を指定)セクションで、以下を設定します。
- 「Target branches」を選択した状態で、「Add a target」をクリックし、「Include the default branch」を選びます。
- Branch protections (ブランチ保護ルール)セクションで、以下を設定します。
- 「Require a pull request before merging」にチェックを入れます。
- 表示された詳細ルールの中から、「Require approvals」の必要なレビュー数を「1」以上に設定します。
- そして最も重要な、「Require review from Code Owners」にチェックを入れます。
- 最後に「Create」ボタンを押して、ルールセットを有効化します。
この設定により、先ほど紹介したワークフローが完成し、CODEOWNERSで指定されたコードオーナーが承認するまで、マージボタンは有効にならず、クリックできない状態になります。これで、専門家のチェック漏れがなくなりますね！
補足事項
- Enforcement Statusについて:
ルールの適用状態は3つから選べます。新しいルールを導入する際は、まず「Evaluate」でお試し運用し、影響範囲を確認してから「Active」に切り替えるのが安全です。- Active: ルールを完全に有効にし、違反をブロックします。
- Evaluate: 「お試しモード」。違反をブロックせず、結果のみを記録します。この機能は、パブリックリポジトリや、Pro・Teamプラン以上のプライベートリポジトリで利用できます。
- Disabled: ルールを無効にします。
- ルールの対象（Targeting criteria）について:
手順ではデフォルトブランチを指定しましたが、ワイルドカードを使ってfeature/*のように特定のパターンのブランチ群を対象にしたり、逆にルールから除外したりと、柔軟な設定が可能です。 - “Require review from Code Owners”が表示されない場合:
この機能は、プライベートリポジトリではGitHub Pro以上の有料プランが必要です。Freeプランのプライベートリポジトリでは、この項目自体が表示されません。 - UIの変更について:
以前は「Settings」>「Branches」から同様の設定を行っていましたが、現在はより多機能な「Rulesets」に統合されています。
一歩進んだ活用術：よくある質問（FAQ）とベストプラクティス
Q1: CODEOWNERSで指定したチームの誰か一人が承認すれば良いのですか？
A1: はい。デフォルトでは、指定されたチームの誰か一人が承認すれば条件を満たします。もし複数人の承認を必須にしたい場合は、ブランチ保護ルールの「Require approvals」で必要なレビュー数を「2」以上に設定してください。
Q2: Monorepo（モノレポ）のように、1つのリポジトリに複数のプロジェクトがある場合はどうすればいいですか？
A2: MonorepoではCODEOWNERSが特に強力です。ディレクトリごとに明確にオーナーを分けることで、巨大なリポジトリでも秩序を保てます。
/apps/ios-app/ @mobile-team
/apps/web-app/ @frontend-team
/packages/ui-library/ @design-system-teamQ3: CODEOWNERSが形骸化してしまうアンチパターンはありますか？
A3: あります。例えば、* @everyone-team のように、あまりにも広範なルールを設定しすぎると、結局誰も責任を持たない状態に陥りがちです。また、異動したメンバーを更新し忘れることもよくあります。CODEOWNERSファイル自体も定期的にメンテナンスする文化が重要です。
Q4: CODEOWNERSで必須になったレビューと、通常の必須レビュー（Required reviewers）の違いは何ですか？
A4: 良い質問ですね。CODEOWNERSによるレビューは「ファイルの場所」に基づいて動的にレビュアーが決まるのに対し、通常の必須レビューは「Pull Request全体」に対して常に固定のレビュアー（例：特定のシニアエンジニア）を指定します。CODEOWNERSは、コードの専門領域に応じて適切な担当者を割り当てる、より柔軟な仕組みと言えます。
Q5: 複数のCODEOWNERSファイルは作れますか？
A5: いいえ、作れません。CODEOWNERSファイルはリポジトリ内に1つだけで、.github/, docs/, またはルートディレクトリのいずれかに配置されたものが優先順に読み込まれます。.github/CODEOWNERS に一元化するのが最も一般的なベストプラクティスです。
Q6: 多国籍チームで運用する際の注意点はありますか？
A6: 素晴らしい視点です。タイムゾーンが異なるチームを複数オーナーに指定する場合、レビューの待ち時間が発生しやすくなります。対策として、@org/team-japan と @org/team-usa の両方をオーナーにしつつ、ブランチ保護ルールで必要な承認数を「1」に設定することで、どちらかのチームが先にレビューすればプロセスを進められるようにする工夫が有効です。
Q7: GDPRなど、特定の地域の法令に対応するために使えますか？
A7: はい、応用可能です。例えば、ヨーロッパのユーザーデータにアクセスするコードのオーナーに、開発チームだけでなく法務担当者（@org/legal-team）を追加することで、コンプライアンスチェックを開発プロセスに組み込むといった活用事例があります。
料金体系について
「こんなに便利な機能、もしかして有料…？」と気になった方もいるかもしれませんね。ご安心ください！これらの機能は、多くのケースで無料で利用できます。
結論から言うと、パブリックリポジトリ（誰でもコードを閲覧できる状態）であれば、CODEOWNERSもブランチ保護ルールも全ての機能が無料で使えます。
一方で、プライベートリポジトリ（関係者しか閲覧できない状態）で「コードオーナーからのレビューを必須にする（Require review from Code Owners）」機能を利用するには、有料プラン（GitHub Pro以上）が必要になります。
| プラン | リポジトリの種類 | CODEOWNERSファイルの利用 | ブランチ保護ルール （コードオーナーのレビュー必須化） |
|---|---|---|---|
| GitHub Free | パブリック | ✅ 無料 | ✅ 無料 |
| GitHub Free | プライベート | ✅ 無料 | ❌ 有料 |
| GitHub Pro | プライベート | ✅ | ✅ |
| GitHub Team | プライベート | ✅ | ✅ |
| GitHub Enterprise | プライベート | ✅ | ✅ |
※ CODEOWNERSファイル自体はプライベートリポジトリでも無料で作成・利用できますが、それをブランチ保護ルールで「必須」にする段階で有料プランが必要になります。
※ 料金体系は変更される可能性があるため、最新の情報は公式サイトをご確認ください。(2025年9月時点の情報です)
チーム開発でプライベートリポジトリの安全性を高めたい場合は、GitHub Proへのアップグレードを検討する価値が十分にあると言えるでしょう。
より詳しくは、公式サイトの料金ページをご確認ください。
- GitHub Pricing: https://github.com/pricing
理解度チェッククイズ
理論を学んだら、知識が定着したかクイズで試してみましょう！
問題: CODEOWNERSファイルに、以下の2行がこの順番で書かれています。
/docs/ @docs-team
/docs/manual.md @tech-writerdocs/manual.mdを含むPull Requestが作成された場合、自動でレビュアーに設定されるのは誰でしょう？
@docs-team@tech-writer@docs-teamと@tech-writerの両方
答えを見る
正解は 2. @tech-writer です！
CODEOWNERSファイルでは、より下に書かれたルールが優先されます。そのため、/docs/manual.md に完全に一致する @tech-writer のルールが、より広範な /docs/ のルールを上書きします。
知識を試すミニチャレンジ
理論を学んだら、次は実践です！ご自身の練習用リポジトリで、以下の設定を試してみましょう。
.github/CODEOWNERSファイルを作成する。README.mdファイルのオーナーとして、あなた自身のGitHubユーザー名を指定する。README.mdを少し編集してPull Requestを作成し、自分自身が自動でレビュアーに設定されることを確認してみましょう！
まとめ
CODEOWNERSとブランチ保護ルールは、チームのコラボレーションにおける「交通整理」と「安全規則」です。これらを導入することで、コミュニケーションコストを削減し、コードの品質を組織的に担保することができます。
- CODEOWNERSで責任の所在を明確にし、
- ブランチ保護ルールでその責任が果たされることを強制する。
この2つを組み合わせることで、あなたのチームは、メンバーが増えても混乱しない、スケール可能で安全な開発体制を築き上げることができるのです。このアプローチは、著名な『State of DevOps Report』で示されている、ハイパフォーマンスなチームのプラクティスとも一致します。
さあ、チームの「暗黙のルール」をGitHubの「賢い仕組み」に置き換えて、レビュー依頼の迷いや確認漏れの不安から解放されましょう。そして、空いた時間と頭脳で、もっと創造的な開発に集中できる環境を作っていきましょう！
まずは、あなたの個人プロジェクトやチームの小さなリポジトリで、CODEOWNERSファイルを作ってみることから始めてみませんか？ 小さな一歩が、未来の開発効率を大きく変えるはずです。
そして、この記事をチームにシェアして、「うちのプロジェクトの”大家さん”は誰にしよう？」と話し合ってみるのも、素晴らしい第一歩です。
参考資料
- 公式ドキュメント
- About code owners (GitHub Docs)
- 関連する業界レポート
- State of DevOps Report – DevOpsのトレンドとハイパフォーマンスなチームの特性を理解するための業界標準レポートです。
本記事をご利用いただくにあたって
この記事は、公開時点（2025年9月）の情報に基づき、正確な情報を提供するよう努めています。
しかし、本記事で解説するソフトウェアやサービスの仕様は日々更新されるため、記事内で紹介している画面や手順が、ご覧いただいている時点では変更されている可能性があります。
もし内容に相違がある場合は、各サービスの最新の公式ドキュメントも併せてご参照ください。本記事の情報を利用される際は、ご自身の判断と責任においてお願いいたします。
