一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
IEICE Technical Report

LLM を活用したクラスファイルの局所的な編集による代替コンパイラの提案
渡邉凌雅†

肥後 芳樹†

楠本 真二†† 大阪大学大学院情報科学研究科
E-mail: †{ryg-wtnb,higo,kusumoto}@ist.osaka-u.ac.jp
あらましJava プロジェクトの動作検証や性能評価のために，開発に関与していないユーザーが Java プロジェクトを実行することがある．実行時にプロジェクトのソースファイルやリソースファイルに編集を加える場合，ビルドによる JAR ファイルの更新が必要である．しかし，多くの Java プロジェクトではユーザーの実行環境が Java プロ
ジェクトの想定する実行環境と一致しない．そのため，ビルドのために依存関係の解決や実行環境の再構築が必要で時間と労力を要する．一方，編集がビルド環境に影響しない場合，JAR ファイルに含まれるクラスファイルを局所的に編集するだけで十分である．そこで本研究では，大規模言語モデルを活用してクラスファイルを局所的に編集する手法を提案する．提案手法の評価実験では，LLM として gpt-3.5-turbo を使用し，491 件の Java クラスのソースコードの 1 行削除に対応するようにクラスファイルを編集した．その結果，正解のバイトテキスト差分と完全に一致したのは 286 件で，実行可能なクラスファイルは 261 件であった．
キーワード

1.

Java，ビルド，クラスファイル，コンパイラ，代替モデル，大規模言語モデル（LLM）

はじめに

GitHub 等で一般公開されている Java プロジェクトの動作検も，JAR ファイルに含まれるクラスファイルを何らかの方法で局所的に編集することで，従来のビルドを実行せずに JARファイルを更新できる．

証や性能評価などを行うために，Java プロジェクトの開発にそのため，従来のビルドプロセスに依存せずクラスファイル関与していないユーザーが，ビルド済みの JAR ファイルを使を生成する代替コンパイラを実現するための研究が行われてい用し，ユーザーのローカル環境で Java プロジェクトを実行する．橋本ら [3] は，代替コンパイラの実現に向け，Transformer [4]る場合がある．しかし，実行の目的によっては，Java プロジェベースの機械翻訳モデルを用いて Java ソースファイルからク

クト内の Java ソースファイルやリソースファイルの一部を編ラスファイルへの変換を試みた．Transformer ベースのモデル集することがある．その場合，編集後の Java プロジェクトをでは，バイナリ表現を直接扱うことができない．そこで橋本ユーザーのローカル環境でビルドし，JAR ファイルを更新すらは，バイトコードの各命令に対応するテキスト表現（バイる必要がある．このとき，ビルドを成功させるには，Java プロ

トテキスト）と，バイトコードとバイトテキストの相互変換ジェクトのビルド環境の整合性が保持されている必要がある．

プログラムを作成した．そして，ソースファイルの変換先をつまり，Java ソースファイルやリソースファイルに誤りがなバイトテキストにすることで，バイナリ表現の課題を解決しく，ビルドの実行環境が Java プロジェクトの想定する実行環た．しかし，評価実験では，ReCa [5] から収集した 18,290 件境と一致している必要がある．しかし，ユーザーのローカル環の Java ソースファイルのうち正しく動作するクラスファイル

境が Java プロジェクトが想定する環境と一致しないことが多を生成できたのはわずか 152 件であった．ソースコードの変い．実際，ダウンロードしビルドコマンドを実行するだけでビ換をファイル単位で実行したため，変換対象が広範囲にわたルドに成功する Java プロジェクトは少ない [1] [2]．そのため，り誤りが生じやすかったことが原因の一つと考えられる．

Java ソースファイルやリソースファイルを書き換えてビルド

本研究では，代替コンパイラの実現に向け，大規模言語モデする場合，依存関係の解決や実行環境の再構築が必要であり，

ルを活用したクラスファイルの局所的な編集手法を提案する．

多大な時間と労力を要する．

提案手法では，クラスファイルの編集範囲を Java ソースファ

一方，Java ソースファイルに加えた編集がビルド環境の整合イルの編集差分に対応する局所的なバイトコード命令列に限性に影響しない場合，ビルド済み JAR ファイルとユーザーの定し，編集差分に正確に対応するようにクラスファイルを局所ローカル環境でのビルドによって新たに生成された JAR ファ的に編集する．クラスファイルの編集では，橋本らの先行研究

