日本ソフトウェア科学会第 40 回大会 (2023 年度) 講演論文集

実務で使われるコードクローン検出・追跡システムを
めざして
三木 聡

大歳 始 浅原 明広

大澤 俊晴

千葉 滋

本発表では我々が実務で使われる商用システムとして開発しているコードクローンの検出および追跡をおこなうシ
ステムについて述べる．コードクローンはプログラム中に現れる重複コードのことである．これはコード断片のコ
ピー＆ペーストによって生まれ，ソフトウェアの品質低下の要因となることが知られている．コードクローン検出器
はいくつも発表され，無償で利用できるものもあるが，産業界の開発現場に広く普及しているとは言いがたい．我々は，特別な設定なくインストールしてすぐに使え，日々の開発のバックグランドで動かすだけで，コードクローン検
出の効果を実感できるようなツールを目指して，コードクローンの検出・追跡器を開発している．本発表では実務で使ってもらうための工夫や，発見したコードクローンをその後も追跡し続けて変更の量からその危険度を判断する機能などについて述べる．

見つけようという気持ちも生まれない．

1 はじめに

本稿では我々が商用製品として開発しているコー

コードクローン，あるいは重複コード，は，プログ

ドクローン検出器 CloneTracker について述べる．こラム中のコードの断片を別のところにコピー・ペースの検出器はコードクローンの「修正もれ」の発見に重トすることにより作り出される．長年の研究により，点を置いている．修正もれとは，コードクローンを

コードクローンの存在はプログラムの品質に大きな影なすコード片の一方にバグ修正等を加えたとき，他響を与えることが知られており，それを検出するツー方のコード片に同様の修正を加え忘れることである．

ルも数多く開発されてきた．

CloneTracker は，検出したコードクローンが過去か

しかしながら実務でのソフトウェア開発の現場を見ら現在までにどのように修正されてきたかを追跡し，ると，コードクローンを検出してリファクタリングで修正もれの危険が高いコードクローンを優先して提除去し，プログラムの品質を維持する，という活動が示する．これによって，検出したコードクローンをリ

広く実践されているとは言いがたい．コードクローン

ファクタリングの労を払って除去しなくても，コードや重複コードという概念自体も広く知られているわ

クローン検出の意義を感じられるツールにすることをけではない．それにはいくつかの理由があるものの大狙っている．プログラムの開発履歴からコードクロー

きな理由の一つは，実務での開発ではコードクローン

ンの修正もれを検出するツールは過去にも開発されを見つけても，リファクタリングでそれを除去するこてきたが，CloneTracker は継続的にコードクローンとが現実的にしばしば困難だから，と我々は考えていを追跡し続けるのが特徴である．また経験から得たる．見つけても何もできなければ，コードクローンを様々な重み付けの規則を用いて，実務で開発する技術∗ Toward a code clone detection/tracking system used

in industry. (This is an unrefereed paper. Copyrights belong to the Authors.)
Satoshi Miki, 株式会社フィックスターズ, Fixstars Corp..
Hajime Otoshi, Akihiro Asahara, Toshiharu Osawa,
Shigeru Chiba, 株式会社 Sider, Sider Corp..

者やプロジェクトマネージャー (PM) にとって有用であると思われるコードクローンを検出し，提示するように工夫している．この重み付けの規則には対象のプログラミング言語に特化した規則も含まれる．
なお CloneTracker は現在も開発中である．本稿で述べる CloneTracker は本稿執筆時点でのものであり，今後の開発にともない変わる可能性がある．

2 産業界におけるコードクローン検出

1
2
3
4
5

コードクローンは，その重複具合によっていくつか

if (ERR_OK == ret) {/* send message */ret = queue_snd(&msg,
sizeof(struct _msg));}
リスト 1

元のコード片の種類に分類できる [1]．古典的な分類は Type 1 か
ら 4 までの 4 種類である．Type 1 は完全に一致す
るコード片，Type 2 は変数名等が異なる他は一致す
るコード片，Type 3 はほぼ同一のコード片，そしてType 4 は意味的によく似ているが制御構造やアルゴ

1
2
3
4
5

リズムが異なるコード片，の組である．コードクロー

if (ERR_OK == ret) {/* receive message */ret = queue_rcv(&msg,
sizeof(struct _msg));}
リスト 2

