論文

コードクローン検索による類似不具合検出の実証的評価
森崎 修司†

吉田 則裕††

肥後 芳樹††

楠本 真二††

井上 克郎††

佐々木健介†††

村上 浩二†††

松井恭†††

Empirical Evaluation of Similar Defect Detection by Code Clone Search
Shuji MORISAKI† , Norihiro YOSHIDA†† , Yoshiki HIGO†† , Shinji KUSUMOTO†† ,Katsuro INOUE†† , Kensuke SASAKI††† , Koji MURAKAMI††† , and Kyo MATSUI†††

あらまし 不具合修正時の修正前ソースコード片を検索キーとしたコードクローン検索による類似不具合の検出を実証的に評価した．これまでにオープンソースソフトウェアを対象とした研究により，コードクローン検索による類似不具合発見の有用性が確認されている．そこで本論文では，商用開発のソフトウェアを対象としコー
ドクローン検索による類似不具合発見を商用開発の現場への適用する際の指針となることを目指す．対象はパナ
ソニック MSE 株式会社において三つの異なるプロジェクトで開発された 3 件のソースコードであり，試験工程での不具合修正に伴う修正履歴が記録されたリリース済のものである．修正履歴に記録された不具合修正前の
ソースコード片を検索キーとしコードクローン検索を実施し類似不具合を検出した．その結果，対象とした商用開発においてもその有効性を確認できた．
キーワード

コードクローン分析，類似不具合，ソフトウェア保守，ソースコード解析

1. ま え が きと呼ぶコードクローン検出ツールを利用してコードク
ローンに起因する未発見の類似不具合を発見している．

ソフトウェアの高機能化，大規模化に伴い，既存の対象ソフトウェアは Linux と FreeBSD であり，Linux

ソフトウェアの流用による開発や長期にわたって保守において 421 件，FreeBSD において 443 件の不具合

されるソフトウェアが増えている．このようなソフトの候補を抽出し，それぞれ 49 件，31 件の不具合を発ウェア開発で作成されたソースコード中には，コードク

見している．また，泉田らは文献 [12] において，オーローンが多く含まれることが報告されている [2], [14]．

プンソースの仮名漢字変換ソフトウェア “かんな” [1]

コードクローンとは，ソースコード中に含まれる同一のバージョン 3.6 と 3.6p1 の間で修正されたバッファ

または類似したソースコード片のことである [3]．例

オーバフロー対策のコードを対象とし，コードクロー

えば，X Window system を構成するソースコード 71

ン検索により，類似のバッファオーバフロー箇所を発

万行のうち，19%がコードクローンであることが報告

見し，UNIX コマンド grep によるキーワード検索とされている [2]．

の比較をしながら，その有効性を確認している．

不具合除去のために修正したソースコードとコード

Li らは，文献 [15] においてコードクローン発生のクローンとなっている部分には類似の不具合が存在する主原因として二つの理由を挙げている．一つは，抽象可能性がある．Li らは文献 [15] において，CP-Miner

化（共通関数化）するよりもソースコードの一部をコ†††ピーする方がソースコード記述にかかる時間が小さく
奈良先端科学技術大学院大学情報科学研究科，生駒市
Graduate School of Information Science, Nara Institute ofて済むこと，もう一つは抽象化による実行時のオーバ

Science and Technology, Ikoma-shi, 630–0192 Japan

ヘッド（関数呼出しに伴う処理）が問題になることで大阪大学大学院情報科学研究科，豊中市
Graduate School of Information Science and Technology,†††ある．他の原因としてコーディングスタイルや偶発的Osaka University, Toyonaka-shi, 560–8531 Japanなものを挙げている．商用のソフトウェア開発では，

パナソニック MSE 株式会社，横浜市

これらの原因に加え，抽象化によるソースコード変更

Panasonic MSE, Inc., Tsuzuki-ku, Yokohama-shi, 224–8539

が引き起こすデグレードによるリスクにより，保守性

Japan

2466

電子情報通信学会論文誌 D Vol. J91–D

c （社）電子情報通信学会 2008
No. 10 pp. 2466–2477 論文／コードクローン検索による類似不具合検出の実証的評価

よりも信頼性を優先し，コードクローンを除去していは if(A)B; を if(A){B;}に変換する等が含まれる．

ない場合がある．したがって，コードクローン分析に（ 3 ） 名前の正規化よる類似不具合の発見がより有用であると期待される

変数名，定数名を正規化する．変数，定数名が異なっが，具体的な評価によって明らかにはされていない．

ていてもコードクローンとして検出できるようになる．

本論文では，コードクローン検索を用いた類似不具

これにより，a = b; と c = d; がクローンセットとし合検出を商用開発へ適用する際の指針となることを目て検出できるようになる．

的として，オープンソースソフトウェアの類似不具合（ 4 ） クローンセットの検出の発見に役立つことが確認されているコードクローン

指定された長さ以上一致するトークンをすべてク

検索が商用のソフトウェアに対しても役立つかを確認

ローンセットとして検出する．

する．具体的には商用ソフトウェアを対象として，不図 1 はコードクローンの例を示したものである．

具合修正の履歴を用いて適合率と再現率を求める．対図 1 の網掛け部が互いにクローン関係にあることを表象とした商用ソフトウェアはパナソニック MSE 株式しており，網掛け部の集合（点線で囲まれた三つの網会社で開発され，既にリリースが完了した 3 種類のソ

掛け部）がクローンセットである．図 1 中右上のソー

フトウェアである．対象ソースコードには，結合テス

スコードと左下のソースコードは変数名は異なるが，ト，システムテスト以降の不具合除去時のソースコー

同じ処理を記述したものであり，変数名 top1 が変数

ド修正履歴が記録されている．修正履歴をもとに，修名 bottom1 に，変数名 top2 が変数名 bottom2 になっ正前のソースコード片を検索キーとしコードクローンている点，及び，if 文から始まる行の最後の定数の 1検索を実施し，検索結果に検索キー以外の修正前ソーが 0 になっている点，が異なり，変数名の正規化によスコード片が含まれるかを調べ，適合率，再現率，F1

りこの差異がなくなり，コードクローンとして検出で値を算出した．また，検索キーとなるソースコード片きる．

の考察と作業者から得られた意見を述べる．

2. 2 コードクローン検索ツール Libra

以降，2. でコードクローンとコードクローン検索

不具合修正部分の修正前ソースコードとクローン

