WebRTCとは：アーキテクチャと動作原理

WebRTCとは

WebRTC（Web Real-Time Communication）は、2011年にGoogleが開始したオープンソースプロジェクトであり、W3C（JavaScript API）とIETF（プロトコル）によって標準化されています。主な目的は、プラグインやサードパーティソフトウェアをインストールせずに、ブラウザとアプリケーション間の低レイテンシ通信を提供することです。

ビデオがサーバーを通過する従来のソリューション（RTMP、HLS）とは異なり、WebRTCはピアツーピアアーキテクチャを使用します。データは参加者間で直接送信されます。これにより、HLSの3〜10秒に対して200〜500 msのレイテンシを実現します。これは音声通話やビデオ通話、ゲームストリーミング、遠隔手術にとって重要な違いです。

Google WebRTC Team（2025）によると、この技術は合計50億以上のインストール数のアプリケーションで使用されています：Google Meet、WhatsApp、Discord、Telegram、Zoom（一部）。テレヘルスとEdTech分野のベンチャースタートアップの85%以上が、WebRTCをベースのリアルタイムトランスポートとして選択しています。

モバイル開発は2013年にlibjingle_peerconnectionのリリースにより完全なWebRTCサポートを取得しました。これはAndroidとiOS向けのネイティブ実装です。現在、両プラットフォームにはH.264とVP8のハードウェアエンコーディング、カメラ、マイク、デバイススピーカーをサポートする安定したSDKがあります。

WebRTCのアーキテクチャとプロトコル

WebRTCアーキテクチャは3つの層で構成されています。最上位層はJavaScript API（またはモバイルプラットフォーム向けのネイティブAPI）、中間層はトランスポートプロトコル、最下層はコーデックとセキュリティです。各層は独自のタスクを解決しますが、接続確立にはすべてが必要です。

主要なWebRTC API

MediaStream（getUserMedia） — デバイスのマイクとカメラからオーディオとビデオをキャプチャします。RTCPeerConnection — P2P接続を管理します：エンコーディング、トランスポート、ビットレート適応。RTCDataChannel — 同じチャネルで任意のデータ（テキスト、ファイル、バイナリメッセージ）を送信します。

// WebRTC JavaScript API（ブラウザの例）
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

リアルタイムプロトコル

WebRTCはオーディオとビデオにSRTP（Secure Real-Time Transport Protocol）を使用します。これはAES-128暗号化を備えたRTPのセキュアバージョンです。セッション管理はDTLS上でSCTP（Stream Control Transmission Protocol）を介して行われます。各データストリームは必須で暗号化されます。WebRTCに非セキュアモードはありません。

• SRTP/SRTCP — リプレイ攻撃保護付きのメディアストリームの暗号化伝送
• DTLS-SRTP — UDP上のDatagram TLSによる暗号化キー確立
• SCTP — DataChannelのための信頼性のある、または部分的に信頼性のあるデータ配信
• ICE（Interactive Connectivity Establishment） — ピア間のネットワークパスを見つけるためのフレームワーク
• Trickle ICE — 候補が見つかり次第送信されるICEのインクリメンタルバージョンで、接続確立を高速化

NATトラバーサル：ICE、STUN、TURN

WebRTCの主要な技術的課題は、NAT（Network Address Translation）の背後にあるデバイス間でP2P接続を確立することです。特別なメカニズムがなければ、デバイスのローカルIPアドレスがインターネットから見えないため、デバイスは互いに直接到達できません。

STUN — パブリックアドレスの特定

STUN（Session Traversal Utilities for NAT） — “私のパブリックIPとポートは何か？”という質問に答えるサーバーです。クライアントがSTUNサーバーにリクエストを送信すると、サーバーはそのパブリックアドレスを確認してクライアントに返します。GoogleはSTUNサーバーstun:stun.l.google.com:19302を公開保守しています。

// iOSでのWebRTC — ICEサーバー設定
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — リレー接続

TURN（Traversal Using Relays around NAT） — STUNが機能しない場合（対称NATや企業ファイアウォール）のリレーサーバーです。このモードではすべてのデータがTURNサーバーを通過します。これにより速度が低下しレイテンシが増加しますが、99%のケースで接続を保証します。

