Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

129
特集●ソフトウェア工学の基礎

CCX: SaaS 型コードクローン分析システム
松島 一樹 小池 耀

井上 克郎

コードクローンを検出する際，検出ツールの種類や設定するパラメータの値によって得られる検出結果が大きく変化することが知られている [5] [22]．より正確なコードクローン分析を行うためには, 一つの対象に対し異なる検出ツー
ルやパラメータ値を用いて検出を行い, それらの検出結果を比較することが重要である．しかし個々のコードクロー
ン検出ツールの実行環境を整備し実行結果を比較することは容易ではない．本研究では多様な検出ツールに対応した
SaaS 型コードクローン分析システム CCX を開発した．CCX を利用することで，開発者は個別にインストールすることなく現在 5 つの検出ツールを利用でき，その検出結果の比較や分析を容易に行うことができる．

It is reported that the results of the code clone detection are drastically aﬀected by clone detection tool
and/or their detection parameters [5] [22]. However, it is not easy to set up execution environments forclone detection tools with diﬀerent parameters and to compare the execution results. In this study, we havedeveloped a SaaS-based code clone analysis environment, named CCX. By using CCX, developers can use
currently ﬁve detection tools without installing them individually, and can easily compare and analyze theirdetection results.

ことで効率的なコードクローンの管理が可能である．

1 はじめに

一方で，複数の既存研究において検出ツールの特性

ソフトウェア開発の保守工程における大きな問題の違いやそのパラメータの違いによって，得られる検の 1 つとしてコードクローンの存在が指摘されてい出結果が大きく変化することが明らかにされている

る [4] [14]．コードクローンとはソースコード中に存在[5] [22]．よって，プログラムの保守を行う際には, 複する互いに類似したコード片のことであり，主に既存数の検出ツールやパラメータを組み合わせてコード

ソースコードの複製によって発生する [9]．開発者はクローンを検出し, 修正の影響範囲を慎重に特定する

コードクローンを管理し，適切に修正することでコーことが重要である．しかし，以下のような問題から複ドクローンによる悪影響を軽減させる事ができる．

数の検出ツールや分析ツールを同時に利用すること

しかし，ソースコード中から手作業でコードクロー
ンを検出することは困難であるため，コードクローン
を自動で検出するための様々な手法が研究されているは困難である．
問題点 1 インストールする際の導入コストと動作環境の違い．

[11] [15] [16] [23] ．また，検出結果を可視化することで問題点 2 検出パラメータの違い．

コードクローン分析を支援するツールも開発されて問題点 3 入出力仕様の違い．

いる [1] [2] [21]．開発者はこのようなツールを利用する

本研究ではこれら既存ツールの問題点を解決した

CCX: SaaS-based Code Clone Analysis Environment.
Kazuki Matsushima, Yo Koike, 大阪大学大学院情報科
学研究科, Osaka University.
Katsuro Inoue, 南山大学理工学部, Nanzan University.
コンピュータソフトウェア, Vol.39, No.4 (2022),pp.129–143.
[ソフトウェア論文] 2021 年 1 月 12 日受付.

SaaS 型コードクローン分析システム CCX を開発した．CCX は Web クライアントを提供しておりブラ
ウザからアクセスするだけで利用できるため，ローカルマシンにコードクローンの検出や分析のためのソフトウェアをインストールする必要がない．また，

Sanshusha pLATEX 2ε :c02_matsushima :1302022/10/14(13:41)

コンピュータソフトウェア

CCX はサーバ上でコードクローン検出を行い，バッ

2. 1 コードクローン検出・分析ツール

クエンドとして複数の検出ツールを使用可能である．

コードクローンを管理・修正することは，ソフト

更に CCX の仕様に沿ったプラグインを実装しアッウェアの保守性を維持するために重要である．しかプロードすることで，新たな検出ツールをバックエン

し，全てのコードクローンを手作業で検出することはドに追加できる．

非現実的であるため，効率的なコードクローンの検上述した 3 項目の既存ツールの問題点を解決する
ために CCX に導入した様々な要素についてその設計の妥当性を調査した.

出・分析を目的としたツールに関する研究が数多く行われている [16]．
コ ー ド ク ロ ー ン の 検 出 に 関 し て CCFinder [11]，以降，2 では本研究の背景としてコードクローンつ

NiCad [15]，SourcererCC [17] といったツールが提案いて述べる．3 では既存ツールの問題点について述べされている．一般的に検出ツールはコードクローン

る．4 では CCX とその詳細について述べる．5 ではをファイル名や行番号などの組み合わせで出力する

CCX の設計の妥当性について調査する．6 では妥当ため，検出結果を直感的に理解することは難しい．

性への脅威を述べ, 最後に 7 では本研究のまとめと今

そこで，検出結果を可視化して効率的なコードク

後の課題について述べる．

ローンの分析を支援するツールが提案されている．植田らは CCFinder の検出結果を散布図やメトリクス

2 コードクローンと関連研究

グラフとして可視化するツール Gemini を提案してソースコード中に存在する，全く同一あるいは互いる [21]．また，Asaduzzaman らは NiCad などのいに類似したコード片をコードクローンと呼ぶ [16]．

検出結果を散布図やラジアルマップ，ツリーマップと

コードクローンは主に，既存ソースコードのコピーア

して可視化するツール VisCad を提案している [1]．

ンドペーストやコード生成ツールによる自動生成によって発生する．一般的に互いにコードクローンとな
る 2 つのコード片の組をクローンペアと呼び，コー
ドクローンの同値類をクローンセットと呼ぶ．
複数の既存研究において，コードクローンはソフト
ウェア保守を困難にする要因のひとつとして指摘され

2. 2 検出結果の変化
同一のソースコード集合に対してであっても，コー
ドクローン検出ツールごとの特性や検出パラメータ
によって検出されるコードクローンは大きく変化す
ることが既存研究から明らかになっている．

ている．Barbour らは論文 [4] において一貫した修正

Bellon らは論文 [5] において，CCFinder のデフォが行われていないコードクローンにはバグが混入する

ルトパラメータと調整したパラメータで検出される可能性が高いことを明らかにした．また，Mondal ら

コードクローンの正解集合に対する適合率と再現率

