AI英会話の「フリートーク」は、自由に話しているように見えて、実際には何重もの決まりごとの上に乗っている。
相手は、こちらが話し終わったかどうかを音の切れ目か、言葉の意味かのどちらかで判定している。
そして、前に何を話したかは「覚えている」のではなく、毎回どこかに積み直されている。
だから、話題が続くときにも、急に噛み合わなくなるときにも、仕様のどこかに対応する理由がある。
この記事では、AIの部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、そこを1つずつ開けていく。
扱うのは「公式ドキュメントに何と書いてあるか」であって、特定のアプリが内部で何を使っているかではない。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】フリートークは「自由」ではなく、区切りと状態の管理で成立している
先に答えを置く。
フリートークが成り立つために、少なくとも3つの仕組みが同時に働いている。
| 仕組み | 何を決めているか | 公式ドキュメントでの呼び名 |
|---|---|---|
| ①区切り | こちらが話し終わったかどうか | Voice activity detection（VAD）／turn detection |
| ②状態 | 前の発言をどこまで持ち越すか | Conversation／conversation state |
| ③指示 | どんな役柄でどう話すか | instructions／session instructions |
⇒ 話題が続くのは②が効いているとき、急に途切れるのは①か②の上限に当たったときだ。
「AIの気分」ではなく、どれも数字やパラメータで設定できるものとして公式に書かれている。
フリートークの土台｜会話は「セッション」という入れ物の中にある
まず、フリートークが行われている場所の名前をはっきりさせておく。
OpenAIの Realtime conversations は、セッションを「a stateful interaction between the model and a connected client」と定義している。
そして、そのセッションが3つの要素からできていると説明されている。
- Session オブジェクト＝使うモデル、出力に使う声、その他の設定といった「やりとりのパラメータ」を制御する。
- Conversation＝現在のセッション中に生成された、ユーザー入力のItemとモデル出力のItemを表す。
- Responses＝モデルが生成した音声またはテキストのItemで、Conversationに追加される。
つまり、フリートークの中身は「Itemが1つずつ積まれていくリスト」として持たれている。
話した順に積まれ、モデルの返事も同じリストに積まれる。
この「積まれている」状態が、話題が続く土台になっている。
そして Realtime API の入門ガイドは、このセッションが「ブラウザではWebRTC、サーバーではWebSocketで接続する」手順として説明している。
フリートークが1往復で終わらない理由｜文章生成そのものは状態を持たない
ここが、いちばん誤解されているところだ。
OpenAIの Conversation state には、こう書かれている。
「While each text generation request is independent and stateless, you can still implement multi-turn conversations by providing additional messages as parameters to your text generation request.」
テキスト生成のリクエストは、1回ごとに独立していて状態を持たない。
多ターンの会話は、過去のやりとりを「追加のメッセージ」としてもう一度渡すことで実現すると説明されている。
公式が例に出しているのは、ノックノック・ジョークだ。
user「knock knock.」／assistant「Who’s there?」／user「Orange.」という3つのメッセージをinput配列に並べて渡す形が、そのままサンプルコードになっている。
⇒ フリートークで「前の話を覚えている」ように見えるのは、記憶ではなく再送の結果である。
この再送を自動でやる仕組みも用意されている。
| やり方 | 公式ドキュメントの説明 |
|---|---|
| 手で積む | 過去のメッセージをパラメータとして渡す |
| Conversations API | 会話の状態を、独自の永続的な識別子を持つ長寿命オブジェクトとして保持する。作成後はセッション・デバイス・ジョブをまたいで使い続けられる |
previous_response_id | 前の応答から続きをつなぐ。ただし「all previous input tokens for responses in the chain are billed as input tokens」と明記されている |
最後の一文が効いている。
話題が長く続くほど、毎回のリクエストに乗る入力の量は増えていくという構造になっている。
フリートークの区切り方①｜沈黙の長さで切る「server_vad」
フリートークで最初に効く判定が、「この人はもう話し終わったか」だ。
Voice activity detection（VAD）のガイドは、これを「automatically detect when the user has started or stopped speaking」する機能だと説明している。
speech-to-speechのRealtimeセッションでは既定で有効だが、任意であり、切ることもできると書かれている。
そして2つのモードがある。
server_vad＝沈黙の区間にもとづいて音声を自動的に区切る。semantic_vad＝ユーザーが言った言葉から、発話が完了したとモデルが判断したときに区切る。
既定値は server_vad だと明記されている。
この server_vad には、調整できる値が3つある。
| パラメータ | 公式の説明 | ガイド内の例 |
|---|---|---|
threshold | 作動のしきい値（0〜1）。高くすると作動により大きな音が要るので、騒がしい環境で有利になりうる | 0.5 |
prefix_padding_ms | VADが検出した発話の前に含める音声の量（ミリ秒） | 300 |
silence_duration_ms | 発話の停止を検出するための沈黙の長さ（ミリ秒）。短くするとターンがより速く検出される | 500 |
⇒ フリートークで「考えている途中なのに割り込まれる」現象は、この沈黙の長さの設定と直結している。
英語で話す側からすると、単語を探す間は日本語のときより長くなりやすい。
沈黙の長さだけで切る方式は、その事情を見ていない。
フリートークの区切り方②｜言葉の意味で切る「semantic_vad」
もう1つのモードは、沈黙ではなく中身を見る。
公式の説明は「uses a semantic classifier to detect when the user has finished speaking, based on the words they have uttered」というものだ。
この分類器は、ユーザーが話し終わっている確率で入力音声を採点する。
確率が低いときはタイムアウトまで待ち、高いときは待つ必要がない、と書かれている。
公式が挙げている例がそのまま英語学習の話になっている。
「user audio that trails off with an “ummm…” would result in a longer timeout than a definitive statement」。
言いよどんで「ummm…」で終わった音声は、言い切った文より長く待たれるということだ。
そして「this mode, the model is less likely to interrupt the user during a speech-to-speech conversation」とも書かれている。
待ち方の強さは eagerness で調整する。
auto＝既定値。mediumと同等。low＝ユーザーに時間をかけて話させる。high＝できるだけ早く音声を区切る。
⇒ 同じ「AI英会話のフリートーク」でも、この1つの設定で待ってくれるかどうかが変わる。
フリートークが途切れる条件①｜セッションの時間には上限がある
続くか途切れるかを決めているのは、会話の面白さではなく上限値だ。
Realtime conversations には「The maximum duration of a Realtime session is 60 minutes」と書かれている。
加えて、セッション中に変更できない項目もある。
公式には「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」とある。
一度音声で返事をしたあとは、その会話のあいだ声を変えられないということだ。
フリートークの途中で声色が変わらないのは、この仕様に沿った動きにあたる。
フリートークが途切れる条件②｜コンテキストウィンドウという天井
長く話すほど、別の天井に近づいていく。
Conversation state のガイドは、コンテキストウィンドウを「the maximum number of tokens that can be used in a single request」と定義している。
そして、この上限には入力・出力・推論のトークンが含まれると書かれている。
さらに「Tokens generated in excess of the context window limit may be truncated in API responses」という一文がある。
⇒ 会話が長くなるほど、過去のやりとりと今の返事が同じ枠を取り合う構造になっている。
公式は、大きなプロンプトを作ると「run the risk of exceeding the allocated context window for a model, which might result in truncated outputs」とも注意している。
この天井に対する手当ても、別のガイドとして用意されている。
Conversation state のページには Compaction という節があり、詳しい指針は専用ページへ移されたと書かれている。
context_management と compact_threshold によるサーバー側の圧縮、明示的に制御するための専用エンドポイントが挙げられている。
つまり「長くなった会話をどう畳むか」自体が、設計項目として存在している。
フリートークが途切れる条件③｜割り込みと打ち切りの後始末
こちらが話し始めた瞬間に相手が黙るのも、仕様として書かれている。
公式は「Realtime API handles interruptions when VAD is enabled, in that it detects user speech, cancels the ongoing response, and starts a new one」と説明している。
問題は、そのあとだ。
モデルは「どこで切られたか」を知らないと、会話を自然に続けられないと書かれている。
そこで、まだ再生されていない部分を会話から取り除く truncating という処理がある。
| 接続方式 | 公式に書かれている後始末 |
|---|---|
| WebRTC・SIP | サーバーが出力音声のバッファを管理しているため、ユーザーの割り込み時に未再生の音声を自動的に切り詰める |
| WebSocket | クライアントが再生を管理するため、再生を止めて conversation.item.truncate を送る必要がある |
そして、切り詰めには公式が認めている限界がある。
「The realtime model doesn’t have enough information to precisely align transcript and audio」と書かれており、conversation.item.truncate は指定した位置で音声を切り、未再生分のテキストを取り除くが、切り詰めた文字起こしそのものは得られないと説明されている。
⇒ 割り込みの多いフリートークほど、会話のリストと実際に耳へ届いた内容のずれが積み上がりやすい。
フリートークの話題を決めているもの｜指示文と3つのアーキテクチャ
「何を話すか」を決めているのは、モデルの性格ではなく指示文だ。
Realtime API の入門コードは、エージェントを new RealtimeAgent({ name, instructions }) という形で作っている。
Prompting GPT-Live は、この指示文の書き方をさらに具体的に示している。
推奨される構成には、役柄・話し方に加えて、会話の流れを直接左右する項目が並ぶ。
- Backchannel policy＝「mm-hmm」のような短い相づちをどれくらい入れるか。公式は moderate から始めることを勧めている。
- Interruption policy＝割り込まれたら話すのをやめて聞く、という方針。
- 沈黙と雑音の扱い＝「Keep listening while the user pauses to think.」「Do not treat a cough, music, or nearby conversation as a new request.」という文例まで載っている。
「考えている間は待つ」という挙動が、設定ではなく文章で指示される項目として扱われている点が重要だ。
公式はまた、相づちを消しすぎる副作用にも触れている。
「ユーザーが話している間は決して話すな」という一律の規則を足すと、役に立つ聞き手の音まで抑えてしまう可能性があると書かれている。
そして、そもそも会話の作り方自体に選択肢がある。
Voice agents は、3つのアーキテクチャを表で並べている。
| アーキテクチャ | 公式が挙げる向き先 |
|---|---|
| GPT-Live | 別のバックエンドを持つ全二重（full duplex）の会話。聞きながら同時に話せる |
| Realtime API | 音声・推論・ツール利用を1つのセッションで扱う |
| Chained voice pipeline | 音声認識 → エージェントの処理 → 音声合成の各段を自分で制御し、途中のテキストを確認・加工できる |
⇒ 同じ「フリートーク」でも、途中のテキストを取り出せる作りかどうかで、できる添削の種類が変わる。
フリートークの出来はどう測られているのか｜公式の評価項目
作る側が何を見ているかを知ると、感想の言葉が変わる。
Voice agents の評価の節は、まず「Test conversation quality and task outcomes separately」と釘を刺している。
自然に聞こえる返事が返ってきたことは、処理が正しく走った証明にはならない、という趣旨だ。
そのうえで、測る軸が分けて挙げられている。
- Conversational timing＝聞こえる応答の速さ、望ましくない沈黙、重なり、割り込みへの譲り方。
- Speech and language＝訛り・雑音・言語の切り替え・名前・数字をまたいだ入力認識と、出力の聞き取りやすさ。
- Session reliability＝接続の失敗、音声の脱落、タイムアウト、未完了のセッション。
「望ましくない沈黙」と「重なり」が、わざわざ別の指標として挙げられているのがフリートークらしいところだ。
さらに公式は、段階を踏んだテストの進め方として Crawl・Walk・Run という3段を挙げている。
合成音声による単発の要求から始め、人間の録音に移り、最後に多ターンの連続した会話を模擬するという順序だ。
そして「Complement automated scores with human listening」と、人が聞いて確かめる工程を残すよう書かれている。
フリートークに関するよくある質問
Q. フリートークの途中で言葉に詰まると、なぜ割り込まれるのか。 A. 既定のターン検出が server_vad で、沈黙の長さ（silence_duration_ms）で発話の終わりを判定しているためだ。ガイドの例では500ミリ秒が示されている（出典）。
Q. 待ってくれるようにはできないのか。 A. semantic_vad というモードがあり、言葉の意味から発話の完了を判定する。eagerness を low にすると、ユーザーに時間をかけて話させると書かれている。
Q. フリートークで前の話題を覚えているのはなぜか。 A. 覚えているのではなく、過去のやりとりを追加のメッセージとして渡し直している。公式は「each text generation request is independent and stateless」と明記している。
Q. 長く話し続けると噛み合わなくなるのはなぜか。 A. コンテキストウィンドウは1回のリクエストで使えるトークンの最大数で、入力・出力・推論の合計がそこに収まる。上限を超えた分は応答が切り詰められる可能性があると書かれている。
Q. 会話は何分まで続くのか。 A. Realtime セッションについては「The maximum duration of a Realtime session is 60 minutes」と公式に書かれている。
Q. 相づちが多い／少ないのは調整できるのか。 A. GPT-Liveの推奨プロンプトには Backchannel policy という行があり、moderate から始めることが勧められている。ただし「ユーザーが話している間は決して話すな」という一律の規則を足すと、役に立つ聞き手の音まで抑えうると注意されている。
まとめ｜フリートークは3つの設定の上で成立している
もう一度整理する。
- フリートークの入れ物はセッションで、公式は「接続したクライアントとモデルのあいだの状態」と定義している。
- 話題が続くのは記憶ではなく再送＝テキスト生成のリクエストは1回ごとに独立していて状態を持たないと明記されている。
- 区切りを決めているのはVAD＝既定は沈黙の長さで切る
server_vad、意味で切るsemantic_vadも選べる。 - 途切れる条件は時間とトークン＝Realtimeセッションは最大60分、コンテキストウィンドウを超えた分は切り詰められうる。
- 話し方と待ち方は指示文で決まる＝相づち・割り込み・沈黙の扱いが、文章で書く項目として公式に例示されている。
⇒ 「話が続かない」と感じたら、続かないのが区切りの問題なのか、状態の問題なのか、指示文の問題なのかで分けて見る。そこが分かれば、設定を変えれば済む話と、そもそも構造上そうなっている話を取り違えずにすむ。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments