バグ密度・テスト密度の目安｜IPA基準値と計算式・ゾーン分析

バグ密度もテスト密度も、計算式そのものは割り算ひとつで終わります。実務で詰まるのは「で、いくつなら妥当なのか」という一点です。この記事は、その目安をIPA「ソフトウェア開発分析データ集2022」（5,546プロジェクトの実績値）の数値で示し、9ゾーン分析での読み方、業種別編で見える水準差、そして基準値をそのまま自社に当てはめると判断を誤る条件までを扱います。

まとめ

結論として、目安はIPAの公開実績値をたたき台にし、最終的には自社実績に置き換えます。IPA分析データ集2022（全開発種別・SLOC規模）の中央値は、結合テストでテストケース密度51.7件/KSLOC・検出バグ密度1.111件/KSLOC、総合テストで16.0件/KSLOC・0.197件/KSLOCでした。ざっくり言えば「1,000行あたり結合テスト50件、1万行あたり結合テストのバグ12件」の相場観になります。

ただし、この基準値には4つの前提があります。対象は結合テストと総合テストの2工程だけで単体テストの基準値が存在しないこと、分布が右に大きく裾を引いていて平均値は使えないこと（結合テストの検出バグ密度は中央値1.111に対し平均22.866）、業種によって水準が2倍以上ずれること（結合テストのテストケース密度は製造業編34.47・金融・保険業編83.2）、そしてこのデータ集は2022年版が最終で今後更新されないことです。数値の出どころと限界を押さえたうえで、以降の各節で計算式・工程別の基準値表・業種別の水準差・ゾーン分析・自社基準への落とし方を見ていきます。

バグ密度とテスト密度の計算式・単位と集計前提を実務で揃える方法

どちらも「規模あたりの件数」を出す指標です。規模には行数（SLOC）かファンクションポイント（FP）を使い、1,000単位に正規化して比較します。工程の切り方そのものがぶれていると密度も揃わないため、システム開発のテスト工程の区分とV字モデルの対応を先に固定してから測り始めるのが順番として安全です。

計算式の形と、規模をSLOCとFPのどちらで測るかの実務判断

バグ密度は検出バグ数÷規模、テスト密度はテストケース数÷規模で求めます。単位は件/KSLOC（1,000行あたり）または件/KFP（1,000FPあたり）です。

規模の測り方は業種によって異なるものです。組み込みソフトウェアのようにソースコードを直接管理する開発ではSLOC、業務システムの受託開発では見積り単位に合わせてFPが使われます。IPAのデータもSLOC規模とFP規模で別々に集計されており、後述の基準値表もSLOC用とFP用で数値がまったく違います。自社がどちらで規模を測っているかを先に決めないと、基準値を引き写しても意味を持ちません。FP側の数え方が固まっていないなら、ファンクションポイント法の計算方法と重み表を押さえてから密度の話に入ってください。

欠陥密度・不良密度・試験密度という呼び方の違いと数え方の実務基準

バグ密度は現場ごとに欠陥密度・不良密度・不具合密度・障害密度と呼ばれ、テスト密度は試験密度・テストケース密度と呼ばれます。指標としては同じもので、割る対象（規模）と割られる対象（バグ件数）の定義が揃っていれば呼称は問いません。

危ないのは呼称ではなく、件数の数え方が組織内で揃っていないことです。IPAは検出バグを「現象数」と「原因数」に分けて集計しており、同じプロジェクトでも数え方を変えれば密度は変わります。1つの原因が10画面で再現すれば、現象数では10件、原因数では1件です。IPA自身も「現象数と原因数のデータを提出しているそれぞれのプロジェクト群は重なりが少ないため、数だけのデータでは比較できない」と注記しており、現象数の表と原因数の表を混ぜて使うこともできません。基準値と比較する前に、自社の集計が現象数と原因数のどちらなのかを確認してください。

