AssemblyAIでリアルタイム 文字起こし：話者分離・モデル・料金を比較

同じ音声から文字起こし、話者の割り当て、構造化したノートまで作るプロダクトには、AssemblyAIが候補になります。リアルタイム 文字起こしが必要なのか、録音後の処理でよいのかが、まず判断すべきポイントです。現行の録音向けフラッグシップは18言語、リアルタイム向けフラッグシップは32言語に対応しています。議事録なら録音処理から始め、会話が終わる前にアプリが応答する必要があればストリーミングを選びます。

AssemblyAIで何ができる？

AssemblyAIは、音声をテキストに変換する開発者向けプラットフォームです。テキストの分析、音声生成、言語モデルの呼び出しにもAPIを提供しています。録音ファイルやライブ音声を渡し、その結果を使って、検索できるインタビュー、会議の要約、通話分析画面、音声エージェントなどを構築します。提供されるのは音声処理の部品です。画面、ストレージ、権限管理、業務上の操作は、自分たちのプロダクトに実装する必要があります。

モデル、機能、料金は2026年11月5日にAssemblyAIの公開ページで確認しています。本評価はドキュメント、公開製品ページ、以下の費用計算に基づくもので、音声認識の精度や遅延を実測したレビューではありません。

どんな用途に向き、どんな場合に他社を選ぶべき？

文字起こしと、そこから得られる情報の両方が必要なら、AssemblyAIは比較候補に入ります。採用サービスには話者付きの面接ノート、サポート製品には検索可能な通話と課題の抽出が必要です。音声アシスタントには発話のテキストと、相手が話し終えたことを判断できる信号が求められます。

本レビューで重視するのは、処理方式、必要な言語、話者の割り当て、後続処理の出力、その構成での費用です。「高精度」という総論だけでは、これらは判断できません。

AssemblyAIとDeepgramはどう選ぶ？

会話のターン制御が中心課題なら、Deepgramのほうが合う場合があります。Fluxにはモデルに統合された発話終了検出と、ターンの挙動を調整する機能があります。Fluxのクイックスタートでは、接続先の違いも明示されています。Fluxは/v2/listenを使うため、従来の/v1/listenへの文字起こし接続をそのまま置き換えることはできません。電話アシスタントが相手の話を遮ったり、話し終わっても待ち続けたりするなら候補に入れ、実際の通話で挙動を比較します。

ElevenLabsが適しているのは？

ライブ音声でより幅広い言語を検討したい場合や、メディア向けの文字起こしには、ElevenLabsが合う場合があります。音声認識のドキュメントでは、Scribe v2とScribe v2 Realtimeが90+言語に対応し、バッチ出力には発話以外の音声イベントのタグが付くとしています。両方式で同じ機能を提供すると約束する前に、個別に確認してください。同じドキュメントには逐語モードがないとも記載されています。ためらいや言いよどみまで残す必要があるなら、別の選択肢を検証すべき理由になります。

OpenAIが適しているのは？

すでにOpenAIのAPIを使っていて、その連携に文字起こしを加えたいなら、OpenAIが合う場合があります。文字起こしの移行ガイドでは、完了済み音声向けのGPT-Transcribe（gpt-transcribe）と、継続的なライブ入力向けのGPT-Live-Transcribe（gpt-live-transcribe）を区別しています。話者ラベル付きファイルには、別のgpt-4o-transcribe-diarizeのワークフローを使います。新しいモデルへの切り替えで字幕形式やタイムスタンプも引き継がれるとは限りません。

より広く比較するなら、音声認識APIの比較記事を参照してください。完成した議事録アプリだけが欲しい場合は、API連携の開発に着手する前に、その製品カテゴリを評価するほうがよいでしょう。

録音の文字起こし：モデルをどう選ぶ？

終了済みの会議、面接、通話には、AssemblyAIの録音向けAPIから始めるのが自然です。ファイルを非同期処理するため、アプリでジョブを送信し、処理完了後に結果を取得します。議事録を読む人にとって、誰かが話している最中にテキストが届く必要はありません。

