モデル

主力モデル

テキスト読み上げ

スピーチtoテキスト

音楽

モデル概要

ElevenLabs APIでは、さまざまなユースケース、品質レベル、パフォーマンス要件に最適化された幅広いオーディオモデルを提供しています。

非推奨モデル

Eleven v3

Eleven v3は、最新かつ最も高度な音声合成モデルです。複数の言語で、高い感情表現と文脈理解を備えた自然で生き生きとした音声を生成する最先端モデルです。

このモデルは、次のようなシナリオに適しています：

• キャラクター同士の会話：複数のキャラクターが相互にやり取りするオーディオ体験に最適です。
• オーディオブック制作：複雑な感情表現を含む長編ナレーションに最適です。
• 感情豊かな対話：高い感情表現と文脈理解を備えた、自然で生き生きとした対話を生成します。

Eleven v3では、新しいText to Dialogue APIを利用できます。これにより、複数の言語で高い感情表現と文脈理解を備えた、自然で生き生きとした対話を生成できます。Eleven v3は、テキスト読み上げAPIと組み合わせて使用することで、複数の言語で高い感情表現と文脈理解を備えた、自然で生き生きとした音声を生成することもできます。

Text to Dialogue APIの詳細はこちら。

対応言語

Eleven v3モデルは、以下を含む70以上の言語に対応しています。

アフリカーンス語（afr）、アラビア語（ara）、アルメニア語（hye）、アッサム語（asm）、アゼルバイジャン語（aze）、ベラルーシ語（bel）、ベンガル語（ben）、ボスニア語（bos）、ブルガリア語（bul）、カタロニア語（cat）、セブアノ語（ceb）、チェワ語（nya）、クロアチア語（hrv）、チェコ語（ces）、デンマーク語（dan）、オランダ語（nld）、英語（eng）、エストニア語（est）、フィリピノ語（fil）、フィンランド語（fin）、フランス語（fra）、ガリシア語（glg）、ジョージア語（kat）、ドイツ語（deu）、ギリシャ語（ell）、グジャラート語（guj）、ハウサ語（hau）、ヘブライ語（heb）、ヒンディー語（hin）、ハンガリー語（hun）、アイスランド語（isl）、インドネシア語（ind）、アイルランド語（gle）、イタリア語（ita）、日本語（jpn）、ジャワ語（jav）、カンナダ語（kan）、カザフ語（kaz）、キルギス語（kir）、韓国語（kor）、ラトビア語（lav）、リンガラ語（lin）、リトアニア語（lit）、ルクセンブルク語（ltz）、マケドニア語（mkd）、マレー語（msa）、マラヤーラム語（mal）、中国語（標準語）（cmn）、マラーティー語（mar）、ネパール語（nep）、ノルウェー語（nor）、パシュトー語（pus）、ペルシア語（fas）、ポーランド語（pol）、ポルトガル語（por）、パンジャブ語（pan）、ルーマニア語（ron）、ロシア語（rus）、セルビア語（srp）、シンド語（snd）、スロバキア語（slk）、スロベニア語（slv）、ソマリ語（som）、スペイン語（spa）、スワヒリ語（swa）、スウェーデン語（swe）、タミル語（tam）、テルグ語（tel）、タイ語（tha）、トルコ語（tur）、ウクライナ語（ukr）、ウルドゥー語（urd）、ベトナム語（vie）、ウェールズ語（cym）。

Eleven v3 Conversational

Eleven v3 Conversationalは、リアルタイム音声合成向けの最も表現力豊かなモデルです。複数の言語で、高い感情表現と文脈理解を備えた自然で生き生きとした音声を生成する最先端モデルです。

このモデルは、次のようなシナリオに適しています：

• サポートエージェント：顧客からの問い合わせをリアルタイムで解決する音声エージェントを実現します。
• AIアシスタント：高い感情表現と文脈理解を備えた、自然で生き生きとした対話を生成します。
• インタラクティブキャラクター：表現力豊かなキャラクターによるオーディオ体験に最適です。

Eleven v3 Conversationalでは、新しいText to Dialogue WebSocketを利用できます。これにより、複数の言語で高い感情表現と文脈理解を備えた、自然で生き生きとした対話を生成できます。

