信学技報
IEICE Technical Report
信学技報
SS2020-8,DC2020-25(2020-10)

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

言語モデルに基づく Dockerﬁle コード補完システムの提案
華山 魁生†

柗本 真佑†

楠本 真二†† 大阪大学大学院情報科学研究科 〒 565–0871 大阪府吹田市山田丘 1–5
E-mail: †{k-hanaym,shinsuke,kusumoto}@ist.osaka-u.ac.jp
あらまし コスト削減や計算資源の有効活用を目的として，1 台の物理サーバ上に複数の仮想サーバ（コンテナ）を構築するコンテナ型仮想化が広く利用されている．本研究の対象は，コンテナ型仮想化技術でデファクトスタンダードとなっている，Docker と呼ばれるプラットフォームにある．Docker では，スクリプトを記述し Dockerﬁle と呼ばれるファイルを作成することで，コンテナの構築を行う．インフラ構成を計算機が解読可能なファイルにより管理することで，ヒューマンエラーの防止や管理の自動化を行えるほか，従来のソフトウェア開発で得られた知見をインフラ構成に応用できる．しかし，このような比較的新しい技術においては，開発支援や静的解析など研究が未熟な領域が存在する．本研究ではコード補完に着目し，Dockerﬁle 作成を支援するシステムの構築を目指す．提案を実現するため事前に収集したデータセットを用いて機械学習を行い，言語モデルを作成し，コード補完システム Humpback を作成した．
さらに，推薦精度向上を目指し，Docker 固有の問題を解決するための手法を導入した．評価実験の結果，Humpback
は平均で 93.0%という高い推薦精度を持つことが示された．
キーワード

Docker，コード補完，言語モデル，機械学習，LSTM

本研究の貢献は以下の通りである．

1. は じ め に（ 1 ） コード補完システムの実現に向けた Docker の課題

コスト削減や計算資源の有効活用を目的として，サーバ仮想点を整理した．Docker のベースイメージでは，コンテナ作成化技術が広く利用されている．仮想化には様々な方法があるが，の基となる Linux ディストリビューションを指定するため，

近年はコンテナ型仮想化が主流となっている [1]．コンテナ型

Dockerﬁle の内容はベースイメージによって大きく異なる．そ仮想化では，ホスト OS 上に論理的な区画（コンテナ）を作成の違いを考慮してコード補完を行わなければ，良い精度は望め

し，独立した環境を提供する．Docker [2] はコンテナ型仮想化ない（2. 3 節）．

でデファクトスタンダードとなっている技術であり，IT 企業の（ 2 ） 上記の課題点に対する解決策を示した．Docker 固有の87%以上が Docker を利用しているほか，様々な OSS コミュニ

課題点を解決するため，予測を行うための言語モデルを Docker-

ティでも採用されている [3] [4]．

ﬁle のベースイメージによって変更する，モデルスイッチングとDocker におけるコンテナは，Dockerﬁle と呼ばれるファイルいう手法を導入した．本研究では，Dockerﬁle の内容を時系列に手続き的な命令を書き連ねて構成される．このように，インデータとして扱い，コード補完システムを実現している．なお，

フラ構成を計算機が解読可能なファイルを通して行うプロセス

言語モデルの生成には Long Short-Term Memory (LSTM) [10] をを Infrastructure-as-Code (IaC) と呼ぶ [5]．IaC の活用によりイ使用した (3. 2 節)．

ンフラ構成をアプリケーションコードと同等に管理できるため，（ 3 ） Dockerﬁle に 特 化 し た 新 た な コ ー ド 補 完 シ ス テ ム

スケーリングと監視の自動化を行えるだけでなく，ソフトウェ

Humpback を実装した．図 1 は Humpback のスクリーンショッ

ア開発で培われてきた知見をインフラ構成に導入できる [6]．しトである．Humpback はオンラインエディタとして実装されかし，IaC は比較的新しい技術分野であり，開発支援や静的解ており，ブラウザからすぐに使用できる．1 予測単語は瞬時に析など研究がまだ未熟な領域も存在する [7]．

