Speech-to-Speech時代にTTS APIは必要？音声AI・Voice Agentの構成を比較！

皆さんこんにちは。
感情豊かな音声合成技術を誰もがかんたんに活用できる未来を目指す、Aivis Projectです✨

音声を直接受け取り、そのまま音声で返すSpeech-to-Speechモデルが登場したことで、Voice Agentの設計は大きく変わり始めています。

従来は、音声認識のSTT、応答を考えるLLM、音声を作るTTSを組み合わせる構成が一般的でした。
現在は、ひとつのRealtimeモデルに音声を入力し、低遅延で音声を返してもらう構成も選べます。

そこで生まれるのが、「TTS APIは、もう必要ないのでは？」という疑問です。

私たちの答えは、TTS APIが不要になるのではなく、TTSを分離して使う理由が、より明確になるというものです。

この記事では、Speech-to-Speech型とSTT・LLM・TTSを組み合わせるパイプライン型を比較し、速度、声、読み、ログ、運用の観点から選び方を解説します📚

【結論】自然な対話ならSpeech-to-Speech、声と制御を選ぶならパイプライン型

パイプライン型が向いている場面
・自社専用の声やキャラクターの声を使いたい
・社名、商品名、人名などの読みとアクセントを固定したい
・応答テキストを検査してから音声化したい
・STT、LLM、TTSを個別に選び、将来入れ替えたい

どちらが常に優れている、という関係ではありません。

会話の即時性を優先するのか、出力する声と内容の再現性を優先するのかで、適した構成が変わります。

【全体像】2つの音声AIアーキテクチャ

Speech-to-Speech型

アプリケーションから見ると、音声をRealtimeモデルへ送り、音声の応答を直接受け取る構成です。

音声入力
  ↓
Speech-to-Speechモデル
  ↓
音声出力

STT、推論、音声生成の境界をアプリケーション側で細かく管理せず、ひとつのセッションとして扱えます。
割り込み、相づち、話し終わりの検出などを含む自然なターンテイキングを作りやすいのが特徴です。

ただし、「エンドツーエンド」と呼ばれていても、必ずしもテキストを一切取得できないわけではありません。
現在の代表的なRealtime APIには、入力音声や出力音声の文字起こし、ツール呼び出し、トレースを利用できるものがあります。

パイプライン型

音声認識、応答生成、音声合成を、それぞれ独立した工程としてつなぐ構成です。

音声入力
  ↓
STT：音声を文字に変換
  ↓
LLM：応答テキストを生成
  ↓
TTS：テキストを音声に変換
  ↓
音声出力

工程が増える一方、各段階の入力と出力を確認し、用途に合うサービスへ入れ替えられます。

すでにテキストチャットのAIエージェントを運用している場合は、その仕組みを再利用しやすい構成でもあります。

【比較1】会話の速さと自然な割り込み

リアルタイム会話では、Speech-to-Speech型に強みがあります。

音声の入力から出力までを同じセッションで扱えるため、次のような会話表現を実装しやすくなります。

・ユーザーが話し始めたら、AIの発話を止める
・短い相づちを返す
・話し終わりを検出して、すぐ応答を始める
・声色や話し方から受け取ったニュアンスを応答へ反映する

ただし、Speech-to-Speech型なら必ず速いとは限りません。
体感速度は、VADによる話し終わり判定、ネットワーク、モデルの推論、ツール呼び出し、音声のバッファリングなどを含む合計で決まります。

パイプライン型でも、処理をすべて順番に完了させる必要はありません。

LLMが最初の文を生成
  ↓ すぐTTSへ送信
TTSが最初の音声チャンクを生成
  ↓ すぐ再生開始
LLMとTTSは後続部分を並行して処理

Aivis Cloud APIは音声のストリーミング出力に対応しています。
短いテキストでは最速0.3秒未満で音声を生成でき、受信した音声チャンクから順次再生することで、全文の生成完了を待たずに読み上げを始められます。

⚠️ 0.3秒未満は最良条件での目安であり、常に保証される値ではありません。
実際の応答時間は、入力テキスト、モデル、通信環境、クライアント側の再生実装によって変わります。

【比較2】声を選べる範囲とブランドの再現性

Speech-to-Speech型でも、複数のプリセット音声から話者を選べるサービスがあります。
そのため、「Speech-to-Speechでは声を選べない」わけではありません。

一方、ブランドボイスを考えるときは、単に候補から好みの声を選べるだけでは不十分です。

・既存のキャラクターやナレーターの声を使えるか
・自社専用に制作したモデルを持ち込めるか
・Web、アプリ、動画、電話などで同じ声を使い続けられるか
・サービス側の更新後も、同じ声質を再現できるか
・利用範囲や商用利用の条件を自社で管理できるか

これらが必要なら、TTSを独立した出力層として設計する方法が分かりやすく、移行もしやすくなります。

