Skip to content
Published on

WebRTC & リアルタイム通信 2026 完全ガイド — LiveKit · Daily · Agora · Twilio · Pion · Mediasoup · Jitsi · Janus · AWS IVS · Cloudflare Calls 徹底分析

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — Programmable Video の死と新しい秩序

2024 年 12 月 5 日、Twilio が Programmable Video を正式に終了した。かつて WebRTC PaaS の代名詞だった製品が新規登録を止めたのが 2024-03、そして正確に 9 か月後、既存ワークロードもすべて切り捨てられた。移行を先延ばしにしていた数千のアプリが、四半期のあいだに LiveKit · Daily · Agora · Vonage · Dolby.io · Zoom Video SDK のあいだで新しい巣を探し回った。

その空白に誰が入ったかが、すなわち 2026 年のリアルタイム通信の地図である。

  • LiveKit が OpenAI Realtime API の公式 transport に採用されたことで、AI 音声エージェントの事実上の標準となった。オープンソース SFU と LiveKit Cloud、Agents SDK がひとつの束として動く。
  • Daily.co は Daily Bots とともに LLM · STT · TTS · SFU をひとつのパイプラインに束ね、Pipecat が間のグルーコードを標準化している。
  • Cloudflare Calls が 0.05 USD/GB（送出量基準）という攻撃的な価格で参入し、SFU 市場に価格圧力をかけた。
  • AWS IVS Real-Time（2023-08 GA）は Twitch のインフラをそのまま借り、100ms 未満のグローバル多人数ホストライブ配信を実現した。
  • そして標準側では WebRTC NV が — RTCRtpScriptTransform · Encoded Audio/Video Frame · AV1 · L1T3 SVC — 長年の実験をワーキングドラフトへ引き上げた。

本稿はその地図を端から端まで描く。RTCPeerConnection の 1 行コードから、9 プラットフォームの比較マトリクス、AI 音声エージェントとの統合、そして韓国・日本市場の事情まで。

1 章 · WebRTC が実際にしていること — 3 本の脚

WebRTC は魔法ではない。3 本の脚で立つ標準である。

[Browser A]                                     [Browser B]
   |                                                 |
   |  (1) Signaling — どう出会うかを決める               |
   |     （WebRTC の規定外 — WebSocket・SIP・任意）        |
   +---->  Signaling Server（アプリ側で運用） <--------+
   |                                                 |
   |  (2) ICE — どこへ接続するかの候補を集める            |
   +---->  STUN（自身のパブリック IP・ポートを知る）       |
   |     TURN（NAT 越え失敗時にリレー）                    |
   |                                                 |
   |  (3) Media — 実際に映像・音声・データを流す           |
   +-----------------DTLS-SRTP で暗号化-------------- +
                （P2P または SFU/MCU 経由）

3 本の脚の役割を覚えておくと道具選びが楽になる。

  • (1) Signaling は WebRTC 標準の範囲外。 どのチャンネルでも — WebSocket、Server-Sent Events、MQTT、SIP — 両側に同じ SDP（Session Description Protocol）と ICE candidate を渡せれば足りる。LiveKit・Daily・Agora はこの部分を自前で書いて SDK の中に隠す。
  • (2) ICE は標準の核心。 STUN で自身のパブリック IP・ポートを知り、それで足りなければ TURN で実メディアをリレーする。オープンソースの coturn が事実上の標準。
  • (3) Media は常に DTLS-SRTP で暗号化される。 平文メディアは標準に存在しない。上に乗るコーデックは Opus（音声は必須）、VP8/VP9/H.264/AV1（映像。AV1 と H.265 は 2024 年から本格的に登場）。

3 本の脚のうち 1 本でも欠ければ通信は成立しない。PaaS が売っているのは、この 3 本を「動く束」にまとめる労力そのものだ。

2 章 · RTCPeerConnection — コア API をひとページで

ブラウザが露出する表面は意外に小さい。中心は 3 つのオブジェクトだ。

  • RTCPeerConnection — ピアの一方を表すオブジェクト。SDP offer/answer、ICE candidate、トラックの送受信すべてがここで起きる。
  • MediaStream と MediaStreamTrack — カメラ・マイク・画面共有の抽象。
  • RTCDataChannel — メディアでない任意データを同じ PeerConnection 上に流す。

最小の双方向例（シグナリングは擬似コード）。

