機械学習を取り入れた組織・サービスにおいて発生しがちな問題と、その解決方法

成長を止めない機械学習のやり方

染谷悠一郎氏（以下、染谷）：ありがとうございます。みなさん、おはようございます。1時間目ということで「成長を止めない機械学習のやり方」というテーマでお話しさせていただきます。

今回、AIのセッションオーナーの方からご紹介いただきましてMANABIYAで発表させていただくことになりました、染谷と申します。

学生時代はコンピューターサイエンスをずっとやっておりました。実は、機械学習ではなく、機械論理学とか形式手法とかそのあたりをずっとやっておりまして、2016年に卒業してクックパッド株式会社に入社して研究開発部に入りました。

今はリサーチエンジニアという肩書きで研究をやっております。リサーチエンジニアとは何ぞや？　という話はこれから少しずつしていくと思います。主にうちはAWSをすごく使っているので、AWSの上で機械学習をやりやすくする基盤を作ったり、あとは一応研究開発にいるので、レシピデータを使って分析、ディープラーニングも少しやっております。

最初に軽くクックパッドの紹介をさせていただきます。クックパッドはご存知いただいている方が多いと思うんですけども、レシピの投稿・検索サービスを運営しております。現在、Webとスマートフォンでレシピ数が280万品以上、国内の月間利用者数で言うと約6,000万人のユーザーに使っていただいています。最近はグローバル化に力を入れてまして、現状の対応言語が22言語、68カ国でうちのサービスがお使いいただけるようになっています。海外の月間利用者数は3,000万人以上という状況です（注：数字はいずれも2017年12月時点のもの）。

一方、クックパッドの研究開発部は、僕が入社して新卒研修を3ヶ月やって、配属が決まる時期の2016年7月にできたんです。なので僕はクックパッド研究開発部の初期メンバーですね。それからハイヤリングもがんばってます。ちょっと古いデータですけど、

例えばAlexaのアプリケーションを作る部隊もいたりしてデータサイエンティストだけではないんですけど、国内の研究開発部には合計18名の人間がいます。海外にもデータを中心に仕事をしている人間が10人ほどいます。

写真で「何の料理か」判定する料理きろく

今日の例示として使うので紹介させていただきたいんですけれども、クックパッドとして深層学習を実際にアプリケーションに取り入れた最初の例として出た……あ、アプリケーションじゃなくてフィーチャーですね。クックパッドの今回のアプリケーションの1フィーチャーとして公開されている、「料理きろく」というものがございます。

これはどういうものかというと、スマートフォンの中のカメラロールの写真の中から料理の写真だけを分類して抜き出して、カレンダー上に配置してくれるというそれだけなんですけども。料理して写真を撮るっていう普段の記録行為をまとめてあげるようなサービスですね。実際、中で画像分類が動いています。

これはオプトイン型なので、使いたいというユーザーの方にだけ使っていただいているんですけど、現在、20万人のユーザーから利用許諾をいただき、使っていただいてます。その中で2,000万枚以上の料理写真が記録されています。たくさんの写真が判定の対象になるんですけど、現在、そのうち料理写真が2,000万枚あります。

研究開発部としては、例えばさっきは「料理か料理じゃないか」に関してだけでしたが、例えば画像からラーメン、チャーハン、その他みたいなレシピの分類をさらに細かくやるとか。

うちはユーザーの方からコンテンツを投稿いただくサービスなので、材料名にしょうゆって書かれていたり、おしょうゆって書かれていたり、漢字で醤油って書かれていたり、すごく表記ゆれがあるんですね。あとは、うちのサービスを使っていただいていたらわかると思うんですけど、醤油と砂糖の左側に星が書いてあって、「星を混ぜる」とかステップに書いてあったりします。こういった表記ゆれを解消したいときに、データを使ってなんとかできないかやってみたりとか。

あとはユーザーさんから直接来るフィードバックを自動でタグ付けするとか。「このサービスに関するフィードバックです」とか、「ポジティブです」「ネガティブです」とかいうのもやったりしてます。紹介は以上です。

機械学習の課題を共有して分析していく

