ソフトウェア・シンポジウム 2015 in 和歌山

バイトコードの機械学習に基づく不具合予測手法の提案
藤原 剛史

水野 修

京都工芸繊維大学 工芸科学部 情報工学課程

京都工芸繊維大学 大学院工芸科学研究科 情報工学部門

m5622042@edu.kit.ac.jp

o-mizuno@kit.ac.jp

要旨

ジュール（Fault-prone モジュール）の検出が可能であることは，レビューやデバッグに費やすコストの削減につなが不具合を含んでいそうなモジュール（Fault-prone モる．そのため，これまでも Fault-prone モジュールを予測

ジュール）の予測には，複雑度メトリクスに基づいたモすべく，多くの研究が行われてきた [1][2][3][4][5][6][7]．

デルが用いられることが多い．しかし，それらのモデル

従来の手法では，主にモジュールの複雑さや変更頻度等を構築するには，メトリクスを測定するための環境整備のソフトウェアメトリクスを用いて予測モデルを構築しやツールへの慣れが必要であり，現場への適用は簡単でている．しかし，こうしたソフトウェアメトリクスを測はない．そこで，メトリクス測定を行わない Fault-prone定するためには，メトリクスの測定環境が必要であり，モジュール検出手法として，「Fault-prone フィルタリン現場への適用を難しくしている一因となっている．

グ」というものが提唱されている．この手法は，スパムこうした状況の中，メトリクス等の測定の必要なく，フィルタリングの理論を用いたものであり，ソースコーソースコードのみを入力として Fault-prone モジュールドへの簡単な適用のみによって Fault-prone モジュールの予測が可能である「Fault-prone フィルタリング」と呼を検知できる．

ばれる手法が水野らによって提唱されている [8][9]．こ本研究では，Fault-prone フィルタリングによる Fault-の手法は，迷惑メール検出に用いられるスパムフィルタ

prone モジュール検出のより高い効果を得ることを目的として，Fault-prone フィルタリングをバイトコードへリングの技術をソフトウェアのソースコードに対して適適用した場合とソースコードへ適用した場合の比較実モジュールを予測する．そして，適用が簡便であるにも験を行う．具体的には，対象とするプロジェクトのバイ関わらず，従来の手法と比較しても劣らない程の高い予トコードおよびソースコードから単語を抽出し，スパム測精度が示されている手法である．

用し，純粋にコードのテキスト情報のみから Fault-proneフィルタに通して結果を得たのち，比較を行う，

先に示した Fault-prone フィルタリングの研究では，本研究ではこの実験を通して，バイトコードによる不ソースコードを入力として Fault-prone モジュールの予具合予測が従来の不具合予測と比べて同等以上の精度を測が行われているが，実は Fault-prone フィルタリングに得ることが可能であることを示した.

用いる入力は，テキスト情報であればソースコードでなくてもよい．そこで，本研究では，この Fault-prone フィルタリングをバイトコードへ適用する．バイトコードを1. はじめに用いる理由としては，ソースコードに比べ開発者のコードの書き方等に依存しにくく，精度が保証されれば有用今やソフトウェアの果たす社会的な役割は大きく，ソであるだろう、という考えのもとに採用した．そして，フトウェアの品質を高く保つことはソフトウェア工学にソースコードによる予測と比べてどのように精度が違うおける重要な目標である．しかし実際には，時間的・人のかを，ソースコードへ適用した場合との比較実験を通的な理由が障害となって，それらの品質を高く保持するじて調べる．のは難しく，より効率的かつ簡易な手法が求められてい本報告書の構成を以下に示す．２章では，本研究を行る．コードを作成した時点で不具合を含んでいそうなモ

80

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

う目的について述べる．３章では本実験への準備としし，新たにメールを受信した際に，それらの学習に従って，前提知識として必要な事項を説明する．４章では，てメールを本人に有用なメール (ham) と迷惑なメール

本実験の対象となるプロジェクトおよび本実験の準備の(spam) に分類するといった仕組みを取っている．基本的手順を述べるとともに，実験の方法について説明する．

なスパムフィルタの動作は，メールを学習するステップ

５章では，予測精度の評価尺度について言及し，本実験と，学習した結果を用いてメールが ham メールか spamの結果を述べる．６章では，本実験の結果を基に考察をメールかを分類するステップの２ステップで構成されて行う．そして７章では，本研究のまとめと今後の課題にいる．

ついて述べる．

3.1.2

2. 研究の目的

CRM114

Yerazunis らによって開発されたスパムフィルタであ
これまで行われてきた Fault-prone フィルタリングのり [10] ，Fault-prone フィルタリングに使用されている．

研究においては，ソースコードを入力とした不具合予測

主にスパムフィルタとして開発されているが，汎用的で高い成果を収めてきた．しかし，Fault-prone フィルタな用途，例えば計算機のログ監視やネットワークのトラリングの入力はテキスト情報であればソースコードであフィック監視等にも活用できるとされている．また，現る必要はない．何か別のテキスト情報を入力とすること

在開発されているメールフィルタの中でも高い予測精度によって，より良い結果が得られる可能性がある．

をあげているものの１つである．

をバイトコードにすることによって不具合予測を行い結CRM114 は基本的にはベイズ識別を利用したテキス
ト分類フィルタであるが，複数の単語を組み合わせたも果を得る．バイトコードを用いる理由としては，バイトのをトークンと呼び，学習・分類の単位として利用する

コードは最低限の命令列で記述されているため，開発者ことが大きな特徴である．従来のテキスト分類フィルタのコードの書き方等に依存しにくいので，精度が保証さは１単語をトークンとしているのに対し複数単語の組をれれば有用であることが挙げられる．また，ソースコートークンとすることで，より複雑な学習が可能となってドを入力とした不具合予測との比較を行い，どのようないる．

そこで本研究では，Fault-prone フィルタリングの入力

本研究では，CRM114 のデフォルトの分類手法であ違いが生じるのかを調べる．

る ”Othogonal Sparce Bigrams Marcovmodel (OSB)”を使用する．OSB は任意の連続する５単語の組み合わせの3. 準備

うち，２単語からなるものだけをトークンとする手法である．

本章では実験を行う前に，実験の前提となる事項を紹介する．

3.2. PROMISE
3.1. Fault-prone フィルタリング
ソフトウェア工学のためのデータセットを公開してい迷惑メール検出に用いられるスパムフィルタで利用さるウェブサイトである．PROMISE 内で公開されているれる技術を，ソフトウェアのソースコードに対して適用

データセットの中には，不具合情報や，提案手法との比し，純粋にコードのテキスト情報のみから Fault-prone モ

較に利用することができる，ジュールを予測する手法である．

3.3. Lex
3.1.1

Lex は，レキシカルアナライザ（字句解析プログラム）スパムフィルタを生成するプログラムである．テキスト中の文字列の変現在使用されている一般的なスパムフィルタは，その換，カウント，抽出などさまざまな目的に使われ，その仕組みにベイズの定理を利用しているものが多い．これ応用領域は，コンパイラやコンバータの作成を筆頭に，らのスパムフィルタでは受信したメールの特徴を学習自然言語処理や簡単な整形まで幅広い．

81SEA

ソフトウェア・シンポジウム 2015 in 和歌山

本研究では，バイトコードおよびソースコードの単語ジョン毎に用意する．また，Apache Ant に関するリビ抽出に使用する．

ジョン毎のデータセットを PROMISE から取得し，以降の操作を行う．

3.4. 誤判定時のみ学習 (TOE)
4.2.1

これは，スパムフィルタにおいても利用される方式であり，対象の分類を行い，その分類結果が実際の結果とjar ファイル展開

用意したバイトコードは jar（Java アーカイブ）形式で異なっていたと判断した時点でのみ学習を行う手法であ圧縮されているため，クラスファイルに展開する必要がる．この手法を用いることで，実際の環境に近い状況，ある．jar 形式のファイルを展開する手段は JDK （Javaすなわち事前の知識が全くない状態からの予測モデル構Development Kit）で提供されており，jar コマンドの -x オ築が可能となる．

プションと-f オプションを使用することで，バイトコー

本研究では，実際は Fault-prone であるバイトコード

ドが記述されたクラスファイルを取得することが可能でおよびソースコードで示されたモジュールを Non-Fault-ある．

prone であると判断したとき，または実際は Non-Faultprone であるモジュールを Fault-prone であると判断したときのみに学習する．

4.2.2

逆アセンブルクラスファイルの状態だと学習に利用できないため，

4. 実験オペコードを取得する必要がある．しかし，バイナリデータからオペコードを抽出するのは困難であるため，クラ

本章では，実験の対象・準備・方法について説明する．