安定版の録音モデル、プレビュー版、ライブ向けフラッグシップは別製品なので、モデル名が重要になります。現行モデルの一覧と処理方式ごとの選択ガイドでは、次の構成になっています。

録音とリアルタイムの行でuniversal-3-5-proという識別子が共通でも、APIを取り替えて使えるわけではありません。録音リクエストには複数形のspeech_models配列、ストリーミング接続には単数形のspeech_modelパラメータを使います。

Universal-3.5 Proの録音対応言語は、英語、スペイン語、ドイツ語、フランス語、ポルトガル語、イタリア語、トルコ語、オランダ語、スウェーデン語、ノルウェー語、デンマーク語、フィンランド語、ヒンディー語、ベトナム語、アラビア語、ヘブライ語、日本語、中国語（標準中国語）です。コードスイッチングとは、録音全体を単一言語に限定せず、途中で言語が切り替わる会話を認識することです。

録音モデルの選択ガイドでは、デフォルトの組み合わせを["universal-3-5-pro", "universal-2"]としています。検出または指定された言語に対応する最初のモデルが選ばれます。すべてのジョブがフラッグシップで処理されたと考えず、結果のspeech_model_usedを確認してください。

英語と韓国語の面接を扱うサービスでは、この違いが重要です。英語にはUniversal-3.5 Proを使えますが、韓国語は同モデルの対応言語に含まれず、対応範囲の広い録音処理経路が必要です。アプリ全体を「99言語対応の文字起こし」と表現するだけでは、評価に含めるべきモデルの切り替えが見えなくなります。

録音から議事録を作る手順

ファイル文字起こしのクイックスタートでは、公開先のある音声URLとローカルファイルのアップロードに対応しています。議事録機能なら、次の流れが実用的です。

1. 1

   モデルと言語ごとの処理経路を選ぶ

   意図したspeech_models配列を明示します。アプリ側で言語が分からない場合はlanguage_detectionを有効にします。選択されたモデルをジョブのメタデータに残し、評価時に処理経路を分けて比較できるようにします。

2. 2

   プロダクトに必要な形式で文字起こしを依頼する

   話者付きの会話表示が必要なら、speaker_labels: trueを指定してPOST /v2/transcriptに録音を送ります。検証用の録音で認識の補助が必要と分かった顧客名や製品名などは、キータームとして追加します。

3. 3

   ジョブの完了を待つ

   GET /v2/transcript/{id}をポーリングするか、完了Webhookを使います。失敗したジョブの処理も明示的に実装してください。文字起こしIDを自社の会議IDとともに保存し、後から作る要約や修正が正しい会議に紐付くようにします。

4. 4

   話者と根拠をたどれるノートを作る

   要約を生成する前に、話者ごとの発言とタイムスタンプを保存します。決定事項に異論が出たとき、管理者が根拠のない文章だけを受け取るのではなく、元の発言を開けるようにします。

キータームとコンテキストプロンプトは役割が異なります。前者は登場しそうな語彙を指定し、後者は状況を説明します。Universal-3.5 Proは最大1,000件、Universal-2は最大200件のキータームを受け付けます。どちらを使う場合も、既知の語彙だけが出てくる明瞭なサンプルで成功を判断するべきではありません。

SyncやDictationを選ぶべき場面は？

AssemblyAIの**Sync Speech-to-Text API**は、HTTPレスポンスで完成した文字起こしを返します。短い音声メッセージなど、非同期ジョブの管理が不要なアプリ状態を増やしてしまう場面に適しています。Syncのクイックスタートでは、通常のHTTPアップロードは最大20分、SDKまたはライブアップロードによるリクエストは最大120秒と区別しています。SDKで試作した後、長い録音も受け付ける場合には、このインターフェースごとの上限が重要です。

Dictation APIは、同じリクエストで文字起こしに加え、整文・整形したテキストを返します。話したメッセージを、そのまま送信できる文章にしたい用途に向きます。原文の言い回し自体が成果物なら通常の文字起こし、文章の編集も求めるならDictationを選びます。

