S2S API比較：RAG編 〜Speech-to-SpeechでRAGを使うなら、何を選ぶべきか

はじめに

前回の記事では、S2S（Speech-to-Speech）APIを単体で比較し、体験品質・知能性能・レイテンシといった観点から各モデルの違いを整理しました。素のS2S APIとして見ると、GPT Realtime 1.5 はバランスが良く、Gemini 3.1 Flash Live は体験品質が高く、Gemini 2.5 Flash Live は知識系に強く、Nova 2 Sonic は低遅延が目立つ、という構図でした。

techblog.heroz.jp

ただ、実際のシステム開発では、単体の対話性能だけでモデルを選ぶ場面はそれほど多くありません。業務システムや社内向けアシスタントを考えると、外部知識を参照するRAG（Retrieval-Augmented Generation）を前提にした設計になることがほとんどです。すると、見るべきポイントは少し変わります。S2S単体では「自然に話せるか」「賢く答えられるか」が中心でしたが、RAGではそれに加えて「正しい文書に到達できるか」「検索結果を会話の中でうまく扱えるか」が重要になります。

さらに、RAGではモデルの素の能力だけでなく、実装のしやすさも無視できません。Tool Callingの仕様、ツール結果の返し方、イベント処理、再開制御などがモデルごとにかなり異なるため、表のスコアだけでは実務上の扱いやすさまでは見えてきません。実際に組み込んでみると、同じ「Tool Calling対応」でもかなり性格が違い、その差がそのまま開発コストや安定性に跳ね返ってきます。

本記事では、S2SでRAGを使う前提で各モデルを比較し、どのモデルがどの用途に向くのかを整理します。前回の基本編の続きとして、今回は「RAGを入れると評価軸がどう変わるか」を中心に見ていきます。

比較対象と評価設計

今回の比較対象は、前回と同じく以下の5モデルです。

GPT Realtime 1.5

GPT Realtime Mini

Nova 2 Sonic

Gemini 2.5 Flash Live

Gemini 3.1 Flash Live

評価は、Tool Calling 40問、RAG 35問で実施しました。採点には Claude 4.5 Sonnet を用いた LLM as a judge を利用し、各項目を 1〜5点の5段階評価（5点満点） で採点しています。前回と同様、単に「答えられたか」だけではなく、実際の利用場面を意識して複数の観点に分解して見ています。

今回のRAG評価で主に見たのは、次の3つです。

検索性能

検索精度、正答文書到達、根拠提示、multi-hop推論

会話型RAG

文脈依存、曖昧質問対応、ハルシネーション耐性、結果統合

システム特性

レイテンシ、コスト、実装時の扱いやすさ

ここで重要なのは、RAGでは単体性能の延長で順位が決まるわけではない、という点です。S2S単体で好印象だったモデルが、RAGを入れるとそのまま有力とは限りません。逆に、基本編では不利だったモデルが、RAGでは十分候補に入ることもあります。今回はその差がかなりはっきり出ました。

結論

先に結論をまとめると、今回の位置づけは次の通りです。

第一候補：Gemini 2.5 Flash Live

検索精度、根拠提示、会話型RAGのいずれも高く、RAG性能が最も高かった

安定性重視：GPT Realtime 1.5

極端な弱点が少なく、実装も含めて扱いやすい

速度重視：Nova 2 Sonic

基本編では厳しかったが、RAGでは実用圏まで健闘した

今回の用途では弱い：GPT Realtime Mini

軽量さはあるが、RAG性能はかなり厳しい

要するに、RAGでは「最強モデル」を一つ決めるというより、何を優先するかで選び方が変わるということです。今回の比較では、知識性能なら Gemini 2.5 Flash Live、安定性なら GPT Realtime 1.5、速度なら Nova 2 Sonic という整理が最もしっくりきました。

まずは、RAGの土台になる検索性能を見ます。今回は、検索精度（基本1hop）、正答文書到達、根拠提示、multi-hop推論を中心に評価しました。

検索性能表

まず目立つのは、Gemini 2.5 Flash Live が検索性能全体で一歩抜けている点です。検索精度だけでなく、正答文書到達や根拠提示も高く、RAGで重要な指標がきれいに揃っています。単にそれらしい答えを返すのではなく、検索した文書を比較的うまく使えている、という印象です。

一方で、他モデルはそれぞれ強みと弱みがはっきり出ました。ここは表をそのまま読み上げるより、要点だけ押さえた方が分かりやすいと思います。

Gemini 2.5 Flash Live

