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 です。この記事では、この 2 つを計測しています。

TL;DR

• gpt-realtime-2.1 では、ユーザー音声は 100 ms あたり正確に 1 audio token、モデル音声は 50 ms あたり正確に 1 audio token として課金されます。聞き取りは 1 分あたり $0.0192、発話は 1 分あたり $0.0768 です。
• server VAD が有効な状態で 60 秒間無音にしても、input token は 0 でした。
• 自動キャッシュは 30 ターン目までに input の 93% をカバーしました。履歴を 1 件削除すると、1 ターンだけ通常料金の input が 3 倍になりました。
• 長い音声回答を開始から 2 秒でキャンセルしても、4 秒分の音声が課金されました。
• gpt-realtime-2.1-mini の課金方式は同じで、音声料金は 3.2 倍安くなります。

この記事の数値はすべて、2026-07-19 に両モデルへ接続して実施した、計測機能付き WebSocket セッションの結果です。server event はすべて記録しました。両モデルは Synthorai gateway の /v1/realtime endpoint で利用でき、今回のセッションもそこで実行しています。プロトコルと課金方式は OpenAI に直接接続する場合と同じです。計測用 harness は標準ライブラリだけで動く単一の Python ファイルで、以下の数値はすべて生の response.done usage record にさかのぼれます。

Realtime API への接続方法

テキスト API と異なり、Realtime は HTTP の request／response 方式ではありません。セッションごとに WebSocket を 1 本開き、JSON event を送受信します。client はマイク音声を streaming で送り、server は生成した音声を streaming で返します。会話全体を 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 field は unknown_parameter として拒否されます。

GPT Realtime の 1 分あたりの料金

公式の変換率は token 単位まで正確でした。30.0 秒の音声 clip は 300 input audio token（100 ms あたり 1）、4.5 秒の音声回答は 90 output audio token（50 ms あたり 1）として課金されました。token 単価を 1 分あたりに換算すると、次のようになります。

表に含まれないコストが 2 つあります。まず、音声回答では text output にも課金されます。内訳は transcript と reasoning token です。gpt-realtime-2.1 は reasoning を行い、すべての実行で output_token_details.reasoning_tokens が 0 より大きい値を返しました。短い回答を使ったテストでは、$24/M の text 料金によって、audio token の料金に約 24% が上乗せされました。

次に、文字起こし add-on は独立した課金枠です。usage record は {"type": "duration", "seconds": 30} となります。token 数とは無関係に、時間ベースで 1 分あたり $0.017 が課金され、transcript がモデルの input に入ることもありません。この設定を有効にするだけで、input 側のコストは 2.1 では約 2 倍、mini ではほぼ 4 倍になります。コンプライアンスや製品要件としてテキストが本当に必要な場合だけ有効にしてください。

無音、割り込み、tool call に料金はかかるか

無音は無料です。server VAD を有効にしたセッションへ 60 秒間の無音を送った後で質問しましたが、usage は音声を一切送らなかった control session と byte 単位で同一でした。VAD が commit するのは音声として検出した区間だけです。そのため、保留音、顧客がフォームを読んでいる時間、接続したまま待機している回線では、input token の料金は 0 です。ただし、実際の環境では背景雑音によって VAD が反応する場合があります。完全な無音では 0 になりますが、雑音のある通話でも無料になるとは限りません。

割り込み時は、ユーザーが実際に聞いた位置ではなく、生成が進んだ位置まで課金されます。まだ生成されていない残りの部分には課金されません。40 までゆっくり数える音声を生成し、2.0 秒聞いた時点でキャンセルしたところ、81 audio token、つまり 4.0 秒分が課金されました。この 2 秒の差は、response.cancel が到着するまでに生成が再生より先行した分です。mini で同じ実験をすると 6.3 秒分が課金されました。小さいモデルほどリアルタイム再生より先まで生成するためです。client が barge-in を検出したら、すぐに response.cancel を送ってください。キャンセルが到着するまで課金は続きます。

tool call 自体は課金に影響しません。function definition を 1 つ設定したセッションで call を発生させ、結果を注入したところ、直後の応答では input の 99% がキャッシュ料金で課金されました。function-call item とその output は、後から追加された他の履歴と同じようにキャッシュされます。tool definition は static prefix に含まれ、2 ターン目以降はキャッシュされます。

長いセッションをキャッシュで安く保つ仕組み

