https://docs.livekit.io/home/

Getting Started: 認証

了解！以下は、LiveKit公式ドキュメント「Authentication」セクションの日本語訳（2025年7月24日時点）です：

認証（Authentication）

LiveKit セッションにユーザーを認証する方法を解説します。

概要

LiveKit SDK がサーバへ接続するには、アクセストークンをリクエストに含める必要があります。

このトークンは以下の情報を含みます：

• 参加者の識別子（identity）
• ルーム名
• 権限（roomJoin, canPublish など）
• 有効期限

トークンは JWT 形式で、APIシークレットで署名されており、改ざんを防止します。
なお、有効期限は初回接続にのみ影響し、再接続時には考慮されません。

アクセストークンの作成

🔧 LiveKit CLI:

lk token create \
  --api-key <KEY> \
  --api-secret <SECRET> \
  --identity <名前> \
  --room <ルーム名> \
  --join \
  --valid-for 1h

💻 各言語でのトークン生成例

以下はすべて「Roomへ参加するためのVideoトークン」作成例です：

Node.js

import { AccessToken, VideoGrant } from 'livekit-server-sdk';

const at = new AccessToken('API_KEY', 'API_SECRET', { identity: 'ユーザー名' });

at.addGrant({
  room: 'ルーム名',
  roomJoin: true,
  canPublish: true,
  canSubscribe: true,
});

const token = await at.toJwt();
console.log('access token', token);

（他言語版は省略可能。要望があれば全訳対応）

トークンの中身（例）

以下はJWTトークンをデコードした例です：

{
  "exp": 1621657263,
  "iss": "APIキー",
  "sub": "ユーザーID",
  "video": {
    "room": "myroom",
    "roomJoin": true
  },
  "metadata": ""
}

🎥 Video Grant の権限一覧

"video": {
  "room": "room-name",
  "roomJoin": true,
  "canPublish": true,
  "canSubscribe": true,
  "canPublishData": true,
  "canPublishSources": ["camera", "microphone"],
  "canUpdateOwnMetadata": true,
  "hidden": false
}

🔐 SIP Grant（電話関連の権限）

電話（SIP）サービスと連携するには、sipフィールドを付与します：

"sip": {
  "admin": true,
  "call": true
}

🏗️ Room Configuration（ルーム設定付きトークン）

トークンに roomConfig を含めると、ルーム作成時に設定が反映されます。

例：エージェントを指定して招待する

at.roomConfig = new RoomConfiguration ({
  agents: [
    new RoomAgentDispatch({
      agentName: "ai-bot",
      metadata: "greeting-bot"
    })
  ]
})

この仕組みで「特定のBotを起動してユーザーを迎える」といった動作が可能になります。

🔁 トークンの自動更新

LiveKitでは、接続中の参加者に対して自動的に新しいトークンを発行します（有効期限：10分）。

また、以下の情報が変わると即時再発行されます：

• 名前
• 権限
• メタデータ

🔄 権限の動的変更

参加者がRoomに接続した後でも、UpdateParticipant API を使って以下が可能：

• canPublish: false → true に変更
• 視聴者から登壇者への昇格など

📎 補足リンク

• 最新ドキュメント: https://docs.livekit.io/home/get-started/authentication.md
• CLI: https://github.com/livekit/livekit-cli
• Node.jsトークン生成コード: AccessToken.ts

次に翻訳したいセクションがあれば教えてね！（例：Server API, Agent Dispatch, Room Lifecycle など）
Rust版のトークン生成などを深掘りしてもOK！

スタータープロジェクトの紹介

アプリケーションの初期化（Bootstrapping an application）

用意されたテンプレートからアプリを作成・初期化します。

ℹ️ 補足

開始する前に、以下を済ませておいてください：

• LiveKit Cloud アカウントの作成
• LiveKit CLI のインストール
• 任意の LiveKit プロジェクトへの認証または手動設定

アプリのブートストラップ

LiveKit CLI を使えば、便利なテンプレート群からアプリケーションをブートストラップできます。
CLI はプロジェクトの認証情報を使って、必要な環境変数や設定を自動でセットアップしてくれます。

アプリをテンプレートから作成するには以下を実行：

lk app create --template <テンプレート名> my-app

その後、CLIの案内に従ってセットアップを完了してください。

--template を省略すると利用可能なテンプレート一覧が表示されます。

