Skip to main content

概要

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 プロトコル
状態: プライベートベータ / 統合作業中。 Realtime 音声は供給数が限られており、まだセルフサービスでは利用できません — 有効化にはご連絡が必要です。上流のプロトコルと挙動は、ベータ期間中に変更される可能性があります。以下の「既知の制限事項」セクションの内容はすべて実測済みで、上流の変更に合わせて更新されます。フォールバック経路なしで本番環境にリリースしないでください。統合作業を予定している場合、またはより高い同時実行数が必要な場合は、WeComサポート[email protected] / [email protected] までご連絡ください。
🎤 ハイライト: 1つの接続で双方向ストリーミング音声、いつでも barge-in 可能server_vadsemantic_vad のターン検出、完全な function-calling の往復(結果注入を含む)、画像入力、そしてモダリティごとに分かれた usage。上記は4モデルすべてで検証済み(2026-08-24, UTC+8)。
まず覚えておくべきこと: 4つのモデルは 2種類の異なるリクエストプロトコル を使用しており、フィールド名もイベント名も異なります。リクエストボディを変更せずに model パラメータだけを変えても動作しません — これは圧倒的に最も多い統合作業の失敗です。違いは合計 6 フィールドと 3 つのイベント名で、すべて下の「プロトコル比較」に記載しています。

ベータアクセスをリクエスト

アカウント情報と想定同時実行数を添えて WeComサポートにご連絡いただければ、キーにベータグループを有効化します。

API マニュアル

キー作成、base URL、課金モード、その他の一般的な規約。

キーとグループ

キーを作成し、グループを選択し、クォータを設定します。

呼び出しログ

コンソールで token 使用量と呼び出しごとの実際の課金額を確認します。
このページは長文です。必読のセクションは3つあります。プロトコル比較(モデルを切り替える前に読む)、テキストから始める(マイクなしで全体の流れを確認する)、および既知の制限事項(クライアントコードに影響する4つの実測差分)です。

AIエージェントに統合作業を任せる

Codex / Claude Code / Cursor で開発している場合は、下のプロンプトをそこに貼り付けてください。まずこのページのプレーンテキスト版を取得します(任意の docs URL の末尾に .md を付けてください)。その後、あなたのスタック向けのコードを書きます。2つのフィールドファミリー、サンプルレートの厳格な下限、キャンセルの挙動、アイドル切断はすべて要件に組み込まれています。

コーディングエージェントに Realtime 音声の統合またはトラブルシューティングをさせてください。Codex、Claude Code、Cursor などのツールにコピー&ペーストしてください。

Realtime Voice に APIYI を使う理由

1つのキー、4つのモデル

同じ wss エンドポイント、同じ認証。モデルを切り替えるときは、model パラメータと対応するフィールドテンプレートを変更するだけです。2つ目のベンダーアカウントを管理する必要はありません。

海外設定不要の直接アクセス

中国本土のデータセンター、家庭用ブロードバンド、または海外ノードから api.apiyi.com にアクセスできます。上流ベンダーのアカウント、本人確認、前払いは不要です。

プロトコルの違いはすでに対応済み

フィールド比較、イベント名比較、サンプルレートの制限、そして4つの測定済みの制約はすべてここに記載されているため、改めて調べ直す必要はありません。

テキストによる無料セルフテスト

マイクなしで、ハンドシェイク、認証、フィールド、ツール接続、同時実行数を検証できます — 音声プランはテキストより桁違いに高いため、統合時の実コスト削減につながります。

測定済みのレイテンシと同時実行数

20件の同時セッションでは、ハンドシェイクの p50 は 0.65–1.08 s、最初のテキスト delta の p50 は 0.54–0.95 s です。テスト条件と日付は、Technical Specs に記載しています。

ベータ期間中の直接サポート

ベータ版ユーザーは、統合に関する質問、同時実行数の増加、上流側の挙動変更について、直接の WeCom チャネルを利用できます。

コア機能

双方向ストリーミング、割り込み可能

音声は生成されるそばからストリーミングされ、クライアントはresponse.cancelをいつでも送信できます。セッションは維持され、コンテキストは保持されます。4つのモデルすべてで検証済みです。

2つのターン検出モード

server_vadは無音時間で分割し、semantic_vadは意図で分割します(「uh-huh」のようなフィラーワードを無視するのがより得意です)。どちらも4つのモデルすべてで検証済みです。