スファイルに逆アセンブル 2 を行う．クラスファイルを本実験では，Fault-prone フィルタリングの入力をバイ逆アセンブルする手段は JDK で提供されており，javap

トコードとすることで，Fault-prone モジュールの予測をコマンドの -c オプションをクラスファイルに適用するだ行う．また，ソースコードを用いた場合の予測との変化

けで，アセンブリコードの命令列（以下アセンブリコーを確認するため，入力をソースコードとした Fault-proneドと呼ぶ）を得ることが可能である．

モジュール予測との比較を行う．
以下，この実験においてはクラスをモジュール単位として扱う．

4.2.3

ソースファイル分割

１つの Java ソースファイル（以下ソースファイルと4.1. 実験対象呼ぶ）には複数のクラスが定義されていることがある．
本実験では，次に示すオープンソースプロジェクトをクラスを１つのモジュールとして扱うと，１つのソース対象とする．

ファイルに複数のモジュールが存在することとなり，実験を行うにあたって不都合である．よって，１つのソー• Apatch Ant

スファイルには１つのモジュール（クラス）のみが存在

Apache Ant は，GNU make の Java 版ともいえるもするようにソースファイルを分割する．のであり，OS など特定の環境に依存しにくいビルドツールである．記述言語は Java である．

4.2.4

今回の実験では rev.1.5，rev.1.6，rev1.7 の３つのリビジョンを対象とする．

タグ付け

PROMISE のデータセットに準拠して，各モジュールが Fault-prone であるか Non-Fault-prone であるかを決定

4.2. 実験の準備する．本実験において Fault-prone なモジュールとは，バグを少なくとも１つ含んでいるモジュールであると定義実験を行う前にまず，”THE APACHE ANT PROJECT”1から Apache Ant のバイトコードとソースコードをリビ

2 実行可能なバイナリデータを人間が可読なアセンブリ言語に変換すること

1 http://ant.apache.org/git.html

82

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

し，Non-Fault-prone なモジュールとは，バグを１つも含モジュールが Fault-prone であるか Non-Fault-prone であんでいないモジュールであると定義する．

るかの予測を決定するための確率の閾値は，0.5 に設定タグ付けの結果，Fault-prone なモジュールが 291，Non-している．

Fault-prone なモジュールが 1,096，合計 1,387 のモジュールが得られた．

4.4. 実験方法 2
より具体的な比較をするため，アセンブリコードおよ

4.2.5

トークナイザ作成

びソースコードで記述されたそれぞれのモジュール群にFault-prone フィルタリングを行うにあたって，テキス
ト情報を単語に分割するトークナイザが必要となる．本

対して，閾値を動かして Fault-prone モジュールを予測実験では，Lex を用いて作成した字句解析プログラムをた TOE を用いた Fault-prone フィルタリングの手順 (1)もってトークナイザとする．具体的には，正規表現を用〜(4) を用いる．また，閾値は 0.05 から 0.95 まで 0.05 刻し，結果を評価する．予測の手順に関しては，先に示しいて，アセンブリコードからニーモニック を抽出するみで動かして実験を行う．このとき，TOE という手法はトークナイザとソースコードから単語 4 を抽出するトー予測の順への依存が大きいため，閾値を変えて測定し直クナイザの２つを作成する．

す際に，最初にランダムに決定した同リビジョン内のモ3ジュール群の順を変えないように注意する．

4.3. 実験方法 1

5. 実験結果
本実験では，Fault-prone フィルタリングを適用するにあたって，誤判定時のみ学習（TOE）を採用する．TOE本章では，実験によって得られた結果を示す．

を用いた Fault-prone フィルタリングの具体的な手順を5.1. 実験の条件

以下に示す．

(1) 当該プロジェクトのモジュール群を古いリビジョン

本実験に行う上での条件を次に示す．のものから順にソートする．ただし，同リビジョン内のモジュール群の順に関しては，ランダムに決定

5.1.1

する．

スパムフィルタ(2) 並び替えたモジュール群から１つ取り出して適当な本実験では，スパムフィルタとして CRM114 を使用

トークナイザを適用し，Fault-prone であるか Non-する．また分類の手法として，CRM114 のデフォルト

Fault-prone であるかをスパムフィルタにより予測するの”Othogonal Sparce Bigrams Marcovmodel（OSB）”を使用する．

(3) モジュールの予測が完了した時点で，その結果とタグを比較し，予測が正しければ何もせずに (2) へ5.1.2戻る．

