はじめに WebRTCという標準的な選択肢 産業用途での検討ポイント SFUの選定と移行コスト センサーデータとの統合 録画・解析システムの構築 intdashという選択肢 Webアプリからintdashを使う ― intdash-RTC SDK ユースケース おわりに はじめに Webアプリケーションでリアルタイムな映像通信を実装したい。ビデオ通話、遠隔支援、リアルタイム監視...。こうしたニーズは年々高まっています。 リアルタイムな映像通信を実装するとき、まず候補に挙がるのがWebRTCです。ブラウザ標準で使え、低遅延な双方向通信が可能で、実績も豊富。多くの開発者が最初に検討する選択肢でしょう。 ただ、産業用途で本格的に活用するには、追加の検討が必要になることもあります。本記事では、産業用途での検討ポイントを整理しつつ、intdashという選択肢を紹介します。 WebRTCという標準的な選択肢 WebRTC（Web Real-Time Communication）は、ブラウザ間で低遅延な双方向通信を実現するための技術です。P2Pによるダイレクトな通信が可能で、ビデオ会議、ライブカスタマーサポート、オンライン診療など、さまざまなユースケースで広く採用されています。 WebRTCの強み: ブラウザ標準: 主要ブラウザでネイティブサポート、追加プラグイン不要 低遅延な双方向通信: P2Pによる直接接続で、遅延を最小限に抑えた通信を実現 豊富な実績: ビデオ会議ツールやオンライン診療など、多くのサービスで採用 SFUベンダーの充実: Twilio、Agora、時雨堂等、多くの選択肢 「標準規格だからベンダーロックインされない」という声もよく聞きます。確かにWebRTC自体はRFCで標準化されたプロトコルです。 産業用途での検討ポイント WebRTCは汎用的で優れた技術ですが、産業用途で本格的に活用するには、追加の検討や工夫が必要になることがあります。 SFUの選定と移行コスト WebRTCの接続方式：P2P vs SFU WebRTCの「標準」が規定するのは、主にブラウザ間のP2P通信です。 P2Pは1対1の通信に向いていますが、参加者が増えると各端末の送受信負荷が急増するため、多人数での通信にはSFU（Selective Forwarding Unit）が必要になります。しかし、SFUは各ベンダーが独自に実装しており、ルーム管理、認証、録画といった機能もベンダーごとにAPIが異なります。 また、利用規模の拡大や新たな機能要件により、SFUベンダーの乗り換えが必要になることもあります。その場合、ベンダー固有のAPIに依存した部分は作り直しになるため、選定時には将来的な移行コストも考慮に入れておくと良いでしょう。 センサーデータとの統合 産業用途では、映像だけでなくセンサーデータも一緒に扱いたいケースがあります。たとえば、車両の走行映像とCANデータ・GPS、建設現場の監視映像とセンサー情報、製造ラインの映像と設備データ、といった組み合わせです。 WebRTCでこれを実現する場合、DataChannelを活用する方法があります。ただし、DataChannelはデータの送受信のみを提供するため、センサーデータの格納フォーマットや映像との時刻同期の仕組みは、自前で定義・実装する必要があります。 録画・解析システムの構築 「送信した映像を後から見返したい」「解析に使いたい」という要件も多いです。 WebRTCでは、録画や解析の機能は標準で提供されていません。SFUベンダーが録画機能を提供している場合もありますが、解析・可視化まで含めたシステムを構築する場合は、追加の開発が必要になることがあります。 intdashという選択肢 弊社が開発するintdashは、こうした産業用途のニーズを想定して設計された伝送プラットフォームです。 intdashの強み: マルチモーダル対応: 映像、音声、センサーデータを統合して伝送可能 大容量・低遅延: モバイル回線経由でも高頻度データを伝送可能 時刻同期が標準装備: すべてのデータに共通の基準時刻でタイムスタンプ 保存・解析・可視化まで一気通貫: サーバーに保存し、Data Visualizerでノーコード可視化・再生が可能 Webアプリからintdashを使う ― intdash-RTC SDK intdashでWebアプリから映像・音声のリアルタイム通信を行う場合は、intdash-RTC SDKを使用できます。 intdash-RTC SDKは、intdashを用いたリアルタイムコミュニケーションを実装するためのSDKです。 intdashの通信クライアントをラップして利用することで、リアルタイムコミュニケーションの実装をWebRTCのようなシンプルなインターフェイスで実現できます。 intdash-RTC SDKは、3つのインターフェイスで構成されています: MediaConnection: 接続の開始・停止 MediaSender: 映像・音声を送信 MediaReceiver: 映像・音声を受信 さらに、センサーデータの統合や録画・可視化といったintdashの機能も併せて活用できます。 実装の流れは以下のとおりです。シンプルなビデオチャットであれば、数十行のコードで実装できます: // 1. intdashに接続 const iscpConn = await iscp.Conn.connect( { address , connector , tokenSource , nodeId } ) // 2. メディア接続を設定 const mediaConnection = createMediaConnection(iscpConn, { video : { codec : 'H264' , ... } , audio : { codec : 'PCM' , ... } , receive : { sourceNodeIds : [ 相手のノードID ] } } ) // 3. ローカルメディアを送信 const stream = await navigator .mediaDevices. getUserMedia ( { video : true , audio : true } ) await mediaConnection.sender.setLocalMediaStream(stream) // 4. リモート映像を表示 mediaConnection.receiver.on( 'statechange' , state => { if (state === 'running' ) mediaConnection.receiver.attach(videoElement) } ) // 5. 接続開始 await mediaConnection.start() 具体的な実装方法は後編で解説します。 ユースケース intdash-RTC SDKは、以下のようなユースケースで活用できます。 ビデオ通話・遠隔支援: 作業者同士のリアルタイムコミュニケーション、技術支援 遠隔監視: 現場の映像をリアルタイムで確認、必要に応じてセンサーデータも統合 データ収集: 映像とセンサーデータを時刻同期して収集・解析 おわりに Webアプリでリアルタイムな映像通信を実現するとき、WebRTCは有力な選択肢です。ビデオ会議やライブ配信など、多くのユースケースで実績があります。一方で、産業用途においてセンサーデータとの統合や録画・解析が求められる場合は、追加のシステム構築が必要になることがあります。 intdashは、そうしたニーズに対応した、WebRTCとは異なるアプローチの映像伝送プラットフォームです。Webアプリから利用する場合は、intdash-RTC SDKを使うことで、シンプルなインターフェイスでintdashの機能を活用できます。 次回の記事では、intdash-RTC SDKを使った具体的な実装方法をサンプルコード付きで解説します。「実際どれくらい簡単なの？」という疑問にお答えしますので、ぜひご覧ください。 本ライブラリは現在お問い合わせベースでの個別提供となっています。ご興味のある方は、お気軽に お問い合わせ ください。

