ブラウザでAI英会話はどうつながっているのか。2本の通り道と60分の上限を公式仕様から分解した

公開日 2026年9月19日(土) 10:11更新日更新なし

アプリを入れずにブラウザで動くAI英会話が増えている。

ページを開いてマイクを許可するだけで、会話が始まる。

この「開くだけ」の裏側では、音声が通る道が2本用意されていて、どちらを使うかで挙動が変わる。

途中で切れる、声が遅れる、長く話していると終わる。こうした症状は、通り道の仕様を読むと位置が特定できる。

しかも接続の手順そのものが、公式の開発者向けドキュメントに手順書の形で公開されている。

この記事では、AIの音声部品を売っている会社の公式ドキュメントの記述だけを材料にして、ブラウザの中で何が起きているかを開けていく。

サービスの順位づけはしない。仕組みの話だけをする。

TOC

【結論】AI英会話をブラウザで動かす通り道は2本しかない

先に答えを置く。

OpenAI の音声対話APIの公式ガイドは、接続の形をこう書いている。

「The session connects over WebRTC in the browser or WebSocket on the server.」（Getting started with the Realtime API・OpenAI）

訳すと「セッションはブラウザでは WebRTC、サーバー側では WebSocket でつながる」となる。

⇒ ブラウザで直接つなぐなら WebRTC、いったん自社サーバーを挟むなら WebSocket。この2本だ。

通り道	音の扱い	公式の位置づけ
WebRTC	ブラウザ側のAPIが送受信を肩代わりする	ブラウザから直接つなぐときの形
WebSocket	音声をBase64にして自分で送り、自分で受ける	サーバーからつなぐときの形

この違いは、そのまま「途切れ方の違い」に出る。

AI英会話のブラウザ接続は4つの手順で始まっている

公式ガイドは、ブラウザで始めるときの流れを4行で示している。

アプリのサーバーが、そのセッション用の使い捨ての鍵を作る。
ブラウザ側が会話のセッションを作る。
セッションが WebRTC（ブラウザ）または WebSocket（サーバー）でつながる。
そのセッションの中で、発話の順番・道具の呼び出し・割り込み・引き継ぎが処理される。

重要なのは、4つ目に「割り込み」が最初から入っていることだ。

公式は同じページで、このAPIを使うべき場面を「barge-in, low first-audio latency, natural turn taking, and realtime tool use」が必要なときだと書いている。

barge-in＝相手が話している最中に割り込むこと。

⇒ 割り込めることは後付けの機能ではなく、この通り道を選ぶ理由そのものだ。

ブラウザのAI英会話が使う鍵は「使い捨て」になっている

手順の1つ目にある鍵の話は、仕組みとして押さえておく価値がある。

公式のコード例では、ブラウザが受け取る鍵に ek_... という接頭辞が付き、「ephemeral key from your server」と注記されている。

ephemeral＝短命、つまりその場かぎりの鍵だ。

公式は移行手順の節で「Use POST /v1/realtime/client_secrets to create ephemeral credentials for browser or mobile clients.」と、作り方まで指定している。

⇒ 本物の鍵はブラウザに置かない、という設計が前提になっている。

ブラウザに置いた文字列は、開発者ツールを開けば誰でも読めるからだ。

この形のおかげで、ページを再読み込みするたびに新しいセッションが作られる。

WebRTCでつながるAI英会話はブラウザに音の面倒を任せている

WebRTC を選んだ場合、音の送受信はブラウザの標準機能が受け持つ。

公式の会話管理ガイドはこう書いている（Managing conversations・OpenAI）。

「If you are using WebRTC, much of the media handling required to send and receive audio from the model is assisted by WebRTC APIs.」

具体的には、マイクの取得に getUserMedia を使い、集めた音を接続のトラックとして足す形になる。

そしてこの形のいちばん大きな違いが、次の1文だ。

「By default, WebRTC clients don’t need to send any client events to the Realtime API before sending audio inputs. Once a local audio track is added to the peer connection, your users can just start talking!」

⇒ マイクをつないだら、あとは話し始めるだけでいい。

ボタンを押さずに会話が成立するタイプのAI英会話は、この形に近い。

WebSocketのAI英会話は音を自分で刻んで送っている

もう一方の WebSocket では、手作業が増える。

公式はこう書いている。「If you are using WebSockets for audio, you will need to manually interact with the input audio buffer by sending audio to the server, sent with JSON events with base64-encoded audio.」

音声を Base64 という文字列の形に変換し、JSONイベントとして送る。

