LASSIC Media らしくメディア
レイテンシとスループットの違い｜性能指標
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- レイテンシは、1件の処理を依頼してから結果が返るまでの時間で、応答の速さを表します。
- スループットは、決まった時間に処理できる件数や量で、システム全体の処理能力を表します。
- 片方を良くしてももう片方が良くなるとは限らないので、処理ごとにどちらを重視するかを決めます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
性能要件の打ち合わせで「レイテンシは問題ないが、スループットが足りない」と言われる。応答は速いはずなのに、全体の処理件数が伸びない——。システムの性能を話し合う場では、こうした二つの指標の取り違えが起こりがちです。レイテンシは1件の処理を依頼してから結果が返ってくるまでの時間、スループットは決まった時間に処理できる件数や量を指します。
どちらもシステムの性能を測る代表的な指標で、要件定義の段階で分けて書いておけば、画面の反応は速いのに繁忙期に処理が遅れる、といった食い違いを防ぎやすくなります。ただし、指標を決めるだけでは足りず、計測の仕組みがなければ、決めた値が守られているかを確かめられません。本記事では、システム開発を発注する担当者や設計者に向けて、二つの指標の意味と違い、影響し合う関係、性能要件での使い分けと計測、そして外部に委託するときに確認したい点を整理します。
目次
レイテンシとは
レイテンシ（Latency）は、利用者がボタンを押してから画面が切り替わるまでの待ち時間に直結する指標です。単位はミリ秒や秒です。Webサイトでリンクをクリックしてからページが表示されるまでを例にとると、その間には、リクエストがサーバーへ届くまでの通信時間、サーバーでの処理時間、データベースへの問い合わせ時間、結果を利用者の端末へ返す通信時間が積み重なっています。これらを合計したものが、利用者が感じるレイテンシです。
レイテンシは、いくつかの時間の合計として捉えると設計しやすくなります。主な内訳は次の4つです。
- 通信にかかる時間：リクエストとレスポンスが回線を伝わる時間
- 待ち行列による遅延：処理の順番を待っている間の時間
- アプリケーションの処理時間：プログラムの実行やデータベースへの問い合わせにかかる時間
- 他のサービスの呼び出し：別のシステムを次々に呼び出すことで積み上がる時間
このうちどれか1つの時間が大きければ、レイテンシを縮めるにはまずそこを見直します。操作画面の応答は利用者の感じ方に直結し、ボタンを押してからの反応がわずかに遅くなっただけでも「重い」「使いにくい」と受け取られ、利用をやめるきっかけになる場合もあります。社内システムでも、毎日何度も操作する画面の応答が遅ければ、業務全体の生産性に影響します。
スループットとは
スループット（Throughput）は、システムが決まった時間に処理できる件数や量を表す指標です。1秒あたりのリクエスト数（RPS）や1秒あたりの取引件数（TPS）の形で示されることが多い指標です。単位は件/秒のほか、件/時などが使われます。
ECサイトのセール期間中に、1分間に何件の注文を処理できるかを考えると分かりやすいでしょう。1件ごとの応答が多少遅くても、たくさんの注文を並行して処理できれば、全体の処理件数は保たれます。反対に、1件ごとの応答が速くても、同時に扱える件数に上限があれば、混雑したときに全体の処理件数はそれ以上伸びなくなります。
スループットは、システムの処理能力にどれだけ余裕があるかで大きく変わります。左右する主な要素は次の4つです。
- 並列度：同時に動かせる処理の数
- 計算資源の量：CPUやメモリ、ディスクの読み書きといったリソースの余裕
- 処理の効率：アルゴリズムやデータベースへの問い合わせの組み方にむだが少ないか
- 接続数の上限：データベースに同時につなげる数のように、上限が決まっている要素
スループットは、一定の期間に処理できた件数を、その期間の長さで割って求めます。たとえば10分間で1200件の注文を処理できたなら、1分あたりのスループットは120件です。この値を平常時とピーク時で比べておくと、繁忙期にどれだけの余力が残っているかを見積もる手がかりになります。
レイテンシとスループットの違い
どちらも「速さ」に関わる言葉として語られがちですが、レイテンシは1件あたりの速さを、スループットは全体としての処理量を見ています。主な観点で並べると次の表のとおりです。
| 観点 | レイテンシ | スループット |
|---|---|---|
| 意味 | 1件の処理にかかる時間（応答の速さ） | 決まった時間に処理できる量（処理能力） |
| 主な単位 | ミリ秒・秒 | 件/秒（RPS・TPS）、件/時など |
| 重視される場面 | 利用者を待たせない応答が必要な処理 | 大量のデータや取引をまとめて処理する場面 |
| 改善で見直すところ | 1件の処理の流れの中で、時間がかかっている箇所 | 並列度とリソースの余力 |
| 負荷が高いときの傾向 | 処理を待つ列が伸び、値が大きく（遅く）なりやすい | 処理能力の上限に近づくと、それ以上増えなくなる |
次の図は、高速道路を走る車で両者を示したものです。1台の車が入口から出口まで走り抜ける時間がレイテンシ、料金所を一定時間に通過できる車の台数がスループットに当たります。
両者はどう影響し合うのか
レイテンシとスループットは別々の指標ですが、負荷の状況によって影響し合います。処理を受け持つサーバーやプログラムの数を増やすと、同時に処理できる件数が増えるので、全体のスループットは上がりやすくなります。ただし、1件あたりの処理時間そのものが短くなるわけではありません。共有しているデータベースや外部サービスへのアクセスが増えるとリソースの取り合いが起きやすくなり、かえって1件ごとのレイテンシが伸びることもあります。
もう一つ押さえておきたいのが待ち行列、つまり処理の順番を待つ列です。システムに届くリクエストの量が処理能力の上限に近づくほど、処理を待つ列は長くなりやすくなります。余裕がある状態では待ち時間はわずかですが、上限に近い水準まで負荷が高まると、待ち時間が急に大きくなる傾向が知られています。待ち行列理論と呼ばれる考え方で説明される現象です。
処理能力に対して実際に流れてくる負荷の割合を稼働率と呼びます。稼働率が低いうちはレイテンシへの影響もわずかです。ピーク時の負荷を見込んで稼働率に余裕を持たせた設計にしておくと、レイテンシは安定しやすくなります。性能要件を考えるときは、平常時の値だけでなく、負荷が高まったときの振る舞いもあわせて確かめておきます。
どちらを重視するのか
どちらの指標を重視するかは、システムの用途で変わります。利用者の操作に対してその場で結果を返す画面や、他のシステムへすぐに結果を渡す必要がある処理では、レイテンシを主な指標としてSLA（サービス品質の取り決め）を定めるのが一般的です。「全体の95パーセントのリクエストが何ミリ秒以内に応答する」（95パーセンタイル）のように、平均値だけでなく遅い側の応答時間まで含めて基準を置く考え方がよく採られます。
夜間にまとめて実行する処理（夜間バッチ）や大量データの取り込み、集計処理のように、利用者がその場で結果を待たない処理では、スループットを主な指標にすることが多くなります。「1時間あたり何件処理できるか」「決められた時間内に処理を終えられるか」という形で性能要件を定めます。
会員数の多いサービスの申込処理や決済処理のように、応答の速さと大量の件数の処理の両方が求められる場面も少なくありません。その場合は、どちらを優先するかを一律に決めず、機能ごと、処理の流れごとに求める水準を分けて決めます。「性能要件」とひとまとめに書くと、応答の速さの要件なのか処理件数の要件なのかがあいまいになりがちです。要件定義の段階で機能ごとに主な指標を分けておけば、後の工程での認識のずれを減らせます。
計測と原因の切り分け
レイテンシを計測するときは、平均値に加えて、p95やp99といったパーセンタイル値（遅い側の応答時間を表す値）もあわせて見ておきます。平均値が良くても、一部の利用者だけが極端に遅い応答を経験していることがあり、そうした一部の遅い応答は平均値からは見えにくいためです。スループットは、一定期間あたりの処理件数を続けて記録し、負荷の変化とあわせて推移を追うのが基本です。
レイテンシが悪くなっているときは、監視ツールやAPM（アプリケーション性能監視）を使って、どの処理段階に時間がかかっているかを切り分けるところから始めます。ネットワーク、アプリケーションの処理、データベースへの問い合わせ、外部サービスの呼び出しのうち、どこで時間がかかっているかを確かめないまま対策をとると、期待した改善につながらないことがあります。
スループットが伸びないときも同じです。データベースの接続数、ロック（データの同時書き換えを防ぐ仕組み）、外部サービスの呼び出し回数の上限など、特定のリソースが全体の上限を決めている場合が多くあります。その箇所を突き止めることが、改善への早道です。
外部に委託するときに確認しておきたい点
システム開発を委託するときは、次の点を発注の前に確かめておくと、性能要件のすれ違いを防ぎやすくなります。
- 対象の処理が、応答の速さ（レイテンシ）と処理量（スループット）のどちらを重視するものか
- SLAとして定める値が、平均値なのかパーセンタイル値なのか
- 想定するピーク時の負荷（同時アクセス数・処理件数）はどの程度か
- 負荷が高まったときのレイテンシの振る舞いを、事前に確認・検証する計画があるか
- 性能を続けて計測・監視する仕組みが、リリース後に用意されているか
とくに、SLAの値を平均値で決めるのかパーセンタイル値で決めるのかで、基準の意味は変わります。また、負荷が高まったときの振る舞いは、平常時の試験だけでは確かめられません。ピーク時を想定した検証を、いつ、どの処理を対象に行うのかを委託先と話し合っておくと進めやすくなります。負荷をかけて性能を確かめる試験の進め方は「負荷テスト・性能テストを外注する費用と進め方」で扱っています。
まとめ：性能指標で確かめておきたい3つの点
レイテンシとスループットを性能要件に落とし込むうえで、確かめておきたい点は3つに整理できます。第一に、処理ごとに、応答の速さと処理件数のどちらを主な指標にするかを分けて決めること。第二に、平均値だけでなく、パーセンタイル値や負荷が高まったときの振る舞いまで含めて計測すること。第三に、並列化でスループットを上げても、1件ごとのレイテンシが縮むわけではないと理解しておくことです。この3点を踏まえておけば、「画面の反応は速くなったのに、繁忙期に処理が終わらない」という事態を避けやすくなります。性能要件の整理に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
レイテンシを下げれば、スループットも上がりますか
そうとは限りません。1件あたりの処理時間が短くなった結果、スループットが上がる場合もあります。しかし並列度やリソースの余力が足りなければ、レイテンシを改善しても全体の処理件数は伸びないことがあります。
レイテンシとスループットは、同時に計測できますか
できます。多くの監視ツールやAPMでは、応答時間（レイテンシ）と処理件数（スループット）を同時に記録し、負荷の変化とあわせてグラフにできます。両方を並べて見ると、負荷が高まったときにどちらの指標がどう変わるかをつかみやすくなります。
p95やp99は、どういう意味ですか
全体のリクエストのうち、95パーセントあるいは99パーセントが収まる応答時間を示すパーセンタイル値です。平均値では見えにくい、一部の利用者が経験する遅い応答をつかむために使います。
待ち行列理論を知らないと、性能設計はできませんか
詳しい数式を扱えなくても、性能要件の整理は進められます。押さえておきたいのは、負荷が処理能力の上限に近づくほど待ち時間が急に伸びやすいという傾向です。これを踏まえて、ピーク時に余裕を持たせた設計を検討します。
システム開発・性能設計のご相談
元請（プライムベンダー）として、性能要件の整理から負荷検証を含むシステム開発までご提案します。
Remoguとリラシクなら、性能要件の整理や負荷検証を含むシステム開発に加わるITエンジニアも探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA（情報処理推進機構）「試験要綱・シラバス」（https://www.ipa.go.jp/shiken/syllabus/index.html）。出典：基本情報技術者試験シラバスのうち、性能指標と待ち行列に関する記述を参照（2026年9月確認）
