1.　はじめに

現在，ソフトウェア開発においてテストの自動化，ビルドの自動化など技術の発展に伴い様々な工程の自動化が進められている[1]．開発の自動化を研究する分野のひとつに，テストの実行履歴を用いてバグの原因箇所を推定し，修正パッチを自動生成する技術（自動バグ修正技術）が積極的に研究されている．開発にかかる時間のうち25%を占める[2]と言われるバグ修正作業を自動化できれば開発効率は大幅に上昇するため，自動バグ修正は将来において発展が期待される魅力ある研究分野である．

自動バグ修正技術に関して，OSS（Open Source Software）開発プロジェクトや企業プロジェクト[3]-[5]の両方に対する適用事例の報告がある．自動バグ修正ツールの1つであるProphet [6]は8つのOSS開発プロジェクトから収集した69個のバグに対して修正を試み，15件の正しいパッチを生成することに成功している．開発者と同等の修正パッチが生成できたことから，修正が有効であることを示している[6]．一方で，実際に期待する形での修正が難しいことも報告されている[3], [4]．

先行事例から，自動バグ修正ツールの修正率は不十分であるものの，我々は今後修正性能の向上などでソフトウェア開発現場での適用が可能になると期待している．しかしながら，自動バグ修正の適用を実際のソフトウェア開発現場で成功させるためには，単に修正性能の向上だけでは難しいと考える．たとえば，開発プロセスに自動バグ修正のプロセスをどう組み込むか，自動バグ修正によってテスト仕様やテストプログラムの書き方は以前の開発プロセスと比較して変化するのか，またテストをどう実施すべきか，さらには，適用コストに対してどの程度の恩恵が得られるか，などの検討・評価を行っていくことが求められる．

本稿では，上記に対する知見を得るために，富士通九州ネットワークテクノロジーズ株式会社（以下QNET）におけるミドルウェア製品に対して自動バグ修正ツールProphetを適用し，調査で得られたデータから自動バグ修正ツールの今後の発展とプロセス改善に関する議論を行う^*1．具体的には，QNETにおけるミドルウェア製品から収集した実際のバグに対して自動バグ修正を適用し，その後，今後必要と考えられる自動バグ修正の適用範囲拡大，および，開発プロセスに適した自動バグ修正の導入の指針について検討する．

2.　自動バグ修正

本章では自動バグ修正の流れとその適用事例，および本調査で使用する自動バグ修正ツールであるProphetについて述べる．

2.1　自動バグ修正の概要

本調査において使用する自動バグ修正ツールは，Gazzolaら[8]がまとめた自動バグ修正技術の分類から選定した．調査対象プロジェクト（詳細は3章）ではC言語が採用されているため，分類されているツールの中でC言語対応であり，かつ，ツールが公開されている，という2つの条件を満たす自動バグ修正ツールを探した．この条件を唯一満たしたのはLongらのProphet [6]のみであったため，本稿ではProphetを使用するツールとして選択した．

Prophetの特徴は，修正の際に利用するテンプレートを用意している点，内部にOSS開発者の修正を機械学習した確率モデルを保持している点の2つである．この2点の特徴を，生成と検証を繰り返す手法（Generate and Validate，G&V）の一般的な自動バグ修正ツールの流れとともに説明する．修正の流れの概要は図1のとおりである．

G&Vでは，ツールの実行にバグのあるプログラムとバグを引き起こすテストを含むテストスイートを必要とする．このテストスイートはテストの自動化がなされていることが必要である．G&Vでは主にバグの箇所推定，パッチ生成，パッチ検証の3つのステップによって自動バグ修正を行う．

バグの箇所推定　テストスイートを実行し，バグを引き起こすテストの実行経路からバグの箇所の推定を行う．このステップではバグの箇所の候補のリストが生成される．

パッチ生成　バグの箇所の候補に対してプログラムを変異させ，パッチを生成する．Prophetは抽象構文木上の一点に対して修正テンプレート（表1）を適用することで，1行程度のパッチを生成する．このステップでは大量のパッチが生成され，次のパッチの検証ステップに移る．

