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

信学技報
IEICE Technical Report

ChatGPT を用いたプログラム修正におけるソースコードの意味的情報の影響
堀

翔太†

柗本

真佑†

肥後 芳樹†

伊藤 信治††

楠本 真二†

安田和矢††

張潘タンフエン††† 大阪大学大学院情報科学研究科†† 株式会社 日立製作所
E-mail: †{sho-hori,shinsuke,higo,kusumoto}@ist.osaka-u.ac.jp,††{kazuya.yasuda.fd,shinji.itoh.wn,thithanhhuyen.phan.gw}@hitachi.com
あらましソフトウェア開発におけるデバッグ支援の一つとして，大規模言語モデル（LLM）を用いた自動プログ

ラム修正（LLM-APR）が注目されている．既存研究では LLM-APR のプログラム修正性能を実験的に確認しているが，ソースコードに付帯する情報の影響は明らかにされていない．本研究では LLM-APR の性能改善を目的として，
ソースコードが持つ意味的情報の影響を調査する．意味的情報とはソースコードのコンパイル・実行には影響を与えない，ソースコード理解のための情報であり，JavaDoc に記載された仕様やメソッド名などが該当する．調査では意味的情報の有無を制御した 4 種類のプロンプトを作成し，各プロンプトのプログラム修正成功の割合を調べる．
調査の結果，多くの意味的情報を含むほど LLM-APR の性能が高くなる傾向にあることを確認した．LLM-APR は開発者によるソースコード理解と同様に，仕様や変数名などから修正対象メソッドの取るべき振る舞いを類推していると考えられる．
キーワード

1.

大規模言語モデル（LLM），自動プログラム修正（APR），意味的情報，ChatGPT

はじめに

bug? How to ﬁx it?” のような最小限のタスク指示と，バグを含むソースコードのみがプロンプトとして利用されている．

ソフトウェア開発におけるデバッグ支援の一つとして，大ChatGPT のような対話型の生成系 AI においては，プロンプト

規模言語モデル（LLM, Large Language Model）を用いた自動の設計がその性能に大幅な影響を与える [5] ことが知られていプログラム修正が注目されている．LLM とは大量のテキストる．よって，LLM-APR に対するタスクの指示文章をどう設計

データを用いて学習した言語モデルの一種であり，様々な自するか，あるいは修正対象となるソースコードにどのような然言語タスクに適用可能な汎用アプリケーションである．学

情報を持たせるかは，その性能を左右する重要な要素である

習データにソースコードを含めた LLM も存在しており，ソーといえる．

スコードを対象とした様々なタスクにも応用できる．その応

本稿では，LLM-APR への入力データとなるソースコードが用の一つとして，LLM を用いた自動プログラム修正（APR,

持つ意味的情報に着目する．ここでの意味的情報とはコンパ

Automated Program Repair）が挙げられる．本稿ではこの手法

イルや実行には一切寄与しない，開発者によるソースコード

を LLM-APR と略す．既存の APR 手法 [1] [2] の多くはソース

理解のための付帯情報のことを指す．例えば，Java におけるコードの性質を考慮したプログラム修正への特化手法である

JavaDoc や Python における docstring などの仕様は意味的情報のに対し，LLM-APR は大量のデータに基づく学習と推論を基の一つである．これらのドキュメントには，メソッドの目的本とする点で実現手段が決定的に異なる．LLM-APR は自然言や振る舞い，利用方法などの意味や解釈が記載されており，対語による自然かつ対話的なプログラム修正が可能という利点

象メソッドの理解に寄与する．同様に，メソッド名はそのメだけでなく，その修正精度も既存 APR 技術と同等かそれ以上ソッドの責務を極めて端的に表現した意味的情報の一つであであると報告されている [3]．

る．さらにソースコードの内部に着目すると，変数名も一種社会に大きなインパクトを与えた ChatGPT の公開が 2022
年 11 月という点から，根本的に LLM-APR 研究は黎明期にあの意味的情報だと見なせる．変数名には対象変数が持つ値の意味や役割が付与されているためである．

り，様々な性能改善の可能性が残されている．Sobania ら [4]

