リアルタイムAPI（Realtime API）とは？接続方式・課金の仕組み・Python実装【2026年11月版】

リアルタイムAPIという言葉は、2つの意味で使われます。一般には、サーバ側で起きた変化を待たずにクライアントへ届ける連携APIの総称です。AI開発の文脈では、OpenAIのRealtime APIを指します。マイクの音声をそのままモデルへ流し、モデルが話した音声をそのまま受け取るAPIで、文字起こし・応答生成・音声合成を別々に呼ぶ必要がありません。

OpenAIのRealtime APIは2026年に入って大きく動きました。5月12日にベータ版のインターフェースが撤去され、2027年1月20日には gpt-realtime など旧世代のモデルも停止します。この記事では、言葉の切り分けから、GPT-Live・チェーン型との選び分け、接続方式、課金の試算、Pythonの実装、古い手順が動かない理由までを順に扱います。

まとめ：Realtime APIで最初に決める3点と2027年1月の移行期限

• 構成：1つのモデルに聞き取り・判断・発話・ツール実行を任せるならRealtime API。会話を続けながら裏で別の処理を走らせたいならGPT-Live、途中のテキストを検査したいならチェーン型です。
• 接続方式：ブラウザとモバイルはWebRTC、サーバに生音声が届く構成はWebSocket、電話はSIPです。後工程の作りはここでほぼ決まります。
• 移行期限：ベータ版は2026年5月12日に撤去済みです。gpt-realtime・gpt-realtime-mini は2027年1月20日に止まるので、gpt-realtime-2.1 系へ移してください。

課金は応答ごとで、それまでの会話全体が毎回入力に数えられます。長い通話ほど1回の応答が高くなるため、キャッシュが効く作り方が費用を左右します。

リアルタイムAPIの定義：一般的な連携APIとOpenAI Realtime APIの違い

WebSocket・SSE・Webhookで即時に届ける一般的なリアルタイムAPI

一般名詞のリアルタイムAPIは、クライアントが問い合わせるのを待たずに、サーバが更新を送り出すAPIの総称です。土台にはWebSocket、Server-Sent Events（SSE）、Webhookが使われます。Supabase RealtimeやFirebase Realtime Databaseのように、製品名にこの語を含むものもあります。仮想通貨取引所の価格配信APIもこの分類で、検索結果の上位にはこちらの意味の資料も並びます。

REST APIは「聞かれたら答える」一往復の型、一般のリアルタイムAPIは「変化があれば知らせる」型です。接続を張りっぱなしにする仕組みそのものは、WebSocketのハンドシェイクと運用設計で詳しく扱っています。

音声・推論・ツール実行を1セッションで扱うOpenAI Realtime API

OpenAIのRealtime APIは固有名詞です。公式のRealtime APIの導入ガイドは、モデルが音声を直接扱い、会話の状態を保ち、ツールも呼べると説明しています。割り込み（バージイン）、最初の音声が返るまでの短さ、自然な話者交代を求める音声エージェントの出発点という位置づけです。社内で「リアルタイムAPIを使いたい」と話が出たら、データ連携の話か音声対話の話かを最初に確かめておくと、設計の手戻りを防げます。

音声エージェントの3つの構成：GPT-Live・Realtime API・チェーン型

OpenAIの音声エージェントのガイドは、音声と推論・ツールのつなぎ方を3つに分けています。以前は「音声から音声へ直接」と「チェーン型」の2択でしたが、2026年9月10日に一般提供されたGPT-Liveが加わりました。

判断の軸は「誰が考えるか」です。Realtime APIは1つのモデルが音声を解釈し、何をするか決め、話して返します。GPT-Liveは聞く・話すを同時にこなす音声担当で、推論とツール実行は別のバックエンドへ任せます。既存のテキスト用エージェントを残したまま音声の窓口だけ足したいなら、GPT-Liveのほうが素直です。両者の細かな違いはGPT-Live-1とRealtime APIの違いで比べています。チェーン型は、認識結果のテキストを監査・置換してから応答させたいときの選択肢です。