Text to Dialogue WebSocketの詳細はこちら。

対応言語

Eleven v3モデルは、以下を含む70以上の言語に対応しています。

アフリカーンス語（afr）、アラビア語（ara）、アルメニア語（hye）、アッサム語（asm）、アゼルバイジャン語（aze）、ベラルーシ語（bel）、ベンガル語（ben）、ボスニア語（bos）、ブルガリア語（bul）、カタロニア語（cat）、セブアノ語（ceb）、チェワ語（nya）、クロアチア語（hrv）、チェコ語（ces）、デンマーク語（dan）、オランダ語（nld）、英語（eng）、エストニア語（est）、フィリピノ語（fil）、フィンランド語（fin）、フランス語（fra）、ガリシア語（glg）、ジョージア語（kat）、ドイツ語（deu）、ギリシャ語（ell）、グジャラート語（guj）、ハウサ語（hau）、ヘブライ語（heb）、ヒンディー語（hin）、ハンガリー語（hun）、アイスランド語（isl）、インドネシア語（ind）、アイルランド語（gle）、イタリア語（ita）、日本語（jpn）、ジャワ語（jav）、カンナダ語（kan）、カザフ語（kaz）、キルギス語（kir）、韓国語（kor）、ラトビア語（lav）、リンガラ語（lin）、リトアニア語（lit）、ルクセンブルク語（ltz）、マケドニア語（mkd）、マレー語（msa）、マラヤーラム語（mal）、中国語（標準語）（cmn）、マラーティー語（mar）、ネパール語（nep）、ノルウェー語（nor）、パシュトー語（pus）、ペルシア語（fas）、ポーランド語（pol）、ポルトガル語（por）、パンジャブ語（pan）、ルーマニア語（ron）、ロシア語（rus）、セルビア語（srp）、シンド語（snd）、スロバキア語（slk）、スロベニア語（slv）、ソマリ語（som）、スペイン語（spa）、スワヒリ語（swa）、スウェーデン語（swe）、タミル語（tam）、テルグ語（tel）、タイ語（tha）、トルコ語（tur）、ウクライナ語（ukr）、ウルドゥー語（urd）、ベトナム語（vie）、ウェールズ語（cym）。

Multilingual v2

Eleven Multilingual v2は、最も高度で感情を理解する音声合成モデルです。複数の言語で、高い感情表現と文脈理解を備えた自然で生き生きとした音声を生成します。

話者固有の特徴やアクセントを維持しながら、対応するすべての言語で一貫した音声品質と個性を提供します。

このモデルは、高品質で感情のニュアンスに富んだ音声が必要なシナリオで優れています：

• キャラクターボイスオーバー：感情表現の幅が広く、ゲームやアニメーションに最適です。
• プロフェッショナルコンテンツ：企業ビデオやeラーニング教材に適しています。
• 多言語プロジェクト：言語を切り替えても一貫した音声品質を維持します。
• 安定した品質：一貫して高品質なオーディオ出力を生成します。

Flashモデルよりもレイテンシと1文字あたりのコストは高くなりますが、自然な音声が重要なプロジェクトでは優れた品質を提供します。

Multilingual v2モデルは、29言語に対応しています。

英語（米国、英国、オーストラリア、カナダ）、日本語、中国語、ドイツ語、ヒンディー語、フランス語（フランス、カナダ）、韓国語、ポルトガル語（ブラジル、ポルトガル）、イタリア語、スペイン語（スペイン、メキシコ）、インドネシア語、オランダ語、トルコ語、フィリピン語、ポーランド語、スウェーデン語、ブルガリア語、ルーマニア語、アラビア語（サウジアラビア、アラブ首長国連邦）、チェコ語、ギリシャ語、フィンランド語、クロアチア語、マレー語、スロバキア語、デンマーク語、タミル語、ウクライナ語、ロシア語。

Flash v2.5

Eleven Flash v2.5は、リアルタイムアプリケーションおよびAgents Platform向けに設計された、最速の音声合成モデルです。32言語で、超低レイテンシ（約75ms†）の高品質な音声を提供します。

速度と品質のバランスに優れ、自然な出力と、言語をまたいで一貫した音声特性を維持しながら、インタラクティブなアプリケーションに最適です。

