【2026年7月】LiveKit Agents完全ガイド｜WebRTC音声AI

「リアルタイム音声AIって、WebRTC関係でしょ？難しそう…」

実際に音声AIエージェントの導入支援を進める中で、最も多い反応がこれです。WebRTCと聞くだけで拒絶反応が出る開発者は多い。シグナリング、ICE、NAT越えなど、確かに低レベルの話をし始めるとキリがありません。

ところが、LiveKit Agentsを使うとその全複雑さが消えます。WebRTCの内部をまったく意識せずに、Pythonのコードだけで「ユーザーが話す → AIが聞く → AIが答える」のループを実装できるようになっています。2025年4月に1.0正式リリースを迎え、2026年7月時点でPython SDK 1.5.x系に達した現在、実用性は格段に上がっています。

この記事では、LiveKit Agentsの実装方法を、コピペできるコードつきで解説します。PipecatやVapiとの使い分け基準、本番運用の注意点まで含めて一気通貫でまとめます。

LiveKit Agentsとは｜WebRTC × LLM の仕組み

LiveKit Agentsは、音声・映像・物理AIエージェントを構築するためのリアルタイムフレームワークです。Apache 2.0ライセンスのオープンソースで、GitHubのlivekit/agentsリポジトリで公開されています（2026年7月時点でスター数10,000超）。

アーキテクチャの核心

LiveKit Agentsのエージェントは、「LiveKitルームに参加する1つの参加者（ヘッドレス参加者）」として動作します。人間のユーザーがブラウザやモバイルアプリからルームに入り、エージェントが別の参加者として自動参加する構造です。

[ユーザー側]
ブラウザ / iOS / Android
    ↓  WebRTC（マイク音声）
[LiveKit Cloud / Self-hosted SFU]
    ↓  WebRTC（音声トラック）
[エージェント（Python プロセス）]
    ↓  HTTP/WebSocket
[STT → LLM → TTS パイプライン]

ポイントは「エージェントはWebRTCを直接扱わない」ことです。LiveKit SDKがすべての低レベル処理（ICE交渉、DTLS、SRTP）を吸収し、エージェントコードからはシンプルなPython APIだけを見ることになります。

カスケードパイプラインとリアルタイムAPIの2構成

LiveKit Agentsには2つの動作モードがあります。

2026年7月時点では、90%以上の本番エージェントがカスケードパイプライン構成を採用しています（複数ベンダーを組み合わせることでコストと品質をコントロールできるため）。本記事ではカスケード構成を中心に解説します。

対応プロバイダー一覧

セットアップ｜Python 環境構築から認証まで

セットアップは3ステップで完了します。必要なのはPython 3.9以上の環境と、LiveKit Cloudアカウントです。

Step 1: パッケージインストール

基本パッケージとプラグインを一括でインストールします。STT/TTS/LLMはプラグイン形式で追加します。

# 基本パッケージ
pip install livekit-agents>=1.5.0

# プラグイン（最小構成: Deepgram STT + OpenAI LLM + Cartesia TTS）
pip install livekit-plugins-deepgram livekit-plugins-openai livekit-plugins-cartesia livekit-plugins-silero

# 注意: バージョン指定推奨。livekit-agents 1.5.x と互換性のあるプラグインバージョンを使うこと
# 動作環境: Python 3.9+, Ubuntu 20.04+, macOS 12+

Step 2: 環境変数の設定

LiveKit Cloudのダッシュボード（cloud.livekit.io）からプロジェクトを作成し、APIキーを取得します。

# .env ファイル
LIVEKIT_URL=wss://your-project.livekit.cloud
LIVEKIT_API_KEY=APIxxxxxxxxxxxxxxxx
LIVEKIT_API_SECRET=your-secret-here

# STT / LLM / TTS のAPIキー
DEEPGRAM_API_KEY=your-deepgram-key
OPENAI_API_KEY=sk-your-openai-key
CARTESIA_API_KEY=your-cartesia-key

# 注意: .env を .gitignore に追加し、本番ではシークレットマネージャーを使うこと

Step 3: 動作確認

LiveKit CLIでトークンを発行し、ブラウザのLiveKit Meetをテスト用クライアントとして使うのが最も手軽です。

# LiveKit CLI をインストール（Go製ツール）
# macOS
brew install livekit-cli

# ルームトークン発行（テスト用）
lk token create 
  --api-key $LIVEKIT_API_KEY 
  --api-secret $LIVEKIT_API_SECRET 
  --join --room test-room 
  --identity user-1 
  --valid-for 1h