// 両側共通のセットアップ
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    { urls: 'turn:turn.example.com:3478', username: 'u', credential: 'p' },
  ],
})

pc.onicecandidate = (e) => e.candidate && signaling.send('ice', e.candidate)
pc.ontrack = (e) => (remoteVideo.srcObject = e.streams[0])

const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true })
stream.getTracks().forEach((t) => pc.addTrack(t, stream))

// caller
const offer = await pc.createOffer()
await pc.setLocalDescription(offer)
signaling.send('sdp', offer)

// callee
signaling.on('sdp', async (sdp) => {
  await pc.setRemoteDescription(sdp)
  const answer = await pc.createAnswer()
  await pc.setLocalDescription(answer)
  signaling.send('sdp', answer)
})

40 行ほどで 1:1 通話が立ち上がる。問題はここからだ。3 人、30 人、300 人へと増えた瞬間に P2P 網を維持するコストが爆発する。だから次章が必要になる。

3 章 · トポロジー — Mesh と MCU と SFU の違い

3 種類のトポロジーがあり、2026 年現場ではほぼすべてのグループ通話が SFU を採用する。

Mesh（N:N の完全グラフ）
   A <----> B
   ^  \  / ^
   |   \/  |
   |   /\  |
   v  /  \ v
   D <----> C
   上下リンク: peer ごと O(N)、合計 O(N^2)
   長所: サーバコスト ゼロ、E2EE が自然
   短所: 4〜5 人を超えるとクライアントの CPU・帯域が爆発

MCU（Multipoint Conferencing Unit — サーバがデコード・ミックス・再エンコード）
   A -+
   B -+- [MCU: decode -> composite -> re-encode] -> 1 本の映像 -> 全員
   C -+
   D -+
   長所: クライアントの帯域は 1 ストリーム、旧端末互換
   短所: サーバ CPU が非常に高い、E2EE 不可

SFU（Selective Forwarding Unit — サーバはルーティングのみ）
   A -> [SFU] -> B, C, D
   B -> [SFU] -> A, C, D
   ...
   長所: サーバ CPU が軽く拡張容易、simulcast/SVC で受信者別の画質
   短所: クライアント下りは O(N)、E2EE は Insertable Streams で別途

2026 年に新規構築されるグループ通話で MCU が出てくることはほぼない。SFU が標準で、100 人を超える観衆モードは SFU + HLS/LL-HLS · WHEP のファンアウトが一般的だ。LiveKit · Mediasoup · Janus · Jitsi Videobridge · Agora · Daily · Cloudflare Calls いずれも SFU。

4 章 · WebRTC NV — 標準はどこまで来たか

WebRTC 1.0 は 2021-01 に W3C 勧告となり、以降の新機能はすべて「WebRTC NV（Next Version）」の名で W3C WebRTC ワーキンググループと IETF RTCWEB で進められてきた。2026 年時点で実務に効く項目を挙げる。

  • Insertable Streams / RTCRtpScriptTransform — エンコード済みフレームに JavaScript からアクセスでき、E2EE・ウォーターマーキング・適応トランスコードが書ける。Chromium ではすでに安定。Safari · Firefox 26 以降で普及。
  • Encoded Audio/Video Frame — 上記 transform が扱う単位。RTCEncodedAudioFrame、RTCEncodedVideoFrame。メタデータ付き。
  • AV1 — コーデック。同等画質で VP9 比約 30% のビットレート削減。Chrome 90+、Safari 17+、Firefox 116+ でデコード。エンコードは端末依存。ハードウェアエンコーダ不足のため依然フォールバックが要る。
  • L1T3 SVC（Scalable Video Coding） — 1 回のエンコードで時間軸 3 レイヤを作り、SFU が受信者ごとに選んで送る。simulcast（空間軸）と補完関係。
  • Selectable Audio Output（setSinkId） — 出力デバイスの選択。Chrome · Edge · Safari · Firefox いずれも安定。
  • WebRTC-HTTP Ingest/Egress（WHIP/WHEP） — IETF RFC。SDP を 1 回 POST するだけでエンコーダがメディアを push（WHIP）、視聴者が pull（WHEP）。OBS Studio 30+、FFmpeg 7、Cloudflare Stream Live、AWS IVS、LiveKit いずれも対応。
  • WebCodecs / WebTransport — WebRTC に隣接する標準。エンコード／デコードとトランスポートを分離し、ゲームやクラウドゲーミングで低遅延を作る。

