ビジネスマッチングであれ、恋愛系マッチングであれ、マッチングした相手とはコミュニケーションが不可欠です。
仲介型サービスでは、『チャットサービス』や『ファイルのやり取り』等を行うためのコミュニケーション機能が搭載されていることは少なく有りませんが、『通話機能』が搭載されているマッチングサービスは、そこまで多くありません。
実は『アプリやサービスに通話機能をいれる』というのは、難易度が高い技術なのです。
本日は、技術的な側面からそのあたりのことについてご紹介します！
通話機能やビデオ電話機能を使うにはWebRTCが必須
WEBであれアプリであれ、通話機能を使うには何らかの通信を行わなければなりませんが、一般的なHTTPのリクエスト（WEBページ等と同じ手法）だと遅すぎます。ざっくりと語ると、こちらから『こんにちは』と相手に行ってから届くまでが1～3秒、更にそこから相手が『こんにちは』と返事を返してくるのに、更に1～3秒掛かるレベルです。これではとても通話が成り立ちません。
更にクライアントからサーバへの一方的な通信が基本なので、その点でもリアルタイムの会話は難しいです。
これを『WebSocket』という方式にすれば、少しはマシになりますが、それでもまだラグがあります。
WebSocketを使えば、サーバとクライアント間でリアルタイムな双方向通信が可能です。ただし、通信は一旦サーバを経由するため、チャット等のテキストデータなら問題ないのですが、音声データや動画データで快適な通話を行うのは難しいです。
またサーバにも負荷がかかるため、AWS等の従量課金制のサーバを使う場合、コストも問題になります。
そこで最善策となるのが『WebRTC』なのです。
『WebRTC』は『Web Real-Time Communication』の略称です。
先程のWebSocketが『サーバとクライアント間のリアルタイムな双方向通信が可能』と説明しましたが、WebRTCは『クライアントとクライアント間でリアルタイムな双方向通信が可能』な通信方式です。
最初にサーバ側で接続を確立した後は、音声データ・動画データを直接クライアント間（P2P）でやり取りします。
大きなデータはサーバ側を通さずやり取りするため、接続環境さえ整っていれば、ほとんどラグを感じさせること無く通信が可能です。
しかもこのWebRTCはブラウザでやり取りが可能です。よってファイアウォールの設定を変更したり、ポートを開放したりといった一般ユーザーには難しい手順も踏む必要はありません。
よって、もしマッチングサービスで通話機能をつけようとするならば『WebRTC』が一番現実的な選択肢となります。
各種クラウドサーバで『WebRTC』を使うには
ではその『WebRTC』はどのように実装できるのでしょうか？
先ほどの図では割愛しましたが、『WebRTC』を実装する場合、「STUNサーバー」や「TURNサーバー」というものが必要になります。
詳しい説明は割愛しますが、『セキュリティやプライバシーを保ったまま、直接通信を実現するために必要なサーバ』と思ってください。
本来それらを導入するのはとても手間が掛かるのですが、各クラウドベンダーが使いやすい形で提供してくれているため、そちらをご紹介します。
AWS：Kinesis Video Streams
『Kinesis Video Streams』は、ビデオ通話やライブ配信を簡単に実現するためのサービスです。
先ほど出した「STUNサーバー」や「TURNサーバー」としての役割はもちろん、スケーラブルなインフラとして使えるため、急に通信量が多くなっても問題なく対応できます。
またSDKで簡単に実装できるため、複雑な専門知識がなくとも利用が可能です。
Azure：Azure Communication Services
『Azure Communication Services』は、Microsoftが提供しているマルチチャネル コンピューター APIです。
音声通話はもちろん、ビデオ通話・チャット・テキストメッセージ・SMS等、多岐にわたるコミュニケーションを実現できます。
なおこのサービスにはMicrosoft Teamsの技術が使われているため、品質は十分でしょう。
なお、こちらもSDKが用意されているので導入は用意です。また従量課金制なので無駄なコストを払う必要もありません。
Google Cloudは専用のサービスがない…
AWS、Azureとくれば、次はGCPと言いたいところですが、GCPには前述したようなサービスがありません。
理由は諸説ありますが、GoogleはそもそもWebRTCそのものの利便性を追求しており、プラットフォームに依存しない実装を推奨している……という説もあります。
（実際、webrtc.orgはGoogle for Developers上で管理されています）
Twilio、Vonage、Agora、Daily.coなどのPaaSベンダーもあり
なお大手クラウドサーバ以外にも、PaaSとしてこれらの通話サービスを展開している企業があります。
AWSやAzureを使うと、ベンダーロックイン等が気になるところですが、こちらであれば自由な環境で、手軽に導入ができるためより手軽です。（どのサービスでも、おおむねSDKやAPIが提供されています）
ただし、利用状況によってはAWSやAzureよりも高額となるケースが有るため、予めどの程度の利用が見込まれるか調査を行いましょう。
オープンソースも存在するが……
『他社にお金を払うのではなく、自分で全てを賄いたい』という方には、オープンソースで全てを揃えることも可能ではあります。
WebRTCに必要な『シグナリングサーバ・STUNサーバ・TURNサーバ・ICEサーバ』各種に、オープンソースのプロジェクトが存在するので、これらを組み合わせ、構築し、自身で管理するのです。もし実現できれば、毎月の利用量を節約できます。
……ですが、実際のところこれらを使うのは至難の業です。
まずWebRTCの複雑な仕組みを理解した上で、各プログラムを適切に設定する必要があります。
またサーバのセットアップやメンテナンスも自分で行わなければなりません。一度設定したら終わり、ではなくセキュリティパッチも定期的に当て続ける必要があります。
更に利用者が増えた際には、それに耐えられるようインフラを整えなければなりませんし、減ったら減ったでまたスケールダウンが必要です。
もしサービスがダウンして停止した場合、運営側が直さなければなりません。365日、24時間対応する必要があります。
もしオープンソースの開発が止まり、整合性が取れなくなった際は、新たなサービスを見つけるか自前で作成する必要もあるでしょう。
……とてもではないですが、割が合いません。
一応オープンソースのプロジェクトを紹介しておきますが、基本的には前述のクラウドサービスかPaaSを強くおすすめします。
- シグナリングサーバー：Socket.io、PeerJS、Signalmaster
- STUNサーバ：Coturn、stund
- TURNサーバ：Coturn
- ICEサーバ：Pion ICE、JSEP (JavaScript Session Establishment Protocol)
そもそも通話機能が必要か熟考を
ここまでマッチングサービスに付随させる通話機能について、システム的な面からご紹介しました。
しかしながら、まず考えていただきたい点としては『通話機能の実装が必要か？』という点です。
最初に話した通り、大手のマッチングサービスでも通話機能・会議機能をつけているサービスは多くありません。
それは実装の難易度・コストに比べて、プラットフォーム側の旨味がほとんどないからです。
先ほど書いた通り、通話機能は実装そのものが簡単では有りません。ほとんどの人はZoomやGoogle Meet等の使い慣れたサービスを使いたがるため、オープンソースのプロジェクトはもちろん、導入に関するナレッジ（知識）も、それほど世に出ていなかったりします。
AzureやPaaS等のサービスを使えば、実装は比較的容易になりますが、それでもUI周りの設計等でコストは掛かりますし、毎月のサービス利用量もそれなりの規模になります。
そのような多額の費用を掛けて、プラットフォーム側は何を得るのでしょうか……？
取引仲介型のマッチングサービスであれば、『外部コンタクトを取らせない』という一応のメリットはあるかもしれませんが、それも微々たる効果であり、とてもコストに見合った効果はでないでしょう。
（なお、やり取りを録音してデータ収集に役立てる……という案もあるかもしれませんが、WebRTCの会話は仕組み上録音が出来ません）
なので今一度『マッチングサービスに通話機能は必要か？』という点を熟考していただき、コストに見合った設計を考えていただければと思います。
マッチングサービスを運営するには？
『マッチングサービス』は、今大変需要が高まり、急成長している分野です。
ただし、その運営は決して簡単ではありません。
TodoONadaでは、マッチングサービスを低コストに始める方法や、サービスで決めないといけないこと・運用方法等について本ブログでご紹介しています。
各記事をご拝読いただければ幸いです。
また本記事でご紹介した内容を含め、各形態でのマッチングサービスを低コストで開発したいなら『マッチングワン』がおすすめです。
『マッチングサービスを開発したいけれど、あまりコストは掛けられない』『必要な機能をしっかり揃えたい』という方におすすめなパッケージとなりますので、ぜひ一度ご相談ください。
