「モバイル端末への警報メッセージ配信について」

弊社では、いろいろな監視・制御システムの開発や構築に携わっていますが、システムで検出した異常や状態を警報として、現場にはいないユーザーに通知したい、また特にモバイル端末へ配信したいという要望がよくあります。
モバイル端末への配信方法はいろいろありますが、最近はIoTやDXなどの発展に伴い、特定の少数ユーザーだけではなく、特定の多数のユーザーへ配信したい、また、社内ユーザーだけではなく社外ユーザーにも配信したいという場面も増えてきています。

そこで、今回は、モバイル端末への警報メッセージの配信方法についてこれまでを振り返りながら、整理してみたいと思います。

インターネットが生まれる前からあったEメールですが、今でも最も手軽に配信できる方法の一つではないでしょうか。

配信したいユーザーのEメールアドレスを監視システム側へ登録しておき、通知時にEメールサーバーに対してSMTPプロトコルで送信することで実現できます。
Eメールサーバーは、監視システム専用ではなく、他の業務やシステムで使用しているものと兼用するケースが多いように思われます。
また、市販のSCADAでも標準機能として、アラームのEメール送信機能を持つものがいろいろあります。
通知を受けるモバイル端末側には、Eメールクライアントアプリは標準でインストールされていますので、Eメール設定さえしてしまえば、それで受信可能です。

Eメールでの配信はこのように比較的簡単にできますが、Ｅメールは個人情報となる可能性がありますので、配信するユーザーが増えるほどその管理も注意が必要です。
また、社内ユーザーだけでなく社外ユーザーも管理するとなると、それに応じた管理が必要になる可能性があります。

そして、配信数やユーザー数が増えるほど、Ｅメールサーバーの処理負荷は上がります。
配信先が数百人以上になったり、警報の発生頻度によっては、Eメールサーバーのスペックや通信帯域が不足する場合が考えられます。特にＥメールサーバーが兼用の場合には、他に影響を与えないようにする必要があります。
では、監視システム専用のＥメールサーバーを持てばよいのではないか、という考えにもなりますが、最近のＥメールは、スパムメール対策やマルウェア対策も必要な状況となっており、Ｅメールサーバーを持つということは、そういったセキュリティ対策についても考慮しなければならないことが多いです。

また、Eメールサーバーを、クラウドのVMで立ち上げて稼働させようとしても、多くのクラウドベンダーは迷惑メールサーバーとして簡単に悪用できないよう、デフォルトで各種制限がかけられています。そのため、Ｅメールサーバーとして稼働させるには解除の申請が必要な場合がほとんどです。そもそも、VM上でのEメールサーバー稼働をサポート対象外としているベンダーもあります。
そのため、クラウド上にEメールサーバーを立ち上げるのはあまり現実的ではないのですが、代わりにメール配信を行ってくれる、メールリレーサービスがあります。具体的には、AWS SES(Amazon Simple Email Service)やSendGridなどがありますので、Eメールが必須で、大量のメールを配信する必要がある場合には、選択肢の一つになると思います。

モバイル端末では各メーカーが提供するプッシュ通知機能を使えます。これは配信先の情報にEメールなどの個人情報となりうるものは使用せず、端末毎に固有の識別子デバイストークンを生成し、そのトークンを使用して配信が行われます。
モバイル端末のシェアから考えると、iOSのAPNs(Apple Push Notification Service)と、AndroidのFCM(Firebase Cloud Messaging)が主要になると思います。

仕組みとしては、監視システム側に配信先の端末毎のデバイストークンを登録しておき、通知時に配信サーバーに対してAPI経由(別途事前登録必要)で配信要求を行うことで、全端末へ一斉にプッシュ通知が行われます。
配信サーバーは、Appleやgoogleからの提供となるため、自前で準備する必要はありませんが、同時配信数や配信回数などの制限はそれに従う形になります。例えばFCMの場合は、配信サーバーへの接続は400回/分、デバイスへの送信は240件/1台に制限されています。

また、通常、デバイストークンの登録には、モバイル端末側から送信処理(登録・解除)、監視システム側では受信処理(保存・通知時に参照)を実装する形となります。また、モバイル端末側では、プッシュ通知受信処理およびその後の、メッセージ処理を実装します。
つまり、基本的には、ユーザー側でプッシュ通知の登録・解除を行う仕組みとなります(もちろん、Ｅメールの場合も、ユーザー側からの登録・解除の仕組みを組み込むことで対応可能です)。

