オーディオストリーミングを理解する

ビデオをストリーミングするときは、ファイルをダウンロードしています。サーバーはバイトを送信し、プレーヤーは再生に十分な量が届くまでそれをバッファリングします。オーディオ生成のストリーミングは根本的に異なります。ストリーミング開始時点では、まだオーディオが存在しないためです。モデルがリアルタイムで合成し、ストリーミングされるバイトはその合成プロセスのライブ出力です。

この違いは、レイテンシー、バッファリング、障害モードの考え方を変えるため重要です。

ストリーミングエンドポイントの呼び出し時に起こること

ElevenLabsのストリーミングTTSエンドポイントを呼び出すと、次の順序で処理が行われます：

リクエストがサーバーに到着します。
モデルが音声の合成を開始します。
オーディオが生成されると、サーバーは段階的に送信します。通常は数キロバイトごとのチャンクです。
クライアントは各チャンクを受信し、到着次第再生します。

重要なのはステップ3です。サーバーは、オーディオファイル全体の準備が完了するまで待ってから送信するのではありません。この点が、合成が完了するまでオーディオを一切返さない標準エンドポイントとの根本的な違いです。

ストリーミングが最初のオーディオまでの時間を短縮する理由

標準エンドポイントでは、最初のオーディオまでの時間はテキスト全体の合成に必要な時間と同じです。短い文なら500ms程度ですが、段落では数秒かかる場合があります。

ストリーミングでは、最初のオーディオまでの時間は、おおむね最初のオーディオチャンクの合成に必要な時間です。通常は最初の数百ミリ秒分の音声です。それ以降は、後続のチャンクが並行して生成される間に再生されます。

このため、リアルタイムアプリケーションではストリーミングが不可欠です。生成全体に時間がかかる場合でも、ユーザーは1秒未満で音声を聞けます。

2つのストリーミングプロトコル

ElevenLabsは2つのストリーミング方式をサポートしており、それぞれ異なるユースケースに対応します。

HTTPストリーミング（server-sent events）は、よりシンプルな方式です。テキスト全体をあらかじめ送信すると、サーバーは生成されたオーディオをストリーミングで返します。開始前にすべてのテキストがある場合に適しています。たとえば、事前に作成したスクリプトや、すぐに再生したい完全なLLMレスポンスなどです。

WebSocketストリーミングでは、双方向通信が可能です。テキストを単語ごと、または文ごとに増分送信でき、モデルは入力全体が利用可能になる前に生成を開始します。これにより、エンドツーエンドで低レイテンシーな音声パイプラインが実現します。LLMがトークンを生成し、到着するたびにTTS WebSocketへ転送すると、LLMがレスポンスを完了する前からオーディオの再生を開始できます。

WebSocket方式はより複雑です。モデルはオーディオ生成を確定するタイミングを判断する必要があります。早すぎるとフレーズ境界で不自然な韻律になる可能性があり、遅すぎるとレイテンシーが悪化します。これはチャンクスケジュールとauto_mode設定で制御され、ほとんどのユースケースではこのトレードオフを自動的に処理します。

チャンクサイズがレイテンシーと自然さの両方に影響する理由

ストリーミングオーディオ生成には、チャンクサイズと発話の自然さの関係という根本的な緊張関係があります。

音声合成モデルは、コンテキストを確認できるほど有利です。ある単語の前後に何があるかを把握することで、モデルは自然な韻律を生成できます。「The economy」からオーディオを生成するモデルでは、文末が「is recovering」なのか「is in freefall.」なのかによって、韻律に関する考慮事項が大きく異なります。

モデルが十分なテキストを確認する前にオーディオを確定すると、フレーズ境界で不自然に聞こえる発話になるおそれがあります。技術的には正しくても、やや機械的に聞こえます。より多くのコンテキストを待てば自然さは向上しますが、レイテンシーも増加します。

ElevenLabsのauto_modeは、入力テキストを分析して適切なバランスを自動的に見つけようとします。ほとんどのアプリケーションで良好な結果が得られます。たとえば、低レイテンシーのためなら多少自然さが低い韻律を許容できる音声エージェントなど、より細かな制御が必要な場合は、チャンクスケジュールを直接設定できます。

ストリーミングレイテンシーと生成レイテンシー

この2つは混同しやすいですが、異なる数値です。

生成レイテンシーは、モデルがオーディオを生成するまでにかかる時間です。~75msのFlashモデルという数値はこれを指し、ネットワークの往復時間やアプリケーションのオーバーヘッドを除いた、短いテキスト入力に対するモデルの推論時間です。

最初のオーディオまでの時間は、アプリケーションがリクエストを開始してから、最初のオーディオサンプルがエンドユーザーに実際に再生されるまでの経過時間です。ネットワークレイテンシー、サーバー処理時間、オーディオプレーヤーによるバッファリングが含まれます。

実際には、最初のオーディオまでの時間は、モデルの生のレイテンシーだけより大幅に長くなることがあります。ネットワークの往復には、地理的な距離に応じて50〜200msが加わります。オーディオプレーヤーのバッファもさらに時間を加えます。この違いを理解すれば、現実的な期待値を設定し、パフォーマンスの問題を診断できます。最初のオーディオまでの時間が長い場合、ボトルネックは通常、モデルのパフォーマンスではなくネットワークまたはアプリケーションのバッファリングです。

よくある誤解

「ストリーミングエンドポイントはデータを増分送信するため遅い。」 いいえ、ユーザーはより早くオーディオを聞けるため高速です。生成全体にかかる時間は同程度ですが、変わるのはデータが到着し始めるタイミングです。

「ストリーミングにはWebSocketが必要。」 必ずしもそうではありません。HTTPストリーミングエンドポイントは、ほとんどのユースケースに適しています。WebSocketが特に有用なのは、テキストとオーディオを同時に生成する場合です。たとえば、LLMが生成したテキストを直接オーディオ生成に渡す場合です。

「高品質のオーディオ形式はストリーミングレイテンシーを大幅に増加させる。」 これは大半が誇張です。レイテンシーに最も大きく寄与するのは、モデルの推論時間とネットワークの往復時間です。より高ビットレートの出力形式によるオーバーヘッドは控えめで、大きな要因に対処する前に最適化する価値はほとんどありません。