2024 年まで「実験」だったものが、2026 年には一斉に普及標準へと進んだことが重要だ。

5 章 · コーデック — Opus は神、映像は政治

音声には事実上選択肢がない。WebRTC 標準必須コーデックは Opus。8kHz 音声から 48kHz 音楽まで、可変ビットレート、低遅延。音声 AI エージェントでも Opus がそのまま使われる。

映像は政治である。

  • VP8 — 最も普遍的で互換性が高い。ライセンスなし。ハードウェアアクセラレーションが弱い。
  • VP9 — VP8 比 約 50% 削減。Chrome/Edge/Firefox/Safari 14+ でデコード。
  • H.264（Baseline / Constrained Baseline） — モバイルでのハードウェアアクセラレーションがほぼ普遍。特許料はあるが PaaS が処理する。
  • H.265 / HEVC — ライセンス紛争が長く、WebRTC では事実上ニッチ。Apple エコシステム中心。
  • AV1 — 未来。30% 効率的。エンコードコストが高く、simulcast/SVC と段階導入。
  • Lyra — Google のニューラル音声コーデック。3kbps でも明瞭。WebRTC 標準には未到達だが SDK 内では利用可能。

2026 年の既定推奨は、音声は Opus 単一、映像は simulcast で VP9 + H.264、AV1 はオプション。画面共有は VP9 か AV1 がテキスト描画に強い。

6 章 · ICE · STUN · TURN — もっともよく壊れるところ

WebRTC 運用でもっとも頻繁に壊れるのが ICE 候補収集だ。社内ネットワーク・企業ファイアウォール・キャリアグレード NAT・IPv6 半適用環境では、STUN だけで足りないケースがよく出る。

  • STUN — パブリック IP とポートだけを教える。非常に軽い。Google の stun:stun.l.google.com:19302 が事実上の公共インフラ。
  • TURN — メディア自体をリレーする。実トラフィックを流すサーバなので帯域コストが大きい。世界の通話トラフィックの 10〜25% が TURN を経由する。
  • TURN-TLS（443） — 企業ファイアウォールが UDP を塞ぐ場合に TCP/443 で迂回。遅延は増えるが接続成功率を上げる。
  • Trickle ICE — 集まった候補を即送信。最初のパケット到達時間を短縮。標準化済みだが実装の質はまちまち。

オープンソース標準は coturn。PaaS は自前のグローバル TURN を運用し、一定 GB まで無料に含めるか、または別途課金する。Cloudflare TURN（2023 開始）が価格破壊役となり、他 PaaS の TURN 単価も下がった。

7 章 · 9 プラットフォームのひと言要約

2026 年の実務候補をひと言ずつ。

  • LiveKit — オープンソース SFU + LiveKit Cloud + Agents SDK。OpenAI Realtime API の公式 transport。Apache 2.0。
  • Daily.co — マネージド SFU + Daily Bots + Pipecat のグルー。AI 音声統合の体験がもっとも滑らか。
  • Agora — グローバルと中国を同時にカバーできる点が強み。4.x SDK、世界平均 100ms 未満。
  • Twilio Video — 2024-12-05 終了。代替推奨：Zoom Video SDK、LiveKit、Daily、Vonage。
  • Pion — Go で書かれたオープンソース WebRTC スタック。ライブラリ。インフラを自前で書くとき。
  • Mediasoup 3 — Node.js + C++ SFU ライブラリ。非常に強いルータ。自前で書くチーム向け。
  • Jitsi Meet / JVB / Jicofo — オープンソース会議スタック。セルフホストの標準。8x8 が運営。
  • Janus Gateway — Meetecho のモジュラーゲートウェイ。プラグインで会議・配信・録画・SIP ゲート。
  • AWS IVS Real-Time — Twitch インフラ基盤。マネージド。ライブ配信と多人数ホスト。
  • Cloudflare Calls（Realtime SFU） — 0.05 USD/GB 送出。グローバルエッジに SFU。

次章から各プラットフォームを詳しく見る。

8 章 · LiveKit — OpenAI Realtime API の標準 transport

LiveKit は 2021 年に始まったオープンソースプロジェクトで、2024 年に OpenAI Realtime API が最初の公式 SDK として LiveKit Agents を選んだことで事実上の標準を固めた。

