Webアプリケーションの世界は情報を“送りつける”ことが苦手

“社長、このお客さんにお金を貸していいですか？　今すぐ返事をください”

　世の中には、リアルタイムに意思決定が求められるビジネスが少なくない。たとえば、消費者金融の与信決裁だ。新規顧客の融資依頼に応じるか否か。いくらまでなら許容範囲内か。最近は与信管理システムなどシステムによる支援も進んでおり、人間がすべてを判断しなくてもよくなっているが、とある消費者金融の経営者はすべての融資に目を通すという。それがビジネスの競争力の源泉になっていると理解しているからだ。そのときの情報送信はリアルタイムでなければならない。目の前には融資を待つ顧客がいる。すぐさま相手へ確実に情報を届けて、YESかNOを返す必要がある。

　しかし、現在主流となっているWebアプリケーションシステムは、ユーザーが求めて初めて答えを返すプル型の情報通信が基本である。ユーザーの関与なく一方的に情報を送りつけるということが苦手だ。

　では、電子メールはどうなのか。電子メールは確かにプッシュ型情報送信ツールである。しかし、今の用語でいうなら“既読管理”ができない。送るには送っても、通常は相手に情報を届いたかどうか確認する手段はない。これもまた違う意味で一方通行だ。インスタントメッセンジャーは情報を送ることもできるし、既読管理もできる。しかし、情報を送りそこなうということがある。100％確実に届けられるわけではない。たとえばLINEでのやり取りが企業向けに最適かというと疑問が残る。

　急ぎなら電話をかければいいじゃないかと思われるかもしれない。しかし、電話は相手が話し中だとお手上げだ。また、上記の消費者金融の例で言えば決済内容をメールしてから電話することになる。となれば明らかに二度手間だ。

　最近のスマートフォンではこうした問題を解決できる仕組みが備わっている。iPhoneやAndroid端末では、前者がAPNS（Apple Push Notification Service）、後者がGCM（Google Cloud Messaging）というフレームワークを使って通知を送ることができる。ユーザーの許可を取った上で、アップルやグーグルのサーバに通知を送れば、OSに転送され、端末上で通知が表示される仕組みになっているが、ネイティブアプリでの実装には開発費もかかるし、何より既存のシステムとのつなぎ込みという問題も発生する。

【次ページ】Webでプッシュ型通信を実現する4つの方法