WebRTC メディアインフラ 2026 — LiveKit·Pion·Daily·100ms·mediasoup·Janus·Cloudflare Realtime と WHIP/WHEP 徹底解剖

プロローグ — WebRTC は 90% がインフラ選定だ

2018 年の WebRTC は「ブラウザで P2P ビデオ通話をどう書くか」の問題だった。STUN/TURN サーバ 1 台、RTCPeerConnection のコード 200 行、ビデオ 2 枠のデモページ。以上。

2026 年の WebRTC は別の問題になっている。

• 100 人ルームをどう回す? — 答えは SFU(Selective Forwarding Unit)。P2P メッシュは N² で 5 人で崩れる。
• AI ボイスエージェントをどう繋ぐ? — LLM の出力トークンを TTS に、マイク音声を STT に、すべて 200ms 以内に。WebRTC の強みの領域。
• ライブ配信はどうする? — RTMP は古いコーデック(H.264 のみ)で遅延 2〜5 秒。WHIP(WebRTC-HTTP Ingestion Protocol)/WHEP(WebRTC-HTTP Egress Protocol)が新標準に上がってきた。
• マネージド(Daily・100ms・Twilio・Chime)を使うか、セルフホスト(LiveKit OSS・mediasoup・Janus・Jitsi)を選ぶか?

本稿は「WebRTC のコード 200 行」ではなく「本番のメディアインフラをどこでどう動かすか」を扱う。この一回の判断が、半年後のインフラ費用・遅延・運用負荷を決める。

要約: 2026 年 5 月時点の大きな絵はこうだ。

• LiveKit が AI ボイスエージェントインフラの事実上の標準になった。LiveKit Agents フレームワークは OpenAI Realtime API・Deepgram・ElevenLabs と一等で統合される。
• Pion が Go 陣営の WebRTC エンジンとして定着。LiveKit 自身も Pion の上に乗っている。
• WHIP/WHEP が RTMP を置き換えるライブインジェスト標準として定着。OBS 30+ が WHIP 配信を標準サポート。
• マネージド陣営(Daily・100ms・Twilio Video・AWS Chime SDK)は生きているが価格圧力が強い。LiveKit Cloud がラウンド 1 の強敵。
• Cloudflare Realtime がエッジで WebRTC を投げ、新カテゴリを作った。Calls API + Realtime SFU。

では始める。

1 章 · WebRTC インフラの風景 — 2026 年の地図

まずは分類。全員が同じ場所にいるわけではない。

本稿の焦点は太く分かれた LiveKit・Pion・Daily・100ms・mediasoup・Janus・Jitsi・Twilio・Chime・Cloudflare Realtime だ。WHIP/WHEP は別章で扱う。

なぜ LiveKit が標準になったか

• AI ボイスエージェント時代のインフラ第一位。LiveKit Agents フレームワークが OpenAI Realtime・Deepgram STT・ElevenLabs TTS・Cartesia と一等統合。
• OSS とクラウド(LiveKit Cloud)の両方を同時に回す。セルフホストで始めてクラウドに乗り換えできる。
• Pion の上に書かれ、Go の単一バイナリ。Kubernetes・Docker デプロイが単純。
• LiveKit のクライアント SDK(JS・Swift・Kotlin・Flutter・Unity・React Native)が綺麗に整っている。

2 章 · 7 軸で見る比較マトリクス

詳細分析の前に、一目で見る大きな絵。

この表だけで決めてはいけない。次章から各ツールの「できる/できない」を正確に押さえる。

3 章 · LiveKit — 標準になった理由と LiveKit Agents

LiveKit は 2021 年の登場以来、最速で居場所を見つけた WebRTC インフラだ。OSS(Apache 2.0)と LiveKit Cloud の両線を同時に走らせる。2025〜2026 で決定的な出来事が二つ。

1. LiveKit Agents フレームワーク — Python/Node SDK で LLM・STT・TTS・VAD をまとめ、ボイスエージェントを作る。OpenAI Realtime API・Deepgram・AssemblyAI・ElevenLabs・Cartesia などが一等統合。
2. OpenAI が LiveKit を公式採用 — ChatGPT 音声モードのインフラが LiveKit 上で動いていることが公表された。事実上の業界スタンプ。