最小構成の実装サンプル｜音声入力 → STT → LLM → TTS → 音声出力

以下が最小構成の音声AIエージェントです。このコードをそのまま動かせます。

エージェント本体

LiveKit Agentsでは Agent クラスを継承し、AgentSession にSTT/LLM/TTSを渡す構成になっています。

"""
LiveKit Agents 最小構成サンプル
動作環境: Python 3.10+, livekit-agents 1.5.x
"""
import asyncio
import logging
from dotenv import load_dotenv

from livekit.agents import Agent, AgentSession, JobContext, WorkerOptions, cli
from livekit.plugins import cartesia, deepgram, openai, silero

load_dotenv()
logging.basicConfig(level=logging.INFO)


class MyVoiceAgent(Agent):
    """シンプルな音声アシスタント。日本語での質問に答える。"""

    def __init__(self) -> None:
        super().__init__(
            instructions=(
                "あなたは丁寧で親しみやすい音声アシスタントです。"
                "簡潔に、わかりやすい日本語で回答してください。"
                "長い回答は2〜3文にまとめてください。"
            )
        )


async def entrypoint(ctx: JobContext) -> None:
    """エントリーポイント: ルームに接続してエージェントを起動する"""

    # ルームに接続
    await ctx.connect(auto_subscribe="audio_only")

    # セッション作成: STT → LLM → TTS の順にパイプラインを定義
    session = AgentSession(
        vad=silero.VAD.load(),                          # 音声区間検出
        stt=deepgram.STT(model="nova-3", language="ja"), # 日本語STT
        llm=openai.LLM(model="gpt-4.1-mini"),           # LLM
        tts=cartesia.TTS(
            model="sonic-3",
            language="ja",
            voice="CARTESIA_VOICE_ID_HERE",             # Cartesiaのボイス ID
        ),
    )

    # エージェントを起動してルームに参加
    await session.start(ctx.room, agent=MyVoiceAgent())

    # 最初の挨拶
    await session.generate_reply(
        instructions="まず簡潔に挨拶してください。"
    )


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

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

起動コマンド:

python agent.py dev  # 開発モード（ホットリロードあり）

コードのポイント:

• AgentSession がSTT/LLM/TTSのパイプラインを自動で接続します。ストリーミング処理（LLMが生成しながらTTSが合成）は内部で自動管理
• vad=silero.VAD.load() はオフラインで動くSilero VADを使います。クラウドSTTへの無駄な送信を防ぎます
• auto_subscribe="audio_only" で映像トラックを無視し、音声のみ処理します（コスト節約）

Function Callingの実装

エージェントにツールを持たせる場合は、@function_tool デコレータを使います。Pythonの型アノテーションからJSONスキーマが自動生成される仕組みです。

from livekit.agents import Agent, function_tool
from livekit.agents.types import NOT_GIVEN
import httpx
from typing import Annotated


class WeatherAgent(Agent):
    """天気情報を取得できる音声エージェント"""

    def __init__(self) -> None:
        super().__init__(
            instructions=(
                "あなたは天気情報を提供する音声アシスタントです。"
                "天気を聞かれたら必ずget_weather()ツールを呼び出してください。"
            )
        )

    @function_tool
    async def get_weather(
        self,
        city: Annotated[str, "都市名（例: Tokyo, Osaka）"],
    ) -> str:
        """指定した都市の現在の天気を取得します"""
        # Open-Meteo（無料の天気API）を使用
        async with httpx.AsyncClient() as client:
            # 簡略化のため、ここでは東京の座標を固定
            resp = await client.get(
                "https://api.open-meteo.com/v1/forecast",
                params={
                    "latitude": 35.6762,
                    "longitude": 139.6503,
                    "current_weather": True,
                },
            )
            data = resp.json()
            temp = data["current_weather"]["temperature"]
            return f"{city}の現在気温は{temp}℃です。"

# 注意: 本番では都市名から座標を動的に取得するジオコーディング処理を追加してください。

ポイント:

• ツールの docstring がLLMへの説明文になります。「いつ呼び出すか」を明記すると精度が上がります
• 非同期（async def）必須。外部APIコールはすべて httpx や aiohttp を使います
• 型アノテーションの Annotated[str, "説明"] でパラメータの説明を付けられます

Interruption Handling（割り込み処理）の実装

