Codecovとは｜GitHub Actions連携とcodecov.ymlの設定手順

テストのカバレッジ自体はpytest --covやjest --coverageで今すぐ出せます。困るのはその先で、数字がPRごとにどう動いたかをレビューの場に出すとなると、CIのログを開いて前回と読み比べる作業が残ります。Codecovは、CIが吐いたレポートを受け取って集計し、PRコメントとコミットステータスの2つの形でレビュー画面へ差し戻すSaaSです。この記事では、合否が決まるまでの経路、codecov.ymlでしきい値を決める手順、無料枠が頭打ちになる条件、そして2026年にSentryからHarnessへ移った運営体制までを扱いました。指標そのものの段階と目標値の決め方はテストカバレッジとは？C0/C1/C2の網羅率と目標設定で整理しているため、本稿は道具の側に絞ります。

まとめ：Codecovを導入する前に決める接続方式とカバレッジ基準の判断

Codecovの導入そのものは、ワークフローにcodecov/codecov-actionを1ステップ足し、CODECOV_TOKENをSecretsへ入れるだけで終わります。手が止まるのはその後です。

先に決めるのは合否条件と費用の分岐点の2つ。Codecovは既定でprojectとpatchという2種のコミットステータスを返し、前者は全体カバレッジが基準コミットから5%落ちても通す一方、後者は「そのPRで追加・変更された行」だけを見て既定のしきい値を0%に置きます。全体には甘く、差分には厳しい。この非対称を知らずに入れると、既存コードの負債は放置されたままPRだけが赤くなり、開発者がステータスを見なくなります。

費用のほうは、無料のDeveloperがプライベートリポジトリで月250アップロードまで。消費は人数ではなくジョブ数に比例します。

運営体制も2026年に動きました。SentryからHarnessへ事業が移り、Sentry画面側の入口は同年5月29日に消えています。既存の使い勝手は維持されると公式は表明していますが、社内ドキュメントがSentry経由の導線を書いているなら書き換えが要ります。

カバレッジレポートをCodecovへ送って差分が出るまでの処理の流れ

Codecovは自前でテストを実行しません。CI側が生成したレポートファイルを受け取り、行単位の実行有無を再構成してGitHub上へ返す役割に徹します。この分担を押さえると、詰まったときの切り分けが速くなります。

lcovやcoberturaを受け取って集計するまでの入力形式と送信手段

入力になるのは各言語のカバレッジツールが吐く中間ファイルです。Pythonのcoverage.pyが出すcoverage.xml（cobertura形式）、JavaScriptのlcov.info、Javaのjacoco.xmlと形式は違いますが、Codecovはこれらをパースして共通の内部表現に直すため、テストランナーは問いません。送る手段はGitHub Actionsならcodecov/codecov-action、それ以外のCIやローカル検証ならCodecov CLIで、どちらも最終的にはCLIが動くため中身は変わりません。アクション側はランナーにbash・curl・git・gpgが入っていること、actions/checkoutを先に実行しておくことを前提にします。

PRコメントと2種のコミットステータスに出る差分カバレッジの中身

受け取ったレポートは2つの出口を持ちます。1つはPRへ投稿されるコメントで、既定のレイアウトはdiff, flags, filesの3ブロックです。差分の増減、フラグ別の内訳、そして変更のあったファイル一覧がこの順で並びます。

もう1つがコミットステータスです。公式ドキュメントのCommit Statusによれば、既定でprojectとpatchの2つが送られ、前者はリポジトリ全体のカバレッジをPRのベースコミットと比較し、後者はそのPRで追加・変更された行だけを対象にします。ブランチ保護で必須チェックに指定するなら、実務で効くのは後者です。全体の数字は巨大なリポジトリではほとんど動かないためです。

SentryからHarnessへ移った運営体制の変更と既存利用者への影響

Codecovの所有者は2026年に動きました。この経緯を知らないと、検索で出てくる導入記事の前提がずれていることに気づけません。

