プロトコル・フォーマット

はじめに　分類と「プロトコル」と「フォーマット」の違い

• プロトコル（通信規格：どう運ぶか）: データをネットワークやシリアル通信で「送受信するためのルール・手順」のこと。
• フォーマット（データ形式：中身が何か）: 届いたデータが「どのような並び順（構造）で書かれているか」という仕様のこと。

実務上は、Free-Dのように「特定のデータ構造（フォーマット）を、UDPなどのネットワーク通信で送る仕組み」が一体化してプロトコルと呼ばれているケースがほとんどです。

分類
１　映像、音声などの伝送
２　映像そのものではなく、それに付帯するデータの伝送
　　カメラデータ　トラッキング、FIZデータなど
３　CG、バーチャル系データ
　　モデルデータ、テクスチャー、リグ関節データ、モーションデータ、
４　その他
その応用例、事例など

1. 映像伝送プロトコル

映像データ

• NDI (Network Device Interface): 一般的なギガビットLAN環境で、高品質・低遅延な映像を伝送できるプロトコル。ライブ配信や番組制作で急速に普及しています。
• SMPTE ST 2110: 放送局などのプロフェッショナル環境向けの次世代規格。映像、音声、補助データ（字幕など）をそれぞれ独立したストリームとしてIPネットワーク上で伝送します。
• SRT (Secure Reliable Transport): 公衆インターネットなどの不安定な回線でも、安全かつ低遅延で高品質な映像をリスニング・配信するためのプロトコル。
• SDI (Serial Digital Interface): 同軸ケーブルを使用した、放送業界で長年使われている堅牢なデジタル映像伝送の標準規格（3G-SDI、12G-SDIなど）。

映像に付帯するデータの伝送

1. カメラトラッキングデータの伝送

バーチャルプロダクション（インカメラVFXやグリーンバック合成）で、現実のカメラの動き（位置・角度・ズーム・フォーカス）をUnreal EngineなどのCGレンダラーに送るための技術です。

• Free-D (フリー・ディー):
  • 分類: プロトコル（通信規格）
  • 解説: 元々はBBCが開発した、カメラの位置・傾き（パン・チルト・ロール）・レンズ情報（ズーム・フォーカス）をリアルタイムに伝送するための業界標準プロトコルです。現在は主にUDP/IP（ネットワーク）を介して軽量・低遅延で送信されます。ほぼすべてのPTZカメラ（リモートカメラ）やトラッキングシステム（Mo-Sys、Stypeなど）が対応しています。
• OpenVR / Live Link:
  • 分類: 専用プロトコル / API
  • 解説: HTC VIVEのトラッカーなどをVFXで流用する際はOpenVR、Unreal Engineへ直接データを流し込む際はEpic Games独自の「Live Link」プロトコルが使われます。

３　CG、バーチャル系データ

モーション（骨格）データの伝送

バーチャルライブやVTuberの配信で、アクター（演者）の身体や顔の動きを、リアルタイムに3Dアバターへ反映させるためのプロトコルです。

• VMCプロトコル (Virtual Motion Capture Protocol):
  • 分類: プロトコル（OSCの応用拡張）
  • 解説: 日本のVTuber・VR業界における事実上の標準プロトコル。ネットワーク制御プロトコルであるOSC（Open Sound Control）に乗せる形で、キャラクターのボーン（骨格）位置や表情のデータをUDPで伝送します。これにより、モーションキャプチャソフトからUnityやUnreal Engineへ、メーカーを問わずリアルタイムに動きを同期できます。
• gRPC / WebSocket:
  • 分類: 汎用ネットワークプロトコル
  • 解説: 大規模な商業バーチャルライブなどで、独自開発のシステム間に大量のモーションデータを高頻度・低遅延で双方向通信させる際によく採用されます。

モデル・アセットデータの伝送・読み込み

こちらは「通信のルール」ではなく、「ファイル・データ形式（フォーマット）」に分類されます。ライブ中に動的に読み込んだり、メタバース空間でアセットを共有したりする際に重要となります。