なぜ LiveKit は強いか

• 単一の Go バイナリ — livekit-server 一個。Pion ベース。Docker 一行で立ち上がる。
• クライアント SDK 群 — JS, Swift, Kotlin, Flutter, Unity, React Native, Python。すべて同じ抽象(Room, Participant, Track)。
• Egress と Ingress サービス — 録画(MP4・HLS)、ストリーム抽出(WHIP/WHEP インジェスト)、トランスコードがモジュール分離。
• @livekit/components-react — 会議 UI を 30 分で作る事前ビルトコンポーネント。
• LiveKit Cloud — セルフホスト運用が重ければ同じ API でクラウドに移行できる。SLA・グローバルルーティング込み。

LiveKit Agents の最小スケルトン

ボイスエージェント一個の最小形。このコードはマイク入力を OpenAI Realtime に流し、モデルの返答音声をルームに戻す。

# agent.py — LiveKit Agents の最小スケルトン
import asyncio
import os
from livekit import agents, rtc
from livekit.agents import AgentSession, Agent
from livekit.plugins import openai, deepgram, elevenlabs, silero

class VoiceAssistant(Agent):
    def __init__(self) -> None:
        super().__init__(
            instructions=(
                "You are a friendly voice assistant. "
                "Answer in short, conversational sentences."
            ),
        )

    async def on_enter(self) -> None:
        # 自動挨拶
        await self.session.say("こんにちは。何かお手伝いできますか?")

async def entrypoint(ctx: agents.JobContext) -> None:
    await ctx.connect()  # ルームに参加

    session = AgentSession(
        # 1) STT — Deepgram nova-3
        stt=deepgram.STT(model="nova-3"),
        # 2) LLM — OpenAI Realtime もしくは通常の chat completions
        llm=openai.LLM(model="gpt-4o-mini"),
        # 3) TTS — ElevenLabs
        tts=elevenlabs.TTS(voice_id="Rachel"),
        # 4) VAD — Silero 音声活動検出(ターン判定)
        vad=silero.VAD.load(),
    )

    await session.start(
        agent=VoiceAssistant(),
        room=ctx.room,
    )

if __name__ == "__main__":
    agents.cli.run_app(
        agents.WorkerOptions(entrypoint_fnc=entrypoint),
    )

デプロイはローカルで python agent.py dev、本番では python agent.py start。LiveKit サーバが新しいルームを作ると Agents ワーカーが自動マッチングして参加する。

OpenAI Realtime + WebRTC 直結モード

OpenAI Realtime API は 2024 年のローンチ時 WebSocket のみだった。2025 年に WebRTC 接続モードが追加された。クライアントが SDP を作って OpenAI のエンドポイントに直接投げると、モデルが SFU のように応答する。遅延は 200〜400ms。

LiveKit Agents は両方を抽象化する。

# OpenAI Realtime を WebRTC 直結で使う形
from livekit.plugins import openai

session = AgentSession(
    llm=openai.realtime.RealtimeModel(
        model="gpt-4o-realtime-preview",
        voice="alloy",
        # WebRTC モード — 別途 STT/TTS は不要
        modalities=["audio", "text"],
    ),
)

このモードでは STT/TTS が別途要らない。モデルがオーディオ入出力自体を扱う。短所は価格が高く、モデル選択が OpenAI Realtime 系統に固定されること。

LiveKit の弱点

• マネージド勢に比べてクライアント側の分析(品質計測・セッションリプレイ)が弱い。Daily がこの領域で先行する。
• セルフホストに行くと TURN・ロードバランサ・録画ストレージなどの周辺をすべて自前で回す。
• ルーティングトポロジ(ノードクラスタリング)は強力だが学習曲線がある。

4 章 · Pion — Go の WebRTC エンジン

Pion は Go で書かれた WebRTC のフル実装。2018 年初公開。LiveKit・Galene・ion-sfu・OBS の WHIP 配信まで、すべて Pion の上に乗っている。Go の単一バイナリ・並行性・クロスコンパイルの利点がメディアサーバ運用と相性が良い。