提示されるため，開発者は開発速度を落とすことなく快適に

本研究ではそのような技術領域の中でも，コード補完に着目

Humpback を活用できる．評価実験の結果，Humpback の推薦した．コード補完とは，文字列の入力中に次の字句を推測し補精度は平均で 93.0%と非常に高く，Dockerﬁle の開発支援にお完候補のリストを表示する機能であり，ソフトウェア開発で頻いて有用であると示された．また，我々の導入した手法が精度繁に用いられる [8] [9]. Docker のような発展途上の技術に特化向上に有効であることも確認した (4. 4 節)．

したコード補完システムを提供することで，ヒューマンエラーの低減だけでなく，事前収集した Dockerﬁle の統計処理による過去の知見の再利用にも繋がると考えた．

（注 1）：https://sdl.ist.osaka-u.ac.jp/˜k-hanaym/humpback/- 19 -—1—
This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©2020 by IEICE

様々な OSS コミュニティでも採用されている [3] [4]．

Docker におけるコンテナはコマンドを毎回実行するだけでな
く，Dockerﬁle と呼ばれるファイルを作成することでも構築できる．Dockerﬁle を作成しコンテナの構成情報を手続き的な命令を通して設定することで，再現性のあるビルドを可能にしている [16]．このように，ソフトウェアシステムのテストやデプロイを行う環境をスクリプトで設定し，自動化するプロセスを

Infrastructure-as-Code (IaC) と呼ぶ [5]．インフラ構成をアプリ
ケーションコードと同じように管理できるため，ヒューマンエ
ラーの防止やスケーリングと監視の自動化だけでなく，ソフト
ウェア開発で培ったノウハウの応用が可能となる [6]．その特徴から，近年は実務者と研究者ともに IaC への興味関心が高まっ

図 1: Humpback のスクリーンショットている [17] [18]．
しかし，注目の高まりとは反対に，IaC に関する研究には未

2. 背

景

熟な領域が存在する [7]．既存研究も少なく，さらにそれらの大部分は IaC 自体の手法を実装したり拡張したりするツールの提2. 1 コード補完
コード補完とは，文字列の入力中に次の字句を推測し，ポップアップを使用して補完候補のリストを表示する機能である．
開発者はそのリストから入力値を選択することで，誤字脱字な案をしているに過ぎない．すなわち開発支援や静的解析などの未開拓な技術領域においては，ソフトウェア工学で培った知識を IaC に活かす余地があると言える．

2. 3 IaC におけるコード補完に向けた課題

どの一般的なエラーを削減できる．コード補完を利用するその他の利点として，より長く記述的な名前を変数や関数などに付与できるようになることが挙げられる．長い名前を付与するとプログラム理解やバグの削減に効果が期待できる [11] 一方，それらを手動で入力するのは煩わしく間違いも起きやすい．しかし，コード補完を使用した入力処理の自動化により，それらの問題が解消される．ソフトウェア開発において，開発者はコー
ド補完を頻繁に利用しており [8]，その回数は 1 分間に数回にも及ぶことが知られている [9]．
しかし，伝統的なコード補完では全ての補完候補を表示するため，開発者が非常に長いリストの中から入力値を適切に選ばなくてはならない．この課題を解決するために，多くのインテリジェ
ントコード補完が提案されている [12] [13] [14] [15]．N-gram のような統計的言語モデル，Best Matching Neighbor (BMN) や

Recurrent Neural Network (RNN) などは，インテリジェントコー

前節で述べた技術領域の中で，本研究ではコード補完に着目した．Docker 固有のコード補完システムを構築する上で考慮すべき課題として，ベースイメージの違いがある．ベースイメー
ジとは，コンテナを作成する基となるイメージファイルであり，Dockerﬁle の中で FROM 命令によって指定する．Linux ディスト
リビューションがここで決定されるため，どのベースイメージを指定するかによって Dockerﬁle の内容が大きく異なる．また，Dockerﬁle は入れ子構造を持っており，上位の構文に入れ子になった状態で埋め込み言語（主に bash）が記述される [1]．例えばベースイメージに Ubuntu を指定した場合は，コンテナ内でコマンドを実行する RUN 命令の中で apt-get コマンドを使用
し，CentOS を指定した場合は yum コマンドを使用するといった具合である．そのためベースイメージの違いを考慮しなければ，高い精度でのコード補完は難しいと言える．

