LINEで働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」の第8弾です。当コーナーでは、インタビュアーにLINEで働くエンジニア tokuhirom を迎え、エンジニア同士でざっくばらんに話を聞くという形で進めています。今回も、LINEのエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。

第8弾は開発1センターBパートの小野侑一さんに、BOTの開発者がユーザーとやりとりするために使用するMessaging APIの中でも、2016年にリリースされたTemplate Messageと、2018年6月にリリースされたFlex Messageの開発に至った流れやこだわり、今後の展望について聞いてきました。

ざっくり言うと

「Flex message」は自由にレイアウトしたメッセージを送信可能

CSS Flexboxをベースにしているため、Webデザイナーにもとっつきやすい

社外からのフィードバックを積極的に受付中

―― tokuhirom
よろしくお願いします。入社されて何年目ですか？というのと、現在どのようなお仕事をメインでしているか教えていただけますか

―― yuichi
入社して4年目です。僕のいるチームでは、一般のユーザーアカウント部分と、それ以外の企業アカウント（LINE公式アカウント/LINE@）やAPI BOTに関する部分で担当が分かれています。僕は後者で「Bパート」というチームに所属していて、一般のアカウントとは少し違う「友だちが100万人いるアカウント」など特殊な独自のシステム開発をしています。

―― tokuhirom
Bパートの中ではなかなか古株ですか？

―― yuichi
そうですね。最近は、新卒社員がわりと入ってきてくれているので、人数も増えています。

―― tokuhirom
ちなみにBパートの「B」ってBOTの「B」じゃないんですね。

―― yuichi
諸説あります。「バルス」からきているんじゃないかと聞いたこともあるのですが、実際はよく分かっていないです（笑）

―― tokuhirom
小野さんがBパートに入られた時は、BOTの開発はある程度進んでいたんですか？

―― yuichi
僕が入った時にはすでにBOTの仕組みはできていたんですが、API BOTが普及するにつれて一度に何百万の一般ユーザーに配信されるようになってきたタイミングだったんです。配信するアカウントの数が増える中で、いかに大勢のユーザーに素早く配信するか、大規模アカウントが同時に送信しても詰まらないようにフロー制御を行なったのが始まりですね。
最近では、Messaging APIというBOTの開発者がユーザーとやりとりするために使用するインターフェースを活性化させるために、機能を充実させる開発をメインで行なっています。

Template Messageの開発

―― tokuhirom
BOTの機能として、どれほどの大人数に配信できているのかは結構気になりますね。小野さんは、Messaging APIのインターフェースの開発段階から関わっていたんですか？

―― yuichi
チームには入っていましたが、自分で仕様を決めるなど深く関わり始めたのは、Template Messageからですね。

―― tokuhirom
なるほど。具体的にTemplate Messageというのはどういう機能ですか？

―― yuichi
Template Messageは、あらかじめ決まったレイアウトに沿ってメッセージを送る機能のことで、2016年にリリースしました。
もともとテキストや画像を送信する機能はあったのですが、企業アカウントの利用者からは、いま風のカード型のメッセージを送りたいという要望があったんです。テキストと画像を組み合わせたリッチなメッセージを送れるようにするためにTemplate Messageの開発を始めました。 左から、ボタンテンプレート、確認テンプレート、カルーセルテンプレート、画像カルーセルテンプレート

旧来のTemplate Messageでは補えなかったFlex Messageの開発に至るまでの経緯

―― tokuhirom
社外の人からも、「Messaging APIの中で、Template Messageは以前の仕様に比べるとかなり使いやすくなった」という感想はよく聞きます。

―― yuichi
以前の仕様は、社内向けのAPIを無理やり外部向けに公開したような流れだったんですが、「さすがにこのままではいけないだろう」と思い、かなり急ピッチで仕様を変更しました。

―― tokuhirom
Template Messageの仕様は策定からがっつりと関わっていたんですか？

―― yuichi
そうですね。Template Messageの見た目はシンプルなんですが、内部実装は難しいです。仕組みとしては、JSONからHTMLを生成してそれをWebViewで表示しているので端末のWebViewの仕様が表示に影響するんです。例えば「iOSの最新版なら大丈夫だけど、Androidの古いバージョンだと変に表示されてしまう」みたいなことがすごく多いんですよね。