3 つのレイヤがひとつの束として動く。

  • LiveKit Server — Go で書かれた SFU。Apache 2.0。単一ノードで数万同時セッション、クラスタで数十万。ION/Mediasoup と並ぶオープンソース SFU 三羽烏。
  • LiveKit Cloud — 上記サーバをグローバルエッジでマネージドに動かす。ワークスペース単位課金。Free 50GB/月、Build プラン 100 USD/月から。
  • LiveKit Agents — 音声エージェントフレームワーク。STT · LLM · TTS をひとつのパイプラインに束ね、LiveKit Room へボットとして参加させる。OpenAI Realtime · GPT-4o Realtime · Anthropic Claude · Google Gemini · Cartesia · ElevenLabs · Deepgram · Whisper のいずれにもアダプタ。

コア API は Room 中心。

import { Room, RoomEvent } from 'livekit-client'

const room = new Room({ adaptiveStream: true, dynacast: true })
room
  .on(RoomEvent.TrackSubscribed, (track, pub, participant) => {
    if (track.kind === 'video') document.body.appendChild(track.attach())
  })
  .on(RoomEvent.ParticipantConnected, (p) => console.log('joined', p.identity))

await room.connect('wss://your.livekit.cloud', token)
await room.localParticipant.enableCameraAndMicrophone()

adaptiveStream が受信側の描画サイズに応じて SFU に別の simulcast レイヤを要求し、dynacast が誰も見ていないトラックの送出を自動停止する。両機能ともクラウド帯域コストに直接効く。

9 章 · Daily.co · Daily Bots · Pipecat — AI 音声にいちばん滑らかなスタック

Daily は 2016 年からマネージド WebRTC を売ってきた会社で、2024 年に Daily Bots とオープンソースの Pipecat フレームワークを束ねて「AI 通話を最も簡単に作れる場所」のポジションを固めた。

  • Daily SDK — JS、iOS、Android、React Native。daily-js で埋め込み型の通話 UI を 1 行で立ち上げられる。
  • Daily Bots — マネージドのサーバサイドボット。LLM · STT · TTS を束ねて通話に参加させる。
  • Pipecat — オープンソース。STT · LLM · TTS をノードグラフで接続するパイプライン。Daily が作ったが transport 独立で、LiveKit · Twilio Programmable Voice · PSTN 上でも動く。

代表的な 1 行呼び出し。

import DailyIframe from '@daily-co/daily-js'
const call = DailyIframe.createFrame({ url: 'https://yourdomain.daily.co/room' })
call.join()

createFrame が iframe を作り、Daily の UI をまるごと埋め込む。UI カスタマイズが必要なら createCallObject モードに落として全トラックを直接制御する。

価格は分単位課金で、Free 10,000 分/月、Scale プラン 600 USD/月 + 使用量。他 PaaS と違い帯域ではなく参加者・分基準なので、予測しやすい。

10 章 · Agora — グローバルと中国を同時にカバーできる事実上唯一の選択肢

Agora は 2014 年に上海／シリコンバレーで始まった会社で、SoftBank 傘下の SD-RTN（Software-Defined Real-Time Network）という自社グローバル網を運用している。4.x SDK で世界平均 first-frame-time 76ms、5G 環境のグローバル e2e 平均 100ms 未満を謳う。

中国国内ワークロードを抱えるあらゆるグローバルサービスは、この時点で Agora を本気で検討することになる。他 PaaS は本土での安定運用が難しく、政府規制（ICP など）への対応経験も Agora がいちばん長い。

API は Channel モデル。

import AgoraRTC from 'agora-rtc-sdk-ng'

const client = AgoraRTC.createClient({ mode: 'rtc', codec: 'vp9' })
await client.join(appId, channel, token, uid)

const [mic, cam] = await Promise.all([
  AgoraRTC.createMicrophoneAudioTrack(),
  AgoraRTC.createCameraVideoTrack({ encoderConfig: '1080p_1' }),
])
await client.publish([mic, cam])

価格は分単位＋画質別。1080p 映像が約 0.0099 USD/分、HD は 0.00399。グローバル・中国ルーティング費用は別途。他 PaaS より価格マトリクスは複雑だがボリュームディスカウントは厚め。

11 章 · Twilio Video の終了と移行先