検索精度、正答文書到達、根拠提示のバランスが最も良く、今回の比較では最もRAG向きでした。似た文書が複数ある状況でも比較的正しい文書に着地できており、知識アクセスを伴う用途では第一候補です。

GPT Realtime 1.5

検索精度と根拠提示は一定水準でしたが、正答文書到達はやや弱く、類似文書への誤参照耐性には課題が残りました。検索自体はできても、似た情報が並ぶ状況で安定して正しい文書を使えるかという点では、Gemini 2.5 Flash Live に一歩譲る結果です。

Gemini 3.1 Flash Live

基本編では体験品質の面で好印象だったモデルですが、RAG性能だけを見ると今回は伸び切りませんでした。Gemini系だからRAGにも強いだろうと見たくなるところですが、少なくとも今回の条件では Gemini 2.5 Flash Live の方が明確に上でした。

GPT Realtime Mini

軽量モデルとしての魅力はありますが、検索精度、根拠提示、multi-hop推論のいずれも低めで、RAGの検索基盤としては力不足でした。今回の用途ではかなり厳しい印象です。

Nova 2 Sonic

基本編の印象より健闘しました。トップではありませんが、検索性能としては十分実用圏で、少なくとも「低遅延だがRAGには弱い」と単純には言えない結果でした。

今回の結果から見えてくるのは、RAGでは単体の知能性能と検索性能が必ずしも一致しないということです。素の会話で賢く見えるモデルが、検索文書を挟んだ途端に不安定になることがありますし、その逆もあります。RAGでは「何を知っているか」よりも、「必要な知識にどう到達するか」の比重が大きくなります。

会話型RAG

ただし、RAGは検索性能だけでは決まりません。S2Sで重要なのは、検索結果を会話の中にどう統合できるかです。そこで今回は、会話型RAG（文脈依存・参照解決）、曖昧質問対応、ハルシネーション耐性、結果統合、ツール選択も合わせて見ました。

会話型RAG表

ここでも最も強かったのは Gemini 2.5 Flash Live でした。会話型検索強化生成（RAG）、曖昧質問対応、ハルシネーション耐性が全体に高く、検索結果を会話の流れの中で使う能力まで含めて強さが出ています。音声対話（Speech-to-Speech / S2S）では、ユーザーが毎回きれいに検索語を話してくれるわけではなく、「あれ」「さっきの件」「前の資料」のような曖昧な参照が普通に出てきます。そのときに、会話履歴と検索をつなげて扱えるかどうかは、体験を大きく左右します。

各モデルの傾向を整理すると、次のようになります。

Gemini 2.5 Flash Live

会話型 RAG でも最も強く、曖昧な問いや文脈依存の参照に比較的安定して対応できました。今回の RAG 評価では、検索性能だけでなく会話としての扱いやすさまで含めてトップです。

GPT Realtime 1.5

突出はないものの、全体的に安定していました。曖昧質問対応や結果統合は大崩れせず、会話として破綻しにくい印象があります。ピーク性能ではなく、バランスの良さが強みです。

Gemini 3.1 Flash Live

基本編の体験品質ほどの強さは今回は出ませんでした。会話型 RAG では中位に収まり、素の S2S としての良さと、RAG 込みでの強さは別物だということがよく分かる結果です。

GPT Realtime Mini

会話型 RAG、曖昧質問対応、ハルシネーション耐性のいずれも低く、今回の用途では厳しいという評価を補強する結果でした。

Nova 2 Sonic

会話型 RAG でも一定の健闘を見せました。トップではないものの、基本編からの印象よりはかなり実用寄りで、速度重視の選択肢としては十分に検討できます。

この結果から見えてくるのは、RAG では単発の検索精度だけでなく、会話として扱えるかどうかがかなり重要だということです。検索で上位文書を取れても、その結果を文脈に接続できなければ、ユーザー体験としては弱いままです。S2S で RAG を使うなら、ここは外せない観点です。

レイテンシ（重要な注意点）

RAG を導入すると、レイテンシは必ず増加します。これはどのモデルでも避けられません。

ここでのレイテンシは、問い合わせから最初のトークンが返ってくるまでの時間（TTFT：Time To First Token 相当）で測定しています。RAG ではこの値が、検索処理の影響を受けて増加します。

今回の比較では、Gemini 2.5 Flash Live は 2503.5ms から 3859.8ms、GPT Realtime 1.5 は 738.5ms から 1401.5ms、Nova 2 Sonic は 207.1ms から 740.5ms へと伸びました。増加率だけを見ると Nova 2 Sonic がかなり大きく見えますが、最終的なレイテンシ自体はまだ十分速い水準にあります。