―― tokuhirom
LINEがサポートしているAndroid端末だと結構画面が小さいものもありますもんね。

―― yuichi
Template Messageを使った人の中には、「なんでこんなに文字数の制限が多いんだろう」「なんでこの形のURLでないとだめなんだろう」と感じる人もいらっしゃると思います。でもそうしないと、正常に表示されない端末が出てきてしまうんです。そんな諸々の制限を回避するために、今の形になっています。

―― tokuhirom
Template Messageでは、APIではJSONで送られているけど、それをサーバー側でHTMLに変換してるんですね。

―― yuichi
そうです。HTMLに変換するという実装自体は複雑なものではないので、各OSに合わせて仕様を擦り合わせていくことがメインでした。

―― tokuhirom
文字数の制限やURLの他に、具体的なTemplate Messageへの不満はありますか？

―― yuichi
文字の色や大きさを変えたり、画像をもっと自由に使ったりしたいという要望が多いです。
我々の不満としては、WebViewの細かい挙動が度々変わるんですよね。何もしていないのに表示がおかしくなることがあって調べると、OS側のWebViewの仕様が変わったことが原因であることが結構あります。あと単純に、重いですね。

―― tokuhirom
トークルームにWebViewをたくさん入れたら重くなりますよね。

―― yuichi
1個2個なら問題ないと思うんですが、あれが10個も100個もあると大変ですよね。しかも表示に何百ミリ秒もかかるので、ユーザーが体感で気づくくらいには時間がかかるんです。そこが結構不満ですね。

―― tokuhirom
そのあたりの不満があって、Flex Messageの開発につながると。

―― yuichi
そうですね。一番の不満は、相変わらずメールのようなテキストベースの情報しか送れていないことだと思います。今はAIが発展してBOTも結構賢くなっているにもかかわらず、情報としてあまりリッチな情報が送れないな、と。
ユーザーは本当は自由にデザインしたHTMLを送りたいと思ってるはずなんです。でもそれを実現するのはセキュリティやパフォーマンスの問題があり難しい。デザインとセキュリティ、パフォーマンスのバランスを取った新しいメッセージフォーマットが求められる流れの中で、Flex Messageの仕様が固まっていきました。

CSS Flexboxのアルゴリズムを採用した Flex Messageの開発

―― tokuhirom
Flex Messageとはどういった機能なのでしょうか？

―― yuichi
Flex Messageは、ある程度自由にレイアウトしたメッセージを送れる機能で、2018年6月にリリースしました。レイアウトアルゴリズムとしてCSS Flexboxを採用していて、Flex Messageの「Flex」はFlexboxの「Flex」です。Flexboxの仕様を引き継いでいるので、一部のプロパティ名はCSSの仕様をそのまま採用しています。
―― tokuhirom
そうだったんですね。単にフレキシブルだからFlex Messageなのかな〜と思っていました。名前の由来って自社の説明ドキュメントに載っていましたっけ？

―― yuichi
載っていません。実は、僕の心にしかないんです（笑）

Flex Messageの優れている点

―― tokuhirom
Flex Messageが優れている点を教えてください。

―― yuichi
いっぱいありますよ。一見すると単純に割合ベースで格子状にレイアウトしてるだけのように見えるんですが、実際にはいろいろなアルゴリズムが含まれています。例えば、メッセージのサイズが変化してもメッセージに含まれる画像の縦横比が維持されるようにしています。そのために、メッセージの横幅が変化したら高さも再計算するようにしています。
あと、Flex Messageを横に並べた時に、内容によってはそのままだと高さが不揃いになりますよね。

―― tokuhirom
確かに。

―― yuichi
それをキレイにそろえるために、メッセージのボディサイズを自動的に調整しています。



―― tokuhirom
へええ〜、全然気にしていなかった（笑）

―― yuichi
単純にみえますけど、実はすごく複雑なアルゴリズムなんです。だからあまり自前で実装したくなかったんですよね。