🎨 利用可能なテンプレート

💡 ヒント

LiveKitの Agents フレームワーク を試したり、事前構築済みのフロントエンドやトークンサーバーでプロトタイピングしたい場合は、Sandbox環境 をチェックしてみてください。

🔗 関連リンク

• テンプレートの一覧: LiveKit Template Index
• 最新版のこのドキュメント: templates.md

STT, VAD の設定

https://docs.livekit.io/agents/integrations/stt/#vad-and-streamadapter

4o に雑投げ

LiveKit における Signaling, STUN, TURN

LiveKit は WebRTC アプリの構築に必要な signaling / STUN / TURN の仕組みを内包しており、開発者はほぼ意識せずに使えるようになってるよ。ただし、少し細かく見てみよう：

✅ 1. Signaling サーバ

• LiveKit に完全に内包されている
• クライアント（ブラウザなど）と SFU 間の通信の確立、トラックの publish/subscribe、参加者の入退室、ICE candidate 交換などを処理
• WebSocket 経由で通信する（例: wss://yourdomain.livekit.cloud）

→ Signaling サーバの独立運用は 不要

✅ 2. STUN サーバ

• LiveKit Cloud では自動で提供
• Self-hosted LiveKit Server でも、デフォルトで Google の STUN（stun:stun.l.google.com:19302）を利用
• STUN は「自分のグローバルIPを知るための軽い仕組み」なので LiveKit に特化した処理は不要

→ もし必要なら自前の STUN サーバを指定することも可能（config で設定）

✅ 3. TURN サーバ

• LiveKit Cloud では TURN サーバ込み（商用グレード）
• 自前で構築する場合は、coturn などの TURN サーバと連携する必要がある

なぜ必要かというと：

NAT やファイアウォールの影響で P2P や UDP での通信ができないときに、TURN がリレー通信を補う

→ LiveKit 自体は TURN サーバ機能を直接提供しないけど、TURN サーバとの統合設定は公式にサポートされてる

🛠 自前で構築する場合の構成例（Self-Hosted）

Client (browser)
   │
   ├── WebSocket
   │   ↓
   └─▶ LiveKit Signaling Server (内包)

Media:
   ├── UDP, TCP
   │   ↓
   ├─▶ LiveKit SFU
   │
   └──（接続できない場合）
         ↓
       TURN Server (coturnなど) ← 指定可能

✅ まとめ表

必要なら、Self-hosted 構成で TURN を組み込む config.yaml の例も出せるよ！興味ある？

SFU とは

https://docs.livekit.io/reference/internals/livekit-sfu/

以下は、LiveKit の SFU に関するドキュメントの日本語訳と、添付のアーキテクチャ図の説明です。

🔧 LiveKit SFU（Selective Forwarding Unit）とは

LiveKit は WebRTC の中でも「SFU」方式を採用した、水平スケーリングが可能なメディアサーバです。

💬 P2P / MCU / SFU の違い

🔹 P2P（ピア・ツー・ピア）方式

• 基本の WebRTC の形。
• 各参加者が他の参加者に直接音声や映像を送信。
• 2～3人程度なら機能するが、それ以上になるとアップロード帯域が厳しい（例：720p 映像を5人に送るのは困難）。

🔹 MCU（Multipoint Control Unit）方式

• 全員のメディアをサーバに集め、合成して一つの映像として各参加者に配信。

• 特徴:

  • 送信者（Publisher）は1つだけ送ればOK。
  • 受信者（Subscriber）も1つの合成された映像を受け取るだけ。

• 欠点:

  • 柔軟性が低い（音量個別調整不可、UI自由度が低い）。
  • 高スペックサーバが必要。スケールが難しい。

🔹 SFU（Selective Forwarding Unit）方式（LiveKit が採用）

• サーバは受信したストリームを加工せずそのまま複数の受信者へ中継。

• 特徴:

  • 送信者は1つだけ送ればOK（アップロード負荷軽減）。
  • 受信者は複数の個別ストリームを受信（ダウンロード帯域は多く使う）。
  • 柔軟性が非常に高く、個々の映像や音声の制御が可能。
  • スケーラビリティが高く、大規模セッションも分散処理可能。

🧠 LiveKit のスマートさ

• クライアント SDK と SFU サーバが協調し、受信者のネットワーク帯域を自動で測定。
• 解像度やビットレートなどを動的に調整（開発者が意識しなくてもOK）。