パッチ検証　パッチ生成で生成されたパッチをプログラムに適用し，テストスイートによって検証を行う．最初にバグが検出されていたテストに通過するかだけでなく，パッチ適用前に通過していたテストに失敗しないかを確認する．すべてのテストスイートに通過したパッチが修正パッチとして出力される．Prophetはこのステップで確率モデルを使用し，パッチを検証する順番を変更している．この確率モデルにパッチを入力として与えると学習した開発者のパッチとの類似度が出力される．検証を行う際はこの類似度が高いパッチから評価することで，開発者の修正に近いパッチを生成することが可能になっている．

Prophetを利用する際のプロセス　最後に，本稿で想定するソフトウェア開発者がProphetを利用する際のプロセスを示す．

• (1)ソフトウェア開発者がソースコードを作成する．
• (2)ソフトウェア開発者は作成したソースコードをもとに，単体テストを作成，および，実施する．
• (3)ソフトウェア開発者は単体テストでバグが検出された場合，該当ソースコード，単体テストをProphetに入力する．
• (4)Prophetによって修正パッチが生成された場合，ソフトウェア開発者はそのパッチの可否を判断する．
• (5)パッチが受け入れられる場合，ソフトウェア開発者はパッチを採用する．
• (6)パッチが受け入れられない場合，ソフトウェア開発者はバグの修正を行う．この際，Prophetのパッチを参考にする．
• (7)ソースコード作成，および，テスト実施を終了する．

2.2　自動バグ修正と適用事例

自動バグ修正ツールを提案している論文の多くは，OSSにツールを適用し，その評価を行っている．一方で，実際に企業内で開発されたソースコードに対しての適用事例は少ない．

内藤ら[3]は，Javaで記述された企業内ソースコードに対してGenProg [9]を含む複数の自動バグ修正手法を適用し，修正率は7.7%（=1件/13件）であった．その結果から得られた自動バグ修正の実用化の障壁について議論している．

Nodaら[4]は，Javaで記述された150を超える企業内ソースコードから得られたバグを用いて自動バグ修正ツールElixir [10]を適用し，修正率は10.0%（=2件/20件）であった．また，その結果からテストケースの不足やツールの成功率の低さを指摘している．

本調査では自動バグ修正の企業内ソースコードへの適用事例のひとつとして，適用する際に得られた知見について報告する．

3.　適用対象プロジェクト

対象プロジェクトの概要　本稿での対象プロジェクトはC言語で開発されたミドルウェア製品である．このミドルウェア製品は母体にあたる部分の開発はすでに終了しており，複数回の派生開発によって機能追加を行っている．母体に当たる部分は約16 kLOCであり，派生開発では母体の一部を含み約7.2 kLOCである．ウォーターフォール型の開発が行われ，派生開発での開発人数は平均3人である．

品質保証に関する指針　対象プロジェクトはバージョン管理システムによって管理されており，派生開発後の総コミット数は759である．開発中のコミットのポリシーとしては，コンパイルエラーが起きない，プロジェクトのビルド・単体テストが通過するなどがある．なお，単体テスト作成時，分岐網羅率（branch coverage，C1）が80%程度を達成するよう，テスト項目が作成されている．

4.　適用調査

4.1　調査観点

今回，3章で述べたミドルウェア製品を対象にProphetによる自動修正を試みた．Prophetはテストスイートによってパッチの検証を行うアプローチを採用しているため，バグが直ったかどうかを確認するためのテストコードが必要となる．そのため，今回の調査ではQNETにおけるミドルウェア製品開発プロセス（開発標準および品質指標）に沿って実際にテストコードを作成し，開発現場での自動バグ修正の適用可否を評価した．評価の観点は以下の3つである．

（観点1）自動バグ修正技術の適用可能性　現状，自動バグ修正が適用可能なバグの割合がどの程度かを調査した．

（観点2）自動バグ修正の性能　自動バグ修正を適用し，どの程度修正可能かを調査した．

（観点3）自動バグ修正の適用プロセスとコスト　現在のミドルウェア製品開発プロセスにおいて自動バグ修正を適用するコストをテスト作成の観点から調査した．

4.2　（観点1）自動バグ修正技術の適用可能性

