概要
Realtime モデルは 長時間維持される WebSocket 接続 上で動作します。音声が入り、音声が出力され、モデルは文の途中で中断できます。つまり、「録音、アップロード、待機、再生」というサイクルはありません。ASR + テキストモデル + TTS をつなぎ合わせる方式との違いは、こちらはエンドツーエンドである点です。モデルはトーン、間、感情を直接聞き取り、直接話します。レイテンシは 1 秒未満の範囲に収まります。 APIYI は現在、2つのプロトコルにまたがる 4つのモデル を提供しており、1つのエンドポイントと1つのキーを共有しています。gpt-realtime-2.1/gpt-realtime-2.1-mini— OpenAI リアルタイム GA プロトコルqwen3.5-omni-plus-realtime/qwen3.5-omni-flash-realtime— Alibaba Cloud Model Studio プロトコル
server_vad と semantic_vad のターン検出、完全な function-calling の往復(結果注入を含む)、画像入力、そしてモダリティごとに分かれた usage。上記は4モデルすべてで検証済み(2026-08-24, UTC+8)。model パラメータだけを変えても動作しません — これは圧倒的に最も多い統合作業の失敗です。違いは合計 6 フィールドと 3 つのイベント名で、すべて下の「プロトコル比較」に記載しています。ベータアクセスをリクエスト
API マニュアル
キーとグループ
呼び出しログ
AIエージェントに統合作業を任せる
.md を付けてください)。その後、あなたのスタック向けのコードを書きます。2つのフィールドファミリー、サンプルレートの厳格な下限、キャンセルの挙動、アイドル切断はすべて要件に組み込まれています。コーディングエージェントに Realtime 音声の統合またはトラブルシューティングをさせてください。Codex、Claude Code、Cursor などのツールにコピー&ペーストしてください。
このプロンプトで回避できること
このプロンプトで回避できること
Realtime Voice に APIYI を使う理由
1つのキー、4つのモデル
wss エンドポイント、同じ認証。モデルを切り替えるときは、model パラメータと対応するフィールドテンプレートを変更するだけです。2つ目のベンダーアカウントを管理する必要はありません。海外設定不要の直接アクセス
api.apiyi.com にアクセスできます。上流ベンダーのアカウント、本人確認、前払いは不要です。プロトコルの違いはすでに対応済み
テキストによる無料セルフテスト
測定済みのレイテンシと同時実行数
ベータ期間中の直接サポート
コア機能
双方向ストリーミング、割り込み可能
response.cancelをいつでも送信できます。セッションは維持され、コンテキストは保持されます。4つのモデルすべてで検証済みです。2つのターン検出モード
server_vadは無音時間で分割し、semantic_vadは意図で分割します(「uh-huh」のようなフィラーワードを無視するのがより得意です)。どちらも4つのモデルすべてで検証済みです。完全な関数呼び出しループ
function_call_outputが結果を注入し、モデルは会話を続けます。4つのモデルすべてでエンドツーエンドに検証済みです。画像入力、モダリティごとの使用量
usageは text / audio / image tokens を個別に返すため、コストを割り当てられます。4つのモデルすべてで検証済みです。サポート対象モデル
価格
gpt-realtime-2.1の場合、audio input は $32、text input は $4、audio output は $64、text output は $24 です)。統合中は text のみで実行し、チェーンが検証できたら audio に切り替えてください — 下の「テキストから開始」をご覧ください。Realtime GAプロトコル
Model Studioプロトコル
課金の単位が異なります。image input は text の料金帯に含まれ、output は「text のみ」と「text + audio」に分かれます(後者のレートが適用されるのは audio 部分のみです)。アクセスグループ
技術仕様
測定されたレイテンシと同時実行数
2026-08-24 (UTC+8) に、公開api.apiyi.com 経路上で、20 個の同時セッション × 2 モデル、単一ターンのテキストのみのやり取りとして測定しました:
エンドポイント
model クエリパラメータで接続先のモデルを選択します。
⚠️ プロトコル比較(モデルを切り替える前にお読みください)
この2つのファミリーは、endpoint、auth scheme、そして全体のイベントフローを共有しています。違いはsession.update フィールド構造と、いくつかのサーバーイベント名に集中しています。
リクエストフィールドの比較
サーバーイベントの比較
session.created, session.updated, conversation.item.create, input_audio_buffer.append, input_audio_buffer.commit, response.create, response.cancel, response.done — は、両方で同一の名前です。
session.update ペイロードの最小例を2つ
同じ内容を2回書いたものです。そのままコピーしてください。Model Studioプロトコル:テキストから始める: テキストチャネルの役割と3段階のセルフテスト
オーディオパイプラインには、マイクの取り込み、リサンプリング、チャンク分割、ターン検出が含まれます。どこか1か所でも壊れると、「何も起きない」として現れ、原因特定が難しくなります。ですので、マイクから始めないでください。テキストは制御プレーンであり、フォールバック入力ではありません
リアルタイム音声モデルにおいて、テキストは「入力を送る別の方法」ではなく、音声ストリーム以外の、制御チャネルのすべてです。3段階のセルフテスト
ステップ1: テキストのみ、マイクなし
output_modalitiesをテキストのみに設定し、ターン検出を無効化して、input_textを1回送信します。これだけで、ハンドシェイク、キーとグループ、正しいフィールドテンプレートを選んだかどうか、session.updateが反映されたかどうか、ツールが正しく注入されるかどうか、複数ターンのコンテキストが保持されるかどうか、そして同時実行数の挙動を確認できます。音声tokenはまったく生成されません。ステップ2: ローカルのwavファイルを再生する
input_audio_buffer.appendに流し込みます。これにより、オーディオパイプライン(フォーマット、サンプルレート、チャンク分割、commit、VADトリガー)を業務ロジックから切り離せて、再現可能になります — 同じファイルなら2回とも同じ結果になるはずです。ステップ3: ライブマイクを接続する
実行可能なテキストのスモークテスト
websockets(pip install websockets)だけに依存します。1つの変数を切り替えるだけでプロトコルを変更できます:
セッション機能: ボイス、ターン検出、tools、画像
ボイス
ターン検出: server_vad と semantic_vad
server_vad— 無音の継続時間で分割し、パラメータはシンプルです(threshold、silence_duration_ms、prefix_padding_ms)。semantic_vad— 会話の意図で分割し、フィラー語や意味のない背景ノイズを無視します。複数話者環境でより堅牢です。- ターン検出(
nullまたはnone)を無効化して、手動モードで実行することもできます。input_audio_buffer.commitを自分で送信し、その後response.createを送ります。これは、UI がターンを制御するプッシュトゥトークのインターフェースに適しています。
関数呼び出し
イベント順序: モデルはresponse.output_item.done を function_call 型で出力し(call_id と arguments を含む)→ クライアントがそれを実行 → 結果が注入される → 別の response.create によりモデルが続行します。
画像入力
Realtime GA プロトコル:input_image をメッセージに直接入れてください。値にはデータ URI を指定できます。
Error append image before append audio. になります。テストでは、input_image_buffer.append を input_audio_buffer.append ストリームに 1 秒あたり約 1 フレームの割合で交互に挿入する方法が機能しました。
既知の制限(ベータ)
以下の4項目はいずれも確認済みで、すべてクライアントコードに影響します。統合する前にお読みください。ベストプラクティス
まずプロトコルファミリーごとにフィールドテンプレートを選ぶ
session.update ペイロードは、if 分岐を散らすのではなく、モデル名で選択する2つの設定定数として記述してください。これは、6か月後の保守時に最も壊れやすい部分です。最初のフレームでセッションパラメータを固定する
output_modalities、voice、speed、turn_detection、transcription を、最初の session.update で必ず設定してください。音声は特に重要です。いったんオーディオが生成されたら手遅れです。オーディオを追加する前にテキストのスモークテストを通す
サンプルレートとチャネルはクライアント側で変換する
タイムアウト付きで output_item.done で完了処理する
response.done だけを待たないでください。この方法は両方のファミリーで正しく、ユーザーが中断したときにターンがハングするのを防げます。長いセッションには keepalive と再接続を追加する
expires_at に注意してください。再接続後は、session.update と必要なコンテキストを再送してください。そうしないと、新しいセッションはデフォルト設定で動作します。本番環境ではバックエンドリレーを使う
エラーと再試行
event_id とセッションの session.id を記録し、問題を報告する際に含めてください。診断時間を大幅に短縮できます。なお、Realtime GA のエラーオブジェクトには code と param が含まれます(正確なフィールド名とその許容値を示します)が、Model Studio のエラーメッセージはより大まかです。デバッグ時は、まず前者でフィールド構文を検証してください。よくある質問
このページにインタラクティブなプレイグラウンドがないのはなぜですか?
このページにインタラクティブなプレイグラウンドがないのはなぜですか?
モデル名だけを変えて4つのモデルを切り替えられますか?
モデル名だけを変えて4つのモデルを切り替えられますか?
modalities ↔ output_modalities, voice ↔ audio.output.voice, input_audio_format ↔ audio.input.format, turn_detection ↔ audio.input.turn_detection, input_audio_transcription ↔ audio.input.transcription, さらにイベント名の response.text.delta ↔ response.output_text.delta と response.audio.delta ↔ response.output_audio.delta です。完全な対応表は Protocol Comparison セクションを参照してください。ハンドシェイクが完全に失敗します。どうデバッグすればよいですか?
ハンドシェイクが完全に失敗します。どうデバッグすればよいですか?
wss:// で、https:// ではないこと; 2. エンドポイントに ?model=<model-name> が含まれていること; 3. Authorization: Bearer <key> ヘッダーがあること; 4. キーがベータグループで有効になっていること(そうでない場合は「no available channel」で 503 になります); 5. 間にあるリバースプロキシが Upgrade ヘッダーを削除していないこと — これは自前のゲートウェイ経由でリレーする場合によくある問題です。ブラウザから接続できますか? キーは漏えいしますか?
ブラウザから接続できますか? キーは漏えいしますか?
Sec-WebSocket-Protocol サブプロトコル経由の認証を受け付けるため、ブラウザの WebSocket は直接接続できます。ただし、それではキーをブラウザに渡してしまうことになり、訪問者なら誰でもネットワークパネルから読めるため、ローカル検証にのみ適しています。本番環境ではバックエンドリレーを実装してください。バックエンドがキーを保持して APIYI への接続を開き、フロントエンドは自前のサービスとだけやり取りします。gpt-realtime-2.1 に 16 kHz の音声を送ると失敗します。なぜですか?
gpt-realtime-2.1 に 16 kHz の音声を送ると失敗します。なぜですか?
integer_below_min_value が返ります。正しい形式は "audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}} です。2つの Model Studio モデルは代わりに 16 kHz が必要で、両者は互換ではありません。マイクがありません / 音声のテストが難しいです。どうすればよいですか?
マイクがありません / 音声のテストが難しいです。どうすればよいですか?
say と afconvert を使えば1行で生成できます — コマンドはそのセクションにあります。response.cancel を送っても response.done を受け取れません。
response.cancel を送っても response.done を受け取れません。
response.text.done、response.content_part.done、response.output_item.done は受け取れますが、response.done は配信されません。response.output_item.done をターン終了シグナルとして使い、保険としてタイムアウトも追加してください。 セッション自体には影響せず、会話は通常どおり継続します。2つの Realtime GA モデルではここは正しく動作します。接続が約5分後に切れます。
接続が約5分後に切れます。
session.update)を送るか、切断を受け入れて自動的に再接続してください。再接続後は session.update と必要なコンテキストを再送するのを忘れないでください。1つのセッションはどれくらい開いたままにできますか?
1つのセッションはどれくらい開いたままにできますか?
session.created イベントが expires_at を運び、接続からおよそ30分でその制限に達するため、その後は再接続が必要です。Model Studio プロトコルで主に確認された制約は、300秒のアイドル切断です。長い会話はセッションが期限切れになる前提で設計し、コンテキストをセッション間でどう引き継ぐかを計画してください。音声はどう設定しますか? また、変更すると cannot_update_voice が返るのはなぜですか?
音声はどう設定しますか? また、変更すると cannot_update_voice が返るのはなぜですか?
session.update で音声を設定します: Model Studio ではトップレベルの voice、Realtime GA では audio.output.voice です。セッションが音声出力を生成したあとでは voice は変更できません — これは両方のプロトコルに当てはまり、cannot_update_voice が返ります。最初のフレームで固定し、切り替えるには新しいセッションを開いてください。また、Model Studio では voice に空文字列を送らないでください。400 が返ります。手動コミットモードで入力の文字起こしが取得できません。
手動コミットモードで入力の文字起こしが取得できません。
flash モデルは、手動 commit モードでは文字起こし完了イベントを返しません(実行ごとに一貫して再現されています)。plus モデルは返しますし、どちらも VAD モードでは動作します。server_vad または semantic_vad に切り替えてください。 テストでは、この場合 transcript テキストは delta イベント上のドキュメント化されていないフィールドに入ることが確認されていますが、そのフィールドはいつでも変更される可能性があり、依存すべきではありません。 なお、これは UI でユーザーの発話を表示する部分にのみ影響し、会話には影響しません。モデルは音声を正しく理解して回答します。画像入力はサポートされていますか? なぜ「Error append image before append audio.」が出るのですか?
画像入力はサポートされていますか? なぜ「Error append image before append audio.」が出るのですか?
input_image を直接置きます。Model Studio では画像は動画フレームとして扱われるため、最初の画像の前に音声を追加する必要があり、それがそのエラーを引き起こします。テストでは、画像フレームを音声 stream におよそ1秒あたり1フレームの割合で挟み込む方法がうまくいきました。プロンプトキャッシュはありますか? ヒットをどう確認しますか?
プロンプトキャッシュはありますか? ヒットをどう確認しますか?
usage.input_token_details.cached_tokens に値がありました。2つの Model Studio モデルでは cache hit は確認されませんでした。コストはどう見積もりますか? テキストと音声は別々に課金されますか?
コストはどう見積もりますか? テキストと音声は別々に課金されますか?
usage オブジェクトが response.done 上でモダリティごとの tokens(入力と出力でそれぞれ text / audio / image)を報告するため、コストを按分できます。音声の料金帯はテキストよりかなり高いので、統合作業中はテキストのみが推奨されます。実際の課金については、通話ログを参照してください。