このモデルは、特に以下に適しています：

• Agents Platform：リアルタイム音声エージェントやチャットボットに最適です。
• インタラクティブアプリケーション：即時応答が必要なゲームやアプリケーションに最適です。
• 大規模処理：大量のテキスト読み上げ変換を効率的に行えます。

API生成の低価格と75msのレイテンシにより、Flash v2.5は、複数の言語で高速かつ信頼性の高い音声合成を必要とするすべての人にとって、コスト効率の高い選択肢です。

Flash v2.5は、v2モデルのすべての言語に加え、以下を含む32言語に対応しています。

ハンガリー語、ノルウェー語、ベトナム語

考慮事項

モデル選択ガイド

要件やユースケースに最適なモデルについては、モデル選択ガイドをご覧ください。

文字数制限

1回のテキスト読み上げリクエストでサポートされる最大文字数は、モデルによって異なります。

Scribe v2

Scribe v2は、90以上の言語で正確な文字起こしを行うために設計された、最先端の音声認識モデルです。単語レベルの正確なタイムスタンプに加え、話者ダイアライゼーションや動的オーディオタグ付けなどの高度な機能を提供します。

このモデルは、正確なスピーチtoテキスト変換が必要なシナリオで優れた性能を発揮します。

• 文字起こしサービス：オーディオ／ビデオコンテンツのテキスト化に最適
• 会議の記録：会話の記録と文書化に最適
• コンテンツ分析：オーディオコンテンツの処理・分析に適しています
• 多言語認識：90以上の言語で正確な文字起こしに対応

主な機能：

• 単語レベルのタイムスタンプを含む正確な文字起こし
• 複数話者オーディオ向けの話者ダイアライゼーション
• 文脈をより豊かにする動的オーディオタグ付け
• 90以上の言語に対応
• エンティティ検出
• キータームプロンプト
• 文字起こしの編集

Scribe v2の詳細はこちらをご覧ください。

Scribe v2 Realtime

Scribe v2 Realtimeは、最速かつ最も正確なライブ音声認識モデルです。超低レイテンシーの150msで、90以上の言語において最先端の精度を実現します。

このモデルは会話型のユースケースで優れた性能を発揮します。

• ライブ会議の文字起こし：リアルタイム文字起こしに最適
• AIエージェント：ライブ会話に最適
• 多言語認識：自動言語認識により、90以上の言語で正確な文字起こしに対応

主な機能：

• 超低レイテンシー：約150ミリ秒で部分的な文字起こしを取得
• ストリーミング対応：オーディオをチャンクで送信しながら、リアルタイムで文字起こしを受信
• 複数のオーディオ形式：PCM（8kHz～48kHz）とμ-lawエンコーディングに対応
• Voice Activity Detection（VAD）：無音検出に基づく自動音声セグメンテーション
• 手動コミット制御：文字起こしセグメントを確定するタイミングを完全に制御
• エンティティ検出
• 文字起こしの編集

Scribe v2 Realtimeの詳細はこちらをご覧ください。

Scribe v2 Medical

Scribe v2 Medicalは、医療・臨床オーディオに特化したバッチ音声認識モデルです。Scribe v2を微調整したモデルで、日常会話におけるScribe v2と同等の精度を維持しながら、薬剤名、解剖学、病理学、臨床ディクテーションの認識精度を向上させます。Scribe v2と同じスピーチtoテキストAPIを使用し、料金も同一です。model_idとしてscribe_v2_medicalを指定してください。

このモデルは、以下の用途に適しています。

• 臨床文書作成：会話の途中で医療用語が出てくるアンビエント診療や記録
• ディクテーション：薬剤名、用量、所見が密集して含まれる音声
• 受付・連携通話：患者自身が症状を説明する、電話で行われることが多い通話
• コンプライアンスワークフロー：PHIカテゴリにはエンティティ検出と組み合わせて使用

主な機能：

• Scribe v2と同じリクエスト形式（keyterms、entity_detection、no_verbatim、ダイアライゼーション、タイムスタンプ）
• 薬剤名、解剖学用語、病理学用語の認識精度向上
• Scribe v2と比較して日常会話の精度低下なし
• 90以上の言語に対応
• 複数話者オーディオ向けの話者ダイアライゼーション
• 動的オーディオタグ付け
• PHIカテゴリを含むエンティティ検出

