音声AIエージェントを常駐させるシステムを設計・運用している方に向けた内容です。ローカルLLM（自分の端末やサーバー上で動かす大規模言語モデル）やTTS（テキスト読み上げ）パイプラインを組んだあと、「答えは正確なのに画面には波形しか出ない」という手触りの物足りなさに直面した経験がある方の参考になれば幸いです。
ARPA Hellenic Logical Systemsが公開しているAVATARは、VRM（3Dアバターの標準ファイル形式）キャラクターをデスクトップに常駐させ、音声に合わせてリップシンク（口の動きを音声に同期させる処理）とモーションを付ける、オープンソースのElectronアプリです。v0.7.0では、モーション制御まわりに手が入りました。単なる見た目の話ではなく、既存の音声パイプラインに追加コンポーネントを1つ挿す形の構成なので、アーキテクチャとして何が増えるのかを整理する価値があります。
AVATARが担う役割とシステム構成
AVATARはElectron（デスクトップアプリをWeb技術で作るフレームワーク）製の、常に最前面に表示される透過オーバーレイとして動きます。Windows向けの配布が主です。
描画にはThree.js（ブラウザ・Electron上で3Dを扱うJavaScriptライブラリ）を使い、キャラクターの見た目・モーションはVRMおよびVRMA（VRM用のモーションデータ形式）という業界標準フォーマットに準拠しています。ここが設計判断として地味に重要です。独自フォーマットを採用せず、VRoid（3Dアバター制作エコシステム）が普及させた標準に乗ることで、キャラクター資産の差し替えやコミュニティ製アセットの流用がしやすくなっています。
音声入力は、システム出力・特定アプリのウィンドウ音・マイク・音声ファイルのいずれからでも取り込める設計です。つまりAVATAR自体は音声を「生成」しません。既存のTTSやOllama（ローカルLLMを手軽に動かすランタイム）のような下流の出力を「拾って表示に変換する」レイヤーとして機能します。
設定はConfig.yaml（プレーンテキストの設定ファイル）で管理され、Settings→Directoriesから自分の.vrmファイルや環境フォルダを指定できます。VRoid Hub連携はオプションで、利用する場合のみOAuth（外部サービス認証の標準プロトコル）でキャラクターを読み込みます。
v0.7.0の変更点を段階的に見る
バージョン0.7.0の主眼は新機能の追加というより、モーション制御の一本化です。3点に分けて見ていきます。
1点目は、Directoriesから独自の.vrmaクリップフォルダを直接参照できるようになったことです。これによりモーションアセットの管理場所を自分のファイルシステム側に寄せられます。
2点目は、stageコマンドという検証済みのレイヤーが、再生・設定系のパスを一元的に持つようになった点です。これまで複数の経路から呼ばれていたトリガー処理が、1つの共通インターフェースを通るようになったと理解できます。ソフトウェア設計でいう「単一責任の集約」に近い整理です。
3点目は、Settings→Motionに新設されたMotion Deckです。ジェスチャーをショートリスト化し、キーバインドで1回だけ発火させられます。既存のAnimations選択（ループ中のモーション）を横取りしない設計になっており、配信中に設定画面を開かずに済むという運用上の配慮がされています。
環境選択のサムネイルもGIFからポスター画像に軽量化され、配布用ビルドではデフォルトでtrial custom/メディアをインストーラーから除外するようになりました。これは配布サイズとビルド構成の管理という、地味だが継続運用では効いてくる変更です。
類似アーキテクチャとの比較で見る設計判断
AI音声に「顔」を与える取り組み自体は新しくありません。VTuber向けのVSeeFaceやLive2D系ツール、クラウド型のアバターSaaSなど選択肢は複数あります。AVATARの立ち位置を整理すると、判断軸は次のようになります。
| 観点 | AVATAR（ローカル完結型） | クラウド型アバターSaaS |
|---|---|---|
| 音声データの経路 | ローカル完結が可能 | 外部APIに送信が前提のことが多い |
| ライセンス | MIT（改変・商用利用が容易） | サービスごとの利用規約に依存 |
| 拡張性 | ソースコード改変・自前ビルドが可能 | 提供機能の範囲に限定されやすい |
| 依存の重さ | Electron・Three.js・VRM標準のみ | ベンダー固有SDKへの依存 |
この比較から見えてくるのは、非機能要件でいう「可用性」と「データ主権」のトレードオフです。クラウド型は運用の手離れが良い一方、音声データが外部に渡る経路が生まれます。社内向けの音声アシスタントや、機密性のある会議の要約読み上げのような用途では、この経路の有無が採用可否を左右する場面もあり得ます。
AVATARがローカル完結を選んだ設計は、性能面のレイテンシ（音声からアバター反応までの遅延）にも影響します。ネットワーク往復がない分、理論上は反応の遅延要因が減ります。ただしこれは実測値が公開されているわけではないため、自分の環境で iotop や Task Manager のGPU使用率を見ながら確認する余地があります。
今日確認できること
導入を検討する場合、まず確認すべきはOSと動作方式です。AVATARは現状Windows向けのElectron配布が中心で、Node.js環境があればソースからも動かせます。
git clone https://github.com/ARPAHLS/avatar.git
cd avatar/avatar
npm install
npm run desktopコントリビューター向けにはブラウザ上のUIサンドボックスも用意されています。ただしシステムループバック（PC内部の音声出力を直接キャプチャする機能）とオーバーレイ表示はElectron版のみの対応です。
npm run devこのコマンドで http://localhost:5173 にアクセスすると、VRMの見た目調整だけをブラウザで試せます。
運用前の判断ポイントとしては、次の3点を確認しておくと導入後の手戻りを減らせます。
- 音声パイプラインのどこにAVATARを挟むか（TTS出力の直後か、システム出力全体を拾うか）
- VRMアセットの権利関係（社内利用なら商用可のモデルか、VRoid Hub経由でも問題ないか）
- インストーラー配布時に
trial custom/の除外設定が意図通りかどうか
ライセンスはMITなので、社内ツールへの組み込みや改変も比較的自由に検討できます。研究利用の際はリポジトリの CITATION.cff に沿った引用が案内されています。
まとめ
AVATARは、既存の音声・LLMパイプラインに「表示レイヤー」を1枚追加する、比較的薄い構成のコンポーネントです。VRM/VRMAという標準に乗ることで、特定ベンダーへの依存を避けつつキャラクター資産の差し替えを容易にしている点が設計上の特徴です。
v0.7.0で入ったstageコマンドの一元化とMotion Deckは、機能追加というより「トリガー経路の技術的負債を整理した」変更として読むと理解しやすくなります。
導入を検討するなら、まずソースからのビルドで自分の音声パイプラインとの相性を試し、そのうえでデータ経路とアセットライセンスを確認する、という順番が無理のない進め方です。