Aivisのエコシステムでは、AivisHubの公開モデルから声を選ぶほか、限定公開・非公開モデルや、まるなげボイスで制作した専用モデルを利用できます。
会話AIの頭脳を変更しても、TTSを固定すれば、ユーザーへ届ける声を保ちやすくなります✨

【比較3】日本語の読みとアクセントを制御できるか

業務で日本語音声を使うとき、声質と同じくらい重要なのが読みの再現性です。

・社名やサービス名
・担当者名
・地名や施設名
・製品番号や略語
・業界固有の専門用語

会話として自然でも、社名を毎回違う読み方で発音してしまえば、本番サービスでは使えません。

Aivis Cloud APIでは、ユーザー辞書を音声合成リクエストに指定し、表記、読み、アクセント型、品詞、優先度を管理できます。また、対応範囲内のSSMLを使い、特定箇所の間や読み方、話速などを調整できます。

{
  "model_uuid": "MODEL_UUID",
  "text": "AivisSpeechで調整した読みを確認します。",
  "user_dictionary_uuid": "USER_DICTIONARY_UUID",
  "output_format": "mp3"
}

Speech-to-Speech型でもプロンプトによる読みの指示が使える場合はありますが、同じ単語を毎回同じ読みとアクセントで発音できるかは、採用前に実データで検証する必要があります。

【比較4】テキスト、ログ、監査の扱いやすさ

Speech-to-Speech型でも、APIによっては入力・出力の文字起こしや実行トレースを取得できます。
したがって、「音声を直接扱うからログが残せない」とは限りません。

違いは、テキストが処理の中心にあるかどうかです。

パイプライン型では、LLMが生成したテキストをTTSへ渡す前に、次の処理を明示的に挟めます。

・禁止表現や個人情報の検査
・人間による承認
・読み上げ対象と画面表示用テキストの分離
・応答内容の保存と検索
・問題発生時の原因切り分け

Speech-to-Speech型の文字起こしは、サービスによって精度や確定タイミング、保持方法が異なります。
監査で必要なのが「会話のおおよその記録」なのか、「実際に承認され、読み上げられた文面」なのかを先に決めてください。

金融、医療、予約受付、契約案内など、発話内容の確認が重要な用途では、TTSへ送る直前の確定テキストを保存できるパイプライン型が扱いやすい場合があります📕

【比較5】構成要素を交換できるか

Speech-to-Speech型は、音声入力から出力までをひとつのモデルやサービスにまとめられるため、構築を始めやすいのが魅力です。

その一方で、音声認識だけ、LLMだけ、声だけを別のサービスへ入れ替えたい場合は、利用中のAPIが提供する範囲に左右されます。

パイプライン型では、次のような変更を個別に行えます。

・専門用語に強いSTTへ変更する
・用途に合うLLMへ切り替える
・応答生成は変えず、TTSだけブランド音声へ変更する
・クラウドTTSから自社環境の音声合成基盤へ移行する

ただし、自由度が高いぶん、認証、エラー処理、ストリーミング、監視を複数サービスにまたがって設計する必要があります。

開発の速さを取るならSpeech-to-Speech型、将来の交換性を取るならパイプライン型という見方ができます。

【比較6】料金は構成だけで決められない

Speech-to-Speech型は、ひとつのサービスへまとめられるため、構成と請求を把握しやすい場合があります。一方、音声入出力を含むRealtimeモデルの単価と、STT・LLM・TTSを個別に使う料金のどちらが安いかは、サービスと利用量によって変わります。

比較するときは、API単価だけでなく次の項目を含めてください。

・1会話あたりの平均時間
・無音区間を含む入力音声の長さ
・LLMへ渡すコンテキスト量
・生成する返答の長さ
・再接続や失敗時の再試行
・監視やログ保存にかかる運用コスト

本番トラフィックを想定した小規模なPoCを行い、1会話あたりの総コストと応答時間を同時に測るのが確実です。

【現実解】RealtimeモデルとAivis Cloud APIを組み合わせる

「音声入力の自然さはRealtimeモデルを使いたい。ただし、ユーザーへ返す声は自社専用にしたい」という場合は、出力段だけをAivis Cloud APIへ分ける構成があります。

ユーザーの音声
  ↓
Realtimeモデル
  ├─ 音声理解・ツール実行
  └─ 応答テキストを出力
          ↓
    内容の検査・読みの調整
          ↓
    Aivis Cloud API
          ↓
    ブランド音声で再生

この構成では、Realtimeモデルが生成したネイティブ音声は使わず、確定した応答テキストをAivis Cloud APIで音声化します。

出力側はパイプライン型になりますが、会話の頭脳とブランド音声を分けて管理できます。

⚠️ 同じキャラクターが場面によって別の声へ切り替わると、ユーザーは違和感を覚えます。
ひとつの人格として提供するなら、通常応答も重要な案内も、同じTTSへ統一する設計がおすすめです。

【自社環境】Citorasで守れるのはTTSの処理範囲

