1. 日本ソフトウェア科学会 第 35 回大会 (2018 年度) 講演論文集
型チェックのアノテーションによる保守・運用の改善
橋本 順之1
機械学習のソフトウェアの保守運用の効率化のため API や関数の イン
ターフェースのチェックをし，レビューしやすいコードにす るこ とが
必要である．しかし，行列やテンソルの型や次元の検証は難 しい とい
う問題がある．本提案は関数やブロック単位で検証可能なイ ンタ ーフ
ェースのコードを追加し，問題の改善を行う．
1 本ポジションペーパーの目的
機械学習ソフトウェアの検証は難しく保守運用を困難にしている状況を考察し ，問 題
を確認する．問題の改善のために API や関数のインターフェースのチェックを し ，レビ
ューしやすいコードにすることが必要である．しかし，行列やテンソルの型や 次元 の検
証は難しいという問題がある．本提案は関数やブロック単位で検証可能なイン ター フェ
ースのコードを追加し，問題の改善する行うことを目的としている．
2 機械学習ソフトウェアの保守と運用の問題の確認
機械学習ソフトウェアは研究目的やアルゴリズムの開発に重点を置いているた め ，開
発速度を優先し動的型付け言語が好まれる傾向がある．特に深層学習ではその 傾向 は顕
著である．
静的型付け言語は動的型付け言語に比べコンパイルに時間がかかる傾向があり ，コ ー
ディングと実行の繰り返しを頻繁に行い開発するケースでは動的型付け言語の ほう が優
位であろうと推測される．開発者が完全に利用しているライブラリやコードを 理解 して
いる限りにおいてこの利点は強調される．
一方保守運用では状況は変わる．運用は日々同じソフトを動作させ，機械的な 故障 や
平常の時よりたまたま多いデータや不正なデータがくることにより，期待する 動作 をし
ない場合に，問題の原因を切り分け，一次対応のため問題を一時的に手作業で 取り 除き
ソフトを再実行をするなど，その場限りの対処を行い，その後，恒久対応とし て不 具合
を修正する．
保守はソフトの機能の向上，セキュリティ上の要件，ハードウェアや OS の切 り替 え
の必要性により，利用するライブラリや処理系のバージョンをあげたり，その 結果 本来
の機能が動作しない場合の修正や作業である．その作業の前後で同じ動作をす るこ とが
期待されるが，関数名の変更や仕様そのものの変更があり，実際にはうまくい かな いの
で，不整合が起こる原因を特定する必要がでてくる．参考文献[2]に Tensorflow のバ
ージョンアップに必要な項目があるが関数の名前の変更や処理系により浮動小 数点 の挙
動の違いもあり容易ではない．しかし，開発時と同様のリソースをかけること がで きな
いので効率的な解決が求めらえる．
保守及び運用で問題の箇所の特定にはデバッグ手法が適用が有効である．デバ ッグ は
問題の種類の特定する．アルゴリズムのバグか，データのバグ（データに本来 予期 して
いないものがある場合），リソースのバグ（メモリリーク）か切り分ける．次 に問 題の
1 Junji Hashimoto, GREE, Inc.

2. 日本ソフトウェア科学会 第 35回大会 (2018 年度) 講演論文集
場所を特定するために分割統治法で問題のコードの場所を特定し，原因を注意 深く 観察
しコードを直して問題が改善するかチェックし，問題の解決を行う．
運用や保守では開発者ではない第 3 者がコードレビューを行うことが多く，変 更の 影
響が把握できるコードが重要である．静的型付け言語では入力と出力のデータ が一 目で
わかるように記述可能であるが，動的型付け言語では関数やドキュメントを読 むだ けで
動作を予測することが困難であり，どのような入出力を期待しているかはコー ドの 中を
読む他はなく、API やインターフェースの検証が困難である。
保守や運用ではデバッグなど問題の特定が容易でレビューしやすいコードが好まれ る ．
動的型付け言語のライブラリや処理系のバージョンアップは困難であり，動的 的型 付け
言語でも Python2から Python3 へのアップデートの例（参考文献[3]）のよ うに 型を
利用することは有用である．
IT シ ス テ ム の ソ フ ト ウ ェ ア で は ク ラ ス を デー タ の 単 位 と す る た め ，Java や
Python(参考文献[4])がもつ型システムによってデータの不整合を検知しや す い が ，
機械学習ソフトウェアは型で簡単に解決できない．機械学習ソフトウェアは行 列や テン
ソルの数値計算を主に行う傾向があるが，静的型付け言語であっても整数や浮 動少 数点
の型のチェックは行えても，行列やテンソルの次元のチェックは行えないため ，学 習の
データやモデルの検証が困難という問題がある．
機械学習のソフトウェアは多数かつ高次元のデータ（ベクトルやテンソル）を 扱う ．
IT システムのソフトウェアと違いフラットなデータ構造であり次元の異なるデ ー タを
扱うことが多く，クラスの中に小さいクラスを多数含むようなデータ構造を機 械学 習へ
の入力のソースとして使うことはない．機械学習のソフトウェアはベクトルや テン ソル
を扱うため型システムで十分なチェックができない．例えば，Java などがも つ型 シス
テムはベクトルの長さをチェックしない．Python では動的型付け言語の利点 を生 かし
て，スカラの通しの演算，ベクトル通しの演算，スカラとベクトル混在の演 算 に 対し
て，”+”や”-”のようなシンプルな演算子を流用できる．開発時にはこの特徴は 簡 素に
アルゴリズムを記述するのに便利なものの意図せぬ記述をした場合に脆弱であ る ．例え
ば，ベクトルとベクトルを足すべき演算で，誤って片方のベクトルにスカラを いれ てし
まっても間違いに気づくことはできない．スカラやベクトルだけでなくテンソ ルと いっ
た高次元のデータでは問題は深刻なものになる．
保守運用だけでなく開発では後の行程ほど費用がかかる．学習のモデルの作成 が数 日
でできたとしても, モデルのトレーニングには数週間かかることもあり，後の 行程 にな
るほど開発の手戻りの時間や費用が大きくなる．検証のコストは上位レイヤー に行 くほ
ど増大する．デバッグのために高速かつ多数のハードウェアを投入するのも限界があ る ．
API やインターフェースの検証が困難なことにより保守運用が困難という問題 に対 し
て，レビュー可能なように関数やインターフェースを記述し修正結果が容易に 妥当 であ
るかどうか容易にチェックできるようにすることが保守運用のために必要である．
3 解決したい問題の確認と解決のための提案
保守運用のために解決したい問題はライブラリと保守対象のコードの次の点である。
● ライブラリ
○ API のバージョンアップによる非互換を機械的にチェックできない．
○ API のインターフェースの仕様が容易にわからない．ドキュメ ント や
コードを精読する他にわからない．
○ ドキュメントとコードの動作の不一致があっても検出できない．