3. コード補完システム：Humpback

ド補完システムを構築するのに高い性能を発揮してきた．言語
モデルは長さ m の単語列 w が与えられたとき，その生起確率

3. 1 システムの概要

P(w1, ..., wm ) を与える．異なる単語に対してこの生起確率を算出することで，相対的な尤度を得られる．そしてインテリジェ
ントコード補完は文脈を考慮し，言語モデルを用いて予測単語
から可能性のある単語を絞り込むことで，従来のコード補完よりも効果的に開発者の生産性を向上できる．

本研究では，Dockerﬁle に特化したコード補完システムを提案する．この提案を実現するため，コード補完システム Humpbackの実装を行った．既存研究におけるコード補完システムの実装には様々な手法が用いられているが，本研究では機械学習による手法を採用している．事前に収集した Dockerﬁle を統計処理

2. 2 Docker，Infrastructure-as-Code とその課題
Docker は，アプリケーションを開発・出荷・実行するためのオープンプラットフォームである [2]．コンテナを用いた OS
レベルの仮想化によりアプリケーションを開発・実行環境からし，文脈を考慮した予測を行うことで，過去の知見を再利用できる．また，2. 3 節で述べたベースイメージの違いによる問題を解決するため，モデルスイッチングという手法を考案した．

3. 2 方 法 論

隔離し，アプリケーションの素早い提供や，可搬性の向上を可能とする．その性質から Docker の人気は急速に高まっており，
現在 Docker はコンテナ型仮想化でデファクトスタンダードと

Humpback の方法論について，学習段階と予測段階に分けて説明する．

なっている．IT 企業の 87%以上が Docker を利用しているほか，- 20 -—2—

…

GitHub API
学習用データDockerfile

ファイル収集

データ加工

LSTM

言語モデル

言語モデル生成

FROM: 1
RUN : 3…

FROM centos

1 25

FROM centos RUN

1 25

3

FROM centos RUN yum

1 25

3 52

1 25 3 52

2. 学習用データを整数値で符号化する

3. 学習用データが固定長になるように
0埋めを行う1. Dockerfileの内容を読み込んだのち
入力 期待する出力の形に加工する

0

0

1 25

0

1 25

3

図 2: 学習段階の全体像

3. 2. 1 学 習 段 階3. 2. 2 予 測 段 階

図 2 は学習段階の全体像を示している．学習段階について，

図 3 は予測段階の全体像を示している．Humpback による予ファイル収集，データ加工，言語モデル生成の順に説明する．

測では，ベースイメージの違いによる問題に対する解決策としファイル収集て，モデルスイッチングという手法を活用している．ベースイ

GitHub API2は，特定のプログラミング言語で記述されたファメージを考慮した補完を行うため，各ベースイメージに対してイルを含む GitHub 上のリポジトリを検索できる．GitHub API

事前学習済みのモデルを用意しておく．そして Humpback は入を用いて Dockerﬁle を含むリポジトリを検索し，人気度を示す

力 Dockerﬁle のベースイメージによって，予測を行うモデルをStar 数の多い順にそれらをプルしたのち Dockerﬁle だけを抽出切り替える．例えば入力 Dockerﬁle のベースイメージが Ubuntu

した．

であれば，ベースイメージが Ubuntu である Dockerﬁle のみでデータ加工学習したモデルを用いて予測を行う．

収集した Dockerﬁle を読み込み，その内容を空白や改行で区しかし，ベースイメージ名から Linux ディストリビューショ

切ってトークン列とする．その際，入力と期待する出力が対にンを判別できない場合もある．例えば openjdk:11-jdk というなるように加工を行う．例えば FROM centos RUN yum というベースイメージ名に Java の開発環境が含まれていると推測で記述があった場合，FROM という入力に対して centos が対応

