ユーザーガイド

1. はじめに

Fucini Coverage Studio は、ビルドがすでに生成しているカバレッジ トレースファイルを、エディター内のファーストクラスなカバレッジに変えます — VS Code でも Visual Studio でも。25 の形式を読み込み、1 つの正規 Fucini モデルに正規化し、複数の実行を決定論的にマージして、エディター自体に表示します — ガター、CodeLens、ホバー、Covered Files ビュー — ので、エディターを離れて別のビューアーを開く必要はありません。2 つのエディションは 1 つのリーダーを共有し、同じレポートから両方で桁まで同じ数値が得られます。このガイドは VS Code を基準に書かれています。Visual Studio が異なる箇所では、In Visual Studio のボックスがその方法を示します。

機能安全のワークフローを念頭に設計されています：MC/DCカバレッジ、リージョンおよびC++インスタンス化カバレッジ、安全性で重み付けされた複合スコア、そしてIEC 61508、ISO 26262、DO-178Cの考え方に沿った設定可能なCOMPLIANT / NON-COMPLIANT判定。

Screenshot pending — add assets/img/marketplace-demo.gif (see SCREENSHOTS.md).

2. インストールと要件

• VS Code 1.88 以降 — この拡張機能がサポートする最小バージョン — または Visual Studio 2022 か 2026、Community、Professional、Enterprise のいずれか（下のボックスを参照）。
• プロジェクトがすでに生成しているカバレッジ トレースファイル（§4 を参照）。

Marketplaceから、または Extensions → ⋯ → Install from VSIX… で.vsixからインストールします。拡張機能は起動時にアクティベートされ、アクティビティバーにCoverageアイコンを追加します。

3. クイックスタート

1. 通常のテストワークフローでカバレッジのトレースファイルを生成します。
2. コマンドパレット（Ctrl+Shift+P）→ Fucini Coverage: Load Coverage。watch.enabledがオン（デフォルト）の場合、一致するファイルが自動的に読み込まれます。
3. カバーされたソースファイルを開きます：ステータスバーにそのパーセンテージが表示され、Coverage ビューが埋まり、行にホバーするとヒット数が表示され、実行がネイティブの Test Coverage パネルに現れます。未カバー行のバー、ヒット数のヒートマップ、インラインの ×N 回数は設定 1 つで有効にできます（editorGutter.mode、hitCounts.inline）。

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

4. トレースファイルの生成

以下のいずれも、読み込み時に自動的に検出されます：

C / C++ — LLVM（llvm-cov）

clang --coverage -fprofile-instr-generate -fcoverage-mapping test.c -o test
LLVM_PROFILE_FILE=test.profraw ./test
llvm-profdata merge -sparse test.profraw -o test.profdata
llvm-cov export ./test -instr-profile=test.profdata --format=json > coverage.json

llvm-cov JSON は最も情報量の多い入力です — 行、ブランチ、関数に加えて、リージョン、MC/DC、C++テンプレートのインスタンス化も含まれます。

C / C++ — GCC（gcov → lcov）

gcc --coverage calc.c calc_test.c -o test && ./test
lcov --capture --directory . --output-file lcov.info
# or gcovr --cobertura coverage.xml
# or skip the conversion entirely: gcovr --json coverage.json

JavaScript / TypeScript — Istanbul / nyc

nyc --reporter=json mocha        # emits coverage/coverage-final.json

Java — JaCoCo

mvn test        # emits target/site/jacoco/jacoco.xml

Ruby — SimpleCov

# .resultset.json (built-in) or coverage.json via the simplecov-json gem

Go

go test ./... -coverprofile=coverage.out    # read directly, no conversion

Python — coverage.py

coverage run --branch -m pytest && coverage json    # emits coverage.json

PHP — PHPUnit (Clover)

XDEBUG_MODE=coverage phpunit --coverage-clover clover.xml

.NET / C# — Coverlet (OpenCover)

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover

ネイティブ C++ プロジェクトを、Visual Studio から計測する

Screenshot pending — add assets/img/vs-native-run.gif (see SCREENSHOTS.md).

5. 読み込みと検出

デフォルトでは、拡張機能はワークスペースのルートからスキャンします。2つの設定でより正確に指定できます：

{
  "fuciniCoverage.coverageFile.defaultLocation": "${workspaceFolder}/build",
  "fuciniCoverage.coverageFile.paths": [
    "coverage.json",
    "reports/*.info",
    "${env:CI_ARTIFACTS}/lcov.info",
    "https://ci.example.com/artifacts/latest/coverage.xml"
  ]
}

• 各 paths エントリは defaultLocation（未設定の場合はワークスペースのルート）からの相対パスです。
• * を含むエントリは再帰的に検索されます。単純なファイル名はベースフォルダ直下でのみ一致します。
• paths が空の場合、拡張機能は coverage.json、次に lcov.info を探し、最初に見つかったものを読み込みます。
• Pick Coverage File は、これらのパスの代わりに選んだファイルを使用します（選ぶたびに追加され、すべてマージされます）。アンロードするか、これらの設定を編集するまで有効です。
• 変数 — すべてのパス設定は ${workspaceFolder}、${workspaceFolderBasename}、${userHome}、${env:NAME}、${command:id}、${config:section.key} を展開します。拡張機能が知らない変数は書かれたとおりに残されるため、打ち間違いは消えてなくなるのではなく、探したパスとして検出ログに現れます。${command:id} は先にそのコマンドを実行します（信頼されたワークスペースでのみ、最大 5 秒）。そのため ${command:cmake.buildDirectory} は選択中の CMake キットに追従します。
• URL の項目 — http(s):// の項目は読み込みのたびに拡張機能のストレージへ取得され、そこから読み込まれます。Coverage ビューは URL を表示します。各取得は条件付き（ETag / Last-Modified）なので、変わっていないアーティファクトは何もダウンロードせず、取得に失敗したときは最後にダウンロードしたコピーが代わりに読み込まれ、理由が出力に記録されます。remote.headers は変数を展開した Name: value ヘッダーを追加し、remote.refreshMinutes はタイマーで再取得し、URL 自体がファイル名で終わらない場合は #lcov.info フラグメントが形式を指定します。
• 無視グロブ — fuciniCoverage.ignore は読み込み時にファイル（ベンダー由来、生成済み、サードパーティ）を丸ごと実行から外すため、すべてのビュー、ゲート、エクスポートがそれら抜きで数えます。読み込み結果はいくつ外されたかを述べ、出力がその名前を挙げます。パターンはワークスペース相対パスと絶対パスに照合され、/ を含まないパターンは .gitignore と同様に任意の深さのフォルダー名またはファイル名に一致します。
• マルチルート ワークスペース — 各フォルダーはそれぞれの条件で検出されます。defaultLocation、paths、pathRemap、ignore、watch.*、remote.* はフォルダーごとに読まれるため、フォルダー自身の .vscode/settings.json や .code-workspace の項目が適用され、項目内の ${workspaceFolder} はその項目自身のフォルダーを意味します。すべてのフォルダーのトレースファイルは 1 つの実行にマージされ、Coverage ビューはファイルをフォルダーごとにまとめ、ワークスペースへのフォルダーの追加や削除はそれ自体でカバレッジを再読み込みします。
• タスク後の再読み込み — watch.reloadAfterTasks に挙げたタスク（tasks.json の label、または Run Task の一覧に表示されるとおりの source: name）の終了時に、watch.enabled のオン・オフにかかわらずカバレッジを再読み込みします。ウォッチャーが追えないビルドのためのものです。ワークスペース外の絶対パスの paths 項目もポーリングされるため、そこに現れたファイルは読み込まれます。
• キャンセルできる進行状況 — 10 個以上、または合計 8 MB 以上のトレースファイルの読み込みは、読み込み中のファイル名と段階を示す「キャンセル」ボタン付きの進行状況の通知の下で走ります。それより小さい読み込みはステータスバーが回るだけです。キャンセルすると前回の実行が読み込まれたまま残り、そう伝えます。

1.2026.6 以降、絶対パスのエントリにもワイルドカードを含められます：${workspaceFolder}/build/coverage-merged/*.lcov.info はそのフォルダーにあるそのようなファイルをすべて読み込み、** は任意の深さを表します。最初のワイルドカードより前のフォルダーが探す場所で、そこは監視されるため、ビルドがそこに書いたレポートは自動で読み込まれます。Visual Studio エディションもそのようなエントリを同じように読み、1.2026.5 以降は相対ワイルドカードもそちらで任意の深さで検索されます — ここでは以前からそうだったとおりに。

paths が設定されていない場合、ベースフォルダー以下で最初に見つかった既知のレポート名が読み込まれます。まず、これまでも常に探していた 4 つ — coverage.json、lcov.info、coverage.out、clover.xml — を、次に 0.2026.83 以降は jacoco.xml、coverage.xml、cobertura.xml、coverage.cobertura.xml、coverage.opencover.xml、coverage-final.json を、さらに既定の構成が出力する場所を探します: coverage/ (nyc、Jest、vitest、PHPUnit、SimpleCov)、target/site/jacoco/jacoco.xml (Maven)、build/reports/jacoco/test/jacocoTestReport.xml (Gradle)、TestResults/*/coverage.cobertura.xml (dotnet test)。そのため Java や .NET のプロジェクトでも、lcov のプロジェクトがこれまでそうであったように、最初に開いた時点でカバレッジが表示されます。

1.2026.3 以降、.NET ソリューションに必要なものはさらに少なくなりました。既知の場所には、ワークスペース フォルダー自身のものだけでなく、各テスト プロジェクトの TestResults/<run>/ フォルダーが含まれ、Microsoft のコレクターの <user>_<machine>_<date>.cobertura.xml も Coverlet の coverage.cobertura.xml の隣で見つかります — そのため、Visual Studio の Test Explorer でテストを実行したソリューションは最初に開いた時点でカバレッジを表示し、すべての実行フォルダーが読み込まれ、マージでは各ファイルについて最新の実行の結果が優先されます。また、既定でオンの fuciniCoverage.ignore.generated は、デザイナー ファイルと生成されたファイル — *.Designer.cs、*.g.cs、*.generated.cs、*.razor.g.cs、AssemblyInfo、グローバル using、Migrations/、obj/ — を、ignore が適用される前にすべての合計、ページ、エクスポートから除外します。したがって、誰もテストしない生成されたテーブルのせいでソリューションがゲートを失うことはありません。

トークンの背後にある CI のアーティファクトを 15 分ごとに再確認します — トークンは環境に置かれ、settings.json には決して入りません：

{
  "fuciniCoverage.coverageFile.paths": [
    "https://ci.example.com/api/builds/latest/artifacts/coverage#lcov.info"
  ],
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:CI_TOKEN}"],
  "fuciniCoverage.remote.refreshMinutes": 15
}

Screenshot pending — add assets/img/remote-tracefile.png (see SCREENSHOTS.md).

再読み込みはあえて何も言いません。ビルドのたびに出るダイアログは、答えが一つしかない質問だからです。黙っていないのは Coverage のアイコンです。ビューが目の前にない間、読み直されたトレースファイルの数を示し、ツールチップがその名前を挙げます。ビューを開けば数は消えます。

Screenshot pending — add assets/img/coverage-badge.gif (see SCREENSHOTS.md).

トレースファイルが何と言おうと、決して数えるべきでないファイル：

{
  "fuciniCoverage.ignore": ["vendor/**", "**/*.generated.ts", "build/**"]
}

ファイルウォッチャーが追えないビルド — シンボリックリンクされた出力ツリーを置き換える実行、ネットワーク共有上のレポート、ファイルを後処理するカバレッジのステップ — のために、テストタスクの終了時に再読み込みします：

{
  "fuciniCoverage.watch.reloadAfterTasks": ["npm: test", "coverage-report"]
}

6. 実行結果のマージ

既存の paths エントリはすべて読み込まれ、一つの実行に統合されます。統合は決定的で、結果は読み込み順に依存しません。複数のトレースファイルが計測したファイルは、ディスク上の mtime が最も新しいものの数値を採用します。つまりモジュール単体の再実行は、より広く古い実行がそのファイルについて述べた内容に加算されるのではなく、それを置き換えます。カバレッジビューはその結果を示します。各ファイル行には数値の出所であるトレースファイル名が付き、その数値が古いレポートを上書きした箇所ではバッジに枠線が付き、ツリー上部の各トレースファイル行には上書きされた、あるいは上書きしたファイル数が表示され、トレースファイル行をクリックすると、もう一度クリックするまでそのファイルがツリー内で強調表示されます（coverageView.mergedMarks で枠線と強調表示をオフにできます）。

Screenshot pending — add assets/img/four-reports-one-file.svg (see SCREENSHOTS.md).

マージされた実行結果には、従来の 6 つのメトリックを超えるものが含まれることがあり、それぞれはそれを計測するレポートに由来します。行、関数、リージョン、分岐、MC/DC、実体化に加えて、関数呼び出し、オブジェクトコード、ミューテーションスコアです。Coverage ビューは、実行結果に含まれるメトリックごとに列を表示し、含まれないメトリックの列は表示しません。列はスコアでの重みが大きい順に並び、幅にかかわらず表示されます。収まらない列は消えるのではなく横にスクロールします。ビューを下部パネルにドラッグすると表になります。ステータスバーのカード、HTML レポート、CSV および Markdown のエクスポートも同じ規則に従います。レポートに含まれるものは表示され、含まれないものはゼロとして出力されるのではなく省かれます。

Screenshot pending — add assets/img/coverage-view-editor.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/coverage-view-columns.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/workspace-overview.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-workspace-overview.gif (see SCREENSHOTS.md).

ファイルがどのレポートから来るか

読み込み済みの複数のレポートが同じファイルを計測しているときは、最も新しいものがそのファイルを丸ごと取ります — モジュール自身の再実行が、より古く広い範囲の実行の結果を置き換えるときには、それが正解です。しかしレポートが意図的に同じコードを計測している場合には誤りです。エディターはビルドのたびに両者の間を行き来し、どれも話の一部しか語りません。coverageFile.sources は、代わりにどうするかをファイルごとに指定します。これが必要になるのは次の 3 つの状況です：

• 一方のレポートの方が優れている。 llvm-cov の coverage.json は MC/DC を含み、同じビルドの GCC の gcov.info には行と分岐しかありません。coverage.json を選び、もう一方は GCC だけがビルドする少数のファイルのために残しておきます。
• 1 つのビルドに複数のテストスイート。 単体テスト、結合テスト、HIL（hardware-in-the-loop）テストがそれぞれレポートを書き出し、どれも単独では他のスイートが実行した行を取りこぼします。結合、union：いずれかのレポートが実行した行はカバー済みとなり、実行回数は合算されます。
• 1 つのコードベース、2 つのコンパイラー。 同じソースを clang と GCC でビルドすると、ツールチェーン固有のコード — こちらでは組み込み関数、あちらでは移植可能なフォールバック — で異なる経路をたどり、それぞれのレポートがもう半分は一度も実行されていないと言います。結合、agree：その行を計測するすべてのレポートが実行した行だけがカバー済みとなり、結果が食い違う行は青緑色で示されます。これはクロスコンパイラーのチェックが問うこと、つまり、出荷するすべてのビルドが実際に何を動かしたのか、という問いです。

ルールを手で書くことはほとんどありません。Coverage ビューでファイルを右クリックしてChoose Coverage Source...を選ぶ（または開いているファイルでChoose Coverage Source for This File...を実行する）と、そのファイルを計測しているすべてのレポートが、それぞれの行、分岐、MC/DC とともに一覧表示され、続いてCombine them — agreeとCombine them — unionが並びます。1 つを選び、それをファイル、そのフォルダー、またはパターンのどれに適用するかを指定します。Clear Coverage Source for This File...でルールを再び取り除きます。設定では、各ルールはファイルに対する glob、レポートに対する glob（/ を含まないパターンはレポートのファイル名にマッチし、{a,b} で複数を指定できます）、そして結合する場合は "combine": "agree" または "union" から成ります。ファイルがマッチし、かつそのレポートがファイルを計測している最初のルールが決定します。1 つのレポートしか計測していないファイルが、そのレポートから外されることはありません。結合されたファイルの分岐、MC/DC、領域は、それらを最も豊富に持つレポートから取られます。coverageFile.mergeStrategy: "order" は、どのルールも扱わないファイルを、時刻ではなく coverageFile.paths の順序で決めます。

{
  "fuciniCoverage.coverageFile.paths": ["clang.json", "gcc/bits.gcov.json.gz"],
  "fuciniCoverage.coverageFile.sources": [
    { "files": "src/**", "report": "{clang.json,bits.gcov.json.gz}", "combine": "agree" }
  ]
}

表示されるもの：Coverage ビューのファイルの行には、数値の出所であるレポートの名前が、結合した場合はすべてのレポートとモードが、食い違う行を示す ≠ n とともに表示されます。ガターと注釈付きソースはそれらの行を青緑色で示し、どのレポートが何回実行したかを示します。ステータスバーのホバーカードは、開いているファイルの取得元と、実行全体について有効なルールおよび他のファイルがどう決まったかを示します。デモの samples/c-cross-check が 2 つのコンパイラーのケースで、すぐに開けます。Visual Studio でもこのすべてが行えます。Coverage ビューの行で Choose Coverage Source...、Tools > Coverage Studio で Choose と Clear Coverage Source for This File... を使います。

取得元の選択と結合は有料プランの機能です。Community では、ルールがない場合と同様に最新のレポートがすべてのファイルを取り、設定内のルールは黙って無視されるのではなく、使われていないと明示されます。

7. パスの再マッピング

CIは、ワークステーションに存在しない絶対的なビルドマシンのパスを記録することがよくあります。順序付けられたルールでそれらを書き換えます：

{
  "fuciniCoverage.pathRemap": [
    { "from": "/builds/ci/project", "to": "${workspaceFolder}" },
    { "from": "\\\\", "to": "/" }
  ]
}

ルールは順に適用され、各プレフィックスについて最初に一致したものが優先されます。これを使って Windows/Unix のセパレータの違いを解消したり、コンテナのパスをチェックアウトにマッピングしたりします。

ルールを自分で書く必要はめったにありません。「読み込まれたのに何も点灯しない」の最も多い原因は、ワークスペースには src/a.c があるのに、トレースファイルのパスがコンテナや CI のチェックアウト（/build/src/a.c、/home/runner/work/repo/repo/src/a.c、C:\agent\_work\1\s\src\a.c）に由来していることです。読み込みで一致しないファイルが残ると、拡張機能はそのファイル名をワークスペースで探し、最も多くを説明するプレフィックスのルールを推定し、[FUCINI_REMAP_002] として記録し、読み込み結果に Apply Suggested Remap を提示します — 1 クリックでルールが fuciniCoverage.pathRemap に追記され、再読み込みされます。Suggest Path Remap Rule は同じ解析をパレットからオンデマンドで実行します。クリックしなければ何も書き込まれません。

to では ${workspaceRoot} を使えます。これはトレースファイルのあるワークスペース フォルダーを表し、マルチルート ワークスペースではまずそのフォルダーを、次にそのファイルを持つことが分かったほかのすべてのフォルダーを試します。ルール自体はフォルダーごとに読まれるため、マルチルート ワークスペースの各ルートが独自のルールを持てます。

8. エディタ内カバレッジ

• ガターとルーラー — 既定では、エディター自身のガターは所見だけを示します。MC/DC のバー、前回の実行以降の三角形、編集行のドットです。editorGutter.mode で未カバーのみのバーやヒット数のヒートマップを加えられます（後述）。ファイル全体の色分け表示は Annotated Source です。
• 関数CodeLens — 各関数の上に表示されるカバレッジ％。クリックすると最初の未カバー行にジャンプします。codeLens.enabled で切り替えます。
• ブランチおよびMC/DCホバー — 判定行にホバーすると、分岐ごとのTaken/Not-Taken回数と条件ごとのベクターテーブルが表示されます。mcdcGutter.enabled で色付きのマージンバーを有効にします。
• デッドコード警告 — 測定可能な行があり、カバレッジがゼロの関数はProblemsパネルでフラグが立てられます（deadCode.enabled）。
• Next / Previous Uncovered — 未カバー箇所間をジャンプします。
• ステータスバー — 実行全体の $(dashboard) NN% 項目とファイルごとの項目があり、両方とも複合スコアに応じて色分けされます。ホバーすると完全なメトリクステーブルが表示されます。
• エクスプローラーバッジ — ファイルごと・フォルダーごとのカバレッジバッジ。ホバーでメトリクスの内訳を表示。 既定はオフです。explorerBadges.enabled でオンにできます。
• 前回の実行以降 — 前回実行され今回実行されなかった各行に赤い三角形、逆に緑の三角形。概要ルーラーとホバーのヒット数付き。
• 編集中のバッファ — 編集に合わせてすべてのマーク、ホバー、CodeLens がテキストと一緒に移動し、書き換えた行からは退き、灰色の点がその理由を示します。
• インラインのヒット数 — hitCounts.inline は文が始まる各行の後ろに ×12 を書き込みます。×0 も含めて。ホバーすれば以前から見えていた数値を、ホバーせずに。Toggle Inline Hit Counts で切り替え、ステータスバーのメニューではその時点に応じて Show または Hide として提示されます。
• 行ごとの Problems 項目 — problems.perLine は、開いているドキュメントで一度も実行されなかった連続する行のブロックごとに、エディター内の波線付きの Information 診断を置き（40 行のデッド関数は 40 項目ではなく 1 項目）、uncoveredAndPartial ではさらに、分岐のアームが一度も通らなかった各行にも置きます。項目は編集に合わせて行に追従し、ドキュメントを閉じると消えます。problems.enabled の背後にあるファイルごとの項目は変わりません。
• 行の色付け — lineHighlight は、ガターが示す内容に合わせて行そのものの背後に半透明の色を敷きます（uncovered、実行された行も含めるなら heatmap）。独立した設定なので、ガターは何も描かずに未実行行だけ色付ける、あるいはその逆ができます。
• 概要ルーラー — overviewRuler はスクロールバーの線をガターとは別に決めます。follow（バーと一緒に、従来どおり）、uncovered（常に。ガターをオフにしてもスクロールバーはギャップの地図を示します）、off のいずれかです。
• その行をカバーしたトレースファイル — 複数のレポートをマージしていると、実行回数のホバーの最後に カバー元: とその行をカバーしたレポートが並びます（lcov の TN: のスイート名も含みます）。Coverage ビューでトレースファイルの行をクリックすると、そのファイルが測定した行が開いているすべてのエディターで光ります。