なぜ Pion か

• libwebrtc(Google の C++ WebRTC)はビルド・組み込みが悪名高く難しい。Pion は go get で終わる。
• Go の goroutine が多数ピア管理に自然に合う。
• WebRTC の全サブシステム(SDP・DTLS・SRTP・ICE・SCTP)が分離ライブラリで提供され、必要な部分だけ取り出せる。

Pion で書く一番単純な SFU ピア断片

1 人の発信者トラックを受け取り、別の参加者にそのまま流す最小形。実際の SFU 構築にはトラックルーティング・simulcast・DataChannel・再接続処理が加わる。

// sfu_peer.go — Pion で書く 1 対 1 トラック転送の断片
package main

import (
    "fmt"
    "github.com/pion/webrtc/v4"
)

func newPeer() (*webrtc.PeerConnection, error) {
    api := webrtc.NewAPI()
    pc, err := api.NewPeerConnection(webrtc.Configuration{
        ICEServers: []webrtc.ICEServer{
            {URLs: []string{"stun:stun.l.google.com:19302"}},
        },
    })
    if err != nil {
        return nil, err
    }

    // 入力トラックを受けて outgoing トラックとしてそのまま送出
    pc.OnTrack(func(remote *webrtc.TrackRemote, _ *webrtc.RTPReceiver) {
        // outgoing トラック生成(VP8 想定)
        local, err := webrtc.NewTrackLocalStaticRTP(
            remote.Codec().RTPCodecCapability,
            "video",
            "pion-sfu",
        )
        if err != nil {
            return
        }
        if _, err := pc.AddTrack(local); err != nil {
            return
        }

        // RTP パケットをそのまま転送
        buf := make([]byte, 1500)
        for {
            n, _, readErr := remote.Read(buf)
            if readErr != nil {
                return
            }
            if _, writeErr := local.Write(buf[:n]); writeErr != nil {
                return
            }
        }
    })

    pc.OnICEConnectionStateChange(func(s webrtc.ICEConnectionState) {
        fmt.Println("ICE state:", s.String())
    })

    return pc, nil
}

このコードの限界は明白。1 対 1 のみで、simulcast(多解像度トラック)は受けず、シグナリングも入っていない。それでも Pion の直接さは伝わる。

Pion ベースのプロジェクト

• LiveKit
• Galene — 単一運営者を想定する軽量 SFU。講義・小規模会議に向く。
• ion-sfu — フル SFU。simulcast・録画・ルーティング。
• OBS Studio の WHIP 配信 — Pion クライアントモジュール。

5 章 · mediasoup — Node.js の標準 SFU ライブラリ

mediasoup は Node.js 陣営の SFU ライブラリ。自身がデーモンではなく Node プロセスから import するライブラリ形態である点が肝。Worker は C++ で書かれ、JS がそれを操る。

なぜ mediasoup か

• ライブラリ形態なので、シグナリング・認証・ルーム管理を完全に自由に設計できる。
• simulcast・SVC・録画・トランスコード・サーバルーティングすべて対応。
• Discord や Microsoft Mesh のような大手が mediasoup を基盤にしたという事例がある。

mediasoup の短所

• シグナリングからルーム管理・認証・再接続まで全部自分で書く。LiveKit/Janus が端から端まで結ぶのとは正反対。
• 学習曲線が最も急。router・transport・producer・consumer の抽象が多層。
• Node 陣営以外のクライアント SDK はコミュニティが回す。

「チームにメディアインフラを深く理解するエンジニアがいる」前提のときだけ勧める。LiveKit やマネージドが埋める席に mediasoup を自前で書くと半年ぶんが費用に化ける。

6 章 · Janus — C で書かれた OG SFU

Janus は 2014 年公開の C ベース SFU。WebRTC インフラの OG で、プラグインアーキテクチャがトレードマーク。

• VideoRoom プラグイン — 定番の多人数会議。
• Streaming プラグイン — RTP/RTSP を WebRTC に変換。
• AudioBridge プラグイン — 多人数オーディオミキシング。
• WHIP プラグイン — 標準 WHIP 配信を受信。