• glTF / glb (GL Transmission Format):
  • 分類: 3Dデータフォーマット
  • 解説: 「3D界のJPEG」を目指してWeb3Dコンソーシアム（Khronos Group）が策定した形式。軽量で、テクスチャやアニメーション情報も含めて1ファイル（.glb）にまとめられるため、ネットワーク経由でのダウンロードや、ライブ中の動的読み込みに最適化されています。
• VRM:
  • 分類: 3Dアバター専用フォーマット
  • 解説: glTFをベースに、日本のアバター文化に合わせて開発された国際標準フォーマット。人型キャラクターの骨格設定、表情（ブレンドシェイプ）、揺れもの（髪や服）、ライセンス情報などを内包しており、対応するあらゆるバーチャルライブシステムやメタバースに同じアバターをそのまま持ち込めます。
• USD / USDA / USDC (Universal Scene Description):
  • 分類: 3Dシーン記述フォーマット
  • 解説: Pixarが開発し、現在はNVIDIA（Omniverse）などが推進するオープン規格。モデル単体ではなく、カメラ、照明、物理挙動を含めた「シーン全体」を保持し、複数のクリエイターがネットワーク経由でリアルタイムに同時編集（コラボレーション）する際のデータ基盤として使われます。

2. 音声伝送プロトコル（Audio over IPなど）

ネットワークケーブル（LANケーブル）や専用線を使って、高品質な多チャンネル音声を伝送するプロトコルです。

• Dante (ダンテ): 現在の音響業界で最も普及しているネットワークオーディオ規格。一般的なギガビットルーターを使って、極めて低い遅延で多チャンネルの音声を伝送できます。
• AES67: 異なるネットワークオーディオ規格（Dante、Ravenna、Q-LANなど）の間で相互運用性を持たせるための国際標準規格。
• MADI (Multi-channel Audio Digital Interface): 同軸ケーブルや光ファイバーを使い、最大64チャンネルのデジタル音声を一方向へ伝送する伝統的な規格。
• AVB (Audio Video Bridging): IEEEによって標準化された規格。ネットワーク全体で帯域を予約し、音声を途切れなく伝送します。対応するスイッチングハブが必要です。

3. 制御・同期プロトコル

機器の動作タイミングを合わせたり、遠隔で操作したりするためのプロトコルです。

• MIDI (Musical Instrument Digital Interface): 電子楽器の演奏データだけでなく、音響機器や照明機器のコントロール、ステージ演出の同期（MIDI Time Code）にも広く使われています。
• OSC (Open Sound Control): MIDIの後継として開発されたプロトコル。ネットワーク（UDP/IP）を利用し、より高速かつ柔軟に機器を制御できます。
• LTC / VITC (Timecode): 映像と音声を1フレーム単位で完全に同期させるためのタイムコード規格。
• PTP (Precision Time Protocol / IEEE 1588): ネットワーク上の全機器の時計をマイクロ秒未満の精度で同期させるプロトコル。DanteやSMPTE ST 2110の同期基盤として使われています。
• DMX（DMX512）
  • DMX（DMX512）は、「現在も超現役だが、イマーシブの現場（Unreal Engine等との連携）においては、そのままでは使えず『Art-Net』や『sACN』への変換が必須のプロトコル」という位置づけになります。
  • 分類: 照明・演出制御プロトコル
  • 現状: 半分レガシー、半分現役（ネットワーク化が必須）。
  • 解説:
    舞台照明をコントロールする伝統的な規格（XLR 3ピン/5ピンの専用ケーブルを使用）です。現在も照明器具自体を動かすためには必須ですが、イマーシブ環境（バーチャルライブ、XRスタジオ）では、PCやゲームエンジン（Unreal Engine/Unity）とダイレクトに通信できません。
    そのため、現代の現場や開発では、DMXの信号をLANケーブル（IPネットワーク）で流せるようにした「Art-Net（アートネット）」や「sACN（エスエーシーエヌ）」というプロトコルが標準となっています。

実例、汎用例

🛠️ 【実例1】バーチャルライブでの演出・同期システム

（モーションキャプチャ、アバター、リアル照明の完全同期）
VTuberや3Dアーティストが、リアルタイムに歌って踊るバーチャルライブでの機材・システム連携の例です。

【演者の動き】モーションキャプチャ ➡ [VMCプロトコル(OSC) / UDP] ➡ Unity / Unreal Engine（アバターが動く）
                                                                             ⬇