動機　本稿で適用する自動バグ修正ツールProphetは，先行研究[6]によって高い性能が報告されているものの，修正可能なバグが1ファイル内の1行程度という制約がある．そのため，複数ファイルかつ複雑な修正が予想される実製品レベルのバグを修正するのは困難であると我々は考える．この制約がどの程度現実的かについて調査・考察することで，今後の自動バグ修正に役立つ知見や方向性を示す．

方法　対象プロジェクトのリポジトリ内からバグ修正をしているコミットを抽出し，Prophetによって修正できる可能性があるかを調査した．具体的には，以下の手順（1）から手順（3）で調査対象コミットを抽出した．その後，手順（4）と手順（5）でコミットを修正ファイル数，修正行数，Prophetによって修正できる可能性があるか，の3項目で分類した．

• (1)対象プロジェクトの全コミット履歴からコミットメッセージを抽出
• (2)「バグ」や「修正」などのキーワードを含むコミットを抽出
• (3)手順（2）で抽出されたコミットのコミットメッセージを目視調査し，バグ修正を行っていると判断したコミット（バグ修正コミット）を抽出
• (4)バグ修正コミットによって追加・削除された差分行数，差分ファイル数を調査
• (5)差分行数が単一行かつ単一ファイルの編集であり，開発者の修正がProphetのテンプレートに含まれているものを適用対象コミットとした

調査結果　全コミット759件のうち，コミットメッセージにキーワードが含まれるものが130件であった（手順（2））．そのうち，コミットメッセージからバグ修正を行っていると判断できたコミットは21件であった．21件のコミットに対して，実際にバグ修正を行っている行を特定できたものは14件であった（手順（4））．差分からバグが特定できなかった7件のコミットに関しては，差分の行数が多くコミットメッセージのみからはバグの箇所が判断できないものや，コミットメッセージが「バグ修正」のみなどのコミットがあげられる．

14件のコミットを修正ファイル数，修正行数，Prophetによって修正できる可能性の3項目によって分類した（表2）．その結果，Prophetによって修正できる可能性があるコミットは3件であった．

（知見1）適用対象の割合

ミドルウェア製品のバグのうち，Prophetの適用対象となったのはバグの全体の21%（=3/14）であった．21%という数字をどう捉えるかは判断が難しく，21%しか適用できないと考えるか，それとも自動バグ修正というある意味で夢の技術の適用可能性が現時点でも21%もあると考えるかにより評価は大きく異なる．

適用対象のバグ修正コミット　以降，3件の適用対象コミットをそれぞれCommit 1，Commit 2，Commit 3と呼ぶ．Commit 1は設定ファイルに関係するバグ，Commit 2はNULLチェック，Commit 3は無限ループのバグである．各適用対象コミットについてバグの内容と開発者の修正について説明する．

Commit 1（プログラム1）はデバッグ用の関数に関する修正である．プログラムでは，設定ファイルから値を読み込み，その値によってメモリを確保している（2，3行目）．プログラム中にfor文のループ変数に応じてメモリを参照する箇所がある．メモリを確保した以上にfor文内の処理が実行された場合，範囲外にアクセスしてしまいコアダンプが起きる，という内容である．開発者の修正はfor文のループ回数を設定ファイルの値によって制限し，コアダンプを回避している．

Commit 2（プログラム2）では，関数ポインタhandlerがNULLだった場合，handler(args)でコアダンプを出力するいう内容である．開発者はhandlerがNULLでない場合のみhandler(args)を実行するように修正している．

Commit 3（プログラム3）では，else文に入った場合無限ループが発生しており，break文を挿入することで修正している．

適用対象コミットの3件はすべてバグではあるものの，修正という観点では難易度は低い．適用可能範囲は狭いが自動バグ修正を適用できる可能性があると言える．

（知見2）修正の容易性

実製品のバグは修正が困難なものが多く，自動バグ修正で対処できるものではないという先入観が我々にはあったが，今回の調査で自動バグ修正でも対応可能なものが少なくないことが分かった．要求仕様に起因するバグや設計の見直しが必要なバグについては，現時点の自動バグ修正では確かに対処が困難である．しかし，今回の調査のようなバグはコーディングミスやテスト漏れに近く，自動バグ修正で十分対応可能である．前者のバグ修正は開発者自身の手で，後者は自動バグ修正で行うなどの分業が期待される．

