バグ密度の指標とIPAの基準値 計算式と工程別の目安・データの正しい使い方

「テストが終わったが、この品質で本当にリリースしてよいのか」。判断の根拠を求めて、バグ密度という指標にたどり着く方は多いのではないでしょうか。

バグ密度は、検出したバグの件数を開発規模で割った値です。計算そのものは割り算ひとつで終わりますが、実務で詰まるのは「いくつなら妥当なのか」という一点にあります。

その目安として広く参照されているのが、IPA（情報処理推進機構）が公開している定量データです。5,546プロジェクトの実績にもとづく統計値であり、社内に基準がない場合の拠り所になります。

この記事では、バグ密度の計算式と関連指標を整理したうえで、IPAが示す工程別の実数値、その使い方、そして数値をそのまま自社に当てはめると判断を誤る条件までを順に扱います。

確認したいポイント	結論	詳細
バグ密度とは？	規模あたりの検出バグ件数	検出したバグ数を開発規模で割った値です。単位は件/KSLOCまたは件/KFPが一般的です。
IPAの基準値は？	結合テストで中央値1.111件/KSLOC	分析データ集2022の全開発種別の値です。総合テストは0.197件/KSLOCが中央値になります。
平均と中央値どちら？	中央値を使うのが基本	平均値は一部の極端なデータに引っ張られます。分布とあわせて確認する必要があります。
使うときの注意は？	母集団と数え方を確認する	提供元はベンダー35社で、97%がウォーターフォール型です。自社の前提と合うか確認します。

この記事でわかること

• バグ密度の計算式と、テスト密度やレビュー指摘密度との関係
• IPA「ソフトウェア開発分析データ集2022」が示す工程別・開発種別の実数値
• 平均値ではなく中央値を使う理由と、分布の読み方
• 検出バグの現象数と原因数の違いなど、データを扱う際の落とし穴
• 基準値から外れたときの解釈と、自社の基準値をつくる進め方

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や試験の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。 社内での検討材料としてご活用いただけます。 ＞ 資料請求はこちら

バグ密度とは｜定義と計算式

バグ密度は、ソフトウェアの品質を定量的に把握するための指標です。テスト工程で検出したバグの件数を、開発規模で割って算出します。

計算式と単位

計算式は単純です。分母に何を使うかで単位が変わります。

バグ密度 ＝ 検出バグ件数 ÷ 開発規模

・分母がソースコード行数の場合：件/KSLOC（1,000行あたり）

・分母がファンクションポイントの場合：件/KFP（1,000FPあたり）

日本の開発現場ではKSLOCを使うことが多く、IPAの公開データも両方の単位で整理されています。ただし後述するとおり、行数の数え方が揃っていないと比較できません。

工程ごとに算出するのが基本です。結合テストのバグ密度、総合テストのバグ密度というように、同じ工程どうしで比較します。

テスト密度との関係

セットで語られるのがテスト密度です。テストケース数を開発規模で割った値で、どれだけテストを実施したかを表します。

この2つは組み合わせて見ます。バグ密度が低いという事実だけでは、品質が良いのか、そもそもテストが足りていないのかを区別できないためです。

テストを十分に実施したうえでバグが少ないという状態が確認できて、初めて品質が高いと言えます。片方の指標だけを見て判断すると、必ず誤ります。

なぜ指標として使われるのか

バグの件数そのものでは、規模の違うプロジェクトを比べられません。1万行のシステムで50件と、100万行のシステムで50件では、意味がまったく違います。規模で割ることで、初めて比較が可能になります。

用途は主に3つです。テスト工程の完了を判断する、過去の案件や他チームと比較する、そして品質に問題のある箇所を特定する。リリース判断の根拠として使われる場面が最も多くなります。

ただし、この指標が万能というわけではありません。後述するとおり、測っていない品質特性が多く残ります。根拠の1つとして使うという位置づけを最初に共有しておく必要があります。

呼び方の違い

同じ概念が、組織によって別の名前で呼ばれています。欠陥密度、不良密度、バグ検出密度、障害密度などです。