コピー&ペースト後

ンはプログラムの品質を考える上で重要なものとされ，それを検出するツールが数多く開発されてきた．
例えば CCFinder [5]，NiCad [8]，SourcererCC [9]などの検出器がある．
どこまで異なるコード片の組を Type 3 コードク

1
2
3
4
5
6

if (ERR_OK == ret) {/* receive message */ret = queue_rcv(&msg,
sizeof(struct _msg));
ret = new_return_code(ret)}

ローンと呼ぶかについて明確な合意はないと思われるが，例えば CCAligner [10] は large-gap クローン

リスト 3

修正もれ

と呼ぶ種類の Type 3 コードクローンの検出器である．Large-gap クローンとは，一方のコード片の途

ア開発で最も頻繁に現れるコードクローンであると考中に多数の文（あるいは行）を挿入・削除したもの

えられ，その検出はプログラムの品質向上に役立つ．

がもう一方のコード片だと見なせるようなコード片

すでにある関数と類似した機能をもつ関数を実装すの組である．多数の文を挿入・削除するのがコードるときに，元の関数の宣言をコピーしてプログラム中

片の途中の一ヶ所だけでなく，複数箇所である場合をの別の場所に貼り付け，目的に合うように少し修正すlarge-variance クローンと呼び，それを検出するできる，というのは一般的によくおこなわれる作業であるようにした検出器 LVMapper [11] や NIL [7] も開るが，これが Type 3 コードクローンを生む．このよ

発されている．

うなコードクローンは，生まれた直後は比較的無害と考えられるが，バグや機能拡張などの理由でコー

2. 1 コードクローン検出の目的

ドの修正が必要になった際に，片方のコード片だけを

実務上，Type 1 および Type 2 コードクローンの修正して，もう片方のコード片の修正を忘れる危険

検出は，誤って製品に混入した自社が権利を持たない性をはらむ．実際に片方の修正を忘れる「修正もれ」

プログラムの発見に役立つ．例えば 2000 年代後半にがおきると，大きな障害を引き起こしかねない．

は，オープンソース・ライセンスのプログラムの一部

例えばリスト 1 がコピーされて修正され，リスト 2を，知らぬ間に無知な技術者が自社製品のプログラムが書かれたとする．呼ばれている関数は異なるが，こに流用してしまい，結果としてその製品がライセンの二つのコード片は Type 3 コードクローンである．

ス違反となる事件が頻発した．これを未然に防ぐた

その後，何らかの理由でライブラリの仕様が変わり，め，オープンソース・ライセンスのプログラムとの間

リスト 2 に修正が加えられてリスト 3 になったとすのコードクローンを製品のプログラムから検出する

る．5 行目の関数呼び出しが修正で追加された行であProtex [13] などの製品が販売されている．

る．このときリスト 1 にも同様の修正が加えられてType 3 コードクローンは実務におけるソフトウェ

いなければ，おそらく修正を忘れたバグと考えられ

る．これが「修正もれ」である．

まず，実務での開発によく用いられる Windows 環境

全てのコードクローンが将来の修正もれをおこすわ

で検出器を動かすのが容易ではない．また，検出結果

けではないが [6]，危険を避けるためにコードクロー

を見やすくするには他の可視化ツールと組み合わせる

ンは見つかり次第リファクタリング作業で取り除く必要があり，手軽ではない．さらに，チームが開発しことが望ましい．リファクタリングをせずに済むようているプログラムの品質向上に本当につながるコーに，見つけたコードクローンを追跡し，そのコードク

ドクローンを検出するには，検出器の検出パラメータ

ローンに修正もれを検知すると，修正からもれたコーを慎重に調整する必要がある．しかし，コードクロー

ド片も同様に修正するように警告を発するツールもン検出の研究者や専門家でない，一般の技術者にとっ開発されている [3] [12] [4]．

て，このような検出パラメータの調整は困難である．
これらの問題点については我々も同様の意見を見込み

2. 2 普及しないコードクローン検出

顧客から得ている．

このような研究の蓄積にもかかわらず，コードク

単独の商用製品として提供されているコードクロー

ローンを積極的に発見してソフトウェアの品質改善にン検出器で，よく知られたものは我々の知る限り存在

役立てるという姿勢が，実務としてのソフトウェア開しない．存在するのは，プログラムの静的解析の一部