閾値（Threshold）

対象となるモジュールに CRM114 を適用すると，0〜1 の値が得られる．この値はベイズ識別によって得られ(4) 予測が正しくなければ，正しい結果を学習させ，そた，そのモジュールが Fault-prone である確率である．閾の後 (2) へ戻る．

値は，そのモジュールが Fault-prone か Non-Fault-prone
以上の (1)〜(4) の手順を，アセンブリコードおよびソーかの予測を決定するための境界値であり，Fault-prone でスコードで記述された，それぞれのモジュール群に対しある確率が閾値より大きければ Fault-prone と予測され，て適用することをもって，実験の方法とする．このとき，閾値以下であれば Non-Fault-prone と予測されるという3 オペコードと１対１対応している人間が可読な文字列ことである．

4 ここで述べる「単語」とは，変数名，演算子，キーワード等のソースコードを構成する要素のことである．ただし，本研究では区切り文字を示す” ; ”は含まない．

83

SEA

ソフトウェア・シンポジウム 2015 in 和歌山当実験においては，実験方法１では閾値を 0.5 に設定再現率（Recall）5.2.3し，実験方法２では閾値を 0.05〜0.95 間を 0.05 刻みで再現率は，実測が Fault-prone である全てのモジュー動かしながら実験を行う．

ルのうち，正しく Fault-prone と予測できたものの割合を示す．よって，再現率は以下のように定義される．

5.2. 評価尺度

Recall =表 1 は本実験で得られる結果の凡例である．N1 ，N2 ，

N1
N1 + N2(3)再現率は，直感的には予測によって実際の不具合をどN3 ，N4 は横に示す予測と縦に示す実測にそれぞれ該当する例数を表す．またこの表 1 では便宜上，Fault-proneれだけ網羅できるかを示す指標である．そのため，Fault-を FP，Non-Fault-prone を NFP と省略する．本実験で得prone モジュール予測にあっては，不具合を未然に防ぐという観点から最も重視すべき指標といえる．

られた結果の評価尺度として以下の，精度（Accuracy），適合率（Precision），再現率（Recall）の３つの指標を使用する．

5.3. 実験結果１[ 4.3 実験方法１ ] によって得られた Fault-prone フィ
ルタリングの経過のグラフを図 1，図 2 に，最終的な予表 1. 実験結果の凡例
実測

FP
N1N3FP
NFP

予測NFP
N2N4

測結果を表 2，表 3 に示す．

10.9
Recall5.2.1

0.8

精度（Accuracy）

0.7
0.6Rate

精度は，全モジュールのうち，予測が正しかった割合0.4を示す．よって，精度は以下のように定義される．

N1 + N4
Accuracy =N1 + N2 + N3 + N4

Accuracy

0.5

0.3

Precision

0.2(1)

0.10

精度は，予測の全体的な傾向を把握するには便利であNumber of predicted modules

るが，実測値の偏り等に大きく影響を受ける指標である．
そのため，この値のみで予測の良さを判断するのは危険
図 1. バイトコード入力時における各指標の推移

である．

5.2.2

適合率（Precision）

10.9

適合率は，予測が Fault-prone であるモジュールのう0.80.6

N1
N1 + N3

Rateて，適合率は以下のように定義される．

Precision =Accuracy

0.7

ち，実測が Fault-prone であったものの割合を示す．よっ0.5

Recall0.40.3(2)Precision

0.20.10

適合率は，直感的には１つの不具合を見つけるのにどのくらい無駄なモジュールを調べる必要があるかを示す

Number of predicted modules

指標である，すなわち，テストのためのコストを示している．
図 2. ソースコード入力時における各指標の推移

84SEAソフトウェア・シンポジウム 2015 in 和歌山

く高く，これはおよそ 85 ％の Fault-prone モジュールを
表 2. バイトコードモジュールの最終予測結果
実測FP
NFP
精度（accuracy）
適合率（precision）
再現率（recall）

FP248
686
0.474
0.266
0.852

検出できていることを意味する．

予測
NFP
43410

5.4. 実験結果２[ 4.4 実験方法２ ] によって得られた閾値を動かして行った Fault-prone フィルタリングの結果のグラフを
図 3，図 4 に示す．

表 3. ソースコードモジュールの最終予測結果
実測

FP
NFP
精度（accuracy）
適合率（precision）
再現率（recall）

FP
192
388
0.649
0.331
0.660