2026年6月のHarnessによる買収とSentry側の設定削除の経緯

2026年6月2日、HarnessがSentryからCodecovを買収したと発表しました。プレスリリースは「Harness has acquired Codecov from Sentry」と明記し、既存利用者については「preserving the experience teams rely on today」――今チームが頼っている体験を保ったまま投資を続ける、という書き方です。公式の料金ページも「Codecov by Harness」の表記に変わりました。

この動きに先行して、Sentry側では2026年5月29日にCodecovの組織設定が削除されています。チェンジログの指示は短く、カバレッジのレビューを続けるならapp.codecov.ioへ直接行け、というものでした。

Sentry連携を前提に組んだ社内導線で確認すべき移行先と窓口

実務上の影響は、機能よりも導線と請求に出ます。Sentryのアカウントでログインしていたチームは、入口がapp.codecov.ioに変わったことを共有しないとオンボーディング資料の手順で迷子が出ますし、請求をSentry側にまとめていたなら経理側の登録先も確認が要ります。技術面ではアップロードの仕組みもトークンの発行元も従来のまま動いているため、慌てて別のカバレッジサービスへ乗り換える理由には現時点でなりません。ただし受託開発で顧客環境へ組み込む場合、契約主体が変わった事実は伝えておくほうが後々の説明が楽です。

GitHub Actionsからカバレッジをアップロードする最小構成の作成

ここからは手を動かす部分です。バージョン選定でつまずく事情があるため、そこから片付けます。

codecov-actionのv7系とv5系が並行して更新されている現状

GitHub API上のリリース履歴を実測すると、codecov/codecov-actionのタグは素直な直線になっていません。2026年9月17日にv7.1.1が出ている一方で、v5系も同年6月9日にv5.5.5が出ており、v6.0.0（3月26日）とv7.0.0（6月7日）が短い間隔で並びます。公式リポジトリのREADMEには推奨としてv5の記載が残る箇所もあり、参照する情報源によって案内が食い違う状態です。

新規に組むならv7系のタグを明示して固定するのが無難でしょう。v5で入った変更のうち引っかかるのは入力名の改名で、fileはfilesに、pluginはpluginsに変わりました。古い記事をコピーしてfile:のまま書くと指定が無視され、レポートの自動探索が走って意図しないファイルが送られます。

pytestのカバレッジをv7系のActionで送るワークフロー例

Pythonプロジェクトの最小構成です。テストを走らせてXMLを出し、アクションへ渡すだけで足ります。

name: test
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install -r requirements.txt pytest-cov
      - run: pytest --cov=src --cov-report=xml
      - uses: codecov/codecov-action@v7
        with:
          files: ./coverage.xml
          flags: unittests
          fail_ci_if_error: true
        env:
          CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}

fail_ci_if_errorの既定はfalseで、アップロードに失敗してもジョブは緑のまま通過します。品質ゲートとして使うならtrueへ倒してください。既定のままだと、トークン切れでレポートが何週間も届いていないのに誰も気づかない、という壊れ方をします。

CODECOV_TOKENの置き場所とフォークからのPRで詰まる箇所

トークンは公式のQuick Startにある通り、リポジトリをセットアップした画面で発行されるものをコピーして使います。置き場所はリポジトリのSecretsが基本で、複数リポジトリで共有したいならOrganization Secretsに上げて対象を絞る形。置き場所ごとの漏えい経路とOIDCへの寄せ方はGitHub ActionsのSecrets管理で扱いました。

詰まるのはフォークからのPRです。GitHub Actionsは外部フォーク発のPRへSecretsを渡さないため、secrets.CODECOV_TOKENは空文字になります。v5以降のCodecovはトークン無しのアップロードを原則受け付けませんが、フォークから公開upstreamへのPRだけは例外として扱われるとリポジトリ側が明記しています。プライベートリポジトリで外部コントリビューターを受け入れる構成なら、この例外は効きません。pull_request_targetへ切り替える案が出がちなものの、フォーク側のコードを特権つきで走らせる危険を抱えるため、カバレッジのために採るべき手ではありません。

