国内月間アクティブユーザ数8,400万人
メッセンジャーだけではなく、
サービス上で提供される情報やコンテンツのデータサイズ、
日々データが大量に蓄積・
LINE社内における機械学習を活用した企画やプロジェクト・
菊地 悠 氏
そのDSEセンター傘下にある、
後編では、
Machine Learning1チームの周辺組織との関わり
社内ツール「LIBRA」を活用したA/Bテストでのチーム間連携
- ――LINE DEVELOPER DAY 2019で、
DSチーム高口太朗氏のセッション 「コミュニケーションアプリ では、「LINE」 の機能改善を支えるデータサイエンス」 「LIBRA」 や 「Shiny」 といったツールを使用した、 MLチームとDSチームの業務上のコミュニケーションの一端が解説されていました。
MLチームの方は、これらのツールを使用して、 周辺のメンバーの方々とどのようなコミュニケーションを取りながら業務に取り組んでいるのでしょうか？ 「LIBRA」 は、 A/ Bテストを行うための設定情報を管理・ 定義する、 かなり簡素なシステムです。社内のサービスに推薦システムの導入が進んできて、 新たなエンジンへの改善ニーズが高まってきたこと、 DSチームのデータサイエンティストが個別にA/ Bテストの設計を行っており、 共通化のメリットが高そうなことから、 2017年末くらいから、 検討・ 導入を進め、 最近では社内の標準的な環境になりつつあります。 たとえば、
より使いやすいUIを決めるにあたり、 実験計画と実際のA/ Bテストの実施・ 検証をDSチームだけで行う場合もありますし、 機械学習が関わるSmart Channelのようなプロジェクトにおいて、 エンジンの変更や機能追加・ 設定変更などに関して、 A/ Bテスト実施のサポートをお願いするようなこともあります。 A/
Bテストの設計というのは、 たとえば1%のCTRが見込まれる表示領域の修正を行うにあたって、 「どれくらいの変化量を、 どれくらいの確からしさで検出したいか」 を決めた上で、 「どれくらいのユーザに、 どれくらいの期間、 試してもらうか」 を決めることに相当します。 また実験計画という観点では、
試したいパターンが複数存在するような場合に、 1度にまとめて行うべきか、 複数回に分けて実施すべきか、 といった検討をすることもあります。LINE DEVELOPER DAY 2019のセッションで、 弊社の高口が解説しているように、 1回にまとめてA/ Bテストを実施しようとすると、 多重比較の問題による偽陽性の可能性や、 偽陽性を抑えるためにサンプルサイズが大きくなりすぎる問題が生じることもあります。 高口のセッションでの例は、
LINEのメッセンジャーにおけるグループ作成手順のわかりにくさを改善させるために、 「招待するユーザの友だちリストの並び順」 「手順の画面数」 を変更させる改善を組み合わせた、 4パターンのテストについて、 2回に分けて、 3パターンのテストにする、 という内容でした。 たとえば2つの機能のテストをまとめて行おうとすると、
4群のA/ Bテストになります。A～Dの4パターンで考えると、 有意差に関する検定は、 AとBの比較、 AとCの比較…、 という風に数えることになり、 合計で6つのペアを比較しなければなりません。 このような場合は単純に2群
（2パターン） でのA/ Bテストを2回行う方が、 サンプルサイズも小さくて済む上に、 結果の解釈もシンプルになります。 UIの検証の例は、
ML1チームは関与していませんが、 前回紹介したSmart Channelについては、 DSチームに協力してもらいながら、 A/ Bテストを行っています。 当初は単なるテストの設定情報のみを提供していたLIBRAですが、
Smart Channelでは、 システム的な連携をかなり盛り込んでもらいました。このため、 前編で紹介したバンディットアルゴリズムのA/ Bテストを行いながら、 同時に個別サービスのロジック、 たとえばSmart Channel向けのスタンプのレコメンドのA/ Bテストも実施する、 といったことが可能になっています。 また、
A/ Bテスト実施の際のログがリアルタイムで出力されることから、 LIBRA上でも、 リアルタイムのテスト結果が確認できるような機能追加を行いました。 A/
Bテスト実施時の分析の実務にあたっては、 DSチームに協力を仰ぎながら、 A/ Bテストの仕組み自体を導入したり、 社内の他システムとの連携をしたりなどを含め、 開発に関わる部分はML1チームがメインで担当しています。
エンジニアやデータサイエンティストの裁量に委ねられた開発ツール選定
弊社では、
さまざまなサービスのデータをきちんと取ったら、 それをダッシュボードなどで常に確認できるようにする、 という文化が根づいています。個人的におもしろいと思うのは、 この際に使われるツールが1つだけではなくて、 かなりの部分がデータサイエンティストの裁量に委ねられている点です。 たとえば、
Shinyは統計ソフトR上での分析結果をWebアプリとして公開するためのRのパッケージですが、 弊社のデータサイエンティストにはRをメインで利用しているメンバーも多く、 こうしたメンバーはShinyを使っています。 その他、
Tableauを使ったり、 内製の 「OASIS」 というツールを使ったりもしています。OASISは PythonもRも使える上に、 SQL （SparkSQLやPrestoなど） も利用できるので、 ML1チームでも、 他組織に何かを共有する際に、 OASISを使うことは多いです （チーム内部の検証ではJupyterを利用しています）。 他にも
「conflr」 というLINE発のオープンソースソフトウェア （OSS） で、 R Markdownで書いた分析内容を直接Confluenceのwikiページへと出力できるツールもあります。DSチームの中にも、 エンジニアリング指向の人が混ざっていたりする点は、 おもしろいと思います （※）。
これからのDSEセンターが目指す役割とは
- ――3月に組織再編をされましたが、
それによる変化は起きていますか？ 前編でも少し解説しましたが、
現状のDSEセンターへと体制整備がされる前は、 各サービスを担当している社内の企画者から直接要望をヒアリングして、 機械学習を活用したレコメンデーションなり、 個別のソリューションなりを提供する、 といったテイラーメイドの開発事例が主流でした。 
しかし、
現体制に変わってからは 「LINE全社に対し広くソリューションを提供すること」 がより強く求められており、 プロダクトの共通化できる部分は共通化する、 ということを意識して開発しています。 共通化する部分の例としては、
機械学習における特徴量データの加工などが挙げられます。 特定のサービス
（たとえばLINE NEWSの記事閲覧や、 LINEマンガの購買ログ、 Smart Channel上での行動ログなど） のユーザの行動ログを、 共通のフォーマットに整形し、 機械学習開発をしている社内の他組織にも提供しています。
ユーザのプライバシーを最優先に考えたデータの取り扱い
- ――データの加工や活用をする上で無視できないのがプライバシー情報の扱いだと思います。昨今、
機械学習を活用したサービスにおいては、 サービス事業者に対して説明可能性 （解釈性） が求められることがよくあります。
ユーザからのデータを基にさまざまなサービスの開発・展開をされているLINEの、 機械学習を活用した開発の解釈性に関するご見解をお伺いできますか？ まず、
トークの中身など、 LINE社のプライバシーポリシーで厳格に扱わないと明記されているデータは、 我々ML1チームが利用している分析環境では参照自体ができません。 ML1チームやDSチームが分析や開発に使用しているHadoopクラスタには、
先の機微なデータはあらかじめフィルタリングされています。その上で、 さらにアクセス制御により、 利用可能データが厳しく管理されています。 Hadoopクラスタにデータを取り込む過程では、
必ず、 弊社の情報セキュリティ部門や法務部門のレビューやチェックを通しています。 ただし、
ひとつひとつのデータはプライバシーに影響を及ぼさなくても、 複数を組み合わせると個人を特定しやすくなってしまう場合があるため、 確認できる情報量が増えると、 ユーザのプライバシーに懸念が生じてしまうデータになる可能性はあります。 こうした事情も踏まえ、
ユーザの行動ログについては、 機械学習を利用して、 データを圧縮したり、 その過程で人間には解釈ができない特徴ベクトルに変換したりする、 といった取り組みも行っています （※）。
- ※）
- Feature as a Service at Data Labs
（LINE Machine Learningチーム Senior Software Engineer Chaerim Yeo氏）
LINE、そしてLINEの全社横断組織であるDSEセンターだからこそのやりがい
- ――LINE、
そしてDSEセンターだからこその開発内容や環境などの特徴はありますか？ またさきほどご説明いただいた組織構造の変化によって今後はどうなっていく予定でしょうか？ 私の在籍するML1チームは、
組織再編後に 「Data Platform室」 との距離が近くなり、 一緒に仕事が進めやすくなりました。 Data Platform室のメンバーは、
弊社内の大きなデータを扱うインフラ系の開発や運用にも携わってきた面々がおり、 大規模データの取り扱いに関しても高いスキルをもっています。 機械学習のシステムをいざ組む際に、
Data Platform室のメンバーがバックエンド部分の開発を担ってくれることは、 ML1チームとしても心強く、 以前よりも大きなことにチャレンジできる環境へ変わりつつあると感じています。 LINEならでは、
という観点だと、 弊社はメッセンジャー以外にも多種多様なサービスを展開しているので、 それぞれの領域において、 何らかのデータ分析や機械学習が必要となる企画やプロジェクト・ プロダクトが常にあります。 ある1つの特定のサービスに根を詰めて開発を深めていくというよりは、
エンジニア本人の希望次第で、 さまざまなサービスやデータに触れながら飽きずに仕事ができる、 という魅力があると自負しています。 - ――LINEで働いている機械学習エンジニアの方々が感じているやりがいや魅力を教えてください。
やはり弊社で扱う大規模で多様なデータを使用して機械学習開発をやる、
ということに対して、 やりがいや魅力を感じる機械学習エンジニアが多いようです。 データの規模が大きくなると、
市中では問題なく使えているライブラリなどでは十分な性能が得られないことも珍しくなく、 しっかりとサービスが運用できるように低レイヤーから自前で開発する、 ということもあります。あるいは機械学習モデルの複雑性と扱うデータ量、 処理性能などのトレードオフの問題を検討しないといけない場合もあります。 一般的にソフトウェアは、
複雑性を隠蔽して、 あとからソフトウェアを扱う人にも使いやすくなるように提供する、 といったサイクルを繰り返して改善・ 発展すると考えています。 弊社では、
扱うデータの規模が非常に大きいがゆえに、 扱いづらいシステムを扱いやすくするというレイヤーの仕事がまだまだ残っています。 そういった面において、
エンジニア・ 技術者にとっての 「腕試し」 ができると魅力を感じて、 仕事に取り組んでいる機械学習エンジニアは多いです。 データサイエンティストに関しても、
扱えるデータの規模やA/ Bテストをやって結果が出るまでの時間がものすごい短いというところに、 魅力を感じて仕事のやりがいを感じている人は多いようですね。 扱うデータの規模感やスピード感を求める方にとっては、
非常に魅力的な環境だと思います。 - ――本日はありがとうございました。
以上、
LINEの機械学習エンジニア、
当記事中にもところどころ、
今年は初のオンライン開催となり、
幅広いジャンルの先進事例を知ることのできる