機械学習における品質保証のチャレンジ〜産学連携による突破への期待
国立情報学研究所

石川冬樹

f-ishikawa@nii.ac.jp / @fyufyu
http://research.nii.ac.jp/~f-ishikawa/
トップエスイーシンポジウム 2018/03

自己紹介国立情報学研究所 准教授
ソフトウェア工学および，先端自律・スマートシステムに関する研究・教育電気通信大学 客員准教授
社会人博士学生の指導（在学中も含め計9名）

産業界向け教育トップエスイー（形式手法，クラウド等）
日科技連SQiP研究会（要求と仕様のエンジニアリング）
電通大ウェブシステムデザイン（クラウド）

興味：要求や仕様、設計に関する様々なモデルを活用した
検証・推論・最適化・自動テスト生成・自己適応など
2018/03/23

f-ishikawa@TopSE Symposium2最近の主な活動
ERATO-MMSDプロジェクト グループ３リーダー
物理世界や確率などの連続値や微分方程式を含み複雑なシステムの検証・品質保証（主に車）形式検証・テスト自動生成・最適化・機械学習などの技術を適宜活用・併用する実用的検証手法の追求

機械学習（や広くAI）を含むシステムの品質保証
コミュニティ活動，概念や技術の整理
検証・品質保証のための具体的な技術の研究

形式手法における工学的支援・応用
形式仕様の段階的詳細化における保守や再利用
IoTプラットフォームにおける自己適応機構
2018/03/23

f-ishikawa@TopSE Symposium3

AI・機械学習に関するコミュニティ活動
日本ソフトウェア科学会 機械学習工学研究会 主査
2018年4月から（3月までは「有志一同」での活動）
5/17：キックオフシンポジウム（一橋講堂）
7月：合宿形式ワークショップ（三浦半島）
https://sites.google.com/view/sig-mlse/

AIプロダクト品質保証コンソーシアム
副運営委員長ガイドラインや保証レベルの策定など
来週プレスリリース予定
4月活動開始（月例）http://www.qa4ai.jp/
2018/03/23

f-ishikawa@TopSE Symposium

4イメージをもつための事例

2018/03/23

f-ishikawa@TopSE Symposium

5

はじめに
ソフトウェアシステムの「品質」
残念ながら個人・組織・社会に損害をもたらす問題も一例：2017/09/28

多々起きてしまっているとはいえ技術的な進歩・累積も大きい

機械学習あるいはAIを用いたシステムは何が違うのか？？