ツール Libra について述べる．3. で評価の概要と結果セットとなっている部分があれば，その部分にも類似について述べ，4. で考察する．5. で関連研究についの不具合が存在する可能性が高い．修正前ソースコーて述べ，6. でまとめと今後の課題について述べる．

ドを検索キーとしクローンセットを検索すれば，類似

2. 準

備

の不具合の可能性のある部分を効率的にさがすことができる．Libra [16] は検索対象ソースコード，及び，

2. 1 コードクローン

ソースコードの一部（検索キー）を入力とし，検索ソースコード中に含まれる任意の部分列のうち，他

キーのクローンセットを出力する．

の部分列と一致または類似しているものをコードク
ローンと呼ぶ．部分列はコードクローン検出手法によLibra はコードクローン統合分析環境（ICCA [11]）の 1 コンポーネントである．

り異なるがトークン列や文字列などである．また，二つ以上の一致若しくは類似している部分列の集合を
クローンセットと呼ぶ．クローンセットの定義はコー
ドクローン検出手法により異なる．本論文では，文献 [14] での定義を用いる．文献 [14] での検出手順は，
字句解析，表記の正規化，変数名等の正規化，検出に大別され，以下のとおりである．
（ 1 ） 対象ソースコードの字句解析
対象ソースコードからトークンを抽出する．コメン
ト，改行/タブ/空白等の字面上の違いがあってもコー
ドクローンとして検出できるようになる．
（ 2 ） 変換
変換ルールにより表記方法を正規化する．ルールに

図 1 コードクローンとクローンセット
Fig. 1 Code clone and code clone set.

2467

電子情報通信学会論文誌 2008/10 Vol. J91–D No. 10

CCFinder [14] の GUI ラッパーであり，利用者からのプログラミング言語，検索結果の最小一致トークン

検索キーとして与えられたソースコード片と検索条件

数，CCFinder の検索オプションを指定することがでをコードクローン検出エンジンである CCFinder に与きる．検索を実行すると，図 3 のように検索結果をえ，結果を利用者に提示する．図 2，図 3 は Libra のユーザに提示する．図 3 の左側は，検索対象のソース

ユーザインタフェースである．図 2 は検索条件を与え

コードのディレクトリトリーであり，各ノードはソーるユーザインタフェースであり，中央部の “Fragment”

スコードファイルを表す．ソースコードファイル名のと書かれたテキストエリアに検索キーを指定する．ほ後ろの括弧付きの数値はそのソースコードにいくつのかにも，Libra が使用する最大メモリ容量，検索対象

クローンセットが含まれているかを表している．ノードを選択すると右側に検索ソースコード片とクローンセットとなっているソースコードが強調表示される．
図 4 はクローンセットが類似の不具合の原因となる
ソースコードの例であり，図 4 中 A と B がクローンセットである．図 4 中の A に示されるソースコードと B に示されるソースコードとはともに配列をコピーし，ある条件を満たす場合には，コピー先の配列の末
尾に NULL を付加する処理を記述したものである．いま，NULL を付加する条件の記述が不十分であること
がテストにより発見され，図 4 中 A の網掛け部分に示すように if 文の条件に|| (length % 16 == 0) を追加する必要があることが分かったとする．このとき，

図 2 Libra のユーザインタフェース（検索条件指定画面）
Fig. 2

A screen shot of Libra user interface. (search
key speciﬁcation screen)

Fig. 32468

図 4 中 B にも同様の修正が必要であるが，B に対してはテストがまだ未実行であるとする．図 4 中 A を検索キーとして，Libra に与えれば図 4 中 B を検索結図 3 Libra のユーザインタフェース（検索結果表示画面）
A screen shot of Libra user interface. (search result screen)論文／コードクローン検索による類似不具合検出の実証的評価

文献 [12] での評価対象は一つのオープンソースソフ
トウェアであり，調査の対象となった不具合はバッファ
オーバフローに関するもの 1 件である．オープンソー
スソフトウェア以外のソフトウェア，バッファオーバ
フロー以外の不具合を含む複数の不具合修正に関する調査は残された課題であった．

3. 評

価

3. 1 概要2. 3 で述べた課題に取り組むため，複数の商用ソフ
トウェアを対象とし，バッファオーバフロー以外の不具合を含む複数の不具合修正を対象とした．具体的には，パナソニック MSE 株式会社の三つの異なるプ
ロジェクトで開発されたソースコードを対象として 2
種類の評価 A，B を実施した．三つのプロジェクトはウォータフォールモデル型の派生開発（既存システムの機能追加，一部改変）プロジェクトである．また，設計，コーディングの両フェーズにおいて設計ドキュ
図 4 同一クローンセットに属する類似不具合の例
Fig. 4 An example of similar bugs included in thesame code clone.

メントのレビュー，コードレビューが実施され，次工程に不具合が持ち越されないよう工程移行の判定会議
で品質が検討される．各プロジェクトの概要を表 1 に示す．プロジェクトに関する知識がない作業者であっ果として得ることができる．得られたコードクローンてもコードクローン検索により類似不具合を検出できを開発者が検討し，不具合であると判断すれば，B にるかを明らかにするため，評価 A は当該プロジェクト

対するテストを実施する前に類似不具合を修正するこのプロジェクトリーダが実施し，評価 B は当該プログとができる．

ラミング言語でのコーディング，テストの業務経験は

2. 3 Libra の有効性評価 [12]もつが，当該プロジェクトの知識をもたない作業者が

文献 [12] において，オープンソースの仮名漢字変換実施した．いずれのプロジェクトで開発されたソフト

ソフトウェア “かんな” [1] の不具合修正を対象としてウェアも稼動実績があり，評価実施時点で発見済みか

Libra による評価を実施している．対象ソースコードの規模は約 21k ステップである．評価の対象とした不つ未修正の不具合は存在しない．

具合は 1 件でありバージョン 3.6 と 3.6p1 の間で実施

システムテストで発見された不具合の修正に伴う修正されたバッファオーバフローに関する修正である．修履歴がコメントとして記録されている．記録された修正箇所は全部で 21 箇所あり，21 箇所のうちの 1 箇所

正前コードを検索キーとしてクローンセットを検索し，を検索コード片として Libra に与え，残り 20 箇所の検索結果に他の修正箇所が含まれているかを調べる．

修正箇所が検索結果に含まれるかを調べている．また，

コーディング，単体テスト中に発見された不具合修正

修正箇所に含まれる変数の変数名を UNIX コマンドは今回の評価の対象外である．

の grep に与えて得られた検索結果と比較している．