そこで目をつけたのが、CSSのFlexboxという仕様です。ブラウザのように画面のサイズが変化する中で、画面要素を柔軟にレイアウトするためのアルゴリズムですね。そのCSS Flexboxが仕様の土台になっていることがFlex Messageの特徴です。その点で、HTMLに慣れている人はすんなりと使い方を理解してもらえるのではないか、という意図もあります。

ネイティブアプリ上でCSSのレイアウトを実現するYoga Library

―― tokuhirom
今もHTMLのWebViewで表示させていることは変わっていないんですか？

―― yuichi
CSSのFlexboxの仕様に則っているので、現状はWebViewでCSSを使ってレンダリングしている状態ですね。変わらずWebViewで表示させているのでTemplate Message以来の欠点は変わっていなかったんです。
でも、iOSやAndroidの開発メンバーが、React NativeではレイアウトにCSSのFlexboxを使っているということを教えてくれたんです。
※ReactNative…Webの技術（React.js）を使ってネイティブアプリを開発するフレームワーク

―― tokuhirom
WebViewじゃないのに、CSSのFlexboxのアルゴリズムを使って、アプリをレイアウトしているんですね。

―― yuichi
そうです。レイアウトエンジンとして「Yoga」というFlexboxを実装したC言語のライブラリを採用しています。
これを使えばWebViewを使わなくてもFlex Messageを実装できるのではないかと思いクライアントメンバーに「デモを作ってくれないか」と相談したら、すぐにできちゃったんです（笑）そこから話が一気に進み、7月末にネイティブ版をリリースすることができました。

―― tokuhirom
なるほど〜、すごい。

―― yuichi
今までのTemplate MessageやFlex MessageはHTMLベースだったので、デスクトップ版に移植できなかったんです。でもYogaはC言語で開発されているおかげで、MacやWindowsのデスクトップ版のLINEアプリにも組み込むことができるようになります。Flexboxに則ったことにより、いろんな話が進んだという感じですね。

―― tokuhirom
せっかく便利なメッセージが追加されても、デスクトップ版で使えないと悲しくなることはありますよね。あと、デバッグが辛い。ネイティブアプリになることで、近々Flex Messageの表示は軽くなるんでしょうか？

―― yuichi
その比較が出来るものを持ってきました。

WebView版とNative版のレンダリング速度を比較しているんですが、目でみてわかるほど違うんですよ。
編集部注：左がNative版、右がWebview版。わかりやすくするため、実際の画面描画速度の1/10にしています
―― tokuhirom
なるほど、たしかにずいぶん違いますね。

―― yuichi
Native版はレンダリングがほとんど一瞬ですが、Webview版はかなり表示が遅れてます。でも表示後の見た目は全く一緒ですよね。僕もどっちがどっちかわからない。

―― tokuhirom
いいですね。Native版では、制限されていた文字数も解消されますか？

―― yuichi
メッセージ全体でのサイズ上限はありますが、個々のテキストに対する上限はなくなりました。かなり自由度が高くなったと思います。

海外で活性化しているBOT開発

―― tokuhirom
僕らはMessaging APIのSDKを作っていますが、Flex Messageは最近の機能の中でも特にユーザーから「早く対応してくれ」という声が多いです。

―― yuichi
国内だけでなく、海外でもBOT開発は活発です。台湾やタイなどのデベロッパーがBOTの解説記事などを書いてくれているんですよね。我々よりもはるかにリッチなシミュレータとかを作ってくれていて「このシミュレータ、そのまま使いたいな」って思ってます。

―― tokuhirom
なぜ我々のシミュレータは負けてしまったのか（笑）

―― yuichi
我々のシミュレータは片手間に僕が作っているやつなんです。それだけタイや台湾ではとてもBOTが活性化しているんだと思います。

Flex Messageの国際化対応

―― tokuhirom
Flex Messageについて、他に進めていることはありますか？

―― yuichi
国際化対応を結構頑張っていて、Flex Messageでは書字方向の設定に対応しています。書字方向というのは「テキストを書く方向」のことで、例えば英語や日本語では左から右に表示しますけど、アラビア語ではその逆ですよね。テキストだけでなくメッセージ内部の画像やボタンの配置も、書字方向に合わせて逆転させる必要があります。
Flex Messageでは、「direction」というプロパティ1個でメッセージのテキストとレイアウトを左右逆転できるようにしています。書字方向の設定はもともとFlexboxの仕様としてあるので、それを使いました。