2024-03-04、Twilio は Programmable Video の新規登録を停止した。2024-12-05、EOL。5 年間 WebRTC PaaS の事実上の標準だった製品が — Twilio Voice/Messaging は生き残ったが — 映像は死んだ。

公式移行ガイドが指したのは Zoom Video SDK だった。Zoom が移行パッケージとコード変換ツールを用意した。実際の市場はもっと分散した。

  • Zoom Video SDK — Twilio に最も近い SDK 形。分単位課金。移行ツールが最も整っている。
  • LiveKit Cloud — オープンソース親和のチーム。Twilio Programmable Video から LiveKit Room へほぼ 1:1 で対応する公式ガイド。
  • Daily.co — AI 音声へ素早く広げたいチーム。
  • Vonage Video API（旧 OpenTok） — 最も古い PaaS。SDK の抽象度が Twilio に近い。
  • Dolby.io Communications — 空間音響・高音質を必要とするチーム。

2025 年は移行の年であり、2026 年には上記 5 か所へトラフィックが分散して入ったことが市場データに表れた。

12 章 · Pion — Go で書かれた WebRTC スタック

Pion は Sean DuBois が 2018 年に始めた Go 製の WebRTC ライブラリだ。マネージドサービスではなく「Go から WebRTC を直接書けるようにする道具」。WebRTC を自前で実装すると決めたチームが最初に見る場所。

特徴。

  • モジュラ — DTLS · SRTP · ICE · SCTP · RTP · RTCP が別パッケージ。必要分だけ取り込む。
  • Go の並行モデル — 数万の PeerConnection を 1 ノードで扱いやすい。
  • 本番採用 — Twitch Cloud Game、Hopin、WeWork、LiveKit の一部コンポーネント。

代替として Rust 陣営には WebRTC-rs（2023 年開始、Pion API に近い形でポートしたもの）、C++ 陣営には Google の libwebrtc 本家がある。マネージド SFU を一から作る決定では、Pion・WebRTC-rs・libwebrtc のいずれかを選ぶのが自然。

13 章 · Mediasoup 3 — Router / Worker モデルの精髄

Mediasoup は José Luis Millán（元 SIP.js）が始めた Node.js + C++ の SFU ライブラリ。マネージドではなくライブラリ。自前で SFU を作るチームがいちばん選ぶ。

  • C++ Worker プロセス — 1 プロセスが 1 CPU コアを占有。メディアルーティングのホットパス。
  • Node.js Router オブジェクト — Worker の上の JS 抽象。ルーム・ピア・トランスポートを管理。
  • Pipe Transport — Router 間のメディア配送。マルチノード拡張の標準パターン。
  • DataProducer / DataConsumer — SCTP-on-DataChannel を SFU がルーティング。

代表ユーザに Atlassian、Versatica、Whereby、LiveKit の一部などがある。マネージドを作るリソースのないチームが Mediasoup の上で自前 SFU を作り、その上に業務用ルームを乗せるパターン。

14 章 · Jitsi Meet — セルフホストの標準

Jitsi は BlueJimp が始め、2015 年に Atlassian が買収、2018 年に 8x8 へ移ったオープンソースの会議スタック。セルフホストで会議を立てるとき最も選ばれる束。

  • Jitsi Videobridge（JVB） — Java で書かれた SFU。単一ノードで数百名、カスケードで数千名。
  • Jicofo（Jitsi Conference Focus） — XMPP ベースのシグナリングと会議フォーカス。
  • Prosody — XMPP サーバ。
  • Jitsi Meet — React フロントエンド。meet.jit.si がリファレンスインスタンス。
  • Jibri — 録画・ライブ配信ボット。Chromium を立ち上げ画面を取り込む。

セルフホストの定石は docker-jitsi-meet 一式。1 つの VM に 1 コマンドで上がる。セキュリティ要件が高い政府・医療・教育で最もよく見る。

15 章 · Janus Gateway — モジュラーゲートウェイの精髄

Janus はイタリアの Meetecho が作った C ベースの WebRTC ゲートウェイ。SFU・MCU・SIP gateway・録画・配信・NoSIP をプラグインで差し替える構造。Jitsi が会議特化なら、Janus は「WebRTC を何かに接続するための汎用ゲートウェイ」に近い。