音声AIで最も重要な機能の一つが、ユーザーが途中で話しかけてきた時の割り込み処理です。LiveKit Agentsではセマンティックターン検出により、単なる無音検出より自然な割り込みを実現しています。

from livekit.agents import AgentSession
from livekit.plugins import silero, openai
from livekit.agents.voice import SpeechHandle


async def entrypoint(ctx):
    await ctx.connect(auto_subscribe="audio_only")

    session = AgentSession(
        vad=silero.VAD.load(),
        stt=openai.STT(model="whisper-1", language="ja"),
        llm=openai.LLM(model="gpt-4o"),
        tts=openai.TTS(voice="alloy"),
        # セマンティックターン検出を有効化（Silero VAD + トランスフォーマーモデル）
        turn_detection="semantic",
        # 割り込みが起きた時、エージェントの応答を即座に停止する
        allow_interruptions=True,
        # 割り込みと判定するまでの最小無音時間（ms）
        min_interruption_silence_ms=300,
    )

    # 割り込みが起きた時のイベントハンドラ
    @session.on("agent_speech_interrupted")
    def on_interrupted(speech: SpeechHandle):
        # 割り込まれた発話の内容をログに記録
        logging.info(f"エージェント発話が割り込まれました: {speech.id}")

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

# 注意: min_interruption_silence_ms は環境の背景ノイズに合わせて調整してください。

ポイント:

• turn_detection="semantic" にするとトランスフォーマーモデルがターン終了を判定します。「300ms の無音」で機械的に区切るより自然な会話になります
• allow_interruptions=True がデフォルト設定です。コールセンター用途等で割り込みを禁止したい場合は False に設定します
• 割り込みが起きると、TTSの再生と進行中のLLM生成が即座に停止します

主要機能詳解｜Multimodal / VAD / Function Calling

マルチモーダル対応（映像+音声）

LiveKit Agentsは音声だけでなく映像トラックも扱えます。カメラ映像をフレームとしてLLMに渡す構成が可能です。

from livekit.agents import AgentSession
from livekit.plugins import openai

# 映像フレームをOpenAI Vision APIに渡す設定
session = AgentSession(
    vad=silero.VAD.load(),
    stt=openai.STT(),
    llm=openai.LLM(
        model="gpt-4o",
        # 映像フレームをコンテキストとしてLLMに渡す
        vision=True,
    ),
    tts=openai.TTS(),
)

# auto_subscribe をデフォルト（audio_and_video）に変更
await ctx.connect()  # auto_subscribe のデフォルトは "subscribe_all"

# 注意: 映像処理はCPU/帯域幅コストが大幅に増加します。必要でなければ audio_only を推奨します。

複数エージェントの連携（ハンドオフ）

1つの会話の中でエージェントを切り替える「ハンドオフ」機能が1.5.xで強化されています。例えば、一般対応エージェントから専門エージェントへの切り替えが以下で実装できます。

from livekit.agents import Agent, AgentSession


class GeneralAgent(Agent):
    """一般対応エージェント"""
    def __init__(self) -> None:
        super().__init__(
            instructions="一般的な問い合わせに対応してください。"
                         "技術的な質問が来たらTechAgentに転送してください。",
            handoffs=[TechAgent],  # 転送先エージェントを指定
        )


class TechAgent(Agent):
    """技術専門エージェント"""
    def __init__(self) -> None:
        super().__init__(
            instructions="技術的な問い合わせに詳しく対応してください。"
        )


# AgentSession はどちらのエージェントも扱える
session = AgentSession(...)
await session.start(ctx.room, agent=GeneralAgent())

PipecatとLiveKit Agentsの使い分け｜音声パイプライン特化 vs WebRTC統合

音声AIフレームワークを選ぶ際、最も比較されるのがPipecatとLiveKit Agentsです。当サイトにはPipecatの完全ガイドもありますが、両者の使い分けは明確です。

LiveKit Agentsを選ぶべきケース

• Webアプリ・モバイルアプリへの音声AI統合: LiveKit SDKのクライアントライブラリが豊富（React/Swift/Kotlin対応）
• 複数ユーザーが同時参加する会議型エージェント: SFUによる効率的な多人数配信が必要
• SIP/電話統合: LiveKit SIPで既存電話インフラとブリッジできる
• クラウドプラットフォームを使いたい: LiveKit CloudのマネージドSFUで運用コストを最小化

Pipecatを選ぶべきケース

