Upgrade to Pro — share decks privately, control downloads, hide ads and more …

機械学習ビジネスがときめく5Dの魔法

Yuki Mimuro
August 28, 2019

 機械学習ビジネスがときめく5Dの魔法

https://machine-learning-pitch.connpass.com/event/141255/
こちらで発表したスライドです

Yuki Mimuro

August 28, 2019
Tweet

More Decks by Yuki Mimuro

Other Decks in Business

Transcript

  1. 自己紹介 2 • Yuki Mimuro (三室佑貴: @yuki_mimu) • LeapMind 株式会社

    • Collaborative Development (Co-Dev) 事業部 ◦ 一橋大学商学部経営学科 → (2013年4月)組織人事コンサルティング会社 → (2016年5月)LeapMind   → 事業開発、採用/人事、セールス、広報などを担当 • 現在は、セールスチームのマネージャー
  2. よくある状況(開発周り) 10 • データ ◦ そもそもデータをまだ収集していない ◦ 収集する環境を構築していない ◦ 収集したデータのフォーマットがバラバラ

    ◦ アノテーションがされていない • 機械学習モデル ◦ 精度目標を決めづらい ◦ 実行環境をコスト安くセキュアにしたい ◦ ブラックボックスになっていて何をやっているか分からない ◦ そもそも機械学習必要ないかもしれない • 運用 ◦ 機械学習モデルのアウトプットを利用したアプリケーション開発をしたい ◦ システム全体をどのように評価すれば良いのか分からない ◦ 現場の人が使えないと困る ◦ 再学習する仕組みを構築してモデルをアップデートしたい
  3. よくある状況(ビジネス周り) 11 • 予算 ◦ 実用化まで含めた予算を算出してから検討したい ◦ ROIを明確にして欲しい ◦ 保守/運用にかかる費用も知りたい

    • 契約 ◦ 請負契約で完成責任を負って欲しい ◦ 実導入するシステムであれば瑕疵担保責任を負って欲しい ◦ モデルの知的財産権は譲渡して欲しい ◦ 自分たちでカスタマイズできるようにして欲しい
  4. よくある状況(ビジネス周り) 12 • 予算 ◦ 実用化まで含めた予算を算出してから検討したい ◦ ROIを明確にして欲しい ◦ 保守/運用にかかる費用も知りたい

    →実用可能な性能を出すまでの期間が読めないので、予算算出が難しい • 契約 ◦ 請負契約で完成責任を負って欲しい ◦ 実導入するシステムであれば瑕疵担保責任を負って欲しい ◦ モデルの知的財産権は譲渡して欲しい ◦ 自分たちでカスタマイズできるようにして欲しい →データがモデル性能に大きく関わるため、性能保証が難しいケースが多い  知財は譲渡すると今後のビジネスに大きく関わるケースも
  5. 目的設計 17 • Problem ◦ 誰のどんな課題を解決するのか ? ▪ 本当に課題かという問いも大事 •

    Possibility ◦ 解決可能な課題なのか ? ▪ 機械学習を用いるかどうかも要検討 • Person concerned ◦ 関わるステークホルダーは誰か ? ▪ 画像系だとカメラ提供者が肝だったり • Processing ◦ インプットに対してどのようなアウトプットをすれば良いのか ? ▪ アウトプットが課題解決に繋がるか
  6. よくある状況 20 • Develop中心に考えてしまう ◦ 機械学習を使うこと起点で考えるので、後から「ビジネス効果あるんでしたっけ ?」とかに なってしまう ◦ 実行環境(Deploy)を考慮していないと、コストや電力的に実現不可能なシステムになっ

    てしまう恐れがある • 機械学習を目的にしてはいけないので、 Defineをきちんと行おうとする ◦ すると、「あれ機械学習不要では ?」となる • 運用の際にインテグレーションするシステムや使う人を考慮しない ◦ 実行環境がバラバラだったり、実際に使う人が使えないシステムになる可能性がある
  7. 網羅的に考える(例) 22 Define 解決したい課題 誰のどんな課題を解決するのか システム開発の背景 /目的 システムの目的は何か 機械学習の用途 MLをどこになぜ使うのか

    ビジネス的なインパクト どのくらいの効果が見込めるのか Data データ収集状況 サンプルデータを見せてもらうのがベター アノテーション要件 ツール含めてどのように行うか Develop モデルの機能要件 分類 or 回帰、どういったアウトプットにするかなど モデルの非機能要件 セキュリティやレイテンシなど 評価方法 モデルの評価方法の想定 Deploy 用意可能な学習環境 どういった環境で学習するのか、再学習する際に 想定している推論環境 電力やコストだけでなく、物理的な環境もヒアリングした方がベター Drive システムアーキテクチャ設計 システム全体の概要、実現するための関係者洗い出し UI設計 インターフェースの設計はどの程度必要か 他システムとの IF どういった形で結果を渡せば良いか 追加データ収集の頻度 どうやって再学習用のデータを集めるか
  8. たとえば製造業での異常品検知の場合 ... 25 No 工程 検討内容・実施内容 1 判定対象の撮影 ・カメラの選定 (解像度など)

    ・撮影条件の設定 (設置場所・撮影角度・撮影距離・光源など ) ・データの取得 (正常品・異常品のバリエーション撮影 ) ・出力形式の選定 (有線/ネットワーク通信、データフォーマットなど ) 2 正常品・異常品の判定 ・カメラ撮影データに応じた、正常品・異常品の判定手法の選定 ・正常品・異常品の判定プログラムの構築 ・正常品・異常品の判定結果を外部に通知する仕組みの構築 3 異常品への対処 ・異常品に対処する仕組みの選定 (選別機構/発光機構/発音機構など) ・入力形式の選定 (有線/ネットワーク通信、データフォーマットなど ) ・運用方法の検討   異常品が発見された場合に自動的にライン外に避けるか、手動で避けるか   異常品と判定された物を、人間が再チェックするか、全て廃棄するか。 ・判定速度の目標値設定 ・異常品検出率の目標値設定   導入費用・異常品検出率・人員削減率などから費用対効果が定まる。
  9. まとめ 26 • 実用化のためには、モデル開発以外のデータ収集やシステム全体設計が大事 ◦ むしろモデル開発はプログラミング無しでもできるツールが揃ってきている • 予算など始動に向けて、従来のソフトウェア開発との異なる点を関係者ですり合わせる ◦ 経産省のAI・データの利用に関する

    契約ガイドラインが良い • 目的設計からはじめて手戻りを少なくする ◦ どういったパートナーが必要かなどを事前に考えておく • 最終的な運用イメージから ”5つのD”で網羅的に考える ◦ システムを欲しがっている人とすり合わせながら抜け漏れがないよう • すり合わせる際は相互の認識確認をしながら行う ◦ 機械学習システム全体で成し遂げたいことや全貌のイメージを合わせる
  10. 今後やりたいこと 27 • AIというワードのおかげで色んな課題が表出していて、機械学習以外のアプローチで解決でき ることもどんどん解決していきたい • ケーススタディの作成と共有会を実施して、業界全体でノウハウを貯めていきたい • サービスの契約やビジネスモデルについての抜本的なやり方を色んな方と模索したい ◦

    サービス提供者もユーザーも win-winになるやり方 • 実用化に持っていくための観点については検証と改善を繰り返してオープンにしたい ◦ どんな人でも思考ツールとして使えるように • 自社プロダクトやサービス設計