発の現場に十分浸透しているとはいいがたい．コー
ドクローン検出器の利用も普及しているとは言えなとしてコードクローン検出をおこなう製品である．例
えば SonaSource 社の SonarQube†1 はプログラムのい．我々の観察によれば，とくに日本国内で業務とし品質改善のために様々な解析をおこなうツールだが，てソフトウェア開発をおこなっている技術者（エンジニア）の間の，コードクローンあるいは重複コード

コードクローンの検出機能を備える．同様の静的解析ツールに Synopsys 社の Coverity†2 がある．これら(duplicated code) の認知度は低い．

の製品に含まれるコードクローンの検出機能がどの

コードクローン検出が実務の開発で普及していなくらい使われているかは不明だが，これらの製品があいのは，実際のところ，コードクローンが検出されるので他のコードクローン検出器は不要であるといても技術者はその扱いに困るからだと，見込み顧客

う声も我々は知らない．

との対話から我々は考えている．一般に，検出された

コードクローン検出器が実務での開発で活用されコードクローンは除去するべきである．しかし通常ない，もう一つの理由はプロジェクトマネージャーのリファクタリングでは簡単に除去できないコード(PM) の無関心にもあると我々は考えている．コード

クローンが多いことも知られている [6]．多大な労力

クローン検出器のようなツールを開発チームに導入を払ってコードクローンを除去するべきか，それが将する際の決定権をもつのは PM である．開発してい来問題となる危険性は低いと予想して放置すべきか，るプログラムの品質に責任を負うのは PM であるが，開発全体の人的・時間的制約まで含めて考えると悩ま

とくに大規模な開発チームの PM の中にはプログラ

しい．開発しているのが金融や官公庁向けのシステム

ムの品質にあまり関心がなかったり，関心があってもの場合，万一リグレッションが起きたときの社会的影

プログラミングの技術的詳細に疎く，ツールの導入は響が大きく，後からのリファクタリングは気軽に実施

実際の開発をおこなう協力会社が考えればよい，と考しにくい．結局，検出されたコードクローンをそのまえる者がいる．そのような PM の開発チームの場合，

ま放置せざるを得ないことが多いが，そうであるならコードクローン検出器を導入して積極的に活用しよ

何のためにコードクローンを検出するのか，というこうという気運は生まれにくい．

とになる．

このように現状でコードクローン検出は実務として

上記の問題に加え，オープンソース・ソフトウェア
として自由に利用可能なコードクローン検出器については，利用の際の敷居の高さも指摘されている [14]．

†1 https://www.sonarsource.com†2 https://www.synopsys.com

図1

CloneTracker による解析結果

図2検出されたコードクローンの表示のソフトウェア開発の現場で広く行われているとは言歴を過去から未来にかけて継続的に追跡し，「修正もいがたい．しかし，コードクローンの存在に注意を払れ」の危険性が高いコードクローンを中心に，重要なうことがプログラムの品質向上につながることは様々

もの，PM や技術者が見たいはずのコードクローンな研究から明らかであり，コードクローン検出に一般を優先して提示するツールである．このツールは検出の技術者が無関心である現状はけして望ましくない．

したコードクローンをリファクタリングで除去する

このような状況を打開するためには，検出器を使ったように利用者に無理に求めない．除去が難しいコー

PM や技術者に「これは有用だ」と思う体験（いわゆドクローンはそのままにしてよい．そのままにしてる aha/wow moment [2]）を届けるクローン検出器

も，コードクローンの存在をツールが記録・追跡するを開発し，その意識を変えていくことが必要である．

ので，将来，修正もれが起きないように利用者は気を配ることができる．仮に気づかず「修正もれ」をおこ

3 CloneTracker

しても，ツールがそれを知らせる．CloneTracker は，

我々は前章で述べた問題意識の下，コードクロー
ン検出器 CloneTracker†3 を開発している．これは本来は悪いものであるコードクローンと無理な労力

商用製品として単体で提供されるクローン検出器で，える．またこれにより，CloneTracker はリファクタ

https://clonetracker.com から入手可能である．

リングの労力を払わずとも，動かすだけで利用者が有をかけずに上手に付き合っていくためのツールとも言用性を感じられるツールとなることを狙っている．

