「この業務を回すのに、回線はどれだけ要るのか」——見積りの骨格は驚くほど単純で、1件あたりのデータ量 × 件数 ÷ かける時間、これだけです。ところが実際に数字を出すと、8倍ずれる・混む時間に破綻する・思ったより速くならないといった外し方をします。ずれる場所は毎回ほぼ同じなので、骨格よりも落とし穴を覚えるほうが得点になります。
混ざりやすい3語を分けます。帯域（通信速度）は1秒あたりに流せる量で、単位はビット毎秒（bit/s）。スループットは実際に流れた（処理できた）量で、帯域より必ず小さくなります。応答時間は依頼してから答えが返るまでの時間で、待ち時間＋処理時間＋伝送時間＋往復の遅延の合計です。「たくさん流せる」ことと「1件が速く返る」ことは別の指標で、ここを混ぜると設計を誤ります。
必要な帯域の出し方
手順は3つだけです。
① 1件の量を決める
- 1件（1画面・1伝票・1明細）で運ばれるバイト数を押さえる。
- 本体だけでなく付随して流れるもの（応答、確認、再送）も数える。
② 件数を決める
- 対象人数 × 1人あたりの回数、のように掛け算で件数に落とす。
- ここで使うのは平均ではなく混む時間の件数。
③ 時間で割る
- 「1時間で」なら3600で割って1秒あたりにする。
- 最後にバイトを8倍してビットへ直す。
式にすると 必要帯域(bit/s) ＝ 1件のバイト数 × 8 × 件数 ÷ 秒数。たとえば1件20kバイトのやり取りを、混む1時間に18,000件こなすなら、20,000×8×18,000÷3,600＝800,000ビット毎秒＝0.8Mビット毎秒。ここに後述のオーバヘッドと余裕を足したものが、実際に用意すべき回線です。逆に「用意した帯域で何件さばけるか」を問われたら、同じ式を件数について解き直すだけです。
数え方の落とし穴
点が動くのはここです。4つとも「式は合っているのに答えが違う」を生みます。
| 落とし穴 | ずれ方 | 外さないための確認 |
|---|---|---|
| バイトとビット | 8倍ずれる | データ量はバイト（B）、回線速度はビット毎秒（bit/s）で書かれるのが普通。大文字Bと小文字bを必ず読む。答えの桁が8倍ずれていたらまずここを疑う。 |
| ピークと平均 | 数倍ずれる | 1日の総件数を24で割った平均で設計すると、始業直後や締め処理の時間に破綻する。混む時間帯に何件来るかで計算する。「1日◯件」と与えられ、別の場所に「うち◯割が午前中に集中」と書いてあるのが典型。 |
| オーバヘッド | 1〜数割ずれる | 回線を流れるのは中身だけではない。各階層のヘッダ、確認応答、再送、接続の確立や暗号化のやり取りが上乗せされる。小さいデータを大量にやり取りするほどヘッダの比率が上がる。問題文に「伝送効率◯％」「制御情報が◯％」とあれば、その分で割る。 |
| Kは1000か1024か | 2.4％ずつずれる | 記憶容量は1024倍、通信速度は1000倍で数える慣習がある。選択肢が僅差で並んでいたら、出題者はここを見ている。問題文の指定が最優先で、指定があればそれに従う。 |
4つのうちバイト／ビットとピーク／平均は答えが大きく動くので、計算を始める前に必ず確認します。順序としては①単位をそろえる → ②ピーク件数に直す → ③オーバヘッドを乗せる → ④余裕を足す。この順に固定しておくと、途中で迷いません。
帯域を倍にしても、応答時間は半分になりません。応答時間の内訳は待ち時間＋処理時間＋伝送時間＋往復の遅延で、帯域を増やして縮むのは伝送時間（＝データ量÷速度）だけです。処理時間はサーバ側の都合、往復の遅延は距離と経路の都合なので、帯域では動きません。とくに小さいデータを何度もやり取りする処理は、時間のほとんどが往復の遅延で占められているため、回線を太くしてもほぼ変わらない——「増速したのに体感が変わらない」という相談の正体はたいていこれです。効くのは往復回数を減らす（まとめて送る・手元に持つ）ことのほう。逆に大きなファイルを一度に運ぶ用途なら伝送時間が主なので、帯域増強はよく効きます。どの成分が支配的かを先に見極めるのが順序です。
利用率と待ち時間
もう一つの本体が待ち行列の考え方です。処理する側が1つの窓口だとして、利用率（＝どれだけの時間ふさがっているか）が上がると、待ち時間は比例ではなく加速度的に伸びます。目安として、待ち時間はおおよそ利用率 ÷（1 − 利用率）に比例して増えます。数字を入れると効き方が見えます。
| 利用率 | 待ち時間の目安（処理時間の何倍） | 状態 |
|---|---|---|
| 50％ | 1.0倍 | 余裕がある |
| 80％ | 4.0倍 | 目に見えて遅くなる |
| 90％ | 9.0倍 | わずかな増加で崩れる |
| 95％ | 19.0倍 | 実質的に破綻 |
利用率が50％から80％へ上がるのは「1.6倍の仕事」ですが、待ち時間は4倍になります。100％に近づくと分母が0に近づき、待ち時間は発散します。余裕（バッファ）を持たせる理由はここです。「平均でちょうど処理できる能力」を用意すると、到着はばらつくので必ず行列ができ、しかも一度伸びた行列は簡単には解消しません。だから見積りではピークでも利用率が一定以下に収まるように能力を決め、さらに将来の増加分を上乗せします。この性質は回線でも同じで、帯域の使用率が高止まりしている回線は、平均では足りていても遅いのです。
設問は「なぜ余裕を持たせるのか」と「どの数字を使って計算したか」を突いてきます。前者の答えは利用率が上がると待ち時間が急激に伸びるから（比例ではない、が言えること）。後者は、問題文に平均とピークの両方の数字がわざと置かれていることが多く、ピークで計算しているかが採点の分かれ目になります。さらに一段深いのが「その増強で本当に速くなるか」という問い。ボトルネックが回線でないなら帯域を増やしても効かず、先に測って、支配的な成分を特定してから手を打つのが筋です。記述では「ピーク時の◯件を基準に、伝送効率と将来の増加分を考慮して算出した」のように使った前提を明示すると通ります。
サーバ側の見積り
回線が足りていても、処理する側が詰まれば同じことです。サーバ側は3つの数字の関係で押さえます。
- スループット：単位時間に処理できる件数。同時に処理できる数 ÷ 1件の処理時間で決まる。1件0.05秒の処理を同時4本さばけるなら、毎秒80件が上限。
- 同時接続数：ある瞬間に処理中・待機中の件数。到着率 × 滞在時間とほぼ等しくなる（毎秒100件が来て1件0.5秒滞在するなら、常時およそ50件が中にいる）。
- 応答時間：上の関係から、処理能力に対して到着が増えるほど待ちが伸びて延びる。応答時間の目標を先に決め、そこから逆算して必要な処理能力を出すのが実務の順序。
ここでも数え落としが起きます。1画面が1件とは限らない——画面を構成する部品ごとに要求が飛べば件数は何倍にもなりますし、裏で走るバッチや集計、監視の通信も同じ資源を食います。また、能力を増やすときはどこを増やすかで効き方が違う点に注意します。処理が資源の奪い合いで詰まっているなら台数を増やしても伸びず、直列で詰まっている一点（＝ボトルネック）を外さないと全体は速くなりません。ボトルネックを解消すると次のボトルネックが現れるのも常で、見積りは一度きりでなく測る→直す→また測るの繰り返しになります。
混同しやすい仕組みを1行ずつ。優先制御は「足りないときに何を先に通すか」の配り方の話で、いくら要るかを出すこのページとは目的が違います。負荷分散は用意した能力を複数台へ振り分ける手段で、これも総量の見積りが先。可用性の指標（止まらないこと）は速さとは別の軸で、混ぜて語らないのが安全です。