Realtime APIの推奨モデルと接続先（2026年11月時点）

このほか gpt-realtime-2・gpt-realtime-1.5・gpt-realtime-whisper も料金表に載っており、停止予定は出ていません。文字起こしだけは接続URLの書き方が違います。リアルタイム文字起こしのガイドは、URLに model を付けず intent=transcription で接続し、session.update で type: "transcription" と gpt-live-transcribe を指定するよう求めています。model 付きのURLは会話用のセッションになり、この設定を受け付けません。また gpt-live-transcribe は server_vad にも semantic_vad にも対応しないため、ターン検出は省くか null にします。2.1と2.1-miniの単価や性能差はGPT-Realtime-2.1とminiの違い・料金にまとめているので、この記事ではAPIの構造に絞ります。

2027年に停止する旧モデルと置き換え先

OpenAIの廃止予定の一覧には、音声まわりの停止日が3つ並んでいます。

見落としやすいのは1行目です。読み上げ専用だったTTSモデルの置き換え先として、Realtime APIの gpt-realtime-2.1-mini が指定されています。チェーン型で tts-1 を使っている構成は、2027年1月6日までに音声合成の部分をRealtime API側へ寄せるか、別の音声合成製品へ替える判断が要ります。

接続方式の選定：WebRTC・WebSocket・SIP

ブラウザとモバイルはWebRTC：統合インターフェースとエフェメラルキー

音声デバイスを触るのが利用者の端末ならWebRTCを選びます。公式も、ブラウザやモバイルからはWebSocketより性能が安定するとしてWebRTCを勧めています。WebRTCのガイドによると、ブラウザからの接続経路は2つです。

• 統合インターフェース：ブラウザのSDPを自社サーバが受け取り、セッション設定と合わせて /v1/realtime/calls へ送ります。設定が簡単で接続も速い反面、自社サーバがセッション開始の経路に入ります。
• エフェメラルキー：自社サーバが POST /v1/realtime/client_secrets で短命の鍵を発行し、ブラウザはその鍵でOpenAIへ直接つなぎます。

どちらもAPIキーをブラウザへ渡さない点は同じです。エフェメラルキーの発行は次の形になります。

const sessionConfig = JSON.stringify({
  session: {
    type: "realtime",
    model: "gpt-realtime-2.1",
    audio: { output: { voice: "marin" } },
  },
});

const response = await fetch(
  "https://api.openai.com/v1/realtime/client_secrets",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
      "Content-Type": "application/json",
      "OpenAI-Safety-Identifier": "hashed-user-id",
    },
    body: sessionConfig,
  }
);

body にオブジェクトのまま入れると [object Object] が送られてJSONとして解釈できずエラーになるため、JSON.stringify を必ず通します。モデルや指示文をサーバ側で固めるので、クライアントから差し替えられない構成にできます。接続開始までの時間を詰めたい場合は、往復を減らすWARPという仕組みも用意されています。

サーバに生音声が届く構成はWebSocket

コールセンターの録音基盤やメディアサーバが、すでにサーバ側で音声を受けているならWebSocketで直結します。接続先は wss://api.openai.com/v1/realtime?model=gpt-realtime-2.1、ヘッダは Authorization と、利用者を識別する場合の OpenAI-Safety-Identifier です。後者は任意ですが、公式はハッシュ化した社内ユーザーIDのような安定した値を送るよう勧めています。音声は24kHzのPCMをbase64にして送り、返ってきた音声の再生も自分で書きます。

電話はSIP：着信Webhookから通話の受付・転送・切断まで

電話番号をRealtime APIにつなぐには、TwilioなどのSIPトランクを sip:[email protected];transport=tls へ向けます。SIPのガイドの流れは次のとおりです。