IPAの資料では、テスト工程で見つかったものを「検出バグ」、リリース後に発生したものを「発生不具合」として区別しています。この2つは意味が違うため、混同しないよう注意します。

社内で議論する前に、何をバグとして数えるかを揃えておく必要があります。仕様変更の要望を含めるか、再現しなかったものをどう扱うかで、数値は簡単に変わります。

IPAが公開しているデータの中身

基準値の出典として最も広く参照されているのが、IPAのソフトウェア開発分析データ集です。まずこのデータが何であるかを押さえます。

ソフトウェア開発分析データ集とは

IPA社会基盤センターが、2005年から継続してソフトウェア開発プロジェクトの定量データを収集・分析し、公開している資料です。2020年に書籍版の名称が「ソフトウェア開発データ白書」から変更されました。

最新にあたるソフトウェア開発分析データ集2022では、累計5,546プロジェクトの定量データをもとに、ソフトウェアの信頼性を中心とした分析が掲載されています。

IPAはこの活動の目的について、技術者の経験と勘に頼った方法ではなく、実際のプロジェクトデータに基づいた定量的なプロジェクト管理が必要であるためだと説明しています。

母集団の特徴を知っておく

数値を使う前に、どういうプロジェクトから集めたデータなのかを確認しておく必要があります。ここを知らずに使うと、判断を誤ります。

• データ提供元：ソフトウェア開発ベンダー35社。国内の大手システムインテグレーターが中心
• 開発ライフサイクル：ウォーターフォール型が97.2%を占め、反復型とその他の合計は約2.8%
• 対象業種：金融・保険業が約37%と最多。次いで製造業、公務、情報通信業
• プロダクト種別：改修・保守が約51%、新規開発が約29%
• 分析対象年度：主な統計値は直近6年間（2016年度から2021年度）のデータで算出

受託開発が約9割を占めるという点も特徴です。自社サービスをアジャイルで継続的にリリースしている組織とは、前提がかなり異なります。

中央値を見るべき理由

統計値には中央値と平均値の両方が示されていますが、バグ密度に関しては中央値を使うのが基本です。

理由は分布の偏りにあります。たとえば結合テストの検出バグ密度は、中央値が1.111件/KSLOCであるのに対し、平均値は22.866件/KSLOCです。一部の極端に大きい値が平均を引き上げています。

IPAの資料でも箱ひげ図が併載されており、分布を確認したうえで使うことが前提になっています。P25とP75を見て、自社の値がどのあたりに位置するかを把握するのが実務的な読み方です。

IPAが示す工程別のバグ密度

ここからが実数値です。以下はすべて「ソフトウェア開発分析データ集2022」に掲載されている値であり、2016年度から2021年度のデータにもとづきます。

全開発種別・SLOC規模あたりの検出バグ密度

最も参照される数値です。単位はいずれも件/KSLOC、つまりソースコード1,000行あたりの検出バグ件数です。

【全開発種別】　　　　　　　N　　P25　　中央値　　P75

結合テスト 検出バグ(現象)　507　0.468　1.111　　2.402

総合テスト 検出バグ(現象)　475　0.051　0.197　　0.639

結合テスト 検出バグ(原因)　389　0.373　1.042　　1.957

総合テスト 検出バグ(原因)　376　0.063　0.246　　0.675

結合テストの中央値が約1.1件、総合テストが約0.2件という水準です。後工程になるほど密度が下がるという傾向は、直感とも一致します。

P25とP75の幅が広い点に注目してください。結合テストでは0.468から2.402まで、5倍以上の開きがあります。中央値だけを目標にすると、幅の広さを見落とします。

新規開発と改良開発では水準が違う

開発の種別で層別すると、値が変わります。自社の案件がどちらに近いかで、参照すべき数値も変わります。

【結合テスト 検出バグ(現象)】　中央値

新規開発　　1.565 件/KSLOC

改良開発　　0.976 件/KSLOC

再開発　　　1.091 件/KSLOC

