「みなづちAI」はリンクフリーです。リンクを行う場合の許可や連絡は不要です。引用する際は、引用元の明記と該当ページへのリンクをお願いします。
ChatGPTの音声が自然になった理由。ミリ秒は1つも書かれていない
みなづちです。
2026年8月3日の16時（日本時間）、OpenAIが1本のエンジニアリング記事を公開しました。タイトルは「How we built a realtime system for responsive voice AI in six months」です。
ChatGPTの音声が7月に大きく変わったことは、使っている方なら気づいているはずです。相手の話が終わるのを待たずに返事が始まる。こちらが割り込んでも止まる。あの変化の裏側を、開発した本人たちが書いた記事でした。
読み始めてすぐ、妙なことに気づきました。速くなった話をしているのに、速さの数字が出てこないのです。
念のため本文をすべて取得して機械的に走査しました。ミリ秒も、秒も、パーセントも、1件もありませんでした。
2024年5月にGPT-4oを発表したとき、同じOpenAIは「232ミリ秒」「320ミリ秒」と数字を書いていました。2年で語り方が変わっています。
本記事では、以下のポイントから解説します。
- 8月3日の記事に書かれた定量表現が、実際には何だったのか
- ターン検知器を外したという説明に付いている、5語の限定
- Python asyncioからGoへの移行と、WARPという新しいプロトコル
- 「full-duplex」を名乗っているのがOpenAIだけではないこと
- 会話の返しが世界でいちばん速い言語が、日本語であること
- SynthIDの追記とEU AI法の期限が、実は結びつかないこと
目次
結論：GPT-4oでは232ミリ秒と書いたOpenAIが、今回は数字を出さなかった
まず記事全体の結論からお伝えします。今回の発表で押さえておきたいのは、OpenAIがレイテンシの絶対値を1つも書かなかったという点です。
本文の実文字数は約17,600字です。ここに含まれる数字は、GPT-5.5、GPT-Live-1、DTLS 1.3、p95、p50だけでした。すべてモデル名かプロトコルのバージョンか、統計の記号です。
ミリ秒も秒もパーセントも0件。前世代のGPT-4oを発表したときは「as little as 232 milliseconds, with an average of 320 milliseconds」と明記していたのに、今回は書いていません。
ここで正確を期しておきます。定量的な主張がまったくないわけではありません。数えられる形の記述は3つありました。
1つ目は「the new system’s p95 matching the previous system’s p50」です。新システムの95パーセンタイルが、旧システムの中央値に並んだ、という相対比較です。
2つ目は「reduces media and data startup from six network round trips to just one」。接続開始時の往復回数が6回から1回になった、という数え上げです。
3つ目は「the client can now start a session with a single UDP packet」。UDPパケット1つでセッションを開始できる、という記述です。
いずれも絶対値ではありません。だから「速くなった」ことは伝わるのに、「どのくらい速いのか」は最後まで分からない構成になっています。
もう1つ、記事の中心にある表現にも限定が付いています。GPT-Liveがターン検知器を外したという説明は、原文では「removes the turn detector from the audio path」です。音声経路から、という5語が付いています。
システム全体からターンの概念が消えたわけではありません。同じ記事の中に「Deriving discrete turns from continuous speech」という節があり、アプリケーション側ではいまも離散的なターンを組み立てていると書かれています。
筆者の視点：ミリ秒の不在と「音声経路から」の5語に引っかかった
この記事を読む中で、二度立ち止まりました。ここではその過程を書きます。
GPT-4oのときは232ミリ秒と書いていた
最初の引っかかりは、読み終えたあとに来ました。速くなった話を延々と読んだのに、どのくらい速いのかが頭に残っていないのです。
見落としたのかと思って、本文を全部取得して数字を機械的に拾い直しました。結果は先に書いたとおりで、レイテンシの絶対値は0件でした。
比較のためにGPT-4oの発表ページを開き直しました。2024年5月13日の「Hello GPT-4o」には、こう書かれています。
It can respond to audio inputs in as little as 232 milliseconds, with an average of 320 milliseconds, which is similar to human response time in a conversation.
最速232ミリ秒、平均320ミリ秒。しかも「会話における人間の応答時間と同程度」という比較まで添えてありました。
さらにその前の世代についても数字があります。「Prior to GPT-4o, you could use Voice Mode to talk to ChatGPT with latencies of 2.8 seconds (GPT-3.5) and 5.4 seconds (GPT-4) on average」。旧方式は平均2.8秒と5.4秒だった、と。
2年前は、前世代の遅さも新世代の速さも、両方とも秒とミリ秒で語られていました。今回はどちらもありません。
ここで1つ注意しておきます。232ミリ秒はGPT-4oというモデルの数値であって、GPT-Liveの数値ではありません。世代が違うので、GPT-Liveの説明に流用することはできません。
しかも「Hello GPT-4o」の同じページには、こうも書かれていました。「Today we are publicly releasing text and image inputs and text outputs」。2024年5月13日の時点で、音声の入出力はまだ提供されていなかったのです。232ミリ秒は、発表時点の利用者が体験できた数字でもありませんでした。
「音声経路から」という5語が残っている理由
2つ目の引っかかりは、記事の第2段落です。
GPT-Live, our third-generation voice system, removes the turn detector from the audio path.
沈黙を検知して発話の終わりを判定する小さなモデル、それを外した、という文です。ただし「from the audio path」が付いています。
最初はもったいぶった書き方だと思いました。ところが記事の後半を読むと、この5語が正確な記述であることが分かります。
「Deriving discrete turns from continuous speech」という節があります。連続した音声から離散的なターンを取り出す、という意味です。
ChatGPTの会話画面には吹き出しが並びます。分析や安全性の仕組みも、ターン単位で動いています。だから連続音声のままでは扱えず、アプリケーションサーバが部分的な文字起こしとタイミング信号から発話者を推定し、メッセージの列を組み立て直しているのです。
つまりターン検知器が消えたのは音声の通り道からだけで、ターンという単位そのものは残っています。場所を移して、遅延を生まない位置で再構成されている。
「沈黙検知を廃止した」と書きたくなる話ですが、原文はそう書いていません。この5語を落とすと、記事の主張より強い断定になります。
GPT-Liveの発表は7月8日。8月3日の記事は何を足したのか
順序を整理しておきます。GPT-Liveそのものは8月3日に発表されたものではありません。
発表は7月8日、8月3日はエンジニアリング記事
GPT-Liveが公になったのは2026年7月8日です。「Introducing GPT-Live」というページで、カテゴリはProduct。本文は「We’re launching GPT-Live, a new generation of voice models that make talking with AI feel much more like having a real conversation.」で始まります。
8月3日の記事はカテゴリがEngineeringで、著者名が入っています。バイラインは「By Justin Uberti and Zahan Malkani, Members of Technical Staff」。OpenAIの記事としては珍しく、個人名義に近い形です。
配信のタイムスタンプは「Mon, 03 Aug 2026 07:00:00 GMT」でした。日本時間では8月3日の16時にあたります。
つまり8月3日に出たのは製品発表ではなく、約1か月前に出した製品の作り方を書いた記事です。この区別を落とすと、「OpenAIが8月3日に新しい音声モデルを発表した」という誤った理解になります。
Justin Uberti氏はWebRTCの原設計者の一人
著者の1人について、OpenAI自身が別の記事で説明しています。2026年5月4日の「How OpenAI delivers low-latency voice AI at scale」に、こうあります。
Foundational work by Justin Uberti (one of WebRTC’s original architects) and Sean DuBois (creator and maintainer of Pion)
WebRTCはブラウザ間でリアルタイム通信を行うための技術で、ビデオ会議の多くがこれを使っています。その原設計者の一人が、いまOpenAIで音声の基盤を作っている、という構図です。
同じ記事には「We’re fortunate that both Justin and Sean are now colleagues here at OpenAI」とも書かれています。Pionの作者であるSean DuBois氏も在籍しているということです。
なお、Uberti氏の役職については注意が必要です。「Head of Realtime AI」という肩書きが出回っていますが、OpenAIの公式サイトでこの表記を確認することはできませんでした。出典は本人のプロフィールと第三者による紹介で、しかもその第三者間でも表記が揺れています。本記事ではバイラインの表記に留めます。
提供範囲はGo・Plus・Proが上位、Freeはmini
7月8日のページには、提供の内訳が書かれています。
GPT-Live-1 will become the default model powering ChatGPT Voice for Go, Plus, and Pro users, and GPT-Live-1 mini will become the default for Free users.
Go・Plus・Proの利用者にはGPT-Live-1が、無料の利用者にはGPT-Live-1 miniが既定になる、という記述です。動詞が「will become」であることに注意してください。段階的に切り替わる、という書き方です。
法人向けのプランについては、この本文に記載がありません。列挙されているのはGo・Plus・Pro・Freeの4つだけで、詳細はヘルプセンターに委ねられています。
ローンチ時の制限も書かれています。「At launch, GPT-Live will not support voice with video or screen sharing in ChatGPT」。動画や画面共有と組み合わせた音声には、当初は対応していません。その場合は従来のStandard・Advanced Voice Modeが引き続き使えます。
6か月でやったのは「作り直し」であって「ゼロから構築」ではない
タイトルの「in six months」も、係り先を確認しておきます。
Over the last six months, we reworked model inference, context management, and media transport to keep speech flowing smoothly from end to end.
動詞はreworkedで、対象はモデル推論・コンテキスト管理・メディア転送の3領域です。built（構築した）ではありません。
さらに別の段落には「Earlier work on ChatGPT Voice and the Realtime API gave us an important foundation. We had already rebuilt our voice infrastructure」とあります。先行する基盤があった、と明記されているわけです。
「6か月でゼロから音声AIを作った」と読むと、原文より強い話になります。
ターン検知器を外したのは「音声経路から」。ターンの概念は消えていない
ここからは技術の中身に入ります。まず、外されたものが何だったのかを確認します。
検知器の判断が終わるまで、大きいLLMは動けなかった
旧来の構成について、記事の第1段落がうまく説明しています。
tiny models known as turn detectors, which faced an unenviable task: guess too soon, and the user gets cut off; guess too late, and the response feels sluggish.
ターン検知器は「うらやましくない仕事」を負っていた、と。早く判断しすぎれば利用者の話が途中で切られ、遅く判断すれば返事がもたつく。
そして続く一文が構造の核心です。
Only after the detector made its decision could the much larger LLM get to work.
検知器が判断を終えてはじめて、はるかに大きいLLMが動き出せた。つまり小さなモデルの判断待ちが、そのまま全体の遅延になっていたわけです。
沈黙で判定する仕組みなので、少し息を継いだだけ、あるいは背景の物音だけでも、発話の終わりと誤認されることがありました。7月8日のページはこう書いています。「even a brief pause or background noise could be mistaken for the end of turn」。
speech-to-speechに変えても、ターン制は残っていた
音声から音声へ直接処理するモデル、いわゆるspeech-to-speechに移行しても、この構造は変わらなかったと記事は述べています。
But the system still relied on the turn detector to decide when inference could begin. The model handled more of the interaction, but the interaction remained turn-based.
モデルが対話のより多くの部分を扱うようになっても、やりとりはターン制のままだった、と。
ここがGPT-Liveとの分かれ目です。7月8日のページによれば、GPT-Liveは「continuously processes input while generating output」、つまり出力を生成しながら入力を処理し続けます。その結果として「make interaction decisions many times per second: whether to speak, continue listening, pause, interrupt, or invoke a tool」という記述になります。
話すか、聴き続けるか、止まるか、割り込むか、ツールを呼ぶか。この判断を毎秒何度も行う、というわけです。
アプリ層では、いまも離散ターンを組み立てている
そして先に触れた「Deriving discrete turns from continuous speech」の節です。
記事によれば、最新のメッセージは暫定的なもの（provisional）として扱われ、発話権が十分に持続したところで確定されます。推測に基づく見え方と、確定した記録の2重管理になっているという説明です。
なぜそんな手間をかけるのか。ChatGPTの会話UI、分析、安全性の基盤が、いずれもターン単位を前提にしているからです。
音声経路からは外したが、システム全体からは外していない。この構造を理解すると、「from the audio path」という限定が単なる用心深さではないことが分かります。
相槌を独立したメッセージにするかどうかの判断
この節には、細かいけれど面白い記述があります。
A brief acknowledgement from the assistant while the user is talking (e.g. “mm hmm,” or “okay”) should not necessarily become its own message. However, a substantive assistant interjection often should.
利用者が話している最中にアシスタント側が挟む短い相槌は、必ずしも独立したメッセージにしない。ただし実質的な内容を伴う割り込みは、しばしば独立したメッセージにする、と。
主語がアシスタント側であること、そして「necessarily」という留保が付いていることに注意してください。全二重で同時に話せるようになると、こういう判断が新しく必要になる、という例です。
7月8日のページにも「During conversations, GPT-Live can show it’s paying attention with phrases like “mhmm” or “yeah”」とあり、相槌を打つこと自体が機能として書かれています。
Python asyncioからGoへ。p95が旧p50に並び、WARPが6往復を1往復に
ここからはメディア転送の話です。数字が出てくるのは、この節だけです。
最初にやったのは、メディア経路と業務ロジックの分離
記事は設計の起点をこう書いています。
An early decision we made was to specifically separate media flow from application and business logic.
音声の流れと、アプリケーションや業務のロジックを、はっきり分ける。その効果が次の一文です。
A slow tool call or backend service can delay its own result, but cannot stall the flow of media.
遅いツール呼び出しやバックエンドは自分の結果を遅らせることはできるが、音声の流れを止めることはできない。
この対比が効いています。「ツールが遅くても会話が途切れない」と一般化すると、遅い結果そのものは遅れるという事実が消えてしまうので、原文の限定を残しておきます。
Goへの移行で、フレーム配信のp95が旧p50に一致した
実装言語の変更が書かれています。
We wrote the media frontend and inference logic in Go, replacing a previous Python asyncio implementation.
置き換えた対象はメディアのフロントエンドと推論ロジックの2つ、旧実装はPythonのasyncioです。そして効果がこう書かれています。
This significantly improved the smoothness of frame delivery, with the new system’s p95 matching the previous system’s p50.
フレーム配信の滑らかさが大きく改善し、新システムの95パーセンタイルが旧システムの中央値に並んだ。
ここで射程に注意が必要です。この数字はフレーム配信の滑らかさについてのもので、会話全体の応答時間ではありません。しかも絶対値は書かれていないので、何ミリ秒が何ミリ秒になったのかは分かりません。
「GPT-Liveは従来比で2倍速い」といった読み方は、二重に成り立たないことになります。
WARPの4つの改良と、6往復から1往復へ
接続の立ち上がりについて、新しいプロトコルが紹介されています。
We analyzed the stack and developed the WebRTC Abridged Roundtrip Protocol (WARP), which reduces media and data startup from six network round trips to just one.
WARPの正式名称はWebRTC Abridged Roundtrip Protocolで、メディアとデータの立ち上がりを6往復から1往復に減らす、と。
内訳は4つ挙げられています。
| 改良 | 内容 |
|---|---|
| SPED | DTLSハンドシェイクをICEに相乗りさせる |
| DTLS 1.3 | より速いハンドシェイクを使う |
| SNAP | SCTPのハンドシェイクを事前にネゴシエートする |
| データチャネル | DCEPを使わず事前ネゴシエートする |
これらは「a set of backward-compatible protocol improvements」、つまり後方互換の改良群として設計されています。
実装状況も書かれています。「WARP support has already been added to both libwebrtc and Pion」。GoogleのlibwebrtcとSean DuBois氏のPionには、すでに入っているということです。
標準化については「We’re advancing the proposals through the IETF’s TSVWG working group」という書き方でした。提案を進めている段階であって、標準化が完了したわけではありません。実際、IETFに提出されているのは個人ドラフト（draft-uberti-tsvwg-warp-00、2026年7月22日改訂）です。
Instant Connectとの合わせ技でUDPパケット1つ
WARPとは別に、もう1つの仕組みが紹介されています。
To remove that exchange from the critical path, we developed what we call Instant Connect.
WebRTCが接続する前にSDPというパラメータを交換する必要があり、その往復がクリティカルパスに乗っていた。それを外したのがInstant Connectです。
そして2つを組み合わせた結果が、先に挙げた記述になります。
Together, Instant Connect and WARP dramatically reduce the time from user intent to live media flow. With the SDP exchange off the critical path and WARP collapsing the transport handshake, the client can now start a session with a single UDP packet.
文頭が「Together」であることに注意してください。UDPパケット1つでの開始は、WARP単独の成果ではありません。
さらに条件も書かれています。事前にネゴシエートしたパラメータが有効なら1パケットで済むが、古かったり無効だったりした場合はシグナリングの流れが既に進行しているので、追加の遅延なく通常の手順に退避できる、と。常に1パケットというわけではありません。
本番の一部を影の経路へ流すsilent test、ユーザーが聞く音は変えなかった
実装より面白いのは、本番投入の手順かもしれません。ここが記事のいちばん実務的な部分です。
shadow pathはread-onlyで走らせた
OpenAIはこのテストを「silent test」と呼んでいます。
Before letting GPT-Live chat with users, we ran a silent test that routed a small, gradually increasing share of production ChatGPT Voice sessions to both the existing Advanced Voice Mode experience and our new system.
本番のChatGPT Voiceのセッションのうち、少しずつ割合を増やしながら、既存のAdvanced Voice Modeと新システムの両方に流した、と。
そして肝心の部分です。
Advanced Voice Mode continued serving users as usual, while the shadow path ran inference in read-only mode.
利用者に応答していたのは既存のAdvanced Voice Modeで、影の経路は読み取り専用で推論を走らせていた。「without changing what users heard」とも書かれています。
つまり利用者にGPT-Liveを試験提供していたわけではありません。本番の実際の回線・端末・セッション長・地理的分布に新システムをさらしながら、聞こえる音は変えなかった、という設計です。
容量の問いが「GPUが何リクエスト捌けるか」から変わった
このテストで得た知見として、問いの立て方が変わったことが書かれています。
従来は「How many requests can a GPU handle?」と問うていた。それが「How many concurrent sessions can the system sustain while keeping every frame on schedule?」に変わった、と。
1つのGPUが何リクエストを処理できるか、ではなく、すべてのフレームを予定どおりに届けながら、システムは何本の同時セッションを維持できるか。リアルタイム音声では、平均的なスループットより、遅れないことのほうが効きます。
負荷テストの見積もりより早く飽和した構成要素があったことも書かれていますが、その名前は伏せられています。ほかにも、推論を利用者の近くに寄せたこと、長時間セッションでのメモリ圧迫、再接続時の状態復元といった個別の事象が挙がっています。
GPT-5.5への委譲は「such as」という例示だった
重い処理の扱いについて、こう書かれています。
When deeper reasoning or tool use is needed, GPT-Live can also consult our frontier models, such as GPT-5.5, without interrupting the flow of the conversation.
深い推論やツール利用が必要なとき、GPT-Liveは会話の流れを止めずにフロンティアモデルに相談できる。ここで「such as」は例示であって、GPT-5.5に限定されていません。
7月8日のページにも「As we release new frontier models, we’ll continuously update the model used by GPT-Live.」とあります。実際、GPT-5.6はGPT-Liveの翌日にあたる2026年7月9日に発表されています。「GPT-LiveはGPT-5.5を使っている」と現在形で書くと、時点がずれる可能性があります。
この構造をOpenAIはこう表現しています。
effectively decoupling “talking” from deeper “thinking”
話すことと、深く考えることを切り離す。talkingとthinkingがそれぞれ引用符でくくられています。
委譲を速くする工夫も書かれていました。音声セッションが始まった時点でフロンティアモデル側の推論セッションを先に作り、プロンプトの処理を済ませておく。そのセッションを会話の間ずっと保持し、後続のリクエストには安定したセッションアフィニティを使う。プロンプトキャッシュと組み合わせる、と。
「full-duplex」を名乗るのはOpenAIだけではない。サーベイが数えた12件超
ここで、この記事を書く途中で自分の見立てが崩れた話をします。
Google・xAI・Amazonの公式文言には1件もなかった
まず確認できた事実から書きます。競合3社の公式ドキュメントを機械的に走査した結果です。
GoogleのGemini API Liveガイドには「By default, the model automatically performs VAD on a continuous audio input stream.」とあります。VAD（音声区間検出）で判定する、という説明です。割り込みについても「When VAD detects an interruption, the ongoing generation is canceled and discarded.」と書かれています。
このガイドを含むLive API関連の5ページを走査しましたが、full-duplexという語は0件でした。ただしプロトコル名としてBidiGenerateContent（Bidi＝bidirectional、双方向）は使われています。双方向という概念そのものを避けているわけではありません。
xAIのドキュメントには「Build real-time, speech-to-speech voice agents over WebSockets, with low-latency turn-taking and tool use.」とあります。低遅延のターンテイキング、という表現です。全文を統合したファイルを走査してもfull-duplexは0件でした。
なお「server_vad」という語も出てきますが、これはコードサンプル内のAPIパラメータの値（”turn_detection”: {“type”: “server_vad”}）であって、散文での主張ではありません。
AmazonのAlexa+の製品ページには「Say anything, interrupt the conversation, or change the topic halfway through.」とあります。割り込める、とは書いてあります。ただしアーキテクチャの技術的な記述は皆無で、full-duplexもLLMもレイテンシも0件でした。消費者向けのランディングページなので、当然といえば当然です。
NVIDIAとKyutaiは、自社モデルにこの語を使っている
ここまでを見て、私は「full-duplexを自社アーキテクチャの説明に使っているのはOpenAIだけだ」と考えました。これは誤りでした。
反例があります。
NVIDIAの研究部門ADLRが公開しているPersonaPlexのページには「PersonaPlex is a full duplex model: it listens and speaks at the same time.」とあります。OpenAIの表現とほとんど同じです。
Kyutai LabsのMoshiは、公式リポジトリの説明が「Moshi is a speech-text foundation model and full-duplex spoken dialogue framework.」です。論文の抄録にも同じ表現が使われています。
つまり3社を見て「OpenAIだけ」と結論づけたのは、比較対象の選び方が結論を作っていただけでした。GoogleとxAIとAmazonが使っていないことは事実ですが、そこから業界全体を語ることはできません。
18人のサーベイが指摘した「realization gap」
決定的だったのは、根拠に使おうとしていたサーベイ論文そのものでした。
2026年6月17日に投稿されたプレプリント「A Survey of Full-Duplex Spoken Dialogue Systems: Architectural Hierarchy, Interaction Ontology, and Decision State Machine」（arXiv:2606.19453）は、著者18名、34ページ、第一著者はJingyu Lu氏です。
その抄録の第1文がこれです。
More than a dozen spoken dialogue systems have recently claimed to be “full-duplex,” yet the term has been used to describe substantially different capabilities.
十数個を超えるシステムが最近「全二重」を自称しているが、この語は実質的に異なる能力を指すのに使われてきた。full-duplexが引用符でくくられているのは、自称であることに距離を置くためです。
この論文が提案しているのは、L0からL3というアーキテクチャの階層で分類する枠組みです。「全二重かどうか」ではなく「二重性の判断がどの層で行われるか」で見る。
この物差しで見ると、GeminiとGPT-Liveの違いが言葉にできます。どちらも割り込めますが、Geminiはサーバ側のVADが外付けで判断し、GPT-Liveはモデル自身が毎秒何度も判断する。同じ「割り込み可能」でも層が違います。
そしてこの論文には、OpenAIにも刺さる指摘があります。
although many architectures can in principle operate in full-duplex states, their observed behavior remains constrained by the interaction patterns represented in training and evaluation
原理的には全二重で動けるアーキテクチャでも、実際の振る舞いは訓練と評価に現れた対話パターンに縛られたままだ、と。原理と実現の間にある溝です。
「うちは全二重だ」という宣言だけでは、体感の違いは説明できない。この指摘は特定の企業に向けたものではありません。
会話の返しが世界最速の言語は日本語。ただし+7ミリ秒には4つの但し書き
ここで日本の読者に関わる話をします。会話の間合いは言語ごとに違うのか、という問いです。
10言語の平均で、日本語が+7ミリ秒、デンマーク語が+469ミリ秒
2009年のPNASに掲載された論文があります。Tanya Stivers氏ら11名による「Universals and cultural variation in turn-taking in conversation」（第106巻26号、10587〜10592ページ）です。2026年8月時点で約1,490回引用されている、この分野の標準文献です。
5大陸から10言語を選び、日常的な会話をビデオで記録して、質問が終わってから応答が始まるまでの時間を計測しています。各言語350問、全体で101会話です。
結果がこれです。
Danish has the slowest response time on average (+469 ms) and Japanese has the fastest (+7 ms). The mean response offset for the full dataset is +208 ms.
平均でもっとも遅いのがデンマーク語で+469ミリ秒、もっとも速いのが日本語で+7ミリ秒。全体の平均は+208ミリ秒でした。
論文は「日本人は間を置く」という通説を名指しで否定している
さらに考察部分に、こう書かれています。
Japanese speakers are said to leave substantial gaps of silence before responding, but our findings show that Japanese speakers are, on average, the earliest to respond of all of the languages in our sample.
日本語の話者は応答の前に長い沈黙を置くと言われているが、我々の発見では、サンプル中のどの言語よりも早く応答している。
「said to」の主語は民族誌の文献（Gudykunst & Nishida, 1994）で、論文の著者たちの主張ではありません。通説を引いて、それをデータで否定している構図です。
但し書きが4つある。数字の性質を確認しておく
ただしこの+7ミリ秒を、そのまま「日本人は7ミリ秒で返す」と読むことはできません。論文の方法論に、押さえておくべき条件が4つあります。
1つ目は測定の粒度です。方法の節には「measured instrumentally by using annotation software ELAN in 10-ms increments rounded to 100 ms」とあります。生データは100ミリ秒単位に丸められています。報告される中央値が0/+100/+300ミリ秒と100の倍数ばかりなのは、この丸めの結果です。7ミリ秒という数字は、丸めた値を平均した結果であって、7ミリ秒の分解能で測ったものではありません。
2つ目は応答の起点です。「The response turn was considered to begin if a vocal or gestural response was initiated」。声だけでなく身振りによる応答も起点になります。うなずきが先に出れば、そこが応答開始時刻です。日本語は話者への視線率が88%で10言語中最高であり、視線は応答を69.28ミリ秒早める有意な予測因子でもあります。日本語の速さは、うなずきや視線の効果を相当に含んでいることになります。
3つ目は対象の限定です。「For optimal comparability we restricted the comparison to polar questions」。計測されたのは、機能的にイエスかノーを求める極性疑問文への応答だけです。会話一般の間合いではありません。
4つ目は中央値です。「ranging from 0 ms (English, Japanese, Tzeltal, and Yélî-Dnye) to +300 ms」。日本語の中央値は0ミリ秒ですが、これは英語・ツェルタル語・イェリドニェ語と同じ値です。日本語だけが突出して速いのは、平均値で見たときだけです。
論文の結論は「日本語が速い」ではなく「10言語に共通の仕組みがある」
いちばん重要な留保がこれです。この論文の主眼は、日本語の特殊性ではありません。
考察にはこう書かれています。「local variations are quantitative only」。各言語の平均は全体平均の前後およそ250ミリ秒以内に収まっており、それは英語の1音節を発音する程度の長さにすぎない、と。
結論部はさらに直接的です。「The actual difference between the 10-language norm and the average turn transition in Danish is confined to the time it takes to utter a single syllable」。10言語の標準とデンマーク語の平均の差は、1音節を発する時間に収まる。
デンマーク語についても留保があります。最頻値は100ミリ秒と小さく、「speakers target minimizing gaps and overlaps」、つまりデンマーク語の話者も間と重なりを最小にしようとしている。民族誌の報告が示唆する「分単位、あるいは時間単位の長い沈黙」とはほど遠い、と。
言語による差はあるが、それは量的なものにすぎない。順番交替の仕組みそのものは10言語に共通している。これが論文の主張です。
なお、論文冒頭で引かれている「長い沈黙」の逸話はフィンランドと北スウェーデンのものですが、10言語のサンプルにフィンランド語もスウェーデン語も入っていません。検証されたのはデンマーク語だけです。
ここまで確認したうえで言えることは、こうなります。会話の間合いは言語で少しずつ違う。そしてどの言語の話者も、間を詰めようとしている。全二重の音声AIが相手にしているのは、この共通の性質のほうです。
SynthIDの追記は7月31日。EU AI法の期限は改正で12月2日に延びていた
もう1つ、日付が近いために結びつけたくなる話があります。ここは因果を作らないよう慎重に書きます。
7月8日のページに、7月31日付の追記が入った
「Introducing GPT-Live」のページの冒頭には、後から追記されたブロックがあります。
Update July 31, 2026: Supported audio generated with GPT-Live through ChatGPT Voice and the OpenAI API now includes SynthID watermarking.
GPT-Liveが生成した対応する（Supported）音声に、SynthIDの電子透かしが入るようになった、と。
この「Supported」という限定は落とせません。続く文でも「Our public verification tool can now detect OpenAI provenance signals in supported audio files」と、再び同じ語が使われています。すべての音声出力に透かしが入る、とは書かれていません。
これは独立した発表記事ではなく7月8日のページへの追記です。同じ日付の追記は、5月19日の来歴に関するページにも入っています。
検証ツールの側も確認しました。OpenAIのverifyページには「It looks for supported signals, including C2PA metadata and SynthID watermarks, and reports whether they are detected.」とあります。対応形式は「It currently supports images and audio files.」で、画像と音声ファイルです。
ただし検出できる範囲には制限があります。対象は「ChatGPT、OpenAI API、Codexで生成されたコンテンツ」に限られ、FAQには「Content could also still be AI-generated by another company’s model, which the tool currently does not detect.」と書かれています。
つまり検出されなかったことは、AI生成でないことの証明にはなりません。他社のモデルで作られた可能性は残りますし、メタデータが剥がされたり透かしが劣化したりした場合も検出できません。陽性は根拠になりますが、陰性は結論になりません。
第50条の適用開始は8月2日、既存システムは12月2日
7月31日という日付は、EU AI法の第50条（透明性義務）の適用開始である2026年8月2日の2日前にあたります。並べると、駆け込みで対応したように読めます。
ここを確認したところ、その読み方は成立しませんでした。
EU AI法は2026年7月8日に採択された改正規則（Regulation (EU) 2026/1744）で大きく改正され、7月27日に発効しています。その改正で新設された第111条(4)に、こうあります。
Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, that have been placed on the market before 2 August 2026 shall take the necessary steps in order to comply with Article 50(2) by 2 December 2026.
2026年8月2日より前に市場に出された生成AIシステムの提供者は、2026年12月2日までに第50条(2)を遵守する措置を講じる、と。
ChatGPTもOpenAI APIも、8月2日より前から提供されている既存のシステムです。したがって、マーキング義務の実際の期限は12月2日ということになります。
「8月2日に間に合わせるため7月31日に対応した」という因果は書けません。時系列としては近いですが、それだけです。
なお同じ改正で、高リスクAIに関する規定の適用時期も後ろ倒しになりました。2026年8月2日から始まるのは透明性義務などであって、高リスク規制の本格適用ではありません。
GPT-Liveの2本に規制の語はないが、別記事にはある
では、OpenAIは規制について何も言っていないのか。ここも確認が必要でした。
GPT-Liveの2本（7月8日・8月3日）を機械的に走査すると、EU、European、AI Act、regulation、regulatoryといった語はいずれも0件です。8月3日の記事にはSynthID、provenance、watermarkの語すらありません。
ただし、それは2本のページの話にすぎませんでした。OpenAIは同じ7月31日に別の記事「Advancing responsible AI across Europe」を公開しています。
As the EU AI Act enters its next phase, we’re sharing how we have strengthened our approach to safety, security, transparency and provenance in line with the EU framework
そして透明性の節にはこうあります。「We are expanding that work to include audio outputs in addition to images. Consistent with our commitments under the Code…」。画像に加えて音声にも広げる、透明性行動規範の下でのコミットメントに沿って、と。
音声へのSynthID拡大を、OpenAI自身がEU AI法と明示的に結びつけていたわけです。ただし結びつけたのは規制対応の枠組みとしてであって、8月2日という期限に間に合わせるためだとは書いていません。
日本語で使えるのか。公式は「人気の高い言語の一部」としか書いていない
最後に、日本の読者がいちばん知りたいところを確認します。
7月8日のページに「Japanese」の語は0件だった
言語対応について、7月8日のページはこう書いています。
We’ve optimized GPT-Live for some of the most popular languages in ChatGPT. For certain languages, the model may have a non-native accent or gaps in fluency.
ChatGPTで人気の高い言語のいくつかに（some of）最適化した。一部の言語では、母語話者でないような訛りや流暢さの欠落があるかもしれない、と。
ここに個別の言語名は1つも出てきません。念のためページ全体を機械的に走査しました。Japanese、日本語ともに0件。Spanish、French、German、Chinese、Korean、Hindi、Arabicなども同様に0件です。唯一ヒットしたEnglishは、フッターのロケール切り替えUIでした。
つまり「日本語に最適化済み」も「日本語は対象外」も、公式ページを根拠にはできません。書かれていないことは、どちらの方向にも証拠になりません。
日本のメディアは実機で試した所感を書いている
日本語での挙動については、日本のメディアが実際に試した記述があります。
ギズモード・ジャパンは2026年7月9日、かみやまたくみ氏の署名で「ハンズフリーでも使いやすく。ChatGPTの「音声会話モード」が大幅進化」を公開しました。同日16時15分に「実際に試すことができたので、所感を述べる形に一部変更しました」と更新されています。
その記事にはこうあります。「自分の環境にも下りてきていて試したのですが、日本語でも英語デモと同等の進化をしているのが確認できました。」
もう1か所、変化の中身に触れた記述もあります。「以前は会話が「ターン制」でChatGPTとユーザーが交互にしゃべる感じでしたが（中略）会話のテンポは確実によくなりました。」
これは筆者個人が自分の環境で試した所感であり、測定や検証に基づく評価ではありません。ただし、公式が言語別の情報を出していない以上、日本語での実際の挙動について参照できる数少ない記述です。
段階的な展開で、動画・画面共有には当初非対応
提供のされ方についても、公式の書き方を確認しておきます。
7月8日のページは「We’re beginning to roll out two versions of GPT-Live」「rolling out now to ChatGPT users globally across iOS, Android, and ChatGPT.com」「will become the default」と、いずれも段階的な展開・未来形で書かれています。7月8日に全員が一斉に切り替わったわけではありません。
ローンチ時の制限も先に触れたとおりで、動画や画面共有と組み合わせた音声には当初対応していません。Standard・Advanced Voice Modeという従来のモードは残されています。
音声そのものについては「We’ve also remastered the nine distinct voices in ChatGPT for GPT-Live.」とあります。9種類の声は新規追加ではなく、既存の声のリマスターです。
なお、APIについては8月3日の記事が「will underpin the upcoming GPT-Live API」と書いており、8月3日時点でGPT-Live APIは提供前です。一方で7月31日の追記は「through ChatGPT Voice and the OpenAI API」に言及しています。APIの提供状況に触れる場合は、どの時点の話かを明示する必要があります。
OpenAIの232ミリ秒から沈黙までの2年間が示すもの
ここまで確認してきて、最初の引っかかりに戻ります。なぜ数字がなかったのか。
推測を書くつもりはありません。OpenAIは理由を説明していないので、分かるのは事実のほうだけです。
2024年5月、OpenAIはGPT-4oの音声応答を232ミリ秒と書きました。2026年8月、GPT-Liveについては1つも数字を書きませんでした。
代わりに書かれたのは、p95が旧p50に並んだという相対比較、6往復が1往復になったという数え上げ、UDPパケット1つという最小単位です。どれも「速い」ではなく「詰めた」ことを示す数字です。
そして唯一の定性表現がこれでした。
By minimizing buffering and blocking throughout the system, we can deliver the sub-second responsiveness that humans expect from conversation.
バッファリングとブロッキングを最小化することで、人間が会話に期待する1秒未満の応答性を提供できる。測定値ではなく、条件付きの記述です。
そしてもう1つ、記事の第1段落にはこうあります。「Human speakers effortlessly hand off to each other in a fraction of a second」。人間の話者は1秒に満たない時間で苦もなく交替する、と。これはGPT-Liveの性能ではなく、目指す対象としての人間の速さです。
ここでPNASの数字が効いてきます。人間が実際にどのくらいで返しているか。10言語の平均で+208ミリ秒、日本語で+7ミリ秒でした。
ターン制の時代は、遅れをミリ秒で測る意味がありました。人間より遅いことが分かっていたからです。全二重になると、測るべきものが変わります。話し始めのタイミングが正しいか、割り込みを正しく受け止めるか、相槌を独立した発言と誤解しないか。これらはミリ秒では表せません。
サーベイ論文が指摘したrealization gap、つまり原理上は全二重でも振る舞いは訓練と評価に縛られるという問題も、同じところを指しています。アーキテクチャの宣言と体感の間には、まだ埋まっていない距離があります。
数字が消えたことを、都合の悪い数字を隠したと読むこともできます。測る物差しがまだない、と読むこともできます。どちらが正しいかは、いまの情報では決められません。
分かっているのは、この2年でOpenAIの語り方が変わったこと。そして次に何が語られるかを見れば、業界がどんな物差しを採用したのかが分かる、ということです。
まとめ：GPT-Liveの全二重から日本語の+7ミリ秒まで、7つの要点
最後に、この記事で確認したことを整理します。
1. 8月3日の記事にレイテンシの絶対値はない。約17,600字の本文にミリ秒も秒もパーセントも0件でした。定量表現は「p95が旧p50に一致」「6往復が1往復に」「UDPパケット1つ」の3つだけです。
2. GPT-Liveの発表は7月8日で、8月3日は舞台裏の記事。カテゴリはEngineering、著者はJustin Uberti氏とZahan Malkani氏で、肩書きはMembers of Technical Staffです。
3. ターン検知器を外したのは「音声経路から」。アプリケーション層ではいまも離散的なターンを組み立てています。「ターン制を廃止した」とは書かれていません。
4. 6か月でやったのは3領域の作り直し。動詞はreworkedで、モデル推論・コンテキスト管理・メディア転送が対象です。既存の基盤があったことも明記されています。
5. 「full-duplex」を名乗るのはOpenAIだけではない。Google・xAI・Amazonの公式文言には0件でしたが、NVIDIAのPersonaPlexもKyutaiのMoshiも使っています。サーベイは「十数個を超えるシステムが自称している」と述べています。
6. 会話の返しが世界最速の言語は日本語。ただし+7ミリ秒は100ミリ秒単位に丸めた値の平均で、うなずきなど身振りの応答も含み、極性疑問文に限定され、中央値は英語と同じ0ミリ秒です。論文の主眼は日本語の特殊性ではなく、10言語に共通する仕組みのほうにあります。
7. SynthIDとEU AI法に因果は書けない。第50条の適用開始は8月2日ですが、改正で新設された第111条(4)により、既存システムの遵守期限は12月2日です。ただしOpenAI自身は、同じ7月31日の別記事で音声へのSynthID拡大をEU AI法と結びつけています。
音声の変化は、使えばすぐ分かります。数字で説明されないぶん、自分の耳が唯一の物差しになりました。あなたの環境では、会話のテンポはどう変わったでしょうか。
その日の他のAIニュースについては、まとめ記事のほうもあわせてご覧ください。
よくある質問（FAQ）
Q1. GPT-Liveはいつから使えるようになったのですか。
2026年7月8日の「Introducing GPT-Live」で発表され、同日から段階的に展開が始まりました。8月3日に公開されたのは製品の発表ではなく、その開発過程を書いたエンジニアリング記事です。提供の内訳は、Go・Plus・ProがGPT-Live-1、FreeがGPT-Live-1 miniで、いずれも「will become the default」という書き方になっています。
Q2. GPT-Liveの応答速度は何ミリ秒ですか。
公式には示されていません。8月3日の記事にも7月8日のページにも、レイテンシの絶対値は書かれていませんでした。書かれているのは「sub-second responsiveness（1秒未満の応答性）」という定性表現と、「新システムのp95が旧システムのp50に一致」という相対比較だけです。なお2024年5月に公表された232ミリ秒・320ミリ秒はGPT-4o世代の数値であり、GPT-Liveのものではありません。
Q3. 日本語での品質は公式にどう説明されていますか。
個別の言語について、公式の説明はありません。7月8日のページは「ChatGPTで人気の高い言語のいくつかに最適化した」「一部の言語では母語話者でないような訛りや流暢さの欠落があるかもしれない」と書くのみで、Japaneseという語はページ内に1件も登場しません。日本語での実際の挙動については、ギズモード・ジャパンが2026年7月9日に「日本語でも英語デモと同等の進化をしているのが確認できました」という実機の所感を掲載しています。
筆者より
この記事を書く途中で、自分の見立てが1つ崩れました。
Google・xAI・Amazonの公式ドキュメントを走査して「full-duplexを自社アーキテクチャの説明に使っているのはOpenAIだけだ」と考えたのですが、NVIDIAのPersonaPlexとKyutaiのMoshiという反例がありました。しかも根拠に使おうとしていたサーベイ論文自身が、冒頭で「十数個を超えるシステムが自称している」と書いていたのです。
3社を選んだのは私で、その選び方が結論を作っていました。比較対象を自分で決めたときは、その選び方が答えを決めていないかを疑ったほうがいい、と改めて思いました。
もう1つ、PNASの+7ミリ秒も危ないところでした。「日本人は会話の返しが世界一速い」は事実として書けますが、方法の節を開くと、生データが100ミリ秒単位に丸められていること、うなずきも応答の起点になること、極性疑問文だけが対象であることが分かります。数字は正しくても、そのまま使うと違う意味になります。
参考資料
- OpenAI「How we built a realtime system for responsive voice AI in six months」（2026年8月3日、Justin Uberti・Zahan Malkani）
- OpenAI「Introducing GPT-Live」（2026年7月8日、7月31日追記）
- OpenAI「How OpenAI delivers low-latency voice AI at scale」（2026年5月4日）
- OpenAI「Hello GPT-4o」（2024年5月13日）
- OpenAI「ChatGPT can now see, hear, and speak」（2023年9月25日）
- OpenAI「Advancing responsible AI across Europe」（2026年7月31日）
- OpenAI「Verify」（来歴シグナルの検証ツール、2026年8月4日閲覧）
- Google「Gemini API Live guide」（2026年8月4日閲覧）
- xAI「Voice Overview」docs.x.ai（2026年8月4日閲覧）
- Amazon「Alexa+」製品ページ（米国ロケール版、2026年8月4日閲覧）
- Jingyu Lu ほか17名「A Survey of Full-Duplex Spoken Dialogue Systems」arXiv:2606.19453（2026年6月17日、プレプリント）
- NVIDIA ADLR「PersonaPlex」プロジェクトページ（2026年8月4日閲覧）
- Kyutai Labs「Moshi」公式リポジトリ（2026年8月4日閲覧）
- Tanya Stivers ほか10名「Universals and cultural variation in turn-taking in conversation」PNAS 第106巻26号 10587-10592ページ（2009年）
- 欧州連合「Regulation (EU) 2024/1689（AI法）統合版 CELEX:02024R1689-20260727」EUR-Lex
- IETF「draft-uberti-tsvwg-warp-00」（2026年7月22日改訂）
- ギズモード・ジャパン「ハンズフリーでも使いやすく。ChatGPTの「音声会話モード」が大幅進化」（2026年7月9日、かみやまたくみ氏）
この記事が気に入ったら
フォローしてね！
お気軽にコメントどうぞ