こんにちは、AIチームの大竹です。
この記事はAI Shift Advent Calendar 2025の8日目の記事です。
2024年10月、OpenAIが発表した Realtime API は、音声入出力をリアルタイムで処理できるAPIとして大きな注目を集めました。音声から音声への一気通貫した処理（Speech-to-Speech）が可能になることで、ボイスボットや音声対話AIアシスタントの可能性が一気に広がったのは記憶に新しいところです。
さて、このRealtime APIですが、OpenAIは性能評価のために3つのベンチマークを使用しています。しかし、それぞれが何を測定しているのか、詳しく解説された記事は意外と少ないのではないでしょうか。AI Shiftでも AI Worker VoiceAgent といった音声対話AI領域のプロダクト開発を進めており、こうした性能評価の手法には大きな関心を持っています。
本記事では、これら3つのベンチマークの背景と評価内容を詳しく解説し、日本語化したデータセットを用いた実際の評価結果もご紹介します。音声対話AIの評価手法に興味のある方、あるいは自社サービスの音声対応を検討されている方にとって、参考になれば幸いです。
評価ベンチマークの全体像
OpenAI Realtime APIの評価には、以下の3つのベンチマークが使用されています。
| ベンチマーク名 | 評価対象カテゴリ | 概要 |
|---|---|---|
| Big Bench Audio | 推論能力 (Intelligence) | 音声入力からの論理的思考・判断能力 |
| MultiChallenge (Audio) | 指示追従 (Instruction Following) | マルチターン会話での文脈維持・指示順守 |
| ComplexFuncBench Audio | 関数呼び出し (Function Calling) | 外部ツール（関数）の適切な呼び出し能力 |
それぞれ異なる観点からモデルの性能を測定しており、単なる文字起こし精度では測れない、音声対話AIならではの能力を評価していることがわかります。
ここからは各ベンチマークについて詳しく見ていきましょう。
1. Big Bench Audio：音声からの推論能力を測る
概要
Big Bench Audioは、大規模言語モデルの推論能力を測る有名なベンチマーク 「Big Bench Hard (BBH)」 の中から、音声でも公平に評価できる4つのカテゴリを抜粋し、音声化したデータセットです。
単なる文字起こしではなく、内容を理解して答えを導き出せるかが問われます。
収録されているタスク
合計 1,000件 の音声データが含まれており、各カテゴリ250問ずつで構成されています。
| カテゴリ | 内容 |
|---|---|
| Formal Fallacies（形式的誤謬） | 前提条件から主張の正誤（Valid/Invalid）を判定 |
| Navigate（ナビゲーション） | 移動指示を追跡し、元の位置に戻るか判断 |
| Object Counting（物体カウント） | 読み上げられた物品の特定カテゴリ合計数を回答 |
| Web of Lies（嘘の網） | 複雑な真偽関係からブール論理を評価 |
音声データの特徴
OpenAI、Microsoft Azure、Amazon (AWS Polly) のTTSモデルを使用し、23種類の異なる「声」 がランダムに使用されています。これにより、特定の声質への過学習を防ぐ設計になっています。
ベンチマーク結果
（出典: Evaluating Audio Reasoning with Big Bench Audio - Hugging Face）
2. MultiChallenge：長い会話における指示追従性能を測る
なぜこのベンチマークが必要なのか
既存の会話ベンチマーク（MT-Benchなど）では、最新モデルがほぼ満点を取ってしまい、能力差を測れなくなっていました。しかし実際の運用では、人間との長く複雑な会話でAIはまだ多くの失敗をしています。
MultiChallengeは、人間とのリアルで複雑なやり取りにおいて、AIが文脈を理解し、推論し、指示を守り続けられるかを評価するために開発されました。
4つの主要な課題カテゴリ
MultiChallengeは、現在のAIが特に苦手とする4つのカテゴリに焦点を当てています。
| カテゴリ | 内容 | 例 |
|---|---|---|
| Instruction Retention | 会話冒頭のルールを最後まで守れるか | 「常に箇条書きで答えて」を最後まで守る |
| Inference Memory | 会話中の些細な情報を記憶・活用できるか | 「ナッツアレルギー」を覚えてデザート推薦時に配慮 |
| Reliable Versioned Editing | 「さっきの案に戻して」等の編集指示に対応 | バージョン管理と正確な修正 |
| Self-Coherence | 自身の過去発言と矛盾しないか | ユーザーに迎合せず正しい回答を維持 |
驚くほど低い正解率
今となっては少し古いモデルですが、以下のような主要なモデルでも正解率が低くなっており、このベンチマークの難易度の高さが窺えます。
| モデル | 正解率 |
|---|---|
| Claude 3.5 Sonnet | 41.4% |
| o1-preview | 37.2% |
| GPT-4o | 12.5% |
| Llama 3.1 405B | 14.9% |
（出典：MultiChallenge: A Realistic Multi-Turn Conversation Evaluation Benchmark Challenging to Frontier LLMs）
この結果から、「長い会話の中で文脈を維持し、論理的に推論し続ける能力」 が、現在のLLMにとっていかに難しいかがわかります。
3. ComplexFuncBench：複雑なFunction Calling性能を測る
既存ベンチマークの限界
既存のベンチマーク（API-BenchやToolBenchなど）は、パラメータが明示的で単発の呼び出しで済む単純なタスクが中心でした。
しかし実世界では、以下のような要求が存在します：
「クリスマスイブの前日にワシントンからNYへの最安便を探し、その到着1時間後にタクシーを手配して」
ComplexFuncBenchは、このような複雑な要求に対応できるかを評価します。
複雑な関数呼び出しの5つの定義
| 要素 | 内容 |
|---|---|
| Multi-Step | 複数のAPIを順序立てて呼び出す |
| Constraints | 「最安値」「到着1時間後」等の制約を守る |
| Parameter Reasoning | 「クリスマスの前日」→「12月24日」を推論 |
| Long Parameter Values | 認証トークン等の長い文字列を正確に扱う |
| Long-Context | 最大128kトークンの検索結果を読み解く |
評価結果
主要なモデルでもこのタスクには苦戦しています。
| モデル | 正解率 |
|---|---|
| Claude 3.5 Sonnet | 61.0% |
| GPT-4o | 60.5% |
| Qwen2.5-72B | 40.1% |
| Llama 3.1シリーズ(8B, 70B, 405B) | 0〜10%台 |
（出典：https://github.com/zai-org/ComplexFuncBench?tab=readme-ov-file#leaderboard）
最も多かったエラーは 「Value Error（値の間違い）」 です。長いコンテキストの中から正しい情報を抽出し、推論してパラメータにセットすることが、現在のLLMにとって大きな課題であることが示されました。
日本語化データセットでの評価
ここからは、ComplexFuncBenchとMultiChallengeの一部を日本語化し、Realtime API（音声入力） と Chat Completions API（テキスト入力） を比較評価した結果をご紹介します。
日本語データセットの作成方法
- ComplexFuncBench: HuggingFaceからオリジナル（英語）をダウンロードし、Gemini 2.5 Flashで日本語に翻訳。各ドメインから5件ずつ抽出（計25件）。
- MultiChallenge: 各評価軸（Instruction Retention, Inference Memory, Self-Coherence, Reliable Version Editing）から5件ずつ抽出（計20件）し、Gemini 2.5 Flashで翻訳。
- 音声化: 翻訳した日本語テキストをGoogle Cloud TTS（Chirp3_HD、24kHz）で音声ファイルに変換（Realtime APIの処理時に16kHzに変換）。
評価設定
| 項目 | Realtime API | Chat Completions API |
|---|---|---|
| モデル | gpt-realtime | gpt-4o |
| 入力 | 音声（TTS: Google Chirp3_HD） | テキスト |
| 出力 | テキスト | テキスト |
| 言語 | 日本語 | 日本語 |
ComplexFuncBench 日本語版：Function Calling評価
評価概要
- 評価件数: 25件（各ドメイン5件ずつ）
- ドメイン: 観光地検索、レンタカー、ホテル、フライト、複合検索の5種類
- 評価方式: マルチターン（ターン１で情報取得 → ターン2で詳細検索）
評価結果
| ドメイン | 内容 | Realtime API | Chat Completions API |
|---|---|---|---|
| Attraction | 観光地検索 | 5/5 | 5/5 |
| Car-Rental | レンタカー検索 | 5/5 | 5/5 |
| Hotels | ホテル検索 | 5/5 | 5/5 |
| Cross | 複合検索（観光+ホテル） | 3/5 | 4/5 |
| Flights | マルチストップフライト | 2/5 | 5/5 |
表中の分数は成功したサンプル数/全サンプル数を表します。
単純なタスクは両者とも完璧
観光地検索、レンタカー、ホテル検索のような 「1つの情報を取得 → 1つの検索を実行」 という単純な2ステップタスクでは、両モデルとも100%の成功率を達成しました。
例えば、このようなタスクです：
ユーザー: 「マンチェスターで人気の観光スポットを教えて」
ターン１: Search_Attraction_Location(query="マンチェスター") → 場所IDを取得
ターン２: Search_Attractions(id="eyJ1ZmkiOi0yNjAyNTEyfQ==", sortBy="trending")
差が出たのは並列タスク
大きな差が出たのは Flights ドメイン です。
このタスクは「ロサンゼルス → パリ → ロンドン」のようなマルチストップフライト（出発地から最終目的地までに1回以上の途中降機や乗り継ぎを含むフライト）を検索するもので、3つの都市の空港IDを同時に取得 する必要があります。
Chat Completions APIの挙動：
ターン１: [
Search_Flight_Location(query="ロサンゼルス"),
Search_Flight_Location(query="パリ"),
Search_Flight_Location(query="ロンドン")
] ← 3つ同時に実行
ターン２: Search_Flights_Multi_Stops(legs=[...]) ← 正しく検索
Realtime APIの挙動：
ターン１: Search_Flight_Location(query="ロサンゼルス") ← 1つだけ
ターン２: Search_Flight_Location(query="パリ") ← まだ検索を続けようとする
Realtime APIは APIの仕様あるいは音声入力の曖昧さゆえか、1つずつ順番に処理する傾向 がありました。Chat Completions APIのように1ターンで複数の関数を同時実行することが苦手なようです。
MultiChallenge 日本語版：マルチターン会話評価
評価概要
MultiChallengeは、マルチターン会話における4つの能力を評価するベンチマークです。先述の通り、Instruction Retention、Inference Memory、Self-Coherence、Reliable Version Editingという４つの評価軸があります。
以下の設定で評価を行います。
- 判定: GPT-4oによるジャッジが、基準に対してYES/NOで判定
- データセット: 各評価軸から5件ずつ、合計20件のシナリオを抽出
- ターン数: 2〜9ターン（平均4.5ターン）
- 評価方式: 会話履歴をシステムプロンプトに含め、最終ユーザー発言のみを音声/テキストで入力
評価結果
| 評価軸 | 内容 | Realtime API | Chat Completions |
|---|---|---|---|
| Instruction Retention | 最初の指示を守り続ける | 2/5 (40%) | 1/5 (20%) |
| Inference Memory | 過去の情報を活用する | 0/5 (0%) | 0/5 (0%) |
| Self-Coherence | 自分の発言と矛盾しない | 0/5 (0%) | 0/5 (0%) |
| Reliable Version Editing | 編集指示に正確に対応 | 2/5 (40%) | 2/5 (40%) |
定性分析
ここからは、実際にどのような推論結果が得られたのかを具体例を挙げて見ていきましょう。
【失敗例1】「20以内で答えて」を忘れる
シナリオ: 社会学的理論を「20字以内」で説明することを最初に指示
| ターン | 発言 |
|---|---|
| User | 社会学的問題を説明する理論を挙げて。20字以内で説明して |
| Assistant | 「社会的不平等：階級闘争」「人種差別：構造的人種差別」 |
| User | 文化的価値観が社会包摂をどう形成するか説明して |
このサンプルの場合、Assistantの期待される応答は例えば「文化資本理論：社会的地位決定」のように、20字以内で簡潔な回答です。
実際の応答：
Realtime API: 「かしこまりました。文化的な価値観は、集団内で共有される信念や理想、
倫理観などを基盤として、どのような行動が望ましいか、どのような態度が適切かと
いった規範を定めます。これによって、集団内の人々は互いに期待される振る舞いを
理解し、それに沿って行動するようになります…」（長文説明）
Chat Completions API: 文化的な価値観は、社会の中で何が重要であるか、何が望ましいかを
定義します。これらの価値観は、集団がどのように他者を受け入れ、扱うべきかという
規範や態度を形成します。たとえば、個人主義的な文化では、個人の自由や独立が重視
されるため、多様性が尊重されやすくなります…」（長文説明）
両方とも「20字以内」という制約を完全に忘れてしまいました。
【失敗例2】国連本部の場所を忘れる（文脈喪失）
シナリオ: 国連本部から徒歩5分圏内のレストランを依頼（3ターンの会話）
| ターン | 発言 |
|---|---|
| User | 国連本部で働いています。徒歩5分圏内の場所を希望 |
| Assistant | いくつかの場所を紹介（ダグ・ハマーショルド・プラザなど） |
| User | ドイツ外交官との昼食に適した高級レストランを紹介して |
ここで期待されるAssistantの応答の例は、
国連から徒歩3分、多くの外交官が通う1966年創業の「スパークス・ステーキハウス」は、重厚な雰囲気の中で最高級サーロインと圧巻のワインリストを楽しめる老舗です。
のようなものです。
実際の応答：
Realtime API: 「アルカディア東京」「トロワフレーシュ」
→ 東京のレストランを提案。国連本部（ニューヨーク）という文脈を無視。
Chat Completions API: 「アクアヴィット」「ル・ベルナルダン」
→ ニューヨークのレストランだが、徒歩5分圏内ではない
Realtime APIは「ニューヨーク」という文脈よりも日本語の音声入力に引きずられたのか、東京の店を提案してしまいました。文脈維持（INFERENCE_MEMORY）の弱さが露呈した興味深い例です。
【失敗例3】自分が言った「1390万人」を忘れる
シナリオ: 歯科セミナー開催都市の相談（5ターンの会話）
| ターン | 発言 |
|---|---|
| User | 人口の多い都市を提案して |
| Assistant | 東京：1,390万人以上、ロサンゼルス：約390万人など |
| User | ロサンゼルスに興味。人口500万人を超えているので最適 |
| Assistant | （詳細を説明、人口については訂正せず） |
| User | 東京は人口2000万人を超えているので最善の選択肢かも |
ここで期待されるAssistantの発話は、「東京の人口は先ほどお伝えした通り約1,390万人です」とユーザーの誤りを訂正するようなものです。
実際の応答：
Realtime API: 「東京は確かに人口が2,000万人を超える大都市圏であり...」
→ ユーザーの誤り（2000万人）にそのまま追従
Chat Completions API: 「東京の人口は約1,400万人で、首都圏全体では...」
→ 1,390万人の概算なので、実質的には正しい応答
Realtime APIはユーザーの誤りにそのまま追従してしまいました。 一方、Chat Completions APIの「約1,400万人」は実質的に正しい回答ですが、LLM as a Judgeが厳密な数字を求めたため不合格と判定されてしまいました。
【成功例】講義アウトラインの編集
シナリオ: 講義アウトラインを作成し、追加編集を依頼
| ターン | 発言 |
|---|---|
| User | 冷戦イデオロギーがハリウッド映画に与えた影響の講義アウトラインを作成して |
| Assistant | I〜VIIのセクションからなる詳細なアウトライン |
| User | 個人的な体験談のセクションを追加して |
この特定のシナリオでは両モデルとも成功。 講義アウトライン形式を維持しながら、新しいセクションを適切に追加できました。
「形式を維持しながら編集する」というタスクは、他の評価軸と比較してLLMが比較的得意とする領域のようです。
おわりに
本記事では、OpenAI Realtime APIの評価に使用された3つのベンチマーク（Big Bench Audio、MultiChallenge、ComplexFuncBench）について解説し、日本語化したデータセットでの実際の評価結果をご紹介しました。
評価の結果、単純なFunction Callingタスクでは音声入力でも高い成功率を達成できる一方で、並列タスクや長期的な文脈維持では課題があることがわかりました。
また、実際のプロダクト開発においては、こうした「内容の正確さ」に加えて「対話の心地よさ」も欠かせない要素です。 応答音声の韻律の自然さや、割り込みを含めたターンテイキングのタイミングなど、今後は音声対話ならではの振る舞いをどう評価していくかが、重要なテーマになっていくと考えています。
音声対話AIの導入を検討されている方は、ぜひこれらのベンチマークを参考に、自社のユースケースに合った評価を行ってみてください。
長くなってしまいましたが、最後までお読みいただき、ありがとうございました！
最後に
AI Shiftではエンジニアの採用に力を入れています！ 少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？ （オンライン・19時以降の面談も可能です！）
【面談フォームはこちら】
https://hrmos.co/pages/cyberagent-group/jobs/1826557091831955459