本研究の目的は LLM-APR におけるプログラム修正性能のは ChatGPT を用いた LLM-APR の性能を実験的に確かめてお改善であり，そのためにソースコードに付帯する意味的情報のり，全 40 個のバグのうち 19 個の修正に成功したと報告して効果を実験的に確かめる．実験では，3 種類の意味的情報（仕いる．しかしながら，この研究では “Does this program have a

様・メソッド名・変数名）の有無を変化させた 4 種類のソー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-APR の実現可能性を確かめる研究が進められるようて各ソースコードに人為的なバグを埋め込む．このバグを含になってきた．Sobania ら [4] は ChatGPT を用いた LLM-APR

むソースコードをプロンプトとして ChatGPT に与えることで，のプログラム修正能力を実験的に検証している．この研究でその修正の成否を確かめる．実験の結果，意味的情報を多くは，簡単な指示文章とバグを含むソースコードを LLM への含むソースコードほど修正の成功率が向上することが確認で入力に用いている．実験ではプログラミングコンテストからきた．また，仕様を併記することで修正成功率が 5% 改善して得られた QuixBugs [12] と呼ばれるバグデータセットを用いている点から，開発者によるプログラム理解と同様に，LLM におり，40 個のバグに対し 19 個の修正の成功を確認している．

対しても仕様がプログラム理解の手助けになっている可能性

より大規模な LLM-APR 調査として，Xia ら [3] は複数の LLMが示唆された．

モデルと複数のバグデータセットを用いた実験を行っている．

2.

準

備

2. 1

大規模言語モデル（LLM）

結果として，QuixBugs データセットに対しては 37 個の修正に成功したと報告している．LLM を用いない従来の APR 手法の比較研究 [13] によると，全 10 種類の APR 手法を統合して大規模言語モデル（LLM，Large Language Model）とは大量

も QuixBugs に対する修正成功数は 16 個であるとされている．

のテキストデータを用いて学習された言語モデルの一種であ

よって，現時点でも LLM-APR の性能は従来の APR を大幅にる．LLM は翻訳，要約，分類などの多くの自然言語処理タス上回っているといえる．

クを実行できる．代表的な LLM として，OpenAI 社によって開また，LLM の活用においてはプロンプトの改善がその性能発された GPT-3 [6] や，Google 社によって開発された BERT [7]に大きく影響する [5] ことが知られている．先の Sobania と Xiaがある．これらの LLM は，従来の畳み込みニューラルネットの研究では，few-shot 学習や one-shot 学習の効果を確かめておやリカレントニューラルネットを用いた深層学習と異なり，り，いずれも性能改善に寄与している．

Transformer モデルを用いて学習を行っている．

一方で，修正対象となるソースコードにどのような情報をもLLM はソフトウェア工学の分野でも大きな注目を集めていたせるべきかについては明らかになっていない．ソースコード

る．LLM を用いたソフトウェア開発支援の一つとして GitHubは自然言語の文章と同様，高い自由度を持っており，同じ内容

Copilot（注1）がある．これは LLM の一種である Codex [8] を用いであっても様々な表現での記述が可能である．例えば，メソッ

たコーディング支援技術である．Codex とは GPT-3 をソース

ド名や変数名は開発者の考えや癖に強く依存する要素である．

コードに関するタスクにファインチューニングしたモデルでこれらの識別子名はソースコード理解に強く寄与する [14] [15]ある．GitHub Copilot ではコード生成やコメント生成，プログ

ことが知られている．また JavaDoc 記載の仕様はそのメソッ

ラム修正，コード補完などのプログラミング作業を支援する．

ドの責務の把握に役立つ．しかしながら，仕様や識別子名がJesse ら [9] は Codex が補完するコードの品質を調査している．

LLM によるバグ修正にも貢献するのか，あるいはどのような調査の結果，Codex のコード補完タスクでは，正解のソース

仕様や識別子名が LLM に対して有用かについては明らかではコードより多くバグを含むソースコードを生成しており，未ない．

だ精度改善の余地があると確認されている．
2. 2

自動プログラム修正（APR）

3.