もうひとつ揃えるべきは、テストケースを何単位で数えるかです。1シナリオを1件と数える現場と、期待値の確認項目ごとに1件と数える現場では、同じテストで密度が数倍変わります。粒度の議論に踏み込むならGoogle流のテストサイズによる分類のように、工程名ではなく実行範囲でテストを層に分ける考え方が参考になります。

IPA分析データ集2022が示すバグ密度・テスト密度の基準値

国内で最も引用されている目安は、IPA（情報処理推進機構）が公開する「ソフトウェア開発分析データ集2022」です。累計5,546プロジェクトの定量データを収集した資料で、第5章「テスト検出バグ」に、結合テストと総合テストの規模あたりテストケース数・検出バグ数が四分位（P25／中央値／P75）で載っています。この記事の基準値はすべてこの資料の値で、公開は2022年9月26日、ページの最終更新は2025年8月28日でした（2026年8月時点で確認）。

注意点として、各表のN（集計対象プロジェクト数）は5,546ではありません。SLOC規模・結合テストのテストケース密度でN=665、検出バグ密度（現象数）でN=507です。さらに集計対象は「開発5工程（基本設計から総合テストまで）のフェーズ有無がすべて○」のプロジェクトに限られます。数値を引用するときは、この母数と層別条件も一緒に押さえてください。

SLOC規模の基準値と現象数・原因数それぞれの中央値を比べる基準

全開発種別の集計値です。IPA自身は運用方法を規定していませんが、実務ではP25を下限、中央値を標準、P75を上限とする三段構えが広く使われています。

現象数と原因数を並べると、結合テストでは現象1.111に対し原因1.042とほぼ同じ水準、総合テストでは逆に原因（0.246）のほうが現象（0.197）より高く出ています。直感に反する並びですが、これは同じ母集団を数え方だけ変えた結果ではなく、提出プロジェクト群が別だからです。自社の数え方に対応するほうの行だけを見て、もう一方は参照しないでください。

開発種別で動く基準値：新規開発・改良開発・再開発の差を比べる軸

開発種別でも数値は動きます。3種別の中央値は次のとおりです（カッコ内はP25／P75）。

改良開発のほうがテストケースは多く、バグは少ない。既存コードへの回帰テストが積み上がる一方、コード自体は枯れているという実態を反映した数字です。自社が改修案件中心なのに新規開発の基準値をあてると、テストケース密度は「不足」、バグ密度は「多すぎ」と両方を誤判定します。改良開発の高いテストケース密度をどう積むかはリグレッションテストの範囲選定と自動化の判断と直結する話で、範囲を絞りすぎれば密度も検出力も同時に落ちます。

再開発（既存システムの作り直し）は、テストケース密度が新規開発と改良開発の中間、バグ密度は新規開発より低い位置に来ました。仕様が既知である一方で実装は新しいという性質が、両者の中間値として現れています。

FP規模の基準値は母数が小さく幅の広い参考値にとどまる理由と条件

FP規模の全開発種別（結合テスト）は、テストケース密度がP25 668.8・中央値1,782.3・P75 3,450.8件/KFP、検出バグ密度（現象）が41.0・91.2・164.1件/KFPです。総合テストはテストケース密度252.4・556.9・1,500.0、検出バグ密度（現象）10.5・30.1・80.0となります。原因数ベースなら結合テスト94.0、総合テスト34.0が中央値になります。

ただしFP規模のデータは母数が小さく、結合テストのテストケース密度はN=42件しかありません（SLOC規模は665件）。IPA自身も「データ件数Nが小さいので、変動したとは言えない」と注記しています。FP基準値は幅の広い参考値として扱い、判定の閾値に使うなら自社の過去案件を数件でも足して補正するべきです。

リリース後の発生不具合密度は10万行に1件という相場観の読み方

「バグ密度の目安」を探す人のうち、テスト工程ではなく出荷品質を知りたいケースもあります。IPAは稼働後6か月の発生不具合密度も集計しており、新規開発（SLOC規模・全体）で中央値0.000・P75 0.077・平均0.100件/KSLOCでした。同資料は全体傾向として「不具合は10万行で1個（中央値）、1万行で1個（平均値）」とまとめています。