3. 1 過去から未来へ継続的な追跡
CloneTracker の使い方は簡単である．インストー
ル後，解析対象のプログラムが存在するディレクトリ

3. 2 善玉クローンと悪玉クローンを指定するだけである．それを指定すると解析が始ま継続的なコードクローンの追跡のため，CloneTracker が解析するプログラムは git†4 で管理しなけ

り，終了すると検出されたコードクローンの一覧が表ればならない．CloneTracker が初めて対象のプログ示される（図 1）．詳細を調べたいコードクローンを

ラムを解析するときは，その最新版だけでなく，過去選択すると，コードクローンと認識されたコード片の版（90 日前の版と，90 日前の版と最新版の中間のが左右に並べて表示され，差分が強調表示される（図版）も合わせて解析をおこない，検出されたコードク

2）．

ローンの変化の履歴を調べる．

CloneTracker は検出したコードクローンの変更履

CloneTracker は新しいコミット (commit) がある†3 文献 [3] の CloneTracker とは異なる．

†4 https://git-scm.com

とコードクローン検出をおこない，前回の検出結果

3. 3 コードクローン検出との差分からコードクローンの変化を調べる．新しCloneTracker のコードクローン検出は CCFinder

いコミットが，既存のコードクローンの一方または両[5] や CCAligner [10] と同様，プログラムのトークン

方のコード片の，直前またはその内部に新しい行を列に対しておこなっている．トークン化のための字挿入している場合，または行を削除している場合，そ句解析器には各言語の標準的なコンパイラのものをれは「修正もれ」の可能性が高いと判断する．つまり移植して使っているので，何をトークンと見なすか

バグや機能拡張の理由でコードに修正が必要なのに，はその字句解析器に依存する．例えば Java の場合，

そのコードの全てのコピーに修正が加えられていな

public や class のような予約語はそれぞれ異なる

いと判断する．その判断が正しければ，明らかなバグ

トークンであるが，変数名やメソッド名などは識別子であるので，CloneTracker はそのコードクローンをとしてすべて同一のトークンとなる．なお C/C++「悪玉クローン」に分類して注意を促す．

の場合，字句解析はマクロ展開などの前処理をする

一度，悪玉クローンに分類されたコードクローン
は，その後もずっと悪玉である．次のコミットで抜け前のプログラムに対しておこなう．その際，#defineのような前処理指令は無視される．

ていた修正が追加されて「修正もれ」が修正されて次に，得られたトークン列をスライド窓 (sliding

も，「善玉クローン」にはならず悪玉のままである．こwindow) 方式で 5 行ずつ取り出しハッシュ値を計算

れは今後も，一方のコード片が修正されたら合わせする（5 は我々が経験的に得た値である）．このときて他方も修正しなければならない，注意を払うべき{ や } のような括弧やカンマ , やセミコロン ; だけ

コードクローンと予想されるからである．むしろ「超の行は無視し，5 行に含めない．そしてプログラム全悪玉クローン」と分類されるべきものである．悪玉ク

体でこのハッシュ値が一致する 5 行の組を探す．ハッローンが悪玉でなくなるのは，リファクタリングにシュ値が一致する 5 行の組のうち，さらにその中央

よってそのコードクローンが除去されて消滅したとき

行の生テキスト（字句解析前の文字列，ただしコメン

である．

トと空白文字は除く）が一致するとき，その 5 行のコードクローンの中には，やがて各コード片に異組をクローンと認識する．スライド窓とハッシュ値をなる修正が加えられて，最後には互いに似なくなり，

用いてコードクローンを探す方式は CCAligner と似

コードクローンではなくなるものが多いことが知らているが，CloneTracker は 5 行のハッシュ値が完全れている [6]．しかし CloneTracker は，悪玉クローンに一致しないとコードクローンと認識しない．一致度に分類したコードクローンがその後に多くの修正がの低いコードクローンを検出してもあまり有用でな

加えられて相当異なるクローンになってしまっても，

いと我々は考えるからである．

悪玉クローンとして追跡を続ける．これはコードク

5 行のハッシュ値を計算するときに括弧等だけの行

ローンが生まれた後，それぞれのコード片に Goolge
Analytics†5 によるアクセス解析や Sentry†6 によるを除外するのも，あまり有用でないコードクローンの障害監視のサービスを利用するためのコードが挿入て検出をおこなうとされると，見かけ上大きく異なってしまい，コードク
ローンでなくなることがあるからである．このような非機能要件に関連するコードを除外してコード片を比較するとコードクローンと判断されるコード片は少なくない．