イルで生じる差分は，編集を加えた Java ソースファイルに対と同様にクラスファイルをバイトテキストとして扱う．そし応するクラスファイルのみである．そのため，ビルド環境のて，大規模言語モデル（LLM）を使用して，バイトコード命令整合性が原因でビルドに失敗する Java プロジェクトに対して列の差分に対応するバイトテキスト差分を生成する．さらに，

This article is a technical report without peer review, and its polished and/or extended version may be published eleswhere.
Copyright ©2024 by IEICE

ソースコード差分と対応するバイトテキスト差分（差分ペア）

自然言語処理分野における LLM の成功を受けて，コードをもとに LLM をファインチューニングし，バイトテキスト差関連タスクにおける LLM の応用が注目されている．LLM は，分生成の精度を向上させる．

コードクローン検出，コード検索といったコード理解系タス

本稿では，以下の設定のもと提案手法を実装し，評価実験を実施した．
• LLM として gpt-3.5-turbo を使用

ク，およびコード翻訳，コード要約といったコード生成系タスクにおいても高い性能を達成している [9]．
LLM は汎用的なモデルであり，特定のタスクに最適化されソースコードの編集差分の単位を 1 行削除に限定ていない．特定のタスクを実行する際は，LLM をそのタスク評価実験では，491 件の検証データを使用して，提案手法によるに合わせてファインチューニングするか，プロンプトエンジクラスファイル編集能力を評価した．実験の結果，gpt-3.5-turbo

ニアリングによって LLM への入力を工夫するのが一般的でが正解のバイトテキスト差分と完全に一致する差分を予測しある．

•た件数は 491 件中 286 件であった．また，提案手法によって得られたクラスファイルのうち，実行可能な件数は 491 件中3.

先行研究とその課題

本研究は，橋本らの先行研究 [3] に基づく．橋本らは，Trans-261 件であった．

former ベースの機械翻訳モデルを用いて Java ソースファイル

2.

準備

2. 1

コンパイルとビルドからクラスファイルへの変換を試みた．
3. 1

先行研究におけるバイナリ表現の扱い

コンパイルとは，プログラミング言語のソースコードを実Transformer ベースのモデルで Java ソースファイルを Java ク行可能形式に変換する処理であり，この処理を実行するプロラスファイルに変換する際，Java クラスファイルがバイナリグラムをコンパイラという．Java プログラムの開発では，Java表現であることが課題となる．Transformer ベースのモデルでのコンパイラが Java ソースファイルをクラスファイルと呼ばは，バイナリ表現を直接扱えないためである．そこで橋本られる実行可能形式に変換する．

は，バイトコードの各命令に対応するテキスト表現（バイトテ大規模な Java プロジェクトでは，Java ソースファイルの他キスト）と，バイトコードとバイトテキストの相互変換プログにリソースファイルや外部ライブラリへの依存関係も含まれラムを作成した．これにより，ソースファイルの変換先をバる．そのため，コンパイルだけでは実行可能なファイルを生成イトテキストにすることで，バイナリ表現を直接扱えない課できない．このような Java プロジェクトでは，代わりにビル題を解決した．

ドと呼ばれるプロセスが実行される．ビルドとは，プロジェク

先行研究では，バイトコードとバイトテキストの相互変換

トのソースコードやリソースファイルを入力し，ソースコーに ASM（注 5）を使用している．ASM とは，Java バイトコードをドのコンパイルと依存関係の解決を経て，実行可能ファイル操作・分析するための API を提供する Java ライブラリである．

を生成するまでの一連のプロセスを指す．Java では，実行可ASM は，クラスファイルを読み込みイベントのシーケンスに能ファイルは一般的に JAR ファイルとして生成される．JAR

変換する ClassReader 抽象クラスと，イベントのシーケンスファイルは，プログラムを構成するクラスファイルや設定ファからクラスファイルを生成する ClassWriter 抽象クラスを提イルを圧縮した Java の実行可能ファイル形式の 1 つである．

