Blogブログ

こんにちは！広報の林です。

今回は私たちが手掛けたソフトウェア受託開発の事例として、LINEプラットフォームを活用した家庭用給湯器の遠隔操作システムをご紹介します。補足として、現在は『LINEミニアプリ』として親しまれている仕組みのベースとなる、LIFF（LINE Front-end Framework）を活用した事例です。

こういうお悩みを抱えている方にぜひ読んでいただきたいので、最後までお付き合いいただけると嬉しいです。

LIFFアプリ（今で言う「LINEミニアプリ」に相当する仕組み）とは

LIFFアプリとは、LINE社が提供するLIFF（LINE Front-end Framework）という技術基盤を使ったアプリのことです。

Webアプリとネイティブアプリのいいとこ取りのシステムで、企業側・ユーザー側それぞれにメリットがあるのが特徴です。

まずは、ストアからのダウンロードが要らないうえに、LINE上で「カメラ起動」などの高度な機能が使えます。

そして最大のメリットは、独自のログイン画面を作らなくてもLINEアカウントでサービスにログインできるため、操作が簡単です。「なんかめんどくさそうやからもういいや…」というユーザーが減るので、離脱率を大幅に下げられます。

つまり、ユーザーが気軽に使ってくれるので、冒頭で紹介したような「既存の自社サービスやIoT機器があるが、あまり使ってもらえていない」という悩みを解決してくれるんですね。

いま、LIFFアプリを導入する企業が増えている！その理由は？

今回のような家庭用給湯器の事例であれば「LINE IDと給湯器の個体識別番号を安全に紐付けられる」というメリットもあります。

何が良いかというと、通常のWebサイトでは必要な「ログイン」という手間が要らないんです！（めんどくさがりの林も歓喜🙌）

ユーザーがURLを開いた瞬間にLINE IDと紐づくため、企業側は「●●さんが今、自分の給湯器を操作しようとしている」という情報を即座にバックエンドで把握できます。

そして「給湯器のスイッチをONにしました」のように操作の結果も同じトーク内に通知されるので、ユーザーがトークから離脱せず接点を持ち続けられるという利点もあります。

特に大手企業様のお悩みとして多いのは「企業の知名度もあって製品の売れ行きもいいのに、購入後に誘導したい自社サービスをユーザーに使ってもらえない」というもの。

そこで、ユーザーとの距離が近いLINEに架け橋になってもらうわけです。誰が、いつ、どの機能を使ったかという「ID連携による行動ログ」の取得もできるので、ユーザー属性や行動の傾向を把握し、製品の改良やマーケティング、販促に活かせるんですね。

これは技術的な話になりますが「開発効率の高さ」も選ばれている理由です。LIFFの中身はHTML/CSS/JavaScriptなので、ReactやVue.jsといった最新のフロントエンド技術がそのまま使えるので、iOSとAndroidで別々にシステムを開発する必要がありません。

独自のアプリ開発をせずとも、LINEという完成されたインフラに乗るだけで、洗練されたUIを低価格で利用できます。つまり「開発のハードルを下げながら、サービスの質は妥協しない」それがLIFFアプリを導入する企業が増えている理由です。

今回の事例も、LINEだと既にユーザーがスマートフォンにアプリをダウンロードしているケースが多く、慣れ親しんでいるので操作しやすいのではないかと、弊社からLIFFを活用してサービスを作ってみませんかと提案させてもらいました。

開発において難しかった点・苦労した点

さて、前置きが長くなりましたが、実際に開発をしてみてどうだったのか技術者にインタビューをしたので、翻訳者としての立場でご紹介していきますね。

今回の事例は「LIFFを活用した家庭用給湯器の遠隔操作システム」で、「LIFFの活用」は先ほどご紹介したように開発効率が高くユーザーにもメリットがありますが、ここに「IoT連携」という技術が入ってくると設計・実装共に一気に複雑になります。

インタビューでは、とにかく「IoT連携が難しい」とのことでした。なぜIoT連携が難しいのか、技術者への取材をもとにまとめてみました。

IoT連携の難しさ①：状態の同期（競合した時の解決）

IoT連携は、まず「状態の同期」という難しさがあります。

Webアプリならデータベースが正解なのでそれだけ見ればいいのですが、IoTでは「デバイスの状態」「サーバーの記録」「アプリの表示」の3つを一致させるのがほんっとに難しいそうです。

例えば…

• デバイスがオフラインの間にアプリで設定を変更した場合、オンライン復帰時にどちらの設定を優先するのか？
• アプリで給湯温度を「40度」に設定している最中に、家族が本体のボタンで「42度」に変えた場合、アプリ側にどう即時反映させるか？

といった具合に、特に家庭用給湯器のような複数人が操作するようなデバイスは、ハードとサーバーの状態が競合することがあり、そうなったときにどのように同期をさせるのかが難しいんですね。

サーバー上のデータベースには「40度」なのに、給湯器では「42度」となっている。このズレを解消するために、リアルタイム双方向通信をどう組み込むかが技術者の苦労ポイントです。

通常のWebアプリ開発なら、APIを叩くと「200 OK」が返ってこれば処理完了です。つまり、注文伝票を渡した店員さんから「かしこまりました！」と言われたら注文完了ということですね。

しかし、IoT連携（特に給湯器などの家電）となるとそうはいきません。家庭用給湯器の「お風呂を沸かして」という指示を例に、なぜIoT連携が複雑なのか見てみましょう。