予測
NFP
99708

図 1，図 2 のグラフについて説明する．図 1 のグラフ
は，バイトコードモジュールに Fault-prone フィルタリングを適用したときの各指標の推移経過を，また図 2 のグラフはソースコードモジュールに Fault-prone フィル
図 3. 閾値の変化における適合率の推移

タリングを適用したときの各指標の推移経過を示している．TOE では無学習の状態から１つずつモジュールを予測していき，その予測結果が間違っていればその時点で学習を行うため，予測し終えたモジュールの数によって予測精度が変わる．これらのグラフは，第 n 個目までのモジュールの予測が完了した時点での３つの指標の値をプロットしたものである．このグラフの縦軸は精度（Accuracy），適合率（Precision），再現率（Recall）の各指標の値を表す．また，横軸は精度，適合率，再現率の各指標を算出した時点での，既に予測が完了しているモジュールの数を表している．
次に，表 2，表 3 について説明する．これらの表は，対象としたプロジェクトの全てのモジュールを予測し終図 4. 閾値の変化における再現率の推移

わった時点での予測と実測をクロス集計したものである．
特に，表 2 はバイトコードモジュールを予測したときの図 3，図 4 のグラフについて説明する．このグラフは，予測結果であり，表 3 はソースコードモジュールを予測閾値 （Threshold）を変化させた場合の Fault-prone フィしたときの予測結果である．

ルタリングの適合率（Precision）と再現率（Recall）のこれらの結果からは，バイトコードモジュールの Fault-推移について示している．図 3 のグラフの縦軸は適合率

prone フィルタリングによる予測は，ソースコードモジ
ュールの予測に比べて精度，適合率が低いことが確認できる．特に適合率は 0.266 と，１つの Fault-prone モの値，図 4 のグラフの縦軸は再現率の値を表し，これらのグラフの横軸は閾値を表している．
ここで注意すべきは図 4 のグラフにおいて，閾値のジュールを見つけるのに余分なモジュールを３つも調べ増加に伴い再現率の値が増加することがあることであなければならないことを示している．しかし再現率は，る．通常，すべてのデータを学習する場合は閾値の増加

ソースコードモジュールのものと比べても 0.852 と著しによって再現率が上がることはない．しかし，本実験で85SEA

ソフトウェア・シンポジウム 2015 in 和歌山

は TOE という手法を使っており，閾値を変えることにつかのモジュールデータに対して適用して確認をしよって予測が変われば，今までの閾値で学習されていたてみてはいるが，人手で確認するにはデータの量がモジュールが学習されなくなる，また逆に学習されてい膨大なためすべてのデータに対して確認ができておなかったモジュールが学習されるようになるということ

らず，字句解析プログラムが不具合なく動いているが起こりうる．よって，ある程度の再現率の揺れは十分という確証はない．にあり得るものであると考えられる．

• モジュール群の適用順

図 3，図 4 では，閾値を 0.8 あるいは 0.85 としたと

本実験を行うにあたって，同リビジョン内のモジューきにバイトコードモジュールの予測結果による適合率とル群の順をランダムにソートした．これは，ダウン再現率双方の値がソースコードモジュールの予測結果のロードしてきたバイトコードおよびソースコードか値を上回っている，あるいは同等であることが確認できらは詳細な作成日時が不明であったためである．今る．このことからバイトコードモジュールによる予測精回実験に用いた手法である TOE においては適用順

度は，閾値を変えることによってソースコードモジューによって学習内容が変わるので，最悪の場合と最良ルの予測精度を上回ることが可能である．の場合とで大きな差が出る可能性がある．

6. 考察

6.2. 実験結果の考察

本章では，実験に対する考察を行う

まず，実験方法１の結果を考察する，図 1，図 2，表 2，
表 3 はバイトコードモジュールおよびソースコードモ

6.1. 妥当性の検証

ジュールの fault-prone フィルタリングを用いた不具合予測における，精度，適合率，再現率の各指標の推移と本実験で得られた結果の妥当性を検証する．

最終結果を示したものである．図 1 と表 2 からはバイ• 対象プロジェクトの不足

トコードモジュールの不具合予測の結果を知ることができる．バイトコードモジュールの不具合予測は精度と適本実験では，Apache Ant を対象のプロジェクトとし合率はあまり高くないが再現率だけは非常に高い，このて特定の結果を得た．しかし，対象としたプロジェことの理由がこれらの図表から確認できる．その理由とクトが１つしかなく，本実験で示した結果が他の多は，バイトコードモジュールの不具合予測ではモジュー