きるが，どのディストリビューションが使われているかは確認

し，FROM centos という入力に対しては RUN が対応する．次できない．そこで，各ベースイメージにおいて使用されているに，学習器が効率的に学習用データを解釈できるように整数値

ディストリビューションを解析するために，ベースイメージで符号化する．この状態では各データの要素数が異なるため，検出器を作成した．ベースイメージ検出器は入力 Dockerﬁle か

最後に全データの要素数が固定長になるように 0 埋めを行う．

らコンテナを作成したのち，/etc/os-release に記述されて言語モデル生成いるディストリビューションの識別子を確認する．この解析

Humpback では，推薦単語の予測に言語モデルを使用してい結果によって，ディストリビューションが明示されていない

る．言語モデルには N-gram や BMN，RNN といった種類があ場合でも，Humpback がモデルスイッチを実行できるようになるが，本研究では Dockerﬁle の内容を時系列データとみなし，る．なお，openjdk:11-jdk の Linux ディストリビューション

言語モデルの生成に Long Short-Term Memory (LSTM) [10] を用

は Debian GNU/Linux である．

いた．LSTM とは自然言語処理の分野においてよく用いられる

3. 3 データクレンジング

RNN アーキテクチャである．古典的な RNN でも時系列デーより高い精度を持つコード補完システムを構築するために，タを処理できるが，長期の記憶保存ができないという欠点がデータクレンジングを実施した．データクレンジングとは，デーあった．LSTM は RNN の中間層を LSTM ブロックと呼ばれるタの品質を向上させる処理である [19]．データセットに含まれユニットに置き換えることで，長期にわたる依存を持つ学習をる重複やエラー，表記ゆれなど検知し，削除や修正により正規可能としている．

化を行う．本研究では Dockerﬁle 特有のデータクレンジングとして，抽象化，具体化，そしてノイズ除去を行った．図 4 は各
データクレンジングの例を示している．

（注 2）：https://docs.github.com/en/graphql- 21 -—3—

表 1: 評価メトリクスの例

1. apt-get
2. export

Ubuntu正解

3. echo
4. apt-key
5. setDebian
入力データ

予測単語

ランク

ランクの逆数

Top-1 精度

RUN

RUN, FROM, CMD

aptyum, apk, apt

1

1

✓

3

1/3

install update, install, delete2

1/2

ベースイメージ
検出器

学習のソフトウェアライブラリ，Keras4 は高水準のニューラル
ネットワークライブラリ，そして Optuna5 はハイパーパラメー

CentOS
言語モデル

予測単語

タ自動最適化フレームワークである．

図 3: 予測段階の全体像

オンラインエディタの構築には，獲得した言語モデルを展開するための JavaScript ライブラリである TensorFlow.js6 ，および抽象化

FROM ubuntu:18.04
FROM ubuntu@sha256:cbbf2f...

ブラウザで動作するエディタの Ace7 を使用した．図 1 に示す通FROM ubuntu
FROM ubuntu

り，Humpback はブラウザからすぐに使用できる．カラーテー
マの変更やフォントサイズの変更など，通常のエディタと同様

具体化

RUN apt-get install git&& apt-get updateの使用感で開発を行えるが，文字列を入力すると Humpback に

RUN apt-get install git
RUN apt-get update

組み込み済みの言語モデルを利用した予測を行う．その予測単語は瞬時に提示されるため，開発者は開発速度を落とすことな

ノイズ除去

LABEL maintainer=“kaisei<k-hanaym@...>”FROM centos:latest AS server

く快適に Humpback を活用できる．

（削除）
FROM centos:latest

4. 評 価 実 験

図 4: データクレンジングの例

4. 1 評価メトリクス
抽

象

我々の導入した手法が Humpback の推薦精度向上に寄与して化

抽象化の例としては，ベースイメージのタグとダイジェスト

いるか確かめるために，評価実験を行った． Acc(k)（Top-k 精の消去が挙げられる．FROM 命令では，ベースイメージ名の他

