評価は、Tool Calling 40問、RAG 35問で実施しました。採点には Claude 4.5 Sonnet を用いた LLM as a judge を利用し、各項目を 1〜5点の5段階評価（5点満点） で採点しています。前回と同様、単に「答えられたか」だけではなく、実際の利用場面を意識して複数の観点に分解して見ています。
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には弱い」と単純には言えない結果でした。
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部分は雑に共通化せず、専用分岐を用意した方が安定します。
