先に結論
GitHub の code coverage preview は、別サービスを足さずに PR 上で coverage を見たいチーム にはかなり使いやすい更新です。
やることは多くありません。
- GitHub Code Quality を有効化する
- CI で Cobertura XML を出す
actions/upload-code-coverage@v1を追加する
ただし、条件ははっきりしています。
- 対象は GitHub Team / Enterprise Cloud
- preview 中でも GitHub Actions minutes は消費 する
- fork PR では coverage upload が動かない
つまり今回は、coverage そのものの議論より 今の GitHub 運用にそのまま乗るか を見る更新です。
何が変わったか
GitHub は 2026-05-26 に、pull request 上で aggregate coverage を直接表示する public preview を公開しました。
レビュー担当は、PR を開いたまま「今回の変更がどれだけテストで覆われているか」を見られます。別の coverage SaaS を開き直さなくてよいのが一番大きい変化です。
表示の土台は GitHub Code Quality です。GitHub Docs では、Code Quality を有効化したうえで coverage レポートをアップロードする流れが案内されています。
この更新が刺さるのは、すでに GitHub Actions でテストを回しているチームです。CI を丸ごと組み替える話ではなく、既存 workflow に upload step を足すだけで始めやすいからです。
まず確認したい導入条件
1. Team / Enterprise Cloud か
ここが最初の分岐です。
GitHub の changelog では、GitHub Code Quality は github.com 上の Team と Enterprise Cloud で使えます。GitHub Enterprise Server はまだ対象外です。
preview 中は Code Quality 自体は無料です。ただし、Docs では Code Quality scan が GitHub Actions minutes を消費すると明記されています。
無料 preview だから運用コストがゼロ、とは考えないほうが安全です。
2. GitHub Actions でテストが回っているか
coverage 表示は、既存のテスト結果を GitHub へ送って初めて出ます。
そのため前提はシンプルです。
- GitHub Actions を使っている
- テストを自動実行している
- Cobertura XML を出せる
GitHub Docs では、Python、Java、JavaScript、Ruby、Go の例が先に出ています。Cobertura XML を作れれば、言語自体はかなり広く対応できます。
3. fork PR の扱いを決められるか
ここは見落としやすいです。
actions/upload-code-coverage@v1 の README では、fork からの PR は upload 非対応です。理由は、base repository に write できないからです。
OSS や外部 contributor が多い repo では、coverage が見える PR と見えない PR が混ざります。先に運用ルールを決めておかないと、レビューの期待値がずれます。
今やるべき設定は 3 ステップで足ります
ステップ1: Code Quality を有効化する
GitHub Docs では、repository の Settings → Security → Code quality から有効化できます。
ここで runner や解析対象言語も確認できます。もしボタン自体が見えないなら、enterprise owner 側で無効化されている可能性があります。
ステップ2: CI で Cobertura XML を生成する
coverage 表示の必須条件は Cobertura XML です。
GitHub Docs の例では、たとえば次の形です。
- Python なら
pytest --cov=. --cov-report=xml - JavaScript / TypeScript なら
nyc report --reporter=cobertura - Go なら
gocover-coberturaで変換
要するに、今のテスト基盤を捨てる必要はありません。Cobertura XML を出す出口だけ合わせる のがコツです。
ステップ3: upload action を追加する
GitHub Docs と action README を合わせると、workflow で押さえるべき点は次の3つです。
actions/upload-code-coverage@v1を使う- workflow か job に
code-quality: writeを付ける - PR head が fork のときは upload をスキップする
README ベースの最小例はこうです。
permissions:
contents: read
code-quality: write
- name: Upload coverage report
if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository
uses: actions/upload-code-coverage@v1
with:
file: cobertura.xml
language: JavaScript
label: code-coverage/nycGitHub Docs のガイドは手順理解に向いています。一方で action README は、現行の input 名や制約を確認するときに役立ちます。実装時は README も一緒に見ておくほうが安全です。
PR 上では何が見えるのか
GitHub Docs では、workflow 完了後に github-code-quality[bot] が PR に comment を付ける流れが案内されています。
そこで見えるのは主に次の2つです。
- PR branch の aggregate coverage
- file ごとの coverage 増減
つまり、coverage ツールの管理画面ではなく レビュー画面の中で判断材料を増やす のが今回の価値です。
AI が書いた変更や、複数人が触った大きめの差分でも、「どこまでテストが追いついているか」を PR 上で共有しやすくなります。
PR レビューの信号を GitHub 内で増やしたいなら、Haystack vs CodeRabbit vs GitHub Copilot｜AI生成PRレビューのトリアージ比較 も合わせて見ると、coverage とレビュー自動化をどう分けるか考えやすくなります。
導入前に知っておきたい制約
preview でも Actions minutes は減る
これは GitHub Docs に明記されています。
Code Quality が無料でも、scan 実行は GitHub Actions 上で動きます。Team プランで minutes を詰め気味に使っている組織は、coverage upload を足した後のラン時間を見たほうがよいです。
fork PR は coverage を上げられない
fork PR は notice を出して skip されます。CI を落とさずに済むのは良い点ですが、coverage の一貫性は崩れます。
OSS repo では、internal branch の PR だけ coverage を評価対象にするか、fork PR には別のレビュー基準を置くかを決めておく必要があります。
merge queue では upload しない
action README では、merge queue run は skip されると案内されています。
GitHub の考え方は明快です。coverage は default branch と PR で取れれば十分で、merge queue にまで重ねなくてよいという整理です。
どんなチームから試すべきか
最初に試す価値が高いのは、次のようなチームです。
- GitHub Actions がすでに標準化されている
- PR review を GitHub 内で完結させたい
- code review の判断材料を増やしたい
- Team か Enterprise Cloud を使っている
逆に、fork 中心の OSS repo や Cobertura XML 変換がまだ重いチームは、先にレポート生成の整備から入ったほうがスムーズです。
GitHub の review signal を増やす文脈では、GitHub Actions security roadmap 2026 で何が変わるか や GitHub Copilot Business / Enterprise のモデル承認ガイド もつなげて読むと、レビュー品質と運用統制を同じ線で見やすくなります。
迷ったらこの順番で進める
最後に、導入の順番だけ短くまとめます。
- Team / Enterprise Cloud かを確認する
- Cobertura XML を今の CI で出せるか確認する
code-quality: writeを付けて upload step を足す
ここまで通るなら、この preview は十分試す価値があります。
coverage を別ツールで追いかけるより、まず GitHub の PR 画面で見えるようにする。今の更新は、その一手としてかなり扱いやすいです。