評価で対象としたソースコードには，結合テスト，

3. 2 対象ソースコードの修正履歴

文献 [12] での評価では，適合率と再現率のバランス

対象プロジェクトでは，テストフェーズで発見されを示す F1 値の比較において grep よりも Libra の方がた不具合の修正手順が定義されている．定義には修正

よい結果が得られている．具体的には，grep を用いたに伴うソースコード修正履歴の記録方法が述べられて検索の適合率が 34%，Libra を用いた検索の適合率がいる．

100%，再現率が grep では 95%，Libra では 81%となっている．

対象プロジェクトでは，テストフェーズで発見された不具合の修正手順が定義されており，修正に伴う
2469

電子情報通信学会論文誌 2008/10 Vol. J91–D No. 10
表 1 対象プロジェクト
Table 1 Target projects.
プロジェクト
A-1
A-2
B

概要
Windows アプリケーション
Windows クライアントサーバアプリケーション
UNIX サーバアプリケーション

プログラミング言語 規模（ソースコード行数） 修正箇所
C++
13.5k step30
Java
7.2k step
28
C++
20.7k step36

ドである B の部分の前後に変更後であることを示すコ
メントを挿入する．それぞれのコメントには修正に対応する修正 ID を記述する．
同一の不具合修正に伴ってソースコードの複数箇所が修正された場合，それぞれの修正箇所に同一の ID が記録される．評価では一つの修正 ID から一つの修正前
ソースコードを選び検索キーとし，クローンセットを検索した．得られた検索結果が修正履歴に含まれるかを調べ，含まれない場合には潜在的な類似不具合でないか調べた．図 5 の例であれば，*ptr++; continueとクローンセットとなる部分が，同一の修正 ID の修
正履歴に含まれているかを確認する．

3. 3 評 価 方 法
評価では，修正履歴をもとにすべての修正箇所を修
正前の状態（不具合が再現する状態）に戻した．次に，一つの修正 ID から一つの修正前ソースコード（ソー図 5 ソースコード中の修正履歴記述例
Fig. 5 An example of notation of ﬁxed source code.

スコード片）を取り出し，クローンセットとなっている箇所を対象ソースコードから検索する．一つの修正

ID が複数のソースコード片にわたる場合には，修正
ソースコード修正履歴の記録，及び，記録方法も定義

履歴に記された日付が最も古いソースコード片を選ぶ．

に含まれている．そのため，当該プロジェクトに関す検索結果が同一 ID の他のソースコード（類似不具合）る知識をもたない場合でも，ソースコードの修正を記を正しく検索できているかどうかを作業者が確認し，適合率，再現率，F1 値を求める．適合率は，検索結録から再現できる．
図 5 は修正履歴の記録例である．図 5 中 “修正前”

果に含まれていたクローンセットのうち，実際に修正から同図 “修正後” のようにソースコードを修正した場されていたものの割合である．再現率は，修正部分に合，同図の “ソースコードへの記述” のように修正履歴

クローンセットが含まれていたものの割合である．F1

をコメントとして記録する．具体的には，図 5 中 “ソー値は適合率と再現率のバランスを示す指標であり，次スコードへの記述” に示すような修正前ソースコード式で求める．

終了位置と修正 ID を記す．図 5 は，修正 ID 0001 の

2 × 適合率 × 再現率
適合率 + 再現率

修正の際に，if 文の中の “*ptr++;

検索結果の判定手順は以下のとおりである．

とその開始，終了位置，修正後ソースコードの開始，中 A）” を “*ptr += 8;

continue;（図break;（図中 B）” と修正(a) 検索結果が修正履歴に含まれる場合した記録である．ソースコードには，もともと記述さ得られた検索結果が修正履歴に含まれる（修正前

れていた “*ptr++; continue; ” の前後にコメント

ソースコードとして記録されている）場合に不具合をとして修正開始と修正終了を記述し，対応する修正 ID

正しく検索できたものとする．

（ID 0001）の記録を加える．また，修正前のコードで(b) 検索結果が修正履歴に含まれない場合

ある A の部分をコメントアウトし，その前後に変更前得られた検索結果が修正履歴に含まれていない場合であることを示すコメントを挿入する．変更後のコーには，まず，作業者が修正が必要であるが実際には修2470

論文／コードクローン検索による類似不具合検出の実証的評価

正されていない潜在的な不具合であるかどうかを確認が付与されたソースコード修正履歴の記録の総数であ

し，潜在的な不具合であると判断された場合には正しる．“修正 ID 数” は不具合数であり，修正箇所から修く検索できたものとする．類似不具合であると判断さ

正 ID の重複を取り除いたものである．“検索結果が10 件以上となる修正 ID 数” はクローンセットの数が10 件以上となった修正 ID の数である．“検索キーのれなかった場合には，正しく検索できなかったものとする．
なお，評価 A の作業者は当該プロジェクトのプロ

平均トークン数（全体）” はすべての検索キーのトーク

ジェクトリーダであり，(b) の類似不具合かどうかのン数の平均である．“検索キーの平均トークン数（10判断は，プロジェクトに関する知識をもって判断した．

件未満）” はクローンセットの検索結果が 10 件未満と評価 B では対象プログラミング言語にてコーディン

なるような検索キーの平均トークン数である．“適合グ，テストの実務経験があるが，当該プロジェクトに率”，“再現率”，“F1 値” は，修正 ID ごとの適合率，関する知識をもたない作業者が判断した．

再現率，F1 値の平均をとったものである．なお，ク

修正前コードとクローンセットとなるソースコード

ローンセットの数が 10 件以上となった修正 ID は適合片が対象ソースコードに大量に含まれる場合（例えば率，再現率，F1 値算出の対象外である．クローンセッ

a = b; のようなソースコード中に頻出する代入文のトの数が 10 件以上となったコードを表 3 に示す．

場合）には検索結果も膨大になり，調査の手間が大き

表 2 に示すとおり，A-1 では 19 件，A-2 では 13

くなる．評価 A では，実際にプロジェクトを担当して件の修正 ID が記録されており，それらの修正箇所はいるプロジェクトリーダが本来の業務を妨げない範囲

それぞれ 30 箇所，28 箇所である．検索結果が 10 件で調査を実施する必要があったため，検索結果が 10以上となった件数は A-1，A-2 ともに 3 件ある．検索件以上になった場合には検索結果が修正箇所を含むかキーの平均トークン数は A-1 で平均 35.8 トークン，

どうかの確認を省略した．評価 B ではすべての検索結

