WebRTCを用いたビデオ通話・音声通話サービス・アプリの開発

WebRTCとは

WebRTCはWeb Real-Time Communicationの略です。文字通り、リアルタイム性をもったインターネット上のサービスの構築に用いられる技術規格です。シグナリングサーバ、スタンサーバ、ターンサーバを用いてWebRTCを実現させると、リアルタイム性が必要な音声通話やビデオ通話のサービスを、PC間、スマホ間、PCとスマホ間にて提供が可能になります。ここでは、関連する技術をいくつか紹介させていただきます。

シグナリングサーバ WebRTCのPeer to Peer通信を開始する際に必要となる、自分と相手先のネットワーク接続情報の交換を仲介する役割を担うサーバです。
スタンサーバ Peer to Peerで接続を確立する際、大きく分けて、異なるNAT間にデバイスがある場合と、同じNATの中にデバイスがある場合の2つがありますが、それがどちらにあたるのか見定めます。外から見たときに複数見えるIPアドレスのうち、自分のデバイスがどのIPアドレスが接続を確立可能か自分に教えてくれます。また、その際のIPアドレス以外のネットワーク接続情報も自分に教えてくれるという役割も担うサーバです。
ターンサーバスタンサーバから取得できたネットワーク接続情報でPeer to Peer通信が確立できなかった場合に、ターンサーバを経由した通信に切り替わります。ターンサーバを経由した接続は、Peer to Peerではなく、クライアント／サーバ型で接続を確立している状態になります。これはサーバの負荷を高めると同時にネットワークの帯域を占めてしまう原因にもなるため、従量課金制のサーバを借りる際には十分な注意が必要になります。つまり、ターンサーバは接続の補助的な役割を担うサーバです。
SFU
WebRTCはWeb Real-Time Communicationの略であることからすると、広い意味ではSFU(Selective Forwarding Unit)もWebRTCに属するサーバです。しかし、上記のシグナリングサーバを用いたPeer to Peerの接続方法とSFUを用いた接続方法は大きく異なり、各エンド端末から送られてくる映像や音声などの情報をサーバが転送・配信する形を取ります。

ここで、シグナリングを用いたPeer to Peerでn人でビデオ通話をする場合と、SFUでn人でビデオ通話をする場合を比較してみます。

シグナリングを用いたPeer to Peerの場合、(n－1)人宛てに情報を配信し、また(n－1)人分の情報を各端末が受取るため、各端末に対する通信量、負荷ともに高くなりますが、通話することに対する負荷はサーバを経由しないためかかりません。

SFUを用いてn人でビデオ通話をする場合、各端末からは、サーバにのみ情報を送信し、サーバは転送する形で(n－1)人の情報を端末に対して送信します。上りの情報がサーバ宛ての1つに絞られるため、端末のネットワーク負荷は下がりますが、各端末で(n－1)人分の情報をデコードする必要は残るので、それなりに各端末への負荷はかかります。無償で使えるSFUとしては、JanusやMediaSoupなどがあります。
データコネクション WebRTCというとビデオ通話といった活用法が目立ちますが、映像以外にもリアルタイムにデータを同期させて送受信するデータコネクションの技術を用いることで、単なる通話以外に適応できる範囲が大幅に広がります。

例えば、テキストデータをデータコネクションを用いてやりとりすることで、ビデオ通話がつながったままチャットを利用したり、画像データを同期させて表示することで、スタンプを送信したりオススメの商品をレコメンドしたりすることなども可能になります。
VoIPプッシュ通知/プッシュ通知 URLを事前シェアしてビデオ通話を行うのではなく相手を指定して呼び出し音を鳴らし、それを受けることによってビデオ通話を開始するタイプのアプリケーションでは、上記のWebRTCのサーバの機能に含まれない仕組みを実装する必要があります。

一般的には、iOSの場合は、iOS8から実装されたVoIPプッシュという仕組みを利用します。VoIPプッシュは、優先度が高くまたプッシュ通知に発生しがちな遅延なども発生しづらいという特徴があります。

