配信サービスは帯域が肝。YouTube との併用を選んだ訳

ライブ配信の仕組みを自分のサーバーで作ると、最初に足りなくなるのは、サーバーからインターネットへ送る向き(上り)の帯域です。この記事では、必要な帯域の計算のしかた、VPS の回線の上限、YouTube Live の仕組みと決まりを、公式の情報で整理します。あわせて、編集部の運営会社が、自前の配信と YouTube の併用を選んだ理由を説明します。

配信は、上りの帯域で上限が決まる

帯域は、回線が 1 秒に送れるデータの量です。単位は bps(1 秒あたりのビットの数)で、100Mbps は 1 秒に 1 億ビットです。サーバーからインターネットへ送る向きを「上り」と呼びます。

ビットレートは、映像 1 本が 1 秒に使うデータの量です。配信のサーバーは、見る人ひとりずつに映像を送ります。見る人が増えると、その数だけ上りの帯域を使います。

• 3Mbps の映像を 100 人が同時に見ると、サーバーの上りは 300Mbps 要ります。
• 国内の VPS(仮想専用サーバー。1 台の仮想のサーバーを月額で借りるサービス)3 社の回線は、仕様では 100Mbps です。
• YouTube に映像を 1 本送り、YouTube から配ってもらうと、サーバーの上りは 1 本ぶんで済みます。

この連載の第 5 回Web はレンタルサーバーで十分。足りなくなる 4 つの場面では、配信は回線の太さで上限が決まることを紹介しました。この回では、計算のしかたと、YouTube と組み合わせる方法を説明します。

必要な帯域を計算する

計算に使う式は 3 つです。

• 必要な上りの帯域 = ビットレート × 同時に見る人数
• 同時に見られる人数 = 回線の上限 ÷ ビットレート
• 送るデータの量(GB) = ビットレート(Mbps)× 0.45 × 時間 × 人数

人数は、会員や登録者の数ではなく、同時に見る人数(同時視聴者数)です。0.45 は、1Mbps を 1 時間送ったときのデータの量(GB)です。1 バイトは 8 ビットなので、1Mbps は 1 秒に 0.125MB、1 時間で 450MB になります。

人数ごとに必要な帯域

• 1.5Mbps は、LiveKit(あとで紹介する配信サーバー)のドキュメントが、720p の映像の例に挙げている値です。
• 表の人数は、計算上の上限です。実際には、音声、通信の制御、ほかの通信の分だけ少なくなります。

ビットレートとデータの量を、実際に測る

編集部で、同じ 60 秒の映像(1280×720・30 コマ/秒)を 4 つのビットレートで書き出して、ファイルの大きさを測りました。映像の作り方は、あとの「映像に好きなものを重ねる」で紹介します。

• 映像 3Mbps のファイルは 23.1MB でした。音声と合わせたビットレートは 3.08Mbps で、「3.08Mbps × 60 秒 ÷ 8 = 23.1MB」の計算と合います。
• 1 時間に直すと、約 1.39GB です。100 人が 1 時間見ると、サーバーは約 139GB を送ることになります(音声を含めた実測の値です。映像の 3Mbps だけで計算すると、約 135GB です)。
• ビットレートを 2 倍にすると、データの量もほぼ 2 倍になります。画質を上げると、同じ回線で見られる人数は減ります。

自前の配信サーバーは、見る人ごとに写しを送る

自前のライブ配信の仕組みには、WebRTC(ブラウザやアプリの間で、映像と音声をリアルタイムにやり取りする仕組み)を使うものがあります。LiveKit は、WebRTC の配信サーバーを自分で動かせるオープンソースのソフトです(ライセンスは Apache 2.0)。公式の説明では、LiveKit のサーバーは SFU(Selective Forwarding Unit)という方式です。

• SFU は、配信する人から届いた映像を、中身を変えずに、見る人ごとに写して転送します(LiveKit のドキュメント)。配信する人が送るのは 1 本だけで、見る人への分はサーバーが送ります。
• 公式のベンチマーク(16 コアのサーバー)では、配信する人 1 人・見る人 3,000 人の 720p の配信で、サーバーが受け取る量は 1 秒に 233kB、送る量は 1 秒に 531MB でした。Mbps に直すと、約 4,200Mbps(4.2Gbps)です。
• 見る人 1 人あたりは、1 秒に約 177kB(約 1.4Mbps)です。100Mbps の回線に当てはめると、計算上は約 70 人です。