中央値が0.000というのは、リリース後6か月で不具合報告ゼロのプロジェクトが半数を超えるという意味です。ただし規模別に分けると様子が変わります。40KSLOC未満では中央値0.000のままですが、40KSLOC以上100KSLOC未満で0.008、100KSLOC以上300KSLOC未満で0.007、300KSLOC以上で0.010と、大規模側では中央値がゼロを離れました。小規模案件の「不具合ゼロ」が全体の中央値を押し下げている構図なので、規模帯を合わせずに自社の値と比べると過大評価になります。

テスト工程の検出バグ密度（結合テスト中央値1.111件/KSLOC）と比べると、平均値ベース（0.100）でも約11倍、IPAが相場観として示す中央値ベース（10万行に1個＝0.01件/KSLOC）なら100倍以上の開きがあります。両者を同じ「バグ密度」として並べて比較しないでください。

ゾーン分析でテスト密度とバグ密度を2軸から実務で具体的に読む手順

密度は単独では解釈できません。バグ密度が低いのは品質が良いからなのか、単にテストしていないからなのか、片方の数字だけでは区別がつかないためです。そこでテスト密度を横軸、バグ密度を縦軸に取り、それぞれ下限・上限の基準値で3分割して9つの領域に当てはめるのがゾーン分析です。なおゾーン分析はIPAの資料に定義があるわけではなく、IPAの基準値を上下限として現場で運用されてきた読み方になります。

9ゾーンの読み方と、外れたときに次へ取るべき行動の実務判断基準

実務で最も危険なのはゾーン⑨（テスト密度・バグ密度ともに低い）です。数字だけ見れば静かで、報告資料上は問題なく見えますが、実際にはテストが足りずバグが見つかっていないだけの可能性があります。この領域に落ちたモジュールは、密度をいじって基準内に見せるのではなく、テスト観点表を突き合わせて漏れを探すのが唯一の対処です。

もう一点。ゾーン分析はテスト完了後の判定会でやると手遅れになります。テスト実行中に週次以上の頻度で見て、外れているモジュールをその場で手当てする使い方が本来です。判定会に間に合わせるためだけに集計する運用になっているなら、指標そのものより集計サイクルの設計を先に直してください。

業種別編で比べるバグ密度・テスト密度の水準差と選び方の判断基準

ここは他社記事がほとんど触れていない部分です。IPAは本編（全業種）とは別に、金融・保険業編、情報通信業編、製造業編の3つを業種別編として公開しています。本編と同じ表番号・同じ層別条件で集計されているので、数値をそのまま横に並べられます。

金融・保険業と情報通信業と製造業で基準値はどう動くかを比べる軸

SLOC規模・全開発種別・中央値で並べると次のようになります（カッコ内はN）。

結合テストのテストケース密度は、製造業編の34.47から金融・保険業編の83.2まで2.4倍の開きがあります。検出バグ密度は逆向きで、金融・保険業編が0.986と最も低く、情報通信業編1.808・製造業編1.723が上に来ました。テストを厚く積む業種ほど工程単位のバグ密度は下がる、という読み方が素直な解釈になります。IPA自身も金融・保険業編で「1,000行あたり80個の結合テスト」という相場観を別途示しており、本編の「50個」とは前提が違います。

総合テストの検出バグ密度は、製造業編の0.429が本編0.197の2倍以上です。組み込み開発では実機結合の段階で表面化する不具合が多く、上流で潰しきれない構造がそのまま数値に出ています。組み込み案件で本編の0.197を上限扱いにすると、正常な進行を「品質不良」と誤判定しかねません。

自社に近い母集団を選ぶときに確かめる3つの前提条件と実務判断軸

