はじめに：AIとの会話、もう少し自然にならない？
音声AIと話していて、こんなやり取りを経験したことはありませんか。
自分「明日の予定なんだけど、えーっと……」
AI 「明日の予定ですね！ まずは……」
自分「いや、まだ考えてる途中なんだけど……」
返事が速いのは嬉しい。でも、そこで入ってこられると困る。
逆に、AIの説明中に「うんうん」と相づちを打っただけで、説明が止まってしまうのも少し不自然です。人間同士なら、それが「続きを話していいよ」なのか、「ちょっと待って」なのかを、会話の流れから判断していますよね。
DuplexSLAが扱うのは、こうした会話の間合いだけではありません。もう一つの重要な要素が「ツール」です。音声AIやLLMにおけるツールとは、AIが会話するだけでなく、外部の機能を使って実際の処理を行う仕組みのことです。たとえば、天気を調べる、カレンダーを確認する、音楽を再生する、目的地までの経路を検索するといった操作が当てはまります。こうした外部機能を実行するための指示を出すことを「ツール呼び出し（Tool Calling）」と呼びます。
今回読んだ論文で提案されているDuplexSLAは、会話の間合いを判断しながら、話している途中でツールまで呼び出す音声モデルです。
SLAは Speech–Language–Action の略。音声、言語、そして行動です。
面白いのは、聞く・話す・短い計画を立てる・ツールを呼ぶ、という処理を、160ミリ秒刻みの共通の時間軸に載せていること。会話が進んでいるその途中に、次の操作も組み込んでいくわけです。
というわけで、この記事ではDuplexSLAの仕組みを、できるだけイメージしやすい形で読み解いていきます。
想定読者
- LLMや音声AIの仕組みに興味がある人
- ツール呼び出しは知っているけど、音声とどう組み合わせるのか気になる人
- モデルの賢さだけでなく、「会話していて気持ちいいか」も大事だと思う人
この記事を読むと分かること
- 全二重の音声対話で、何が難しいのか
- DuplexSLAの「2ストリーム・3チャネル」という設計
- 相づち、割り込み、考え中の沈黙をどう扱うのか
- 会話の途中でツールを呼ぶ仕組みと、実験結果の読みどころ
論文情報
- タイトル：DuplexSLA: A Full-Duplex Spoken Language Model with Synchronized Speech, Language, and Action
- 著者：Haoyang Zhang, Jun Chen, Donghang Wu ほか
- 発表：arXivプレプリント。初版は2026年5月20日、本記事で参照するv2は2026年6月11日
- 論文：arXiv / PDF
- 公式リポジトリ：hyzhang24/DuplexSLA
- デモページ：DuplexSLA Project Page
※本記事は論文を読んだ解説です。以下の実験値は著者らの報告であり、私が再現実験を行ったものではありません。公開状況は2026年9月15日に確認しました。
そもそも「全二重」の会話って何？
全二重（full-duplex）は、送信と受信を同時に行えること。音声対話なら、AIが話している間も、ユーザーの声を受け取り続けるイメージです。
電話で話している場面を思い浮かべると分かりやすいです。相手が説明している途中でも、こちらは相づちを打ったり、「あ、それ先に聞きたい」と入ったりできます。
音声AIでこれを自然に実現しようとすると、単にマイクを開きっぱなしにするだけでは足りません。入ってきた声を聞いて、いま話し続けてよいかまで判断する必要があります。
音声対話を順番に処理すると、待ち時間が生まれる
論文が背景として挙げているのは、次のような段階的な構成です。
それぞれの役割を、略語と対応させておきます。
| 略語 | 役割 | ざっくり言うと |
|---|---|---|
| VAD | Voice Activity Detection | 人が話している区間を見つける |
| ASR | Automatic Speech Recognition | 音声を文字にする |
| LLM | Large Language Model | 内容を理解し、返答や操作を決める |
| TTS | Text-to-Speech | 文字を音声にする |
ここで、音の有無を中心に見るVADにとっては、「考え中の沈黙」と「言い終わった後の沈黙」が紛らわしい。意味も見る外部の検出器を追加する方法はありますが、その判断を待つ時間も必要になります。
さらに、ツール呼び出しを発話の前後にまとめると、操作が終わるまで返答を待たせたり、説明が終わるまで操作が遅れたりします。
DuplexSLAは、こうした会話のタイミングと操作のタイミングを、一緒にモデル化する研究です。なお、全二重の音声モデル自体には先行研究があります。この論文で注目したいのは、そこへ計画とツール呼び出しを組み込む設計です。論文・第1節
DuplexSLAの基本アイデア：会話に「操作用のチャネル」を足す
DuplexSLAには、3つのチャネルがあります。
| チャネル | 流れるもの | 役割 |
|---|---|---|
| User Channel | ユーザーの音声特徴量 | 相手の声を受け取る |
| Assistant Channel | AIの発話に対応するテキストアンカーと音声トークン | 声を出す |
| Action Channel | 書き起こし、短い計画、会話制御ラベル、ツール呼び出し | 会話に合わせて判断や操作を出す |
ポイントは、Action Channelも発話と同じ時間軸で進むことです。論文・第2.1節
たとえば、人と話しながらメモを取る場面を想像してください。
- 耳では相手の話を聞く
- 口では返事をする
- 手元では「次に調べること」を書く
この手元のメモに相当するものが、Action Channelです。そこに書く内容には、ツールへの具体的な指示も含まれます。
会話しながらメモも取る。人間でもなかなか忙しいやつです。メモに集中すると、相づちが全部「なるほど」になったりしますよね。
ただし、3人の担当者が別々に動く構成ではありません。共通のLLMバックボーンが、入力音声や過去の出力を参照しながら、AI側の音声とアクションの両方を生成します。
図にすると、入力を受け取りながら、同じモデルから2種類の出力を作る構成です。
図の矢印は情報の流れを表しています。2種類の出力は、どちらも160ミリ秒刻みの共通の時間軸に対応づけられます。
「2ストリーム・3チャネル」の数え方
ここ、名前だけ見ると少しややこしいですね。
- 2ストリーム：ユーザー側とAI側、2本の音声の流れ
- 3チャネル：ユーザー音声、AI音声、アクションという3種類の情報
Action Channelはテキストなので、音声ストリームがもう1本増えるわけではありません。また、ユーザー音声は観測する入力であり、モデルが生成する対象ではありません。論文・第2.1〜2.2節
160ミリ秒の刻み：全員が同じ時計を見る
DuplexSLAは、会話を 160ミリ秒のチャンク（短い区間） に区切ります。
1チャンクの中身は、次のようになっています。
| チャネル | 160ミリ秒あたりの中身 |
|---|---|
| ユーザー音声 | 80ミリ秒刻みの音声特徴量 × 2 |
| AI音声 | テキストアンカー × 1 ＋ 40ミリ秒刻みの音声トークン × 4 |
| アクション | 最大10個のテキストトークン |
AI音声の形式は、Textが1個、Audioが4個なので TA4 と呼ばれます。テキストアンカーは、音声とテキストを結びつけるための目印だと考えるとよさそうです。論文・第2節、Table 1
少しだけ数式で確認
📘 数式が苦手な方へ：ここは「160ミリ秒ごとのマスに情報を載せる」と分かれば大丈夫です。
論文では、時刻を次のようにチャンク番号へ対応づけています。
$$
c = \left\lfloor \frac{t}{\Delta} \right\rfloor, \qquad \Delta = 160\ \mathrm{ms}
$$
- $t$：会話の開始からの経過時間
- $\Delta$：1チャンクの長さ
- $c$：チャンク番号
- $\lfloor \cdot \rfloor$：小数点以下を切り捨てる操作
たとえば、開始から350ミリ秒なら $\lfloor 350/160 \rfloor = 2$。0番から数えて3つ目の区間です。
これにより、「どの音声を聞いているときに、何を話し、どの操作を出したのか」を、同じ目盛りで扱えます。論文・第2.1節
Action Channelに字数制限がある理由
アクションを書き放題にすると、長い計画やJSONの生成に時間がかかり、次の音声区間に間に合わなくなります。
アクション側が長々と書いている間にも、次の音声がやってきます。「ちょっと待って、今いい感じのJSON書いてるから」では、会話が止まってしまいます。
そこで、論文の設定では1チャンクあたり最大10トークン。入りきらない内容は、次のチャンクへ持ち越します。10トークンは10文字という意味ではありません。
下の図は、上から下へ時間が進みます。同じ区間の中で、ユーザー音声の入力と、AI音声・アクションの出力が対応づけられています。
アクションが次のチャンクへ持ち越されても、AI音声は各チャンクで出力され続けます。各チャンク内ではトークンを順番に生成するため、図はすべての処理を同時刻に実行することを意味しません。
※仕組みを示す模式図です。矢印の間隔や所要チャンク数は実測値ではありません。
この上限は、実行環境の処理速度に合わせた運用上の設定です。論文では、アクセラレータに応じて再学習なしで調整できるとしています。論文・第2.3節、付録D
160ミリ秒は、処理を揃える時間単位です。ユーザーが話してから必ず160ミリ秒で返答する、という意味ではありません。
実際の待ち時間には、判断に必要な音声が揃うまでの時間や、生成処理なども関係します。
会話の間合い：沈黙・割り込み・相づちを扱う
論文が重視するのは、次の3つの振る舞いです。
まず、「ユーザーがどういうつもりで発言・沈黙したか」と「AIがどう振る舞うか」を対応づけてみます。
これは3つの振る舞いを整理した図です。実装上の固定ルールで分岐させるのではなく、同じモデルが会話の意味から判断します。
1. Pause：考え中なので、少し待って
ユーザー「近くのお店で……えーっと……静かなところがいいな」
AI （途中の沈黙では話し始めず、続きを聞く）
途中で音が途切れても、ユーザーがまだ話すつもりなら待つ。AI側の音声チャネルには、無音に対応するトークンを出します。
2. Interrupt：説明を止めて、こちらを聞いて
AI 「候補のお店は3つあって、まず1つ目は……」
ユーザー「あ、ごめん。徒歩で行けるところだけにして」
AI （発話を止め、ユーザーに話す番を渡す）
新しい意図を伴う割り込みでは、Action Channelに interrupt を出し、AI側の音声を無音へ切り替えます。
3. Backchannel：聞いてるよ。そのまま続けて
AI 「このお店は駅から近くて……」
ユーザー「うんうん」
AI 「席の間隔も広めです」
相づちは、相手から話す番を奪うための発言ではありません。Action Channelで backchannel と判断し、話の流れを保ちます。
以上は説明用に作った会話例です。論文のポイントは、こうした判断を発話を生成するモデル自身の意味表現から行うことにあります。外部のsemantic VAD（意味を考慮する発話検出器）に会話制御を任せる必要を減らしています。論文・第2.4節、Figure 2
※Pauseは振る舞いの名前です。論文では、待機を response 系の継続聴取ラベルと無音出力で表しており、3つの振る舞いがそのまま同名の3トークンになるわけではありません。
会話の途中でツールを呼ぶ：説明しながら操作も進める
ここがDuplexSLAの、特に面白いところだと思います。
短い追加依頼を、話の途中で受け付ける
たとえば、AIが何かを説明している途中に、ユーザーが「音楽をかけて」と頼む場面。
DuplexSLAはAction Channelへ計画とツール呼び出しを出しつつ、AI音声のチャネルでは説明を続ける、というパターンを扱います。
論文では、これを backchannel-triggered tool calling と呼んでいます。ここでのbackchannelは、単なる「うんうん」だけでなく、現在の説明を止めずに処理する短い別件の依頼まで含む使い方です。論文・第2.5節、Figure 3
ユーザーから見ると、一つの会話の中で「説明を聞く」と「音楽を頼む」が重なります。
図は利用者から見た処理の重なりを表しています。外部ツールへの受け渡しと音楽再生の部分は、利用時の構成を想定して補ったものです。論文の評価対象は呼び出し内容とタイミングであり、実機での再生完了を検証した図ではありません。外部ツールの実行にかかる時間は、モデルが呼び出しを生成する時間とは別です。
1回の発話から、複数の操作を順番に出す
説明用の例として、運転中に「エアコンを22度にして、音楽の音量を少し下げて」と頼む場面を考えてみます。エアコンの温度設定と音量調整は、それぞれ独立した操作です。DuplexSLAは、こうした複数の依頼に対し、それぞれの意図が現れたタイミングに合わせて呼び出しを順番に生成します。
アクションは発生順に待ち行列へ入り、前の呼び出しが長ければ後ろのものは待ちます。その間も、AI音声の生成はチャンクごとに進みます。論文・第3.3節、付録E
会話しながら、横でタスクリストを順番に処理していく感じですね。
ただし、モデルがツール呼び出しを出す時刻と、外部ツールが処理を完了する時刻は別です。長いJSONが複数チャンクにまたがる場合もあり、呼び出し内容が揃うまでの時間や、呼び出し先の実行時間まで消えるわけではありません。論文・付録D
学習方法：まず時間を合わせて、それから会話の間合いを覚える
DuplexSLAは、約7B、つまり約70億パラメータ規模の Step-Audio 2 mini を初期モデルに使い、2段階で学習しています。論文・第4節
最初に会話とアクションの時間を揃える土台を作り、その後に具体的な振る舞いを学ばせる流れです。各段階のデータ量は次のとおりです。
| 段階 | 主なデータ | 狙い |
|---|---|---|
| 継続事前学習（CPT） | 音声約50万時間 ＋ テキスト約192万サンプル | 3チャネルの形式と時間の対応を学ぶ |
| 事後学習（Post-training） | 音声約5万時間 | 割り込み・相づち・待機・ツール呼び出しを学ぶ |
継続事前学習の音声は、全二重対話が約32万時間、ユーザー側とAI側のASR（音声を文字に変換する音声認識）がそれぞれ約9万時間。事後学習は、会話制御が約3.6万時間、ツール呼び出しが約1.4万時間です。論文・Table 2
事後学習だけでも5万時間。休みなく聞き続けたとすると、約5.7年分です。「それだけ会話して、ようやく相づちの間合いを覚えたのか……」と、ついツッコミたくなりますね（実際には相づち以外の会話制御やツール呼び出しも含む、音声データの合計時間です）。
AI自身の音声も書き起こす理由
個人的に面白いと思ったのは、AI側の音声に対するASRも学習に使うところです。
TA4のテキストアンカーだけでは、言葉が実際に発声されるタイミングを厳密に表せません。そこで、AIが発した音声の書き起こしもAction Channelに対応づけ、発話とアクションの時間を揃えます。
自分の口がいまどこまで話したのかを、時計とセットで覚えるイメージです。論文・第3.4節
学習目標の基本は、次のトークンを予測するクロスエントロピー損失です。そこに無音やチャネル境界などへのマスク・重み付けを加えています。会話の形式とタイミングを、学習データと目的関数の両方で教えているわけです。論文・第4.3節
実験結果：どれくらい速く、正しく動くのか
評価には、著者らが構築した DuplexSLA-Bench を使っています。全2,100件で、内訳は次のとおりです。
| 評価対象 | シナリオ | 件数 |
|---|---|---|
| 会話制御 | 通常応答、考え中の沈黙、割り込み、相づち | 各300件、計1,200件 |
| ツール呼び出し | 単一操作、複数操作、会話中の短い追加依頼 | 各300件、計900件 |
ツールは車内操作、ナビゲーション、メディア再生、検索など、50種類の関数スキーマを対象にしています。論文・付録C
ツール呼び出し：平均遅延は0.64秒
論文のTable 5を、パターンごとに並べ直しました。
| パターン | ASR＋LLM 正解率 | DuplexSLA 正解率 | ASR＋LLM 遅延 | DuplexSLA 遅延 |
|---|---|---|---|---|
| 単一操作 | 89.33% | 85.67% | 2.33秒 | 0.67秒 |
| 複数操作 | 89.33% | 75.00% | 4.71秒 | 0.68秒 |
| 会話中の短い追加依頼 | 95.33% | 96.00% | 1.27秒 | 0.57秒 |
| 3パターン平均 | 91.33% | 85.56% | 2.77秒 | 0.64秒 |
出典：論文・第5.2節、Table 5。比較対象は論文内のASR＋LLMシステムです。
平均遅延は、2.77秒から0.64秒へ。割り算すると約4.3分の1、約77%の短縮です。
この遅延は、正解の基準時刻と、予測したアクションのトリガー時刻との差を評価したものです。付録Dでは、トリガー時刻を「計画テキストの出力が始まるチャンク」に対応づけています。呼び出し内容がすべて揃うまでの時間や、外部ツールの実行完了までの時間を表す値ではありません。論文・第5.2節、付録D
一方で、平均正解率は5.77ポイント下がっています。特に複数操作では75.00%なので、ここは見逃せません。
この比較では、速度の改善が大きい一方、正解率にはトレードオフがあります。
なお、正解判定では、必要なすべてのツール呼び出しについて、関数名・引数・呼び出しタイミングが合っているかを確認します。引数は完全一致だけでなく、表記が違っても意味が同じなら、LLMによる判定で一致とみなします。複数の操作が必要な場合は、1つでも欠けるとケース全体が不正解です。また、遅延は正しく呼び出せたアクションだけを対象に計算されるため、正解率とセットで読む必要があります。論文・第5.2節
図で整理すると、正解率は「ケース単位」、遅延は「一致したアクション単位」で集計している点がポイントです。
ケース全体が不正解でも、一部のアクションが一致していれば、そのアクションは遅延の集計対象になります。
会話制御：割り込みに対する遅延は0.40秒
会話履歴を事前に入力する context prefillあり の条件で、DuplexSLAの結果を抜き出すと次のようになります。
| シナリオ | 正解率 | 遅延 |
|---|---|---|
| 通常応答 | 96.00% | 0.27秒 |
| 考え中の沈黙を含む発話 | 93.33% | 0.27秒 |
| 割り込み | 99.33% | 0.40秒 |
| 相づち | 98.33% | 0.32秒 |
出典：論文・第5.3節、Table 6。
ここで「遅延」は、シナリオごとに測っている対象が違います。
- 通常応答・Pause：ユーザーの発話終了からAIの発話開始までの時間差
- Interrupt：意味上の割り込み基準時刻と、AIが発話を止めた時刻との差
- Backchannel：相づちの終了時刻と、ラベルを出した時刻との差
いずれも論文の定義では基準時刻との差の絶対値で、成功例に対して計算します。したがって、相づちの0.32秒は「AIが音声で相づちを返すまでの時間」ではありません。論文・第5.1節、Table 3
数値を見るときに気をつけたい点
今回の評価は、著者らが定義したシナリオと判定条件での結果です。
特に相づちは、DuplexSLAではアクションラベルを読めますが、一部の比較モデルでは読めません。そのため、比較モデルでは音声上のイベントを使う代替判定が入り、相づちの遅延はN/Aになっています。
また、Table 6のキャプションには全シナリオで最高精度という趣旨の記載がありますが、Pauseの正解率はDuplexSLAの93.33%に対し、比較モデルに94.33%の値があります。本文では表の数値を優先して読みたいところです。論文・Table 5, 6
会話の自然さを数値にするのも、なかなか難しいですね。
面白さと、これから確認したいこと
良いと思ったところ
- 声と操作に共通の時間軸がある：何をするかに加え、いつするかを扱える
- 会話の間合いをモデルの中で判断する：相づちと割り込みに異なる振る舞いを学ばせる
- 処理時間を意識した設計：アクションの出力量を制限し、音声を続けられるようにする
特に、アクションを音声と並べて扱う設計が好きです。音声エージェントを作るとき、「返答の内容は合っているのに、操作のタイミングが微妙」という問題まで考える必要があるのだと、改めて感じます。
今後の検証で知りたいこと
ここからは、論文を読んで私が気になった点です。
-
長い計画や複雑な操作で、どれくらい待ちが増えるか
アクションにはトークン数の上限があり、後続操作は順番待ちになります。依頼が複雑になっていくとこの待ち時間がどうなっていくのかは気になります。 -
日本語や実環境の雑音で、同じように間合いを取れるか
今回参照した結果から、日本語での性能や騒がしい場所での性能までは判断できません。「あー」「えっと」の使い方も含め、別途評価が必要そうですね。 -
呼び出したツールの失敗や、途中の言い直しをどう扱うか
「エアコンを下げて……やっぱりそのままで」と言われたとき、操作がすでに進んでいたらどうするか。呼び出しを速く出せるほど、取り消しや状態管理も大事になりそうです。
こうした点は、論文の呼び出し精度・タイミング評価に加えて、実際のアプリケーションとして確認したい部分です。
公開状況：手元で試せる？
2026年9月15日に公式リポジトリを確認した時点では、技術レポートとデモページが案内されています。一方、READMEでは次のものが未公開、または公開予定とされています。
- モデルのチェックポイント
- 推論コード・ストリーミングサーバー・デプロイ手順
- DuplexSLA-Benchの評価コードとデータ
論文の概要には評価スイートを公開済みとする記述もありますが、READMEの公開予定とは一致していません。現時点で手元での再現に必要な一式が揃っているとは確認できない、というのが確認結果です。公式README・Model Usage
実装を試す際には、リポジトリの更新を確認したいですね。
まとめ：会話の途中に、行動まで入ってくる
DuplexSLAについて、仕組みと実験結果を見てきました。
要点をまとめると、次の3つです。
- ユーザー音声・AI音声・アクションを、160ミリ秒刻みの時間軸で揃える
- 相づちや割り込みを判断しながら、発話とツール呼び出しを進める
- 論文内の比較でツール呼び出しの遅延を大きく短縮。ただし精度や評価条件も見る必要がある
人間同士なら、相手の話を聞きながら返事をし、横で予定を確認したり、音楽を変えたりします。そうしたやり取りをAIでも扱うために、「いつ聞いて、いつ話し、いつ動くか」をモデルの設計に取り込んだところに、この研究の面白さを感じました。
個人的には、作業中に手を止めずに相談できるアシスタントへの応用が楽しみです。こちらが考えている間は待ってくれて、説明を聞きながら追加で頼んだことも処理してくれる。そんな相手なら、会話のしやすさはかなり変わりそうです。
この記事ではすべての学習上の工夫や具体例を取り上げられていません。興味を持った方は、論文のFigure 1〜3や、付録のチャンクごとの出力例も見てみてください。論文PDF
少しでもDuplexSLAの面白さが伝わったら嬉しいです！
参考資料
- Haoyang Zhang et al., DuplexSLA: A Full-Duplex Spoken Language Model with Synchronized Speech, Language, and Action, arXiv:2605.20755v2, 2026.
- DuplexSLA 公式リポジトリ
- DuplexSLA デモページ
※技術説明と実験表は、CC BY 4.0で公開された上記論文に基づき、日本語で要約・再構成しています。会話例と模式図は、本記事の説明用に作成したものです。論文のライセンス表示
注意事項
本記事の内容は私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。