QoS とは｜優先制御の仕組みと製品共通で押さえる設計のポイント

はじめに

ネットワークの帯域には上限があり、回線が混雑（輻輳）した状況では、すべての通信を同じように速く届けることはできません。このとき、音声通話や Web 会議のように遅延に弱い通信と、大容量ファイルのダウンロードのように多少遅れても支障の少ない通信を区別せずに扱うと、業務上重要な通信の品質が先に低下します。

QoS（Quality of Service）／優先制御は、こうした輻輳時に「どの通信を優先して処理するか」をルーターやスイッチに指示し、限られた帯域を意図した配分で使うための仕組みです。ただし、製品によって設定方法や用語が異なり、設計の考え方を押さえないまま設定だけを真似ると、意図どおりに動作しないこともあります。

本記事では、Cisco・FortiGate・IX・YAMAHA といった主要製品の設定に入る前提として、QoS の基礎と設計の考え方、そして近年の動向を整理します。

QoS（優先制御）とは｜基本の考え方

QoS は、ネットワーク上の通信に優先順位や帯域の割り当てを設定し、輻輳時でも重要な通信の品質を保ちやすくするための技術の総称です。まずは QoS が必要になる背景と、標準的な通信方式であるベストエフォートとの違いを整理します。

QoS が必要になる場面（輻輳・遅延・ジッタ・パケットロス）

QoS が効果を持つのは、回線が混雑し、通信品質の指標が悪化する場面です。代表的な指標は次の 4 つです。

• 遅延（Delay / Latency）: パケットが届くまでの時間。音声・映像通話で特に影響が大きい。
• ジッタ（Jitter）: 遅延のばらつき。値が大きいと、音声の途切れや映像の乱れにつながる。
• パケットロス（Packet Loss）: パケットの欠落。輻輳でキューがあふれると発生しやすい。
• スループット（Throughput）: 単位時間あたりに送れるデータ量。

通信の品質は、これらの指標によって定量的に表されます。DiffServ のアーキテクチャを定義した RFC 2475 でも、サービスの差別化は多様なアプリケーションの要件に応えるために求められる、という考え方が示されています。

参考: RFC 2475 — An Architecture for Differentiated Services
“Service differentiation is desired to accommodate heterogeneous application requirements and user expectations”
（サービスの差別化は、多様なアプリケーションの要件とユーザーの期待に応えるために求められる）
https://www.rfc-editor.org/rfc/rfc2475.html

ベストエフォートとの違い

通常の IP ネットワークは、ベストエフォート型で動作します。これは、すべてのパケットを到着順に区別なく処理し、品質の保証を行わない方式です。平常時は問題になりにくい一方で、輻輳時にはどの通信が遅延や損失の影響を受けるかを制御できません。

QoS（優先制御）は、このベストエフォートに対して、あらかじめ定めた基準で通信を分類し、優先度や帯域を割り当てます。たとえば、音声通話を優先キューに入れ、ファイル転送には上限帯域を設ける、といった配分です。

項目	ベストエフォート	QoS（優先制御）
処理方針	到着順に一律で処理	分類した通信ごとに優先度・帯域を割り当て
品質の保証	なし	設計に応じて一定の品質を確保しやすい
効果が出る場面	—	輻輳時
設定の要否	不要（既定動作）	設計と設定が必要

QoS を構成する 4 つの機能

QoS は単一の機能ではなく、複数の機能を組み合わせて実現します。大まかな流れは「通信を見分ける（分類）→ 印を付ける（マーキング）→ 送出順を決める（キューイング）→ 帯域の上限を整える（帯域制御）」です。ここでは、それぞれの役割を整理します。

分類（Classification）とマーキング（DSCP / CoS）

分類とマーキングは、QoS の起点となる機能です。分類はネットワークの入口で 1 回だけ行い、以降の機器はマーキングされた値を信頼して処理することで、各機器が毎回中身を調べる負荷を避け、大規模な環境でも一貫した優先制御を実現します。

分類（Classification）は、通信を一定の基準で見分ける処理です。送信元・宛先 IP アドレス、ポート番号、プロトコル、入力インターフェース、あるいはアプリケーション識別など、製品が対応する条件で通信をグループに振り分けます。

マーキング（Marking）は、分類した通信に優先度を表す値を書き込む処理です。代表的な方式は次の 2 つです。

DSCP（Differentiated Services Code Point）