入力テキストを共有型のクラウドTTSへ送れない場合は、Citorasを使い、Aivisの音声合成基盤をお客様の管理するGPU環境で動かす選択肢があります。

ただし、Citorasが担うのは音声合成部分です。

STT ── 別途選定・構築
LLM ── 別途選定・構築
TTS ── Citorasを自社環境へ配置

Voice Agent全体を自社環境内で完結させるには、STTやLLMも、自社のセキュリティ要件に合う構成で用意する必要があります。

守りたいのが音声モデルなのか、TTSへ渡すテキストなのか、会話全体なのかを分けて整理すると、必要な構成が見えやすくなります。

【選び方】用途から逆引きする

Speech-to-Speech型が向くケース

・汎用的な音声アシスタントを短期間で試したい
・割り込みや相づちを含む自然な会話を重視する
・提供される音声の中に、用途に合うものがある
・厳密な読みや発話前の承認を必要としない

パイプライン型が向くケース

・キャラクターや企業のブランド音声を継続して使いたい
・社名、商品名、人名の読みを固定したい
・発話前に応答テキストを検査・承認したい
・既存のテキストAIエージェントを音声化したい
・STT、LLM、TTSを将来個別に入れ替えたい

ハイブリッド構成が向くケース

・Realtimeモデルの音声理解やツール連携を使いながら、出力音声はAivisへ統一したい
・試作ではSpeech-to-Speech型を使い、本番要件が固まった段階でTTSを分離したい
・通常の会話速度と、重要な発話の検査・再現性を両立したい

【導入前】比較検証で確認する項目

アーキテクチャを決める前に、実際の会話を使って次の項目を測定してください。

・ユーザーが話し終えてから、最初の音が再生されるまでの時間
・割り込みが正しく動くか
・固有名詞、数字、英字、略語を正しく発音できるか
・同じ指示で、声質や読みが安定して再現されるか
・発話した内容を後から確認できるか
・禁止表現や誤案内を音声化する前に止められるか
・利用予定のトラフィックで、料金とレート制限が成立するか
・モデルやサービスを変更するとき、どこまで作り直しになるか

比較時は、短いデモ用の会話だけで判断せず、実際の固有名詞、沈黙、言い直し、割り込み、ツール呼び出しを含むテストを行うことが重要です。

よくある質問（FAQ）

Q. Speech-to-Speech型でも声を選べますか？

複数のプリセット音声から選べるサービスがあります。
独自の声を登録できるか、既存の音声モデルを持ち込めるか、同じ声を将来も再現できるかはサービスごとに異なります。

Q. Speech-to-Speech型でも会話ログを保存できますか？

入力・出力の文字起こしやトレースを提供するAPIがあります。
ただし、文字起こしの精度、確定タイミング、保存範囲はサービスごとに異なります。

Q. RealtimeモデルとAivis Cloud APIは連携できますか？

できます。
Realtimeモデルから応答テキストを受け取り、そのテキストをPOST /v1/tts/synthesizeへ送る構成にすれば、Aivisの音声モデルで読み上げられます。

Q. 途中でSpeech-to-Speech型からAivisの声へ切り替えても問題ありませんか？

技術的には可能ですが、同じ人格の声が途中で変わると違和感につながります。
ブランドやキャラクターとして提供する場合は、出力音声をひとつのTTSへ統一するほうが自然です。

Q. Citorasを導入すれば、Voice Agent全体をオンプレミス化できますか？

Citorasで自社環境へ配置できるのはTTS部分です。
Voice Agent全体を自社環境内で動かすには、STTとLLMも別途、自社環境または要件に合うサービスで構築してください。

Q. 最初からどちらか一方に決める必要がありますか？

ありません。
Speech-to-Speech型で会話体験を検証し、ブランド音声や読みの制御が必要になった段階でTTSを分離する進め方もできます。

ただし、本番移行時の変更範囲を把握するため、試作段階から応答テキストを取得できる構成にしておくと移行しやすくなります。

まとめ

Speech-to-Speech型の登場によって、TTS APIの価値がなくなるわけではありません。

誰の声で、どのように読み、どの内容を発話したかを管理したい場面ほど、TTSを独立させる意味が大きくなります。

まずは実際の会話で速度と自然さを試し、そのうえで、自社にとって声が体験の一部なのか、事業の資産なのかを考えてみてください✨

以上で、この記事はおしまいです。

Aivis ProjectやAivis Cloud APIに関してご不明点やご相談がある場合には、お問い合わせフォームよりお気軽にご連絡ください。

🔗 関連リンク
・Aivis Cloud API: https://aivis-project.com/cloud-api/
・Aivis Cloud APIドキュメント: https://api.aivis-project.com/v1/docs
・リアルタイム音声合成デモ: https://api.aivis-project.com/v1/demo/realtime-streaming
・AivisHub（音声合成モデル共有）: https://hub.aivis-project.com
・AivisSpeech（無料音声合成ソフト）: https://aivis-project.com/