GitHubコミットステータスを活用した柔軟な承認数管理

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 の機能です。 ![](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/03/commit-status-1024x647.png) Commit Status を Branch Protection の「Required status checks」と組み合わせると、特定の Commit Status が success になっている場合のみマージを許可する、といった制御が可能になります。 今回はこの仕組みを、以下のように approve 数の判定に応用しました。 1. PR のレビューイベント（`pull_request_review`）や PR 更新イベントをトリガーに GitHub Actions を実行 2. Actions 内で PR のレビュー状態を取得し、定義したルールに基づいて必要な approve 数を判定 3. 条件を満たしていれば Commit Status を `success` に、満たしていなければ `pending` に設定 4. Branch Protection で該当の Commit Status を Required status check に設定 実際にルール評価と Commit Status 書き込みを行っているコードの抜粋です。 ```javascript // 1. PR のレビュー一覧から、各ユーザーの最新レビュー状態を取得 const latestReviewByUser = new Map (); 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 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` ステータスが設定され、マージがブロックされます。 ![](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/03/approval-check-commit-status-pending-1024x117.png) ![](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/03/approval-check-commit-status-success-1024x66.png) 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)** ```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** ```yaml 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コミットステータスを活用した柔軟な承認数管理

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト