見出し画像

2019-07-31 Google Cloud Next ’19 Day1 #GoogleNext19

2019/07/31 に開催された Google Cloud Next ’19 Day1 のイベントレポートです。

●イベント概要
ビジネス リーダーやエキスパートからクラウドの最先端を学ぶ
 クラウドを活用するビジネス リーダーやエグゼクティブ、開発エキスパートが一堂に会し、AI や機械学習、セキュリティ、インフラストラクチャなど最先端のクラウド テクノロジーをお届けします。クラウドでビジネスの価値を高めたいビジネス リーダーや開発者にとって、Google Cloud Next ’19 は多くの刺激を得る機会となるでしょう。

多様な学習プログラムでクラウドのスキルを磨く
 ビジネス イノベーションを生み出す Google Cloud の最新の製品やサービスに触れながら、技術的な知識を深め、スキルを磨きましょう。セッションからハンズオンまで、 Next ’19 の様々なプログラムを通して、最新のビジネス トレンドやテクノロジーを学んでみませんか。


■基調講演

阿部 伸一さん [Google Cloud]
ウルス ヘルツルさん [Google Cloud]

●かつてないクラウドを体験しよう
・クラウドを活用するには
  最先端の技術を知っていくジャーニー
・お客様に寄り添う
  カスタマーエクスペリエンスを高める
  生産性を高める
・世界中の事例を紹介

●大阪リージョン
・世界で20、アジアで7、日本で2番目
・海底ケーブルは3本目を引く

●ワークロードをモダナイズ
・クラウド上でもオンプレでも
・Anthos
  速度、管理性、使いやすさを解決
  一度書いたコードをどこでも
  オンプレ、GCP、他のクラウドでも

●ビジョン
・アプリケーション開発ソリューション
  オンプレミスのモダナイズ
    anthosでオンプレで準備->クラウドへ
    コンテナでセキュリティも
・DXプラットフォーム
  収集したデータからインサイトを得る
  cloud tpu
・各業界の特定の課題を解決するソリューション


■基調講演: DeNA

南場 智子さん [DeNA]

●DeNA
・1999年 立ち上げ
  元は経営コンサルタント
  3人の創業者
  ものづくりの認識が甘かった
    要件は自分たちで固めた
    つくりは外部のパートナーに任せていた
・2000年 内製化
  経営と技術の両方を話せる人を信じて進めた
  50億req / day
  3000台のサーバ
  数十人のインフラエンジニア
・2018年 オンプレ vs クラウドシフト
  運用工数の高まり
    オンプレの故障が増えてきた
    セキュリティでも

●クラウド派、オンプレ派に分かれてしまった
・D: クラウド
・Q: オンプレ = クラウド
・C: オンプレ
  クラウド化で3倍のコスト は、間違いだった
  使い倒せば オンプレ ≒ クラウドにできる
・最終的な経営判断の鍵は、人材だった
  創造的な仕事にフォーカスさせたい
・Cloud Shift
  「技術の蓄積が活かせないのはもったいない」は間違い
  知識があるからGCPのカタログスペック以上の依頼ができる
  GCPメンバーととことん会話
  -> feature request
  -> DeNAだけでなく、世界中へメリットが広がる

●Delight and Impact the World
・長く愛されるゲーム
  リターンレートを向上するための施策を蓄積
  ポケモンマスターズは All Cloud Native
・Anytime, Aywhere
  MOV, Anyca
・ヘルスケア
・スポーツ
  野球、バスケ
  -> まちづくりへ


■基調講演: メルペイ

曾川 景介さん [株式会社メルペイ]

●自己紹介
・3つのペイメントをつくった
  Mr.ペイメント

●メルペイ
・1,444億円の取引
・1,299万人
  -> 5,000億円規模
・リリースしてきた機能
  ID
  コード払
  後払い
  ネット決済

●メルペイのチャレンジ
・15ヶ月でのサービス立ち上げ
・マイクロサービス化
・金融関連事業のメルカリとの統合

●GKE, CloudSpanner など15以上のサービスを利用
・k8sの上で何をするか、だけに注力
・データベースには多くが求められる
  専任なしでバックエンドエンジニアが管理