は論文 [14] において複数のプロジェクトを対象にコーを比較した．その結果，調整後のパラメータで得られドクローンの変更履歴を調査し，過去にバグ修正が行た検出結果はデフォルトパラメータのものと比較しわれたコードクローンのうち 18.42% がバグ伝播に関て全く同じ再現率で適合率が 3 倍以上向上していた．

与していることを明らかにした．

また，Wang らは論文 [22] において，6 つの検出

開発者がコードクローンを管理し修正することで，ツールで検出されたコードクローンを行単位で比較

上記のようなコードクローンによる影響を抑制しソした．その結果，ある 1 つの検出ツールで検出されフトウェアの保守性を維持できる．そのため，開発者

たコードクローンの多くはほかの検出ツールでは検がコードクローンに関する情報を認識することは重出されないものであった．また，全検出ツールで共通要である．

して得られるコードクローンは 10% 程度であった．
このように，ただ 1 つの検出結果だけではコードクローンの正確な分析は困難であり，異なる検出ツー
ルやそのパラメータから得られた複数の検出結果を

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022
分析することが重要である．

131

動作環境の制約に関連する問題として，ツールがBigCloneEval は，IjaDataset と呼ばれる Java プ

特定の OS 上でのみ動作する，または共存不可能な

ログラムのデータセットに対して，コードクローン

バージョンのランタイムを要求するという問題が挙検出ツールの検出結果の再現率を計算するためのフげられる．NiCad は Windows 環境をサポートしてレームワークである [19] [20]．このフレームワークは，

おらず，Cygwin や VirtualBox のような Windows

特定のデータに対する再現率の算出に特化しており，上に Linux 環境を構築するソフトウェアを別途イン

データセットの変更や検出結果の詳細な調査などをストールし，その中に NiCad をインストールする必行うことは困難である．

要がある．また，CCFinderX の GUI フロントエンドである GemX はランタイムとして Java 6 を要求

2. 3 クラウドベースの検出システムする一方で CCVolti は Java 8 以上 を要求する．異CloneSwarm は，AWS クラウド環境上で NiCadなるバージョンの Java は同時に利用できないためを検出ツールとして稼働させ，一般ユーザにコード

GemX と CCVolti も同時に利用できない．

クローン検出を提供するサービスである [2] [3]．検出
結果はコードクローンの存在を大局的に可視化したり，また，詳細にコードレベルで表示することがで
きる．git レポジトリを検出対象としてユーザに指定

3. 2 インストールされたツールを利用する際の問題

3. 2. 1 問題点 2: 検出パラメータの違いさせるなど CCX との共通点もあるが，検出ツールがインストールされたツールを利用する際の問題の 1

NiCad に固定されている，検出結果の比較ができなつとして検出パラメータの違いが挙げられる．一般

い，など CCX に比べて機能が限られている．

的に検出ツールは実行時に検出のためのパラメータを設定でき，例えば NiCad には類似度が閾値を下回

3 既存ツールの問題点

るコードクローンを検出結果から除外するパラメー

正確な分析のためには異なる検出ツールやそのパ

タや出力単位を変更するパラメータなどが存在する．

ラメータでコードクローンを検出することが重要で

検出パラメータの種類や定義は検出ツールごとに異なあるが，様々な理由から複数の検出ツールを同時に利るため GemX は CCFinderX 専用の，Clone Swarm

用することは困難である．

[2] は NiCad 専用のパラメータ設定フォームを実装しており，オプションなどでフォームを変更し他の検3. 1 問題点 1: ツールをインストールする際の問題
ツールをインストールする際の問題としてツールの導入コストと動作環境の制約がある．

出ツールに対応するような仕組みは備えていない．

3. 2. 2 問題点 3: 入出力仕様の違い
インストールされたツールを利用する際のもう 1
つの問題として入出力仕様の違いがある．

導入コストに関連する問題として，実行可能ファイ検出ツールへの入力には起動コマンドと検出パラ

ルが配布されていない，またはドキュメントに動作要

メータの 2 つがあり，出力にはコード片の位置を示件が明記されていないという問題が挙げられる．表 1

すファイルパスと範囲，コードクローンの出力単位，の例では NiCad は実行可能ファイルが配布されてお出力フォーマットの 4 つがある．

らず，利用するためにはユーザがソースコードをビル

表 1 に挙げた 5 つの検出ツールについて入力仕様

ドしなければならない．また，Deckard ではビルドをまとめたものを表 2 に，出力仕様をまとめたものに必要なライブラリやラインタイムがドキュメント

を表 3 に示す．入力仕様・出力仕様共にほとんどのに記載されていないため，エラーメッセージから不足

ツールで互換性がない．また，独自フォーマットのしているパッケージを読み取り適切にインストール

出力は構文が複雑で単純な正規表現によるパターン

する必要がある．

マッチでは必要なデータを抽出することが困難であSanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

コンピュータソフトウェア

132
表1

検出ツールの配布形態と動作環境

検出ツール

配布形態

動作環境

ランタイム

CCFinderX+GemX [10]実行可能ファイル

Windows, Ubuntu 9

Python 2.6, Java 6

CCVolti [23]ソースコードWindows

Java 8 以上

CCFinderSW [18]実行可能ファイル

JVM

Java 8 以上

NiCad [15]ソースコードLinux

TXL

Deckard [8]ソースコードLinux

Python 2

る．VisCad では出力フォーマットごとにパーサを用検出を行う実行可能ファイルである．コードクロー

意することで複数の検出ツールに対応しているが，検ン検出プラグインには共通の入出力仕様が定められ出パラメータの設定や起動コマンドの入力はユーザており，内部では検出ツールの起動コマンドの生成やが手作業で行う必要がある．

検出結果の変換などを行う．

4 CCX

4. 2 アーキテクチャ

4. 1 概要

本節では CCX のアーキテクチャとその詳細につ本研究では 3 で述べた問題点を踏まえ SaaS 型コー
ドクローン分析システム CCX を開発した．

CCX は公開された Git リポジトリに対してコードクローンの検出および分析を行う．コードクローン

いて述べる．
図 1 に CCX のアーキテクチャを示す．CCX はコントローラノードとワーカノードという 2 種類のノードと Web クライアントから構成される．

の検出には様々な検出ツールおよびそのパラメータ

コントローラノードは CCX のシステム内に 1 つを設定することが可能である．検出結果は任意に参だけ存在し API サーバやデータベース，検出ツール

照でき，Web クライアントからコードクローンの分