Screenshot pending — add assets/img/codelens-hover.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/codelens-crap.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/jump-between-gaps.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/explorer-badges.png (see SCREENSHOTS.md).

エディターのガターモード

editorGutter.mode は、常に表示される所見に加えて、エディター自身のガターがカバレッジについて何を示すかを決めます。off（既定）はその所見だけです。uncovered は一度も実行されなかったすべての行にバーを、分岐のアームが一度も通らなかったすべての行に琥珀色のバーを置き、カバー済みの行には何も置きません。緑の壁が 3 本の赤を隠さないためです。coverage はカバー済みのすべての行に緑のバーを加えるので、ファイル全体がカラースケールの色で赤・琥珀・緑として読めます。heatmap は代わりに実行されたすべての行に暖色を加え、実行回数が多いほど濃くなります。これは行がカバーされているかどうかではなく何回実行されたかを示すため、100% のファイルもここでは黄色から茶色になり、緑にはなりません。Choose Editor Gutter Mode... はパレットまたはステータスバーのメニューから 1 つを選びます。ステータスバー右端のモードボタン、または Alt+G は、1 回押すごとに次のモードへ進みます（statusBar.showModeToggle でボタンを非表示にできます）。どちらも設定に書き込みます。例では未カバーのバーとインラインの回数を一緒にオンにします：