度）と Mean Reciprocal Rank (M RR) [21] を精度評価のメトリクにバージョンの指定を行うタグとダイジェストを記述できる．

スとして使用した：

しかし，ベースイメージのバージョンの違いによって使用する
コマンド（apt-get など）に大きな差はないため，その違いをAcc(k) =吸収して学習効率を向上できると考えた．
具体化

Ntop−k
|Q|

(1)

|Q |

M RR =

具体化の例としては，&&の直前の命令への置換が挙げられる．

1 ∑ 1
|Q|
rank i(2)

i=1

RUN 命令内で&&を使用すると，複数のコマンドを一つの RUN 命
令にまとめて記述できる．RUN 命令は実行される度にイメージ

ここで，|Q| はテストデータのサンプル数の合計，Ntop−k はファイルのレイヤが増えるため，可能な限り&&を使用しサイズ|Q| 回の予測における上位 k 位の予測単語のうち正答単語数，増加を抑えることが推奨されている [20]．しかし，学習用デー

そして rank i は i 番目のクエリに対する最初の正答単語の位タの作成という観点では，&&の示している命令を明示すること置を表す． Acc(k) と M RR のいずれにおいても，その値が 1によって，より正確な学習が可能になると考えた．

に近いほど性能が良いことを示す．表 1 に評価メトリクスのノイズ除去例を示す．この場合， Acc(1) は 1/3 ≈ 0.33 であり， M RR はノイズ除去の例としては，学習に不必要な作者名やバージョ(1 + 1/3 + 1/2)/3 = 11/18 ≈ 0.61 である．
4. 2 データセット

ンなどのメタ情報，およびビルドステージの別名指定などの消GitHub API を用いて 21,190 個の Dockerﬁle を収集した．各去が挙げられる．Dockerﬁle では LABEL 命令によってメタ情報を設定したり，AS 命令によって中間イメージに名前を付けられる．しかしこれらの情報は，言語モデルが Dockerﬁle の内容をン数を表 2 の左側に，学習エポック数と学習時間を表 2 の右側に示す．データセットの中で主要なディストリビューション

学習する上では余分であると考え消去した．

3. 4 実Linux ディストリビューションにおける Dockerﬁle 数とバージョは Alpine Linux，Debian GNU/Linux，Ubuntu である．Ubuntu

装Humpback の実装に当たっては，言語モデルの獲得とオンラのデータセットは最も多様なバージョンから構成されており，

インエディタの構築を行った．言語モデルの獲得には 3 つのラ
イブラリおよびフレームワークを活用した．TensorFlow3 は機械（注 4）：https://keras.io/（注 5）：https://preferred.jp/en/projects/optuna/（注 6）：https://www.tensorﬂow.org/js（注 3）：https://www.tensorﬂow.org/（注 7）：https://ace.c9.io/- 22 -—4—

される．正確性と瞬時性を有する Humpback は，開発者の生産

表 2: データセットと学習の詳細
バージョン数 エポック数

性向上に大きく寄与できると考える．

Linux

Dockerﬁle 数

学習時間

Alpine1,105 (5.2%)

9

94

3h00m

Debian17,011 (80.2%)6813d15h12m

実験結果をさらに詳細に分析するため，導入した手法ごとにUbuntu1,497 (7.0%)

19

55

2h30m

その効果に着目する．まず，データクレンジングを行っていな

その他

1,577 (7.4%)

-

-

-

い Nothing モデルに焦点を当てると，他のモデルと比較して精4. 4. 2 導入手法による精度向上

度が非常に低い．Top-1 精度の最低値は 8.7%（Alpine，Docker

1,497 ファイルに 19 個のバージョンが含まれている．その他の構文）であり，これは約 10 回の予測で 1 回しか正解単語を予測

ディストリビューションには Amazon Linux，CentOS，Fedora，

できていないことになる．この結果から，データクレンジング

Oracle Linux Server，VMware Photon OS/Linux が含まれている．