●信用を創造して、なめらかな社会を創る
・お金がある人だけでなく
  どんな人でもやりたいことを実現できる社会を


■基調講演: アクセンチュア

関戸 亮司さん [アクセンチュア株式会社]
永吉 健一さん [ゼロバンク・デザインファクトリー株式会社]

●金融基幹システム
・1960 第1次オンライン
・1970 第2次オンライン
・1980 第3次オンライン
-> バブル崩壊後停滞

●正確に手続きを実施する形で進化してきた
・HWなどの技術的には効率的になった
・アプリは密結合、スピードには課題

●ゼロベースで次世代の金融システムを創る時期
・コアな機能をベースに、顧客体験をつくる
  クラウド、マイクロサービス、セキュリティ
・MAINRI
  CloudSpanner、BigQueryをベースにフルクラウド
-> ふくおかフィナンシャルグループを支援

●ゼロバンク・デザインファクトリー
  ふくおかフィナンシャルグループ

●サービス
・wallet++
  ネオバンク
・my Coin
  ブロックチェーンでポイント管理

●銀行機能は必要だが、今の銀行はいらない
  ビル・ゲイツ
  25年前

●次世代のバンキングと、その器
・東京-福岡でアジャイルな研究・開発
・GCPをフル活用したMAINRIがベース
・コアバンキングシステム
  マイクロサービスをどれだけスケールさせていくか
  新しい銀行象にチャレンジ
  ノアの方舟に載せたのは動物と職人


■基調講演: ガンホー

菊池 貴則さん [ガンホー・オンライン・エンターテイメント株式会社]

●ガンホー
・パズドラ、妖怪ウォッチワールドなど
・カプコンとTEPPENをリリース
・ビジョン
  新しい価値の創造
  感動と新しい経験を提供
・mspo
  新しいモバイル向けプラットフォーム
  初めてGCPを、フルコミットで採用

●なぜGCPを採用したか?
・広告収入モデル
  広告サービスとの親和性
  分析が強い、拡張性が高い
・Cloud Spanner
  初めて RDBMS以外を利用
  サポートで大きな壁にはならなかった
・BigQuery
  広告やゲームのデータを集約が簡単
  lookerを活用

●今後の展開
  AIを活用
  海外展開

タリク シャウカットさん [Google Cloud]

●ドラゴンクエストウォークもGCPで
  GKE + Cloud Spanner

●企業の可能性を広げる
  各ビジネスから、より簡単に使い始められるように
  セキュリティ、コンプライアンスも拡充
  go to market

イヤル マナーさん [Google Cloud]

●現状
・80% のワークロードがオンプレ
・75% がハイブリッドクラウド、マルチクラウドを想定

●Anthos
・オンプレでもクラウドでも、高速にデプロイ
・セキュリティも考慮済み
・マルチクラウド対応して、一貫した体験を
・3h以内でinstall、利用開始

佐藤 聖規さん [Google Cloud]

●プラットフォーム管理者はやることが多い
・ビジネスと安定稼働のためにやることは煩雑
・VMからコンテナへ

●Migrate for Anthos
・VMの書き直し、アプリの変更は不要
・DEMO
  VMの計画停止
  大規模なセールのためにHWを購入
    セール期間外は使わない
  CloudShell kubectl applyで一発
  -> GKEへデプロイ
・変換されたサービスはメッシュが構成されている
  テレメトリーも見れる
・ポリシーのサジェスト
  config repoにpush で GKEへ適用
・稼働場所に関係なく、同じ方法で管理
  GCP、オンプレ、AWSどこでも


■基調講演: NTTコミュニケーションズ

工藤 晶子さん [NTTコミュニケーションズ株式会社]

●NTTコミュニケーションズ
・NTTグループを再編
・グローバルICTパートナーとして発足
  柔軟性とスピードが必要
  -> GKE
  COTOHAで利用
・クラウド環境にデータを持ち出すのは不安という企業は多い
  Anthos + セキュアなインフラ、運用ノウハウでDXサポート
