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

信学技報
TECHNICAL REPORT OF IEICE.

構文誤りを含むプログラムを評価可能なソースコード用自動評価尺度の
調査
髙市

陸†

肥後

芳樹†

柗本

真佑†

楠本

倉林 利行††

切貫

弘之††

丹野

治門††

真二†

† 大阪大学大学院情報科学研究科†† 日本電信電話株式会社
あらまし

近年，コード翻訳や自動プログラム生成等のソースコードを出力する手法の研究が盛んに行われている．それらの手法は発展途上で，構文的に間違っているプログラムが生成されることも少なくない．そのため，既存手法の評価には，自然言語処理で用いられる自動評価尺度が使われることがある．しかし，それらの評価尺度のうち，どれが自動生成されたプログラムの評価に適しているかは不明である．そこで本研究では，構文的に正しくないプログラムに対しても適用可能で，自然言語で記述された要求からプログラムを生成する手法の評価に適した自動評価尺度を明らかにする．
キーワード

自動評価尺度，自動プログラム生成，深層学習

1. ま え が きム生成では，要求を満たすコードの生成は困難である [8]．自動プログラム生成を利用する際，生成されたコードを人間が修正す

近年，コード翻訳や自動プログラム生成（Automated Program

ることにより，要求を満たすコードにする必要がある．そのた

Generation: APG）等のソースコードを生成する手法の研究がめ，生成されたコードは要求を満たすコードへの修正が容易であ盛んに行われている [1] [2] [3] [4] [5]．これらの研究では，生成さることが望ましい．自動評価尺度が生成されたコードの評価にれたコードの評価に自動評価尺度が用いられている．

適しているかどうかは，生成されたコードから要求を満たすコー

ソースコードのための自動評価尺度はいくつか提案されていドへの修正の容易さによって判断できる．

る [6] [7]．それらの評価尺度は，コードが構文的に正しいことを生成されたコードから要求を満たすコードへの修正容易性を前提として抽象構文木やプログラム依存グラフを用いている．し測る被験者実験を行った．その結果，生成コードの修正容易性とかし，コードを生成する手法の研究は発展途上で，構文的に間相関が強く，自動プログラム生成によって生成されたコードの評違っているプログラムが生成されることも少なくない．例えば，価に適した自動評価尺度は METEOR [12] であることが明らか

近年提案された自動プログラム生成モデルである SNM [4] ではになった．

7.0 %，Coarse-to-Fine [5] では 90 % の出力プログラムが構文的に正しくなかったという報告がある [8]．そのため，コードが構
文的に正しいことを前提としているソースコードのための自動評価尺度は使えないことがある．
コードを生成する手法の評価には，ソースコード用の自動評

2. Research Question
自動プログラム生成によって生成されたコードの評価に適した自動評価尺度を明らかにするために，以下 2 つの Research

Question（RQ）を設定した．

価尺度ではなく，自然言語処理で用いられる自動評価尺度が使わ

RQ1: 修正時間を用いて測定する生成コードの修正容易性をれている場合もある [9] [10]．特に，BLEU は生成されたソース

適切に評価できる自動評価尺度はどれか？

コードの品質評価に頻繁に用いられているが，ソースコードを評

生成コードの修正容易性は，開発者による修正に要した時間

価するには限界があるといわれている [6] [11]．生成コードの評で評価できる．生成コードの修正容易性を修正時間で評価する価に用いられておりコードの構文的正しさを前提としない評価

とき，修正容易性を適切に評価できる自動評価尺度を調査する．

尺度のうち，どれが自動生成されたプログラムの評価に適してい調査では，修正時間と自動評価尺度の評価値の相関をみる．対象

るかは不明である．

となる自動評価尺度のうち最も相関が強い尺度が修正容易性を

そこで本研究では，構文的に正しくないコードに対しても適用適切に評価できるとみなす．

可能なコードの評価に適した自動評価尺度を明らかにする．特

RQ2: 修正量を用いて測定する生成コードの修正容易性を適に自動プログラム生成タスクに着目し，自然言語で記述された要切に評価できる自動評価尺度はどれか？

求から自動的に生成されたコードの評価に適した自動評価尺度

生成コードの修正容易性は，開発者による修正前後のコードを明らかにする．
現状，自然言語で記述された要求を入力とする自動プログラの修正量によっても評価できる．生成コードの修正容易性を修正量で評価するとき，修正容易性を適切に評価できる自動評価尺—1—

