Search
Calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< October 2018 >>
New Entries
Recent Comment
Category
Archives
Profile
Links
mobile
qrcode
RSSATOM 無料ブログ作成サービス JUGEM
「CPaaS」まもなく日本にやってくる、マルチメディアコミュニケーションの新潮流
0

    JUGEMテーマ:インターネット

     

    日本ではあまり知られたIT用語ではありませんが、アメリカでは「CPaaS」を活用したビジネスモデルがとても流行っています。

     

    Googleの「地域の設定」で日本を選択して「CPaaS」と検索してもわかり易い説明にヒットしません。

    そこで今回は「CPaaS」について、お話しをしたいと思います。

     

    ちょっと技術的な話が含まれますが、我慢して読んで頂けると身近に感じる不便さを改善するヒントになるかもしれません。

     

    まずは「CPaaS」の略から。「CPaaS」はCommunications Platform as a Serviceの略で「マルチメディアコミュニケーションの機能をAPIで提供するクラウド基盤」です。

     

    そう聞くと「これまでのユニファイドコミュニケーション(以降、「UC」と呼びます)と何が違うの?」という疑問を持たれる方もいらっしゃるかと思います。

     

    「CPaaS」は「UC」とは似て非なるものです。この後に説明いたします。

     

    また「高額なソリューションに違いない」と思う方もいらっしゃるかと思います。

    SaaS(Software as a Service)はこれまでのアプリケーションの利用形態をオンプレミス(システムを自分の会社に置く)からクラウドサービスに転換させました。その時に何が起きたのでしょうか。

     

    アプリケーションの利便性は向上し、システムを稼働維持も含めて安価に利用することができるようになりました。

     

    「CPaaS」は同様にこれまで高額だったコミュニケーションの様々な手段をクラウド化することで、マルチメディアシステムを安価に構築することができます。

     

    そして繰り返しになりますが「CPaaS」は「マルチメディアコミュニケーションの機能をAPIで提供するクラウド基盤」です。

    そうです。「CPaasS」はAPIであり、そのまま使える「UC」システムと明確に違うポイントです。

     

    「API」とはApplication Programming Interfaceの略でアプリケーションの機能を共有できるインターフェースの仕様です。

     

    APIを使って「CPaaS」はあらゆるコミュニケーションの手段を提供します。

    既存のアプリケーションから「CPaaS」のAPIを使って、電話、映像、ショートメッセージ、音声会議、映像会議、画面共有、双方向型ホワイトボード、通話録音、IVRなどを利用することができます。

     

    これまでアプリケーションで電話を利用する場合、電話のプロトコルを理解する必要がありました。ソフトフォンなどがその良い例です。

     

    例えば実質通信の標準プロトコル、SIP(Session Initiation Protocol)を理解してアプリケーションに実装することになります。

     

    SIPは2002年にRFC3261〜RFC3265として制定され、プロトコルの記述がHTTPに近いテキストベースであることから、これまでのH.323の複雑さから解放されるという期待もあり一気に普及しました。

     

    しかしそれでもSIPによる通信はアプリケーション技術者にとってかなりハードルが高いものでした。

     

    例えば電話をかける時、発信者は着信者に「INVITE」を送り、着信者は「Ringing(呼出し)」を返し、応答したら「OK」を送信。そし発信者は「ACK」を着信者に返してセッションが確立。

    さらにRTPで双方向の通話を始める。

     

    電通話させるだけで上記のようなプロトコル記述が必要なわけで、更に切断、保留、転送、パークなどの実装を考えるとたくさんの記述と高い技術力が要求されます。

     

    これは電話の一例ですが、更に映像、会議、ショートメールなどを実装した新しいコミュニケーションシステムを開発しようとした時に、様々な、かつ複雑なプロトコルの記述が必要になり「うー、コリャだめだ」となり、結局バラバラなシステムを組み合わせて、ベンダー独自のAPIを駆使して、連携させて構築することになします。

     

    しかし不幸なことにバラバラなシステムはバラバラに進化し、最悪の場合、システムの連携が維持できなくなるリスクを抱えることになります。

     

    そんな非合理的かつ、お金のかかるシステムの開発、違うベンダー間のシステム連携にまつわる課題を一挙に解決できるのが「CPaaS」です。

     

    「CPaaS」は記述ルールの決まったHTTPの書式、RESTfulなAPIでほんどのコミュニケーションの手段を、先ほど書いた面倒なプロトコルを意識せずにリクエストし、利用することができます。

     

    もちろん複雑なシステムを構築しようとすれば、これまで通りの記述も可能です。

    そんなAPIをクラウドで提供するのが「CPaaS」です。

     

    実は日本でも「CPaaS」は静かに浸透しています。もっとも分かり易い例が「WebRTC」です。

     

    WebRTCはWebブラウザを使い、簡単なAPIでコミュニケーションをすることができる技術です。

     

    SDK(Software Development Kit)を使えばWebブラウザではなくアプリケーションに組み込むことも可能です。

     

    WebRTCをアプリケーションに組み込み、もっとも身近に普及しているアプリケーションの1つがFaceBookのMessengerでしょう。

     

    そして「CPaaS」はB2BB2Cにおけるコミュニケーションの改善ニーズを満たすことができます。

     

    例えばこのようなシーンです。

     

    皆さんも病院、美容室、レストランなどに予約して通うことがあると思います。

    予約はスマホ、PCの予約画面で入力、またはIVRで登録をします。さて予約日は何日か先なので忙しさにかまけて予約日を忘れてしまうことはよくあることです。

    さてその時にどのような事が起きるでしょうか。

     

    お店の人からすると予約しない人が来ないことで、医師、美容師、料理が無駄になり、予約者はキャンセル料が取られたり、再予約すると予約日がかなり先になったりと双方で不利益が生じます。

     

    そんな問題を「CPaaS」は解決することができます。

     

    今お使いの予約システムにRESTfulAPIを使って「CPaaS」に予約者へショートメールで「予約日は3日後です」とリマインダーの指示をします。その時にキャンセルする場合のために適宜なコミュニケーション手段を記載しておきます。

     

    お店の利用者は予約日に行けないことに気づき「キャンセルをする」「予約日を変更する」場合の連絡手段をショートメールにある手段、チャット、電話などから選択して予約の変更をします。

     

    どうでしょう、最大に機会損失を防ぐことができます。

     

    また「働き方改革」で一役買うこともできます。少し作りこみが必要ですがこんなシーンです。

    全員参加が不可欠な会議を主催者がやっとの思いで調整して、会議の開催日時を決めました。

    ところが一番重要なメンバーがトラブル対応などで急遽会議の開催ができなくなります。

    さて再調整となると大変です。参加者のスケジュールを確認して、メールして、電話して・・・

     

    こんな非生産性な作業を「CPaaS」は解決します。

     

    予約システムに一工夫をして、全員が空いている日を見つけショートメールで通知、予約の調整、招集の全てを「CPaaS」と連携した予約システムに任せてしまう。

     

    ほんの一例ですが「CPaaS」はそんなコミュニケーションにまつわる課題を解決することができます。

     

    コミュニケーションをより便利に、ROIの高いサービスを実現する「CPaaS」。

     

    「CPaaS」によるコミュニケーション改革の潮流がまもなく日本にやってきます。

    posted by: 中高年の就活 ブログ(Powerd) | 時事の話題 | 10:42 | comments(0) | - |