WebRTC は、遅れの小さいやり取りに使う仕組みです。LiveKit のドキュメントは、SFU を「低遅延で、帯域を多く使うメディアの転送に最適化した、専用のルーターのようなもの」と説明しています。出演者どうしが会話する配信や、見る人とすぐにやり取りする配信に向きます。そのかわり、見る人の数だけ、サーバーの上りを使います。

VPS の回線の上限と、転送量の扱い

国内の VPS 3 社の仕様(2026年10月12日に確認)は、次のとおりです。

• エックスサーバー VPS: インターネットの回線は「10Gbps共有（1契約あたり最大100Mbps）」、データ転送量は「無制限」です。
• ConoHa VPS: 「50Gbps共有(100Mbps制限あり)」、データ転送量は「課金無し、無制限。」です。有料の「ネットワーク帯域拡張」で、300Mbps(月 4,950 円)・500Mbps(月 7,920 円)・1Gbps(月 15,180 円)に広げられます。
• さくらの VPS: 「100Mbps共有回線」、データ転送量は「無制限」です。

クラウドは、考え方が逆です。AWS の EC2(東京)は、インターネットへ送った量に料金がかかります。1 か月 100GB までは無料で(AWS のすべてのサービスの合計)、その先は 10TB まで 1GB あたり 0.114 ドル、次の 40TB は 0.089 ドルです。

1 人に 3Mbps で、1 回 2 時間の配信を月 4 回行う場合を計算しました。

• VPS は、転送量の料金はかかりません。そのかわり、100Mbps の回線では 33 人が計算上の上限です。
• EC2 の料金は通信の分だけで、サーバーの料金は別です。無料の 100GB を、ほかの通信に使っていない場合の額です。

VPS とクラウドの料金の違いは、第 4 回クラウド vs VPS。AI の時代に VPS でクラウドは超えられるのかでくわしく比べています。

編集部の運営会社の例: 上りに上限があった

編集部の運営会社は、ある会社の会員向けアプリを開発し、運用しています。このアプリにはライブ配信の機能があり、配信のサーバーを VPS で動かしています。この仕組みでは、多くの人に同時に見せる配信の届け先として、YouTube を選びました。

送る向きは、約 92Mbps で頭打ちだった

• 運営会社が運用している VPS どうしでデータを写したとき、速さは 1 秒に約 11.5MB で頭打ちでした。Mbps に直すと、11.5 × 8 = 約 92Mbps です。回線の仕様の上限(100Mbps)に近い値です。どの組み合わせでも、どちらの向きでも同じで、4 本に分けて同時に送っても、合計は変わりませんでした(2026年9月28日の調査)。
• 同じ VPS が、外部の CDN(コンテンツを各地のサーバーから配る仕組み)からデータを受け取る速さは、1 秒に約 34MB(約 272Mbps)でした。受け取る向きは速いので、上限は送る側にあると見ています。
• 上りは、配信のほかの通信でも使います。この会員向けアプリのサーバーの上りは、ふだん 8.8Mbps、24 時間の 95% 値(95% の時間は、この値以下)で 30.5Mbps でした(2026年9月20日の記録)。配信に使えるのは、その残りです。

YouTube を選んだ 2 つの理由

1 つ目は、上りの帯域の上限です。仕様の 100Mbps いっぱいまで使えたとしても、1 人に 1.5Mbps で、計算上 66 人が上限です。自前のサーバーだけで多くの人に同時に配る形では、見る人が増えたときに足りなくなります。大勢に配るところを YouTube に任せれば、サーバーが送るのは 1 本ぶんで済みます。

2 つ目は、映像に好きなものを重ねられることです。YouTube へは、素材をまとめたあとの 1 本の映像を送ります。資料や文字などを、送る側で自由に重ねられます。重ね方は「映像に好きなものを重ねる」で説明します。

取引先の仕組みのため、構成の細部と画面は、この記事には載せていません。YouTube での公開設定や見せ方も、ここでは扱いません。あとの「気をつけること」は、YouTube を組み合わせるときの一般的な注意で、この取引先の使い方について述べたものではありません。

YouTube Live の仕組み

YouTube ヘルプによると、YouTube でライブ配信する方法は、ウェブカメラ・モバイル・エンコーダーの 3 つです。エンコーダーは、映像を配信用の形式に変換するソフトや機械です。エンコーダーを使うと、画面の共有、外付けのカメラやマイク、重ねる表示(オーバーレイ)が使えます。