度を調査する．調査では RQ1 と同様に，修正量と自動評価尺度の評価値の相関をみる．対象となる自動評価尺度のうち最も相関が強い尺度が修正容易性を適切に評価できるとみなす．

3. 準

S += b [ j ] + a [ i ]S += a [ i ] + b [ j + 1 ](a) 生成コード pre備(b) 正解コード ref

図 1: 自動評価尺度の計算手順説明用コード

3. 1 自動プログラム生成（APG）
自動プログラム生成とは，プログラムを全自動で生成する技

ある．同様に p1 = 11/11，p2 = 7/10，p3 = 3/9 となる．また，length(ref) = 13，length(pre) = 11 より術である．自動プログラム生成手法は，入力として与える要求

BP = e−2/11の形式とプログラム生成手段の 2 つの組み合わせで分類できる．
入力の形式には自然言語の文章 [8]，DSL [13]，入出力例 [14] 等

BLEU(pre, ref) = BP · exp

がある．手段には，翻訳ベース [8]，探索ベース [15] 等がある．

n=1

本研究では特に，自然言語の文章で書かれた要求を入力とする翻N≃ 0.345

訳ベースの自動プログラム生成手法を想定する．

3. 2 編 集 距 離( 4)∑ log pnとなる．

編集距離 EditDistance [16] は，ある列 X を別の列 Y と同じ

正解コードが複数ある場合の BLEU は，(3) 式で算出される．

列にするための編集操作の最小回数である．編集操作には要素

BLEU(pref, refs) = max BLEU(pref, ref)の追加，削除，置換の 3 種類がある．

0 以上 1 以下の値に正規化された編集距離の求め方を (1) 式に示す．なお，列 S の長さを length(S) で表している．

NormarizedEditDistance =(3)

ref∈refs

STS
STS（STring Similarity）[6] は，編集距離を用いた自動評価

EditDistance (X, Y )max (length (X) , length (Y ))(1)

尺度で (4) 式で表される．

STS(pre, ref) = 1 − NormarizedEditDistance(pre, ref) (4)3. 3 自動評価尺度

例えば，生成コードが図 1(a) で正解コードが図 1(b) のときの自動評価尺度は，翻訳結果の品質を自動的に評価するためのSTS は次のように計算する．まず，pre に対する ref の編集距離尺度である．翻訳結果の手動評価は高コスト [17] なため，低コを考える．pre の左から b を a に，j を i に，a を b に，i を j にストで評価可能な自動評価尺度が提案されている．自動評価尺

それぞれ置換し，+ と 1 を挿入すれば ref になる．よって，編集距

度によって手動評価を代替するという目的を考えると，自動評価

離 EditDistance(pre, ref) = 6 となる．また，length(ref) = 13，

尺度による評価と手動評価の相関は高いほどよい．

length(pre) = 11 なので以下では，本研究で用いた自動評価尺度について説明する．いSTS(pre, ref) = 1 − 6/ max(13, 11)

ずれも，評価値は 0 以上 1 以下の数値で表現され，1 に近いほ

≃ 0.538

ど高い評価を意味する．また，説明では生成コードのトークン列
を pre，正解コードのトークン列を ref ，正解コードのトークン
列の集合を refs として用いる．

となる．
正解コードが複数ある場合の STS は，(5) 式で算出される．

BLEU
BLEU（BiLingual Evaluation Understudy）[17] は，自然言語の機械翻訳結果の評価のために考えられた自動評価尺度である．BLEU は，pre と ref の n-gram の精度 pn と重み wn ，生成コードの長さに対するペナルティ BP を用いて (2) 式で表される．

(

BP = min 1, e
BLEU(pre, ref) = BP · exp

1−length(ref)/ length(pre)

(N
∑

(5)

ref∈refs

ROUGE-L
ROUGE（Recall-Oriented Understudy for Gisting Evaluation）[18] は，自然言語要約の品質評価のために考えられた自動評価尺度である．ROUGE-L [18] は ROUGE の一種で，2 つ)の列における最長共通部分列（Longest Common Subsequence:)
wn log pn

STS(pref, refs) = max STS(pref, ref)

LCS）の長さを用いて計算される．ROUGE-L は，重み β を用
(2)

いて (6) 式で表される．

n=1