業種別編を選ぶ判断は、発注者の業種ではなく開発対象の性質で行います。確認するのは次の3点です。第一に規模の測り方で、SLOCで測る開発なら製造業編・情報通信業編、FP中心の業務システムなら金融・保険業編のほうが母集団は近くなります。第二にNの大きさで、情報通信業編の結合テスト検出バグ密度はN=37と小さく、閾値ではなく参考値の扱いが妥当です。第三に開発種別の構成で、改修・保守が中心なら本編の改良開発の行（結合67.91／0.976）のほうが業種別編の全開発種別より近いこともあります。

3つとも合致する資料が無いなら、業種別編に寄せるより本編の開発種別別の表を使い、自社実績で補正するほうが安全です。母集団の近さは「業種名の一致」ではなく「テストの積み方の一致」で決まります。

IPA基準値をそのまま社内標準にすると判断を誤る条件と見極め方

基準値を導入する側にとっては、ここが一番効く部分です。IPAの数値は「そのまま社内標準にできる完成品」ではありません。次の4条件に当てはまるなら、引き写しは避けてください。

単体テストの密度基準値はIPAに存在しないという前提と判断基準

IPA分析データ集2022で密度の基準値（規模あたりテストケース数・検出バグ数）が示されているのは、第5章「テスト検出バグ」が対象とする結合テストと総合テスト（ベンダ確認）の2工程だけです。単体テストの密度は集計対象に含まれていません。「単体テストのテスト密度はIPAで何件？」という問いに公式の答えは無く、単体テストの目安が必要なら自社実績を測るしかありません。JUnitによる単体テストの書き方と基本で扱うように、単体テストはケース数より観点の質で決まる面が強く、密度指標との相性がそもそも良くない工程でもあります。

平均値を基準に据えると全プロジェクトが異常判定になる理由と条件

結合テストの検出バグ密度は、中央値1.111に対して平均22.866、標準偏差353.638です。最大値は7,846.154件/KSLOCに達します。極端な外れ値が平均を引き上げているため、平均値を標準値に据えると、まともなプロジェクトがそろって「バグが少なすぎる」判定になります。基準値には必ず中央値とP25／P75を使ってください。

この最大値7,846.154は業種別編を突き合わせると金融・保険業編にも同じ値で現れます。つまり本編の平均を壊しているのは特定の1件で、テストケース密度側の最大値100,000.0件/KSLOCも同様の性質です。単一の外れ値が平均と標準偏差を支配する分布では、平均を語ること自体に意味がありません。

自動テストが増えるとテスト密度は指標として成立しない理由と条件

テスト密度は「テストケース数」を数える指標です。CIで自動テストを回す開発では、パラメータ化テストで1メソッドから数十ケースが生成され、ケース数はコードの書き方ひとつで何倍にも振れる仕組みです。GitHub Actionsでビルドと自動テストを組む手順のようなCI前提の開発に、手動テスト時代の件数基準を当てるのは無理があります。自動テストが主体の領域では、密度よりテストカバレッジのC0・C1・C2という網羅率や、静的解析と動的テストの検出範囲の違いを踏まえた検出手段の組み合わせで品質を見るほうが実態に合います。

データ集2022が最終版で今後は更新されないという事実と注意点

IPAは公式サイトで「事業終了に伴い、『ソフトウェア開発分析データ集』の今後の発行予定はございません」と告知しています。2022年版が最終版で、以後の技術トレンド（自動テストの普及、クラウド前提の開発、生成AIによるコード生成）は反映されません。IPA基準値は「初期値」として使い、案件を重ねながら自社の中央値・P25・P75へ置き換えていく前提で運用してください。基準値の更新計画が無いまま社内標準として固定化すると、数年で実態と乖離します。

なお同ページには正誤表も掲載されています。PDF本文の数値をそのまま社内標準に転記する前に、正誤表の該当箇所を必ず突き合わせてください。転記ミスではなく資料側の訂正で数字が変わっている場合、後から差分の説明ができなくなります。