主要プラグイン。

  • videoroom — SFU モードのグループ通話。
  • streaming — RTSP/RTP を受けて WebRTC として配る。カメラ・OBS のライブ分配。
  • sip — SIP gateway。PSTN を WebRTC に引き込む。
  • recordplay — 録画と再生。
  • textroom — DataChannel ベースのチャットルーム。

Discord の音声チャンネル時代（2017〜2020）、Slack Huddle の初期、Microsoft Teams の一部分岐などが Janus またはそのフォークを使ったと公開されている。自由度が最も高く、運用難度も高い。

16 章 · AWS IVS Real-Time と Cloudflare Calls

マネージド SFU の最新の 2 軸はクラウド事業者から出てきた。

AWS IVS（Interactive Video Service） は Twitch のインフラを AWS 製品として借り直したもの。2020 年にライブ配信専用モードで出発し、2023-08 に IVS Real-Time が GA して多人数ホスト（stage）機能が加わった。

  • Stage — 最大 12 名のホストが双方向リアルタイム。観衆へライブ配信。
  • Channel — 一方向ライブ配信。LL-HLS で 5 秒未満。
  • Composition — サーバサイド合成で 1 本の映像にして下流配信。
  • WHIP 対応 — OBS・FFmpeg・自前エンコーダから直接 push。

価格は Stage が 0.0149 USD/分/参加者、Channel は視聴時間 + エンコード時間で分割。

Cloudflare Calls（Realtime SFU） は 2023-11 にベータ、2024-09 に GA。1 行の価格表が衝撃だった。

  • 0.05 USD/GB 送出 — 他 PaaS の 1/5〜1/10。
  • グローバルエッジ — Cloudflare の 300 以上の PoP をそのまま SFU に。
  • TURN over 443 が無料で含まれる。Cloudflare TURN は単独販売もしている。

この価格圧力が他 PaaS の値札を引き下げた。Cloudflare は Calls の上で WebRTC WHIP/WHEP ゲートウェイも合わせて運営している。

17 章 · OpenAI Realtime API · Claude voice · Cartesia · ElevenLabs — AI 音声の transport

2024 年 10 月、OpenAI が Realtime API を公開した。中心的な変化は「GPT-4o が初めてテキストではなく音声として直接聞き、直接話す」ことだった。これ以前の音声エージェントは STT → LLM → TTS の 3 モデル直列だったが、Realtime は 3 段を GPT-4o の中にひとつにまとめた。

ここで決定的だったのが LiveKit。OpenAI が公式 SDK を LiveKit Agents で組んだ結果、LiveKit が事実上の標準 transport になった。WebSocket 直結も可能だが、本番運用ではほぼ全員 LiveKit Agents を経由して SFU に乗せる。

同時期に出てきた競合。

  • Anthropic Claude voice — Claude 3.5/3.7 上の音声エージェント。Pipecat · LiveKit Agents いずれにもアダプタ。
  • Google Gemini Live API — 2024 I/O で公開。マルチモーダル双方向ストリーム。
  • Cartesia Sonic — TTS。90ms の first-token 遅延。音声エージェントの応答遅延を削るときにいちばんよく動員される。
  • ElevenLabs Conversational AI — STT · LLM · TTS · turn-taking をまとめたマネージド。自前 transport または Twilio · LiveKit 接続。
  • Deepgram Aura — TTS。200ms 遅延。
  • Whisper / Whisper-Large-v3 — STT。オープンソースの基盤。

WebRTC の P95 e2e 遅延が 200ms 内に収まる条件で、AI 音声のユーザ体感遅延（話し終わり→次の発話開始）を 500ms 内に収めるのが 2026 年の標準目標になった。それを可能にしたのが WebRTC 標準 + 現代 AI モデルの組み合わせである。

18 章 · WHIP · WHEP — ライブ配信が WebRTC へ移ってくる

長らくライブ配信は RTMP push と HLS pull の組だった。エンコーダ（OBS）が RTMP でメディアサーバに push し、視聴者は HLS で pull。遅延は通常 6〜30 秒。

2022 年に IETF が WHIP（WebRTC-HTTP Ingest Protocol）と WHEP（WebRTC-HTTP Egress Protocol）の標準化を始め、その組を置き換え始めた。鍵はシンプルさにある。

  • WHIP — エンコーダが SDP を HTTP POST。サーバが SDP answer を返す。あとは普通の WebRTC。
  • WHEP — 視聴者が SDP を HTTP POST。あとは WebRTC。

