音声対話AIを安く作りたい！

今回はこちらのアドベントカレンダーに参加させていただきます！！！
初心者園児ニアですがよろしくお願いいたします。

注意
この記事は思想と全体の設計と細かい技術選定を盛り込んだ結果そこそこ長文になっております。

忙しい人のための要約

• 対話エージェント作成はPipecatが個人的に書きやすいよ
• STTはローカルで動かすには微妙に要求スペックが高いのでDeepgramとか使おう
• LLMはコスパの観点ならgeminiが無難
• TTSはCPU推論ならStyle-Bert-VITS2、富豪ならElevenLabsがおすすめ

以上です、暇な人は以下もお読みください。

自己紹介

あかつき

その辺の学生です。データサイエンス寄りのMLとかAIエージェント構築とかVCモデル構築とか色々やってます。
メインの活動は未踏アドバンスト事業とかです。

• 所属大学: 名古屋工業大学 学部2年
• 所属団体: C0de NxTEND STECH etc...
• 趣味: お絵描き🎨 カラオケ🎤 etc...
• Twitter(宗教): あかつき

AI系ならなんでもやってるのでご用があればTwitter(思想)のDMにでも連絡ください、面白そうならなんでもやります。

動機

このアドベントカレンダーを見ているということはおそらくみなさんAI VTuberやら音声対話AIやらAIアシスタントやらを作った事があるでしょう!

私も例に漏れずAI VTuberを作った事があるわけですが、

↑my AI VTuber作品。当時なんもわからないままフルスクラッチしてるので完成度はお察しですが、気になればご覧ください。


今回はこれ本体ではなく、これに派生したお話をしたいと思います。鶴舞こあらもそのうち動かします。他の業務とかこあらの改修作業が早く終われば、この記事が出る頃にはもう配信復帰してるかもしれません。


配信でコメントを拾って配信で発話する、世に出すという意味ではこれだけでも良いが、もう一捻り個人開発としては欲しいところ。
ですので、折角だしリアルタイムの音声対話にチャレンジしてみたい！
ということで作ります。

ですが、学生という身分である以上、金がありません、本当に金がありません。API使用料金に使うお金も殆ど無いし何ならGPUも自前で持ち合わせていません。

金さえあればElevenLabsで欲しい声質ガチャしてAPI立ててpay as you goで回しまくるとかいう頭の悪い構成もできるのですが、、、

今回は、限界まで金は削って、かつリアルタイムの応答システムとして実用的なラインを攻めて作ろう！というのが今回の記事の動機と趣旨です。

注意その1
完全無料構成ではありません、実用性を求めた結果普通にLLMのAPI使用料などでお金を貢いでいます。

注意その2
ライセンスなどに関する情報は本記事では触れませんので、実際に技術選定を行うときには注意してください。

正直なところ文字起こしあたりのレイテンシを求めるなら、どうしても外部サービスを頼らざるを得ないところがあります。GPUが自前であればもっと楽はできたとは思いますが、

学生にそんな金はありません。手元の処理は全てCPUです。

動作環境

• Mac
  • チップ: Apple M3 pro
  • メモリ: 18GB
• 使用言語
  • Python(私の使用したパッケージマネージャはuvですが、お好きなものを)

一般的なPCスペックですね！これなら再現性がありそうです。

基本的な対話エージェント設計の話

1. End-to-End or カスケード

対話エージェント設計において、まず全体の構成に関わる選択肢があります。

End-to-End(一つのSpeech to Speechモデルで対話させる構成)か、カスケード(文字起こしと応答生成と応答音声の生成までをそれぞれのモデルで行う構成)かの二択ですね。

End-to-Endは、最近のモデルは結構ChatGPTのrealtime apiなどレイテンシ的にはユーザーの発話が終わってからおおよそ2秒前後で応答が返ることもあるし、何より実装がとても楽です。

が、End-to-Endは基本的にAPI料金が比較的高いです。少なくとも今回採用できるほどではないので却下。

また、応答速度の面は悪くないのですが、実際に使ってみると応答内容の調整がプロンプトエンジニアリングだけでは厳しく、自分の思った対話設計を辿ってくれないという問題点もあるため、人格に則った対話AIを作りたい場合期待するほど良い対話エージェントは作れません。
使いたければあと1,2年待ちましょう。その頃にはAPI料金が安くてもっと自分で改造しやすいモデルが出てくる気がします。

カスケードモデルに関しては、STT(文字起こし), LLM(応答内容生成)は流石にGPUがないと自前で動かしても実用に耐えるレイテンシが出せないため、外部APIを使うことになると思います。TTS(音声生成)は、死ぬほど声質や抑揚にこだわらないのであればCPU推論で実はいけます。問題は開発コストが高いことくらいですね。

結果的に応答の質と料金両方の面でカスケードモデルに軍配が上がりそうです。


それぞれの概念についてちゃんと知りたければ以下の記事を参照ください。

もっと詳しく原点を当たりたい人はこちら(ちゃっぴー談)、
上: カスケードモデル
下: End-to-End