密度が基準から外れたときの切り分けと読み解きを実務で進める手順

数値が外れること自体は問題ではありません。外れた理由を特定できないまま報告書の数字だけ整えることが問題です。

バグ密度が基準を超過したときの切り分け手順と原因を探る判断軸

まずモジュール単位への分解が出発点です。全体で基準超過でも、押し上げているのが特定モジュールに限られることがあります。その場合は該当モジュールの再設計・再レビューで収束します。全モジュールで一様に高いなら、要件・設計工程の品質か、開発チームの実装品質そのものが原因です。テスト工程での作業では回収しきれないので、上流に戻す判断が要ります。

上流に戻す判断をした後、実装レベルで効くのはコードレビューの観点設計と運用の立て直しです。IPAの基本設計レビュー指摘密度は中央値2.500件/KSLOC（N=405）、ページあたりでは0.216件/ページ（N=353）が中央値でした。テスト工程でバグ密度が跳ねているのにレビュー指摘密度が中央値を大きく下回っているなら、レビューが形骸化している可能性を先に疑うべきです。

バグ密度が基準を下回ったときの観点漏れを点検する進め方と判断軸

低密度は良い兆候とは限りません。テスト密度が同時に低ければテスト不足、テスト密度が十分ならテストケースの観点が偏っている可能性があります。ブラックボックステストとホワイトボックステストの違いを踏まえ、入力値の同値分割・境界値・異常系といった観点で穴を探すのが実務的な確認手順です。テストを先に書くテスト駆動開発（TDD）の基本サイクルを採る現場では、実装前に書いたテストがそのまま観点表として使えるため、この点検の起点にできます。

観点表の突き合わせでも穴が見つからないときは、設計済みのケースを増やす方向ではなく、探索的テストのチャーター設計とセッション記録で未知の観点を掘りに行くほうが効率的です。設計書から導けるケースを数え上げても、設計書に書かれていない前提の抜けは検出できません。

収束曲線と組み合わせてリリース可否の判定に使う方法と判断基準

密度は「量」の指標なので、時間軸の情報を持ちません。テスト後半で検出バグの発生が鈍化しているか（バグ収束）を累積バグ数の推移で確認し、密度が基準内かつ収束傾向にあることをリリース判定の条件にします。密度が基準内でも、最終日まで一定ペースでバグが出続けているなら、未検出バグが残っている前提で判断すべきです。密度・収束を含む工程全体の管理の組み立てはシステム開発の品質管理を工程別に整理した記事で扱っています。

IPA基準値を自社基準へ置き換える手順と実務で適切に併用する指標

IPAの数値は初期値であって終着点ではありません。データ集が更新されない以上、自社の実績値へ移していく作業は避けて通れないものになります。

自社の中央値と四分位を出すために集める必要なデータ項目と集計条件

集めるのは4項目だけです。工程区分（結合／総合）、規模（実効SLOCまたはFP実績値）、テストケース数、検出バグ数。加えて開発種別（新規／改良／再開発）を属性として持たせます。IPAと同じ層別条件（基本設計から総合テストまでの工程が揃っている案件に限る）を自社でも課すと、比較可能性が保てます。

件数の目安として、IPAが「参考値扱い」と注記しているNは40件前後でした。自社データが10件に満たない段階では中央値も四分位も安定しないので、その間はIPA値を暫定基準に据え、案件ごとに自社値を並記して差を見るだけにとどめます。20件を超えたあたりから自社の四分位が形になり、30件前後で判定の閾値として使えるようになる、という進み方が現実的です。集計と可視化の仕組みを内製で持ち切れないなら、保守運用と内製化支援のように、メトリクス収集の仕組みづくりから運用移管までを外部と分担する選択肢もあります。

レビュー指摘密度やカバレッジと併用して指標の弱点を埋める方法