本研究では，N = 4，wn = 1/N とする．これは，BLEU を提案した研究 [17] で用いられた設定である．例えば，生成コードが図 1(a) で正解コードが図 1(b) のときの BLEU は次のように計算する．まず，pre に対する ref の n-gram の精度を考える．n = 4 のとき，pre の 4-gram は 8 個あり，そのうち ref にも存在する 4-gram は “a [ i ]” のみで 1 個なので p4 = 1/8 でR(pre, ref) =LCS(pre, ref)length(ref)P (pre, ref) =LCS(pre, ref)length(pre)ROUGE-L(pre, ref) =(1 + β 2 )RP
R + β2P(6)

本研究では，R と P を同じ重要度として扱うために β = 1 とす

—2—

る．例えば，生成コードが図 1(a) で正解コードが図 1(b) のとき

α，β ，γ ，δ および wi はパラメータである．本研究では，ソーの ROUGE-L は次のように計算する．まず，pre に対する ref の

スコードが英単語を用いて書かれる場合が多い点に着目して，生LCS を考える．LCS は “S += [ ] + [ ]” なので，LCS(pre, ref) =成コードと正解コードをそれぞれ生成されたテキストと参照テ

7 となる．また，length(ref) = 13，length(pre) = 11 なのでキストと見なして評価した．評価では，METEOR の実装である meteor-1.5.jar [12] に -lang en オプションを渡して言語設定をR(pre, ref) = 7/13

英語にし，コードを英語のテキストとみなした．各パラメータP (pre, ref) = 7/11
ROUGE-L(pre, ref) =は，言語設定を英語にしたときのデフォルトの値である．

2 · 7/13 · 7/11
7/13 + 7/11

正解コードが複数ある場合の METEOR は，(9) 式で算出される．

≃ 0.614
METEOR(pref, refs) = max METEOR(pref, ref)(9)ref∈refsとなる．
正解コードが複数ある場合の ROUGE-L は，(7) 式で算出さ

4. 実

験

れる．

∑
LCS(pref, ref)ref∈refs
R(pref, refs) = ∑∑ref∈refs

ref∈refs

P (pref, refs) =被験者実験によって，自動プログラム生成モデルの生成したコードを要求を満たすコードに修正する修正容易性を測定する．

length(ref)修正容易性は，修正時間と修正量で測る．修正量は，生成コード

LCS(pref, ref)と修正済コードの正規化された編集距離によって求める．測定

length(pref)(1 + β 2 )R(pref, refs)P (pref, refs)
ROUGE-L(pref, refs) =R(pref, refs) + β 2 P (pref, refs)(7)

した修正容易性と自動評価尺度による生成コードの評価の相関をとる．修正時間と修正量は高いほど修正容易性が低いので，負の相関が強いほど，その自動評価尺度は自然言語で記述された要求からプログラムを生成する手法の評価に適しているといえる．

METEOR

負の相関が強いということは，修正容易性が高いほど評価が高く

METEOR は，自然言語の機械翻訳結果の評価のために考えなる傾向が強いからである．

られた自動評価尺度で，BLEU の改良版として設計されている [19]．METEOR では，トークンの一致度を以下のように分類する．

4. 1 自動プログラム生成モデルの作成
自動プログラム生成モデルの作成のために，GitHub 上で公開されている自然言語翻訳用のネットワーク（注 1）を利用した．

（1）完全一致

学習には，プログラミングコンテストの問題文と正解コード，（2）語幹が一致

テストケースの組からなるデータセット ReCa [8] を用いた．

（3）同義語

データセットには，5,149 問の問題文と 16,673 個の Python コー（4）フレーズが言い換え可能ドが含まれている．300 問をテスト用，200 問を検証用，残りをある文 A に含まれる単語 a と別の文 B に含まれる単語 b が一致訓練用として学習を行い自動プログラム生成モデルを作成した．

するとき，一致度がどれに分類されるか判定する関数を M (a, b)

作成したモデルの入出力例を図 2(b)(c)(d) に示す．入力は，とする．このとき，A に含まれる単語であって B にも含まれる

図 2(a) のような英語の問題文に対して小文字化，レンマ化，ス

単語との一致度が（1）から（4）に分類される単語数をそれぞ

トップワード除去などの前処理を施した図 2(b) のような文でれ m1 (A, B) から m4 (A, B) で表す．特に，B が自明な場合はある．出力は，図 2(c) のような Python コードのトークン列で