供する．先行研究では，ASM で定義されるイベントに対し一また，ビルド実行の効率化を目的として，ビルド自動化ツー対一対応するバイトテキストの構文を定義し，それをもとにルが開発されている．Java 用の代表的なビルド自動化ツール

ClassReader と ClassWriter を継承した独自クラスを実装しとして，Mavenてバイトコードとバイトテキストの相互変換を実現している．

，Gradle（注 1）

2. 2，Ant（注 2）がある．

（注3）

大規模言語モデル（LLM）

図 1 に，"Hello, World!"と出力する Java クラスのソースコー

大規模言語モデル（LLM）は，多数のニューラルパラメードと，コンパイルして得られたクラスファイルをバイトテキスタを持ち，大規模なコーパスで事前学習された言語モデルでトに変換した結果を示す．ソースコードに含まれるクラス宣ある．最先端の性能を持つモデルの多くが Transformer と呼ば言やメソッド宣言，メソッド呼び出しに対応したバイトコーれるアーキテクチャをベースとする．これまでに，BERT [6]，ド命令の列がテキスト表現として出力される．

GPT [7]，T5 [8] といった数多くの Transformer ベースの LLM が3. 2

提案され，機械翻訳や感情分析といった自然言語処理のタス先行研究における評価実験で，ReCa [5] から収集した 18,290先行研究の課題と解決策

クにおいて高い性能を達成している．特に GPT は，その後継件の Java ソースファイルのうち，正しく動作するクラスファモデルである GPT-3.5 や GPT-4 を利用した ChatGPTのリイルを生成できたのはわずか 152 件であった．この原因の 1

リース以降，その高い文章生成能力から多くの分野で急速につとして，ソースコードの変換をファイル単位で実行したた利用が拡大している．

め，変換対象が広範囲にわたり，バイトテキストに誤りが生じ（注 4）やすかったことが考えられる．
（注 1）：https://maven.apache.org/（注 2）：https://gradle.org/

そこで本研究では，Java ソースファイルを局所的に編集した（注 3）：https://ant.apache.org/（注 4）：https://chatgpt.com/（注 5）：https://asm.ow2.io/—2—public class Sample {public static void main( String [] args) {javaSystem .out. println ("Hello ,␣World !");

java

class

class

javajava}}
1.

2.