【演出の同期】照明・特効の制御卓  ➡ [Art-Net / sACN (LAN)] ➡ ➡ ➡ ➡ ➡ ➡ ➡ ➡ 統合制御PC (DL / カウントダウン)
                                                                             ⬇
【リアル照明】[Art-Net信号] ➡ (Art-Netノード/変換器) ➡ [従来のDMX] ➡ スタジオのリアル照明（アバターと色が連動）

• ポイント:
  人間の動きは VMCプロトコル でゲームエンジンへ送り、照明のタイミングは Art-Net でエンジン側（または制御PC）に送ります。最終的にスタジオのリアルな照明器具を動かす手前で、Art-Netから従来のDMXケーブルに変換して器具に接続します。

🛠️ 【実例2】インカメラVFX（LEDスタジオ）での映画・CM撮影

（カメラトラッキングと背景CG、照明の完全同期）

巨大LEDディスプレイの前に本物の役者を立たせ、カメラの動きに合わせて背景の3DCGをリアルタイムに動かす撮影手法（バーチャルプロダクション）の例です。

【位置同期】シネマカメラ ➡ [Free-D / UDP (LAN)] ➡ Unreal Engine（カメラの動きに合わせて背景CGがリアルタイムに描画）
                                                        ⬇
【環境照明】背景CGの空の色・爆発 ➡ [Art-Net / sACN] ➡ スタジオ天井のLED照明（役者への照り返しがCGと100%連動）

1. ポイント:
   カメラマンがカメラを動かすと、その座標データが Free-D でUnreal Engineに一瞬で届き、背景の3D世界も連動して動きます。さらに、CGの中で太陽が沈んだり爆発が起きたりすると、その色情報がUnreal Engineから Art-Net として出力され、スタジオのリアルな照明を光らせて役者を照らします。これにより、CGと現実が完全に融合します。

【実例3】ボリュメトリックビデオ（Volumetric Video：自由視点映像）

ボリュメトリックビデオ（Volumetric Video：自由視点映像）をリアルタイムの「ライブ」として運用・配信する環境は、現在のイマーシブコンテンツにおいて最もホットで、かつ最も高いマシンスペックとネットワーク帯域を要求する領域です。

開発者と現場オペレーターが共通認識を持つべき「リアルタイム・ボリュメトリックビデオ」のコア要素（カメラ、スキャナー、プロトコル、フォーマット）を実例を交えて解説します。

1. 必要なカメラ・スキャナー（撮影システム）

リアルタイムで空間をキャプチャするためには、静止画用の3Dスキャナー（LiDAR等）ではなく、高フレームレートで同期撮影できる「マルチカメラ方式」が必須です。

• RGBシネマカメラ / PTZカメラ（数十台〜百数十台）
  • 役割: 被写体の色や質感を全方位から高精細に捉えます。
  • 実例: Canonの「自由視点映像生成システム」や、Sonyのボリュメトリックスタジオ等では、専用の4K/60fpsカメラをグリーンバックのスタジオに円状に配置します。
  • 現場の注意点: すべてのカメラのシャッタータイミングを1フレーム（マイクロ秒単位）のズレもなく合わせるための「Genlock（外部同期信号）」、またはネットワーク同期（PTP）が絶対に必要です。
• RGB-Dカメラ（高精度デプスカメラ）
  • 役割: 赤外線などを用いて、被写体までの「距離（深度）」を直接リアルタイムに計測します。
  • 実例: Azure Kinect DK（※生産終了ですが現場ではまだ現役）、Intel RealSense シリーズ、または Orbbec（オルベック） の最新デプスカメラ。
  • 特徴: 個人〜中規模のリアルタイムシステム（数台〜十数台の組み合わせ）では、RGBカメラ単体よりも深度計算の負荷を大幅に減らせるため、インディーズのバーチャルライブや実験的配信でよく使われます。

2. 必要なプロトコル（どう通信するか）

ボリュメトリックライブでは、「カメラ ➡ サーバー（結合・計算）」と「サーバー ➡ 視聴者・Unreal Engine等（配信）」の2つのフェーズで異なるプロトコルが動きます。

【カメラ ➡ サーバー間（生データ伝送）】