検出を抑制するためである．例えばトークン列に対し

1, 2, 3,]});のような配列や構造体の初期化部分をコードクロー
ンとして検出してしまいがちだが，これは検出してもあまり有用ではないことが多い．あるいは誤検出と判定されるべきものである．

†5 https://analytics.google.com†6 https://sentry.io

5 行の組のクローンと認識した後，5 行以上の長さ

のコードクローンを検出するため，互いにクローンと認識された 5 行の組のうち，連続して現れるものを連結する．例えば 5 行の組 A と A’ と，別の 5 行の組 B と B’ とが，それぞれクローンと認識されたとする．A と B，そして A’ と B’ がそれぞれ同じ

1
2
3
4
5
6
7

ret = new_return_code(ret)if (ERR_OK == ret) {/* receive message */ret = queue_rcv(&msg,
sizeof(struct _msg));
ret = new_return_code(ret)}

ソースファイル中の連続する行に現れる場合，A とB，A’ と B’ を連結し，AB と A’B’ の組がクローン

リスト 4

修正後のコードクローン

であると認識する．このとき A と B，A’ と B’ の間は必ずしも完全に連続する必要はなく，A と B，A’

れているが，片方のコード片の直前に新しい行が挿入と B’ の間に一致しない行が 3 行まで含まれていてされたときも CloneTracker は修正もれの可能性ありも許容する．

と判断する．しかしコード片の直前に挿入された行

このようにして見つけたコードクローンは，重要が，そのコード片の修正の一部か否かを判定するのは度が高そうなものだけを提示するため，重み付けさ実は容易ではない．例えばリスト 3 の事例で，実際にれる．CloneTracker の利用者に提示されるのは一定

CloneTracker が修正後のコードクローンとして検出の閾値以上の重みをもつコードクローンだけである．

したのはリスト 4 であった．if 文の直前に関数呼び出

重み付けの規則は我々が経験的に得たもので例えば次しの行（1 行目）が挿入されたと判定している．該当のようなものである．

するプログラムの部分を調べたところ，1 行目はこの• より行数の多いコードクローンほど重要．

コード片の前の部分に属すと判断でき，1 行目をこの• 生テキスト同士で比較したときに一致部分が多コード片に対する修正とした CloneTracker の判定はいほど重要．

• if や while など制御構造に関わるトークンが多いほど重要．

• 同じトークン列の行が繰り返されるコードクローンは重要でない．

厳密には誤りであった．現在，CloneTracker は直前に挿入された文が変数宣言であるならコード片の修正の一部と見なさないが，if 文であるときは見なす，といった我々の経験から得た規則で判定をしている．
このように修正もれの判断は容易ではない．対象と• 特定のトークン列が頻繁に現れるコードクロー

なるプログラミング言語の意味論や慣用句を考慮しンは重要でない．例えば C 言語の，識別子，識別て判断しなければならないこともある．例えば Java子，=，数値，; というトークン列は int a = 1;のプログラムには以下のような慣用句と呼べるコーのような変数宣言である．これを多く含むコード

ド片が頻繁に現れる．

クローンは重要でないことが多い．

3. 4 適用事例
2. 1 節のリスト 1，2，3 の例は，実際に CloneTracker が我々の顧客のプログラムから発見した事例である．ただし守秘義務により実際のコード片を簡略化している．この事例では，この後のコミットで実