エンコーダーで配信を始めるまでの流れを、YouTube ヘルプの手順から短くまとめました。

届いた映像は、YouTube が自動で変換します。ヘルプには「ライブ配信は YouTube によって自動的にコード変換され、さまざまな出力形式が作成されるため、多くのデバイスやネットワークで視聴できます」とあります。送る側は 1 本だけ送ればよく、視聴者の端末や回線に合わせて配るところは、YouTube が受け持ちます。

送るときのビットレートの目安

• H.264・H.265・AV1 は、映像を圧縮する方式(コーデック)です。
• ビットレートを一定にする方式(CBR)、キーフレームの間隔は 2 秒(4 秒以下)、音声はステレオで 128kbps がすすめられています。
• 送る側の回線の上りは、この値より太い必要があります。YouTube は、速度のテストで、上りのビットレートを確かめるようすすめています。

遅延の 3 つのモード

遅延は、カメラが映像を捉えてから、視聴者に表示されるまでの遅れです。エンコーダーの配信では、3 つのモードから選べます。

• 通常の遅延: 視聴者とやり取りをしない配信向けです。再生が途中で止まって待たされること(バッファリング)が最も少なく、画質がよいモードです。すべての解像度とライブ機能に対応します。
• 低遅延: やり取りが限られる配信向けです。通常は、遅延が 10 秒未満になります。4K には対応しません。
• 超低遅延: 視聴者と会話する配信向けです。通常は、遅延が 5 秒未満になります。4K には対応しません。視聴者の側で、再生が途中で止まることが増える可能性があります。

ウェブカメラとモバイルの配信では、遅延のモードは選べません。

自前の配信と YouTube Live を比べる

• 上りの帯域と人数: 自前の配信は、見る人の数だけ上りを使います。YouTube Live は、送るのが 1 本で、見る人が増えても送る側の帯域は変わりません。
• 遅延と、見る人のしぼり方: 自前の配信は、低遅延のやり取りに向き、見られる人を自分のサーバーで決められます。LiveKit では、自分のサーバーが作るアクセストークンを持つ人だけが、部屋に入れます。YouTube Live は、数秒の遅延があり、公開設定は公開・限定公開・非公開の 3 つです。
• 広告と決まり: YouTube Live は、広告が表示されることがあり、YouTube の規約とポリシーに従います。くわしくは「気をつけること」で説明します。

自前の配信と YouTube を組み合わせる

どちらか一方に決めずに、役割を分けて組み合わせられます。

• 自前の仕組み: 出演者どうしの映像と音声のやり取りや、配信の記録を受け持ちます。出演者のように人数が限られるやり取りなら、必要な帯域は小さく済みます。
• YouTube: まとめた 1 本の映像を受け取り、大勢に配ります。

YouTube へ送る方法は、2 つあります。

• エンコーダーから送る: OBS Studio などで素材を 1 本にまとめて、YouTube に送ります。上りを使うのは、送る人のパソコンと回線です。
• 配信サーバーの書き出しの機能から送る: LiveKit Egress は、公式の説明では、部屋の映像を MP4 のファイルや HLS(映像を短いファイルに分けて配る方式)に録画でき、RTMP で YouTube Live などの配信サービスに送ることもできます。この場合、サーバーの上りを 1 本ぶん使います。

見る場所は、YouTube か、埋め込みのプレーヤー

視聴者は、YouTube のアプリやサイトで見るか、Web ページやアプリに埋め込んだプレーヤーで見ます。埋め込みには、YouTube の「共有」→「埋め込む」で表示される HTML のコードを使います。

<iframe width="560" height="315"
  src="https://www.youtube-nocookie.com/embed/動画のID"
  frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

• youtube-nocookie.com は、プライバシー強化モードのアドレスです。このモードでは、埋め込みのプレーヤーで見た情報が、YouTube でのおすすめや広告のカスタマイズに使われません。Web サイト上の埋め込みだけで使えます。
• アプリに埋め込むときは、OS が用意する WebView(アプリの中で Web ページを表示する部品)を使います。
• 埋め込みには、HTTP リファラー(どのページから開いたかを伝える情報)を送ることが義務付けられています。送らないと、再生が止められて「エラー 153」が表示されます。
• 動画の側で「埋め込みを許可する」をオフにすると、外のサイトに埋め込めなくなります。