2. フレームワーク使う？使うとしたら何使う？

次に、エージェントを作る上で議論点となるのはフレームワークの選定かと思われます。料金には関わらないが、開発体験がかなり左右されます。

主な選択肢は、

• langchain
• Mastra
• LiveKit
• Pipecat
• 使わない

あたり。

選定方法

正直に言うとこれは設計思想によりけりです！！！！

個人的には、

• 推論部分を意識して書きたいのであればlangchain
• 開発効率を求めるなら(TypeScriptで書きたいのであれば)Mastra
• エージェントのワーカーの管理部分もうまくwrapして欲しいならLiveKit
• カスケードモデルのnodeを簡単で綺麗に管理したいなら、Pipecat

というイメージです。

そもそもフレームワークを使う以上、どれもある程度の抽象化がされるため、それが気に入らないならフレームワークを捨てましょう。それも一つの選択だね！


私はPipecatをよく採用してます。VAD(voice activity detection)と一緒にエージェントの状態機械を乗せて、それにターン管理とかの状態遷移を全て乗せるべきという自分の対話AIの設計思想に一番合致していて書きやすいです。異論は認めます。

余談: Pipecatの布教

まず、カスケードモデルの音声対話AIを作る場合の構成は以下の通りですよね？

この時に、Pipecatの良さは二つあって、

一つ目に、音声対話をする上でのモデルの群をprocessorのnodeとして個別で管理して、それを全体を一括で管理するためのpipelineを定義して書くという芸当が簡単にできることがとても嬉しい。

設計例としては以下の通り。

app/
  pipeline/
    base_pipeline.py        # トランスポート/STT/LLM/TTS をつなぐ素のパイプライン定義
    processors/
      vad_turn.py           # VAD + ターンテイク state machine
      latency_metrics.py    # レイテンシ計測・ロギング
  flows/
    core_agent_flow.py      # メインの会話フロー(Nodeグラフ)
    tools_flow.py           # ツール呼び出し専用のサブフロー
  nodes/
    stt_openai.py           # STTノード（ベンダーごとにファイルを分ける想定）
    stt_deepgram.py
    llm_planner.py
    llm_react.py
    tts_kokoro.py

なんとなく責務が分割しやすそうだなーみたいに感じてくれたら良いです。


二つ目に、turn takingという今ユーザーとエージェントどちらが喋るターンかといったことを管理して、それに基づいて考えた内容を発話するかどうかを制限するといったことが対話AIを作る上での基本なのだが、このturn takingを行うための処理をどこに書くかというのが明確でないとかなりコードがごちゃつきます。

そこで、VAD(voice activity detection)という今ユーザーが話しているか？という状態を取れるnodeを定義して、それを基準にエージェントの状態機械を管理し、話すかどうかを判断させる。これによって話すか否かの判断を行う処理がそれ以外のSTT以降の処理に余計な処理が介入しない設計を取る事ができます。

とても良いですよ、使いましょう。

ただ、VADや対話設計をこだわって複雑にしすぎるとNode間の関係が煩雑になってPipecatの良さを消しとばすことになっていくので、いっそのことフレームワーク捨てた方がうまくいく場合もあります。作りたいものに応じてここは変えていきましょうね。

...そうならないように設計を最初から考えろ？おっしゃるとおりです...

STT(speech to text)のモデル選定

閑話休題、ここからは具体的な内部のモデルの話に入っていきます。
STTというか本来ASR(Automatic Speech Recognition)なのですが、認識部分の話を深めるとVADやらturn takingやらで長くなるのでSTTのみここでは触れます。

STTのモデルに関しては、まずローカルで動かすの？とか外部サービスならどんなモデルを使うの？レイテンシはどの程度まで許容？とかが考慮する点かと思います。

まず前提として、streamingモデルを選ぶことを前提としましょう。
streamingモデルとは、入ってくる音声を短い時間単位ごとに区切って、小さい時間で音声をテキスト化するモデルです。


なぜstreamingが必要かというと、本来発話のブロックに対して文字起こしであるSTTを噛ませて、その後にLLM,TTSと繋げると、

このように、STTの処理時間が発話の後に発生して、その後にLLMなどを処理するという状態になります。当たり前ですね、直前の層の情報がなければ処理はできませんから。


これがstreamingだと、少し話が変わります。
streamingの場合、組み込んだ時の挙動は、まず短い時間で音声をとって、ユーザーが喋っている最中に同時に直前の文字起こしをして、またさっき喋っていた内容の文字起こしをして〜〜〜を繰り返すというものです。
これを先ほどの図に起こすと、

のようにSTTの処理時間を実質的に無効化されることがわかると思います。streamingモデルの有無で合計の処理時間が大幅に変わるわけですね。


したがって、モデル選定に関してですが、streamingモデルのSTTなら正直なんでも良いです。
一応、意外とSTTはある程度の精度を求めようとすると要求スペックがGPU前提だったりするのでGPU難民は大人しく外部サービスを使いましょう。