今回MANABIYAに登壇させていただくということで、僕はMANABIYAのホームページを見たわけですけど、みなさん、これ読みましたか？　これはMANABIYAのスローガン的なところに書いてあったんですけど、「質問まではいかないが気になっていること、回答を知りたいがなかなか知る機会がなかったことを日本中から集めて、今日、明日を通して解決策を見出して知恵を生み出すといったことをやりたい」と言っていますね。

僕なりに考えた結果としては、疑問を日本中から集めるということは、要は「実はこういう問題があるんだよ」という話をして、発見されていない課題をまずここで共有するわけですね。そのうえで「じゃあ、こうすべきだ」っていうところまではいかなくても、「例えばこういうことができるよね」と解決策をいくつか列挙して、それぞれ「こういう解決策はこういう問題があるよね」と分析して1つの本当の解決策に向かうための礎にするといったコンセプトなのかなと思ったわけです。

一方これは僕のセッションの説明文なんですけど、一応、最初に考えたときにそのコンセプトに則っています。

まず課題の共有をします。まず、実際に機械学習をやっている組織において「プロジェクトがスピードアップしない」とか「どうしても機械学習を使ったアプリケーションが出せません」といった課題があるとしましょう。そのうえで原因をいろいろ考えていくんですね。

「こうだから機械学習のアプリケーションができない」「こうだから機械学習のプロジェクトが加速しない」というところを考えていって、それを分析していきます。というわけでタイトルは、「成長を止めない機械学習のやり方」です。今回は機械学習に取り組む現場、とくにうちみたいなサービス開発の現場にちょっと寄っちゃうんですけど、そういったところで機械学習をやるときの課題を見つけて、分析します。

人工知能に寄せられる期待の高まり

アジェンダはこんな感じですね。

ちょっと前半しゃべりすぎたので、少しかいつまんでいきます。はじめに、「人工知能ブームと幻滅期」。聞いたことのある人はたくさんいると思うんですけど、現在我々は第3次人工知能ブームの真ん中にいるわけです。いろいろな説はあるんですけど、よく言われるのは、画像分類系の学術領域においてすごいブレイクスルーがあって、それをきっかけに、事業でも機械学習、深層学習を使おうぜという話がすごく出てきた。

ただし、流行ったきっかけ自体は深層学習なんですけど、それに巻き込まれて機械学習がものすごく流行ってきてるといったかたちになってます。機械学習、深層学習を応用したいっていう流れがすごくあって、うちみたいなサービス事業も例外じゃないわけですね。みんなが機械学習をやりたいと思っている。この図、見たことある人はいますか？

（会場挙手）

けっこういますね。これは何かと言うと、人々の期待の時系列変化です。左から右に人々の期待値が変化していく。ハイプと言って、過度な期待が寄せられている分野に関する期待のグラフなんですね。Y軸が期待値で、X軸が時間。機械学習が今どこにいるかと言うと、このへんにいるんですよ。

去年の人工知能学会の基調講演で話されていたんですけど、結局、今って機械学習への期待がものすごく膨らんでいて、このあとドスンと落ちる瞬間が来るんじゃないのって言われているわけです。歴史的にもそういう話が何度かあって、今が第3次って言われるのは第1次、第2次が潰れちゃったからですよね。

そういった期待値が上昇している現状で、このあとどうしようかって考えると、現場としてやっていくことは、機械学習を使ってコツコツと価値を創造していくしかないわけです。結局なんでもなかったじゃんってなっちゃうと、幻滅した瞬間の落ち幅がすごいことになっちゃうので。今回はサービス開発現場のクックパッドの現場で得られた知見を中心に、この問題について考えていきたいなと思っています。

サービス開発のときの機械学習の使い方

第1章、成長を止めない機械学習のやり方、組織・チーム編ということで話していきます。テーマはサービス開発と機械学習ですね。先ほども申し上げたとおり、サービス開発の現場でも機械学習を使いたいというニーズがすごく膨らんでいます。うちもすごくやりたいなと思っているんですけど。そもそもサービス開発企業が機械学習を使うっていうのはどういうことなのかを、ちょっと見直してみます。

これは機械学習のワークフローというか、ライフサイクルみたいなキーワードでよく出てくる図を僕がデフォルメして書いてみました。

てっぺんの課題発見から、「こんなことやりたいんだよね」「この数字を最大化したいね」ということを決めてから、持ってるデータを集めて、それを分析して……EDAっていうのは、探索的データ分析みたいなやつですね。

要はグラフにしてみたり、並べてみたりして可視化して分析して、「モデルはこんなものを作りましょう」ということで学習をして、評価して、「これなら本番に出せるね」ってなったら本番に出すと。またフィードバックループがあって、新たな課題を発見してループを回していくというのが機械学習のワークフローだと思います。左の部分が機械学習のモデルを作っているところ。実際に使っているところはあそこなんですね。本番に出ないと使ってることにはなりません。

ちょっと話は飛ぶんですけど、本番にモデルを出すときに、例えば1つの案としてすごくシンプルなモデルのAPIを作って、例えばpredictというendpointが生えていて、そこに画像を投げるとなにかが返ってくるみたいなデプロイ方法を考えたとすると、それに必要なステップはこのくらいあるんですね。

ちょっと聞きなじみがないかもしれないですけど、学習したモデルを持ち出すためにそれをセーブしてダンプして、かたまりの1個のファイルにして、この実行環境を実際に、その実験環境と同じようにモデルが動くような環境を作ってあげて、DockernizeしてAPIサーバーを作ってあげて、Endpointを作って、アプリケーションのサービスの開発の人たちと「このendpointに投げてね」とかコミュニケーションして、実際自分たちの持ってるインフラの環境にインテグレーションすることが必要になります。

機械学習を使うための手間と時間の認識のギャップ

何が言いたいかと言うと、けっこう手間と時間がかかるんです。機械学習を使うには手間と時間がかかる。一方で、これは実際に我々の今現在使っている料理きろくというサービスの中で機械学習が使われている行です。

ある程度抽象化してありますけど、classifierにイメージを投げると、resultが返ってきて、resultが料理だったら何をするというのが、機械学習モデルが真ん中にあって、その周りにコードでロジックが書かれているわけですよね。

これは1個の例なので毎回こうとは限らないんですけど、サービス開発という文脈で機械学習を使おうぜってなったら、機械学習モデルの動作というものは、要はif文と一緒なんですよね。ロジックと一緒なんですよ。この画像が料理の写真だったらこうする、料理の写真じゃなかったらこうするというのを実装するわけなので。今みたいに、サービス開発側から見た機械学習のモデルという存在は1行のコードであるべきなんです。

こういうときに何が起こるかと言うと、例えば、ちょっと字がちっちゃいですけど、こっち（右の絵）はサービス開発の人ですね。こっち（左の絵）はR&Dの人。

サービス開発の人がカレーとラーメンだけじゃなくて麻婆豆腐も分類したいとなったとする。先ほども言ったとおり機械学習の分類というのはコードで書かれたロジックと同等に扱われるので、サービス開発の人の頭の中では麻婆豆腐を加えるには、category=麻婆豆腐を足せばいいじゃんって話なんですね。

カレーだったらカレーのロジック、カレー用のファンクションを動かして、麻婆豆腐だったら麻婆豆腐用のファンクションをこっちで動かす。でも実際にR&Dの頭の中にはさっきのサイクルがあって、またデータに直して麻婆豆腐の写真で何枚かまとめて学習するのかって考えると、ここにスピード感のギャップが生まれるわけです。

カテゴリー1個足すのに何週間もかかるのはサービス側からは許容しづらい。気持ちのうえでの問題もあるんですけど、こういったかたちでサービス開発とモデルの開発・デプロイというところにはギャップが生まれやすいことがわかってきました。じゃあどうすればいいか？　という話です。

ギャップは人員配置の最適化で埋める

どうすればいいかと言いますと、まず単純な話で人材配置の最適化をすりゃいいよっていう話がありますよね。どういうことかと言うと、それぞれサービス開発とR&Dが1人ずつだったらしょうがないんですけど、だいたいチームで動いているので複数の人材が配置されてるわけじゃないですか。時間がかかって困るんだったら、単純な話、こっち（サービス開発）の人がこっち（R&D）に行ってデプロイを手伝ってあげたりすればいいんですよね。