Janus の立ち位置

• 非常に古く安定。小さいコア・低メモリ・C の性能。
• プラグインモデルでライブ配信・通話・ミキシングなど多様なシナリオを 1 デーモンで回せる。
• 短所: シグナリングプロトコルが独自(REST/WebSocket の Janus API)。クライアント SDK がマネージドほど豊富ではない。
• 新規採用は LiveKit/マネージドに流れる傾向だが、活動は続いている。

7 章 · Jitsi — フルスタック OSS 会議ソリューション

Jitsi は OSS のフルスタック会議ソリューション。一度ダウンロードすれば Jitsi Meet(Web UI)+ Videobridge(SFU)+ Jicofo(シグナリング)+ Prosody(XMPP)が一塊で動く。

• 8x8(Jitsi を買収)がメインメンテナ。
• 「社内会議ソリューション」をセルフホストで素早く立ち上げる用途で第一候補。
• API 統合は弱い — Jitsi は「ソリューション」であって「ライブラリ」ではない。

代替ユースケース

• 社内会議ソリューションのセルフホスト → Jitsi。
• 自社プロダクトに動画を組み込む → LiveKit / mediasoup / マネージド。
• 二つを混同するケースが多い。狙いが違う。

8 章 · マネージド陣営 — Daily, 100ms, Twilio Video, AWS Chime SDK

マネージドビデオ API の大筋は似ている。SDK + サーバ SDK + マネージド SFU + 録画 + 分析。ただ強みが分かれる。

Daily.co

• 最も洗練された DX。一行 prebuilt 埋め込み(call-frame)とフル SDK の両方が強い。
• 分析・セッションリプレイが最も深い。どのユーザのどの通話がどう壊れたかが一番見える。
• 価格: 分単位課金。1000 人規模までは合理的。

100ms

• インド発。RoomKit という事前ビルト会議 UI パッケージ。
• インド・東南アジア市場の比重が強い。ライブ配信用 RoomKit が別に存在し、ライブ配信も同梱。
• 価格競争力が強み。

Twilio Video

• かつてはエンタープライズの定番だったが 2024 年に新規受付停止、2026 年に EOL へ。Twilio の音声・SMS は生きている。
• 現時点で新規に Twilio Video を選ぶ理由はほぼ無い。

AWS Chime SDK

• AWS 陣営でビデオ通話を組むときの第一候補。IAM・CloudWatch・S3 録画など AWS エコシステム統合が強み。
• Voice Focus(ノイズ抑制)・Echo Reduction などのパーツが一等で同梱。
• 短所: 価格が高く、クライアント SDK は LiveKit/Daily ほど洗練されていない。

Cloudflare Realtime / Calls

• 2024 年登場。Cloudflare のエッジネットワーク上に WebRTC SFU を投げたという新カテゴリ。
• グローバル分散が一等で、WHIP/WHEP 標準サポートが強力。
• 新しい価格モデルでトラフィック形状次第で大差が出る。評価する価値は十分。
• 短所: エコシステムがまだ若い。SDK・ドキュメントは LiveKit/Daily に届かない。ただし追走速度は速い。

9 章 · WHIP/WHEP — RTMP を置き換える新標準

ライブインジェストは長らく RTMP の席だった。2002 年に Adobe が作ったプロトコル。H.264・Flash 時代に作られ、決定的な弱点が三つ。

• コーデックが事実上 H.264 固定。AV1・VP9・HEVC は不可。
• 遅延 2〜5 秒。WebRTC は 200〜500ms。
• TCP ベースでパケット損失復帰が鈍い。

WHIP(WebRTC-HTTP Ingestion Protocol)と WHEP(WebRTC-HTTP Egress Protocol)が答え。IETF 標準化が進む。

WHIP の流れ

1. 配信者が SDP offer を HTTP POST でサーバに投げる。
2. サーバは SDP answer を 200 OK で返す。
3. DTLS/SRTP のネゴが終われば、メディアが流れ始める。

これだけだ。シグナリングは HTTP 一往復。WebSocket やシグナリングサーバを別に立てる必要がない。

