ネットワークの性能・帯域要件とは？通信量・遅延・ロスを要件定義で整理する方法

2026年8月11日

ネットワーク上級編 05／全70記事

この記事は、「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」の第5回です。

第1章では、顧客の要望を整理し、ネットワーク設計で判断できる具体的な条件へ変換する 要件定義を学びます。

NETWORK ADVANCED｜CHAPTER 1 REQUIREMENTS

性能・帯域要件の整理｜「ネットワークを速くしたい」を設計条件へ変える方法

「ネットワークが遅いので速くしたい」「Web会議が途切れないようにしたい」「将来クラウド利用が増えても困らないようにしたい」。こうした要望をそのまま設計することはできません。性能要件では、通信量・帯域だけでなく、遅延・ジッター・パケットロス・利用時間帯・将来増加まで整理し、設計や試験で確認できる条件へ変換します。

対象レベル Level 3〜4・上級

想定読了時間 約25分

身につく成果 性能要望を数値・条件へ整理できる

前提知識 要件定義・通信量の基礎

演習環境 ブラウザ・Excel等

性能要件を考えるとき、 「何Gbpsの回線にするか」から考え始めてはいけません。

先に確認するのは、どの業務・アプリケーションを、何人が、いつ利用し、どの程度の通信品質が必要なのかです。

その条件を整理してから、必要な回線帯域や機器性能、QoSなどを基本設計で検討します。

この記事を読み終えるとできること

性能要件と帯域要件の意味を説明できる
帯域だけでは通信品質を判断できない理由を説明できる
平均値とピーク値を区別して確認できる
遅延・ジッター・パケットロスを要件として整理できる
利用アプリケーションから性能条件を整理できる
将来の通信量増加を考慮できる
要件と具体的な設計方式を分離できる
性能要件を要件定義書へ記録できる

性能・帯域要件とは何か

最初に覚える定義

性能・帯域要件とは、ネットワーク上で必要な通信を、必要な速度・品質で処理するために満たすべき条件です。

顧客から次のような要望を受けることがあります。

顧客：
「最近ネットワークが遅いので、新しいネットワークでは快適に使えるようにしてください。」

しかし、「快適」「高速」「遅くならない」という言葉だけでは設計条件になりません。

少なくとも、次のような情報を確認する必要があります。

何のアプリケーションが遅いのか
何人が同時に利用するのか
どの時間帯に遅くなるのか
現在どの程度の通信量が発生しているのか
平均値とピーク値はどの程度か
どの区間で通信量が増えているのか
遅延やパケットロスが発生していないか
今後利用者や通信量がどの程度増えるのか

「速いネットワーク」は要件ではありません。

「何を、どの程度の通信品質で利用できる必要があるのか」まで具体化して初めて、設計判断に使える性能要件になります。

帯域だけではネットワーク性能を判断できない

ネットワーク性能というと、最初に「1Gbps」「10Gbps」などの帯域を想像しやすいでしょう。

しかし、 帯域が大きければ必ず快適になるわけではありません。

「ネットワークが遅い」には複数の原因がある

帯域不足 通信量が回線能力へ集中

＋

遅延応答まで時間がかかる

＋

ジッター 遅延時間がばらつく

＋

パケットロス データが途中で失われる

例：Web会議が途切れる

Web会議の音声が途切れる場合、単純な帯域不足とは限りません。

回線が混雑している
一時的なパケットロスが発生している
遅延が大きい
遅延時間が大きく変動している
無線LAN側で品質が低下している
インターネット側やクラウドサービス側に問題がある

したがって、性能要件では、 帯域と通信品質を分けて整理する必要があります。

性能要件で確認する主な指標

性能要件では、主に次の項目を確認します。

帯域
Bandwidth

通信経路が一定時間に運べるデータ量の大きさです。 MbpsやGbpsなどで表します。

通信量
Traffic

実際にネットワークを流れているデータ量です。平均値だけでなくピーク時の値を確認することが重要です。

遅延
Latency

データが送信元から相手へ届くまでにかかる時間です。リアルタイム通信や遠隔地通信では特に重要になります。

ジッター
Jitter