プラグインといったコンポーネントを含む．ワーカ

析が可能である．

ノードは検出ツールプラグインを利用して実際にコー

CCX は問題点 1 について Web サービス化によりドクローン検出を行うためのノードであり，CCX の解決する．従来の検出ツールは利用するためにまずシステム内に 1 つ以上存在する．ワーカノード上でインストールする必要があった．CCX はバックエンはプラグインマネージャが検出ツールプラグインを実ドでコードクローン検出を行うため，ツールをインス行するための前処理と実行後の後処理を行う．Web

トールすることなくブラウザからアクセスするだけ

クライアントは Web ブラウザから CCX を利用する

で様々な検出ツールを利用可能である．

ためのフロントエンドである．

次に，問題点 2 については検出パラメータ定義ファ
イルの導入により解決する．検出パラメータ定義ファ
イルは検出ツールに与える検出パラメータの定義を以降，CCX を構成する主なコンポーネントについて詳細を述べる．

4. 2. 1 API サーバ

記述したテキストファイルである．CCX はこの検出

API サーバはコントローラノードの中心となるコ

パラメータ定義ファイルから検出パラメータの設定

ンポーネントであり，受信した API リクエストを実

フォームを動的に生成することで，検出ツールの種類

行するサーバである．API サーバが提供する API のに関わらず統一された UI を提供する．

例として，外部リポジトリのインポートや検出履歴の最後に，問題点 3 については検出ツールプラグイ

取得，検出結果の参照などがある．その他にコードクンの導入により解決する．コードクローン検出プラグ

ローン検出を実行するための API も提供するが，こインは既存の検出ツールを利用してコードクローン

れに対するリクエストは API サーバではなくワーカ

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022
表2

133

検出ツールの入力仕様

検出ツール

起動コマンド検出パラメータ

CCFinderX./ccfx.exe d java . . .

起動コマンドで設定

CCVoltijava -jar CCVolti.jar . . .

起動コマンドで設定

CCFinderSW./CCFinderSW d . . .

起動コマンドで設定

NiCad./nicad6 blocks java . . .

起動コマンドおよび設定ファイルで設定

Deckard./deckard.sh

設定ファイルで設定
表3

検出ツール

検出ツールの出力仕様

ファイルパス

範囲

出力単位

フォーマット絶対パス

トークン番号

クローンペア

独自フォーマット (バイナリ)

相対パス

トークン番号

クローンペア

独自フォーマット (バイナリ)

絶対パス

行番号

クローンペア

CCVolti

CSV

クローンセット

独自フォーマット (テキスト)

絶対パス

行番号

クローンペアCCFinderSW

JSON

トークン番号

クローンペアCCFinderX フォーマット

クローンペアXML

クローンセットXML

クローンセット

独自フォーマット (テキスト)

CCFinderX

NiCad

絶対パス

Deckard

相対パス

公開

行番号
トークン番号

Git リポジトリ
データベース

API リクエスト

利用
ユーザ

Web クライアント

実装

実行結果

検出ツールプラグイン

プラグイン
マネージャ

API サーバ

新規検出ツール用(必要に応じて実装)

既存検出ツール用(実装済み)

検出ツールプラグイン

検出ツールプラグイン

検出パラメータ定義ファイル

検出パラメータ定義ファイル

Dockerfile

Dockerfile

コントローラノード

図1

Docker コンテナ

ワーカノードソースコード検出パラメータ
検出結果

CCX のアーキテクチャ

ノード上で実行される．また，CCX を複数人で共有

4. 2. 2 検出パラメータ定義ファイル

するために必要なユーザ認証機能も API サーバが提検出パラメータ定義ファイルは検出ツールのパラ供する．

API は Web クライアント以外にも公開され，外部サービスと連携したコードクローンの分析が可能である．

メータ定義のリストを記述したテキストファイルである.

NiCad の検出パラメータの 1 つである threshold
パラメータの定義を記述したものソースコード 1 に示す．1 行目では検出パラメータの表示名を設定している．2 行目では検出パラメータの種類を設定して

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

コンピュータソフトウェア

134おり，float は threshold パラメータが実数値をとることを表す．ここには float の他に，ディレクト
リ名をとることを表す directory や文字列をとることを表す input などが設定可能である．3–6 行目では検出パラメータの制約を設定しており，ここではデフォルト値が 0.3，最小値は 0 より大きく最大値
が 1 に等しいという制約を設定している．7 行目では threshold パラメータの説明文を設定している．
説明文は Web クライアントの検出パラメータ設定
フォームに表示されるため，不慣れなユーザであっても意味を確認しながらパラメータ設定が可能である．
ソースコード 1

threshold パラメータの定義

1

label: Threshold2

type: float

3

rule:

4

default: 0.3

5

max: 1

6

minExclusive: 0

7description: Maximum difference threshold

図2

検出パラメータ設定画面

you are interested in.

とで，新たな検出ツールを CCX のバックエンドに

4. 2. 3 プラグインマネージャ
プラグインマネージャはワーカノードに存在する
コンポーネントであり，検出ツールプラグインを起動
してコードクローン検出を行う．また，その前処理として検出対象のソースコードの取得や検出ツールプ
ラグイン用 Docker コンテナの作成を，後処理として

API サーバへ検出結果の送信などを行う．

追加できる．
検出ツールプラグインは同梱された Dockerﬁle をもとに作成された Docker コンテナ内で実行される †1 ．

Docker を用いることによりランタイムの有無やそのバージョンといったワーカノード環境の制約を排除
し，独立した専用の仮想環境内で検出ツールプラグイ
ンを実行できる．

API サーバとのデータの送受信は全てネットワー
ク経由で行われるため コントローラノードとワー
カノードを異なるマシンに割り当てることも可能である．

4. 2. 4 検出ツールプラグイン
検出ツールプラグインは既存検出ツールを起動してコードクローン検出を行うコンポーネントである．

CCX では検出パラメータと検出結果の共通フォー
マットを JSON 形式で定めており，検出ツールプラ
グインはこの共通フォーマットと検出ツール独自の

4. 3 Web クライアント
Web クライアントは Web ブラウザから CCX を利用するためのフロントエンドである．

