AI英会話のアプリで通話ボタンを押すと1秒ほど間が空く。この裏で済まされているのが認証で、ブラウザは会話を始める直前に鍵を1本受け取っている。
ただし、その鍵は本物ではない。
OpenAI の Realtime API の入門ガイドは、ブラウザで音声の会話を始める流れの1段目に、使い捨ての資格情報をアプリのサーバーが作ることを置いている。
英語のドキュメントでは ephemeral、つまり「短命な」という語が当てられている。
本物の鍵はサーバーに置いたまま、ブラウザには一時的な鍵だけを渡す、という設計だ。
この1手間があるかどうかで、アプリの安全性はまるごと変わる。
この記事では、開発者向けの公式ドキュメントに書かれた手順とヘッダーだけを材料に、通話が始まるまでに何が往復しているのかを開けていく。
サービスの順位づけはしない。
【結論】AI英会話の認証は、ブラウザに本物の鍵を置かないための迂回路
先に答えを置いておく。
音声の会話は、ブラウザと相手のサーバーが直接つながって初めて滑らかに動く。
ところが直接つなぐには、ブラウザ側が何らかの鍵を持っていなければならない。
ここで本物の鍵を渡すと、ページを開いた誰にでも中身が見えてしまう。
だから WebRTC のガイドは、標準のAPIキーを使うのはサーバーだけにして、ブラウザでは使うな、と太字で釘を刺している。
⇒ 使い捨ての鍵は、便利機能ではなく「本物を外に出さない」ための迂回路として置かれている。
AI英会話の認証①｜通話が始まるまでの流れは4段に分かれている
入門ガイドは、ブラウザでよくある流れとして4つの段を並べている。
| 段 | 誰が動くか | 何をしているか |
|---|---|---|
| ① | アプリのサーバー | そのセッション用の使い捨ての資格情報を作る |
| ② | ブラウザ側 | 会話のためのセッションを組み立てる |
| ③ | 接続の層 | ブラウザなら WebRTC、サーバーからなら WebSocket でつなぐ |
| ④ | セッションの中 | 音声のターン、道具、割り込み、担当の受け渡しを処理する |
学習者がボタンを押してから声が返ってくるまでに、この4段がすべて終わっている。
同じガイドは、この方式が向く場面も書いている。
割り込んで話せること、最初の音が出るまでが短いこと、自然な話し手の交代、そして会話中に道具を使えること。
この4つが要るときの出発点だ、という位置づけになっている。
⇒ AI英会話で「こちらが話し始めるとAIが黙る」あの挙動は、この接続の形とセットで設計されている。
AI英会話の認証②｜使い捨ての鍵は、アプリ側の小さなサーバーが作る
鍵を作る役は、ブラウザではなくアプリのサーバーが担う。
ガイドが挙げている手順は3段だ。
- ブラウザが、開発者の管理するサーバーへ「鍵を1本作ってほしい」と頼む。
- そのサーバーが標準のAPIキーを使って REST の窓口へ請求し、返ってきた新しい鍵をブラウザへ渡す。
- ブラウザはその鍵で、Realtime API と直接セッションを張る。
叩かれる窓口は POST /v1/realtime/client_secrets で、作成の項目として独立して載っている。
このとき送られる中身が面白い。
公式の例では、セッションの種類・使うモデル・出力音声の声の指定が、そのまま本文として積まれている。
⇒ どの声で話すかは、鍵を作る時点でサーバー側が決めている。学習者の画面から選べるとしても、確定はサーバーで起きる。
AI英会話の認証③｜ブラウザが受け取るのは値1つ、使い道はSDPの送信
返ってきた鍵は、ブラウザ側ではごく素っ気なく扱われる。
公式のサンプルは、サーバーの返事から値を1つ取り出して使い捨ての鍵として持つ形になっている。
そのあとブラウザがやることは、順番が決まっている。
- 音声を再生するための要素を用意し、届いた音のトラックをそこへ流す。
- マイクの許可を取り、その音声トラックを接続へ足す。
- イベントをやり取りするためのデータチャネルを
oai-eventsという名前で開く。 - 接続の条件を書いた SDP を作り、
/v1/realtime/callsへ送る。
最後の送信で、認証のヘッダーに載るのが使い捨ての鍵のほうだ。
内容の種別は application/sdp で、返ってきた答えをそのまま接続の設定に当てはめる。
ブラウザで動かす以上、前提も1つ書かれている。
マイクの許可が下りていること、そして HTTPS か localhost で動いていることだ。
AI英会話の認証④｜もう1つの道は、自前サーバーを毎回通す形
ブラウザからつなぐ方法は、実は1つではない。
ガイドは、使い捨ての鍵を使う形と、統合インターフェースと呼ばれる新しい形の2つを挙げている。
| 比べどころ | 使い捨ての鍵 | 統合インターフェース |
|---|---|---|
| ブラウザが持つもの | 短命な鍵 | 何も持たない |
| ブラウザの接続先 | OpenAI 側へ直接 | まず自分のサーバー |
| 標準のAPIキーの置き場 | サーバーだけ | サーバーだけ |
| ドキュメントの評価 | 手数は多い | より簡単 |
| 引き換えになるもの | ― | セッション開始の要所に自前サーバーが入る |
後者について、公式は「より簡単だが、セッションの初期化の要所にアプリのサーバーが入ることになる」という趣旨を、はっきり断り書きとして置いている。
この形では、ブラウザが作った SDP をまず自分のサーバーへ送る。
サーバーはそれにセッションの設定を組み合わせ、標準のAPIキーで認証して OpenAI 側へ送る。
⇒ どちらを選んでも結論は同じで、本物の鍵はサーバーから外へ出ない。
AI英会話の認証⑤｜利用者を見分ける札は、鍵を作るときに貼る
認証と並んで書かれているのが、利用者を見分けるための札の話だ。
入門ガイドは、アプリが個々の利用者を識別しているなら 安全識別子を添えるよう勧めている。
推奨であって必須ではない、とも明記されている。
目的の書き方が具体的で、問題のある振る舞いが起きたときに、組織全体ではなく個々の利用者へ対応を絞り込めるようにするため、とされている。
- 値＝安定していてプライバシーを損なわないもの。例として、内部の利用者IDをハッシュ化したものが挙がっている。
- 載せる場所＝使い捨ての鍵を使う構成なら、鍵を作るサーバー側のリクエストに
OpenAI-Safety-Identifierを置く。 - 立てる主体＝信頼できる自前のサーバー。ブラウザ側で付けるものではない、とわざわざ断られている。
識別子は出来上がった鍵のほうに結びつくので、ブラウザが後から送り直す必要はない、とも説明されている。
もう1つ、引き継がれない範囲についての記述がある。
この札は、別のAPIへのリクエストや、ほかのセッションから持ち越されない。
だからアプリの別の場所で同じ値を使っているなら、セッションを作るときとつなぐときの両方で、同じものを渡すよう求められている。
⇒ 誰が使ったかを見分ける札もまた、ブラウザではなくサーバーの持ち物として扱われている。
AI英会話の認証⑥｜会話が始まったあと、サーバーが横から同じ席に入れる
つながったあとの話も、認証の一部として書かれている。
Server-side controls は、道具の実行や業務の判断をブラウザに置きたくない場合の作りを扱っている。
そこで出てくるのがサイドバンドと呼ばれる2本目の接続で、同じ1つのセッションに、利用者の端末とアプリのサーバーの両方がつながる形になる。
| やりたいこと | 2本目の接続でできること |
|---|---|
| 会話を見張る | 書き起こしの断片や、やり取りのイベントを受け取る |
| 途中で方針を変える | セッションへ指示を追記して、話の向きを変える |
| 道具を動かす | 道具の呼び出しに応え、結果を会話へ戻す |
| マイクを止める | 入力音声の停止と再開を指示する |
| 終わらせる | 終了を送り、終了の通知を受け取ってから切る |
入る鍵はここでも分かれていて、この2本目は標準のAPIキーで認証する。
しかも、そのセッションを作った側と同じプロジェクトの認証を使うこと、という条件が付く。
セッションを特定する値の扱いも決められている。
中身を解釈しない値として、接頭辞も含めてそのまま保つこと、そしてアプリがそのセッションへの権限を持っているかを確かめること、の2つだ。
AI英会話の認証⑦｜2本つながる以上、担当を1つに決める必要がある
接続が2本ある構成には、固有の落とし穴が書かれている。
同じドキュメントは、行動ごとに担当を1つ決めよ、という項目を立てている。
理由は単純で、道具の呼び出しの知らせは両方の接続に届きうるからだ。
そのうえで、実行は1回だけにすること、と念を押している。
同じ考え方を、会話への文脈の追加や、処理の続行の依頼にも当てはめるよう書かれている。
預け先の線引きも明確だ。
道具の資格情報と、許可するかどうかの判断は自前のサーバーに置き、会話に必要な分だけを返す、という書き方になっている。
⇒ 同じ「AIが道具を使った」でも、鍵を持っていた場所が違えば、漏れたときの被害範囲が変わる。
AI英会話の認証が、学習者の画面に出てくる場面
仕様の話を、使っているときに見えるものへ置き換えておく。
- 通話ボタンを押してから少し待つ＝鍵の発行と、接続条件の往復が先に済んでいる。
- マイクの許可を毎回聞かれる＝マイクの許可と HTTPS が、接続の前提として挙げられている。
- 時間が経つと再接続される＝ブラウザが持っているのは短命な鍵で、本物の鍵ではない。
- 声の種類がアプリ側で決まっている＝出力音声の指定が、鍵を作るときの本文に含まれている。
- 会話の記録がサーバーにも残る＝2本目の接続で、書き起こしの断片を受け取る作りが用意されている。
どれも英語力とは関係がなく、アプリの組み方で決まっている部分だ。
公式が Voice agents や 会話の管理を別立てにしているのも、この層と会話の中身を切り分けているからだ。
AI英会話の認証｜よくある質問
Q. ブラウザの中にAPIキーが入っているのか。 A. 公式ドキュメントは、標準のAPIキーをサーバーだけで使い、ブラウザでは使わないよう太字で指示している。
ブラウザに渡すのは短命な鍵のほうだ。
Q. 短命な鍵はどこで作られるのか。 A. アプリ側のサーバーが標準のAPIキーで POST /v1/realtime/client_secrets を叩いて作り、返ってきたものをブラウザへ渡す、という3段の流れが書かれている。
Q. 利用者ごとの識別はブラウザが送るのか。 A. 使い捨ての鍵を使う構成では、鍵を作るサーバー側のリクエストに OpenAI-Safety-Identifier を載せる。
識別子は鍵に結びつくので、ブラウザが送り直す必要はないと明記されている。
Q. 会話の途中でサーバーが介入することはあるのか。 A. 同じセッションへ2本目の接続を張る作りが用意されている。
その接続では、会話の観測、指示の追記、道具の呼び出しへの応答ができると書かれている。
Q. 接続が2本あると処理が二重にならないのか。 A. そこは注意点として立てられている。
道具の呼び出しが両方に届いた場合でも実行は1回にすること、という指示が置かれている。
まとめ｜AI英会話の認証は「鍵をどこに置くか」の設計
もう一度、要点だけを並べ直す。
- ブラウザが持つのは短命な鍵だけで、標準のAPIキーはサーバーから出さない、と明示されている。
- 鍵を作るのはアプリ側のサーバーで、窓口は
POST /v1/realtime/client_secrets。声やモデルの指定もここで積まれる。 - ブラウザからつなぐ道は2つあり、統合インターフェースは簡単だが、セッション開始の要所に自前サーバーが入る。
- 利用者を見分ける札は鍵を作るときに貼る。ヘッダーを立てるのは信頼できるサーバー側だと書かれている。
- 会話中はサーバーが2本目の接続で同じセッションへ入れる。そのぶん、担当を1つに決める必要がある。
⇒ AI英会話のアプリを仕組みから見るときは、「どんなAIか」ではなく「鍵がどこに置かれているか」で線を引く。
そこが分かっていれば、接続の待ち時間も、サーバーに残る記録も、仕様の側から読み解ける。
※本記事の一次ソースは、各公式ドキュメントを2026-09-20に取得した生テキストで確認した。
仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
鍵を受け取った後のつながり方を知りたい人向けの記事です。
60分の上限まで分解した記事
Comments