・Smart Health Care
  医療機関と連携してリハビリを支援
  患者一人ひとりに対応
-> SmartWorld へ

イヤル マナーさん [Google Cloud]

●GCPのserverlessプラットフォームで管理から開放
・コンテナの柔軟性 vs サーバーレスの機敏性

●Cloud Run
・サーバレスな能力をコンテナに
  どの言語、ライブラリ、バイナリでも実行可能
  オートスケール
  従量課金

●Cloud Run on GKE
・Knativeでポータブルに

●Cloud Code
・VSCode, IntelliJの機能拡張
・ビルド、デバッグ、k8sデプロイを簡単に

エイミー クリシュナモハンさん [Google Cloud]
寳野 雄太さん [Google Cloud]

●データ管理は拡張性が必要
・GCPでもバリエーションを網羅
・Windowsワークロードもサポート

●DEMO
・構成
  windows アプリ
  SQL Server
・GCPにWindowsServerイメージがある
・CloudSQL
  MSSQL -> FullBackup -> Cloud Storageへ
  import
  マネージドMicrosoftAD まもなくリリース
・CloudSQLのデータをBigQuueryから直接見れる

ピーター フィッツジェラルドさん [Google]

●事例
・GPU利用
  tensorflowの学習が55倍速に
・hadoop, sparkをGCPへ移行
  リードタイムが14倍早くなった
・モビリティ分野
  JR東日本
  Machine Visionで線路上の不具合を検知
・ホスピタリティを、物理とシステムでシームレスにつないでいく


■基調講演: JR東日本

小縣 方樹さん [東日本旅客鉄道株式会社]

●JR東日本のビジネス構造
・日本独特なので説明している
・上下一体構造
  非鉄道事業
  オペレーション
  メンテナンス
  インフラ
・水平一体構造
  首都圏〜東北
  新幹線でつないでいる
・収益構造
  1/3が生活サービス
・ビジネスモデルの展開
  鉄道
  -> 生活サービス
  -> 電子マネー
  -> 車両製造
  -> 海外
  -> MaaS

●STTTモデル
・シームレスな移動
  1 個別の事業が最適化
  2 すべての交通機関が協調して一貫輸送
  3 新しいモビリティ・ソリューションと統合
  -> あらゆるサービスと協調

●MTOMIモデル
・事業
  インフラ
    オペレーション
    メンテナンス
  テクノロジー
  マネジメント
 ↑
  |  価値をやりとり
 ↓
・お客様

●AI / IoT
・世界最大の乗客数
  1,790万人/日
・乗客のいる車両で、線路のチェック
  時間ベースだった運用から状態ベースへ

●Googleとの連携
・GooglePay + suica
・Googleアシスタント対応予定

バラバラになっている鉄道をまとめて
6つくらいにしたら日本はどうなるんだ?
-> 実現された

これからは
地域、人、心 をつないでいく


画像1

■Mercari U.S における CRM データ活用事例 - 機械学習によるクーポン最適化

アザマット べクナザロフさん [Google]
上原 優典さん [株式会社メルカリ]
田中 宏樹さん [Google Cloud]
現王園 浩士さん [株式会社メルカリ]

●Mercari USのCRM
1. パーソナライズ化されていないCRM
  プロダクトマーケ など
2. お客様の行動をトリガーにしたCRM
  検索、いいね など
3. 機械学習を活用したCRM
  レコメンデーション、離脱予測 など

●現状の課題
・リピート購入率を向上
  LTVを向上させたい
・リピート購入する顧客は一定数いる
  全員にクーパンを配りたくはない

●解決策の仮説
・Churn Prediction
  購入から3日間の行動
  -> 30日後の購買予測

●Churn Predictionの流れ
1. 既存のログ基盤の確認
2. トレーニングデータの選定
3. モデル学習、評価
4. パイプラインの作成
5. Churn Prediction に基づいたクーポン付与

●行動ログ
・アプリ内の主要な行動
  起動、商品のタップ、PVなど
・施策分析に必要な行動
  画面ごとの商品タップなど
・起点となる行動
  商品の購入、いいね

