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

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

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

ネイティブAPIへ直接接続する方法は、1台のMac上では効率的です。ウィンドウ階層、透明描画、入力透過を細かく制御でき、ローカルアプリの上にリアルタイムアバターを配置できました。この経験が、後にVirmiiの表示と操作モデルを考える土台になりました。

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

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

透明で枠のないウィンドウを他のアプリより上に表示するには、NSWindowのレベル、フォーカス、クリック透過を慎重に扱う必要があります。画面キャプチャやカメラにはシステム権限が必要で、OS更新後に再許可が必要になる場合もあります。

描画をMetalへ直接結び付けると性能は得られますが、WindowsやLinuxへ移植するには別のバックエンドが必要です。さらに、一般ユーザーへ配布するにはコード署名、公証、権限説明、バイナリ更新の仕組みが必要でした。小規模チームにとって、アバター機能そのものより配布基盤の維持へ多くの時間を使う構造になります。

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

透明なリアルタイム描画を複数OSへ展開すると、それぞれ専用の実装が必要です。

• Cocoa（macOS）： NSWindow、CALayer、Metalを中心に透明ウィンドウを構築します。
• Win32 / DWM（Windows）： WS_EX_LAYERED、DWM合成、HWNDメッセージループを扱います。
• X11 / Wayland（Linux）： X11の旧来のウィンドウ属性と、セキュリティを重視してグローバル操作を制限するWaylandの設計差があります。

GPU側も、macOSはMetal、WindowsはDirect3D、LinuxはVulkanやOpenGLとドライバー差異を抱えます。カメラ取得、音声ループバック、ウィンドウ入力、更新配布までOS別に維持すると、機能改善よりプラットフォーム固有の不具合調査が中心になります。

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

現在のブラウザは、単なる文書閲覧ソフトではありません。WebGL、WebGPU、WebAssembly、MediaDevices、WebRTCを備え、リアルタイム3Dアバターを動かせる共通ランタイムになっています。

ブラウザへ移行する最大の理由は、Windows、macOS、Linuxの差を標準化されたAPIの下へ隠せることでした。ユーザーはネイティブインストーラーや管理者権限を必要とせず、URLを開くだけで同じワークスペースへ入れます。

完全に差が消えるわけではありません。GPUやブラウザ実装によって性能は変わり、カメラ権限も必要です。それでも、OSごとにウィンドウと描画基盤を作り直すより、機能とユーザー体験へ集中できる範囲が大きくなります。

性能を維持するため、アセットのストリーミングと計算処理も分離します。行列計算、ボーン階層、ブレンドシェイプ更新を標準化されたブラウザAPIへ移すことで、利用者に複雑なセットアップを求めず、異なるハードウェア上でリアルタイム再生を行えます。

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

WebGLは広い互換性を持ち、three.jsなどのライブラリを通じてVRMのメッシュ、マテリアル、ボーン、表情を描画できます。WebGPUはより新しいGPU制御を提供しますが、対応状況を考慮し、現時点では段階的に採用する必要があります。

WebAssemblyは、画像処理、数値計算、トラッキングなど、JavaScriptだけでは負荷が高い処理をブラウザへ持ち込む手段です。行列乗算、顔のモーフターゲット補間、ボーン階層の変換といった高頻度の処理をWebAssemblyへ移すと、JavaScriptのガベージコレクションによる予測しにくい停止を避けやすくなります。

計算済みの頂点と法線は共有バッファを介して描画コンテキストへ渡せます。WebGLは標準シェーダーによって幅広いブラウザ互換性を提供し、WebGPUは対応端末でコンピュートシェーダーと低オーバーヘッドのコマンド処理を利用できます。これらを組み合わせると、モデルの読み込み、アニメーション、カメラ解析、ライブ通信を一つのページ内で実行できます。

重要なのは、技術を使うこと自体ではなく、モデルの読み込み失敗、GPU不足、権限拒否、通信切断をユーザーへ理解できる形で伝えることです。Virmiiでは静的プレビューや頭部のみのトラッキングなど、機能を段階的に落とすフォールバックを重視しています。

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

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

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

1. 使用許可のあるキャラクター画像をアップロードする
2. AI支援でベース3Dモデルと人型リグを生成する
3. モデルを標準化し、顔機能を検証してVRMを構築する
4. ブラウザで3Dプレビューとカメラトラッキングを試す
5. 非公開ライブステージをOBSブラウザソースへ接続する
6. VRMをダウンロードし、対応ツールでも利用する

ブラウザ側では、glTFとVRMのバイナリをクライアントメモリ内で解析し、ブレンドシェイプ、ボーン階層、マテリアルシェーダーを取り出します。描画とアニメーションをクライアントで実行することで、サーバー側に3D描画基盤を用意せず、高いフレームレートを維持できます。

