100ms.liveとは？WebRTC・HLSのライブ動画SDKの料金と上限、導入手順【2026年9月】

100ms（100ms.live）は、ビデオ会議とライブ配信を自社アプリに組み込むための開発者向け動画基盤です。WebRTCによる双方向の通話と、HLSによる大人数向け配信を同じSDKとダッシュボードで扱えます。なお「100ms」は時間の単位としても使われ、その場合は100ミリ秒＝0.1秒を指します。この記事で扱うのは製品のほうです。

公式ドキュメントに載っている参加者数の上限、料金の従量単価、選べるデータ保管リージョン、サーバーでの認証トークン発行コードを、2026年9月15日時点の公式情報で整理しました。採用判断に使えるよう、向かない場面も書いています。

まとめ：100msで判断に使う数値と採用の分かれ目

• 2つの配信方式：WebRTCの会議は1秒未満の遅延、HLSのライブ配信は10秒未満の遅延（公式FAQでは平均10〜12秒）です。
• 上限：音声と映像を全員が出す会議は100人まで。登壇10人と視聴1,000人のウェビナー型、HLS視聴はチャット有効時5,000人が目安です。大規模ルームはsize 20,000まで広げられますが、配信権限を持てるのは200人までです。
• 料金：会議が参加者1人1分0.004ドル、HLS視聴が視聴者1人1分0.0012ドル。会議とHLS視聴はそれぞれ月10,000分まで無料です（HD画質の利用は無料枠の対象外）。
• リージョン：region codeはeu・in・us・autoの4つで、日本のリージョンはありません。
• 認証：クライアントはApp Token（JWT）で入室します。app_secretはサーバーだけに置きます。
• 向かない場面：国内だけで遅延要件が厳しい、HLSの10秒遅延では成立しない、長期の供給継続を契約で担保したい、のいずれかに当たるなら比較検証を先に行います。

以下、構成要素、上限、料金、実装、競合との違い、採用しないほうがよい場面の順に説明します。

100msの構成要素｜Room・Role・Templateと2つの配信方式

Room・Peer・Role・Templateの関係

100msのアプリはRoomを単位に動きます。公式ドキュメントの定義は次のとおりです。

設計で最初に決めるのはRoleです。Roleは「誰を見聞きできるか、どの品質で映像を出すか、映像や画面共有を配信できるか、他人をミュートやRole変更できるか」を定めます。講師と受講者、登壇者と視聴者のように権限の異なる参加者をRoleで分け、それらをTemplateにまとめてRoomに適用します。Templateには接続先の地域や入室時に録画を始めるかどうかも含まれるため、用途ごとにTemplateを1つ作るのが基本です。

WebRTC会議とHLSライブ配信の遅延差

公式のライブ配信ドキュメントは、参加者の関わり方を3段階に分けています。登壇者（On Stage・WebRTC）は全二重の音声と映像、ウェビナー型の視聴者（Off Stage・WebRTC）は1秒未満の遅延、HLSの視聴者（Off Stage・HLS）は10秒未満の遅延です。

ただし同じ公式サイトのFAQは、ライブ配信の平均遅延を「10〜12秒」としています。設計では10秒を上限と見るより、10秒を超えうる前提で置くほうが安全です。視聴者のコメントに登壇者が口頭で答える程度なら成り立ちますが、入札や早押しのように数秒の差で結果が変わる用途には向きません。その場合は視聴者もWebRTCのOff Stageで接続します。WebRTCの仕組みそのもの（ICE・STUN・TURN、SFUの選び方）はWebRTCの仕組みとSFU選定の解説で扱っています。

HLS配信は、会議の映像をサーバー側で合成してエンコードし、視聴者に配ります。録画を事前に有効にした場合は、配信開始と同時に録画が始まります。設定に応じてM3U8形式のVODやMP4を生成できます。会議そのものを録画する場合は、参加者ごとのトラック録画、参加者単位で音声と映像を結合する録画、Room全体を1本の映像にまとめる合成録画の3種類から選びます。YouTubeやTwitchなど外部サービスへはRTMPで送出できます。

公式ドキュメントに載っている参加者数の上限

100msの上限は、通常のルーム、ウェビナー型、HLS視聴、大規模ルームで値が変わります。JavaScript SDKの公式FAQと大規模ルームの公式ガイドから抜き出すと次のとおりです。

FAQは会議の上限を「アップロードするストリーム数とダウンロードするストリーム数の合計が10,000以下」とも説明しています。人数だけでなく、全員がカメラを出すかどうかで上限が変わるということです。

