バグ密度

計算式と考え方

バグ密度は「検出したバグ数 ÷ コード行数（KLOC）」で求めます。5万行のコードで150件なら3件/KLOCという計算です。一般に3件/KLOC前後が標準的、1件以下なら高品質とされます。残存バグの推定は、検出済みバグに対する残存率から逆算します。残存率10%なら約17件が未検出という推定です。修正コストは検出フェーズによって大きく異なり、単体テストで見つかったバグの修正コストを1とすると、結合テストで3倍、システムテストで6倍、本番リリース後では30倍以上になるとされます。この計算では、入力した修正コストを単体テスト基準の1件あたり単価とみなし、検出フェーズの倍率（単体1倍・結合3倍・システム6倍・本番30倍）を掛けて合計を求めています。残存バグが本番へ流出した場合の想定コストは、常に30倍で見積もっています。この非線形性が、早期のテストとレビューに投資すべき理由です。

検出フェーズと修正コスト

バグ密度の詳しい解説

バグ密度は品質管理の基本指標ですが、数値の解釈には注意が必要です。バグ密度が低いことは、品質が高いことを意味する場合と、テストが不十分でバグが検出できていない場合の両方があり得ます。このためバグ密度は単独ではなく、テストカバレッジやテスト密度（テストケース数÷KLOC）と併せて評価する必要があります。カバレッジが低いのにバグ密度も低いなら、それは品質が高いのではなく検査が甘い可能性が高くなります。分母の取り方によっても数値は変わります。全ソースの行数を使うか、新規・変更した行だけを使うか、コメントと空行を除くか、自動生成されたコードを含めるかで、同じ成果物の密度が数倍違うことがあります。言語によって同じ機能を実装するのに要する行数も異なるため、他社の公表値との単純な比較には向きません。比較するなら、定義をそろえた自社の過去プロジェクトとの対比が現実的です。もう一つ重要なのは、検出フェーズによる修正コストの違いです。設計段階で見つかった誤りは設計書の修正だけで済みますが、本番リリース後に発覚すると、障害調査、修正、影響範囲の確認、緊急リリース、顧客への説明といった工数が加わり、30倍以上のコストになるとされます。この構造が、シフトレフト（テストと品質確保を開発の早い段階へ移す）という考え方の根拠です。静的解析ツールの導入、コードレビューの徹底、単体テストの自動化は、いずれも早期にバグを検出するための投資です。残存バグの推定には、検出数の推移から収束を見る信頼度成長曲線や、独立した二者が検出した重複から総数を見積もる方法がありますが、いずれも前提の置き方で結果が動きます。リリースの可否は単一の数値ではなく、未修正バグの重大度の分布や再現条件と併せて判断するのが実務的です。目標値を設定する際は、システムの特性を考慮すべきです。人命に関わるシステムや金融の基幹系では0.1件/KLOC以下という厳しい基準が求められる一方、社内の業務支援ツールでは3件/KLOC程度が許容される場合もあります。一律の基準を当てはめるのではなく、リスクに応じた水準設定が実務的です。なお指標は改善のための材料であり、個人やチームの評価に直結させると報告そのものが減り、数値だけが良く見える状態を招きます。何のために測っているのかを共有しておくことが、運用の前提になります。

業界・現場での使い方

よくある間違い・注意点

• バグ密度の低さだけで品質を判断する — テストが不十分で検出できていない可能性があります。カバレッジと併せて評価してください。
• 一律の目標値を適用する — システムの重要度で求められる水準が異なります。リスクに応じた設定が必要です。
• バグ数を評価指標にする — 報告が抑制される恐れがあります。バグを見つけることが評価される文化が品質を高めます。

関連する規格・法規

• 業界標準
• ISO/IEC規格

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール