エンジニアリング

Virmiiを作った理由:macOS固有の制約からクロスプラットフォームなブラウザ再生へ

mac-avatar-layerで直面したネイティブ環境の制約がVirmiiへつながり、ブラウザベースの再生が3D VTubingをクロスプラットフォーム化した経緯を解説します。

更新日
Virmiiを作った理由:macOS固有の制約からクロスプラットフォームなブラウザ再生へのカバー

始まり:macOSでmac-avatar-layerを作る

最初に開発したmac-avatar-layerは、macOSのネイティブなウィンドウとグラフィックス機構へ統合する、軽量なバーチャルアバターオーバーレイでした。大規模なゲームエンジンを導入せず、透明なアバターを低遅延でデスクトップへ表示することが目標でした。

mac-avatar-layerはRustを中心にしたLive2Dホストで、Cubism Coreでモデルを評価し、独自のRust/Metalレンダラーで描画します。Virmiiの3D VRMワークスペースとは、モデル形式も実装も異なります。ただし、ウィンドウ階層、透明描画、入力透過を扱った経験は、後にVirmiiの表示と操作モデルを考える土台になりました。


macOSネイティブ環境で直面した制約

実際に配布可能なデスクトップツールへ育てると、macOSのウィンドウシステム、セキュリティ、ハードウェア固有の描画層が大きな摩擦になりました。

透明で枠のないウィンドウを他のアプリより上に表示するには、NSWindowのレベル、フォーカス、クリック透過を慎重に扱う必要があります。画面キャプチャやカメラ入力には、それぞれ対応する権限が必要です。ただし、透明ウィンドウを表示すること自体が画面収録権限を必要とするわけではありません。どの機能がどの権限を使うのかを分けて説明する必要があります。

Metalに直接結び付いたレンダラーを、そのままWindowsやLinuxへ移すことはできません。署名、公証、権限説明、更新手順も、配布対象と配布方法に応じて検討する必要があります。ローカル開発での実行と一般ユーザーへの配布は、同じ手順ではありません。小規模な開発では、アバター機能の改善とプラットフォームごとの実行・配布基盤の維持に、どれだけ時間を割くかが課題になります。


クロスプラットフォームの難しさ:OSごとの分断

透明なリアルタイム描画を複数OSへ展開すると、ウィンドウ合成、入力、キャプチャの違いを扱う必要があります。共通フレームワークを使っても、OSごとの動作検証は残ります。

  • macOSでは、CocoaのNSWindowやCALayerなど、ネイティブのウィンドウ・レイヤー機構を扱います。
  • Windowsでは、Win32とDWMによるウィンドウや合成処理、ウィンドウスタイル、メッセージ処理を考慮します。
  • Linuxでは、X11とWaylandの違いに加え、コンポジターや対応プロトコルによって動作が変わります。

GPU側にはMetal、Direct3D、Vulkan、OpenGLなどの選択肢があり、利用できる構成はOSやライブラリによって異なります。特定のOSで一つのAPIしか使えないわけではありませんが、バックエンドとドライバーの組み合わせごとに検証が必要です。カメラ取得、必要な場合の音声ループバック、ウィンドウ入力、更新配布まで含めると、維持する範囲はさらに広がります。


ブラウザを共通のアバターランタイムとして考え直す

現在のブラウザでは、WebGLやWebAssemblyなどを利用してリアルタイム3D描画やカメラ入力の解析を行えます。ただし、利用できるAPIと性能はブラウザや端末によって異なります。

ブラウザ中心の構成を選んだ理由は、複数OSからアクセスできる共通のワークスペースが必要だったためです。ユーザーはVirmii専用のデスクトップアプリをインストールせず、URLからモデルを確認できます。開発側も、各OSのウィンドウ機構を一から実装する代わりにブラウザAPIを利用できます。

完全に差が消えるわけではありません。GPU、ドライバー、ブラウザのバージョンによって性能は変わり、カメラ権限も必要です。OBSで配信する場合は、OBSを別途用意して設定します。

目標は、すべての環境で同じ性能を保証することではなく、インストールや接続の手順を減らすことです。問題が起きたときに原因や制限を理解できる案内も、その設計に含まれます。


WebGL、WebGPU、WebAssemblyでリアルタイム3Dを動かす

WebGLはブラウザでGPUを使った描画を行う仕組みです。現在のVirmiiのアバタービューアーは、three.js、React Three Fiber、three-vrmを使い、VRMのメッシュ、マテリアル、ボーン、モデルが持つ表情を扱います。

WebAssemblyは、トラッキングなどの処理モジュールをWebアプリへ組み込むために利用できます。Virmiiの顔トラッキングではMediaPipe Tasks VisionとそのWASMリソースを使っています。ただし、アバターの物理計算、ボーン変換、ブレンドシェイプ計算をすべて独自のWebAssemblyエンジンで実行しているわけではありません。

WebGPUはコンピュートシェーダーなどの新しいGPU機能を提供しますが、ブラウザと端末の対応確認が必要です。現在のVirmiiのアバターレンダラーはWebGPU実装ではありません。将来検討できる技術と、すでに使っている機能は区別する必要があります。

共有バッファやWASMへの計算移行も、それだけで性能を保証するものではありません。データ転送、メモリ管理、GPU負荷、ページ内の他の処理を含めて測定する必要があります。ブラウザで動くことが、安定した60 FPSやフレーム落ちのない動作を意味するわけではありません。

ユーザーにとっては、APIの名前よりも、モデルの読み込み失敗、カメラ権限の拒否、トラッキング停止、接続状態が分かることが重要な場合もあります。自分の環境で何が使えるかを理解できるようにすることも、ランタイム設計の一部です。


Virmiiの設計:デスクトップ試作からWebワークスペースへ

mac-avatar-layerが「完成したアバターをデスクトップに表示する」ことから始まったのに対し、Virmiiはキャラクター資料からライブ出力までを一つのワークスペースとして設計しました。

主な流れは次のとおりです。

  1. 使用許可のあるキャラクター画像から3Dアバターの生成を始める
  2. 生成したモデルをブラウザで確認する
  3. 必要に応じてAI表情画像を別途生成し、目や口の反応を試す
  4. Live Studioでカメラトラッキングとモデルの反応を調整する
  5. 非公開ライブステージURLをOBSブラウザソースへ追加する
  6. 提供されるVRMをダウンロードし、他のアプリで使う前に互換性を確認する

ブラウザ側ではGLTFLoaderとVRMLoaderPluginでモデルを読み込みます。アバターの表示とアニメーションはユーザーの端末で動きますが、生成、保存、認証などのサービス機能にはバックエンドも関わります。モデルの生成段階と、完成したモデルをリアルタイムに表示する段階は別です。

OBSとの接続は、仮想カメラの映像ストリームではありません。Live Studioで計算した動作データをWebRTCデータチャネルでステージへ送り、OBSのブラウザソースがモデルを描画します。接続環境によって中継を利用する場合もありますが、この経路でカメラの生映像をOBSへ送るわけではありません。

トラッキングを操作するページと出力ページを分けることで、専用のVirmii仮想カメラドライバーなしでOBSへアバターを追加できます。使用中はトラッキングページを開いたままにし、非公開ステージURLを安全に管理する必要があります。


VTubingの技術的な入口を下げる

従来の3D VTuber制作では、モデリング、UV、テクスチャ、ウェイト、表情シェイプ、VRMメタデータ、トラッキング、OBSを別々に学ぶ必要がありました。専門的な制作を置き換えることはできませんが、最初の動くモデルへ到達するまでの距離は短くできます。

Virmiiで作成したモデルはAI表情生成に対応しています。完成モデルを開いて「表情を生成」を選ぶと、まばたき、笑顔、口の動きに使う13枚の画像を作成し、カメラトラッキングで確認できます。顔のシェイプキーがなくても、Virmiiのプレビュー、Live Studio、OBSで表情画像を表示できます。アップロードしたVRMは既存の表情バインドを使用し、ダウンロードしたVRMには生成した表情画像は含まれません。詳しくはAI表情生成ガイドをご覧ください。

モデル生成と表情機能には、クレジットやプランごとの利用条件が適用されます。開始前に現在の料金と利用枠を確認し、結果によっては追加生成や外部編集が必要になることも考慮してください。

完成したVRMをダウンロードできることは、対応する他のツールで確認や再利用をする助けになります。ただし、表情画像を含め、サービス内のすべての機能がファイルと一緒に移るわけではありません。

ブラウザ方式が減らすのはインストール手順であり、端末の計算負荷ではありません。低価格のノートPCで快適に使えるかは、モデルの複雑さ、解像度、ブラウザ、同時に実行するゲームなどに左右されます。実際の配信構成で録画し、必要に応じて設定を下げてください。初めて準備する場合は、VTuber入門ガイドも参考になります。


カメラトラッキングと音声処理を区別する

カメラ映像はセンシティブなデータです。ブラウザのMediaDevices APIを使うと、ユーザーが明示的に許可したタブ内でカメラを取得し、顔の特徴点や姿勢をローカル処理できます。

Virmiiでは、既定で生の映像をリアルタイムデータベース経由で中継しません。コントローラーは頭部回転、目、口、距離などの値を生成し、WebRTCなどを通じて非公開ステージへ送ります。OBSはステージページを描画するだけで、カメラ映像を受け取る必要がありません。

MediaDevices.getUserMedia()は、許可されたカメラやマイクのストリームを取得するAPIです。現在のVirmiiはaudio: falseでカメラ入力だけを要求します。顔トラッキングの結果でモデルの対応する表情を動かし、マイクの周波数解析や音素認識によるリップシンクは行いません。