は精度向上に大きく寄与することが確認できる．Dockerﬁle の学習における活性化関数，最適化関数や各層のユニット数と内容は RUN 命令が大半を占めており，データクレンジングを行いったハイパーパラメータは，それぞれ Optuna によって最適う場合は 3. 3 節の具体化で述べた&&の置換処理が頻繁に実行さになるよう調整されている．

れる．その結果，データクレンジングを行った学習用データは

4. 3 実 験 設 計

より具体性のあるものとなり，効果的な学習が出来たものと考3 つの Linux ディストリビューション Alpine，Debian，そしてえられる．
次にモデルスイッチングの効果を確認するため，Normal モデ

Ubuntu を対象として，我々の導入した手法の有無で推薦精度に変化が生じるかを確かめた．比較対象として，データクレンジ

ルと Humpback を比較すると，Humpback では Top-1 精度が最ングとモデルスイッチングのいずれも行わないモデル（Nothing

大で 5.9%改善されている（Ubuntu，Docker 構文）．また，Shellモデル）と，データクレンジングは行うがモデルスイッチング

構文では全体的に精度が引き上げられており，平均で 1.9%改は行わないモデル（Normal モデル）を準備した．Humpback は善されている．モデルスイッチングを活用している Humpback

モデルスイッチングにより複数の言語モデルを使い分けるが，では，Linux ディストリビューションの違いからなるコマンド

Nothing モデルと Normal モデルはともに単一の言語モデルであの差異を予測に反映できる．従って Shell 構文の予測においてる．両モデルの学習用データには，ディストリビューションには，どのディストリビューションに対してもモデルスイッチン

よって区別していない 21,190 個全ての Dockerﬁle を使用した．

グの効果が発揮され，精度向上に繋がったと考えられる．以上

また，RUN 命令内の記述を Shell 構文，それ以外の記述をの結果から，データクレンジングとモデルスイッチングのいずDocker 構文と定義し，それぞれ推薦精度の確認を行った．なれも，Dockerﬁle に特化したコード補完システムを構築する上お，Docker 構文にはコンテナ内にファイルをコピーする COPY

で有用であると示された．

命令や，外部に公開するポートを指定する EXPOSE 命令などが4. 4. 3 ディストリビューションによる違い含まれる．すなわち本実験における評価軸は，データクレンジ

Humpback の精度に注目すると，いずれの構文においてもングとモデルスイッチングの有無，Linux ディストリビューショ

Debian における精度が最も高い．表 2 に示した通り，Debian のン，そして構文の違いである．

Dockerﬁle 数は 17,011 個で全体の約 80%を占める．学習用デー

テスト用データの作成において，まずは収集済みデータセッ

タ数が多ければそれだけ効果的な学習が行えるため，Debian にトから 100 個の Dockerﬁle を抽出し，各 Dockerﬁle においてラおける精度が最も高くなったのは学習用データ数が影響していンダムな位置で正解単語を 1 つ選ぶ．次に，ファイルの先頭るものと考えられる．

から正解単語の手前までの内容を言語モデルに与え，予測単

Alpine と Ubuntu を比較すると，Alpine は構文によって精度語を生成する．そして予測単語を正解単語と照らし合わせて，にそれほど差がない一方，Ubuntu は Docker 構文の精度が 95.8%

Acc(k) と M RR を計算する．ここまでの操作を 1 ラウンドとと非常に高い．しかし両ディストリビューションにおけるデー

し，各評価軸ごとに実験を 10 ラウンド行った．

タ数はほぼ同じである．この点に関しては，Ubuntu では Docker

4. 4 実 験 結 果

構文における記述に似通ったものが多く，学習がより効率的に

4. 4. 1 概行われた結果，データ数がほぼ同じ Alpine よりも高い精度を獲要

表 3 は Top-1 精度 Acc(1) と Top-5 精度 Acc(5)，そして M RRの平均値を示している．ここで，NTG は Nothing モデル，NML

得したと考えられる．現段階では実際にどのような記述が多いのかは確認できていないため，今後の課題としたい．