イベント	役割
`input_audio_buffer.append`	音声のかたまりを送る。1つのかたまりは15MBを超えられない
`input_audio_buffer.commit`	「ここまでが1回の発話」と確定する
`response.output_audio.delta`	返ってくる音声を、分割された形で受け取る
`output_audio_buffer.clear`	再生していない音を捨てる。割り込みのときに使う

公式は、返答の完了イベントには音声そのものが入らないとも書いている。

「Note that the response.output_audio.done and response.done events won’t actually contain audio data in them – just audio content transcriptions.」

⇒ 音は細切れで届き、受け取る側がつなぎ直している。

再生が途切れがちになる余地は、この組み立て直しの工程にある。

AI英会話のブラウザ接続には60分という上限がある

通り道の話で、いちばんはっきりした数字がこれだ。

「The maximum duration of a Realtime session is 60 minutes.」

⇒ 1回のセッションは最長60分。

長時間の会話をしていると突然終わる、という現象には、この上限が関わっている可能性がある。

ただし、アプリ側がセッションを作り直して会話を続ける作りになっていれば、利用者からは見えない。

その場合に問題になるのは、作り直したセッションへ前の会話が引き継がれているかどうかだ。

ここは製品ごとの作りの違いであって、通り道の仕様では決まらない。

会話の途中でAI英会話の声だけは差し替えられない

セッションの設定は、つながったあとでも変えられる。

公式はこう書いている。「Most session properties can be updated at any time, except for the voice the model uses for audio output, after the model has responded with audio once during the session.」

⇒ ほとんどの設定はいつでも変えられるが、いちど音声で返答したあとの「声」だけは変えられない。

声を変えたければ、会話を切って始め直すしかない構造だ。

AI英会話のアプリで「話す相手を変える」と会話が最初からになるのは、この制約と噛み合っている。

逆に、速さや指示文の変更が会話の途中で効くのは、こちらが session.update でいつでも送れる側だからだ。

ブラウザのAI英会話でマイクの選択やミュートができる理由

画面に出るマイクのボタンも、独自機能ではない。

公式はこう書いている。「Using media captures and streams in the browser enables you to do things like mute and unmute microphones, select which device to collect input from, and more.」

⇒ ミュートも入力デバイスの切り替えも、ブラウザの標準機能の側にある。

だから、同じサービスでもブラウザやOSが変わると挙動が変わることがある。

マイクの許可を求める画面＝ブラウザが出している。
どのマイクを使うかの一覧＝ブラウザが持っている情報。
音が拾えているかの表示＝取得した音の波形を見ている。

マイクが選べないときにサービス側へ問い合わせても解決しにくいのは、この層の違いが理由だ。

AI英会話のブラウザ利用には、利用者を識別する仕組みも用意されている

通り道の仕様には、安全のための項目も含まれている。

公式は、個々の利用者を識別するアプリに対して OpenAI-Safety-Identifier というヘッダーを送ることを勧めている。

「Use a stable, privacy-preserving value, such as a hashed internal user ID.」＝そのままのIDではなく、ハッシュ化した値を使えという指定だ（Safety best practices・OpenAI）。

目的も明記されていて、問題のある使い方が起きたときに、組織全体ではなく個人へ対処を絞れるようにするためだとされている。

公式は推奨であって必須ではないとも書いている。

⇒ 入れるかどうかはサービス側の判断になる。

ブラウザとAI英会話に関するよくある質問

Q. アプリ版とブラウザ版で会話の反応が違うのはなぜか。 A. 公式は接続の形を2つ示しており、ブラウザは WebRTC、サーバー経由は WebSocket と書き分けている。WebRTC ではブラウザのAPIが音の扱いを肩代わりし、WebSocket では音を分割して自分で送る形になる。音の組み立て方が違えば、体感の差が出る余地がある。

Q. 1時間くらい話していると切れるのは不具合か。 A. 公式は「The maximum duration of a Realtime session is 60 minutes.」と明記している。仕様上の上限であり、アプリがセッションを作り直す作りになっているかどうかで見え方が変わる。

Q. 会話の途中で声を変えられないのはなぜか。 A. 「Most session properties can be updated at any time, except for the voice… after the model has responded with audio once during the session.」と書かれている。いちど音声で返答したあとの声の変更だけが例外として除かれている。

Q. マイクの許可を毎回求められるのはサービス側の設定か。 A. マイクの取得はブラウザの getUserMedia が担当している。公式は、ミュートや入力デバイスの選択がブラウザ側の機能でできると書いており、許可の扱いもその層にある。

Q. ブラウザに鍵が置かれていると危なくないのか。 A. 公式が指定しているのは使い捨ての鍵で、コード例では ek_ で始まる文字列に「ephemeral key from your server」と注記されている。作成には専用の入口（POST /v1/realtime/client_secrets）を使うよう書かれている。