RevComm Tech Blog

コミュニケーションを再発明し 人が人を想う社会を創る

Gather公式の壁を破り100人超えの配信を低遅延で実施した方法

RevComm の木村です。

所属チームはInfrastructure(インフラチーム)です。

今回は、RevCommの全社オフサイトに関する記事の第3弾になります。

オフラインでの開催予定だった会が急遽オンラインイベントとなり、第1部はZoom開催、第2部の懇親会はGatherでの開催となりました。

Gatherとは、2D RPGのような雰囲気でアバターを操作して会話や画面共有をしながらビデオチャットを行うことができるバーチャルスペースです。

本記事では、Gatherを利用した参加者160人超のオンラインイベントを実現する上で発生した課題と解決策に関して触れていきたいと思います。

記事の構成は以下のとおりです。

第1章 - バーチャルスペースの方法

本記事では、イベントの参加人数とコンテンツ内容は決まっているものとします。その段階でまず行うべきことが、会場の作成です。

Gather公式のテンプレートもいくつかあり、公式のマップエディタも存在するためスペース作成をブラウザ上で完結することも可能です。しかし、今回は条件に見合う公式テンプレートがなく、さらに公式マップエディタの自由度も少なく感じたため、Tiledというマップエディタを利用してスペースを作成することにしました。

スペースの作成自体は本記事の主題ではないので軽く触れる程度に説明しますが、以下の5ステップを実行してGatherのスペースを作成しました。

  • 32×32のマスでスペース全体のサイズを決定する
  • Tiled上でGatherのタイルセットを配置して、PNG形式でエクスポートする
  • PNGをPhotoShopで編集して、文字や矢印を配置する
  • 出来上がった画像をGather上でインポートする
  • Gather上でSpotlightやワープ設定、制限エリアなどを設定する

結果として、今回作成したスペースは以下の構成になりました。

  • 幅1280px × 縦2560px(40マス × 80マス)の2ルーム構成
  • メインルーム側には司会者用にSpotlightを多数配置する
  • サブルーム側には中継者用のSpotlightを少数配置する
  • 各ルームの上段にはテーブルを配置する
  • テーブルにはPrivate Areaを設定する

※スペース設計にもこだわりが隠れているのですが、本記事では割愛します。

第2章 - リハーサル時に発生した問題とその解決策

いよいよ作成した会場でリハーサルです。

前提として、今回のイベントでは、参加者に対して司会者が画面共有をしながら運営を行う必要がありました。Gatherの公式ページには、100人以上の参加者がいるルームで配信を行う場合には、YouTube LiveやZoomなどの別ツールを使用することが推奨されています。

調査をしたところ、配信者用のルームを別途用意し、会場に設置したEmbed Mediaで配信者の風景をYouTube Liveで配信するといった記事がWeb上で見つかりました。

今回も当初は見つけた記事と同様に別室からの配信を行う選択肢を検討しました。しかし、試行錯誤の結果、低遅延で画面共有を行いつつ会場の雰囲気を司会者に伝えるために配信用のルームは作成せず、メインルームの内容をサブルームに配信する方式を採用しました。

この方法であれば、各ルームの参加人数が100人を超えないように調整しながら、司会者にもライブ感を伝えることが可能です。

※中継者の画面。参加者の反応が見えることが分かります。

懇親会のコンテンツとしては複数の企画がありましたが、その一つにennoshitaと言うツールを利用したクイズがありました。クイズの設問もその場で提示され、回答までの時間制限もある、リアルタイム性が厳しく求められるコンテンツです。

※実際に実施されたクイズの画面。

当初検討していたYouTube Liveを利用する方法では、数秒の遅延が発生することがあらかじめ分かっていました。そこは司会者の話術でカバーしてもらう想定でしたが、実際にリハーサルを実施してみると、話術ではカバーできない問題が発生しました。

具体的には、ライブ配信を見ている人によって配信のタイムラインがずれるという問題です。司会者の知らないところで配信が遅れている状態では、クイズの進行が成り立たなくなるため致命的です。