Scribe v2 Medicalはバッチモデルです。ライブ文字起こしには、Scribe v2 Realtimeを使用してください。

Scribe v2 MedicalはHIPAAの対象であり、エンタープライズのお客様にはBusiness Associate Agreement（BAA）とZero Retention Mode（ZRM）が提供されます。ZRMを有効にすると、各リクエストの完了直後にオーディオ入力とテキスト出力が削除されます。ElevenLabsは何も保持せず、アプリケーションは完全なAPIレスポンスを受け取り、独自の管理下で文字起こしを保持します。

スピーチtoテキストの詳細はこちらをご覧ください。

Elevenミュージック

Elevenミュージックは、スタジオ品質の音楽生成モデルです。自然言語プロンプトを使って、あらゆるスタイルの音楽を生成できます。

このモデルは、次のようなシナリオに最適です。

• ゲームサウンドトラック：ゲーム向けの没入感あるサウンドトラックを作成
• ポッドキャストのBGM：プロフェッショナルな音楽でポッドキャストを強化
• マーケティング：広告リールにBGMを追加

主な機能：

• ジャンル、スタイル、構成を完全にコントロール
• ボーカルあり、またはインストゥルメンタルのみ
• 英語、スペイン語、ドイツ語、日本語などを含む多言語対応
• 個別のセクションまたは曲全体のサウンドと歌詞を編集

Elevenミュージックの詳細はこちらをご覧ください。

同時実行数と優先度

サブスクリプションプランによって、同時に処理できるリクエスト数と、キュー内でのリクエストの優先度が決まります。 スピーチtoテキストには、引き上げられた同時実行数の上限が適用されます。 同時実行数の上限に達すると、後続のリクエストは優先度の低いリクエストとともにキューで処理されます。 通常、これによるレイテンシーの増加は約50msにとどまります。

レスポンスヘッダーにはcurrent-concurrent-requestsとmaximum-concurrent-requestsが含まれており、同時実行数の監視に使用できます。

1分あたりのAPIリクエスト数と同時実行リクエスト数

1分あたりのAPIリクエスト数と同時実行リクエスト数は、利用パターンに応じて変わる別の指標です。この違いを理解することが重要です。

1分あたりのAPIリクエスト数は、各リクエストにかかる時間やリクエストのバッチ処理方法によって決まるため、同時実行リクエスト数とは異なる場合があります。

例1：間隔を空けたリクエスト 1分あたり180件のリクエストがあり、それぞれの完了に1秒かかり、0.33秒間隔で送信した場合、常に3件が処理中になるため、最大同時実行リクエスト数と平均はともに3になります。

例2：バッチ処理されたリクエスト 一方、それぞれの完了に3秒かかる1分あたり180件のリクエストをすべて同時に送信するような利用パターンの場合、最大同時実行リクエスト数は180、平均は9になります（1分間の最初の3秒間は180件のリクエストが同時にあり、残りの57秒間は0件です）。

システムでは同時実行数が重視されるため、1分あたりのリクエスト数よりも、各リクエストにかかる時間と送信タイミングのパターンのほうが重要です。

エンドポイントへのリクエスト方法は、同時実行数の上限に影響します。

• HTTPでは、各リクエストが個別に同時実行数の上限としてカウントされます。
• テキスト読み上げWebSocketでは、モデルがオーディオを生成している時間のみが同時実行数の上限としてカウントされます。つまり、ほとんどの時間で、開いているWebSocketは同時実行数の上限としてまったくカウントされません。
• テキストtoダイアログWebSocketの仕組みは異なります。開いている各接続は、接続が開いている間、別のプールから1つのダイアログセッションを予約します。接続を通じて生成されるオーディオは、標準の同時実行数上限にはカウントされません。1接続が1セッションとなるため把握しやすく、ダイアログセッションの上限はこの新しい同時実行方式に合わせて設定されています。テキストtoダイアログの同時実行数をご覧ください。

同時実行数の上限について

