Skip to main content

概要

Realtimeモデルは長時間維持されるWebSocket接続上で動作します。音声をストリーミングで入力し、音声をストリーミングで出力し、モデルは発話の途中でも割り込まれることがあります。「録音、アップロード、待機、再生」というサイクルは必要ありません。ASR + テキストモデル + TTSをつなぎ合わせる場合との違いは、これがエンドツーエンドであることです。モデルは声のトーン、間、感情を直接聞き取り、直接発話します。レイテンシーはサブ秒の範囲に収まります。 APIYIでは現在、2つのプロトコルにまたがる4モデルを提供しており、1つのエンドポイントと1つのキーを共有します。
  • gpt-realtime-2.1 / gpt-realtime-2.1-mini — OpenAI Realtime GAプロトコル
  • qwen3.5-omni-plus-realtime / qwen3.5-omni-flash-realtime — Alibaba Cloud Model Studioプロトコル
ステータス(2026-09-14更新、UTC+8):4モデルすべてが利用可能です。キーでデフォルトのグループを選択すれば、申請なしで直接呼び出せます。VIPおよびSVIPグループにも対応しています。ぜひテスト、検証、統合をお試しください。このページに不足している情報がある場合や、実測結果と異なる場合はお知らせください。上流のプロトコルや動作は今後も変更される可能性があります。以下の「既知の制限事項」に記載されている内容はすべて実測に基づいており、上流の変更に応じて更新されます。本番環境にリリースする前に、再接続とグレースフルデグラデーションを実装してください。より高い同時実行数が必要な場合は、WeComサポートまたは [email protected] / [email protected] までご連絡ください。
🎤 ハイライト:1つの接続を介した双方向ストリーミング音声、いつでも割り込み可能なバージイン、server_vadおよびsemantic_vadによるターン検出、結果の注入を含む完全なファンクションコールのラウンドトリップ、画像入力、そしてモダリティごとに分離されたusage。上記すべては4モデルで検証済みです(初回検証:2026-08-24、再検証:2026-09-14、UTC+8)。
まず覚えておくべきこと:4モデルは2つの異なるリクエストプロトコルを使用しており、フィールド名とイベント名も異なります。リクエストボディを変更せずにmodelパラメータだけを変更しても動作しません。これは、統合時に最もよく発生する失敗です。違いは6つのフィールドと3つのイベント名に集約されており、すべて以下の「プロトコル比較」に一覧されています。

WeComサポート

統合に関する質問、同時実行数の増加、ドキュメントの不足について、担当者に直接ご相談いただけます。

APIマニュアル

キーの作成、ベースURL、課金モード、その他の一般的な規則について説明します。

キーとグループ

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

呼び出しログ

コンソールで、呼び出しごとのtoken使用量と実際の料金を確認します。
このページは長いため、次の3つのセクションを必ずお読みください:プロトコル比較(モデルを切り替える前にお読みください)、テキストから始める(マイクを使わずにチェーン全体を検証します)、既知の制限事項(クライアントコードに影響する、実測に基づく4つの違いを説明します)。

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

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

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

リアルタイム音声に APIYI を選ぶ理由

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

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

直接アクセス、海外でのセットアップ不要

中国本土のデータセンター、自宅のブロードバンド、または海外ノードから api.apiyi.com にアクセスできます。上流ベンダーのアカウント、本人確認、事前入金は必要ありません。

プロトコルの違いをあらかじめ整理済み

フィールド比較、イベント名の比較、サンプルレートの制限、4つの実測制限をすべてここで説明しているため、自分で再調査する必要はありません。

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

マイクなしでハンドシェイク、認証、フィールド、ツール連携、同時実行数を検証できます。音声プランはテキストより1桁多くの費用がかかるため、これは統合時の実質的なコスト削減になります。

実測レイテンシーと同時実行数

40の同時セッションで、ハンドシェイクのp50は約1秒、最初のテキストデルタのp50も約1秒でした。120セッション中120セッションが成功しており、テスト条件と実施日は「技術仕様」に記載しています。

エンジニアによる直接サポート

統合に関する質問、同時実行数の増加、上流サービスの動作変更に対応するWeComの直接連絡チャネルを提供しています。

コア機能

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

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

2つのターン検出モード

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

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

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

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

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

対応モデル

4つのモデルすべてで、出力音声はPCM 符号付き16ビット/モノラル/24 kHzです。
2つのプロトコルファミリーで共有されるのはエンドポイントと認証方式のみです。リクエストフィールドとサーバーイベント名はどちらも異なります。モデルを切り替える場合は、フィールドテンプレートも切り替える必要があります。詳しくは以下の「プロトコル比較」を参照してください。