mi (A) と書く．また，A と B で同一順序で出現し，連続して一ある．図 2(c) のようなトークン列は，適当な処理によって自動致する単語の列をチャンクという．チャンクの数を ch(A, B) で的に図 2(d) のような Python コードに変換できる．以下では，表す．METEOR は，生成されたテキスト内の内容語 hc と 機

図 2(d) のような自動プログラム生成モデルの出力から得られる

能語 hf ，参照テキスト内の内容語 rc と機能語 rf ，生成されたコードを生成コードと呼ぶ．図 2(d) は要求を満たさないコード

テキストと参照テキストそれぞれの一致する単語数の平均 m おである．例えば，図 2(g) のようなテストケースの入力が与えら

よび単語の一致度ごとの重み wi を用いて (8) 式で表される．

∑

れた場合に，図 2(d) は入力の受け取りに失敗する．入力の 1 行

wi · (δ · mi (hc ) + (1 − δ) · mi (hf ))δ · |hc | + (1 − δ) · |hf |目には整数が 1 つしかないが，図 2(d) の 1 行目では n と k の 2

wi · (δ · mi (rc ) + (1 − δ) · mi (rf ))δ · |rc | + (1 − δ) · |rf |P ·R
Fmean =
α · P + (1 − α) · R

ドのひとつであり，要求を満たす図 2(e) では，図 2(g) の入力を

i

P =

∑

R=

Pen = γ ·つの整数を受け取ろうとしているからである．問題の正答コー

i

(

ch
m

与えると期待される出力と同じ出力が得られる．

4. 2 対)β

METEOR = (1 − Pen) · Fmean

象

被験者実験には，テスト用データ 300 問からランダムにサン（注 1）：https://github.com/nazim1021/neural- machine- translation-(8)

using-gan—3—

Suppose we have a s e q u e n c e o f non−n e g a t i v e
i n t e g e r s , Namely a_1 , a_2 , . . . , a_n . At eachtime we can c h o o s e one term a_i with 0 < i < nand we s u b t r a c t 1 from both a_i and a_i +1. We
wonder whether we can g e t a s e q u e n c e o f a l lzeros after several operations .

s u p p o s e we have s e q u e n c e o f non−n e g a t i v e
i n t e g e r , namely a_1 , a_2 , . . . , a_n . a t each time
we can c h o o s e one term a_i with 0 < i < n andwe s u b t r a c t 1 from both a_i and a_i +1. wewonder whether we can g e t s e q u e n c e o f a l l z e r oafter several operation .

(a) 問題文(b) 前処理された問題文

n , k = map ( int , input ( ) . split ( ) ) & n a =list ( map ( int , input ( ) . split ( ) ) ) & n a .
sort ( ) & n ans = 0 & n for i in range ( k ) : & n &indent if a [ i ] == a [ i - 1 ] : & n & indent & indentans += 1 & n & indent & dedent print ( ans ) & n

n ,
a =
a .
ans
for

k = map ( int , input ( ) . split ( ) )list ( map ( int , input ( ) . split ( ) ) )sort ( )= 0i in range ( k ) :if a [ i ] == a [ i - 1 ] :ans += 1
print ( ans )(c) 自動プログラム生成モデルの出力(d) 生成コード

Len = int ( input () )List = list ( map ( int , input () . split () ) )assume = True
res = 0for i in range ( Len ) :res = List [ i ] - res
if res < 0:assume = False
break
if assume and res == 0:
print ( " YES " )else :
print ( " NO " )n = int ( input ( ) )a = list ( map ( int , input ( ) . split ( ) ) )for i in range ( n -1 ) :a [ i +1] -= a [ i ]a [ i ]=0if ( a [ -1]==0) : print ( " YES " )else : print ( " NO " )(e) 正解コード(f) 修正済コード

入力期待される出力

2
2 2

YES

(g) テストケース

図 2: 実験データの例

プリングした 10 問を用いた．サンプリングされた問題には，1問あたり平均 53.4 個のテストケースがある．
被験者は，大阪大学大学院情報科学研究科に所属する教員 1名，同研究科に所属する修士の学生 8 名，大阪大学基礎工学部

STEP-3 （テスト）STEP-2 で修正したコードが STEP-1 で与えられたすべてのテストケースに通過するか確かめる．通過
すれば STEP-3 は終了する．通過しなければ STEP-2 に戻り
生成コードをさらに修正する．

情報科学科に所属する学部生 2 名の計 11 名である．被験者ご