●ログ収集基盤
・システム構成
  API Gateway
  Cloud Pub/Sub
    大量の行動ログをjsonで投入
  Cloud Dataflow
    subscriber
    BigQueryと連携しやすい
  BigQuery

●トレーニングデータの選定
・探索的データ解析
  有効な特徴例
    アプリ起動回数 vs 後続購入スウウ
  無効な例
    配送日数 vs 継続購入有無
・トレーニングデータ
  BigQueryに保存

●機械学習基盤
・システム構成
  BigQuery
  Cloud Composer
    Cloud Dataflow: ETL
    Cloud Storage
      Normalize Data -> Training
      Prediction Result -> BigQuery
  Machine Learning
    Trainning models
    Hosted model -> Prediction Result
・Cloud Composer
  airflowベースのワークフローオーケストレーション
  DAGを構成できる
  他のGCPサービスとの連携が簡単

●Churn Prediction に基づいたクーポン付与
・クーポンの付与は日次バッチ
・SQLでシンプルに結果を取得

●機械学習の詳細
・特徴量 preprocessing
  BigQuery -> ETL
  Tensorflow
・モデル
  Wide & Deepモデル
    線形モデル
    ディープニューラルうネットワーク
    のハイブリッド
・ハイパーパラメータ調整
  AI Platformで自動調整
  評価指標
    損失平均値
    AUC
・今回のソースはすべてgithubに載ってます

●機械学習 & クーポンの成果
・99% ROAS
・+15% 継続購買率

●Next Action
・学習データの自動更新
・購買予測率に連動したクーポン
  迷っている人には今回のクーポンが効いた
  もともと辞めそうな人には効かなかった
  -> 施策を切り替えたい

ワンショットの機械学習は増えてきたが
改善サイクルを回せているところはまだ少ない


■GCP で構築する高性能かつスケーラブルなオンライン予測システム

大薮 勇輝さん [Google Cloud]
山崎 和博さん [NVIDIA]

●機械学習の現状
・機械学習に関する論文投稿数の推移
  ムーアの法則以上
・機械学習で解決できる典型的なタスク例
  視覚
  言語
  会話

●インタラクティブな機械学習サービスの例
・GauGAN
  雑な絵から意図を予測したした画像へ
・Magenda Studio
  ベースの音だけ -> 機会学習で楽器を追加
・多人数に体験を提供するには
  高価なクライアントは難しい
  モデルサーバで機械学習が必要
  -> 応答時間が肝

●オンライン予測システムの要件
・エンドツーエンドの応答時間
・ランニング個数との最適化
・スケーラビリティの確保

●オンライン予測システムの基本設計
クライアント
  GCP: 近くのリージョン
    ロードバランサ
    GKE: スケーラビリティ
      モデルサーバ
      Cloud GPU: 処理時間を短縮

●Cloud GPUの種類
・V100, P100, K80, T4, P4
  T4の費用対効果が高い
・NVIDIA Tesla T4
  Tensorコア 320個搭載
・NVIDIA TensorRT
  低制度(FP16, INT8)で推論を実行する
  推論オプティマイザ
  対応モデルサーバ
・TensorRT Inference Server
  TensorRT, caffe2, TensorFlowのモデルに対応
  サービスとGPUの監視ができる

●つまりこんな構成になる
クライアント
  GCP: 近くのリージョン
    ロードバランサ
    GKE: スケーラビリティ
      TensorRT Inference Server
      NVIDIA Tesla T4

※チューニングの全体像は、ブログに書いてます

●チューニングで確認する指標
・スループット、同時接続数
・遅延
・精度(認識率、検出率など)

●トレードオフポイント
・スループット vs 遅延
・スループット vs 精度
・遅延 vs 精度
-> GPUの処理特性をおさえて、考える

●GPUの特徴と特性
・特徴
  多数の計算コアが並列に動作
  メモリアクセスが高速
・特性
  並列動作が基本
  まとめて処理するほうが得意
    依存関係がないもの

●高速化するための方針
・バッチにまとめて処理
・同一のモデルを複数動かして並列処理
・CUDAカーネルもまとめる

TensorRT はフリーで使えるがクローズド
TensorRT Inference Server はgithubで公開

●TRTISのチューニングポイント
・リクエストをキューイングしてバッチ化
・1枚のモデルに複数モデルを並べて並列化

●事前にやること
・1モデル単体の性能評価
・目標値の設定
  スピードは簡単
  アキュラシー
    INT8に落とすときに顕在化
    キャリブレーションで

●試験した環境
・Locust
・1クライアントごとに 1画像 / 1秒 で投げる
・メトリクス
  リクエスト
    スループット
    遅延
  GPU
    GPU使用率
    GPUメモリ使用量
・Prometheusと連携して可視化

●チューニングの流れ
・性能確認・目標設定
・元モデルの評価
・TRT利用
  FP16化
  バッチサイズ、同時実行数調整
    INT8化
    バッチサイズ、同時実行数調整

●方針
・遅延が大きい & GPU使用率低い
  -> 小さくして、並列させる
・遅延が大きい & GPU使用率高い
  -> FP16、INT8化
・遅延小さい & スループットが足りない

●結果
・スループット 6倍
  = コスト 84%減


■GCP をフル活用した「KARTE Datahub」で挑む次世代のデータ活用

萩村 卓也さん [NRI digital, Ltd.]
倉澤 孝明さん [NRI digital, Ltd.]
宮原 忍さん [株式会社プレイド]
池上 純平さん [株式会社プレイド]

●KARTE
・いつもこの質問をさせてもらってます
  あなたのサービスに
  今誰が来て、どうしているか
  知っていますか?
・JS or SDKを入れるだけ
  アプリの改修なし
・オンライン/オフラインを問わずに対応
・レスポンスは 0.4秒程度

●KARTE Datahub
・あらゆるデータを集約して活用
・BigQueryが中心

●NRI
・シンクタンク、コンサルティングのイメージが強い
  実はITソリューションが大きい
・デジタル戦略
  デジタル戦略支援
  共創
  共同事業
・NRI digital
  GCPのMarketing Analytics Partner

●デジタルマーケティング
・プロセス
  データを集めて、理解して、行動する
  重要なのは集めて「何をするのか」
・利用しているサービス
  Analytic360 / Firebase
  KARTE
    -> BigQuery
・KARTE Datahubは分析で使っている

●次世代のデジタルマーケティング
・リアルの体験もデジタル化
  リアルでの行動履歴
  リアル行動に併せて情報提供
・リアル接点では取れなかったデータが取れるようになった
  webでしかできなかったことができるように
  来店、どう歩いたか + POSなど
    -> KARTE Datahub
・リアル デジタルマーケティングのユースケース
  オンラインデータ取得
  リアルデジタルデータ取得
    オンラインで見たものを実物で
  リアルデジタル顧客体験
    試着して買わずに帰宅
    迷った商品をレコメンドなど
  コンバージョン
・大手町で実証実験
  センサーデータ -> KARTEへ
    商品を閲覧、手にとった
    スマホサイト閲覧
    入店

--- パネルディスカッション ---
●リアル・デジタルマーケティングの具体的な使い所は?
・例えばアパレル
  ECとリアル店舗を持っている
・不動産、旅行なども相性が良い
  リアルとwebを行き来する
・どちらか一方だけだとシナジーは生まれにくい
・ニーズの探索中でもある

●なぜ KARTE Datahub を使うのか?
・データを集めて、理解して、行動する が一気通貫
・KARTEは、一人の人間をどこまで追いかけていけるか に強い
  N1分析で一人を追いかけた後、マクロで分析

●デジタルマーケティングやデータ活用はどうなっていく?
・リアルがデータ化していく
  えんぴつにセンサーが入って、何を書いたかわかるようになる
  のようなイメージ
・取れるデータの粒度が細かくなってきている
  手にとったはわかるが
  どれ持って、どこに戻したは、まだ取れない
  こういうものが見えるようになっていく