• SMPTE ST 2110:
  • 大規模スタジオの標準。非圧縮の超高画質映像をIPネットワークで複数台からサーバーへ超低遅延で集約します。
• USB 3.0 / PCIe 延長プロトコル:
  • デプスカメラ（RealSense等）を複数台使う小〜中規模システムの場合。LANケーブル（Cat6A）等に変換してサーバーに集約します。

【サーバー ➡ レンダラー / 視聴者間（3Dデータ配信）】

• WebRTC / WebSocket:
  • 生成された3Dデータ（点群やメッシュ）のパケットを、Unreal EngineやWebブラウザへ超低遅延（1秒未満）でリアルタイムに送り込むための通信プロトコル。
• MPEG-I OMAF (Omnidirectional Media Format):
  • 360度映像やボリュメトリックを効率よく配信するための国際標準プロトコル。視聴者の見ている方向のデータだけを高画質で送る「タイルベース配信」などを制御します。

3. 必要なフォーマット（データ形式）

ボリュメトリックビデオは、本質的には「3Dオブジェクト（立体データ）が毎秒30〜60回入れ替わるパラパラマンガ」です。ライブ配信では、1フレームあたりのデータ量を極限まで削る圧縮フォーマット（コーデック）の選定が開発の命を握ります。

• Point Cloud（点群データ）形式
  • 解説: 空間の立体を「無数の点の座標（XYZ）と色（RGB）」の集まりとして表現する形式。メッシュ（面）を貼る計算を省けるため、リアルタイム処理に向いています。
  • リアルタイム用コーデック: MPEG-PCC (Point Cloud Compression)。点のデータを劇的に圧縮し、ネットワーク伝送を可能にします。
• Dynamic Mesh（動的メッシュ）形式
  • 解説: 点と点を繋いで「面（ポリゴン）」を作り、そこにテクスチャ（映像）を貼り付ける形式。Point Cloudよりも見た目が滑らかでリッチになりますが、リアルタイムの計算負荷は跳ね上がります。
  • リアルタイム用フォーマット: Volumetric H.264 / H.265 (Depth+Color)。立体データを「カラー映像」と「深さ（白黒のグラデーション）映像」の2つに分解し、従来のYouTube等で使われる普通の動画コーデック（H.264等）に乗せて配信する手法です。受信側（Unreal Engine等）で、この2つの映像を再び3Dに復元（変形）させます。これが現在のリアルタイム配信の最も現実的なアプローチです。

💡 ハンドブックで「必要ない知識（切り捨てるべきもの）」

ボリュメトリックの「ライブ」を扱う場合、以下のフォーマットやアプローチは「処理が重すぎる・配信に向かない」ため、完全に除外して構いません。

• ❌ Alembic (.abc) / OBJシーケンス:
  • 映画のVFXなどで使われる「フレームごとの3D形状を丸ごと保存した巨大ファイル」。1秒間で数ギガバイトになるため、事前収録（オフライン）用であり、ネットワークを流すライブ配信では100%不可能です。
• ❌ NeRF (Neural Radiance Fields) / 3D Gaussian Splatting（の初期アプローチ）:
  • AIを用いた超高画質な空間再現技術としてトレンドですが、現時点では「静止した空間」の再現がメインです。動く人間をリアルタイムにキャプチャ・配信するシステムとしては、まだ計算負荷が高すぎ、プロダクションの現場でライブに組み込むには時期尚早です。

ボリュメトリックライブの実例フロー

【撮影】数十台のカメラ (Azure Kinect / シネマカメラ)
          ⬇ [SDI 12G 又は ST 2110]
【計算】ボリュメトリック生成サーバー (毎秒 数十フレームの3Dデータを結合・生成)
          ⬇ [MPEG-PCC 又は Depth+Color圧縮]
【伝送】[WebSocket / WebRTC] (超低遅延ネットワーク伝送)
          ⬇ 
【描画】Unreal Engine / 視聴者ブラウザ (リアルタイムに3Dとして復元・配置)

「配信用には、3Dデータをそのまま送るのではなく、動画コーデック（H.264/H.265等）に一度落とし込んでから送る技術（Depth+Color方式）が現場の主流である」と解説すると、開発者・オペレーター双方にとって非常に実践的な知識となります。