完全な関数呼び出しループ

モデルがツールを起動し、クライアントがそれを実行し、function_call_outputが結果を注入し、モデルは会話を続けます。4つのモデルすべてでエンドツーエンドに検証済みです。

画像入力、モダリティごとの使用量

セッション中に画像を送信して、モデルに読み取らせます;usageは text / audio / image tokens を個別に返すため、コストを割り当てられます。4つのモデルすべてで検証済みです。

サポート対象モデル

出力音声は4つのモデルすべてで PCM signed 16-bit / mono / 24 kHz です。
2つのプロトコルファミリーは エンドポイントと認証方式だけを共有します。リクエストフィールドとサーバーイベント名はいずれも異なります。モデルを切り替える際はフィールドテンプレートも切り替える必要があります — 下記の「プロトコル比較」を参照してください。

価格

1文で言うと: 課金は token ごとで、audio は text より桁違いに高額ですgpt-realtime-2.1の場合、audio input は $32、text input は $4、audio output は $64、text output は $24 です)。統合中は text のみで実行し、チェーンが検証できたら audio に切り替えてください — 下の「テキストから開始」をご覧ください。
以下の表は、ベンダーの公式リスト価格で、1M token あたりの USD です。APIYI での実際の課金額は call logs に表示される内容そのものですrecharge bonus により、実効コストはさらに下がります。

Realtime GAプロトコル

Model Studioプロトコル

課金の単位が異なります。image input は text の料金帯に含まれ、output は「text のみ」と「text + audio」に分かれます(後者のレートが適用されるのは audio 部分のみです)。
ベータ版の注意: Realtime voice は供給が限られており、課金はまだ上流側と調整中です。実際の課金額が上の表と大きく異なる場合は、整合を取るためにサポートへご連絡ください。価格はベンダーの方針や供給状況によって変更される場合があります。この機能は供給を確保し、お客様に提供するためのものであり、利益目的の掲載ではありません。

アクセスグループ

ベータ期間中に有効化する方法: まだセルフサービスでのグループ選択は利用できません。アクセスは申請に基づいて付与されます。アカウント、ユースケース、想定される同時実行数を添えてWeCom サポートにお問い合わせください。こちらでキーにベータグループを有効化し、現在の注意点をご案内します。一般提供開始は変更履歴で告知します。その時点では、キーやコードの変更は不要です。

技術仕様

測定されたレイテンシと同時実行数

2026-08-24 (UTC+8) に、公開 api.apiyi.com 経路上で、20 個の同時セッション × 2 モデル、単一ターンのテキストのみのやり取りとして測定しました:
これらは特定の同時実行数レベルでの時点測定であり、性能保証ではありません。ベータ期間中は可用性SLAは提供されません — クライアント側で再接続と適切な縮退を実装してください。

エンドポイント

4つのモデルはすべてこのエンドポイントを共有します; model クエリパラメータで接続先のモデルを選択します。
ブラウザから接続する場合: このエンドポイントは Sec-WebSocket-Protocol サブプロトコル(realtime, openai-insecure-api-key.<key>, openai-beta.realtime-v1)による認証も受け付けるため、ブラウザWebSocketは直接接続できます — ただし、それでは キーをブラウザに渡してしまい、訪問者なら誰でもネットワークパネルから確認できてしまいます。ローカルでの検証にのみ使用してください。 本番環境では、バックエンドのリレーを作成します。バックエンドがキーを保持して APIYI への接続を開き、フロントエンドは自分のサービスとのみ通信します。

⚠️ プロトコル比較(モデルを切り替える前にお読みください)

この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プロトコル:
Realtime GAプロトコル:
サンプルレートは厳格な制約です: Realtime GAプロトコルでは audio.input.format.rate≥ 24000 である必要があります。16000 を送ると、integer_below_min_value: Expected a value >= 24000 で即座に失敗します。Model Studioプロトコルでは 16 kHz 入力が必要です。クライアント側で再サンプリングしてください。

テキストから始める: テキストチャネルの役割と3段階のセルフテスト

オーディオパイプラインには、マイクの取り込み、リサンプリング、チャンク分割、ターン検出が含まれます。どこか1か所でも壊れると、「何も起きない」として現れ、原因特定が難しくなります。ですので、マイクから始めないでください

テキストは制御プレーンであり、フォールバック入力ではありません

