共催企業3社とのオンラインイベント「Qiita Summit ～リアルタイムコミュニケーション～」を開催
テレワークやオンライン会議・オンラインイベントなどの普及によって、リアルタイムコミュニケーション（RTC）へのニーズが高くなりました。それを実現するのが、WebRTCの技術です。
WebRTCとはサーバーを介さずに端末間で直接通信を行う通信方式を基盤とした技術です。特徴として、データの転送速度の速さ、安定した通信が挙げられます。Webブラウザ間でのリアルタイム通信に適しているため、チャットやビデオ通話、ライブ配信といったリアルタイムコミュニケーションツールに使われています。世界のWebRTC市場規模は2023年に52億米ドルと評価され、2024年には70億3,000万米ドル、2032年までに940億7,000万米ドルに成長すると予測されるなど、今後も急成長が見込まれています。
Qiita株式会社では2024年9月13日に、WebRTCなどの配信・通信技術を活用してリアルタイムコミュニケーションツールを開発するNTTコミュニケーションズ株式会社、株式会社ブイキューブ、ZVC JAPAN株式会社の3社と共同で、オンラインイベント「Qiita Summit〜リアルタイムコミュニケーション〜」を開催しました。イベントでは3社の技術やノウハウ・活用事例に触れるスポンサーセッションのほか、リアルタイムコミュニケーションやWebRTCに詳しいゲストによるLTセッションも実施。本記事では、当日のセッションの様子をお伝えします。
目次
オープニングセッション「リアルタイムコミュニケーションとWebRTCの過去から未来」
「そもそもWebRTCって何？」「リアルタイムコミュニケーションの技術は、どのように変わってきたの？」…そのような疑問にお応えしたのが、WebRTC Meetupの運営にも携わる、がねこ まさし氏です。リアルタイムコミュニケーションとWebRTCの基礎知識から現在までの移り変わり、リアルタイム通信の未来まで語っていただきました。
登壇者情報
WebRTCが起こした「リアルタイムコミュニケーションの民主化」
清野：本日はよろしくお願いいたします。 はじめにリアルタイムコミュニケーションやWebRTCの概要について教えてください。
がねこ：リアルタイムコミュニケーションとは、離れた場所にいる人同士が音声や映像を使ってコミュニケーションを取ることです。WebRTCとは、リアルタイムコミュニケーションをウェブ上で行うための技術や仕組みを指します。WebRTCはウェブブラウザだけでなく、ウェブにつながる様々なアプリやデバイス間でも利用できます。
WebRTCが登場したのは2011年で、当時はすでにSkypeやLINEの音声通話、企業向けではWebexやFaceTimeなど、様々なリアルタイムコミュニケーションツールが存在していました。2013年にはZoomも登場し、競争が激化していきます。
そのような状況の中、「もっと自由にリアルタイムコミュニケーションツールを作りたい」というニーズから生まれたのがWebRTCでした。WebRTCの登場によって、それまでは一部の企業だけが独占していたリアルタイムコミュニケーションの技術を誰もが使えるようになりました。まさに「リアルタイムコミュニケーションの民主化」が起きたわけです。
清野：WebRTCは、アプリやデバイスをつなぐ「本体」のようなものでしょうか？
がねこ：WebRTCとは、双方向のリアルタイム通信を実現するためのAPIやプロトコルの集合体なので、ブラウザとデバイス間での通信ができます。音声や映像を暗号化する方式を規定したり、そもそも音声や映像をどのようなコーデックで取り扱うかを決めたりするための手順も含めたものが、WebRTCというイメージです。
清野：WebRTCは新しい概念というよりも、既存の概念や規格、プロトコルなどを組み合わせるためのルールのようなものなのですね。それを1つの規格にすることで、APIインターフェースとしてアクセスできるようになっているのでしょうか？
がねこ：まさにそうですね。新しく発明したというより、今まで使われていたものをうまく組み合わせて実現しているという感じです。
ライブ配信、AIの活用…利用シーンの拡大が技術を向上させる
清野：2010年代に様々なリアルタイムコミュニケーションツールが登場してから10年間で、どのような変化がありましたか？
がねこ：はじめはブラウザでの使用が中心で、 その後アプリやデバイスでも使われるようになりました。当初、アプリでの使用は非常に難しかったのですが、様々なベンダーがアプリでの使用に対応するSDKを提供したことで、徐々にハードルが下がっていきました。
清野：もともとはネイティブアプリなどで使われていたリアルタイムコミュニケーションをブラウザがサポートしたことで、様々なサービスが通信技術として活用できるようになったのですね。
がねこ：そうですね。転機の1つは、ブラウザのサポートが拡大したことです。2017年にはSafariがWebRTCをサポートし、モバイルでの利用が急激に増えました。その後ChromeのEdgeが登場した際にもデフォルトでWebRTCが使えるようになっていたので、企業向けの普及にも貢献したはずです。
もう1つの転機は、WebRTCによってビデオ会議が当たり前の存在になったことです。誰もがカメラやヘッドセットを持ち、日常的にビデオ会議を利用したことで、安定して通信できるノウハウが蓄積されていきました。
清野：需要の高まりに伴って利用シーンが増えてきたことで、技術の広がりも加速度的になっていったんですね。
がねこ：はい、そうです。WebRTCが登場した頃は1対1や少人数での通話に使われることがほとんどでしたが、今では大人数の会議やリアルタイムのイベント配信といったユースケースも増えてきました。もともとWebRTCはP2P（ピアツーピア）で、ブラウザ同士、デバイス同士が通信するという発想でしたが、それでは大人数の会議のようなユースケースに対応できません。そこで「サーバー経由で通信する」という方法が一般的になりましたが、そのサーバーを自分で立てて運用するのは現実的ではありません。そのためCPaaS（Communications Platform as a Service）のようなプラットフォームも浸透しました。
清野：WebRTCは今後どのように変化していくのでしょうか？
がねこ：リアルタイムコミュニケーションはますます盛んになっていくでしょう。なかでも双方向のコミュニケーションでWebRTCを超えるものはないので、WebRTCの利用もさらに拡大していくと思います。また、非対称のリアルタイムコミュニケーションも増えてくると予想されます。一方通行の配信ではなく、見ている側もコメントをしたりスパチャで投げ銭したりすることで、「リアルタイムでつながるうれしさ」を実感できるようなシナリオが増えるのではないかと考えています。
更に、AIとの組み合わせがあります。すでにノイズキャンセリングやバーチャル背景、音声の文字起こしや翻訳などで使われていますが、リアルタイムのボイスチェンジャーやアバターの活用など、AIを使ったリアルタイムコミュニケーションの機能はさらに増えていくでしょう。
清野：ありがとうございます。リアルタイムコミュニケーションの進化に伴って技術領域や業界が拡大し、これまで想像できなかったことが実現していくのが楽しみです。
スポンサーセッション
ここまでの内容から、WebRTCが実際のツール開発の中でどのように活用されているのか、気になった方も多いでしょう。スポンサーセッションでは、リアルタイムコミュニケーション業界を代表する3社の担当者が登壇。自社サービスの技術の仕組みから活用事例、開発のウラ側までお話しいただきました。
思わず触ってみたくなる！？国産CPaaS「SkyWay」のウラ側お見せします
登壇者情報
WebRTCが登場した2011年当時、使いこなすには様々なプロトコルや技術の知識、サーバーの構築・運用が必要でした。そこで2013年に「WebRTCの面倒くさいを解決する」を掲げて我々がリリースしたのが、WebRTC技術を活用したCPaaSであるSkyWayです。コミュニケーションを生業にする企業としてWebRTC業界の発展に寄与したいという想いから、リリース当時から今に至るまで無料でのサービス提供にこだわってきました。おかげさまで10周年を迎え2023年には新しいバージョンをリリースしました。具体的には、「1対1の通話をしたい」「配信をしたい」「レコーディングをしたい」「通話の品質を可視化したい」といった様々なユースケースに応じた機能を組み合わせて利用できるようになりました。
SkyWayは通話のトラフィックを中継する一部のTURN（ターン）サーバという、メディアの中継する一部のサーバを除き、すべて国内のデータセンターで運用しています。そのため、データを国内のみに限定して流通・保管したいというニーズにも基本機能で対応できます。
さらにリアルタイムコミュニケーションを実装するためのSDKも様々なプラットフォームに対応しています。近年需要が高まっているメタバース系の開発に対応したUnity SDKや通信品質の可視化機能（Analytics）、RaspiなどのIoT機器で利用できるLinux SDKも提供しております。今後はノイズキャンセリング機能や大規模配信機能、提供中のサイマルキャスト機能を更に賢く利用する利用帯域の最適化機能の提供も予定しています。
ここからは、ユースケースについてもご紹介いたします。WebRTCはP2Pのイメージが強いかもしれませんが、多人数通話やライブ配信など、様々な目的で活用されています。たとえば、オンライン英会話では、SkyWayが得意とするP2Pの通話を利用した生徒と講師のマンツーマンレッスンに加えて、SFU（エスエフユー）サーバーというメディアサーバーを活用した多人数のライブレッスンも提供されています。また、他のユースケースでは、わずか2週間ほどの開発期間でメタバース空間内でアバター同士のボイスチャットや位置情報共有の機能を実装された例もありました。
SkyWay開発の裏側を少しお見せします。 SkyWayは内製でサービスを提供しているので、プロダクトとお客さまの距離が非常に近いのが特徴です。提案から設計、構築、運用など各フェーズごとに社内のエンジニアが担当しています。更に、トラブル時にはプリセールスエンジニアがテクニカルサポートエンジニアや開発エンジニアと連携し、技術面とビジネス面の両面から課題解決をサポートします。例えば、テクニカルサポートエンジニアはお客様の課題解決のために、社内で検証を行い、回避策やサンプルコードを提供します。開発エンジニアはプリセールスエンジニアからのフィードバックを迅速にキャッチアップし、プロダクトの改善を行います。このように、ワンチームで対応することにより、連携の速さが強みとなっています。
WebRTCでは定期的なブラウザのアップデートに追従する必要が出てきます。ChromeやFirefoxでは4週間ごとに新しいバージョンがリリースされ、WebRTCに関する機能にも大小様々な修正が入ります。そのためサポートブラウザとSDKの組み合わせで機能を提供できているかどうかをリリースごとにテストしながら、問題があればSDKの改修やアナウンスの発信、ワークアラウンドの提示などの対処を行います。
繰り返しとなりますが、SkyWayはプロダクトとお客さまの距離が近いサービスというのが特徴です。WebRTC業界を盛り上げるために、これからも開発者のみなさまと共に歩んでいきたいと思います。ありがとうございました。
なぜZoomがAPIやSDKを開発者に提供するのか？その全貌を公開！
登壇者情報
Zoomはミーティングやウェビナーだけでなく、非常に幅広い機能を内包する形でサービスを展開しています。 クラウドPBXのZoom Phoneやコールセンター向けクラウドのZoom Contact Center、メールカレンダー機能、ドキュメント管理サービスのZoom Docsのほか、昨年の企業買収により社内コミュニケーション向けプラットフォームのWorkvivoを取り込みました。
我々は2011年に創業し、クラウドファースト・APIファーストの開発を行っています。そのため、これまでご紹介したサービスを自社で使うときにも、APIやSDKを駆使していますし、 ほかの事業者にも使っていただけるように開放しています。Microsoft、Google、Salesforceなどのサービスとの連携も可能ですし、それらを組み込んでZoomのインフラをお使いいただくこともできます。
Zoomでは全世界で数億人が同時に使えるインフラを持っています。また、より高度な信頼性と品質を保つために、グローバル分散ネットワークを活用しています。更に、クライアント側のリソースを利用することで通信品質を良好に保つ独自の技術を採用しています。私たちは自社を支えるそのようなインフラや技術を、Zoom Video SDKという形で外部に提供しています。
では、なぜZoomが自社のサービスを支えるインフラを提供しているかというと、それによって新たなビジネスの機会を得ることができると考えているからです。Zoomの組込みライセンスをご利用いただいている企業様は日本国内でも多く存在します。例えば、オンライン診療などの医療現場やお年寄りとご家族を結ぶサービスにワンボタンで繋がる仕組みを作る事はZoom単体では実現が難しいです。しかし、様々な事業者がZooｍ Video SDKを活用することで、リアルタイムコミュニケーションを提供できるようになり、結果的に多くの方にZoomをご利用いただけるようになります。
Zoom Video SDKの最大の特徴は、Zoomのクラウドインフラを使って高品質なビデオ通信が実現できることです。UI、UXを独自にカスタマイズできる一方で、Zoomが全世界に持つデータセンターのネットワークを利用した高品質なサービスを維持できます。また、Zoomと同じインフラを利用する為、日本国内ではISMAPにも既に対応しております。CPaaSのTwilioさんもこのような強みを高く評価してくださり、ビデオに関するサービス終了にあたって、既存のお客さまの推奨移行先としてZoom Video SDKを選んでくださいました。
Zoom Video SDKではノイズリダクションやバーチャル背景、文字起こし、翻訳といったAI関連機能に関しても、Zoomと同じものをご利用いただけます。今後は会議内容の要約機能や分析機能そして会議内容に関するQ&AをAIが回答する自動回答機能などを提供予定です。また、「UIをカスタマイズせずシンプルに組み込みたい」というご要望にお応えしてUIツールキットもリリースし、ネイティブアプリおよびウェブアプリを数行のコードで実装いただけるようになりました。
Zoomはこれからも開発者のみなさまに寄り添い、リアルタイムコミュニケーションの発展に貢献していきたいと考えています。グローバルなインフラを基盤にした既存機能の進化、そして独自性あふれる新機能の提供にご期待ください。
ライブ配信からクラウド技術まで：映像音声コミュニケーションの最前線
登壇者情報
Tencent Cloud（テンセントクラウド）はパブリッククラウドサービスプロバイダーとして、様々な業界にサービスを提供しています。今回はTencent Cloudの代表的なサービスをご紹介します。
テンセントクラウドストリーミングサービス（CSS）は、エンドツーエンドのライブオーディオ・ビデオブロードキャストソリューションを提供するワンストップPaaSサービスです。安定したライブプッシュ機能、トランスコーディング、配信＆再生SDKなどのストリーム処理ライブラリなどが含まれます。大量の同時アクセスに耐えうる超低遅延、超高画質、超高性能なサービスで、最先端のAI技術を活用した高品質なライブ配信を実現しています。
CSSの特徴は、業界トップレベルの圧縮率を実現するトップスピードコネクトです。これによって配信時に映像の品質を保ちつつ、必要なネットワークの帯域幅やビットレートを作成できます。
CSSではリアルタイムの顔ぼかし技術や、コンテンツの不正利用や違法コピーを防ぐために不可欠なTRAの技術、自動音声認識と翻訳、字幕の埋め込みをリアルタイムで行うライブ字幕機能など、ライブ配信に必要な技術や機能を網羅的に提供しています。近年特に注目されているのが、オブジェクトの自動検出機能です。出演者の顔など視聴者が注目するオブジェクトを自動的に検出し、それを避けてコメントを配置します。
ライブ配信においては他の配信者とのコラボレーションなど、リアルタイムコミュニケーションの機会が頻発します。このようなシーンに備えて、テンセントリアルタイムコミュニケーション（TRTC）というソリューションもご用意しています。 TRTCはテンセントが長年にわたって蓄積したネットワークとオーディオ、ビデオ技術を基盤に、高品質で信頼性の高いビデオSDK体験を提供しています。
音声でのリアルタイムコミュニケーションに重要な機能として、ノイズキャンセリングの機能があります。リアルタイムコミュニケーションの中で環境音が会話に混じると、 内容が聞き取りにくくなるからです。これに対してTRTCはエコーケンサリング、ノイズキャンセリング、自動音量調整機能を組み込んでいます。特に最新のAIノイズキャンセリング機能は、従来のノイズ抑制技術では対応が難しかった断続的なノイズを効果的に抑制できます。
ライブ配信では、コメントのやり取りや視聴者リスト管理などの機能が欠かせません。こうしたシーンに対するソリューションが、Chatです。Chatには1対1のチャット、グループチャット、チャットルーム、システム通知などの機能があり、開発者はわずか1日で独自のチャットアプリを構築できます。Chatは独自のAT転送技術を利用し、ネットワークパケットロス60%、メッセージ送信の成功率は100%を実現しています。
Tencent Effect SDKは、バーチャル背景やフィルター処理などを実現するサービスです。 AI技術によって300以上の全身ポイントと40以上の顔のポイントを認識し、身体のあらゆる部分に対してエフェクトをかけられます。配信者は自分の好みに応じて外見をカスタマイズし、視聴者により良い印象を与えられます。
Tencent Cloudにはストリーミング技術を活用したクラウドゲーミングやTRTCを利用した対話型AIなど、ほかにも魅力的なサービスが数多くあります。また、今後も他サービスにない独自のサービスを開発予定です。ぜひご期待ください。
Tencent Cloudに関するお問い合わせ・無料トライアルはこちら
※ Tencent Cloudの日本正規代理店である株式会社ブイキューブが、技術的なサポートも日本語で丁寧に対応いたします。
QiitaユーザーによるLT
ラストを飾ったのは、リアルタイムコミュニケーションやWebRTCに詳しいQiitaユーザー3名によるライトニングトークです。WebRTCを使った開発・運用のポイントや開発事例、CPaaSベンダーの選定基準など、開発者が気になる内容が満載のセッションが続きました。
動画配信技術に入門する
登壇者情報
リアルタイムコミュニケーションは非同期と同期、双方向と片方向という二軸で考えられます。非同期型・片方向通信のビデオオンデマンドは、システムにアップロードしたログファイルをプロトコルで配信するもので、キャッシュを利かせやすいという特性があります。同期型・片方向通信のライブストリーミングの場合は、リアルタイムのインプットによってデータインジェスチョンを行います。視聴者数が増えれば、その負荷に耐え得るインフラが必要になります。
実際にはどのように技術を組み合わせて使うのでしょうか。一例としては、まず配信サーバーにmp4をアップロードして、FFmpegで分割したファイルを作成し、HTMLの中にプレイヤーを配置して、最終的に出ていく時にCloudflareでキャッシュを利かせるという構成が考えられます。
セグメントに分けた動画ファイルを最初に3つほど取りに行きつつ、再生中も先のファイルを取りながら配信します。今回、動画ファイルに関してはキャッシュを利かせるようにしているため、Cloudflareキャッシュステータスがヒットになっているものが随時取られて、快適に見られる構成ができています。
ビデオオンデマンドのユースケースでは、Cloudflareのページとストリームとアクセスを使って、簡単なページを作りました。たとえばCloudflareのページには社内研修動画の一覧が表示されて、実際にストリームのプレイヤーで配信することが可能です。
ライブストリーミングのユースケースは、One To Manyのシナリオでご紹介します。インジェストのためのシグナリングプロトコルであるWHIPを使ってストリームでチャンネルを作成し、配信してみました。ストリームに関してはストリームライブインプットを作っていただくとWHIPのURLが貼り出されますので、こちらに向けて各ブラウザで映像を送ることができれば、すぐに配信できます。
最後にオンラインミーティングのユースケースです。Cloudflare CallsというWebRTCのSFUサービスを使いました。Cloudflare Callsは1対1のビデオ通話からOne To Many、Many To Manyのオンライン会議まで構築できる便利なサービスです。このように、ウェブメインでWebRTCを使うとブラウザベースの仕組みが実現できます。 こうした仕組みを使ってサービスや機能を作れると楽しみも広がりますので、ぜひ試してみてください。
GoのWasmでWebRTC P2Pで通信する シンプルなP2Pチャットによる検証
登壇者情報
私は現在、Goを用いたバックエンドエンジニアとして仕事をしています。WebRTCに興味を持つ以前は、チャットなどができるWebSocketで遊んでいたのですが、GoのWebRTCのポケットパッケージが活発で日本語の記事も豊富だと知り、WebRTCに興味が出てきました。ちょうどその頃、EbitengineというゲームのライブラリがWasmでビルド可能だと知り、WebRTCと組み合わせて通信対戦ゲームを作ってみたいと考えました。
Wasmには文字列とバイナリーを送る仕組みがあり、それがデータ値になります。これはP2Pでも実現できるので、WebSocketからWebRTCに移ってもサーバーを介さない通信が可能でした。 個人開発者でもサーバーを多く持たずに通信サービスを提供できるのが良いですよね。
検証にあたっては、まずチャットを作ってみようと考えました。チャットは、送った情報を受け取った側が表示するというだけの原始的な情報の交換です。まずは簡単なチャレンジからはじめるという意味では、最適なテーマだと思います。
WebRTCは、シグナリングと呼ばれる端末間の情報交換によって通信を行います。幸い私はOSS・クライアントともにシグナリングに適したものを無料で提供されている範囲で見つけることができましたので、それらを使ってなんとかGoのWasmにまとめられました。サーバーもGoogle Cloudの無料のサーバーを選び、コストを抑えました。
内容については、クライアントAが入ってきたらWebSocketのメモリ上のマッチ行列で反映し、クライアントBが入ってきてマッチングすれば、同じroomIdを双方のクライアントに送ります。そのIDを使えばWebRTCのための情報がクライアント間で共有されるという流れです。メッセージの送受信は単純で、メッセージを送って表示するだけです。マッチングやシグナリングのために作ったサーバーはチャットでは使わず、 クライアント間で通信しています。
マッチング後の通信もチャットと同じで、 いつもチャットで送って表示しているだけのデータを少し加工し、 いつ送れるか、送ったときにどう受け取ってどう処理するかというコードをゲームの内容に沿って書いてあげれば、今回のようなゲームを作ることができます。今回の内容を参考にして、ぜひWebRTCを使ったオリジナルのゲームを作ってみてください。
リアルタイムコミュニケーションのシステムを設計・運用する際のベストプラクティス
登壇者情報
私は2016年からTwilio、今はVonageというサービスのエバンジェリストを担当しています。そのかたわら、エンジニアとして自社サービスを作ることもあります。これまでの開発経験から感じるのは「自社サービスはサービス品質との戦い」だということです。意識しなければ、自社サービスのサービス品質は悪くなりやすいのです。その理由はいくつかあります。
1つめは、SFUという仕組みです。WebRTCはP2Pで動く仕組みのため、ピアが増えるとクライアント側に大きな負荷がかかります。この負荷を軽減するためにSFUが必要になるのですが、ここに落とし穴があります。SFUでは中央のサーバーが受診したストリームを配信するため、配信に遅延や中断が生じる可能性があるのです。
2つめは、ネットワーク環境の不安定さです。Wi-Fiは速度が安定しないことも多く、それによってサービス品質が低下します。重要なのは、サービス品質の低下をいち早く検知して、復旧するアルゴリズムがあるかどうかです。
3つめは、PCの負荷です。たとえばバーチャル背景機能などではAIが動いていたりするので、それだけCPUのパワーやメモリの消費が激しく、サービス品質の低下につながります。
4つめは、マルチデバイス対応です。WebRTCは基本的に1つの解像度でやり取りをするものなので、複数の解像度のデバイスが入ってくると、どうしても低解像度のデバイスに引っ張られてしまうのです。
こうした自社サービスのサービス品質低下を防ぐには、最適なCPaaSベンダーを選ぶことが大切です。ここからは、ベンダーの選定基準についてお話ししましょう。
そもそもCPaaSベンダーが提供しているのはメインのビデオプラットフォームに加えてシグナリングサーバーなど、様々な付加機能などがあります。なかでも重要なのが、クライアントのSDKです。これがプラットフォームとのやり取りをまるっとラッピングしてくれていて、クライアントSDKが優秀であればあるほどユーザーの行動の量が少なくなるからです。
特に加味しなければいけない点は、UIです。ビデオ会議では人数が増えたり減ったりします。そのたびに自分で画面のサイズを変える必要があるのは大変ですよね。このような作業のどこまでをクライアントSDKがやってくれて、どこからは自分でやらなければいけないのかは、ベンダーによって様々です。
こうしたポイントを押さえてサービスに最適なCPaaSベンダーを選定できれば、サービス品質を保ちながら自社サービスを開発できるでしょう。自社サービスの開発は決して簡単ではありませんが、それだけ大きな可能性を秘めています。ぜひチャレンジしてみてください。
編集後記
リアルタイムコミュニケーションの進化は、意欲的な挑戦の賜物である。業界を代表する3企業の歩みとビジョンを聞いて、そう感じました。リアルコミュニケーションツールは今なお進化しており、さらなる音声品質やセキュリティ面の向上が期待されています。それに伴い、WebRTCへの注目度もさらに高まっていくでしょう。開発者のみなさまの手によって、WebRTCを活用した新しいサービスが生み出される日が待ち遠しくなりました。
文／株式会社Tokyo Edit