GitHubのカバレッジ基準をAPIで統一｜RulesetをIaC管理する実践ガイド

GitHub コードカバレッジ Ruleset Infrastructure as Code

テストカバレッジの基準がリポジトリごとに違い、設定画面を人が巡回していないでしょうか。GitHubは2026年9月18日、リポジトリRulesetの「Restrict code coverage」をREST APIから作成・更新・取得できるようにしました。

<style> .cv-hero,.cv-note,.cv-flow{padding:1.2rem;margin:1.5rem 0;border:1px solid #cdd5e1;border-radius:16px;background:#f5f7fb;color:#172033}.cv-hero p:last-child,.cv-note p:last-child{margin-bottom:0}.cv-grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,210px),1fr));gap:12px;margin:1.5rem 0}.cv-card{padding:1.1rem;border:1px solid #cdd5e1;border-radius:14px;background:#fff}.cv-card strong{display:block;color:#3658b0;font-size:1.35rem;margin-bottom:.35rem}.cv-table{overflow-x:auto;margin:1.5rem 0}.cv-table table{border-collapse:collapse;width:100%;min-width:650px}.cv-table th,.cv-table td{padding:.8rem;border:1px solid #cdd5e1;text-align:left;vertical-align:top}.cv-table th{background:#e9edfa}.cv-flow ol{padding-left:1.3rem}.cv-flow li{margin:.7rem 0}.cv-note{background:#fff7e8;border-left:5px solid #b66a16}.cv-code{overflow:auto;padding:1rem;border-radius:14px;background:#101827;color:#e6edf7;font-size:.88rem;line-height:1.55}.cv-meter{display:grid;gap:.8rem;margin:1.5rem 0}.cv-row{display:grid;grid-template-columns:9rem 1fr 4rem;align-items:center;gap:.6rem}.cv-track{height:14px;background:#dce2eb;border-radius:99px;overflow:hidden}.cv-fill{height:100%;background:linear-gradient(90deg,#3658b0,#20a89a)}@media(max-width:560px){.cv-row{grid-template-columns:1fr 4rem}.cv-track{grid-column:1/-1;grid-row:2}} </style>

① 最低ラインと許容低下幅をREST APIでコード化できます。

② GitHub Code Qualityとカバレッジのアップロードが前提です。

③ 現状値を測り、評価モードから始め、例外と監査方法を決めてから強制します。

何が新しいのか

従来はWeb画面で設定していたコードカバレッジRulesetを、一般提供のREST APIで管理できます。設定値をGitでレビューし、テンプレートから多数のリポジトリへ配布し、ドリフトを定期検出できるようになりました。

minimum_coveragePRに要求する絶対的な最低ラインカバレッジ
max_coverage_dropデフォルトブランチから許容する低下幅（パーセントポイント）
REST API GA作成・更新・取得を自動化し、IaCワークフローへ統合

例えば現在80%のリポジトリで minimum_coverage: 75、max_coverage_drop: 1 とした場合、75%未満になるPRだけでなく、79%を下回るPRもブロック対象になります。前者は絶対基準、後者は現在値からの後退防止です。

対象プランと前提条件

項目要件確認ポイント
提供先GitHub Team、GitHub Enterprise Cloud（データレジデンシー含む）GitHub Enterprise Serverでは利用不可
解析GitHub Code Qualityを有効化組織ポリシーとライセンスを確認
データコードカバレッジをアップロードPRと対象ブランチの両方で継続送信
作成権限Administrationのwrite権限Fine-grained tokenまたはGitHub Appを最小権限で使用
API版バージョン指定公式例は2026-03-10

APIでRulesetを作る例

次はデフォルトブランチを対象に、最低75%、低下幅1ポイントまでを指定する最小構成例です。OWNER と REPO、トークンは環境に合わせて置き換えます。

gh api --method POST \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  /repos/OWNER/REPO/rulesets \
  --input - <<'JSON'
{
  "name": "coverage-baseline",
  "target": "branch",
  "enforcement": "evaluate",
  "conditions": {
    "ref_name": {
      "include": ["~DEFAULT_BRANCH"],
      "exclude": []
    }
  },
  "rules": [
    {
      "type": "code_coverage",
      "parameters": {
        "minimum_coverage": 75,
        "max_coverage_drop": 1
      }
    }
  ]
}
JSON

evaluate はGitHub Enterpriseで、マージを止めずにRule Insightsで影響を試すためのモードです。Teamプランなどで利用できない場合は、検証用リポジトリと低いしきい値から始め、active 化する前に影響を確認してください。

安全な導入フロー

  1. 棚卸し：言語、テスト方式、直近30日のカバレッジ分布を取得する。
  2. 分類：新規、既存、レガシー、生成コード主体など、同じ基準を適用できる群に分ける。
  3. 基準決定：一律80%ではなく、現状値と重要度から最低値・低下幅を決める。
  4. 評価：`evaluate` または検証リポジトリで、ブロックされるPRを観測する。
  5. 例外設計：障害対応時のバイパス担当、期限、監査ログを決める。
  6. 段階適用：小規模なリポジトリ群から `active` にする。
  7. ドリフト監視：GET APIの応答と宣言JSONを比較し、手動変更を検知する。

「高い数字」より後退を防ぐ

カバレッジ率は品質そのものではありません。重要な分岐が未テストでも数字は高くなり、価値の薄いテストを増やして数字だけを満たすこともできます。導入初期は絶対値を急に上げるより、低下幅を小さくして既存水準から後退させない設計が現実的です。

観測のみ
1週
低下幅を制限
2週
最低値も強制
以降

この期間は編集部の導入例で、GitHubの推奨値ではありません。変更頻度や失敗率に合わせて調整します。

リスクと限界

  • モノレポでは全体値が一部パッケージの低下を隠す場合があります。
  • 生成コード、移行コード、プラットフォーム固有コードは分母の定義を揃える必要があります。
  • API更新時にRuleset全体を送る実装では、他のルールを意図せず上書きしないよう、GET後の差分確認が必要です。
  • バイパスを広くすると統制が形骸化し、狭すぎると緊急修正を妨げます。
  • GHESでは利用できないため、CloudとServerの混在組織は別の統制方法が必要です。

開発者と企業への影響

プラットフォームチームは、カバレッジ基準を「人が画面で設定する規約」から「レビュー・テスト可能な構成データ」へ変えられます。開発者はPR時点で一貫した基準を受け取れます。一方、経営指標にするならカバレッジだけでなく、変更失敗率、障害流出率、テスト時間も併せて見るべきです。

今後注目すべき点

組織レベルでの配布方法、Rule InsightsのAPI連携、モノレポ単位の粒度、GHESへの提供状況を追跡します。まずは宣言JSONと実設定の差分を可視化し、強制前に「どのPRが、なぜ止まるか」を説明できる状態が目標です。

最終確認日：2026年9月20日

参照元

Previous Post Next Post