GPT Realtime API の料金：話す方が聴くより 4 倍高い（実測）
目次
OpenAI の Realtime API を使った音声会話は，ユーザーが話している間は 1 分あたり $0.0192，モデルが話し返している間は 1 分あたり $0.0768 かかる。話す方が聴く方のちょうど 4 倍で，この比率ひとつで音声セッションの料金のほとんどが説明できる。数字に入る前に名前の話を一つ。「GPT Live」は ChatGPT のコンシューマー向け機能で，API はない。その裏にある API 製品が gpt-realtime-2.1 と gpt-realtime-2.1-mini で，この記事で計測するのはこちらだ。
TL;DR
- gpt-realtime-2.1 は，ユーザーの発話 100 ms ごとに audio token をちょうど 1 個，モデルの発話 50 ms ごとに 1 個課金する。聴くのに 1 分あたり $0.0192，話すのに 1 分あたり $0.0768。
- server VAD で 60 秒の無音を流したところ，input token の課金はゼロだった。
- 自動キャッシュは 30 ターン目までに入力の 93% をカバーした。履歴を 1 件削除すると，そのターンのフルプライス入力が 3 倍になった。
- 長い音声回答を 2 秒で cancel すると，4 秒分の音声が課金された。
- gpt-realtime-2.1-mini は課金の仕組みが同じで，audio の価格が 3.2 倍安い。
ここに出てくる数字はすべて，2026-07-19 に両モデルに対して計測済みの WebSocket セッションを実行し，すべての server event をログに記録したものだ。両モデルとも Synthorai gateway の /v1/realtime エンドポイントで稼働しており，これらのセッションもそこで実行した。プロトコルも課金も OpenAI に直接話すのと同じだ。ハーネスは stdlib のみで書いた単一の Python ファイルで，以下の各数値は生の response.done の usage レコードまで辿れる。
Realtime API にはどう接続するのか
テキスト API と違い，Realtime は HTTP 上のリクエスト/レスポンスではない。セッションごとに WebSocket を 1 本開き，その上で JSON イベントをやり取りする。クライアントがマイク音声をストリームで送り込み，サーバーが音声をストリームで返す。1 本の接続で会話全体を運ぶ。
import websocket, json
ws = websocket.create_connection(
"wss://synthorai.io/v1/realtime?model=gpt-realtime-2.1",
header=["Authorization: Bearer sk-..."])
ws.send(json.dumps({"type": "session.update", "session": {
"type": "realtime", "output_modalities": ["audio"],
"audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}}}}))
# stream mic audio as base64 chunks: {"type": "input_audio_buffer.append", ...}
# then either let server VAD end the turn, or commit and ask for an answer:
ws.send(json.dumps({"type": "response.create"}))
# read events until "response.done": billing usage rides on that event課金に関わるセッションのライフサイクルはこうだ。session.update で instructions，voice，tools，turn detection を設定する（これがキャッシュ可能な prefix になる）。input_audio_buffer.append / commit でユーザー音声を追加する。response.create で応答をトリガーする。そして response.done のたびに，その応答の usage の全内訳が付いてくる。方言の注意点が一つ。GA API では output_modalities とネストした audio.input/audio.output の設定を使う。beta 時代の response.modalities フィールドは unknown_parameter として拒否される。
GPT Realtime は1分あたりいくらかかるのか？
公式の換算レートはトークン単位できっちり合う。30.0秒のクリップは入力音声トークン300個（100msあたり1個）、4.5秒の音声応答は出力音声トークン90個（50msあたり1個）で課金された。これでトークン単価の一覧を分単位の計算に落とし込める。
| レーン | gpt-realtime-2.1 | gpt-realtime-2.1-mini |
|---|---|---|
| リスニング（ユーザー音声入力、通常料金） | $0.0192/min | $0.0060/min |
| スピーキング（モデル音声出力） | $0.0768/min | $0.0240/min |
| リスニング、キャッシュ再生 | $0.00024/min（1/80） | $0.00018/min |
| 文字起こしアドオン（任意） | +$0.017/min | +$0.017/min |
表に載らないコストが2つ隠れている。1つ目は、音声応答ではテキスト出力も課金される点だ。トランスクリプトに加えて reasoning トークンが含まれる（gpt-realtime-2.1 は実際に推論する。output_token_details.reasoning_tokens はどの実行でも非ゼロを返した）。今回の短いテスト応答では、音声トークンの上に約24%が上乗せされ、$24/M のテキストレートで課金された。
2つ目は、文字起こしアドオンが独立した課金レーンだという点だ。使用量レコードは {"type": "duration", "seconds": 30} と出る。トークンとは無関係に $0.017/min の時間課金で、トランスクリプトがモデルの入力に入ることはない。このフラグを1つ立てるだけで、2.1では入力側コストがおよそ2倍、mini では4倍近くになる。だからコンプライアンスや製品要件でテキストが本当に必要な場面だけオンにすること。
沈黙・割り込み・ツール呼び出しにコストはかかるのか？
沈黙はコストゼロだ。server VAD を有効にしたセッションに60秒の沈黙をストリーミングし、その後で質問した。使用量は、音声を一切送らなかった対照セッションとバイト単位で同じだった。VAD は発話と検出した音声だけをコミットするので、保留音、フォームを読み上げる顧客、開いたままのアイドル回線はいずれも入力トークンをゼロで課金する。ただし実際の背景ノイズは VAD を誤検出させ得る。純粋な沈黙が下限であって、ノイズの多い通話での保証にはならない。
割り込みはユーザーの耳に届いた地点ではなく生成のフロンティアまで課金され、生成されていない残り分は課金されない。40までゆっくり数え上げる音声を要求し、2.0秒聞いた時点でキャンセルした。課金は音声トークン81個、つまり4.0秒だった。この2秒の超過分は、response.cancel が届くまでに生成が再生をどれだけ先行していたかを表す。mini では同じ実験で6.3秒課金された。小さいモデルはリアルタイムよりさらに先まで生成するためだ。実務上のルールはこうだ。クライアントがバージインを検出した瞬間に response.cancel を送ること。キャンセルが届くまでメーターは回り続ける。
ツール呼び出しは課金中立だ。関数定義を1つ持つセッションで呼び出しを発行し、注入された結果を受け取ると、直後の応答では入力の99%がキャッシュレートで課金されていた。関数呼び出しのアイテムとその出力は、他の追記された履歴と同様にキャッシュされる。ツール定義自体も、2ターン目以降にキャッシュされる静的プレフィックスに収まる。
キャッシュで長いセッションを安く保つ仕組み
Realtime API は応答ごとに会話全体を入力として読み直すため、ターンあたりの入力はセッションの長さに比例して増えていく。これを安く抑えているのが自動プレフィックスキャッシュだ。キャッシュされた音声は $32/M ではなく $0.40/M で再生される。フル料金の 1/80 だ。今回の 30 ターンのセッションでは、キャッシュの割合が徐々に上がり、30 ターン目には入力の 93% に達した。
キャッシュの内訳は毎回の response.done で報告される。
"usage": {
"input_tokens": 891,
"input_token_details": {
"text_tokens": 891, "audio_tokens": 0,
"cached_tokens": 832,
"cached_tokens_details": { "text_tokens": 832, "audio_tokens": 0 }
}
}公式ドキュメントに載っていない仕様が 3 つあり、いずれも実測で確認した。キャッシュはプレフィックスがおよそ 128 トークンで有効になる（テキスト API のドキュメント上の最小値は 1,024）。前進は 64 トークン単位だ。そして静的プレフィックスは同じキー上の複数セッションで再利用できる。最後の点は 60 分のセッション上限に効いてくる。新しいセッションの最初のターンでも instructions はすでにキャッシュ料金で課金されるので、ローテーション時にフル料金がかかるのは会話履歴の読み直しだけで、system prompt には及ばない。
割引を失う唯一の方法が履歴の編集で、そのペナルティも正確に測った。セッションの途中で古いアイテムを 1 つ削除すると、キャッシュ割合がちょうど 1 ターンだけ崩れ、その後キャッシュは再構築された。
| ターン | 入力 | キャッシュ | フル料金 |
|---|---|---|---|
| 8（削除前） | 319 | 256 | 63 |
| 9（最初のユーザーアイテムを削除） | 326 | 128 | 198 |
| 10 | 352 | 320 | 32 |
もう 1 つ、実測で分かった負担軽減がある。モデル自身の音声応答は、後続の入力に音声ではなくテキストとして再入力される。8 ターンの音声会話では、入力音声は毎ターンちょうどユーザーのクリップ分だけ増え、アシスタント側は $4/M の transcript トークンとして再登場した。積み上がっていく項のうち高くつくのはユーザー音声だけだ。
ここから導ける方針は短い。履歴は追記のみにする。instructions と tool 定義はセッション全体で（そしてセッションをまたいでも）バイト単位で同一に保つ。動的なものはプレフィックスではなく最新のユーザーメッセージに入れる。そして削らざるを得ないときは、毎ターンではなく、まれに大きな単位で削る。プロバイダー横断の一般的な仕組みについてはプロンプトキャッシュガイドとキャッシュ最小値の実測の記事を参照してほしい。
gpt-realtime-2.1 と mini：どちらを選ぶべきか
課金の仕組みはどちらのモデルも同じだ。変換レート、64 トークン単位のキャッシュ量子化、カーブの形状、すべて共通。違うのは価格と挙動だけ。
| gpt-realtime-2.1 | gpt-realtime-2.1-mini | |
|---|---|---|
| 音声 入力 / 出力（100 万トークンあたり） | $32 / $64 | $10 / $20（3.2 倍安い） |
| テキスト 入力 / 出力 | $4 / $24 | $0.60 / $2.40（6.7 倍安い） |
| キャッシュ済み音声 | $0.40（1/80） | $0.30（1/33） |
| テキストターンのレイテンシ（実測） | 0.5〜0.9 秒 | 0.5〜0.6 秒 |
| 同一プロンプトでの冗長さ | 基準 | 出力トークンが一貫して多い |
| バージイン時の余剰（2 秒分を聞いた場合） | 4.0 秒分を課金 | 6.3 秒分を課金 |
注目すべき点が 2 つある。キャッシュ再生のレーンでは価格差がほぼなくなる（$0.40 対 $0.30）。そのため、キャッシュ率の高い長いセッションでは mini の優位性がわずかに縮まるが、それでも総額を支配するのは新規トークンだ。もう 1 つ、mini の速さは割り込み時に不利に働く。再生位置よりも先まで生成してしまうため、バージインのたびに破棄される生成済み音声が約 2 倍になる。ただし金額で見れば、計測したすべてのシナリオで mini が勝つ。3.2 倍の価格差が両方の影響を吸収してしまうからだ。
短いコマンドを扱うアシスタント、IVR、高並列のサポート用途では、デフォルトで mini を選べばいい。複雑なツールのオーケストレーションや多段の推論が必要なセッションでは 2.1 を選ぶ。OpenAI は 2.1 を指示追従のフラッグシップと位置づけているが、この点はこちらのコスト計測では意図的に評価対象にしていない。
一般的な音声シナリオの実際のコストは？
| シナリオ | 主なコスト | 計測からわかること |
|---|---|---|
| ボイスチャット、コンパニオン | 発話レーン＋履歴の累積 | 履歴は追記のみに保つ。60 分ごとのローテーションで履歴が一度だけ全額で再読み込みされるが、プロンプトはキャッシュされたまま |
| ライブ翻訳 | 発話 ≈ リスニング時間 | 専用の gpt-realtime-translate SKU は $0.034/分の定額。2.1 で翻訳を組むと、リスト価格でおよそ 3 倍かかる |
| コールセンター | 通話に占める無音の割合 | 無音は無料なので、静かな時間帯のコストは ≈$0。コンプライアンス用の文字起こしは 1 レグあたり $0.017/分が加算され、別途予算計上が必要 |
| デバイスアシスタント | 接続確立＋最初のターン | 回線を 1 本開いたままにする方が再接続より有利。アイドルは無料で、セッション確立にはユーザーから見えて約 2.5 秒の遅延が実測された |
| ツールを使うボイスエージェント | ツールの往復 | ツール呼び出しはキャッシュを壊さない（次のターンで 99% キャッシュ）。定義は静的に保つこと |
| 議事録 | Realtime の仕事ではない | 時間課金の文字起こしとテキストモデルを組み合わせれば、累積項も 60 分の上限も完全に避けられる |
割り込みの多いシナリオでは、1 インタラクションあたりの計算にバージインの余剰を加える。割り込みごとに、ユーザーが聞いた音声分に加えて数秒の生成先行分がコストになる。
FAQ
GPT Live と GPT Realtime API は同じものですか？
いいえ。GPT Live は ChatGPT アプリに搭載された音声機能で、独自の API も料金ページも持っていません。同じ体験をプログラムから使いたい開発者は Realtime API のモデル gpt-realtime-2.1 と gpt-realtime-2.1-mini を使うことになります。本記事で料金を計測したのはこれらのモデルです。
Realtime セッションはどのくらい継続できますか？
上限は 60 分で、これは絶対に超えられません。一度閉じたセッションは再開できません。テキスト履歴は新しいセッションに再注入できますが（フルプライスで一度課金され、静的な prompt はキャッシュされたまま）、アシスタントの音声は再生できません。そのため長時間動かす音声プロダクトでは、60 分に達する前にローテーションの計画が必要です。
ターン間のアイドルタイムアウトはありますか？
アイドルタイムアウトはドキュメントに記載がなく、server VAD を使った我々の計測では無音時のトークン課金はゼロでした。つまり、やり取りの合間に回線を開いたままにしても、接続自体のコスト以外はかかりません。利用頻度の低いプロダクトでは、やり取りごとに接続し直すより 1 本の長いセッションを維持するほうが安く、速くなります。セットアップは約 2.5 秒かかったからです。
API はどの音声フォーマットを想定していますか？
入力・出力ともにデフォルトは PCM16、24 kHz モノラルで、session.update の audio.input.format と audio.output.format で設定します。課金はフォーマットに依存しません。音声トークンは長さだけで決まり、入力は 100 ms あたり 1 token、出力は 50 ms あたり 1 token です。
60 分の壁とどう付き合うか（ローテーション、履歴の引き継ぎ、再接続で何が残るか）というエンジニアリングのパターンはそれ自体が別のテーマで、本記事の数値はその計算のための入力になります。テキスト API で課金トークンがファミリーごとにどう分解されるかについては、関連記事の token 使用量の内訳 を参照してください。