リアルタイム 文字起こし：音声エージェントとライブ字幕への組み込み

会話の途中で反応しなければならないアプリには、AssemblyAIのストリーミングを使います。持続的なWebSocket接続で音声を受け取り、発話が届くたびに文字起こしイベントを返します。字幕画面はその更新を表示し、音声エージェントの制御部分は次の動作の判断に使います。

新規連携では、Universal-3.6 Pro Realtimeから検証を始めます。ストリーミングモデルの選択ガイドでは、speech_modelを省略した場合のデフォルトとされています。設定レビューで意図した配備内容を説明できるよう、モデルを明示的に固定してください。

低価格の選択肢は対応範囲が狭くなります。料金ページでUniversal-Streamingと呼ばれているUniversal-Streaming Englishは英語向けです。Universal-Streaming Multilingualは英語、スペイン語、ドイツ語、フランス語、ポルトガル語、イタリア語に対応し、ターンごとに言語を扱います。リアルタイム向けフラッグシップは、より広い対応言語でネイティブなコードスイッチングを支援します。そのため、文の途中で言語を切り替える話者と、ターン間で切り替える話者は、別々の録音で検証する必要があります。

予約アシスタントで重要なのは、予約依頼を正しく把握し、適切なタイミングで返答することです。相手が時刻を言い直している途中でも、文字起こしの断片に正しい日付が入っていることはあります。すべての断片を完成した指示と扱うと、単語は正しく認識できていても、誤った予約を作りかねません。

ストリーミングのクイックスタートには、Begin、Turn、Terminationメッセージが記載されています。end_of_turn: trueのTurnは、確定したターンを表します。エンドポイント検出の信号が示すのは発話の境界であり、取引の承認ではありません。途中のテキストと業務ロジックが確定処理に使うテキストを分け、音声のエンコーディングとサンプルレートを入力元に合わせ、通話終了時にセッションを終了します。

評価では、単語の誤り、固有名詞などの認識誤り、早すぎる返答、依頼終了後の長い待ち時間を分けて記録します。文字起こしの処理時間に加え、依頼が終わってからエージェントが返答するまでの全体の遅延も測ります。アプリ、言語モデル、音声出力のすべてが影響するためです。

話者分離で「誰が何を話したか」を扱う

AssemblyAIの話者分離は、発話を話者ごとにまとめます。「この発言はどの声の人か」を判別する機能です。名前や役割の付与を試みるSpeaker Identificationは別機能です。「A」「B」というラベルだけでは、どちらが面接官でどちらが顧客かは分かりません。

録音では、録音向け話者分離ドキュメントのとおり、speaker_labels: trueで話者付きの発言が返ります。話者を強調表示し、対応する音声へ移動できる面接プレーヤーなどに役立ちます。

ライブ音声では、ターン単位のspeaker_labelと、確定した単語の話者フィールドが返ります。ただし割り当ては暫定的なため、アプリ側で修正を受け付ける必要があります。ストリーミングの話者ドキュメントには、過去のターンを修正するSpeakerRevisionメッセージと、Terminationの前に最終修正が届くことが説明されています。

プロジェクト会議で、短い「私がやります」がタスクの担当決定になる場面を考えてください。最初の話者ラベルが誤っていて修正を適用しなければ、最終議事録で別の人にタスクを割り当ててしまいます。turn_orderをキーにターンを保存し、修正を反映してから最終ノートを生成します。最初のテキストイベントを変更不能なログとして残すだけの設計は、この機能には合いません。

見落としやすい制約もあります。

• max_speakersは厳密な上限です。 超過した話者は既存のラベルに統合されます。遅れて参加する人の余地を設けず、予定人数ぴったりにすると、話者の割り当てが崩れるおそれがあります。
• 短い応答はPENDINGになることがあります。 十分な根拠や修正が届くまで、話者未確定として扱います。同時発話も難しいケースです。ドキュメントでは、同時に話す人の声を単純に独立した音声へ分けられるわけではないと説明しています。