例えばこのメッセージは英語なので左から右ですが
書字設定を変更するとこうなります
―― tokuhirom
かなり簡単にできていますね。

―― yuichi
テキストの方向だけじゃなくて、ラベルやアイコンの位置関係も左右に反転できると。

―― tokuhirom
いいですね。他に工夫してるところとかありますか？

―― yuichi
Flex Messageからいろいろなアクションを起動できるんですが、いままでTemplate MessageやRich Menuで使っていたアクションの仕様をそのまま流用しているので、利便性が高いと思います。

―― tokuhirom
BOTのSDKでもアクションタイプのクラスは共通で使えるようになっていますね。

―― yuichi
アクションタイプを共通で行えたら確実に使い勝手がよくなりますよね。そこはこだわって共通化しています。

―― tokuhirom
そうですね、Flex Message が追加されても覚えることが少ないし、使いやすかったです。

Flex Messageの今後の展開

―― tokuhirom
Flex Messageでリッチな表現が可能になりましたが、今後のFlex Messageの展開はありますか？

―― yuichi
iOSやAndroid、デスクトップなどでそれぞれ実装しないといけないですし、最初のFlex Messageの仕様自体が相当複雑なのでシミュレータも作らないといけないですよね。SDKを各言語で実装することも考えて、リリース時点ではかなりミニマムな仕様にしたんです。

―― tokuhirom
そうなんですか、現時点で結構複雑だなぁと思ってました。

―― yuichi
実はもっと入れようと思っていた機能はあったんですが、だいぶ削りましたね。でも、機能の要望はかなり来ているので、段階的に実装したいと思っています。
一番多いのは「バブル（吹き出し）の幅をもっと変えたい」という要望です。イメージマップのように「画面をフルで使いたい」「カルーセルの1個1個が大きいので次のが見えない」などの意見をいただきます。Flexboxはもともと画面の幅が変化するブラウザを想定して作られたものであるおかげで柔軟に対応できるはずなので、今後検討していきたいなと思っています。
他には「画像の上にテキストを置きたい」「画像だけでなく、動画やアニメーションgifを表示したい」という要望も届きます。

―― tokuhirom
確かに、アニメーションgifは出したいですね。

―― yuichi
技術的にはもちろん可能なんですが、トーク画面を重くしてしまっては元も子もないので、慎重に検討していきたいと思います。

Messaging APIに対する、社外からの要望受付先

―― tokuhirom
Flex Messageに限らずですが、LINEのMessaging APIに対する要望は、社外の人はどこ宛連絡したらいいんですか？

―― yuichi
GitHubのフィードバックのリポジトリですね。

―― tokuhirom
なるほど。リポジトリはあるけど広報している気配がないから、社外の人はみんなどこから見つけてるのかなって感じですよね。

―― yuichi
そうですね。あとは、LINEエンジニアとデべロッパーのミートアップを定期的に開催しているので、一番要望などを話しやすいのではないかなと思いますね。

―― tokuhirom
やってますね〜、確かに。LINEのDevRelのチームが立ち上がって、デべロッパー向けイベントも増えてきていますね。僕たちもLINE BOOT AWARDSに向けてSDKを作っていて、「エンジニアもちょこちょこ顔を出してヒアリングしてこよう」という話をしているので、どこかに小野さんが現れるかもしれないですね。
編集部注：LINEのDevRelチームは「社内・社外へ向けて技術的な観点から啓蒙活動を行い、LINEのエンジニア文化やコミュニティ、エコシステムをよりよいものにしていくこと」を目的としたチームで、様々なイベントの開催なども行っています
―― yuichi
要望を聞く機会は結構あって、今後必要だと思う機能のリストもあるんですが、その中でも優先順位をつけないといけないんですよね。「こんな機能があれば、これができる」というような踏み込んだユースケースも一緒に教えてもらえると、優先順位がつけやすくて対応しやすいです。

