配信のアップロード速度：ダウンロードが速くても分からないこと

この比較が特に役立つのは、ダウンロードが高速な範囲です。2026年10月1日には、ダウンロードが100 Mbps以上300 Mbps未満の採用ペアのうち、約4分の1でアップロードが14.128 Mbpsを下回りました。1週間後の割合はやや低く、23.4%でした。300 Mbps以上の速度帯でも、それぞれ9.6%と8.8%でした。

これらの割合は、日付と速度帯ごとに異なる分母を使っています。表では4つの速度帯すべてを示し、高速側の結果を全体の中で確認できるようにしました。ここでいう速度帯はダウンロードの実測値であり、契約プランに表示された速度ではありません。

両日とも、ダウンロード速度帯が高くなるにつれて、アップロードが14.128 Mbps未満となる割合は下がりました。この関係は参考になります。しかし、なお残る割合を見ると、ダウンロードだけの確認では十分な情報がそろわないと分かります。高速なダウンロード速度帯に入っていても、すべてのアップロード測定値が比較用のペイロードを上回ったわけではありません。

デモを準備する事業者にとって、次に役立つ行動は速度テストの両方の数値を残すことです。アップロードがダウンロードより大幅に低ければ、形式を変えたり別の接続に費用をかけたりする前に、実際の構成で予定する配信を確かめましょう。

何と比較するかが重要です。YouTubeのエンコーダー設定ガイドでは、1080p・毎秒30フレームのH.264映像に14 Mbps、ステレオ音声に128 Kbpsを推奨しています。合計すると14.128 Mbpsです。同じガイドには、この解像度とフレームレートに対する、より低いH.264映像の最低ビットレート5 Mbpsも記載されています。^[2]

エンコードした映像と音声の推奨値は、インターネット回線の最低速度とは異なります。今回の測定も、それとは別の量です。M-Labサーバーとの短時間のデータ転送を測っています。元データの速度はサーバー側のTCPバイト数と経過時間から計算され、YouTubeへの継続的な配信から求めたものではありません。^[3][6][7]

したがって、この表は2つの量の比較であり、合否判定ではありません。選んだペイロードを下回る測定値は、予定する構成を調べるきっかけになりますが、その配信が失敗することを示しません。上回っていても、イベントの成功を保証するものではありません。配信サービスまでの経路、イベント中の変化、ほかの通信、エンコーダーを動かす機器も関係します。

この区別は、予算を守るうえでも役立ちます。14.128 Mbpsを一律の購入条件と捉えると、実際の設定や動作を確かめる前にお金を使うかもしれません。比較値以上なら安心と捉えると、リハーサルを省くかもしれません。今回の測定からは、どちらの判断も導けません。

より役立つ順序は、必要な画質、動き、音声の設定を決め、ペイロードを記録し、実際の配信を試すことです。この分析では、帯域幅に掛ける一律の余裕率や、回線をアップグレードする推奨は設けていません。

結果が1つの比較設定に依存していないかも確認しました。追加の比較値として、同じYouTubeの表にある別の推奨エンコーダー設定から、10.128 Mbpsと17.128 Mbpsを事前に定めました。^[2] 全結果は分析資料からダウンロードできます。

100 Mbps以上300 Mbps未満のダウンロード速度帯では、低い比較値を使うと、下回る割合は10月1日に18.9%、10月8日に18.1%でした。高い比較値では28.0%と26.8%でした。分母は212,675ペアと194,290ペアのままです。300 Mbps以上の速度帯では、対応する割合は10月1日に7.9%から11.0%、10月8日に7.1%から10.2%で、分母は237,588ペアと221,617ペアでした。設定によって比較結果が変わるため、「配信」に対応する割合が1つあるわけではありません。

