LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

モバイルアプリのビデオ通話・音声通話とWebRTC

WebRTC（Web Real-Time Communication）は、ブラウザやモバイルアプリ間でカメラ・マイクの映像と音声をリアルタイムにやり取りするための技術仕様群です。本記事は、モバイルアプリへビデオ通話・音声通話を組み込みたい開発担当者・発注担当者を対象に、WebRTC固有の論点と外注の進め方を整理します。

なお、テキストチャットやプレゼンス通知などのリアルタイム通信（WebSocketを中心とした双方向データ連携）は本記事の主題ではありません。それらは別稿（リアルタイム通信・チャット実装の解説記事）で扱っており、本記事は映像・音声の通話に絞って解説します。

WebRTCはW3CとIETFが標準化を進める技術で、対応ブラウザでは追加のプラグインなしで通話機能を実装できます*1。モバイルアプリでも、ネイティブ向けのライブラリやマネージドSDK経由で同等の機能を利用できます。一方で、後述するシグナリングやNAT越えの仕組みはアプリ側で用意する必要があり、ここが実装の難しさの中心になります。

WebRTCの構成要素 — getUserMedia・RTCPeerConnection・メディアストリーム

WebRTCで通話を成立させるには、大きく3つの構成要素を理解しておくと設計の見通しが良くなります。MDNのWebRTC APIドキュメントでも、これらが中心的なインターフェースとして説明されています*2。

getUserMedia（メディアの取得）

navigator.mediaDevices.getUserMediaは、カメラやマイクからメディアを取得するためのAPIです*1。ユーザーの許可を得たうえで、映像トラックと音声トラックを含むメディアストリームを取得します。画面共有が必要な場合は、別途getDisplayMediaが用意されています*1。

RTCPeerConnection（通話の確立と制御）

RTCPeerConnectionは、2つの端末（ピア）間の接続を確立・制御する中心的なインターフェースです*1。取得したメディアストリームを相手に送り、相手からのストリームを受け取る処理を担います。接続の交渉（ネゴシエーション）や、後述するICE候補のやり取りもこのインターフェースを通じて行われます。

メディアストリーム（MediaStream）

MediaStreamは、音声・映像などのトラックをまとめて扱う単位です*2。多くの場合、1つのストリームに少なくとも音声トラックと映像トラックが含まれます。なお、テキストやファイルなどの任意データを送る用途にはRTCDataChannelという別のインターフェースが用意されていますが、本記事の主題である通話では音声・映像トラックが中心になります*2。

これらのAPIに加えて、WebRTCの接続はDTLS（Datagram Transport Layer Security）などにより既定で暗号化される設計になっています*2。通話内容の保護という観点でも、この点は要件整理時に確認しておく価値があります。

シグナリングサーバとNAT越え — WebSocket・STUN・TURN

WebRTCの仕様には、実は「2つの端末がどうやって相手を見つけ、接続情報を交換するか」という部分が含まれていません。この接続情報の交換を担うのがシグナリングであり、NATを越えて経路を確立するのがSTUN/TURNです。WebRTC固有の論点として誤解されやすい箇所のため、丁寧に整理します。

シグナリングサーバ

シグナリングとは、通話を始める前に双方の接続情報（セッション記述やICE候補）を交換する処理です。MDNのチュートリアルでも、WebSocket接続をWebRTCのシグナリングに用いる構成が示されています*3。シグナリングの仕組みはWebRTC仕様で規定されていないため、WebSocketなどを使って自前で用意する必要があります。

重要なのは、シグナリングサーバが担うのは初期のハンドシェイク（接続交渉）であり、いったん接続が確立した後の映像・音声のデータ自体はシグナリングサーバを経由しない、という点です*2。この役割分担を理解しておくと、サーバ構成や負荷の見積もりがしやすくなります。

NAT越え — ICE・STUN・TURN

多くの端末は、ルーターのNAT（ネットワークアドレス変換）の内側にあるため、外部から直接到達できるIPアドレスを持っていません。WebRTCでは、ICE（Interactive Connectivity Establishment）という枠組みで到達可能な経路の候補を集めて接続を試みます*2。

企業ネットワークや一部のモバイル回線では、ファイアウォールやNATの構成により直接接続が成立せず、TURNによる中継が必要になる場合があります。TURNは映像・音声のトラフィックがサーバを通過するため、利用者数や同時通話数が増えると帯域とサーバコストが増えます。要件定義の段階で、想定する利用環境（社内網・公衆回線・海外拠点など）を洗い出しておくと、TURNの規模見積もりがしやすくなります。