Web クライアントの画面の例を図 2 に示す．
図 2 は Git リポジトリに対し，検出パラメータを設定しコードクローン検出を実行するための画面である．Target revision セクションでは，分析対象となる任意の版を，コミットのハッシュ値またはブランチ
名で指定できる (デフォルトは HEAD). Detector セ

フォーマット間の変換を行う．また，この仕様に沿ったプラグインをユーザが実装しアップロードするこ†1 Dockerﬁle が同梱されない場合ワーカノード上のプロセスとして実行される．

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022

135

クションから使用する検出ツールとそのバージョン

は Git リポジトリからソースコードを，データベース

を，Parameters セクションで検出パラメータを設定から検出結果を取得する．Web クライアントは API

する．ユーザが選択する検出ツールとそのバージョン

サーバから受信したソースコードと検出結果から分に応じて Parameters セクションに表示されるフィー析画面を表示する．

ルドは変化する．

検出結果の表示画面の例を図 3 に示す．画面左上

従来のツールでは特定の検出ツール専用のパラメーの a にはファイルツリーが表示される．a でファイ

タ設定用フォームを実装しており，他の検出ツールにルを 1 つ選択するとそのファイルに関連するクロー

対応させるために外部からフォームを変更するようなンペアの一覧が b に，そのソースコードが c に表示仕組みを備えていなかった．CCX では検出パラメー

され，存在するコードクローンは d に示すような縦タ定義ファイルの記述をもとに動的にフォームを生のラインでハイライトされる．e には d と対になる成することで，ソースコードを改変することなく新た

コードクローンのソースコードが表示される．

な検出ツールに対応する．例えばソースコード 1 の4. 4. 3 2 つの検出結果の比較

検出パラメータ定義からは図 2 の Threshold フィー

CCX では 2 つの検出結果を比較，分析する以下のルドが生成される．

ような機能を有する．

検出ツールやパラメータの異なる実行を簡単にま機能 1 文献 [13] の方法により，検出結果の差異のとめてできるよう，CCX では複数の検出パラメータ

大きさを，ファイル単位で散布図上に，赤 (100%)

定義ファイルの逐次作成・実行する機能や，全分析から黄色 (1%) までの階調色，または緑 (0%) で

ツールのデフォルト実行する機能を設けて，ユーザの表示する．

パラメータ設定の手間の軽減を図っている．

機能 2 各ファイル単位に 2 つの検出結果に共通に現れるコードクローン，一方のみに出現するコー

4. 4 機能
本節では CCX が提供する機能について説明する．

ドクローンのリストを表示する．
機能 3 散布図上の点（ファイルに対応）をクリッ

4. 4. 1 コードクローンの検出

クすることにより，対応するファイル中に存在す

前述のようにユーザは設定画面を通じて検出ツー

るコードクローンのソースコードを，その対とな

ルの選択，およびその検出パラメータの設定を行い，
コードクローン検出を実行させることができる．

るコードクローンとともに並列表示する．
図 4 は ある Java ライブラリに対する 2 種類の分

CCX は，API サーバがクライアントからコードク

析結果を比較する散布図の例で，左上を原点として縦ローン検出の API リクエストを受信すると，検出パ

横両軸に同じ順番でファイルが並べられ，各マス目

ラメータ設定ファイルを参照しパラメータ値のバリ（点と呼ぶ）が１つのファイルに対応する．有色点はデーションを行う．制約が満たされていれば，APIいずれかの分析結果にコードクローンが存在すること

サーバはプラグインマネージャへ検出パラメータをを示し，無色の点は存在しないことを示す．この例で送信する．プラグインマネージャは検出パラメータは，有色点のうち半分程度が赤で，対応するそれらのを受信すると，検出ツールプラグインを起動してコー

ファイルでは検出結果の差異が大きいことが分かり，

ドクローン検出を行う．

これらの点をクリックしてソースコードを精査する

検出結果は API サーバを経由してデータベースに保存される．

4. 4. 2 検出結果の表示ことができる．また，有色点の残り半分程度は緑で，２つの検出結果が完全に一致しているのがわかる．
上記機能 1 により，２つの検出結果の差異の概要

CCX では検出結果のコードクローンの対（クローを視覚的に認識できるようになる．赤い点が多い場

ンペア）を ソースコード上に表示でき，視覚的に存在合は，差異が大きいファイルが多数あることを示してを確認することができる．表示のために API サーバ

いる．一般にコードクローン部分のコードを変更すSanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

コンピュータソフトウェア

136

a

c

e

d

b

図3

検出結果表示画面の例

結果の表示画面と同様な画面構成を用いて実現しているが，両方の検出結果に現れるクローンペア，比較の基礎となる検出結果のみに現れるクローンペア，そして，基礎には現れずにもう一方の比較対象の検出結果のみに現れるクローンペアの３種に分けてリスト
表示し，それぞれのクローンペアのファイル中での位置や行数がわかるようになっている．これによって，
機能 1 で赤く表示されたファイルに修正を加えようとする場合，機能 2 や 3 を用いることによって，変更予定箇所がどこの分析結果のコードクローンに含まれているか，対になっているコード片はどこにあるか，それは具体的にどのようなコードで修正の必要が
図4

検出結果を比較した散布図の例

あるか，などを知るのに役立つ．

る場合は，コードクローン対の両方のコードを同時に5 設計の妥当性

変更する必要があり，細心の注意を要する [4] [14] が，CCX では Web サービス化，検出パラメータ定義

検出結果の差異の大きいファイルでは，一種類のコー

ファイルの導入，検出ツールプラグインによる入出ドクローンの検出結果だけを頼りにコードの修正箇

力フォーマットの統一により，3 で挙げた既存ツール

所を特定すると，必要な変更箇所を見落とす可能性がの 3 つの問題点に対処した．本章では表 1 で挙げた高まる．従って，赤い点のファイルの修正には注意が

5 つの既存ツールのプラグインをそれぞれ実装し，問必要である．一方，緑の点が多い散布図は分析結果が題点に対する CCX の設計の妥当性を調査する．こ

安定しており，一種類の検出結果の参照で十分である

れら５つのツールを選んだ理由は，我々が開発し, イ

ことを示している．

ンストールや利用方法の知見がある（CCFinderSW,

機能 2 および機能 3 は、図 3 に示した単独の検出

CCFinderX, CCVolti），長年にわたり利用 さ れ 続けSanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022
ソースコード 2 CCFinderX をインストールする
Powershell スクリプト
1