🏗️ アーキテクチャ図の説明（添付画像）

CLIENT
  │
  ├── websocket TLS（シグナリング通信）
  │
  ▼
LOAD BALANCER（ロードバランサ）
  │
  ├─→ 複数の LIVEKIT SERVER へ振り分け
        └─ Redis によるルーム参加者の P2P ルーティング制御
  │
  └── 各クライアントとの WebRTC UDP/TCP 通信を中継

各コンポーネントの役割

💡補足：LiveKit の特徴

• 言語: Go で実装
• WebRTC ライブラリ: Pion 使用
• 単一ノードでも動作可能（Redis 不要）
• 複数ノードで動かす場合は Redis が必須

もしこのアーキテクチャに応じたアプリの構築方法、例えば「自分の音声AIアプリをこの LiveKit 上に構築するには？」のような観点で解説が欲しければ、続けて教えてください。

WebRTC on LiveKit での Signaling

https://docs.livekit.io/reference/internals/client-protocol/

以下は、LiveKit における シグナリング（Signaling）プロトコル の日本語訳および解説です。

🎯 シグナリングとは？

WebRTC で音声・映像をやりとりする前に、「誰が誰と、どのように接続するか」 を調整する通信が必要です。これが シグナリング です。

LiveKit では、WebSocket を使ってクライアントとサーバ間でシグナリング を行います。通信の中身は Protocol Buffers（protobuf） で定義されています。

🔌 通信の基本構造

• 通信は WebSocket + protobuf

• 通常、クライアントは 最大2つの WebRTC PeerConnection を作成：

  • 送信用 PeerConnection（映像や音声を送る）
  • 受信用 PeerConnection（他の参加者の映像や音声を受け取る）

• 最初に接続されるのは「受信用 PeerConnection」（=自動購読）

• 送信する場合にだけ、送信用の接続を追加で確立

🚪 ルーム参加の流れ（Join）

1. クライアントが /rtc に WebSocket 接続

2. サーバが JoinResponse を送信（ルーム・参加者情報を含む）

3. サーバが 受信用 PeerConnection を初期化し、offer を送る

   • ここで既存のトラック情報も含まれる（auto_subscribe = true の場合）
   • データチャンネルも2つ自動的に作成

4. trickle ICE による ICE Candidate の交換

5. クライアントが answer を送信し、接続完了

6. ICE 接続が確立

7. サーバが他の参加者に「新しい参加者が来た」と通知

🌐 WebSocket /rtc のパラメータ

📤 トラックの送信（Publishing）

1. クライアントが AddTrackRequest を送信（メタ情報付き）
2. サーバが TrackPublishedResponse を返す
3. クライアントが PeerConnection に transceiver + media track を追加
4. クライアントが offer を送信
5. サーバが answer を返して接続確立
6. 他の参加者にもそのトラックが配信される

📥 トラックの受信（Receiving）

• トラックが公開されると、すぐにそのメタデータが全参加者に送られる
• それぞれのクライアントの「受信用 PeerConnection」に追加される

📡 サーバからのイベント通知

サーバは以下のイベントをクライアントに通知：

これらは 冪等（べきとう）性 を持って処理する必要あり（重複送信もあり得る）

🎛️ クライアントからの操作（制御系）

🔇 トラックのミュート

• WebRTC の MediaStreamTrack.enabled = false に加えて、

• MuteTrackRequest を送信して、明示的にサーバへ通知

  • 空パケット送信を抑制でき、ネットワーク負荷軽減

📉 質の変更（UpdateTrackSettings）

• 一部トラックの画質を落とす、一時停止する、などを指示可能
• 例: UI 外のユーザーの映像は一時停止 → 帯域節約

📡 購読の制御（UpdateSubscription）

• 必要なトラックだけ購読し、他は購読解除できる

✨まとめ：LiveKit の Signaling の特徴

さらに具体的に SDK 実装や、UI 側の挙動についても知りたい場合は教えてください。必要ならメッセージフォーマット（protobuf の構造）も掘り下げられます。

📡 WebRTC の仕組み on LiveKit

LiveKit は WebRTC に基づく音声・映像通信インフラであり、水平スケーリング可能な SFU（Selective Forwarding Unit）アーキテクチャを採用しています。このドキュメントでは、LiveKit 上で WebRTC がどのように動作しているかを解説します。