2,500人を超えるルームは、Room作成APIで large_room を true にしないとエラーになります。大規模ルームでは、音声・映像の配信権限を持つ参加者が200人までです。実際に配信中の人数だけを数える制限ではありません。同時に手を挙げられる人数も200人までです。さらにクライアント側の最適化は large_room を有効にしたときだけ働くので、参加者一覧や挙手の取得には大規模ルーム用のAPIを使います。後から「1,000人のウェビナーを3,000人に」と規模を広げると、クライアントの実装変更が発生します。

料金の仕組み｜無料枠と従量単価、月額の試算

公式の無料枠と従量単価

会議の単価は参加者1人ごとの分数にかかります。音声のみの用途は75%引きです。料金ページにはSD・HDの区分があり、公式FAQにはHD利用時は無料枠対象外との記述もあるため、画質ごとの単価と無料枠の適用条件は契約前に確認してください。サポートは有料プランが分かれており、Premiumは月1,500ドルか月間経常収益（MRR）の5%の高いほう、Enterpriseは月2,500ドルかMRRの8%の高いほうです。単価は変更されるので、契約前に100ms公式の料金ページで最新の値を確認してください。

会議型とHLS配信型の月額試算

以下は、SD画質で利用し、記載した単価と無料枠が適用され、同月にほかの利用がなく、有料サポートなどの追加費用を含めない場合の試算です。

ケース1：社内の定例会議。6人が60分の会議を月20回行うと、6人×60分×20回＝7,200分です。会議の無料枠10,000分に収まるので、請求は0ドルです。

ケース2：オンラインセミナーのHLS配信。登壇2人、視聴者500人、90分の配信を月4回行い、配信の全時間を録画する場合です。

• HLS視聴：500人×90分×4回＝180,000分。無料枠を引いた170,000分×0.0012ドル＝204ドル
• 登壇者の会議分：2人×90分×4回＝720分。無料枠内で0ドル
• エンコード：90分×4回＝360分。無料枠1,000分の内側で0ドル
• 録画：360分から無料枠300分を引いた60分×0.0135ドル＝0.81ドル

合計は月204.81ドルで、ほぼ全額がHLS視聴の分数です。HLS視聴費用は各視聴者の視聴分数の合計で決まります。見積もりでは「延べ視聴者数×平均視聴時間」を配信ごとに計算して月間で合算し、無料枠を差し引きます。常時配信のチャンネル型で総額がどう逆転するかは、ライブ配信システムの構築｜RTMP/SRT取り込みからLL-HLS配信・冗長化・費用設計までで自社構築と比べています。

導入手順｜App Tokenの発行からRoomへの参加まで

サーバー側のApp Token発行とJWT署名

100msの認証トークンは2種類あります。クライアントSDKがRoomに入るためのApp Token（Auth Token）と、サーバーからREST APIを呼ぶためのManagement Tokenです。どちらもダッシュボードで発行したアクセスキーとシークレットで署名するJWTで、シークレットやManagement Tokenをクライアントに渡してはいけません。ダッシュボードで生成するManagement Tokenの有効期間は既定で7日、設定できる最大値は14日です。

App Tokenのペイロードには access_key・room_id・user_id・role・type（値は app）・version（値は2）を入れ、HS256で署名します。公式サンプルは有効期間を24時間にしています。次のコードは外部パッケージのjsonwebtokenを使う公式サンプルを調整したもので、UUIDは uuid4 パッケージの代わりに node:crypto で生成しています。

const jwt = require('jsonwebtoken');
const { randomUUID } = require('node:crypto');

function createAppToken({ roomId, userId, role }) {
  const now = Math.floor(Date.now() / 1000);
  const payload = {
    access_key: process.env.HMS_ACCESS_KEY,
    room_id: roomId,
    user_id: userId,
    role,
    type: 'app',
    version: 2,
    iat: now,
    nbf: now,
  };
  return jwt.sign(payload, process.env.HMS_SECRET, {
    algorithm: 'HS256',
    expiresIn: '24h',
    jwtid: randomUUID(),
  });
}

const token = createAppToken({ roomId: 'room_abc123', userId: 'user-42', role: 'host' });
const decoded = jwt.verify(token, process.env.HMS_SECRET, { algorithms: ['HS256'] });
console.log(Object.keys(decoded).join(','));
console.log(decoded.type, decoded.version, decoded.exp - decoded.iat);

Node.js v26.5.0とjsonwebtoken 9.0.3で、ダミーのキーを環境変数に入れて実行した出力です。

access_key,room_id,user_id,role,type,version,iat,nbf,exp,jti
app 2 86400

expiresIn によって exp が付き、有効期間は86,400秒（24時間）になっています。role には、Templateで定義したRole名をそのまま入れます。存在しないRole名を入れると入室に失敗するので、ユーザーの権限からRole名を引く対応表をサーバー側に持たせます。