• 1:1の音声アシスタント（コールセンター・カスタマーサポート）: Pipecatの方がフレームベースの細かな制御がしやすい
• 既存のメディアインフラがある: WebRTC以外の接続（WebSocket、TCP）にも柔軟に対応
• ボット向けの詳細なパイプライン制御: フレームプロセッサのカスタマイズがより細かくできる

詳しくはPipecat完全ガイドで実装例と比較を確認してください。

料金プラン｜LiveKit Cloud vs セルフホスト

LiveKit Agentsのフレームワーク自体は無料（OSS）です。コストが発生するのはLiveKit Cloudを使う場合です。

Agent Session分数の超過料金: $0.01/分（全プラン共通）

コスト試算例: 1日100セッション × 平均5分 = 月15,000分。Shipプランで5,000分が含まれ、超過10,000分 × $0.01 = $100。プラン費用$50と合わせて月$150が目安です。ただしSTT/LLM/TTSのAPIコストは別途かかります。

セルフホストが適しているケース

LiveKit SFU（Go製、オープンソース）はDockerイメージが公開されており、Kubernetes上でのデプロイが可能です。以下の条件が揃えばセルフホストがコスト効率で上回ります。

• 月間セッション数が安定して500以上ある
• Kubernetesの運用ノウハウがある（または専担エンジニアがいる）
• データ主権要件（医療・金融）でサードパーティSaaSを使えない

参考: LiveKit公式ブログ「Deploy and scale agents on LiveKit Cloud」には本番スケーリングのガイドが詳しく記載されています（参照日: 2026-04-30）。

本番運用の落とし穴5選

実際に音声AIエージェントを本番環境に出してみると、開発環境では気づかなかった問題が出てきます。よく踏むパターンを5つまとめます。

落とし穴1: VADの誤検知でレイテンシが悪化する

症状: ユーザーが話し終わっていないのにSTTが起動し、途中の文章でLLMへ投げてしまう。

原因: デフォルトのVAD設定が背景ノイズに対して敏感すぎる。

from livekit.plugins import silero

# VADの感度を調整する
vad = silero.VAD.load(
    min_silence_duration=600,       # 無音と判定するまでの時間（ms）。デフォルト400
    min_speech_duration=100,        # 音声と判定するまでの最小時間（ms）
    pre_speech_pad_ms=300,          # 音声開始前のパディング
    post_speech_pad_ms=100,         # 音声終了後のパディング
)

# 注意: オフィス環境と静かな部屋では最適値が大きく異なります。A/Bテストで調整してください。

落とし穴2: STTの言語設定ミスで精度が落ちる

症状: 日本語で話しているのに英語として認識される、または認識精度が著しく低い。

対策: STTプラグインの language パラメータを明示的に指定します。

# DeepgramのSTTで日本語を明示指定
from livekit.plugins import deepgram

stt = deepgram.STT(
    model="nova-3",
    language="ja",           # 明示的に日本語を指定
    smart_format=True,       # 句読点の自動補完
    punctuate=True,
)

# Openai Whisper の場合
from livekit.plugins import openai
stt = openai.STT(
    model="whisper-1",
    language="ja",           # ISO 639-1コードで指定
)

落とし穴3: エージェントワーカーのスケールアウトを設定しない

症状: 同時接続数が増えると新しいセッションが始まらない、または応答が極端に遅くなる。

対策: WorkerOptions でワーカー並列数を設定し、複数プロセスで負荷分散します。

from livekit.agents import WorkerOptions, cli

# ワーカーを複数並列起動する設定
options = WorkerOptions(
    entrypoint_fnc=entrypoint,
    # 1ワーカーあたりの最大同時セッション数
    max_concurrent_jobs=5,
    # ワーカープロセス数（CPUコア数に合わせる）
    num_idle_processes=2,
)

cli.run_app(options)

# 本番では PM2 / systemd / Kubernetes Deployment でプロセスを管理すること

落とし穴4: TTS音声の遅延がUXに出る

症状: LLMのレスポンスが早くても、TTSの初回チャンク受信まで500ms以上かかる。

原因: ストリーミングTTSを使っていない、またはTTSのネットワーク距離が遠い。

対策:

• Cartesia SonicはデフォルトでストリーミングTTSをサポートします（最初のチャンクが50〜100msで届く）
• LiveKit CloudのリージョンをユーザーとTTSプロバイダーに近い場所に設定する（Scale以上のプランで選択可能）
• ユーザーの応答を待つ間に「うん」「なるほど」等の短い相槌を返す「フィラー」機能を活用する