リアルタイム音声モデルにおいて、テキストは「入力を送る別の方法」ではなく、音声ストリーム以外の、制御チャネルのすべてです。

3段階のセルフテスト

1

ステップ1: テキストのみ、マイクなし

output_modalitiesをテキストのみに設定し、ターン検出を無効化して、input_textを1回送信します。これだけで、ハンドシェイク、キーとグループ、正しいフィールドテンプレートを選んだかどうかsession.updateが反映されたかどうか、ツールが正しく注入されるかどうか、複数ターンのコンテキストが保持されるかどうか、そして同時実行数の挙動を確認できます。音声tokenはまったく生成されません。
2

ステップ2: ローカルのwavファイルを再生する

マイクの代わりに固定のローカル音声ファイルを使い、100 msのチャンクでinput_audio_buffer.appendに流し込みます。これにより、オーディオパイプライン(フォーマット、サンプルレート、チャンク分割、commit、VADトリガー)を業務ロジックから切り離せて、再現可能になります — 同じファイルなら2回とも同じ結果になるはずです。
3

ステップ3: ライブマイクを接続する

最初の2段階を通過したら、残るのは取り込みと再生だけです。ここで何か壊れていても、探索範囲はすでに狭くなっています。
テスト用音声が手元にありませんか? macOSでは、標準搭載ツールで要件を満たすファイルを1行で生成できます:
ステップ2で最もよくある失敗は、サンプルレートの選択ミスです — 2つのプロトコルは異なるため、混同しないでください。

実行可能なテキストのスモークテスト

websocketspip install websockets)だけに依存します。1つの変数を切り替えるだけでプロトコルを変更できます:
これが動作すれば、エンドポイント、キー、グループ、フィールドテンプレートはすべて正しいので、ステップ2へ進んでください。

セッション機能: ボイス、ターン検出、tools、画像

ボイス

最初のsession.updateでボイスを固定してください。 セッションが一度音声出力を生成した後は、ボイスの変更は cannot_update_voice で失敗します。これは両方のプロトコルに適用されます。ボイスを切り替えるには新しいセッションを開いてください。また、Model Studio プロトコルでは ボイスとして空文字列を送信しないでください。サポートされていないボイスにフォールバックし、400 を返します。設定が不要な場合は、そのフィールドを単に省略してください。

ターン検出: server_vad と semantic_vad

  • server_vad — 無音の継続時間で分割し、パラメータはシンプルです(thresholdsilence_duration_msprefix_padding_ms)。
  • semantic_vad — 会話の意図で分割し、フィラー語や意味のない背景ノイズを無視します。複数話者環境でより堅牢です。
  • ターン検出(null または none)を無効化して、手動モードで実行することもできます。input_audio_buffer.commit を自分で送信し、その後 response.create を送ります。これは、UI がターンを制御するプッシュトゥトークのインターフェースに適しています。
VAD モードでは ストリーミングを継続する必要があります。発話が終わったら、サーバーが発話終了を検出できるように、短い無音区間を送り続けてください(テストでは 2 秒あれば十分です)。音声区間だけを送って停止すると、speech_stopped は一度も発火せず、応答は生成されません。

関数呼び出し

イベント順序: モデルは response.output_item.donefunction_call 型で出力し(call_idarguments を含む)→ クライアントがそれを実行 → 結果が注入される → 別の response.create によりモデルが続行します。
完全なループは 4 つのモデルすべてで検証済みです。注入後、モデルはツールが返した内容を正しく復唱します。

画像入力

Realtime GA プロトコル: input_image をメッセージに直接入れてください。値にはデータ URI を指定できます。
Model Studio プロトコル: 画像は 動画フレーム として扱われるため、先に音声を追加する必要があります。そうしないと Error append image before append audio. になります。テストでは、input_image_buffer.appendinput_audio_buffer.append ストリームに 1 秒あたり約 1 フレームの割合で交互に挿入する方法が機能しました。

既知の制限(ベータ)

以下の4項目はいずれも確認済みで、すべてクライアントコードに影響します。統合する前にお読みください。
これらの挙動は、ベータ期間中に上流が進化するにつれて変更される可能性があります。このページは常に最新の内容に保ちます。ここに記載のない問題に遭遇した場合は、WeComサポート または [email protected] まで、タイムスタンプと session.id を添えてご報告ください。追跡できるようにします。

ベストプラクティス

1

まずプロトコルファミリーごとにフィールドテンプレートを選ぶ