🧑‍🤝‍🧑 登場人物

🔁 処理の流れ

1. ルーム参加（Signaling）

• クライアントが WebSocket 経由で /rtc に接続し、JWT トークン等の情報を送信
• サーバが JoinResponse を返却、部屋・参加者・既存トラック情報を含む
• サーバが受信用 PeerConnection を初期化し offer を送信
• クライアントが answer を返す（ICE candidate も交換）

2. メディア送信（Publishing）

• クライアントが AddTrackRequest を送信
• サーバが TrackPublishedResponse を返却
• クライアントが PeerConnection に映像/音声を追加し offer を送信
• サーバが answer を返し、送信ストリームの受信開始

3. メディア受信（Subscribing）

• 新しいトラックが公開されると、サーバが全参加者に通知
• 各参加者の PeerConnection にトラックが追加され、映像/音声を受信

4. 状態変化の通知

• ParticipantUpdate, SpeakersChanged, LeaveRequest などがサーバから随時通知される

5. クライアント制御（任意）

• MuteTrackRequest によるミュート
• UpdateSubscription によるトラック購読制御
• UpdateTrackSettings による画質制御など

🧭 シーケンス図（mermaid）

補足

概念整理

了解です！ここでは WebRTC の構成要素をより詳しく・明確に説明します。特に STUN と TURN を分けて、略語の意味・役割・動作も記載します。

🧩 WebRTC の概念（詳細解説）

WebRTC（Web Real-Time Communication）は、ブラウザやネイティブアプリ間で直接、音声・映像・データをリアルタイムにやり取りできる技術です。

以下のような複数の技術要素で構成されています：

🎥 MediaStream / MediaStreamTrack

• MediaStream は音声・映像などのストリーム全体（例：カメラ + マイク）。
• MediaStreamTrack はその中の1つのトラック（音声 or 映像）。

const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
const [videoTrack] = stream.getVideoTracks();

🔗 RTCPeerConnection（リアルタイム通信接続）

• P2P 接続を管理する中核クラス。
• 音声・映像などのトラックを相手に送るためのコネクション。
• 複数のネットワーク候補（ICE candidate）を検討して接続を最適化。

const pc = new RTCPeerConnection();

💬 RTCDataChannel（データチャンネル）

• テキスト・バイナリの任意データを P2P で送受信できる WebRTC の機能。
• チャット、ファイル共有などに利用可能。

const channel = pc.createDataChannel("chat");

🧭 シグナリング（Signaling）

• WebRTC には含まれていないが、必要不可欠な通信手順。

• 以下の情報を相手とやり取りするための仕組み：

  • offer / answer（接続交渉の提案と応答）
  • ICE candidate（接続候補情報）

• 方法は自由（例：WebSocket、HTTP、Socket.io など）

❄️ ICE（Interactive Connectivity Establishment）

• ネットワーク越え（NAT越え）接続のためのプロセス全体の名前。
• 接続候補（candidate）を複数用意し、ベストなものを選ぶ。

🌐 STUN（Session Traversal Utilities for NAT）

• NAT越えのために、自分のグローバル IP / ポートを知るための仕組み。
• UDP で問い合わせを送り、「外部から見える自分のIP:Port」を返してもらう。
• 中継しない。あくまで問い合わせるだけ。

🔁 TURN（Traversal Using Relays around NAT）

• どうしても P2P でつながらない時、通信を中継してくれるサーバ。
• 実質的に リレーサーバ。
• 帯域消費も多く、コストも高いが、確実な接続性を提供。

🔁 WebRTC の流れ（簡易）

1. クライアント A がメディア取得（MediaStream）
2. クライアント A/B が RTCPeerConnection を生成
3. A が offer を作ってシグナリング経由で B に送る
4. B が answer を返す
5. 双方が ICE candidate を交換（STUN 経由）
6. P2P 接続が確立 or TURN 経由にフォールバック
7. メディア or データをやりとり

✅ 補足まとめ

LiveKit や Zoom、Google Meet、Slack Huddles などのサービスは、上記の WebRTC の仕組みを隠蔽・制御・拡張することで高機能な通話体験を提供しています。

さらに掘り下げて知りたい要素（セキュリティ、QoS、再接続処理など）があれば教えてください！

LiveKit を Docker で動かす

以下が参考になった

https://qiita.com/maishikawa/items/57fdf23a7bd09f9b6d73