この 1 回の POST のおかげで、ingest と egress が同じ WebRTC 上に統合された。遅延も 1〜3 秒水準に落ちる。

2026 年の対応状況。

  • OBS Studio 30+ — WHIP 出力を既定対応。
  • FFmpeg 7+ — WHIP muxer。
  • Cloudflare Stream Live · AWS IVS · Mux · Daily · LiveKit · Wowza · Ant Media — WHIP/WHEP いずれも対応。
  • ブラウザは WHEP を専用 SDK なしに RTCPeerConnection + fetch だけで実装できる。

RTMP は死んでいないが、2030 年頃には新規システムのほぼすべてが WHIP/WHEP へ移るというのが標準陣営のコンセンサス。

19 章 · 韓国と日本のリアルタイム通信市場

韓国・日本はグローバル PaaS に加えてローカル事業者が強い市場だ。

韓国 — NHN TalkN、NCP Real-Time Comms、KakaoTalk 音声

  • NHN TalkN — NHN Cloud が運用するマネージド WebRTC。ゲーム・教育分野で採用が多い。国内データ・レジデンシ要件に強い。
  • Naver Cloud Platform Real-Time Comms — Naver Cloud のマネージド SFU。国内 KISA · VoIP 認証に強い。
  • KakaoTalk 音声・映像通話 — 自社スタック。公開 SDK はないが、Kakao i BizCall や KakaoWork で部分 API を露出。
  • Zoom · Google Meet · Microsoft Teams — 韓国企業の協業標準。いずれも WebRTC 上に動く。

日本 — Skyway（NTT コミュニケーションズ）、Yahoo!Japan、NTT-X

  • Skyway — NTT コミュニケーションズが運用。2014 年から続く最古参の国内 PaaS。2023 年に v2 がリリースされ SDK が刷新された。国内データセンタと日本語ドキュメントが強み。
  • NTT コミュニケーションズ Smart Workspace — Skyway の上に乗る協業 SaaS。
  • LINE 音声・映像通話 — 自社スタック。LINE WORKS に統合。
  • Yahoo!Japan — 自社会議システム。

日本は Skyway が固く、グローバル PaaS のシェアは韓国より低めだ。韓国はグローバル PaaS（とくに Zoom · Google Meet · Agora · LiveKit）の浸透が速い。

20 章 · 意思決定マトリクス — どこで何を使うか

2026 年 5 月時点のシナリオ別推奨。

  • 1:1 ビデオ通話 — デザイン自由度が最重要の SaaS → LiveKit Cloud か Daily.co。UI を 100% 自前にしやすい。
  • グループ会議 — Zoom 級の機能を最初から → Zoom Video SDK がいちばん早い ramp-up。デザイン自由度は低め。
  • グローバルと中国を同時に必要とする → Agora 以外に事実上の選択肢はない。
  • セルフホスト・政府・医療・教育 → Jitsi Meet または Janus Gateway。データが外へ出ない。
  • ライブ配信 + 多人数ホスト → AWS IVS Real-Time。Twitch 親和ワークフロー。
  • 価格が最重要の大規模観衆 → Cloudflare Calls + WHEP。0.05 USD/GB。
  • AI 音声エージェント → LiveKit Agents + OpenAI Realtime か Claude voice + Cartesia/ElevenLabs。事実上の標準。
  • SFU を自前で建てる → Mediasoup 3（Node.js）または Pion（Go）または ION。
  • 国内データ・レジデンシ — 韓国 → NHN TalkN または NCP Real-Time Comms。
  • 国内データ・レジデンシ — 日本 → Skyway v2。

このマトリクスは万能ではない。価格、チームの言語スタック、運用人員、データガバナンス、政府認証がすべて変数だ。それでも候補を絞る初手としては十分使える。

21 章 · 運用の落とし穴 — 実際に壊れるところ

マネージドでもセルフホストでも、運用で壊れる場所は似通っている。

  • 初回接続失敗 — TURN 設定。企業網で UDP が塞がれていて TURN-TLS（443）が必要な場合が多い。
  • 品質低下 — 適応 simulcast が無効。送信側の上り帯域が狭いとき自動ダウンレイヤが動かないと全員が崩れる。
  • 録画欠落 — サーバサイド録画 SDK の権限不足、またはコンテナのディスクフル。
  • オーディオエコー — echoCancellation: true が一部端末で実際は効いていない。AEC3 強制適用が必要。
  • モバイルのバックグラウンド切断 — iOS Safari のバックグラウンド制限。PWA で特に。標準は徐々に緩和中。
  • CPU 暴走 — モバイルでの VP9/AV1 ソフトウェアエンコードが CPU を 100% 占有。H.264 simulcast へのフォールバック必須。
  • クロックずれ — NTP が狂って RTCP が崩れる。コンテナでよく起きる。
  • TURN コスト暴走 — TURN 使用率が 25% を超えたら原価モデルを見直す。