さらに、アップロードまたはダウンロードの要約値がゼロのペアをすべて除いて計算し直しました。元データの処理経路によっては最終測定値がないとゼロになるため、元のゼロ値が必ずしも「何も転送しなかった」証拠になるわけではありません。^[6] 100 Mbps以上300 Mbps未満では、10月1日は212,136ペア中51,313ペア（24.2%）、10月8日は193,832ペア中45,047ペア（23.2%）になりました。300 Mbps以上では、それぞれ236,909ペア中22,122ペア（9.3%）、220,928ペア中18,764ペア（8.5%）でした。ゼロを除いたことによる4つの主速度帯の割合の変化は、両日とも各速度帯で0.3ポイント未満でした。準備に関わる違いは残りました。

一方、あるサーバーソフトウェアのグループでは、より大きな変化がありました。バージョンv0.25.2でダウンロードが300 Mbps以上の速度帯では、アップロードが14.128 Mbps未満の割合が、10月1日の26,338ペア中4,803ペア（18.24%）から、10月8日の21,217ペア中1,418ペア（6.68%）へ下がりました。この違いは主要結果と合わせて読む必要があります。この分析の割合を、あらゆる計画に使えるルールにしてはいけない理由です。

ただし、ソフトウェアが変化の原因だったとは分かりません。日によって、ネットワーク、機器、経路、測定クライアントの構成が異なる可能性があります。同じクライアントが複数回、また両日とも現れる場合もあります。全体の数値だけに頼らず違いを確認できるよう、時間帯別、クライアントライブラリ別、サーバーバージョン別の内訳をすべて公開しています。^[1]

まず、アップロードの測定値を見えるところに残しましょう。いつ、どこで、どの機器と接続を使い、ネットワーク上でほかに何が動いていたかを書きます。後から結果を理解しやすくなり、ある場所の測定値を別会場の証拠として扱うことも防げます。

次に、実際の構成に最も負荷がかかる場面をリハーサルします。製品の操作説明なら、話しながら画面を共有し、カメラと製品画面を切り替える場面かもしれません。実物の実演なら、動きや細部を見せる接写が含まれるでしょう。予定するエンコーダー、アカウント、プラットフォーム、接続を使い、本番に関わる問いを確かめます。YouTubeも、本番を代表する音声と動きを使って試し、配信の状態を監視するよう勧めています。^[2]

リハーサルのメモでは、冒頭のカメラ映像、接写での実演、画面共有による操作説明、視聴者からの質問など、代表的な場面に名前を付けます。各場面の開始時刻と、観察者が見たり聞いたりして確認すべき内容を記録します。問題が起きたら、場面、時刻、見えた症状や聞こえた症状を残し、登壇者と観察者がメモを照合できるようにします。

観察したことと、原因の説明は分けてください。「画面共有中に映像が乱れた」は記録すべき観察です。「回線事業者が原因だった」は、追加の証拠が必要な診断です。M-Labの短時間の測定だけでは、配信サービスまでの別経路で起きた問題の原因は特定できません。

問題が見つかったら、予定する構成の一部を変えて再度試します。同じ場面を繰り返し、変更した設定、変わらなかった条件、各観察者が見たことを記録してください。別の機器がネットワークに加わったなど、避けられない違いも書きます。再テストで良くなれば、その試行について役立つ証拠になりますが、ほかの条件も変わっていれば原因を切り分けたことにはなりません。形式を変えたときは、前の結果に頼らず新しい形式を試します。

最後に、ライブデモが中断したら視聴者へ何を届けるか決めます。動画や手順書を準備しておけば、チームが中断に対応している間も説明を届けられます。本番中にその資料をすぐ使えるようにする担当者を決めてください。デモの準備には動画台本テンプレートが使えます。また、開発者向けマーケティングとドキュメントに関する当社の研究では、動画と一緒にどのような役立つ資料を置くかを扱っています。

5人の架空のソフトウェア企業が、新規ユーザー向けのライブ操作説明を準備しているとします。速度テストはダウンロード180 Mbps、アップロード11 Mbpsという設定です。これは準備シートの使い方を示す数字であり、M-Labデータで観測した企業ではありません。