ただ、APNsにしろFCMにしろ、基本的にモバイル端末側のアプリを作成する必要があります。
現状は、iOSとAndroidが主要なスマホのOSといっていいと思いますが、どちらにも対応するには、それぞれのアプリを作成する必要があり、かつ、アプリを開発するための開発言語はそれぞれ異なります(現在の推奨の開発言語は、iOSはSwift、Androidはkotlin)。
これは対しては、マルチデバイスに対応した開発プラットフォームというものが以前より存在し、一つのプログラムを作れば、iOS/Android両方動くと謳っているものはいろいろ存在していました(最近では、WindowsやMacまで網羅する、Flutterや.NET MAUIなどがでていますが今後の主流になっていくのでしょうか)。
ただ、それでも共通化できない部分はOS別に作り分けが必要になるケースがあります。
そして、スマホは毎年新しい端末が発売され、OSも年々バージョンアップしていきますので、OSのバージョンアップにアプリも追従していく必要があります(これは、WindowsやLinuxも同じと言えば同じですが、スマホのOSのバージョンアップの頻度はより早いと思います)。

更に、モバイル用アプリを作成したとしても、今度はそのアプリ自体の配布においてハードルが出てくる場合があります。
通常はアプリの配布は、App Store/Play StoreのStoreを介すことになりますが、Storeの登録には、セキュリティの観点などから、Appleやgoogleへの審査・承認が必要となります。またStoreのサーバーは海外となり、場合によっては輸出手続きの考慮しなければならない可能性があります。
Storeを経由せずにアプリをインストールする方法もありますが、iOSの場合は、ライセンス形態がいろいろあり、配布範囲や用途に応じたライセンスの取得をする必要があります。

ということから、モバイル端末のプッシュ通知は、その機能を作りこむこと以外にも、保守やそのアプリ自体の配布の面でもハードルが出てくる可能性があります。

そんな中登場したのがWebプッシュでした。Webでのプッシュ通知も歴史があり、古くはAjaxからServer Sent Envets、Web SocketやMQTT、また、HTTP/2 Server Pushへ進化してきており、2017年にRFC8030として、Web Pushが規格提案されています。

Web PushはWebブラウザを使ったプッシュ通知方法となります。たまに購読許可ダイアログが自動的に表示されるWebサイトがあると思いますが、あれがそうです。
Webブラウザも通常モバイル端末に標準で入っていますので、これさえあれば、モバイル端末への通知の課題も解決するはずです。
そして、監視システムもWebシステムとすれば、アプリの改修時も、端末側のソフトの更新なしで、サーバー側ソフト更新だけで対応できることになります。

Web Pushの仕組みとしては、セキュリティを考慮した仕様となっていることから、多少込み入っていますが、以下のようになります。

• まず、Webブラウザ側で、Webページにアクセスした際に、監視システムサーバーから公開鍵の取得(監視システムサーバーはこの時点でサーバー秘密鍵も生成)。
• その後、Webブラウザにて許可ダイアログ表示されるのでユーザーが許可すると、公開鍵を配信サーバーへ送信し、ブラウザトークン(クライアント公開鍵・クライアント秘密乱数・エンドポイント)を取得し、監視システムへ送信(監視システム側ではそのブラウザトークンを保存)。
• 監視システム側では、通知時に、保存していたブラウザトークンをサーバー秘密鍵で暗号化し、サーバー公開鍵とともに配信サーバーへプッシュ通知要求を送信。
• 配信サーバーは、公開鍵を使って暗号化されたメッセージを検証し、問題なければブラウザへプッシュ通知

配信サーバーは、googleがWeb Pushを推進してきたこともあり、モバイルプッシュのところで出てきた、googleのFCMサーバーが使われていることが多いようです。
また、Webブラウザ側での、監視システムサーバーとのやり取りや、配信サーバーとのやり取りは、Webブラウザ側で動作するjavasciptプログラムによって行われます。そのため、監視システム側ではWebサーバーを準備して、そのWebページを公開する形になります。