調査の目的

自動プログラム修正（APR，Automated Program Repair）とは，本研究の調査目的は，ソースコードの持つ意味的情報がバグを含むプログラムから全自動でバグを取り除く技術であLLM-APR に与える影響の分析である．ここでの意味的情報とる．既存の APR 手法として，探索ベースの手法 [1] やテンプ

はコンパイルや実行には一切寄与しない，開発者のソースコー

レートベースの手法 [10]，意味論ベースの合成手法 [11] などがド理解のための付帯情報を指す．より具体的には，仕様，メ挙げられる．これらの手法は，バグを含むプログラムとテスト

ソッド名及び変数名の 3 種類を意味的情報と見なす．JavaDocを入力として与え，全てのテストケースを通過するプログラなどに記載された仕様は対象メソッドの責務や利用方法，引数ムを目標としてプログラム修正する．いずれもソースコードなどの多くの意味や解釈が記載された意味的情報である．さの静的・動的解析やプログラムの修正事例などを用いた，ソーらにメソッド名は仕様ほど多くの情報を含まないが，そのメスコード特化の手法であるといえる．

ソッドの責務を極めて端的に表現しており一種の意味的情報

LLM を用いた自動プログラム修正（LLM-APR）とみなせる．同様に，変数名はメソッド全体の意味や解釈を

LLM-APR とは LLM を利用した APR 技術であり，バグを含表現しないが，対象変数が持つ値の意味や役割が付与された

むソースコードとバグ修正の指示文を LLM に与えることで，意味的情報といえる．これらの情報はプログラム実行には影修正されたソースコードを得る．一般的な APR とは異なり，響を与えないものの，開発者のソースコード理解に大きく寄

LLM-APR では自然言語文章を用いた自然かつ対話的なプログ

与すると報告されている [14] [15]．本研究では，これらの開発

ラム修正が可能である．

者のソースコード理解のための情報が，LLM に対しても有効

2. 3

ChatGPT に代表されるサービス型の生成系 AI の登場に伴であるかを確認する．

（注 1）：https://github.com/features/copilot

—2—

4.

調査設計

4. 1

調査の流れ

4. 2

実験題材と実験対象ソースコードの単位

実 験 題 材 と し て Java 標 準 ラ イ ブ ラ リ に 含 ま れ る
java.util.ArrayList クラスを採用する．本クラスは全て

本研究の調査は 図 1 に示す以下 6 ステップから構成される．

のメソッドに JavaDoc が記載されており，メソッド名や変数名

1.

対象メソッドを改変し意味的情報の有無を制御するも適切に記述されている．よって，これらの意味的情報がメ2.

対象メソッドに人工的にバグを埋め込む

ソッド理解に役立つ内容であると判断したためである．

3.

対象メソッドからプロンプトを生成する

4.

LLM によりプログラム修正を試みる

いる．すなわち 図 1 に示すソースコードは全てメソッドに該

5.

プログラム修正の成否を確認する

当する．ArrayList クラスは 41 個のメソッドを含んでおり，

6.

ステップ 2 に戻り新たなバグを埋め込む

全メソッドを実験の対象とする．

表 1 に実験に用いたパラメタの一覧を示す．以降では実験

プロンプトに与えるソースコードは，個々のメソッドを用

4. 3

意味的情報の制御方法の流れに従い，実験題材と実験対象ソースコードの単位，意味意味的情報の一つである仕様は，JavaDoc に既に記載され的情報の制御方法，人工的なバグの埋込方法，プロンプトの設ている内容を改変せずそのまま用いる．JavaDoc 記載の内容

計，LLM モデル，プログラム修正の成否判定方法についてそを利用することで，著者らの主観を排除した実験が可能となれぞれ説明する．

る．なお，JavaDoc にはメソッドの著者@author や，リンクの参照@link などのメタ情報のほかに，API ドキュメント生成時

仕様
メソッド名
変数名

ソースコードの HTML の修飾情報なども含まれる．これらはメソッドの責
務の理解には寄与しないため，プログラム修正への影響はな

1. 意味的情報の制御