IP ヘッダー内の DS フィールドを使う、レイヤ 3 のマーキング。6 ビットで 64 通りの値を表せます。ルーターをまたいだエンドツーエンドの優先制御に用います。

CoS（Class of Service / IEEE 802.1p）

802.1Q（VLAN タグ）内の 3 ビットを使う、レイヤ 2 のマーキング。8 段階の優先度を表し、スイッチ間の制御に用います。

DSCP は IETF で標準化されており、DS フィールドの構造は RFC 2474 で次のように定義されています。

参考: RFC 2474 — Definition of the Differentiated Services Field (DS Field)
“Six bits of the DS field are used as a codepoint (DSCP)”
（DS フィールドの 6 ビットが、コードポイント（DSCP）として使用される）
https://www.rfc-editor.org/rfc/rfc2474

DSCP には、用途ごとに広く使われる代表的な値があります。

DSCP 名	値（10 進）	主な用途
CS0（Default）	0	ベストエフォート（既定）
AF クラス	AF11〜AF43	業務データなど、相対的な優先度を付ける通信
EF	46	音声（VoIP）など、遅延・損失に弱い通信
CS6	48	ルーティングプロトコルなどの制御通信

キューイングと輻輳管理（PQ / CBWFQ / LLQ などの考え方）

キューイングは、マーキングされた通信を出力インターフェースで複数のキュー（待ち行列）に振り分け、どの順序・どの割合で送出するかを決める機能です。輻輳時に優先制御の効果が最も現れる部分にあたります。代表的な考え方は次のとおりです。

FIFO（First In First Out）

既定の単一キュー。到着順に処理し、優先度は付けません。

PQ（Priority Queuing）

優先度の高いキューを常に先に処理する厳格優先方式。応答性は高い一方、優先トラフィックが多いと、低優先の通信が送出されにくくなる（枯渇）リスクがあります。

CBWFQ（Class-Based Weighted Fair Queuing）

クラスごとに最低帯域を割り当て、輻輳時もクラス間の配分を保ちやすくする方式

LLQ（Low Latency Queuing）

CBWFQ に厳格優先キューを組み合わせ、音声のように遅延に弱い通信を優先しつつ、他クラスの帯域も確保する方式

加えて、キューがあふれる前にパケットを選択的に破棄して輻輳を緩和する輻輳回避（WRED など）の仕組みもあります。

シェーピングとポリシング（帯域制御）の違い

シェーピングとポリシングは、いずれも通信の帯域に上限を設ける帯域制御の機能です。違いは、上限を超えた通信の扱いにあります。

シェーピング（Shaping）

超過分を一時的にバッファへ蓄え、送出を遅らせてレートを平滑化します。破棄は抑えられますが、遅延が増えます。主に送信側で、回線速度に合わせて送出を整える用途に用います。

ポリシング（Policing）

超過分をその場で破棄、または DSCP を下げて再マーキングします。バッファしないため遅延は増えませんが、破棄が発生します。主に境界で、契約帯域や上限を超える通信を抑える用途に用います。

項目	シェーピング	ポリシング
超過分の扱い	バッファに蓄えて遅延送出	破棄または再マーキング
遅延への影響	増える	増えない
破棄の発生	抑えられる	発生する
主な用途	送出レートの平滑化	上限の強制・境界での制御

優先制御の設計で押さえるポイント

各機能を理解しても、「どの通信を優先するか」「どこでマーキングを信頼するか」「どれだけ帯域を割くか」という設計が伴わないと、意図どおりには動作しません。ここでは、製品を問わず共通する設計の判断軸を整理します。

どのトラフィックを優先するか（音声・映像・業務・ベストエフォート）

優先制御の出発点は、通信を性能要件で分類し、優先度を決めることです。代表的な区分は次のとおりです。

音声（VoIP）

遅延・ジッタ・損失に弱い一方、帯域は比較的小さく一定。最優先（厳格優先キュー、DSCP では EF）で扱うのが一般的です。

映像・Web 会議

遅延に弱く、帯域も大きい。音声に次ぐ優先度で扱います。

業務データ（基幹系・ファイル共有など）

ある程度の遅延を許容できる。相対的な優先度（AF クラス）を付けます。

ベストエフォート（一般的な Web 閲覧・更新通信など）

残りの帯域を利用します。

