LiveKit（WebRTC音声・映像のリアルタイム通信基盤）とDeepgram（音声認識API）、LLM（大規模言語モデル）を組み合わせて、面接や商談などをリアルタイムに分析するパイプラインを検討しているインフラ・SRE担当者に向けた内容です。
この手のシステムは、録音してから後処理する非同期型のバッチ処理とは監視要件がまるで違います。数十秒ごとにスコアが更新され続けるダッシュボードを、障害なく動かし続けられるかどうかを判断する軸を整理します。
AI面接分析プラットフォームの構成例では、音声ストリームがLiveKit経由でDeepgramに渡され、文字起こしのチャンク（数十秒単位の断片）ごとにLLM（この例ではxAIのGrokモデル）がスコアリングし、Supabase Realtime（データベース変更をWebSocketで配信する仕組み）でダッシュボードに反映される、という5つのサービスが一方向に連なる構成が使われています。ポーリング（定期的に問い合わせて確認する方式）を使わない設計です。
この構成をそのまま自社に持ち込むべきか、それとも簡素化すべきか。判断のための軸を4つ整理します。
判断軸1: レイテンシ要件はどこまで厳しいか
最初に確認すべきは「結果が何秒遅れたら価値がなくなるか」です。
面接分析の例では、チャンクごとのスコアが30〜60秒ごとに更新される設計になっています。これは「面接終了後にレポートを待つ」体験と、「面接中にリアルタイムで兆候が見える」体験の違いを作るための数字です。
一方、日次バッチでレポートを作る用途であれば、そもそもWebRTCやストリーミングSTT（Speech-to-Text、音声をテキスト化する技術）は過剰です。ファイルアップロード後に非同期でLLMに投げるだけで十分なケースは珍しくありません。
レイテンシ許容度が秒単位で必要なのか、分単位で十分なのかを最初に切り分けることが、アーキテクチャ選定の出発点になります。
判断軸2: 障害時に「沈黙」と「誤警報」のどちらが致命的か
リアルタイムパイプラインで見落とされがちなのが、LLMの出力パース失敗時のフォールバック設計です。
実装例では、LLMの応答からJSONを抽出する処理で、マークダウンのコードフェンスや説明文、推論モデル特有の思考過程ブロックが混入するケースに対応しています。正規表現で複数の{...}ブロックを抽出し、後ろから順にJSON.parseを試みる、という実装です。最初のブロックではなく最後のブロックから試す理由は、説明文が先に出力され、実際の構造化データは末尾に来ることが多いためです。
重要なのは、パース失敗時の挙動です。この設計ではスコアをゼロにするのではなく、中間値（25点満点中15点など）にフォールバックしています。ゼロにすると面接官のダッシュボードに「異常値」として映り、誤った警報になってしまうためです。
これは監視設計の一般原則にも通じます。ゼロやNullを返すシステムは「壊れている」ことがひと目でわかる代わりに、業務を止めてしまいます。中間値を返すシステムは業務を止めない代わりに、障害が静かに進行するリスクを抱えます。
自社のユースケースで、どちらのリスクが許容できるかを事前に決めておく必要があります。金融の不正検知のように誤検知が致命的な領域では沈黙優先、面接官の体験を優先する領域では中間値優先、といった判断になります。
判断軸3: 監視すべき対象はどこにあるか
この構成は5つのサービスが直列につながっています。LiveKitの接続断、Deepgramの認識精度低下、LLM APIのレイテンシ増加やレート制限、Supabase Edge Functions（Denoランタイム上で動くサーバーレス関数）のコールドスタート、Supabase Realtimeの配信遅延。障害点は単一ではなく5箇所に分散します。
オンプレの録画・後処理バッチと違い、どこか1箇所が詰まるとパイプライン全体が体感遅延として面接官に露出します。監視設計としては、各サービス境界でのレイテンシと成功率を個別に計測する必要があります。
具体的には、以下のような指標を各段階で取ることが最低ラインになります。
- LiveKitのWebRTC接続の切断率・再接続回数
- Deepgramからチャンクが届く間隔のばらつき（ジッター）
- LLM呼び出しのレスポンスタイム分布（p50/p95/p99）
- Edge Functionのコールドスタート発生率
- Realtimeの配信からダッシュボード反映までの遅延
これらをAPM（Application Performance Monitoring）ツールで横断的に可視化できないと、障害発生時に「どこで詰まったか」を切り分けるのに時間がかかります。
判断軸4: 運用コストとモデル選定のトレードオフ
チャンクごとのスコアリングにはgrok-3-fastのような、推論（reasoning）を行わない軽量モデルが使われています。推論モデルは精度が上がる代わりにレイテンシが伸びるため、30〜60秒ごとの逐次処理には不向きという判断です。
一方、面接終了後の最終レポート生成では、全チャンクのデータを統合してより重いモデルで合成する、という役割分担になっています。リアルタイム処理と最終処理でモデルを使い分けることが、コストとレイテンシのバランスを取る鍵になります。
同じモデルをすべての処理に使うと、チャンク処理の呼び出し回数が多い分だけAPIコストが跳ね上がります。1回の面接で数十回のLLM呼び出しが発生する設計であれば、軽量モデルとの組み合わせは運用コストの観点でも妥当な選択です。
| 比較軸 | マイクロサービス型5段構成 | バッチ処理・単純構成 |
|---|---|---|
| レイテンシ | 数十秒単位で逐次更新 | 処理完了まで数分〜数十分 |
| 障害点の数 | 5サービス分散、切り分けに監視設計が必須 | 1〜2箇所に集約、原因特定が容易 |
| 運用コスト | LLM呼び出し回数が多く、モデル使い分けが前提 | 呼び出し回数が少なく単純 |
| 適するユースケース | ライブ配信・面接・商談などその場での意思決定支援 | 日次レポート・事後監査・非同期レビュー |
ケース別の推奨
面接官やオペレーターが「その場で」意思決定に使う情報であれば、チャンク分割型のリアルタイム構成を選ぶ理由があります。逆に、翌朝にレポートを確認すれば足りる業務であれば、ストリーミング構成を導入する必然性は乏しいです。
また、既存のオンプレ録音システムからクラウド移行を検討している場合、いきなり5段構成のリアルタイムパイプラインに全面移行するのはリスクが高くなります。まずは録音ファイルをクラウドストレージにアップロードし、非同期でLLM分析する構成から始め、レイテンシ要件が明確になった段階でストリーミング化する、という段階移行が現実的です。
あえて見送るべき条件
以下に該当する場合は、リアルタイム構成の導入を見送るか延期する判断が妥当です。
- 監視対象のサービス境界を横断的に可視化するAPM基盤がまだ整っていない
- LLM呼び出しのレート制限やコスト上限について運用ルールが決まっていない
- 障害時のフォールバック挙動（沈黙か中間値か）について合意が取れていない
- チームにDeno・Edge Functionsのようなサーバーレス実行環境の運用経験が少ない
これらが未整備のままリアルタイム構成を本番投入すると、障害発生時に「どこが原因か分からない」状態に陥りやすくなります。まずは非同期バッチで安定運用の実績を積んでから、段階的にリアルタイム化する方が結果的に近道になります。
まとめ
リアルタイムAIパイプラインの導入判断は、レイテンシ要件・障害時の挙動設計・監視対象の分散・モデル選定コストの4軸で整理できます。
まず自社のユースケースで「何秒の遅延なら許容できるか」を明文化し、次にLLMのパース失敗時にゼロ返却と中間値返却のどちらを選ぶかをチームで合意してください。そのうえで、各サービス境界のレイテンシ計測をAPMで先に整備してから、段階的にストリーミング構成へ移行するのが安全な進め方です。