いと考えられるが，本調査ではこのメタ情報や修飾情報の排除はしていない．
メソッド名と変数名の制御は構文解析によるマスキングを

2. バグを人工的に埋込バグ用いる．ArrayList クラスの全てのメソッド名と変数名は適切な内容が付与されている．よってこれらを$1 や$2 という意
味を持たない文字列に正規化し，意味的情報の有無を制御す

3. プロンプトの生成

る．正規化の際には，コンパイルやプログラム実行に一切の影響を与えないように処理する．
4. 4

人工的なバグの埋込方法

バグの埋込方法として，ミューテーション解析（注 2）を用いる．

4. LLMによるプログラム修正

これは，生成規則に基づいてソースコードを改変し，バグを人工的に埋め込む技術である．例えば，<を<=に変換する関係
演算子の境界の変更や，+ を-に変換する算術演算子の書き換
えなどの生成規則がある．ミューテーション解析は人工的に

5. 修正成否の判定

OK

OK

NG

バグを埋め込むため，バグの種類や位置を正確に把握できる．

NG

また生成規則に従って大量のバグを埋め込むことが可能であ6. バグ埋込の繰り返しる．本調査では，ミューテーション解析を用いて単一のバグを持つソースコードを生成する．実験題材である ArrayList

図 1: 調査の流れの全 41 メソッドにミューテーション解析を適用し，単一のバ
グを含むソースコードを 150 個生成した．この 150 個のバグを含むソースコードを全て実験に用いる．

表 1: 実験に用いたパラメタ
パラメタ

4. 5
値

実験題材

java.util.Arraylist の全 41 メソッド

仕様

JavaDoc をそのまま使用

メソッド名と変数名の制御方法 構文解析によるマスキング

プロンプトの設計

LLM への入力となるプロンプトの基本構造は指示文章と
ソースコードのペアである．指示文章には “The method has abug. Please ﬁx the bug.” のような，ソースコードにバグが含ま

バグの埋込方法

ミューテーション解析（注 2）

れている旨，及びタスクがバグ修正である旨が含まれる．よっ

バグを含むメソッドの数150 個て想定する利用シーンは，開発者がバグの存在に気づいておLLM モデル

gpt-3.5-turbo

り，かつその修正方法が不明という状況である．
プロンプトの取り得る種類は 3 種類の意味的情報の有無の組み合わせであり，全 8（23 ）通りとなる．以降では，この 8通りのプロンプトをプロンプトパターンと呼び，P—-/—-/—- の（注 2）：https://github.com/kusumotolab/Mutanerator

形式で表現する．まず，最も多くの意味的情報を持つパターン—3—

は Psp/mn/vn であり，仕様（speciﬁcation），メソッド名（methodname），変数名（variable name）の全てを含む．また，仕様を持### prompt ###The method has a bug. Please fix the bug.

たずメソッド名と変数名を含む場合は P—-/mn/vn となり，これが 2. 3 節で述べた Sobania ら [4] が実施していた調査のプロン### method ###プトとなる．この P—-/mn/vn を実験のベースラインと見なす．

public boolean $1 () {return $2 != 0;

本研究では 8 通りのプロンプトパターンの内， 表 2 に示す
4 種類のプロンプトパターンを用いる．各意味的情報のソース}

コード理解への寄与度は仕様・メソッド名・変数名の順に高く(a) P—-/—-/—- の例なると考えられる．仕様はメソッド全体の責務を自然言語で表現しており，メソッド名はその責務を簡略化し表現してい### prompt ###る．変数名は処理内部の理解には役立つものの，メソッド全The method follows the specification .

体の理解には直接的に貢献しないためである．よって今回は

And it has a bug.

仕様・メソッド名・変数名の順に有無を制御したプロンプトパ

Please fix the bug.

ターンを用いる．

### specification ###Returns true if this list contains no elements

表 2: 調査に用いる 4 種類のプロンプトパターン
仕様

メソッド名

変数名

Psp/mn/vn⃝⃝⃝

P—-/mn/vn ∗

×

⃝

⃝

P—-/—-/vn

×

×

⃝

×

×

×