1. 着信するとプロジェクトのWebhookに realtime.call.incoming が届き、call_id が渡される
2. /v1/realtime/calls/{call_id}/accept にセッション設定を付けて受ける（断るなら reject）
3. wss://api.openai.com/v1/realtime?call_id={call_id} へWebSocketを張り、通話中のイベントを監視する
4. 有人対応へは refer、終話は hangup

Python SDKでは client.realtime.calls.accept()、監視の接続は client.realtime.connect(call_id=...) で書けます。有人転送が要件に入る案件では、refer の転送先を誰が決めるかを先に詰めておくと設計が固まります。

セッション設定：session.update・ターン検出・ツール呼び出し

session.updateで指定する音声フォーマットと指示

接続後に最初に送るのが session.update です。入力音声の形式、ターン検出、出力音声と声、モデルへの指示をまとめて指定します。

{
  "type": "session.update",
  "session": {
    "type": "realtime",
    "model": "gpt-realtime-2.1",
    "output_modalities": ["audio"],
    "audio": {
      "input": {
        "format": { "type": "audio/pcm", "rate": 24000 },
        "turn_detection": { "type": "semantic_vad" }
      },
      "output": {
        "format": { "type": "audio/pcm" },
        "voice": "marin"
      }
    },
    "instructions": "日本語で簡潔に答えてください。"
  }
}

多くの項目はセッション中いつでも変えられますが、voice だけは一度音声で応答した後は変更できません。セッションの上限は60分なので、長時間の受付窓口は張り直しを前提に組みます。

server_vadとsemantic_vadの既定値と押しボタン型の制御

会話の切れ目の判定は2方式です。ターン検出のガイドによると、指定を省いたときの既定は server_vad で、無音の長さで発話を区切ります。調整項目は感度の threshold（0〜1）、発話直前を含める長さの prefix_padding_ms、終了とみなす無音の長さの silence_duration_ms です。

semantic_vad は、無音ではなく発話が意味として言い終わったかで区切ります。検出の感度に関わる項目は、割り込みの積極性を決める eagerness（low・medium・high・auto、既定auto）だけです。言い淀みの多い相手に先走って応答されると困るなら、こちらへ切り替えます。押しボタン通話のように区切りをアプリ側で決めたい場合は turn_detection を null にし、input_audio_buffer.commit と response.create を自分で送ります。検出は残して応答の発火だけ止めるなら create_response と interrupt_response を false にします。応答前に内容の審査を挟みたい業務では、この最後の構成を選んでください。

関数呼び出しとリモートMCPサーバの使い分け

ツールの定義方法は2つあります。type: "function" の関数は自社のアプリが実行します。モデルが呼ぶと response.done に引数と call_id が入って返り、処理結果は conversation.item.create で function_call_output として同じ call_id を添えて返します。社内文書を検索させる場合もこの経路で、回答の精度は音声側ではなく検索側の設計で決まります。RAGの検索工程と精度改善の判断基準を先に固めてから音声を載せる順序が安全です。

もう1つは type: "mcp" で、server_url にリモートMCPサーバを指定すると、Realtime API自身がそのサーバのツールを呼びます。ツールのガイドには承認の要否を決める require_approval があり、旧来の connector_id は2026年9月1日より後に出たモデルでは非推奨です。業務データの更新や決済のように取り消せない操作は、MCPに任せず関数として自社側で権限を確かめてから実行させる設計を勧めます。

Realtime APIの課金の仕組み：応答ごとに会話全体が入力に積み上がる

課金は時間ではなく、応答（Response）を作るたびのトークン数です。コスト最適化のガイドが挙げる要点は3つあります。

• 音声トークンは、利用者の発話が100ミリ秒で1トークン、モデルの発話が50ミリ秒で1トークン
• 応答のたびに、それまでの会話全体がモデルへの入力になる
• 前の応答と一致する入力はキャッシュが効き、単価が大きく下がる（保証はない）