落とし穴5: セッション終了後にリソースリークが起きる

症状: 長時間稼働後にメモリ使用量が増加し続ける。再起動後は正常に戻る。

対策: セッション終了時のクリーンアップを明示的に実装します。

async def entrypoint(ctx: JobContext) -> None:
    await ctx.connect(auto_subscribe="audio_only")

    session = AgentSession(...)
    await session.start(ctx.room, agent=MyVoiceAgent())

    try:
        # セッションが終了するまで待機
        await session.wait()
    finally:
        # 必ずクリーンアップを実行する
        await session.aclose()
        logging.info("セッションクリーンアップ完了")

# 注意: 本番環境で使用する前に、必ずテスト環境でメモリ使用量を長時間監視してください。

音声AI基盤の選択肢｜LiveKit・Twilio・Vapi・Pipecatの立ち位置

音声AIエージェントを構築する際、開発者は「どの層の課題を解決したいのか」によって選ぶべき基盤が変わります。記事内ではフレームワーク同士の比較を扱いましたが、ここでは通信インフラからフルマネージドサービスまで、レイヤーの異なる選択肢を横並びで整理します。LiveKitはWebRTCベースのリアルタイム通信基盤＋エージェント実行環境という位置付けで、自前のロジックを組み込みやすい一方、電話網（PSTN）連携やフルマネージドな会話設計は別の基盤が得意とする領域です。

下表は各製品の一般的な性格をまとめたものです。具体的なレイテンシ値・料金・同時接続上限は製品改定で頻繁に変わるため記載していません。導入検討時は必ず各社の公式ドキュメントで最新の数値を確認してください。

レイヤーで考えると迷いにくい

選定で迷ったときは、「通信インフラを握りたいのか、会話ロジックを握りたいのか」という軸で整理すると判断しやすくなります。ブラウザやアプリ内でユーザーと直接つながるリアルタイム音声体験を、自社のロジックで作り込みたいならLiveKitが第一候補になります。逆に、既存の電話番号にかかってくるコールを処理したいならTwilioのような通信プラットフォームが起点になり、会話設計そのものを最短で形にしたいならVapiのようなフルマネージド型が適します。これらは排他的ではなく、「Twilioで電話を受けてLiveKitでリアルタイム処理する」といった組み合わせも実務では珍しくありません。詳細な仕様はLiveKit公式ドキュメントで確認するのが確実です。

本番リリース前チェックリスト｜レイテンシ・コスト・スケール・障害・セキュリティ

プロトタイプが動いたあと、本番運用に移す前に確認すべき観点を領域別に整理しました。記事中の「落とし穴5選」がコードレベルの個別対策だったのに対し、ここではリリース判断の前に通すべきゲートとして、運用ドメインごとにチェック項目を並べています。すべてを満たす必要はありませんが、「未確認のまま本番に出す項目」をゼロにすることが目的です。なお具体的なレイテンシ目標値やコスト上限は案件ごとに異なるため、ここでは数値を断定せず観点のみを示します。

レイテンシ最適化

• 応答遅延の実測：開発環境ではなく、想定する本番ネットワーク条件下で会話の往復遅延を計測したか。
• パイプライン構成の妥当性：カスケード構成とリアルタイムAPI構成のどちらが要件に合うか、実会話で比較したか。
• モデル・プロバイダー選定：STT/LLM/TTSの各段で、遅延と品質のトレードオフを把握したうえで選定したか。
• 割り込み処理：ユーザーが話し始めた際にエージェント発話を止める挙動が、実利用で自然に動くか。

コスト管理

• 従量課金の試算：分単位課金やプロバイダーAPI料金を、想定通話量に基づいて事前試算したか（最新単価は公式ドキュメントで要確認）。
• 上限・アラート：想定外のトラフィックでコストが暴走しないよう、利用上限やアラートを設定したか。
• セルフホストとマネージドの比較：トラフィック規模に対して、どちらが総コストで有利かを試算したか。

スケール設計

• ワーカーの並行処理：同時セッション数の増加に対し、ワーカープロセスがスケールする構成になっているか。
• 負荷試験：ピーク時の同時接続を想定した負荷試験を実施したか。
• リソース解放：セッション終了時に接続やプロセスが確実に解放され、リークが起きないか。

障害時フォールバック