録音システムがすでに参加者ごとの別チャンネルを収録しているなら、その構造を残してマルチチャンネル文字起こしを評価してください。チャンネル分離は録音の構造を使い、話者分離は混ざった音声から話者の交代を推定します。用途が異なり、マルチチャンネル処理では請求額も変わります。

Speech UnderstandingとLLMで何を作れる？

文字起こしだけの連携と比べてAssemblyAIを選ぶ強い理由になるのが、Speech Understandingです。ドキュメントには、Action Items、Auto Chapters、Custom Formatting、Entity Detection、Key Phrases、Sentiment Analysis、Speaker Identification、Summarization、Topic Detection、Translationが挙げられています。

議事録なら、会議を文字起こしし、話者の割り当てを確定し、要約を作り、アクションと担当者を抽出するという具体的な流れになります。サポート分析なら、完了した通話からエンティティやトピックを抽出する流れかもしれません。出力を実際に使うか確かめずに分析機能をすべて有効にすると、費用だけが増えます。

独自のスキーマや推論指示が必要なら、LLM Gatewayを使います。大規模言語モデル（LLM）で文字起こしをdecision、owner、due_date、evidenceなどのフィールドに変換できます。Gatewayのクイックスタートには、transcript_idによる文字起こしの挿入、構造化出力、ツール呼び出し、リトライ、モデルのフォールバックを共通APIから使う方法が記載されています。

それでも、何を正しい回答とするかは定義しなければなりません。「来週のどこかで」という発言なら、具体的な日付を作らず、その曖昧さを残します。誰もタスクを引き受けていないなら、もっともらしい名前より担当者欄が空のほうが役立ちます。抽出項目を元の発言と紐付け、確認できるようにしてください。

正しいJSONが返ったことは、要求した構造に沿っている証拠にはなります。ただし、提案された行動が実行されたことや、本人が合意したことの証明にはなりません。抽出ノートで顧客情報を書き換えたり、重要な業務を割り当てたりする前に、アプリ側で承認の段階を設けます。

Medical Modeは医療用語向けの任意アドオンで、対応する録音・ストリーミングモデルの英語、スペイン語、ドイツ語、フランス語で利用できます。プラットフォーム全体より対応言語が限られます。多言語の医療製品では、文字起こし対応言語すべてで同じ専門性を使えると思い込まず、ドメインモード自体を検証する必要があります。

AssemblyAI-TTS-1は逆方向の処理を担当し、ストリーミングWebSocketまたはHTTPでテキストを音声に変えます。英語、スペイン語、ドイツ語、フランス語、イタリア語、ポルトガル語に対応し、音声クローンと単語のタイミング情報も提供します。音声エージェントでは、入力モデル、推論モデル、出力音声をそれぞれ検証してください。リアルタイム文字起こしの対応言語が、そのまま音声出力の対応言語になるわけではありません。

AssemblyAIの料金と構成別の費用

まずは最低利用額のない従量課金から始めるのが合理的です。請求額は有効にしたモデルと機能で決まります。以下は2026年11月5日にAssemblyAIの料金ページで確認した公開料金です。録音は処理した音声時間、ストリーミングはセッションを開いている時間に課金されます。

• Universal-3.5 Pro： 録音音声1時間あたり$0.21。
• Universal-2： 録音音声1時間あたり$0.15。
• Universal-3.6 Pro Realtime： ストリーミングのセッション1時間あたり$0.45。
• Universal-Streaming： ストリーミングのセッション1時間あたり$0.15。ドキュメント上のUniversal-Streaming Englishです。
• Universal-Streaming Multilingual： ストリーミングのセッション1時間あたり$0.15。
• Universal-3.6 Pro Preview： 現行の料金ページに個別料金の記載はありません。プレビュー版の予算を組む前に確認してください。
• Universal-3.5 Pro Realtime： 対応モデルとしての記載は残っていますが、現行料金ページに個別の料金行はありません。固定して使っている連携の料金を確認してください。
• Sync API： 音声1時間あたり$0.30。
• Dictation API： 記載されている整形・プロンプト機能を含め、1時間あたり$0.62。
• AssemblyAI-TTS-1： 入力100万文字あたり$15。