この仕組みで、1往復を「利用者10秒（100トークン）＋モデル10秒（200トークン）」として30往復（約10分）の通話を試算しました。n回目の応答の入力は、それまでの全往復分（300×(n−1)トークン）に今回の発話100トークンを足した量です。単価はモデルページの音声単価（2.1は入力32ドル・キャッシュ0.4ドル・出力64ドル、miniは10ドル・0.3ドル・20ドル、いずれも100万トークンあたり）です。指示文やテキスト、推論のトークンは含めていません。

キャッシュの有無で、gpt-realtime-2.1では約9倍、miniでは約8倍開きます。そのため、通話の途中で指示文やツール定義を書き換えないことが効果の大きい節約の1つになります。先頭にあるこれらを変えると、それ以降のキャッシュが外れるためです。1セッションあたりの費用をさらに抑えたい場合、公式は session.truncation で token_limits.post_instructions を下げて入力の上限を絞り、あわせて retention_ratio を1未満にして切り詰めのたびにキャッシュが外れるのを減らす方法を案内しています。会話の古い部分をモデルが覚えていられなくなる点との引き換えです。実際の消費は response.done の usage に入力・キャッシュ・出力の内訳が返るので、試算ではなくこの値で見積もりを直してください。入力音声の文字起こしを有効にすると、その分は別の料金表で加算されます。

比較として、GPT-Liveは通話時間に対して1分0.05ドルの秒課金で、10分なら0.5ドルに裏側のモデル代が加わります。gpt-realtime-2.1はキャッシュが効けば同程度、効かなければ約9倍です。miniならキャッシュが効けばGPT-Liveの音声代より安く、効かなくても約3倍に収まります。

Pythonで作る音声対話の最小実装（openai 3.42.1）

接続・session.updateの送信と受信イベントの振り分け

Python SDKでは client.realtime.connect() でセッションを張ります。次のコードは openai 3.42.1（2026年11月公開）とPython 3.13で、ローカルに立てた模擬WebSocketサーバへ接続し、/v1/realtime?model=gpt-realtime-2.1 への接続、送信3件、受信3イベントの流れを確かめたものです。

import asyncio
import base64
from openai import AsyncOpenAI

client = AsyncOpenAI()

SESSION = {
    "type": "realtime",
    "model": "gpt-realtime-2.1",
    "output_modalities": ["audio"],
    "audio": {
        "input": {
            "format": {"type": "audio/pcm", "rate": 24000},
            "turn_detection": {"type": "semantic_vad"},
        },
        "output": {"format": {"type": "audio/pcm"}, "voice": "marin"},
    },
    "instructions": "日本語で簡潔に答えてください。",
}


async def talk(pcm_chunks):
    async with client.realtime.connect(model="gpt-realtime-2.1") as conn:
        await conn.send({"type": "session.update", "session": SESSION})

        async def send_audio():
            for chunk in pcm_chunks:
                await conn.send({
                    "type": "input_audio_buffer.append",
                    "audio": base64.b64encode(chunk).decode(),
                })

        sender = asyncio.create_task(send_audio())
        try:
            async for event in conn:
                if event.type == "response.output_audio.delta":
                    yield base64.b64decode(event.delta)
                elif event.type == "response.output_audio_transcript.delta":
                    print(event.delta, end="", flush=True)
                elif event.type == "response.done":
                    break
        finally:
            sender.cancel()

音声は24kHzのPCMをbase64にして input_audio_buffer.append で送り、返ってきた音声は response.output_audio.delta から取り出します。読み上げ内容をテキストでも残すなら response.output_audio_transcript.delta を併読します。response.done で抜けているのは1往復で終えるためで、会話を続ける場合は break を外し、終了時に送信タスクを止める処理だけ残します。TypeScriptなら、公式が勧める @openai/agents/realtime の RealtimeAgent と RealtimeSession を使う経路が近道です。

client.beta.realtimeのコードが動かない理由

