※旧SEメンバーシップ会員の方は、同じ登録情報（メールアドレス＆パスワード）でログインいただけます
AIシステムが成熟する今「MLOps」が必要とされる理由とは？ MLOpsを推進するために大切なこと
近年、機械学習（ML）やディープラーニング（DL）といったAI関連技術をプロダクトへ応用し、新たな価値を生みだそうという動きが加速しています。その中で、従来の「DevOps」の考え方を、機械学習向けに発展させた「MLOps」という新しい概念が生まれ、注目を浴びています。MLOpsが注目される背景には、どのような課題があるのか。そして、実際に現場でMLOpsに携わる人々は、何を目指し、どんな取り組みを行っているのか。ヤフーとLaunchableで、それぞれMLOpsをリードしている2人のエンジニアに語っていただきました。
機械学習システムの普及を契機に関心が高まる「MLOps」
黒松：ヤフーの黒松です。私は大学時代に、ビッグデータを研究テーマにしており、OSSとして当時注目されていたHadoopなどを扱っていました。卒業後は富士通研究所に入り、基盤研究の一環として、機械学習のための基盤を作り、AI研究者に提供したり、それをテーマとした社外発表を行ったりしていました。2年半ほど前に縁あってヤフーに入り、その後も継続してAI基盤の構築に携わっています。
澁井：実は私も、ファーストキャリアは富士通だったんですよ。
黒松：プロフィールを拝見して「近いところにいらっしゃったのだな」と思っていました。私は2013年入社でしたが、澁井さんはいつごろまでおられたのですか。
澁井：2013年だと、ちょうど私が退職するころですね。私は学部生時代は文学部でイギリスの歴史を学び、そのまま大学院まで進みました。その後、富士通にシステムエンジニアとして入社。当時は、クラウドサービスが注目を集めていた時期で、富士通でも日本企業が利用しやすい国産のクラウドを作っていこうという動きが盛んでした。私は、ビジネスサイドとエンジニアサイドの両方に携わりながら、その構築に関わっていました。
その後、クラウドが一般的になる中で、エンジニアとして幅を広げていったほうが良いのではないかと思ったのが、AI領域に進んだきっかけです。富士通を離れてからは、外資系のソフトウェアベンダーや、複数のスタートアップなどに関わりましたが、一貫していたのは、これまでどちらかと言えばアカデミックやサイエンス的なイメージが強かった機械学習を、世の中で、もっと効率的に使えるものにしていきたいという思いでした。そうした取り組みに、最近「MLOps」という呼び名がついたことで、私の目指すところが、周囲にも理解されやすくなってきたと感じています。
現在は、Jenkinsの開発者として有名な川口耕介さんがCo-CEOを務める「Launchable」という会社で、ソフトウェアテストを機械学習で効率化するためのプロダクト作りをしています。
――「MLOps」という概念に、なじみのないエンジニアも多いと思います。具体的にはどのような考え方なのでしょうか。
澁井：分かりやすく言えば「DevOpsの考え方を、機械学習の開発や運用と、そこで扱われるデータの扱いまでを含む形に拡張したもの」だと言えます。
DevOpsは、以前は個別に扱われがちだったシステムの「開発」と「運用」のプロセスをつなげ、ひとつのワークフローとしてサイクル化していこうという考え方です。リリースしたソフトウェアは、常に完璧ではないという前提で、フィードバックをもとに改善を続けていくために、DevOpsは有用な考え方です。
この「リリースしたものが、常に完璧ではない」という状況は、機械学習の領域で特に顕著です。機械学習では、既にあるデータをもとにモデルを作成しますが、データは「生もの」であり、常に変化していきます。例えば、ネットの個人売買サービスで取引される「マスクの価格」は、コロナ禍直後に、それ以前には想像できなかったレベルで大きく変動しました。仮に、コロナ禍以前のデータをもとに「マスクの価格」を推定するモデルがあったとしても、コロナ禍以降のデータを使ってモデルを再構築しなければ、現実的には実用に耐えません。
機械学習をプロダクトで活用していく上では、データが変化することを前提に、データの収集やモデルの改善といったプロセスを、DevOpsのサイクルに組み込んで考える必要が出てきます。それが「MLOps」の一例になります。
黒松：MLOpsの基本的な考え方については、澁井さんの説明に同意です。従来のDevOpsで対象としていた、機械学習を利用しないソフトウェアの場合、ユーザーの入力に対して、ソフト側が何を出力すべきかは、ある程度決まっており、その出力が正しいかどうかの判断も比較的容易なケースが多いです。
ただ、そこに機械学習が入ってくると、従来のDevOpsの方法論だけでは、うまくいかない部分が出てきます。例えば、機械学習の世界では、入力するデータのフォーマットは一定でも、それに対応する出力が変化することが頻繁にあります。その際、システムが行った出力が、人間側が期待しているような“正しい”出力なのかどうかの判断が難しくなります。従来のDevOpsの仕組みだけでは、機械学習が“正しく”機能しているかを観測できないのです。
その意味で、私は「MLOps」を、「生もの」であるデータを、DevOpsの中でいかに取り扱うかの方法論と、そのための組織の作り方、文化の育て方までを含めたものだと捉えています。現状で難しいのは、組織によって「MLOps」の捉え方がまちまちで、共通の理解が確立されていない点でしょうか。
黒松 信行（くろまつ・のぶゆき）氏
ヤフー AIプラットフォームチーム プラットフォームエンジニア。前職を含め、2016年からKubernetesを使った機械学習基盤の開発と運用を担当。MLOpsの実現と普及のために、機械学習を使ったシステム開発の“トイル（toil）”（戦術的、長期的な価値がない、自動化が可能な作業）を組織の中から削減していくことに関心を持つ。
澁井：そう思います。人によっても、まだMLOpsの定義はバラバラですね。機械学習基盤を作ることを指して言うこともありますし、データサイエンティストの知見をプロダクトとして世の中に出すための仕組みづくりを言うこともあります。また、黒松さんがおっしゃったように、そのための組織文化の醸成のような、周辺環境の整備を含めて、そう呼ぶこともあります。MLOpsという言葉が指す内容や範囲が、まだ固まっていない状況であるというのが、現状の面倒くさいところであり、面白いところでもありますね。
――そもそも「MLOps」という概念自体は、いつ、どのように提唱され、日本で注目されはじめたのでしょうか。
黒松：実は、そのあたりの認識も人によって違います。私の認識だと、言葉としての「MLOps」が国内で認知され始めたのは、2018年の「Google Cloud Next」というイベントで、同社の佐藤一憲さんが発表を行ってからだと思います。特に、ここ1～2年の間に、急速に関心が高まっていますね。
澁井：Googleは、検索機能の改善などを目的に機械学習を以前から活用していたわけですが、その中で、単なる機械学習の理論だけでなく、それをプロダクトへうまく実装していくやり方、直面しがちな課題への対策、継続的に精度を高めていくプロセスのような方法論も構築しています。それが世に出て「MLOps」という名前が付いたと捉えています。
もっとも、それに近い概念は以前にもありました。機械学習のためのシステム構築の方法論で「SysML（System and Machine Learningの意。System Modeling Languageとは別物）」と呼ばれていたのですが、いつの間にか、それを取り込む形で「MLOps」という呼び方のほうがポピュラーになりましたね。
――特にここ数年で「MLOps」への注目度が上がっている背景には、どのような理由があるのでしょうか。
澁井：機械学習という技術が、実際にビジネスへ貢献できる可能性があることが、事例として多く出てきたことが大きいと思います。そこで、プロダクトに組み込んで世に出した後で、機械学習のパフォーマンスや精度を継続的に高めていくためには、どうすればいいのかを考える必要が出てきます。
普通のソフトウェアであれば「DevOps」、インフラ運用であれば「SRE」的な考え方が、それぞれのニーズに合わせて出てきたわけですが、機械学習の領域は、それらとはさまざまな部分が異なります。基盤そのもののアーキテクチャや、利用するライブラリの構成も違いますし、データの取得や蓄積、意味づけ、モデルの評価といったプロセスも独特です。
黒松：企業が、AI技術に注目し、PoC（概念検証）を重ねてきた中で、機械学習が「使える領域」と「使えない領域」が、ある程度まで見えてきました。では「使える領域」で、本格的に運用を始めたいと思った時に、そうした機械学習ならではの仕組みやデータの取り扱いが、従来の方法論では難しいことが見えてきたのだと思います。そこで「MLOps」が必要になったわけです。
澁井：ここ数年で“とりあえず機械学習を始めてみる”までの敷居も大きく下がりました。多くの使いやすいツールがOSSにありますし、公開されているデータや学習済みモデルなどを使えば、最初に動かしてみるところまでは、比較的短時間でできる環境が整っています。しかし、それをビジネスへ活用しようとすると、ソフトウェアエンジニアリングのスキルに加えて、機械学習を考慮に入れたデータの取り扱いスキル、新たなワークフローの構築などが不可欠になってきます。機械学習のための「Ops」を考える必要が出てくるのですね。それがリアルに認識されはじめたのが、日本ではここ2～3年ということなのだと思います。
ヤフーとLaunchableでのMLOpsの実践
澁井：先ほど、黒松さんが「機械学習では、データが変化することによって出力も変化していく」という話をされていました。特にヤフーのように、検索やニュースのようなサービスを提供している企業だと「生もの」としてのデータの変化は、ダイナミックに感じておられるのではないでしょうか。サービスに機械学習を生かしていくためには、モデルも頻繁に更新していく必要があると思うのですが、そのあたりはどのようなワークフローでやっているのかに興味があります。
黒松：ヤフーでは、サービスの中で生まれる多様なデータを、サービスの成長に活用していくことを掲げています。AI領域、機械学習への取り組みもその一環で、既にいろいろなところで応用が始まっています。その中で、先ほどお話ししたようなデータを取り扱うことの難しさにも直面しており、MLOpsの重要性を痛感しているところです。
これまでは、各チームがそれぞれに機械学習の導入や、その運用のための仕組み作りを試行錯誤している状況でした。現在ではMLOpsの方法論と、それを実践する文化を組織に根付かせる取り組みを進めています。その過程でMLOpsを実践するための基盤として、私が所属するチームが開発する「AIプラットフォーム」の利用が社内で急速に拡大してきています。
もともとヤフーには、機械学習をサービスに組み込むソフトウェアエンジニアも、モデルを作るデータサイエンティストも、優秀な方が大勢いました。技術をサービスに適用すること自体は、それほど難しくなかったのですが、それを継続して安定的に運用する上での課題は、各チームで感じていました。ヤフーでの機械学習の活用方法はサービスごとに要件が大きく異なります。
機械学習をサービスに適用し、MLOpsを実践するために必要な基盤をAIプラットフォームとしてある程度標準化して整備することと併せて、MLOpsそのものの重要性や、「この機能はこう使うと便利」というような知見を、社内で浸透させていきたいと考えています。
澁井：ヤフーがすごいのは、インフラから機械学習基盤までを自前で作ってしまうところですね。最近では、特に物理サーバのような低いレイヤについては外部のサービスを活用することが多いですし、実際、そのほうが現実的なケースも多いと思います。自分たちが好きなように使いたいと思えば、インフラから自前で作るのが一番だというのはたしかですが、そのためのエンジニアリソースをそろえるのは大変です。しかも、ヤフーの場合は、開発チームが自分たちでKubernetesを使う仕組みや文化も合わせて作っています。「よくできたなぁ」というのが、正直な感想です。
黒松：Kubernetesについては、普及促進のためのチームや技術コミュニティが以前から社内にありました。自分も、ヤフーへ来た時に、データサイエンティストが当たり前のようにKubernetes使っているのを見て驚きましたね。これは、本当にヤフーの良いところで、MLOpsを意識した組織作りがスムーズに進められている理由のひとつでもあります。
澁井さんは、これまでのキャリアで、どのようにMLOpsを実践されてきたのですか。
澁井：思い返すと、キャリアの中で、自然と「MLOps的」なことに関心を持つようになっていました。外資系ソフトウェアベンダーでは、データサイエンスのためのプラットフォーム開発に携わっていたのですが、その時「製品をユーザーに導入して終わり」というビジネススタイルに何となく違和感をおぼえ、「作った後にどうすべきか」が気になりはじめました。一度作ったデータの分析基盤、機械学習基盤の価値を、その後も維持し、高めていくためのシステムやチームが必要なのではないかという思いが、個人の課題として生まれたのです。
ちょうどその頃にKubernetesが登場し、自分がイメージしていたような仕組みを実現する上で、相性が良い技術だと思いました。その後転職したスタートアップでKubernetesを使って実際に作ったプロダクトは、良いものだったと自負しているのですが、当時はまだ機械学習向けの独特なコンピューティングシステムを扱えるエンジニアも、Kubernetesを扱えるエンジニアも少なく、「スゴイものは作ったけれど、使ってもらえない」という状況でした。結局その後、「Amazon SageMaker」やGoogleの「Vertex AI」といった形で、自分たちが作っていたようなものがクラウドベンダーの手でプラットフォーム化され、広く簡単に扱えるようになっていきましたね。
その後に入った、自動運転システムを開発するスタートアップでもデータ基盤を作っていました。自動運転のAIでは、車載カメラで撮影した大容量の動画データに対し、ディープラーニングを使って、映っているものを認識するということをやっていました。1日に1テラバイト近くのデータが入ってくるのですが、これ自体は、データサイエンティストや機械学習エンジニアの視点で見ると、非常に「汚い」データです。それを使えるデータにするために必要な前処理のシステムを作るというのが、そこでの仕事でした。正直、これは本当に大変でした。
今勤めているLaunchableでは「ソフトウェアテストを機械学習で効率化する」事業を行っています。今、ソフトウェア開発の領域ではCI/CDなどの自動化が進み、そこでは開発プロセスに関わる大量のログデータも生みだされています。このデータをもとにした機械学習で、テストをさらに効率化できると考えています。
例えば、リリース前のテストが完了するのに、全体で半日かかるとしますよね。その半日の間に走っているテストの「重要さ」というのは、常に同じというわけではありません。一部の修正をしただけの場合、失敗する可能性が高いテストの数は限られます。それ以外の部分の重要性は相対的に下がります。テスト後の対応時間を短縮するためには、状況に応じて各テストと対象範囲の重要さを判断し、通らない可能性が高いところ、影響が大きそうな所からテストを実行していったほうがよいわけです。全体で6時間のテストのうち、最初の1時間で重大な問題が見つかれば、すぐに修正に動けますからね。こうしたテストの優先順位を判断する仕組みを、機械学習で実現しようとしています。モデルは案件ごとに変える必要がありますので、各ユーザーの最新のログデータをもとに、モデルを改善するという取り組みも併せてやっています。
Launchableで、機械学習のバックグラウンドを持っているエンジニアは、今のところ私一人です。周囲のエンジニアは、インフラ、バックエンド、フロントエンドの全般を作れる人ばかりですが、その中で、データシステムやデータ基盤を含む機械学習の基盤を、どうにかしていくのが私の仕事になります。
澁井 雄介（しぶい・ゆうすけ）氏
Launchable, Inc. MLOpsエンジニア。フルスタックエンジニアとして、バックエンドの開発を行いつつ、コードテストの実行を効率化するための機械学習基盤の開発、実用化に従事。過去にはSIer、外資系ソフトウェアベンダー、スタートアップで新規プロダクトの立ち上げ、大規模システム運用、チームマネジメントなどを多数経験した。著書に『AIエンジニアのための機械学習システムデザインパターン』（翔泳社）がある。
黒松：AIの使いみちとしては、レコメンドエンジンや画像認識など、ある程度一般的なパターンが出そろったように思っていたのですが、テスト効率や開発者体験の向上にAIを使うというLaunchableの取り組みはユニークですね。
澁井：会社としては、DevOpsの極限までの効率化を目指しています。CI/CDのログには、開発プロセスのボトルネックを知るための情報が大量に含まれていますからね。この考え方は、もともとFacebookで生まれたものだそうです。あれだけ大規模なサービスとなると、テストも数千、数万以上のケースをこなすような膨大なものになります。インフラコストもばかになりませんし、作業に関わる開発者体験は生産性にも影響を与えます。これまで、完了に6時間かかっていた作業が、3時間に短縮できれば、それだけでもインパクトは絶大です。
MLOpsを実践する上で組織が直面しがちな課題は？
――現場でMLOpsを実践されているお2人が、特に難しいと感じる部分、さまざまな組織で共通して課題となりそうな部分はどこだと思いますか。
黒松：MLOpsをDevOpsと同じものと考えてしまうことで、DevOpsにはない部分の必要性が認識されにくく、対応が後回しになりがちなのは一つあると思います。代表的なものとしては「モデルモニタリング」ですね。データの傾向が変わり、一度作成したモデルの性能が劣化していく「コンセプトドリフト」や「モデルドリフト」と呼ばれる状況に、どう対処すればいいかという問題です。モニタリングで性能が落ちたモデルは、再学習して作り直す必要があります。理想的には、システムがその状態を検知し、必要に応じて自動的に再学習できるようにしておくべきなのですが、この部分をシステムとして自動化するところまでは、なかなか踏みこめないことが多いように思います。
澁井：4月に開催した「MLOps勉強会」では、黒松さんにKubernetes Operatorを使ってモデルモニタリングを実現する方法について話していただきました。実際の作り方にまで踏み込んだ内容で、とても参考になりました。
黒松：モデルモニタリングのために、既存のツールが使えないかと探してみたのですが、良いものがなかったので、社内で完全に内製しました。その時の経験が、同じようなことをやりたい人の参考になればと思い、発表させていただきました。現場がやりたいことと、実際の環境にギャップがあれば、それを埋める作業をするというのが、組織にMLOpsを根付かせるためのポイントだと思っています。
MLOpsには「こうすれば何でも大丈夫」と言えるようなベストプラクティスはないと思っています。それぞれの組織で、自分たちに合う方法を見つけていく必要がありますね。もっとも、より大きなくくりでの“ひな型”となるようなデザインパターンはあるはずで、今後、いろいろなパターンがまとめられていくべきだと思っています。
その点で、澁井さんが以前の職場で機械学習システムに関われた経験をもとに書かれたデザインパターンの書籍は、価値の高い取り組みだと感じました。
澁井：ありがとうございます。シンプルに言ってしまうと、機械学習を活用していく上で、多くの組織に共通する課題のほとんどは「データをどうにかしなきゃいけない」に帰結するのではないかと思っています。
機械学習やAIをやりたいけれども、そのためのデータが社内になかったり、あったとしても使える状態になっていなかったり、というところでつまずいているケースは多いのではないでしょうか。逆に、いろいろなフォーマットで散らばっているデータを、きちんと整理してシステムに取り込み、使えるようにできれば、後は何とかなるとも言えます。実は一番難しいのは、集めたデータを見ながら、自分たちでその中に潜む、ビジネス的に価値のある「意味」を見つけ出すという作業なのですね。データ基盤の整備は、機械学習の活用のステップを、その段階へ進めるために不可欠です。
次につまずきがちなのは、機械学習の開発成果をプロダクトに組み込むタイミングでしょう。エンジニアやデータサイエンティストがローカルな環境で動かしていたものを、継続的なメンテナンスに耐える品質でプロダクトに組み込むために、どのようなやり方がベストなのかという部分については、正直なところ、自分も答えがあれば知りたいです。
黒松：ソフトウェアエンジニアにとっては、モデルの作り方のような機械学習に関する知識が、機械学習エンジニアにとっては、コードの書き方のようなプロダクト開発のための知識が、それぞれに足りていないために、ギャップが生まれるということでしょうか。だとすると、それをお互いに歩み寄って埋めていくというのが解決策かもしれないですね。
澁井：そうですね。先ほども少し触れましたが、機械学習という技術を知るためのハードルは、今も下がり続けています。そういう意味では、この先、機械学習だけしか分からないエンジニアの市場価値は、相対的に下がっていくような気もします。
機械学習エンジニアは、プロダクトを作るためのソフトウェアエンジニアリングについて知ったほうがいいですし、逆にソフトウェアエンジニアは、少しのコストで機械学習の基礎を学べば自分の価値を上げられると思います。機械学習を活用していきたい組織としては、双方のベクトルでのスキルアップを助けながら、組織としての「常識」のレベルを上げていくのがいいのかもしれません。
エンジニアがこれから「MLOps」へ取り組むには
――これから「MLOpsに取り組みたい」組織に対して、アドバイスできることはありますか。
澁井：私が思うのは、まず「やらないことを決める」ことでしょうか。
組織として機械学習を使っていく上での目的は、常に「ビジネスやプロダクトを良くしていくこと」だと思うのです。もちろん、リソースは限られますので、もし自分たちがMLOpsをやっていく上で、使いたい仕組みやサービスが世の中にあれば、必要なものを選んで使っていくべきです。規模が大きくなって、自分たちのやりたいことが既存のツールではできないと感じるようであれば、その部分を自分たちで作るという選択肢もあると思います。ただ、多くの企業にとって、そのハードルは高いです。
黒松：「自分たちのニーズに合うツールがあれば、それを使う」というのは、私も同意です。ただ、ヤフーの場合は、組織そのものが巨大で、サービスも、それを作るチームも多岐にわたっています。そのため「全体に適したツール」を見つけることができなかったというのが、内製の動機付けになりました。これからMLOpsをやっていきたいという組織であれば、機械学習の活用範囲を広げつつ、まずは既存のツールを選んで使ってみて、それをMLOpsのプロセスに定着させるためのノウハウを蓄積していくというのが、規模が大きくなった時にも役立つ取り組みなのではないでしょうか。
澁井：これは、MLOpsの領域以外でも起こる課題ですが、どんな基盤を作っていくか、それをどのようなルールで使っていくかというのは、自分たちがどのようなエンジニアリング組織を持ちたいかという方針と密接に関わってきます。
MLOpsを本格的に展開しようとすると、バックエンド、サーバサイド、クライアントサイドのソフトウェアエンジニアリングに加えて、機械学習領域の基本的な知識、フレームワークの扱い方、GPUリソースの扱い方など、広範なスキルが必要になってきます。求められるスキルセットは、機械学習の活用レベルが上がれば上がるほど、深掘りされて増えていきます。そのつど、解決したい課題の難しさと照らし合わせながら、足りないスキルセットを埋めていくことを目指すのが、組織を成長させていく上での基本的な流れになるだろうと思います。
――では、個人が「MLOpsエンジニア」を目指す上で、持っておくべきスキルにはどのようなものがありますか。
黒松：これはとても難しい質問ですね。というのも「MLOpsエンジニア」の担う役割が何なのかが、まだきちんと定義されていないように思うのです。「プロダクトのために作った機械学習のモデルを、継続的に運用できるようにするための仕組みを作る」のが「MLOpsエンジニア」だと言えばそうですし、私が今やっているような「MLOpsのための部品を作って、社内に広めていく」というのも重要な取り組みの一部だと思っています。
現状、定義があいまいであることを前提に、共通して必要なのは、きれいなシステムを設計する「アーキテクト」としてのスキルではないかと感じています。良いモデルを作ることも大事ですが、それを継続的に運用できなれければ、ビジネスの中で機械学習をきちんと使っているとは言えないですよね。機械学習を含む開発運用環境を、エンジニアの負担が少なく、きれいに維持できるような“正しい”設計やツールの選定ができるセンスは必要だと思います。
澁井：アーキテクトとしての設計能力は必要ですね。ハードルは下がったといっても、機械学習は確率の世界にある技術で、うまく動き続けるシステムを作るための技術や作り方の選択には、やはり難しさが伴います。万一、間違った作り方をしてしまうと、後から直すのが大変ですし、一度作ったものを、どう管理していくかも重要です。
もうひとつ加えるなら「ワークフロー」を考える能力でしょうか。ユーザーによるサービスの使い方を理解して、それにシステムやプロダクトを当てはめられるスキルです。「検索」を例にとっても、ユーザーが自分の求める情報を見つけるために、どのような方法で「検索」をするのかは、ユーザーにしか分かりません。データから「ユーザーはサービスをどう使って、何を解決したいのか」を理解し、そこにどう機械学習を組み込めば、ユーザー体験をより良いものにできるのかを考え、それをシステムとして成り立たせるための要求定義に落とし込めるような力は、持っていると強いですね。
現在進行系で発展中の「MLOps」だからこその面白さ
――お2人は、MLOpsの「面白さ」はどこにあると思いますか。また、将来的にこの領域でどのようなことをやっていきたいでしょうか。
澁井：機械学習をプロダクトへ効果的に組み込むにあたっては、いろんな技術やスキルが必要だと感じています。そのどれもがチャレンジングで、面白いですね。機械学習という新しい技術を使い、これまで世の中になかった新しいものを出していく。世の中に新しい価値を「驚き」とともに提供していくことに、技術者として関われることにやりがいを感じています。
黒松：先ほど「MLOpsエンジニアの担うべき役割が定まっていない」と話したのですが、それはひとえに、MLOpsが現在進行形で発展中の領域だからです。発展中だからこそ、進めていく上でいろんな課題が出てきます。その課題があるとMLOpsが実現できないのであれば、それを取り除くために、何でも自分でやるしかない。課題を自分で見つけて、解決する。それを実践していくことに、楽しさを感じています。
ある程度時間が経って何らかの答えが導き出されれば、面白さもなくなってしまうのかもしれませんが、私としては、MLOpsの領域で「決まった答え」は見つからないのではないかと、何となく思っています。
澁井：本当に、次から次へと、課題ばかり出てきますよね。エンジニアにもタイプがあって、多様な技術領域に次々と触れるのが好きな人もいれば、ひとつの領域を究めていくことにやりがいを感じる人もいます。今の「MLOps」は、特に前者のエンジニアにとっては、楽しい領域だと思いますよ。
黒松：これからやりたいこととしては、機械学習を取り入れたプロダクトやサービスを作っていく上で直面する課題に、それぞれのチームであたるのではなく、できる限り共通化され、自動化された方法で解決できるような環境を作っていきたいですね。
各チームのソフトウェアエンジニアやデータサイエンティストが、データやモデルの監視に手を取られず、本来の仕事である、より大きな「解決したい課題」に集中して向き合える環境を作りたい。そのために、何が必要か、何が可能かを見きわめて、不要なトイルをできる限りなくしていきたいと思っています。
澁井：機械学習が応用できるプロダクト、それによって生みだされる新しい価値は、今見えているものよりも、もっとたくさんあると思っています。Launchableで取り組んでいる「ソフトウェアテスト」の領域もそのひとつです。機械学習そのものの価値も、これからさらに広く認知されていくでしょう。機械学習が広まれば、MLOpsのニーズも高まります。自分の手で、機械学習を生かした新しいプロダクトを作りながら、それをうまく運用していくための方法論を作ることにも、並行して取り組んでいきたいと思っています。
著：高橋美津
写真：OGURA
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社