はじめに
OpenAI の Realtime API ファミリの中で、gpt-realtime-2 だけが受け付けるパラメータがあります。reasoning.effort です。
通常の chat completions では既に存在していた概念ですが、Realtime API にも降りてきました。しかも段階は 5 つ：minimal / low / medium / high / xhigh。最後の xhigh は OpenAI のドキュメント上もあまり目立たず、API リファレンスを読み込まないと気づきにくい存在です。
本記事は、リアルタイム AI 翻訳アプリ Sokuji で gpt-realtime-2 を組み込んだ際にわかった reasoning.effort の実装上の注意点と、Scale AI Labs の AudioMultiChallenge ベンチマークに出ている定量データから、各段階の実用的な使い分け方をまとめます。
シリーズの第 2 回：
- gpt-realtime-translate 実装で踏んだ 4 つの罠
- gpt-realtime-2 の reasoning.effort を 5 段階全部試した ← 今回
- 翻訳用途：gpt-realtime-translate vs gpt-realtime-2 完全比較ガイド
reasoning.effort とは
会話モデルの思考量を制御するパラメータです。値が大きいほど、応答前にモデルが「考える」量が増え、品質は上がりますがレイテンシとコストも増えます。
Realtime API では session.update の session.reasoning.effort として渡します：
{
type: 'session.update',
session: {
type: 'realtime',
output_modalities: ['audio'],
instructions: '...',
reasoning: { effort: 'low' }, // ← ここ
// ...
}
}
5 段階：
| 段階 | 想定用途 | レイテンシ感 |
|---|---|---|
minimal |
反射的応答が要る場合（ゲーム、通訳の即時性最優先） | 最速 |
low |
バランス型。Sokuji の default | 速い |
medium |
丁寧訳、整った敬語 | 中程度 |
high |
専門用語、論理一貫性が要る場面 | やや遅 |
xhigh |
最高品質。リサーチ、契約書級の通訳 | 遅い |
罠 ①：他の realtime モデルに渡すと弾かれる
最初のハマりポイントがこれ。reasoning.effort を gpt-realtime-mini や gpt-realtime-1.5 に渡すと、サーバー側でセッションが reject されます。
公式ドキュメントには「gpt-realtime-2 のみ対応」と書いてはあるものの、エラーメッセージが直截ではないので、最初に踏むと「なぜ session.update が通らないのか」と遠回りすることになります。
実装は モデル名で gate するのが安全：
// ❌ NG: 全モデル一律で送ると mini/1.5 が落ちる
session.reasoning = { effort: config.reasoningEffort };
// ✅ OK: gpt-realtime-2 のみ適用
if (config.model?.startsWith('gpt-realtime-2') && config.reasoningEffort) {
session.reasoning = { effort: config.reasoningEffort };
}
startsWith にしているのは、将来 gpt-realtime-2-pro のようなバリエーションが来ても自動的に拾うため。
なお gpt-realtime-2 は現時点で WebRTC transport には対応していません（OpenAI 側のサーバ制限）。WebSocket transport では問題なく動作するので、reasoning.effort を使いたい場合は WebSocket 経由で接続する必要があります。Sokuji の実装でも、上記 gate は WebSocket クライアント（OpenAIGAClient.ts）が事実上の対象になっています（WebRTC クライアントにも同じ gate コードが入っていますが、現状 -2 では到達しません）。
罠 ②：GA API の session 構造は Beta から大幅に変わっている
gpt-realtime-2 は GA API のみで利用可能で、Beta 時代の Realtime API とは session 構造が結構違います。reasoning.effort と一緒に session.update を組むときに、GA-only の他の差分も同時に意識しておかないと弾かれます。
主な差分：
| 項目 | Beta | GA |
|---|---|---|
| 出力モダリティ |
modalities: ['text', 'audio']（両方可） |
output_modalities: ['text'] か ['audio']（単独のみ） |
| 最大トークン | max_response_output_tokens |
max_output_tokens |
| 音声フォーマット |
input_audio_format / output_audio_format（フラット） |
audio.input.format / audio.output.format（ネスト） |
| temperature | あり | 削除 |
| voice | session.update でいつでも変更可 | 接続時に固定、output 開始後は変更不可 |
| turn_detection | フラット |
audio.input.turn_detection にネスト |
| transcription | フラット |
audio.input.transcription にネスト |
| noise_reduction | なし or 別 | audio.input.noise_reduction |
特に注意すべきは：
-
output_modalitiesの単独制約：両方一度に欲しい（テキスト履歴を残しながら音声出力）と思っても、GA では片方だけ。テキスト＋音声欲しいなら、テキスト用と音声用で別 session を張るか、転写モデル（audio.input.transcription）を使うかの 2 択 -
voiceの接続時固定：途中で voice を切り替えるロジックを書くと no-op になる。エラーは出ないので気づきにくい -
temperatureの不在：Beta で慣れてると最初に消えてて困る。GA ではreasoning.effortでコントロールする発想に変わっている
Sokuji ではこの全差分を OpenAIGAClient.ts の sendSessionUpdate で吸収しています。
5 段階の実力差：Scale AI Labs の AudioMultiChallenge データ
ここからが本題。「reasoning.effort を上げると本当に効くのか？」「xhigh は実用範囲なのか？」という問いに、Scale AI Labs の AudioMultiChallenge leaderboard が良いデータを出しています。
AudioMultiChallenge は「会話的知能（conversational intelligence）」を測る独立ベンチマークで、
- 多ターン対話の整合性
- 指示追従
- コンテキスト統合
- 自然発話のロバスト性
を Average Pass Rate（APR、すべてのルーブリックを満たした問題の割合）で評価します（評価モデルは o4-mini、人間とのκ ≈ 0.87）。
主要モデルのスコア（高い順）：
| 順位 | モデル | APR |
|---|---|---|
| 1 | gemini-3-pro-preview (Thinking) | 54.65 ± 4.57 |
| 2 | gpt-realtime-2 (xHigh) | 48.45 ± 4.59 |
| 3 | gemini-2.5-pro (Thinking) | 46.90 ± 4.58 |
| 4 | gemini-2.5-flash (Thinking) | 40.04 ± 4.50 |
| 5 | gpt-realtime-2（reasoning なし） | 37.61 ± 4.45 |
| 6 | gemini-3.1-flash-live-preview (Thinking) | 36.06 ± 4.41 |
| 7 | gpt-realtime-1.5 | 34.73 ± 4.38 |
ここから読み取れる事実：
事実 1：xHigh は実装する価値がある（+10.84 ポイント）
gpt-realtime-2 (xHigh) の 48.45 vs gpt-realtime-2 (reasoning なし) の 37.61。差は +10.84 ポイントで、両者の信頼区間（±4.59 / ±4.45）を完全に超える有意差です。
つまり「xhigh は誤差の範囲」では決してなく、会話的タスクでは明確に効きます。
事実 2：xHigh は OpenAI 系モデルを Gemini Pro 級に押し上げる
xHigh あり：48.45、Gemini 2.5 Pro (Thinking)：46.90、Gemini 3 Pro (Thinking)：54.65。
reasoning なしの素の gpt-realtime-2 は Gemini 2.5 Flash よりやや低い順位ですが、xHigh を入れると Gemini 2.5 Pro を超え、Gemini 3 Pro に肉薄します。
事実 3：reasoning なしの -2 は -1.5 とほぼ同列
gpt-realtime-2（reasoning なし）：37.61、gpt-realtime-1.5：34.73。差は誤差範囲ぎりぎり。
つまり 「-2 を使う価値は reasoning.effort を上げてはじめて出る」。reasoning なしで -2 を選ぶ理由はあまりない、という解釈もできます（コストが高いだけ）。
gpt-realtime-translate がいない理由
ちなみに leaderboard には gpt-realtime-translate がいません。これは仕様で、AudioMC は会話エージェントとしての汎用知能を測るベンチマークなので、翻訳タスクに振り切った特化モデルは比較対象外です。
「翻訳目的なら -2 + xHigh と translate のどちらがいいか」の比較は、第 3 回の比較ガイドで扱います。
翻訳タスクでの使い分け（実用ガイド）
AudioMC は会話的知能のベンチマークなので翻訳特化ではありませんが、Sokuji を 1 ヶ月運用した実感も合わせると、翻訳でも以下のような使い分けが妥当です：
effort |
適した翻訳シーン | コメント |
|---|---|---|
minimal |
リアルタイム配信通訳、ゲーム実況 | 訳が雑になるが追従性最優先 |
low（Sokuji default） |
Zoom / Meet / Teams での会議翻訳 | レイテンシ・品質・コストのスイートスポット |
medium |
丁寧訳が要る商談、面接通訳 | 敬語の選択が安定する |
high |
技術プレゼン、論文の口頭通訳 | 専門用語の整合性が上がる |
xhigh |
契約交渉、医療通訳など最高品質要 | レイテンシ大、即時性犠牲、コストも高い |
ポイントは **「xhigh は遅いが品質代償がはっきり見えるので使い所がある」**ということ。Sokuji でも UI から 5 段階すべて選べるようにしてあります。
// OpenAIProviderConfig.ts
private static readonly REASONING_EFFORTS: ReasoningEffort[] = [
'minimal', 'low', 'medium', 'high', 'xhigh',
];
defaults: {
reasoningEffort: 'low', // Sokuji default
// ...
}
罠 ③：tool_choice: 'none' で翻訳役からのドリフトを止める
これは reasoning.effort とは直接関係ないけど、翻訳タスクで gpt-realtime-2 を使う時に必須の小ネタとして書いておきます。
gpt-realtime-2 は元々マルチモーダル汎用エージェントとして設計されており、reasoning.effort を上げると「役立とうとする欲求」も強くなる傾向があります。具体的には：
- 翻訳役を頼んだのに途中で「このフレーズは○○という意味です」と解説を始める
- 「翻訳してください」と instructions に書いても、ユーザー発話を質問と解釈して回答してしまう
- function call/tool 呼び出しを試みる（高 effort で顕著）
これを防ぐには tools を空配列 + tool_choice = 'none' で完全にロックします：
const session: any = {
type: 'realtime',
output_modalities: ['audio'],
instructions: '...あなたは翻訳者です。説明やコメントは一切しないでください...',
// 翻訳役からのドリフト防止
tool_choice: 'none',
tools: []
};
if (config.model?.startsWith('gpt-realtime-2') && config.reasoningEffort) {
session.reasoning = { effort: config.reasoningEffort };
}
tools: [] だけだと OpenAI 側がデフォルトの tool 呼び出し挙動を持ち込んでくることがあるので、tool_choice: 'none' を明示的に併用するのが鍵です。
おわりに
reasoning.effort 5 段階を整理すると：
-
minimal/low→ 即時性重視。Sokuji default はlow -
medium/high→ 丁寧訳・専門用語に効く -
xhigh→ AudioMC で +10.84 ポイント、Gemini 2.5 Pro を上回るレベル。実用価値あり
実装上の注意点：
- ✅
model?.startsWith('gpt-realtime-2')で必ず gate する（mini / 1.5 だと reject） - ✅ GA API の session 構造（output_modalities 単独、voice 固定、temperature 削除など）も同時に意識
- ✅ 翻訳役で使うときは
tool_choice: 'none'+tools: []でロック
Sokuji（OSS）では UI から 5 段階すべてを切り替えられるので、自分のユースケースで体感したい方はぜひ：
- GitHub: https://github.com/kizuna-ai-lab/sokuji
- Web サイト: https://sokuji.kizuna.ai
実装の詳細は OpenAIGAClient.ts を参照してください（gpt-realtime-2 は WebSocket transport で接続）。
次回予告
ここまで gpt-realtime-2 の reasoning.effort を見てきました。一方、前回扱った gpt-realtime-translate は reasoning.effort を持たず、API 設計そのものが翻訳特化です。
第 3 回では **「翻訳目的なら結局どちらを使うべきか」**を、レイテンシ / 言語サポート / コスト / カスタマイズ性 / Sokuji での実運用知見から、ユースケース別の選び方マトリクスとして整理します。