プロジェクト A-1，A-2 ともに，修正履歴に残されA-2 で平均 33.8 トークンとなった．検索結果が 10 件未満となるような検索キーの平均トークン数は A-1 で
平均 38.1 トークン，A-2 で平均 42.0 トークンとなった．A-1，A-2 ともに検索結果が 10 件未満となる検ていないが修正しなければならない不具合は発見され索キーの方がトークン数が大きい．適合率の平均はなかった．評価に利用した計算機は Pentium M 1 Ghz

A-1 が 91.8%，A-2 が 80.4%と A-1 の方が A-2 よりも大きかった．再現率の平均は，A-1 が 86.9%，A-2
が 85.4%と同程度であった．

果を調査した．

3. 4 評価 A の結果

メモリ 1 GByte のものであり，OS は WindowsXP である．すべての検索においてコードクローン検索時間は数秒程度であった．

3. 4. 1 検 索 精 度
結果を表 2 に示す．表 2 中の “修正箇所” は修正 ID

表2

3. 4. 2 修正箇所が多いコード片A-1，A-2 それぞれのプロジェクトにおいて，同一修
正 ID で修正箇所が多かったものを表 4 に示す．A-1 で評価 A の結果（検索結果が 10 件以上となる修正は対象外）
Table 2 Precision, recall and F1 value in trial A.

検索結果が 10 件以 検 索 キ ー の 平 均 検索キーの平均トー
適合率 再現率 F1 値
上となる修正 ID 数 トークン数（全体） クン数（10 件未満）
19
3
35.8
38.1 91.8% 86.9% 0.872
13
3
33.8
42.0 80.4% 85.4% 0.826

修正箇所 修正 ID 数
A-1
A-2

30
28

Table 3

プロジェクト
A-1
A-1
A-1
A-2
A-2
A-2

表 3 検索結果 10 件以上の検索キー評価 A
Search keys that produced ten or more search results in trial A.

検索キー
pStrRes = (InfB_Anrmsig *)pby_wk;
CSysCom::TimerCntl(this, enTimer_Cntcnd, FALSE, bCntcndTimeFlg);for( int i = 0; i < 5; ++i)
if( output != IsCom.RTN_OK )output = m_reset.getTermStatus(request);
Line2 += MachAdd;

検索結果件数
410
48
29
424
246
60

2471

電子情報通信学会論文誌 2008/10 Vol. J91–D No. 10
表 4 修正すべき箇所が最も多いソースコード片（評価 A）
Table 4 Search keys that require largest numbers of ﬁxes in trial A.
プロジェクト

修正すべきコード（同一 ID）

A-1

sys->usSysStat |= SYSST_UNYO_U;

A-1

sys->usSysStat |= SYSST_SYSTEM_ON;

A-1

sys->usSysStat |= SYSST_UNYO_S;

A-1

sys->usSysStat&= ~SYSST_UNYO_S;

検索結果に含まれていたか
検索キー
○
○
×

String filename = JspData.g_MODrive + 文字列 A + m_main.reqyear +A-2((m_main.reqmonth < 10) ? "0" : "") + m_main.reqmonth +((m_main.reqday< 10) ? "0" : "") + m_main.reqday

検索キー+ "_" +((m_main.reqkukan < 10) ? "0" : "") + m_main.reqkukan + ".dat";
String filename = JspData.g_MODrive + 文字列 B + m_main.reqyear +A-2((m_main.reqmonth < 10) ? "0" : "") + m_main.reqmonth +((m_main.reqday< 10) ? "0" : "") + m_main.reqday○+ "_" +((m_main.reqkukan < 10) ? "0" : "") + m_main.reqkukan + ".dat";
String filename = JspData.g_MODrive + 文字列 C + m_main.reqyear +((m_main.reqmonth < 10) ? "0" : "") + m_main.reqmonth +A-2((m_main.reqday< 10) ? "0" : "") + m_main.reqday+ "_" +○((m_main.reqtiten < 10) ? "0" : "") + m_main.reqtiten + "_" +m_main.reqcar + ".dat";
String filename = JspData.g_MODrive + 文字列 D + m_main.reqyear +((m_main.reqmonth < 10) ? "0" : "") + m_main.reqmonth +A-2((m_main.reqday< 10) ? "0" : "") + m_main.reqday+ "_" +○((m_main.reqtiten < 10) ? "0" : "") + m_main.reqtiten + "_" +m_main.reqcar + ".dat";
String filename = JspData.g_MODrive + 文字列 E + m_main.reqyear +((m_main.reqmonth < 10) ? "0" : "") + m_main.reqmonth +A-2((m_main.reqday< 10) ? "0" : "") + m_main.reqday+×((m_main.reqShour < 10) ? "0" : "") + m_main.reqShour + "_" +((m_main.reqtiten < 10) ? "0" : "") + m_main.reqtiten + "_" +m_main.reqcar + ".dat";は，同一修正 ID で修正箇所が 4 件のものが最も修正箇

3. 4. 3 検索結果が 10 件を超えたコード片所が多かった．表 4 に示すとおり，sys->usSysStat

表 3 は ，ク ロ ー ン セット と し て 検 索 し た 件のビット操作に関する修正が実施されている．修正す数 が 10 件 を 超 え た 検 索 キ ー を 示 し て い る ．A-べき四つのコードのうち，3 箇所がクローンセットと

1 で は ，キャス ト を 伴 う 比 較 的 単 純 な 代 入 文

して検索できた．検索できなかったコードはビット操（pStrRes = (InfB_Anrmsig *)pby_wk;）の検索結

作演算子のオペレータが異なっていた（3 箇所は or 演

果 が 410 件 と 最 も 多 かった ．次 に 静 的 メ ソッ

算子，1 箇所は and 演算子）．また，4 箇所のうち演算

ド 呼 出 し が 48 件 ，for ル ー プ が 29 件 と 続 い子の右側のオペランドの変数名が一致しているものはて い る ．A-2 で は ，構 造 が 比 較 的 単 純 な if 文

2 箇所だけで，他の 2 箇所は変数名が異なるため，変（if( output != IsCom.RTN_OK )）の 検 索 結 果 が数の正規化を実施しなければ検出できない．

424 件と最も多くなった．次にメソッド呼出しが 246

A-2 では，同一修正 ID で修正箇所が 5 件のものが最も修正箇所が多かった．“文字列 A” から “文字列 E”

件，変数の加算が 60 件と続いている．

3. 5 評価 B の結果

はアルファベットから構成されるすべて異なる文字列