は Normal モデル，そして HB は Humpback による予測を表して

5. お わ り にいる．太字になっている数値は同カテゴリにおいて最良の値である．表 3 が示す通り，ほぼ全ての評価軸において Humpback，

本研究では，言語モデルに基づく Dockerﬁle に特化したコー

Normal モデル，Nothing モデルの順に高い精度を持つという結ド補完システムを提案し，新たなコード補完システム Humpback

果になった．Humpback の Top-1 精度は平均で 93.0%，最高でを実装した．Humpback はオンラインエディタとして実装され98.3%（Debian，Docker 構文）という非常に高い数値を達成しており，ブラウザからすぐに使用できる．また，予測単語はている．また，3. 4 節でも述べた通り，予測単語は瞬時に提示

瞬時に提示されるため，開発者は開発速度を落とさず快適に- 23 -—5—表 3: 実験結果の平均値
Docker 構文
Top-1 精度

Linux
NTG

NML

Shell 構文Top-5 精度
HB

NTG

NML

Top-1 精度

MRR
HB

NTG

NML

HB

NTG

NML

Top-5 精度
HB

NTG

NML

MRR
HB

NTG

NML

HB

Alpine8.7% 90.1% 90.7% 13.8% 93.0% 93.1% 0.113 0.914 0.918 12.4% 89.2% 91.6% 23.5% 94.2%

Debian

54.9% 96.1% 98.3% 60.1% 96.7% 98.9% 0.576 0.965 0.986 46.6% 89.6% 91.7% 64.7%

92.7% 93.9% 0.548 0.911 0.927

Ubuntu 15.8% 89.9% 95.8% 20.4% 98.9% 99.5% 0.185 0.943 0.976 19.9% 88.9% 90.1% 36.8%

91.3% 91.8% 0.261 0.900 0.909

Humpback を活用できる．Dockerﬁle に特化した問題を解決しHumpback の精度を向上させるため，データクレンジングとモ
デルスイッチングという手法を導入した．評価実験によって，

Humpback は平均 93.0%という高い Top-1 精度を持ち，そして我々の導入した手法が精度向上に貢献していることを確認した．
今後の課題として以下が挙げられる．
改良手法の更なる考案
現状では Humpback の実装にデータクレンジングとモデルス
イッチングを導入しており，これらの手法が Humpback の精度向上に寄与することは 4. 4 節で述べた．しかし Dockerﬁle に固有の課題をさらに考察し，本研究で導入した手法以外にどのような手法を導入すれば精度向上に繋がるか調査する．
データセットの改良本研究における収集済みデータセットには，21,190 個のDockerﬁle が含まれている．4. 4. 3 項に示した通り，現状ではDockerﬁle 数の最も多い Debian における予測が最も高い推薦精度を持つ．そこで Dockerﬁle を追加で収集し，より豊富なデータを用いた学習によって，推薦精度が向上するかを確認したいと考える．また，現状では学習用データとテスト用データを区別せずに使用している．しかし，推薦精度をより正確に算出するため，これらを区別したデータセットで学習および評価を行うことは重要な課題である．
他のコード補完システムとの比較

Humpback は Dockerﬁle に特化したコード補完システムとして実装された．しかし 4. 3 節で述べた通り，評価実験では我々の用意したモデルを対象に比較を行っており，他のコード補完システムとの比較はなされていない．Humpback と既存研究による他のコード補完システムを比較し，推薦精度や推薦速度の点から相対的な評価を行うことは，コード補完システムの性能を確かめる上で重要であると考える．
謝辞

本研究の一部は，日本学術振興会科学研究費補助金基

盤研究（B）（課題番号：18H03222）の助成を得て行われた．
文

献[1] J. Henkel, C. Bird, S.K. Lahiri, and T. Reps, “A dataset of dockerﬁles,”International Working Conference on Mining Software Repositories,
pp.1–5, 2020.
[2] Docker, “Docker overview”. https://docs.docker.com/get-started/
overview/[3] Portworx, “Annual container adoption report,” 2019. https://
portworx.com/wp-content/uploads/2019/05/2019-container-adoptionsurvey.pdf[4] J. Cito, G. Schermann, J.E. Wittern, P. Leitner, S. Zumberi, andH.C. Gall, “An empirical analysis of the docker container ecosystem
on github,” International Working Conference on Mining Software
Repositories, pp.323–333, 2017.