パケットごとの遅延時間のばらつきです。音声・映像など連続したリアルタイム通信に影響します。

パケットロス
Packet Loss

送信したパケットが途中で失われることです。再送による速度低下や、音声・映像品質の低下につながります。

ポート速度
Link Speed

スイッチやルーターなどのインターフェースが対応する通信速度です。端末側だけでなく、集約部分やWAN側も確認します。

指標	確認したいこと	影響を受けやすい例
帯域	必要な通信量を処理できるか	バックアップ、ファイル転送、クラウド通信
遅延	応答までの時間が許容範囲か	Web会議、VDI、対話型システム
ジッター	遅延のばらつきが大きくないか	VoIP、Web会議、動画
パケットロス	通信途中でデータが失われていないか	音声、映像、TCP通信全般
ピーク通信量	最も混雑する時間帯でも処理できるか	始業時、昼休み、バックアップ時間帯

性能要件は利用アプリケーションから考える

性能要件を整理するときに重要なのは、 ネットワークだけを見るのではなく、そのネットワークで何を利用するのかを見ることです。

Web・業務システム

操作への応答時間が利用者の体感へ影響します。通信量だけでなく遅延も確認します。

Web会議・VoIP

遅延、ジッター、パケットロスの影響を受けやすいため、単純な帯域だけでは判断できません。

ファイル転送

大容量ファイルを扱う場合、転送量や完了までに許容できる時間を確認します。

バックアップ

大量の通信が特定時間へ集中することがあります。実行時間帯と他業務への影響を確認します。

クラウドサービス

インターネットやWAN側へ通信が集中するため、 LAN内部だけでなく外部接続部分も確認します。

VDI・リモート操作

操作結果が画面へ返るまでの応答が重要となるため、遅延や通信安定性を確認します。

ヒアリングで確認する

どの業務アプリケーションを利用しますか？
業務上特に重要なアプリケーションはどれですか？
同時利用者は最大何人程度ですか？
利用が集中する時間帯はありますか？
大容量ファイルを送受信しますか？
Web会議やIP電話を利用しますか？
バックアップや更新処理は何時に実行しますか？
クラウドサービスの利用予定はありますか？

「利用者300人」という情報だけでは、必要帯域は決められません。

同じ300人でも、メール中心なのか、全員がWeb会議を行うのか、大容量データをクラウドへ転送するのかで必要なネットワーク性能は大きく変わります。

平均通信量とピーク通信量を確認する

現行ネットワークが存在する場合は、実際の通信量を確認します。

特に重要なのが、 平均値だけで判断しないことです。

1日の通信量イメージ

8時

9時

10時

11時

12時

13時

14時

15時

16時

17時

たとえば、1日の平均通信量が200Mbpsだったとしても、 14時だけ800Mbpsまで上昇しているのであれば、平均200Mbpsだけを見て回線を選定するとピーク時間帯に性能不足となる可能性があります。

確認したい通信量

項目	確認内容
平均通信量	通常時にどの程度利用されているか
ピーク通信量	最も通信が集中するときの値
ピーク時間帯	いつ通信量が増えるのか
上り通信量	端末・拠点から外部へ送る通信
下り通信量	外部から端末・拠点へ受け取る通信
曜日差	平日・休日や特定曜日で違いがあるか
月次・季節差	月末・繁忙期などで増えるか

ある1日の瞬間値だけで判断するのも危険です。業務パターンによって通信量が変わるため、可能であれば複数日・複数時間帯の傾向を確認します。

どこがボトルネックになるか確認する

「インターネットが遅い」という申告があっても、インターネット回線そのものが原因とは限りません。

通信経路ごとに性能を確認する

PC・端末 NIC・無線LAN

→

アクセスSW 端末収容

→

コア・FW 集約・処理

→

WAN・Internet 外部接続

→

Cloud / Server 接続先

ネットワーク全体の性能は、通信経路の一部分だけでは判断できません。

例えばアクセススイッチが十分高速でも、多数のアクセススイッチから集約される上位リンクの容量が不足していれば、そこで通信が集中します。

区間ごとに確認する