一方、Androidでは、VoIPプッシュのように通常のプッシュ通知とは分けられた仕組みは用意されておらず、通常のプッシュ通知を使うため呼び出しに失敗や、遅延が発生する確率が高くなってしまいます。呼び出しには、このような特徴がありWebRTC関連のアプリケーションを構築する際には、ケースに応じて様々な工夫を施す必要があります。

WebRTCのメリット

システム的なメリット WebRTCのPeer to Peerでビデオ通話や音声通話をしている場合、各デバイスが、サーバのような役割を担うため、帯域の確保や高い処理能力をもつサーバ必要とせずに、ビデオ通話や音声通話をすることが可能になります。

また、WebRTCでは、ビデオ通話や音声通話するための部屋のようなURLにアクセスすることで通話が可能になるため、電話番号やLINEアカウントなどのパーソナルデータを通話相手に伝えることなく、ビデオ通話や音声通話をすることが可能になるというメリットがあります。
コミュニケーションツールとしてのメリット
WebRTCを用いたビデオ通話を通じてコミュニケーションを行うメリットとして、メールや電話と比較するとコミュニケーションが圧倒的にスピーディかつ効率的になる点があげられます。また、ビデオ通話のほうが、相手の表情が判るため意思の疎通が容易で、真意なども直接対面でお会いしている場合にとても近いレベルで理解することが可能になります。テキストを用いたコミュニケーションによくある、行間を推察しながら慎重に言葉を選んで返信するというストレスから解放されるというメリットを実感しています。また、問合せ処理に要する時間としても、返信メールの文面を考えている間にお問合せいただいた方と会話することで解決にたどり着いてしまうという感覚があります。特に内容が複雑であったり、映像で見れば瞬時に理解させられる内容でも、テキストや口頭のみでの説明では非常に困難といった場合においては、圧倒的にメリットがあります。

WebRTCのデメリット

開発体制の確保・維持ノウハウを持ったエンジニアの確保が、Web系のエンジニアと比較して難しい点があげられます。シグナリングサーバ、スタンサーバ、ターンサーバといった特殊かつ比較的難易度の高いサーバを構築する必要があり、サービス開発を行った経験のある人材が少なく、経験のある技術者の確保で、開発ノウハウもWeb上にあふれている訳ではないため、チームのスイッチングも困難になります。

LAMP系の環境での開発を得意とする腕利きのエンジニアであっても、これらのサーバの名前すら聞いたことがないというエンジニアはたくさんいるはずで、OSやデバイスごとの挙動の癖などに勘が働くようになるには、かなりの時間を擁します。
コミュニケーションツールとしてのデメリット
Web RTCに限らずオンラインミーティングツール全般に言えることですが、多人数参加型の議論に弱いという点があげられます。SFUを用いて多くの参加者に音声や映像をやり取りすることは形式的には可能です。しかし、例えば、集中して話を聞いていない参加者がいても判別しづらかったり、自分の話が相手に確実に届き、正しく理解されたのかもピンとこないままになってしまうこともよくある話なのではないでしょうか。また、ネットワークや接続された端末の不調などにより重要な打合せであってもコミュニケーションに余計なストレスを与えてしまったり、場合によってはリスケせざるを得ない状況に陥ってしまうことがあります。

WebRTCの技術的進化

WebRTCのブラウザ対応
スプレッドワンでは、2017年頃からWebRTCに着目し、試行錯誤を繰り返しているのですが、2020年のWebRTCに関する非常に大きな進化として、スマートフォンのChromeやSafariといったブラウザ環境からでも安定した接続が可能になったことがあげられると思います。（それ以前にはスマホのブラウザ対応でWebRTCを安定させているサービスを見たことがなく、弊社もできませんでした。）スマホのブラウザがWebRTCに対応されたことで、これまでアプリ中心であったWebRTCを用いたビデオ通話や音声通話が、ブラウザtoブラウザでも可能になりました。アプリのインストールを必須としなくなったことは大きな進化だと思います。ただし、ブラウザを用いて接続する場合の留意点としては、一般的には通話が切断された際の判定処理が難しいという問題があります。その理由は、Peer to Peerであることや、ブラウザの当該タブが閉じられたり、電池が切れたりした際にアクションが拾えないことなどに起因します。多くのブラウザ経由のビデオ通話サービスで、使い捨てのURLが発行され、通話前にその事前にURLをシェアするという面倒なプロセスになってしまっているのは、通話の死活の監視がブラウザ経由であった場合、難しいということが理由です。 ※ブラウザ経由の通話で、煩わしい事前のURLシェアを行う必要をなくしたのが、弊社にて開発・運営を行っているサービス『Deck』です。
ブラウザからの画面共有これまでは、ビデオ通話を確立しながら画面共有をする場合、Zoomなどに代表されるアプリケーションをインストールしておくことが一般的でしたが、スマホブラウザでのWebRTC対応と並んで、大きな進化としてはブラウザから画面共有が可能になった点があげられます。