• プロバイダー障害への備え：STT/LLM/TTSのいずれかが応答しない場合の代替動線や縮退運転を設計したか。
• タイムアウトと再試行：外部API呼び出しに適切なタイムアウトと再試行（無限ループ回避）を実装したか。
• ユーザー体験の劣化対応：障害時に無言で固まらず、ユーザーへ状況を伝える挙動になっているか。

セキュリティ

• 認証情報の管理：APIキーやトークンを.env等で安全に管理し、リポジトリやログに露出していないか。
• トークン発行の制御：参加トークンに適切な権限と有効期限を設定し、過剰な権限を渡していないか。
• 会話データの取り扱い：音声・文字起こしデータの保存範囲と保持期間を、プライバシー要件に沿って決めたか。
• 通信経路：クライアントとサーバー間の通信が暗号化されているか。

よくある質問（FAQ）

Q: LiveKit Agentsは日本語に対応していますか？

A: 対応しています。STTにDeepgram Nova-3（language="ja"）、TTS にCartesia Sonic-3（日本語ボイスID指定）の組み合わせが2026年7月時点での推奨構成です。OpenAI Whisperも日本語精度が高く、コスト重視なら代替になります。

Q: レイテンシの目標値はどのくらいですか？

A: ユーザーが話し終わってから最初の音声が返るまで（TTFS: Time to First Syllable）の目標値は300ms以下が「人間的に自然」とされています。LiveKit Agentsのカスケードパイプラインでは750〜900ms程度が現実的な数値です。300msを実現したい場合はOpenAI Realtime APIまたはGemini Live API統合が必要です。

Q: 電話回線（SIP）との連携はできますか？

A: 可能です。LiveKit SIPコンポーネントを使うと、一般電話回線（PSTN）とWebRTCをブリッジできます。Ship以上のプランで利用可能です。

Q: Pipecat（当サイトのガイドあり）と同じ会社ですか？

A: 別の会社です。LiveKitはLiveKit, Inc.（旧Fishjam）が開発し、PipecatはDaily.co（Daily.co, Inc.）が開発しています。アーキテクチャ設計の思想が異なり、「WebRTC統合重視のLiveKit」対「パイプライン制御重視のPipecat」と覚えると選定しやすいです。

Q: LiveKit CloudのBuildプランから始めて良いですか？

A: 開発・検証であれば十分です。月1,000分の無料枠があり、クレジットカード不要で試せます。同時セッション数が5に制限されるため、負荷テストや本番トラフィックの前にShip/Scaleプランへの移行が必要になります。

Q: セルフホストの場合、LiveKit Agentsのコードは変更が必要ですか？

A: 環境変数を変えるだけです。LIVEKIT_URL をセルフホストのSFUエンドポイントに変更すれば、コードはそのまま動きます。SFUは LiveKit Server（Go製）のDockerイメージを使います。

LiveKit Agents v0.x → v1.0 移行ガイド｜API破壊的変更と書き換えパターン

2025年4月にリリースされた LiveKit Agents 1.0（現行最新: 1.6.0 / 2026年6月11日リリース） では、v0.x系から多数の破壊的変更が入っています。「動いていたコードがそのまま動かない」パターンが多いため、変更点を網羅的に整理します。

主要クラスの対応表

出典: LiveKit公式 v0移行ガイド

サーバー起動コードの書き換え例

v0.xで最も多く書かれているパターンと、v1.0への書き換え例です。

# v0.x の書き方（現行バージョンでは動作しない）
from livekit.agents import WorkerOptions, cli

async def entrypoint(ctx):
    ...

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

# v1.0 の書き方（現行 1.6.0 対応）
from livekit.agents import AgentServer, JobContext, cli

server = AgentServer()

@server.rtc_session()
async def entrypoint(ctx: JobContext) -> None:
    ...

if __name__ == "__main__":
    cli.run_app(server)

出典: GitHub: livekit/agents examples/voice_agents/basic_agent.py

ツール（Function Calling）定義の書き換え

# v0.x の書き方
from livekit.agents import llm

class MyAgent(llm.FunctionContext):
    @llm.ai_callable(description="天気を取得する")
    async def get_weather(self, location: str) -> str:
        ...

# v1.0 の書き方
from livekit.agents import Agent, RunContext
from livekit.agents.llm import function_tool

class MyAgent(Agent):
    @function_tool
    async def get_weather(self, context: RunContext, location: str) -> str:
        """天気を取得する"""
        ...