Invoke-WebRequest https://www.python.org/
ftp/python/2.6.5/python-2.6.5.msi OutFile python-2.6.5.msi

137

N Sothers 上記に当てはまらない操作
Windows 10 Pro における CCFinderX のインス
トール手順を Powershell スクリプトとして記述した
例をソースコード 2 に示す．
ソースコード 2 の 1–2 行目では CCFinderX の動

2msiexec /quiet /i python-2.6.5.msi

3

Invoke-WebRequest http://www.ccfinder.net

作に必要なランタイムとして Python 2.6.5 をインス

/download/ccfx-win32-en.zip -OutFile
ccfx-win32-en.zip
4 Expand-Archive ccfx-win32-en.zip DestinationPath ccfx-win32-en

トールし，3–4 行目では CCFinderX の配布物を zip
ファイルとして取得し展開する．よって Windows 10

Pro における CCFinderX のインストールではユー
ザ操作の数が 4，つまり N S = 4 であり，その内訳はておりツールとして成熟している（Deckard, NiCad）

N Sdist = 2，N Sbuild = 0，N Srt = 2，N Sothers = 0などである. 調査には CPU が Xeon E5-1660，メである．

インメモリが 16GB のマシンを使用し，OS として

5. 1. 2 各既存検出ツールの N S

Windows 10 Pro および Ubuntu 18.04 を利用した．

まず，各検出ツールを単独でインストールする際のN S の値を計測する．計測のために検出ツールをイン
5. 1 問題点 1 の解決: Web サービス化
既存ツールには，ツールをインストールする際の導入コストと動作環境の制約という問題があった．

ストールするシェルスクリプトを Windows 10 Pro
環境では Powershell スクリプトで，Ubuntu 18.04
環境では Bash スクリプトで記述した．

CCX では Web サービス化により Web ブラウザか

Windows 10 Pro 環境における各既存検出ツール

らアクセスするだけでコードクローンの検出や分析がの N S の値を表 4 に示す．NiCad と Deckard は可能である．本節では複数の検出ツールを利用する

Windows 10 Pro を直接サポートしないため，仮想マ

際の導入コストを単純なモデルで表現して定量化し，シン上に作成した Ubuntu 18.04 環境にインストー

Web サービス化が導入コストの低減にどの程度貢献ルするために必要なユーザ操作の数を計測した． 表

しているのか調査する．

中の N Su は VMware Workstation Player 16 をイ

5. 1. 1 導入コストの計測

ンストールし Ubuntu 18.04 仮想マシンを作成後，起導入コストを計測するメトリクスの 1 つとして動が完了するまでに必要なユーザ操作の数を表す．

total number of distinct steps (以下 N S) が提案さ

Ubuntu 18.04 環境における各既存検出ツールのれてる [12]．N S にはファイルのコピーやディレクト

N S の値を表 5 に示す．CCFinderX と CCVolti はリの作成，設定の変更といったソフトウェアのインス

Ubuntu 18.04 を直接サポートしないため，表 4 の場

トール時に必要となる全ユーザ操作が含まれ，値が小合と同様に，仮想マシン上に作成した Windows 10

さいほど良い．

Pro 環境にインストールするために必要なユーザ操計測のためにまず，ドキュメントに記載された手順

作数を計測した．表中の N Sw は VMware Worksta-に沿って各検出ツールをインストールするシェルス

tion Player 16 をインストールし Windows 仮想マシ

クリプトを記述した．ユーザ操作 1 回はシェルスク

ンを作成後，起動が完了するまでに必要なユーザ操作

リプト 1 行に相当するものとして扱う．各ユーザ操の数を表す．

作は以下の 4 種類に分類し，それぞれの行数を合計した全体の行数を N S とする．

N Sdist 配布物の取得に必要な操作

5. 1. 3 複数の検出ツールを同時に利用する際のNS
次に 5. 1. 2 で記述したシェルスクリプトを元に，

N Sbuild 検出ツールのビルドに必要な操作

CCX を使用せずに複数の検出ツールを同時に利用す

N Srt ランタイムのインストールに必要な操作る際の N S の値を計測する．同じランタイムをイン

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

コンピュータソフトウェア

138
表4

Windows 10 Pro 環境で検出ツールを利用する際の N S の値

検出ツール

N SdistN Sbuild

N Srt

N Sothers

NS

CCFinderX

2

0

2

0

4

CCVolti

2

7

0

1

10

CCFinderSW

2

0

2

0

4

NiCad

2

7

0

N Su

9 + N Su

Deckard

2

3

0

N Su

5 + N Su

表5

Ubuntu 18.04 環境で検出ツールを利用する際の N S の値

検出ツール

N SdistN Sbuild

N Srt

N Sothers

NS

CCFinderX

2

0

2

N Sw

4 + N Sw

CCVolti2

70

1+N Sw

10 + N Sw

CCFinderSW

2

0

2

0

4

NiCad

2

7

0

0

9

Deckard

2

3

0

0

5

ストールしているなどシェルスクリプト間で重複した

ルドやランタイムのインストールを自動で行うため，ユーザ操作がある場合は 1 操作とした．また，対象

ユーザ操作による検出ツールのセットアップが不要の既存検出ツールのプラグインが導入済みの CCX をとなったことが大きな要因である．

ローカルマシンにホストして利用する際の N S の値

また，CCX をローカルマシンにホストせず既にイ

N Sccx も同時に計測する．ホスト OS をサポートし

ンターネット上で公開されている CCX をブラウザ

ない検出ツールのプラグインを利用する場合は，ホスから利用する場合，どの検出ツールの組み合わせでもト OS にコントローラノードを，ゲスト OS にワーカ利用するために必要なユーザ操作は，ノードをインストールし CCX システムを構築する．

Windows 10 Pro における計測結果を表 6 に，

1. CCX の Web サイトにアクセスする．
2. アカウントを作成する．

Ubuntu 18.04 における計測結果を表 7 にそれぞれの 2 操作であり N S = 2 で簡便に利用できることが示す．各表の N S と N Sccx を比較すると分かるよ

分かる．

うに，多くの検出ツールの組み合わせで CCX を利上記のことから，CCX をローカルマシンにホスト用しない場合の N S の値が 10 を超えている．特にして利用する場合や CCX をブラウザから利用する