一番のおすすめはDeepgramです。安い割に精度が高い上、streamingモデルが安定してます。
もっと安いサービスで探す場合はAssemblyAIになると思います。安いですが、個人的にはstreaming APIの精度が若干足りないかなという感じ。
無課金を貫いてローカルで頑張るなら多分VoskとかWhisper系列のfaster-whisperあたりを使うと良いと思います。GPUが存在するならもうちょっと重い処理のものも視野に入ります。

外部サービスなどを吟味する上で、ベンチマークは参考程度にすることをお勧めします。日本語のSTTとして使う場合に精度が入れ替わる場合もあるので、実際に使ってみて判断しましょう。

LLMのモデル選定

音声対話AIの頭脳にあたる部分です。勿論推論とか色々して、話題とかをどっかから引っ張ってきて、それをうまく応答内容に反映して欲しいな〜と思うでしょう。


まずはこの設計をやめるところから始めましょう。


最優先で必要なのは応答速度、次にコンテキストウィンドウです。

というのも、音声対話AIは応答速度をいかに早くできるかに全ての努力を割くべきで、検索とか推論とかは非同期で外装したら良いです。直列で繋げようとするとその分LLMの層で使う時間が増えていって、応答するまでに10秒のようになる可能性もあります。

逆にそれさえ守れば、特に問題となる点は少なく、選択肢もかなりあります。

無料でLLM部分を抑えたいならローカルならGPU前提でgpt-oss-20b、API使うならGeminiの無料枠。
有料でも良いならChatGPTでもGeminiでもClaudeでもGrokでも何でも使えば良いと思います。API使用料金が異常に安いのはGeminiなので、Gemini 2.5 Flash-Liteとかが無難です。

注意
Geminiの無料枠を使用する場合は、レート制限に注意しましょう。特に、RPM(1分あたりのリクエスト数)が厳しいので429エラーが出たら大人しくGeminiにお金を払うことをお勧めします。クレジットが貰える場合もあります。

余談: それでも俺はエージェントに検索とか載せたい

リアルタイム応答に対して、検索や単純に推論などを持たせたいという気持ちはわかります。その場合のちょっとしてtipsを余談として書こうと思います。
基本的にはリアルタイムの返答自体を考える部分にこのような処理時間が長くなるものを載せるのは体験をかえって悪化させることになります。

そこで、リアルタイム会話を監視するエージェントを別で立てましょう。
本来やりたかった推論などなどを非同期で行って、リアルタイム会話を行うLLMに対してpromptを差し替える等で内容を反映させることで、擬似的にいろんなことを調べるエージェントができます。

問題点は、「今日の天気は？」みたいな質問に対してダイレクトで答えられない点です。そこは質問回答の場合には別のルートに移行するなどしていい感じに対応してください。それか処理時間増加前提で、検索機能などを持たせる。応答の自由度とレイテンシはトレードオフなので自分の理想的な対話設計を探しましょう。

TTS(text to speech)のモデル選定

対話AIにおいて、一番こだわるべきポイントは勿論TTSですよね？他のアドカレの記事を見てる感じ結構声とアイデンティティにこだわりを持つ人が多いイメージでしたので、そのうちの一つとして技術選定もかなり吟味したいところ。

主には処理時間、声質、感情もしくは抑揚表現あたりが考慮する点かと思います。

まず、一番のおすすめとしてはStyle-Bert-VITS2です。説明不要ですね。
感情表現が配布されているモデルで比較的強いのと、fine tuning等で声質やそれこそ感情表現自体もかなり調整できるところが魅力です。それに踏まえてCPU推論も割と実用的です。正直採用しない理由がないですね。
もし対話AIをサービスとして展開するという場合には適さないかもしれません。

本当に声に対してこだわらない、処理時間を短くしたいという場合はVOICEVOXを使うのが無難です。早いし安定してます。その代わり声質とか感情表現が比較的犠牲になるので試験的に使うといった場合には良いかもしれません。

ここからは有料でも良いorそこそこ良いGPUを持っている場合です。
選択肢がかなり広がりますが、個人的に声質という点ではElevenLabs、アニメ調の感情表現の強さで言えば、Tsukasaが結構お気に入りです。Tsukasaはzero shotで声質を参照音源に寄せられるのも良い点です。手元のGPUではちょっと処理時間が長いなという場合は蒸留してでも使う価値はありそうだなーと思ってます。

具体的な実装やfine tuningのような深くまでTTSを語るならもっと書くべき点はあるのですが、逆に選択肢を狭めそうなのでここで止めておきます。

おわりに

音声対話AIは本当に正解がないので手探りになると思います。
今回は触れませんでしたが、どのタイミングが相手の喋っているターンでどのタイミングが自分の喋るべきターンなのかの切り替えや、発話の終点の判断、TTSへ渡すテキストの最適化など、細かな点をこだわらないとそもそも対話として成り立ちません。

AI VTuberのようなテキストがinputである場合と異なる難しい点が多い分野ではありますが、お手元のAIキャラクターと対話するためのインターフェースを作ってみてはいかがでしょうか？
その際に１学生エンジニアとしての意見がお役に立てば幸いです。