はじめに
OpenAI が提供する Realtime API ファミリの中で、Speech-to-Speech 翻訳に使えるのは 2 系統あります：
-
gpt-realtime-translate— 翻訳に特化した専用モデル -
gpt-realtime-2（+reasoning.effort） — 汎用 Realtime モデルを翻訳役にプロンプトする方式
リアルタイム AI 翻訳アプリ Sokuji ではこの両方を実装し、ユーザーが UI から切り替えられるようにしています。本記事は、1 ヶ月以上両方を本番で使い分けてわかった**「結局どちらを使うべきか」**の判断材料を、ユースケース別マトリクスとして整理します。
シリーズの第 3 回（最終回）：
- gpt-realtime-translate 実装で踏んだ 4 つの罠
- gpt-realtime-2 の reasoning.effort を 5 段階全部試した
- 翻訳用途：gpt-realtime-translate vs gpt-realtime-2 完全比較ガイド ← 今回
全体比較マトリクス
| 項目 | gpt-realtime-translate |
gpt-realtime-2 |
|---|---|---|
| 設計思想 | 翻訳専用、極小 API | 汎用エージェント、prompt で翻訳役化 |
| WebSocket |
/v1/realtime/translations ✅ |
/v1/realtime ✅ |
| WebRTC |
/v1/realtime/translations/calls ✅ |
❌ 現時点で非対応（mini / -1.5 のみ対応） |
| GA / Beta | GA only | GA / Beta |
| 入力言語 | 75 言語（auto-detect） | prompt 次第（任意） |
| 出力言語 | 13 言語固定 | prompt 次第（任意、精度は学習量依存） |
instructions |
❌ | ✅ |
tools / tool_choice
|
❌ | ✅ |
voice 選択 |
❌（自動） | ✅ alloy / verse など |
turn_detection カスタマイズ |
❌（内蔵） | ✅ server_vad / semantic_vad |
reasoning.effort |
❌ | ✅ minimal / low / medium / high / xhigh |
| 転写モデル |
gpt-realtime-whisper 固定 |
gpt-4o-transcribe など選択可 |
| ノイズ抑制 | near_field / far_field | near_field / far_field |
| 接続〜初音声 | 約 600–900 ms（WS）/ 800–1200 ms（WebRTC）※実測値で要差し替え | 約 600–900 ms（WS のみ、WebRTC 非対応） |
| ハートビート処理 | 必要（200ms 4800-sample frame） | 不要 |
| 価格レンジ（公式） | OpenAI pricing 参照 | 同左、reasoning.effort で実コスト変動 |
API 設計思想の違い
両者は単に「機能数の多寡」ではなく、設計思想がそもそも違う API です。
gpt-realtime-translate ＝ 翻訳専門ピペライン
session.update で送れるのは output 言語と入力転写モデル、ノイズ抑制くらい。instructions も tools も voice も無い：
{
type: 'session.update',
session: {
audio: {
output: { language: 'ja' }, // 13 のいずれか
input: {
transcription: { model: 'gpt-realtime-whisper' },
noise_reduction: { type: 'near_field' },
}
}
}
}
「Sokuji 用の翻訳口調を作りたい」「ですます調を強制したい」「専門用語を辞書化したい」といった調整はそもそも API として受け付けない。
代わりに翻訳の精度・レイテンシは内部で最適化済みで、開発側がチューニングしなくてもそこそこの品質が出る、という設計。
gpt-realtime-2 ＝ 汎用 Realtime エージェント
汎用エージェントなので翻訳役にするには instructions で「あなたは翻訳者です。原文を○○語に訳してください。説明はしないでください」のように書きます。
その代わり、触れるところは多い：
-
instructionsで口調・敬語レベル・専門ドメインの指示 -
voiceでアシスタントの声を変える -
turn_detectionで発話区切りの感度調整（threshold / prefix_padding / silence_duration） -
reasoning.effortで思考量チューニング（minimal → xhigh） -
temperatureならぬreasoning.effortで間接的にランダム性制御
「シンプルに動かしたいなら translate、細かく制御したいなら -2」 が一行サマリ。
言語サポート比較
ここが最大の判断ポイント。
translate：75 in / 13 out 固定
入力 75 言語（auto-detect）、出力 13 言語：
en, es, pt, fr, ja, ru, zh, de, ko, hi, id, vi, it
- 言語コードは 粗い ISO 639-1 のみ（zh_CN や pt_BR は不可）
- 出力 13 にない言語へ訳したい場合（例：日本語 → タイ語、日本語 → アラビア語）はそもそもできない
- 双方向トリビアルに通訳できるのは 13 言語間のみ
gpt-realtime-2：prompt 次第で任意
instructions に「タイ語に訳してください」と書けば原則動きます。ただし：
- 学習量の少ない言語は精度が下がる
- 出力音声の音質も言語依存（メジャー言語ほど自然）
- 訳出言語のスペル / 正書法の安定性は translate のほうが安心
判断ルール：
出力先が 13 言語に含まれる → translate を選ぶのが普通
出力先が 13 言語にない → gpt-realtime-2 一択
Sokuji もこの基準で UI を出し分けています（translate 選択時は出力 dropdown が 13 言語）。
レイテンシ・スループット
reasoning.effort を上げない gpt-realtime-2 と、gpt-realtime-translate の素のレイテンシはほぼ拮抗します（Sokuji 内での体感）。差が顕著に出るのは：
-
gpt-realtime-2でreasoning.effortをmedium以上に上げた時 → 数百 ms から秒単位で遅くなる -
gpt-realtime-translateのハートビート構造（200ms 単位の規則的な keep-alive）→ ジッタが安定し、UI 上の「翻訳中…」表示が安定する
会議・配信のように 「テンポ命」のシナリオでは translate のジッタの安定性が効く、というのが Sokuji を運用しての実感です。
翻訳品質
ここは公開された第三者ベンチマークが少なく、評価が難しいゾーンです。前回記事で参照した Scale AI Labs の AudioMultiChallenge は会話的知能の指標で、翻訳精度そのものではないですが、参考にはなります：
-
gpt-realtime-2 (xHigh)：48.45（Gemini 2.5 Pro 超え） -
gpt-realtime-2（reasoning なし）：37.61 -
gpt-realtime-translate：leaderboard には不在
translate が leaderboard にいないのは、評価軸が「会話エージェントとしての汎用知能」だから。翻訳特化モデルを汎用知能で測るのはフェアでない、という運営側の判断とみられます。
実運用での主観的観察（Sokuji ユーザーフィードバック含む）：
| 観点 | translate | gpt-realtime-2（low） | gpt-realtime-2（xhigh） |
|---|---|---|---|
| 直訳の正確さ | ◎ 安定 | ○ | ◎ |
| 敬語・口調 | △ 一律 | ○ 指示で変えられる | ◎ 指示が効く |
| 専門用語 | ○ | △ | ◎ |
| 自然な意訳 | ○ | △ | ◎ |
| 訳抜け / 補完 | △ 訳抜けあり | ○ | ○ |
| ハルシネーション | ◎ ほぼなし | △ instructions で抑制必要 | △ 高 effort で増えがち |
「直訳の正確さ」だけ見ると translate が安定、「丁寧さ・口調制御」では -2 + 高 effort が勝ち、というのが大まかな図式です。
コスト
OpenAI の Pricing を参照ください。一般論として：
-
gpt-realtime-translateは単価が安い傾向（翻訳特化なので推論量が少なく済む） -
gpt-realtime-2は単価が高い +reasoning.effortを上げると tokens 消費が増えて実質コストがさらに上がる
長時間の会議翻訳（1 時間以上）を継続的に運用する場合、コスト差は無視できません。Sokuji ではユーザーが「自分の API キー」で使う前提なので、UI に reasoning.effort のラベルを置きつつ「上げると遅くなる + 高くなる」と注意書きを出しています。
カスタマイズ性
| 触りたいもの | translate | gpt-realtime-2 |
|---|---|---|
| 翻訳口調（敬語 / カジュアル） | ❌ | ✅ instructions |
| 専門用語辞書 | ❌ | ✅ instructions に列挙 |
| 出力声優の選択 | ❌ | ✅ voice |
| 発話区切りの厳しさ | ❌ | ✅ turn_detection |
| 思考時間の調整 | ❌ | ✅ reasoning.effort |
| 速度・音程 | ❌ | ❌ |
「触れる範囲」だけ見ると -2 が圧勝。ただし触る量が増えると安定運用のチューニングコストも増えるので、ここはトレードオフ。
ユースケース別おすすめマトリクス
ここまでの整理を踏まえた選び方ガイド：
| シーン | 推奨 | 理由 |
|---|---|---|
| Zoom / Meet / Teams の社内会議翻訳 | translate | テンポ重視、出力は主要 13 言語で足りる、運用が楽 |
| 配信通訳（Vtuber、ライブイベント） | translate | 即時性最優先、ジッタが安定 |
| 多言語イベント（13 言語に含まれる） | translate | 言語追加コスト 0 |
| 出力先が日中英以外のマイナー言語 | gpt-realtime-2 | translate に対応がない |
| 商談・面接（敬語が重要） | gpt-realtime-2 + medium | 口調を instructions で制御 |
| 技術プレゼン / 学会 | gpt-realtime-2 + high or xhigh | 専門用語の整合性が要る |
| 契約交渉 / 法律 / 医療 | gpt-realtime-2 + xhigh | 最高品質要、レイテンシ犠牲 OK |
| 字幕付き動画の事前生成（バッチ） | gpt-realtime-2 + xhigh | リアルタイム性不要、品質最優先 |
| 個人の即時通訳（雑談、海外旅行） | translate | コスト・テンポ・運用シンプル |
| ゲーム配信のチャット返信通訳 | translate または -2 minimal | 即時性最優先 |
ざっくりした原則：
- 出力 13 言語で足りる + 即時性優先 → translate
- 出力言語のカバレッジが足りない or 制御したい → gpt-realtime-2
- 品質最優先（レイテンシ・コスト犠牲 OK）→ gpt-realtime-2 + xhigh
Sokuji での使い分け実装
Sokuji ではユーザーが UI 上で provider を切り替えられるよう、両者を IClient インタフェース配下で抽象化しています：
src/services/clients/
├── OpenAIGAClient.ts # gpt-realtime-mini / -1.5 / -2 (WebSocket)
├── OpenAIWebRTCClient.ts # gpt-realtime-mini / -1.5 (WebRTC) ※-2 は WebRTC 非対応
├── OpenAITranslateGAClient.ts # gpt-realtime-translate (WebSocket)
└── OpenAITranslateWebRTCClient.ts # gpt-realtime-translate (WebRTC)
UI から見た時の差は ProviderConfig.capabilities の flag で吸収します：
// OpenAIProviderConfig.ts (gpt-realtime-2)
capabilities: {
hasReasoningEffort: true,
hasTurnDetection: true,
hasVoiceSettings: true,
// ...
}
// OpenAITranslateProviderConfig.ts (gpt-realtime-translate)
capabilities: {
hasReasoningEffort: false,
hasTurnDetection: false,
hasVoiceSettings: false,
hasSilenceDuration: true, // translate 専用：UI 側で発話セグメンテーションの閾値だけ調整
// ...
}
Settings UI 側はこの capability を見て、reasoning.effort スライダや voice ドロップダウンを出し分けています。**「同じ会話履歴 UI で両モデルを使い回せる」**のがユーザー体験上のキモです。
おわりに
ここまで見てきた通り、両者は「優劣」ではなく 「設計思想が違う API」 で、ユースケース次第で正解が変わります。
迷ったら最初は gpt-realtime-translate から試すのが無難です。理由：
- 設定が極小（言語と転写モデルだけ）で踏むハマりが少ない
- 安定したジッタで会議・配信に強い
- コストが低めで気軽に長時間運用できる
それで物足りなくなったら（出力言語が足りない / 口調を変えたい / 専門用語が崩れる）、gpt-realtime-2 に切り替えて reasoning.effort を low → medium → high と段階的に上げていく、というルートが Sokuji ユーザーの実際の遷移パターンに近いです。
両方を 1 click で切り替えながら使い分けたい方へ：Sokuji は OSS で、本記事の比較構成をそのまま実装しています。Chrome 拡張 / Electron どちらでも動作します：
- GitHub: https://github.com/kizuna-ai-lab/sokuji
- Web サイト: https://sokuji.kizuna.ai