+メッセージとRCSと、企業向けサービスについての妄想
先日、「+メッセージ」のiOS版がリリースされました。
＋メッセージの発表のときは、後発のメッセージプラットフォームがこれからどこまで浸透するのか疑問だったのだけど、私個人の日常でどこまで使うかは置いといて、サービスとしてのニーズはめちゃありそうな気がしています。
（企業とか自治体の食指が動きそうなポイントが散りばめられているので。。）
特に、WEBサービスの目線で調べたことをメモしておきます。
※ 本人は至って真面目ですが、読む方にとっては稚拙な内容かもしれません。。
What is ＋メッセージ
これについては各種レビュー記事含めて色んな記事が出ていますが、ざっくり言えばスタンプやリッチメニューなど豪華なコンテンツを送信できるSMSです。
現時点では、Docomo, au, Softbank 3キャリアのAndroid, iOS端末でアプリダウンロードしたら利用できます。
格安SIMのユーザーに対しても、近く展開していくみたいです。
よく＋メッセージアプリとLINEを比較する記事がありますが、LINEのようなチャットアプリは、アプリそのものの良さよりもどれだけ自分以外の大人数が利用しているかがキモなので、普段使いのャットアプリがLINEから＋メッセージに乗り代わるというのはあまり考えられないかと思います。
そうではなく、企業ユーザーにとってイメージというか説明しやすいサービスだと思うのです。
- 日本の３キャリアが力を合わせて作ったサービス => なんか安心！
- 電話番号で配信できる => 電話番号は誰でも持ってる！
- LINEみたいなスタンプが送れる => よく分からんけどかわいい！
と、社内決済を通すときにはおあつらえ向きのワードが満載なのです。
だから、少なくとも短期的には、企業からのマーケティング配信とか、自治体からの緊急配信とか安否確認みたいな用途での利用が主になるのではと思います。
ただし、＋メッセージはまだ企業向けサービスとしてはリリースされていません。また先行事例としてもぱっと見る限りは何らかの企業サービスとして＋メッセージが利用されている事例もないようです。
なので、ざっくり企業向けサービスとしてRCSを利用する場合は、どのような感じになるのかを、ざっくり妄想してみたいと思います。
中の仕組み = RCS (Rich Communication Services)
＋メッセージは、メッセージサービスの国際規格「RCS（Rich Communication Services）」の規格に準拠しているそうです。
規格の文章までは読んでいませんが、おそらくデータフォーマットやキャリアNW間の接続IFの仕様なんかが規定されているのかなと思います。
Docomoやauを含むキャリアに加えて、Googleも賛同している規格であるあたりが熱いところです。
Jibeについて
先程RCSはGoogleも賛同する規格であると書きましたが、そのGoogleが提供しているのが「Jibe」というサービスです
- Android Messages
- Jibe Cloud
- Jibe Hub
の、３つのサービスを提供しているみたいですが、この中で、個人的に興味深いのが、Jibe Hubです。
RCS自体はインターネット回線上を通信するものではないので、キャリアをまたいで通信する場合には、そのキャリア間のネットワークがつながっている必要があります。 Jibe Hubは、このキャリア間接続を中継するもので、インターネットのIXみたいなものだと思います。
つまり、Googleが提供するHubにさえつないでおけば、またはHubにつながっているサービスを利用すれば、キャリア毎で個々にネットワーク接続されているか気にすることなく、他のユーザーとRCSでやり取りすることができるというわけです。
インターネット上では「検索」を抑えることで、人々が知りたいデータを掌握しているGoogleですが、RCSではHubを提供することで通信自体をまるっと掌握できそうなあたりがGoogleっぽい気がします。
※ 例えばRCSのやり取りがend-endで暗号化されるようになるとあまり意味ないかもしれませんし、そもそも↑のような意図はないかもしれません。あくまで私の想像です。
一方で、RCSでサービス展開したい側にとっては、Jibeの基盤に乗った、競争力のある海外のサービスを使って、便利に日本のユーザーにRCSを送信できるようになるかもしれません
※ これも、RCSの国際通信自体が高いとか、国をまたいでは送れない制限があるかもしれず、あくまで想像の範囲です。
RCSメッセージングAPIについて
例えばRCSで複数のユーザーにメッセージを送りたい場合、HTTP APIで送れるようになると、サービス提供者にとっては大いに利便性が上がります。 おそらく＋メッセージ向けにも、どこかのキャリアがそんなサービスを提供するのだろうと思います。
で、海外ではすでにそんなサービスを提供しているところがありました。
CLX Communicationsという会社が提供するサービスです。 このサービス、限定ベータ版で利用するのは難しそうですが、親切にもAPI仕様を公開してくれています。
https://www.clxcommunications.com/docs/rcs/http-rest.html
メッセージのフォーマットなどは、LINE messaging APIなどの仕様とそこまで大差ないようですが、特徴的なのは「SMS Fallback」と呼ばれる機能です。
RCSのメッセージは、受信側もそれに対応するアプリを持っている必要があります。裏返すと、RCSは相手によっては受け取れない場合があるということです。 そのようなときに、RCSの代わりにSMSでメッセージを送れる機能が「SMS Fallback」です。
CLXの場合は、次のようにしてRCSメッセージとSMS Fallbackを指定してメッセージ送信しています
curl https://api.clxcommunications.com/rcs/v1/my-agent-id/messages \
-H "Content-Type: application/json" \
-H "Authorization: Bearer zIMEJGfwD4oJ4qObPPjwZxwiP5cKARXRJpt9Kf6GSv7uOesvRV" \
-d '{
"message_id": "5bb77a04-78b7-41ff-abd3-a1006f8d6979",
"to": "46555123456",
"message": {
"type": "text",
"text": "Test message!"
},
"fallback": {
"message": {
"type": "mt_text",
"from": "MyOriginator",
"text": "Test message!"
}
}
}'
おそらく日本国内で企業向けのサービスとして提供されるものは、CLXのHTTP Rest APIサービスに近いかたちになると思われますが、SMS Fallbackしたときに何を送信するか（またはRCS送信失敗時の取り回しかた）は、RCSの独自ポイントとして考える必要がありそうです。
まとめ
- ＋メッセージは企業向けサービスとしてニーズありそうだよ
- すでにGoogleがRCSを使ってなんかやっているよ
- CLX CommunicationがRCS HTTP Rest APIを出しているよ。この仕様は参考になりそうだよ
以上、初めての記事で内容なり文章がかなり稚拙だと思いますが、最後まで読んでいただきありがとうございました。
※ 文章やまとめ方などに関するコメントもいただけますとありがたいです。
では
