WebアプリがそのままVSTプラグインになる画期的技術

2026年6月1日から3日にかけて、東京・秋葉原UDXで開催された「ADC Japan 2026」。このシリーズでもすでにいくつかのセッションをレポートしてきましたが、今回ご紹介するのは、Escentier, LLCの余湖雄一（よごゆういち）さんによる「One UI, One DSP, Everywhere. ― A Chromium-Based Runtime for Audio Plugins」というセッションです。

一言でいうと「ブラウザで作ったWebアプリを、そのままVSTプラグインとして動かしてしまう」という話なのですが、これがただの力技ではなく、Chromiumのプロセス分離やWeb Audio APIの仕組みをうまく利用した、かなり理にかなった設計になっているのが面白いところです。このセッションは余湖さんによる流暢な英語でプレゼンテーションが行われ、スライドもすべて英語。難しい技術の話も多く出てきますが、まずは「何が実現できているのか」だけでも知っていただければと思います。

ADC Japan 2026、余湖雄一さん（Escentier, LLC）によるセッション「One UI, One DSP, Everywhere.」が行われた

東京藝術大学出身、8年間のWeb武者修行
プラグイン開発を阻む2つの壁
SuaraはElectronの、音楽プラグイン版
「音がどこに行くか」を変えるだけ、というトリック
プラグインが1つ落ちても、DAWは無事
UIだけでなくDSPもホットリロード、そしてAIによるライブコーディング
unworklet ― 「音のためのTypeGPU」
「1つのDSPが、どこでも動く」という未来像

東京藝術大学出身、8年間のWeb武者修行

余湖さんはもともと東京藝術大学でクラシック作曲を学んだ音楽家であり、サウンドデザインでもエンジニアリングでもない道を歩んでいました。そこから8年ほどWebエンジニアとしてフロントエンド・バックエンドの双方を経験し、その傍らでWeb Audio APIを使った音作りを続けていたそうです。「音楽もわかるし、Webもわかる。でもC++やVSTのSDKはわからない」という自己紹介から始まったこのセッションは、まさにその立ち位置だからこそ見えたアイデアがベースになっています。

ブラウザでVSTプラグインを作るユニークな手法を発表した余湖さん

去年のVueFesでは「Building Audio Apps with JavaScript ― A tour of every way to make sound on the web」という講演をしていたそうで、その内容を振り返りながら、Webで音を鳴らす2つの方法（<audio>要素とWeb Audio API）や、Web Audio API内部の構成（built-in nodes、AudioWorklet、そしてWASMやWebGPUを使った実験）について、まず整理していました。

プラグイン開発を阻む2つの壁

余湖さんがプラグインを作ろうとしたときにぶつかったのが、2つの壁でした。

1つ目は「C++をちゃんとは知らない」という壁。ここは近年JUCE＋AIの組み合わせでかなり解消できるようになったものの、それだけでは全部の問題が消えるわけではない、といいます。

2つ目、そしてより深刻だったのが「ビルドループの重さ」でした。UIを変えても、DSPを変えても、そのたびにリビルドとDAWの再起動が必要になり、開発のイテレーションがまったく回らない。この体験は、プラグイン開発をしたことがある方なら共感できるところではないでしょうか。

対照的にWebの世界では、編集→ビルド・型チェック・テスト→音を聴く、というループが数秒で回ります。しかもこのループはCI上でも同じように回せるため、AIが自律的に検証・修正することもできる、というのが、後半のライブコーディングデモにつながる重要な伏線になっていました。

SuaraはElectronの、音楽プラグイン版

そこで登場するのが、今回のメインテーマである「Suara」というフレームワークです。ロゴは帆船のマークで、「Run any web page as a real audio plugin.」というキャッチコピーがついています。

余湖さんいわく、Suaraは基本的にElectronと同じ仕組みで、任意のWebページをVSTプラグイン（今のところ対応はVSTのみ）にできる、というものです。

Suaraのチャプタータイトルスライド。「Run any web page as a real audio plugin.」