端末とアクセススイッチ間
アクセススイッチとコアスイッチ間
サーバー接続部分
ファイアウォールを通過する部分
拠点間WAN
インターネット回線
クラウド接続部分
無線LAN区間

性能要件は「ネットワーク全体」だけでなく、重要な通信経路ごとに整理します。

必要帯域をどう見積もるか

新規拠点など、十分な実測データがない場合は、利用アプリケーションと同時利用数から必要帯域を見積もることがあります。

簡易的な考え方 想定通信量 × 同時利用数＋将来増加・変動を考慮した余裕

ただし、この式だけで機械的に帯域を決めるわけではありません。

実際の通信は常に一定ではなく、ファイル転送のように短時間へ集中する通信もあれば、 Web会議のように比較的連続する通信もあります。

例：新しい支店のインターネット回線

利用者：100人
通常のWeb・SaaS利用：あり
Web会議：最大30人程度が同時利用
クラウドストレージ：利用
将来：3年間で利用者150人を想定

この場合、「100人だから○Mbps」と単純に決めるのではなく、アプリケーションごとの利用状況、同時利用数、ピーク時間帯、将来増加を整理して必要な性能条件を決めます。

製品やクラウドサービスごとの具体的な推奨帯域が必要な場合は、ベンダーの最新ドキュメントや実測値も確認します。

現在だけでなく将来の増加を考慮する

要件定義では、現在の通信量だけを満たせばよいとは限りません。

ネットワークは数年間利用されることが多いため、将来の増加予定も確認します。

利用者の増加

新規採用、組織拡大、オフィス統合などによる利用者数の増加を確認します。

端末の増加

PCだけでなく、スマートフォン、IP電話、IoT、無線端末なども考慮します。

クラウド利用の増加

オンプレミス中心からSaaS・IaaS利用へ移行すると、 WAN・インターネット側の通信量が変化します。

拠点の追加

拠点数増加によって、 WANやデータセンター側へ通信が集中する可能性があります。

ヒアリング例

今後3年間の利用者数はどの程度を想定していますか？
新規拠点の開設予定はありますか？
クラウドへ移行予定のシステムはありますか？
Web会議や動画利用は増える予定ですか？
今後追加予定の端末やIoT機器はありますか？

将来拡張を考慮するといっても、根拠なく「とりあえず最大構成」にすることが正解ではありません。

将来計画とコストを確認し、必要な余裕と拡張方法を設計できるように要件を整理します。

性能要件と設計を分ける

要件定義では、 必要な性能条件と、それを実現する方法を混同しないこと が重要です。

設計を先に決めた例

「すべての上位リンクを10Gbpsにする」

要件として整理した例

「現在のピーク通信量と将来増加を考慮し、業務ピーク時にも必要な通信を処理できる帯域を確保する」

顧客要望	要件	基本設計で検討する内容
ネットワークを速くしたい	ピーク時の業務通信を処理できる容量を確保する	回線帯域、リンク速度、機器性能
Web会議を安定させたい	Web会議に必要な通信品質を維持できること	帯域、QoS、WAN構成、無線LAN設計
将来も使えるようにしたい	将来の利用者・端末・通信量増加へ対応できること	ポート速度、回線増速方法、機器容量

要件は「何を満たすか」。
設計は「どう満たすか」。

性能要件を先に整理することで、「なぜこの帯域・この機器・この構成なのか」を説明できます。

性能・帯域要件として要件定義書へ残す内容

性能に関するヒアリング結果は、後工程で確認できるように文書化します。

分類	記録する内容例
対象通信	業務システム、Web会議、SaaS、バックアップなど
利用者	現在人数、同時利用数、将来人数
通信量	平均値、ピーク値、測定期間
ピーク条件	時間帯、曜日、月末、バックアップ時間など
帯域	必要な通信を処理するための条件
品質	遅延、ジッター、パケットロスなど
将来増加	3年後などの利用者・拠点・通信量の見込み
制約	既存回線、予算、機器、契約など
未決事項	測定予定、顧客確認事項、ベンダー確認事項

要件記載例

性能要件例