WHIP 配信クライアント — fetch 一発で

// whip-publisher.js — マイク/カメラを WHIP で配信
async function publishWHIP(endpoint, token) {
  const pc = new RTCPeerConnection({
    iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
  });

  // ローカルメディア追加
  const stream = await navigator.mediaDevices.getUserMedia({
    audio: true,
    video: { width: 1280, height: 720 },
  });
  stream.getTracks().forEach((track) => pc.addTrack(track, stream));

  // SDP offer 作成
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  // ICE gathering 完了を待つ(簡略化)
  await new Promise((resolve) => {
    if (pc.iceGatheringState === 'complete') return resolve(null);
    pc.addEventListener('icegatheringstatechange', () => {
      if (pc.iceGatheringState === 'complete') resolve(null);
    });
  });

  // WHIP エンドポイントへ SDP を POST
  const response = await fetch(endpoint, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/sdp',
      Authorization: `Bearer ${token}`,
    },
    body: pc.localDescription.sdp,
  });

  if (!response.ok) {
    throw new Error(`WHIP failed: HTTP ${response.status}`);
  }

  // サーバの answer を RemoteDescription に設定
  const answer = await response.text();
  await pc.setRemoteDescription({ type: 'answer', sdp: answer });

  return pc;
}

// 利用
const pc = await publishWHIP(
  'https://ingest.example.com/whip/my-stream',
  'my-token',
);

WHIP/WHEP が採用された場

• OBS Studio 30+ — WHIP 配信が標準オプション。
• LiveKit Ingress — WHIP・RTMP・SRT を同じ入口で受ける。
• Cloudflare Realtime — WHIP/WHEP 一等サポート。
• Twitch・YouTube Live — 試験中(2026 年 5 月時点)。
• mediasoup・Janus — プラグインで対応。

WHIP/WHEP が RTMP を置き換える理由

• コーデック自由(VP9・AV1・H.264・Opus などを SDP ネゴで決定)。
• 遅延が一桁秒 → 0.5 秒。
• HTTPS POST 一回でファイアウォール越えが容易(443)。
• WebRTC 標準上なので、標準のデバッグツールがそのまま使える。

10 章 · SFU vs MCU vs P2P — トポロジ選定

WebRTC インフラのトポロジは選定の大きな軸。

SFU が標準になった理由

• サーバ CPU コストが低い。デコード/エンコードしない。RTP パケットをルーティングするだけ。
• simulcast(多解像度)対応。受信者の帯域に合わせて適切な解像度トラックを選ぶ。
• SVC(スケーラブルビデオコーディング)対応。1 トラック内に複数レイヤがあり、より効率的。

MCU の出番

• 電話会議(PSTN ゲートウェイ) — 全員を 1 本にミックスする必要がある。
• 極めて非力なクライアント(組み込み・古い端末) — 1 トラックだけ受ければ良い。
• 録画の最終成果物(単一の合成映像)。

P2P の出番

• 1 対 1 のビデオ通話 — STUN で直結すればサーバ費用 0。
• 小さな家族・友人向けアプリ。3 人以上なら SFU が正解。

11 章 · コーデックの風景 — Opus, VP8, VP9, AV1, H.264, H.265

WebRTC の必須コーデックはオーディオ Opus、ビデオ VP8・H.264。それ以外は選択。

オーディオ

• Opus — 事実上唯一の選択肢。8〜510 kbps の可変。音楽・音声両方で良い。すべての WebRTC 実装がサポート。
• G.711・G.722 — PSTN ゲートウェイで時折使われる。WebRTC 内部ではほぼ使わない。

ビデオ

• VP8 — WebRTC 初期からの必須。互換性最高。
• H.264 — 必須。iOS Safari でハードウェアアクセラレーション一等。米国市場で好まれる。
• VP9 — 任意。AV1 の前段にあたる効率の良いコーデック。Chrome・Firefox 対応。
• AV1 — 任意。最も効率が良い(VP9 比 30% 良い)。エンコードコストが高くすべてのシナリオに合うわけではない。2026 年にデスクトップのハードウェアアクセラレーションが普及し採用が加速。
• H.265(HEVC) — WebRTC ではほぼ使わない。ライセンス負担。