BOTとの会話のテンポを円滑にする新機能「クイックリプライ」

―― tokuhirom
つい最近リリースされたMessaging APIで使用できる機能「クイックリプライ」について教えてもらえますか？

―― yuichi
メッセージそのものの表現としてはFlex Messageでかなり充実したんですが、次の段階としてユーザーに返信を促す機能を拡充したいと思っています。「クイックリプライ」機能は、メッセージの下に代表的な回答例を提示してスワイプしてユーザーに選択させることができるという機能です。
選択肢を直接キーボードで入力する場合ってテンポがかなり損なわれてしまいますし、選択肢を表示したいときに使っていたTemplate Messageはサイズが大きいので会話の流れが遮られることがありましたよね。クイックリプライはトークルームに溶け込んですぐに消えるので、テンポが速くなると思います。

―― tokuhirom
選択肢が画面上に残っているとあまりスマートじゃないですよね。クイックリプライのようにメッセージのログとしては対話したように見せるとリアルさが増しますね。Flex Messageが出たことにより、Template Messageは今後どうなっていきますか？

―― yuichi
Template Message自体は、使い方もシンプルで8~9割ぐらいのユーザーニーズに答えられていると思います。一日に700万通ぐらい送られているので、Template Message自体をなくすことはないですね。
ただ、テキストの文字数制限や、重くなってしまうことは改善したいです。APIとしてはTemplate Messageだけど、内部的にはFlex Messageに変換する仕組みを計画しています。

―― tokuhirom
ネイティブで表示されるということですね。

―― yuichi
デスクトップ版でも表示できるようになりますし、文字数の制限もなくなりますし、良いことずくめです。デペロッパーの使用感は全く変わらないので、あるタイミングで気づかないうちにしれ〜っと、やっちゃおうかなって思ってます。

―― tokuhirom
素晴らしい。急にTemplate Messageが早くなったらそういうことだと思っておきます（笑）
編集部注：クイックリプライはiOS版およびAndroid版のLINE 8.11.0以降で対応しています。詳しくは、「クイックリプライを使う」を参照してください。

Messaging APIの長期的な展望

―― tokuhirom
Messaging APIにおいて、1〜2年後に向けての施策やビジョンはありますか？

―― yuichi
UI的には今年はかなりリッチにできたと思っていますが、決済やBOTのデベロッパーがお金を儲けられる仕組みじゃないと作るインセンティブがないというのが課題として挙げられます。LINE Payとの連携や広告の表示などをもっと簡単にできるようにしたいと思っています。

―― tokuhirom
現状のBOTは、メインのサービスがあった上で、サポートツールのようなシステムになっていますもんね。

―― yuichi
そうですね。外部のなんらかの既存のシステムがあって、そこと簡単にLINE連携できるという利用しかできていないので、もっと積極的に活用していただけるようにしたいです。

SDKの充実度と機能の使用率の関連性

―― tokuhirom
プラットフォームとしてだんだん出来上がってきて、次はいよいよデベロッパーの皆さんが開発しがいのあるプラットフォームになってきた感じがしますね。

―― yuichi
SDKも充実していますね。こんなに各言語SDK充実していることってなかなかないんじゃないですか。

―― tokuhirom
SDKはね、作りすぎたなって感じがあります（笑）各言語のデベロッパーがやる気を出していますね。

―― yuichi
SDKがリリースされると各言語のエキスパートがSDKの開発を頑張ってくださるので、新機能が素早く取り込まれて結果的に機能の使用率が上がるんですよ。そういった背景もあって、SDKがFlex Messageに対応した後も使用率がかなり上がりました。

―― tokuhirom
SDKを開発している立場だとどれだけ使われているのか実感がないので、ユーザーエージェントベースとかで何かしらのタイミングで共有してもらえるとモチベーションになるかもしれないです

―― yuichi
デベロッパーの方にはコミュニティにももっと参加してもらいたいですよね。

―― tokuhirom
台湾・タイなど海外のデベロッパーからの貢献も多いですよね。コミュニティ側からフィードバックをもらいたいし、僕らの側も、もっと積極的にコミュニティに関わっていきたいなという気持ちがすごくありますね。