・中国では、カメラの情報から、誰がどこにいるのかがわかるようになっている
  交通事故があったも、普段との差分から検知できる
  蓄積したデータを活用していく は、あらゆる分野で実現できる

●KARTE や GCP に期待することは?
・十分満足している部分はあるが
・IoT MQTTなどの受け口が広がってほしい
  Cloud PubSubなど
・入り口だけでなく出口も
  何かしらのアクションが必要
  サイネージに出すとか
  まだ模索中ですが
  スマートスピーカーなども面白いですね

●パーソナライズ vs 個人情報 の打開策はある?
・オンライン
  規約や法律をおさえる
・リアル
  道路の画像を使うとして
  一人ひとりの確認を取ることは無理
  掲示で進めている

  どこからが個人情報という線引きも大切
  人らしき物体を捉えていて、個人として捉えていない など
  オープンスペースでは個人を特定しない


■Edge TPU でインテリジェントな IoT サービスの実現

Ajay K Nairさん [Google]
吉川 隼人さん [Google Cloud]

●AIの導入は急速に拡大している
・論文の数は2015〜17で大きく伸びている
・ニーズはあらゆる業種に
  自動運転、コネクテッドデバイス
  家庭でも必要な要素に

●AIのユースケース
・製造
  予知保全で現場でエッジで対処していきたい
・旅行
  カメラで健康状態を把握
など

●求められるエッジAI
・Googleの観点だと
  クラウドの外側で動かすこと
  データセンターもエッジと読んでいる
・プライバシー
  有用なデータはクラウドへ
  プライバシーデータはエッジで留める
・レイテンシ
  自動運転だと、反応が遅れれば命に関わる
・帯域幅
  30fps, 1フレーム24MB
  有用な情報に絞りたい
・オフライン
  採掘場所など重機械が動いている現場
  故障を把握したい
・コスト
  運用コストも含めて

●高度なAIはエッジで強力な計算が必要
・流れ
  画像
  ↓ ダウンサンプル
  224 x 224
  ↓ 推論
  このサイズでもリソースをかなり使う
・Edge TPUを開発
  MobileNet v2

●Coral
・ハードとソフトのコンポーネントを含むスイート
  すべて合わせるとEdgeTPUにつながる
・主要製品
  開発ボード
    2つのボードが提供されている
  USBアクセラレータ
  SOM
    4 TOPS / 2w
  PCI-E アクセラレータ
・Edge TPUのパフォーマンス
  組み込みCPUの最大100倍
・MLモデル
  Googleデータ x Googleのモデル
  顧客のデータ x Googleのモデル
  顧客のデータ x 顧客のモデル

●アイデアから提供までを高速に
  プロトタイプも本番も

●IoTはほとんどの業種業界で使われている
・製造業: 外観検査
  目的
    キズなどのポカよけ
    人の目 or 専用機器だった
  エッジ
    検査時間 = コスト
    -> エッジで高速に推論
  クラウド
    学習データの収集
    学習の計算リソース
    検査結果の集約&モニタリング
・小売: 顧客動向の監視
  目的
    店内の行動
    プライバシーの考慮が必要
  エッジ
    顔画像はクラウドに送らない
    人物検知
  クラウド
    検知結果のみを送信

●DEMO
・Coralの開発ボード(MobileNet v1)
  有線でssh接続
  ラズパイと同じサイズ
  画像はクラウドに上がっていない
・クラウド
  -MQTT-> IoT Core
  -> Cloud Dataflow
    -> BigQuery
    -> Firestore
      -> AppEngine

●Cloud IoTでエンタープライズスケールにする
・データを貯めて、インサイトを得て、何かをする
  設備 -> Gateway -> WAN -> クラウド
・Cloud IoT Core
  用途のグループで管理
    個々のデバイスをconfig、ステータスチェック
    デバイスを用途ごとでグルーピング
    グローバルにスケール
    接続数は無制限(デフォルト 10万)
  MLモデルの配信・管理
    パワーオン時に最新版確認
    デバイス個別にモデル管理
    最新のモデルを配信
  データ収集 - 学習 - 配信のサイクル
    GCPに部品は揃っている
    組み合わせるだけ


