投稿日:
2026年09月02日
読了時間:
7分
すべてのリリースレビューにはカバレッジの数値が含まれており、それは大抵右肩上がりで、人々はそれを進捗として受け止めます。しかし、その数値が教えてくれないのは、テストしたコードが本当に重要なコードだったかどうかです。そして、そここそが、リリースが実際に安全かどうかを左右する部分です。
パーセンテージは、未テストの行をすべて同じ重みで数えます。そのため、誰も気に留めないゲッター関数も、システムをダウンさせかねないフォルトハンドラーも、同じ1行として扱われます。こうして、あるチームはカバレッジ90%に到達しながら、不具合をフィールド障害やリコール、保証クレームに変えてしまうたった一つの関数が、未テストのまま残ることになります。数値は上がりましたが、リスクはそのままです。
この4つを実践すれば、状況は変わります。それぞれがカバレッジを実際に下せる判断へと近づけてくれます。
1. 平均ではなく、リスクでランク付けする
意味のある問いは、「コードのどれだけがカバーされているか」ではなく、「未カバー部分のうち、どこが実際に危険なのか」です。CRAP（Change Risk Anti-Patterns）のようなリスク指標は、各関数の複雑さとカバレッジを掛け合わせることで、この問いに答えます。
- 危険なギャップを見つけ出す。複雑でありながらほとんどテストされていない関数が上位に浮かび上がります。フィールドで実際に不具合を起こすのは、まさにそうした関数だからです。
- 効果のある場所に労力を割く。テストは行数ではなくリスクに従うようになるため、誰にも影響を与えないコードのギャップを埋め続けることがなくなります。
- マネージャーが動ける材料を与える。カバレッジが70%であること自体は変わりませんが、その30%のうちどこに注意を払うべきかが分かるようになります。これは、リリースレビューの場で説明できる数値です。
2. パーセンテージではなく、エビデンスを生成する
規制対象の市場では、規格自体がすでに求める指標を定めており、それはパーセンテージではありません。ダッシュボード上の数値だけでは監査担当者は納得せず、カバレッジを認められるエビデンスに変換できるかどうかで、認証にかかる時間が決まります。
- 指標を規格に合わせる。ISO 26262 の ASIL C/D や DO-178C の Level A/B では MC/DC が求められます。IEC 61508 では SIL 3・4 のクリティカルパスにおいて、IEC 62304 の Class B・C ではトレーサブルなステートメント・ブランチカバレッジのエビデンスが求められます。
- 監査準備を数週間から数日に短縮する。関数ごとに生成され、各行がそれをカバーしたテストまでトレースできるエビデンスは、監査前の手作業による駆け込み対応を不要にします。
- 認定サイクルを省略する。TÜV のような認証機関からすでに認証を受けたツールであれば、安全チームは改めて認定を取り直す必要がなく、ASIL D や SIL 4 のプログラムにおいて実質的なスケジュール短縮につながります。
3. コードが実際に動作する場所で計測する
カバレッジが意味を持つのは、それがリリースするシステムを反映している場合だけです。しかし、皆さんのコードは、ビルドを行うマシン上ではほとんど動作しません。多くのツールが見落としがちな2つの状況があり、どちらもビジネス上のコストにつながります。
- 近似値ではなく、実機で。TriCore、PowerPC、ARM、RISC-V のような制約のあるターゲット上で動作するファームウェアでは、デバイス自体でカバレッジを計測する必要があります。早い段階でハードウェアへの依存を避けたい場合は、ホストベースでの計測も選択肢になります。それ以外の方法では、実際にリリースするものの近似値しか計測できません。
- ソースコードを外部に出さない、委託先でのテスト。テストが委託先や別拠点で行われる場合、誰もソースコードに触れることなくカバレッジデータだけが返送され、中央で統合される仕組みは、知的財産を守りながらエビデンスを確保できます。IP に敏感なプログラムでは、これがツール選定全体を左右することも少なくありません。
4. AI でギャップを埋める。ただしレビューは人が行う
リスクのあるコードを見つけることは、常に半分の作業に過ぎませんでした。それを解消するには、不足しているケースをすべて手作業で書く必要があり、リポジトリに入ってくるコードのうち AI が書く割合が増えるほど、その負担は重くなっていきます。ここでの転換点は、その同じ AI を、ギャップそのものに向けることです。
- AI が不足しているテストを書く。MCP のようなプロトコル経由で実際のカバレッジデータを与えられたエージェントは、何がすでに実行されたかを読み取り、ギャップを埋めるテストを作成し、カバレッジを再実行して自らの成果を確認します。
- それでも、最終判断は人が行う。エージェントは推測ではなく、正確に未テストの行を狙って対応します。そして、すべてのケースはテスターが承認して初めてカウントされます。コードを書いたのが人であってもモデルであっても、基準は変わりません。
- 変更された部分だけを再テストする。パッチ解析は差分を確認するため、未テストの変更はマージされる前に検出され、CI はコミットのたびにすべてを再ビルドする必要がなくなります。
これらを合わせると
この4つを組み合わせれば、カバレッジはダッシュボード上でじわじわ上昇するだけの数字ではなくなり、リリース時に本当に重要な問い、「準備はできているか」に答えるものになります。リスクを増やすことなくより速く動け、検証にかけるコストは減り、監査にはすでに書き上がったエビデンスを持って臨め、そして顧客より先に不具合を見つけられるようになります。パーセンテージそのものは、最初から目的ではなかったのです。
デモ動画：AI でコードカバレッジを探る方法 ― 危険なコードを数分で見つける
Qt Group の Marius Schmidt による40分間のセッションでは、実際のコードと Coco を使って、この4つすべてを実演しています。
- 稼働中のプロジェクトを CRAP でソートし、最もリスクの高い関数を浮かび上がらせる
- 他のすべてのチェックには通るのに、MC/DC では失敗する行を確認する
- カバレッジレポートを AI エージェントに渡し、ギャップを埋めて再検証させる