映像に好きなものを重ねる

YouTube に送るのは、素材をまとめたあとの 1 本の映像です。カメラの映像に、資料・文字・番組名の札などを重ねてから送ると、視聴者には重ねたあとの映像が届きます。

OBS Studio: ソースを重ねて、シーンにする

OBS Studio は、録画とライブ配信のための、無料でオープンソースのソフトです。Windows・macOS・Linux で動きます。公式サイトの最新版は 32.2.2 です(2026年10月12日に確認)。

• ソース: 画面に置く素材です。公式のナレッジベースには、音声、ブラウザ(Web ページ)、色、画面のキャプチャ、ゲームのキャプチャ、画像、メディア(動画や音声のファイル)、テキスト、映像キャプチャデバイス(Web カメラなど)、ウィンドウのキャプチャが載っています。
• シーン: ソースを並べて作る、1 枚の画面です。シーンはいくつでも作れて、配信中に切り替えられます。
• 重なる順番: ソースの一覧で上にあるソースが、画面では手前に重なります。公式の説明は、ゲームの画面の上に Web カメラの映像を出す例を挙げています。
• ブラウザのソース: OBS の中に Web ブラウザを置く機能です。公式の説明では、ふつうのブラウザで動くものは、ほぼそのまま OBS に足せます。背景は、初めの設定で透明になります。

配信の設定では、配信先のサービスを選んで、ストリームキーを入れます。映像のビットレートは、公式の説明では、回線の上りの速さと、配信先のサービスの制限に合わせて決めます。

LiveKit Egress: Web ページを、そのまま映像にする

自前の配信サーバーの側で重ねる方法もあります。LiveKit Egress の「部屋をまとめて書き出す」機能は、公式の説明では、次のように動きます。

• レイアウトは「テンプレート」と呼ぶ Web ページです。初めから用意されたものを使うほか、自分で作ることもできます。
• Egress が、画面を持たない Chrome でそのページを開きます。ページは部屋に入り、出演者の映像を並べて表示します。
• 表示された画面が、そのまま映像になります。MP4 のファイル・HLS・RTMP に出せます。

テンプレートは Web ページなので、Web ページに表示できるものは映像に入れられます。公式のドキュメントは、自作のテンプレートについて「どの映像を出し、どう並べ、ページをどう組むかを、すべて決められる」と説明しています。

編集部で試した: 5 つの素材を重ねる

重ねた結果が 1 本の映像になることを、ffmpeg(映像を変換する無料のソフト)で確かめました。素材の画像づくりから、ffmpeg のコマンド、ファイルの大きさの測定までを、編集部は Claude Code(AI に作業を任せる道具)で行いました。

• 素材は 5 つです。カメラの映像の代わりの絵、資料の画像、番組名の札、コメントの枠、下の帯の順に重ねました。背景が透明の画像は、下の素材が透けて見えます。
• 重ねた映像を、YouTube がすすめる方式(H.264・CBR・キーフレーム 2 秒・音声 AAC)で、1.5Mbps・3Mbps・5Mbps・8Mbps の 4 つのビットレートで書き出しました。
• 編集部の検証用のサーバーでは、60 秒の映像の書き出しに約 11 秒かかりました(GPU は使っていません)。
• 実際に YouTube へ送る試験は、していません。ここで確かめたのは、重ねた結果が 1 本の映像になることと、ビットレートとデータの量の関係です。

ffmpeg -loop 1 -framerate 30 -i camera.png -i slide.png -i banner.png -i comments.png -i telop.png \
  -f lavfi -i "color=c=0xdcf46f:s=1280x10:r=30" \
  -f lavfi -i "sine=frequency=330:sample_rate=44100,volume=0.08" \
  -filter_complex "[0:v]noise=alls=9:allf=t+u[bg];[bg][1:v]overlay=648:92[a];[a][2:v]overlay=32:28[b];[b][3:v]overlay=648:410[c];[c][4:v]overlay=0:612[d];[d][5:v]overlay=x='-W+t*W/60':y=710[v]" \
  -map "[v]" -map 6:a -t 60 -r 30 -c:v libx264 -preset veryfast -pix_fmt yuv420p \
  -b:v 3000k -minrate 3000k -maxrate 3000k -bufsize 6000k \
  -x264-params "nal-hrd=cbr:keyint=60:min-keyint=60:scenecut=0" \
  -c:a aac -b:a 128k -ac 2 -ar 44100 -f flv out.flv