【総合テスト 検出バグ(現象)】　中央値

新規開発　　0.282 件/KSLOC

改良開発　　0.164 件/KSLOC

再開発　　　0.228 件/KSLOC

新規開発のほうが改良開発より高いという結果になっています。一から作る分だけ、検出されるバグも多いという解釈ができます。

改良開発の案件に新規開発の基準値を当てると、実態より甘い目標になります。層別された数値を使うことが、精度を上げる第一歩です。

FP規模での基準値

ファンクションポイントで規模を測っている場合は、こちらを参照します。単位は件/KFPです。

【全開発種別・FP規模】　　　　中央値

結合テスト 検出バグ(現象)　　91.2 件/KFP

総合テスト 検出バグ(現象)　　30.1 件/KFP

注意すべきはデータ件数の少なさです。FP実績値のあるデータは減少傾向にあり、この数値のサンプル数はSLOCと比べてかなり小さくなっています。IPA自身も、件数が少ないものは参考程度とするよう注記しています。

リリース後の発生不具合密度

テストで検出したバグとは別に、稼働後に発生した不具合の密度も公開されています。稼働後6か月間の累計値が基本です。

新規開発の全年度データでは、中央値が0.010件/KSLOC、平均値が0.109件/KSLOCとなっています。IPAはこれを「不具合は10万行で1個（中央値）、1万行で1個（平均値）」という相場観として要約しています。

この数値は、リリース品質の目標を設定する際の参考になります。ただし、発生不具合の定義や集計期間が組織で違うため、そのまま比較できるとは限りません。

品質指標の設計や運用からご相談いただけます 数値は分かっても、自社にどう当てはめるかの判断は別の問題です。 測り方の定義から一緒に整理する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

あわせて見るべき関連指標の基準値

バグ密度だけでは判断できません。同じ資料に掲載されている周辺の指標もあわせて押さえます。

テストケース密度

どれだけテストを実施したかを示す指標です。バグ密度とセットで見ることで、テスト不足なのか品質が高いのかを切り分けられます。

【全開発種別・SLOC規模】　　N　　P25　　中央値　　P75

結合テスト テストケース数　665　22.2　　51.7　　120.1

総合テスト テストケース数　620　 6.4　　16.0　　 40.7

IPAはこれを「1000行あたり50個の結合テスト、15個の総合テスト実施の相場観」とまとめています。バグ密度と同様、こちらも幅は非常に広くなっています。

レビュー指摘密度

テスト工程より前の段階、つまり設計レビューでどれだけ指摘が出ているかを示す指標です。上流の品質を測る手がかりになります。

基本設計レビュー指摘（SLOC規模あたり）　中央値 2.500 件/KSLOC

基本設計レビュー指摘（ページあたり）　　中央値 0.216 件/ページ

IPAは「基本設計レビューでは100ページあたり25個指摘の相場観」と要約しています。上流で指摘が極端に少ない場合、レビューが形骸化している可能性を疑う材料になります。

相場観としてのまとめ

IPAの資料自体が、全体の傾向を短い言葉でまとめています。細かい数値より、この相場観を覚えておくほうが実務では役立ちます。

• 不具合は10万行で1個（中央値）、1万行で1個（平均値）
• 1000行あたり50個の結合テスト、15個の総合テストを実施
• 1万行あたり結合テストで12個、総合テストで2個のバグを検出
• 基本設計レビューでは100ページあたり25個の指摘

この4つを頭に入れておけば、自社の数値が桁違いにずれていないかはすぐ判断できます。詳細な比較は、必要になった時点で原典を参照します。

基準値の使い方

数値を知っただけでは意味がありません。どう使うかを整理します。

目標値の設定に使う

社内に基準がない場合、IPAの中央値を出発点にします。ただし、中央値をそのまま合格ラインにするのは適切ではありません。

実務では、中央値を中心に一定の幅を設けて範囲で管理します。中央値の前後何割かを許容範囲とし、そこから外れた場合に原因を確認するという運用です。