4.3　（観点2）自動バグ修正の性能

動機　自動バグ修正ツールは特定の範囲の対象に対しては高い修正性能を示している一方で，実際には期待どおりの修正性能が発揮されない場合も報告されている．現状のツールでどの程度修正が可能であるかを調査した．

方法　調査した3件に対して，Prophetを適用した．

文献[8]では，自動バグ修正においてテストスイートにすべて通るだけのパッチでなく，開発者に受け入れられるパッチを生成することが求められると述べられている．そこで，得ることができたパッチについて，以下の点を評価した．

• (1)パッチ内で修正された行は，（観点1）で特定したバグのある行か
• (2)修正されたコードは開発者の修正コードと同様の動きをするか
• (3)開発者に受け入れられるか

各項目について九州大学・QNETの共同ミーティング内で議論し，判定した．

単体テストの作成　Commit 1，2，3のバグにProphetを適用するのに必要なテストを作成した．Commit 1，2，3のバグはいずれも軽微であり，修正も容易である．そのため，開発者がテストを作成せずにコミットを行い，単体テストが作成されていなかった．このように適用対象バグに対してバグを発現させるテストが存在しない事例は，先行研究でも報告されている[3], [4]．今回の調査では，単体テスト時に自動バグ修正を適用するという想定の元で，筆頭著者が実際にミドルウェア製品の該当ソースコード箇所を読み，単体テストを作成した．その際，ソースコード理解からテスト作成完了までにかかった作業時間の合計を記録した．ソースコード理解とテスト作成の作業を完全に分離できなかったため，それぞれの作業時間ではなく作業時間の合計のみを記録した．表3にその概要を示す．ここで，Commit 1の対象関数のLOCが他のコミットに比べて非常に大きくなっているが，これは対象関数が多数の分岐を持つswitch文からなっているためであり，着目すべき箇所のLOCは他のコミットと同程度である．

テスト内容について　単体テストの作成にあたっては，以下のテスト内容に示すようにコード網羅率を高めることに留意した．一般的に網羅率を向上させると自動バグ修正の性能が高まるためである[11]．

Commit 1　設定ファイルの値について，for文のループ回数と等しくバグが発生しない256，for文のループ回数より小さいためバグを発生させる256より小さい値，の2つのテストを用意した．

Commit 2　関数の引数（handlerを含む構造体）がNULLでないかを確認するテスト，handlerがNULLでないテスト，handlerがNULLでバグを引き起こすテスト，以上3つのテストを作成した．

Commit 3　else文に入るテスト，入らないテストの2つのテストを作成した．

調査結果　適用結果は表4のとおりである．3件の調査対象コミットのすべてについて，Prophetによってパッチが生成された．現実のミドルウェア製品においても，自動バグ修正によってパッチが生成可能なバグは存在することが分かった．

3件の調査対象コミットのうち，2件のパッチについて開発者に受け入れられるパッチであると判断した．（詳細は知見3後の“受け入れられるパッチ”を参照されたい．）内藤ら[3]の調査では13件のバグに対して実験を行い，1件のバグについて開発者と同等のパッチを生成することができたと述べている．Nodaら[4]の調査では20件のバグに対して実験を行い，2件のバグについて開発者と同等のパッチを生成することができたと述べている．本稿では14件のバグのうち2件のバグについて開発者と同等のパッチが生成できたため，2つの先行事例を補強する結果になっている．内藤らの正答パッチ率は7.7%（=1/13），Nodaらの正答パッチ率は10.0%（=2/20），今回の正答パッチ率は14.3%（=2/14）である（表5）．件数自体が少ないため数値のブレはあるが，言語や使用ツールにかかわらず現状では10%前後くらいしか正しいパッチは得られないと考えられる．

Prophetを提案している論文[6]では，正答パッチ率は21.7%（=15/69）と報告されており，内藤ら，および，Nodaらの調査より高い正答パッチ率となっている．しかし，これは調査対象のプロジェクトをProphetの修正可能範囲にあるコミットを十分に含むものに限定しているためであると考えられる．

（知見3）パッチ生成の可能性

適用可能範囲は限定的であるものの，対象のバグに関しては実製品のバグにおいても開発者と同等のパッチを生成することが可能である．ただし，正しいパッチが得られるのはバグ全体のうち10%程度であり，現時点では，開発現場の期待に応えることは難しい．

