基本情報 平成29年度 春期 問31：テクノロジ系に関する問題

答えは a「50秒」 です。

音声を再生する速度は 192kbps（毎秒192kビット必要）、ネットからダウンロードできる速度は 128kbps。

再生のほうが速いので、再生中も毎秒 192−128 = 64kビットずつ不足します。

全体で 2.4MB = 2400×8 = 19200kビット 必要。

途中で途切れないには、再生に「先回り」して 64kbps × 必要秒数分 を貯めておく必要があり、計算すると 50秒バッファすればOK。

👉 覚え方：不足分の速さ × 秒 ＝ 貯める量 で逆算！

なぜこれが正解か

正解は a。再生時間と単位を揃えて計算する。

• 全データ量：2.4Mバイト = 2.4×8 = 19.2Mビット = 19200kビット
• 再生時間：19200 ÷ 192 = 100秒
• ダウンロード時間：19200 ÷ 128 = 150秒
• 不足時間：150 − 100 = 50秒分のデータを事前にバッファしておけば、再生終了とダウンロード完了が同時になり途切れない。

別解（不足速度から計算）

毎秒の不足量＝192−128＝64kビット。再生100秒なら不足総量 = 64×100 = 6400kビット。これを事前に128kbpsで貯めるには 6400÷128 = 50秒。

各選択肢の解説

• a：50秒 → 正解。
• b：100秒は再生時間そのもの。
• c：150秒は全ダウンロード時間。
• d：250秒は150+100の誤加算。

覚え方・ひっかけ注意

バイト→ビット変換（×8）を忘れない。バッファ秒数 = ダウンロード時間 − 再生時間 がストリーミング系問題の鉄則式。

理論的背景

プログレッシブダウンロード型ストリーミングでは、再生レート R_p と配信レート R_d の差をプリバッファで吸収する。途切れない条件は

バッファ量 B ≥ (R_p − R_d) × T_play （R_p > R_d のとき）

本問は R_p=192kbps, R_d=128kbps, T_play=100s → B ≥ 64×100 = 6400kビット。これを R_d で先行受信する時間は B/R_d = 6400/128 = 50s。

実用システムとの対応

• HLS / MPEG-DASH：適応ビットレート（ABR）で R_p を動的調整しスタベーション回避。代表的アルゴリズムにBOLA（buffer occupancy based）とMPC（model predictive control）。
• YouTube / Netflix：CDNエッジサーバから配信し R_d を確保。バッファ目標は数十秒〜数分。
• WebRTCリアルタイム通信：プリバッファ余裕が小さい（遅延優先）ため、R_p < R_d を厳守する設計（フォワードエラー訂正・パケットロス耐性で補う）。

試験での位置づけ

FE「ネットワーク／マルチメディア」分野の計算問題頻出パターン。類題に「動画ストリーミング」「ファイル転送時間」「圧縮率と通信時間」がある。応用情報・ネットワークスペシャリストではジッタバッファ、QoS、輻輳制御まで発展。

帯域とビットレートの単位

本問の「k」は通信分野慣例の10進キロ（=1000）。情報量（バイト容量）でも近年は10進が標準（IEC 80000）。混在表記は計算ミスの元なので注意。

選択肢の発展補足

b (100秒) を選んでしまう人は「再生時間ぶん貯める」と早合点する典型ミス。c (150秒) は全ダウンロード時間で、バッファ量ではなく完了時刻。d (250秒) は累積誤算。バッファ＝差分 という観点が物理的に正しい。