多人数通話の構成 — メッシュ・SFU・MCUの違い

1対1の通話であれば端末間の直接接続で完結しますが、3人以上の多人数通話では構成方式の選択が品質とコストを左右します。代表的な3方式を整理します。

メッシュ（P2P）

参加者全員が互いに直接接続する方式です。サーバを介さないため構成はシンプルですが、参加人数が増えるほど各端末が送受信する接続数が増え、端末の処理負荷と帯域が急増します。少人数の通話に向いた方式とされます。

SFU（Selective Forwarding Unit）

各参加者がサーバに自分のストリームを1本送り、サーバが他の参加者へ必要に応じて転送（フォワード）する方式です。サーバ側でメディアの合成は行わず転送が中心のため、後述のMCUと比べてサーバの処理負荷が抑えられる傾向があります。中〜大人数の通話で広く採用される構成です。

MCU（Multipoint Control Unit）

サーバ側で複数の映像・音声を1本のストリームに合成して各参加者へ配信する方式です。端末側の負荷は軽くなりますが、合成処理を行う分サーバの負荷が高くなります。単一の合成ストリームが必要な場合や、レイアウトを固定したい用途で用いられます。

どの方式が適するかは、想定する同時参加人数・端末性能・サーバ運用体制・求める通話品質によって変わります。少人数の1対1中心ならメッシュ、複数人での会議や配信を見据えるならSFU、合成ストリームが必要な特定用途ならMCU、というのが目安です。多人数のSFU/MCUを自前で構築・運用するには相応のサーバ運用知見が必要なため、次章のマネージドSDK利用も含めて比較検討することをおすすめします。

自前実装かマネージドSDKか — Agora・Twilio・Amazon Chime SDKの選択

WebRTCの通話機能は、シグナリングサーバ・TURNサーバ・SFU/MCUをすべて自前で構築する方法と、これらをまとめて提供するマネージドSDK（通信プラットフォーム）を利用する方法に大別できます。

自前実装（オープンソース＋自社インフラ）

WebRTCの標準APIやオープンソースのメディアサーバを使い、シグナリング・TURN・SFUを自社で構築する方式です。仕様の自由度が高く、外部サービスへの従量課金が発生しない一方、サーバの設計・スケーリング・障害対応を自社で担う必要があります。通話品質の作り込みや運用には、WebRTC固有の知見が求められます。

マネージドSDKの利用

Agora・Twilio・Amazon Chime SDKなどは、通話に必要なサーバ群やSDKを提供する商用プラットフォームです。代表的なサービスの公式情報を整理します。

マネージドSDKは、TURNやSFUの運用を事業者側に任せられるため、立ち上げの早さと運用負荷の軽さが利点です。一方で、利用量に応じた従量課金が継続的に発生し、機能やデータの取り扱いは事業者の仕様に依存します。各サービスの機能・料金・データの取り扱いポリシーは変更されるため、選定時には公式の最新情報を確認してください。料金体系の詳細はサービスごとに異なるため、想定する同時通話数・通話時間で試算したうえで比較することをおすすめします。

コーデックと帯域・品質 — VP8/VP9/H.264/Opusの前提

通話品質と帯域消費は、使用するコーデック（符号化方式）と回線条件に左右されます。WebRTCで対応が求められるコーデックは仕様で定められており、MDNのコーデックガイドにまとめられています*6。

必須コーデック

MDNによれば、WebRTC対応ブラウザは映像でVP8とH.264のConstrained Baselineプロファイル（RFC 7742）、音声でOpusとG.711のPCMA/PCMU（RFC 7874）への対応が求められます*6。つまり、相手環境を問わず成立させやすいのはこれらの必須コーデックです。

任意対応のコーデック

映像ではVP9やAV1、音声ではG.722などが、ブラウザによって任意で対応されています*6。VP9やAV1は同じ画質をより低い帯域で扱える場合がありますが、対応状況が環境によって異なるため、対象とする端末・ブラウザの範囲を踏まえて選ぶ必要があります。

帯域・品質の考え方

同じ通話でも、解像度・フレームレート・参加人数によって必要な帯域は変わります。モバイル回線では帯域が変動しやすいため、回線状況に応じて画質やビットレートを調整する仕組み（適応制御）が品質維持の鍵になります。MDNは、SDPで特段の指定がない限り、受信側は最低でも320×240・20FPSの映像を扱える必要があるとしています*6。これは下限の目安であり、実際の品質目標は用途に応じて設計します。要件定義では「どの回線・端末で、どの程度の品質を担保したいか」を具体化しておくと、後工程の検証基準が明確になります。