CCVolti と NiCad や NiCad と Deckard のような場合はいずれも複数の既存検出ツールを利用する場

ソースコードをユーザがビルドする必要があり，更に合よりも導入コストが低く，より容易に利用可能であ

ホスト OS をサポートしない検出ツールの組み合わるといえる．

せでは，同時に利用するために非常に多くのユーザ操作が必要である．

CCX をローカルマシンにホストして利用すると，

5. 2 問題点 2 の解決: 検出パラメータ定義ファ
イルの導入

ほぼ全ての検出ツールの組み合わせで CCX を使用

既存ツールにはインストールされた検出ツールを利しない場合と比較して必要なユーザ操作数が少ない．

用する際の問題の 1 つとして検出パラメータの違い

これは Docker が検出ツールプラグインに同梱され(問題点 2) があった．CCX では，検出パラメータ定

た Dockerﬁle の記述に沿って実行可能ファイルのビ

義ファイルに記述された各ツールのパラメータ定義かSanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022
表6

139

Windows 10 Pro 環境で複数の検出ツールを同時に利用する際の N S の値検出ツールの組み合わせ

N SdistN Sbuild

N Srt

N Sothers

NS

N SccxCCFinderX + CCVolti

4

7

2

1

14

6

CCFinderX + CCFinderSW

4

0

4

0

8

6

CCFinderX + NiCad

4

7

2

N Su

13 + N Su

10 + N Su

CCFinderX + Deckard

4

3

2

N Su

9 + N Su

10 + N Su

CCVolti + CCFinderSW

4

7

0

1

12

6

CCVolti + NiCad

4

14

0

1 + N Su

19 + N Su

10 + N Su

CCVolti + Deckard

4

10

0

1 + N Su

15 + N Su

10 + N Su

CCFinderSW + NiCad

4

7

2

N Su

13 + N Su

7

CCFinderSW + Deckard

4

3

2

N Su

9 + N Su

7

NiCad + Deckard

4

10

0

N Su

14 + N Su

7

表7

Ubuntu 18.04 環境で複数の検出ツールを同時に利用する際の N S の値検出ツールの組み合わせ

N SdistN Sbuild

N Srt

N Sothers

NS

N SccxCCFinderX + CCVolti

4

7

2

1 + N Sw

14 + N Sw

12 + N Sw

CCFinderX + CCFinderSW

4

0

4

N Sw

8 + N Sw

12 + N Sw

CCFinderX + NiCad

4

7

2

N Sw

13 + N Sw

12 + N Sw

CCFinderX + Deckard

4

3

2

N Sw

9 + N Sw

12 + N Sw

CCVolti + CCFinderSW

4

7

0

1 + N Sw

12 + N Sw

12 + N Sw

CCVolti + NiCad

4

14

0

1 + N Sw

19 + N Sw

12 + N Sw

CCVolti + Deckard

4

10

0

1 + N Sw

15 + N Sw

12 + N Sw

CCFinderSW + NiCad

4

7

2

0

13

8

CCFinderSW + Deckard

4

3

2

0

9

8

NiCad + Deckard

4

10

0

0

14

8

ら設定用フォームを動的に生成することで統一された

出されたパラメータのうち，実行スレッド数を設定す

UI をユーザに提供する．また，検出パラメータの説

るパラメータや一時ファイルの保存先を指定するパ明の表示や入力値に対するバリデーションを行うこと

ラメータなど出力される検出結果に影響を与えないでユーザビリティを高めている．このように検出パものは除外した．次に抽出された検出パラメータのラメータ定義ファイルは使いやすさに直結するコン制約を可能な限り正確に検出パラメータ定義ファイ

ポーネントであり，検出ツールのパラメータ定義を正ルに記述した．そして最後に各パラメータについて確に記述することが重要である．本節では，検出パラ

制約を再現できているか検証する．

メータ定義ファイルがどの程度正確に既存ツールの5. 2. 2 結果

検出パラメータの制約を再現可能であるか調査する．

調査結果を表 8 に示す．

5. 2. 1 調査手順

CCFinderX，CCVolti，NiCad の 3 つの検出ツー

まず，各検出ツールのドキュメントや CLI のヘルルでは全てのパラメータの制約を正確に再現できた．

プ表示，検出パラメータ設定用ファイルのコメントの一方，それ以外の検出ツールでは再現できなかったパ

記載から検出パラメータとその制約を抽出した．抽

ラメータが 1 つ以上存在する．

Sanshusha pLATEX 2ε :c02_matsushima :1402022/10/14(13:41)

コンピュータソフトウェア

CCFinderSW では b パラメータと antlr パラメー

実装コストは cloc 1.88†2 を用いてコード行数からタに関する制約が再現できなかった．これらは共に計測した．コーディングスタイルがコード行数を変字句解析時の動作を指定するパラメータであり，同時化させないよう，セマンティクスに影響を与えない範に有効化できない．検出パラメータ定義ファイルで囲で事前に改行や括弧の有無などを統一した．

はこのような排他的なパラメータの組み合わせを定義できないため，制約を再現できなかった．

Deckard では MIN TOKENS，STRIDE，SIMILARITY

5. 3. 2 結果
各ツールの検出ツールプラグインを TypeScript で実装したときの実装コストを表 9 に示す．

の 3 つのパラメータに関する制約が再現できなかっ

次に，Deckard 用検出ツールプラグインを Type-た．これらは整数値，整数値，実数値をとるパラメー

Script，Kotlin，Go，Rust で実装したときの実装コ

タで，それぞれ複数の値を指定することが可能であストを表 10 に示す．検出ツールプラグインの実装コる． その場合，各値を組み合わせたパラメータセッ

ストは，どの検出ツール・言語であっても空行やコメトでコードクローンを検出する．例えば MIN TOKENS

ントを除いておおよそ 100–200 行程度であった．

に 20 を，STRIDE に 10 と 20 を，SIMILARITY に

CCX は共通フォーマットの記法として JSON を

0.8 と 0.9 を指定した場合，Deckard は (MIN TOKENS,

採用している．JSON は広く用いられているデータ

STRIDE, SIMILARITY) = (20, 10, 0.8), (20, 10, 0.9),

フォーマットの 1 つで，多くの言語 で シリアライズ(20, 20, 0.8), (20, 20, 0.9) の 4 パターンのパラメー/デシリアライズのためのライブラリが存在する．