P—-/—-/—-### method ###public boolean isEmpty () {return size != 0;}(b) Psp/mn/vn の例∗ 実験のベースラインとなるプロンプト

図 2: プロンプトパターンの一例
2 つのプロンプトパターンの具体例を 図 2 に示す． 図 2(a) はP—-/—-/—- であり，図 2(b) は Psp/mn/vn に対応している． 図 2(a)同様の理由で本研究でも 0 を用いる．

を確認すると，全ての意味的情報がマスクされた状態であり，

4. 7

修正対象メソッドの責務や変数（この場合フィールド）の役割

LLM-APR によるプログラム修正の成否判定としては，目視が読み取れない．そのためこれだけの情報でプログラム修正により振る舞いを考慮した確認を行う．先述の通りソースコーは困難である．他方， 図 2(b) はメソッド名（isEmpty）と変ドは様々な記述方法が可能であるため，バグを埋め込む前の数名（size）が付与されており，何らかの集合のサイズが空

ソースコードとのテキスト的な一致の確認では不十分となる．

プログラム修正の成否判定方法

であるかを確認するメソッドだと推測できる．さらに仕様か

ここでは，LLM-APR の出力した全ソースコードを目視で確認

ら読み取れる情報より，その推測が正しいと窺える．今回のし，意味的に正しい修正が行われているかを調べる．

例では 図 2(b) の return size != 0; にバグが含まれており，
return size == 0; に修正する必要がある．各意味的情報から読み取れる内容より，P—-/—-/—- と比較してメソッドの責務

5.

結果と考察

5. 1

プログラム修正の成否結果が明確であるため，プログラム修正の難易度も下がっていると各プロンプトパターンのプログラム修正の成否結果を 図 3思われる．なお，プロンプトの指示文章については，Psp/mn/vnに示す．プログラム修正の成功数と失敗数を積み上げ式で記のときのみ “The method follows the speciﬁcation.” という，修正述している．ここで成功数と失敗数の合計が各プロンプトパ

対象メソッドが仕様に従うという旨が追加されている．
4. 6

LLM モデル

実験に使用する LLM のモデルは gpt-3.5-turbo である．入力

ターンで一致していないのは，gpt-3.5-turbo の呼び出しにおいてタイムアウトエラーが発生し，解答を得られなかった場合があるからである．

としてテキストを受け取り，テキストを出力するモデルであ

図 3 より，各プロンプトパターンの修正成功率は 64%，59%，

る．gpt-3.5-turbo には出力トークン数の上限が存在している

50% 及び 24% であった．全ての意味的情報を含む Psp/mn/vn のが，本研究において出力トークン数の上限を上回ることは無精度が最も高く，一切含まない P—-/—-/—- の精度が最も低かっかったため問題はない．

た．よって，LLM-APR において 3 種類の意味的情報全てがそ

gpt-3.5-turbo を 呼 び 出 す 際 の パ ラ メ ー タ と し て ，の性能向上に寄与していると考えられる．またベースライン

temperature=0 としている．temperature は，LLM の出力となる P—-/mn/vn と仕様を加えた Psp/mn/vn を比較すると，5%のランダム性に関係する．gpt-3.5-turbo では，0〜1 で指定さの改善が見受けられる．開発者によるプログラム理解と同様

れ，0 に近いほど程ランダム性が小さくなる．ランダム性を小に，LLM に対しても仕様がプログラム理解の手助けになってさくし再現性を確保するため，Xia ら [3] は 0 を採用している．

いる可能性がある．

—4—修正失敗数
修正成功数

160

Psp/mn/vn

P--/mn/vn

18

140

プ 120
ロ
グ 100
ラ
ム 80
修
正 60
の 40
成
否 20
数
0

53

61

12

3

73

61

110
95
(64%)

86
(59%)

Psp/mn/vn

P--/mn/vn

4
73
(50%)

P--/--/vn

34
(24%)

P--/--/--

P--/--/vn

44

図 4: 修正に成功したバグの包含関係（P—-/—-/—- を除く）