気をつけること

ここからは、自前の配信と YouTube を組み合わせるときの、一般的な注意です。公式のヘルプ・利用規約・ポリシーに書かれていることをまとめました。

限定公開は、見せる相手をしぼる仕組みではない

• 限定公開は、リンクを知っている人が見られる設定です。検索結果やチャンネルの「動画」のタブには出ません。ただし、YouTube ヘルプには「共有相手は Google アカウントを持っていなくても動画を視聴できます。リンクを知っているユーザーは、その動画をさらに他の人と共有できます」とあります。
• ログインが必要なページに埋め込んでも、リンクが外に出れば、だれでも見られます。決まった人だけに見せたい内容には向きません。
• 非公開は、自分と、指定した人だけが見られます。相手のメールアドレスを入力して指定するため、大勢に見せる使い方には向きません。

広告が表示されることがある

• YouTube の利用規約には「お客様は、本サービスにおけるコンテンツの収益化に関する権利を YouTube に付与します」とあります。収益化には、コンテンツの上や中に広告を表示することが含まれます。規約は、利用者に支払いを受ける権利を与えるものではない、とも書かれています。
• YouTube ヘルプは、YouTube パートナー プログラム(収益を受け取るための制度)の要件を満たしていないチャンネルでも、一部の動画で広告の掲載を始めている、と説明しています。その広告からの収益の分配はありません。
• 埋め込みのプレーヤーでも、広告が表示されることがあります。YouTube が配信する広告を、変えたり、止めたりしてはいけません(API サービスのポリシー)。

埋め込みのプレーヤーの決まり

埋め込みのプレーヤーには、YouTube API サービスの利用規約とポリシーが適用されます。自分のサービスに埋め込む前に、次の決まりを確かめてください。

映像に重ねたいものは、プレーヤーの上ではなく、送る前の映像に入れます。

配信の内容と、止まることへの備え

• ライブで配信する内容は、YouTube のコミュニティ ガイドラインと利用規約に従う必要があります。
• YouTube は、独自の裁量で、ライブ配信の機能を制限する権利を持つとしています。違反警告を受けると、14 日間ライブ配信ができなくなります。
• ライブ配信を行うには、16 歳以上である必要があります。
• YouTube の側の都合で配信できないことに備えて、自前の仕組みだけで続ける手順も用意しておきます。

映像は、数秒遅れて届く

YouTube を通る映像には、遅延があります。超低遅延のモードでも、目安は「通常は 5 秒未満」です。文字のやり取りを自前の仕組みですぐに届けると、映像とのあいだに、その分のずれが出ます。出演者が見る人の書き込みに答える配信では、ずれを見込んで進めます。

選び方の流れ

• 回線に収まるなら、自前の配信だけで足ります。遅延が小さく、見る人をログインでしぼれます。
• 視聴に料金を受け取る配信や、決まった人だけに見せたい配信は、埋め込みの YouTube には向きません。回線を広げるか、配信を受け持つサービス(CDN など)を調べます。ConoHa VPS は、有料で 1Gbps まで広げられます。
• 広告が出ることがあることと、数秒の遅延を受け入れられるなら、YouTube と組み合わせます。サーバーが送るのは 1 本で、大勢に配れます。

まとめ

• 配信に必要な上りの帯域は「ビットレート × 同時に見る人数」です。国内の VPS 3 社の回線は 100Mbps で、1 人に 1.5Mbps でも、計算上 66 人が上限です。
• 転送量が無制限でも、1 秒に送れる量には上限があります。編集部の運営会社の測定でも、VPS の送る向きは約 92Mbps(100Mbps の上限に近い値)で頭打ちでした。
• YouTube Live に 1 本送って配ってもらうと、サーバーの上りは 1 本ぶんで済みます。送る前に、OBS Studio や配信サーバーの書き出しの機能で、映像に好きなものを重ねられます。
• YouTube を使うときは、限定公開の意味、広告、埋め込みのプレーヤーの決まり、数秒の遅延を確かめます。

次の回のAPI が ATM 化。自社のデータの出し入れに手数料がかかる時代へでは、クラウドから外へデータを出す料金や、SaaS の API の上限を整理します。サーバーの置き場所や費用の考え方は、連載「AIを動かす環境とコスト」のほかの回でも紹介しています。