プロジェクト B においても修正履歴に残されていな定数であり，システム固有の名称をこれらの文字列にいが修正しなければならない不具合は発見されなかっ置き換えている．表 4 に示すとおり，修正すべき 5 箇

た．評価に利用した計算機は Pentium M 1.6 Ghz メ所のうち，4 箇所がクローンセットとして検索できた．

モリ 768 MByte のものであり，OS は WindowsXP

4 箇所は同一の構造で文字列定数部分がすべて異なる．
クローンセットとして検索できなかった 1 箇所は，連結する文字列が他より 1 項目（m_main.reqShour）多である．すべての検索においてコードクローン検索時

いものであった．

2472

間は数秒程度であった．

3. 5. 1 検 索 精 度
結果を表 5 に示す．表 5 中の “修正箇所”，“修正ID 数”，“検索キーの平均トークン数” 等は表 2 と同

論文／コードクローン検索による類似不具合検出の実証的評価

Table 5表 5 評価 B の結果
Precision, recall and F1 value in trial B.
修正箇所 修正 ID 数

すべて検索結果が 10 件未満のもの

Table 6

36
18

22
10

検索キーの平
適合率 再現率 F1 値
均トークン数
21.3 37.2% 89.3% 0.394
28.5 63.5% 90.0% 0.654

表 6 評価 B で検索結果が多かったソースコード片Search keys that produced larger numbers of search results in trial B.

検索キー

検索結果
件数

修正すべ
き件数

検索結果に含まれていた修正すべき件数

if( pst_Position->c_smeter_sts == DEF_DMCAT_METER_ON)

568

1

1

if (_mst_config->us_cleansing == 1)

568

1

1

char c_Mode;

511

3

2

sprintf((char *)_muc_Method, DEF_LOG_SS_CTDREGULARIZE, "mRegularize");

201

1

1

_mLogPut( APLOG, DEF_LOG_TRACE, uc_ApMsg, (UCHAR*)DEF_LOG_MSG03 );i_ret = RTN_NON;

122

4

4

表 7 修正すべき箇所が最も多いソースコード片（評価 B）
Table 7 Search keys that require largest numbers of ﬁxes in trial B.
検索結果に
含まれてい
た

修正すべきコード（同一 ID）
sprintf((char *)pc_Edit, "XXX0=[%02X%02X%02X%02X%04X%04X%02X%02X%02X%02X%08X%08X%02X%02X%02X%02X%02X%02X]",
pst_RawData->c_cmd, pst_RawData->c_subcmd, pst_RawData->c_center_id, pst_RawData->c_trance_id,
pst_RawData->us_data_size, pst_RawData->XXX1, pst_RawData->XXX2, pst_RawData->XXX3,

検索キー

pst_RawData->XXX4, pst_RawData->XXX5, (INT)pst_RawData->XXX6, (INT)pst_RawData->XXX7,
pst_RawData->c_rcv_mon, pst_RawData->c_rcv_day, pst_RawData->c_rcv_hour, pst_RawData->c_rcv_min,
pst_RawData->c_rcv_sec, pst_RawData->c_yobi);
sprintf((char *)pc_Edit, "XXX0=[%02X%02X%02X%02X%04X%04X%02X%02X%02X%02X%08X%08X%02X%02X%02X%02X%02X%02X]",
pst_RawData->c_cmd, pst_RawData->c_subcmd, pst_RawData->c_center_id, pst_RawData->c_trance_id,
pst_RawData->us_data_size, pst_RawData->XXX1, pst_RawData->XXX2, pst_RawData->XXX3,○

pst_RawData->XXX4, pst_RawData->XXX5, (INT)pst_RawData->XXX6, (INT)pst_RawData->XXX7,
pst_RawData->c_rcv_mon, pst_RawData->c_rcv_day, pst_RawData->c_rcv_hour, pst_RawData->c_rcv_min,
pst_RawData->c_rcv_sec, pst_RawData->c_yobi);
sprintf((char *)pc_Edit, "XXX0=[%02X%02X%02X%02X%04X%04X%02X%02X%02X%02X%08X%08X%02X%02X%02X%02X%02X%02X]",
pst_RawHead->c_cmd, pst_RawHead->c_subcmd, pst_RawHead->c_center_id, pst_RawHead->c_trance_id,
pst_RawHead->us_data_size, pst_RawData->XXX1, pst_RawData->XXX2, pst_RawData->XXX3,○

pst_RawData->XXX4, pst_RawData->XXX5, (INT)pst_RawData->XXX6, (INT)pst_RawData->XXX7,
pst_RawData->c_rcv_mon, pst_RawData->c_rcv_day, pst_RawData->c_rcv_hour, pst_RawData->c_rcv_min,
pst_RawData->c_rcv_sec, pst_RawData->c_yobi);
sprintf((char *)pc_Edit, "XXX0=[%02X%02X%02X%02X%04X%04X%02X%02X%02X%02X%08X%08X%02X%02X%02X%02X%02X%02X]",
pst_RawHead->c_cmd, pst_RawHead->c_subcmd, pst_RawHead->c_center_id, pst_RawHead->c_trance_id,
pst_RawHead->us_data_size, pst_RawData->XXX1, pst_RawData->XXX2, pst_RawData->XXX3,○

pst_RawData->XXX4, pst_RawData->XXX5, (INT)pst_RawData->XXX6, (INT)pst_RawData->XXX7,
pst_RawData->c_rcv_mon, pst_RawData->c_rcv_day, pst_RawData->c_rcv_hour, pst_RawData->c_rcv_min,
pst_RawData->c_rcv_sec, pst_RawData->c_yobi);
sprintf((char *)pc_Edit, "XXX0=[%02X%02X%02X%02X%04X%04X%02X%02X%02X%02X%08X%08X%02X%02X%02X%02X%02X%02X]",
pst_RawData->c_cmd, pst_RawData->c_subcmd, pst_RawData->c_center_id, pst_RawData->c_trance_id,
pst_RawData->us_data_size, pst_RawData->XXX1, pst_RawData->XXX2, pst_RawData->XXX3,○

pst_RawData->XXX4, pst_RawData->XXX5, (INT)pst_RawData->XXX6, (INT)pst_RawData->XXX7,
pst_RawData->c_rcv_mon, pst_RawData->c_rcv_day, pst_RawData->c_rcv_hour, pst_RawData->c_rcv_min,
pst_RawData->c_rcv_sec, pst_RawData->c_yobi);

じである．なお，評価 A との比較のためにクローン

り，そのうちクローンセットの検索結果が 10 件未満

セットの数が 10 件未満の結果とすべての検索結果をとなるものは 10 件あった．それらの修正に必要となっ含めた場合の結果の両方を示している．クローンセッ

た修正箇所は，それぞれ，36 箇所，18 箇所である．検トの検索結果数上位 5 件を表 6 に示す．

索キーの平均トークン数は全体で 21.3 トークン，ク

表 5 に示すとおり，22 件の不具合が修正されておローンセットの検索結果が 10 件未満の検索キーに限2473

電子情報通信学会論文誌 2008/10 Vol. J91–D No. 10

定すると平均 28.5 トークンであった．評価 A と同様

報告 [9]，泉田らの報告 [12]，Li らの報告 [15] で確認に検索結果が 10 件未満の方がトークン数が大きい．

されたオープンソースソフトウェアを対象としたコー

適合率の平均は全体で 37.2%，検索結果が 10 件未満

ドクローン検索による類似不具合の発見と同様に，商のものに限定すると 63.5%である．検索結果が 10 件用のソフトウェアを対象とした場合にも，類似不具合

未満となるような検索キーに限定した方が適合率が大の発見にコードクローン検索が役立つことを示す結果

きい．評価 A の検索結果が 10 件未満の適合率と比較が得られた．

すると評価 B のそれは小さい．再現率の平均は全体が検索対象のソースコードに頻出しないソースコード

89.3%，検索結果が 10 件未満となるような検索キーの場合には 90.0%となった．再現率は評価 A と比較す

片（特徴的なソースコード片）が検索キーとなる場合

ると評価 B の方が大きい．

評価で対象としたソースコードでは表 4 や表 7 に示には，再現率，適合率ともに大きな値が得られた．本3. 5. 2 修正箇所が多かったコード片

すような，ビット演算，文字列連結，複雑な引数をも評価 B において，同一修正 ID で修正箇所が最もつ関数呼出し，において特によい結果が得られた．例

多かったものを表 7 に示す．評価 B では，同一修正

外/エラー処理，ログ出力等，特徴的な部分の修正に

ID で修正箇所が 5 件のものが最も修正箇所が多かっ

おいてコードクローン検索による類似不具合検索が特た．“XXX0” は日本語の文字列定数，“XXX1” 以降はアに効果を発揮することが期待される．

ルファベットから構成される互いに異なる文字列定数

適合率，再現率ともに 100%となるような検索キー

または変数名であり，システム固有の名称を置き換え

は，複数行にわたるものが多かった．例えばエラー処ている．表 7 に示すとおり，修正すべき 5 箇所のう理の追加等で，修正箇所（検索キー）の前に条件分

ち，すべてがクローンセットとして検索できた．なお，

岐の条件部分（エラー条件）を追加，修正箇所の後に5 箇所は全く同一のソースコード片である．
表 6 は，検索件数の上位 5 位を示している．最も

else 節（エラー処理）を追加するようなものがあった．
表 3 や表 6 に示すような対象ソースコード中に頻出する単純な代入文，条件が単純な if 文，メソッド呼クローンセットが多かった 2 件は，左辺に構造体メン

出しについては，検索結果数が非常に大きくなり，適バ，右辺に定数をもち，それらの一致を確かめる if 文

合率が小さくなる結果が得られた．また，すべての評であった．ともに 568 件のクローンセットが得られ，価において，すべての検索キーの平均トークン数より修正すべき箇所も，ともに 1 件であった．3 番目に検も検索結果が 10 件未満となる検索キーの平均トーク

索結果が多かったのは，文字列型変数の宣言であり，ン数の方が大きかった．

3. 5. 3 検索結果が 10 件を超えたコード片

511 個のクローンセットが検索結果として得られた．
修正が必要な箇所は 3 箇所あり，2 箇所が検索結果の中に含まれていた．4 番目に検索結果が多かったのは，
sprintf によるログ出力部分であり，201 件のクローンセットが検索結果として得られた．修正すべき箇所は1 件であり，検索結果の中に含まれていた．5 番目に検索結果が多かったのは，関数呼出しと代入文の 2 ス
テートメントからなるソースコード片であり，122 件のクローンセットが検索結果として得られた．修正すべき箇所は 4 件あり，それらすべてが 122 件の検索結果の中に含まれていた．

4. 考

察

4. 1 検索キーとなるコード片
すべての評価において大きな再現率を得ることがで

4. 2 作業者との議論
評価 A を実施した作業者であるプロジェクトリー
ダ，評価 B を実施した作業者との議論から，以下のような意見が得られた．

•

修正コードに関する記憶や知識があれば，再現率が大きくなるように意図的に検索キーを短くしたり，
検索キーを変化させながら複数回検索する等，より再現率が大きくなるような工夫ができる．

•

派生製品や類似機能の不具合調査など迅速かつ網羅的な確認に特に有用である．

•

今回は開発終了後（出荷後）のソースコード

で結合，システムテスト以降の記録を対象としたが，コーディング，単体テスト実施等にプログラマが類似箇所を調査する際にも役立つ．

•

コピーアンドペーストした後，変数名，関数/

き，類似の不具合の発見においてコードクローン検索

メソッド名を変更することは実際の開発でよく起こる．

が有用であることを示す結果が得られた．Higo らの定数，変数名の正規化により，そのような場合でもク2474

論文／コードクローン検索による類似不具合検出の実証的評価

ローンセットとして検索結果に現れるので，キーワー
ド検索と比較して，再現率がより大きくなっている．

•

がある．
評価では，結合テスト以降に発見され同一の修正 ID

本評価で実施したような類似不具合の検索を，が付与されているものを類似不具合とし，文献 [14] のgrep 等のキーワード検索等の方法で検索キーを試行錯誤しながら検索した場合，1 件当り数時間必要となる定義によるコードクローン検索を用いて，類似不具合ことがある．コードクローン検索による方法で，同様

対象ソースコードの変数名や定数名を正規化し，一定に検索キーを試行錯誤しながら検索した場合でも，数以上の長さのトークンが一致すればコードクローンと十分程度に短縮できそうである．

しており，表 4，表 7 に示したような変数名や定数名をどの程度検出できるか調べた．文献 [14] の定義では，

評価 B において検索結果を 10 件未満に限定した場が異なるビット演算，文字列連結，複雑な引数をもつ合と限定しなかった場合を比較すると再現率はほとん

関数呼出しに関する類似不具合を検出することができど変わらないが，10 件未満の方が適合率が大きくなる