ボリュメトリックビデオ「3大トップランナー」

3大システムの比較サマリー　「現場でどう使い分けるべきか」の比較

1. 4DVIEWS（フォーディービューズ）　※システム名：HOLOSYS（ホロシス）

• 特徴: ボリュメトリックビデオの歴史を作ってきた「絶対的な品質重視」のシステムです。
• ライブ配信の可否: ❌ 不可
  • 理由: 撮影した膨大なマルチカメラ映像を、専用サーバーで「数時間〜数日」かけて超高精細な3Dメッシュデータへレンダリング（ポストプロ処理）するため、生配信はシステム構造上不可能です。
• プロトコル・フォーマット:
  • 収録時: 各カメラからサーバーへは、専用の高速シリアル/光ケーブル、またはカメラメーカー独自の伝送プロトコルが使われます。
  • 書き出し（アセット）: 独自フォーマット（.4ds）のほか、Unreal EngineやUnityへインポートするための Alembic (.abc) 拡張やプラグイン用データとして出力されます。
• 現場の認識: 「MV（ミュージックビデオ）や映画、ゲームのアセットなど、事前の作り込み用であり、生放送の現場には持ち込めない」と割り切る知識が必要です。

2. Sony Volumetric Video（ソニー）
※ソニー・イノベーション・スタジオ / 伝送技術「Hawk-Eye」などの技術融合

• 特徴: 「高品質」と「リアルタイム・ライブ配信」のバランスが最も優れており、現在のエンタメ・バーチャルライブで最もアクティブなシステムです。
• ライブ配信の可否: ⭕ 可能
  • 仕組み: 独自開発のGPUクラスター（超高速計算サーバー群）により、数十台のカメラ映像から一瞬で3Dデータを生成し、数フレーム（1秒未満）の遅延で生配信する仕組みを確立しています。
• プロトコル・フォーマット:
  • カメラ ➡ サーバー: SMPTE ST 2110（Video over IP）や12G-SDIをフル活用。
  • サーバー ➡ 配信/レンダラー: WebRTC や WebSocket、または独自に最適化されたパケット伝送プロトコルを使い、3Dデータ（点群や軽量化されたメッシュ）をUnreal EngineやWebブラウザへストリーミングします。
• 現場の認識: 「VTuberのリアルタイム3Dライブの最高峰や、音楽アーティストのリアルタイムメタバース配信を行うならSonyのシステム、またはその互換設計（開発向け）」という位置づけになります。

3. キヤノン（Canon）自由視点映像システム
※Volumetric Video System

• 特徴: 映画やスタジオだけでなく、「サッカースタジアムやバスケットボールアリーナ丸ごと」を3D空間化する怪物級のシステムです。
• ライブ配信の可否: ⭕ 可能
  • 仕組み: スタジアムの壁面に100台以上の4Kカメラを設置。選手やボールの動きをリアルタイムに3Dデータ化し、プロ野球やJリーグ、NBAの生中継で「実況中にカメラが回り込むリプレイ映像」をわずか数秒で生成・放送しています。
• プロトコル・フォーマット:
  • インフラ: 100台以上のカメラから毎秒数百ギガバイトのデータを集約するため、超大規模な専用IPネットワーク（SMPTE ST 2110ベースの放送グレード規格）で構築されます。
  • 出力: 放送用スイッチャーへは通常の SDI (3G/12G) や HDMI として出力（バーチャルカメラの映像として出力）されるほか、メタバース配信用に3Dアセットデータとしてリアルタイム出力（独自の軽量メッシュストリーム）も対応しています。
• 現場の認識: 「スタジオ収録レベルではなく、スポーツや大規模ライブイベントの空間そのものをリアルタイムに配信・リプレイ化するための、最もスケーラブルなインフラ」です。

1. 国内の先駆者・商用実践企業

■ リアライズ・イノベーションズ（日本）

• 特徴: ソフトバンクグループの企業で、日本国内で最も多くの商用ボリュメトリック案件（トップアイドルやアスリートの撮影など）を手がけている実務のパイオニアです。 [1]
• 最新の動向: 2025年〜2026年にかけて、次世代の3D空間再現技術である「4DGS（4D Gaussian Splatting）」を自社スタジオに導入。米国の技術企業 Gracia と協業し、ボリュメトリックビデオにAI（Gaussian Splatting）を融合させて、これまでのメッシュ形式を遥かに超えるリアルな質感を低遅延で配信するエコシステムを構築しています。 [1, 2]
• ハンドブック視点: メッシュやPoint Cloudの「次」のフォーマット（4DGS）を現場で実践している実例として最重要です。 [1, 2]