運用マニュアルの標準は — 「P95 遅延、接続失敗率、TURN 使用率、端末別エンコーダフォールバック比率」の 4 つのグラフを常時掲示すること。

22 章 · セキュリティ — DTLS-SRTP、E2EE、ワークフロー

WebRTC の既定セキュリティは強い。すべてのメディアが DTLS-SRTP で暗号化され、鍵が SDP に露出しない。標準そのものに「暗号化オフ」のオプションは存在しない。

問題は SFU。メディアをルーティングするには DTLS-SRTP を 1 度解く必要があり、つまり SFU 運用者は平文メディアを見られる位置にいる。真の E2EE が必要なら、Insertable Streams / RTCRtpScriptTransform で SFU の前にもう一度暗号化する。

  • Jitsi の E2EE — Insertable Streams ベース。1 つの鍵を全参加者が共有。
  • Google Meet の E2EE — 1:1・少人数限定。同じ仕組み。
  • Zoom の E2EE — オプション。録画・電話ゲートウェイなど一部機能が制限される。
  • LiveKit の E2EE — Insertable Streams + Web Crypto。クライアントライブラリに内蔵。

E2EE を有効にした瞬間に、サーバサイド録画・サーバサイド字幕・SFU トランスコードがすべて不能になる。このトレードオフは最初から設計に入れる。

その他に気を配るべきこと。

  • JWT トークンの有効期限 — Room 入室トークンの TTL は短く。
  • TURN 認証情報のローテーション — 固定認証情報は危険。ephemeral credential 標準を使う。
  • ウォーターマーク — 画面共有にユーザ ID ウォーターマーク。RTCRtpScriptTransform で可能。

23 章 · 未来 — WebTransport · QUIC · クラウドゲーミング隣接

WebRTC の隣で、似た問題を別の方法で解く標準が育っている。

  • WebTransport — QUIC 上の双方向・信頼性選択可能なトランスポート。WebSocket と WebRTC DataChannel の後継。Chrome · Edge · Firefox 対応、Safari 26+。
  • WebCodecs — コーデックをブラウザが露出。トランスポートと分離。ゲームで自前のルーティングを作るときに有利。
  • Media over QUIC（MoQ） — IETF ワーキンググループ。ライブメディアを QUIC 上で標準化。2027〜2028 年標準化目標。
  • HTTP/3 多重化 — シグナリングまで 1 接続に束ねる。
  • クラウドゲーミング — NVIDIA GeForce NOW · Xbox Cloud Gaming — WebRTC + WebCodecs + WebTransport の組み合わせ。

WebRTC が消えるわけではない。ただ「特定のワークロードでは WebRTC は重い」という認識が 5 年で固まり、その隣で WebTransport · MoQ が育っている。2030 年頃には、通話は依然 WebRTC、ライブ・ゲーム・メッセージは WebTransport · MoQ — そんな配置になる可能性が高い。

24 章 · 結び — ひと言の推奨

2026 年に新しくリアルタイム通信を始めるチームへ、ひと言で勧めるなら。

  • AI 音声エージェント — LiveKit Cloud + LiveKit Agents + OpenAI Realtime か Claude voice。
  • 人どうしのグループ会議 — Daily.co か LiveKit Cloud。UI 自由度と価格のバランスが最も良い。
  • グローバルと中国を同時 — Agora。
  • セルフホスト — Jitsi Meet または LiveKit Server。
  • ライブ配信 + 多人数ホスト — AWS IVS Real-Time。
  • 大規模観衆を低コストで — Cloudflare Calls。
  • 国内データ — 韓国 NHN TalkN、日本 Skyway。

標準は安定した。道具は十分多様だ。残るのは — 自分たちのワークロードに合う束を選び、P95 遅延と運用グラフを常に画面に出しておくこと。

References

Discuss on Twitter • View on GitHub