また、GatherのEmbed Mediaの仕様も、この問題をより深くした理由です。

GatherのEmbed MediaにYouTube Liveを埋め込んだ場合には、YouTube側のコントロール機能が隠されてしまい、一時停止および再生のみ実施できる仕様になっています。そのため、ユーザ側の操作で最新のタイムラインに移動することが一切できません。

※YouTube公式サイトにはある上記のコントロール機能が隠されてしまいます。

事前に小規模なテストをしていた際には、配信とのギャップが10秒ほどあれば、最新のライブ映像状態にスキップされる動作(※)が確認できていました。しかし、より大規模にリハーサルを行ったところ、そのスキップ動作が再現されない人がいました。先に述べたとおり、コントロール機能は隠されているため、こうなるとどうしようもありません。 ※実際には、一時停止後に再開するという操作が必要でした。

この問題が発覚したのは本番2日前のリハーサルで、今さらコンテンツの内容を変えることはできません。Gatherでの配信を諦め、Zoom配信に切り替えるべきかと全関係者で悩んでいたところに、とあるひらめきが天から舞い降りました。

ここからが本記事の本題です。

ひらめきにより実現された、公式のベストプラクティスを超えた配信方法の概要は以下のとおりです。

  • 同一のPCから各ルームに中継用のアバターを設置(送信者、受信者)
  • メインルームの画面を中継用のアバターで画面共有し、サブルーム内にSpotlightで共有

ルーム間の中継をYouTube Liveで行わず、同一のPCを利用する点が一番のポイントです。

全体構成を図にすると以下のようになります。

この方法のよい点をまとめると以下になります。

  • ルーム間の転送に要する遅延がほぼない(およそ0.1秒)
  • 仮に人数がさらに倍になったとしても、ルームと中継者を増やすことでスケールアウトが可能
  • 中継者は2ルームとも様子が見えているため、不測の事態に対応しやすい

※実際にサブルーム側の準備が整う前にクイズが進行しそうになったので、中継者をしていた私が司会者に声をかけ、進行を待ってもらいました。

逆に悪い点をまとめると以下になります。

  • メインルームからの一方向の共有となるため、メインルーム側の参加者からはサブルーム側の状況が見えない(※おそらく改善可能で、第4章で触れます)
  • 中継担当者も一参加者としてイベントに参加する場合は、中継用とは別のPCが必要になる
  • PCと画面がたくさんないと、全部を把握することが難しい

※当日はこんな形で参加していました。右上のディスプレイには、別入力で中継者の画面が全画面表示されています。

第3章 - イベントを終えてみての感想

Gatherを採用した決め手は、ホテルなどの会場を借りて実施する懇親会のように参加者が自由に各テーブルを移動しながら懇親できる場を用意したいという点でした。今回は、思惑通りに各テーブルでの会話が繰り広げられていました。

RevCommはフルリモートの社員が多いためオンラインの懇親会の開催頻度は多いのですが、普段はZoomやGoogle Meetを利用しています。今回の経験から、オフラインの空気感を再現することができるGatherを利用した懇親会もいいものだなと思いました。

第4章 - さらなる工夫

悪い点でも取り上げましたが、今回採用した方法はメインルームからの一方向配信です。

さらに大規模なイベントやコンテンツの内容次第では、ルーム間でのやり取りもしたくなることもあると思います。ということで、改善の余地がないか考えてみました。

一方向配信にしていたのは、音声がループすることが理由でした。逆に言うと、音声のループ問題さえどうにかできれば、ルーム間での双方向配信が可能になります。

改めてGatherの設定を行い、ループ問題が解決できないか確認してみました。その結果、理屈上は以下の構成を取ることにより双方向での配信が可能ではないかという結論に至りました。まだ実際に試してはいませんが、試された方がいればツイッターなどで教えていただけると幸いです。

  • 基本的な構成は同様
  • 中継者を1名追加(便宜上Proxyとします)
  • 中継者AのGather上で、Proxy BのUser Volumeをミュートする