図 3: プロンプトパターンごとのプログラム修正の成否数と P—-/mn/vn の修正成功率は 55% と 32% であった．よって修Psp/mn/vn と P—-/mn/vn の修正成功率の差は 5%，P—-/mn/vn と正成功率の差は 23% であり，ArrayList の全メソッドを対象

P—-/—-/vn の修正成功率の差は 9%，及び P—-/—-/vn と P—-/—-/—-とする場合と比較してその改善幅は大きい．一方，責務が多の修正成功率の差は 26% となっていることから，LLM-APR のく長いメソッドではメソッド名を含まないことが性能改善に

修正精度に最も影響を与えている意味的情報は変数名だと推寄与すると考えている．実際，メソッド名をマスクする手法

測できる．ただし，今回の実験では 3 種類の意味的情報の全のみで成功するバグ（図の下）は，責務が多く長いメソッド

組み合わせである 8 通りのプロンプトパターンを用いて実験に含まれる傾向があった．ArrayList 内の最も行数の多いメをしていない．今後，プロンプトパターンを拡張しそれぞれソッドにおいて P—-/—-/vn の修正成功率は 59% であり，これはの意味的情報の影響について調査する必要がある．

Psp/mn/vn の 55% と比較しても高い精度である．責務が多く長プログラム修正に成功したバグの包含関係

いメソッドは，そのすべての責務を完全に表現できるメソッ

5. 2

最も精度の低かった P—-/—-/—- を除く，3 プロンプトパター

ド名を命名しづらい．よってメソッド名が表現できていない

ンの修正成功バグの包含関係を 図 4 に示す．図より 61 個の範囲にバグが存在するとき，メソッド名が LLM に対してミス

バグは 3 種のプロンプトパターン全てで修正に成功しており，リードを招き，プログラム修正が失敗する可能性がある．た

多くのバグは包含関係を持つ．これはバグの種類によって修だしこれは判断材料となる数が少ないため，今後メソッドの

正の難易度が異なるためだと考えられる．これら共通集合と責務の多さを定量的に表現し，その関係を調査していく必要なる 61 個のバグは LLM にとって修正難易度の低いバグであがある．

り，意味的情報の有無にかかわらず修正しやすい可能性があ

6. 2 LLM-APR に効果的な仕様

る．一方で，意味的情報を多く含むプロンプトが含まないプ

本稿では仕様として JavaDoc を用いたが，LLM-APR に利用

ロンプトを完全に内包していないことも確認できる．例えば，できる仕様の選択肢は他にもある．選択肢の一つとして，自動仕様を与えないベースライン手法のみで成功するバグが 3 個

コード要約が考えられる．コード要約により生成された要約（図の右上）あり，仕様もメソッド名も与えない手法のみで成を仕様として用い LLM-APR の性能向上を図る．コード要約

功するバグが 4 個（図の下）存在している．この理由は LLM

が性能向上に寄与する場合，開発者が JavaDoc を作成しなくとのランダムな挙動に起因すると考えられる．本稿では各プロも高い精度のプログラム修正が期待できる．ただし実際の利

ンプト・各バグに対して 1 試行のみしか実験しておらず，複数用シーンを考えると，バグを含むソースコードから要約する必試行による実験が必須である．なお，意味的情報の過多が性要があるため，要約の内容自体がバグの影響を受けると考えら

能低下の要因となっている可能性も考えられる．この点につれる．2. 1 節で述べた Jesse ら [9] は，バグを含むソースコード

いては続く 6. 1 節で議論する．

から生成されたコメントをプロンプトに組み込み，LLM によ論るコード補完性能の検証をしている．調査の結果，コメント

6.

議

6. 1

意味的情報の効果を左右するソースコードの要素

報告している．同様に，LLM-APR においてもバグを含むソー

意味的情報の有無が LLM-APR の性能に与える影響は，修正

スコードから作成された要約が性能向上に寄与する可能性は

対象メソッドの責務や行数の多さに左右されると推測していが無い場合より Codex によるコード補完の性能が向上したとあると考えられる．

る．仕様が修正成功率の改善に寄与するバグ（ 図 4 の左上）

さらに他の仕様として，入出力例やテストケースがある．入は，責務が多く長いメソッドに多く含まれる傾向があった．責