サービスの企画・開発時の注意点

イヤホンのデバイスやスピーカなどの制御
WebRTCを用いたスマートフォンでのビデオ通話の開発では、アプリであってもブラウザであっても、スピーカやマイクの制御や、アプリがオフの状態やバックグランドになっている状態での呼び出しなどに関する制御が必要になることは企画段階で考慮しておくべきです。 PoC版などの開発では、時折、見落とされてしまうため注意しておくべきかと思います。（デバイスによって使えないことがあります）
映像品質と端末の処理能力
スマホで複数人が参加するビデオ通話を4Kなどのハイビジョン画質で行うとデバイスの処理能力の限界でアプリが突然、フリーズすることがあります。そのため、古い端末もユーザとして想定されているのであれば、2者間での通話に留めるか、n者間の場合は、その参加人数に応じて、映像の画質や表示サイズ、fpsなどを落としたり、あるいは、n者間の通話が得意なSFUサーバを立てて処理を補ったりするなどの工夫を施した開発が必要になります。
ネットへの接続環境や帯域について
ハイビジョンでビデオ通話をする場合、1通話あたりおよそ2Mbpsほど帯域を占めてしまう前提で企画・設計を行う必要があります。例えば専用線で100Mbps程度であるとすると、実測は15Mbps程度しかでていないこともあるので、その回線を介した同時通話数が増えると映像が劣化したり、つながりが悪くなったります。コールセンター的に受けるような、一つの建物内で複数の端末がWebRTCでビデオ通話を行う想定の場合には、ネット回線に注意が必要です。また、4Gの環境でネットに接続する想定の場合、電波状況が良ければ、問題なく4Gでもハイビジョンで接続されます。だたし電波状況が悪い場合には、映像の画質が劣化します。また、パケットの消費もハイビジョンの映像をやりとりするため勢いよく進むので、その点についても注意が必要になります。また、ネットへの接続環境として、ファイアウォールなどにより接続できないケースがある点も注意が必要です。
OSやブラウザによって異なる挙動
WebRTCを用いた開発を行うと、OSの種類やバージョンやブラウザの種類やバージョンによって異なる挙動を示すことが（WebRTCに不慣れなエンジニアからするとおそらく驚くほど）多発します。ですので、少なくともテスト工数は多めに見積もっておくべきです。また、不具合の再現が難しいということもよくありますし、再現させられても特定OSでの不具合を解消できないで諦めるということが起こったりもします。特に古い端末には注意が必要で、例えば、少し古いMacOSでは、高いフレームレートを指定できませんが、プログラムで映像の質を制御するため、FPSを高く設定していると映像が送信されないという状況に陥ったりします。予算の都合上、テストケースをそこまで、揃えられないというのが、ビジネスでの実情かと思いますが、現時点では、事前にWebRTCを用いたサービスの開発はそういうものであるといった認識を持っておくべきかと思います。
セキュリティ
盗聴について、Peer toPeerはSSLで接続されるため盗聴されるリスクは少ないかというと、そうでもありません。通話に用いるURLが知られてしまい、入室制限やパーミッションを取る処理がない場合は盗聴されるリスクがありますので、盗聴の対策をたてて開発する必要があります。
録画について
意思表示の証拠データとして、録音や録画を検討される場合、２つの注意が必要です。ひとつは、WebRTCでのビデオ通話を鮮明な画質で行うと、録画自体もそのまま鮮明になるので、1時間で約10GB程度のディスク容量が必要になります。もう一つは、メッシュ型のWebRTC接続で接続された情報を保存する場合、必ず、見たまま、聞こえたまま、録画されているかというと、なかなかうまく行かないケースがあります。ZoomやTeamsなどを使って複数人で会話していると、参加者各々の画面でピタリと表示が一致しているかというとそうでもなく、不安定なことがよくあるのをイメージすると分かり易いかと思います。WebRTCでの録画についても、WebRTCでやり取りされているデータが送信されてきて、それを録画する方式では、不安定になり得るということは想像に難くないかと思いますので、注意が必要なポイントになります。 ※見た映像、聞こえた音声、発した音声をクリティカルに保存する機能について、弊社では開発に成功しています。もしそのような機能が必要な開発を手掛けている場合には、是非、お問合せください。