各調査対象コミットについて生成されたパッチの詳細と評価について述べる．

受け入れられるパッチ　Commit 2に対してProphetが生成したパッチ（プログラム4）はhandlerのアドレスが0，つまりNULLでないときのみhandler(args)を実行するように修正している．このパッチは元のプログラムの機能を維持し，バグも修正しているため，最善の方法ではないものの，開発者に受け入れられるパッチであると判断した．

Commit 3に対してProphetが生成したパッチ（プログラム5）はbreakを挿入して無限ループを解消している．continueを削除していないため開発者の修正と完全に同じ修正ではなく，直接パッチとしてソースコードに適用することはできないが，開発者に受け入れられるパッチだと判断した．開発者とのパッチの差は差分行数で考えると大きくないため，開発工程においてはコードレビューで対応可能であると考える．

（知見4）パッチレビューの必要性

生成した修正パッチをソースコードにマージするためには，テストにすべて通過したかのみで判断するのではなく，通常のコードレビューと同様にパッチのレビューを行う必要がある．

受け入れられないパッチ　Commit 1に対してProphetが生成したパッチ（プログラム6）は，設定ファイルを読み込んでいる関数に対してのパッチである．設定ファイルを読み込む箇所をscanfに変更し，実質，設定ファイル読み込みを無効化している．このscanfへの入力は通常の使用法から逸脱したものではあるが，実際にコンパイル可能なものであり，今回の実験環境では実質何もしない関数呼び出しとなっている．設定ファイルを読み込む関数はconfig_varをfor文の実行回数と同じ値で初期化しており，この初期値によってメモリが確保された場合，コアダンプは発生しない．

このパッチはコアダンプを回避しているためバグを修正しているとも言えるが，設定ファイルを読み込むという本来の機能を維持していない．また，環境に依存するコードでもあるため，開発者に受け入れられないパッチと判断した．このパッチが生成されたのは，自動バグ修正ツールに与えるテストケースが不十分であったためと考えられる．たとえば，設定ファイルの値を読み込んでいるかを確認するテストをテストケースに追加されれば，受け入れられるパッチが生成される可能性がある．

このパッチは開発者には受け入れられないものの，設定ファイルを読み込む周辺でバグが発生していることが分かる．開発者がバグ修正を行う際にこの情報を利用することでデバッグ作業に有用な情報になる可能性がある．従来のバグ検出技術やツールと比較して，実際にどの程度有用であるかの調査・比較は今後の課題とする．

（知見5）自動バグ修正の付帯的効果

開発者と同等の修正パッチが得られない場合でもバグ同定などの情報からデバッグ作業に役立つ情報を利用できる場合がある．

4.4　（観点3）自動バグ修正の適用プロセスとコスト

動機　自動バグ修正の導入を実際のソフトウェア開発現場で成功させるためには，単に修正性能が高いだけでなく，現場の開発プロセスにどう組み込むか，テスト仕様やテストプログラムは現状のまま適用できるのか，開発プロセスの改善は必要か，などについて考える必要がある．さらに，実施にどの程度のコストがかかるかについても調査する必要があると考える．

ここでは，実際のミドルウェア製品開発プロセスにおいて作成されるテスト仕様で自動バグ修正が適用可能かを調査し，その後，自動バグ修正を適用するコストについてテスト作成の観点から調査した．

方法　4.3節において作成したテストについて，テスト内容や追加するべきテスト等についてミドルウェア製品開発プロセスでの基準と比較を行う．比較項目はテストの種類，および，分岐網羅率（C1）である．本調査で作成したテストとミドルウェア製品開発プロセスで作成されるテストを比較することで，開発プロセスで作成されるテストをそのまま自動バグ修正で利用可能かを調査した．本調査では，テストを作成する際，バグ混入時のコミットメッセージを参考にした．

調査結果　作成したテストと品質指標との比較結果は表6のとおりである．

テスト内容について　はじめに，今回作成したテスト内容の妥当性について述べる．今回筆頭著者が作成したテストをプロジェクトに精通した著者が内容を確認し，通常の開発プロセスで作成される可能性が十分にあることを確認した．また，これらの単体テストはProphetの入力になるための条件も満たしている．

