GitHubコミットステータスを活用した柔軟な承認数管理
株式会社CyberAgentの開発者ブログは、GitHubの標準機能であるBranch Protection Rulesでは一律的なapprove数管理しかできない課題に対し、Commit StatusとGitHub Actionsを組み合わせて柔軟なapprove数制御を実現するカスタムソリューション「approval-rules」を紹介している。
キーポイント
標準機能の課題
GitHubのBranch Protection Rulesはリポジトリ単位で一律のapprove数を設定するため、自動生成PRや依存更新PRなど、すべてのPRに同じレビュー負荷をかける運用上の非効率さが課題だった。
提案ソリューションの仕組み
GitHub ActionsでPRのレビューイベントをトリガーにし、定義したルールに基づいて必要なapprove数を判定、その結果をCommit Statusとして書き込み、Branch ProtectionのRequired status checksと連携させることで、PRごとに異なるapprove数要件を実現する。
具体的な適用ケース
Renovateによる依存更新PR、API定義変更に伴う自動生成PR、リリース用設定ファイル更新PR、技術検証中のE2Eテスト実装PRなど、メインアプリケーションコードに直接関わらない差分については、approve数を1に減らす運用を可能にした。
実装と導入
カスタムGitHub Action「approval-rules」として実装され、PRのレビュー状態を取得しルール評価を行い、Commit Statusを更新するコードの抜粋が紹介されている。
GitHub標準機能との併用方法
GitHub標準の「Required approvals」を0に設定し、マージ可否の判定をCommit Status側に委ねることで、柔軟なapprove数制御が実現できる。
自作ツールの選択理由
policy-botは導入コストが高く、リポジトリ単位での細やかな制御にはオーバースペックだったため、GitHub Actionsだけで完結する軽量なソリューションとして自作を選択した。
approval-rulesの機能と拡張性
JSON形式でルールを定義し、PRブランチ名や変更ファイルパスなどの条件に基づいて柔軟なapprove数制御が可能で、今後必要に応じて拡張していく予定。
影響分析・編集コメントを表示
影響分析
この記事は、大規模な開発チームがGitHub上でコードレビュープロセスを効率化するための実践的なノウハウを提供している。標準機能の限界を乗り越えるカスタム自動化の事例として、同様の課題を抱える多くの開発組織にとって参考となる。ただし、これは特定の開発プラットフォーム（GitHub）内でのワークフロー改善に焦点を当てた技術的ソリューションであり、AI技術の核心的な進展や業界全体を変えるような革新性は限定的である。
編集コメント
AI技術の核心的な進展を報じる記事ではなく、開発現場の実務効率化に焦点を当てた技術解説記事。GitHubを中心としたDevOpsプラクティスを改善する具体的なソリューションとして、エンジニアリングマネージャーやDevOpsエンジニアにとって価値が高い内容。
GitHub の Branch Protection Rules よりも柔軟な制御をしたいと思ったことはありませんか？
Commit Status を利用した approve 数制御の仕組み
approval-rules の紹介と使い方
GitHub の Branch Protection だけでは実現できない、条件付き approve 数制御の考え方
Commit Status を活用した柔軟なマージ制御の仕組み
Custom GitHub Action「approval-rules」の導入方法と設定例
GitHub でのコードレビュー運用を改善したいエンジニア
Branch Protection の approve 数設定に不便さを感じている方
自動生成 PR やドキュメント PR のレビューフローを効率化したい方
株式会社 WinTicket でエンジニアをしている谷中(@azoookid)です。
Web チームに所属し、WINTICKET Web 版の開発を担当しています。
今回は、Web チームでの開発における approve 数管理の課題を解決するため、GitHub の Commit Status を活用した仕組みを導入しましたので、その内容を紹介します。
同じような課題を抱えている方の参考になれば幸いです。
GitHub の Branch Protection Rules よりも柔軟な制御をしたいと思ったことはありませんか？
GitHub の Branch Protection Rules には「Required approvals」という設定があり、PR をマージするために必要な approve 数を指定できます。しかし、この設定はリポジトリ（ブランチ）単位で一律にしか適用できません。
WINTICKET Web チームでは、コード品質を担保するために 3 approve を必須として運用してきました。しかし、すべての PR に対して一律 3 approve を求めるのは、運用上負担が大きいケースがありました。
具体的には、以下のような PR です。
Renovate による依存関係更新 PR
JavaScript エコシステム上にある Web アプリケーションのため、Renovate による依存関係更新 PR が頻繁に作成されます。数も多いため、各々が動作確認する前提で 1 approve でマージできるのが理想です。
API 定義変更に伴う infra 層再生成 PR
サーバーの API 定義変更により Web の infra 層再生成 PR が自動で作成されます。自動生成された差分なので複数人でのレビューは不要であり、1 approve でマージできるのが理想です。
リリース用バージョンインクリメント PR
リリース時は設定ファイルのバージョンをインクリメントする PR が作成されます。この PR をマージすることで、Staging 環境へ差分がリリースされ動作確認ができます。リリース差分の確認は別プロセスで行っているため、PR マージ自体は 1 approve でできるのが理想です。
技術検証中の E2E テストシナリオ実装 PR
WINTICKET Web では現在 Playwright を用いた E2E テストの検証を行っています。テストシナリオは monorepo でアプリケーションコードと同じリポジトリに置いていますが、検証スピード向上のため E2E テストファイルのみを変更する PR は 1 approve でマージできるのが理想です。
総じて、メインアプリケーションコードの品質に直接関わらない差分については approve 数を減らした運用にしたいというモチベーションがありました。
Commit Status を使った approve 数制御の仕組み
GitHub Commit Status とは
Commit Status は、特定のコミットに対して外部システムから success などの状態を設定できる GitHub の機能です。
Commit Status を Branch Protection の「Required status checks」と組み合わせると、特定の Commit Status が success になっている場合のみマージを許可する、といった制御が可能になります。
今回はこの仕組みを、以下のように approve 数の判定に応用しました。
- PR のレビューイベント（
pull_request_review）や PR 更新イベントをトリガーに GitHub Actions を実行 - Actions 内で PR のレビュー状態を取得し、定義したルールに基づいて必要な approve 数を判定
- 条件を満たしていれば Commit Status を
successに、満たしていなければpendingに設定 - Branch Protection で該当の Commit Status を Required status check に設定
実際にルール評価と Commit Status 書き込みを行っているコードの抜粋です。
// 1. PR のレビュー一覧から、各ユーザーの最新レビュー状態を取得
const latestReviewByUser = new Map<string, { submittedAt: Date; state: string }>();
for (const review of reviews) {
// approve 後のコメントで状態が上書きされないよう COMMENTED は無視
if (review.state === "COMMENTED") continue;
const submittedAt = new Date(review.submitted_at ?? "");
const reviewer = review.user?.login ?? "";
const existing = latestReviewByUser.get(reviewer);
if (!existing || existing.submittedAt < submittedAt) {
latestReviewByUser.set(reviewer, { submittedAt, state: review.state });
}
}
// 2. 現在の approve 数をカウント
const approvalCount = [...latestReviewByUser.values()].filter((r) => r.state === "APPROVED").length;
// 3. ルールを先頭から順に評価し、最初にマッチしたルールで判定
const satisfiedRule = approvalRules
.map((rule) => validateApprovals({ rule, reviews, payload, changedFiles }))
.find((result) => result != null);
// 4. マッチしたルールに基づいて Commit Status を書き込み
if (satisfiedRule != null) {
await octokit.rest.repos.createCommitStatus({
owner,
repo,
sha: headSha,
state: satisfiedRule.approved ? "success" : "pending",
context: "PR Approval Check",
description: `${satisfiedRule.approved ? "Approved" : "Needs more approvals"} (${satisfiedRule.approvalCount}/${satisfiedRule.rule.requires.count})`,
});
}approve 数が足りない場合は pending ステータスが設定され、マージがブロックされます。
GitHub 標準の「Required approvals」を 0 に設定し、マージ可否の判定を Commit Status 側に委ねることで、柔軟な approve 数制御が実現できます。（WinTicket の GitHub では、Organization の方針として最低 1 approve は必須になっています。そのため、Web チーム管理リポジトリでは「Required approvals」は 1 に設定しています）
同様のアプローチをとるツールとして、Palantir 社の policy-bot があります。policy-bot は高機能ですが、以下の理由から自作を選択しました。
- セルフホストが前提で、さらに Webhook を受け取る GitHub App の整備も必要になり、導入コストが高かった
- Organization 全体を横断的に管理するユースケース向きで、今回のようにリポジトリ単位で細やかな制御をしたいケースにはオーバースペックだった
- GitHub Actions だけで完結する軽量なソリューションが欲しかったため、Custom GitHub Action として実装しました。
approval-rules の紹介と使い方
OSS として WinTicket/approval-rules で公開しています。
JSON 形式でルールを定義し、GitHub Actions で実行することで、柔軟な approve 数制御が可能です。
JSON ルール定義 (approval-rules.json)
[
{
"name": "Requires 1 approve for Renovate PR",
"if": {
"has_author_in": {
"users": ["renovate[bot]"]
}
},
"requires": {
"count": 1
}
},
{
"name": "Requires 1 approve for release PR",
"if": {
"from_branch": {
"pattern": "release/.*"
}
},
"requires": {
"count": 1
}
},
{
"name": "default",
"requires": {
"count": 3
}
}
]GitHub Workflow
name: PR Approval Check
on:
pull_request_review:
types: [submitted, dismissed]
pull_request:
types: [opened, synchronize]
jobs:
check-approvals:
runs-on: ubuntu-latest
steps:
- name: Check Approval Rules
uses: WinTicket/approval-rules@v1
with:
github-token: ${{ secrets.GITHUB_TOKEN }}現時点（2026/03/09）では以下 3 条件に対応しています。
- PR 作成者がどのユーザー（bot含む）か
- PR ブランチ名がどのパターンにマッチするか
- PR の変更ファイルパスがどのパターンにマッチするか
現状は WINTICKET での開発に必要な条件をベースに実装していますが、今後必要に応じて拡張していく予定です。
具体的な実装に興味のある方は WinTicket/approval-rules のコードをご覧ください。
Commit Status の書き換えリスク
この仕組みは Commit Status を利用してマージ可否を制御しています。そのため悪意のある PR 作成者が、Commit Status に write 権限のある GITHUB_TOKEN を取得してステータスを偽装する可能性があります。
厳密なセキュリティ保証が必要な場合は、独立した認証情報で動作する GitHub App として運用する policy-bot などの導入を検討してください。
GitHub API のレートリミット
この Custom GitHub Action は GitHub API を呼び出すため、呼び出し回数が多いとレートリミットに引っかかる可能性があります。大規模な開発で多数の PR が短期間に作成される場合は、専用の GitHub App を用意することも検討してください。
詳細は GitHub API のドキュメントをご覧ください。
まとめ
GitHub の Branch Protection Rules の「Required approvals」は一律設定しかできませんが、Commit Status と GitHub Actions を組み合わせることで、条件に応じた柔軟な approve 数制御が実現できます。
この仕組みを利用した Custom GitHub Action（WinTicket/approval-rules）を OSS として公開しています。ワークフローに追加するだけで導入でき、セルフホストのインフラは不要です。
AI Agent による PR 生成が増えてきている今、複数人がチェックするほどでない差分については、なるべくレビュー負担を減らしてマージできるようにしたいといったニーズも今後増えてくるのではないでしょうか。
様々な条件に応じて approve 数を柔軟に変えたい方は、このアイデアをぜひ活用してみてください。
今回の技術選定や実装にあたって、以下の記事を参考にさせていただきました。
- AI Coding Agentのセキュリティリスク：PRの自己承認とメルカリの対策
- Devinが作るPull Requestのセルフマージを禁止する
原文を表示
GitHub の Branch Protection Rules より柔軟な制御をしたいとき、ありませんか？
Commit Status を使った approve 数制御の仕組み
approval-rules の紹介と使い方
GitHub の Branch Protection だけでは実現できない、条件付き approve 数制御の考え方
Commit Status を活用した柔軟なマージ制御の仕組み
Custom GitHub Action approval-rules の導入方法と設定例
GitHub でのコードレビュー運用を改善したいエンジニア
Branch Protection の approve 数設定に不便さを感じている人
自動生成 PR やドキュメント PR のレビューフローを効率化したい人
株式会社 WinTicket でエンジニアをしている谷中(@azoookid)です。
Web チームに所属し、WINTICKET Web 版の開発を担当しています。
今回は、Web チームでの開発における approve 数管理の課題を解決するために、GitHub の Commit Status を活用した仕組みを導入したので、その内容を紹介します。
同じような課題を抱えている方の参考になれば幸いです。
GitHub の Branch Protection Rules より柔軟な制御をしたいとき、ありませんか？
GitHub の Branch Protection Rules には「Required approvals」という設定があり、PR をマージするために必要な approve 数を指定できます。しかし、この設定はリポジトリ（ブランチ）単位で一律にしか適用できません。
WINTICKET Web チームでは、コード品質を担保するために 3 approve を必須として運用してきました。しかし、すべての PR に対して一律 3 approve を求めるのは、運用上負担が大きいケースがありました。
具体的には、以下のような PR です。
Renovate による依存更新 PR
JavaScript エコシステムに乗っている Web アプリケーションのため、Renovate による依存更新 PR が頻繁に作成されます。量も多いため、各々が動作確認する前提で 1 approve でマージできるのが理想です。
API 定義変更に伴う infra 層再生成 PR
サーバーの API 定義変更により Web の infra 層再生成 PR が自動で作成されます。自動生成された差分なので複数人でのレビューは不要であり、1 approve でマージできるのが理想です。
リリース時は設定ファイルのバージョンをインクリメントする PR が作成されます。この PR をマージすることで、Staging 環境へ差分がリリースされ動作確認ができます。 リリース差分の確認は別プロセスで行っているため、PR マージ自体は 1 approve でできるのが理想です。
技術検証中のE2Eテストシナリオ実装 PR
WINTICKET Web では現在 Playwright を用いた E2E テストの検証を行っています。テストシナリオは monorepo でアプリケーションコードと同じリポジトリに置いていますが、検証スピード向上のため E2E テストファイルへの変更のみの PR は 1 approve でマージできるのが理想です。
総じて、メインアプリケーションコードの品質に直接関わらないような差分については approve 数を減らした運用にしたいというモチベーションがありました。
Commit Status を使った approve 数制御の仕組み
GitHub Commit Status とは
Commit Status は、特定のコミットに対して外部システムから success
Commit Status を Branch Protection の「Required status checks」と組み合わせると、特定の Commit Status が success
今回はこの仕組みを、以下のように approve 数の判定に応用しました。
PR のレビューイベント（pull_request_review
Actions 内で PR のレビュー状態を取得し、定義したルールに基づいて必要な approve 数を判定
条件を満たしていれば Commit Status を success
Branch Protection で該当の Commit Status を Required status check に設定
実際にルール評価と Commit Status 書き込みを行っているコードの抜粋です。
// 1. PR のレビュー一覧から、各ユーザーの最新レビュー状態を取得 const latestReviewByUser = new Map<string, { submittedAt: Date; state: string }>(); for (const review of reviews) { // approve 後のコメントで状態が上書きされないよう COMMENTED は無視 if (review.state === "COMMENTED") continue; const submittedAt = new Date(review.submitted_at ?? ""); const reviewer = review.user?.login ?? ""; const existing = latestReviewByUser.get(reviewer); if (!existing || existing.submittedAt < submittedAt) { latestReviewByUser.set(reviewer, { submittedAt, state: review.state }); } } // 2. 現在の approve 数をカウント const approvalCount = [...latestReviewByUser.values()].filter((r) => r.state === "APPROVED").length; // 3. ルールを先頭から順に評価し、最初にマッチしたルールで判定 const satisfiedRule = approvalRules .map((rule) => validateApprovals({ rule, reviews, payload, changedFiles })) .find((result) => result != null); // 4. マッチしたルールに基づいて Commit Status を書き込み if (satisfiedRule != null) { await octokit.rest.repos.createCommitStatus({ owner, repo, sha: headSha, state: satisfiedRule.approved ? "success" : "pending", context: "PR Approval Check", description: ${satisfiedRule.approved ? "Approved" : "Needs more approvals"} (${satisfiedRule.approvalCount}/${satisfiedRule.rule.requires.count}), }); }
approve 数が足りない場合は pending
GitHub 標準の「Required approvals」を 0 に設定し、マージ可否の判定を Commit Status 側に委ねることで、柔軟な approve 数制御が実現できます。 （WinTicket の GitHub では、 org の方針として最低 1 approve は必須になっています。そのため、Web チーム管理レポジトリでは「Required approvals」は 1 に設定しています）
同様のアプローチをとるツールとして、Palantir 社の policy-bot があります。policy-bot は高機能ですが、以下の理由から自作を選択しました。
セルフホストが前提で、さらに Webhook を受け取る GitHub App の整備も必要になり、導入コストが高かった
Organization 全体を横断的に管理するユースケース向きで、今回のようにリポジトリ単位で細やかな制御をしたいケースにはオーバースペックだった
GitHub Actions だけで完結する軽量なソリューションが欲しかったため、Custom GitHub Action として実装しました。
approval-rules の紹介と使い方
OSS として WinTicket/approval-rules で公開しています。
JSON 形式でルールを定義し、GitHub Actions で実行することで、柔軟な approve 数制御が可能です。
JSON ルール定義 (approval-rules.json)
[ { "name": "Requires 1 approve for Renovate PR", "if": { "has_author_in": { "users": ["renovate[bot]"] } }, "requires": { "count": 1 } }, { "name": "Requires 1 approve for release PR", "if": { "from_branch": { "pattern": "release/.*" } }, "requires": { "count": 1 } }, { "name": "default", "requires": { "count": 3 } } ]
GitHub Workflow
name: PR Approval Check on: pull_request_review: types: [submitted, dismissed] pull_request: types: [opened, synchronize] jobs: check-approvals: runs-on: ubuntu-latest steps: - name: Check Approval Rules uses: WinTicket/approval-rules@v1 with: github-token: ${{ secrets.GITHUB_TOKEN }}
現時点（2026/03/09）では以下 3 条件に対応しています。
PR ブランチ名がどのパターンにマッチするか
PR の変更ファイルパスがどのパターンにマッチするか
現状は WINTICKET での開発に必要な条件をベースに実装していまが、今後必要に応じて拡張していく予定です。
具体的な実装に興味のある方は WinTicket/approval-rules のコードをご覧ください。
Commit Status の書き換えリスク
この仕組みは Commit Status を利用してマージ可否を制御しています。そのため悪意のある PR 作成者が、Commit Status に write 権限のある GITHUB_TOKEN
厳密なセキュリティ保証が必要な場合は、独立した認証情報で動作する GitHub App として運用する policy-bot などの導入を検討してください。
GitHub API のレートリミット
この Custom GitHub Action は GitHub API を呼び出すため、呼び出し回数が多いとレートリミットに引っかかる可能性があります。大規模な開発で多数の PR が短期間に作成される場合は、専用の GitHub App を用意することも検討してください。
詳細は GitHub API のドキュメントをご覧ください。
GitHub の Branch Protection Rules の「Required approvals」は一律設定しかできませんが、Commit Status と GitHub Actions を組み合わせることで、条件に応じた柔軟な approve 数制御が実現できます。
この仕組みを利用した Custom GitHub Action（WinTicket/approval-rules）を OSS として公開しています。 ワークフローに追加するだけで導入でき、セルフホストのインフラは不要です。
AI Agent による PR 生成が増えてきている今、複数人がチェックするほどでない差分については、なるべくレビュー負担を減らしてマージできるようにしたいといったニーズも今後増えてくるのではないでしょうか。
様々な条件に応じて approve 数を柔軟に変えたい方は、このアイデアをぜひ活用してみてください。
今回の技術選定や実装にあたって、以下の記事を参考にさせていただきました。
AI Coding Agentのセキュリティリスク：PRの自己承認とメルカリの対策
Devinが作るPull Requestのセルフマージを禁止する
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み