3. 日本ソフトウェア科学会 第 35 回大会 (2018 年度) 講演論文集
● 保守対象のコード
○ コードの関数・ブロック単位でのレビューが難しい．
これらの原因として考えているものは次の点である。
● 動的型付け言語を使用している．
● ブロックや関数の入出力の型が必ずしも記述されていない．
● 行列やテンソルの次元のチェックが難しい．
これらの問題の解決方法として Java 等の型システムより強力な依存型を用い た型 シ
ステムでテンソルの次元を管理する手法(参考文献[5])がある．コンパイル時に テ ンソ
ルの次元も含めて静的に解析でき，ユーザーに明示的に入出力の仕様を記述さ せる こと
を強要でき，型にインターフェースの情報が含まれているため，ドキュメント とコ ード
の動作の不一致の問題が起こりにくい．しかし，この方法では機械学習で使わ れて いる
Python 等の動的型付け言語の資産が利用できないという問題がある．
本提案は型情報チェックするために関数やブロックの実行可能なコメントにア ノテ ー
ションをつけ問題を改善する．コメントにコードを実行可能なコードを埋め込 みテ スト
する手法として doctest[6]があり、これを利用する．doctest はプログラ ムの 本体
とは別に実行できるため高速にテストできる．
検証対象の関数のドキュメントに入出力のアノテーションをつける．実際の関 数の 処
理とは別であるので，学習の計算に悪影をあたえない．下記に Pythonによる サン プル
を記述した．必要であれば使用しているライブラリの関数に対してチェックす ると 効果
的である．
def cnn_model(features,mode,name=None): #関数と入力変数の宣言
"""Model function for CNN. #関数のドキュメント兼テスト
>>> batch = 7
>>> xdat = tf.zeros([batch,784],name="x")
>>> cnn_model({'x':xdat},tf.estimator.ModeKeys.TRAIN,"cnnt") #関数
の実行
<tf.Tensor 'cnnt/BiasAdd:0' shape=(7, 10) dtype=float32> #関数の出
力する期待値データで shape のところで次元がチェックできる．
"""
関数本体が続く．
本手法の意義として，本体の処理と関係なく事前に実行されるために，処理時 間が 短
く，動作に関して矛盾のない関数のドキュメントにもなる．入出力の次元を含 めた 型チ
ェックが可能となる．仕様と実際の動作が乖離しやすく，ドキュメントは保守 され ない
場合も多いが，本手法は実際のビヘイビアがドキュメントになり，不整合は発生しな い ．
保守運用で不具合がある場合にデバッグでは分割統治法のようなものを使いバ グの ある
場所を発見する必要があるが，本手法では処理単位で期待する動作をしている か検 証の
ためのアノテーションを導入できるため，デバッグにも有用である．
4 まとめ

4. 日本ソフトウェア科学会 第 35回大会 (2018 年度) 講演論文集
機械学習のソフトウェアは保守運用において APIや関数のインターフェースの チェ ッ
クをし，レビューしやすいコードにすることが重要である．行列やテンソルの 型や 次元
の検証は難しいことによるチェックが不十分である．本提案は関数やブロック 単位 で検
証可能なインターフェースのコードを追加し，保守運用の改善を行う．
参考文献
[1] 提案実装のサンプル
https://github.com/junjihashimoto/python-simple-template/blob/master/hoge/mnist.py
アクセス日 2018/06/26
[2] Transitioning to TensorFlow 1.0
https://www.tensorflow.org/install/migration
アクセス日 2018/06/26
[3] Static types in Python,oh my(py)!
https://blog.zulip.org/2016/10/13/static-types-in-python-oh-
mypy/
アクセス日 2018/06/26
[4] mypy # (2018/06/26)
http://mypy-lang.org
アクセス日 2018/06/26
[5] Practical Dependent Types in Haskell: Type-Safe Neural Networks
https://blog.jle.im/entry/practical-dependent-types-in-
haskell-1.html
アクセス日 2018/06/26
[6] Test interactive Python examples
https://docs.python.org/2/library/doctest.html
アクセス日 2018/06/26