Codecov CLIで直接アップロードする場合のコマンドと版の固定

Jenkins、GitLab CI、CircleCIなどGitHub Actions以外から送るときはCLIを直接使います。公式の案内は、バイナリを取得して実行権限を付け、upload-processへトークンとレポートを渡す形です。

curl -Os https://cli.codecov.io/latest/linux/codecov
chmod +x codecov
./codecov --verbose upload-process --fail-on-error \
  -t "$CODECOV_TOKEN" -n "api-$BUILD_ID" \
  -F api -f coverage.xml

latestを指したままだと、CLI側の更新でビルドの挙動が変わる余地が残ります。codecov/codecov-cliのリリース実測では2026年7月9日のv11.3.1が最新で、その前が同7月8日のv11.3.0、さらに前が4月21日のv11.2.8でした。再現性を求める案件では版番号を埋めたURLへ切り替えます。-Fがフラグ、-nが実行の名前で、モノレポで複数ジョブから送るならこの2つを分けておかないと後で内訳が読めません。

codecov.ymlでprojectとpatchのしきい値を決める設定手順

設定ファイルを置かなくてもCodecovは動きます。ただし既定値のままだと合否が期待とずれるため、最初のPRが赤くなった時点で書くことになります。

targetのautoとthresholdの既定5%が意味する合否の境目

codecov.ymlリファレンスによれば、targetの既定値はauto、thresholdの既定値は5%です。autoは固定値を置かず、比較元コミットのカバレッジをそのまま目標にする指定です。つまり既定のprojectステータスは「基準より5%以上落ちなければ通す」という緩い門になります。

一方patch側の既定しきい値は0%。追加・変更された行のカバレッジが基準を下回れば即座に落ちます。この非対称が、導入直後の「全体は緑なのに毎回patchだけ赤い」という状態を生みました。既存コードのカバレッジが低い現場では、まずpatchのtargetを現実的な水準――たとえば60%――へ明示し、新しく書く行から締めていく形が続きます。

coverage:
  status:
    project:
      default:
        target: auto
        threshold: 1%
        if_ci_failed: error
    patch:
      default:
        target: 60%

comment:
  layout: "condensed_header, diff, flags, files"
  require_changes: true

ignore:
  - "**/*_test.go"
  - "migrations/**/*"
  - "src/generated/**/*"

ignoreとflagsで対象外ファイルとテスト種別を切り分ける書き方

ignoreはグロブパターンを受け付け、自動生成コードやマイグレーションのように「テストを書く意味が薄いのに母数だけ増やすファイル」を分母から外します。ORMのスキーマ定義やprotobufの生成物を外すだけで、見かけの数字は動きます。

flagsは逆に、同じリポジトリのカバレッジを種別で分けて見る仕組みです。pathsで対象ディレクトリを絞り、carryforwardで「今回送られてこなかったフラグの値を前回のまま持ち越すか」を決めます。既定はfalse、つまり持ち越しません。モノレポで変更のあったサービスだけテストを走らせていると、走らなかった側のフラグが0%扱いになり全体が急落したように見えました。これは設定ミスではなく既定の仕様なので、部分実行を前提にするならcarryforward: trueを明示します。単体・結合・E2Eの配分という前段の設計をテストピラミッドとは？単体・結合・E2Eの配分で決めてから、フラグ名をその階層に合わせると内訳が読みやすくなります。

codecov.ymlの置き場所と設定が反映されない時の確認手順

置き場所は3か所。公式ドキュメントによれば、リポジトリルート、dev/ディレクトリ、.github/ディレクトリのいずれかで、ファイル名はcodecov.ymlと.codecov.ymlの両方が使えます。拡張子はymlで、.codecov.yamlと綴る取り違えが定番の詰まりどころです。