現在のピーク通信量および今後3年間の利用者増加を考慮し、業務ピーク時間帯に必要な通信を処理できる帯域を確保すること。
Web会議などリアルタイム通信について、業務利用に必要な通信品質を確保すること。
業務通信と大容量バックアップ通信が競合する場合でも、主要業務への影響を抑えられること。
将来の通信量増加時に、回線・機器を拡張できる構成とすること。

実案件では、必要に応じて遅延・ロス・帯域などを具体的な数値で定義します。

数値は一般論だけで決めず、アプリケーション要件、実測値、ベンダー仕様、顧客の業務条件などを根拠に決定します。

性能・帯域要件でよくある失敗

1．平均通信量だけを見る

平均値では問題がなくても、ピーク時間帯だけ帯域が不足することがあります。

2．「利用者数」だけで帯域を決める

同じ人数でも利用するアプリケーションによって通信特性は異なります。

3．帯域だけ確認する

遅延、ジッター、パケットロスが原因で通信品質が低下している場合があります。

4．LANだけを見る

SaaSやクラウド利用では、 WAN・インターネット側がボトルネックになる可能性があります。

5．現在しか見ない

数年後の利用者数・端末数・クラウド利用増加を考慮しないと、早期に性能不足となる可能性があります。

6．最初から速度を決める

「10Gbpsなら安心」と手段を先に決めるのではなく、必要条件を確認してから設計します。

「高速なネットワークにすること」では、完成後に要件を満たしたか判定できません。

良い性能要件は、設計後に測定・試験・確認できる形になっています。

顧客・上司へ性能要件をどう説明するか

技術に詳しくない相手へ、「帯域」「ジッター」などの用語だけを並べても意味が伝わりにくいことがあります。

業務への影響と結び付けて説明します。

技術的な確認	業務側への聞き方
ピーク通信量	最もネットワークが遅くなる時間帯はいつですか？
必要帯域	何人が、どのシステムを同時に使いますか？
遅延	操作してから応答が返るまで、どの程度なら業務上問題ありませんか？
パケットロス	Web会議の音切れや映像停止は業務へどの程度影響しますか？
将来容量	今後、利用人数やクラウド利用はどの程度増える予定ですか？

説明例

「回線速度を先に決めるのではなく、まず現在の通信量と最も混雑する時間帯を確認します。あわせてWeb会議やクラウドなど、どの業務を何人が同時に利用するかを確認します。その結果から必要な帯域と通信品質を整理し、将来の利用者増加も含めて回線や機器構成を設計します。」

上流工程では、 「10Gbpsが必要です」ではなく、「なぜ10Gbps相当の容量が必要なのか」を業務要件から説明できること が重要です。

性能・帯域要件で使われる英語表現

よく使われる単語

英語	意味
Performance requirement	性能要件
Bandwidth	帯域
Traffic volume	通信量
Peak traffic	ピーク通信量
Latency	遅延
Jitter	ジッター・遅延のばらつき
Packet loss	パケットロス
Throughput	実効的な通信処理量
Concurrent users	同時利用者
Expected growth	想定される増加
Bottleneck	性能上のボトルネック

ヒアリングで使える表現

What is the current peak traffic volume?

現在のピーク通信量はどの程度ですか？

When does network traffic usually peak?

通常、ネットワーク通信が最も増えるのはいつですか？

How many concurrent users are expected?

何人程度の同時利用を想定していますか？

Which applications are sensitive to latency?

遅延の影響を受けやすいアプリケーションはどれですか？

What traffic growth is expected over the next three years?

今後3年間でどの程度の通信量増加を想定していますか？

Are there any known network bottlenecks?

既知のネットワークボトルネックはありますか？

理解度チェック

用語の暗記ではなく、顧客の要望を性能要件へ変換できるか確認しましょう。

問題1．顧客から「ネットワークをもっと速くしてください」と言われました。最初の対応として最も適切なものはどれですか。

すべての回線を10Gbpsにする
最も高性能なルーターを選定する
利用アプリケーション、通信量、ピーク時間帯などを確認する
要件定義書へ「高速であること」と記載する

解答を見る

正解：C