出力例は対象メソッドのとるべき挙動を示し，テストケースは務が多く長いメソッドほど，バグの候補となりうる箇所が多く

対象メソッドの取る挙動が想定通りか確認する．どちらも対プログラム修正の精度は下がる．そのため仕様の追加による

象メソッドの振る舞いを示しており一種の仕様といえる．ま

改善幅が大きかったのだと考えられる．実際，ArrayList ク

た実際の開発において，開発者は入出力例やテストケースをラス内で最も行数の多い 30 行のメソッドにおいて，Psp/mn/vn

持っているため利用シナリオにも即しており，これらの影響—5—

の調査は残された調査課題の一つである．
6. 3

LLM-APR に効果的なメソッド名と変数名

責務を行数などで定量的に表現し，意味的情報との関係を調査する必要がある．2 つ目は，LLM-APR に効果的な意味的情メソッド名と変数名の命名方法は様々であり，それぞれの名報の調査である．自動コード要約や入出力例，テストケース

前が持つ意味によってソースコードの可読性は大きく変わる．

を仕様として用いて LLM-APR を行い，JavaDoc を必要としな

Schankin ら [15] は，開発者のソースコード理解に役立つ識別子

い LLM-APR の性能向上について調査する．また，端的な識別名について調査している．調査の結果，短く端的な識別子名に子名と複雑な識別子名による LLM-APR の精度を比較調査し，比べて長く複雑な識別子名の方がプログラマのソースコード

LLM にとって適した識別子名を明らかにする．

理解は早くなると報告されている．複雑な識別子名はコード

謝辞

本 研 究 の 一 部 は ，JSPS 科 研 費（JP20H04166，

行が増え可読性を損ねる恐れがあるが，それ以上に名前の持つ

JP21K18302，JP21K11829，
JP21H04877，JP22H03567，
JP22K11985）

意味情報の利益が大きいと推測できる．LLM-APR も同様に，による助成を受けた．

複雑な識別子名が持つ意味情報が有効に働き，高い性能を示すと考えている．端的な識別子名と複雑な識別子名が LLM-APR

文[1]の性能に与える影響の調査はさらなる研究課題である．
6. 4

LLM のデータリーケージ

LLM の学習データに今回の修正対象となったソースコードの情報が存在しており，LLM-APR の正しい性能評価ができな[2]

い可能性がある．本稿で使用した gpt-3.5-turbo モデルの学習データは公開されていない．そのためデータリーケージの問[3]

題を完全に検証することは不可能である．
本稿の調査では，同一メソッドに対して LLM-APR を適用し[4]た場合でも，埋め込んだバグが異なると修正成否の結果が異なる場合があった．例えば，Psp/mn/vn の場合，全 41 メソッド

[5]の内 15 メソッドにおいて，修正成功と修正失敗が混在している．これは LLM-APR がそれらの 15 メソッドにおいてはデー
タリーケージによる出力をしていないと考えられる．データ[6]

リーケージの対策は，公開されていないソースコードを用いる，またモデルの学習データの期間が公開されている場合は，その期間から外れたソースコードを用いるなどがある．

7.

[7]

おわりに
[8]

本研究では LLM-APR におけるソースコードの持つ意味的情報の影響について調査した．本稿での意味的情報とはコンパ
イルや実行には寄与しない開発者のソースコード理解のため[9]の情報のことで，仕様，メソッド名及び変数名の 3 つである．
調査の結果，3 種類全ての意味的情報が LLM-APR の性能向上[10]に寄与すると分かった．これは，開発者のソースコード理解と同様に，LLM も意味的情報からソースコード理解をし，プ[11]

ログラム修正している可能性を示唆している．
今後取り組むべき課題として，JavaDoc の適切な整形と全プ[12]

ロンプトパターンの実施が挙げられる．本稿では JavaDoc に含まれるメタ情報の排除をしていない．これらが LLM-APR に与える影響は不明だが，仕様の影響を正しく調査するために[13]

