話題の日本語Full-duplex音声対話システム 「J-Moshi」のベースになっている論文を理解しようと試みる。
「J-Moshi」のベースとなっている技術論文「Moshi: a speech-text foundation model for real-time dialogue」をo1 pro modeで非エンジニアでも理解できるように、対話形式で解説してもらう。
登場人物
アキラさん（質問者）：AI や音声技術に興味があるが、専門家ではない。非エンジニア。
ナナセさん（解説者）：今回の論文『Moshi: a speech-text foundation model for real-time dialogue』をわかりやすく説明する役目。
対話形式での解説
1. モデルの背景と目的
(1) 従来の音声対話システムの問題点
アキラ「最近、音声アシスタントとか話題だけど、この論文が言うには、従来の音声対話システムに何か問題があるの？」
ナナセ「うん。たとえば Alexa や Siri などを思い浮かべてもらうと、まずユーザーが話して、その音声が自動音声認識（ASR）で文字に変換されるでしょう？ そのあとテキストのやり取りを通して大規模言語モデル（LLM）が応答を作り、最後にテキスト音声合成（TTS）で返す。こうした段階的な処理の組み合わせ（パイプライン）では、
返事までにタイムラグ が大きい（数秒かかることもある）。
会話中の 音声以外の要素（感情表現や非言語的な音など）がテキスト化ですり抜けてしまう。
ユーザーが割り込んだり、同時に話したりする フルデュープレックス（同時話者） に対処しづらい。
…といった課題が生じるんだ。」
(2) Moshi の目標
アキラ「なるほど。Moshi はそういう問題をどうやって解決しようとしているの？」
ナナセ「Moshi は、音声から音声へ直接 対話を生成できる “speech-to-speech” モデルを目指しているの。つまり途中でテキストに一旦変換して、またテキストから音声に戻す……という段階をまとめて扱おうとしているんだ。こうすると、以下のようなメリットが期待されるよ。
リアルタイム応答を可能にし、遅延を 200ms 程度 に抑えられる（自然な会話に近いスピード）
ユーザーの感情やイントネーションなど、テキストでは失われがちな非言語情報も扱える
フルデュープレックス（相手が話している最中でもこちらが話し始める）を自然にこなせる
つまり “人間っぽい” やり取りを狙った仕組みになっているわけ。」
2. モデルの大枠
(1) Helium: テキスト基盤の言語モデル
アキラ「でも最終的には、意味や文脈を理解して会話してくれるわけだよね？ そのためには、やっぱり言語モデルが必要なんだよね？」
ナナセ「そう。Moshi の核となるのは Helium という 7B パラメータ（約 70 億パラメータ）の テキスト言語モデル。これは英語の大規模データをたくさん使って学習したモデルだよ。
この Helium が論理展開や知識面を支えるから、会話として成り立つというわけ。」
(2) Mimi: 音声を離散トークンに変換するコーデック
アキラ「音声を直接扱うって、どういうふうにやるの？」
ナナセ「ここで Mimi というニューラルコーデック（音声や映像などのメディアデータをエンコード（圧縮）・デコード（伸張）するための仕組み）が登場する。音声を“離散トークン”という単位に変換する仕組みだね。たとえば、
音声から『音素（セマンティックトークン）』 + 細かい音のニュアンス（アコースティックトークン） をまとめて符号化
従来の音声圧縮と 言語情報（何をしゃべっているか）を併せ持つ設計
こうすることで、大量の音声データを扱いながらも、モデルが音声を“トークン列”として予測・生成できるようになるわけ。」
(3) 本体: Moshi
アキラ「Moshi 本体は何をしてくれる？」
ナナセ「大ざっぱに言うと、
Helium（テキスト言語モデル）の“賢さ”をベースにしつつ、
Mimi（オーディオコーデック）で音声を直接理解・生成する。
『Inner Monologue』（後で話すけど）という仕組みで、Moshi 自身がどんなことを話すかテキストとして考えつつ、そのまま音声を生成。
ユーザー音声と Moshi 音声を 並列（マルチストリーム） でモデル化して、同時発話や割り込みを扱える。
だから 1 つのモデル で リアルタイム音声対話 を全部こなせるように狙っているんだ。」
3. キーテクニック
(1) Multi-stream（2 つの音声ストリームを同時に扱う）
アキラ「どうやって『同時にしゃべってる状態』を扱うんだろう？」
ナナセ「ユーザーの音声ストリームと、Moshi 自身の音声ストリームを区別して、同時に処理 するんだ。たとえばユーザーが割り込むように発話しても、Moshi はそのユーザー側のトークン列を解析しつつ、自分の音声を生成する。
従来みたいに『ユーザー→モデル応答→ユーザー→モデル応答…』とターンを区切らない設計だね。」
(2) Inner Monologue（テキストと音声を一緒に予測）
アキラ「Inner Monologue っていうのは？」
ナナセ「これは Moshi の発話を、一度テキストとしても同時に予測する 仕組み。普通の“音声だけ”のモデルだと、正確に何を言おうとしているかがブレることがある。でも、
“Moshi はこのタイミングでこういうテキストを話す”
というテキストトークンを先に生成して、それに沿って音声トークンを作ると、言葉遣いがブレにくくなる。さらにテキストがあることで、途中で ASR や TTS として出力することも可能 になる、という利点もあるんだ。」
4. 性能と評価
(1) レイテンシ（応答の速さ）
アキラ「リアルタイムって、どのくらいの遅延なの？」
ナナセ「この論文では、理論上 160ms、実際は 200ms 程度 の遅延って言ってる。人間同士の会話の平均応答が 230ms 前後という研究もあって、かなり自然な速さだね。」
(2) 質問応答や会話品質
アキラ「モデルとしての賢さとか、きちんと答えられるかはどう？」
ナナセ「テキストモデル Helium がベースにあるから、会話の事実性や文脈把握力は強め。論文でも、英語の質問応答ベンチマークで 既存の音声モデルよりも高い正解率 が報告されてる。
ただし、テキスト専用の超大規模モデルよりは少し劣る場面もあるみたい。そこは学習データやモデル容量が影響してる、と。」
(3) 安全性・トラブル対策
アキラ「じゃあ不適切発話や著作物の“音声まるごとコピー”みたいなことは？」
ナナセ「論文終盤で、毒性（トキシシティ）検出 や 著作権音声のコピペ防止、勝手にユーザーの声を真似しない などへの配慮も議論されてる。
データの重複を減らす
ユーザーとモデルの声を混同しない
将来的にはウォーターマークなど技術検討も…
とか、そういった方向で工夫されてるようだよ。」
5. まとめと今後の展望
アキラ「なるほど。すごいね、音声のやり取りが自然になると、まるで本当に人と話してるみたいだね。」
ナナセ「そうだね。今回の論文『Moshi』の主なポイントは、
音声から音声への対話 ができる基盤モデル
リアルタイム応答（遅延は 160〜200ms）
複数ストリーム（同時話者）対応で、人間同士の自然な会話に近づく
Inner Monologue により、音声生成が正確かつ統一感ある発話に
安全性（毒性、無断コピーなど）にも配慮
といった感じかな。」
アキラ「ありがとう！ 非エンジニアの僕でもわりとイメージつかめたよ。」
ナナセ「よかった。論文は GitHub でも関連リポジトリが公開されているから、より詳細を見たい場合はチェックしてみるといいかもね。」
付記
本論文は arXiv:2410.00037v2 に公開されており、ライセンスは CC BY-NC-SA 4.0。
デモやソースコードは著者らの GitHub（Kyutai）で公開されている。