■BigQuery を活用した既存データ分析サービスのマイグレーションと新規事業開発事例

橋本 久さん [パーソルキャリア株式会社]
竹村 博徳さん [株式会社 True Data]
池田 陽一さん [株式会社 True Data]
吉積 礼敏さん [クラウドエース株式会社]
高野 遼さん [クラウドエース株式会社]

●Cloud Ace
・GCP専業のプレミアパートナー
・日本、アジアで 9拠点
・サービス
  GCPカスタマーサポート
    決済、3%割引、サポートプラン
  SI、受託、コンサル
    クラウドブースター
  GCP認定トレーニング
・8つのSpecialization
  世界で一番
・書籍
  GCPの教科書など

●BigQueryの可能性
・BigQueryとは
  サーバーレスDWH
  高スケーラビリティ
  コスト効率が良い
・当たり前が変わった
  1. 誰でも高品質なDWHを安く持てる
    個人〜中小企業〜大企業まで
  2. 誰でもMLをいつでも開始できる

●変化の要因
・サーバーレス
  データの収集、分析に注力できる
・ペタバイト単位でスケール
  容量を気にしなくて良い
・BigQuery BI Engine
  BigQueryはフルスキャン
  BI Engineをオンにすればサクセク
・リアルタイム分析
・BigQuery ML
  テーブルデータを用意
  予測したいカラムを選択
  既存のデータでトレーニング
  評価/活用

これを活用できるかどうかで
生まれる差をどう捉えるか?

--- カウンセリング音声のビジネス活用 ---
●PERSOL
・日本の人事部長
  この国の「はたらく」を全部
・パーソルキャリア
  an
  LINEバイト
  doda
・データソリューション部
  テクノロジーを使ってデータを価値あるものに変えていく
  ビジネス、アナリティクス、エンジニア

●ビジネス課題
・カウンセリング
  転職希望者 と キャリアアドバイザー で会話
・内容は可視化できていなかった
・2人の声を切り分けて集音
・スマートスピーカーでリアルタイムにテキスト化

●音声データの活用
・キャリアアドバイザーの育成
  ハイパフォーマーの会話で学ぶ
・カウンセリング履歴入力の削減
  手入力 -> コピー
・マッチングへの活用
  Speach To Text
  -> Natural Language API
    転職理由、希望条件、感情抽出
  -> BigQuery
    転職移行、score抽出
    キャリアアドバイザーの発言のポイント
  -> 求人案件データベース
    マッチング精度向上

●導入のポイント
・音声って面倒。なぜやったの?
  クラウドエースに知見があったから
・導入の敷居が高い
  GCPだとイニシャルコストがかからない
  認識率も高かった
・チャレンジングな施策
  サポート企業と良好な関係が必要

--- 視覚購買行動データ商用分析サービス Eagle Eye ---
●TrueData
・ポイントカードの購買履歴を持っている会社
・日本最大級のID-POSデータベース
  5,000万人分
・データ量
  2004 数億件
  2017 数百億件
  13年で100倍

●Eagle Eye
・ID-POS分析のSaaS
・誰でも簡単に使える
  操作性、スキルレス、ビジュアライズ
・BigQueryで、高速に大量データに対応できた
  取り扱えるデータ量が1000倍に拡大
  10億件ごえのスキャンが数分で返ってくる

●IT Transformation
・方針
  全商用分析サービスを GCP、BigQueryへ
・課題
  最大スケールに合わせた環境が必要
  オンプレの制約がたくさん
・優先順位
  基幹サービスから着手

●懸念点
・料金
  BQに適合させて抑えた
・くせ
  シャーディング、パーティショニングを正しく
・安定稼働
  マネージドサービスだから返せないときもある
  リトライありきで処理
-> GCPの伝道師クラウドエースと一緒に解消

●どのくらい早くなった?
・処理が集中するときに、返せない -> 返せる
・数時間 -> 数十分へ

●今後の展望は?
・新商品好き度ランキングなどのEagleEyeに組み込みたい
・増えていくペイメントサービスに対応


■Google Cloud Healthcare API や GKE を活用した新世代の診療支援

