音声のリアルタイム翻訳は、これまでSTT（文字起こし）→ 翻訳 → TTS（音声合成）を自前で組み合わせて実現していました。各段階の遅延が積み上がるため、レイテンシが課題になります。
この検証では、音声翻訳専用モデル gpt-realtime-translate を使い、speech-to-speechの翻訳アプリを実装して疎通まで確認しました。従量課金は $0.034/分です。
この検証の概要
検証日 | 2026年5月8日 |
|---|---|
対象 | OpenAI Realtime API（ |
検証内容 | speech-to-speechリアルタイム翻訳のWebSocket実装、言語切替、字幕/会話ログ保存 |
技術スタック | Next.js 16 + React 19 + Zustand / Custom Server / AudioWorklet |
結果 | 実API接続・マイク入力・翻訳音声/字幕・会話ログ保存まで確認済み |
コスト | $0.034/分（30分連続利用で約$1.02） |
判定 | 条件付きで導入可（★4/5） |
結論：通常のRealtime APIとは別物として扱う
この検証で最も重要な学びです。
Realtime Translationは、通常のRealtime APIとイベント名・ライフサイクルが違います。通常のRealtime APIの知識だけで実装すると、誤った実装になります。
実際、初期実装は「WebSocket接続もボタン操作もマイク入力も動くが、出力言語を変えてもスペイン語が返る」という状態でした。
項目 | Realtime Translation |
|---|---|
接続先 |
|
Betaヘッダー | GA APIなので |
出力言語の指定 |
|
音声入力イベント |
|
出力イベント |
|
入力書き起こし | デフォルト無効。 |
| 使わない（モデルは「通訳」として動く） |
会話応答をしないという点が、通常のRealtime APIとの根本的な違いです。連続ストリームを受け取り、翻訳して返し続けるだけの動作になります。
Betaヘッダーが原因だった
「出力言語が反映されない」問題の原因はこれでした。
OpenAI-Beta: realtime=v1 を付けたことで、GA Translation APIがベータRealtime APIとして扱われ、session.audio がunknown parameterになっていました。
エラー | 原因 | 対処 |
|---|---|---|
| Betaヘッダーを付けている | Translation endpointではBetaヘッダーを外す |
| ベータ互換モードで処理されている | Betaヘッダー削除、endpoint確認 |
「以前のバージョンで必要だったヘッダーが、GA後は逆にエラーの原因になる」——APIの世代が変わるときによくある落とし穴です。
「スペイン語が返る」の正しい確認方法
デバッグ時の観測知見として、これは押さえておく価値があります。
session.created ... audio.output.language: "es"
session.updated ... audio.output.language: "en"session.created の時点では初期値として "es" が返りますが、直後の session.updated でUI選択値に変わります。
つまり「最初にcreatedでSpanishが見える」こと自体は問題ではありません。確認すべきは session.updated の言語です。
最初のログだけを見て原因を判断すると、正常な挙動をバグとして追いかけることになります。
会話ログが残らない問題
もう1つの実装上の落とし穴です。
会話ログが *.done イベント依存だったため、ライブ表示には出るがログに残らないケースがありました。
対処は、*.done だけでなく、停止/close時にlive transcriptをflushする設計にすることです。
ストリーミング処理では「完了イベントが必ず来るとは限らない」前提で保存設計を組む必要があります。
アーキテクチャ：なぜサーバproxyを挟むのか
ブラウザ/PC
↕ WebSocket
Next.js custom server / Node.js
↕ WebSocket
OpenAI Realtime Translation API理由は明確です。ブラウザのWebSocketは任意のAuthorizationヘッダを付けられないため、サーバ側proxyを使う必要があります。APIキーをブラウザに出さずに済みます。
この構成は仕組みの理解とデバッグには向いています。サーバログで session.created / session.updated / error を追えます。
ただし公開運用では課題があります。自前サーバがクライアント接続とOpenAI接続の両方を長時間保持するため、WebSocketを保持できる実行環境が必要になります。
公開時のホスティング選定
候補 | 判定 | 理由 |
|---|---|---|
Render Web Service | 有力 | WebSocket対応。Node.js構成をそのまま載せやすい |
Google Cloud Run | 有力 | WebSocket対応。Docker化しやすい（timeoutと再接続設計は必要） |
Railway | 次点 | WebSocket対応。接続時間制限を前提に設計する |
VPS / Fly.io / EC2 | 可能 | 常駐プロセスを持てるため相性はよい |
Serverless Functions | 不向き | WebSocket常時接続を保持できない（Streaming/SSEとWebSocketは別物） |
共用レンタルサーバ | 不向き | 常駐Node.jsプロセス・リバースプロキシ管理が難しい |
Serverless FunctionsでWebSocketは保持できません。StreamingやSSEに対応していることと、WebSocketを保持できることは別問題です。
使う場合はフロントエンドだけをServerless環境に、Realtime中継は常駐可能な環境に分ける構成になります。
本番構成はWebRTC + client secret
スマホ/ブラウザ向けの本番では、構成を変えるのが自然という判断です。
スマホ/ブラウザ
↕ WebRTC
OpenAI Realtime API
自前バックエンド
→ 短命client secretを発行するHTTP endpointのみ自前バックエンドが長時間WebSocketを中継しなくなるのが最大の利点です。サーバはAPIキーを保持し、短命のclient secretを渡すだけになります。
メリット | 注意点 |
|---|---|
モバイルブラウザの音声通信に向いている | WebRTC実装へ作り替える必要がある |
自前サーバの接続数/帯域負荷を抑えられる | セッション発行APIに認証・レート制限が必要 |
Serverless環境でも実装しやすい | モバイルのマイク許可・自動再生制限の検証が必要 |
レイテンシ面でも有利になりやすい | 翻訳ログの保存設計が別途必要 |
コスト感
$0.034/分を1ドル150円で換算すると約5.1円/分です。
利用量 | API原価の目安 | 用途イメージ |
|---|---|---|
10分/日 × 20営業日 | 約1,020円/月/人 | 旅行・軽い接客補助 |
60分/日 × 20営業日 | 約6,120円/月/人 | 社内会議・営業同行レベル |
4時間/日 × 20営業日 | 約24,480円/月/人 | 通訳端末/SaaSの法人価格帯と比較対象 |
8時間/日 × 20営業日 | 約48,960円/月/人 | 常時通訳用途 |
使用時間によって、既存サービスとの損得が逆転します。「APIのほうが安い」と一括りにはできません。
開発コストの見積もりも整理しています。
構成 | 初期開発 | 月額運用 |
|---|---|---|
個人用PWA / 社内PoC | 数日〜2週間 | API費用 + 数千円のホスティング |
社内向けスマホWebアプリ | 2〜6週間 | API費用 + 認証/ログ基盤 |
アプリストア配布 | 1〜3か月 | API費用 + 保守 |
法人向けSaaS | 3〜6か月以上 | API費用 + 管理画面/監査/サポート |
対応言語の制約
- 入力は70以上の言語を自動検出
- 出力は13言語に限定（Spanish, Portuguese, French, Japanese, Russian, Chinese, German, Korean, Hindi, Indonesian, Vietnamese, Italian, English）
この検証では初期実装のUIに非対応言語（Arabic, Turkish等）が含まれており、UIは公式対応の13言語に絞るという修正を行っています。
選べるのに動かない選択肢をUIに残すと、原因の切り分けが難しくなります。
実運用で必要になる設計項目
PoCから本番へ進むために必要な項目です。
- HTTPS/WSS対応、APIキーのサーバ側管理、ユーザー認証
- セッション単位の時間制限、利用量/課金ログ
- 切断時の再接続、ping/pong keepalive
- 会話ログの保存/削除ポリシー
- 個人情報/機密情報を扱う場合の同意導線
- モバイルブラウザのバックグラウンド/画面ロック時の挙動確認
特にプライバシー面は重要です。会議・通話・配信で利用する場合は、参加者に翻訳処理と外部API送信を明示する必要があります。字幕/会話ログに個人情報が含まれる可能性もあります。
医療・法律・金融など高リスク領域では、人間レビューや免責設計が必要です。
よくある質問
従来のSTT→翻訳→TTS構成と何が違いますか？
3つのAPIを組み合わせる必要がなく、各段階の遅延が積み上がりません。実装量が減り、低レイテンシなライブ翻訳体験を短時間で試せます。一方でカスタムプロンプトやvoice選択といった細かい制御は限定的です。
出力言語が反映されません
まず OpenAI-Beta: realtime=v1 を付けていないか確認してください。GA APIのため、これを付けるとベータ互換モードで処理され session.audio が無効になります。また session.created ではなく session.updated の言語を見てください。
Serverless環境にデプロイできますか？
WebSocket proxy構成では不向きです。Serverless FunctionsはWebSocketの常時接続を保持できません。RenderやCloud Runなど常駐可能な環境か、WebRTC + client secret方式への移行が必要です。
コストはどのくらいですか？
$0.034/分（1ドル150円換算で約5.1円/分）です。1日1時間・月20営業日で約6,120円/人という計算になります。使用時間によって既存サービスとの損得が変わります。
まとめ
- Realtime Translationは通常のRealtime APIと別物。イベント名・ライフサイクルが異なり、通常APIの知識だけでは誤実装しやすい
- GA APIのため
OpenAI-Beta: realtime=v1はエラーの原因になる - 出力言語の確認は
session.createdではなくsession.updatedを見る - 会話ログは
*.done依存にせず、停止/close時にflushする - ブラウザのWebSocketはAuthorizationヘッダを付けられないためサーバproxyが必要。ただしServerless環境では保持できない
- 本番はWebRTC + client secret方式に寄せると、サーバが長時間接続を持たずに済む
- $0.034/分。使用時間によって既存サービスとの損得が逆転する
- 入力70言語超・出力は13言語に限定
新しいAPIは、既存のAPIと似て見えても仕様が違うことがあります。公式のリファレンスでイベント名とライフサイクルを確認してから実装すると、原因不明の挙動に時間を取られずに済みます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の音声AI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。