バグ密度とテスト密度だけでリリース判断を組むと、重大度の区別が抜けたまま「件数が基準内だから可」という結論になりがちです。併用する指標は3つあります。前工程を見るレビュー指摘密度（基本設計で中央値2.500件/KSLOC）、テストの網羅を見るカバレッジ、そして品質特性そのものを見る枠組みです。

3つ目についてはISO/IEC 25010の品質特性一覧が使えます。バグ密度は機能適合性の一側面しか見ていないため、性能効率性やセキュリティは密度が基準内でも未評価のまま残ります。密度が示すのは「どれだけ数えたか」であって、「何を確かめたか」ではありません。指標を増やす前に、この線引きをチーム内で共有しておいてください。

よくある質問

バグ密度の目安は何件ですか？

IPA「ソフトウェア開発分析データ集2022」の全開発種別・SLOC規模では、結合テストの検出バグ密度（現象数ベース）が中央値1.111件/KSLOC（P25 0.468／P75 2.402）、総合テストが中央値0.197件/KSLOC（P25 0.051／P75 0.639）です。FP規模なら結合テスト91.2件/KFP、総合テスト30.1件/KFPが中央値になります。

テスト密度の目安は何件ですか？

同資料で、結合テストのテストケース密度が中央値51.7件/KSLOC（P25 22.2／P75 120.1）、総合テストが中央値16.0件/KSLOC（P25 6.4／P75 40.7）です。IPAは全体傾向として「1,000行あたり50個の結合テスト、15個の総合テスト実施の相場観」とまとめています。

単体テストのテスト密度・バグ密度の基準値はIPAにありますか？

ありません。IPAの集計対象は結合テストと総合テスト（ベンダ確認）の2工程で、単体テストの密度基準値は公開されていません。単体テストの目安が必要な場合は、自社の過去案件から中央値と四分位を算出してください。

バグ密度は意味がないと言われるのはなぜですか？

バグの重大度を区別せず、致命的な障害1件と表記ゆれ1件を同じ「1件」として数えるためです。また、テスト密度と切り離して単独で見ると「品質が良い」と「テストしていない」を区別できません。重大度別に分けて集計し、テスト密度との2軸（ゾーン分析）で読むことで、指標としての弱点はかなり埋まります。

組み込みソフトの品質指標にもIPAのバグ密度は使えますか？

利用可能です。組み込み開発はFPではなくSLOCで規模を測るため、件/KSLOCの基準値がそのまま対応します。ただし本編（全業種）より「ソフトウェア開発分析データ集2022（製造業編）」のほうが母集団は近く、数値も違います。製造業編の中央値は結合テストでテストケース密度34.47・検出バグ密度1.723、総合テストで15.09・0.429でした。密度単独では品質を判定できないので、レビュー指摘密度やコードカバレッジと併用してください。

IPAの基準値はどの資料を見ればよいですか？

IPA公式サイトで公開されている「ソフトウェア開発分析データ集2022」（PDF）の第5章「テスト検出バグ」に、SLOC規模・FP規模それぞれの表があります。同じページに金融・保険業編、情報通信業編、製造業編の3編と正誤表も並んでいるので、自社に近い業種編を先に確認してください。前身は「ソフトウェア開発データ白書2018-2019」で、古い記事が引用しているのはこちらの数値です。データ集は事業終了により2022年版が最終版となっています。

関連記事

• システム開発の品質管理とは？受託開発の工程別レビュー・テスト管理とメトリクス運用
• システム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸
• テストカバレッジとは？C0/C1/C2の網羅率と計測ツール・目標設定を実装者向けに解説
• リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断を解説
• 探索的テストとは？チャーター設計・セッション記録と自動テスト化を実装者向けに解説
• 静的解析と動的テストの違いとは｜検出できるバグ・代表ツール・使い分けを比較
• ブラックボックステストとホワイトボックステストの基本的な違いとは何か
• JUnitとは？Javaの単体テストフレームワークの基本と書き方【2026年版】
• テスト駆動開発（TDD）の基礎：概要と基本サイクルを初心者向けに徹底解説