simulcast と SVC

• simulcast — 配信側が同じ映像を複数解像度/ビットレートで同時送出。SFU が受信者ごとに選ぶ。
• SVC — 1 ストリーム内にベースレイヤ + エンハンスメントレイヤが乗る。SFU がレイヤを削って送る。AV1・VP9 で強い。

判断

• まずは VP8 + Opus。どこでも互換。
• iOS 一等サポート → H.264 を併用。
• 帯域節約・高品質 → AV1 を追加、エンコードコストを織り込む。
• simulcast は必ず ON。SFU 側で受信者別の適応が効かないと大きなルームが崩れる。

12 章 · マネージド vs セルフホストの決定マトリクス

大きな判断 1 回。このマトリクスがガイド。

マネージド → セルフホスト移行のシグナル

• マネージド費用が月 USD 5,000 を超え始める → セルフホストインフラ + DevOps 1 名のコストを超える。
• データ主権・HIPAA・オンプレ要件 → マネージドは難しい。
• メディアパイプラインを深く触る必要(カスタムトランスコード・カスタムルーティング) → マネージドの抽象が塞ぐ。

セルフホストの隠れコスト

• TURN サーバ — 社内ファイアウォール背後のユーザ比率ぶんトラフィックを背負う。トラフィックは高い。
• ロードバランサ・ノードクラスタリング。
• 録画ストレージ・トランスコードワーカー。
• 監視・観測性(WebRTC stats が最も難しい)。
• インシデント対応 — メディアサーバは他のサーバより一段難しい。

13 章 · クライアント側ライブラリ

サーバと同じくらい、クライアントが選定の半分。

標準 RTCPeerConnection

• ブラウザの素の API。最軽量だがシグナリングを完全自前。
• 小さな P2P デモ・WHIP 配信・非常に軽い場面に合う。

LiveKit Client SDK

• Room, Participant, Track の抽象。自動再接続・simulcast・DataChannel。
• @livekit/components-react — 会議 UI を即作る。

Daily の call-frame

• 一行 iframe 埋め込み。最も単純。フル SDK もある。

mediasoup-client

• mediasoup サーバと対。transport / producer / consumer の抽象。

Janus の JS アダプタ

• Janus サーバと対。REST/WebSocket シグナリング。

simple-peer

• 最も単純な P2P ライブラリ。シグナリングは自前。

14 章 · 運用 — TURN, NAT, モニタリング

運用の半分はシグナリング・NAT・観測性に行く。

STUN と TURN

• STUN — クライアントが自分のパブリック IP/ポートを知るためのサーバ。UDP 1 RTT。
• TURN — STUN で抜けられない NAT(対称 NAT・ファイアウォール)越しのユーザ用のメディアリレー。トラフィックが TURN を通るので高い。
• coturn — TURN サーバの事実上の標準 OSS 実装。
• TURN トラフィック比率は通常 5〜20%。企業ネットワークが多ければ 50% まで。

getStats() で見る WebRTC 観測性

• 標準 RTCPeerConnection.getStats() が RTT・jitter・パケット損失・コーデック・解像度などを返す。
• 1 分に 1 回集めてデータウェアハウスに流す。
• マネージド(Daily・LiveKit Cloud)はダッシュボード化されている。

通話品質指標

• MOS(Mean Opinion Score) — 1〜5 の通話品質スコア。RTT・パケット損失・jitter から推定。
• 参加失敗率 — ルーム到達できなかった比率。中心の SLI。
• 再接続頻度 — 1 通話あたり再接続回数。
• ビデオフリーズ時間 — ビデオが止まっていた累積時間。

15 章 · ライブ配信のシナリオ

ライブ配信は WebRTC インフラの別領域として固まった。シナリオ別の推奨。

WebRTC ライブが RTMP ライブを置き換える境界

• 視聴者規模が非常に大きい(10 万+) → CDN の距離は HLS/DASH が依然標準。WebRTC は 5 万以内が合理的。
• 広告挿入・DRM のような放送機能は HLS 陣営が深い。
• WebRTC ライブは「低遅延 + 双方向インタラクション」が強みの領域で優位。