プランに紐づく同時実行数の上限は、同時に処理できる会話、電話、キャラクターボイスオーバーなどの最大数として解釈すべきではありません。 実際の数は、使用する特定のAI音声やユースケースの特性など、いくつかの要因によって異なります。

一般的な目安として、同時実行数の上限が5の場合、通常は最大約100件の同時オーディオ配信をサポートできます。

これは、TTSリクエストの処理にかかる時間に対して、オーディオの生成速度が速いためです。 以下の図は、異なるユーザーとの4件の同時通話を、同時実行リクエスト数を2に抑えながら実現する例です。

いずれかの時点でプランの同時実行数上限を超えても、エンタープライズプランをご利用の場合は、利用可能な容量に応じてベストエフォートで、低速ながらモデルリクエストが成功することがあります。

テキストtoダイアログの同時実行数

テキストtoダイアログのリクエストは、APIの呼び出し方法に応じて2つの異なる方法で計測されます。

• HTTPエンドポイント（ダイアログを作成およびダイアログをストリーミング）は、他のテキスト読み上げリクエストと同様に、オーディオの生成中はプランの標準同時実行数上限にカウントされます。
• テキストtoダイアログWebSocketなどのWebSocketエンドポイントは、ダイアログセッションとして計測されます。オーディオが現在生成されているかどうかにかかわらず、接続が開いている間は1つのダイアログセッションが保持されます。

セッションベースの計測により、容量計画をシンプルに保てます。1接続が1セッションとなるため、利用量は生成アクティビティによって変動しません。オーディオの生成中だけでなく接続全体でセッションが保持されるため、ダイアログセッションの上限はこの新しい同時実行方式に合わせて設定されています。

ワークスペースのダイアログセッションがすべて使用中のときに接続を開くと、新しい接続はtoo_many_concurrent_requestsエラーで拒否されます。セッションを解放するには、不要になった接続を閉じてください。keep_aliveメッセージを送信しない限り、非アクティブ状態が20秒続くと接続も自動的に閉じられます。

ダイアログセッションを監視するには、ダッシュボードのサイドバー下部にあるDevelopersを開き、Analyticsタブを選択して、UsageビューのConcurrent requests指標を確認します。ダイアログセッションは、他の同時実行リクエストとは別に、TTD Websocket Sessionsという独自の系列として報告されます。

同時実行数上限のスケールテスト

スケールテストは、クライアント側のスケーリングの問題を特定し、ユースケースに対して同時実行数の上限が正しく設定されていることを検証するのに役立ちます。

実際の利用状況にできるだけ近いエンドツーエンドのワークフローをテストすることを強く推奨します。シミュレーションと測定を通じてサポート可能なユーザー数を確認することが、この目的を達成するための推奨手法です。以下の点が重要です。

• 生のリクエストではなく、ユーザーをシミュレートする
• リクエスト前にオーディオ再生、ユーザーの発話、文字起こしの完了を待つなど、典型的なユーザー行動をシミュレートする
• 数分かけてユーザー数をゆっくり増やす
• リクエストのタイミングとリクエストサイズにランダム性を持たせる
• レイテンシー指標と、APIから返されたエラーコードを記録する

たとえば、100件の同時会話をサポートするよう設計されたエージェントシステムをテストするには、会話をシミュレートする個別の「ユーザー」を最大100人作成します。会話は通常、約10秒間のユーザーの発話、約150文字に対するTTS API呼び出し、約10秒間のユーザーへのオーディオ再生という繰り返しサイクルで構成されます。したがって、各ユーザーは、待機時間と要求文字数に少量のランダム性を加えながら、20秒ごとに150文字のテキストに対するWebSocketテキスト読み上げAPI呼び出しを行うパターンに従う必要があります。テストでは、100人に達するまで毎秒1人のユーザーを起動し、全体の安定性を確認するために合計10分間テストします。