前述の議事録と音声エージェントでは、次の追加料金も判断に影響します。

• Speaker Diarization： 録音1時間あたり$0.02、またはストリーミングのセッション1時間あたり$0.12を追加。
• Summarization： デフォルトのlow effortは1時間あたり$0.02、medium effortは$0.07を追加。
• Speaker Identification： デフォルトのlow effortは1時間あたり$0.02、medium effortは$0.10を追加。
• Medical Mode： 対象モデルで1時間あたり$0.15を追加。
• Universal-3.5 Proのプロンプト機能： キータームとコンテキストプロンプトは別項目で、それぞれ1時間あたり$0.05。Universal-2にはキータームが含まれます。
• ストリーミングのキーターム： Universal-3.6 Pro Realtimeでは料金に含まれ、Universal-Streamingでは1時間あたり$0.04を追加。

LLM Gatewayは、選んだモデルの入力・出力トークンごとに別途課金されます。トークンはモデルが処理するテキストの単位です。掲載されているGateway料金はグローバルルーティングを前提としており、料金ページではUS/EUのリージョン指定ルーティングは10%高くなるとしています。独自の抽出処理を見積もる際には、この選択も含めてください。

これで選択を具体的に考えられます。両方の録音モデルが受け入れ基準を満たすなら、Universal-2で節約できます。高いモデルによって減らせる修正作業が差額に見合うなら、そちらを選びます。この計算は、どちらかが実際の音声評価に合格すると仮定したものではありません。

ライブセッションの課金ドキュメントは、単位を明確にしています。WebSocketを開いている間は、無音の待機時間も課金対象です。例として、Universal-3.6 Pro Realtimeに話者分離を加えて1,000セッション時間使うと、LLM呼び出しや音声生成を含めず**$570**になります。発話が20分しかなくても、接続を1時間開けば1時間分の利用です。やり取りが終わったら速やかに閉じてください。

マルチチャンネル文字起こしはチャンネルごとに課金されます。1時間の録音を独立した2チャンネルとして処理すると、文字起こしの利用量は2時間になります。モデルだけでなく録音の構成も予算に含めましょう。モノラル会議とチャンネル分離された通話は、同じ費用条件ではありません。

料金ページでは、カード不要の無料登録と、録音の文字起こし最大185時間、ストリーミングの文字起こし最大333時間を案内しています。どの構成でもその時間が保証されるのではなく、公表された上限枠として捉えてください。無料ストリーミングプランは毎分5件の新規接続、従量課金は毎分100件の新規セッションから始まり、自動スケーリングに対応します。これは接続開始のレートであり、同時通話数ではありません。一斉に多くのセッションを開くと、無料枠の時間を使い切る前に開始レートの上限に達する場合があります。

導入判断を変える制約は？

AssemblyAIはモデルと機能の組み合わせが多いため、サンプルの文字起こしが成功しても、検証の出発点にすぎません。特に実装や提供元の選択を左右しやすい制約は、次のとおりです。

ワークフロー全体で対応言語がそろっているとは限りません。 録音モデルのフォールバックで文字起こしの対象言語を増やせても、専門アドオン、ライブモデル、生成音声の対応範囲は狭いことがあります。「韓国語音声から、話者付きの韓国語議事録を作る」のように処理全体の要件を書き、各段階を確認します。

ライブの話者割り当てには、修正可能な状態管理が必要です。 ストリーミングの話者ドキュメントには、暫定ラベル、PENDINGの応答、後続の修正が記載されています。実験的な話者信頼度フィールドも、校正済みの確率ではありません。そのスコアを、タスクの担当者が正しいという保証に置き換えないでください。不確かな区間は確認対象にし、最終記録を作る前に修正を反映します。

