ZoomのRealtime Media Streamsは、bot をルームに参加させることなく、WebSocket経由でミーティングの音声・映像・文字起こしを配信します。RTMSとミーティング botの実際の比較、そして両方を併用することになる理由を解説します。

LLazare Rossillon
··5 min read
Zoom RTMS vs ミーティング bot：リアルタイムメディアストリームが変えること（変えないこと）

Zoomは2026年を通じて、開発者がミーティングデータにアクセスする方法を大きく見直しています。まず3月にOBF token要件が導入され、外部ミーティングへの bot 参加方法が厳格化されました。続いてZoomはRealtime Media Streams（RTMS）を公開しました。これは、セキュアなWebSocket経由でZoomミーティングのライブ音声・映像・参加者ごとのメディア・文字起こしをストリーミングするデータ pipeline であり、ルームに bot 参加者は一切不要です。

Zoomの主張は明確です。「怪しい、紛らわしい bot がミーティングに参加することはもうありません。」では、bot モデルは終わったのでしょうか？まったくそうではありません。しかし正直な答えは、どちらの極論よりも興味深いものです。

RTMSとは何か

RTMSはアプリに対して、Zoomミーティングのメディアへの直接アクセスを構造化されたストリームとして提供します。具体的には、参加者ごとの音声・映像、文字起こしデータ、参加者イベントが、ミーティング実行中にWebSocket経由で配信されます。自動化されたクライアントが通話に参加することはなく、データはZoomのインフラ自体から提供されます。

これはいくつかの点でbotよりも優れています：

  • 参加者が表示されない: 待合室から承認するものも、ギャラリータイルを占有するものもありません。ただし、Zoomはアプリがミーティングにアクセスしている間、標準的な「このミーティングのコンテンツが1つ以上のアプリと共有されています」という開示を表示し、アプリアクティビティ通知を表示する場合があります
  • 参加者ごとのストリーム: 混合録音を話者分離するよりもクリーンな分離が可能です
  • 参加の信頼性問題がない: 参加に失敗するクライアントが存在しません

RTMSが解決しないこと

  • Zoomのノーパーティシパントモデルに匹敵するものはありません。 Google MeetにはDeveloper PreviewのMedia APIがあり、Microsoft TeamsにはReal-Time Media Platformがあります。どちらも生ストリームへのアクセスを提供しますが、どちらも通話に参加するbot的なクライアントが必要です。MicrosoftはAIエージェントのユースケースをそこから明示的に遠ざけています。ZoomのRTMSは、3つの中で唯一、何も参加せずにストリームを提供するものです。参加者なしのキャプチャのみで構築されたプロダクトは現在1つのプラットフォームしかカバーしませんが、ミーティングbot APIは1つの統合で3つすべてをカバーします。
  • Zoom側でのアプリ設定が必要です。 RTMSは、適切なスコープとアカウントレベルの有効化を備えたZoomアプリを通じて実行されます。これは、ゲストとしてのbot モデルが回避するような、テナントごとの設定です。
  • 録画の成果物はあなたの責任です。 RTMSはストリームを提供します。そこから録画、文字起こし、検索可能なアーカイブを組み立てることは、あなたが構築・運用するインフラです。
  • 招待されたミーティング。 botモデルのコアユースケース——ユーザーが他の組織で参加するミーティングを録画する——は、いずれにしてもホストのプラットフォームと設定に依存します。Zoomでは、実装が分岐するのもここです。ZoomのMeeting SDKで構築されたbotは、外部ミーティングに対してOBF認証が必要であり、認証ユーザーが参加し続けることが求められます。特定のベンダーがその制約にどれだけ影響を受けるかは、botが実際にどのように通話に参加するかによって異なります。そして、あなたのプロダクトがZoomの同意画面を構築する必要があるかどうかは、すべての実装で必要なわけではないため、直接確認する価値があります。

RTMSはZoomにのみ対応しており、目に見えるbotはありません。botモデルは、現在Zoom、Google Meet、Microsoft Teamsに対応している唯一の手段です

現実的なアーキテクチャ：両方を活用する

2026年にミーティング製品を開発しているチームは、ハイブリッドな方向に収束しています。RTMSが利用可能で有効な場合はRTMSを使用し、それ以外ではbotを使用するというアプローチです。Meeting BaaSでも同様の立場をとっています。現在Zoom、Google Meet、Microsoft Teams向けのbotを提供している同じAPIに、ZoomがRTMSを展開するにつれてRTMSベースのキャプチャが統合されますが、既存のインテグレーションを変更する必要はありません。

今すぐ3つのプラットフォームすべてでライブのミーティングデータが必要な場合、リアルタイムストリーミングはすでにbot自体からWebSocketsを通じてライブ音声と文字起こしを提供しています。これはRTMSが提供を約束しているデータと同じ形式であり、単一プラットフォームという制約もありません。

今日取るべき行動

  1. Zoomのみ、エンタープライズ向け、テナント管理が必要な場合？ RTMSを注視してください。これはZoomが公式に推奨するパスであり、積極的な投資が続いています。
  2. クロスプラットフォームで構築している場合？ botモデルが引き続きメインのインテグレーション手段です。1つのAPI、3つのプラットフォーム、テナントごとのZoomアプリのデプロイも不要です。
  3. すでにZoom上でbotを運用している場合？ OBFへの対応を確認してください。これはすでに期限（2026年3月2日）が過ぎた、厳格な締め切りのある変更です。

次のステップ

関連ブログanalysis