生成、ストレージ、認証、リアルタイム状態はサーバー側で管理し、生のカメラ映像は既定でブラウザ内処理します。ライブステージへ送るのは、アバターを動かすためのトラッキング値です。WebRTCやHTML5 Canvasを使った出力をOBSのブラウザソースへ渡すことで、ネイティブの表示レイヤーや仮想カメラドライバーに依存せず、macOS、Windows、Linuxで同じ構成を利用できます。

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

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

Virmiiはすべての生成結果が同じ品質だとは扱いません。顔トポロジーと表情が検証できたモデルはフル顔トラッキングとして扱い、それ以外は安定した頭部・身体トラッキングへフォールバックします。この区別は、誇張した期待よりも実際に使える出力を優先するためです。

完成したVRMをダウンロード可能にすることも重要です。クリエイターは一つのWebサービスへ閉じ込められず、Blenderや他のVRM対応ツールで確認、修正、再利用できます。

トラッキングと音声をブラウザ内で扱う

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

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

MediaDevices APIのnavigator.mediaDevices.getUserMedia()を使うと、許可されたカメラとマイクのストリームを取得できます。映像フレームはWebGLまたはWebAssembly上の軽量なモデルで処理し、3D顔メッシュ座標、頭部姿勢、まばたき、頬、顎などに対応する正規化済みブレンドシェイプ値を取り出せます。この処理では、映像を端末外へ送らずにアバターを動かせます。

音声については、Web Audio APIのAudioContext、AnalyserNode、必要に応じてAudioWorkletを利用できます。周波数データをリアルタイムにFFT解析し、音量やフォルマントの傾向から口形を更新すれば、カメラが遮られた場合や無効な場合でも低遅延の音声連動を実装できます。ただし、OS全体の音声ループバックはプラットフォーム制約が強いため、Virmiiはまずカメラ駆動のアバターとOBS連携を明確な境界として扱っています。

次は、ブラウザでカメラとマイクを取得し、音声解析ノードを準備する最小例です。

async function initializeBrowserTracking() {
  const stream = await navigator.mediaDevices.getUserMedia({
    video: { width: 1280, height: 720, frameRate: 30 },
    audio: true
  });
  const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
  const sourceNode = audioCtx.createMediaStreamSource(stream);
  const analyserNode = audioCtx.createAnalyser();
  analyserNode.fftSize = 512;
  sourceNode.connect(analyserNode);
  return { stream, audioCtx, analyserNode };
}

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

ネイティブアプリが不要になるわけではありません。最高性能、オフライン運用、特殊なハードウェア連携にはネイティブが適しています。一方、インストールの少なさ、共有のしやすさ、複数OS対応が重要な場合、ブラウザは強い選択肢です。

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

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

ブラウザ側ではWebGPU、WebCodecs、WASM、リアルタイム通信の進化により、より高品質な描画と低遅延処理が可能になります。ただし、新しいAPIだけを追うのではなく、対応していない環境でも何が利用できるかを明確にし、段階的なフォールバックを維持することが重要です。

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

今後はリアルタイムのブレンドシェイプアニメーション、クラウド同期、交換可能なクライアント実装をさらに改善します。アーキテクチャ資料と実用的なコード例も公開し、3D制作の導入を現代のWebアプリケーションの公開と同じくらい扱いやすいものにすることを目指します。

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

A： 最初の描画パイプラインがMetal、NSWindow、システムの画面キャプチャ権限など、macOS固有の仕組みに強く結び付いていたためです。WindowsやLinuxへ展開するには描画、ウィンドウ、権限、配布の仕組みを作り直す必要がありました。ブラウザへ移行することで、WebGLやWebAssemblyを通じて同じ実装を複数OSで利用できます。

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

A： はい。現代のブラウザは、WebGL、WebGPU、WebAssemblyを使って3D描画、ボーン変換、表情更新、顔トラッキングをクライアントメモリ内で実行できます。モデルの複雑さと端末性能に合わせて品質を調整する必要はありますが、低遅延のリアルタイム再生が可能です。

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

A： VirmiiはWebブラウザ内で動作し、専用インストーラー、複雑なドライバー設定、OS別のデスクトップ依存関係を必要としません。アバター生成、VRM管理、トラッキング、OBS用ライブステージを同じWebワークスペースから利用できます。

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

A： はい。WebAssemblyとWebGLを利用して標準的なブラウザ内で処理するため、高性能なワークステーションGPUがなくても開始できます。端末性能が限られる場合は、描画品質、解像度、トラッキング機能を段階的に調整できます。