クライアントのRoom参加と認証方式

Webでは @100mslive/hms-video-store（2026年9月時点のnpm最新は0.15.0）を使います。Reactなら同じ日に公開された @100mslive/react-sdk 0.13.0、UIを作り込まないなら組み込みUIの @100mslive/roomkit-react があります。次のコードは、自社サーバーの /api/hms-token からトークンを受け取って入室する例と、ダッシュボードで発行したRoom Codeで入室する例です。

import {
  HMSReactiveStore,
  selectIsConnectedToRoom,
} from '@100mslive/hms-video-store';

const hms = new HMSReactiveStore();
hms.triggerOnSubscribe();
const hmsActions = hms.getActions();
const hmsStore = hms.getStore();

hmsStore.subscribe((connected) => {
  console.log('connected:', connected);
}, selectIsConnectedToRoom);

export async function joinRoom(userName: string) {
  const res = await fetch('/api/hms-token', { method: 'POST' });
  if (!res.ok) {
    throw new Error(`Token request failed: ${res.status}`);
  }
  const { token } = await res.json();
  if (typeof token !== 'string' || token.length === 0) {
    throw new Error('Token response is invalid');
  }
  await hmsActions.join({ userName, authToken: token });
}

export async function joinWithRoomCode(userName: string, roomCode: string) {
  const authToken = await hmsActions.getAuthTokenByRoomCode({ roomCode });
  await hmsActions.join({ userName, authToken });
}

window.addEventListener('beforeunload', () => hmsActions.leave());

このコードは @100mslive/hms-video-store 0.15.0に対して、TypeScript 7.0.2の tsc --strict --skipLibCheck で型検査を通したものです（アクセスキーを使った実接続は行っていません）。--skipLibCheck を外すと、SDKに同梱された型定義 notification.d.ts の重複定義でTS2300エラーが出るため、プロジェクトの設定でも同じ指定が必要です。Room Codeを使う方法はトークンサーバーを用意せずに試せるので、検証段階はRoom Code、本番は自社サーバーでのApp Token発行と使い分けます。iOS・Android・Flutter・React NativeのSDKも公式に提供されており、iOS SDKは2026年9月7日に1.17.3が公開されています。

データ保管リージョンとセキュリティ認証

Room作成APIで指定できるregion codeは eu（欧州連合）、in（インド）、us（米国）、auto（Templateの設定に従う）の4つです。ワークスペースのデータ保管先もUSA・Europe・Indiaの3地域から選び、最初のワークスペースは登録時に最も近いサーバー地域が既定になります。日本や東アジアを示すregion codeは用意されていません。

通信は、音声・映像・画面共有をSRTPで送り、DTLS上のAES 256ビットで暗号化すると公式のセキュリティページに書かれています。音声や映像を100msが保存するのは、利用者が録画を明示的に依頼した場合だけです。認証面では、Security・Confidentiality・AvailabilityについてSOC 2 Type IIの証明を取得しており、監査報告書はNDAを結べば請求できます。医療向けにはHIPAAに対応したアプリを作る仕組みを用意し、顧客企業とBAA（Business Associate Agreement）を結ぶと表明しています。オンライン診療のように医療情報を扱う用途では、BAAを結べるかどうかが選定の条件になることがあります。

Agora・Daily・LiveKit・Twilio Videoとの料金と条件の違い

同じ用途で比べられる主なサービスの、公式料金ページに載っている条件です。

この表で単価を横並びにして安い順を決めるのは避けてください。Agoraの料金ページ冒頭に出る「1,000分あたり0.59ドルから」は、Low Latency配信で音声だけを受ける視聴者向けの料金です。ビデオ通話のVideo HDは1,000分あたり3.99ドルなので、映像の比較にはこちらを使います。LiveKitのShipプランは月額50ドルにWebRTC 150,000分を含み、超過は1分0.0005ドルです。下りデータ転送は別枠で250GBまで含まれ、超過は1GBあたり0.12ドルなので、映像用途では転送量も試算します。分数の数え方（参加者ごとか、接続ごとか）も各社で違うため、自社の想定人数と時間でそれぞれ試算します。

Twilio Videoについては、2023年に終了方針（EOL）が告知され、「Twilio Videoは終了する」と書いた日本語記事がいまも残っています。しかしTwilioは2024年10月21日にこの決定を撤回し、単独の製品として継続すると発表しました。現行のFAQでも、新規顧客を受け入れて新機能を出していると明記しています。100msとの比較でTwilio Videoを外す理由にはなりません。