料金

料金を一文で言うと: token ごとの課金で、音声はテキストの約10倍のコストです(gpt-realtime-2.1 では、音声入力は $32、テキスト入力は $4、音声出力は $64、テキスト出力は $24)。統合時はテキストのみで実行し、チェーンの検証後に音声へ切り替えてください。以下の「テキストから開始」を参照してください。
以下の表は、1M tokens あたりの USD 建てのベンダー公式リスト価格です。APIYI は同一レートで token ごとに課金します(2026-09-14、UTC+8 にモダリティごとに照合)。APIYI での実際の請求額は、呼び出しログに表示される内容に従います。チャージボーナスにより、実効コストはさらに下がります。

Realtime GA プロトコル

Model Studio プロトコル

課金ディメンションが異なります。画像入力はテキスト階層に含まれ、出力は「テキストのみ」と「テキスト + 音声」に分かれます(後者のレートで課金されるのは音声部分のみです)。
課金に関する注記: テキスト、音声、画像の tokens は、上記リスト価格に基づき token ごとに課金されます。中断されたターン(response.cancel)は実際に生成された分のみが課金され、空のセッションは課金されません。キャッシュ済み入力はまだ割引されません: キャッシュヒットは usage.cached_tokens に正確に報告されますが、APIYI では現在、対応するテキスト入力レートで課金しています。課金経路が修正され次第、公式キャッシュレートが自動的に適用され、変更履歴でお知らせします。料金はベンダーのポリシーおよび供給状況により変更される場合があります。この機能は、供給を確保し顧客にサービスを提供するために提供しており、利益目的の掲載ではありません。

アクセスグループ

4つのモデルは、1つのエンドポイントと1つのキーを共有します。キー管理の下でチェックボックスを変更してグループを切り替えられます。コードの変更は不要です。

技術仕様

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

2026-09-14(UTC+8)に、公開 api.apiyi.com パス上で、gpt-realtime-2.1 と -mini をそれぞれ20および40同時セッションで測定しました。1ターンのテキストのみのやり取りです。
これらは特定の同時実行数における特定時点の測定値であり、パフォーマンスを保証するものではありません。可用性 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つのプロトコルは異なるため、混同しないでください。

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

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

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

ボイス

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

ターン検出: server_vad と semantic_vad

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

関数呼び出し

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

画像入力

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

既知の制限事項

以下の各項目は測定済みであり、すべてクライアントコードに影響します。統合する前にお読みください。
これらの動作はアップストリームの変更に伴って変わる可能性があります。このページは最新の状態に保たれます。ここに記載されていない問題が発生した場合は、追跡できるようタイムスタンプと session.id を添えて、WeCom サポート または [email protected] からご報告ください。

ベストプラクティス

1

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

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

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

output_modalities、voice、speed、turn_detection、transcription を、最初の 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のエラーオブジェクトにはcodeとparamが含まれます(正確なフィールドと、そのフィールドで受け付けられる値が示されます)。一方、Model Studioのエラーメッセージはより大まかな内容です。デバッグ時は、まず前者でフィールド構文を検証してください。

よくある質問