public static void main(String args[]) {Options opts = Options.parseArgs(args);
これは Apache Cassandra†7 の一部である．このようなコード片をコードクローンだと検出しても有用とは言えない．慣用句なので重みを下げなければならない．さらにこれをコードクローンと認識した場合，片方のコード片だけが際にリスト 1 も 3 と同様に修正されている．Clone-

Tracker は，このコードクローンは今後も修正が加えられるときは両方のコード片に同時に加えなければならないと認識し，「超悪玉クローン」に分類している．
リスト 3 ではコード片の内部に新しい行が挿入さ

public static void main(String[] args) {Options opts = Options.parseArgs(args);と修正され，引数 args の型の書き方が変わったとす†7 https://cassandra.apache.org

る．このとき，他方のコードの型の書き方が変わっていないことを，修正もれと判断するか否かは難しい．
修正の前後でプログラムの意味は変わらないので，修正がもれていても大きな問題ではないからである．
このように CloneTracker を実務で有用なコードク
ローン検出器とするためには，対象プログラミング言表1

初回の解析時間（三つの版の解析時間の合計）

Core i9Core i7
Apple M2
行数
ファイル数

Apache2m 55s4m 33s
5m 54s351,414583

1MLOC
3m 26s
6m 29s
9m 29s1,445,144
12,381OpenSSL9m 55s
17m 08s
28m 53s
736,033
1,984

語ごとに細かな調整が必要である．このため現在のCloneTracker は，実装上は他の言語のプログラムも装されているのも同じ理由で，Rust で再実装するこ分析はできるものの，公式には C/C++ および C#とを計画している．

だけに対応している．

CloneTracker がプログラムの解析に要する時間を表 1 に示す．Apache (Apache HTTP Server†12 )開発の過程では紆余曲折があったが，現在の Clone-と OpenSSL†13 は C 言 語 の プ ロ グ ラ ム で あ る ．
1MLOC は文献 [7] で用いられているデータセット †14

Tracker は各技術者の開発用 PC にインストールしで，Java のプログラムである．Core i9 は i9-12900て使うスタンドアロンのソフトウェアである．クラ(2.4GHz) および 32GB メモリの，Core i7 は i7-

ウド上の SaaS (Software As A Service) として実装

1165G7 (2.8GHz) および 16GB メモリの Windows

されていた時期もあったが，ネットワーク接続を必要マシンである．Apple M2 は 8GB メモリの MacBookとしない製品となっている．実務の開発では開発中

Air (macOS) である．

3. 5 実装のプログラムを外部の SaaS に転送することがセキュ

表の解析時間は初回のそれなので，最新版のプロ

リティの観点から禁止されていることが多いからでグラムだけでなく，90 日前の版，および，最新版とある．また対応するオペレーティングシステムは現在

90 日前の版の中間の版の計三つのプログラムを解析

Windows と macOS および Linux である．

した合計の時間である．ただし 1MLOC は最新版のCloneTracker の実装に利用しているフレームワー

みであるので一回分だけの解析時間である．コードク

クは Tauri†8 である．ユーザインターフェースとコー

ローンを継続的に追跡するためのデータベースの作成

ドクローン検出の主要部は TypeScript で実装されなども含むこと，現在の実装が単一スレッドであるこており，残りの部分は Rust で実装されている．当初用いていた Electron†9 から Tauri に変更することと，などからどの場合も比較的時間がかかっている．

で，ファイルシステムやデータベース（SQLite†10 を

4 関連研究利用）へのアクセスを Rust で行えるようになり実我々は CloneTracker を独自に開発しているが，装の自由度が増した．一方で Tauri は各 OS 標準のコードクローンの検出手法に大きな独創性があるわ

web レンダラを利用するので，その差異に注意を払けではない．CloneTracker の特徴は，実務で開発しう必要がある．コードクローン検出のための字句解析
器は Clang や Javac の字句解析器を Emscripten†11ている技術者や PM にとって有益なコードクローン

で WebAssembly にコンパイルして実行している．こらしている点である．とくにコードクローンの変更のれは当初の実装で Electron を利用していたためであ

履歴を追跡し，修正もれによる不具合を防止することる．コードクローン検出の主要部が TypeScript で実に注力している．

を提示するように，個々の具体例に対応した工夫をこ

コミットの履歴を参照してコードクローンの「修†8 https://tauri.app†9 https://www.electronjs.org†10 https://www.sqlite.org/index.html†11 https://emscripten.org†12 https://github.com/apache/httpd†13 https://github.com/openssl/openssl†14 https://doi.org/10.5281/zenodo.4491208

正もれ」等を指摘する手法は CCEvovis [4] でも提案されている．しかし論文からは，CCEvovis は二つのコミット間の違いの分析に留まっていると読めるが，CloneTracker は三つ以上のコミットにわたって，より長期間コードクローンを追跡する．
文献 [3] の CloneTracker もコードクローンの「修正もれ」を指摘するが，これは統合開発環境 Eclipseのプラグインである．git のような版管理システムとは統合されておらず，コードクローンの一方のコード
片をエディタで編集しようとしたとき，他のコード片も合わせて修正するように促す機能をそなえる．我々の CloneTracker は逆にエディタとは統合されておらず，版管理システムと連携させて使うツールである．

5 まとめ
本稿では我々が商用製品として開発しているコー
ドクローン検出器である CloneTracker について述べた．解析対象のプログラムが時間とともに修正，拡張される中で，コードクローンの変化を追跡するのが特徴である．CloneTracker は現在も実務において有用なツールとなるように開発中であり，他のコードク
ローン検出器との定量的な比較は今後の課題である．

参 考 文 献[ 1 ] Bellon, S., Koschke, R., Antoniol, G., Krinke,J., and Merlo, E.: Comparison and Evaluation ofClone Detection Tools, IEEE Transactions on Software Engineering, Vol. 33, No. 9(2007), pp. 577–
591.
[ 2 ] Bush, W.: Product-Led Growth: How to Build
a Product That Sells Itself, Product-Led Institute,
2019.
[ 3 ] Duala-Ekoko, E. and Robillard, M. P.: Clonetracker: Tool Support for Code Clone Management,
Proceedings of the 30th International Conference on
Software Engineering, ICSE ’08, New York, NY,
USA, ACM, 2008, pp. 843–846.
[ 4 ] Honda, H., Tokui, S., Yokoi, K., Choi, E.,
Yoshida, N., and Inoue, K.: CCEvovis: A Clone
Evolution Visualization System for Software Maintenance, 2019 IEEE/ACM 27th International Conference on Program Comprehension (ICPC), 2019,

pp. 122–125.
[ 5 ] Kamiya, T., Kusumoto, S., and Inoue, K.:
CCFinder: a multilinguistic token-based code clone
detection system for large scale source code, IEEE
Transactions on Software Engineering, Vol. 28,
No. 7(2002), pp. 654–670.
[ 6 ] Kim, M., Sazawal, V., Notkin, D., and Murphy,
G.: An Empirical Study of Code Clone Genealogies, Proceedings of the 10th European Software Engineering Conference Held Jointly with 13th ACM
SIGSOFT International Symposium on Foundations of Software Engineering, ESEC/FSE-13, New
York, NY, USA, ACM, 2005, pp. 187–196.
[ 7 ] Nakagawa, T., Higo, Y., and Kusumoto, S.: NIL:
Large-Scale Detection of Large-Variance Clones,
Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2021, New York, NY, USA, ACM,
2021, pp. 830–841.
[ 8 ] Roy, C. K. and Cordy, J. R.: NICAD: Accurate Detection of Near-Miss Intentional Clones Using Flexible Pretty-Printing and Code Normalization, 2008 16th IEEE International Conference on
Program Comprehension, 2008, pp. 172–181.
[ 9 ] Sajnani, H., Saini, V., Svajlenko, J., Roy, C. K.,
and Lopes, C. V.: SourcererCC: Scaling CodeClone Detection to Big-Code, Proceedings of the
38th International Conference on Software Engineering, ICSE ’16, New York, NY, USA, ACM,
2016, pp. 1157–1168.
[10] Wang, P., Svajlenko, J., Wu, Y., Xu, Y., andRoy, C. K.: CCAligner: A Token Based Large-Gap
Clone Detector, 2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE),
2018, pp. 1066–1077.
[11] Wu, M., Wang, P., Yin, K., Cheng, H., Xu,
Y., and Roy, C. K.: LVMapper: A Large-Variance
Clone Detector Using Sequencing Alignment Approach, IEEE Access, Vol. 8(2020), pp. 27986–
27997.
[12] Yamanaka, Y., Choi, E., Yoshida, N., Inoue, K.,
and Sano, T.: Applying clone change notiﬁcation
system into an industrial development process, 2013
21st International Conference on Program Comprehension (ICPC), 2013, pp. 199–206.
[13] ブラック・ダック・ソフトウェア: オープンソースソフ
トウェア (OSS) ライセンス コンプライアンス ソリューション日本語版 Protex, https://kyodonewsprwire.
jp/release/201309264898.
[14] 松島一樹, 小池耀, 井上克郎: CCX: SaaS 型コー
ドクローン分析システム, コンピュータ ソフトウェア,
Vol. 39, No. 4(2022), pp. 129–143.