単純な話なんですが、とくにサービス開発に機械学習を使うのは不慣れで、まだやったことないという現場だとそうなりがちです。まずさっきみたいなスピード感のギャップがあるという問題が共有されていないわけです。機械学習とサービス開発の間で「サービス開発のPDCAの流れに機械学習を乗っけるというのはけっこう大変なことなんだぜ」っていうことが共有されてる現場はまだ少ないと思うんですよね。

なので人材配置を最適化すればいいんですけど、根本問題として機械学習からサービス開発において価値を見出すことにおいては、それぞれの時間的スケールにギャップがあるという問題をしっかり共有して歩み寄ることが必要です。実際の対応策としては、例えば人的リソースの配置を見直してみることが実現できているわけです。例えばさっき言ったように、機械学習のモデルを作る側にいたけど、デプロイするところはサービス開発の人が手伝う流れでやってみるっていうことが選択肢に入ってきます。

まずは「本当に機械学習に取り組むべきなのか」

ここはサラっといくんですけど、人材配置の最適化以外の対応策としては、例えば取り組む問題の見直しと書きましたが、要はさっきみたいなギャップは開発現場ではコストになり得るわけです。先に右下の引用なんですけど、これは2015年かな、Googleが出した論文です。「機械学習のシステムってすごく複雑化しやすくて維持するのがすごく大変で、機械学習ってキラキラしてるけど、使うとシステムにとって潜在的コストになり得るよ」って話ですね。技術的負債の塊であると言ってるんですけど。

2つ目の課題を考えられたとして、さっきの開発現場でのスピードのギャップとか、こういった技術的負債になりやすいという部分を加味したうえで、機械学習は本当に利用して取り組むべき価値がある問題なのかを考え直すというのは、さっきみたいな問題を認識しないと正しく話ができないですよね。ここがメインなんですけど、エンジニアとしては、こういった問題があるときに機械学習のモデルの開発と改善が遅くて困るとなったら、開発のサイクルを早くしてあげるために「開発のサイクルが遅いという問題をエンジニアリングで解決しようぜ」という話が当然出てくるわけです。

僕なんかもここ派なんですけど。さっきAPI化するのも大変だという話をしたように、結局、機械学習のモデルを学習して、実際にそれが使えるかどうかを確かめて、デプロイして、本番に出して動かすというところの1個1個の大変な部分を、エンジニアリングによってやりやすくしてあげるという話をします。

まず開発の効率化ですね。開発の効率化について、今回に関してはクックパッドでどういう取り組みをしているかでお話ししますと、機械学習基盤というものを自分たちで作って改善しています。

これはどういったものかと言うと、機械学習に関わる、機械学習の実験をしたりデータを集めて実験して学習したり、実験して学習して分析するみたいなところを効率的にやれるようにするための基盤です。

めずらしいかどうかはわかりませんが、うちの部門が意識的にやっているのは、研究開発部の中にこういった基盤を作って改善する人間を配置しています。さっき僕のロールはリサーチエンジニアと言ったんですけど、いわばインフラとか開発基盤の人間が研究開発部にいるっていう状況なんですね。

実際にいろんなところで発表してるんですが、これ（画像左）は今月の半ばにあったAWS Startup Day Tokyoで発表したやつです。インフラストラクチャー部の部長と僕とで発表しました。あっち（画像右）はPyData.Tokyoで発表したクックパッドの機械学習基盤です。そういった取り組みをしています。

複数のGPU環境をどうやって用意するのか

具体例としていくつか実際にやっていることの紹介をしたいのですが、例えば1つは、うちにはオンデマンドGPU環境というのがあります。どういったものかと言いますと、さっき背景でお話ししたように、海外含めてメンバーがけっこういっぱいいて、しかもリモートでたくさんメンバーがいる。

その中で複数の深層学習系のプロジェクトが立ってて、「これやりたいね」というものがある。そこに対して複数名がコミットするという、けっこうアクティブな状況なんですね。その中で実験用の環境をどうするか。深層学習をやるうえでやっぱりGPUは必要なんですけど、そのGPUの環境をどこから持ってくるの？　っていう話があって、どうしたかという話を軽くしたいと思います。

