Phenomer

オンプレミス環境をターゲットとし、「リアルタイム音声認識からテキスト処理、音声合成までを一括で行えるサービス基盤」と、 そのサービス基盤を応用した「AIエージェント音声対話サービス」、「3Dキャラクターライブ配信サービス」を開発するプロジェクトです。 # 背景と目的 AI技術の多くは有償・従量課金のクラウドサービスに強く依存しており、教育・研究環境に取り入れるには予算・契約面で難があります。また、地方公共団体で用いられているLGWANのような閉じたネットワーク内では、利用できる外部サービスが厳しく制限されている点が大きな障壁となります。加えて、既存サービスを利用するだけでは、AIサービス基盤の運用ノウハウが得られないといった問題もあります。 そこで、オンプレミス環境において、リアルタイム音声認識からテキスト処理、音声合成までを一括で行えるサービス基盤と、サービス基盤の具体的な利用例として、Webブラウザで動作するAIエージェント対話サービス、3Dキャラクターライブ配信サービスを開発することにしました。 # 規模感 基本は教員個人としてのプロジェクトです。そのため、技術調査、概念検証から、ハードウェア・ネットワーク準備、バックエンド・フロントエンド・テスト用CLIツールの設計と実装、3Dキャラクターモデリングなどすべてを自身で行い、その上で庁内プロジェクトや研究・教育への応用、技術イベントへの出展・発表を行ってきました。 また、学年担任などをはじめとした定常業務を行いながらのプロジェクト遂行が求められています。 # バックエンド(sincromisor-server)の開発 バックエンドでは、クライアント(Webブラウザなど)から受け取った音声を処理し、返答の音声やキャラクター表現に用いるデータなどを生成します。これらは次のようなサービス群により構成されています。 * 音声ブローカー: クライアントとの音声通信、各サービスとの音声フレームやテキストデータの仲介 * WebRTC(aiortc)、WebSocketを利用 * 音声抽出サービス: 音声ブローカーから受け取った音声データから、人間の音声を抽出 * FastAPI、MediaPipeのAudio Classification Taskを利用 * 音声認識サービス: 抽出した音声から、音声認識結果のテキストを生成 * FastAPI、Nue-ASRを利用 * テキスト処理サービス: 対話ログと音声認識結果テキストから、応答となるテキストを生成 * FastAPI、Dify、Weaviate、Ollama、Sentence Transformersを利用 * 推論モデル: elyza/Llama-3-ELYZA-JP-8B-GGUF * Embeddingモデル: cl-nagoya/ruri-large * Rerankモデル: cl-nagoya/ruri-reranker-large * 音声合成サービス: 応答テキストから音声とリップシンク用の発話データを生成 * FastAPI、VOICEVOX engine、Redisを利用 * リバースプロキシ・ロードバランサー: ユーザーからのリクエストの振り分け * Caddy、Consulを利用 * サービスディスカバリー: 各サービスの稼働状況の監視・管理 * Consulを利用 基本的なフローは「クライアント → 音声ブローカー → 音声抽出 → 音声認識 → テキスト処理 → 音声合成 → 音声ブローカー → クライアント」 となっています。 実装コストやレイテンシ、デバッグやテストの難易度、変更・応用し易さなどを考慮し、WebRTCのセッションごとに実行される音声ブローカープロセスが、クライアントや各ワーカーとの仲介役となる構成としました。フロントエンドと音声ブローカー間はWebRTC、音声ブローカーと各サービスワーカー間はWebSocketによって通信を行います。WebRTC上では、MediaStreamで音声データ、DataChannelで会話ログとテロップ、リップシンク用発話データなどをやり取りします。 【リソースに関する課題と対応】 最も大きな課題として、予算の限界に伴うサーバーリソースの制限の厳しさが挙げられます。共用GPUサーバー2台(VRAM合計24GB)で全てを賄わなければならず、ユーザー数の増加などを考慮すると、分散処理を前提とした設計にする必要がありました。加えて、運用を考慮すると、学生が容易にデプロイできるようにしなければなりません。 分散処理とデプロイの課題は、Docker ComposeとAnsible、Consulを用い、可能な限り設定とデプロイ作業を簡略化する手法を取り入れて解決しました。Docker Composeではサービスコンテナ群のホスティング 、Ansibleではホスト環境のデプロイ、Consulは先述の通りサービスディスカバリーを担当しています。 VRAM不足に対しては、一定の精度を保ちつつVRAMに収まるモデルの選定や、モデルの量子化による節約を行うなどといった対策を行い、サービス全体で16GB以内に収まるようにしています。また、サーバーが正常に稼働しているか、サーバーリソースがどの程度利用されているかを監視するため、Zabbixを併せて導入しています。 【円滑な対話の実現に関する課題と対応】 サービスの中身としては、対話の円滑さの担保が大きな課題となりました。対話の円滑さには、次のような多くの要素が絡み合い、単純な実装では円滑な対話は困難です。 * クライアント(Webブラウザ) - サーバー間の通信 * 音声抽出・音声認識のレスポンスタイムと精度 * テキスト処理のレスポンスタイムと精度 * 音声合成のレスポンスタイムと精度 本プロジェクトでは、WebRTCによる音声対話、対話の先読みや生成されるテキストの調整、音声合成結果のRedisによるキャッシュ、リアルタイムテロップの表示などを取り入れ、可能な限り円滑な対話が実現できるようなサービスを実現しています。 【音声認識の課題と対応】 イベント会場などの複数の人の声が入り混じる場所では、意図しない声を拾ってしまい、無意味な対話が行われてしまうことが課題となりました。 これに対し、音声のフィルタリングやマイクなどのノイズキャンセリング機能の活用、クライアント側の顔認識と連動した対話処理といった対策を行っています。ただ、残念ながらまだ不完全であり、今後の改良が必要となっています。 現時点では、Nue-ASRからReazonSpeechのNemo v2の移行を進めています。 【対話内容に関する課題と対応】 素のローカルLLMでは、対話内容の品質に限界があり、サービスの用途に合った対話が実現できません。 また、この問題に対して行われる検索拡張生成(RAG)は、テキストマイニングツールやベクトルデータベース、推論モデル、Embeddingモデル、Rerankモデルなどのコンポーネントを組み合わせて実現する必要があり、複雑になりがちです。 そこで、用途に合った対話を容易に実現できるよう、DifyとWeaviate、Ollama、Sentence Transformersを組み合わせた日本語テキストのRAGが行えるテキスト処理サービスを実装しました。 日本語テキストのRAGでは、トークナイザーの都合により、[ローカルで利用できるText EmbeddingやRerankのAPIサーバー](https://github.com/Phenomer/fake-openai-server)を別途実装する必要がありました。 RAGを取り入れた際の実用例として「山形県に詳しいAIエージェント」を他プロジェクトに提供しています。今後は、相槌や表情の変化といったものを実装し、対話の雰囲気を作る手法も取り入れていきたいと考えています。 # フロントエンド(sincromisor-client)の開発 フロントエンドでは、AIエージェントとなる3Dキャラクターとの対話インタフェースを提供します。 主な動作環境は、PCやスマートフォンのWebブラウザ、Raspberry Pi 5のWebブラウザ(デジタルサイネージ用途)、 Looking GlassやMeta QuestなどのXRデバイス、OBS Studioなどの組み込みブラウザ(ブラウザソース)などを想定しています。 フロントエンドには、キャラクターによる表現のほか、対話履歴，発話中音声のテロップなどを実装しました。 これらは主に次の要素で構成されています。 * サーバーとの音声通信 * WebRTC(MediaStream)を利用 * サーバーからの対話ログの取得: 対話ログの描画 * WebRTC(DataChannel)を利用 * サーバーからの発話データ取得: テロップの描画、顔の表情 * WebRTC(DataChannel)を利用 * 3Dキャラクターの描画: 身体モーション、顔の表情 * Babylon.js -> Three.js、VRM-1.0を利用 * 顔認識: キャラクターの身体モーション、音声通話のON/OFFに利用 * MediaPipe Face Detectorタスクを利用 開発環境としてViteとTypeScriptを用いています。Reactなどを用いることも検討したものの、フロントエンド開発は将来的に学生も行う見込みであったことから学習コストの高さが課題となり、現在はプレーンなTypeScriptで開発を進めています。 【3DCGライブラリの課題と対応】 3DCGライブラリとして、機能の豊富さ、別プロジェクトの資源の流用などから、当初はBabylon.jsを用いていました。しかしながら、キャラクターモデルのVRM-1.0サポートを検討した際、Babylon.js用VRM Loaderライブラリの開発が停滞していることが判明したため、Three.jsに移行することにしました。 【3Dキャラクターモデルの用意】 当初は自身でBlenderにて1から制作したモデルを使用して進めていましたが、モデル制作を簡略化してバリエーションを豊富にしたい、また、モデルの差し替えを容易にしたいと考え、VRM-1.0形式のモデルをVRoid Studioで制作し組み込む形に切り替えました。これにより、サービス応用の可能性が大きく広がりました。 【口の動き(リップシンク)の実現】 口の動きは、バックエンドの音声ブローカーが、VOICEVOXの音声合成クエリに含まれる発話データを、返答音声の送信タイミングに合わせてDataChannel経由でフロントエンド側に送信、受け取ったフロントエンド側でMorphTargetを制御するすることで実現しています。これにより、発話と完全に一致したリップシンクが実現できました。 【Chromium Embedded Framework(CEF、OBS Studioのブラウザソースなど)での動作】 OBS Studioなどで用いられているCEFでは、機能制限によりWeb Speech APIのSpeechRecognitionなどが利用できないといった課題がありました。当初、音声認識・合成についてはWeb Speech APIを用いて実装する予定でいたものの、この制約により、音声認識・合成についても独自に実装したほうがよいとの結論に至りました。この決断が、外部サービスに依存しない、オンプレミス環境でのサービス提供を実現するきっかけになりました。 # CLIツール(sincromisor-cli)の開発 CLIツールでは、WebRTCを経由した音声認識・音声対話をヘッドレスで行えるしくみを提供します。 これを実装したことにより、ブラウザ側の実装状況に影響されずに動作テストが行え、テストの自動化・不具合の切り分けも容易になりました。 # 成果の発表・応用 開発したサービスは、[オープンソースカンファレンス](https://event.ospn.jp/osc2025-spring/)や[Kernel/VM探検隊](https://kernelvm.connpass.com/)などのイベントで発表・展示しています。 学生の卒業研究への応用として、4人の学生で構成されたプロジェクトベースの卒業研究に本サービスを取り入れ、主に検索拡張生成(RAG)に関する検証を行いました。 また、後述する県の「XRビジネス創出事業」のプロトタイプ開発においても応用しています。 # 関連リンク 開発した基盤とサービスのソースコードは、OSSとしてGitHubに公開しています。 また、イベントでの発表・展示に用いている資料も公開しています。 * [GitHub - Sincromisor](https://github.com/Phenomer/Sincromisor) * [Sincromisorに関する資料](https://www.negix.org/docs/sincromisor) * [オープンソースカンファレンス(2025春)出展記録](https://hachu.net/blog/2025/02/23/osc-tokyo.html) * [Sincromisor 動作サンプル](https://sincromisor.negix.org/simple-vrm/)