適切な整形は必要である．また，本稿では 3 種類の意味的情報の組み合わせである 8 通りのプロンプトパターンについて調査していない．それぞれの意味的情報の影響を正しく検証[14]

するためには必須な項目であり今後の課題である．
さらに 2 つの発展的な研究課題への取り組みを検討している．一つ目は，意味的情報の影響を左右するソースコードの特徴の調査である．修正対象とするメソッドの責務の多さにより，意味的情報の影響は左右されると考えている．メソッドの

[15]

献

Y. Higo, S. Matsumoto, R. Arima, A. Tanikado, K. Naitou, J.
Matsumoto, Y. Tomida, and S. Kusumoto, “kGenProg: A highperformance, high-extensibility and high-portability apr system,”
In Proceedings of Asia-Paciﬁc Software Engineering Conference,
pp.697–698, 2018.
M. Martinez and M. Monperrus, “ASTOR: a program repair library for
java,” In Proceedings of Internatinal Symposium on Software Testingand Analysis, pp.441–444, 2016.
C.S. Xia, Y. Wei, and L. Zhang, “Automated program repair in the eraof large pre-trained language models,” In Proceedings of International
Conference on Software Engineering, pp.1482–1494, 2023.
D. Sobania, M. Briesch, C. Hanna, and J. Petke, “An analysis of automatic bug ﬁxing performance of chatgpt,” In Proceedings of International Workshop on Automated Program Repair, pp.23–30, 2023.
J. White, Q. Fu, S. Hays, M. Sandborn, C. Olea, H. Gilbert, A. Elnashar,J. Spencer-Smith, and D.C. Schmidt, “A prompt pattern catalog to enhance prompt engineering with chatgpt,” arXiv, p.arXiv:2302.11382,
2023.
T. Brown, B. Mann, N. Ryder, M. Subbiah, J.D. Kaplan, P. Dhariwal,
A. Neelakantan, P. Shyam, G. Sastry, A. Askell, et al., “Language models are few-shot learners,” In Proceedings of International Conference
on Neural Information Processing Systems, pp.1877–1901, 2020.
J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “Bert: Pre-trainingof deep bidirectional transformers for language understanding,” arXiv,
p.arXiv:1810.04805, 2018.
M. Chen, J. Tworek, H. Jun, Q. Yuan, H. Ponde, J. Kaplan, H. Edwards,
Y. Burda, N. Joseph, G. Brockman, et al., “Evaluating large language
models trained on code,” arXiv, p.arXiv:2107.03374, 2021.
K. Jesse, T. Ahmed, P.T. Devanbu, and E. Morgan, “Large language
models and simple, stupid bugs,” In Proceedings of International Conference on Mining Software Repositories, pp.563–575, 2023.
K. Liu, A. Koyuncu, D. Kim, and T.F. Bissyandé, “TBar: Revisiting
template-based automated program repair,” In Proceedings of International Symposium on Software Testing and Analysis, pp.31–42, 2019.
S. Jha, S. Gulwani, S.A. Seshia, and A. Tiwari, “Oracle-guided
component-based program synthesis,” In Proceedings of International
Conference on Software Engineering, pp.215–224, 2010.
D. Lin, J. Koppel, A. Chen, and A. Solar-Lezama, “QuixBugs: a multilingual program repair benchmark set based on the quixey challenge,”
In Proceedings of International Conference on Systems, Programming,
Languages, and Applications: Software for Humanity, pp.55–56, 2017.
H. Ye, M. Martinez, T. Durieux, and M. Monperrus, “A comprehensive study of automatic program repair on the quixbugs benchmark,”
In Proceedings of International Workshop on Intelligent Bug Fixing,
pp.1–10, 2019.
R. Cates, N. Yunik, and D.G. Feitelson, “Does code structure aﬀect
comprehension? on using and naming intermediate variables,” In
Proceedings of International Conference on Program Comprehension,
pp.118–126, 2021.
A. Schankin, A. Berger, D.V. Holt, J.C. Hofmeister, T. Riedel, and M.
Beigl, “Descriptive compound identiﬁer names improve source code
comprehension,” In Proceedings of Conference on Program Comprehension, pp.31–40, 2018.

—6—