先に結論
GitHub の code coverage preview は、新しい分析ツールを増やす話 ではありません。
すでに GitHub Actions でテストを回しているチームが、PR レビューの画面に coverage の信号をそのまま載せられる ようになった更新です。
やることは多くありません。
- Code Quality を有効化する
- Cobertura XML を出す
actions/upload-code-coverage@v1でアップロードする
ただし、気をつける点もはっきりしています。
- 対象は GitHub Team / Enterprise Cloud
code-quality: write権限が必要- preview 中でも GitHub Actions minutes は消費
- fork PR では coverage upload できない
要するに、GitHub 上で review signal を増やしたいチームにはかなり試しやすい一方、OSS 中心の運用ではそのまま移植しにくい機能です。
今回何が変わったのか
GitHub は 2026-05-26 の changelog で、pull request 上に aggregate coverage % を直接表示する機能 を public preview として公開しました。
レビュアーは別サービスへ飛ばずに、PR の中で「この変更がどれだけテストで覆われているか」を見られます。
公式 docs の流れもシンプルです。
- repository で Code Quality を有効化する
- CI で Cobertura XML を生成する
actions/upload-code-coverage@v1で coverage をアップロードする
ワークフローが終わると、PR には github-code-quality[bot] の comment が付き、branch 全体の coverage とファイルごとの差分を確認できます。
コードレビューを GitHub の中で閉じたいチームには、かなり素直な導線です。GitHub Actions 自体の統制を見直したいなら、先に GitHub Actions security roadmap 2026 で何が変わる？CI/CD セキュリティ選定ガイド も読んでおくとつながりが見えます。
今やるべき設定は3ステップ
1. 先に Code Quality を有効化する
coverage 表示だけを単独でオンにするのではなく、前提として repository 側で Code Quality を有効化する必要があります。
GitHub docs では、repository の Settings → Security → Code quality から有効化する手順が案内されています。
ここで見ておくべきなのは、preview 中でも Code Quality scans は GitHub Actions minutes を消費する という点です。機能自体は preview 期間中無料でも、CI コストがゼロになるわけではありません。
Team / Enterprise で GitHub を標準化している組織なら通しやすい一方、minutes を厳しく見ている環境では先に対象 repo を絞ったほうが安全です。
2. CI から Cobertura XML を出す
今回の coverage 表示は、何でもそのまま受け付けるわけではありません。
GitHub docs で前提になっているのは Cobertura XML です。
たとえば公式 docs では、次のような例が出ています。
- Python:
pytest --cov=. --cov-report=xml - JavaScript / TypeScript:
nyc report --reporter=cobertura - Go:
gocover-coberturaで変換
まず確認すべきなのは、今の CI が Cobertura を直接出せるか です。ここが詰まるなら、upload step を足す前に coverage 生成方法を決めたほうが早いです。
3. actions/upload-code-coverage@v1 を追加する
Cobertura XML が出せたら、次は upload です。
必要なのは actions/upload-code-coverage@v1 と、workflow 側の code-quality: write 権限です。
設定の骨格はシンプルです。
- trigger は
pushとpull_requestの両方 に置く - permissions に
code-quality: writeを足す - tests の後に
actions/upload-code-coverage@v1を置く - upload 前に fork PR を弾く条件 を付ける
このとき 1 点だけ注意があります。
GitHub docs の手順ページでは upload input が report と書かれていますが、確認時点の action README では required input が file です。コピペ前に action README の最新記法を確認 したほうが安全です。
ポイントは3つです。
- PR だけでなく default branch でも回す
- checkout は merge commit ではなく PR head SHA を使う
- upload step は fork PR を弾く条件を付ける
GitHub docs では、default branch の baseline と比較するために push と pull_request の両方 を有効にする流れが示されています。README の入力名まで含めて最終確認してから workflow に反映するのが無難です。
注意点は4つある
1. code-quality: write がないとアップロードできない
今回の preview で一番見落としやすいのはここです。
GitHub changelog でも、GitHub Apps と Actions workflows に 新しい code-quality: write 権限 が必要だと明記されています。
既存の contents: read だけでは足りません。workflow が通っていても、coverage upload だけ失敗する形になりやすいので先に確認したほうがいいです。
2. fork PR は非対応
actions/upload-code-coverage の README では、fork からの PR は非対応 と案内されています。
理由は単純で、fork PR には base repository への write 権限がないからです。action は fork PR を検知すると、CI を落とさず notice を出してスキップします。
つまり、外部 contributor が多い OSS では「PR 画面の coverage を全件で出す」前提は置けません。内部開発中心の repo のほうが相性は良いです。
3. preview 中でも Actions minutes は減る
Code Quality は preview 期間中無料ですが、docs では Actions minutes を消費する と書かれています。
対象 repo を広げすぎると、PR review 改善のつもりが CI コストだけ先に増えることがあります。最初は main product repo か review 負荷の高い repo から試すのが無難です。
4. merge queue では upload しない
action README では、merge queue runs は skip されると説明されています。
coverage は PR と default branch で取れれば足りる、という整理です。merge queue にも同じ結果を期待して設計しないほうが混乱しません。
どんなチームに向くか
この preview が強いのは、GitHub 上で review signal を完結させたいチーム です。
特に向いています。
- GitHub Actions をすでに使っている
- Team / Enterprise Cloud で repo 権限を整理できる
- AI 生成コードを含めて PR review の質を上げたい
- Codecov など別画面への遷移を減らしたい
逆に、外部 contributor 比率が高い OSS や、coverage 基盤が Cobertura 前提に寄せにくい環境では、すぐには乗り換えにくいです。
AI コードレビューの監査性までまとめて見たいなら、GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ も合わせて読むと整理しやすいです。
まず何をやればいいか
最初の動きは、これで十分です。
- 1つの主力 repo で Code Quality を有効化する
- 既存 CI が Cobertura XML を出せるか確認する
code-quality: writeを付けて upload step を追加する
この3つで、GitHub 上の PR review に coverage という新しい判断材料を足せます。
新しいツールを増やすより、今の GitHub 運用を少し強くしたいチームには、かなり試しやすい preview です。