知見3でも述べたが，自動バグ修正を適用するには網羅率を上げるのが望ましい．ただ，今回作成したCommit 1に対する単体テストは結果として網羅率が十分ではなく，テスト内容も不足している．不足しているテストの例として，境界値の前後のテストだけでなく境界値のテストや設定ファイルの種類を増やすべきである．一方，Commit 2に関しては調査で作成したバグを引き起こすテストは開発時にも用意されているべきであり，開発時のテスト項目の漏れが考えられる．これらの問題を解決するための方法として，まず，自動バグ修正を利用するために必要な最低限の単体テスト，すなわち，ある程度の網羅率を担保するテストを始めに用意する．次に，これに加えて品質保証として不足しているテストを開発者が新たに追加する．この手順を取ることによって，通常の開発プロセスの単体テストをより拡充したものを作成可能であると考えられる．

（知見6）品質保証からの視点

自動バグ修正を適用するためのみに作成した最小限のテストでは品質保証のテストとしては不十分であるが，作成したテストの一部は品質保証のテストのための資産に追加できる．自動バグ修正を適用するために作成したテストを既存の単体テストスイートに随時追加して行くことが望まれる．このプロセス改善のハードルは低いので，開発現場では容易に実現できると思われる．

実施のコストについて　表3の作業時間は筆頭著者がソースコードを読み，ソースコードのコンパイルやテストを作成した時間の合計である．テスト作成はCommit 1，Commit 2，Commit 3の順に行ったため時間が減少している．また，Prophetの1回の実行時間は5分程度であり，Prophetを使ったことがないユーザでも手順書に従えば1時間程度で動かせるようになる．

（知見7）導入のコスト

ミドルウェア製品への理解が浅い作成者でもテストの作成方法について3件程学習することで，作業時間を単体テストレベルで1時間程度の時間に抑えることができる．学習による時間削減の理由としては，テスト作成による慣れが大きい．実際の製品開発では，開発者自身が単体テストを作成するので，時間は1時間より大幅に短くなることが予想され，コスト面での負荷はあまりないと考えられる．

5.　今後の自動バグ修正に向けた方針

ここでは調査から得られた知見から今後の自動バグ修正に向けた方針を考える．

5.1　知見に対する意見

本節では九州大学とQNETの共同ミーティングの議論で得られた自動バグ修正適用の知見（特に，開発現場に対する適用の一事例としての知見や意見）についてまとめる．各項目の評価は以下のとおりである．○現状に満足できる．△改良が必要である．×大幅な改良が必要．

×（知見1）適用対象の割合　現時点では対応できるバグの割合が小さく，導入の効果が薄い．将来的に対応可能なバグが増えることを期待する．

△（知見2）修正の容易性　軽微なバグは修正の難易度は高くはないが，開発の工程前半で数多く発生するものであり，自動修正による効率向上に期待ができる．

△（知見3）パッチ生成の可能性　知見1でもそうだが，現状では適用範囲が狭いため評価が難しい．今後適用範囲が広がり，パッチも生成できれば嬉しい．また，現時点で開発者と同等のパッチが生成できたことは評価できるが，3件中2件は例としての数が少ない．さらなる調査が必要と考える．

△（知見4）パッチレビューの必要性　通常のコードレビュープロセスと同等に行う必要があるため，一部プロセスの改善を行う必要がある．バグ修正作業がどの程度減るかはまだ不明であるが，その時間をコードレビューに充てることができると考える．

△（知見5）自動バグ修正の付帯的効果　開発者と同等のパッチが生成できることが望ましいが，バグ同定でも開発者の負担を減らすことはできる．パッチ生成に成功したかどうかだけでなく，修正パッチとは別にバグ同定結果が分かりやすく開発者に通知できると嬉しい．

○（知見6）品質保証からの視点　単体テストを作成する過程で自動バグ修正が適用できると望ましい．

○（知見7）導入のコスト　1時間より大幅に短い時間であれば，通常の単体テスト作成時間内で自動バグ修正を追加で利用できるので魅力的である．

5.2　自動バグ修正の適用範囲