反映されないときの切り分けには順序があります。まずデフォルトブランチ側にファイルが入っているか。設定の読み込みはコミット単位で走るため、機能ブランチにだけ置いた変更はそのブランチのPRでしか効きません。次にYAMLの妥当性で、インデントのずれで丸ごと無視されてもCI側は何も言いません。最後が、送っているレポートへ対象ファイルが含まれているか。ignoreの書きすぎで分母が消えているケースはここで見つかります。

Developer・Team・Proの料金とアップロード上限に達する条件

費用の見積もりでずれるのは単価ではなく、アップロード回数の数え方です。

無料のDeveloperで運用できる範囲と月250アップロードの上限

公式の料金ページによれば、Developerプランは無料で、パブリックリポジトリのアップロードは無制限、プライベートは月250まで。オープンソースならユーザー数の制限もかかりません。

問題はプライベート側の250という数字の消え方で、これはPRの本数ではなくアップロードの本数を数えます。マトリックスビルドでPython 3.11・3.12・3.13の3並列を回し、それぞれがレポートを送る構成なら1回のpushで3消費。pushとpull_requestの両方でトリガーしていれば倍です。5人のチームが日に10回pushし、営業日20日で数えれば単純計算で1,000を超えます。無料枠で回るのは、個人開発かパブリックリポジトリ、あるいは送信をデフォルトブランチへのマージ時だけに絞った構成に限られます。

TeamとProの単価差と、開発人数が増えたときの費用の伸び方

Teamは1ユーザーあたり月5ドルで、10ユーザーまで、プライベートのアップロードは月2,500までという枠つき。Proは1ユーザーあたり月12ドルで上限はどちらも無く、ただし最小2ユーザーからの契約です。Enterpriseは個別見積もりになります。

10人のチームがTeamに収まれば月50ドル、11人目が入った瞬間にProへ移って月132ドル。人数の増え方が読めるなら、10人の壁の手前でアップロード回数を整理しておくと移行を先送りできます。あわせて見るべきはCI側の実行コストで、カバレッジ計測はテスト実行時間を押し上げるぶん、GitHub Actionsの料金と分単価のほうが総額では先に効く場合があります。

Codecovを採用する条件と、自前集計で足りるため見送る開発現場

ここは判断を言い切ります。Codecovは全案件に入れる道具ではありません。

PRごとの差分カバレッジを合否条件に組み込む現場での採用条件

採用が効くのは、複数人が並行してPRを出し、レビュー時点でテストの抜けを機械的に指摘したい現場です。patchステータスをブランチ保護の必須チェックに入れておけば、テストを書かずに機能を足すPRはマージできません。人のレビューで「テスト書いてください」と毎回言う手間が消えます。

もう1つの条件は、リポジトリが複数に分かれていて横断で数字を見たい場合。リポジトリごとのHTMLレポートを人が開いて回る運用は続きません。パイプライン全体から見直すならCI/CDとは：仕組み・パイプライン構成と導入判断の基準を土台にしたうえで、品質ゲートの位置としてCodecovを置く順序になります。

自前のHTMLレポートで足りるため導入を見送るべき2つの場面

見送ってよい場面は明確です。1つは、開発者が1〜2人でPRレビューの習慣が無い案件。この規模ならcoverage htmlで生成したレポートをローカルで開けば足り、外部サービスへソースの構造情報を送るリスクだけが残ります。

もう1つは、ソースコードの外部送信が契約上ためらわれる案件。Codecovへ送られるのはカバレッジレポートであってソースそのものではないものの、ファイルパスと行番号の構造は渡ります。金融や医療の受託で持ち出し範囲が厳密に定義されているなら、審査を通す工数が得られる可視化を上回ることもあるでしょう。その場合はCIのアーティファクトとしてHTMLレポートを保存し、しきい値判定をcoverage report --fail-under=80の終了コードで代替すれば、大半の効果はCIの中だけで得られます。持ち出し範囲の線引きや品質ゲートの引き渡しまで含めて相談先を探しているなら、保守運用・内製化支援で扱う範囲が近いはずです。

