はじめに
音声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
➡︎ 「どれが最強か」ではなく「どの用途に合うか」で選ぶのが重要です。
