--- title: "テストカバレッジとは？C0/C1/C2の網羅率と計測ツール・目標設定を実装者向けに解説" url: "https://www.issoh.co.jp/tech/details/13507/" published: 2026-07-11 updated: 2026-09-22 categories: ["テスト"] publisher: "株式会社一創" --- # テストカバレッジとは？C0/C1/C2の網羅率と計測ツール・目標設定を実装者向けに解説 テストカバレッジ（コード網羅率）とは、テスト対象のコードのうちテストが実際に通した割合を示す指標です。C0（命令網羅）・C1（分岐網羅）・C2（条件網羅）という段階でどこまで厳しく測るかが変わり、同じ「カバレッジ80%」でも段階が違えば意味がまったく異なります。この記事で扱うのは、3段階の定義と厳しさの序列、JaCoCoやCoverage.py・Istanbulといった言語別の計測ツール、CIでプルリク単位の差分カバレッジを見る組み込み方、そして「目標値を何%に置くか」「100%を目指すべきか」という実装現場の判断です。テストの抜けを数値で管理する視点で全体を通し、テスト配分の全体設計はテストピラミッドの記事へ、テストサイズの分類は判断ハブ記事へ接続します。 ## まとめ：カバレッジは品質保証ではなくテストの抜けを測る計器 先に結論を示します。テストカバレッジは「テストが十分か」を保証する数字ではなく、**テストが一度も通っていないコード＝抜けを見つけるための計器**です。カバレッジ100%はバグゼロを意味せず、逆にカバレッジの低い箇所は「まだ一度も検証されていない」という明確な事実を示します。数字を上げること自体を目的にすると、表面だけ通す中身のないテストが増え、計器としての意味を失います。 実装者が押さえる判断は3つです。第一に、段階を混同しない——C0（命令網羅）とC1（分岐網羅）は厳しさが違い、現実解はC1で70〜80%前後に置くのが多くの現場の相場です。第二に、目標値は一律の全体%ではなく、変更した行に絞った差分カバレッジで管理し、新規コードの抜けをプルリク時点で止める。第三に、E2Eや例外パスなど計測にそぐわない領域は無理に数字で追わず、コードレビューやテスト設計で補う。カバレッジは「どこを見ていないか」を教える道具であって、品質そのものではありません。 ## コード網羅率としてのテストカバレッジの定義とC0・C1・C2の構造 まず言葉の定義と、網羅率をどう測るのかを押さえます。カバレッジは1つの数字ではなく、何を分母に取るかで複数の段階に分かれます。 ### テストカバレッジ（コード網羅率）という指標の定義と分母の取り方 テストカバレッジは、テスト実行時にコードのどの部分が通過したかを計測し、「対象のうち通した割合」を百分率で表した指標です。分母に何を取るかで意味が変わります。行を分母にすれば行カバレッジ、分岐を分母にすれば分岐カバレッジになり、同じテストでも数値が変わります。よく混同されますが、コードカバレッジとテストカバレッジはほぼ同義で使われ、いずれもソースコードの網羅率を指す言葉です。 注意したいのは、カバレッジが測るのは「実行されたか」であって「正しく検証されたか」ではない点です。アサーション（期待値の検証）を1つも書かなくても、コードを呼び出すだけで行は通過し、カバレッジは上がります。だからカバレッジは「通っていない箇所は確実に未検証」という一方向の事実を示す計器として使うのが正しい読み方です。数値が高いことは十分条件ではありません。 ### C0命令網羅・C1分岐網羅・C2条件網羅の違いと厳しさの序列 カバレッジの段階はC0・C1・C2という記号で区別します。C0は命令網羅（ステートメントカバレッジ）で、すべての実行文を最低1回通せば達成です。C1は分岐網羅（ブランチカバレッジ）で、if文などの分岐が真・偽の両方向とも実行されて初めて達成します。C2は条件網羅（コンディションカバレッジ）で、複合条件式に含まれる個々の条件式それぞれが真・偽の両値を取る必要があります。 厳しさはC0＜C1＜C2の順に上がり、達成の難度も跳ね上がります。具体例で差を示します。`if (a && b)` という1行で、a=true・b=trueのケースだけをテストすると、命令は通るのでC0は達成しますが、偽側の分岐を通らないためC1は未達です。C1を満たすには真・偽の両分岐を通す必要があり、C2ではa・bそれぞれが個別に真偽両方を取る組み合わせまで求められます。同じ「網羅率80%」でも、C0の80%とC1の80%では検証の深さが段違いだ、という理解が実務の出発点です。 ### MC/DCやパスカバレッジなど条件網羅の先にある厳密な網羅基準 C2の先には、さらに厳密な網羅基準があります。代表がMC/DC（改良条件判定網羅）で、各条件が単独で判定結果を反転させる組み合わせを網羅します。航空機のDO-178Cや自動車機能安全のISO 26262など、故障が人命に関わる領域で要求される基準です。全条件の全組み合わせを尽くすパスカバレッジ（経路網羅）は理論上最も厳密ですが、分岐が増えると組み合わせが指数的に膨らみ、現実のシステムでは全経路の網羅は非現実的です。 実装者が普段扱うのはC0〜C1、厳しくてC2までで、MC/DCが要るのは安全規格の対象システムに限られます。網羅基準は「厳しいほど良い」わけではなく、対象システムの故障コストに見合った段階を選ぶものです。決済や医療のコアロジックはC2寄りに、管理画面の表示分岐はC0〜C1で十分、といった重み付けを前提に、どの基準で測るかを先に決めます。 ## 言語別のカバレッジ計測ツールとCIでの差分カバレッジ計測の要点 定義を押さえたら、実際にどう測るかです。カバレッジは専用ツールでテスト実行時に自動計測し、CIに組み込んで継続的に観測します。計測した値をPRごとの差分としてレビュー画面に出す手段は、[Codecovとは｜GitHub Actions連携とcodecov.ymlの設定手順](https://www.issoh.co.jp/tech/details/17720/)で扱っています。 ### 主要言語のカバレッジ計測ツールと計測できる網羅段階の対応一覧 計測ツールは言語ごとにほぼ定番が決まっています。用途に応じて選ぶための対応を整理します。 | 言語 | 主なツール | 測れる主な段階 | | --------------------- | ------------------------- | --------------------- | | Java | JaCoCo | 行・分岐（C0/C1） | | JavaScript/TypeScript | Istanbul（nyc）・c8・Vitest内蔵 | 行・分岐・関数（C0/C1） | | Python | Coverage.py（pytest-cov） | 行（C0）／分岐はbranch指定（C1） | | C/C++ | gcov（lcovで可視化） | 行・分岐（C0/C1） | | Ruby | SimpleCov | 行・分岐（C0/C1） | | Go | go test -cover | ステートメント（C0） | ツールを選ぶうえでの落とし穴は、多くのツールが既定では行カバレッジ（C0）しか出さないことです。Coverage.pyは `--branch`、Vitestやnycも設定で分岐計測を有効化しないと、C1の数字は取れません。既定のレポートを見てC1まで測れていると誤解しやすいため、どの段階を計測しているかを設定で明示する必要があります。C2（条件網羅）を自動計測できるツールは少なく、C2はテスト設計側で意識的にケースを組むのが現実的です。 ### CI/CDでのカバレッジ計測とプルリク差分カバレッジによる抜けの検知 カバレッジは一度測って終わりではなく、CIに組み込んで変化を追う運用が中核です。プルリクエストごとにテストとカバレッジ計測を走らせ、レポートをGitHub ActionsやGitLab CIのジョブで生成します。ここで効くのが差分カバレッジ（パッチカバレッジ）で、変更した行に絞ってカバレッジを見る方式です。既存の巨大なレガシーコードで全体%を一気に上げるのは難しくても、「新しく追加・変更した行のカバレッジは80%以上」というルールなら現実的に運用できます。 全体カバレッジを絶対値で門番（ゲート）にすると、テストを書きにくい定型コードのために閾値を下げる圧力が働き、形骸化します。差分に絞る方式なら、新規コードの抜けをその場で止めつつ、古いコードは触ったときに少しずつ改善できる運用が現実的です。回帰の検知でも同じ考え方が効き、変更箇所のカバレッジと[リグレッションテストの範囲選定・自動化](https://www.issoh.co.jp/tech/details/13008/)を組み合わせると、影響範囲だけを効率的に守れます。なお、ブラウザ操作を通す[E2Eテスト](https://www.issoh.co.jp/tech/details/5470/)は経路が広くカバレッジの数値化にそぐわないため、行・分岐カバレッジは単体・結合層で測り、E2Eは主要導線の通過確認に役割を分けるのが実務的です。 ## カバレッジ目標の設定と、数字を追いすぎたときに陥る失敗パターン ここからは判断を言い切ります。カバレッジは目標値の置き方しだいで、毒にも薬にもなる指標です。相場観と、避けるべき場面を条件付きで整理します。 ### カバレッジ目標の相場とC1で70〜80%前後を現実解とする理由 目標値に絶対の正解はありませんが、多くの現場の相場はC1（分岐網羅）で70〜80%前後です。Googleは自社のテスト文化について、60%を「許容できる」、75%を「賞賛に値する」、90%を「模範的」とする目安を技術ブログで示したことがあります。この帯を実装者向けに翻訳すると、コアなドメインロジックはC1で80%以上を狙い、設定ファイルの読み込みや自明なゲッターは無理に追わない、という濃淡をつける運用になります。 数値を一律に適用しないことが肝心です。分岐の少ない定型的なCRUD処理と、料金計算のように条件が絡み合うロジックでは、同じ80%でも守るべき重みが違います。カバレッジのレポートは全体%より「どの分岐が赤いか」を見る道具として使い、赤い箇所がクリティカルなロジックなら優先して埋め、瑣末な分岐なら見送る——この選別ができるかどうかが、目標値運用の成否を分けます。通した行の結果まで検証できているかを測るなら[ミューテーションテストによるテスト自体の検出力の計測](https://www.issoh.co.jp/tech/details/16261/)が併用できます。 ### カバレッジ100%を目指すべきでない場面と典型的な失敗パターン 最も避けたい失敗が、カバレッジ100%を自己目的化することです。100%を強制すると、例外ハンドラやログ出力など到達させにくい行を通すためだけの中身のないテストが量産され、テストコードの保守コストだけが膨らみます。アサーションの無い「呼ぶだけテスト」で数字を作る、到達不能なデフェンシブコードにまで無理にケースを書く——これらは典型的な症状です。カバレッジは上がっても、バグを捕まえる力はまったく増えていません。 100%が正当化されるのは、決済・認証・医療機器の制御のように1件の見逃しが致命傷になるコアモジュールに絞った場合だけです。それ以外で全社一律100%を掲げるのは過剰で、テストを書く動機を「品質」から「数字合わせ」にすり替えてしまいます。判断の基準は明快です。**そのテストが将来のバグを1つでも捕まえうるか**——答えがノーなら、カバレッジのために書くべきではありません。数字ではなく、失敗しうるケースを起点にテストを設計します。同じ行を通る入力値の多様性まで広げたい場合は[プロパティベーステストの入力生成と縮小の仕組み](https://www.issoh.co.jp/tech/details/16259/)が選択肢になります。 ### カバレッジをテスト戦略の中に位置づけ、内製で定着させる運用設計 カバレッジ単体では品質は測れず、テスト全体の設計の中に置いて初めて機能します。どの層にテストを厚く置くかという配分の設計図が[テストピラミッド](https://www.issoh.co.jp/tech/details/13289/)であり、カバレッジは各層で「見ていない箇所」を照らす計器です。層の分類を実行環境の制約で捉え直す[Google流のテストサイズ](https://www.issoh.co.jp/column/details/2360/)と組み合わせると、どの層で何を測るかが整理できます。カバレッジで拾えないのは、仕様の取り違えや設計の妥当性です。ここは[コードレビュー](https://www.issoh.co.jp/tech/details/13384/)で人が補い、数字と人の目を役割分担させます。 この計器と観測の仕組みを社内に根づかせるところが、実装者にとっての本丸です。既存システムの改修と並行してカバレッジ計測をCIに組み込み、差分カバレッジのルールを整え、内製チームが自走できる状態まで持っていくには体力が要ります。既存コードの依存分離やテスト基盤の構築、内製化の伴走を外部と組んで進めたい場合は、[Webシステムの保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で、テスト戦略の設計から運用定着までを一緒に組み立てられます。作って終わりにせず、自走できる状態まで引き渡すことを前提に設計する方針です。 ## テストカバレッジの段階・計測・目標設定でよくある質問への回答 テストカバレッジを実務へ落とし込む際に、検索でよく問われる論点を5つ取り上げます。 ### C0・C1・C2カバレッジの違いを一言でいうと何ですか？ 「どこまで細かく網羅を測るか」の段階の違いです。C0は命令網羅で、すべての実行文を1回通せば達成します。C1は分岐網羅で、if文などの分岐が真・偽の両方向とも実行されて達成という段階です。C2は条件網羅で、複合条件の個々の条件式が真偽両方を取る必要があります。厳しさはC0＜C1＜C2の順で、同じ80%でも段階が違えば検証の深さは大きく変わります。実務ではまずC1で測るのが標準です。 ### テストカバレッジは何%を目標にすればよいですか？ コアなロジックはC1（分岐網羅）で70〜80%前後を一つの目安にし、全社一律の数字は置かないのが現実的です。分岐が絡む料金計算や認証ロジックは高めに、自明なゲッターや設定読み込みは無理に追いません。おすすめは、全体%より変更行に絞った差分カバレッジで管理し、新規コードの抜けをプルリク時点で止める方式です。数字自体を目的化すると中身のないテストが増えるため、目標は優先順位づけの道具として使ってください。 ### カバレッジ100%ならバグは無いと言えますか？ 言えません。カバレッジが測るのは「コードが実行されたか」であって「正しく検証されたか」ではないためです。アサーションを書かず呼び出すだけでも行は通過し、数値は100%になり得ます。また、通っていない入力の組み合わせや仕様の取り違えはカバレッジでは検出できません。100%はバグゼロの保証ではなく、「一度も通っていない箇所は無い」という事実にすぎない、と理解してください。 ### カバレッジはどのツールで測れますか？ 言語ごとに定番があります。JavaはJaCoCo、JavaScript/TypeScriptはIstanbul（nyc）やc8・Vitest内蔵、PythonはCoverage.py（pytest-cov）、C/C++はgcov、RubyはSimpleCov、Goは `go test -cover` が代表です。注意点として、多くのツールは既定で行カバレッジ（C0）しか出さず、分岐（C1）を測るには設定が要ります。Coverage.pyなら `--branch` オプションで分岐計測を有効化します。 ### 差分カバレッジと全体カバレッジはどちらを見るべきですか？ 運用の門番には差分カバレッジ（変更行に絞ったカバレッジ）が向いています。全体%をゲートにすると、テストを書きにくいコードのために閾値を下げる圧力が働き形骸化しがちです。差分に絞れば、新規・変更コードの抜けをその場で止めつつ、レガシーは触ったときに少しずつ改善できます。全体%は長期トレンドの観測用に、差分%はプルリクの合否判定用に、と役割を分けるのが実務的です。 ## 関連記事 - [テストピラミッドとは？単体・結合・E2Eの配分と実装者向けテスト戦略設計](https://www.issoh.co.jp/tech/details/13289/)：カバレッジを各層で読むための配分の設計図 - [単体テストと結合テストはもう古い！Google流テストサイズとは？](https://www.issoh.co.jp/column/details/2360/)：どの層で何を測るかを整理するテストサイズの判断ハブ - [リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断を解説](https://www.issoh.co.jp/tech/details/13008/)：差分カバレッジと組み合わせる回帰の範囲選定 - [E2Eテストとは？目的・他テストとの違い・ツール選定と導入判断まで解説](https://www.issoh.co.jp/tech/details/5470/)：カバレッジ計測にそぐわない上位層の役割分担 - [コードレビューとは？目的・観点・進め方と実装現場の運用設計を解説](https://www.issoh.co.jp/tech/details/13384/)：カバレッジで拾えない仕様・設計の妥当性を補う観点 --- 出典: [テストカバレッジとは？C0/C1/C2の網羅率と計測ツール・目標設定を実装者向けに解説]()（株式会社一創）