カバレッジ100%を合格条件に据えたときに起きる形骸化の兆候

しきい値を100%に置いた現場は、ほぼ例外なく壊れます。兆候の出る順番は決まっていて、最初にignoreの行数が増え、次にアサーションの無いテスト――関数を呼ぶだけで何も検証しない――が混ざり始め、最後にCodecovのステータスを必須チェックから外す提案が出てきました。

数字が100%でもバグは残ります。カバレッジは「実行された行」しか見ておらず、その行の結果が正しいかまでは判定していないためです。テストが欠陥を検出できているかを測りたいなら、コードを意図的に書き換えてテストが落ちるかを見るミューテーションテストのほうが目的に合います。Codecovの数字は、下がったときに理由を聞く計器として使い、上げること自体を目標に据えないでください。

Codecovの導入・トークン・料金・PRコメントでよくある質問への回答

導入時に問い合わせが集まる論点を5つ挙げました。

CodecovとGitHub標準の機能だけで済ませる場合の違いは何ですか？

GitHub単体にはカバレッジを集計して差分表示する機能がありません。サマリーへ数字を書き出すことはできますが、ベースコミットとの比較、PRコメントへの自動投稿、必須チェックとしてのステータス送信は自前で実装が要ります。その実装と維持に割く時間が月5ドルや12ドルを上回るかどうかが判断軸です。

CODECOV_TOKENが無いとアップロードは通りませんか？

v5以降は原則としてトークンが必要です。例外は、フォークから公開されているupstreamリポジトリへ送られたPRで、この場合だけトークン無しでも受け付けられます。プライベートリポジトリでは例外が使えないため、Secretsへの登録が前提です。トークン未設定のままfail_ci_if_error: trueを入れておけば、その時点でCIが赤くなって気づけます。

モノレポで一部のサービスだけテストしたらカバレッジが急落しました

flagsのcarryforwardが既定のfalseのまま部分実行をしているのが原因です。送られてこなかったフラグは値を持ち越さないため、集計上は欠測ではなく未カバーとして扱われます。変更のあったディレクトリだけテストを走らせる構成なら、各フラグへcarryforward: trueを明示してください。

SentryのアカウントでログインしていましたがHarness買収後も使えますか？

Codecov自体はapp.codecov.ioで従来どおり動いています。変わったのはSentry側で、2026年5月29日にSentryの組織設定からCodecovの項目が削除され、公式チェンジログはapp.codecov.ioへ直接アクセスするよう案内しました。アップロードの仕組みやトークンの扱いに変更は入っていません。

PRコメントが毎回投稿されて通知が多すぎる場合は止められますか？

commentセクションで制御できます。require_changes: trueを入れると、カバレッジに変化のないPRではコメントを出しません。レイアウトもlayoutキーで絞り込め、既定のdiff, flags, filesからファイル一覧を外せば縦幅が縮みます。コメント自体を止めるならcomment: falseで、ステータスだけを残す運用にできます。

関連記事

• テストカバレッジとは？C0/C1/C2の網羅率と計測ツール・目標設定を実装者向けに解説：Codecovが表示している数字そのものの定義と、目標値の決め方をまとめています。
• テストピラミッドとは？単体・結合・E2Eの配分と実装者向けテスト戦略設計：フラグをどの階層で分けるかを決める前段の設計です。
• GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断：CODECOV_TOKENの置き場所を決めるときの判断材料です。
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準：カバレッジ計測で伸びる実行時間の費用側を見積もる材料です。
• リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断を解説：カバレッジを維持する対象のテストをどこまで自動化するかの整理です。