2つの session.update ペイロードは、if 分岐を散らすのではなく、モデル名で選択する2つの設定定数として記述してください。これは、6か月後の保守時に最も壊れやすい部分です。
2

最初のフレームでセッションパラメータを固定する

output_modalitiesvoicespeedturn_detectiontranscription を、最初の session.update で必ず設定してください。音声は特に重要です。いったんオーディオが生成されたら手遅れです。
3

オーディオを追加する前にテキストのスモークテストを通す

このページでテキストのスモークテストを実行し、エンドポイント、キー、グループ、フィールドテンプレートがすべて正しいことを確認してから、オーディオに進んでください。オーディオのティアはテキストより桁違いに高額なので、これで統合予算の大半を節約できます。
4

サンプルレートとチャネルはクライアント側で変換する

PCM 符号付き 16 ビット、モノラル。Model Studio では 16 kHz、Realtime GA では 24 kHz 以上です。サーバー側での補正は期待しないでください。フォーマットが間違っていると、明示的なエラーではなく無音として現れることがほとんどです。
5

タイムアウト付きで output_item.done で完了処理する

response.done だけを待たないでください。この方法は両方のファミリーで正しく、ユーザーが中断したときにターンがハングするのを防げます。
6

長いセッションには keepalive と再接続を追加する

Model Studio の 300 秒のアイドル制限と、Realtime GA の expires_at に注意してください。再接続後は、session.update と必要なコンテキストを再送してください。そうしないと、新しいセッションはデフォルト設定で動作します。
7

本番環境ではバックエンドリレーを使う

キーはバックエンドに保持し、フロントエンドは自分のサービスにのみ通信させてください。ブラウザからの直接接続は技術的には動作しますが、キーが露出します。

エラーと再試行

トラブルシューティングのヒント: 各イベントの event_id とセッションの session.id を記録し、問題を報告する際に含めてください。診断時間を大幅に短縮できます。なお、Realtime GA のエラーオブジェクトには codeparam が含まれます(正確なフィールド名とその許容値を示します)が、Model Studio のエラーメッセージはより大まかです。デバッグ時は、まず前者でフィールド構文を検証してください。

よくある質問

