Pull Request上に並ぶコードカバレッジのバーと完了チェックを表したイラスト

記事

GitHub、PR上で見えるコードカバレッジを公開プレビュー——CI結果を別ツールに見に行かなくてよくなる

GitHubは2026年5月26日、Pull Request上にカバレッジ集計を表示する『Code coverage on pull requests』を公開プレビューとして発表しました。Cobertura形式のレポートをupload-code-coverageアクションでアップロードすると、PRコメントとして集計値が並びます。

GitHubは2026年5月26日、Pull Requestの画面上にコードカバレッジの集計値を表示する新機能「Code coverage on pull requests」を公開プレビューとして公開しました。CIで出力したカバレッジレポートをGitHub側にアップロードすると、PRコメントとして自動的にカバレッジ表が並びます。レビュー時にカバレッジを確認するために別のSaaSを開く運用から解放されるのが今回のポイントです。

github-code-qualityボットがPR上にコードカバレッジ集計コメントを投稿している様子

画像引用元: GitHub Changelog

PRコメントとして「カバレッジ表」が並ぶ

公式チェンジログによると、この機能はGitHub Code Qualityの利用者向けに、リポジトリ単位でカバレッジ表示を有効化できる仕組みとして提供されます。設定を有効にしたうえで、CIワークフローからupload-code-coverageアクションを使ってCoberturaフォーマットのレポートをアップロードすると、Pull Request上にgithub-code-qualityボットがコメントを投稿し、ブランチ間のカバレッジ差分を表組みで提示します。

具体的には、PRブランチとベースブランチ（多くの場合main）それぞれの全体カバレッジ率、影響を受けるファイルごとの行カバレッジ、増減（+/-）が一覧で表示されます。レビュアーは「テストが落ちているかどうか」だけでなく、「このPRでテスト網羅率がどれだけ動いたのか」を、PR画面を離れずに確認できるようになります。

CIログをスクロールしたり、外部のカバレッジSaaSにログインし直したりする手間がなくなるため、特に複数言語が混在するモノレポでのレビュー体験への寄与が大きい変更だと言えそうです。

入力フォーマットはCobertura、AppsとActionsの権限制御も追加

レポートフォーマットには、現時点でCoberturaが採用されています。Coberturaは多くの言語向けカバレッジツールが対応する事実上の標準XMLフォーマットで、JavaのJaCoCo、Pythonのcoverage.py、JavaScript系のIstanbul/nycなど、既存のツールチェーンから比較的容易に書き出せます。アップロード自体は、GitHubが提供するupload-code-coverageアクションを介して行います。

権限まわりでは、新しいcode-quality:writeというファイングレインドパーミッションが追加されました。これはGitHub AppsとGitHub Actionsのワークフローで使用でき、コードカバレッジの書き込みを必要とする処理だけに権限を絞れます。フルアクセスのトークンを発行せずに済むため、サプライチェーンセキュリティ上の懸念にも一定の配慮がなされた設計です。

既存のCIをそのまま生かしながら、追加するのはレポート出力とアップロード手順だけ、というのが導入のハードルを下げています。

「GitHub Enterprise Cloud」と「Team」プランで利用可能、Serverは未対応

提供範囲については、GitHub Enterprise CloudプランとTeamプランで利用できることが明示されています。一方で、オンプレミス版のGitHub Enterprise Serverについては「まだ利用できない」とされており、自社データセンターで運用しているチームは現時点では対象外です。

料金面では、公開プレビュー期間中は無料で利用できると案内されています。一般提供（GA）後の課金体系については、現時点では明確なアナウンスはなく、料金が確定するタイミングで改めて発表される見込みです。プレビュー期間を使って、自社のレビュー運用にカバレッジ表示がフィットするかを試せる期間になっていると整理できます。

すでにサードパーティ製のカバレッジSaaSを長く運用しているチームにとっては、機能の重複や移行コストの検討が必要になります。一方、まだ可視化基盤を整備していないチームにとっては、GitHubネイティブの選択肢が増えたという意味で導入判断がしやすくなった格好です。

レビュアー視点の変化と、設計時に意識したい3つのポイント

機能の存在自体は地味ですが、レビュアーの体験は確実に変わります。これまではPRのチェック欄に「Tests passed」と緑のチェックが並んでいても、その背後でテストカバレッジが下がっていることに気付けないケースがありました。今回の機能でPR上にカバレッジが直接表示されるようになると、レビュー時に「テスト追加忘れ」の検知が日常的に行えるようになります。

導入時に押さえておきたい設計ポイントは大きく3つです。1つ目は、Coberturaレポートの出力先と命名規約を統一しておくこと。モノレポでは複数言語のレポートを束ねる必要があるため、配置先を最初に決めておくと後の運用が楽になります。2つ目は、code-quality:writeの最小権限化です。既存ワークフローに合流させる際、トークン権限を見直しておくと将来のサプライチェーン対策に効きます。3つ目は、しきい値運用との切り分け。今回の機能は「表示」が中心で、しきい値による必須化（required status check）は別途設計する必要があります。

最終的に、GitHubのCode Quality製品群は、Coderabbit的なAIレビューやセキュリティスキャンと並んで「PRというUIを情報集約のハブにする」方向に進んでいます。明日からのレビューで、PRを開いただけでテスト網羅状況まで把握できる——そんな小さな積み重ねが、レビュー時間と認知負荷の両方を削っていく機能だと言えそうです。