インタラクティブなプレイグラウンドは、HTTP 経由の単一のリクエストと単一のレスポンスを記述する OpenAPI 仕様によって動作します。Realtime は、1 つの長時間接続上で数十種類のイベントが双方向に流れるため、このモデルには当てはまりません。代わりに、「テキストから開始」セクションのテキストスモークテストを使用できます。数十行程度で、マイクも不要であり、チェーンが機能することを確認できます。
いいえ。 エンドポイントと認証は同じですが、リクエストフィールドとイベント名は 2 つのプロトコルに属します。最低限、次を変更する必要があります: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 です。完全な対応関係については、プロトコル比較セクションを参照してください。
次の 5 点を順番に確認してください:1. スキームが wss:// であり、https:// ではないこと。2. エンドポイントに ?model=<model-name> が含まれていること。3. Authorization: Bearer <key> ヘッダーが存在すること。4. キーのグループにモデルが含まれていること(4 つすべてデフォルトグループに含まれます。不一致の場合は「利用可能なチャネルがありません」というメッセージとともに 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 が必要であり、この 2 つは互換性がありません。
「テキストから開始」セクションの 3 段階のセルフテストに従ってください。まずテキストでチェーンを検証し(音声 token は生成されません)、次にローカルの wav ファイルを再生して音声パイプラインを検証し、その後でライブマイクに接続します。テスト音声は macOS の組み込み機能 say と afconvert を使って 1 行で生成できます。コマンドはそのセクションに記載されています。
これは 2 つの Model Studio モデルで確認されている既知の動作です(6 回のテストすべてで再現)。割り込み後は response.text.done、response.content_part.done、response.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 です。セッションで音声出力が生成された後は、音声を変更できません。これは両方のプロトコルに適用され、cannot_update_voice が返されます。最初のフレームで音声を固定し、切り替える場合は新しいセッションを開始してください。また、Model Studio では音声に空文字列を送信しないでください。400 が返されます。
Model Studio の flash モデルは、手動 commit モードで文字起こし完了イベントを配信しません(複数回の実行で一貫して再現)。plus モデルでは配信され、どちらのモデルも VAD モードでは動作します。server_vad または semantic_vad に切り替えてください。 テストでは、この場合、文字起こしテキストが delta イベントの未文書化フィールドに格納されることが確認されています。ただし、そのフィールドはいつでも変更される可能性があり、依存すべきではありません。これは UI にユーザーの発話内容を表示する場合にのみ影響します。会話には影響せず、モデルは音声を正しく理解して回答します。
4 つのモデルはすべて画像入力をサポートしていますが、構文が異なります。Realtime GA では、input_image をメッセージ内に直接配置します。Model Studio では画像をビデオフレームとして扱うため、画像より前に音声を追加する必要があり、それがこのエラーの原因です。テストで動作した方法は、音声ストリームに画像フレームを 1 秒あたりおよそ 1 フレームの割合でインターリーブすることです。
2 つの Realtime GA モデルがサポートしており、自動的に適用されます。テストでは、セッション内の 2 回目のターンですでにヒットし、usage.input_token_details.cached_tokens に値が入りました(少なくとも 1024 token のプレフィックス、128 token 単位)。現在、APIYI はキャッシュされた token をテキスト入力の通常料金で課金していることに注意してください。割引が提供開始され次第、変更履歴で告知されます。2 つの Model Studio モデルではキャッシュヒットは確認されませんでした。
いいえ。 POST /v1/realtime/client_secrets と POST /v1/realtime/calls はどちらも APIYI で 404 を返し、SIP も利用できません。単一の wss://api.apiyi.com/v1/realtime WebSocket エンドポイントのみがエントリーポイントです。ブラウザまたはモバイルクライアントでは、バックエンドリレーを作成してください。バックエンドがキーを保持して WebSocket を開き、フロントエンドは独自のサービスとのみ通信する構成にします。
はい。テストではすべてのフィールドが変更されずに通過し、session.updated にエコーバックされました:reasoning.effort(minimal / low / medium / high / xhigh、両方のモデルで受け付けられます)、audio.input.noise_reduction、audio.input.turn_detection.idle_timeout_ms、audio.input.transcription.model(gpt-realtime-whisper を含む)、truncation、tracing、max_output_tokens、parallel_tool_calls です。フィールドのセマンティクスは OpenAI のリファレンスに従い、ゲートウェイによる書き換えはありません。
response.done 上の usage オブジェクトは、モダリティごとの token(テキスト / 音声 / 画像を入力と出力で個別に集計)を報告するため、コストを割り当てられます。通話ログの詳細ビューにも、完了した response.done ごとに 1 レコードとして、同じモダリティ別の usage が表示されます。音声の料金階層はテキストより大幅に高いため、統合時にはテキストのみの利用を推奨します。実際の請求額については、通話ログを参照してください。

関連ドキュメント

APIマニュアル

キーの作成、ベースURL、課金モード、その他の一般的な規則。

キーとグループ

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

テキスト生成

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

モデルの料金

プラットフォーム上のすべてのモデルについて、最新の料金、エンドポイント、グループを確認できます。

チャージボーナス

実質的なコストをさらに削減します。

WeComサポート

統合に関する質問、同時実行数の増加、ドキュメントの不足に対応します。
4つすべてのリアルタイムモデルがデフォルトグループで利用可能です。このページの測定結果は、2026-08-24の初回テストおよび2026-09-14の再テスト(UTC+8)に基づいており、上流の変更に応じて更新されます。統合を予定している場合、このページで扱っていない問題が発生した場合、またはより高い同時実行数が必要な場合は、[email protected] / [email protected] までご連絡ください。