幅の決め方に唯一の正解はありません。IPAもデータの活用方法は利用者に委ねる立場を取っています。自社での議論を経て決めることになります。

テスト密度と組み合わせて4象限で見る

現場でよく使われるのが、テスト密度とバグ密度を2軸に取って位置を確認する方法です。それぞれ基準値との高低で4つに分かれます。

• テスト密度が高く、バグ密度も高い：品質に問題がある可能性。原因分析が必要
• テスト密度が高く、バグ密度が低い：品質が良好と判断できる。最も望ましい状態
• テスト密度が低く、バグ密度が高い：テストを続けるとさらにバグが出る可能性
• テスト密度が低く、バグ密度も低い：テスト不足の疑い。品質は判断できない

4つ目を「良好」と誤解しないことが最も重要です。バグが出ていないのではなく、探していないだけという状態がここに含まれます。

推移で見る

テスト期間中の累積バグ件数の推移を追うという使い方もあります。時間の経過とともに新規のバグ検出が減っていけば、収束に向かっていると判断できます。

逆に、テスト終盤になっても検出ペースが落ちない場合は、まだ潜在的な問題が残っている可能性が高くなります。最終日の密度だけを見ていると、この兆候を見逃します。

推移を見るには、日次または週次で件数を記録しておく必要があります。テスト開始時点で記録の仕組みを用意しておくことが前提になります。

機能単位でも見る

プロジェクト全体で基準内に収まっていても、特定の機能に集中している場合があります。全体の数値だけでは、この偏りが見えません。

機能やモジュールの単位で密度を出すと、問題のある箇所が浮かび上がります。そこを重点的に見直すという判断につながります。

バグが集中する箇所には理由があります。仕様が複雑、担当者の経験が浅い、既存コードが古いといった要因を確認します。

データを使うときの注意点

IPAの資料には「データの危うい使い方の例」という節が設けられています。誤用されやすい指標であることが、提供元からも示されています。

現象数と原因数は比較できない

見落とされやすい点です。検出バグには現象数と原因数の2種類が集計されています。1つの原因が複数の現象として報告されることがあるためです。

IPAは、この2つのデータを提出しているプロジェクト群は重なりが少ないため、数だけでは比較できないと明記しています。現象数と原因数を混ぜて論じることはできません。

自社の数値を比べる際は、どちらに相当するかを確認します。不具合票の起票単位が現象なのか原因なのかを、まず整理してください。

母集団が自社と違う可能性

前述のとおり、データの大半はウォーターフォール型の受託開発です。継続的にリリースを繰り返す自社サービスの開発とは、前提が異なります。

反復型の開発では、そもそも「結合テスト」「総合テスト」という工程の区切りが同じ意味を持ちません。この場合、工程別の基準値を当てはめること自体が困難です。

業種による差もあります。IPAは業種編として金融・保険業、情報通信業、製造業のデータを別途公開しており、自社の業種に近いものを参照する選択肢もあります。

規模の測り方が揃っていないと意味がない

分母の測り方が違えば、比較は成立しません。IPAのデータはコメント行と空行を除外した実効SLOCを使っています。

自社が全行数で計算していれば、密度は見かけ上小さくなります。自動生成されたコードを含めるかどうかでも、数値は大きく変わります。

数え方を定義し、社内で統一することが、指標を使う前提条件です。ここが曖昧なまま数値を比較しても、議論の土台になりません。

バグ密度が測っていないもの

最も本質的な注意点です。バグ密度が示すのは「どれだけ見つけたか」であって、「何を確かめたか」ではありません。

性能、セキュリティ、使いやすさといった品質特性は、密度が基準内に収まっていても未評価のまま残ります。機能が仕様どおり動くことと、実務で使えることは別です。

重要度の区別も含まれていません。致命的な不具合1件と、表示の崩れ10件では意味がまったく違いますが、密度としては後者のほうが大きく出ます。

数値が基準から外れたときの見方

基準値と比べて外れた場合、それ自体は良し悪しを意味しません。原因を確認する契機として使います。