{
  "fuciniCoverage.editorGutter.mode": "uncovered",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

ヒートマップはファイルに対して相対的です。行の濃淡は、その行の回数を同じファイル内で最も多く実行された行と、対数スケールで 5 段階に比較したものです。そのため、1000 回実行されたループ本体と 2 回実行された関数は、一方が他方をかき消すことなくどちらも見て取れます。また、すべてがちょうど 1 回ずつ実行されたファイルは、一様に淡くなるのではなく一様に暖かい色になります。ダークテーマでは色の段階は鈍いオリーブから鮮やかなオレンジへ、ライトテーマでは淡い黄色から茶色へと変化します。どちらの場合も色が濃いほど実行回数が多いことを意味し、赤は一度も実行されなかった行のために確保されています。lineHighlight: "heatmap" は同じ濃淡をコードの背景に薄く敷き、hitCounts.inline は正確な回数を行の後ろに書き込みます。

{
  "fuciniCoverage.editorGutter.mode": "heatmap",
  "fuciniCoverage.lineHighlight": "heatmap",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/heatmap-dark.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap-light.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap.gif (see SCREENSHOTS.md).

色は自由に選べます。colorScale.lowColor、midColor、highColor が、ガター、背景の色付け、そしてすべてのパーセンテージの赤・琥珀・緑を塗ります。heatmap.colors と heatmap.colorsDark は、ライトテーマとダークテーマ用のヒートマップの 5 段階の濃淡を、最も実行回数の少ない行から最も多い行まで保持します。設定ページでは保存する前に結果を確認できます。Colour scale の下では、行がスクロールしていってもプレビューが表示されたままです — 2 つのピボットを持つグラデーション、それぞれの色で示したいくつかのパーセンテージ、そして coverage モードとヒートマップで塗った小さなライトのエディターと小さなダークのエディター — そして色を選ぶたびに再描画されます。

{
  "fuciniCoverage.heatmap.colors": ["#e3f2fd", "#90caf9", "#42a5f5", "#1e88e5", "#0d47a1"]
}

行のうち実行されなかった部分

行はカバーされているか、いないかのどちらかですが、実態はその中間にあることが少なくありません。return x > hi ? hi : x; は実行されたものの、その hi 側は一度も実行されていない、という場合です。lineHighlight を有効にすると、列範囲を持つすべての形式 (llvm-cov、Istanbul、Go、dotnet-coverage) について、実行された行のうち一度も実行されなかった部分がエディター上で色付けされます。注釈付きソースがマークするのと同じ範囲です。対象は実行された行だけです。一度も実行されなかった行は、すでに行全体がマークされています。C++ のテンプレートは、いずれかのインスタンス化が実行した箇所を実行済みとして数えます。個々のインスタンス化が何をしたかは、インスタンス化メトリクスが報告します。

Screenshot pending — add assets/img/partial-line.png (see SCREENSHOTS.md).

この行を実行したテスト

レポートによっては、行が実行されたことだけでなく、どのテストが実行したかまで記録しています: .coveragerc に dynamic_context = test_function を設定し coverage json --show-contexts で書き出した coverage.py、-coverbytest を付けて収集した OpenCover、そしてテストごとに 1 セクション（TN:）で書かれた lcov トレースファイルで、そのセクションは行ごとのテストを持つ 1 つのレコードに合算されます。ヒット数が表示されている行頭にホバーすると、テスト名が表示されます — クラス名とメソッド名に短縮され、最初の 5 件は名前で、残りは件数で示されます。関数の CodeLens は、いくつのテストがそれを実行したかを示します。Show Tests That Ran This Line — Command Palette、エディターのコンテキスト メニュー、Visual Studio では Tools → Coverage Studio または Ctrl+Shift+U, T — はそれらを実行回数の多い順に一覧し、選んだものをワークスペース内の定義の場所で開きます。dotnet test の実行は、どのテストが何を実行したかを語れません。testRun.perTest を設定すると、Run Tests with Coverage がテスト クラスを列挙して 1 つずつ実行し、各レポートにそのクラスのタグを付けるので、ホバー、レンズ、コマンドが .NET でも答えられるようになります。この情報はファイルごとに保持されるため、テストについて何も知らないレポートとマージしても失われません。

{
  "fuciniCoverage.testRun.perTest": true
}

# .coveragerc
[run]
dynamic_context = test_function

coverage run -m pytest && coverage json --show-contexts

Screenshot pending — add assets/img/tests-per-line.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/tests-for-line.gif (see SCREENSHOTS.md).

マークで見る成功と失敗

カバー済みの行は、そのテストが成功しても失敗しても同じに見えます。どのテストが行を実行したかをレポートが記録していて、かつそれらがどう終わったかをランナーの結果ファイルが記録している場合、失敗したテストが実行した行には、行頭に赤いバーと概要ルーラーのストライプが付きます。ホバーは失敗したテストの名前を挙げ、Show Tests That Ran This Line はそれぞれの横に failed と書きます。テストが赤いときに見るべき場所は、そのテストが通ったコードです。結果は読み込みのたびに、各レポートのフォルダーから — すべての .trx と、JUnit 形式で書き出すツールが使う名前（TEST-*.xml、junit*.xml、test-results*.xml） — そして testResults.paths から、フォルダーからの相対パスまたはグロブとして読み取られます。Run Tests with Coverage は dotnet test にレポートの横へ test-results.trx を書き出させるので、testRun.perTest がオンなら何も設定する必要はありません。testResults.enabled で読み取りをオフにできます。

{
  "fuciniCoverage.testResults.paths": ["build/test-results/**/*.xml", "reports/junit.xml"]
  }

Screenshot pending — add assets/img/pass-fail.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-pass-fail.gif (see SCREENSHOTS.md).

変更が触れるテスト

フル実行なら時間をかけて答える問いに、Run Tests Affected by My Changes… はすぐに答えます: すべてのテストのうち、いま編集したコードを通ったのはどれか。git に testImpact.baseRef に対する作業ツリーの差分を尋ね — 既定は HEAD で、まだコミットしていないものが対象です。origin/main ならブランチが変更するすべてが対象です — 変更された行を実行したテストを、変更を最も多く実行したものから順に一覧します。テストを選ぶとそれが開きます。レポートがテストごとの実行（testRun.perTest）によるものなら、最初の項目でそれらのテストだけを実行できます。クラスごとに別のレポートに書き出されるので、ほかのクラスのレポートはそのまま残り、合計はスイート全体のままです。挿入や削除より下の行だけを実行したテストも一覧に入ります。そうしないと、そのレポートが誤った行を指すことになるからです。

Screenshot pending — add assets/img/test-impact.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-test-impact.gif (see SCREENSHOTS.md).

すべての行を実行できる最少のテスト

Show Minimal Test Set… は、同じテストごとの行から 2 つの問いに答えます: スイートが実行するすべての行を、どの少数のテストなら実行できるか — コミット前の手早い実行用です — そして、ほかのテストがすでに実行している行しか実行しないテストはどれか。選ばれたテストが先に並び、それぞれに、そのテストが加える行とそのテストだけが実行する行が示されます。続いて残りが、何も加えないという印付きで並びます。選び方は貪欲法です — 最も多く実行するテスト、次にそれに最も多く加えるテスト — そのため最小の集合に近く、毎回同じ結果になります。行の上で冗長でも、テストが検証する内容まで冗長とは限りません: 行を加えないテストが、それらの行の値をアサートする唯一のテストかもしれません。この一覧は、スイートを整理するときにどこを見るべきかを示すもので、何を削除すべきかを示すものではありません。

Screenshot pending — add assets/img/minimal-test-set.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-minimal-test-set.png (see SCREENSHOTS.md).

このテストを、カバレッジ付きで実行する

キャレットをテストに置いて Run This Test with Coverage を実行すると — Command Palette、エディターのコンテキスト メニュー、Visual Studio では Tools → Coverage Studio または Ctrl+Shift+U, R — そのテストだけがカバレッジ付きで実行されます: キャレットのあるテスト メソッド、メソッドの間にあればテスト クラスや describe ブロック、すべてのクラスより上にあればファイルです。キャレットの下にあるものはテキストから読み取られるため、どの言語サービスがインストールされていても、C#、VB、F#（[Fact]、[Test]、[TestMethod] など）、JavaScript と TypeScript（it、test、describe）、Python（def test_…）で動作します。フォルダーのレシピはそれに絞り込まれ — dotnet test --filter "FullyQualifiedName~…"、jest または vitest <file> -t "…"、pytest のノード ID — 書き出されたものはほかの実行と同じように読み込まれます。絞り込めないランナーはそう伝え、Run Tests with Coverage がすべてを実行します。

Screenshot pending — add assets/img/run-this-test.gif (see SCREENSHOTS.md).

Go と Rust。Go のファイルでは、キャレットのある func TestXxx（または Fuzz…、Example…）が、それ自身のパッケージで、正確な名前を指定して単独で実行されます — go test ./pkg/calc -run "^TestTotal$" — テストの外では、そのファイルのパッケージが実行されます。Rust のファイルでは、#[test] の関数がクレート内のパスと --exact で実行されます。キャレットが mod の中にあってどのテストの中にもなければ、そのモジュールのテストが実行されます。tests/ の下の統合テストは、それ自身のバイナリで実行されます（--test api）。ランナーに渡されるのはそのランナーの言語のファイルだけです: Go のフォルダーにある TypeScript ファイルでは、空の実行ではなくメッセージが 1 文表示されます。

保存のたびにカバレッジ

testRun.onSave をオンにすると、ソースを保存したとき、保存の少し後に、そのソースをカバーするテストがカバレッジ付きで実行され、ガターが追従します。.NET ソリューションでは、保存したファイルのプロジェクトが .csproj のグラフから見つけられ、それを — 直接に、またはほかのプロジェクトを介して — 参照するテスト プロジェクトだけが、それぞれ 1 回の dotnet test <project> で実行されます。それ以外のランナーはレシピ全体を実行します。どのプロジェクトにも属さず、どのレポートにも計測されないファイルでは何も実行されません。連続した保存は 1 回の実行にまとめられ、進行中の実行は中断されません。それ以外は Run Tests with Coverage と同じです: ターミナル、Output ペイン、読み込まれるレポート。既定ではオフです — 自分で選んで身につける習慣であって、見つけてしまう既定ではないからです。

{
  "fuciniCoverage.testRun.onSave": true
}

Screenshot pending — add assets/img/coverage-on-save.gif (see SCREENSHOTS.md).

アプリそのものを、カバレッジ付きで

テストの実行は、テストがどこまで到達するかを示します。人が到達するところ — リリース前に画面を順にクリックしていく、顧客の手順を再現する — もカバレッジであり、Run App with Coverage… がそれを収集します。フォルダーの .NET アプリ — Exe、WinExe、Web プロジェクトまたはワーカー プロジェクトで、テスト プロジェクトは対象外です。複数あれば選択します — が、Microsoft の dotnet-coverage の下で専用のコンソールで起動されます。コンソール アプリに入力できるようにするためで、閉じるまで実行され続けます。操作して通った部分は、ほかの実行と同じように読み込まれ、カバレッジ セッション中ならテストが実行した分に加算されます。アプリがどう終了したかは、実行の扱いに影響しません。ツールのインストールが一度だけ必要です: dotnet tool install --global dotnet-coverage。

Screenshot pending — add assets/img/run-app.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-run-app.gif (see SCREENSHOTS.md).

ミュータントとその場所

ミューテーションツール — Java 向けの PIT、JavaScript、C#、Scala 向けの Stryker、C と C++ 向けの Mull — は、コードに小さな変更を加え、その変更ごとにテストを実行します。どのテストも気付かなかった変更が生存ミュータントです。コードは実行されたのに、その動作を誰も検証しなかったということです。ミューテーションスコアは捕捉された数を示しますが、0.2026.83 以降、エディターは残りがどこにあるかを示します。生存ミュータントのある行には行末に注記 (⚑ 2 mutants survived) が付き、レポートがどのテキストかを示している場合 (Stryker と Mull が該当) は変更されたテキストに下線が引かれ、概要ルーラーにはストライプが表示されます。ホバーすると、何が変更されたか、いくつのテストがそこを実行したか、そして捕捉されたミュータントについてはどのテストが捕捉したかが表示されます。

Screenshot pending — add assets/img/mutant-hover.png (see SCREENSHOTS.md).

生存は、テストが変更されたコードを実行し、すべて成功したことを意味します。未テスト (レポート上の no coverage) は、そのコードを実行するテストがまったくなく、したがって何も気付きようがなかったことを意味します。捕捉されたミュータントはホバーで件数が示されるだけで、マークはされません。また、コンパイルできないミュータントのように、そもそも公正なテストにならなかったものはスコアの対象外です。注釈付きソースでは該当する行の下にそれぞれ行が追加され、Next Mutant ボタン (U) が用意されています。HTML レポートには、該当行へリンクする Surviving Mutants セクションがあります。有効化の操作は一切不要で、ミューテーションレポートのないプロジェクトには何も表示されません。

Screenshot pending — add assets/img/mutants.gif (see SCREENSHOTS.md).

テストは気付くか。キャレット位置でのミューテーション実行

プロジェクト全体のミューテーション実行には 1 時間かかりますが、関数 1 つなら 1 分です。Run Mutation Tests Here はその 1 分を実行します: キャレットのある関数 — または選択した行、またはファイル — を変異させるようフォルダーのミューテーション ランナーに指示し、そのレポートを画面上のカバレッジと並べて読み込み、生存ミュータントに印を付けます。C# では Stryker.NET（dotnet tool install --global dotnet-stryker）で、文字の範囲と、ファイルのプロジェクトを参照するテスト プロジェクトを指定します。JavaScript と TypeScript では StrykerJS で、行を指定します。Java では Maven を使う PIT で、クラスを指定します。ランナーがどう終了したかは、実行の扱いに影響しません: スコアがしきい値を下回っても終了コードが変わるだけで、レポートは得られます。何も書き出さなかったランナーについては、インストールが必要なものとともにそのことを伝えます。

Screenshot pending — add assets/img/mutation-here.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mutation-here.gif (see SCREENSHOTS.md).

VS Code 自身の Test Coverage ビュー

testCoverage.publish がオン（既定）なら、読み込まれたすべての実行はエディターのネイティブな Test Coverage ビュー — Test Explorer のカバレッジパネル、それが Explorer に置くファイルごとのパーセンテージ、エディター自身の Show Inline Coverage トグル — にも、行、分岐のアーム、関数として届きます。詳細はオンデマンドで読み込まれ、どのトレースファイル由来でも、テストアダプターは一切関与しません。Show in Test Coverage View は設定にかかわらずアクティブな実行を公開してパネルを開きます。ステータスバーのメニューでは quickActions.showTestCoverage の背後で提供されます。オフなら、Test Explorer に Fucini Coverage の項目はまったく現れません。トレースファイルがテスト名を持つ場合（lcov の TN: セクション）、各テストが Test Explorer の Fucini Coverage の下に表示され、ビューでファイルのカバレッジをテストごとに絞り込めます。

Screenshot pending — add assets/img/test-coverage-view.png (see SCREENSHOTS.md).

Problems パネルの未カバー行

本質的にノイズが多いため既定ではオフで、対象は常に開いているドキュメントだけです — 2,000 ファイルの実行がパネルを溢れさせることはありません。ファイルごとに 1 項目にとどめる problems.enabled とは独立です：

{
  "fuciniCoverage.problems.perLine": "uncoveredAndPartial"
}

Screenshot pending — add assets/img/problems-panel.png (see SCREENSHOTS.md).

9. 差分カバレッジ

gitのベース参照と比較して変更された行のみに装飾を制限します — PR が実際にカバーした部分・していない部分を正確にレビューするのに最適です：

{
  "fuciniCoverage.gitDiff.enabled": true,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
}

Screenshot pending — add assets/img/diff-coverage.png (see SCREENSHOTS.md).

新しいコードのゲート

threshold.newCode は、実行全体のゲートと並ぶ独立したゲートです: gitDiff.baseRef に対して変更された行のうち計測可能なものについて、実行されていなければならない最低のパーセンテージです。全体で 62% のプロジェクトでも、今日書いたものがテストされていることは求められます。読み込みのたびに実行全体から数えられ、実行全体は画面に残ります — gitDiff.enabled は別のもので、実行の代わりに変更された行を表示します。Check Coverage Thresholds と Problems のコンプライアンス項目は、これを専用の 1 文で不合格にします: New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran)。計測可能な行のない変更 — コメント、README — は何も不合格にしません。

{
  "fuciniCoverage.threshold.newCode": 80,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
  }

Screenshot pending — add assets/img/new-code-gate.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-new-code-gate.png (see SCREENSHOTS.md).

タグ、作成者、日付で決める新しいコード

新しいコードとは、既定では、作業ツリーが gitDiff.baseRef に対して変更する行です — ブランチ、コミット、またはタグを指定でき、"v1.4.0" ならそのリリース以降のすべてです。参照では表せないことを、2 つの設定が尋ねます。gitDiff.author は作成者名の一部を取り、新しいコードは git がその作成者のものとする行になります。gitDiff.since は日付を取り、どのブランチから入ってきたかにかかわらず、その日以降に最後に変更された行になります。両方を指定すると、その作成者のその日以降の行です。これらは git blame からファイル 1 つずつ読み取られ — 大きな実行では読み込みのたびにその負担が出ます — 差分カバレッジと上記のゲートで、差分の代わりに使われます。まだコミットしていない行は、どちらの場合も数えられます。

{
  "fuciniCoverage.gitDiff.author": "Ada",
  "fuciniCoverage.gitDiff.since": "2026-09-01"
  }

Screenshot pending — add assets/img/new-code-author.png (see SCREENSHOTS.md).

間接的な変化: 誰も触れていないのに動いたもの

差分はどの行が変わったかを示し、2 つの実行はどの行が実行されなくなったか、実行されるようになったかを示します。見る価値があるのは、この 2 つが食い違う行です: 誰も編集していないのに実行されなくなったコードで、テストが削除された、上流の分岐が早期に return するようになった、フィクスチャが変わった、といったことが原因です。差分のレビューではそれらは見えません — 定義上、差分の外にあるからです。Show Indirect Coverage Changes… はそれらをファイルごとに、最も多く失ったファイルから順に一覧し、選んだファイルをその最初の該当行で開きます。実行は、baseline.report が CI ベースラインを指していればそれと比較され — プル リクエストが評価される基準です — そうでなければ 1 つ前の実行と比較されます。作業ツリーが gitDiff.baseRef に対して変更する行と、その変更によってファイルの行がずれる箇所より下のすべては、対象から外されます。

Screenshot pending — add assets/img/indirect-changes.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-indirect-changes.png (see SCREENSHOTS.md).

10. 複合スコア

拡張機能は、6つの数値を報告する代わりに、それらを単一の加重調和平均（WHM）にまとめます。パーセンテージ pᵢ と重み wᵢ を持つメトリクスの場合：

WHM = ( Σ wᵢ ) / ( Σ wᵢ / pᵢ )

調和平均はその最小の項によって支配されるため、弱い指標が完璧な指標によってマスクされることはありません — これはまさに安全ゲートに求められる特性です。デフォルトの重み：

任意の重みを 0 に設定すると、そのメトリクスをスコアから除外できます。データに存在しないメトリクス（例：プレーンなlcov実行におけるMC/DC）は単純に省略されます。

オブジェクトコードとミューテーションスコアの重みは、変更しない限り 0 です (whmWeights.objectCode、whmWeights.mutation)。オブジェクトコードカバレッジはステートメントカバレッジを包含するため、両方に重みを与えると同じ証拠を二重に数えることになります。ミューテーションスコアはそもそもカバレッジではありません。テストスイートがすべての行を実行しながら、何も検出しないこともあり得ます。それでも、どちらにも専用の列と専用の閾値があります。

Screenshot pending — add assets/img/score-weights.svg (see SCREENSHOTS.md).

条件カバレッジ

a && b は 1 つの判定 — 2 つの分岐 — であり、4 つの結果を持つ 2 つの条件でもあります。テストスイートが両方の分岐を通っていても、b が偽になる場合を一度も見ていないことがあり得ます。このとき分岐カバレッジは完全でも、条件カバレッジは 4 分の 3 です。この水準は DO-178C と ISO 26262 において分岐カバレッジと MC/DC の中間に位置し、0.2026.83 以降は分岐に含めるのではなく独立したメトリクスになりました。ステータスバーのカードの 1 行、Coverage ビュー・レポート・エクスポートの 1 列、スコアでの重み 3 (whmWeights.conditions)、そしてゲート (threshold.conditions。standard プロファイルではゲート対象外、safety では 100) として扱われます。

Screenshot pending — add assets/img/branch-condition-mcdc.svg (see SCREENSHOTS.md).

BullseyeCoverage の condition プローブ、TRACE32 の cond エクスポート、および -fcondition-coverage を付けてビルドした GCC 14 から読み取ります。条件と判定を区別しないレポートには、この行も列も重みもありません。Bullseye または TRACE32 をお使いの場合: これまで条件は分岐として数えられていたため、このリリースで分岐のパーセンテージが変わり、新しい重みによって複合スコアも変わります。以前と同じスコアにするには、whmWeights.conditions を 0 に設定してください。

GCC 14 を行ごとに。-fcondition-coverage を付けると、gcov はどの条件のどの結果が欠けているかを示します — 条件 1 は一度も真にならず、条件 0 は真にも偽にもならなかった — 各条件はその行に印が付き、ホバーで名前が挙がります。gcov の JSON からも、テキストの一覧（condition outcomes covered 3/6）からも読み取ります。このメトリックは、ほかのメトリックと同じ場所にあります: threshold.conditions がゲートになり、実行にその数値がなければ判定されません。Copy Coverage Summary には Conditions 列があり、badge.metric は conditions を取り、検索ボックスは conditions < 80 を受け付けます。関数の分岐の数値には、ファイルや実行の数値と同じく、条件の結果は含まれません。

Screenshot pending — add assets/img/gcc-conditions.png (see SCREENSHOTS.md).

複雑度と CRAP

一部のレポートには、各関数の循環的複雑度が含まれています。OpenCover (Coverlet が出力する形式)、JaCoCo、Clover、Cobertura です。その場合、拡張機能はその複雑度と自ら計測したカバレッジから、関数の CRAP スコア (Change Risk Anti-Patterns) を算出します:

CRAP = complexity² × (1 − coverage)³ + complexity

単純で完全にテストされた関数のスコアは、その複雑度そのものになり、それ以上にはなりません。複雑でほとんどテストされていない関数のスコアは数百に達します。デモプロジェクトの C# サンプルでは、Price() は複雑度が 22 で行の約 37% がカバーされており、スコアは 142.2 になります。一方、Shipping() は複雑度が 12 で完全にカバーされており、スコアは 12 です。慣例的な境界線は 30 です。これ以上の関数は、HTML レポートの Riskiest Methods に、スコアの悪い順に一覧表示されます。

Screenshot pending — add assets/img/crap-curve.svg (see SCREENSHOTS.md).

複雑度とスコアは、関数の CodeLens と、注釈付きソースの関数の横に表示されます。Max CRAP は、ファイル内の関数の中で最も高いスコアです。平均ではなく最悪の値であり、Coverage ビュー、HTML レポート、CSV および Markdown のエクスポートに列として表示されます。これは参考情報であり、閾値はなく、複合スコアにおける重みもありません。複雑度を含まないレポート (lcov、gcov、Istanbul、coverage.py) には CRAP がなく、空の列も表示されません。

0.2026.83 以降、C と C++ でも利用できます。llvm-cov は複雑度を報告しないため、レポートがすでに持っている分岐データから数えます。関数自身のファイルに書かれた条件の数に 1 を加えた値で、これは McCabe の定義であり、.NET や Java 向けのソースレベルのツールが数えるものと同じです。別のファイルのマクロから展開された条件 — たとえばすべての assert — は数えません。

Screenshot pending — add assets/img/riskiest-methods.png (see SCREENSHOTS.md).

Risk hotspots と、どのファイルを表示するか

Coverage ビューのツリーの下で、Risk hotspots は複雑なコードとわずかなカバレッジが重なる関数を最悪のものから順に一覧し、それぞれがその関数の位置でファイルを開きます。関数は CRAP スコア — hotspots.crapThreshold、既定で 30、この指標の考案者が提案した値 — か、循環的複雑度のみ — hotspots.complexityThreshold、既定ではオフ — によって該当します。複雑度を含むレポート(OpenCover、Coverlet の Cobertura、JaCoCo、llvm-cov)だけにホットスポットがあります。Community では件数と最悪のスコアが見え、順位付きの一覧は Pro です。並べ替えの隣にある 2 つ目のドロップダウンは、ツリーがどのファイルを表示するかを指定します — すべて、ギャップのあるファイル、未テストのファイル、または前回の実行以降に変更されたファイル。フォルダーはそのファイルに従い、自身の数値を保ちます。どちらも Visual Studio の Coverage ウィンドウにもあります。

Screenshot pending — add assets/img/vs-hotspots.png (see SCREENSHOTS.md).

名前空間、クラス、メソッド

クラス名を含む .NET レポート — Cobertura や Coverlet の coverage.cobertura.xml、OpenCover — では、3 つ目のドロップダウン Folders / Namespaces が同じ実行を名前空間、クラス、メソッドとして描きます: 名前空間の数値はそのクラスの合計、クラスの数値はそのメソッドの合計で、フォルダーの数値がそのファイルの合計であるのとまったく同じく、同じ並べ替えと同じフィルターが使えます。メソッドの行はファイルをそのメソッドの位置で開きます。名前空間なしで宣言されたクラスは (no namespace) の下に入ります。選択は coverageView.perspective に書き込まれます。クラス名を含まない実行にはドロップダウンがなく、フォルダーが表示されます。Visual Studio では Coverage ウィンドウに同じドロップダウンがあります。

Screenshot pending — add assets/img/namespace-perspective.png (see SCREENSHOTS.md).

ツリーを検索する

ボタンとドロップダウンの下に、検索ボックスがあります。単語は、名前またはパスにそれを含む行を残します — 入力したすべての単語が含まれていなければなりません。比較は、数値がそれを満たす行を残します — スコアに対する < 80%、lines >= 90、branches = 0、functions != 100、mcdc < 50 — そして invoice < 80 は両方を要求します。名前空間パースペクティブのメソッド行とリスク ホットスポットもファイルと一緒に検索されるため、関数は実行がそれを持つ場所で見つかります。ツリーは入力するそばから、ページ内で再描画なしにフィルターされます。一致を含むフォルダーはそのために開き、ボックスが空になると再び閉じます。Esc でクリアします。Visual Studio でも同じボックス、同じ文法です。

Screenshot pending — add assets/img/tree-search.gif (see SCREENSHOTS.md).

ツリーがエディターに追従

いま見ているファイルが Coverage ビューで強調表示され、その上のフォルダーが開かれ、その行が見える位置までスクロールされます — すでに開いているファイルをツリーで探す必要はもうありません。それ以外ではツリーはスクロール位置を保ち、再描画も行われません。ツリーを自分で置いた位置のままにしたい場合は、既定でオンの coverageView.followActiveEditor でオフにできます。

Screenshot pending — add assets/img/follow-editor.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-follow-editor.gif (see SCREENSHOTS.md).

11. コンプライアンスゲーティング

COMPLIANT / NON-COMPLIANT 判定（注釈付きソースビュー、HTMLレポート、両方のステータスバーホバーに表示）は、メトリクスごとの閾値とモードによって決まります：

Screenshot pending — add assets/img/statusbar.png (see SCREENSHOTS.md).

閾値を 0 にするとそのゲートはオフになり、レポートに含まれないメトリックは判定されません。設定していない閾値が何を意味するかは、以下のプロファイルによって決まります。Fucini Coverage: Check Coverage Thresholds を実行すると、オンデマンドで評価できます。

Screenshot pending — add assets/img/vs-error-list.png (see SCREENSHOTS.md).

閾値プロファイル

threshold.profile は、設定していない閾値が何を意味するかを決定します。0.2026.82 以降のデフォルトである standard は、安全関連ではない通常のプロジェクトに求めることのできる水準です。safety はすべてのゲートを 100 にします。これはセーフティケースが要求する水準であり、0.2026.81 までの出荷時の動作そのものです。

自分で設定した閾値は、どちらのプロファイルよりも優先されます。この例では分岐を 90、それ以外をすべて 100 でゲートしています。一部のメトリックだけを 100 に保ちたい場合は、standard のままにして、それらを自分で設定してください。設定の仕組みに起因する注意点が 1 つあります。出荷時のデフォルトと等しい値は、値がまったく設定されていない状態と区別できません。そのため safety では、標準の数値とまったく同じ値として記述された閾値 (たとえば行の 80) は、やはり 100 として扱われます。

{
  "fuciniCoverage.threshold.profile": "safety",
  "fuciniCoverage.threshold.branch": 90
}

Screenshot pending — add assets/img/threshold-profile.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/threshold-profiles.gif (see SCREENSHOTS.md).

以前のデフォルトに依存していた場合、0.2026.82 への更新後は、safety を選択するまで、より緩やかに判定されます。以前から使用されていたインストールには、そのことが一度だけ通知され、プロファイルをユーザー設定に書き込む Keep 100% (safety) ボタンが表示されます。共有プロジェクトの場合は、全員が同じ基準で判定されるよう、ワークスペース設定にも記述してください。Configure Coverage Compliance & Thresholds... では、閾値グリッドの上にプロファイルがあり、そのライブプレビューは実際に有効なゲートで判定します。すべてのカードとレポートにおいて、ゲートがオフのメトリックは、チェックマークやバツ印の代わりに中立的なダッシュとともに数値を表示します。

Screenshot pending — add assets/img/statusbar-metrics.png (see SCREENSHOTS.md).

11a. オブジェクトコードカバレッジ

ここにある他のすべての指標はソースから測定されます。ツールがコードを計装し、計装済みのビルドが実行され、カウンタがどの文・分岐・条件が実行されたかを示します。オブジェクトコードカバレッジが測るのは別のものです — ビルドされたバイナリのどれだけが実際に実行されたかを、ソースを計装するのではなく命令ストリームを観測して、命令バイト単位で数えます。これが重要なのは、コンパイラがソースのどの行にも対応しないコードを出力するからです。配列境界チェック、switch のジャンプテーブル、レジスタのスピル、スタックプローブ、除算や浮動小数点の命令を持たないコアでのランタイム補助ルーチン呼び出しなどです。また、これはアセンブリを覆うのかという問いに答えられる唯一の指標でもあります。手書きのアセンブリは決して計装されず、ソースベースのツールでは届きません。DO-178C はその理由を明示しています。レベル A では、コンパイラやリンカがソース文へ直接たどれないコードを生成する場合、目標 6.4.4.2b はまさにその生成コードに対する追加の検証を求めます。

これは文カバレッジを包含します。実行されたすべての命令は何らかの文から生まれているので、オブジェクトコードカバレッジ 100% は文カバレッジ 100% を意味します。逆は成り立たず、その非対称性こそが測る理由です。ここから二つのことが導かれます。複合スコアには一切の重みを持ちません。同じ実行に対する二つの尺度を平均すれば同じ証拠を二重に数えることになるからです。代わりに fuciniCoverage.threshold.objectCode によるゲートで扱われます — 重みではなく要求であり、規格が求めるのはこの形です。そして差分こそが成果物です。行カバレッジ 100%、オブジェクトコードカバレッジ 100% 未満という結果は、ソースが説明しないコンパイラ生成コードを正確に突き止めています。だから適合カードは「94%」として埋もれさせず、312 バイトが一度も実行されず、行カバレッジは 100% と述べます。その逆 — ソースは実行されていないのにバイナリ全体が実行済みと報告される — は低いスコアではなく矛盾です。ほとんどの場合、マージの片側にある古いトレースファイルか、ファイルパスと一度も一致しなかったモジュール名です。これは所見として報告されます。

オブジェクトコードカバレッジには、バイナリを命令が観測できる場所で走らせる必要があります。方法は三つあり、コストは大きく異なります。オブジェクトコードカバレッジを生むのは三つ目だけです。最初の二つを挙げるのは、それらが関連する問題 — 多くの場合、実際に解く価値があるのはそちらの問題 — を解決するからです。

1. ターゲット上で動く計装済みビルド。 GCC のクロスコンパイラは -fprofile-arcs -ftest-coverage を受け付けるので、ワークステーションで機能する計装はターゲットでも機能します。ただしベアメタルのシステムには .gcda カウンタを書き出すファイルシステムがなく、書き出す契機となる exit() も多くの場合ありません。カウンタはいずれにせよ RAM 上にあるので、そのメモリをダンプしてターゲット外でファイルを再構成するのが解決策です。NASA JPL の embedded-gcov（Apache-2.0）がまさにそれを行います — ファイルシステムも OS も標準 C ライブラリも要りません。得られるのは、あなたのクロスコンパイラが、あなたの命令セット向けに、あなたのハードウェア上で作ったビルドの文・分岐・関数カバレッジです。オブジェクトコードカバレッジではなく、しかも測定対象のバイナリは計装済みで、出荷するものより大きく遅くなります。結果は LCOV、gcovr JSON、gcov JSON として、あるいは GCC 9 より古いツールチェーンではプレーンテキストの .gcov リストとして読み込んでください。
2. 命令セットシミュレータ。 実際のターゲットバイナリをシミュレータで走らせ、実行されたアドレスからカバレッジを導きます。ハードウェア不要、計装不要、プローブ不要で、命令を観測するため本物のオブジェクトコードカバレッジを生み出せます。限界は忠実度です。シミュレータはコアをよく模し、周辺回路はそれほどでもないため、あなたのシリコンを精密に模していない限り、システム全体の結果は疑ってかかってください。
3. オンチップトレースとデバッガ。 認証グレードの経路であり、真に非侵襲な唯一の方法です。コアのトレースユニットが命令ストリームをデバッガに報告し、デバッガがそれをカバレッジに変えます。何も計装されず、コードサイズは変わらず、タイミングにも影響しません — だからこそ結果が、実際に出荷するバイナリについての証拠になります。予算を立てる前にシリコンを確認してください。多くのマイコンファミリでは、完全なトレースは大容量トレースバッファと高速トレースポートを備えたエミュレーション版や開発版でしか使えず、量産品は縮小されたトレースユニットしか備えません。そしてベンダーの代替策はコードを計装して CPU 時間を消費するソフトウェアトレース — この経路を選んだ理由そのものを消してしまいます。

多くの組み込みプロジェクトは、同じソースを開発機向けにコンパイルしてそこでユニットテストを走らせることでカバレッジを測定します。速く、ハードウェアも不要で、多くのチームにとって正しい既定の選択です — ただし、その証拠が実際に何を記述しているかは明確にしておく価値があります。出荷するものとは異なるコンパイラ、異なる最適化器、異なる命令セット、異なるバイナリです。ほとんどのソフトウェアにとってそれは許容でき、よく理解されたトレードオフです。IEC 61508、ISO 26262、DO-178C に照らして評価される作業では、これは定番の「ホスト対ターゲット」異議であり、上記の経路がその定番の回答です — 一つ目はソースカバレッジについてそれを解消し、三つ目はオブジェクトコードについて解消します。

現在、オブジェクトコード用に読み込むエクスポートは Lauterbach TRACE32 の metric="object" を指定した COVerage.EXPORT.ListModule です。他のトレースファイルと同様に読み込んでください。この指標は有料ライセンスの下、および評価期間中にのみスコア化・ゲート判定されます。Community インストールではスコア化されませんが、トレースファイルにこの指標が含まれていることは通知されます。ファイル中の最も強力な証拠を黙って省く適合判定は、何を省いたかを述べる判定よりも悪いからです。

12. コード以外の行の除外

excludeComments がオン（デフォルト）の場合、完全にコメントのみまたは空行に該当するステートメントは合計から除外されます — これは、無関係なヒット数がコメントに紐付いてしまうという llvm-cov／gcov の既知の癖も無効化します。標準的なマーカーも尊重されます：

x = risky();          // LCOV_EXCL_LINE
// LCOV_EXCL_START
debug_only_block();
// LCOV_EXCL_STOP

C、C++、Objective-C、CUDA、C# では、プリプロセッサディレクティブもコードではないものとして扱われます。# で始まる行 — #define、#include、#if — と、末尾のバックスラッシュによって続く行です。gcov はマクロの各使用をそのマクロが定義された行に計上するため、報告された唯一の行が #define CHANNEL_COUNT (33U) だったヘッダーは、.c ファイル内のループがそこまで実行されたことで 100% カバーと表示され、定数がどこでも使われていないヘッダーは 0% と表示されていました。このようなヘッダーには今や計測するものがなく、一覧にも表示されません。

除外された行もそれでもカウントするには、excluded.includeInTotals を true に設定します。

ファイルやフォルダーを、ツリーから除外する

Coverage ビューでファイルまたはフォルダーを右クリックして Exclude from Coverage を選ぶか — 行のパス アクションの中にもあります — 開いているファイルで Exclude This File from Coverage を実行すると、ファイルのワークスペース相対パス、またはフォルダーの /** が、フォルダーの設定の fuciniCoverage.ignore に一度だけ書き込まれ、再読み込みでそれがすべての合計とすべてのページから外れます。パターンはそこにあるので、また取り除けます。Visual Studio では、行のメニューと Tools → Coverage Studio に同じ 2 つがあり、同じ設定を同じファイルに書き込みます。

Screenshot pending — add assets/img/exclude-from-tree.gif (see SCREENSHOTS.md).

.NET の属性と名前空間

2 つの設定が、レポートには語れないことをソースから読み取ります。ignore.attributes — 既定では ExcludeFromCodeCoverage — は、指定した属性の下にあるクラス、メソッド、プロパティを、どのツールがレポートを書いたかにかかわらず、LCOV_EXCL_START/STOP と同じように除外します: Coverlet はこの属性を尊重しますが、OpenCover、dotCover、変換された lcov はそうではありません。今ではすべてが一致します。名前は Attribute 接尾辞の有無、名前空間の有無を問いません。GeneratedCode、Obsolete、あるいは独自のものを追加してください。ignore.namespaces は、名前空間宣言が接頭辞に一致するすべてのファイルを除外します。* がワイルドカードです — Acme.Generated、Acme.*.Migrations、*Tests — そして Output ペインが除外したファイルの名前を挙げます。どちらも、コメント マーカーを読むのと同じパスで読み取られ、両エディションで同じです。

{
  "fuciniCoverage.ignore.attributes": ["ExcludeFromCodeCoverage", "GeneratedCode"],
  "fuciniCoverage.ignore.namespaces": ["Acme.Generated", "*.Migrations"]
}

エディターから除外する

行を選択して、電球、エディターのコンテキスト メニュー、または Command Palette から Exclude Selection from Coverage を選ぶと — Visual Studio では電球（Ctrl+.）、コード ウィンドウの右クリック メニュー、Tools → Coverage Studio または Ctrl+Shift+U, X — 除外がコードのある場所に書き込まれます: C#、VB、F# のクラス、メソッド、プロパティの上には [ExcludeFromCodeCoverage] を、ファイルがすでに System.Diagnostics.CodeAnalysis をインポートしていれば短い名前で、していなければ using を追加せずに済むよう完全修飾で。コード 1 行の末尾には LCOV_EXCL_LINE。複数行の周りには LCOV_EXCL_START と LCOV_EXCL_STOP を、最初の行のインデントで — その言語自身のコメント記号、//、#、'、--、; を使って。元に戻すのは 1 ステップです。電球は、Problems のエントリが未カバーと示す行でもこれを提案します。すでにマークされた行や、すでに属性の付いたメンバーは、そのまま残されます。

Screenshot pending — add assets/img/exclude-selection.gif (see SCREENSHOTS.md).

分岐だけ、そして gcovr のマーカー

防御的な else、どの値も到達しない default:、コンパイラが例外のために追加するアーム: その行は実行され、数えるべきであり、通れないのはその分岐だけです。LCOV_EXCL_BR_LINE と LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP は、その行の分岐をカウントから外し、行は残します。LCOV_EXCL_EXCEPTION_BR_LINE とそのリージョンが外すものはさらに少なく、例外が到達するアームだけです。ただし gcov の JSON のように、どれがそのアームかをレポートが示している場合に限ります。すべてのマーカーは gcovr の接頭辞でも読み取られます: GCOVR_EXCL_LINE、GCOVR_EXCL_START、GCOVR_EXCL_BR_LINE、GCOV_EXCL_STOP などは LCOV_EXCL_ のマーカーと同じ意味なので、gcovr 向けに書かれたソースは、どのツールがレポートを作ったかにかかわらず、ここでも同じように読まれます。読み取られないもの: GCOVR_EXCL_FUNCTION — その行には、関数がどこで終わるかを示すものがないからです。

if (handle == NULL) return E_FAIL;   // LCOV_EXCL_BR_LINE: the allocator never fails on target
  // LCOV_EXCL_BR_START generated state table
  switch (state) { /* … */ }
  // LCOV_EXCL_BR_STOP

Screenshot pending — add assets/img/branch-markers.png (see SCREENSHOTS.md).

理由を示す: 根拠のある除外

コードをカウントから外すことは 1 つの主張です — 「これはテストできない」「これは開発者向けの補助機能だ」 — そして DO-178C、ISO 26262、IEC 61508 の下では、認証の根拠となる数値を変える主張は、文書として残し、レビューできなければなりません。そこで、除外にはそれを書いた場所で理由を示せます: LCOV_EXCL_LINE または LCOV_EXCL_START の後ろのテキスト、あるいは [ExcludeFromCodeCoverage] の Justification です。

abort();                 // LCOV_EXCL_LINE: defensive, unreachable by construction
  // LCOV_EXCL_START debug dump, never built for the target

  [ExcludeFromCodeCoverage(Justification = "a developer aid")]
  public static void DebugDump(decimal amount) { /* … */ }

理由は読み込みのたびに読み取られ、ログがその数を記録します。Export Coverage Report… はその一覧 — exclusions and their justifications — を Markdown または CSV で書き出します: ファイル、行、どう書かれたか、そして根拠または none given です。計測可能なものが何も残らなかったファイルも、この一覧には載ります。exclusions.requireReason をオンにすると、理由のない除外は所見になります: その行に Problems の警告が出て、Check Coverage Thresholds が不合格になります。そのとき Exclude Selection from Coverage は先に理由を尋ね、マーカーと一緒に、または属性の Justification として書き込みます。入力を閉じるか空のままにすると、何も除外されません。