LiveKit Agentsプラグインエコシステム完全一覧｜STT・LLM・TTS・VADの組み合わせ選択

LiveKit Agentsの最大の特徴は、STT・LLM・TTS・VADをプラグインとして差し替えられる設計です。2026年6月時点でPyPIに公開されているプラグインパッケージ（livekit-plugins-*形式）は80以上に達しています。主要なものを用途別に整理します。

プラグイン選択マトリクス

出典: PyPI LiveKit organization（82パッケージ） / PyPI livekit-agents 1.6.0

inference APIを使った抽象化（v1.0推奨パターン）

v1.0から追加された inference モジュールを使うと、プロバイダーを文字列で指定できるため、切り替えコストが下がります。

from livekit.agents import AgentSession, inference

session = AgentSession(
    stt=inference.STT("deepgram/nova-3", language="multi"),
    llm=inference.LLM("openai/gpt-4o-mini"),
    tts=inference.TTS("cartesia/sonic-3"),
)

個別プラグインを直接インスタンス化する方式も引き続き使えます（後述の「最小構成の実装サンプル」セクション参照）。

用途別の推奨プラグイン構成

レイテンシ最優先ならOpenAI Realtime API経由（カスケードパイプライン不要）、コスト優先ならDeepgram+GPT-4o-mini+OpenAI TTS-1の組み合わせが現時点での定番です。プラグイン一覧の最新情報はPyPI LiveKit organizationページで確認できます。

音声AIエージェントの比較軸については、音声AIエージェント比較2026（OpenAI・Gemini・ElevenLabs）も参照してください。

LiveKit Cloud 料金の実コスト試算｜エージェントセッション分とWebRTC分の違い

LiveKit Cloudの料金は「月額固定」ではなく、従量課金 + プランごとの無料枠で構成されます。混乱しやすいのは、課金軸が複数あり、特に「エージェントセッション分（agent session minutes）」と「WebRTC接続分（connection minutes）」が別カウントである点です。音声AIエージェントを動かすと、この2つが同時に消費されます。ここでは2026年6月時点のLiveKit Cloud公式料金をもとに、実際の月額コストを試算します。

プラン別の無料枠と従量単価（2026年6月時点）

※ 上記はLiveKit Cloudのインフラ利用料です。STT・LLM・TTSを外部プロバイダ（OpenAI・Deepgram・Cartesia等）で動かす場合、それらのAPI利用料は別途プロバイダ側に発生します。LiveKitの料金 ≠ 音声AIの総コスト、という点に注意してください。

「通話1分」が消費するリソースの内訳

1人のユーザーが音声AIエージェントと1分間会話したとき、LiveKit Cloud側で消費されるのは大きく以下の3つです。

• エージェントセッション分：エージェント（バックエンドのワーカー）がルームに接続している時間。1セッション1分で1分消費。
• WebRTC接続分（connection minutes）：ルームに参加している各参加者の接続時間。ユーザー1人 + エージェント1人 = 接続2人なら、1分の通話で合計2接続分を消費します。
• 下り転送量（downstream data transfer）：サーバーから各参加者へ送信される音声・映像データ量（GB）。音声のみなら小さく、映像を含むと大きくなります。

月間コストの試算例（Shipプラン・音声のみ）

仮に「1日100通話 × 平均5分」の音声サポートをShipプラン（$50/月〜）で運用するケースを試算します。月間通話 = 100 × 30 = 3,000通話、通話分 = 3,000 × 5 = 15,000通話分。

この規模ではLiveKit側の超過料金はエージェントセッション分の$100程度に収まり、月額は「$50（基本）+ $100（超過）= 約$150」が目安になります。ただし前述の通り、STT・LLM・TTSのAPI料金は別建てで、実運用ではこちらの方が大きくなるケースが多い点に注意してください。映像（カメラ）を扱う場合は下り転送量が跳ね上がり、転送量課金が支配的になります。

マネージドサービス（Vapi等）との料金思想の違い

VapiやBlandのような「音声AIマネージド型」は、STT・LLM・TTS・電話網まで込みの分単価で課金するのが一般的です。一方LiveKitはインフラ（WebRTC基盤）と推論プロバイダを分離する設計なので、プロバイダを自分で選んで最適化できる反面、コスト計算が「LiveKit料金 + 各API料金」と多層になります。各音声AIプラットフォームの料金・機能の比較は、音声AIエージェント比較2026（OpenAI・Gemini・ElevenLabs）もあわせて参照してください。