結論から言うと、Chat bot経由で起動・停止可能なオンデマンドのGPU環境が社内にあります。これは自製したやつですね。ざっくり言うと、「実験用のインスタンス作ってほしいんだ」とslackに言うわけです。そうすると裏でAWS的なものがうにょうにょと動いて……少し細かく説明しますか。

このへんは置いといて、右のこいつですね。これがAMIと言って、AWSにEC2インスタンスって計算機があるんですけど、その計算機の上で例えばGPUドライバーを設定したりとかCUDAをインストールしたりとかPyTorchを入れたりまでを設定したあとの状態を、スナップショット撮ってセーブしておけるような仕組みがあるわけですね。

それができると、設定済みのインスタンスがいくつも立てられているようになる仕組みを使って、うちでは深層学習用に使うAMIというのを部内にいくつか持っていて。「実験用のインスタンスを作って」って言ったら、そのAMIから適切なものを選んで起動して、sshを通すコマンドを返してあげるといったことをやる。

Slackの特定のチャンネルの中でGPUインスタンスを使いたいんだったら「GPUインスタンスを作ってくれ」っていうコマンドを叩くと、3分後くらいにsshコマンドが返ってきて、コピペしてターミナルで入ると入れて、中でGPUがすぐ使えるみたいな状況があります。しかも、これはわかると思うんですけど、自分で3つ欲しかったら3回やれば3つ返ってくるみたいな感じ。もっと詳しくはさっきの資料とかもあるので、この資料はあとで公開するのでTwitterを見ていただければわかると思います。

プロジェクトのテンプレート化で再現性を向上する

機械学習基盤、機械学習を効率化するための1つの取り組みとしてオンデマンドのGPU環境をお話ししました。もう1個、これは最近チームでやり始めていますが、プロジェクトのテンプレート化による実験の再現性の向上ということをずっとやってます。どういうことかと言うと、例えば一方でまだプロダクションに乗ってないけど画像からメニュー名が分類できるような実験をやっているとします。

例えば2ヶ月前くらいに、画像を100万枚使って、ラベルをくっつけて、麻婆豆腐とかラーメンとか分類できるモデルを作るってことをAさんがやっていました。その後「そういえば、あれあったよね。あれをもうちょっとカテゴリー化してこっちで追実験したいんだけど」っていうBさんがいたときに、Aさんの実験を再現できないということがすごく多いんです。

なんでかと言うと、いろいろ要因はあるんですけど、まず例えば、実は100万枚の画像データをいかにバージョン管理するかみたいなノウハウがないということがありあます。というのはGitでプッシュするわけにはいかないので、じゃあこれどうしようかみたいな。Git LFSみたいなのもあるんですけど、まあ、なんかやらないといけない。再現性が低下しがちなんですね。

例えば、あまり耳馴染みがないかもしれませんが、これを解消するためにワークフローエンジンみたいなものがあって。ワークフローエンジンって何かと言うと、例えばクラウドストレージのここから画像を持ってきて、画像をベクターに変換して、さらにクラウドストレージの別の場所にそのベクターを書き戻すみたいなフローをプログラムで書いてあげて、実行するとそれが再現されます。例で言うとDigdagとか、あとはAirflowとかLuigiとかあるんですけど。

それを部内で整備しようってなるかというと、そこまではコストをかけたくないっていうときに、ちょっといいのが見つかりました。Cookiecutterってご存知の方いますか？　Pythonのライブラリなんですけど。

（会場挙手）

あんまりいないですね。これってもともとCookiecutterってプロジェクトのテンプレート化のツールなんですね。ご存知の方がいるかどうかわかんないですけど、Rubyにはbundlerっていうのがあって、Rubyのライブラリを作りたいときにはbundlerで自分のテンプレートを吐かせてそのあと開発すれば、公開まですんなりできるんですけど。

Cookiecutter Data Scienceで実験を再現する