16 章 · セキュリティ・DRM・E2EE

WebRTC は基本的に DTLS-SRTP で暗号化されている。メディアパケットはクライアント-サーバ間で常に暗号化される。ただし SFU モードでは SFU が平文でルーティング判断をする(コーデック情報・simulcast レイヤ選択など)。

E2EE — Insertable Streams

• 真の端末間暗号化が必要なら Insertable Streams で SFU にも平文を見せない。
• LiveKit・Jitsi・Google Meet が採用。マネージドキー管理が肝。
• 代償: simulcast 効率が落ち、サーバ側録画・トランスコードが難しくなる。

DRM

• WebRTC と DRM は相性が悪い。DRM はコンテンツ保護が目的、WebRTC はリアルタイム性が目的。
• ライブ配信 DRM が必要なら HLS + Widevine の組み合わせに行く。

17 章 · ケーススタディ — AI ボイスエージェントのフルスタック

上のツールが集まるとこう動く。最も一般的なシナリオ。

[ユーザのブラウザ]
    |
    | WebRTC オーディオ送受信
    v
[LiveKit Server]
    |
    | LiveKit Agents ワーカーが自動でルームに参加
    v
[Agents Worker (Python)]
    |
    +-- Deepgram STT(ストリーミング)
    +-- OpenAI gpt-4o-mini(LLM)
    +-- ElevenLabs TTS(ストリーミング)
    +-- Silero VAD(ターン判定)
    |
    | TTS オーディオを LiveKit ルームへ送出
    v
[ユーザのブラウザ — 即時再生]

遅延分解(目標 700ms 未満)

• ユーザの発話終了 → VAD がターン判定: 100〜200ms
• 最終 STT 結果確定: 50〜100ms
• LLM の最初のトークンまで: 200〜400ms
• 最初の TTS オーディオチャンクまで: 100〜200ms
• WebRTC 伝送遅延: 50〜150ms

合計: 500〜1000ms。「会話っぽく感じる」境界がこのあたり。

OpenAI Realtime + WebRTC 直結モード

上の図で Deepgram・OpenAI・ElevenLabs が 1 モデルにまとまる。遅延 200〜400ms。

[ユーザのブラウザ]
    |
    | WebRTC オーディオ直結
    v
[OpenAI Realtime エンドポイント]
    |
    | モデルがオーディオ入出力を直接扱う
    v
[ユーザのブラウザ — 応答オーディオ]

このモードのトレードオフ

• 長所: 遅延が極小。モデルが発話のニュアンス(笑い・割り込み)を直接見る。
• 短所: 価格が高い。モデルが OpenAI 陣営に固定。STT/TTS の自由度が落ちる。

多くの本番では両方を併走させる。素早い会話は Realtime、ツール呼び出し・カスタム TTS は通常 LLM + 別 STT/TTS。

18 章 · よくあるアンチパターン

運用で何度も見た。

1. P2P メッシュで 4 人以上を回そうとする — 5 人で崩れる。最初から SFU。
2. TURN サーバ無しで出荷 — 社内ネットワーク背後のユーザが入る瞬間、通話失敗率 30% に到達。
3. simulcast を OFF にして 1 解像度のみ配信 — 10 人ルームで誰かがモバイル 4G だと全員が切れる。
4. getUserMedia の許可を 1 回取れば終わりと思う — 許可はページ・セッション単位で変わる。毎回確認。
5. WebSocket シグナリング 1 個で SFU まで回そうとする — シグナリングはシグナリング、メディアはメディア。1 プロセスにまとめない。
6. WebRTC statistics 収集をしない — ユーザが「切れます」と言っても再現できない。getStats() を 1 分に 1 回。
7. 録画・トランスコードを SFU と同一プロセスに詰める — エンコード 1 本で SFU 全体が止まる。別ワーカーへ。
8. AI ボイスエージェントで VAD を弱く構える — 発話の途中でモデルが割り込む、または終わってもモデルが返さない。
9. WHIP・RTMP・SRT のうち RTMP だけ受ける — 2026 年に AV1・VP9 配信は RTMP では不可。WHIP を選択肢に。
10. セルフホストで監視が PromQL メトリクス 5 本で終わる — メディアサーバの観測性は通常 Web サーバより一段深い。

