日本語で自然に話せるAI対話を、ローカルOSSで作ってみた

こんにちは。AI研究開発室のK.S.（女性）です。

AIとの対話サービスがどんどん増え、日本語でも自然に会話できる体験が身近になってきました。特に、ChatGPTのように驚くほど人間らしく応答してくれる存在が当たり前になりつつあります。
一方で、個人情報の扱いとコストを意識しながら、どこまでローカル中心のOSS（Open Source Software）構成でこの体験に近づけるのかは、まだ十分に試す余地があります。ということで、今回は「話す・聞く」を低遅延で回す日本語向けリアルタイム対話システムを作ってみました。

ちなみに、せっかくのAI時代なので、今回のブログは画像やテキストの一部はAIブログライター君にも手伝ってもらいました。

1. 何を作ったのか

ひとことで言うと、「話す・聞く」を低遅延で回す、日本語向けリアルタイム対話システムです。
マイク入力から音声認識、言語生成、音声合成までをつなぎ、会話として破綻しないように制御を入れています。

なぜクラウドAPIではなくローカルOSSなのか

1. 個人情報管理
   音声には名前や予定など機微情報が自然に含まれます。ローカル完結に寄せることで、外部送信範囲を最小化できます。
2. コストの予測可能性
   会話系は利用量が伸びやすく、従量課金が読みにくくなりがちです。ローカル推論中心なら運用コストを見積もりやすくなります。
3. 透明性と改善速度
   OSSであれば挙動が見えるので、問題が起きた時に自分で修正しやすいです。実運用での改善サイクルが速く回せます。

目指した体験（自然さ・速さ）

日本語の対話の自然さ

ただ文字起こしして返答するだけだと不自然になります。
発話の終端判定、ターン制御、応答タイミングを丁寧に扱うことで、会話らしさが大きく改善しました。

応答はすぐ返る

体感品質に一番効くのは、最初の返答までの速さです。
処理全体をストリーミング前提にして、「待たされる感じ」を減らす構成にしました。

デモ: 実際の会話の様子

それでは、実際にどのような体験なのかを見ていきましょう。

ChatGPTのアプリで体感ベースラインとして確認してみます。

本当に、自然に会話していますね。では、今回作ったローカルOSS構成のデモも見てみましょう。なお、このデモでは LLM として gemma-2-9b-it-4bit を使っています。

いかがでしょうか。動画を通して、ローカルOSS構成でもある程度自然な会話体験が実現できていることが伝わると思います。

一方で、試していると、モデルによっては私のたどたどしい日本語の認識が不安定になり、会話が混乱する場面もありました。それでも、ローカルOSS構成でも実用に近い対話体験を作れる可能性は見えてきており、まだ改善の余地があると感じています。

2. システムの全体像

今回の全体設計は、役割をかなり素直に分けたパイプライン型です。

一般的な音声対話システムの基本形

まず、一般的な音声対話システムの基本形から見ていきましょう。下の図のとおり、ユーザーの音声を音声認識（ASR: Automatic Speech Recognition）でテキストに変換し、そのテキストを大規模言語モデル（LLM: Large Language Model）が解釈して返答文を生成し、最後に音声合成（TTS: Text to Speech）で再び音声へ戻します。つまり、音声対話の中心は ASR → LLM → TTS の3段構成です。

この図の見方としては、左から順に「音声を文字にする」「文字から返答内容を考える」「返答内容を音声に戻す」と捉えるとシンプルです。まずこの3段を主軸に考えると、どこで遅延が出るのか、どこで品質が落ちるのかを整理しやすくなります。

ただし、この基本形をそのまま作るだけでは、実際の会話体験はうまくいきません。理由は大きく2つあって、1つはスピードです。無音や環境音まで含めて ASR に渡したり、再生音の回り込みで認識が乱れたりすると、そのぶん無駄な処理が増えて応答が遅くなります。もう1つは品質の安定性で、スピーカーから出た AI 音声を再び AI が拾ってしまうと、文字起こしも応答内容も崩れやすくなります。

今回のシステムの全体像

そこで今回の設計では、ASR の前段に音響エコーキャンセル（AEC: Acoustic Echo Cancellation）と音声区間検出（VAD: Voice Activity Detection）を置きました。つまり、全体としては AEC / VAD → ASR → LLM → TTS という形です。AEC はスピーカーから出た AI 音声がマイクへ回り込み、ASR がそれをユーザー発話だと誤認するのを防ぐために入れています。一方の VAD は、ユーザーが実際に話している区間だけを切り出し、無音や環境音までまとめて ASR に渡さないためのものです。要するに、AEC は「余計な音を消す」ため、VAD は「必要な区間だけを拾う」ために置いています。この2つを ASR の前に入れるだけで、認識の安定性と全体の応答テンポがかなり改善します。

加えて、AEC の中には DTD（double-talk detector）も入っています。これは「AI の再生音が入っている最中に、今マイクに入っているのがユーザーの声なのか、ただの回り込みなのか」を見分けるための補助で、ユーザー発話中にエコー学習が暴走しないようにする役割があります。

図の読み方: 青線は主な音声/対話データの流れ、破線は制御・メタデータの流れを表します。

1. マイク入力
2. AECでスピーカー再生音の回り込みを抑える
3. VADでユーザー発話の開始と終了を切り出す
4. SenseVoiceで文字起こしする
5. Gemma系モデルにテキスト応答を生成させる
6. Supertonicで音声化して再生する