SDKには旧来の client.beta.realtime も残っています。openai 3.42.1 の実装を見ると、この経路は接続時に OpenAI-Beta: realtime=v1 ヘッダを付けます。API変更履歴のとおり、このベータ版のインターフェースは2026年5月12日に撤去されました。インポートが通るので古いコードは一見動きそうに見えますが、ベータ版のインターフェースはAPI側で受け付けられません。client.beta.realtime を検索して、client.realtime へ置き換えてください。

2024年のRealtime APIとLangChainの手順が動かない理由

参照実装react-voice-agentのアーカイブと停止済みモデル

2024年当時、LangChain公式がRealtime APIとの組み合わせ例として公開した参照実装が langchain-ai/react-voice-agent です。GitHub APIで見ると2026年11月時点でアーカイブ済み、最終更新は2024年12月11日です。接続部のモデルは gpt-4o-realtime-preview-2024-10-01 に固定されていますが、このモデル自体が2025年10月10日に停止しています。リクエストヘッダの "OpenAI-Beta": "realtime=v1" も上のとおり撤去済みで、無視するイベント一覧の response.audio_transcript.delta もGAでは別名です。

LangChain側にも後継はありません。langchain-openai 1.7.3（2026年10月公開）のモジュールは chat_models・embeddings・llms・tools などで、音声セッションを扱うものは含まれていません。LangChainのツール定義は流用できても、セッションとイベントの処理は自分で書く前提です。

websockets 14.0以降のextra_headers廃止とTypeError

モデル名とヘッダを直しても、その手前で止まります。原因はOpenAIではなく依存ライブラリです。websocketsは14.0（2024年11月9日）で from websockets import connect の実体を新しいasyncio実装へ切り替え、ヘッダの引数は additional_headers になりました。旧来の extra_headers を渡すと、最新の17.4（2026年10月公開）でも次のエラーになります。

TypeError: BaseEventLoop.create_connection() got an unexpected keyword argument 'extra_headers'

先頭の BaseEventLoop. はPython 3.10以降の表示です。websocketsを13系に固定すれば通りますが、その先でGAのイベント名とセッション構造の差にぶつかるため、書き直したほうが早く済みます。

ベータからGAへ移すときの変更点

古いコードは「最初から動かない」のではなく「途中まで動いて別の場所で落ちる」形で失敗しがちです。ヘッダとイベント名を先に直してから接続を試すと、原因の切り分けが短くなります。

カスタムボイス：Realtime APIで使えるのは録音から作る声だけ

2026年10月16日、説明文から声を作る「prompt-to-voice」が全API顧客に開放されました。ただし対象はGPT-Liveのセッションです。カスタムボイスの公式ガイドは作り方を2つに分けており、Realtime APIで使えるのは録音から作る方式だけです。

公式ガイドはRealtime APIでカスタムボイスを使うモデルとして gpt-realtime-2.1-mini を案内しています。録音から作った声は、最初の音声応答より前に session.audio.output.voice へIDのオブジェクトで指定します。組み込みの声は文字列、カスタムボイスはオブジェクトという書き分けです。

{
  "type": "session.update",
  "session": {
    "type": "realtime",
    "model": "gpt-realtime-2.1-mini",
    "output_modalities": ["audio"],
    "audio": {
      "output": {
        "format": { "type": "audio/pcm" },
        "voice": { "id": "voice_123abc" }
      }
    }
  }
}

説明文から作る方式は成人の声に限られ、実在の人物やキャラクターの模倣は依頼できません。録音から作る方式は、声の持ち主本人が規定の同意文を読み上げた録音が必須です。/v1/audio/voices での作成はゼロデータリテンション（ZDR）と両立しないと明記されているため、ZDR契約の組織は声の作成工程だけ扱いが変わる点を事前に確認してください。

採用判断：Realtime APIを選ぶ場面と見送る場面

応答の速さが体験を決める一次応答・ハンズフリー操作