知見1，2，および，3より，自動バグ修正ツールが対応可能なバグの割合は開発現場の期待水準には達していない．本節では，自動バグ修正ツールの適用範囲を拡大する際の方向性を議論する．

適用調査では既存のProphetのテンプレートでどの程度修正が期待できるかの調査を行ったが，バグの箇所が特定できた14件のうち3件のみが理論上修正可能であった．上記の3件を除いた11件中4件は単一ファイル・単一行の修正であり，バグの内容を確認したところ，テンプレートの追加によって自動バグ修正を適用することができる可能性があることが分かった．

単一ファイル・複数行のバグの中には連続する複数ステートメントをif文によってガードする修正が2件存在した．このようなバグに対してはProphetにテンプレートを追加するだけでは対応が難しい．今後は連続した複数行を対象とした自動バグ修正ツールの開発やProphetのAdd Guardテンプレートを複数行に拡張する，などの対応が必要である．

上記で述べたテンプレートの追加および拡張を行うことで，現在の14件中3件（約21%）から14件中9件（約64%）のバグが将来的に修正可能になると考えられる．残った5件については修正行数が多く，関数追加やリファクタリングが行われており自動で修正することは難しい．これらのバグに対しては人手での修正や別プロセスで工夫してバグの混入を防ぐなどの対策を考える必要がある．

自動バグ修正適用に向けた方針1

自動バグ修正ツールの適用範囲は限定的であるため，ツールをそのまま使うのではなくテンプレートの追加，もしくは複数行への対応を検討すると適用範囲を広げられる．

5.3　開発工程とコスト

知見6および7より単体テストが自動バグ修正で利用可能なこと，知見4より導入の際に考慮するべきこと，知見5より開発プロセスにおける自動バグ修正の利点が分かった．本節では表7を参考に，コストやProphetの特性から開発プロセスへの組み込みについて議論する．表7ではミドルウェア製品開発における各工程をテスト作成，実施，問題特定，修正，総コストに細分化し，低，中，高，特高の4段階で評価した．各コストは，各工程にかかる金額，人件費，時間などを考慮し，絶対評価を行った．たとえば，結合テストではテストを作成するにあたって，テストの事前条件を作り出す必要があるためテスト作成のコストを高としている．また，コーディングの工程ではテスト作成のコストを低としているが，これは厳密なテスト作成ではなく動作確認やデバッグのことを指している．

Prophetは1行程度の修正のみ可能であるため，問題特定や問題修正がそれほど困難でない単体テスト工程が導入に最適な工程であると考えられる．また，前述したように，今回行った調査では自動バグ修正にかかる時間は5分程度であったため，開発者が単体テストを実行する際に追加で自動バグ修正を適用しても時間の観点で大きなコストにはならない．

単体テスト工程に導入する場合，ミドルウェア製品の特性からパラメータ分岐が多いため，テスト作成工程のコストを考慮する必要がある．テスト作成のコスト改善には自動テスト生成などの技術を用いることが可能である．たとえば，今回のCommit 2においてhandlerがNULLの場合のテストが抜けていたような事例では，自動テスト生成によってhandlerがNULLでない場合のテストを作成し，開発者自身でNULLの場合のテストを作成することで自動バグ修正をより効率よく利用することができると考えられる．以上からプロセス改善につなげるためにはテストの自動生成などと併用して自動バグ修正を導入するのが効果的であると考える．

自動バグ修正適用に向けた方針2

自動バグ修正ツールを導入するのは単体テスト工程が最適と考えられる．単体テスト工程はテスト作成にかかるコストが大きいため，テスト自動生成などと併用することでプロセス改善に取り組める．

6.　おわりに

本稿ではミドルウェア製品開発プロセスから抽出した実際のバグ14件のうち，3件のバグに対して自動バグ修正ツールProphetを適用した．その結果，2件の開発者と同等のパッチ生成に成功し，Prophetによって修正可能な実製品のバグが存在することを明らかにした．ミドルウェア製品開発プロセスにおいて現在の自動バグ修正ツールの適用範囲は21%と小さく，適用範囲を拡大するために修正テンプレートの追加などが必要である．また，適用調査でのデータから得られた知見に対する企業からの意見をまとめ，単体テストの工程が自動バグ修正ツールに適していることを述べた．