IoT連携の場合（お風呂を沸かす）

【ユーザー】注文：「お風呂を沸かして」（APIを叩く）
【アプリ】返事：「200 OK（承りました、給湯器に伝えます）」
｜
その後：給湯器が「今、断水してるから無理」「Wi-Fiが切れてて通信できない」となる可能性がある。
結果：スマホには「成功（200 OK）」と出ているのに、実際のお風呂は沸いていない…という事態が起きる。

ね？最悪ですよね。Webだけで完結しないってほんとに大変なんですよ。あらゆる事態を想定しないといけない。

アプリで「風呂自動（湯張り）」ボタンを押す → サーバーが受ける → サーバーから給湯器へ（ここまでは一瞬）

問題はここから。実際に給湯器が動き出し「お湯を張り始めました」という状態の報告が返ってくるまでには数秒～数十秒のラグがあります。

じゃあそのラグの間、実際にはお湯を張っているかわからないのに「ON」と表示させるのか、もし給湯器側でエラーが起きたら、数秒後に「OFF」に戻すのか？

ユーザーが「ON」となったのを確認してすぐにアプリを閉じてしまった場合は？アプリを閉じてもわかるようにスタック通知を出すのか？…と不確定の状態の時にどうするのかという処理が必要なんです。

IoT連携の難しさ②：バグの再現が困難

通常、Webシステムのバグは「このボタンをタップしてもメニュー画面が表示されない」という誰が同じ操作をしても同じことが起こると検証できるので、技術者が自分の手元でもバグを再現できます。

だから修理も簡単。直ったかどうかもすぐにわかるんですね。

しかしIoT連携の場合は、そもそも現場がユーザーの自宅や職場なので、同じ状況を再現できないのです。例えば「特定のWi-Fiに繋いだ時だけ通信が切れる」と言われても、技術者の手元では再現できません。

また、デバイスが何らかの理由でオフラインになった時点で通信すらできなくなるため、なぜバグが起きているのかログも確認できなくなります。

そうなることを想定して、先手を打ってオフラインになる直前の情報を残す仕掛けをしておく、そしてその情報からなぜバグが起きたのか推測して解決する力が求められるんですね。もはや名探偵コナン並みの推理力を発揮しないといけないんです。

「あれれ～？」とか可愛くとぼけてますけど、あれは天性の推理力だけじゃなくて日ごろの積み重ねの賜物ですからね。

IoT連携の難しさ③：認証とセキュリティの運用コスト

「LINEから給湯器を動かす」といった連携では、認証の鎖が非常に長くなります。なんのこっちゃわからないですよね。

この認証には「トークン」という、いわゆる名前やパスワードの代わりになる「合言葉」的なものが使われています。

今回の「LINEから給湯器を動かす」場合

LINEのアクセストークン（最初の扉）

ユーザーがLINEで操作画面を開いた瞬間、LINEから「この人は●●さんですよ」という証明書（トークン）が発行されます。これがないと、誰が操作しているか分からず、他人の家の給湯器を動かせてしまうことになります。本人確認みたいなものですね。

システム連携用のトークン（二番目の扉）

LINEから受け取った情報を、弊社のサーバーやメーカー側の管理システムに伝える際にも「これは正当なリクエストです」と証明するためのトークンを添えて通信します。

機器操作のトークン（最後の扉）

最終的に「お風呂を沸かす」という命令がデバイス（今回は家庭用給湯器）に届くとき、その命令が本物であることを証明する鍵としてトークンが使われます。

で！何が厄介かというと、このうちどこかひとつでもトークンが切れただけで動かなくなります。時々、他のサービスでも自分でログアウトしたわけじゃないのに再ログインしてくださいって表示出るときありますよね。あれ、もしかしたらこのトークンが関係しているかもしれません。

どこで認証が詰まっているのかを特定して、ユーザーに再ログインを促すフローを作るのは、Webサービスを作るより遥かに複雑です。

まとめ

とにかくIoT連携は、あらゆる可能性を考えないといけない。それが本当に大変だったとのこと。特に家庭用給湯器は、開発現場となるオフィスに家庭用給湯器と風呂釜を持ち込んで検証って訳にはいかないですからね。

担当した技術者もしょっちゅう社内のチャットで「自分の端末ではdevelop環境で機器操作を押すと「利用している●●ではご利用できません」と表示されたり、pdfは表示されないのですが、○○さんの端末でも同じような現象が起こるか確認していただけますか？」と、他の技術者に確認を依頼していました。これ、手元ですぐに検証できないの歯がゆいだろうな…。

まずデバイス自体の知識も要りますしね。給湯器ならほとんどの家に備え付けられているのでイメージが湧きやすいですが、「とあるメーカーの●●という製品」についてをまず調べて詳しくなるという過程が必要です。

ちなみに、今回は家庭用給湯器の発電状況をかわいいキャラクターと一緒に楽しく確認・操作できる関連サービスも同時に作っていて、そのキャラクターのセリフや挙動を考えるというのも開発の一環でした。

動物モチーフの癒し系のキャラで、ユーザー目線だとついキャラに目が行ってしまうのですが、その裏でとんでもない量の分岐図とそれに対しての処理、そして地道な検証が行われていたことがよくわかりました。

実は弊社、他にもIoTの開発をいくつか手掛けているので、また取材してご紹介しますね。それではまた！