会場では実際にCubase上でSuaraの動作をデモしていました。SuaraSynthというVSTiプラグインの中に「SuaraWebPortal」というWeb Viewが組み込まれており、URL欄に直接アドレスを打ち込むと、Googleのトップページなど任意のWebサイトがプラグイン内にそのまま表示される様子や、波形（saw/square/sine/triangle）とカットオフ・レゾナンス・ADSRを備えたシンプルなシンセのUIをそのままVSTとして操作するデモが披露されていました。

「音がどこに行くか」を変えるだけ、というトリック

技術的な核心は非常にシンプルで、「Web Audio APIのAudioContextの出力先を、通常のスピーカーではなくDAWに向ける」という発想にあります。

「Where does the sound go?」通常のWebページなら音はスピーカーへ、SuaraならDAWへ流れる、というトリックの説明スライド。

具体的には、DAWプロセス（VST3ホスト＋Suara.vst3）と、Chromiumのレンダラープロセス（別プロセスとして動くAudioWorklet）の間を、Chromium内部で使われている同期ソケット「mojo」経由でやり取りする構成になっています。DAW側のprocess()が1ブロック分の音を要求すると、その呼び出し境界を越えてChromium側のWeb AudioグラフとAudioWorkletが処理を行い、生成されたPCMデータは共有メモリ経由でDAW側に戻ってくる、という流れです。

DAWプロセスとChromiumレンダラーの間を1オーディオブロックが往復する仕組み。mojo経由の同期呼び出しと共有メモリでデータをやり取りしている。

気になるレイテンシーですが、256サンプル・48kHzのオーディオブロック（5.33ミリ秒）の中で、この往復にかかる時間はおよそ85マイクロ秒（p99.9）。ヘッドルームにして約98%が残っている計算で、55万回のコールバックでドロップは0件だったとのことです。2つの独立したOSプロセスを介していながら、この余裕で処理時間内に収まっている、というのは驚くべき数字でした。

往復レイテンシーは約85マイクロ秒。5.33ミリ秒のオーディオブロックの中では、わずかな割合に収まっている。

そして面白いのが、この仕組みが「1つのコードベースを、Cubase上ではVST3プラグインとして、ブラウザ上ではただのWebページとして、実行時に判定して動かす」という点です。フォークもポーティングも不要で、同じJavaScriptがそのまま両方の環境で動きます。

プラグインが1つ落ちても、DAWは無事

もう1つ、Suaraの利点として強調されていたのが「クラッシュの隔離」です。ネイティブのプラグインがクラッシュすると、ホストであるDAW全体が巻き込まれて落ちてしまう ― これは多くの方が経験したことのある悪夢だと思います。

「One bad plugin, and the whole DAW is gone.」ネイティブプラグインのクラッシュがDAW全体を巻き込んでしまう様子（Cubase 12のクラッシュ画面）。

Suaraのアーキテクチャでは、プラグインのインスタンスごとにChromiumのプロセスが立ち上がる構成になっているため、JS＋WASMで書かれたDSPが動くレンダラープロセスがクラッシュしても、それは1つの独立したOSプロセスの話にとどまり、DAW本体や他のプラグインは無事に動き続けます。

会場では実際に、動作中のプラグインの各プロセス（renderer・utility・gpuなど）を意図的にkillするデモを行い、Cubaseは生きたまま、クラッシュさせたプラグインの音だけが止まる様子を実演していました。

プロセスを意図的にクラッシュさせるデモ用ツール。「CUBASEを選ぶとDAWごと落ちる」が、SingleMotionGranularの各プロセスをkillしてもCubase本体は無事、という対比を見せていました。

UIだけでなくDSPもホットリロード、そしてAIによるライブコーディング

Suaraのもう1つの「良いところ」として挙げられていたのが、UIだけでなくDSPそのものも、プラグインを再コンパイルすることなくその場で変更・反映できる「ホットリロード」です。

このデモとして披露されていたのが、AIによるライブコーディングでした。会場の画面には実際にClaude Code（Opus 4.8）のターミナルが映し出され、「please turn this app into a simple FM synth using web audio API (with Audio Worklet)」というプロンプトを入力し、Claudeにその場でFMシンセへの改造を任せる様子が実演されていました。Claudeが手を動かしている間も余湖さんはプレゼンテーションを続け、完了すると同時にUIとDSPの両方がホットスワップされて、その場で音が変わる ― という、なかなか大胆なデモです。