DiffServ のサービスクラスの考え方は RFC 4594 にまとめられており、通信の特性と求められる性能に基づいてクラスを定義する、とされています。

参考: RFC 4594 — Configuration Guidelines for DiffServ Service Classes
“Service class definitions are based on the different traffic characteristics and required performance”
（サービスクラスの定義は、通信ごとに異なる特性と求められる性能に基づく）
https://www.rfc-editor.org/rfc/rfc4594

マーキングの信頼境界（Trust Boundary）とエンドツーエンド設計

マーキングの設計では、「どこで印を付け、どこから信頼するか」という信頼境界（Trust Boundary）の考え方が重要です。

エンドユーザーの端末が付けたマーキングは、必ずしも信頼できません。任意に高い優先度を付けることが可能なためです。そこで、マーキングを信頼し始める地点を信頼境界として定め、境界の外から来た通信は、境界で分類し直す、あるいは再マーキングする設計が基本になります。マーキング自体は、再分類の負荷を避けるため、送信元にできるだけ近い信頼できる地点で行うことが推奨されます。

帯域・キュー設計の考え方

帯域とキューの設計では、各クラスにどれだけの帯域を割り当て、どのキュー方式で扱うかを決めます。共通する要点は次のとおりです。

• 厳格優先キュー（音声など）には上限を設ける。優先キューに帯域上限を設けないと、他の通信を圧迫するおそれがあるため、回線の一定割合までに制限する考え方が一般的です。
• 残りの帯域をクラスごとに最低保証で配分する（CBWFQ のような方式）
• 平常時ではなく、ピーク時や障害時の輻輳を想定して設計する。優先制御は輻輳時にはじめて効くためです。
• 上流・下流で一貫したクラス設計とする（エンドツーエンドでクラスの意味を保つ）

QoS の最新動向

従来の DiffServ ベースの優先制御に加え、近年はアプリケーションを識別する制御、遅延そのものを抑える技術、無線やクラウド環境での QoS が広がっています。ここでは押さえておきたい動向を 3 つ紹介します。

L4S（Low Latency, Low Loss, Scalable throughput）

L4S は、2023 年に RFC 化された、遅延の発生原因に対処する新しいアプローチです。従来の優先制御が「通信に優先順位を付ける」ものであるのに対し、L4S は輻輳の根本原因を送信側の輻輳制御にあるととらえ、キューにパケットがたまること自体を抑える点が特徴です。

仕組みとしては、ECN（明示的輻輳通知）を改良した方式（ECT(1) のコードポイント）を用い、ネットワークが輻輳の兆候を早期に通知し、送信側がそれに応答します。これにより、キューがあふれる前に送出レートを調整します。

参考: RFC 9330 — Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture
“low queuing latency, low congestion loss, and scalable throughput control”
（低いキューイング遅延、低い輻輳損失、そしてスケーラブルなスループット制御）
https://www.rfc-editor.org/rfc/rfc9330

RFC 9330 では、キューイング遅延の目標として平均 1 ms 未満、99 パーセンタイルで約 2 ms 未満が挙げられています。クラウドゲーミングや Web 会議、VR/AR など低遅延が求められる用途を想定しており、Low Latency DOCSIS（ケーブル回線）などで実装が進んでいます。なお RFC 9330 は Informational（情報提供）に分類され、段階的な展開を前提としています。すぐに企業ルーターの設定へ直結するものではありませんが、今後のアクセス回線や OS の輻輳制御に関わる動向として把握しておくとよいでしょう。

SD-WAN / アプリケーション識別ベースの優先制御

近年は、ポート番号や IP アドレスだけでなく、アプリケーションを識別して優先制御する方式が広がっています。アプリケーション識別（DPI など）により、特定の Web 会議や SaaS といった単位で通信を見分け、優先度や経路を決めます。

SD-WAN では、複数回線（MPLS・インターネット・LTE など）をアプリケーション単位で使い分け、遅延や損失の計測結果に基づいて経路を動的に切り替えます。背景には、TLS による暗号化通信の増加で従来のポートベースの分類が効きにくくなったという事情があります。分類の軸が、ポートからアプリケーション識別へ移りつつある点は、近年の優先制御を理解するうえでの要点です。各製品での具体的な設定（FortiGate のアプリケーション制御や SD-WAN 機能など）は、製品別の記事で扱います。

Wi-Fi（WMM）やクラウド / SASE 環境での QoS