チームはH.264映像を1080p・毎秒30フレーム、音声をステレオにする予定です。アップロードの測定値は、この研究で比較に用いた推奨ペイロード14.128 Mbpsを下回ります。チームはリハーサルのメモに、予定するエンコーダー設定と並べてアップロード値を記し、実演で観察したことと比較できるようにします。

本番と同じノートパソコン、接続、エンコーダー、進行順でリハーサルを予約します。1人が説明し、別の1人が視聴者側の画面を見て、3人目がプラットフォームの配信状態と、映像や音声の途切れを記録します。顧客が小さな画面表示を読む必要がある、画面共有の場面も含めます。

テスト前に、リハーサルが十分でなかった場合の対応を決めます。別の構成を意図的に選んで試し直し、ほかの形式が必要な場合に備えて短い動画と手順書を用意する計画です。ここではリハーサルの成功や性能の改善を仮定していません。まだない証拠を集める具体的な計画を立てたところで、例は終わります。

最初にイベントを記入します。登録せずに準備シート全体をイベントのメモへコピーし、台本と一緒に保管してください。対象の視聴者、会場、予定日と開始時刻、登壇者、視聴者側の画面を確認する同僚を書きます。特にはっきり見聞きしてほしい場面を決めます。

予定する構成を書きます。配信プラットフォーム、機器、エンコーダー、接続に続けて、解像度、フレームレート、映像コーデック、設定した映像・音声ビットレートを記録します。機器やネットワーク上で予定されるほかの利用も書き、リハーサルのメモで想定条件が分かるようにします。

速度確認の結果は別に残します。日付、時刻、場所、測定ツールと、ダウンロード・アップロードの両方の値を単位付きで記録してください。予定する配信構成と、測定時の条件がどう違うかも書きます。背景のない数値は、後から同僚が解釈しにくくなります。

リハーサルを記録します。動き、音声、画面共有を含め、実際に試した進行を明記してください。視聴者側の観察とプラットフォームの配信状態の観察は一緒に残します。設定を変えた場合は、次のテストで何が起きたかも書きます。これらの欄はテスト後に埋め、未確認の項目は未完了のまま示して担当者を決めてください。

配信方法を決めます。リハーサル後に選んだ形式と設定、その理由を記録してください。ライブデモが中断したときに使える代替資料と、変更を視聴者に伝える担当者を明記します。イベント後も役立つ説明を見られるようにしておきましょう。参加できなかった顧客向けに動画と関連リンクを整理する際は、YouTube概要欄テンプレートが使えます。

2026年10月1日・8日に位置情報で米国内と判定された記録について、公開のM-Lab NDT7 union viewを使いました。採用ペアは、同じ認可トークンとサーバー識別情報を持つアップロード記録1件とダウンロード記録1件から成り、開始時刻の差は60秒以内、両方とも選んだUTC日付内で開始したものです。時刻、接続識別子、ソースのバージョンも確認しました。^[1][3]

確認と無効な速度値の除外を経て、10月1日は745,186ペア、10月8日は698,882ペアを採用しました。アップロードまたはダウンロードの相手が欠ける記録は除外し、ゼロでは補っていません。表の各割合は、比較値を下回る件数を、その日付・ダウンロード速度帯の採用ペア数で割ったものです。

M-Labのアップロードとダウンロードを組み合わせ、測定の背景を検討する研究は既にあります。^[4] 今回の貢献は、配信準備の実務的な問いに対し、日付を明示して再現可能な比較を示したことです。選んだ測定データを記述するもので、米国の事業者やクリエイターに遅いアップロードがどれほど広がっているかを示すものではありません。

登録不要のダウンロードには、固定した分析計画、実際のクエリ、ソースの注記、全選定件数、両日それぞれに計画した264セルすべての結果を収録しています。^[8] 内訳は重複するため、264件の独立した研究ではありません。オフラインスクリプトは集計後の計算を再現します。元データへのクエリ再実行は別の作業です。次のデモで行うことは、もっと小さくまとまります。アップロード値を残し、実際のプレゼンテーションをリハーサルし、チームが観察したことから配信方法を決めてください。