また、最近のWebブラウザはPWA(Progressive Web Apps)という仕組みが組み込まれており、Webブラウザを起動していない状態でもバックグラウンドで動作やオフラインでも動作が可能となります。そのPWAの機能を使って、プッシュ通知の受信を行うことができるようになっています。
なお、Webブラウザを使ったプッシュ通知となりますので、対象はモバイル端末だけではなく、デスクトップ用Webブラウザでもプッシュ通知が可能となります。

さて、ここまで書いてきて重要なことをまだ書いていなかったのですが、このPWAのWeb Pushに対応しているブラウザは、現状、Chrome・Edge・Firefox・Operaまでとなっており、Safari/iOSが対応していません！

Web PushはChromeでgoogleが対応を初めてから、もう何年も経っていますが、RFC化された今でも、未だAppleは対応していません。iOS 15.4ベータ版にようやくWeb Pushの試験機能が実装されたようだという噂もありましたが、結局噂だけで何もありませんでした。

Webプッシュに対応したいシステムもいくつかあるのですが、残念ながらいつAppleが対応してくれるのかわからないため、早く対応してくれることを祈り続けるばかりです。

なお、PWAの機能を使うためには、SSL対応したWebサーバーが必要となります。
自前で、SSL対応する場合には、SSL証明書の準備が必要となりますが、iOSはSSL証明書の有効期限が398日以下という制限がありますので、注意が必要です。

上記までで、Eメール、モバイルプッシュ、Webプッシュについて、まとめてみましたが、AWSには、各社モバイル端末のプッシュ通知やＥメールまたSMSを統合して通知できる、SNS(Simple Notification Service)というサービスがあります。

SNSは、基本的には、各モバイルメーカーのプッシュ通知機能である、APNsやFCMをラップして使うイメージとなりますが、ラップすることによって、APNsであってもFCMであっても、Eメールであっても同じI/Fで実装が可能となっています。
ただし、Eメールについては、初回は通知許可の手順が必要となりますので、運用方法を確認したうえで使用することをお勧めいたします。

その他、SNS以外にも、サードバーティ製のプッシュサービスがいろいろありますが、実はgoogleのFCMは、もともとGCM(Google Cloud Messaging)と呼ばれるサービスでしたが、2018年にFCMに生まれ変わると同時に、Andoidだけではなく、iOSとWebへのプッシュ通知にも対応しました。
そのため、Eメールでの配信が必要ない場合は、FCMで事足りる場合も多いのではないかと思います。

Webプッシュが未だSafari/iOSが対応しない状況のため、標準的に使っているアプリを使用(便乗)することで、警報の通知ができないかと考えたくなります。

そこで、真っ先に思い浮かぶのがLINEです。他のSNSもあるかもしれませんが、それらは、不特定多数のユーザーとのコミュニケーションツールであり、特定のユーザーに絞ることが難しいことや、監視システムの警報通知という用途から考えると、使用できるものは絞られるのではないかと思います。

さて、LINEで通知する方法は大きく2つあり、一つは、LINE Notifyで、もう一つは、LINE Botです。LINE NotifyとLINE Botを比較すると、以下のような違いがあります

LINE Notify

• LINE Notifyアカウントを使用。
• Notify APIが公開されており、それを用いてメッセージ通知を行う(アクセストークン必要)。
• 通知先は、トークン発行時にのみ決定され、通知先ユーザーか通知先ユーザーが含まれるグループとなる(別の通知先の登録には再トークン発行が必要)。
• 通知元は、LINE Notifyアカウントからの通知。よって、他サービスでもLINE Notifyを連携している場合は、全てLINE Notifyからの通知となる。

LINE Bot

• LINE公式アカウントを取得し、チャンネルをBotとして作成。
• LINE Messaging APIが公開されており、それを用いてメッセージ通知を行う(アクセストークン必要)。
• 通知先は、通知を受けたいユーザーが作成したBOTを友達、もしくはグループへ招待することで設定(再トークン発行不要)。
• 通知だけでなく、ユーザー側からのメッセージ受信に対するアクションも可能。

手軽に作成できるのは、LINE Notifyの方ですが、Botはユーザー側からのメッセージに対するアクションにも対応できます。しかし、無償枠の制限がありますので、用途に応じて使い分ける形になるかと思います。