WebRTCを適用可能な例

ビデオ通話・音声通話機能を中心としたSNSや会員向けサービス
サポートセンターやヘルプデスクでの通話料の無料化
スマホサイトからのフリーダイアル電話問合せの通話料無料化
建設現場などのプロジェクト専用のメッセージ/通話アプリ
社外からも内線感覚でかけられる通話/メッセージングアプリ
オンラインでの接客やカウンセリング、査定や見積り

上記は、サッと思いつく適応例ですが、WEBを通じて無料の音声通話やビデオ通話を活かしたサービスはアイデア次第では、色々なところで適応していくことが可能だと思います。音声通話やビデオ通話などを絡めたサービス開発のご相談などがございましたら、ぜひお気軽にお問合せください。

WebRTCに力を入れている理由

簡単な伝達事項のやり取りであれば、メールやチャットでもそれほど差支えないと感じますが、クリエイティブな仕事やセンシティブな仕事をメールやチャットだけで進めようとすると、かえって非効率になるというのは経験則からも納得のいく話ではないかと思います。

『世界一速く結果を出す人は、なぜ、メールを使わないのか』という本は、Google社内でどうやっているのかを開示したような本ですが、以下のような件があります。

直接会う方が何倍も速い

メールではうまく意思の疎通ができず、かえって仕事が遅くなることもあります。何回やり取りしても、相手の意図がつかめず、なかなか合意にいたらない。だったら、電話するか直接会って話せばいいのです。どれだけ便利になっても、最後は相手の顔を見て話すことに意味があります。オンラインチャットに書き込んでいる最中でも、「じゃあ、直接話そうか」と言って、ハングアウトを立ち上げて、いきなり会話をはじめます。表情が見えると、お互いに考えていることが、ダイレクトに伝わるので、文字だけや音声だけのやりとりよりもはるかに効果が高いと実感しています。引用元：
『世界一速く結果を出す人は、なぜ、メールを使わないのかグーグルの個人・チームで成果を上げる方法』
ピョートル・フェリークス・グジバチ著

優秀なスタッフが多いと考えられるGoogleですらこんな感じなので、難しいお題で「メールでやり取りしよう！」というのは、自ら進捗を阻害し、混迷を呼び込むことにはならないか注意する必要があると言えそうです。

つまり、コミュニケーション手段として、メールやチャットは便利な面がある一方で、面倒を巻き起こす原因にもなる側面があると考えています。世の中が複雑化している一方で、コミュニケーション手段も日進月歩で進化しています。（WebRTCのバージョンアップの頻度も然りです）

このような状況下で大切なのは、声のトーンや表情から相手の真意を的確にとらえることであり、テキストでのコミュニケーションでは、場合によってはスピードが劣化すると考えています。

そこで、従来からあった音声通話やビデオ通話をアイデアと技術で進化させ、コミュニケーションを効率的かつ気持ちよくを行える環境づくりの一助を担いたいと考えたのが、弊社がWebRTCの普及に力を入れている理由です。

ソーシャルキャピタルの蓄積と
WebRTC

