HEROZ Tech Blog

日本将棋連盟公認「将棋ウォーズ」や、AIを活用したシステム企画・開発を行う、AI企業HEROZの公式テックブログです。

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

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性能（検索能力）

まずは、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、曖昧質問対応、ハルシネーション耐性が全体に高く、検索結果を会話の流れの中で使う能力まで含めて強さが出ています。音声対話では、ユーザーが毎回きれいに検索語を話してくれるわけではなく、「あれ」「さっきの件」「前の資料」のような曖昧な参照が普通に出てきます。そのときに、会話履歴と検索をつなげて扱えるかどうかは、体験を大きく左右します。

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

  • 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相当）で測定しています。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では応答までの流れが一段増えます。

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性能だけ見れば今回かなり有力です。ただし、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でRAGを使うと評価軸がかなり変わるということです。基本編では、体験品質や素の知能性能、低遅延性が前面に出ていましたが、RAGを入れると「正しい文書に到達できるか」「その結果を会話の中で扱えるか」がより重要になります。

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

  • 知識性能を重視するなら Gemini 2.5 Flash Live
  • 安定性を重視するなら GPT Realtime 1.5
  • 速度を重視するなら 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・軽量用途