た．一方，表 3，表 6 に示したような変数名や定数名

結果が得られた．評価 A では，作業者の開発業務とのの正規化により検索結果件数が大幅に増加したと考え兼合いにより，検索結果が 10 件以上となる検索キーられるものもあった．表 3，表 6 に示したような対象に関する調査を途中で断念した．評価 A の作業者に評

ソースコード中に頻出するコード片が検索キーとなる

価 B の結果を見せたところ，評価 A において検索結場合は，別の手法との併用や正規化を変数や定数ごと

果が 10 件以上となる検索キーにおいても，評価 B とに個別に抑制する等の工夫が考えられる．

類似の結果となるだろうという意見が得られた．

4. 3 コードクローン検索の有効性

5. 関 連 研 究対象としたソースコードの類似不具合検出方法（従ソースコードの静的解析により潜在的な不具合の来の検出方法）は，開発担当者，プロジェクトリーダ

検出 を 試 み る 手 法が 提 案 さ れ て いる [7], [8]．ま た ，の記憶やドキュメントに基づいた修正部分の推測，修Lint [13]，Findbugs [10] をはじめ静的解析ツールも正部分を検索キーとしたソースコードのキーワード検

多く開発されている．これらの手法やツールは，特定索，レビューやテストによる確認，である．対象ソーの状況で起こりやすいコーディングミス（初期値の代スコードに記された修正日時から，従来の検出方法で入忘れ）や論理的な不具合を手法の提案者やツールの同時に修正されていなかったと推測される（修正日時

開発者がパターン化し，そのパターンに当てはまるに隔たりがある）修正箇所をコードクローン検索で検

ソースコードの一部を潜在的な不具合の候補として出できているものがあった．一方，従来の検出方法で利用者に提示するものである．本研究ではそのような同時に修正されていたと推測される（修正日時が近い）

パターン化の作業は必要ない．また，これらの静的解

類似不具合のうちコードクローン検索で検出できてい析手法やツールでは，本研究のように文脈に依存するないものもあった．そのような類似不具合には異なる（与えられた不具合と類似の）不具合の候補を検出す

文法表現を用いられたもの（例えば，表 4 に示したよ

ることはできない．

うな&= 演算子と|= 演算子）や検索キーとなるソース

保守性の向上を目的として，多くのコードクロー

コード片の一部にステートメントや変数の追加，削除

ン検出手法が提案されている．例えば，文献 [4] や文があったものである．

献 [17] では，関数やメソッドを最小単位としてコード対象とした 3 プロジェクトはいずれもウォータフォー

クローンを検出する手法を提案している．また，文ルモデル型の派生開発（既存ソフトウェアへの機能追献 [2] では，行単位でのコードクローン検出手法が提案

加，一部改変）プロジェクトであり，保守性向上を目されている．しかしながら，本論文で対象とするよう的としたクラス階層の変更を伴うような大幅なリファ

な修正ソースコードの検索ではより細かい粒度でコー

クタリングは含まれない．不具合の多くはレビュー，

ドクローンを検索できる必要がある．

あるいは，テストにより同一工程内で除去される．今ソースコードの類似部分の理解を支援することを回対象とした修正には大規模なソースコード変更を伴目的とした可視化手法が提案されている．例えば，文う修正は存在しなかった．今回対象としたソフトウェ

献 [5] や [6] では散布図により，二つのソースコードのアと異なる開発プロセスや形態についても，類似不具一致する部分を行単位で可視化している．具体的には，合の発見にコードクローン検索が有効か検討する必要

縦軸と横軸にそれぞれ一つのソースコードを割り当て，2475

電子情報通信学会論文誌 2008/10 Vol. J91–D No. 10

一致している行を点として二次元平面にプロットし，grep 等のキーワード検索など別の手法との併用が考え利用者に提示する．ただし，いずれの手法も変数名がられる．

変更されると異なる行として認識するため本論文のよ今後は，コードクローン検索による検出が効果的な

うな変数名を正規化した上でのコードクローンの提示

類似不具合を分類した上で，本論文での検索手順を実はできない．

際のソフトウェア開発プロセスに組み込んでいく際の6. む す び

課題を挙げ，実際に進行中の開発への適用可能性を検討する予定である．
謝辞用開発の現場へ適用する際の指針となることを目的

EASE プ ロ ジェクト の メン バ に感 謝 する ．
CCFinder の作者の神谷年洋氏（現独立行政法人産業とし，パナソニック MSE 株式会社で開発された三つ総合研究所）に感謝する．本研究の一部は，文部科学の異なるプロジェクトで開発されたソースコードを対

省「eSociety 基盤ソフトウェアの総合開発」の委託，象に，類似不具合の検出を実証的に評価した．コード「次世代 IT 基盤構築のための研究開発」の委託に基づ

クローンの検索結果が 10 件未満となるようなソース

いて行われた．

コードクローン検索による類似不具合の発見を商

コード片を対象とした 3 件の評価において，平均で78.6%の適合率，87.4%の再現率が得られた．また，検索結果を限定しない評価 1 件において，37.2%の適合率，89.3%の再現率が得られた．

文
[1]
[2]

献

日本語入力システム「かんな」，
http://canna.sourceforge.jp/
B.

Baker,“Onﬁndingduplication

and

near-

キーとなるソースコード片のトークン数が大きな場

duplication in large software systems,” Proc. Second

合に大きな適合率が得られることが分かった．評価はWorking Conference on Reverse Engineering, p.86,

当該プロジェクトのプロジェクトリーダと当該プログ

1995.
[3]

I. Baxter, A. Yahin, L. Moura, M. Sant’Anna, and L.

ラミング言語での実務経験があるがプロジェクトに関Bier, “Clone detection using abstract syntax trees,”

する知識のない者により実施した．評価により，従来

Proc. International Conference on Software Main-

確認されていたオープンソースソフトウェアのソース
コードだけでなく，三つの異なる商用プロジェクトでtainance, pp.368–377, 1998.
[4]

K. Kontogiannis, “Measuring clone based reengineer-

開発されたソースコードにおける類似不具合発見にもing opportunities,” Proc. Sixth IEEE International
Symposium on Software Metrics, pp.292–303, 1999.

コードクローン検索が有効であることを確認した．また，評価 B が実施できたことにより，ソースコード修[5]and code,” J. Computational and Graphical Statis-

業者でも検索が実施できること，及び，当該プロジェ

tics, vol.2, no.2, pp.153–174, 1993.
[6]