インタラクティブなプレイグラウンドは OpenAPI 仕様によって動作し、HTTP 経由で1つのリクエストと1つのレスポンスを記述します。Realtime は、1本の長寿命接続を通じて両方向に流れる多数のイベントタイプであり、このモデルには当てはまりません。代替手段は「テキストから始める」セクションのテキストのスモークテストです。数十行程度で、マイクは不要で、チェーンが動作することを確認できます。
いいえ。 エンドポイントと認証は同じですが、リクエストフィールドとイベント名は2つのプロトコルに属しています。少なくとも次を変更する必要があります: modalitiesoutput_modalities, voiceaudio.output.voice, input_audio_formataudio.input.format, turn_detectionaudio.input.turn_detection, input_audio_transcriptionaudio.input.transcription, さらにイベント名の response.text.deltaresponse.output_text.deltaresponse.audio.deltaresponse.output_audio.delta です。完全な対応表は Protocol Comparison セクションを参照してください。
順に5点確認してください: 1. スキームが wss:// で、https:// ではないこと; 2. エンドポイントに ?model=<model-name> が含まれていること; 3. Authorization: Bearer <key> ヘッダーがあること; 4. キーがベータグループで有効になっていること(そうでない場合は「no available channel」で 503 になります); 5. 間にあるリバースプロキシが Upgrade ヘッダーを削除していないこと — これは自前のゲートウェイ経由でリレーする場合によくある問題です。
技術的には可能です — エンドポイントは Sec-WebSocket-Protocol サブプロトコル経由の認証を受け付けるため、ブラウザの WebSocket は直接接続できます。ただし、それではキーをブラウザに渡してしまうことになり、訪問者なら誰でもネットワークパネルから読めるため、ローカル検証にのみ適しています。本番環境ではバックエンドリレーを実装してください。バックエンドがキーを保持して APIYI への接続を開き、フロントエンドは自前のサービスとだけやり取りします。
Realtime GA プロトコルでは入力サンプルレートとして 少なくとも 24000 が必要です。16000 では integer_below_min_value が返ります。正しい形式は "audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}} です。2つの Model Studio モデルは代わりに 16 kHz が必要で、両者は互換ではありません。
「テキストから始める」セクションの3ステップのセルフテストに従ってください。まずテキストだけでチェーンを検証し(audio tokens は生成されません)、次にローカルの wav ファイルを再生して音声パイプラインを検証し、そのあとでライブマイクを接続します。テスト用音声は macOS の標準機能 sayafconvert を使えば1行で生成できます — コマンドはそのセクションにあります。
これは2つの Model Studio モデルで既知の挙動です(6回のテスト実行すべてで再現済み): 中断後に response.text.doneresponse.content_part.doneresponse.output_item.done は受け取れますが、response.done は配信されません。response.output_item.done をターン終了シグナルとして使い、保険としてタイムアウトも追加してください。 セッション自体には影響せず、会話は通常どおり継続します。2つの Realtime GA モデルではここは正しく動作します。
Model Studio プロトコルでは、300秒の非アクティブ状態のあとに接続が切断され、WebSocketレベルの ping/pong はアクティビティとしてカウントされません — ハートビートではこのタイマーは延長されません。アイドル中は定期的にアプリケーションレベルのイベント(たとえば session.update)を送るか、切断を受け入れて自動的に再接続してください。再接続後は session.update と必要なコンテキストを再送するのを忘れないでください。
Realtime GA プロトコルでは、session.created イベントが expires_at を運び、接続からおよそ30分でその制限に達するため、その後は再接続が必要です。Model Studio プロトコルで主に確認された制約は、300秒のアイドル切断です。長い会話はセッションが期限切れになる前提で設計し、コンテキストをセッション間でどう引き継ぐかを計画してください。
session.update で音声を設定します: Model Studio ではトップレベルの voice、Realtime GA では audio.output.voice です。セッションが音声出力を生成したあとでは voice は変更できません — これは両方のプロトコルに当てはまり、cannot_update_voice が返ります。最初のフレームで固定し、切り替えるには新しいセッションを開いてください。また、Model Studio では voice に空文字列を送らないでください。400 が返ります。
Model Studio 上の flash モデルは、手動 commit モードでは文字起こし完了イベントを返しません(実行ごとに一貫して再現されています)。plus モデルは返しますし、どちらも VAD モードでは動作します。server_vad または semantic_vad に切り替えてください。 テストでは、この場合 transcript テキストは delta イベント上のドキュメント化されていないフィールドに入ることが確認されていますが、そのフィールドはいつでも変更される可能性があり、依存すべきではありません。 なお、これは UI でユーザーの発話を表示する部分にのみ影響し、会話には影響しません。モデルは音声を正しく理解して回答します。
4つのモデルすべてが画像入力をサポートしていますが、構文は異なります。Realtime GA ではメッセージ内に input_image を直接置きます。Model Studio では画像は動画フレームとして扱われるため、最初の画像の前に音声を追加する必要があり、それがそのエラーを引き起こします。テストでは、画像フレームを音声 stream におよそ1秒あたり1フレームの割合で挟み込む方法がうまくいきました。
2つの Realtime GA モデルはこれをサポートしており、自動的に適用されます — テストでは、セッション内の2回目のターンですでに cache hit があり、usage.input_token_details.cached_tokens に値がありました。2つの Model Studio モデルでは cache hit は確認されませんでした。
usage オブジェクトが response.done 上でモダリティごとの tokens(入力と出力でそれぞれ text / audio / image)を報告するため、コストを按分できます。音声の料金帯はテキストよりかなり高いので、統合作業中はテキストのみが推奨されます。実際の課金については、通話ログを参照してください。

関連ドキュメント

API マニュアル

キーの作成、base URL、課金モード、その他の一般的な規約。

キーとグループ

キーを作成し、グループを選択してクォータを設定します。

テキスト生成

通常のチャットモデル — テキストのみの会話により適しています。

モデル料金

プラットフォーム上のすべてのモデルのリアルタイム料金、エンドポイント、グループ。

チャージボーナス

実質コストをさらに下げます。

ベータアクセスをリクエスト

アカウントと予想される同時実行数を添えて WeCom サポートにお問い合わせください。
Realtime voice は現在 プライベートベータ です。このページのすべての測定結果は 2026-08-24 (UTC+8) 時点のもので、上流側の変更に応じて更新されます。統合を予定している場合、このページで扱っていない事項に該当する場合、またはより高い同時実行数が必要な場合は、[email protected] / [email protected] までご連絡ください。