Screenshot pending — add assets/img/justified-exclusions.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-justified-exclusions.png (see SCREENSHOTS.md).

12a. このカバレッジは、いまのこのファイルのものですか

12b. 未計測と未カバー

{
  "fuciniCoverage.unmeasured.mode": "list",
  "fuciniCoverage.threshold.unmeasuredFiles": 0
}

ヘッダーファイルは C における既知の偽陽性です。実行の拡張子ファミリーを持ちながら、単体では何にもコンパイルされないため、トレースファイルがヘッダーを挙げることは決してありません。そのため fuciniCoverage.unmeasured.exclude は既定で **/*.h、**/*.hpp、**/*.hh、**/*.inl、**/*.d.ts を、fuciniCoverage.ignore と同じグロブ構文で除外します。ここではビルドされないプラットフォーム移植や生成されたスタブを加えれば、一覧、カウント、ステータスバーの状態から外れます。ignore が挙げるファイルも未計測とは呼ばれません — 外すことが目的だったからです。threshold.unmeasuredFiles の既定は -1 で、チェックしません。0 は実行と同じ種類のファイルがどれか 1 つでもテストに読み込まれなかった時点で失敗し、unmeasured.mode が list または count のあいだだけ適用されます。

13. HTMLレポート

• Generate Full HTML Report — ディレクトリごとの、自己完結型・複数ページのレポート。出力先は htmlReport.outputDir、未設定の場合は拡張機能のグローバルストレージです。
• Open Annotated Source — 単一ファイルの注釈付きビュー。組み込みのレンダラーの代わりにそれらのページを使用するには、事前に構築された llvm-cov show --format=html ディレクトリを externalHtmlReport.dir に指定します。
• Export Fucini JSON — 独自のツール向けの完全な正規化モデル。
• Export Coverage Report... — 実行結果を CSV（ファイル単位・関数単位）、Markdown サマリー、LCOV トレースファイル、Cobertura XML、SARIF、README 用の自己完結型 SVG バッジとして書き出します。Covered Files ビューの Generate Full HTML Report の隣のボタンからも使えます。CSV 以外はすべて非可逆です — MC/DC、リージョン、インスタンス化は LCOV・Cobertura・SARIF に置き場所がありません — したがって全指標を運ぶのは Fucini JSON と CSV です。
• Copy Uncovered Lines — PRに貼り付ける準備ができた、すべてのギャップのMarkdown概要。

Screenshot pending — add assets/img/vs-annotated-source.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-directory-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-file-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-coverage-gaps.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-mcdc-detail.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/export-picker.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/annotated-source.png (see SCREENSHOTS.md).

注釈付きソースと通常のソースの違い

Open Annotated Source は、アクティブなタブをそのファイル用の色分けされたカバレッジ Web ビューに、同じ列内で置き換えます。Open Annotated Source to the Side も同様ですが分割表示になり、ソースと注釈付きビューが並んで表示されます。代わりにその場で切り替えたい場合 — 分割すると各ペインが狭くなりすぎる小さい画面で便利です — は Toggle Annotated Source を使います。アクティブなタブを両者の間で切り替え、現在どちらを見ているかを記憶します。注釈付きビューの中からは、Show Source でそのファイルの通常のエディターに直接戻れます。

実際に表示される HTML は externalHtmlReport.dir によって決まります。設定されており、アクティブなファイルに一致するページがすでに存在する場合（llvm-cov はファイルごとのページを <リポジトリ名>/<相対パス>.html という形式で配置するため、レポート自体のリポジトリ名フォルダーを設定する必要は一切ありません）、組み込みレンダラーの代わりにそのツールチェーン生成ページが表示されます — ローカルリンク／スタイルシートは Web ビュー内で機能するように書き換えられ、組み込みビューでは再現できない詳細（MC/DC 展開ビュー、リージョンのハイライト、ディレクトリのロールアップ）が含まれます。そのファイルに一致するページがない場合、または設定が空の場合はどうなるでしょうか。その場合は組み込みレンダラーが使用されます。拡張機能はこのディレクトリを読み取るだけで、書き込むことは一切ありません。

README 用のカバレッジバッジ

Generate Coverage Badge はアクティブな実行の shields 風 SVG をワークスペースに書き出し — badge.outputPath、既定は coverage-badge.svg、ワークスペース フォルダーからの相対または絶対で、ほかのすべてのパス設定と同じ変数が使えます — 開くことを提案します。リポジトリ内の普通のファイルなので、README は背後のサービスなしに、shields.io との往復なしに埋め込め、エアギャップされたリポジトリでも機能します：

![coverage](coverage-badge.svg)

badge.metric がバッジに載せるものを選びます。lines（ラベルは coverage）、branches、mcdc、または weighted — ステータスバーが示すのと同じ複合スコアで、ラベルは score。選んだ指標のデータがない実行は、赤い 0% ではなく灰色の n/a になります。色はあなた自身の colorScale.* の段階に従います。lowThreshold 未満は lowColor、highThreshold までは midColor、そこからは highColor です。badge.autoUpdate がオンなら、読み込みが成功するたびにバッジは黙って書き直され、出力チャネルが各書き込みを [FUCINI_BADGE] として記録します — 読み込みのたびにワークスペースへ書き込むため、既定ではオフです。SVG をコードと一緒にコミットすれば、リポジトリページの画像がエディターの数値に追従します。

{
  "fuciniCoverage.badge.outputPath": "docs/coverage-badge.svg",
  "fuciniCoverage.badge.metric": "weighted",
  "fuciniCoverage.badge.autoUpdate": true
}

14. 履歴とトレンド

history.enabled を有効にすると、実行結果をローカルに保持できます（history.retention の件数まで保持）。その後、ステータス バーにトレンド矢印（▲/▼）、Coverage ビューにトレンド チャート、そして Compare with Last Run と Compare Two History Runs という 2 つの比較コマンドが利用可能になり、それぞれファイルごとのリグレッション／改善の差分を生成します。

Screenshot pending — add assets/img/history-compare.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/since-last-run.png (see SCREENSHOTS.md).

トレンド チャート

Coverage ビューのツール バーの下に、保存された実行が 2 つ以上あれば、履歴の行カバレッジが古いものから新しいものへ、最新 30 件の折れ線として描かれます: 実行ごとの点はホバーするとその日付と数値を示し、その隣には最後の数値と、最初からの方向を示す矢印があります。縦軸のスケールは実行自身の範囲なので、92～94% のチームには 100 の下の平らな線ではなく、動きが見えます。両エディションとも同じ履歴から描きます。

Screenshot pending — add assets/img/trend-chart.png (see SCREENSHOTS.md).

カバレッジ セッション

1 回のテスト実行で変更が触れたすべてがカバーされることはめったにありません: ユニット テストはここで、統合スイートはあちらで、カバレッジをオンにした UI の操作はまた別の場所で。Start Coverage Session は、それに続く読み込みを 1 つの合計にします — 各実行は前のものに行ごとに和集合として加算され、いずれかが実行した行はカバー済みとなり、回数は足し合わされます — そのため、ガター、ツリー、スコアはそれらすべてが合わせて到達したものを示します。画面上の実行があれば、それがセッションの最初になります。ツリーの上のバーが、いつから何回の実行かを示し、セッションを終了します。End Coverage Session も同じで、次の読み込みは再び単独になります。Visual Studio では、Tools → Coverage Studio の 1 つの項目がセッションを開始し、チェックが付いた状態でそれを終了します。

Screenshot pending — add assets/img/coverage-session.gif (see SCREENSHOTS.md).

CI ベースライン: main に対してどこにいるか

Compare with Last Run は、最後の変更が何をしたかに答えます。プル リクエストの前の問いは main に対してどこにいるかであり、その答えはビルド サーバーにあります。baseline.report は main ブランチのビルドが公開するレポートを指し、すべての読み込みがそれと照らし合わされます: ステータス バーのカードには 1 行の差分が載り — vs CI baseline: 84.20% → 85.10% (+0.90%), 3 file(s) moved — Compare with CI Baseline は動いたファイルを、Compare with Last Run と同じ言葉でファイルごとに一覧します。Visual Studio ではこのコマンドは Tools → Coverage Studio にあり、求めたときにレポートを取得または読み取ります。.vscode/settings.json での指定方法は 3 つあります:

{
  "fuciniCoverage.baseline.report": "https://gitlab.example.com/api/v4/projects/42/jobs/artifacts/main/raw/coverage/lcov.info?job=test",
  "fuciniCoverage.remote.headers": ["PRIVATE-TOKEN: ${env:GITLAB_TOKEN}"]
}

リーダーが知っているどの形式でもかまいません。CI がそのチェックアウトからの相対で書いたパス — ランナー上で Coverlet が書く src/Billing/Invoice.cs のような — は、差分の前にこのフォルダーの下に置かれ、ローカルの実行が解決したファイルと出会います。別のマシンの絶対パスは何にも一致しないので、パイプラインには相対パスを書かせてください。取得も読み取りもできないベースラインは Output ペインの 1 行になるだけで、読み込みが失敗することはありません。

Screenshot pending — add assets/img/ci-baseline.gif (see SCREENSHOTS.md).

成果物は zip ですが、それも読み取れます。GitHub と GitLab は、中に何を入れたかにかかわらず、成果物をアーカイブとして渡します。その中のレポートは # の後ろに指定します: メンバーはパスまたはパスの末尾で見つけられます。# がなければ、アーカイブの唯一のファイル、またはレポートらしく見える唯一のファイルが使われ、複数ある場合は Output ペインにその名前が挙がります。自分でダウンロードした zip（ci/artifact.zip#lcov.info）でも、VS Code では coverageFile.paths の URL でも同じです。トークンはそれを設定した対象のサーバーにだけ送られ、その先には送られません: アーカイブを保持するストレージへのリダイレクトは、トークンなしでたどられます。

{
  "fuciniCoverage.baseline.report": "https://api.github.com/repos/acme/app/actions/artifacts/1234567/zip#coverage/lcov.info",
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:GITHUB_TOKEN}"]
  }

14a. AI エージェント向け: 画面上のカバレッジ

テストを書くエージェントは、テストを実行してパーセンテージを読むことができます。自力ではできないのは、エディターが知っていることを尋ねることです: この関数のどの行が一度も実行されなかったか、どの分岐のどちら側か、どのテストが行に到達するか、いま書いた差分がカバーされているか。6 つのツールがまさにそれに、エージェントがそのまま行動に移せる言葉で、読み込まれている実行から答えます — 画面と同じ除外、同じ再マッピング、同じ数値です。そのため、関数のギャップをカバーするよう指示されたエージェントと、ガターを見ているレビュアーは、同じ行について話していることになります。

VS Code 自身のエージェントは、何も設定せずにこれらをツールとして使えます。それ以外のエージェント — MCP（Model Context Protocol）を話すクライアントすべて — は、mcp.enabled がオンのときにエディターが実行するサーバーを通じて使えます。VS Code でも Visual Studio でも同じです。Copy MCP Server Configuration は、クライアント用のエントリを、VS Code と Visual Studio が mcp.json で読む形でクリップボードに置きます。外側のキーを mcpServers と呼ぶクライアントでは、同じエントリをその名前の下に置きます。

Screenshot pending — add assets/img/mcp-config.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mcp-config.png (see SCREENSHOTS.md).

{
  "servers": {
    "fucini-coverage": {
      "type": "http",
      "url": "http://127.0.0.1:39217/mcp",
      "headers": { "Authorization": "Bearer …" }
    }
  }
  }

• オンにしない限りオフで、127.0.0.1 でのみ待ち受けます: このマシンの外からは何も届きません。
• 呼び出しにはあなたのトークンが必要です。トークンは一度だけ作られ、あなたのために保管されます。なければ応答は 401 です。コピーした構成にはトークンが含まれます: リポジトリには入れないでください。
• Web ページが送った呼び出し — Origin でそうとわかります — は、何を持っていても拒否されます。
• 読み込まれている実行を読むだけで、何も書き込みません。テストの実行はコマンドを示すだけで、開始はしません: コマンドはエージェントが自分のターミナルで実行します。

ポートは mcp.port で、設定しなければ 39217 です。それが使用中の場合 — 2 つ目のウィンドウや、並んで動くもう一方のエディション — は次の空きポートが使われ、コピーした構成には実際に使えるポートが入ります。Output ペインは、サーバーがどこで待ち受けているか（[FUCINI_MCP]）と、待ち受けできなかった理由（[FUCINI_MCP_001]）を示します。プランに含まれないもの — テストの名前、MC/DC の詳細 — については、ホバーと同じように、ツールは内容を明かさずに数だけを示します。

15. コマンドリファレンス

Screenshot pending — add assets/img/statusbar-and-toolbar.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/statusbar-menu.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/worst-functions.png (see SCREENSHOTS.md).

16. 設定リファレンス

デフォルト値を含むすべてのオプションを網羅した、完全に分類された設定テーブルは 機能と設定 ページにあります。すべてのキーには fuciniCoverage. という接頭辞が付きます。

注記：fuciniCoverage.language は、VS Code の表示言語とは独立して、この拡張機能自体のランタイム UI（ステータスバー、通知、ツールチップ、Web ビュー）を特定の言語に固定します。既定値は auto で、サポートされる 18 言語すべてのバンドルが同梱されています。コマンドパレットの項目や設定 UI のラベル（VS Code 自体の表示言語から解決される）は変更しません。

17. エラーコード

診断情報は Fucini Coverage 出力チャンネル（View → Output → Fucini Coverage）に送られ、それぞれ安定した FUCINI_* コードを持ちます。

18. プライバシー

テレメトリは window スコープの telemetry.enabled 設定で制御されます。既定ではオフです。日次サマリーと削除通知には、VS Code のグローバルな telemetry.telemetryLevel がテレメトリを許可していることも必要です。インストール通知といくつかの小さなイベントはそれに関係なく送信されます。試用期間中または無料の Community ティアにあるインストールの使用状況台帳エントリも同様です。Community では、Unlock Full Features が、このテレメトリと引き換えに MC/DC を含むすべての Pro 機能を 30 日間、端末ごとに 1 回限りで解放します。再びオフにすると標準の Community 機能セットが適用されます。有料ライセンスはいずれの場合も影響を受けません。送信される内容はプライバシーポリシーをご覧ください。

知っておく価値のあることが 2 つあります。どちらもお客様ご自身で行動できることだからです。1 つ目は使用状況台帳 ID です。試用中および Community では、拡張機能が Show License / Activation の中と What Community Includes の末尾に表示し、その行を選ぶと ID がコピーされ、ポリシーが開きます。台帳はお客様の端末をハッシュだけで識別し、ほかの手がかりは一切持ちません。そのため、台帳がお客様について何を保持しているかを尋ねる、削除を求める、異議を申し立てる、そのいずれもこの ID がなければできません。ID をお知らせいただければ該当の行を見つけられますが、なければ見つけられません。2 つ目はインストール記録です。インストールが最初に報告したときに書き込まれる 1 行で、90 日後に削除されずそのまま保持され、インストール識別子、その日付、アドレスから判明した場所、各バージョン、オペレーティングシステムを含みます — アドレスそのものは含まず、お客様のコードに関することも一切含みません。長年にわたって何件のインストールがあったかをお伝えできるのは、この記録によるものです。どちらもプライバシーポリシーに詳しく記載されており、どちらもご依頼があれば削除します。

19. 評価とアクティベーション

Fucini Coverage Studio は評価用プレリリース版として配布されています。初回起動時に評価への同意を求められ、試用が始まります。すべての機能は 14 日間の試用期間中に利用でき、期間はそのインストールで最初に使用した時点から数えます。以降に何かが停止する固定の期日はありません。

バージョン 2.2026.2 以降、新しいインストールのトライアルは、拡張機能がライセンスサーバーに一度到達した時点で始まります。それまでは Community ティアで動作し、その旨を表示します。開発コンテナーや Codespace ではトライアルは始まりません。そこでは、サブスクリプションコード、キー、または 7 日間パスですべての機能が利用できます。

試用期間が終わっても何もロックされません。拡張機能は無料の Community ティアに移行します。すべての機能を取り戻すにはアクティベーションを行ってください。アクティベーションはライセンスサーバーに接続し、返されたキーを自動的に適用します。メールも、手作業でのキーの転記も不要です:

Screenshot pending — add assets/img/licence-dialog.png (see SCREENSHOTS.md).

1. Fucini Coverage: Show License / Activation を実行し（試用期間やキーの期限が切れるとステータスバーからも開けます）、Request License…（以前にアクティベート済みの場合はRequest Renewed Key…）をクリックします。
2. リクエストを確認します。キーは自動的に発行され、以前のリクエストの連絡先情報は再度尋ねることなく再利用されます。
3. 以上です。アクティベーションキーが生成され、fuciniCoverage.license.key に自動的に書き込まれます。ステータスバーはまもなく試用からアクティベート済みライセンスに切り替わります。

手作業の道筋を一枚で。ライセンスパネルを開き、Enter Key を選び、メールのキーを貼り付ければ、バナーは「Activated」に変わります。

Screenshot pending — add assets/img/activate-key.gif (see SCREENSHOTS.md).

{ "fuciniCoverage.license.key": "FCK1.…キー全体を貼り付け…" }

無料の Community ティア: 週間利用枠

Community がカバレッジの表示をやめることはありません。ガター、概要ルーラー、ホバー、CodeLens、Coverage ビュー、ウォッチモード、差分カバレッジ、履歴は一切カウントされません。コマンドによるトレースファイルの読み込みも、1 日 25 回という上限があるだけです。計測されるのは出力です。HTML レポートを開く、エクスポートする、2 つの実行を比較する、しきい値をチェックする、注釈付きソースをその場で表示する — これらがそれぞれ週 5 回までです。

1 週間はカレンダーではなく、あなたに合わせて数えます。最初の利用で始まり、7 日後に終わります。利用枠を使い切ると、メッセージにその操作名と枠が戻る日が表示され、その 1 回のメッセージ以降はステータスバーだけがそれを知らせます。Fucini Coverage: What Community Includes を実行すると、上限に達する前でも、すべての利用枠について使用済みの回数とリセット日を確認できます。

Screenshot pending — add assets/img/weekly-allowance.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-limit-prompt.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-includes-weekly.png (see SCREENSHOTS.md).

検出結果そのものは無料のまま、次の 3 つの詳細だけが有料プランの機能です。Community は生存ミュータントのあるすべての行に印を付けてその数を示しますが、各ミュータントが何を変更したかは表示しません。その行を実行したテストの数は示しますが、テスト名は表示しません。実行の Max CRAP は表示しますが、順位付きの Riskiest Methods リストは表示しません。

Screenshot pending — add assets/img/mutant-hover-community.png (see SCREENSHOTS.md).

週間利用枠の導入時 (0.2026.83) にすでに Community をお使いだった場合、以前の上限が 30 日間そのまま適用されます。このことは日付とともに一度だけお知らせします。カウンターはお使いのマシン上 — VS Code 自身のストレージと ~/.fucini-coverage/ — に保存されるため、新しい VS Code プロファイルでも同じ週が継続されます。どこにも送信されることはありません。

7 日間パス

サブスクリプションにはまだ早いとお考えですか? 7 日間パスなら、Pro のすべてを 1 週間、一度のお支払いで利用できます。自動更新はなく、解約の手続きも不要です。料金ページで購入でき (Community の上限に達したときのメッセージにも購入用のボタンがあります)、アクティベーションコードがメールで届きます。

Screenshot pending — add assets/img/pricing-week-pass.png (see SCREENSHOTS.md).

1. Fucini Coverage: Enter Subscription Code を実行します — このコマンドは Community エディションにも Pro にもあります。
2. Pro を選択し、メールに記載された FCB1-… コードを貼り付けます。
3. これで完了です。キーは自動的に発行・適用され、オフラインでも動作します。1 週間はお支払いの時点から数えるため、購入したらすぐにアクティベートしてください。期間が終わると、拡張機能は自動的に Community に戻り、カバレッジの表示を続けます。

Screenshot pending — add assets/img/pass-step-plan.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/pass-step-code.png (see SCREENSHOTS.md).

新しいパソコンへの移行と、シートの管理

キーは 1 台のマシンに結び付いているため、新しいパソコンには新しいキーが必要です。サブスクリプションは表示されている台数までしか対象になりません。古い方はご自分で解放してください。サブスクリプションの管理にサインインし、使わなくなったシートを見つけて Free up を選び、同じコードで新しいマシンをアクティベートします。Pro を購入してもパスワードは送られません。アカウントは存在しますが、まだパスワードがないだけです。初回は購入時のアドレスでパスワードの設定またはリセットをご利用ください。

Business と Enterprise では、同じページから同僚をメールで招待します。それぞれ本人専用のアクティベーションコードを受け取り、使用すると本人のアドレスがそのシートの欄に表示されます。退職者が出たときに、どのシートがその人のものだったかが分かり、次の人のために解放できます。招待は送信した時点でシートを 1 つ確保し、未使用のまま 14 日で期限切れになります。取り消せばすぐに空きに戻ります。

プレリリース版を試す

新しい成果は Marketplace より先に fucini.software に届きます。提供を希望することもできます。Coverage ビューを開き、ライセンス パネルを展開して プレリリース版を試す… を押すか、fuciniCoverage.update.preRelease を設定してください。以後、拡張機能は通常のフィードに加えてここにある専用のプレリリース フィードも確認し、新しいほうを提供します。

Screenshot pending — add assets/img/licence-prerelease.png (see SCREENSHOTS.md).

プレリリースはテスト済みですが、私たちが最も確信を持てないビルドであり、見落としを見つける役目を引き受けていただくことになります。参加すると、このインストールがチャネルにあることが私たちに伝わるため、何人が試しているかを把握し、何が変わったかをお知らせできます。離脱すると、次の安定版で通常の経路に戻ります。プレリリースが常にあるとは限りませんが、ない時期に参加しても損はありません。拡張機能は空のフィードを見つけ、それについては何も言わず、公開されるまで安定版を提供し続けます。

Screenshot pending — add assets/img/licence-prerelease-joined.png (see SCREENSHOTS.md).

20. お問い合わせとライセンス

ご質問、バグ報告、または代替ライセンス条件については、お問い合わせページ、またはメール info@fucini.consulting までご連絡ください。リリースノートでの帰属表示の条件を含むMITライセンスの下で提供されています。Notice も参照してください。

21. コマンドラインで

リーダーはエディターなしでも動きます：npm install -g fucini-coverage、無料で、Windows、Linux、WSL、macOS に。fucini-coverage check coverage/lcov.info --lines 80 がパイプラインを不合格にするゲートです。summary、export、report、badge、compare は同じ名前のエディターのコマンドがすることをし、mcp は上のセクションの 6 つのツールをサーバー上のエージェントに提供します。Visual Studio 版が読む設定ファイル fucini-coverage.json を読むので、しきい値は一度決めるだけです。fucini-coverage help <command> がそれぞれを説明し、完全なページは npm の fucini-coverage にあります。

Screenshot pending — add assets/img/cli-demo.gif (see SCREENSHOTS.md).