録音向けプレビューには、明示された弱点があります。 モデル選択ドキュメントでは、Universal-3.6 Pro Previewは一部の欧州言語で句読点が少なくなることや、複雑なコードスイッチング音声で精度が落ちることがあると警告しています。これは提供元が示す制約で、本レビューの実測結果ではありません。安定版のUniversal-3.5 Proとは別に検証してください。バージョン番号が大きいだけでは選べません。

データの扱いは、アカウント単位で判断する必要があります。 データ保持とモデル学習のドキュメントでは、本番処理での保持とモデル学習への利用を区別しています。学習対象になるかは適用契約と設定次第です。記載されているストリーミングのゼロ保持オプションは学習のオプトアウトが条件で、運用メタデータは残ります。顧客の録音を送る前に、利用するアカウントと処理リージョンを確認してください。

音声分析だけでは、アプリは完成しません。 ジョブの失敗、ノートの修正、顧客との記録の紐付け、抽出したアクションのうち確認を要するものの判断は、引き続き必要です。Gatewayのツール呼び出しは連携を支援しますが、権限とアクションのロジックはアプリ側で用意します。文字起こし料金が小さくても、この開発作業は導入判断に含めるべきです。

結論：プロダクトに必要な出力から選ぶ

会話を話者付きの構造化情報に変える製品なら、AssemblyAIは有力な比較候補です。録音からの議事録では、Universal-3.5 Proに画面で使う分析機能だけを加えて始め、費用や対応言語の広さが重要ならUniversal-2も比較します。新規のライブアシスタントでは、Universal-3.6 Pro Realtimeを、用途に合う低価格ストリーミングモデルやDeepgram Fluxと比較検証します。

判断基準は明確です。 選んだモデル、言語ごとの処理経路、話者情報の出力仕様が製品要件を満たし、文字起こしから知見を得る機能によって自作する連携作業を減らせるなら、AssemblyAIを選びます。必要な言語、ターンの挙動、出力形式が他社のほうに合うなら、そちらを選びます。明瞭なデモ音声が説得力を持って聞こえたというだけで、提供元を変えるべきではありません。

来週、利用許可のある録音を少数用意して試してみてください。普段の会話、聞き慣れない名前、割り込み、短い相づち、利用者が実際に行う言語切り替えを含めます。出力を比較する前に、アプリが必要とするフィールドを書き出します。文字起こしに加えて話者付きの最終ノートを確認し、選んだアドオンと実際の接続時間から費用を計算してください。公開プレイグラウンドは試す入口として便利ですが、受け入れ判定は本番で使う構成で行います。

よくある質問

AssemblyAIのAPIキーはどう取得・管理しますか？

アカウントを作成し、ダッシュボードからキーを取得します。長期利用するキーはサーバー側に保管してください。録音文字起こしAPIでは、Bearerプレフィックスを付けずにauthorizationヘッダーへ指定します。すべてのエンドポイントが同じだと考えず、利用するAPIの認証手順に従ってください。

AssemblyAI Playgroundでは何を試せますか？

公開プレイグラウンドでは、サンプル音声の選択、ファイルのアップロード、URLの指定ができ、モデルのコンテキストと対応する分析機能を設定できます。連携前に製品を確認するのに便利です。代表的な音声を使い、実際に配備する予定の構成で評価してください。

AssemblyAI APIはどの方式を選べばよいですか？

非同期で完了を待てる録音には録音向けAPI、進行中の音声やライブ応答にはストリーミング、リクエストとレスポンスのやり取りで完成した文字起こしが欲しい場合はSyncを使います。そのまま使える文章が必要なら、Dictationで編集済みの出力を加えられます。

AssemblyAIのドキュメントはどこから読みますか？

使う処理方式の現行モデル選択ページから始め、対応するクイックスタートへ進みます。現在のAPI識別子を使い、対応言語と機能を確認して、設定でモデルを固定します。古いチュートリアルの製品名は、別世代のモデルを指している場合があります。

AI Business Workflow Audit Checklistを使い、音声の入力元、必要な出力、アプリ間の受け渡しを整理してください。チェックリストを入手する。