Pythonには、Cookiecutterというのがあります。ほかにもあるんですけど、テンプレートを生成するツールですね。CookiecutterにPythonパッケージを作りたいですと言うと、Pythonのパッケージのよくあるかたちのディレクトリの構成がダーっと生成できｋます。これはテンプレートもプラグインみたいにほかの人が開発できるような設定になっています。実はデータサイエンス用でもあるんですよ。drivendataっていう、どこだっけな？　国は忘れちゃったけど、海外の企業が作って公開しているCookiecutter data scienceというのがあります。

Cookiecutter Data Scienceを使ってテンプレートを生成すると何ができあがるかと言うと、ザッとこんな感じのディレクトリ構成で、もうちょいいろいろあるんですけど生成されます。

各種規約ディレクトリって書いてあるんですけど、要はまずソースというディレクトリができて、ソースの下にデータとモデルというのがあって。データを作るソースはここに書いて、モデルをトレインするやつはここに書けるみたいな、規約に則ったディレクトリが切られているわけですね。

一方でソースと同じ階層にデータっていうディレクトリが切られて、こいつは基本的にデータを入れる場所なのでGitにあがらないようにあらかじめignoreされている。一方でMakefileのほうにtargetがあって、このtargetを使うとAmazonのクラウドストレージにデータを規約に則ったプレフィックスを切ったうえでコピーされるみたいなtargetが書かれている。それは逆もできるわけですよね。ちょっと何言ってるかわかんなくなってきたと思うんですけど。

さっきの話ですね。追実験したいとなって、先ほどは「ソースコードはあるけどデータはどっかいっちゃったよ」っていう話になってたんですけど、「ここだよ」って指してあげて。こいつをcloneしてあげて、さっきのデータを持ってくるtargetをmakeするわけですね。クラウドストレージ上にある規約のプレフィックスの下にあるデータがシュッとローカルに落ちてきて、実験がすぐに再現できるといったような。

もちろん、データのバージョニングとか細かい問題は残るんですけど、けっこう手軽で小規模なチームにおいてはすぐに再現性の向上が狙えるいいツールでした。

これはよかったので、うちの社内のエンジニアがもうちょいいいやつにしようということで、実はオープンソースのプロジェクトができています。

開発の効率化を担当する人を配置する

さっきのやつはすごく平たく言うとdockerを使ってないんですね。dockerを使わずにrequirementsってかたちで依存ライブラリを列挙してあげて、それで実験の環境を再現できるということだったんですけれども、事はそううまくいかない場合もあるので、できればdockerで再現性を保証してあげたいという気持ちがあって、さっきのやつのdocker版みたいなものを作っています。

makeにはいろいろなtargetがあって、make notebookとかやるとdocker……が立ち上がって、ローカルマシンでもportをしっかりつなげられて、こっちのブラウザから見られるようになるとか、そういったことができるようになっていて、ここはちょこちょこ開発しているような感じです。こういうのもいわゆる機械学習基盤の1つですね。

モデルの開発の効率化は、要は研究開発部の中で基盤を作るエンジニアも配置されていて、そこで積極的に改善しているといった背景があります。一例としていくつか紹介しました。あんまりTips集みたいにはしたくなかったんですけど、実際にチームで機械学習をやろうぜとなったときに、このへんをお世話する人がチームの中にいるとやっぱりいいと思います（笑）。開発の効率化というのはこんな感じでやっていきますよって話をしました。

APIでデプロイする利点

一方で、課題としてすごく大きいのがデプロイですね。学習したモデルを実際に使うとなったときに、どう使うかという話です。デプロイの選択肢ってけっこういろいろあるんですよ。例えばうちはRailsで動いているのでRubyになっちゃうんですけど、サーバーのコードの中に機械学習のモジュールを食い込ませる。実際にバッチプログラムとかどこかのサーバー上のAPIポイントの裏側で機械学習が呼ばれて、その判定結果を実際に動作に活かすみたいなサーバーに埋め込むやり方があったりとか。

あとPythonパッケージ化するみたいなのもありますね。社内のPythonパッケージのレポジトリにあげておいて、モデルをインストールするとモデルのクラスが使えるようになるとかっていうのもあるんですけど。あとはさっき言ったAPIですね。ちっちゃいHTTPで通信できる小さなAPIサーバーを作ってあげて、その中にモデルを入れるみたいな。いくつかあってそれぞれに良いところと悪いところがあるわけなんですけど、ちょっと今日は時間がないのでAPIがいいという前提で話を進めていってしまいます。