生成コードを修正するまでに要した時間として，STEP-2 からとに Python の習熟度は異なる．習熟していない被験者のため

STEP-3 終了までの秒数を測定した．以上の手順で図 2(f) のよに，コードの修正時に必要と思われる処理のチートシートを配布

うに修正された生成コードを，修正済コードと呼ぶ．STEP-2 やした．

STEP-3 において生成コードを修正できなかった場合は，修正済

4. 3 手順

被験者実験は，問題ごとに以下の手順で行った．

STEP-1 （要求の理解）被験者には図 2(a) のような問題文とコードおよび修正時間は得られない．そのため，得られる修正済
コードと修正時間の数は被験者ごとに異なる．

4. 4 結果と考察

図 2(g) のようなテストケースが与えられる．被験者は問題文

実験結果から，2 つの RQ に回答する．

を読み，要求を理解する．

RQ1: 修正時間を用いて測定する生成コードの修正容易性を

STEP-2 （生成コードの修正）被験者には図 2(d) のような生成

適切に評価できる自動評価尺度はどれか？

コードが与えられる．被験者は STEP-1 で与えられた問題の表 1 に各自動評価尺度の評価値と修正時間のピアソンの相関

解答コードとして正しいコードになるように生成コードを修正

係数，有意性検定の結果である p 値を示す．表 1 から，評価値する．すなわち，要求を満たすように生成コードを修正する．

と修正時間の相関は METEOR が最も強いことがわかる．また，

—4—

4000
2000

0.2
0.4
0.6
0.8
BLEU(生成コード, 正解コード)

8000
6000
4000
2000
0
0.0

1.0

0.2
0.4
0.6
0.8
STS(生成コード, 正解コード)(a) BLEU(b) STS

8000

0.7

0.6
0.0

6000
4000
2000

0.2
0.4
0.6
0.8
ROUGE‒L(生成コード, 正解コード)

1.0

0.8

0.7

0.6
0.0

0.2
0.4
0.6
0.8
STS(生成コード, 正解コード)(a) BLEU

6000
4000
2000
0
0.0

1.0

0.2
0.4
0.6
0.8
BLEU(生成コード, 正解コード)

0.9

1.0

(b) STS

8000(c) ROUGE-L

0.2
0.4
0.6
0.8
METEOR(生成コード, 正解コード)

1.0(d) METEOR

図 3: 各メトリクスによる生成コードと正解コードの類似度に対する生成コード修正時間の分布

NormarizedEditDistance(修正済コード, 生成コード)

修正にかかった秒数

修正にかかった秒数

0.8

10000

10000

0
0.0

1.0

0.9

NormarizedEditDistance(修正済コード, 生成コード)

6000

0.9

0.8

0.7

0.6
0.0

METEOR に関しては，有意水準 5 % で有意に相関があること

0.2
0.4
0.6
0.8
ROUGE‒L(生成コード, 正解コード)

1.0

NormarizedEditDistance(修正済コード, 生成コード)

8000

0
0.0

NormarizedEditDistance(修正済コード, 生成コード)10000
修正にかかった秒数

修正にかかった秒数

10000

0.9

0.8

0.7

0.6

(c) ROUGE-L

もわかる．

0.0

0.2
0.4
0.6
0.8
METEOR(生成コード, 正解コード)

1.0(d) METEOR

図 4: 各メトリクスによる生成コードと正解コードの類似度に対

図 3 に，各自動評価尺度による生成コードと正解コード間のする生成コードと修正コードの編集距離の分布

類似度に対する生成コード修正時間の分布を示す．図中の線分は各被験者の分布に対する回帰直線を表している．直線と分布

評価値が高いほど修正量が少なくなっている．ROUGE-L で修の点の色は，回帰直線の傾きが正の場合は暖色，負の場合は寒色正量と評価値の相関が低い原因は，ROUGE-L が正解コードので，傾きが強いほど赤または青が濃くなっている．図 3 をみる

長さを考慮しすぎているからだと考えられる．ROUGE-L 以外と，ほとんどの被験者は評価値が高いほど修正時間が短くなっての 3 つの評価尺度では，正解コードが複数あるとき，各正解コーいる．一方で，一部の被験者に関しては評価値が高いほど修正時

ドを用いた場合の評価値の最大値を全体の評価値とすることで，間が長くなっている．そのような被験者による修正時間と各自

1 つの正解コードの長さのみを考慮している．一方で ROUGE-L

