site iconKoei's Digital Garden

Archive

Forwarding to the frontend (RPC)

4 min read

Forwarding to the frontend (RPC)

参照元: LiveKit Agents Documentation ロードマップ: 学習ロードマップ

追加参照（公式）:

What（何についてか）

LLMのfunction tool呼び出しを、LiveKitのRPC機能を使ってフロントエンドへ転送し、フロント側で実データ取得やUI操作を実行するパターンを扱う。典型例はブラウザだけが取得できる位置情報（latitude/longitude）で、AgentはRPCの呼び出し元として振る舞う。

Why（なぜ必要か）

音声エージェントが必要とする情報の一部は、サーバー側では取得できない。たとえばブラウザのGeolocation APIやフロントのローカルUI状態は、クライアント参加者が最も近い取得点になる。toolをRPCへ転送することで、Agentの会話制御は維持しつつ、データ取得責務を適切な実行主体へ委譲できる。

How（どう動くか）

基本フローは、Agent側のtoolをRPCアダプタとして実装し、Frontend側のRPCハンドラに処理を委譲する構成になる。

sequenceDiagram
    participant User as User
    participant LLM as Agent(LLM)
    participant A as Agent Tool
    participant F as Frontend RPC Handler

    User->>LLM: 「現在地で近くの店を探して」
    LLM->>A: get_user_location()
    A->>F: performRpc(method="get_user_location")
    F-->>A: {"latitude":..., "longitude":...}
    A-->>LLM: structured tool result
    LLM-->>User: 位置情報を使った応答

Agent implementation の責務

Agent側は「処理実行者」ではなく「転送アダプタ」として実装する。

  • function tool内で performRpc を呼ぶ
  • 宛先participant identity・method名・payloadを指定する
  • 返却文字列（多くはJSON）を検証し、必要なら正規化してLLMへ返す

このとき、文字列をそのまま返すより、Agent側でJSONパースとバリデーションを行ってから構造化データとして返した方が安定する。

Frontend implementation の責務

Frontend側はRPCの受け口として method handler を登録する。

  • Agent側と一致するmethod名で登録
  • ブラウザAPIやUI状態からデータを取得
  • 文字列payload（通常JSON文字列）として返却

RPCは文字列payloadで動作し、サイズ上限・タイムアウト・エラーコード体系があるため、レスポンス設計は小さく明確に保つ。

実装上の注意

  • hidden participant はRPCを呼べない
  • performRpc はタイムアウトを持つ（デフォルト10秒）
  • 失敗時はLiveKit定義のRPCエラー、またはアプリ側エラーで返る
  • 位置情報などの機微データは、必要最小限の精度・項目で返す

Key Concepts

用語説明
Forwarding tool callLLMのtool呼び出しをRPC経由でフロントへ委譲する設計。
performRpc参加者間でリモートメソッドを呼ぶLiveKit API。
RPC method handlerFrontend側で登録する受け口。実データ取得やUI更新を担う。
PayloadRPCの入出力文字列。一般的にはJSON文字列を使う。
Adapter patternAgent toolをRPC呼び出しに変換する責務分離パターン。

一言まとめ

Forwarding to the frontendは、Agentが会話と推論を担い、Frontendがローカルデータ取得やUI操作を担うための責務分離パターンであり、performRpc を境界としてtool実行を安全に委譲する設計である。

Graph View

Backlinks