Proc. International Conference on Software Mainte-

評価では，4. 1 に示したようなエラー処理，表 7 でnance, pp.109–118, 1999.
[7]

D. Engler and K. Ashcraft, “RacerX: Eﬀective,
static detection of race conditions and deadlocks,”

ソースコードに頻出しないソースコード片（特徴的なProc. ACM Symposium Operating Systems Princi-部分）において特に大きな適合率，再現率が得られた．
また，評価を実施したプロジェクトリーダとの議論か

S. Ducasse, M. Rieger, and S. Demeyer, “A language
independent approach for detecting duplicated code,”

同程度の再現率が得られることを確認した．
示したようなログ出力をはじめとして，検索対象の

K. Church and J. Helfman, “Dotplot: A program for
exploring self-similarity in millions of lines of text

正履歴があれば，プロジェクトに関する知識のない作
クトに関する知識のある作業者が実施した評価 A と

M. Balazinska, E. Merlo, M. Dagenais, B. Lague, andples, pp.237–252, 2003.
[8]

S. Hallem, B. Chelf , Y. Xie, and D. Engler, “Aら，本評価のようなシステムテスト時の類似不具合検

system and language for building system-speciﬁc,

出だけでなく，派生製品の類似不具合検出，コーディ

static analyses,” Proc. ACM SIGPLAN Conference
Programming Language Design and Implementation,

ングや単体テスト時の類似不具合検出にも有用であるとの評価を得た．

pp.69–82, 2002.
[9]

一方，検索ソースコード片の長さ（トークン数）がanalysis,” Proc. 14th Asia-Paciﬁc Software Engineer-

小さい場合には，検索結果が非常に多数になり，効率的でない場合があることが確認された．このような場
合，コードクローン検索時の変数名の正規化の制限，
2476

Y. Higo, Y. Ueda, S. Kusumoto, and K. Inoue, “Simultaneous modiﬁcation support based on code clone
ing Conference, pp.262–269, 2007.

[10]

D. Hovemeyer and W. Pugh, “Finding bugs is easy,”
SIGPLAN Notice, vol.39, no.12, pp.92–106, 2004.

論文／コードクローン検索による類似不具合検出の実証的評価
[11]

楠本

ICCA (Integrated Code Clone Analyzer):
http://sel.ics.es.osaka-u.ac.jp/icca/index.html[12]

昭 63 阪大・基礎工・情報卒．平 3 同大
大学院博士課程中退．同年同大・基礎工・

泉田聡介，植田泰士，神谷年洋，楠本真二，井上克郎，“ソフトウェア保守のための類似コード片検索ツール，” 信学

情報・助手．平 8 同大講師．平 11 同大助

論（D-I），vol.J86-D-I, no.12, pp.906–908, Dec. 2003.
[13]

S. Johnson, “Lint, a C program checker,” Unix Pro-

[14]

T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder:

grammer’s Manual, AT&T Bell Laboratories, 1978.
A multi-linguistic token-based code clone detection
system for large scale source code,” IEEE Trans.

真二 （正員）

教授．平 14 阪大・情報・コンピュータサイ
エンス・助教授．平 17 同教授．博士（工学）．ソフトウェアの生産性や品質の定量的評価，プロジェクト管理に関する研究に従事．IPSJ，IEEE，
JFPUG，PM 各会員．

Softw. Eng., vol.28, no.7, pp.654–670, 2002.
[15]

井上

Z. Li, S. Lu, and S. Myagmar, “CP-Miner: Find-

克郎 （正員）ing copy-paste and related bugs in large-scale soft-

昭 54 阪大・基礎工・情報卒．昭 59 同大

ware code,” IEEE Trans. Softw. Eng., vol.32, no.3,[16]

Libra, http://sel.ist.osaka-u.ac.jp/icca/libra.html

大学院博士課程了．同年同大・基礎工・情報・助手．昭 59〜61 ハワイ大マノア校情[17]

J. Mayrand, C. Leblanc, and E. Merlo, “Experiment

報工学科・助教授．平元阪大・基礎工・情pp.176–192, 2006.

報・講師．平 3 同学科・助教授．平 7 同学科・教授．平 14 阪大・情報・コンピューon the automatic detection of function clones in asoftware system using metrics,” Proc. IEEE International Conference on Software Maintenance, pp.244–
253, 1996.

タサイエンス・教授．工博．ソフトウェア工学の研究に従事．
IPSJ，JSSST，IEEE，ACM 各会員．

（平成 20 年 1 月 29 日受付，5 月 23 日再受付）

佐々木健介
平元松下システムエンジニアリング（株）（現パナソニック MSE（株））入社．公共森崎

インフラシステムのソフトウェア開発，SE修司

業務を経て，CMM 認定推進活動に従事．
産官学連携の COSE プロジェクトに従事．

平 13 奈良先端大・情報科学・博士課程了．同年（株）インターネットイニシアティ
ブ入社．平 17 奈良先端大・産学官連携研究員．平 19 同大学・情報科学・助教．博士（工学）．エンピリカルソフトウェア工学，インターネットを介した知識共有の研究に従事．IPSJ，IEEE 各会員．

ユビキタスネットワーク事業部 e ソリューション開発グループ主任技師．所属開発組織の SEPG，及び品質管理担当．

村上浩二

昭 63 松下システムエンジニアリング吉田則裕

平 16 九工大・情報工・知能情報卒．平18 阪大大学院博士前期課程了．現在同大

学院博士後期課程在学中．リファクタリン
グ支援及びデザインパターン適用支援の研究に従事．情報処理学会，人工知能学会，
IEEE 各会員．

肥後芳樹 （正員）平 14 阪大・基礎工・情報中退．平 18 同大大学院博士後期課程了，平 19 阪大・情報・コンピュータサイエンス・助教．博士（情報科学）．コードクローン分析やリファ
クタリング支援に関する研究に従事．情報（株）（現パナソニック MSE（株））入社．
公共インフラシステムのソフトウェア開発，産官学連携の COSE プロジェクトに従事．
ユビキタスネットワーク事業部 e ソリューション開発グループ主任技師．

松井恭

昭 62 松下システムエンジニアリング（株）（現パナソニック MSE（株））入社．
公共インフラシステムのソフトウェア開発・産学官連携の業界標準化 SE 活動を経て CMM 認定推進等の開発組織運営に従事．ユビキタスネットワーク事業部 e ソ
リューション開発グループグループマネージャー．

処理学会，IEEE 各会員．

2477