動評価尺度における評価値の相関は統計的に有意とは言えない．

は，各正解コードの和を用いており，すべての正解コードの長さを考慮している．実際，正解コードの長さをあまり考慮しないよ

RQ1 への回答： 生成コードの修正時間による評価の代替

うに β = 2 とした場合，相関係数は −0.573 と改善する．これとして優れている自動評価尺度は METEOR である．まは，METEOR に次ぐ相関の強さである．反対に，β = 0.5 とした，生成コードの評価によく用いられている BLEU は修正た場合，相関係数は −0.267 と悪化する．

時間による評価の代替として優れているとは言えない．

 RQ2 への回答： 生成コードの修正量による評価の代替とRQ2: 修正量を用いて測定する生成コードの修正容易性を適して優れている自動評価尺度は METEOR である．また，切に評価できる自動評価尺度はどれか？

生成コードの評価によく用いられている BLEU は修正量に

表 2 に各自動評価尺度の評価値と修正量の相関係数，有意性検定の結果である p 値を示す．表 2 から，評価値と修正量の相関よる評価の代替として優れているとは言えない．



は METEOR が最も強いことがわかる．また，全ての自動評価

RQ1 および RQ2 の結果を踏まえると，自然言語の文章で記尺度において，有意水準 5 % で有意に相関があることもわかる．

述された要求からプログラムを生成する手法の評価に適した自図 4 に，各自動評価尺度による生成コードと正解コード間の動評価尺度は METEOR であると言える．

類似度に対する生成コード修正量の分布を示す．図 4 をみると，

ROUGE-L 以外の自動評価尺度では，すべての被験者において
表 1: 各自動評価尺度の評価値と修正時間の相関p値

表 2: 各自動評価尺度の評価値と修正量の相関
自動評価尺度

相関係数

BLEU−0.392 4.64 × 10−4

p値

STS

−0.555 1.99 × 10−7

自動評価尺度

相関係数

BLEU−0.181 0.117

ROUGE-L−0.481 1.08 × 10−5STS

−0.100 0.389

METEOR−0.696 3.03 × 10−12

ROUGE-L

0.011, 5 0.921

METEOR−0.251 0.028, 6—5—

5. 妥当性の脅威
本研究では，自然言語用のネットワークから自動プログラム生成モデルを作成した．そのため，最新の自動プログラム生成モ
デルよりも性能が低く，正解コードと大きく異なるコードが生成されている可能性がある．生成コードの質が異なれば，異なる実験結果となるかもしれない．
被験者実験は，11 人の被験者と最大 10 問分のデータで実施された．統計的な分析をするには規模が小さすぎる可能性がある．
より多くの被験者とデータ数で実験した場合，同様の結果が得られるとは限らない．
被験者実験で使用した問題が被験者に難しすぎた可能性もある．簡単な問題の正解コードは短く単純で，難しい問題の正解
コードは長く複雑かもしれない．もし，実験に使用したモデルが短く単純なコードを生成しやすければ，自動評価尺度による評価
は単に問題の難しさを表すだけとも考えられる．被験者にとって問題が難しすぎる場合，被験者は生成コードの理解と修正だけでなく，問題を解くためのアルゴリズムを考察する時間が余分にかかってしまう．その結果，簡単な問題の時は高評価かつ修正容易，難しい問題のときは低評価かつ修正困難となってしまう．
考察の時間を考慮して被験者実験を行い修正容易性を測定した
場合，実験結果が異なる可能性がある．

6. あ と が き
本研究では，構文的に正しくないコードに対しても適用可能なコードの評価に適した自動評価尺度を明らかにすることを目的に，被験者実験によって得られた評価値と相関の強い自動評
価尺度を調査した．調査の結果，自動プログラム生成による生成コードを要求を満たすコードへ修正するまでの時間と修正量の両方で比較的強い相関を示した自動評価尺度は METEOR であった．よって，METEOR がコードの評価に適した自動評価尺度であると言える．
今後の研究課題として，問題文だけを読んで一からコードを書いたときの時間と生成コードの修正時間との差分によって生成コードを評価した場合と相関の強い自動評価尺度の調査を考えている．このような手動評価尺度を用いることで，問題の難しさによる考察時間の影響を小さくした評価ができる可能性がある．また，コード生成に特化した最新の自動プログラム生成
モデルの利用も検討している．生成コードの品質が向上すれば，問題の難しさによる考察時間の影響や Python への習熟度の影
響を小さくできるかもしれないからである．
謝辞

