3行でいうと

  • 音声そのものを扱うAIは、「音声対音声」の1つの接続で、聞く・考える・話すを続けてやる
  • 料金は2種類。OpenAIのRealtimeは音声トークンの量、GPT-Liveは接続している秒数
  • 会話が進むほど、過去の会話を毎回読み直す分の入力が増える。キャッシュの有無で費用が変わる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。OpenAIとGoogleの価格は2026年10月22日に料金ページで読み直しました。変わることがあります。

先に結論

前提：言葉の整理

作り方の違い

OpenAI

OpenAIの文書は、3つの構成を並べています。

構成 向く場面 公式の説明
GPT-Live 全二重の会話と、別のバックエンドの組み合わせ 既存のテキストの仕組みをそのまま使い、バックエンドを自由に選べる
Realtime API 聞く・考える・ツールを使う、を1つのセッションで 1つのモデルが音声を理解し、判断し、声で返す
連鎖型の音声パイプライン 各段階を自分で管理したい 音声認識、エージェント、音声合成を別々に差し替えられる

Google（Gemini Live API）

通信のしくみ

話し終わりの判定と割り込み

遅延の体感に最も影響するのは、「いつ話し終わったと判断するか」です。

見立てです。短くするほど返事は早く感じられますが、話の途中で割り込んでしまう危険が増えます。

遅延の考え方

公式文書には、「何ミリ秒」という保証は見当たりませんでした。OpenAIの文書は、遅延の測り方として次を示しています。

見立てです。遅延は、次の部品の合計です。(1)接続の確立、(2)話し終わりの判定の待ち、(3)モデルの処理、(4)ツールの待ち、(5)再生の準備。公式資料は、WebRTCの初期接続を短くする仕組み（WARP）も案内しています。

料金

OpenAI

製品 単位 価格（米ドル）
gpt-realtime-2.1（音声） 100万トークン 入力32、キャッシュ入力0.40、出力64
gpt-realtime-2.1（文字） 100万トークン 入力4、キャッシュ入力0.40、出力24
gpt-realtime-2.1（画像） 100万トークン 入力5、キャッシュ入力0.50
gpt-realtime-2.1-mini（音声） 100万トークン 入力10、キャッシュ入力0.30、出力20
gpt-realtime-2.1-mini（文字） 100万トークン 入力0.60、キャッシュ入力0.06、出力2.40
gpt-live-1（会話の部分） 1分（秒単位で課金） 0.05

Google

会話1回の費用の見積り（OpenAI Realtime）

僕らの計算です。次の仮定です。1回15秒の発話を10往復（ユーザーの音声10トークン/秒、AIの音声20トークン/秒）。指示文、文字起こし、ツール呼び出しは含めません。

キャッシュは「最善の努力」で、保証はない、と文書にあります。会話の途中で指示やツールの定義を変えると、キャッシュの効きが落ちます。

なお、GPT-Liveの5分の会話部分は0.05ドル×5＝0.25ドルですが（僕らの計算）、バックエンド費用が別にかかるため、直接の比較には使えません。

公式の短い例と、費用を下げる方法

Realtime APIのブラウザ向けの例（OpenAI公式文書の例です。この記事では、実行していません）

import { RealtimeAgent, RealtimeSession } from "@openai/agents/realtime";

const agent = new RealtimeAgent({
  name: "Assistant",
  instructions: "You are a helpful voice assistant.",
});

const session = new RealtimeSession(agent, {
  model: "gpt-realtime-2.1",
});

await session.connect({ apiKey: "ek_...(ephemeral key)" });

公式の流れは次のとおりです。(1)自分のサーバーが一時鍵を作る、(2)フロントエンドがセッションを作る、(3)ブラウザならWebRTC、サーバーならWebSocketで接続、(4)エージェントが音声の出入り、ツール、割り込み、引き継ぎを扱う。

OpenAIの費用を下げる方法（公式の記述）

  • 会話の古い部分を捨てる（切り詰め）。token_limits.post_instructionsで、指示を除く入力の上限を決める。retention_ratioを1未満にすると、一度に多めに捨て、キャッシュが毎回無効になるのを避けられる。ただし、モデルの記憶は減る。
  • 古い会話を要約に置き換える（conversation.item.delete、conversation.item.create）。
  • 小さい（mini）モデルを使う。ただし、指示への従い方や関数呼び出しは弱くなりうるので、まず大きいモデルで調整してから試す、とされている。
  • GPT-Liveでは、待ち時間を減らす（ツールの並列実行など）と、会話の秒数が減って費用も下がる。長い作業の間はセッションを閉じる。公式の説明では、閉じると、待機中の1分あたり0.05ドルを節約できる。再開の費用と体験への影響と比べて決める。
  • 使用量の記録：Realtimeはresponse.doneのusageを読む。GPT-Liveはsession.usage.updatedが累積の秒数を返すので、足し合わせずに、session.closedの最終値を1回だけ記録する。

セッションの長さと制限

選び方・判断の基準

見立てです。公式資料を読んだうえでの、僕らの整理です。

よくあるつまずき

見立てです。公式資料を読んで、読み違えやすいと思った点を挙げます。

気をつけること

出典

更新履歴