import json
import random
import time
import gevent
import locust
from locust import User, task, events, constant_throughput
import websocket
# Averages up to 10 seconds of audio when played, depends on the voice speed
DEFAULT_TEXT = (
    "Hello, this is a test message. I am testing if a long input will cause issues for the model "
    "like this sentence. "
)
TEXT_ARRAY = [
    "Hello.",
    "Hello, this is a test message.",
    DEFAULT_TEXT,
    DEFAULT_TEXT * 2,
    DEFAULT_TEXT * 3
]
# Custom command line arguments
@events.init_command_line_parser.add_listener
def on_parser_init(parser):
    parser.add_argument("--api-key", default="YOUR_API_KEY", help="API key for authentication")
    parser.add_argument("--encoding", default="mp3_22050_32", help="Encoding")
    parser.add_argument("--text", default=DEFAULT_TEXT, help="Text to use")
    parser.add_argument("--use-text-array", default="false", help="Text to use")
    parser.add_argument("--voice-id", default="aria", help="Text to use")
class WebSocketTTSUser(User):
    # Each user will send a request every 20 seconds, regardless of how long each request takes
    wait_time = constant_throughput(0.05)
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.api_key = self.environment.parsed_options.api_key
        self.voice_id = self.environment.parsed_options.voice_id
        self.text = self.environment.parsed_options.text
        self.encoding = self.environment.parsed_options.encoding
        self.use_text_array = self.environment.parsed_options.use_text_array
        if self.use_text_array:
            self.text = random.choice(TEXT_ARRAY)
        self.all_recieved = False
    @task
    def tts_task(self):
        # Do jitter waiting of up to 1 second
        # Users appear to be spawned every second so this ensures requests are not aligned
        gevent.sleep(random.random())
        max_wait_time = 10
        # Connection details
        uri = f"{self.environment.host}/v1/text-to-speech/{self.voice_id}/stream-input?auto_mode=true&output_format={self.encoding}"
        headers = {"xi-api-key": self.api_key}
        ws = None
        self.all_recieved = False
        try:
            init_msg = {"text": " "}
            # Use proper header format for websocket - this is case sensitive!
            ws = websocket.create_connection(uri, header=headers)
            ws.send(json.dumps(init_msg))
            # Start measuring after websocket initiated but before any messages are sent
            send_request_time = time.perf_counter()
            ws.send(json.dumps({"text": self.text}))
            # Send to flush and receive the audio
            ws.send(json.dumps({"text": ""}))
            def _receive():
                t_first_response = None
                audio_size = 0
                try:
                    while True:
                        # Wait up to 10 seconds for a response
                        ws.settimeout(max_wait_time)
                        response = ws.recv()
                        response_data = json.loads(response)
                        if "audio" in response_data and response_data["audio"]:
                            audio_size = audio_size + len(response_data["audio"])
                        if t_first_response is None:
                            t_first_response = time.perf_counter()
                            first_byte_ms = (
                                t_first_response - send_request_time
                            ) * 1000
                            if audio_size is None:
                                # The first response should always have audio
                                locust.events.request.fire(
                                    request_type="websocket",
                                    name="Bad Response (no audio)",
                                    response_time=first_byte_ms,
                                    response_length=audio_size,
                                    exception=Exception("Response has no audio"),
                                )
                                break
                        if "isFinal" in response_data and response_data["isFinal"]:
                            # Fire this event once finished streaming, but report the important TTFB metric
                            locust.events.request.fire(
                                request_type="websocket",
                                name="TTS Stream Success (First Byte)",
                                response_time=first_byte_ms,
                                response_length=audio_size,
                                exception=None,
                            )
                            break
                except websocket.WebSocketTimeoutException:
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Timeout",
                        response_time=max_wait_time * 1000,
                        response_length=audio_size,
                        exception=Exception("Timeout waiting for response"),
                    )
                except Exception as e:
                    # Typically JSON decode error if the server returns HTTP backoff error
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Failure",
                        response_time=0,
                        response_length=0,
                        exception=e,
                    )
                finally:
                    self.all_recieved = True
            gevent.spawn(_receive)
            # Sleep until recieved so new tasks aren't spawned
            while not self.all_recieved:
                gevent.sleep(1)
        except websocket.WebSocketTimeoutException:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Timeout",
                response_time=max_wait_time * 1000,
                response_length=0,
                exception=Exception("Timeout waiting for response"),
            )
        except Exception as e:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Failure",
                response_time=0,
                response_length=0,
                exception=e,
            )
        finally:
            # Try and close the websocket gracefully
            try:
                if ws:
                    ws.close()
            except Exception:
                pass