本研究は JSPS 科研費（JP20H04166，JP21K18302，

JP21K11820，JP21H04877，JP22H03567，JP22K11985）の助成を得て行われた．
文

献[1] D. Guo, S. Ren, S. Lu, Z. Feng, D. Tang, S. LIU, L. Zhou,
N. Duan, A. Svyatkovskiy, S. Fu, M. Tufano, S.K. Deng, C.
Clement, D. Drain, N. Sundaresan, J. Yin, D. Jiang, and M.
Zhou, “GraphCodeBERT: Pre-training code representations
with data ﬂow,” Proc. International Conference on Learning
Representations, 2021.

[2] B. Roziere, M.A. Lachaux, L. Chanussot, and G. Lample,“Unsupervised translation of programming languages,” Proc.
International Conference on Neural Information Processing
Systems, 2020.
[3] W. Ahmad, S. Chakraborty, B. Ray, and K.W. Chang, “Uniﬁed pre-training for program understanding and generation,”
Proc. Conference of the North American Chapter of the Association for Computational Linguistics: Human Language
Technologies, June 2021.
[4] P. Yin and G. Neubig, “A syntactic neural model for generalpurpose code generation,” Proc. Annual Meeting of the Association for Computational Linguistics, 2017.
[5] L. Dong and M. Lapata, “Coarse-to-Fine decoding for neuralsemantic parsing,” Proc. Annual Meeting of the Association
for Computational Linguistics, 2018.
[6] N. Tran, H. Tran, S. Nguyen, H. Nguyen, and T. Nguyen,“Does BLEU score work for code migration?,” Proc. 2019
IEEE/ACM International Conference on Program Comprehension, 2019.
[7] G. Zhao and J. Huang, “Deepsim: deep learning code functional similarity,” Proc. ACM Joint Meeting on European
Software Engineering Conference and Symposium on theFoundations of Software Engineering, 2018.
[8] H. Liu, M. Shen, J. Zhu, N. Niu, G. Li, and L. Zhang, “Deeplearning based program generation from requirements text:
Are we there yet?,” IEEE Transactions on Software Engineering, vol.48, no.4, pp.1268–1289, 2022.
[9] A. Svyatkovskiy, S.K. Deng, S. Fu, and N. Sundaresan, “Intellicode compose: Code generation using transformer,” Proc.
ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2020.
[10] B. Wei, G. Li, X. Xia, Z. Fu, and Z. Jin, “Code generation
as a dual task of code summarization,” Proc. International
Conference on Neural Information Processing Systems, 2019.
[11] S. Karaivanov, V. Raychev, and M. Vechev, “Phrase-based
statistical translation of programming languages,” Proc.
2014 ACM International Symposium on New Ideas, New
Paradigms, and Reﬂections on Programming & Software,
2014.
[12] M. Denkowski and A. Lavie, “Meteor universal: Language
speciﬁc translation evaluation for any target language,” Proc.
Ninth Workshop on Statistical Machine Translation, 2014.
[13] M. Rabinovich, M. Stern, and D. Klein, “Abstract syntax
networks for code generation and semantic parsing,” 2017.
https://arxiv.org/abs/1704.07535[14] E. Parisotto, A. Mohamed, R. Singh, L. Li, D. Zhou, andP. Kohli, “Neuro-symbolic program synthesis,” Proc. International Conference on Learning Representations, 2017.
[15] L. Spector, “Autoconstructive evolution: Push, PushGP,
and Pushpop,” Proc. Genetic and Evolutionary Computation
Conference, 2001.
[16] V.I. Levenshtein, “Binary codes capable of correcting deletions, insertions, and reversals,” Soviet physics doklady,
vol.10, 1966.
[17] K. Papineni, S. Roukos, T. Ward, and W.J. Zhu, “Bleu:a method for automatic evaluation of machine translation,”
Proc. Annual Meeting of the Association for Computational
Linguistics, 2002.
[18] C.Y. Lin, “ROUGE: a package for automatic evaluation ofsummaries,” Proc. ACL Workshop on Text Summarization
Branches Out, 2004.
[19] S. Banerjee and A. Lavie, “METEOR: An automatic metric for MT evaluation with improved correlation with humanjudgments,” Proc. ACL Workshop on Intrinsic and Extrinsic
Evaluation Measures for Machine Translation and/or Summarization, 2005.

—6—