■ 株式会社クレセント（日本）

• 特徴: モーションキャプチャやスタジオ構築の老舗インテグレーター。独自にリアルタイム・ボリュメトリックビデオ撮影システム「Volu☆ME!（ボリューミー）」を開発・展開しています。 [1]
• 技術アプローチ: 撮影エリア内の人や物をリアルタイムに3次元デジタルデータ化し、そのままインターネット生配信できるパッケージをスタジオ向けに提供しています。 [1]
• ハンドブック視点: オペレーター向けに「日本国内で独自システムを組んでスタジオ構築をサポートしてくれる企業」として紹介できます。

2. 海外のリアルタイム・配信特化型スタートアップ

■ Condense（イギリス）

• 特徴: バーチャルプロダクションや「ライブイベントの生配信」に特化してボリュメトリック技術を開発する超注目スタートアップです。
• 技術アプローチ: 特殊なスタジオでなくても、一般的な会場にカメラを数台設置するだけで、リアルタイムに演者を3D化し、メタバース空間（Unity/Unreal Engine）やWebブラウザへ数秒の遅延でストリーミングできるシステム（Video 3.0）を提供しています。
• ハンドブック視点: 「大規模な放送局グレードでなくても、イベントレベルでリアルタイム・ボリュメトリックを実用化している」好例です。 [1]

■ Evercoast（アメリカ）

• 特徴: クラウドベースの3Dビデオキャプチャおよびリアルタイム配信システムを開発する企業です。
• 技術アプローチ: 現場のカメラ（デプスカメラやRGBカメラ）で捉えたデータを、オンプレミス（現場のPC）ではなくクラウド上のサーバーで高速処理・合成し、さまざまなプラットフォーム（Web、VR、メタバース）へ配信するパイプラインを持っています。 [1, 2, 3]

■ 8i（ニュージーランド / アメリカ）

• 特徴: ボリュメトリックビデオの圧縮技術とモバイル配信において、世界的に高いシェアを持つ企業です。
• 技術アプローチ: 独自のホログラム変換技術を持ち、数十台のカメラ映像から生成された巨大な3Dデータを、スマホの4G/5G回線でもスムーズに再生できるレベルまで軽量化してWebAR等にリアルタイム配信するプラットフォームを持っています。 [1, 2, 3]

3. 大手テック企業・インフラの最新「共同」実例

2026年現在のトレンドとして、ボリュメトリック単体ではなく「次世代の通信インフラと掛け合わせた超低遅延ライブ」の実証実験が商用化に向けて加速しています。

■ キヤノン × NTT東日本（IOWN連携）

• 実践例: 2026年1月より、キヤノンのボリュメトリックビデオシステムと、NTTの次世代光ネットワーク「All-Photonics Connect powered by IOWN」を組み合わせた技術検証・協業がスタートしています。
• なぜ重要か: ボリュメトリックの生配信は、約100台のカメラから出る膨大なデータ（ゆらぎ、遅延、帯域の壁）が課題でした。これをIOWNの超高速・低遅延な光ネットワーク（プロトコル層を最適化した次世代通信）に直接流し込むことで、「スタジオで撮影したボリュメトリックデータを、離れた場所にある劇場や街頭のXRステージへ、完全にノータイム（超低遅延）で伝送する」という実践が進んでいます。 [1, 2, 3]

■ Nokia「VolStream」（フィンランド）

なぜ重要か: 開発者向けに、市販のハードウェアを使って「エンコード ➡ 配信 ➡ デコード ➡ レンダリング」を完結させ、人間が自然に会話・インタラクションできるレベルの低遅延（グラス・トゥ・グラス遅延）を実現するためのオープンなストリーミング技術を提供し始めています。 [1]

実践例: 通信大手のノキアが、リアルタイムな3Dビデオ配信を民主化するために、オープンソースのリファレンス実装「VolStream」を発表。