実装・運用の難所と内製/外注の判断

WebRTCの通話機能は、サンプルを動かすだけなら比較的短期間で形になりますが、実利用に耐える品質に仕上げる工程に難所が集中します。内製と外注の判断は、これらの難所に対応できる体制が社内にあるかどうかで整理できます。

実装・運用の主な難所

• NAT越えの実環境対応：社内網・公衆回線・海外拠点など、接続できない環境ごとのTURN設計と検証。
• シグナリングの設計：再接続・切断・同時接続数の扱いなど、例外処理の作り込み。
• 多人数時のスケーリング：SFU/MCUのサーバ増減と負荷分散、コスト管理。
• 品質の作り込み：弱い回線でのビットレート調整、エコー・ノイズ対策、端末ごとの挙動差の吸収。
• OS・端末差への追随：iOS/Androidのバージョン更新や権限仕様の変更への継続対応。

内製で対応しやすい条件

既存の開発チームにモバイルアプリ開発の経験があり、サーバ運用やネットワークの知見を持つメンバーがいる場合、1対1の通話やマネージドSDKを使った実装は内製で進められる場合があります。検証用のPoC（概念実証）から始め、想定する回線・端末での通話品質を実測しながら進める進め方が現実的です。

外注を検討したい条件

次のいずれかに該当する場合は、外注の検討余地があります。多人数通話のSFU/MCUを自前運用する体制がない場合・WebRTC固有のNAT越えや品質チューニングの経験がない場合・リリース期限が明確な場合・本番稼働後の通話品質監視やTURN運用まで一括で任せたい場合です。コア事業の開発リソースを通話機能に割けないケースでも、外注による並行開発が選択肢になります。

ビデオ通話実装を外注するときの進め方と委託先選定

外注を決めた後、どのように進めるかをフェーズごとに整理します。WebRTC固有の論点を発注側で押さえておくと、見積もりと品質の精度が上がります。

フェーズ1：要件定義とPoC

外注前に自社側で明確にしておきたい事項があります。通話形態（1対1か多人数か）・想定同時通話数・対象OS/端末・利用される回線環境（社内網・公衆回線・海外拠点）・画面共有や録画の要否・通話品質の目標・予算と期限です。これらが曖昧なまま発注すると、方式選定（自前/SDK、メッシュ/SFU/MCU）がぶれて手戻りが発生します。小規模なPoCで実回線・実端末の通話品質を計測してから本格開発に移る進め方が、リスクを抑えるうえで有効です。

フェーズ2：RFPと委託先評価

複数のベンダーへRFP（提案依頼書）を送り、提案内容を比較評価することをおすすめします。WebRTC通話実装では、次の観点が評価の中心になります。

• WebRTC実装経験：モバイルアプリでの通話実装実績、シグナリング/TURNの構築経験。
• 方式選定の根拠：自前構築かマネージドSDKか、SFU/MCUの選択理由が要件に即して具体的か。
• 品質保証の方法：弱い回線・多人数時の品質検証手順、計測基準が示されているか。
• 運用・保守体制：TURN運用・通話品質監視・OS更新への追随を担えるか。
• セキュリティ対応：通話の暗号化前提、録画データの保管・取り扱いの設計。

フェーズ3：契約形態の選択

契約は、請負契約と準委任契約が中心です。動作するシステムの納品を明確にしたい場合は請負契約が適し、品質チューニングを反復しながら進めたい場合は月次での作業委託が可能な準委任契約（SES型）が柔軟です。WebRTCはOS・端末・ブラウザの仕様更新の影響を受けるため、「仕様変更への追随」を契約範囲にどこまで含めるかを事前に明記しておくことが重要です。

フェーズ4：本番稼働後の運用保守

本番稼働後も、通話機能は継続的な保守が必要です。TURNサーバの運用・通話品質の監視・OSや端末のアップデートへの追随・マネージドSDK利用時の仕様変更対応が主な運用項目です。これらを内製チームが担えるか、委託先に任せるかを選定段階で確認しておくと、長期的なコスト管理につながります。

まとめ：WebRTC通話実装外注の判断軸

本稿では、モバイルアプリへのビデオ通話・音声通話の実装に絞って、WebRTCの構成要素・シグナリング/NAT越え・多人数構成・マネージドSDK選定・コーデック・外注の進め方を整理しました。要点を3つに集約します。