Realtime API は応答のたびに会話全体を input として再度読み込むため、1 ターンあたりの input はセッションの長さに比例して増えます。それでも料金を抑えられるのは、自動 prefix caching があるためです。キャッシュされた音声のリプレイは $32/M ではなく $0.40/M で、通常料金の 1/80 です。30 ターンのセッションでは、キャッシュ済み input の割合が継続的に増え、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 token の prefix から有効になります。テキスト API で文書化されている最小値は 1,024 です。また、キャッシュは 64 token 単位で進みます。static prefix は、同じ key を使う別セッションでも再利用できます。最後の仕様は、セッション上限が 60 分である点と関係します。新しいセッションでも、最初のターンから instructions がキャッシュ料金で課金されました。セッションを切り替えた際に通常料金で再度読み込まれるのは会話履歴だけで、system prompt はキャッシュされたままです。

履歴の編集は、割引を失う唯一の操作です。セッション途中で古い item を 1 件削除すると、キャッシュ率がちょうど 1 ターンだけ下がり、その後は再構築されました。実測結果は次のとおりです。

もう 1 つ、コストを抑える要素があります。モデルが生成した音声回答は、後続の input には音声ではなくテキストとして再入力されます。8 ターンの音声会話では、input audio は各ターンでユーザーの clip サイズと正確に同じ量だけ増えました。一方、assistant 側は transcript token として再入力され、料金は $4/M でした。累積コストのうち、高価なのはユーザー音声だけです。

実運用の要点は明確です。履歴は append-only にします。セッション中もセッション間でも、instructions と tool definition は byte 単位で同一に保ちます。動的な内容は prefix ではなく、最新の user message に入れます。履歴を削る必要がある場合は、毎ターン少しずつ削るのではなく、回数を減らして一度に大きく削ります。provider をまたぐ一般的な仕組みについては、prompt cache のガイドと実測した cache 最小値を参照してください。

gpt-realtime-2.1 と mini のどちらを選ぶべきか

両モデルの課金方式は同じです。変換率、64 token 単位の cache quantization、料金曲線の形も変わりません。違うのは価格と挙動です。

注目すべき点は 2 つあります。キャッシュ済みリプレイでは価格差が $0.40 と $0.30 まで縮まります。そのため、キャッシュ率が高い長時間セッションでは mini の優位性がやや小さくなりますが、総額の大半は新規 token が占めます。また、割り込み時には mini の速さが不利に働きます。再生より先まで生成するため、barge-in のたびに破棄される生成済み音声が約 2 倍になります。それでも、実測したすべてのシナリオで mini のほうが安くなりました。3.2 倍の価格差が、どちらの影響も吸収するためです。

短いコマンドを扱う assistant、IVR、高 concurrency の support では、mini を標準にしてください。複雑な tool orchestration や複数ステップの reasoning が必要なセッションでは 2.1 を選びます。OpenAI は 2.1 を instruction following の flagship と位置付けていますが、今回のコスト計測では品質を評価していません。

一般的な音声シナリオの実コスト

割り込みが多いシナリオでは、やり取りごとの計算に barge-in の先行分も加えてください。割り込み 1 回につき、ユーザーが聞いた音声に加えて、数秒分の先行生成にも料金がかかります。

FAQ

GPT Live と GPT Realtime API は同じですか？

いいえ。GPT Live は ChatGPT app 内の音声機能で、専用の API も料金ページもありません。同等の体験をプログラムから実装する場合は、Realtime API の gpt-realtime-2.1 または gpt-realtime-2.1-mini を使います。この記事では、この 2 モデルの料金を計測しています。

Realtime セッションはどのくらい継続できますか？

上限は 60 分で、終了したセッションは再開できません。text history は新しいセッションへ再投入できます。その際、履歴には 1 回だけ通常料金がかかり、static prompt はキャッシュされたままです。ただし、assistant audio はリプレイできません。長時間動作する音声製品では、60 分に達する前にセッションを切り替える設計が必要です。

ターン間に idle timeout はありますか？

idle timeout は文書化されていません。実測では、server VAD の利用時に無音の token 料金は 0 でした。そのため、やり取りの間も回線を接続したままにしておけば、接続自体を除いて料金はかかりません。利用頻度が低い製品でも、やり取りごとに再接続するより、1 つの長いセッションを維持するほうが安く、応答も速くなります。接続設定には実測で約 2.5 秒かかりました。

API が受け付ける音声形式は何ですか？

input と output のデフォルトは、どちらも 24 kHz mono の PCM16 です。session.update の audio.input.format と audio.output.format で設定します。課金は形式に依存しません。audio token は再生時間だけで決まり、input は 100 ms あたり 1 token、output は 50 ms あたり 1 token です。

60 分の上限に対応する設計パターンには、セッション切り替え、履歴の引き継ぎ、再接続後も維持される情報などがあります。これは別のテーマであり、この記事の数値がその計算の入力になります。テキスト API で課金対象 token がモデル family ごとにどう分解されるかは、関連記事のtoken usage の内訳を参照してください。

← ブログに戻る