まずソーシャルキャピタルを簡単に説明すると、人の価値を「人自身」と「その人の持つ人とのつながり」に切り離して考えてみたときに、その「つながり」の部分に資産性があるといったコンセプトです。つまり、もともとつながりがあって信頼できる知り合いであれば、いろいろと便宜が図られ、物事がうまく進むだけでなく、つながりを持っている状態について人が幸福感を感じるものだとされています。このソーシャルキャピタルの考え方と前述のGoogleでのコミュニケーション方法を合わせて考えると、音声や映像でリアルタイムに接続することの重要性が増していくのではないかとの考えに至ったというのが、結論です。例えば、Facebookでつながっている友達でも、時間が経つにつれて関係性が徐々に薄れていくということは意外に多いのではないでしょうか。そんな時に関係性を保つ、あるいはリビルドするためには、「直接会う」のが普通に考えると最良の選択肢だと思いますが、互いに忙しい身であった場合、簡単にはそうもいかないというのが実情であるとも考えています。つまり、関係性を保つためのコミュニケーション手段としては、以下の不等式が概ね成り立っているのではないかと考えています。①会う＞ ②ビデオチャット＞ ③音声通話＞ ④テキストチャット＞ ⑤メール＞ ⑥なしこの内、WebRTCで担うことが可能なコミュニケーションのが、②③④になります。
（通常のクライアントサーバ型の構成で可能な範囲は、④⑤のみです。）このことから、ソーシャルキャピタルの増加をさせ、世の中をより良くしていくための技術として、リアルタイムにビデオチャットで映像や音声のやりとりが可能で、低コストでの導入が可能なWebRTCが今よりも利用されてほしいと考えています。

対応している
WebRTCの開発環境

自社サーバの構築 coTurnのnode js、GoogleのSDKを用いて構築します。 NTTコミュニケーションズのSkyWayと比較した場合のメリットは、Turnを経由した際の料金が帯域の使用料が低く抑えられることと自由度が高いことが挙げられます。また、SkyWayは、とても良くできていますが、突然、「サービスを止める」といわれるリスクがまったくゼロという訳ではありません。その点では、coTurnやnode jsを用いて開発している場合においては、オープンソースであるため安心です。
SkyWayを用いた開発 NTTコミュニケーションズのSkyWayのSDKを用いた開発です。SDKが良くできており、かなりの自由度のあるカスタマイズが可能なように作られているため、イニシャルの開発費を抑えて安定的なビデオ通話や音声通話の機能を備えたサービスを開発したい場合にはおすすめです。
その他 agoraやjanus、MediaSoupなどを用いた開発に関する相談も承ります。

WebRTCの技術を誰にでも弊社ではWebRTCの技術を用いて、ITツールが苦手な人でも簡単に使えるサービスとして、
２つのサービスを運営しています。もちろんノーコードでご利用いただくことが可能です。

Deck（デッキ）

アカウント登録すると、アカウントに固定のURLが発行され、そのURLをブラウザで表示させるとアプリにビデオ通話や音声通話をかけることができるというシンプルなサービスです。「会わずに済ませる」という文脈でのDX推進のあらゆる業種/業態に適応が可能なサービスに仕上がっていると思います。最大の特徴は、発行されたURLをユーザがブラウザで開くだけで通話ができるという点です。アプリのインストールや個人情報の登録、事前予約、SNSでの友だち承認などが一切不要で、ワンタップですぐにビデオ通話を開始できます。またURLのQRコードも同時に発行されるため、チラシや名刺に貼っておけばプル型の営業ツールになり、工場や工事現場に貼っておけば、機械の不具合のサポートや現場監督をオンラインで呼び出して映像を見せながら指示を出すことが可能になります。利用シーンとしては、ECサイトの在庫確認や対面での商品説明、会社の問合せ窓口、マンションやモデルハウスのオンライン見学、中古品のオンライン査定、美容のカウンセリングやオンラインでの医療相談など、多くの業界の様々なシーンで利用されています。ご興味のある方は、無料でご利用いただけるプランもございますので、ぜひご覧ください。
Port（ポート）

Portは、Deckの姉妹サービスですが、通話相手に対して通話時間に応じて課金することが可能なサービスです。課金額は、アカウント所有者が自由に設定することができ、各種カウンセリングや占い、遠隔医療系サービス、外国語学習、プライベートレッスン、コンサルティングなどで利用されています。弊社の調べでは、Portは通話相手に自由に課金することが可能かつ、無料で簡単にスタートできる日本で唯一のサービスです。