94.1% 0.176 0.914 0.928[5] Y. Jiang and B. Adams, “Co-evolution of infrastructure and sourcecode - an empirical study,” International Working Conference on
Mining Software Repositories, pp.45–55, 2015.
[6] M. Artac, T. Borovssak, E. Di Nitto, M. Guerriero, and D.A. Tamburri, “Devops: Introducing infrastructure-as-code,” International
Conference on Software Engineering Companion, pp.497–498, 2017.
[7] A. Rahman, R. Mahdavi-Hezaveh, and L. Williams, “A systematic
mapping study of infrastructure as code research,” Information and
Software Technology, vol.108, pp.65–77, 2019.
[8] M. Bruch, M. Monperrus, and M. Mezini, “Learning from examples to improve code completion systems,” European Software Engineering Conference and Symposium on the Foundations of Software
Engineering, pp.213–222, 2009.
[9] G.C. Murphy, M. Kersten, and L. Findlater, “How are java software developers using the eclipse ide?,” IEEE Software, vol.23, no.4,
pp.76–83, 2006.
[10] F.A. Gers, J. Schmidhuber, and F. Cummins, “Learning to forget:
Continual prediction with lstm,” IEEE Conference Publication, vol.2,
pp.850–855, 1999.
[11] A. Schankin, A. Berger, D.V. Holt, J.C. Hofmeister, T. Riedel, and M.
Beigl, “Descriptive compound identiﬁer names improve source code
comprehension,” International Conference on Software Engineering,pp.31–40, 2018.
[12] I. Kuraj and R. Piskac, “Complete completion using types andweights,” ACM SIGPLAN Notices, vol.48, pp.27–38, 2013.
[13] V. Raychev, M. Vechev, and E. Yahav, “Code completion with statistical language models,” ACM SIGPLAN Notices, vol.49, no.6,
pp.419–428, 2014.
[14] S. Proksch, J. Lerch, and M. Mezini, “Intelligent code completion
with bayesian networks,” ACM Transactions on Software Engineering and Methodology, vol.25, no.1, pp.1–31, 2015.
[15] A. Svyatkovskiy, S. Fu, Y. Zhao, and N. Sundaresan, “Pythia:
Ai-assisted code completion system,” International Conference on
Knowledge Discovery and Data Mining, pp.2727–2735, 2019.
[16] Y. Zhang, B. Vasilescu, H. Wang, and V. Filkov, “One size does not
ﬁt all: An empirical study of containerized continuous deployment
workﬂows,” ACM Joint Meeting on European Software Engineering
Conference and Symposium on the Foundations of Software Engineering, pp.295–306, 2018.
[17] T. Sharma, M. Fragkoulis, and D. Spinellis, “Does your conﬁguration
code smell?,” International Working Conference on Mining Software
Repositories, pp.189–200, 2016.
[18] C. Parnin, E. Helms, C. Atlee, H. Boughton, M. Ghattas, A. Glover, J.
Holman, J. Micco, B. Murphy, T. Savor, M. Stumm, S. Whitaker, and
L. Williams, “The top 10 adages in continuous deployment,” IEEE
Software, vol.34, no.3, pp.86–95, 2017.
[19] S. Wu, “A review on coarse warranty data and analysis,” Reliability
Engineering and System Safety, vol.114, no.1, pp.1–11, jun 2013.
[20] Docker, “Best practices for writing dockerﬁles”. https://
docs.docker.com/develop/develop-images/dockerﬁle_best-practices/[21] D.R. Radev, H. Qi, H. Wu, and W. Fan, “Evaluating web-based question answering systems,” International Conference on Language Resources and Evaluation, pp.1153–1156, 2002.

- 24 -—6—