Claude Code（Opus 4.8）に「Web Audio APIとAudio Workletを使ったシンプルなFMシンセに改造して」と指示している場面。ライブコーディングの様子。

unworklet ― 「音のためのTypeGPU」

後半で紹介されたのが、もう1つのプロジェクト「unworklet」です。JavaScriptにはガベージコレクション（GC）があるため、リアルタイム性が求められるDSP処理には向かない、という「もっともな反論」に対する答えとして位置付けられています。

C++のオーディオ開発者なら誰もが思う、もっともな反論。

参照点として挙げられていたのが、Software Mansionが開発している「TypeGPU」という型安全なWebGPUツールキットです。型付きのTypeScriptでGPUの計算を記述すると、WGSLが生成されてGPU上で実行される、というものですが、unworkletはこれの音声版にあたります。TypeGPUが「typed TS → WGSL → GPU」であるのに対し、unworkletは「typed TS → WASM → オーディオスレッド」という対応関係になっています。

TypeGPUとunworkletの対応関係を示すスライド。

ポイントは、TypeScriptのコードが実行されるのはビルド時だけで、オーディオスレッド上で動くのはあらかじめコンパイルされたWASMだけ、という点です。つまり実行時にJavaScriptのGCが走ることは構造的にありえず、「realtime-safe by construction」ということになります。

unworkletで書いたソフトクリップ・ディストーションのコード例（distortion.uwk.ts）。見た目はほぼ普通のTypeScriptですが、コンパイルするとリアルタイム安全なWASM AudioWorkletになります。

生のAudioWorkletでWASMを手作業で配線しようとすると、リニアメモリのオフセット計算やバイト⇔float変換を手で行う必要があり、ちょっとしたミスが無音やクラッシュにつながります。unworkletではその配線が不要で、out.ch(0)[i] = process(input.ch(0)[i])のような書き方だけで済みます。MIDIの扱いも同様で、生のpostMessageによる手動パースではサンプル精度のタイミングが失われがちなところを、unworkletは型付きかつサンプル精度を保ったまま扱えるとのことです。

WASMの手動配線（左）とunworklet（右）の比較。バイト⇔float変換などの面倒な処理がunworkletでは不要になります。

テスト面では、@unworklet/offlineのrenderOffline()を使うことで、実際に出荷するのとまったく同じWASMを、Node・Bun・Denoといった環境上で決定論的・ビット精度でPCMにレンダリングできる、という仕組みも用意されています。

なお、unworkletは講演時点ではまだ一般公開されておらず、AIエージェントが正しいAPIでコードを書けるよう「npx unworklet initでバージョンの一致したDSLリファレンスを参照させる」という、AIが書くこと前提の設計になっている点も紹介されていました。

「Built for your AI to write.」AIエージェントが正しいAPIを使えるよう設計されているunworklet。講演時点ではまだ未公開とのことです。

「1つのDSPが、どこでも動く」という未来像

セッションの締めくくりでは、「One DSP, Everywhere」というビジョンが語られていました。WASMという実行形式である以上、原理的にはブラウザの外、たとえばNode.jsや、さらにはマイコン上でも同じコードを動かせる可能性がある、という話です。

「A programmable guitar pedal.」同じ.uwk.tsのコードをマイコン向けにコンパイルすれば、TypeScriptで書いたDSPがストンプボックス上で動く、という将来像。「まだ作られてはいない」との注記付きです。

余湖さん自身、「自分で全部書きたいわけではないからこそ、最初からAIに近いところから始めた」と語っており、Web技術・AI・音楽制作という3つの領域が交差する場所に立っている開発者ならではの視点が、Suaraとunworkletという2つのプロジェクトに一貫して表れているセッションでした。

質疑応答では、Chromiumの組み込み方法（ソースコードの改変規模が約150GBに及ぶこと）や、JavaScriptの一般的な挙動とアーキテクチャ固有の問題の切り分け、実際の開発ワークフロー（フロントエンド開発→suara buildでVST3を出力→macOSでは公証も必要）についての質問が挙がるなど、参加者の多くが、興味津々という感じで非常に注目度の高いセッションとなっていました。

【関連情報】
ADC Japan 2026サイト