WebRTC音声基盤の仕組みと電話（SIP）連携｜なぜ音声AIにWebRTCなのか

LiveKit Agentsが「音声AIに強い」と言われる理由は、通信基盤にWebRTCを採用している点にあります。公式ドキュメントでも構成は明確で、「フロントエンドとエージェントの間はLiveKit WebRTC、エージェントとバックエンドの間はHTTPとWebSocket」と定義されています。ここでは、なぜ音声AIでWebRTCが効くのか、そして電話（SIP）との連携はどう実現するのかを整理します。

WebRTC と WebSocket の役割分担

音声会話では「遅延」と「途切れ」が体験を直接左右します。WebRTCはもともとリアルタイム通信のために設計されており、ネットワーク品質が変動しても音声を破綻させにくい仕組み（適応的なビットレート制御やパケットロス補償）を持っています。テキストチャット向けのWebSocketだけで音声を流すより、WebRTCをメディア路に使う方が、通話品質の面で有利になります。

電話（SIP）連携の仕組み

「Webブラウザだけでなく、普通の電話番号でAIに発着信したい」というニーズには、LiveKitのSIP連携で対応します。WebRTCで構築した音声AIを、SIP（Session Initiation Protocol）経由で電話網につなぐ構成です。公式ドキュメントで定義されている主要コンポーネントは以下の通りです。

トランスポートは SIP over UDP / SIP over TCP / SIP over TLS をサポートし、DTMF（プッシュ操作）やコール転送（cold / warm transfer）、SRTP（暗号化されたメディア）にも対応します。つまり、WebRTCで作った音声AIエージェントを、そのままコールセンターの電話受付や自動アウトバウンドコールに転用できるのがLiveKitの強みです。

SIP連携でハマりやすいポイント

• トランクの方向：着信（Inbound）と発信（Outbound）でトランク設定が別。発信だけ設定して着信が来ない、という取り違えが起きやすい。
• Dispatch rulesの未設定：着信トランクはあるのにディスパッチルールが無いと、着信がどのルーム（=どのエージェント）にも届かない。
• 料金の二重発生：SIP経由でもLiveKit側のWebRTC接続分・エージェントセッション分は消費される。電話網側（SIPプロバイダ）の通話料と、LiveKit側のインフラ料金は別々に発生する点を見落としやすい。

SIPを含む音声パイプライン全体の設計思想は、フレームワークによって考え方が異なります。OpenAI系のリアルタイム音声 + SIP構成との比較は、OpenAI Agents SDK 音声パイプライン・Realtime・SIP実装ガイドもあわせて確認すると、設計の引き出しが増えます。

まとめ：今日から始める3つのアクション

1. 今日やること: pip install livekit-agents livekit-plugins-openai livekit-plugins-silero を実行し、最小構成サンプルをローカルで動かす。OpenAI APIキーがあればDeepgramなしでも試せます（OpenAI STT+LLM+TTSで一本化）
2. 今週中: 自分のユースケースに合わせてLLMの instructions を書き、社内でデモを実施する。Function callingで既存APIと繋いだプロトタイプを1本完成させる
3. 今月中: LiveKit CloudのShipプランで本番環境にデプロイし、実際のユーザーにフィードバックをもらう。VADとターン検出の設定を実環境で最適化する

あわせて読みたい:

• Pipecat完全ガイド｜音声AIエージェント実装 — フレームベースのパイプライン制御を詳しく解説。LiveKitと迷ったらまずこちらと読み比べを
• AIエージェント完全ガイド｜設計から本番運用まで — エージェント設計の全体像を把握したい方へ

参考・出典

• LiveKit Agents 公式ドキュメント — LiveKit, Inc.（参照日: 2026-04-30）
• LiveKit Pricing — LiveKit, Inc.（参照日: 2026-04-30）
• Build Your First AI Voice Agent in Python — LiveKit Blog（参照日: 2026-04-30）
• Choosing a Voice AI Agent Production Framework — WebRTC.ventures（参照日: 2026-04-30）
• Deploy and scale agents on LiveKit Cloud — LiveKit Blog（参照日: 2026-04-30）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。SoftBank IT連載7回執筆。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

📚 公式リファレンス・出典

• OpenAI Agents SDK
• Anthropic Claude Tool Use Guide
• 総務省 情報通信白書 AI/DX 章
• 経済産業省 AI関連政策