くのプロジェクトに対して，一般的に当てはまるとルの多数を Fault-prone であると予測しているというこは限らない．また，Apache Ant はオープンソースとである．特に，実測が Non-Fault-prone なモジュールでプロジェクトであり，商業プロジェクトに今回の手は 1,096 モジュール中 686 ものモジュールが Fault-prone法を適用しても同等の結果が得られる確証はない．と誤判定されていることがわかる．しかし一方，Fault-• Perl スクリプトの不具合

prone モジュールは 291 モジュール中 248 ものモジュー

本実験を行うにあたって，当環境では複数の処理をルの予測に成功しており，図 1 のグラフからもわかるよ一括して行うために，Perl スクリプトを作成して実うに，TOE による学習は一定の成果を上げている．こ験を行っている．得られた実験結果に関してはあるのようなことが起こる理由として考えられるのは，バ程度の根拠があり，目下のところ特別な問題は見受

イトコードモジュールでは Fault-prone なモジュールはけられないが，作成した Perl スクリプトに何らかのFault-prone であると識別できる何か決定的な特徴を持ち不備が存在して実験の処理の手順を誤っている可能ながら，その他の特徴は Non-Fault-prone なモジュール性がある．と似通っている，そして，Non-Fault-prone なモジュールは Non-Fault-prone であると識別できる決定的な特徴を• トークナイザの不具合持っていないということである．一方，図 2 と表 3 か

本実験において，Lex を用いて作成した字句解析プ

らはソースコードモジュールの不具合予測の結果を知ログラムをもってトークナイザとしたが，この字句ることができる．これらの図表からは，ソースコードモ解析プログラムに不具合がある可能性がある．いくジュールの不具合予測は精度と再現性が比較的高いこ86SEA

ソフトウェア・シンポジウム 2015 in 和歌山とが確認できる．バイトコードモジュールの予測と反し大きく変わるバイトコードモジュールの不具合予測は状て，N1 : N2 と N4 : N3 がともにおよそ 2 : 1 の比になっ

況に合わせた使用が可能であると考える．ていることからも，バランスの良い安定した学習と予測

今回の実験は単一のプロジェクト内の複数リビジョンが行われていると考えられる．

で行っているためこのような結果が出たが，複数のプロ

次に，実験方法２の結果を考察する．図 3，図 4 は確

ジェクト間で不具合予測を行った場合，バイトコードモ率の閾値の変化における適合率と再現率の推移を示してジュールによる不具合予測が勝るものと予想できる．根いる．図 3，図 4 を見てまず注意すべきことは，バイト拠としては，別プロジェクトにおいては開発者が違えばコードモジュールの不具合予測では閾値を変えると適合文脈も違い，また変数名や関数名も違うためユニークな率と再現率が大きく変化するのに対し，ソースコードモ情報が役に立ちにくいと考えるからである．一方，バイジュールの不具合予測では閾値を変えても再現率がほぼトコードは余分な情報を排除した純粋な命令列である変わらず，適合率もさほど変わらないことである．このため，違うプロジェクト間においても機能すると考えら結果が示すことは，バイトコードモジュールの不具合予れる．もしこの考えが成り立つならば，あるプロジェク

測では，Fault-prone であるか Non-Fault-prone であるか

トで蓄積した学習情報を違うプロジェクトの初期のリビ明確でないモジュールが多いのに対して，ソースコードジョンでも適用することも可能となり，さらに適用も比モジュールの不具合予測ではモジュールが Fault-prone較的簡単であるので，今後への大きな貢献となることがであるか Non-Fault-prone であるかが明確であるという期待できる．

ことである．特に，閾値を上げても再現率がほぼ変化し7. 結言ていないことから，Fault-prone であると予測されたモジュールのほぼすべてにおいて Fault-prone である確率が１に近いことを表している．これは，バイトコードか本研究では，スパムフィルタ CRM114 を用いた Fault-ら抽出された単語（ニーモニック）は種類が少なく，ユら抽出された単語は，変数名や記号が含まれることからprone フィルタリングの手法を用いて，バイトコードモジュールの不具合予測を行う実験を行った．また，ソースコードモジュールに対しても同様の不具合予測を行種類も多く，トークンがユニークになりやすいことに起い，バイトコードモジュールの予測結果と比較すること因すると考えられる．つまり，バイトコードモジュールで予測の精度の違いに関して調べた．実験の結果，バイでは特徴が似たようなものが多くなり，Fault-prone であ