Web AudioのAudioContext、AnalyserNode、AudioWorkletで音声反応型アバターを作ることは、別の実装上の選択肢です。解析ノードを接続するだけで正確な音素別リップシンクが完成するわけではなく、現在のVirmiiの機能として紹介すべきではありません。配信するマイク音声はOBSで別途設定します。

次はVirmiiのカメラ要求条件に合わせた最小例です。ストリームを開くコードであり、顔トラッキングやOBSとの接続まで実装するものではありません。

js
async function openTrackingCamera() {
  const stream = await navigator.mediaDevices.getUserMedia({
    audio: false,
    video: {
      facingMode: "user",
      width: { ideal: 1280 },
      height: { ideal: 720 },
      frameRate: { ideal: 30, max: 30 }
    }
  });

  return {
    stream,
    stop() {
      stream.getTracks().forEach((track) => track.stop());
    }
  };
}

実際のアプリでは、HTTPSなどの安全なコンテキスト、権限拒否、カメラの利用可否、セッション終了時のストリーム解放も扱う必要があります。要求した解像度が、そのまま端末の実際の出力になるとは限りません。


アーキテクチャ比較:ネイティブアプリとブラウザ再生

表
観点ネイティブデスクトップブラウザベース
配布OS別ビルド、パッケージ化、配布方法に応じた署名手順URLでアクセス。対応ブラウザとWeb配布の管理は必要
描画共通フレームワークも使えるが、バックエンドとドライバーごとに検証VirmiiはWebGLベース。ブラウザとGPUの差は残る
更新プラットフォームごとの更新経路を管理Webデプロイに加え、キャッシュ・互換性・サービス稼働を管理
権限OSの権限方針の下でシステムAPIや装置を使用ブラウザのサンドボックスと、カメラなどへの明示的許可
OBS連携アプリに応じたウィンドウキャプチャや専用出力Virmiiは非公開ステージをブラウザソースで表示
オフラインローカル動作を設計しやすい場合がある別途設計が必要。Virmiiのオンライン機能には接続が必要
低レベル制御特殊な装置との連携に向く場合があるブラウザが許可する範囲に限定

ネイティブアプリが不要になるわけではありません。特殊な装置との連携や細かなローカル制御が重要なら、ネイティブが適する場合があります。Virmiiではアクセス方法と設定の流れをそろえることに重きを置きました。ブラウザはその選択を支える実行環境であり、すべての制約を取り除く手段ではありません。


VirmiiとオープンなWebアバターの未来

今後の目標は、生成品質だけでなく、モデル検証、表情設定、トラッキング調整、他ツールとの相互運用を改善することです。VRMやglTFのような公開仕様を基盤にすることで、アバターを一つのサービス専用データではなく、クリエイターが持ち運べる資産として扱えます。

WebGPUなどの新しいAPIは検討できる選択肢ですが、採用による効果は実際の環境で測定する必要があります。新しいAPIだけを追うのではなく、対応していない環境で何を利用できるかを明確にすることも重要です。

macOS専用の小さなオーバーレイから始まった試作は、最終的に「どのOSでもURLからアバターを動かせるか」という問いへ変わりました。Virmiiはその答えを、オープン形式、ブラウザ処理、持ち運べるVRM、正直な機能表示を通じて作り続けています。

アニメーション、状態同期、モジュールごとの実装、技術資料を改善することは、プロジェクトの方向性です。すべてがすでに提供済みの機能という意味ではありません。セットアップの負担を減らしながら、現在の機能と制限が分かるワークスペースを目指します。


Q:mac-avatar-layerでは、なぜmacOSネイティブソフトだけでは不十分だったのですか?

A: macOS専用ツールとしての価値がなくなったわけではありません。Metalレンダラーやネイティブのウィンドウ処理を他のOSへ展開するには追加作業が必要でした。Virmiiは、より広いアクセスとモデル準備からOBS出力までの流れを目的に選んだ、別のブラウザ中心のワークスペースです。

Q:Webブラウザで3D VTuberアバターを滑らかに動かせますか?

A: ブラウザでのリアルタイム描画とカメラトラッキングは可能で、Virmiiでも利用しています。ただし、モデルの複雑さ、端末性能、ブラウザ、同時に動くアプリによって結果は変わります。固定の60 FPSや遅延のない動作は保証していません。

Q:Virmiiは従来のネイティブVTuberソフトと何が違いますか?

A: Virmii専用のデスクトップアプリではなく、Webワークスペースで生成モデルの確認、VRM管理、トラッキング、OBS用の非公開ステージを利用します。OBSへはブラウザソースURLで接続します。カメラ権限、対応ブラウザ、十分な端末性能、OBSの設定は引き続き必要です。

Q:Virmiiは低価格な機材を使う個人クリエイターにも適していますか?

A: 使用するモデルと配信構成で、まず手持ちの機材を試してください。専用アプリのインストールを避けられる利点はありますが、ブラウザでもCPUとGPUを使います。ゲーム、アバター、OBSを同時に動かし、必要に応じて出力解像度やフレームレートを調整します。