以下はBot＋Messaging APIを使って、警報発生通知と同時にユーザーアクション用のボタン(クイックリプライ)を含めて通知した例です。クイックリプライ機能は、ボタンアイコンやメッセージをカスタマイズできる機能ですが、下記では警報復旧ボタンとして埋め込んでみました。

以下は、その後、ユーザー側が、警報復旧ボタンを押下した例です。
今回は、警報復旧ボタンを押されたら、警報復旧と再通知するだけにしていますが、ボタン押下のタイミングをフックできるので、このタイミングで実際の監視システムのアラームを停止することなども可能です。

クイックリプライで表示するボタンの数やメッセージは、状況に応じて可変させることが可能ですので、警報内容に応じて、取れるアクションを変えることも可能です。

また、Messaging APIには、更にリッチにボタンを複数並べて可変できる、リッチメニューという機能もあります。

ただし、このリッチメニューはユーザー単位での使用を前提としているようで、グループ単位での設定は現状できないようなので、使いどころは検討が必要です。

その他、余談ですが、Twitterには、グループDM(ダイレクトメール)という、LINEのような特定グループのチャンネルを作成できます。
しかし、このグループDMには、現状、プログラムからメッセージを送信できるAPIが公開されていません。
今後、グループDM用のAPIが公開されることがあれば、Twitterも選択肢に入ってくるかもしれません。

コロナ禍になってから、弊社では、MicrosoftのTeamsを使用しています。以前はSlackを使っていましたが、Teamsが社内規定ツールとなりましたので、Teamsについても取り上げてみます。
Teamsは基本的に組織向けのツールですので、主に社内ユーザー向けになると思いますが、LINEと同様に通知だけでなく、ユーザー側からのアクションにも対応が可能です。

Teamsとの連携方法としては、警報通知したいTeamsのチャンネルに、他アプリと連携可能なコネクタを設定する形となりますが、最も手軽なのは、 もともと用意されている「Incoming Webhook」を選択し、発行されたWebhook用のURLに対して、監視システム側からメッセージを送信することです。

以下が、コネクタを設定し、メッセージ受信した場合の例ですが、LINEの時と同じように、警報復旧ボタンを付加して通知が可能です。

また、ボタンの数や押下時のアクションの指定が可変できますので、http送信を埋め込んであげれば、監視システム側でそれを受信して、それに対するリアクション動作が可能となります。

以上、モバイル端末への警報メッセージの配信方法について取り上げてみました。
また、今回LINEとTeamsで、ユーザー側からのアクションで、監視システム側で処理を行えることも取り上げましたが、実運用で導入する際はリスクについても検討が必要です。これは、遠隔から制御をかけられることになるので、本当にその機能が必要な対象なのか、 また、必要な場合は、認証方法が十分か、誤操作防止処置が十分かなどを考慮した上で判断していく必要があります。

最後に今回紹介したサービスの概要・注意点を表にまとめてみます(2022/05/20時点の情報)。

配信方法	通知可能OS	内容	サービス料金
Eメール	iOS/Android/Windowsなど	Eメールアドレスは個人情報となる可能性あり 配信数によってはEメールサーバスペック要検討	無償
AWS SES	iOS/Android/Windowsなど	Eメールリレーサービス 62,000通/月以内であれば無料	無償/有償
SendGrid	iOS/Android/Windowsなど	Eメールリレーサービス 12,000通/月以内であれば無料	無償/有償
APNs	iOS	アプリ配布が難となる可能性あり？	無償
FCM	iOS/Android/Web	アプリ配布が難となる可能性あり？	無償
Web Push	Android/Windowsなど	iOS未対応 SSL必須	無償
AWS SNS	iOS/Android/Windowsなど	各社モバイルプッシュ/メール/SMS統合通知サービス	有償
LINE Notify	iOS/Android/Windowsなど	1時間1000回上限 トークン発行100個まで	無償
LINE Bot	iOS/Android/Windowsなど	1,000通/月以内であれば無料	無償/有償
Teams	iOS/Android/Windowsなど	社外ユーザーは組織間連携もしくはゲスト登録が必要？	有償

各サービスにはそれぞれの特性や制約がありますので、実際に使用する際には詳細仕様の確認は必要です。また、サービスの仕様やI/Fも年々バージョンアップ等に伴い、変わっているものがありますので注意が必要です。