向いているのは、間の悪さがそのまま体験の質になる用途です。コールセンターの一次応答、作業中のハンズフリー操作、店頭端末の音声案内が該当します。認識・推論・合成の待ちが積み上がらない構造そのものが選定理由になり、関数呼び出しで基幹システムを引けるため、問い合わせの一次切り分けは現実的な適用先です。gpt-realtime-2.1は英数字の聞き取り、無音や雑音の扱い、割り込みへの反応を前の世代から改善したとモデルページに書かれており、電話番号や注文番号を口頭で受ける窓口ではこの点が効きます。

逐語監査・出力前審査・長時間通話でRealtime APIを避ける条件

次のいずれかに当てはまるなら、Realtime APIを第一候補にしないでください。

• 発話の逐語記録を監査に使う、または応答を送出前に審査する業務：途中のテキストを工程として押さえやすいチェーン型を選ぶ。公式もチェーン型を、各段の間のテキストを検査・変換したい場合の構成としている
• 既存のテキスト用エージェントや業務フローを作り直したくない：GPT-Liveを音声の窓口にして裏側を残す
• 30分を超える通話が多く、指示文を途中で頻繁に変える：キャッシュが効かず費用が膨らみやすい。上の試算で見積もり、GPT-Liveの時間課金と比べる

文字起こしだけが目的なら対話用のセッションは要りません。GPT-Live-Transcribeの実装手順と使い分けや文字起こしAPI主要7サービスの比較が判断材料になります。他社の音声基盤と並べるならGemini 3.1 Flash Liveの終了予定と移行先やxAIのGrok Voice Agent Builder、音声合成を独立させるなら音声合成AIの作り方と方式選定も参考になります。接続方式の決定から既存のCTIや業務システムとの連携、通話ログの保存設計まで一続きで検討したい場合は、一創のAI音声認識システム開発でご相談いただけます。

よくある質問

リアルタイムAPIとは何ですか？

文脈で2つに分かれます。一般名詞としては、サーバ側の変化を即時にクライアントへ届ける連携APIの総称で、WebSocket・SSE・Webhookを土台にします。AI開発の文脈では、音声の入出力とツール実行を1つのセッションで扱うOpenAIのRealtime APIを指します。

REST APIとリアルタイムAPIは何が違いますか？

REST APIは、クライアントが要求するたびに1回応答する型です。リアルタイムAPIは接続を張ったまま、サーバが変化を随時送ります。OpenAIのRealtime APIはさらに、音声の断片とイベントを双方向に流し続けます。

Realtime APIの料金はどう計算しますか？

応答ごとのトークン課金で、それまでの会話全体が毎回入力に数えられます。音声は利用者の発話が100ミリ秒で1トークン、モデルの発話が50ミリ秒で1トークンです。キャッシュが効くかで費用が数倍変わるため、実際の消費は response.done の usage で確かめてください。

LangChainでRealtime APIは使えますか？

LangChain公式の参照実装 react-voice-agent はアーカイブ済みで、固定されていたモデルも2025年10月10日に停止しています。langchain-openai 1.7.3にも音声セッション用のモジュールはありません。ツール定義は流用できますが、セッションとイベントの処理は自分で書く前提です。

文字起こしだけしたい場合もRealtime APIですか？

文字起こし専用のセッションがあります。wss://api.openai.com/v1/realtime?intent=transcription にモデル名を付けずに接続し、session.update で type: "transcription" と gpt-live-transcribe を指定します。録音済みの音声ならファイル向けの文字起こしを使います。

関連記事

• GPT-Realtime-2.1とは｜gpt-realtime-2との違い・料金・miniとGPT-Liveの使い分け
• GPT-Live-1とは？APIの料金・使い方とRealtime APIとの違い
• GPT-Live-Transcribeとは？OpenAIの低遅延ストリーミング文字起こしの実装手順とGPT-Transcribeとの使い分け
• WebSocketとは？仕組み・ハンドシェイクからNode.js実装・運用の判断まで実装者向けに解説
• 文字起こしAPIの比較と選び方｜主要7サービスの料金・日本語対応・使い方