この構成の狙いは、各段の責務をはっきり分けることです。SenseVoiceが音声をテキストにし、Gemma系モデルが返答内容を作り、Supertonicがそれを音声に戻すという主線を、AECとVADが支える形です。また、これらの技術選定にはスピード面の理由もあります。SenseVoiceは短い発話を素早く次段へ渡しやすく、Gemma系モデルはローカル運用しながら速度と会話品質のバランスを取りやすく、Supertonicは短い単位で音声を返しやすいため、全体として待ち時間を抑えやすい構成にしています。1つの巨大な仕組みに全部を任せるより、どこが遅いのか、どこで誤るのかを切り分けやすく、それぞれの技術を切り替えたり改善したりしやすいのがこの構成の利点です。

この構成で使っている主な技術と選定理由

ここでは、実際に使っているスタックを中心に、その良い点と弱い点、比較対象も含めて整理します。

• VAD: 発話区間の切り出しにはSilero VADを使っています。良い点は、軽くて扱いやすく、リアルタイム用途でも十分な速度が出ることです。音声対話では、ASRそのものの精度より先に「どこからどこまでを認識に渡すか」で体感がかなり変わるので、まずは安定したVADを置くのが効きます。弱い点は、長めの間や相づちのような曖昧な発話境界に弱いことです。比較対象としてはVAPのような予測型ターン検出もありますが、今回は構成を複雑にしすぎないことを優先して、まずはVADベースにしています。
• AEC: エコーキャンセルにはPBFDAF（Partitioned Block Frequency-Domain Adaptive Filter）系のAECを入れています。PBFDAFは、ブロック単位でエコーを打ち消していく適応フィルタ系の手法です。さらに内部では DTD（double-talk detector）も使っていて、ユーザーが話している最中はエコー学習を止め、ユーザーの声を誤ってエコーとして学習しないようにしています。良い点は、スピーカー再生音がマイクに回り込んで、AIの声をAI自身が再認識する事故を減らせることです。スピーカー運用ではかなり重要で、これがないとASRの評価自体が難しくなります。弱い点は、デバイスや音量、部屋の響きの影響を受けやすく、チューニング項目が増えることです。比較対象としてはWebRTC（Web Real-Time Communication）のAEC系が定番ですが、Pythonからの扱いやすさや現在の構成との噛み合わせを優先して、今回は今の実装を採っています。
• ASR: 音声認識にはSenseVoiceを使っています。良い点は、日本語を含む会話音声をローカルで軽く回しやすく、短い発話を素早く文字へ落としやすいことです。リアルタイム対話では、長文の完全な書き起こしよりも、短い発話を速く次段に渡せることのほうが価値があります。弱い点は、Whisper系ほど選択肢や周辺エコシステムが広くないこと、ベンチ結果や導入事例の蓄積が比較的少ないことです。比較対象としては mlx-whisper や Whisper large-v3 turbo があり、そちらは汎用性や安心感が強い一方で、今回の用途ではSenseVoiceの軽さと応答速度を優先しました。
• LLM: 会話の中身は、Gemma 2とGemma 4の両方を試しています。Gemma 2は応答が速く、テンポを重視したい場面で扱いやすい一方、Gemma 4はそのぶん会話品質が高く、返答の自然さや安定感を出しやすい印象でした。用途に応じて、速度を優先するならGemma 2、品質を優先するならGemma 4、という使い分けがしやすいのも利点です。特に、モデルファイルの差し替えや管理をLM Studioに寄せると、実験中の運用がかなり楽になります。弱い点は、より大きいモデルほどメモリと初動負荷が重くなりやすいこと、会話の安定性はプロンプト設計にも大きく依存することです。比較対象としてはQwen系があり、Qwenは商用条件の明快さや多用途性が強みです。一方で今回は、Gemma系の会話品質と手元環境での扱いやすさを優先しました。
• TTS: 音声合成にはSupertonicを使っています。良い点は、日本語音声としての聞きやすさが高く、短いチャンクで出力しやすいのでリアルタイム会話に向いていることです。応答全文を待たずにしゃべり始められるので、待たされる感じを減らせます。弱い点は、TTSは声質の好みが強く、運用環境によっては別の声のほうが自然に感じることがある点です。比較対象としてはKokoro-JPやVOICEVOX系があり、軽さや導入しやすさでは魅力がありますが、今回は全体の遅延と自然さのバランスでSupertonicを選びました。

3. まとめ

今回は、ローカル環境での再現性を重視しながら、高品質なリアルタイム会話体験の実現を目指しました。ある程度の遅延や誤認識は許容しつつも、全体として自然な会話体験を提供することを目標にしました。

結果として、現時点でも一定程度は使えるものの、まだ完璧とは言えません。個人的には、いくつか課題が残っていると感じています。

主な課題は、日本語会話における自然さの向上、応答速度の改善、そしてローカル環境での再現性の確保です。まだ詰め切れていない部分があり、もう少し強化したいと感じています。会話のテンポや受け答えの自然さという点でも、ChatGPTの完成度にはまだ届いていません。

技術選定そのものに加えて、それぞれの技術をどう組み合わせるかが重要であり、組み合わせ次第でまだ大きく改善できる可能性が見えてきています。

最後に

グループ研究開発本部 AI研究開発室では、データサイエンティスト/機械学習エンジニアを募集しています。 ビッグデータの解析業務などAI研究開発室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。 皆さんのご応募をお待ちしています。 一緒に勉強しながら楽しく働きたい方のご応募をお待ちしています。