S2S APIを比較して分かった実務的な選び方
HEROZ Tech Blogは、主要なS2S（Speak-to-Speak）APIモデル（GPT・Gemini・Nova）を体験品質・知能性能・レイテンシ・実装面で比較し、実務的な選び方を整理した記事を公開した。
キーポイント
S2S APIの実務比較
GPT、Gemini、Novaの主要モデルを同一条件で比較し、体験品質、知能性能、レイテンシの観点から評価している。
実装面の重要な差異
ターン制御やAPI設計の違いなど、開発者が実際に実装する際に直面する実務的な課題に焦点を当てている。
実用的な選定基準の提示
単なる性能比較ではなく、実際のプロジェクトでどのモデルを選ぶべきかの判断材料を提供している。
音声対話技術の現状分析
音声→音声のリアルタイム対話を実現する新しいアーキテクチャであるS2S APIの現状を整理している。
影響分析・編集コメントを表示
影響分析
この記事は、音声対話AIの実用化が進む中で、開発者が適切な技術スタックを選択するための具体的な指針を提供している。技術比較記事としての実用性は高いが、S2S API自体は既存技術の応用であり、業界を変革するほどの革新性は限定的である。
編集コメント
技術ブログとして実務に直結する内容で価値が高いが、特定の企業のPR色は薄く、開発者向けの実用的な情報として整理されている。
S2S（Speak-to-Speak）APIは、音声から音声へのリアルタイム対話を実現する新たなアーキテクチャです。本記事では、主要モデル（GPT・Gemini・Nova）を同一条件で比較し、体験品質・知能性能・レイテンシに加えて、実装時のターン制御やAPI設計の差異を検証し、実務に即した選び方を解説します。
原文を表示
はじめに
音声AIの実装では、これまで「音声 → テキスト → LLM → 音声」というパイプライン構成が一般的でした。
これに対して、音声入力から音声出力までを一気通貫で扱う S2S（Speech-to-Speech）API が登場し、リアルタイムな会話体験の実現が現実的になってきています。
一方で、各社のS2S APIはまだ新しい領域にあり、単純な性能比較だけでは整理しづらい状況です。応答の正確さだけでなく、会話の自然さ、レイテンシ、コスト、さらには実装時の扱いやすさまで含めて見ないと、実務的な判断は難しいと感じています。
そこで本記事では、主要なS2Sモデルを同一条件で比較し、まずは基本性能に絞って整理しました。RAGやTool Callingについては別記事で扱い、本記事では「素のS2S APIとしての違い」にフォーカスします。
比較対象
今回の比較対象は以下のモデルです。
GPT Realtime 1.5 (gpt-realtime-1.5)
GPT Realtime Mini (gpt-realtime-mini)
Nova 2 Sonic (amazon.nova-2-sonic-v1:0)
Gemini 2.5 Flash Live (gemini-2.5-flash-native-audio-preview-12-2025)
Gemini 3.1 Flash Live (gemini-3.1-flash-live-preview)
なお、Gemini 3.1 Flash Live は比較的新しいモデルであり、検証時点では Vertex AI 未対応で、Gemini API 経由での利用となりました。また、output token usage が取得できないケースがあり、コストの扱いには制約があります。
実験設計
今回の評価では、体験品質と知能性能を分けて評価しています。
S2Sでは「正しい答えを出すか」だけでなく、「会話として自然か」が重要になるため、この2軸を分離しました。
体験品質は人手評価で、会話自然度や感情表現、発話や割り込みといった観点を中心に3段階で評価しています。
一方で知能性能は自動評価とし、基本QA、指示追従、会話メモリ、言語混在耐性、構造制御などを対象に5段階で評価しました。評価には Claude 4.5 Sonnet を用いた LLM as a judge を利用しています。
総合スコアは単純平均ではなく、評価件数（体験30問、知能120問）を考慮して統合しています。
今回の評価に使用した対話テーマは、以下のような実務寄りのシナリオを中心に構成しています。
一般的なQA（知識質問・業務FAQ）
指示追従（条件付き回答、フォーマット指定）
複数ターン会話（文脈保持・言い換え）
言語混在（日本語＋英語）
特定ドメインに強く依存しないように設計しつつ、実際の業務利用を想定したケースを中心に評価しています。
➡︎ 体験と知能を分離した上で統合することで、S2Sの特性をより正確に評価しています。
実験結果
今回の比較では、単純な精度や応答品質だけでなく、実際の利用シーンを想定した複数の観点から評価を行いました。
具体的には、以下の3つの軸で整理しています。
体験品質（人手評価）: 会話の自然さ、感情表現、発話品質、割り込みや停止の扱いやすさなど、実際に使った際の体験を評価しています。
知能性能（自動評価）: 基本QA、指示追従、会話メモリ、言語混在耐性、構造制御など、モデルとしての能力を評価しています。こちらは Claude 4.5 Sonnet を用いた LLM as a judge により採点しています。
システム特性: レイテンシやコストといった、実運用に直結する指標を評価しています。
これらを統合した総合スコアに加えて、各観点ごとの結果も併せて見ることで、モデルごとの特性をより立体的に把握できるようにしています。
➡︎ 本記事では「どのモデルが優れているか」ではなく、「どの観点で強みがあるか」に注目して比較しています。
総合比較
総合比較テーブル
総合スコアでは GPT Realtime 1.5 が最も高くなりました。
体験品質・知能性能ともに大きな弱点がありません。
個別項目で突出しているわけではありませんが、どの観点でも安定しており、実運用で扱いやすいバランスに収まっています。
Gemini 3.1 Flash Live は僅差で続き、特に体験スコアの高さが目立ちました。会話の自然さや感情表現といった部分では強さがあり、ユーザー体験という観点では魅力的です。
一方で、挙動の安定性や実装面では注意が必要な場面もあり、スコアだけでは評価しきれない側面があります。
Gemini 2.5 Flash Live は知能面では依然として高水準ですが、レイテンシの影響で総合スコアはやや下がっています。
GPT Realtime Mini は軽量モデルとしてバランスが良く、コストを抑えたい場合の現実的な選択肢です。
Nova 2 Sonic は総合スコアでは低めですが、低遅延という別軸の強みがあります。
整理すると、各モデルの位置づけは次の通りです。
GPT Realtime 1.5：バランス型で実運用向け
Gemini 3.1 Flash Live：体験品質が高い最新モデル
Gemini 2.5 Flash Live：知識系に強いがレイテンシ重め
GPT Realtime Mini：コスパ重視の軽量モデル
Nova 2 Sonic：低遅延特化
➡︎ 総合順位よりも「どの特性を持つか」で見るべき結果です。
体験品質と知能性能の関係
散布図
図を見ると、体験品質と知能性能は2軸上で右上に集中しており、いずれのモデルも一定以上の品質を持っていることが分かります。
そのため、この図は優劣を比較するというよりも、各モデルの「性格の違い」を見るものになります。
GPT Realtime 1.5 は体験・知能ともにバランスが良く、実用域の中心に位置しています。
特定の強みよりも、安定性が際立つモデルです。
Gemini 2.5 Flash Live および Gemini 3.1 Flash Live はやや知能寄りに分布しており、QAや会話メモリといった観点での強さが影響しています。
GPT Realtime Mini はその中間に位置し、軽量モデルとして性能とコストのバランスを取っています。
Nova 2 Sonic は他モデルより下側に位置しますが、これは今回の評価軸によるものであり、低遅延という特性はこの図には含まれていません。
整理すると、各モデルの関係は以下のようになります。
GPT Realtime 1.5：バランス型
Gemini系：知能寄り
GPT Realtime Mini：中間
Nova 2 Sonic：低遅延特化
➡︎ 性能差よりも「モデルの性格差」が支配的です。
能力分解（知能）
能力分解テーブル
知能性能を分解すると、各モデルの得意分野がより明確になります。
Gemini 2.5 Flash Live は基本QAのスコアが高く、知識を引き出して回答する能力が際立っています。
Gemini 3.1 Flash Live は会話メモリが強く、複数ターンにわたる文脈保持に優れています。
一方で GPT Realtime 1.5 は構造制御の安定性が高く、形式に沿った出力や応答の整理といった点で優位です。
実務で扱う際に破綻しにくいという特徴は、この結果とも一致します。
GPT Realtime Mini は指示追従は比較的良好ですが、メモリや構造制御は控えめです。
Nova 2 Sonic はQA力自体は一定水準にあるものの、言語耐性が低く、言語混在への対応では弱さが見られました。
整理すると、モデルの特徴は次の通りです。
Gemini系：内容の強さ（QA・メモリ）
GPT Realtime系：出力の安定性
Nova 2 Sonic：知能面はやや弱い
➡︎ 「何を出すか」と「どう出すか」で強みが分かれています。
レイテンシとコスト
レイテンシ・コスト表
レイテンシでは Nova 2 Sonic が突出しており、約200msという値は体感的にも非常に軽快でした。
リアルタイム性を重視する用途では、この差は明確に効いてきます。
GPT Realtime 1.5 と GPT Realtime Mini はいずれも700ms台で、リアルタイム会話として十分成立する水準です。
特に GPT Realtime Mini はコストも抑えられており、速度と価格のバランスが良いモデルです。
Gemini 2.5 Flash Live はレイテンシが重く、応答開始までの待ち時間が長くなります。
Gemini 3.1 Flash Live は改善されているものの、依然としてGPT系より遅く、さらに output token usage が安定しないため、コスト見積もりには注意が必要です。
整理すると、次のような関係になります。
Nova 2 Sonic：最速（低遅延）
GPT Realtime系：バランス型
Gemini系：低コストだが遅い
➡︎ レイテンシとコストは明確なトレードオフです。
実装してみて分かったこと
実際にS2S APIを実装してみると、単純な性能比較では見えない差がはっきりと出てきます。
特に大きかったのは、音声対話における「ターン制御」の扱いです。
音声UIでは、「いつ話し終わったか」「途中で止めるか」「割り込んだ場合どうするか」といった制御が不可欠になります。これらは単なるAPI呼び出しでは解決できず、イベント処理・再生制御・状態管理が密接に絡みます。
➡︎ 精度より先に、ターン制御で実装が分かれます。
途中停止と割り込みの設計
途中停止（Stop / cancel）
音声UIでは、アシスタントの発話を途中で止められることが前提になります。ただし実装してみると、「止める」という処理は2つのレイヤーに分かれます。
モデル側の生成を止める
クライアント側の再生を止める
この違いを整理しないと、設計が破綻します。
GPT Realtime 1.5 / Mini では、response.cancel や conversation.item.truncate により、生成そのものを停止できます。そのため、
APIに停止イベントを送る
以降のトークン生成が止まる
再生も停止する
という一貫した制御が可能です。
一方で Nova 2 Sonic や Gemini Flash Live では、少なくとも今回の検証範囲では生成停止を前提としたAPI設計にはなっていません。そのため実装としては、
音声再生を停止する
受信済みのバッファを破棄する
以降の出力は無視する
という「聞き捨てる」設計になります。
この差は責任分担の違いとして整理できます。
GPT：停止制御をAPI側に委ねられる
Gemini / Nova：停止制御をクライアント側で持つ
➡︎ 途中停止は「止める」か「聞き捨てる」かで設計が分かれます。
割り込み（Barge-in）
割り込みは、ユーザーがアシスタント発話中に話し始めた際の挙動です。音声UIの自然さはここで決まります。
今回の実装ではローカルVADは使わず、API側の検知に委ねています。各モデルの挙動は以下の通りです。
GPT Realtime：server VAD による検知
Nova 2 Sonic：Bedrock側の turn detection / barge-in
Gemini Flash Live：activity detection
重要なのは、割り込みは単なる停止ではないという点です。実際には以下のような状態遷移になります（「話している → 止める → 次に切り替える」という流れ）。
ユーザー発話を検知
現在の音声再生を停止
未処理の音声バッファを破棄
新しい入力として次ターンに遷移
この「再生停止 + 状態リセット + 次ターン移行」が一体となって初めて自然な挙動になります。
➡︎ 割り込みは停止ではなく「ターンの切り替え」です。
モデル別の実装特性
ここまでの挙動を踏まえると、各モデルの実装体験には明確な違いがあります。細かい仕様差に入る前に、直感的には以下のように整理できます。
GPT Realtime 1.5 / Mini：素直で完結している
Gemini Flash Live：柔軟だがイベント依存が強い
Nova 2 Sonic：仕様が厳格で入力にシビア
これは単なる使いやすさではなく、「どこに制御責任があるか」の違いです。
➡︎ モデルごとに「実装責任の置き場所」が異なります。
GPT Realtime 1.5 / Mini
GPT Realtime 系は、イベントの流れが明確で、ターン制御がAPI側で完結します。
server VAD によるターン検知
cancel / truncate による生成停止
一貫したイベント構造（開始 → 生成 → 完了の流れが明確）
これにより、
いつ終了したか
いつ止めるか
いつ次に進むか
をすべてAPIで判断できます。
クライアント側は「イベントに従う」だけで成立するため、状態管理がシンプルです。結果として、Stop・割り込み・ターン制御を一貫した設計で扱えます。
Gemini Flash Live
Gemini Flash Live は柔軟ですが、その分イベント解釈の責任がクライアント側に寄ります。
特に注意が必要だったのは以下です。
activity detection に依存したターン確定
response.done のタイミングが一定でない
transcript / audio のイベント粒度の違い
usage情報が安定しないケース
例えば、response.done を終了判定に使うと、実際の音声出力より先に終了扱いになるケースがありました。このため、終了判定は複数イベントを組み合わせて判断する必要があります。
➡︎ イベントをどう解釈するかが実装の本質になります。
Nova 2 Sonic
Nova 2 Sonic は仕様が厳格で、入力フォーマットへの依存が強いモデルでした。
主な特徴は以下です。
promptの先頭がSYSTEMである必要がある
イベント構造が固定されている
フォーマット不備でValidationExceptionが発生しやすい
cancel前提ではなくturn detectionベース
このため、「自由に設計する」というよりも「仕様に正確に合わせる」実装が求められます。柔軟性は低いですが、その分動作は一貫しています。
➡︎ 仕様適合性がそのまま実装難易度になります。
まとめ
今回の比較から見えてきたのは、S2S APIは単純なランキングで選べるものではないという点です。
GPT Realtime 1.5 は体験品質・知能性能・レイテンシのバランスが良く、さらに実装も素直であるため、最も扱いやすいモデルでした。
汎用的なリアルタイム対話基盤としては第一候補になります。
Gemini 2.5 Flash Live と Gemini 3.1 Flash Live は知能面での強さがあり、特に知識系やRAG用途では有力です。ただしレイテンシや実装上の癖には注意が必要です。
GPT Realtime Mini はコストと性能のバランスが良く、軽量な選択肢として実用的です。
Nova 2 Sonic は低遅延という明確な強みがあり、速度が重要な場面では有効です。
整理すると、用途別の選択は以下の通りです。
汎用用途：GPT Realtime 1.5
知識・RAG用途：Gemini系
コスト重視：GPT Realtime Mini
低遅延重視：Nova 2 Sonic
➡︎ 「どれが最強か」ではなく「どの用途に合うか」で選ぶのが重要です。
関連記事
Google DeepmindのGemini Robotics-ER 1.6がロボットの計画・知覚能力を向上
Google Deepmindが、ロボットの計画・知覚能力を強化するGemini Robotics-ER 1.6を発表した。計測機器の読み取り能力も向上している。
ジェミニの環境影響、中国の新興AIハブ、チャットボットによる採用面接、エージェントのセキュリティ
The Batch AI News and Insightsが、AIを理解する開発者の需要が未充足であると報告した。
プロンプトだけでは平凡なAIライティングは救えない
AIライティングの品質向上には、プロンプトよりも素材の質・モデルの性能・レビュー能力の3要素が重要である。