[ https://www.standard.co.uk/news/world/passengersface-chaos-after-airport-checkin-systems-crash-acrossglobe-a3645816.html ]2018/03/23

f-ishikawa@TopSE Symposium6いつかあるかもしれない社会的大事件
2016年のテスラ自動運転車の事故

ここが機械学習テスラの発表： 「まぶしい空に対してトレーラーの白い側面を認識できず」（「運転者すら」ともある）[ https://www.tesla.com/jp/blog/tragic-loss ]2017年11月の調査報告での論点に上記は全くなく，「そもそも自動運転の対象外状況だが運転者が長らく操作していない」という過信や，アラートの効力が中心[ https://dms.ntsb.gov/pubdms/search/hitlist.cfm?docketID=59989 ][ http://www.dailymail.co.uk/news/article-3677101/Tesla-toldregulators-fatal-Autopilot-crash-nine-days-happened.html ]2018/03/23

f-ishikawa@TopSE Symposium

7

その２（現時点では仮情報）
Uberの自動運転車（試験運転中）による死亡事故
数日前の事故なので，調査詳細を待たずに，何かの判断や結論などは出さないで下さい暗がりから突然道路を横断する歩行者
「人間の運転手だろうが，これは避けられないのでは」（レーダー搭載有無は不明）[ https://headlines.yahoo.co.jp/hl?a=20180322-00000037-zdn̲n-sci ][ https://www.recode.net/2018/3/21/17149428/uber-self-driving-fatal-accident-video-tempe-arizona ]車載カメラの映像がそのまま出ているので要注意

2018/03/23

f-ishikawa@TopSE Symposium

8社会的影響の大きな例・技術的限界の例
Googleフォトの画像認識
被写体の自動タグ付け機能
黒人を「ゴリラ」とタグ付け
2年経って本質的には直せていない（ゴリラを禁止ワード扱いにして対策）[ https://www.theguardian.com/technology/2015/jul/01/google-sorry-racist-auto-tag-photo-app ][ https://www.theguardian.com/technology/2018/jan/12/google-racism-ban-gorilla-black-people ]2018/03/23

f-ishikawa@TopSE Symposium

9画像認識あれこれ（１）最近のTweetより（Honda SENSING）[ https://twitter.com/̲gyochan̲/status/
938240168078622720 ][ https://twitter.com/Bleu̲kakeru727/status/
937680760491753473 ][ http://www.tenkaippin.co.jp/
注：利用者への注意あり
company.html ]http://www.honda.co.jp/hondasensing/feature/srf/おまけ： Google画像類似検索
ロゴイラスト部のみ切り取って検索「たぶん ”lip” 」といいつつ，デンマーク国旗と（その赤白逆の）イングランド国旗をまず推してくる[ https://www.google.co.jp/imghp ](2017/12/11)（進入禁止標識は出ず）（←これは40位くらい）
2018/03/23

f-ishikawa@TopSE Symposium

10画像認識あれこれ（２）Deep Learningに関する論文より有名な例「パンダ」が「テナガザル」に[ Goodfellow et al., Explaining andHarnessing Adversarial Examples, 2015 ][ Huang et al., Safety Verification of Deep Neural Networks, 2017 ]2018/03/23

f-ishikawa@TopSE Symposium

11訓練データに関する例
Twitter Botによる（ユーザを真似た結果の）不適切発言[ https://www.nytimes.com/2016/03/25/technology/microsoft-created-a-twitter-bot-tolearn-from-users-it-quickly-became-a-racist-jerk.html ]2018/03/23

f-ishikawa@TopSE Symposium

12要求と不具合・運用について考える例[ https://twitter.com/RapidUTL/
status/932189705088598017/photo/1 ](2017/11/19)「あら」の扱いが修正？？
“Fish Soup”になる
わけではない？
[ https://translate.google.co.jp/ ](2017/12/11, 2018/3/21)

以下で同時期（11月中旬）に話題になったような「他の変なもの」も挙動が変わっている？
https://togetter.com/li/1173236
2018/03/23

f-ishikawa@TopSE Symposium

13後半の例題チョイスは遊びすぎましたでも「似たような」技術で，皆さんビジネスや実世界の制御やるのですよね？
物体認識に基づく自動運転
音声認識に基づくAIスピーカー・AI家電など
商品の売上げ予測に基づく生産・発注制御など
バグ予測や工数予測に基づくプロジェクト管理判断など
・・・（「あら汁」で損害賠償請求されることはないだろうが）皆さんのシステムではどう「品質」に向き合っていく？
2018/03/23

f-ishikawa@TopSE Symposium14何を考えますか？
これらすべて「バグ」か？潰さなければならないのか？
そもそも潰せるものなのか？それとも技術的限界？
どうやってこれらに気づくのか？他に対処すべき「同種」や「類似」の状況は列挙できるのか？どうやって？
そもそも何を持って「品質保証」「完成」とするのか？
「仕様」は何なのか？事前に見積・合意できるのか？
修正内容をどう決めてどれだけの頻度で更新するのか？
顧客やユーザには何をどうやって説明するのか？
こんな挙動の原因を把握したり，予測し踏まえてテストしたりできるのか？どうやって？開発者ならわかるものなのか？外部品質保証者は何ができるのか？
 ・・・
2018/03/23

f-ishikawa@TopSE Symposium

15

さらに・・・保守もこれまでよりさらに難しい従来のソフトウェアとはだいぶ性質が異なる「技術的負債」の存在

Googleでの経験から14個の負債を紹介
けっこう刺激的なタイトル[Sculley et al., Machine Learning: The High-Interest
Credit Card of Technical Debt, 2014]

品質の観点・指標やその担保施策が大きく異なる
CASE： Changing Anything Changes Everything（コードではなく）データに対する依存性分析や保守・管理などのエンジニアリング
統計のパラドックス，フィードバックループの影響など
固有の留意点「何とかVer. 1.0リリース」は借金の始まり・・・
2018/03/23

f-ishikawa@TopSE Symposium

16本質的な違い（１）：実世界アプリケーション

2018/03/23

f-ishikawa@TopSE Symposium

17「システムが何をするか」のそもそも
Zave/Jacksonのモデル

S, E

World (Environment)

R

R

E

MachineS

マシン（開発の成果物）の仕様 S は，
要求 R を満たす[Zave et al., Four Dark Corners of Requirements Engineering, 1997]

例：R• enter 発生回数 ≦ pay 発生回数

S

• pay の発生を検知したら，unlock する• push の発生を検知したら， lock する[ http://www.fujitaka.com/ ]2018/03/23

f-ishikawa@TopSE Symposium

18

「システムが何をするか」のそもそも
Zave/Jacksonのモデル

S, E

World (Environment)

R

R

E

MachineS

マシン（開発の成果物）の仕様 S は，想定環境（ドメインの性質） E の下で，要求 R を満たす
[Zave et al., Four Dark Corners of Requirements Engineering, 1997]

例：[ http://www.fujitaka.com/ ]2018/03/23

R• enter 発生回数 ≦ pay 発生回数

S

• pay の発生を検知したら，unlock する• push の発生を検知したら， lock するE• push と enter は交互にしか起きないと仮定• lock が起きてから unlock が起きるまではpush は起こせないと仮定
f-ishikawa@TopSE Symposium

19

消える境界先の例は古典的なもの（20年前）
しかし，ソフトウェアづくりにおいて，そこまで実世界における真の R と向きあっていなかったかも

先の例では，その気になれば，V&Vは可能

SとEがRに対して十分であるかの正当性検証
Eの仮定の下考えることが現実的かの妥当性確認

World (Environment)R
2018/03/23

E

f-ishikawa@TopSE Symposium

MachineS
20

消える境界実世界に踏み込むCPS，IoT（自動運転が象徴的）
しかし，ソフトウェアづくりにおいて，そこまで実世界における真の R と向きあっていなかったかも

ソフトウェア制御の範囲（Sの範囲）が広がり，
実世界における真のRを直接扱うことが可能に・必要に先の例では，その気になれば，V&Vは可能

SとEがRに対して十分であるかの正当性検証
Eの仮定の下考えることが現実的かの妥当性確認
RとEにおいて「扱う範囲の境界」が不明確で，さらにRやEの完全・網羅的な把握や予測は不可能
World (Environment)R
2018/03/23

E

f-ishikawa@TopSE Symposium

MachineS
21

本質的な違い（２）：振る舞いの帰納的な決定

2018/03/23

f-ishikawa@TopSE Symposium

22参考：演繹と帰納演繹
諸前提から論理の規則にしたがって必然的に結論を導き出すこと。普通、一般的原理から特殊な原理や事実を導くことをいう。

帰納個々の特殊な事実や命題の集まりからそこに共通する性
質や関係を取り出し、一般的な命題や法則を導き出すこと。

[大辞林（三省堂） via https://kotobank.jp/ ]2018/03/23

f-ishikawa@TopSE Symposium23演繹的システム開発と帰納的システム開発
演繹的システム開発（従来）計算や判断を行うための知識・規則（モデル・アルゴリズム）を，人が決めてプログラムという形で書き下す

帰納的システム開発（というか機械学習）
計算や判断を行うための知識・規則（モデル・アルゴリズム）を訓練データから獲得し生成する
それを行うプログラムを人が書き下す※ 広く「AI」というだけだとどちらの作り方もありうる
が，後者の場合，開発・運用・品質保証が大きく変わる

2018/03/23

f-ishikawa@TopSE Symposium

24例（PFN丸山さん資料より）
同じ場所で摂氏・華氏両方を計ることを大量に行うという手段でも，「摂氏・華氏変換」の実装はできる（嬉しいかどうかはともかく）[丸山宏，PPL 2018，演繹から帰納へ〜新しいシステム開発パラダイム〜
https://www.slideshare.net/pfi/20180305ppl2018 ]2018/03/23

f-ishikawa@TopSE Symposium

25

別の例

この線引きを訓練データから作るイメージ
テナガザル

0 245 231

20 121 24

122 101 0

211 54 42

12 222 90

88 79 114

24 56 78

98 199 1466 31 198

35 24 210

20 121 24

122 81 20

211 54 42

12 222 90

88 79 116

24 36 98

98 181 31

66 31 198

パンダ

0 245 231

0 245 231

20 121 24

122 101 0

211 54 42

12 222 90

88 79 114

24 56 78

98 199 1466 31 198

0 245 231

20 121 24

122 101 0

211 54 42

12 222 90

88 79 114

24 56 78

98 199 1466 31 198

20 121 24

122 101 0

211 54 42

12 222 90

88 79 114

24 56 78

98 199 1466 31 198

0 245 231

20 121 24

122 101 0

211 54 42

12 222 90

88 79 114

24 56 78

98 199 1466 31 198

※ 数値データ表現は画像によりもちろん違うはずですが[ http://free-photos.gatag.net/ ]面倒なのでコピペしてしまっています2018/03/23

f-ishikawa@TopSE Symposium

26機械学習（帰納的システム開発）
すごいこと
人が明確に規則として書き出せないことも，訓練データが大量にあれば判断・予測などの計算ができる
 「この画像はパンダの画像だ」
 「本Aを買った人は，きっと本Bにも興味がある」

訓練データを更新していけば，新しいことに対応できる
 今月デビューした芸能人の画像も判別可能に
 ユーザごとのクセがある音声指示も認識可能に※ なぜ最近この点が持ち上げられるようになったのか，
関連してディープラーニングとは何なのか，は省略
2018/03/23

f-ishikawa@TopSE Symposium

27機械学習（帰納的システム開発）
大変なこと
大量かつ「適切な」訓練データが必要 正面写真しか見せなければ，横からの写真を判別できるようにはならない Twitterbotによる暴言の例

訓練データがあればうまくいくとも限らない
訓練データ外のデータでどう振る舞うかは未知何がなぜ起きるのかは前もって説明できず，
後付けで説明することすら難しい・できないことがある パンダとテナガザルの例
 Googleのゴリラの例
2018/03/23

f-ishikawa@TopSE Symposium

28

根本的なスタンスの変化

2018/03/23

f-ishikawa@TopSE Symposium

29

本質的な難しさの要因（の一部）（１）
１．入力・適用状況，および
出力への要件が無数にある
実世界や人の感覚により深く踏み込む
応用事例を扱うデータに基づき
帰納的に部品を構築する

２．絶対的なオラクルがない

３．出力は学習データに強く依存し，出力が得られた理由を
演繹的には説明できない

４．動かすまで挙動や精度，変更影響が十分に予測できない
2018/03/23

f-ishikawa@TopSE Symposium

30

本質的な難しさの要因（の一部）（２）
１．入力・適用状況，および
出力への要件が無数にある

実行時に想定外のことが発生することが原則になる

２．絶対的なオラクルがない

テスト入力を多数用意しても成否判定が困難・高コストで，明らかなコーディングミス等
すら気づかない可能性がある

３．出力は学習データに強く依存し，出力が得られた理由を
演繹的には説明できない

何が実際実現できているのか
把握・説明できず，問題の原因同定・修正も難しい

４．動かすまで挙動や精度，変更影響が十分に予測できない要求の実現可否・実現コストや変更の影響を事前に把握しての分析・意思決定は難しい

2018/03/23

f-ishikawa@TopSE Symposium

31

本質的な難しさの要因（の一部）（３）
実行時に想定外のことが発生することが原則になる
テスト入力を多数用意しても成否判定が困難・高コストで，明らかなコーディングミス等
すら気づかない可能性がある
何が実際実現できているのか
把握・説明できず，問題の原因同定・修正も難しいん？全部「不確かさ」の話じゃないか！
要求と評価指標，
入力，実装，出力が不確か

要求の実現可否・実現コストや変更の影響を事前に把握しての分析・意思決定は難しい
2018/03/23

f-ishikawa@TopSE Symposium

32

自然に必要となるだろうスタンス
実行時に想定外のことが発生することが原則になる
テスト入力を多数用意しても成否判定が困難・高コストで，明らかなコーディングミス等
すら気づかない可能性がある
何が実際実現できているのか
把握・説明できず，問題の原因同定・修正も難しい要求の実現可否・実現コストや変更の影響を事前に把握しての分析・意思決定は難しい
2018/03/23

より上位のシステム全体で失敗の対応策を打つ
実行時に継続的な監視・評価を行いフィードバックするシステムの上位の目的（ユーザ体験や安全性）の観点からフィードバックを得る
疑似オラクルを用意し大量に（ゆえに自動）テストをする
構築過程から部分部分に対し確信が持てる構築方法を用いたり検証手段を設けたりする（想定する性質のアサーション等）
探索的・試験的に仮説・分析・評価を繰り返す

f-ishikawa@TopSE Symposium

33

ヒント

2018/03/23

f-ishikawa@TopSE Symposium34先人のヒントNIPS，ICML等の機械学習系国際会議
特に併設ワークショップの”Reliable Machine Learning in
the Wild”や”ML Systems”など，アルゴリズムよりも実用システム構築上の課題に着眼したもの
Googleなど企業の招待講演が多く参考になる

ソフトウェア工学系国際会議では最近急に
間接的にヒントになりそうなものは昔から：
Models@run.time，疑似オラクルを用いたテスティング，
サーチベースドテスティング，メタモルフィックテス
ティングなどなど

2018/03/23

f-ishikawa@TopSE Symposium

35機械学習コミュニティで出ている原則・指針
機械学習における「技術的負債」（前述）従来のソフトウェアにおけるものに加えて，固有の負債が多数ある難しさとその対策
例： Changing Anything Changes Everything[ Sculley et al., Machine Learning: The High-Interest Credit Card of Technical Debt, 2014 ]ベストプラクティス集
例： 問題が顕在化しない失敗を見張れ[ Zinkevich, Rules of Machine Learning: Best Practices for ML Engineering, 2016 ]どれだけ監視・テストできているかの評価スコア
例： 個々のfeatureの分布が予想と合っているかどうか[ Breck, Whatʼs your ML Test Score? A rubric for ML production systems, 2016 ]2018/03/23

f-ishikawa@TopSE Symposium36ソフトウェア工学と不確かさModels@run.timeアプローチが代表的要求，仮定・想定や，設計に関する意思決定の論理などのモデルを明示化し，システムが実行時にも活用
現実とモデルのずれを検出・同定しやすく，また意思決定の論理をたどり直して自動設計変更などのフィードバックも可能に
CPSや自己適応に関連するソフトウェア工学研究において2010年代盛んに取り組まれている一つの方向性
ただし帰納的な振る舞いを主眼においてはこなかった
2018/03/23

f-ishikawa@TopSE Symposium

37Model@run.time
Before要求，想定，
設計などの
…
モデル
…
（ときに暗黙） …

想定などを掘り起こしつつ，人の理解により
原因追求
出力やログ
人が解釈し
コードとして表現

After
要求，想定，
設計などのモデル

様々なことがらの結果としての不具合が表出（機械学習だとここで不具合に気づかないかも）
出力やログ

…
…

（明示・形式化）

2018/03/23

実行時

開発時

…
モデルをシステムに持たせる
f-ishikawa@TopSE Symposium……
…

システムが常に想定などを監視，
違反や例外を検出（可能なら自身でモデル・コードを同期しつつ更新）
38

Model@run.time
様々な言葉“Models need to continue to live at run-time and evolve
as changes occur while the software is running”[Baresi et al., The Disappearing Boundary Between Development-time and Run-time, 2010]

“Run-time reasoning over requirements is necessary
where design-time decisions about the requirements
are made on incomplete and uncertain knowledge
about the domain and the stakeholdersʼ goals”[Sawyer et al., Requirements-Aware Systems - A research agenda for RE for self-adaptive systems, 2010]

“a runtime model can be seen as a live development
model”
2018/03/23[Blair et al., Models@Run.Time, 2009]

f-ishikawa@TopSE Symposium39参考になるアプローチ？？（１）（V字モデルなど眺めるよりむしろ・・・）

制御工学におけるフィードバックループ
「自己適応システムのためのソフトウェア工学」の人たちには常識 [ Filieri, Control theory for software engineering: technical briefing, 2016 ]制御したい対象：思い通りにできない不確かなもの
何かの「外乱」の影響がある

ずれを計って制御の仕方に反映[ https://en.wikipedia.org/wiki/Feedback ]2018/03/23

f-ishikawa@TopSE Symposium

40参考になるアプローチ？？（２）（V字モデルなど眺めるよりむしろ・・・ ）例：車におけるエンジン周り監視の「3レベル」
アウディ，ダイムラー，ポルシェ，フォルクスワーゲン
で「差別化要素がない」として標準化

機能
機能の監視

独立した監視[ Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units Ver. 6.0, 2015 ]2018/03/23

f-ishikawa@TopSE Symposium

41機械学習システムの検証・テスティング研究動向

2018/03/23

f-ishikawa@TopSE Symposium42背景技術： メタモルフィックテスティング
メタモルフィックテスティング多数の入力を用いてテストをしたくても，各出力の正しさ（テスト成否）を判定するのが困難または高コスト「入力を変えると出力はこう変わるはず」という関係を検証，既存テストケースから多数のテストケースを生成
入力1

Software Under Test

出力1

これを見てもテスト成否判断が困難
Tに応じた
変換M(T)

ある変換T
入力1ʼ

Software Under Test

出力1ʼ

出力1ʼ
期待値

照らし合わせ例： sin(x) = sin(π - x)
2018/03/23[ Segura et al., A Survey on Metamorphic Testing, 2016 ]f-ishikawa@TopSE Symposium43背景技術： サーチベースドテスティング
サーチベースドテスティング
最適化技術（メタヒューリスティック）を用い， 「欲しいテストケース・テストスイート」を表すスコアを最大化するようテストスイートやテストケースを生成 例：「車が人に最も近づくような危ういテスト」ケースを生成 例：「前バージョンと比べ出力が大きく変わる」入力を発見
 例：「高カバレッジで小さい」回帰テストスイートを生成
テストケース
テストスイートの候補群（第n世代）

淘汰・進化（突然変異・勾配など）
スコア評価

テストケース
テストスイートの候補群（第n+1世代）[ S. Ali et al., Systematic Review of the Application and EmpiricalInvestigation of Search-Based Test Case Generation, 2010 ][ http://www.evosuite.org/ ]2018/03/23

f-ishikawa@TopSE Symposium

44機械学習システムへの応用例
メタモルフィックテスティングの適用
時系列分析で入力に一定の幾何学変換をかけるドローンシステムで地図を回転など変化させる
より分類が難しいコーナーケースを生成する[ Jarman et al., Metamorphic Testing for Adobe Data Analytics Software, 2017 ][ Lindvall et al., Metamorphic Model-based Testing of Autonomous Systems, 2017 ][ 中島,データセット多様性のソフトウェア・テスティング, 2017 ]ディープラーニングのホワイトボックステスト
サーチベースドテスティング
ニューロンのカバレッジを上げるとともに，比較対象の別実装との出力差分を上げるように，テストスイート（テスト入力セット）を最適化[ Pei et al., DeepXplore: Automated Whitebox Testing of Deep Learning Systems, 2017 ]2018/03/23

f-ishikawa@TopSE Symposium

45

他の技術
GAN（Generative Adversarial Networks）
機械学習コミュニティでは盛ん（ここでは軽く）
雑には，品質保証・向上対象の機械学習部品に対して，「敵対的」な機械学習部品をぶつけ，同時に育てる（ 「失敗のさせ方」を学ぶテスターも同時に育てる）[ Goodfellow et al., Generative Adversarial Networks, 2014 ]形式検証技術（SMTソルバー）の応用
画像認識において，「一定範囲の画像操作」を行っても認識結果が変わらないかどうかを網羅的に検証[ Huang et al., Safety Verificationof Deep Neural Networks, 2017 ]2018/03/23

f-ishikawa@TopSE Symposium

46

システムレベルの要求に基づくテスティング
システム全体の要求を踏まえるのが重要なのでは機械学習部品（生成されたモデル）の精度だけむやみに突き詰めても
例： 遠くの物体を誤認識しても衝突には至らないかも
例題：自動ブレーキシステム（人の操作や先行車の位置が入力，「先行車との距離が一定以上ある」ことが要求）
１．完璧な機械学習部品を用いると要求を満たすが，常に失敗する機械学習部品を使うとそうならないような
入力パラメータ領域を絞り込む
２．その領域に限定して機械学習部品が誤認識するような画像を探す
３．その画像を用い要求を満たさないケースを探す[ Dreossi et al., Compositional Falsification of Cyber-Physical Systems
with Machine Learning Components, 2017 ]2018/03/23

f-ishikawa@TopSE Symposium

47

テスティング技術マップ（更新中）
対象

学習・推論
コンポーネントシステム

モデル

テストアプローチ
系統的網羅的特定観点でのあぶり出し

テストデータ量増加
仮説確認

2018/03/23

画像生成による系統的テスト[Dreossi@MLWild_ICML’17]
ニューロンカバレッジ[PEI@SOSP’17]
疑似オラクルとの差異最大化[PEI@SOSP’17]

システムレベルオラクルに基づくモデルのテスト[Dreossi@NFM’17]

SVMの分類困難なデータの生成[中島@JSSST’17]

故障学習器のメタモルフィック
テスティング[Murphy’08]

深層学習のメタモルフィック
テスティング[Ding@MET’17]

Adobe Anomaly detectionのメタモルフィック
テスティング[Jarman@MET’17]

f-ishikawa@TopSE Symposium

ドローン制御のメタモルフィック
テスティング[Lindvall@MET’17]

48

おわりに

2018/03/23

f-ishikawa@TopSE Symposium49問題はたくさんMLSE meet-up #1 での議論をまとめた結果[ 吉岡ら, SEチャレンジ: 機械学習 x ソフトウェア工学 = 機械学習工学, 2017 ]2018/03/23

f-ishikawa@TopSE Symposium

50トップエスイーで起きてきたと思うこと（１）企業では学びにくいことを学び試していただいた例：形式手法（理論や一般論をおさえないといけない部
分もあり，教える側になるのはなかなか難しい？）先端の論文を調べ，先端手法を試していただいた例：サーチベースドテスティング

目の前の問題から離れ，現状にとらわれず，あるべき手法やプロセスを検討していただいた例：「5年後も今のやり方，では無理，それでは？」

2018/03/23

f-ishikawa@TopSE Symposium

51トップエスイーで起きてきたと思うこと（２）普段よりも広い視点から，厳しい意見も受けて，方向性の検討や評価をしっかりできた講師となる人はたいてい活動範囲がとても広く，特定の「常識」「しがらみ」にとらわれたりしていない人がほとんど

会社の外での情報収集や議論が当たり前になった
という人もいる（日々の仕事にまた埋もれてしまう人もいる）

2018/03/23

f-ishikawa@TopSE Symposium

52

企業の皆さんだけでいいんじゃない？
別に企業だからできないこと，ってないはず形式手法ものすごく詳しい企業の方はたくさんいる今日出したテストの話など，私より速くフォローしている人ももちろんいる前述のことは当たり前な企業さんもあるGoogleは「開発と研究を離さず一体化」
これが機械学習の難しさに効いているという話
研究チームが出したものを，開発チームにとって「ブラックボックス」にしないなど[ Sculley et al., Machine Learning: The High-Interest Credit Card of Technical Debt, 2014 ][ Spector et al., Googleʼs hybrid approach to research, 2012 ]2018/03/23

f-ishikawa@TopSE Symposium

53

とはいえ・・・
現状「学」にも頼っていただけている点はとても嬉しく思い，頑張っていますトップエスイー13期生過去最大の受講生数

きっと「学」が得意なことがある先々のことを自由に考え，あるべき姿を描いている？
概念整理や，知見の一般化，それらを目的とした実験などをすることが（企業よりも）「仕事」になる？
一見離れた（目の前の問題には出て来ない）昔の思想や技術などをおさえている？
中立の立場で相談を受けられる？

機械学習やAIについてもきっと活きる！
2018/03/23

f-ishikawa@TopSE Symposium

54

おわりに
※ 改めて機械学習（AI）の話

今までソフトウェア屋さんがサボってきた・やりきれてなかったことが突きつけられているのかも画面の外の実世界での意義や安全性，ユーザの感性的な満足の追求や評価，探索的・試験的な投資や問題解決，
仮説と検証による科学的な判断や評価，常に測定，数学の理解・活用，Correctness-by-Construction，
現実問題の数学的問題（最適化等）への帰着，
実行時検証やテスト自動化（入力生成・疑似オラクル） ，といったことへの本気のパラダイムシフト，・・・

産学で楽しんで切り拓いていきましょう！
2018/03/23

f-ishikawa@TopSE Symposium

55