WebRTCをテーマにした連載の最終回として、運用フェーズで重要となるパフォーマンス品質の測定と監視手法を解説します。WebRTCが提供する getStats() APIを用いた統計的分析と、Chromeのデバッグ機能 webrtc-internals によるリアルタイム監視の2つの方法を紹介。特に画面共有アプリケーションで重要となるフレームレート、解像度、CPU負荷などの観点や、確認すべき具体的なStats項目、 clumsy を用いたネットワーク劣化テストの実践的な確認方法にも触れます。

本ブログは株式会社電通総研とAmazon Web Services Japan が共同で執筆いたしました。 電通総研様が開発された リアルタイム 3DCG ソリューション「UNVEIL」 において、「1,000 名の同時接続」と「100〜500ms の低レイテンシー」という厳しい要件を、わずか約 1 ヶ月の準備期間で大規模 GPU 環境を構築し、乗り越えた事例をご紹介します。 まず、「UNVEIL」 についてご紹介します。「UNVEIL」とは電通総研様が開発されているブラウザでのリアルタイム 3DCG メタバース/仮想空間のソリューションで、現実に近い高品質な 3D 体験を、多人数同時参加で提供する商用向けサービスです。 (出展: 株式会社電通総研) お客様の状況と課題 電通総研様は、「UNVEIL」の商用展開に向けた取り組みの一環として、2025 年 12 月に実施された社内イベントでの活用を計画されていました。同イベントでは、1,000 名の同時接続と、レスポンス 100〜500 ms 程度という要件がありました。 課題は、 大規模な GPU 環境（ Amazon EC2 の g4dn 系、g5 系インスタンス）を効率的に構築する ことでした。イベント駆動型のワークロードであるため、コスト効率を保ちながら、必要な規模の環境を短期間で立ち上げる必要がありました。 戦略1: コスト最適化のためのリージョン選択 当初はアジアパシフィック (東京) リージョンで基盤を構築されていましたが、大規模な GPU 環境を構築するにあたり、 コスト効率 の観点から、海外リージョンの活用を検討しました。 Amazon EC2 の料金はリージョンによって異なるため、コスト効率の良い米国東部 (バージニア北部) リージョンと米国西部 (オレゴン)リージョンが候補として浮上しました。また、リージョンに依存しないアプリケーション設計を採用されていた点も、海外リージョンを選択できた大きな理由でした。 リージョン g5.xlarge のオンデマンド料金 ($/Hour) ※ アジアパシフィック (東京) 1.459 米国東部 (バージニア北部) 1.006 米国西部 (オレゴン) 1.006 ※ 2026 年 3 月時点の料金 戦略2: レイテンシーを考慮した実測テスト 海外リージョンを活用する際の最大の懸念は、日本からのアクセスにおけるレイテンシーでした。電通総研様は、 机上の計算だけでなく、実際のアプリケーションで測定する というアプローチを採用されました。 まず 米国東部 (バージニア北部) で検証を実施しましたが、日本からのアクセスでは遅延が大きく、ユーザー体験に影響があることが判明しました。次に米国西部 (オレゴン) で検証した結果、米国東部 (バージニア北部) よりもレスポンスが改善され、目標のレイテンシー数値に抑え、視聴体験を損なわない範囲に収まることを確認できました。この結果から コスト効率とレイテンシーの両面で最適な米国西部 (オレゴン) リージョンを採用 することが決定しました。 テストに向けた環境構築において、AWS の各リージョンで同一のサービスや API が提供されていたため、環境を別のリージョンへ再現することが容易でした。加えて、 Amazon EKS をはじめとするマネージドサービスを活用していたことで、リージョン間の環境移行も約 1 週間で完了し、迅速な検証が可能になりました。 戦略3: 複数回の事前テストによるリスク軽減 イベント本番での失敗を避けるため、 複数回のテスト を実施しました。数百台規模での動作確認を実施することで、以下のような潜在的な問題を事前に発見・対処することができました： 数百台規模のオートスケーリング起動が問題ないことの確認 (スケール起動検証) Service Quota の事前確認と調整 Amazon VPC の IP アドレス設計などインフラ面での考慮事項の確認 リージョンごとのレイテンシー特性の把握 また、大規模な GPU 環境を構築する際のキャパシティ確保の観点から、g4dn 系と g5 系の複数世代の GPU インスタンスタイプを混在させる構成を採用しました。単一のインスタンスタイプに依存せず、複数のインスタンスタイプを組み合わせることで、特定のインスタンスタイプで必要な台数が確保できない場合でも、他のインスタンスタイプで補完できる柔軟な環境を実現しました。 ソリューション概要 UNVEIL は、Amazon EKS を中心としたアーキテクチャで構成されています： フロントエンド: Amazon CloudFront + Amazon S3 による高速コンテンツ配信 アプリケーション層: Amazon EKS 上で動作する MatchMaker（ユーザーと GPU サーバーを割り当てる仕組み）、GPU サーバー、TURN/STUN サーバー 監視層: Amazon CloudWatch による包括的な監視 ユーザーは Amazon CloudFront 経由でアクセスし、MatchMaker が利用可能な GPU サーバーに割り当て、Unreal Engine でレンダリングされた映像を WebRTC 経由で配信します。 導入効果 2025 年 12 月のイベントでは以下の成果を得ることができました： 最大 1,000 台規模 GPU インスタンスを稼働 既存の東京リージョンと比較してコスト効率の良い環境構築を実現 電通総研様からは、「1,000 人規模のスパイクアクセスに対しても、インフラをオートスケーラブルに増減できることを検証できた点が大きな成果でした。未使用時にコスト増となり得る GPU リソースを、利用人数に応じて自動的にスケールできることを確認し、品質とコストの両立の可能性を示せました。また、事前検証によりボトルネックを特定できたことも、商用化に向けた重要な学びとなりました。一方で、アプリケーション面では大規模・多人数同時利用時の考慮が十分でなく、一部挙動が不安定となる課題も確認でき、改善項目として整理できました」とのコメントをいただきました。 大規模 GPU 環境構築の学び 今回のプロジェクトから得られた重要な学びをまとめます： 1. コスト最適化のためのリージョン戦略 海外リージョンの活用により、コスト効率の良い大規模 GPU 環境を構築できます。 2. 実測ベースの意思決定 複数リージョンで実際にレイテンシーを測定し、机上の計算だけでなく実際のアプリケーションでの検証が重要です。 3. 複数回の事前テストの重要性 複数回のテストを実施し、各テストでボトルネックを特定することで、イベント本番のリスクを最小化できます。また、g4dn 系と g5 系など複数世代の GPU インスタンスタイプを混在させることで、大規模環境でのキャパシティ確保の柔軟性を高めることができます。 4. イベント当日の運用設計 イベント開始前に十分な台数を確保し、Amazon CloudWatch による包括的な監視で問題の早期発見を実現します。 まとめ 今回は、電通総研様の UNVEIL において、大規模 GPU 環境を効率的に構築するための戦略的アプローチをご紹介しました。 電通総研様の「まず試してみる」という実践的なアプローチと、事前テストで計測したデータに基づく意思決定が、短期間でのシステム構築を可能にしました。大規模な GPU 環境を構築される際は、ぜひ今回ご紹介した戦略を参考にしていただければ幸いです。 AWS では定期的に技術イベントを開催しております。ぜひご参加ください。 https://aws.amazon.com/jp/events/ 執筆者 株式会社電通総研 事業開発室 姫野 智也氏、孫 辰氏 Amazon Web Services Japan: ソリューションアーキテクト 本多 和幸