株式会社ブートストラップ
株式会社ブートストラップ（本社：東京都、代表取締役：川田 寛）は、次世代のメディア転送プロトコル MoQ（Media over QUIC） を用いた双方向ライブ接続を、2026年9月1日に東京・初台のイベントスペース「KAIWAI 初台」で開催されたVTuber・詩音ガトさんのファンミーティングにて本番運用しました。VTuberのリアルイベントにおけるMoQの商用利用は、日本国内で初の事例となります※。 本機能は、当社が提供するバーチャルタレント向けイベント支援サービス「AIAI」に実装されています。
MoQは、IETF（Internet Engineering Task Force）で標準化作業が進む新しいメディア転送プロトコルです。タレントの自宅から会場へは4K解像度の映像と音声を低遅延で送り、会場からタレントの自宅へは来場者の声と会場の様子を返します。バーチャルと現実の境界を狭め、タレントとファンが同じ空間にいるかのように言葉を交わせる環境を実現しました。
さらにこの方式は、タレント側の準備を大きく変えます。従来は、高解像度を確保するためにモデルデータを会場側にダウンロードさせ、現地でレンダリングする必要がありましたが、MoQでは映像をそのまま送れるため、OBS StudioやVTube Studioなど、VTuberが普段の配信で使っている環境をそのまま利用できます。日頃YouTubeで配信しているタレントであれば、特別な準備なしにリアルイベントへ出演できます。モデルデータがタレントの手元から出ないため、モデルの管理・権利保護の面でも利点があります。
※ VTuber・バーチャルタレントのリアルイベントにおけるMoQ（Media over QUIC）の商用利用として。2026年9月時点。
実施の概要
「AIAI」は、バーチャルタレントがリアルの場でファンと交流するためのイベント運営を、企画から当日の技術オペレーションまで一貫して支援するサービスです。今回、その配信基盤にMoQを採用しました。
タレントの自宅スタジオからイベント会場へは、4K解像度の映像と音声を低遅延で伝送可能。会場からタレントの自宅へは、来場者の声や会場の様子をリアルタイムで返します。この双方向の接続によって、タレントと来場者は同じ空間にいるかのように会話を交わすことができます。
- 開催日：2026年9月1日（月）
- 会場：KAIWAI 初台（東京都渋谷区初台）
- 出演：詩音ガト さん
- 規模：小規模ファンミーティング
- 技術提供・運営：株式会社ブートストラップ「AIAI」
従来手法との違い――「普段の配信環境が、そのまま使える」
これまで、解像度の高いVTuberの映像を会場へ届ける方法は、限られていました。一般的だったのは、タレントの3Dモデルデータを会場側のPCにダウンロードしておき、当日はモーションなどの制御データだけを送って、会場側でリアルタイムにレンダリングするという方式です。
高解像度の映像を低遅延で伝送する手段がなかったため、「映像を送らない」という解決策がとられてきた、と言い換えることもできます。制御データであれば軽く、遅延も抑えられます。品質を確保するための、合理的な回避策でした。
ただし、この方式には制約が伴います。
- 会場側にレンダリング用のPCと、それを扱えるオペレーターが必要になる
- タレントが普段の配信で使っている環境を、そのまま持ち込むことができない
- タレントの3Dモデルデータそのものを、会場側にダウンロードさせなければならない
MoQは、この前提そのものを変えます。4K解像度の映像を低遅延で伝送できるため、回避策をとる必要がなくなり、**映像を映像のまま会場へ届けられます。**タレントは、いつものYouTube配信とまったく同じように、OBS Studio や VTube Studio といった使い慣れたツールで画面を作り、その出力を送るだけで済みます。
（なお、映像として送るという発想自体は、RTMPやWHIPでも可能です。それらではなくMoQを選んだ理由は後述します）
これは、VTuberがこれまで積み上げてきた技術資産を、そのまま活かせるということです。日頃使っている演出、テロップ、BGM、画面構成――それらを会場向けに作り直す必要はありません。普段YouTubeで配信しているタレントであれば、特別な準備なしにリアルイベントへ出演できます。
モデルデータが、タレントの手元から出ない
この方式には、もうひとつ重要な意味があります。
VTuberにとって3Dモデルは、単なるデータではありません。タレントの姿そのものであり、多くの場合、制作者との契約のもとで利用範囲が定められた資産でもあります。従来の方式では、レンダリングを会場側で行う以上、イベントのたびにそのモデルデータを会場側へダウンロードさせる必要がありました。会場が増えれば、預け先も増えていきます。
MoQを用いた今回の方式では、**モデルデータはタレントの手元から一歩も出ません。**会場側のPCにモデルデータを事前に配置する工程は一切なく、会場へ送られるのは、レンダリングされた後の映像だけです。
これは、モデルの管理と権利保護の観点で大きな利点です。データの取り扱いをめぐる会場ごとの取り決めが不要になり、タレントや権利者は、自分の姿がどこに置かれているかを気にせずにイベントへ臨めます。バーチャルタレントのリアルイベントを、より多くの会場へ、より気軽に広げていくうえで、この点は欠かせない条件だと考えています。
会話が成立すること――ひとつの経路に、二つの異なる要求
今回の取り組みでもうひとつ重要なのは、タレントの自宅と会場との間で、会話が成立しているという点です。会場の来場者が話しかければ、間を置かずに返事が返ってきます。
離れた二地点を双方向でつなぐ、という部分だけを見れば、これは従来WebRTCが担ってきた領域です。当社もこれまでWebRTCを用いてきました。
MoQは何のために作られたのか
ここで、MoQというプロトコルがそもそも何を解こうとして生まれたのかに触れておきます。
メディア転送プロトコルの世界は、長らく分断されていました。RTMPやHLS、DASHといったTCPベースのプロトコルは、単純で大規模な配信に強い一方、輻輳の検知と応答が遅く、低遅延の用途には向きません。逆にRTPやWebRTC、SRTといったUDPベースのプロトコルは低遅延を実現できますが、断片化・輻輳制御・再送・受信側フィードバック・再構成といった処理をメディアプロトコル自身が引き受けることになり、実装が複雑になって相互運用性を損なう、という代償を伴います。
結果として、事業者は用途ごとに別々のスタックを抱え、それぞれに別の専門知識を必要としてきました。MoQは、この分断そのものを解消するために設計されています。QUICの上にメディアを載せることで、単純さを保ちながら輻輳へ素早く応答する。そして重要なのは、遅延と品質のトレードオフを、プロトコルではなくアプリケーション側で選べるようにするという設計思想です。送り手は届けたい体験に合わせてエンコードし、受け手はネットワークの状況に応じてどれだけバッファを持つかを選べます。
VTuberのファンミーティングが必要としていたもの
VTuberのファンミーティングでは、ひとつの経路の中で、性質の異なる二つの要求を同時に満たす必要があります。音声には、会話が成立するための即時性が求められます。映像には、タレントの姿を保つための品質が求められます。この二つは、望ましいトレードオフの位置が異なります。
WebRTCは会議のための技術として設計されており、そのトレードオフはスタックの前提として組み込まれています。用途に合わせてトラックごとに位置を選ぶ、という発想がそもそもありません。一方でMoQでは、トラックごとに優先度を設定でき、回線が苦しくなったときに何を守り何を落とすかを、アプリケーション側が決められます。会話を守りながら、映像に必要なだけの品質を確保する――という設計が可能になります。
「WebRTCではだめなのか」という問いについて
映像として送るのであれば、MoQ以外にも選択肢はあります。この点は技術的な検討の過程で当然議論になったため、判断の理由を記しておきます。
RTMPは、OBSからの出力として最も広く使われている方式です。ただし遅延が数秒単位で発生します。配信を「見る」だけであれば許容できますが、会話の往復には使えません。今回の用途では最初に外れました。
WHIP（WebRTC-HTTP Ingestion Protocol）は、WebRTCへの取り込みを標準化したもので、2025年3月にRFC 9725として発行されています。OBSからWebRTCへ送出すること自体は、これで可能です。送出側だけを見れば、選択肢として成立します。
問題は再生側です。取り込みのWHIPがRFCになった一方で、**再生側にあたるWHEP（WebRTC-HTTP Egress Protocol）は、2026年現在もInternet-Draftの段階にとどまっています。**実際の再生はブラウザのWebRTC実装に強く依存し、コーデックの扱いやバッファの挙動、遅延と品質のトレードオフを、こちらの意図どおりに制御することができません。会場のスクリーンに映るのはタレントの姿です。その品質がブラウザの実装任せになる構成は、私たちにとって受け入れがたいものでした。
MoQを選んだのは、送出から再生までを一つのプロトコルで扱え、そのトレードオフを自分たちで決められるからです。柔軟に扱えること、それ自体が今回の要件でした。
| 方式 | 送出 | 遅延 | 再生側の制御 |
| モデル配布＋現地レンダリング | 制御データのみ | 小さい | 会場側の環境に依存。モデルデータの受け渡しが必要 |
| RTMP | OBSから可能 | 数秒。会話には使えない | ― |
| WHIP／WebRTC | OBSから可能（RFC 9725） | 小さい | WHEPが未RFC。ブラウザ実装に依存し制御できない |
| MoQ | OBSから可能 | 小さい | アプリケーション側で制御できる |
なお、MoQがWebRTCの上位互換だと主張するつもりはありません。1対1の通話のように、両端が対等に会話する用途では、長年かけて磨かれたWebRTCに分があります。MoQが本領を発揮するのは、今回のような一対多のライブイベントです。私たちの用途がたまたまそちら側にあった、というのが正確なところです。
プロトコルとしてのMoQ
MoQ（Media over QUIC）は、IETF（Internet Engineering Task Force）のMoQワーキンググループで標準化作業が進められている、QUIC上でメディアを転送するためのプロトコルです。ワーキンググループは「配信と取り込みの双方に対応する、単純で低遅延なメディア配送方式」を目標に掲げ、ライブ配信・ゲーム・メディア会議を対象領域としています。コア仕様であるMoQ Transport（MOQT）は2026年7月にドラフト19版が公開され、2026年12月のIESGへの発行要請がマイルストーンに置かれています。
今回の用途に効いた特性は、次の3点です。
- QUICのストリーム多重化：映像パケットの損失が音声の再生を止めない。TCPのヘッドオブラインブロッキングの影響を受けずに、映像と音声を独立して扱える
- アプリケーション側での優先度制御：トラックやサブグループ単位で優先度を設定でき、輻輳時に何を落とすかを送り手が決められる
- リレーによるスケール：CDNのようにリレーを経由して配信を広げられるため、会場が増えても同じ仕組みのまま拡張できる。WebRTCのように視聴者ごとの状態をサーバが持つ必要がない
システム構成と技術詳細
本番運用にあたっての構成と実測値を公開します。
| 項目 | 内容 |
| 準拠ドラフト | draft-16（※ Cloudflare MoQ Relayのサポート状況によります） |
| リレー構成 | Cloudflare MoQ Relay + 自社ホストのリレーサーバー |
| 映像 | コーデック: H264 （OBSではH264, H265, AV1をサポートする）解像度 最大4K (2160p)までフレームレート: 60fpsまでビットレート: 10Mbpsまで（※店舗側、配信側の環境により実用可能な条件が変わります） |
| 音声 | OBS: Opus 160kbpsその他（マイク等）: Opus 96kbps~128kbps |
バーチャルと現実の境界を狭める
高解像度の映像は、VTuberの姿を美しいまま会場のスクリーンへ届けます。低遅延の音声は、まるですぐそこにいるかのような距離感で会話を成立させます。
VTuberとファンが直接顔を合わせる機会は、これまで大規模なホールイベントや、画面越しの配信に限られてきました。「AIAI」は、数十人規模の小さな場でも、タレントが自宅にいながらファンと同じ時間・同じ空気を共有できる環境をつくります。バーチャルと現実の境界を狭めていくことが、このサービスの目的です。
代表コメント
株式会社ブートストラップ 代表取締役 川田 寛
VTuberの魅力は、その姿と、その言葉です。これまでのイベントは、そのどちらかを諦めることが少なくありませんでした。画質を取ればモデルを会場に配って現地でレンダリングするしかなく、会話を取ればWebRTCで、映像の見え方をブラウザの実装に委ねるしかない。私たちはその両方を試してきて、どちらにも限界を感じていました。
MoQが良かったのは、遅延と品質のどちらを優先するかを、プロトコルではなく私たちが決められることです。音声は会話のための即時性、映像はタレントの姿を守るための品質――ひとつの経路の中で、別々の答えを選べる。これは、これまでのやり方では選びようがなかったものです。
もうひとつ、私たちが重要だと考えているのは、タレント本人の負担が増えないことです。これまでのやり方は、解像度を守るためにモデルデータを会場側にダウンロードさせ、現地でレンダリングしてもらうというものでした。つまり、タレントが自分の配信で積み上げてきた環境は一度脇に置かれ、イベント用の別の段取りをやり直すことになる。MoQなら、いつものOBSとVTube Studioのまま、YouTubeで配信するのと同じ感覚で会場に立てます。技術は、新しいことを覚えさせるためではなく、覚えなくて済むようにするために使いたい。
そして、モデルデータを外に出さずに済むというのは、私が長く見てきた領域からすると、想像以上に大きなことです。3Dモデルはタレントの姿そのものであり、制作者との契約に守られた資産でもあります。イベントのたびにそれをどこかへ預ける前提が消えるだけで、開催のハードルは確実に下がります。
実際に会場で見た光景は、想像していたものを超えていました。来場者が話しかけ、ほとんど間を置かずに返事が返ってくる。その瞬間、スクリーンの向こうにいたはずのタレントが、確かにその場にいる存在になっていました。技術の話をしたいのではなく、この体験を成立させたかった。それが今回の取り組みのすべてです。
標準化の途上にあるプロトコルを商用の現場に持ち込むことには、当然リスクもあります。それでも、クリエイターの表現をより良い形で届けるための技術は、誰かが先に実地で試さなければ前に進みません。私たちはこれからも、その役割を担っていきます。
今後の展開
株式会社ブートストラップは、「AIAI」におけるMoQの活用を継続し、以下の展開を予定しています。
- 対応会場の拡大と、イベント主催者向けの提供メニュー整備
- MoQ配信基盤のSaaS化、VTuber・バーチャルタレント系サービスへの一般提供
- 実運用で得られた知見の技術コミュニティへの還元
技術連携・共同検証のご相談を受け付けています
MoQは、バーチャルタレントのイベントに限らず、低遅延と高解像度の両立が求められるあらゆる領域で有効な技術です。当社は、今回の実運用で得た知見をもとに、以下のようなご相談を受け付けています。
- MoQの導入検討にあたっての技術評価・PoC支援
- 配信基盤・映像伝送に関わる事業者との共同検証
- 自社イベント・施設でのMoQ活用に関するご相談
国内でMoQの商用運用に取り組む事業者はまだ多くありません。知見を持ち寄れる相手を探しています。下記の窓口までお気軽にご連絡ください。
サービス・会場について
バーチャルタレント向けイベント支援サービス「AIAI」
バーチャルタレントがリアルの場でファンと交流するためのイベントを、企画・技術・当日運営まで一貫して支援するサービスです。株式会社ブートストラップが提供しています。
- Webサイト：https://aiai-s.com/
- お問い合わせ：https://aiai-s.com/contact
KAIWAI 初台
東京・初台にあるイベントスペース。バーチャルタレントやVTuberのファンミーティングをはじめとした催しを開催しています。
- X（旧Twitter）：@kaiwai_hatsudai
- 所在地：東京都渋谷区初台1-53-6 TA初台 2F
会社概要
株式会社ブートストラップ
クリエイター向けサービスのコンサルティングおよびプロダクト開発を手がける企業です。UGC/CGMプラットフォームの設計・運用に関する知見をもとに、コンテンツとクリエイターを支える技術・プロダクトの開発を受託しています。
- 代表者：代表取締役 川田 寛
- 所在地：東京都渋谷区初台1-53-6 TA初台 2F
- 設立：2023年4月3日
- 事業内容：クリエイター向けサービスのコンサルティング、プロダクト開発受託、バーチャルタレント向けイベント支援
- Webサイト：https://bt-strap.com/
代表者プロフィール
川田 寛（かわだ ひろし）
株式会社ブートストラップ 代表取締役。NTTグループ（NTTコムウェア）出身の技術者として、日本最大のWeb技術者コミュニティ「html5j」のコアメンバーを務め、Web技術の普及推進に携わる。その後ピクシブ株式会社にて執行役員・エンジニアリングマネージャー・事業責任者として、クリエイターとコンテンツを取り巻くプロダクトと技術を支えた。2018年には事業責任者としてVRoidプロジェクトの立ち上げに参画し、バーチャルタレント領域との関わりを持つ。現在は株式会社ブートストラップ代表取締役のほか、「小説家になろう」を運営する株式会社ヒナプロジェクトの社外CTOも務める。
お問い合わせ先
株式会社ブートストラップ 広報担当 メール：[email protected]
MoQを用いた本システムのデモンストレーション、および技術詳細に関する取材を受け付けております。MoQの導入検討、共同検証、配信基盤に関するご相談も受け付けております。