社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

現実的な設定に基づいたバグ予測モデルの構築及び精度評価
荻野

翔†

肥後

芳樹†

楠本

真二†

† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{s-ogino,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし

バグ予測は品質保証に必要なコストを低減できると期待されている．バグを予測するモデルを構築する場

合，以下の 3 つの条件を全て満たす現実的な設定が用いられるべきである．1 つ目に，データセットの構築方法について，モデルの予測能力を正しく評価できる方法が用いられている．2 つ目に，予測対象の粒度について，品質保証のコストを最小化する最適な粒度が採用されている．3 つ目に，目的変数について，予測対象となるソフトウェアモジュー
ルのバグの有無を正しく表す指標が用いられている．しかし，これらの条件を全て満たす設定で構築されたバグ予測
モデルについての精度評価実験は未だ行われていない．そこで本研究では，これらの条件を満たす現実的な設定のもとでバグ予測モデルを構築し，その予測精度を計測した．実験の結果，構築されたバグ予測モデルの F 値は 0.18 と低く，現実的な設定のもとで高精度のバグ予測モデルを構築するには大きな課題が残されていると判明した．
キーワード 品質保証，バグ予測，機械学習

1. ま え が き

体的には，目的変数として，「その時点でソフトウェアモジュー
ルにバグが存在するかどうか（isBuggy）」という指標ではな

近年，ソフトウェア開発の規模は増大の一途を辿っている [1]．

く，「過去の一定期間内で一度でもバグが修正されたかどうか

このような状況で，開発コストを低減する技術は重要である．

（hasBeenFixed）」という指標が設定されている点が問題である．

開発コストの中でもレビュー等の品質保証に必要なコストが大

なぜなら，ソフトウェアモジュールには，「hasBeenFixed につきいため，それを低減する技術は特に重要である [2]．

いて偽だが isBuggy について真である」という状況があり得る

品質保証に必要なコストを低減する技術としてバグ予測が存在する．バグ予測とは，プロジェクトを構成するソフトウェア

ため，hasBeenFixed を目的変数とするモデルはバグを正しく予測できていない可能性があるからである．

モジュール（例：ソースファイル）に対象に，バグの有無を予Pascarella らが下した結論について真偽を確かめるために，測することである．バグ予測によりバグが存在するソフトウェ

hasBeenFixed がバグ予測モデルの目的変数として適切かを調査

アモジュールを特定し，それらを重点的にレビューすることで，すべきであり，もし適切でないならば，現実的な設定に基づい品質保証に必要なコストを低減できる．

て構築されたバグ予測モデルについて予測精度を調査すべきでバグを予測するモデル（バグ予測モデル）の予測能力を正しある．しかし，そのような調査は未だ行われていない．そこで，く評価するためには，データセットを適切に構築すべきであ

著者らはまずバグ予測モデルの目的変数として hasBeenFixed がる．従来，プロジェクトのある時点に存在するソフトウェアモ

適切かどうかを調査した．次に，目的変数・データセットの構

ジュールについて目的変数を算出し，プロジェクト開始時から

築方法・予測対象の粒度について現実的な設定を用いて構築さその時点までの開発履歴を用いて説明変数を算出することでれたバグ予測モデルについて精度評価実験を行った．

データセットが構築されていた [3] [4]．しかし，上記のようにその結果，hasBeenFixed はバグが存在するメソッドの 25 ％構築されたデータセットでは，モデルの予測能力が正しく評価

しか検出できず，バグ予測モデルの目的変数としては不適切だ

されないと Pascarella らは批判した [5]．Pascarella らはその問と判明した．また，現実的な設定のもとで構築されたバグ予測

題を回避できるデータセットの構築方法としてリリースバイリ

モデルの F 値は 0.18 であり，現実的な設定のもとで高精度のリースという手法を提案し，その手法を用いてバグ予測モデル

バグ予測モデルを構築するためには大きな課題が残されているの予測精度を調査した．その結果，低い予測精度が計測され，ことが明らかになった．

高精度のバグ予測モデルを構築するには大きな課題が残されていると彼らは結論づけた．

2. 研 究 背 景

しかし，Pascarella らがリリースバイリリースの調査を目的とバグ予測モデルの構築において，様々な設定が混在する．本して構築したバグ予測モデルの設定には議論の余地がある．具章では，本研究と関わりが深い項目として，予測対象の粒度と—1—

データセットの構築方法について紹介する．

RQ2 の目的は，以下に示す現実的な設定を用いてバグ予測モデ

2. 1 予 測 粒 度

ルを構築した場合の予測精度を明らかにすることである．

これまでバグ予測モデルの研究に採用されてきた予測対象の目的変数：isBuggy

粒度としては，ソースファイル・メソッド・コミットの 3 種類

予測粒度：メソッドが存在する．本研究ではメソッドを予測粒度としたバグ予測モ

データセットの構築方法：リリースバイリリース

デルについて調査する．なぜなら，本研究では Pascarella らの予測精度が低ければ，バグ予測モデルについての研究にはまだ結論の真偽を確かめることを目標の 1 つとしており，Pascarella

課題が残されており，Pascarella らの結論は正しいと言える．

らは現実的な設定として予測粒度にメソッドを採用しているか

RQ3: 現実的な設定のもとで構築されたバグ予測モデルのらである．

予測精度は，開発履歴の量が変化するとどのように変化す2. 2 データセットの構築方法
バグ予測モデルの予測精度を正しく評価するためには，適切なデータセットの構築方法を採用すべきである．従来，プロジェクトのある時点に存在するソフトウェアモジュールについて目的変数を算出し，プロジェクト開始時からその時点までのるか．


リズムを変化させるべきか等の知見を得ることである．

4. 各 RQ に共通する実験設定

開発履歴を用いて説明変数を算出することでデータセットが構築されていた [3] [4]．そのようにデータセットを構築する場合，本章では，各 RQ で共通する実験設定について述べる．

大半のメソッドについてバグの有無が判明している状態で残り

4. 1 調 査 対 象のメソッドのバグを予測するという非現実的な状況下でのバグ予測精度が評価されてしまうと Pascarella らは批判した．



RQ3 の目的は，開発履歴の量によって，利用するモデルアルゴ

本実験が調査対象とするプロジェクトの概要が表 1 に記されている．以下の 6 つの理由により，これらのプロジェクトを選

そして Pascarella らは，そのような問題を回避できる適切なデータセットの構築方法としてリリースバイリリースを提案し択した．

た．リリースバイリリースは，プロジェクトのあるリリース時に存在するソフトウェアモジュールについて，目的変数と説明
変数を算出する．このとき，説明変数は 1 つ前のリリースから
そのリリースまでの開発履歴を用いて算出する．リリースバイ
リリースに基づいてデータセットを構築する具体的な手順については，詳細を 6. 1. 4 項で述べる．

•

GitHub でリポジトリが公開されている．

•

Java で開発されている．

•

Jira で 1,000 以上のバグレポートが取得可能である．

•

コミット数が 10,000 以上である．

•

4 回以上のメジャーリリースが行われている．

•

セマンティックバージョニングが採用されている．

4. 2 リリースの特定方法
本研究では，2. 2 節で説明されたリリースバイリリースという

3. Research Questions

手法でデータセットを構築する．そのためには，対象プロジェ

本研究では，以下の Reasearch Question (RQ) を調査する．

クトの各リリースのタイミングを特定する必要がある．本研究RQ1: hasBeenFixed はバグ予測モデルの目的変数として適では，Pascarella らが提案した方法に従い，セマンティックバー

切か．

ジョニングを採用したプロジェクトについて，リリースを以下のように特定する．セマンティックバージョニングは，X.Y.Z

RQ1 の目的は，先行研究のモデルの目的変数が適切かを定量的という形式（例: 1.0.0）でバージョンを表すバージョン表記でに判定することである．

ある．セマンティックバージョニングでは，X がメジャーバー

例えば，hasBeenFixed が真であるメソッドに isBuggy が真でジョンを表す．メジャーバージョンのリリース，つまり Y と Z

あるメソッドの大半が含まれない場合，hasBeenFixed を目的がともに 0 であるようなバージョンのリリースをプロジェクト

変数として採用したモデルはバグの所在を正しく予測できず，のリリースとして特定する．

4. 3 hasBeenFixed の算出方法

hasBeenFixed はバグ予測モデルの目的変数として不適切である
と言える．





前提として，プロジェクトのリポジトリを GitHub 等から取得できているとする．また，そのプロジェクトのバグレポート

RQ2: 現実的な設定のもとで構築されたバグ予測モデルのを Jira 等から取得できているとする．

予測精度はどの程度か．



各メソッドについて，hasBeenFixed は以下のように算出さ表 1 対象プロジェクト一覧
プロジェクト名

開発期間 コミット回数

リリース回数

バグレポート数

バグが存在するメソッドの割合（リリース時）

lucene-solr 18 年 348 日

34,037

9

6,198

1.9%

wicket 15 年 337 日

20,925

7

2,868

1.2%

cassandra 11 年 145 日

23,537

4

5,351

5.2%

—2—

メソッド名 hasBeenFixed

リポジトリ収集
リリース特定

good

𝑋
𝐴

𝐵

𝑋
𝐴

𝐵

isBuggyinitialize

偽偽update真偽getName

偽

真

𝑋
X :
メソッドの全体集合 𝐴
𝑨 : hasBeenFixedが真のメソッドの集合
𝑩:
isBuggyが真のメソッドの集合

isBuggy,
hasBeenFixedの算出

𝐵

bad

hasBeenFixedの評価

図 1 RQ1 について行う実験の流れれる．

step4 すべてのバグレポートについて上記の操作が完了した時

step1 過去に発見されたバグについてはバグレポートが発行に，isBuggy が真でないメソッドは，isBuggy が偽である．

されており，バグレポートには ID が付与されている．その IDがコミットメッセージに記されているコミットが，そのバグに

5. RQ1

ついて修正を行うコミット（バグ修正コミット）である．バグ

RQ1 では，hasBeenFixed という指標はバグが存在するメソッ

修正コミットを取得するために，コミットメッセージにバグレドを検出できているのか，すなわち hasBeenFixed という指標はポート ID が記されているコミットをリポジトリから検索する．

バグ予測モデルの目的変数として適切かを調査する．

step2 検索により得られたバグ修正コミットでは，あるメソッ

5. 1 実 験 設 定

ド A のある行について修正が行われているとする．そのコ

5. 1. 1 実験の流れ

ミットが n − 1 番目のリリース（ Rn−1 ）から n 番目のリリース

RQ1 について調査するために，実験を行う．その概要を図 1（ Rn ）までの区間に含まれる場合，メソッド A は Rn の時点でと以下に示す．

hasBeenFixed が真である．

step1 リポジトリ・バグレポートを収集する．

step3 すべてのバグレポートについて上記の操作が完了した時

step2 各リリース時に存在するメソッドについて，isBuggy・に，hasBeenFixed が真でないメソッドは，hasBeenFixed が偽で

hasBeenFixed を算出する．

ある．

step3 hasBeenFixed の適切さを評価する．

4. 4 isBuggy の算出方法

5. 1. 2 評 価 指 標

前提として，プロジェクトのリポジトリを GitHub 等から取hasBeenFixed が適切かを評価する指標としては，以下に示す

得できているとする．また，そのプロジェクトのバグレポート

再現率を用いる．

を Jira 等から取得できているとする．

isBuggy の算出には SZZ アルゴリズム [6] を利用し，実装としては [7] を用いた．各メソッドについて，isBuggy は以下のよ

再現率＝|XhasBeenFixed ∩ XisBuggy ||XisBuggy |うに算出される．

ここで， XhasBeenFixed は hasBeenFixed が真と評価されるメ

step1 hasBeenFixed の算出方法の step1 と同様である．過去にソッドの集合，XisBuggy は isBuggy が真と評価されるメソッド

発見されたバグについてはバグレポートが発行されており，バ
グレポートには ID が付与されている．その ID がコミットメッ
セージに記されているコミットが，そのバグについて修正を行
うコミット（バグ修正コミット）である．バグ修正コミットを取得するために，コミットメッセージにバグレポート ID が記されているコミットをリポジトリから検索する．

step2 検索により得られたバグ修正コミットで，あるメソッド
A のある行について修正が行われていると仮定する．ここで，修正された箇所はバグであったとみなせる．修正された箇所を挿入したコミットを，"git diﬀ"等の操作によって特定し，そのコミットをメソッドにバグを混入させたコミット（バグ混入コの集合である．算出された再現率の値が 0.5 以下であれば，目的変数として hasBeenFixed を採用したバグ予測モデルは半数
以上のバグを予測できないため，hasBeenFixed はバグ予測モデ
ルの目的変数として不適切であるとする．

5. 2 実 験 結 果
実験の結果を表 2 に示す．表 2 は，各プロジェクトにおける再現率の値，すなわち hasBeenFixed という指標が実際のバグを検出した割合を示している．プロジェクトごとの再現率の値，
そして平均値はいずれも 0.50 を大幅に下回っている．よって，

hasBeenFixed はメソッドのバグの有無を表せておらず，バグ予測モデルの目的変数として不適切であると言える．

ミット）と定義する．

step3 メソッド A についてのバグ混入コミットが Rn 以前に存在し， Rn 以降にそのバグについてのバグ修正コミットが存在する場合， Rn の時点でメソッド A は isBuggy が真である．

表 2 isBuggy に対する hasBeenFixed の再現率

lucene-solr wicket cassandra 平均値
再現率

0.195

0.254

0.353

0.25

—3—

データ収集メソッド名

目的 説明変数
変数 A B C

initialize

0

7

6

5

update1396

getName

1

8

7

6

データセット構築

適合率
再現率
F値

モデル構築

モデル評価

図 2 RQ2 について行う実験の流れ

6. RQ2

リリース

開発過程の予測精度を調査する．

6. 1 実 験 設 定
6. 1. 1 実験の流れ
RQ2 について調査するために，実験を行う．その概要を図 2と以下に示す．

step2 収集されたデータを元にデータセットを構築する．

𝑆1

𝑇1

𝑆2

𝑆2

𝑇2

𝑆3

𝑆3

𝑆3

𝑇3

𝑆𝑛−1

𝑆𝑛−1

𝑆𝑛−1

𝑆𝑛−1

step3 データセットを元にバグ予測モデルを構築する．

𝑅𝑛−1 𝑅𝑛

データブロック

学習
用

・
・
・

step1 リポジトリ・バグレポートを収集する．

テ学
ス習
トデ
デー
ータ
タセ
セッ
ット
ト・
の
組
合
せ

𝑅4

𝑅3

𝑅2

・
・
・

𝑅1

RQ2 では，現実的な設定のもとで構築されたバグ予測モデル

𝑇𝑛−1

図 3 データセットの概要

step4 バグ予測モデルの予測精度を評価する．
6. 1. 2 目 的 変 数
目的変数としては isBuggy を設定した．定義は 4. 4 節で述べられた．

このとき，図 3 に示すように，プロジェクト開始から k 番
目のリリース（ Rk ）までの開発履歴を用いて構築されるデータセットを学習データセット Sk とし， Rk から Rk+1 までの開発

6. 1. 3 説 明 変 数
説明変数としては，Pascarella らが用いたプロダクトメトリ
クス・プロセスメトリクスを採用した．その概要を表 3，表 4に示す．プロダクトメトリクスとは，ソースコード単体から得られるメトリクス（例：ソースコードの行数）である．プロセ
スメトリクスとは，開発履歴から得られるメトリクス（例：コミットの回数）である．

6. 1. 4 学習データセット・テストデータセットの構築
本調査においては，データセットをリリースバイリリース
で構築する．つまり，プロジェクトのリリースに着目して，リ履歴を用いて構築されるデータセットをテストデータセット Tkとすることで，リリース総数が n のプロジェクトからは，n − 1
個の学習データセット・テストデータセットの組合せが得られる．
あるプロジェクトについて Sk ，Tk を構築する手順を以下に示す．まず，各リリース番号 m について，以下のようにデータ
ブロック Bm を構築する．

step1

Rm 時点で存在するメソッドについて以下の操作を行う．

step1-1

Rm におけるソースコード，そして Rm−1 から Rm ま

リース時に存在するソフトウェアモジュールについて目的変数を算出し，説明変数を 1 つ前のリリースからそのリリースまでの開発履歴を用いて算出し，その組合せをデータセットに追加
していくことでデータセットを構築する．

表 3 説明変数（プロダクトメトリクス）

表 4 説明変数（プロセスメトリクス）
メトリクス名概要

MethodHistories

コミット回数

Authors

そのメソッドを編集した人数

StmtAdded

追加されたステートメントの総数

MaxStmtAdded

追加されたステートメントの最大値

AvgStmtAdded

追加されたステートメントの平均値

メトリクス名概要

StmtDeleted

取り除かれたステートメントの総数

FanIn

そのメソッドを参照するメソッドの数

MaxStmtDeleted

取り除かれたステートメントの最大値

FanOutそのメソッドが参照するメソッドの数

AvgStmtDeleted

取り除かれたステートメントの平均値

LocalVar

ローカル変数の数

Churn

StmtAdded - StmtDeleted

Parameters

引数の数

MaxChurn

Churn の最大値

CommentToCodeRatio ソースコードに対するコメントの割合（行単位）

AvgChurn

Churn の平均値

CountPath

実行可能経路の数

Decl

メソッド宣言の変更回数

Complexity

サイクロマティック数

Cond

条件文の変更回数

execStmt

実行可能ステートメントの数

ElseAdded

else 文の追加回数

maxNesting

ネストの最大値

ElseDeleted

else 文の削除回数—4—

での開発履歴に基づいて説明変数を算出する．なお，R0 はプロ

る．しかし，その RF で構築されたモデルの適合率の値は 0.12

ジェクト開始時とする．

であり，これはバグが存在すると予測されたメソッドの 9 個に

step1-2 isBuggy を目的変数として算出する．

1 個しかバグがないことを意味する．また，再現率の値は 0.55

step1-3 算出された説明変数・目的変数の組を Bm に加える．
こうして構築されたデータブロックを以下のように Sk ，Tk

であり，これはおよそ半分ほどの，バグが存在するメソッドをに分割する．

とで構築されたバグ予測モデルの予測精度はかなり低い．

検出できないことを意味する．結論として，現実的な設定のもstep1 学習データセット Sk を， k 以下の添字を持つデータブ
ロックに含まれる説明変数・目的変数の組（サンプル）によっ

7. RQ3て構成する．

RQ3 では，現実的な設定のもとで構築されたバグ予測モデル

step2 不均衡データを正しく分類できるモデルを構築するたの予測精度が，開発履歴の量が変化するにしたがってどのようめ，Sk について，目的変数 isBuggy が真であるサンプルと偽でに変化するかを調査する．

あるサンプルが同数になるように，目的変数 isBuggy が真であ

7. 1 実 験 設 定

るサンプルをオーバーサンプリング [8] する．

データセット・モデル構築時の設定は RQ2 と同様である．

step3 テストデータセット Tk を，添字が k + 1 のデータブロッ

7. 2 実 験 結 果

クに含まれるサンプルによって構成する．

実験結果を図 4， 5， 6 に示す．これらの図は，前述した現

6. 1. 5 モデルアルゴリズム

実的な設定のもとで構築されたバグ予測モデルについて，学習モデルアルゴリズムとしてはランダムフォレスト（RF），

データセット・テストデータセットの組合せごとにモデルを構

ディープニューラルネットワーク（DNN）を採用した．上記の築・評価した結果得られた F 値をグラフの形で示している．図アルゴリズムを用いる理由は，バグ予測モデルは予測精度が重4， 5， 6 からわかるように，RF の予測精度が常に DNN を上要であるため，DNN のように設定可能なパラメータが多くモデ回っている．この結果は，DNN の表現力の大きさが仇となったルの表現力があるものが望ましいからである．DNN に加えてためだと考える．つまり，前後のリリースでバグが存在するメ

RF を採用した理由は，パラメータ数が多いからといって，必ずソッドの特徴が異なっていて，前のリリースにおいてバグが存

しも DNN が RF より予測精度の観点で優れているわけではな

在するメソッドの特徴をよく学習してしまったために，後のリ

い [9] からである．

リースにおいてメソッドのバグの有無をうまく予測できなかっ6. 1. 6 パラメータチューニング

たためだと考える．

予測モデルを構築する場合，予測精度の高いモデルを構築す

結論として，現実的な設定のもとで構築されたバグ予測モデ

るためにはハイパーパラメータのチューニングが必須である．

ルの予測精度は，開発履歴の量が増加するにつれ，低下する．

本研究では，パラメータチューニングのアルゴリズムとしてはまた，本研究における設定のもとでは，どのような開発履歴量

ベイズ最適化 [10] を採用し，その実装としては optuna [11] を利であろうとも，DNN より RF をモデルアルゴリズムとして用い用した．また，パラメータチューニングには CPU として AMD

るべきである．

Ryzen 9 3950X，GPU として NVIDIA GeForce RTX 2080Ti を搭載するコンピュータを使用した．それぞれのモデルに対して 24時間を費やしてパラメータチューニングを行った．

8. 妥当性の脅威
目的変数

本研究では，修正済みと記されたバグレポートを利6. 1. 7 評 価 指 標

用して，メソッドのバグの有無を判定している．よって，正確

バグ予測モデルを評価する指標を以下に示す．

なデータセットを構築するには，存在する全てのバグが報告さ|T P||F N + T P|
|T P|
適合率 =
|FP + T P|

れ，修正されている必要がある．しかしながら，本研究で対象

再現率 =2 × 再現率 × 適合率
F値 =再現率 + 適合率としたプロジェクトには未報告のバグや，未修正のバグが存在する．この問題を解決することで，予測精度が高く有意義なモデルを構築できる可能性がある．
説明変数

本研究でバグ予測モデルの説明変数として採用したのは，ソースコード・開発履歴から算出されたメトリクスであTP はバグが存在すると予想され，実際にバグが存在したメソッ

る．メトリクスは元となるソースコード・開発履歴から抽出さドの数である．FN はバグが存在しないと予想され，実際にはれたデータであり，バグ予測に重要な情報が抽出の過程で捨てバグが存在したメソッドの数である．FP はバグが存在するとられている可能性がある．よって，他のメトリクスを採用する予想され，実際にはバグが存在しなかったメソッドの数である．

ことで，予測精度が高く有意義なバグ予測モデルが構築される

6. 2 実 験 結 果
実験結果を表 5 に示す．表 5 は，現実的な設定のもとでバグ

表 5 現実的な設定のもとで構築されたバグ予測モデルの予測精度予測モデルを構築した際の予測精度を表す．F 値の観点から見モデルアルゴリズム 適合率

再現率

F値

ると，現実的な設定のもとでは，RF の方が DNN よりもバグ予

RF

0.12

0.55

0.18

測モデルを構築するアルゴリズムとして優れていることがわか

DNN

0.10

0.63

0.15

—5—

0.35
Lucene-solr(DNN)

F値

0.3
0.25

本研究では，まず「過去の一定期間内で一度でもバグが修正

0.2

されたかどうか（hasBeenFixed）」という指標がバグ予測モデル

0.15の目的変数として適切かを調査した．そして，現実的な設定に基づいてバグ予測モデルを構築し，その予測精度を評価した．

0.1

結果として，hasBeenFixed は実際のバグの 25%しか検出せ

0.05

ず，バグ予測モデルの目的変数としては不適切であると判明し

0
1

2

3

4

5

6

予測モデルを構築することは難しいと判明した．以上の結果か

図 4 予測精度の推移（lucene の場合）

ら，現実的な設定のもとで高精度のバグ予測モデルを構築するには大きな課題が残されていると言える．

0.35
Wicket(DNN)

0.3

Wicket(RF)

0.25

F値

た．また，現実的な設定に基づいて構築されたバグ予測モデルの F 値が 0.18 であり，現実的な設定のもとでは，実用的なバグ

テストデータセットの添字n

今後の課題としては，説明変数の追加，より綿密なパラメー
タチューニング，そして対象プロジェクトの追加が挙げられる．
謝辞

0.2

本研究は，日本学術振興会科学研究費補助金基盤研究（B）（課題番号：20H04166）の助成を得て行われた．

0.15

文

0.1
0.05
0

1

2

3

4

テストデータセットの添字n
図 5 予測精度の推移（wicket の場合）
0.35
0.3

0.25

F値

9. あ と が き

Lucene-solr(RF)

0.2
0.15
Cassandra(DNN)

0.1

Cassandra(RF)

0.05
0
1

2

テストデータセットの添字n
図 6 予測精度の推移（cassandra の場合）可能性がある．
パラメータチューニング RF，DNN 等のモデルアルゴリズムを用いてモデルを構築する場合，予測精度の高いモデルを構築するために，パラメータチューニングが不可欠である．パラメータ探索の範囲を広くし，試行回数を増やすことで，より予測精度の高いモデルを構築できる．本研究では，ベイズ最適化のアルゴリズムを用いて 24 時間のパラメータチューニングを行っているが，より長い時間を費やせば，予測精度が高く有意義なモデルを構築できる可能性がある．
サンプル数 各 RQ において得られた考察・結論は 3 つのプロ
ジェクトについて実験を行った結果に基づいている．他のプロジェクトについて実験を行った場合，本研究の結論に当てはまらない結果を得る可能性がある．

献[1] 情 報 処 理 推 進 機 構 ，“ソ フ ト ウ ェ ア 開 発 デ ー タ 白 書”．
https://www.ipa.go.jp/ikc/publish/whitepaper_dl.html[2] T. Britton, L. Jeng, G. Carver, P. Cheak, and T. KKatzenellenbogen, “Increasing software development productivity with reversible debugging”. https://undo.io/media/uploads/files/
Undo_ReversibleDebugging_Whitepaper.pdf[3] H. Hata, O. Mizuno, and T. Kikuno, “Bug prediction based on finegrained module histories,” Proceedings - International Conference on
Software Engineering, pp.200–210, 06 2012.
[4] E. Giger, M. D’Ambros, M. Pinzger, and H. Gall, “Method-level bug
prediction,” International Symposium on Empirical Software Engineering and Measurement, pp.171–180, 09 2012.
[5] L. Pascarella, F. Palomba, and A. Bacchelli, “Re-evaluating methodlevel bug prediction,” 2018 IEEE 25th International Conference on
Software Analysis, Evolution and Reengineering (SANER), pp.592–
601, 2018.
[6] J. undefinedliwerski, T. Zimmermann, and A. Zeller, “When dochanges induce fixes?,” SIGSOFT Softw. Eng. Notes, vol.30, no.4,
p.1–5, May 2005. https://doi.org/10.1145/1082983.1083147[7] M. Borg, O. Svensson, K. Berg, and D. Hansson, “Szz unleashed: An
open implementation of the szz algorithm - featuring example usage ina study of just-in-time bug prediction for the jenkins project,” Proceedings of the 3rd ACM SIGSOFT International Workshop on Machine
Learning Techniques for Software Quality Evaluation, p.7–12, MaLTeSQuE 2019, Association for Computing Machinery, New York,NY, USA, 2019. https://doi.org/10.1145/3340482.3342742[8] N.V. Chawla, “Data mining for imbalanced datasets: An overview,”
pp.875–886, Springer US, Boston, MA, 2010.
[9] M. Sewak, S.K. Sahay, and H. Rathore, “Comparison of deep learning and the classical machine learning algorithm for the malware
detection,” 2018 19th IEEE/ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD), pp.293–296, 2018.
[10] J. Močkus, “On bayesian methods for seeking the extremum,” Optimization Techniques IFIP Technical Conference Novosibirsk, July
1–7, 1974, ed. by G.I. Marchuk, pp.400–404, Springer Berlin Heidelberg, Berlin, Heidelberg, 1975.
[11] T. Akiba, S. Sano, T. Yanase, T. Ohta, and M. Koyama, “Optuna: A
next-generation hyperparameter optimization framework,” Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery &amp; Data Mining, p.2623–2631, KDD ’19, Association for Computing Machinery, New York, NY, USA, 2019.
https://doi.org/10.1145/3292500.3330701—6—