一方で、GPT Realtime Mini は増加がほとんど見られませんでした。ただし、これは単純に強みと見るより、検索性能や会話型 RAG の結果と合わせて解釈する必要があります。レイテンシが小さいこと自体は魅力ですが、RAG として十分に機能していないのであれば評価は変わります。

ここで押さえておきたいのは、RAG では遅くなること自体が例外ではなく前提だということです。検索処理が入る以上、S2S 単体より速くなることはありません。したがって、レイテンシは「どのモデルが遅いか」を競うというより、RAG 込みでどこまで許容できるかで見る方が実務的です。

RAG の流れ

S2S に RAG を組み込むと、処理の流れは概ね次のようになります。

S2S 単体の対話に検索処理が追加されることで、RAG では応答までの流れが一段増えます。

この図で見ておきたいのは、S2S 単体の対話に検索処理が追加される、という点です。音声対話ではこの追加処理がそのまま待ち時間や応答テンポに影響するため、RAG ではレイテンシが一つの注意点になります。

ただし、本記事の主眼はあくまで「どのモデルが RAG に向くか」です。レイテンシは重要ですが、それだけでモデル選定が決まるわけではありません。検索性能、会話型 RAG、実装の安定性と合わせて見る必要があります。

実装してみて分かったこと（ツール呼び出し（Tool Calling）編）

ここからは、表の数字だけでは分かりにくい実装上の差です。前回の記事では、S2S 一般の実装差、割り込みや停止、ターン制御なども扱いました。今回はそこには踏み込まず、Tool Calling を使った RAG 実装で実際に効いた差に絞って整理します。

GPT Realtime 1.5

GPT Realtime 1.5 は、Tool Calling 自体は比較的素直でした。function calling の流れは追いやすく、イベント構造も理解しやすいため、今回の 5 モデルの中では最も見通しが立てやすい部類です。

特に重要だったのは次の点です。

tool 実行後に明示的な再開処理が必要だった

GPT Realtime 1.5 では、tool call を受けて検索を実行し、function_call_output を返しただけでは、そのまま最終回答が生成されないケースがありました。ここで response.create を送って会話を再開しないと、ツールは呼ばれたのに最終応答が返らない状態になります。

これは実装してみるまで見落としやすく、評価系でもかなり影響が大きいポイントでした。tool call 前後の response.done を区別せずに処理すると、「無応答だった」と誤判定しやすくなります。Spec でも、OpenAI Realtime は function_call_output 投入後に追加の response.create が必要だったことが明記されています。

このモデルは、実装上の癖がまったくないわけではありませんが、癖の出方が比較的分かりやすく、修正方針も立てやすいのが強みでした。RAG 性能そのものでは Gemini 2.5 Flash Live に譲る場面があっても、実務で「まず崩れにくいものを選びたい」ときにはかなり有力です。

GPT Realtime Mini

GPT Realtime Mini も系統としては GPT Realtime 1.5 に近く、Tool Calling の考え方も大きくは変わりません。ただし、今回の RAG 用途では肝心の性能面が伸びませんでした。

実装面で特別大きな落とし穴があるというより、ちゃんと実装しても、RAG としての見返りが小さいというのが率直な印象です。軽量モデルとしての魅力はありますが、S2S で RAG をしっかり使いたいという前提では、選びにくい結果でした。

Gemini 2.5 Flash Live / Gemini 3.1 Flash Live

Geminiシリーズは、性能面では特にGemini 2.5 Flash Liveが優れていましたが、Tool Calling（ツール呼び出し）の実装においては最も注意が必要なグループでした。OpenAI互換のコードをそのまま持ち込めず、Gemini向けに調整し直す必要があります。

特に留意すべき点として、以下の項目が挙げられます。

OpenAI互換のスキーマ（schema）をそのまま受け付けない

Gemini 2.5 Flash Live / Gemini 3.1 Flash Live では、OpenAI向けのtool schema（ツールスキーマ）をそのまま渡しても受理されず、Gemini向けに変換する必要がありました。例えばadditionalProperties（追加プロパティ）などを削除しないと処理が通らず、共通のツール定義をそのまま各モデルに流す設計では破綻しやすいです。

Tool Calling（ツール呼び出し）をマルチプロバイダで共通化したい場合、この差分吸収レイヤーはほぼ必須でした。Spec（仕様書）でも、Gemini向けschemaへの変換が必要であることが明記されています。

FunctionResponse（関数レスポンス）にtool call（ツール呼び出し）のidが必要だった

Geminiシリーズでは、name（名前）とresponse（レスポンス）だけを返せばよいわけではなく、対応するtool callのidを明示的に返す必要がありました。ここが欠けると、見た目上は正しいレスポンスを返していても受理されません。