(a) "Hello, World!"と出力する Java クラスのソースコード
javaclclmemememememeclmememememememe
clvisit 61 33 Sample null java/lang/ Object
Method 1 <init > ()V null null
Code
VarInsn 25 0
MethodInsn 183 java/lang/ Object <init > ()V false
Insn 177
Maxs 1 1End
Method 9 main ([ Ljava /lang/ String ;)V null null
CodeFieldInsn 178 java/lang/ System out Ljava /io/ PrintStream ;LdcInsn class java.lang. String Hello , World !
MethodInsn 182 java/io/ PrintStream println (Ljava /lang/ String ;)VInsn 177
Maxs 2 1
EndEnd

diff

java

diff

3.

java

class

ASM

bytetext

LLM

bytetext

LLM

diff

diff

false

(b) (a) に対応するバイトテキスト

4.

bytetext

diff

patch

bytetext

ASM

class

図 1: Java クラスのソースコードと対応するバイトテキスト
図 2: 提案手法の流れ
場合に，ビルドによってクラスファイルに生じるバイトコード命令列の差分も局所的である点に着目する．そして，クラコマンドで定義される差分の表現方式の 1 つであり，可読性がスファイルの編集範囲を Java ソースファイルの編集差分に対高く，変更箇所が一目でわかる点が特徴である．また，patch応する局所的なバイトコード命令列に限定し，編集差分に正コマンドを使えば，差分を機械的に適用できる．

確に対応するようにクラスファイルを局所的に編集する．さ手順 2. バイトテキストへの変換

らに，ソースコードの編集差分とそれに対応するバイトテキ𝑠 をコンパイルして生成されたクラスファイル 𝑐 𝑠 のバイトスト差分をもとに LLM をファインチューニングし，バイトテコードをバイトテキスト 𝑡 𝑠 に変換する．本研究では，3. 1 節でキスト差分生成の精度を向上させる．

述べた橋本ら [3] のバイトテキスト定義と相互変換プログラム

4.

提案手法

を使用する．
手順 3. LLM によるバイトテキスト差分の生成

本研究では，代替コンパイラの実現に向け，大規模言語モデ

𝑠 に Δ𝑠 の編集を加えたときに，バイトテキスト 𝑡 𝑠 に生じるルを活用したクラスファイルの局所的な編集手法を提案する．

差分 Δ𝑡 𝑠 を LLM に予測させる．LLM のバイトテキスト差分

この手法は既存の Java コンパイラに依存しないため，ビルド生成の正確性を向上させるため，あらかじめソースコード差環境の整合性が原因でビルドに失敗する Java プロジェクトに分と対応するバイトテキスト差分から作成されたデータセッも適用できる．提案手法は様々な LLM に適用できる汎用的なトを用いて LLM をファインチューニングする（5. 章）．

手法である．提案手法の評価実験（6. 章）では gpt-3.5-turbo を使用している．

まず，LLM に入力するプロンプトを生成する．提案手法の評
価実験では LLM として gpt-3.5-turbo を使用したため，この節

図 2 に提案手法の流れを示す．提案手法は，Java ソースファ

では gpt-3.5-turbo を使用する際のプロンプト形式を解説する．

イル 𝑠 とそれに対応するクラスファイル 𝑐 𝑠 ，および 𝑠 に局所プロンプトは，システムプロンプトと指示プロンプトの 2 つ的な編集を加えた Java ソースファイル 𝑠′ を入力として受け取で構成される．システムプロンプトとは，LLM の役割を記述り，𝑠′ に対応するクラスファイル 𝑐 𝑠 ′ を出力する．提案手法はするプロンプトである． 図 3 に本研究で使用するシステムプ

以下の 4 つの手順から構成される．

ロンプトを示す．本研究では，「Java 開発に特化した AI アシ

手順 1.

ソースコード差分の取得スタントであり，与えられたコンテキスト情報に基づき，Java

手順 2.

バイトテキストへの変換

ソースコードの変更に基づいてバイトコードのテキスト表現

手順 3.

LLM によるバイトテキスト差分の生成の差分を Uniﬁed 形式で生成する」旨の英文を使用する．

手順 4.

差分の適用とクラスファイルへの変換

指示プロンプトは，実行したいタスクを具体的に指示するプ

手順 1. ソースコード差分の取得ロンプトであり，システムプロンプトの次に与えられる． 図 4

diff コマンドを使用して 𝑠 と 𝑠′ の差分 Δ𝑠 を取得する．テに本研究で使用する指示プロンプトの例を示す．本研究で作キストファイルの差分を表現する方法には様々な種類がある

成する指示プロンプトは，実行したいタスクの指示文と，タスが，本研究では Uniﬁed 形式を使用する．Uniﬁed 形式は，diff

クの実行に必要なコンテキスト情報で構成される．タスクの—3—

You are an AI assistant specialized in Java development.
Your task is to generate the diff of the text representationof byte code in unified diff format, based on changes madeto the Java source code. You will be provided with three
inputs: the original Java source code, its corresponding
original text representation of byte code, and the diff ofthe Java source code. Using these inputs, your objective isto produce an accurate diff of the text representation ofbyte code in unified diff format that reflects themodifications made to the Java source code.

1.

11javajava

2.

図 3: システムプロンプトの例
java

Using the following information, generate the diff of thebyte code text in unified diff format.
If there is no diff, output "No diff found".

bytetext

class

javac

ASM

java

Original Source Code:bytetext

class

3.

import java.util.*;public class Target00000 {public byte a2b(byte c){if ('0' <= c && c <= '9')
return (byte)(c - '0');
if ('a' <= c && c <= 'z')
return (byte)(c - 'a' + 10);return (byte)(c - 'A' + 10);}}

bytetext

diffbytetext

diff

図 5: 差分ぺアの収集

Original Byte Text:
cl visit 61 33 Target00000 null java/lang/Object
cl Source Target00000.java nullcl Method 1 <init> ()V null nullme Codeme Label l1... () ...
Diff of Source Code:@@ -1,3 +1,3 @@",
-import java.util.*;+public class Target00000 {Diff of Byte Text:

図 4: 指示プロンプトの例

チューニングする．
5. 1

差分ペアの収集

複数の Java ソースファイルから差分ペアを収集する．LLMにバイトテキストの局所的な差分を生成させるため，差分ペアも局所的である必要がある．そこで本稿では，ソースコードに対する編集の単位を 1 行削除とした．
収集対象
差分ペアの収集対象として，FEMP Dataset [10] を使用した．
FEMP Dataset は，機能的に等価な Java メソッドのペアを集めたデータセットである．FEMP Dataset に含まれるすべての Java
メソッドは，Java の標準パッケージ（java.lang および java.util）のみに依存し，メソッド単体で処理が完結する特徴を持つ．

指示文として，「コンテキスト情報を使用し，ソースコードの編集差分に対応するバイトテキストの差分を Uniﬁed 形式で生成せよ．差分がない場合は “No diﬀ found” と出力せよ」旨の英文を使用する．コンテキストとして，ソースコード 𝑠，𝑠 に対応するバイトテキスト 𝑡 𝑠 ，𝑠 に加えた差分 Δ𝑠 の 3 つを含める．
次に，LLM にこれらのプロンプトを入力し，Δ𝑠 に対応するバイトテキスト差分 Δ𝑡 𝑠 を生成させる．

FEMP Dataset から，コンパイル可能で命令文の数が 10 未満の Java メソッドを 1,000 個抽出した．これらの Java メソッドを 1 つずつクラス定義でラップし，1,000 個の Java ソースファイルで構成される集合 𝑆 を作成した．𝑆 は合計 11,432 行のソースコードを含む．
手順

𝑆 に含まれるすべての Java ソースファイル 𝑠 について，𝑠 に

手順 4. 差分の適用とクラスファイルへの変換

含まれるすべてのソースコード行 𝑙 を対象に，𝑙 を削除した際patch コマンドを使用してバイトテキスト 𝑡 𝑠 に手順 3. で得のソースコード差分 Δ𝑠 と対応するバイトテキスト差分 Δ𝑡 𝑠 のられた差分 Δ𝑡 𝑠 を適用し，バイトテキスト 𝑡 𝑠 ′ を得る．手順 3.の生成結果が “No diﬀ found” である場合は 𝑡 𝑠 をそのまま 𝑡 𝑠 ′ とペア (Δ𝑠, Δ𝑡 𝑠 ) を差分ペアとして収集する． 図 5 に，𝑠 から 1行を削除した際の差分ペアを得る手順を示す．収集方法は以して扱う．次に，橋本らによる相互変換プログラムを使用し下の 3 つの手順で構成される．て，𝑡 𝑠 ′ を 𝑠′ に対応するクラスファイル 𝑐 𝑠 ′ に変換する．

手順 1.

𝑠 から 1 行削除したソースファイル 𝑠′ の用意

手順 2.

𝑠，𝑠′ に対応するバイトテキスト 𝑡 𝑠 ，𝑡 𝑠 ′ の生成

5.

LLM のファインチューニング

LLM によるバイトテキスト差分生成の精度向上を目的とし

手順 3. 𝑡 𝑠 ，𝑡 𝑠 ′ の差分 Δ𝑡 𝑠 の取得
手順 1 では，ソースコード 𝑠 から 1 行削除したソースコーて，ソースコード差分と対応するバイトテキスト差分（差分ド 𝑠′ を用意する．手順 2 では，𝑠，𝑠′ それぞれを javac でコンペア）から作成されたデータセットを用いて LLM をファインパイルし，対応する Java クラスファイル 𝑐 𝑠 ，𝑐 𝑠 ′ を生成する．
次に，橋本らによる相互変換プログラムを使用して 𝑐 𝑠 ，𝑐 𝑠 ′ を—4—

バイトテキスト 𝑡 𝑠 ，𝑡 𝑠 ′ に変換する．削除した行によって構文RQ2: 予測差分の適用とクラスファイルへの変換は可能かに誤りが生じ，𝑠′ のコンパイルに失敗する場合は収集対象かpatch コマンドを実行し，RQ1 の検証時に生成した予測差ら除外する．手順 3 では，𝑇𝑠 と 𝑇𝑠 ′ を比較し，バイトテキスト分をバイトテキストに適用可能か検証する．patch コマンド

差分 Δ𝑇𝑠 を得る．差分は Uniﬁed 形式で生成する．の実行が正常終了した場合，予測差分の形式に問題がなく，差結果分が適用可能であると判定する．その後，橋本らによる相互𝑆 に対してバイトテキスト差分を収集した結果，2,453 個の差分ペアを得た．
5. 2

変換プログラムを実行し，予測差分を適用できたバイトテキストをクラスファイルに変換可能か検証する．相互変換プロ

ファインチューニング用データセットの作成

5. 1 節で収集した差分ペアをもとに，gpt-3.5-turbo をファインチューニングするためのデータセットを作成する．このデーグラムの実行が正常終了した場合，差分適用後のバイトテキストに文法的な誤りが含まれておらず，クラスファイルへ変換可能であると判定する．

タセットは，システムプロンプト，指示プロンプト，正解文の実験結果を 表 3 に示す．検証データ 491 件のうち，予測差3 つ組で構成される．システムプロンプトと指示プロンプトに分をバイトテキストに適用ができたケースは 391 件，そのう

ついては 4. 章で説明した通りである．正解文には Δ𝑇𝑠 をそのちクラスファイルに変換できたケースは 343 件であった．

まま使用する．

RQ3: 提案手法で得られたクラスファイルは実行可能か作成した 2,453 件のデータセットを訓練データと検証データ

RQ2 において変換に成功したクラスファイルに対して，そで 4 対 1 に分割した．訓練データ（1,962 件）はファインチューのクラスをテスト対象とする単体テストを実行し，クラスファニングの学習データとして使用し，検証データ（491 件）は提イルが実行可能かどうかを検証する．Java では，クラスファ案手法の評価実験の実験対象として使用する．

イルのロード時にフレームのオペランドスタックのサイズがファインチューニングの実行正しいかどうかなど，クラスファイルの形式に矛盾がないか

5. 3

5. 2 節で作成したデータセットを使用して，gpt-3.5-turbo を検証される．矛盾がある場合，VerifyError が発生し，単体ファインチューニングする．実行には Open AI が提供するファテストの実行に失敗する．そのため，単体テストの実行時にインチューニング API を使用する．ファインチューニング実

VerifyError が発生しなければ，そのクラスファイルは実行

行時の設定は 表 1 に示す通りである．

可能であると判定する．クラスファイルの実行には，FEMP

6.

Dataset に含まれる単体テストのテストスイートを使用した．

評価実験

実験の結果，RQ2 で変換に成功した 343 件のクラスファイ

本稿では，以下の設定のもと提案手法を実装した．
• LLM として gpt-3.5-turbo を使用•

ソースコードの編集差分の単位を 1 行削除に限定

そして，5. 2 節で作成した 491 件の検証データを使用して提案手法によるクラスファイル編集能力を評価する．評価実験にあたり，3 つの Research Questions（RQ）を設定した．

ルのうち，約 76.09% の 261 件が実行可能であった．これは，検証データ 491 件の約 53.16% にあたる．

7.

おわりに

本研究では，大規模言語モデルを活用したクラスファイルの局所的な編集による代替コンパイラの実現手法を提案した．

RQ1: 予測差分は正解差分と一致するか

クラスファイルの編集範囲を Java ソースファイルの編集差分

491 件の検証データに対し，gpt-3.5-turbo でバイトテキストに対応する局所的なバイトコード命令列に限定し，編集差分差分を予測する．その後，予測されたバイトテキスト差分（予に正確に対応するようにクラスファイルを局所的に編集する．

測差分）と正解のバイトテキスト差分（正解差分）を比較し，クラスファイルの編集では，橋本らの先行研究と同様にクラ文字列として完全一致した件数とその割合を計算した．

スファイルをバイトテキストとして扱う．そして，大規模言実験の結果を 表 2 に示す．予測差分と正解差分が一致したのは 491 件中 285 件であった．そのうち，バイトテキストに差語モデル（LLM）を使用して，バイトコード命令列の差分に対応するバイトテキスト差分を生成する．

分が生じたケースについては，約 34.73% で差分が一致した．
一方，バイトテキストに差分が生じなかったケースについて

表 2: RQ1 の結果

は 2 件を除く全てのケースで差分が一致した．

表 1: ファインチューニング実行時の設定
項目

値

ベースモデル

gpt-3.5-turbo-0125

個数 正答数

正答率

全体

491

286

約 58.25%

バイトテキスト差分あり

311

108

約 34.73%

バイトテキスト差分なし

180

178

約 98.89%

シード値

8058399

エポック数

3

バッチサイズ2

予測差分の適用391

約 79.63%

LR マルチプライヤ

2

クラスファイルへの変換

343

約 69.86%

表 3: RQ2 の結果
成功した数

割合

—5—

LLM に gpt-3.5-turbo を使用し，ソースコードの編集差分の単位を 1 行削除に限定した上で提案手法を実装し，491 件の検証データに対して提案手法によるクラスファイル編集能力を評価した．評価実験の結果，gpt-3.5-turbo が正解のバイトテキスト差分と完全に一致する差分を予測した件数は 491 件中 286件であった．また，提案手法によって得られたクラスファイ
ルのうち，実行可能な件数は 491 件中 261 件であった．
提案手法の実装ではソースコード編集差分の単位を 1 行削除とした．しかし，1 行に文や式が多く含まれる場合，バイトテキストの差分が大きくなり，LLM をファインチューニングする際の局所的な差分の対応関係の学習が困難となる．そこで，AST を利用した編集単位の縮小を検討している．AST のノード単位で削除を実行することで，より細かい単位での編集が可能となり，LLM によるバイトテキスト差分生成の精度が向上する可能性がある．将来的には，AST ノードの削除に加えて新たなノードの追加や変更も編集差分に含め，幅広い編集に対応する予定である．
評価実験では 3 つの RQ を設定し，提案手法のクラスファイル編集能力を評価した．しかし，それぞれの RQ の結果に対する考察は実施していない．したがって，それぞれの RQ における成功例や失敗例についての詳細なケーススタディを実施する予定である．
謝辞

本 研 究 は JSPS 科 研 費（JP24H00692，JP21K18302，JP21H04877，JP23K24823，JP22K11985）の助成を得て行われた．
文献[1] M. Sulír, M. Bačíková, M. Madeja, S. Chodarev, and J. Juhár, “Largescale dataset of local java software build results,” Data, vol.5, no.3,
pp.1–11, 2020.
[2] 小池 耀，眞鍋雄貴，松下 誠，井上克郎，“オープンソース Android アプリケーションのビルド可能性に関する調査，” Technicalreport，大阪大学，July 2022．
[3] 橋本 周，“深層学習を用いたコンパイラレスコンパイルの試
み，” Master’s thesis，大阪大学，Feb. 2023．
[4] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A.N. Gomez,
L.u. Kaiser, and I. Polosukhin, “Attention is all you need,” Advancesin Neural Information Processing Systems, pp.5998–6008, 2017.
[5] H. Liu, M. Shen, J. Zhu, N. Niu, G. Li, and L. Zhang, “Deep learning
based program generation from requirements text: Are we there yet?,”IEEE Transactions on Software Engineering, vol.48, no.4, pp.1268–1289, 2022.
[6] J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “BERT: Pretraining of deep bidirectional transformers for language understanding,” Proceedings of the 2019 Conference of the North American
Chapter of the Association for Computational Linguistics: HumanLanguage Technologies, Volume 1 (Long and Short Papers), pp.4171–4186, 2019.
[7] A. Radford, K. Narasimhan, T. Salimans, I. Sutskever, et al., “Improving language understanding by generative pre-training,” 2018.
[8] C. Raﬀel, N. Shazeer, A. Roberts, K. Lee, S. Narang, M. Matena, Y.
Zhou, W. Li, and P.J. Liu, “Exploring the limits of transfer learning witha uniﬁed text-to-text transformer,” The Journal of Machine Learning
Research, vol.21, pp.5485–5551, Jan. 2020.
[9] C. Niu, C. Li, V. Ng, D. Chen, J. Ge, and B. Luo, “An empirical comparison of pre-trained models of source code,” Proceedings of the 45th
International Conference on Software Engineering, p.2136 ‒ 2148,
2023.
[10] 肥後芳樹，“自動テスト生成技術を利用した機能等価メソッド
データセットの構築,” ソフトウェアエンジニアリングシンポジ
ウム 2023，pp.30–38，2023．

—6—