選定の分かれ目は料金より機能の範囲です。100msはHLS配信・録画・RTMP送出・文字起こし・ホワイトボードを1つの管理画面にまとめている点が強みで、会議とセミナー配信を同じ製品で扱いたい場合に向きます。音声通話だけの用途や、SDKを使わず自前で組む選択肢との比較はボイスチャットの実装方法｜WebRTCで音声通話を作る手順とSDK選定、AWS上で配信する場合の選択肢はAmazon Interactive Video Service（IVS）とは何か？特徴と概要を徹底解説で扱っています。

100msを採用しないほうがよい4つの場面

国内ユーザーだけで遅延要件が厳しいサービス

region codeにあるのは欧州・インド・米国の3地域だけです。利用者がほぼ日本国内に限られ、会話の遅延を体感できるほど厳しく求める用途（遠隔の合奏、発話が重なりやすい少人数会議など）では、実際に接続されるサーバー地域と往復遅延を検証期間中に測ってから決めます。測らずに「WebRTCだから低遅延」と判断するのは危険です。

10秒の遅延で成り立たない大人数配信

HLSを選ぶ場合は10秒前後の遅延を見込みます。ただし、視聴者が1,000人を超えてもHLSが必須になるわけではなく、大規模ルームによるWebRTC構成も検討対象です。ライブコマースの限定販売やオークション、クイズの早押しのように、視聴者の操作が数秒以内に反映される必要がある用途は、HLSでは成り立ちません。WebRTC構成で必要な遅延と視聴者数を満たせるか検証します。FAQの1,000人構成を超える場合は、大規模ルームの配信権限人数や購読数の条件を確認し、要件を満たさなければ別の基盤を比べます。

ベンダーの長期的な供給継続を重く見る案件

100msの会社概要ページには、動画基盤の説明と並んで「100ms.aiで医療業務向けのAIエージェントを開発している」と書かれています。一方で、Web SDKのリポジトリには2026年9月14日にもコミットがあり、iOS SDKも9月7日に更新され、ステータスページも稼働を示しています。動画基盤の開発が止まったわけではありません。ただ、10年単位で使い続ける基幹システムに組み込むなら、SLAの条件と契約終了時のデータ持ち出し方法を事前に確認します。SDKの呼び出しを自社のラッパーに閉じ込めて、乗り換えられる設計にしておくのが現実的です。

後から参加者の上限を大きく超えそうな設計

全員がカメラを出す会議は100人、通常のルームは2,500人が上限で、それを超えると大規模ルームへの切り替えとクライアント側の実装変更が要ります。大規模ルームでも配信権限を持てるのは200人までです。数百人が同時に音声・映像を配信する要件なら、100msの配信権限人数の制限に照らし、登壇者の交代制やルーム分割、別サービスの採用を検討します。リアルタイム通信の方式の違いはSSEとWebSocketの違いと使い分け｜WebRTC・WebTransportまで性能比較も参考になります。

よくある質問

100msは何秒ですか？

時間の単位としての100msは100ミリ秒で、0.1秒です。この記事で扱っている100ms（100ms.live）は、ビデオ会議とライブ配信のSDKを提供する製品の名前です。

100msは無料で使えますか？

毎月、ビデオ会議10,000分とHLS視聴10,000分、HLSエンコード1,000分、録画300分までは無料です。ただし公式FAQによると、HD画質で使った分には無料枠が適用されません。超過分は会議が参加者1人1分0.004ドル、HLS視聴が視聴者1人1分0.0012ドルで課金されます。

100msのルームには最大何人まで参加できますか？

全員が音声と映像を出す会議は100人、通常のルームは2,500人までです。large_room を有効にした大規模ルームはsizeを20,000まで設定できますが、音声と映像の配信権限を持てる参加者は200人に限られます。

WebRTCとHLSのどちらで配信すればよいですか？

低遅延のやり取りが必要ならWebRTC、一方向の大人数配信で10秒前後の遅延を許容できるならHLSが候補です。1,000人を超える場合も、WebRTCの大規模ルーム構成を検討できます。HLSの視聴上限はチャットありで5,000人、チャットなしで50,000〜100,000人が公式の目安です。

Twilio Videoは終了したのですか？

終了していません。Twilioは2023年に告知した終了方針を2024年10月21日に撤回し、単独の製品として継続すると発表しました。現行のFAQでも新規顧客を受け付けています。

関連記事

• WebRTCとは？P2Pの仕組み・ICE/STUN/TURNからSFU選定・実装・運用判断まで実装者向けに解説
• ボイスチャットの実装方法｜WebRTCで音声通話を作る手順とSDK選定
• ライブ配信システムの構築｜RTMP/SRT取り込みからLL-HLS配信・冗長化・費用設計まで
• Amazon Interactive Video Service（IVS）とは何か？特徴と概要を徹底解説
• SSEとWebSocketの違いと使い分け｜WebRTC・WebTransportまで性能比較