OpenAIシリーズと同じ感覚で実装するとハマりやすい点であり、Tool Callingのレスポンス形式そのものが微妙に異なることを意識する必要があります。

tool call（ツール呼び出し）と他イベントが同居し、取りこぼしやすかった

Gemini 3.1 Flash Live では、usage_metadata（使用量メタデータ）とtool_callが同一responseに同居するケースがあり、usageを先に処理するとtool call自体を取りこぼして無応答に見えることがありました。

また、Geminiシリーズは全体としてイベント粒度がやや扱いづらく、Tool Callingだけを独立して雑に処理すると不安定になりやすい印象があります。イベントを逐次1件ずつ単純に返す設計ではなく、どの情報を優先して拾うかを考えて受信ループを組む必要がありました。

Geminiシリーズは、RAG（Retrieval-Augmented Generation）性能だけ見れば今回かなり有力です。ただし、Tool Calling実装まで含めると、強いモデルであるほど丁寧な受け側が必要になる、という印象でした。特にGemini 2.5 Flash Liveを使うなら、schema変換とレスポンス整形は最初から前提にしておいた方がよさそうです。

Nova 2 Sonic

Nova 2 Sonic は、Tool Calling（ツール呼び出し）まわりの仕様が最も厳格でした。自由に設計するというより、仕様に正確に合わせること自体が実装になります。

特に重要だったのは次の点です。

tool schema（ツールスキーマ）の渡し方がかなり特殊だった

Nova 2 Sonic では、inputSchema.jsonをJSON文字列で渡す必要があり、一般的なJSONオブジェクトとしてそのまま載せる実装だと通りませんでした。また、toolUseOutputConfiguration（ツール出力設定）も必要で、ツール利用時の周辺設定まで含めて揃えないと動きません。

ぱっと見では小さな差に見えますが、共通実装を組もうとするとここが大きな分岐になります。OpenAIシリーズやGeminiシリーズと同じ前提では作れません。

tool result（ツール結果）の返却形式が専用で、少しでもずれるとエラーになった

Nova 2 Sonic では、tool resultを単純なテキスト応答として返すのではなく、contentStart(type=TOOL) -> toolResult -> contentEndのような専用構造で返す必要がありました。これを単発イベントで返したり、誤ってtextInput（テキスト入力）的に返すと受理されません。

しかもエラーは必ずしも親切ではなく、ValidationException（検証例外）やModelStreamErrorException（モデルストリームエラー例外）のような抽象的な形で返るため、原因の切り分けに時間がかかりました。Spec（仕様書）でも、Nova 2 Sonicはtool use（ツール使用）まわりが最も癖が強かったと整理されています。

Nova 2 Sonic は、性能評価だけ見ると今回かなり健闘しています。ただし、その裏側では「仕様に正確に合わせる」実装負荷が相応にあります。速度を優先して選ぶ価値はありますが、Tool Calling部分は雑に共通化せず、専用分岐を用意した方が安定します。

まとめ

今回の比較で見えてきたのは、S2S（Speech-to-Speech）でRAGを使うと評価軸がかなり変わるということです。基本編では、体験品質や素の知能性能、低遅延性（Low Latency）が前面に出ていましたが、RAGを入れると「正しい文書に到達できるか」「その結果を会話の中で扱えるか」がより重要になります。

今回の結論をあらためて整理すると、次の通りです。

知識性能（Knowledge Performance）を重視するならGemini 2.5 Flash Live

安定性（Stability）を重視するならGPT Realtime 1.5

速度（Speed）を重視するならNova 2 Sonic

逆に、GPT Realtime Miniは今回の用途ではかなり厳しいというのが率直な印象でした。

RAGでは、単純なランキングよりも、何を優先するかで選ぶ方が実務的です。知識性能、安定性、速度のどれを取りにいくかで、最適なモデルは変わります。今回の比較が、S2SでRAGを組み込む際のモデル選定の参考になればありがたいです。

モデル別の使い分け（まとめ）

モデル

総合評価

強み

弱み

向いている用途

Gemini 2.5 Flash Live

★★★★☆

RAG性能が最も高い

実装がやや複雑

知識検索・RAG中心の対話

GPT Realtime 1.5

★★★☆☆

安定性が高い

RAG精度は中程度

安定重視の音声対話

Nova 2 Sonic

★★★☆☆

低レイテンシ

Tool周りが厳格

速度重視のRAG

GPT Realtime Mini

★★☆☆☆

軽量・低コスト

RAG性能が低い

非RAG・軽量用途