19 章 · 大きな絵 — 何が標準になったか

2026 年 5 月時点のまとめ。

• LiveKit が AI ボイスエージェントインフラの標準 — Agents フレームワーク・OpenAI 採用・OSS + クラウド両線。
• Pion が Go 陣営の WebRTC エンジン — LiveKit・Galene・OBS WHIP すべてが Pion 上。
• WHIP/WHEP が RTMP の席を急速に奪う — OBS 30+ が標準サポート。
• OpenAI Realtime が WebRTC 直結モードを追加 — ボイスエージェントの遅延が人間会話レベル。
• Cloudflare Realtime がエッジ SFU という新カテゴリを作る — グローバル分散が一等。
• マネージド陣営はまだ強い — Daily・100ms・AWS Chime SDK。ただし価格圧力。
• Twilio Video は事実上消える — 新規受付停止、EOL 進行中。
• mediasoup・Janus・Jitsi がセルフホストの三系統として固まる。

判断チェックリスト

• AI ボイスエージェントが中心? — LiveKit + LiveKit Agents。
• 社内会議ソリューションが要る? — Jitsi セルフホスト。
• ライブ配信インジェストが中心? — WHIP + LiveKit Ingress または Cloudflare Realtime。
• グローバル分散エッジが最優先? — Cloudflare Realtime または LiveKit Cloud。
• マネージドの一等分析が必要? — Daily。
• インド・東南アジアの価格競争力が必要? — 100ms。
• AWS と深い統合が必要? — AWS Chime SDK。
• Go で小さな SFU 断片を深く触る? — Pion を直接。
• Node.js でシグナリング・ルーティングを完全制御? — mediasoup。
• 非常に安定した古い C デーモンが欲しい? — Janus。

アンチパターン要約

1. P2P メッシュで 4 人以上。
2. TURN 無しで出荷。
3. simulcast OFF。
4. WebRTC getStats() 未収集。
5. シグナリング・SFU・録画・トランスコードを 1 プロセス。
6. AI エージェントで VAD が弱い。
7. RTMP のみ受信(WHIP 未対応)。
8. 大きなルームに MCU を強要。
9. マネージドとセルフホストを未決定のまま混在。
10. E2EE を ON にしてサーバ側録画に期待。

次回予告

次回候補: LiveKit Agents 深掘り — トークン単位ストリーミング・ツール呼び出し・割り込み処理、WHIP/WHEP インジェストの 1 か月運用記 — OBS・Cloudflare・LiveKit 比較、WebRTC getStats() 100 メトリクス — 何を見て何を捨てるか。

「WebRTC は単一標準ではなく標準の束だ。束を運用できるチームほど遠くへ行く。」

— WebRTC メディアインフラ 2026、おわり。

参考 / References

• LiveKit 公式
• LiveKit GitHub — livekit/livekit
• LiveKit Agents フレームワークドキュメント
• LiveKit Agents GitHub — livekit/agents
• LiveKit Cloud 料金
• Pion 公式
• Pion WebRTC GitHub
• Daily.co 公式
• 100ms 公式
• mediasoup 公式
• Janus Gateway 公式
• Jitsi Meet 公式
• Twilio Video ドキュメント
• AWS Chime SDK ドキュメント
• Cloudflare Realtime 公式
• Cloudflare Calls 発表
• WHIP IETF 標準 RFC 9725
• WHEP IETF ドラフト
• OBS Studio — WHIP 配信サポート
• OpenAI Realtime API ドキュメント
• OpenAI Realtime + WebRTC ガイド
• Deepgram Nova モデル
• ElevenLabs TTS ドキュメント
• Cartesia TTS
• Silero VAD GitHub
• coturn GitHub — TURN サーバ OSS 標準
• WebRTC getStats() MDN
• Insertable Streams MDN
• Opus コーデック
• AV1 コーデック
• Galene SFU GitHub
• ion-sfu GitHub
• webrtc-rs GitHub