タセットでコードクローンを検出し，4 つの結果を出

CCX では，独自のデータフォーマットを定義するの力する．CCX では検出パラメータセット 1 つに対しではなく標準的なデータフォーマットを用いることて検出結果 1 つのみが紐づけられるため，複数の検で検出ツールプラグインの入出力処理の実装コスト

出結果を出力するパラメータには対応できない．

を削減している．また，検出ツールプラグインは基本

上記のことから，検出パラメータ定義ファイルでは的なファイル IO と検出ツールを起動するための外部

多くのパラメータの制約を再現可能である．一方で，プロセス実行機能で構成されるため様々な言語で実CCX の設計上の都合から排他的なパラメータや複数装可能である．上記のことから，検出ツールプラグイの検出結果を出力するパラメータには対応できない．

ンは言語を問わず実装可能であり，実装コストは多く
とも 200 行程度である．

5. 3 問題点 3 の解決: 検出ツールプラグイン

コードクローン検出ツールとして，以下の条件を満

既存ツールにはインストールされた検出ツールを利たせば，CCX のプラグインとして実装可能である．

用する際の問題の 1 つとして入出力仕様の違い (問題• Docker 環境下の Winodws または Linux 上で稼

点 3) があった．CCX では検出ツールプラグインが働するスタンドアロン型コードクローン検出ツー

CCX の共通フォーマットと検出ツール独自のフォールである．

マットを変換することで，様々な検出ツールをバック• 分析対象をファイルまたはディレクトリとしてエンドに追加できる．本節では 5 つの検出ツールに指定し，分析結果はクローンペアもしくはクロー

対して実装した検出ツールプラグインの実装コスト

ンセットの情報として出力する．

を調査する．

• 検出パラメータは実行コマンドのオプションと5. 3. 1 実装コストの計測して指定するか，またはファイルとして読み込む

検出ツールごとの実装コストを調査するため各ツー機能がある．

ルの検出ツールプラグインを TypeScript で実装した．

例えば SourcererCC などもこの条件に適合し，CCX

更に，言語ごとの実装コストを調査するため Deckardに組み込むことは可能である．

用検出ツールプラグインを Kotlin，Go，Rust で実装した．

†2 https://github.com/AlDanial/cloc

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022
表8141

制約を再現できなかったパラメータ数検出ツール抽出したパラメータ数

再現できなかったパラメータ数

CCFinderX

70

CCVolti

10

0

CCFinderSW

14

2

NiCad

12

0

Deckard53

各検出ツールプラグインのTypeScript による実装コストため，導入コストが実際よりも過大に，あるいは過少

検出ツール

LoC

るメトリクスとして以下のような ISO/IEC 9126 でCCFinderX168

定義されている．より正確に導入コストを計測する

CCVolti136

ためには N S だけでなくこれらのメトリクスの利用

CCFinderSW

121

も検討する必要があろう．

NiCad

155

Ease of installation [6] ユーザの都合で手順をDeckard144

変更した場合にインストールが成功した割合．

表9に計測されている可能性がある． 導入コストに関す

Installation eﬀort [7] 全インストール手順のう表 10

Deckard 用プラグインの実装コスト

ち自動化されているものの割合．
しかしこれらのメトリクスを具体的に実装し適用し

言語

LoC

TypeScript

154

Kotlin

186

Go

143

本研究では SaaS 型コードクローン分析システム

Rust

197

CCX を開発した．ユーザは CCX の Web サイトにている例は知られていない．

7 まとめと今後の課題

アクセスするだけで複数の検出ツールを用いてコードクローンの分析ができる．また，ユーザが検出ツール

6 妥当性への脅威

プラグインを実装し CCX にアップロードすること

本研究の妥当性への脅威として次の 2 点が挙げらで新たな検出ツールをバックエンドに追加することがれる．

可能である．検出ツールプラグインは基本的な言語

1 点目は限られた種類の検出ツールを調査対象とし機能で構成されるため様々な言語で実装可能である．

た点である．本研究では 5 の結果を基に CCX は僅

今後の課題として分析機能のプラグイン化が挙げ

かな実装コストで既存検出ツールに対応可能であり，られる．CCX のバックエンドはユーザが検出ツール

導入コストにおいて既存検出ツールより優れている

プラグインを実装することで拡張できるが，フロント

ことを示した．しかし，対象外の検出ツールではこれエンドである Web クライアントはそのような仕組みに反する結果が得られる可能性がある．

を備えていない．現在の設計では，ユーザは新たな分

2 点目は文献 [12] に基づいて 5. 1 で導入コストを析機能を CCX の API を利用する外部サービスとし

シェルスクリプトの行数というモデルで定量化した点て開発できるが，ユーザ認証やデータ取得といった分である．調査においてシェルスクリプト 1 行をユー

析以外の機能も開発する必要があり実装コストが増

ザ操作 1 回に相当するものとして扱っているが，1 行大する．分析機能をプラグイン化し Web クライアンで実行される処理の複雑度は統一されていない．このSanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

コンピュータソフトウェア

142

トに埋め込むことが可能になれば，Web クライアン
トが取得したデータを元に分析を行い結果を可視化する処理を実装するだけで CCX に分析機能を追加できる．また処理の一部をワーカノード上で実行することで複雑で大規模な分析に対応できる．
この機能を実現するためには既存の分析手法がどのように検出結果を利用するか調査し，分析プラグイ
ンのための共通仕様を定める必要がある．

CCX は https://sel.ist.osaka-u.ac.jp/webapps/
ccx/ で公開されており，GitHub などでホストされた Git リポジトリからコードクローンを検出できる．また，そのソースコードは https://github.com/

koi-y/ccx で公開されている．
謝辞

本研究は JSPS 科研費 18H04094 の助成を受けた．また本研究に関していろいろな助言いただい
た関係者や査読者に深謝いたします．