バグ密度が高い場合

考えられる要因は複数あります。品質が悪いと決めつける前に、次の可能性を確認します。

• 実装の品質に問題がある（本来の意味での品質不良）
• 上流工程のレビューが不十分で、設計の誤りがテストで出ている
• テストが丁寧で、他より多く検出できている（望ましい状態）
• バグの数え方が他より細かい（現象単位で起票しているなど）

レビュー指摘密度とあわせて見ると切り分けが進みます。上流の指摘が少なく、テストのバグが多いなら、レビューの見直しが必要という判断になります。

バグ密度が低い場合

低いことを素直に喜べる状況は限られます。テスト密度が十分に高いことが確認できて初めて、品質が良いと言えます。

テスト密度も低いなら、単にテストが足りていない可能性が高くなります。この状態でリリースすると、稼働後に不具合が集中します。

テストケースの質も確認します。件数だけ多くても、正常系ばかりで異常系が含まれていなければ、バグは見つかりません。

数値だけで判断しない

最終的な品質の判断は、複数の情報を突き合わせて行います。バグ密度は判断材料の1つであり、それ単独で合否を決めるものではありません。

残存する不具合の重要度、テストの網羅性、性能やセキュリティの検証結果、そして関係者の合意。これらを含めて判断します。

テスト工程の設計や、外部に委託する場合の役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方も参考になります。

自社の基準値をつくる進め方

最終的に目指すべきは、自社の実績にもとづく基準値を持つことです。IPAのデータは、その出発点として使います。

まず自社の実績を測る

過去に完了したプロジェクトについて、規模、テストケース数、検出バグ数を集計します。5件から10件も集まれば、傾向は見えてきます。

この段階で、データが揃っていないことに気づくはずです。規模を測っていない、バグの数え方が案件ごとに違う。それが判明すること自体に価値があります。

今後のプロジェクトから記録の様式を統一します。集計の負担が大きいと続かないため、必要最小限の項目に絞ることが継続の条件です。

層別して比較する

自社のデータが溜まってきたら、新規開発と改良開発、規模の大小、担当チームといった軸で分けて見ます。

IPAのデータでも層別によって値が変わることが示されています。自社でも同様の差が現れるはずで、その差に自社固有の傾向が表れます。

IPAの数値と自社の数値を比べることにも意味があります。大きく乖離しているなら、測り方が違うのか、実態が違うのかを確認する契機になります。

継続して更新する

一度決めた基準値を固定してはいけません。技術も体制も変わるため、定期的に見直します。

自動テストの導入、開発言語の変更、体制の入れ替え。これらは数値の水準そのものを変えます。年に1度は実績を集計し、基準値を更新します。

また、基準値を評価に使わないという運用上の配慮も必要です。数値で評価されると、バグを報告しなくなるという逆効果が生じます。改善のための道具として位置づけを明確にします。

まとめ

バグ密度は、検出バグ件数を開発規模で割った指標です。IPAの「ソフトウェア開発分析データ集2022」では、全開発種別で結合テストが中央値1.111件/KSLOC、総合テストが0.197件/KSLOCと示されています。

使う際は中央値を基準にします。平均値は一部の極端な値に引っ張られるため、分布とあわせて確認する必要があります。P25とP75の幅の広さも把握しておきます。

注意点は3つです。現象数と原因数は比較できないこと、母集団の97%がウォーターフォール型の受託開発であること、そして規模の測り方を揃えないと比較が成立しないことです。

そして最も重要なのは、バグ密度が示すのは「どれだけ見つけたか」であって「何を確かめたか」ではないという点です。テスト密度と組み合わせ、重要度も含めて判断します。

まずは直近で完了したプロジェクト1件について、規模とバグ件数を集計してみてください。IPAの数値と並べたときの位置が、次に何を見るべきかを示してくれます。

開発と品質管理の進め方から、無料で相談できます リリース判断の根拠を持ちたい、社内に品質管理の知見がなく不安があるといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