QoS は有線だけでなく、無線やクラウド経路でも考慮が必要です。

無線 LAN では、WMM（Wi-Fi Multimedia、IEEE 802.11e がベース）により、通信を音声・映像・ベストエフォート・バックグラウンドの 4 つのアクセスカテゴリに分類します。有線側の DSCP と無線側の WMM をどう対応づけるか（マッピング）が設計上の要点になります。

クラウドや SASE 環境では、通信がインターネットやクラウド経由になるため、自社でエンドツーエンドの QoS を保証することが難しくなります。経路選択や SLA、SASE が提供する経路最適化機能などで補う考え方が中心です。優先制御は「自社で制御できる区間」と「できない区間」を分けて設計することが、クラウド時代の前提になります。

優先制御が「効かない」ときの切り分けの基礎

QoS を設定したのに効果が見えない、という場合、設定そのものより前提や整合の問題であることが少なくありません。ここでは、製品共通の切り分けの考え方を整理します。

よくある原因（信頼境界・マーキング・キュー設計の不整合）

優先制御が意図どおりに動かない場合、次のような原因が考えられます。

• マーキングが信頼境界で破棄、または再マーキングされている。境界の設定（信頼する／しない）が想定と異なるケースです。
• 分類条件が実際の通信と一致していない。ポートやアプリケーションの指定漏れ、対象 IP の誤りなどです。
• キュー設計の不整合。優先キューに帯域上限がない、各クラスの最低保証が不足している、といった配分の問題です。
• そもそも輻輳していない。優先制御は輻輳時にはじめて効くため、平常時の確認では差が現れません。
• 上流・下流でクラス設計が一致していない。途中の機器や区間で DSCP が書き換わると、エンドツーエンドで優先度が保たれません。

確認の着眼点（キャプチャでの DSCP / CoS 確認など）

原因の切り分けでは、設定値だけでなく、実際の通信と機器の状態を確認することが有効です。

• 実際のパケットに付与された DSCP / CoS 値を、パケットキャプチャで確認します。設定上のマーキングと、流れている値が一致しているかを確かめられます。なお、キャプチャでの絞り込み方法は関連記事「Wireshark の表示フィルタの使い方」で扱っています（URL は実際のパーマリンクに差し替え）。
• 各機器のキュー統計（キューごとのドロップ数、使用率）を確認し、どのクラスで破棄が起きているかを把握します。
• 信頼境界の設定（信頼する／しないの区分）が、設計どおりかを確認します。
• 輻輳を再現した状態で測定します。負荷がない状態では効果を確認できないためです。

製品別の実装に向けて

ここまで整理した分類・マーキング・キューイング・帯域制御の考え方や、信頼境界・帯域設計の要点は、製品が変わっても共通します。一方で、CLI の体系や設定手順、用語は製品ごとに異なります。

本記事を前提に、主要 4 製品それぞれの設計ポイント・設定方法・よくあるトラブルと対処を、個別の記事で扱う予定です（公開後に各リンクを追加します）

Cisco

MQC（Modular QoS CLI）による class-map / policy-map を用いた設定が中心です。

FortiGate

トラフィックシェイピングやアプリケーション制御、SD-WAN と組み合わせた優先制御が特徴です。

IX（NEC）

QoS の各機能を、独自の CLI 体系で設定します。

YAMAHA（RTX）

クラス分けと帯域制御のコマンドで、拠点向けルーターの優先制御を構成します。

各製品の記事では、本記事で扱った考え方が、具体的なコマンドや画面操作にどう対応するかを確認できるようにする予定です。

まとめ

• QoS（優先制御）は帯域を増やす技術ではなく、限られた帯域の配分を制御する仕組みです。
• 効果が現れるのは輻輳時で、平常時は差が見えにくくなります。
• 構成要素は、分類・マーキング（DSCP / CoS）・キューイング・帯域制御（シェーピング／ポリシング）です。
• 設計の中心は、何を優先し何を後回しにするかをクラスとして絞り込むことです。
• マーキングは信頼境界を定め、端末が付けた値をそのまま信頼しない設計が基本です。
• 近年はアプリケーション識別ベースの制御や、遅延そのものを抑える L4S などの動向が進んでいます。
• 効かないときは、信頼境界・マーキング・キュー設計の整合と、実際の DSCP 値を確認します。

以上、最後までお読みいただきありがとうございました。