参 考 文 献[ 1 ] Asaduzzaman, M., Roy, C. K., and Schneider,
K. A.: VisCad: Flexible Code Clone Analysis Support for NiCad, in Proceeding of the 5th ICSE International Workshop on Software Clones (IWSC’11),
Association for Computing Machinery, 2011, pp. 77–
78.
[ 2 ] Bandi, V., Roy, C. K., and Gutwin, C.: Clone
Swarm: A Cloud Based Code-Clone Analysis Tool,
in Proceedings of the 2020 IEEE 14th International
Workshop on Software Clones (IWSC’20), IEEE,2020.
[ 3 ] Bandi, V.: CloneSwarm, (2020). https://cloneswarm.usask.ca/.
[ 4 ] Barbour, L., Khomh, F., and Zou, Y.: An
Empirical Study of Faults in Late Propagation
Clone Genealogies, J. Softw.: Evol. Process, Vol. 25,
No. 11 (2013), pp. 1139–1165.
[ 5 ] Bellon, S., Koschke, R., Antoniol, G., Krinke, J.,
and Merlo, E.: Comparison and Evaluation of Clone
Detection Tools, IEEE Trans. Softw. Eng., Vol. 33,
No. 9 (2007), pp. 577–591.
[ 6 ] ISO/IEC: Software Engineering – Product Quality – Part 2: External Metrics, Technical Report
ISO/IEC TR 9126-2, ISO/IEC, 2003.
[ 7 ] ISO/IEC: Software Engineering – Product Quality – Part 3: Internal Metrics, Technical Report
ISO/IEC TR 9126-3, ISO/IEC, 2003.
[ 8 ] Jiang, L., Misherghi, G., Su, Z., and Glondu, S.:
DECKARD: Scalable and Accurate Tree-Based Detection of Code Clones, in Proceedings of the 29th

international conference on Software Engineering(ICSE’07), IEEE Computer Society, 2007, pp. 96–
105.
[ 9 ] Juergens, E., Deissenboeck, F., Hummel, B., andWagner, S.: Do Code Clones Matter?, in Proceedings of the 2009 IEEE 31st International Conference on Software Engineering (ICSE ’09), IEEE
Computer Society, 2009, pp. 485–495.
[10] Kamiya, T.: AIST CCFinderX. http://www.
ccﬁnder.net/ccﬁnderxos.html.
[11] Kamiya, T., Kusumoto, S., and Inoue, K.:
CCFinder: A Multilinguistic Token-based CodeClone Detection System for Large Scale Source
Code, IEEE Trans. Softw. Eng., Vol. 28, No. 7(2002), pp. 654–670.
[12] Lenhard, J., Harrer, S., and Wirtz, G.: Measuring the Installability of Service Orchestrations Using the Square Method, in Proceedings of the 2013
IEEE 6th International Conference on ServiceOriented Computing and Applications (SOCA’13),
IEEE Computer Society, 2013, pp. 118–125.
[13] Matsushima, K. and Inoue, K.: Comparison and
Visualization of Code Clone Detection Results, inProceedings of the 2020 IEEE 14th International
Workshop on Software Clones (IWSC’20), IEEE,
2020, pp. 45–51.
[14] Mondal, M., Roy, B., Roy, C. K., and Schneider, K. A.: An Empirical Study on Bug Propagation through Code Cloning, J. Syst. Softw., Vol. 158(2019), pp. 110407.
[15] Roy, C. K., and Cordy, J. R.: NiCad: Accurate Detection of Near-Miss Intentional Clones Using Flexible Pretty-Printing and Code Normalization, in Proceedings of the 2008 The 16th IEEE International Conference on Program Comprehension(ICPC’08), IEEE Computer Society, 2008, pp. 172–
181.
[16] Roy, C. K., Cordy, J. R., and Koschke, R.: Comparison and Evaluation of Code Clone Detection
Techniques and Tools: A Qualitative Approach,
Science of Computer Programming, Vol. 74, No. 7(2009), pp. 470 – 495.
[17] Sajnani, H., Saini, V., Svajlenko, J., Roy, C. K.,
and Lopes, C. V.: SourcererCC: Scaling Code Clone
Detection to Big-Code, in Proceedings of the 38th
International Conference on Software Engineering(ICSE’16), Association for Computing Machinery,
2016, pp. 1157–1168.
[18] Semura, Y., Yoshida, N., Choi, E., and Inoue,
K.: CCFinderSW: Clone Detection Tool with Flexible Multilingual Tokenization, in Proceedings of the24th Asia-Paciﬁc Software Engineering Conference(APSEC 2017), IEEE, 2017, pp. 654–659.
[19] Svajlenko, J.: IJaDataset 2.0, (2013). https://github.com/jeﬀsvajlenko/BigCloneEval.
[20] Svajlenko, J. and Roy, C. K.: BigCloneEval: A
Clone Detection Tool Evaluation Framework with
BigCloneBench, in 2016 IEEE International Con-

Sanshusha pLATEX 2ε :c02_matsushima :2022/10/14(13:41)

Vol. 39 No. 4 Nov. 2022
ference on Software Maintenance and Evolution(ICSME), 2016, pp. 596–600.
[21] Ueda, Y., Kamiya, T., Kusumoto, S., and Inoue, K.: Gemini: Maintenance Support Environment Based on Code Clone Analysis, in Proceedingsof the 8th International Symposium on Software
Metrics (METRICS ’02), IEEE Computer Society,2002, pp. 67–76.
[22] Wang, T., Harman, M., Jia, Y., and Krinke,
J.: Searching for Better Conﬁgurations: A Rigorous Approach to Clone Evaluation, in Proceedingsof the 2013 9th Joint Meeting on Foundations ofSoftware Engineering (ESEC/FSE 2013), Association for Computing Machinery, 2013, pp. 455–465.
[23] 横井一輝, 崔恩瀞, 吉田則裕, 井上克郎: 情報検索技術に基づく細粒度ブロッククローン検出, コンピュータ
ソフトウェア, Vol. 35, No. 4 (2018), pp. 16–36.

143

コードクローンに関する研究に従事．
小池耀

2021 年大阪大学基礎工学部情報科学科卒業．現在，大阪大学大学院情報科学研究科博士前期課程 2 年．コー
ドクローンに関する研究に従事．
井上克郎

1979 年大阪大学基礎工学部情報工学科卒業．1984 年博士課程了. 同年同大学基礎工学部助手．2002 年情報科
学研究科教授. 2022 年南山大学理工学部教授．工学博士. ソフトウェア工学, 特にソフト

松島一樹

ウェア開発手法, プログラム解析, 再利用技術の研究

2019 年大阪大学基礎工学部情報科学に従事.

科卒業．2021 年同大学大学院情報科
学研究科博士前期課程修了．同年楽天グループ株式会社入社．在学中，