第一に、WebRTCはgetUserMedia・RTCPeerConnection・メディアストリームが中心であり、シグナリングとSTUN/TURNによるNAT越えは仕様外でアプリ側が用意する必要がある、という役割分担を理解することが設計の前提です。第二に、多人数通話ではメッシュ/SFU/MCUの方式選定と、自前構築かマネージドSDK（Agora・Twilio・Amazon Chime SDK等）かの選択が、品質とコストを大きく左右します。第三に、実装の難所は実環境でのNAT越えと品質の作り込みに集中するため、PoCで実回線・実端末の品質を計測してから本格開発に進む進め方が有効です。

外注先の選定では、WebRTC固有の実装経験・方式選定の根拠・品質保証と運用保守の体制を評価観点の中心に置くと、委託後のトラブルを減らせます。

よくある質問

WebRTCのビデオ通話実装の開発期間の目安はどのくらいですか。

1対1の通話やマネージドSDKを使った実装であれば、PoC（概念実証）フェーズで数週間、本番対応（NAT越えの実環境検証・例外処理・品質チューニング・監視設計を含む）まで含めると数ヶ月程度が実務上の目安とされています。多人数通話のSFU/MCUを自前構築する場合や、既存システムとの複雑な統合が伴う場合は期間が延びます。要件の確定度と対象端末・回線の範囲によって大きく変わるため、まず小規模なPoCで実態を計測することをおすすめします。

シグナリングサーバやTURNサーバは自前で用意する必要がありますか。

WebRTCの仕様にはシグナリングの仕組みが含まれていないため、WebSocketなどを使って自前で用意するか、マネージドSDKに任せる形になります。TURNサーバも、直接接続できない環境での中継に必要となるため、自前運用かマネージドSDK利用かを選ぶ必要があります。社内網や海外拠点など接続が難しい環境を想定する場合は、TURNの規模見積もりを早めに行うことが重要です。

自前実装とマネージドSDK（Agora・Twilio・Amazon Chime SDK等）はどちらを選ぶべきですか。

立ち上げの早さと運用負荷の軽さを重視する場合はマネージドSDK、自由度や従量課金の回避を重視する場合は自前実装が候補になります。マネージドSDKは利用量に応じた従量課金が継続的に発生し、機能やデータの取り扱いは事業者の仕様に依存します。各サービスの機能・料金・ポリシーは変更されるため、想定する同時通話数・通話時間で試算したうえで、公式の最新情報を確認して比較することをおすすめします。

WebRTCの通話実装の外注費用はどのくらいかかりますか。

開発費用は、通話形態（1対1か多人数か）・対象端末数・自前構築かマネージドSDKか・品質要件・運用保守の範囲によって大きく異なります。市場参考値（一次資料ではありません）として、PoC規模の小規模実装で数十万円から、多人数通話やSFU/MCUの自前構築を含む中〜大規模開発では数百万円以上になるケースがあります。ベンダー選定時は複数社から見積もりを取り、機能スコープ・品質基準・保守範囲が同条件かを確認したうえで比較することが重要です。

テキストチャット機能も同じ実装で対応できますか。

本記事はビデオ通話・音声通話に絞って解説しています。テキストチャットやプレゼンス通知などのリアルタイム通信は、WebSocketを中心とした別の設計論点が中心となるため、別稿で扱っています。WebRTCにはデータ送信用のRTCDataChannelもありますが、チャット機能の一般的な実装は通話とは別に検討するのが実務的です。両機能を同時に提供する場合は、要件定義の段階でそれぞれの設計を分けて整理することをおすすめします。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：WebRTC「Getting started with WebRTC（Overview）」（getUserMedia/RTCPeerConnection等の説明、確認日2026年6月）
2. *2　出典：MDN Web Docs「WebRTC API」（RTCPeerConnection/MediaStream/ICE/STUN/TURN/暗号化の説明、確認日2026年6月）
3. *3　出典：MDN Web Docs「Signaling and video calling」（WebSocketによるシグナリングの説明、確認日2026年6月）
4. *4　出典：Amazon Web Services「What is the Amazon Chime SDK?」（音声/映像/画面共有/メッセージング・従量課金の説明、確認日2026年6月）
5. *5　出典：Twilio「Twilio Video Docs」（Web/iOS/Android向け音声・映像通話機能の説明、確認日2026年6月）
6. *6　出典：MDN Web Docs「Codecs used by WebRTC」（VP8/H.264/Opus/G.711等の必須・任意コーデックの説明、確認日2026年6月）