トコードモジュールを Fault-prone フィルタリングに適る確率が中程の値を取りやすいのに対して，ソフトコー用して不具合予測を行うことによって，従来の予測をわ

ドモジュールでは特徴がユニークであるので，多くのモずかに上回る，もしくは同等な精度を得ることが可能でジュールにおいて Fault-prone である確率は 0 か 1 に近あることが示された．

ニークなトークンが乏しくなる一方で，ソースコードかく，閾値を変えても予測がほとんど変わらないものであ

今後の課題としては，より多くのプロジェクトに対しると予想される．て実験を行い，バイトコードモジュールによる不具合予実験方法１，実験方法２の結果を通して述べた通り，測が他のプロジェクトにおいても高い精度を得ることがバイトコードモジュールの不具合予測においては Fault-できるかを調べることが考えられる．また，プロジェク

prone である確率がどっち付かずとなることが多く，実践的な適用に向いてないように思われるかもしれない．
しかし，図 1 と表 2 が示すように，閾値が 0.5 のときにト間に対しても実験を行うことで，あるプロジェクトの高い再現率を持つことから決定的な識別要因が存在してしたい．

バイトコードモジュールの学習結果を他プロジェクトに適用できるかどうかを調べることを今後行うべき課題といるものと考えられる．それを裏付けるように，バイト参考文献

コードモジュールの不具合予測では適切な閾値を設定してやれば，ソースコードモジュールの不具合予測の精度[1] P. Bellini and I. Bruno and P. Nesi and D. Rogai “Comparing
Fault-Proneness Estimation Models”, Proc. of 10th IEEE International Conference on Engineering of Complex Computer
Systems, pp. 205–214, 2005.

を上回る可能性があることが図 3，図 4 からわかる．さらに言うならば，実は適合率と再現率はトレードオフの関係にあるので，閾値の変化によって適合率と再現率の87

SEA

ソフトウェア・シンポジウム 2015 in 和歌山[2] Lionel C. Briand and Walcelio L. Melo and Jurgen Wust “Assessing the Applicability of Fault-Proneness Models AcrossObject-Oriented Software Projects”, IEEE Trans. on Software
Engineering, Vol. 28, No. 7, pp. 706–720, 2002.
[3] Giovanni Denaro and Mauro Pezze “An Empirical Evaluationof Fault-Proneness Models’, Proc. of 24th International Conference on Software Engineering, pp. 241–251, 2002.
[4] Lan Guo and Bojan Cukic and Harshinder Singh “Predicting Fault Prone Modules by the Dempster-Shafer Belief Networks”, Proc. of 18st International Conference on AutomatedSoftware Engineering, pp. 249–252, 2003.
[5] Taghi M. Khoshgoftaar and Naeem Seliya “Comparative Assessment of Software Quality Classification Techniques: An
Empirical Study”, Empirical Software Engineering, pp. 229–257, 2004.
[6] Tim Menzies and Jeremy Greenwald and Art Frank “DataMining Static Code Attributes to Learn Defect Predictors”,
IEEE Transactions on Software Engineering, pp. 2–13, 2007.
[7] Naeem Seliya and Taghi M. Khoshgoftaar and Shi Zhong“Analyzing Software Quality with Limited Fault-PronenessDefect Data”, Proc. of 9th IEEE International Symposium onHigh-Assurance Systems Engineering, pp. 89–98, 2005.
[8] Osamu Mizuno and Shiro Ikami and Shuya Nakaichi andTohru Kikuno “Fault-Prone Filtering: Detection of FaultProne Modules Using Spam Filtering Technique”, Proc. of 1stInternational Symposium on Empirical Software Engineeringand Measurement, 2007.
[9] Osamu Mizuno and Tohru Kikuno “Training on Errors Experiment to Detect Fault-Prone Software Modules by SpamFilter”, Proc. of 6th joint meeting of the European software
engineering conference and the ACM SIGSOFT symposiumon the founda- tions of software engineering, pp. 405–414,
2007.
[10] S. Chhabra and William S. Yerazunis and C. Siefkes “Spamfiltering using a Markov random field model with variableweighting schemas”, Proc. of 4th IEEE International Conference on Data Mining, pp. 347–350, 2004.

88SEA