水江 伸久さん [Google Cloud]
北村 直幸さん [株式会社 エムネス]

●医療のDXに必要な条件
・インフラ
  セキュリティ、コンプライアンス、信頼性、低コスト
・互換性
  標準化されたデータ
・インサイト
  ワークフローと統合

●クラウドを導入する理由
1. アジリティ
2. セキュリティ
3. 経費削減

●セキュリティ
・第三者セキュリティ評価
  GCPは最高評価
・データ処理に関する規約
  Googleはデータ見るんでしょ?
    コンシューマ向けと企業向けで規約は異なる
    データへの制限がある
    -> データはお客様のもの
・ハードウェアから独自設計
  チップ、サーバ、ストレージ、ネットワーク、データセンター
  セキュリティのための専用チップTitan
  インフラのセキュリティはデフォルトで有効
    HWなどの低レイヤから、ユーザの操作まで
・デフォルトの暗号化
  データをupすると必ず暗号化される
・Live Migration
  meltdown, spectreなど大規模な更新も中断なし
  他のクラウドベンダーでは再起動祭りだった

●ヘルスケア
・ヘルスケアに関連する認証はすべて取得
  HIPAA
  3省3ガイドライン、FISC、NISC、CSVなど各種ガイドライン
・専任のチーム
  ヘルスケアの専任チームがいる
・ヘルスケア業界の標準仕様をネイティブサポート
  Cloud Healthcare API
    HL7 v2, FHIR, DICOMなどに対応
    東京リージョンでも利用可能
  標準仕様にのっていれば、保存、分析、匿名化を実装済み
    DICOMの画像に含まれる個人情報を削除したり
  BigQuery, Tensorflowなどに連携できる
    BigQueryにエクスポートして、更に詳細な分析へ
  予測の結果を返すこともできる

●エムネス
・日本の現状は、画像をとっても、専門医が見れない状況
  -> 遠隔画像診断
・ルックレック
  DICOMの画像を提供するサービス
  画像診断医のネットワークを提供
  すべてをGCP上で実現
    インターネット + Googleアカウント があれば利用できる

●しくみ
CTやMRIなどの機器
  -> ストレージ
    <- 診断補助AI
    -> どこでも画像診断
    -> 患者さんへ提供

●事例
・モンゴルへ導入
  医療の発展途上国はたくさん
・CT/MRIなどを持たない病院の現状
  持っている病院へ依頼
  患者さんに、撮影しに行ってもらい
  印刷して、もとの病院へ郵送
  患者さんに、帰宅してもらう
  郵送が到着後
  患者さんに、もとの病院へ
  -> ルックレックで効率化
・AIが医師をアシスト

●Healthcare APIがデータを橋渡し
・ルックレック -API-> AIベンダー
・装置メーカーがAIを開発するのが主流
  装置メーカーのAIしか利用できない
  -> ユーザー側がアルゴリズムを選択できる状況へ

●患者自ら画像を管理
・画像は患者のもの
  今は、依頼すると追加必要がかかる
  -> 生涯に渡って画像を保存
    -> 必要に応じて医師に見せる
・スポーツ選手が遠征先で負傷したら
  今は、地元に戻って、チームドクターに診てもらう
  -> 現地の医師に診てもらう

●PHR: 医療データのライフログ
・病理データが一番重い
・他のデータも取り扱えるように
  血液検査、服薬履歴、カルテ など

●目指すところ
  世界中どなたでも、どこにいても、いつでも
  高度な医療を受けれる状況を整える


■Day2の様子


■感想

GKE x BigQueryの事例が増えてきましたね!
Anthos と Migrate for Anthos で、GKE(k8s), CloudRun の導入はぐっと敷居が下がった印象でした。BigQuery、AI、IoTを組み込んだシステムのライフサイクルも型化されてきているので、predictionをサービスに組み込むのが当たり前になる日も近そうでワクワクしますね!

登壇者の皆さん、運営の皆さん ありがとうございました!
明日も楽しみです!!


この記事が参加している募集

いつも応援していただいている皆さん支えられています。