TURNはすべてのメディアトラフィックを自身を通過させるため、WebRTCインフラストラクチャで最も高価なコンポーネントです。Coturn Project（2025）によると、8 vCPUと16 GB RAMを搭載した標準的なTURNサーバーは、約200の同時音声通話または40のHDビデオ通話を処理します。

ICEプロセス

ICEはすべての可能な候補（ローカルIP、STUN経由のパブリックIP、TURN経由のリレー）を収集し、優先順位に従って接続を試みます。少なくとも1組の候補（ローカル-リモート）が接続性チェックに合格すると、接続が確立されたと見なされます。

• Host candidates — サブネット内のデバイスのローカルIPアドレス（最速だがNATの背後では機能しない）
• Server Reflexive candidates — STUNサーバー経由で取得したパブリックIP
• Relay candidates — リレーが行われるTURNサーバーアドレス（最も遅いが最も信頼性が高い）

モバイルアプリでのWebRTC

モバイル開発向けに、GoogleはlibWebRTCを保守しています。これはAndroid（AAR）とiOS（XCFramework）向けのネイティブライブラリです。このライブラリには完全なプロトコルスタック、コーデック（VP8、VP9、H.264、AV1）、およびエンコード/デコードのためのハードウェアアクセラレーションが含まれています。

AndroidでのWebRTC

Android SDKはPeerConnectionFactory、PeerConnection、MediaStreamクラスを提供します。アプリはファクトリを作成し、ビデオコーデックを設定し、VideoCapturerを介してカメラストリームをキャプチャし、SDP offer/answerを介してピア接続を確立します。

// Android WebRTC — 初期化
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

iOSでのWebRTC

iOS SDKはRTCPeerConnectionFactory、RTCCameraVideoCapturer、RTCVideoTrackラッパーを使用したObjective-C APIを使用します。ハードウェアH.264エンコーディングはVideoToolboxを介して利用可能です。ビデオ表示にはRTCMTLVideoView（Metal）またはRTCVideoRendererが使用されます。

// iOS WebRTC — カメラからのビデオキャプチャ
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// カメラ選択（フロント/バック）
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// 最大FPSでキャプチャを開始
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

プロダクションのビデオ通話では、モバイルアプリは通常libWebRTC上のSDKラッパーを使用します：Twilio Video、Agora、Daily.co。これらのSDKはシグナリング、ルーム管理を簡素化し、参加者のビデオグリッドを表示するための既製のUIコンポーネントを提供します。

シグナリングと接続確立

WebRTCはシグナリングプロトコルを指定しません — ピア間のSDP（Session Description Protocol）メッセージの交換です。開発者はシグナリングのトランスポートを選択します：WebSocket、MQTT、SIP、XMPP、またはREST API。シグナリングはoffer、answer、ICE候補を一方のピアから他方に届けます。

SDP Offer/Answer交換

プロセスはofferの作成から始まり（イニシエーターがメディア機能を記述）、シグナリングを介して2番目のピアに送信され、answerで応答します。SDP交換後、各ピアはICEを開始し、ストリーム暗号化のためにDTLS-SRTPを起動します。

// Android — offerの作成と送信
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // シグナリングサーバーにsdp.descriptionを送信
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

シグナリングプロトコル

モバイルアプリで最も一般的なシグナリングはWebSocketを介したものです。これはTCP上の双方向チャネルで、サーバーとの永続的な接続を維持します。シグナリングサーバーは多くの場合、ルームの参加者間でメッセージをルーティングする独立したマイクロサービス（Node.js、Golang、Elixir）です。

• WebSocket — 永続的な双方向接続、最小限のオーバーヘッド、シグナリングの標準的な選択肢
• WebSocket上のSIP — 標準VoIPプロトコル、既存の電話インフラと統合
• MQTT — IoTと弱いネットワーク向けの軽量pub/subプロトコルだが、レイテンシが高い
• Matrix / XMPP — プライバシー重視のアプリケーション向けの分散型プロトコル

ICEとDTLS-SRTPの完了後、シグナリングはデータ伝送に参加しなくなります — すべてのメディアトラフィックは直接P2P（またはTURNリレー経由）で流れます。シグナリングサーバーはアクティブな通話を中断せずにシャットダウンできます。これがWebRTCの分散型アーキテクチャの重要な利点です。