モデルを読み込んで外部リクエストに応じて、要はpredictみたいなエンドポイントがあったり、あとはヘルスチェックするhello波動とか、なんでもいいんですけど、エンドポイントが立ってるというだけのちっちゃいアプリケーションを作るのがおすすめです……っていう話はさっきあったPyData.Tokyoのスライドにも書いてあるので、もし詳しく知りたい方がいればそちらを参照ください。あ、でも、良い理由はこれから話します（笑）。

APIが良い理由はいくつかあって、機械学習のモデルを呼び出すだけのAPIなので、すごくMicroservice的な考え方なんですよね。マイクロにもほどがあるってほどマイクロなんですけど。Microserviceの利点とほぼ一致するんですけど、まず機械学習をやるモデルの部分とアプリケーション、例えばWebサーバーのほうで異なる技術が使えるという部分ですよね。うちだとサーバーはほとんどRubyで書かれていて、機械学習はPythonでやることが多いのでそこはもう顕著です。

デプロイの効率化をどうするか

あとは機械学習のモデルというのは、深層学習だったらGPUの上で動かしたいときに、1つの独立したサービスとして存在していると、そのへんの取り回しがききやすくなる。あとはこれもMicroserviceの利点ですけど、サービスで分化されたAPI、WebサーバーとAPIという部分が機械学習APIと疎結合になっていると機械学習APIだけ必要な分をスケールして伸ばせるとかですね。

これはちょっと細かい話なんですが、機械学習のモデルは、さっきも言ったとおり写真が料理かそうでないかを見分けたり、料理の写真からメニューを当てたりっていう、1個1個はけっこうプリミティブな存在なんですよ。なので、例えば料理かそうでないかを見分ける分類器みたいなのは必ずしもアプリケーション1個じゃないんですよね。

さっきの料理きろくで使う場合もあれば、もしかしたらユーザーから投稿されたレシピの写真が料理じゃなかったらアドミンツールで警告を出して「このレシピはちょっと変だよ」と通知してあげるっていう使い方もできるかもしれない。Microservice系の良さとして機械学習のモデルというプリミティブな存在を各所で再利用するというチャンスも生まれるといった話があります。これはあとでいっか。あ、そうそう。デプロイの効率化という話ですよね。デプロイの先はAPIがいいとお話しして、じゃあさっき出たAPI化するのに何が必要かを見直す。けっこう大変なんですよ。

実際にエンジニアってスペシャリティがいろいろあるわけで、データサイエンティストが書くコードが汚いとかそういうことを言うわけじゃないですけど、APIサーバーを書いたりとかDocker化したりとかインフラに入れ込むみたいなところって、スペシャリティとしては外れがちなんですよね。このへんはけっこうやるのがつらいです。

学習済みモデルのセーブは普通に分析するときにやっていくのでできるんですけど、このへんからだんだんつらくなっていきます。

これを解決する方法です。実は最近、要はデプロイの手順の大変さをけっこうダイナミックに解決する方法ができ始めています。というのは、マネージドなデプロイ環境ですね。マネージドなデプロイ環境って何かと言うと、GoogleのCloud Machine Leaning EngineとかAmazon SageMakerとか、あとfloydhubっていうやつがあったりとか。要はモデルを作ってデプロイってコマンド叩くと、「そのモデルがアップロードされてAPIが作られるみたいな。最近は、そのへんをお世話してくれる共通基盤みたいなのがけっこうできてきてます。

なのでこのへんを使うっていう手もありますよね。これも今日はちょっと時間がなくて1つ1つ紹介できないので、もし興味があれば詳しくは以前のスライドにあったりするので見てください。

というわけで「成長を止めない機械学習のやり方、組織・チーム編」ということで、サービス開発と機械学習のスピードのギャップとか、そのあたりを問題意識として挙げて、どうやって解決するのかという検証をいくつかやっていきました。

機械学習は現場で身につける