「速い」という表現は曖昧です。何の通信に問題があり、いつ、どの程度の通信量が発生しているのかを確認する必要があります。

問題2．1日の平均通信量が200Mbpsで、特定時間帯だけ800Mbpsまで増えるネットワークがあります。帯域検討で特に重要なのはどちらですか。

平均200Mbpsだけを見る
ピーク800Mbpsと、その発生条件を確認する

解答を見る

正解：B

平均値だけではピーク時間帯の帯域不足を見逃す可能性があります。ピーク値と、その通信がいつ・なぜ発生したのかを確認します。

問題3．Web会議の音声が途切れる場合、帯域以外に確認したい指標を2つ以上挙げてください。

解答例を見る

遅延
ジッター
パケットロス

問題4．次のうち「要件」に近いものはどちらですか。

コアスイッチ間を10Gbpsで接続する
業務ピーク時にも必要な通信を処理できる容量を確保する

解答を見る

正解：B

Bは「何を満たす必要があるか」を示す要件です。 Aはそれを実現するための具体的な設計方法です。

問題5．性能要件で現在の通信量だけでなく、将来計画を確認する理由を説明してください。

解答例を見る

ネットワーク導入後に利用者、端末、拠点、クラウド利用などが増えることで通信量が増加する可能性があるためです。将来増加を考慮せず設計すると、導入後早い段階で性能不足となる可能性があります。

実践演習：支店ネットワークの性能要件を整理する

あなたは、ある企業の支店ネットワーク更改を担当しています。

顧客から聞いた内容

「社員は現在100人です。最近Web会議が増えていて、午後になると音声が途切れることがあります。業務システムはクラウドへ移行する予定です。 3年後には社員が150人程度になる予定なので、今回の更改後はしばらく増速しなくても使えるようにしたいです。」

課題1．追加で確認する質問を考える

性能・帯域要件を整理するため、顧客へ追加で確認したい質問を8つ考えてください。

1．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
6．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
7．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
8．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

解答例を見る

現在のインターネット回線帯域はいくつですか？
現在の平均・ピーク通信量はどの程度ですか？
通信量が最も多い時間帯はいつですか？
Web会議の最大同時利用者数は何人ですか？
音声が途切れるのは有線・無線のどちらでも発生しますか？
遅延やパケットロスの測定結果はありますか？
クラウドへ移行する業務システムは何ですか？
3年後の通信量増加について予測値はありますか？

課題2．要望と要件を分ける

顧客の言葉	確認・具体化する内容
Web会議が途切れる	＿＿＿＿＿＿＿＿＿＿＿＿＿＿
午後になると遅い	＿＿＿＿＿＿＿＿＿＿＿＿＿＿
クラウドへ移行する	＿＿＿＿＿＿＿＿＿＿＿＿＿＿
150人になっても使いたい	＿＿＿＿＿＿＿＿＿＿＿＿＿＿

解答例を見る

Web会議が途切れる： 同時利用数、帯域、遅延、ジッター、パケットロスを確認する
午後になると遅い： 時間帯別の通信量とピーク値を確認する
クラウドへ移行： クラウド移行後に増えるWAN・インターネット通信を確認する
150人になっても使いたい： 将来利用者数と通信量増加を性能要件へ反映する

課題3．要件と設計を判断する

次の文章が「要件」か「設計」かを判断してください。

業務ピーク時にもWeb会議と業務システムを利用できる性能を確保する
インターネット回線を1Gbpsへ増速する
3年後の利用者150人を考慮した通信容量を確保する
アクセススイッチとコアスイッチを10Gbpsで接続する
重要なリアルタイム通信を優先できる構成とする

解答を見る

要件
設計
要件
設計
要件

課題4．性能要件シートを作る

次の形式で情報を整理してください。

項目	現状	将来	要件	未決事項
利用者数	100人	150人	＿＿＿＿＿	＿＿＿＿＿
通信量	＿＿＿＿＿	＿＿＿＿＿	＿＿＿＿＿	測定必要
Web会議	音切れあり	利用増加	＿＿＿＿＿	同時利用数確認
クラウド	一部利用	業務システム移行	＿＿＿＿＿	通信量確認