次は個人編ですね。個人編となると、みなさんが個人個人成長を止めないために何をすべきかっていう、けっこう偉そうな話になってくるんですけど。ちょっと辛抱して聞いてください。「機械学習ができるようになるとは何なのか？」　というテーマでちょっとだけお話ししたいと思います。Amazonで「機械学習」って検索すると、例えばこんなふうにたくさんいろんな本が出てきて、キーワードもピックアップするとこのくらいあるわけですよね。真ん中にRがいますけど。

一言で機械学習と言っても何をやればいいのか、最近の機械学習ブームも手伝って情報がわちゃわちゃになって氾濫しています。じゃあ何をすればいいんだっけっていう。今、実際のエンドユーザーと情報のバランス的に、それこそ「プログラミングを始めるときって何からやったらいいんですか？」状態になってると思います。

実際のところ僕もそうで、やれこういった論文は読まなきゃだめだとか、やっぱkaggleもやったほうがいいよねとか、いろいろ情報がいっぱいあって、あれもこれもやりた過ぎるんですよね。でも時間は有限なのでどうにかしていかなきゃいけない。時間は有限なので、こういった状況ではものすごく具体化された目標とか目的が必要になってくるわけです。

例えば僕の場合……っていうか、サービス開発に機械学習を使うような、うちみたいな中規模の、エンジニア100人くらいの組織での目標としては、機械学習を使って自立して価値を生み出し続けられるような状態になることがわりと納得感があるなという話があります。実際にやることを具体化するという話なんですけど、一方でやっぱり、やることもいっぱいあるわけですよね。情報が氾濫してるんですけど、現場もそれなりに氾濫してるので。

Python書かなきゃいけないかもしれないし、dockerもできなきゃいけないかもしれないし、SQLをちゃんと書けないと、データ基盤をぶっ壊さないSQLをちゃんと書けなきゃいけないかもしれないし。インフラのことも学ばないといけないかもしれないし、GPUとかももしかしたらちょっとはわからないといけないかもしれないというような、現場も実はそんな状況なんです。なので今は、そのどれが必要かというのは、「これをやれ！」っていうふうには言えない状態なんですね。

本当に月並みなんですけど、現場で機械学習をやるみなさんって、1冊1冊の本で学べないところってものすごく多いんです。結論を言ってしまえば、1番の近道はたぶん、実務で機械学習のプロジェクトに入って機械学習をやることだろうなと思っております。実際にクックパッドの現場で機械学習のチームに入って、こんな感じに機械学習をやっていく、ということを日々やるわけなんですけど。その中で見えてくる課題というのはものすごくあって、そうなってくると努力もしやすいという感覚があるので、実務で機械学習を1個1個やるという経験をしていくというのがよかろうと思っております。

一方でやっぱりデータ分析系のコンペも実はけっこう良くて。よくkaggleと実務は違うとか、コンペと実務は違うよね、実際の現場は違うよねみたいな話もあるんですけど、実際に見てみると、与えられたデータと問題というのがあって。問題が明確でないことが現場ではけっこうあるので、そのへんはちょっとギャップがあるんですけど、限られたデータと限られた時間の中でスコアをちゃんと上げていくようなところはまあまあ実務に沿ってる部分があると思っています。噂に惑わされず、実際にデータ分析コンペをやってみるのはすごくいいなと思っております。

機械学習の価値を積み上げて、幻滅期を乗り越える

というわけでちょうど時間ぴったりくらいなんですけど、いかがでしたでしょうか？　成長を止めない機械学習のやり方ということでお話をさせていただきました。サービス開発にしろシステム開発にしろ、機械学習を使っていくということに関しては、今はブームが手伝っているのもあるんですけど、やりたいことと現場の成熟度みたいなところにものすごくギャップがあるような状態を感じております。

その中で、最初に話した幻滅期みたいな話もあるんですけど、実際地に足付けてたくさんの細かい価値を増やしていきたいなという想いです。このセッションに集まっていただいているということは、みなさん機械学習に興味があって集まっていただいていると思うんですけれども、ぜひお互いにがんばって幻滅期を乗り越えていきましょう（笑）。以上になります。

ありがとうございました。

（会場拍手）