スループットとは？レスポンスタイムとの違いと性能テストでの測り方

2026 8/08

2026年8月8日

「サーバーのスループットが目標に届かない」「レスポンスタイムは速いのにスループットが上がらない」。性能テストの現場では、この2つの指標を混同したまま議論が空転しがちです。

スループットとレスポンスタイムは別物です。一方を追いかけると、もう一方が悪化するトレードオフの関係にあります。

本記事では、スループットの定義と単位から解説します。関連する指標（レスポンスタイム・レイテンシ・同時実行ユーザー数）との関係も扱います。両者を結ぶ「リトルの法則」も解説します。

ボトルネックの特定手順、性能テストでの測定方法まで整理します。ネットワーク文脈の「通信速度としてのスループット」にも触れます。

スループットとは？単位時間あたりに処理できる量のこと

スループット（Throughput）とは、システムや機器が単位時間あたりに処理できる仕事量を指す指標です。英語の through（通り抜けて）＋ put（置く）が語源で、「一定時間内にどれだけ通し切れたか」を表します。

IT の分野では、大きく2つの文脈で使われます。

処理のスループット：Webサーバーが1秒間に処理できるリクエスト数、データベースが1秒間に実行できるトランザクション数、バッチが1時間で処理できるレコード件数など
通信のスループット：ネットワーク回線が1秒間に実際に転送できたデータ量（bps）

「スループット」で検索すると通信文脈の解説が多くヒットしますが、システム開発・性能テストの現場で扱うのは、主に前者です。本記事は処理のスループットを中心に据え、通信のスループットも後半で整理します。

スループットの単位一覧

スループットは「何を数えるか」によって単位が変わります。性能要件書やテスト報告書で頻出する単位を、整理しました。

単位	読み・正式名称	数える対象	主な使用場面
tps	transactions per second	1秒あたりのトランザクション数	基幹システム、決済、DB処理
rps	requests per second	1秒あたりのリクエスト数	Webサーバー、APIサーバー
qps	queries per second	1秒あたりのクエリ数	データベース、検索エンジン
rpm	requests per minute	1分あたりのリクエスト数	負荷が比較的低いシステムの表現
bps	bits per second	1秒あたりの転送ビット数	ネットワーク回線、通信機器
IOPS	Input/Output per second	1秒あたりのディスクI/O回数	ストレージ、SSD／HDD性能
件/時	—	1時間あたりの処理件数	夜間バッチ、帳票出力、データ移行
件/日	—	1日あたりの処理件数	業務量ベースの要件定義

注意したいのは、単位を明示しないまま「スループット1000」と書かれた要件は必ず解釈違いを生むという点です。1秒あたりなのか、1分あたりなのか。リクエスト単位なのか、業務トランザクション単位なのか。

これによって、必要なサーバー台数は桁違いに変わります。要件定義の段階で単位まで確定させることが、性能テストの前提条件になります。

理論スループットと実効スループット

スペックシートやミドルウェアの公称値が示すのが、理論スループットです。実際の条件下で観測されるのが、実効スループットです。この2つは必ず乖離します。

乖離を生むのは、プロトコルのオーバーヘッド、リトライ、ロック待ち、GC（ガベージコレクション）などです。これらが理論値を押し下げます。

性能テストで測るべきは、実効スループットです。「理論上は捌けるはず」という机上の計算だけでリリースに踏み切る。本番初日に処理が詰まる、典型的な失敗パターンです。

スループットとレスポンスタイム（応答時間）の違い

性能指標として最も混同されやすいのが、スループットとレスポンスタイムです。この2つは「どちらが優れているか」ではなく「何を測っているかが根本的に違う」指標です。

高速道路にたとえると理解しやすい

スループットとレスポンスタイムの関係は、高速道路にたとえると直感的に理解できます。

スループット＝車線数（1時間に何台の車を通せるか）。
レスポンスタイム＝1台の車が出発地から目的地に着くまでの所要時間。

車線を増やせば、1時間に通行できる車の総数（スループット）は増えます。あなたの車が目的地に着く時間（レスポンスタイム）は、短くなるとは限りません。

道路が空いていれば、1台あたりの所要時間は最短です。そのとき通行している車の総数は少なく、スループットは低い状態です。

システムでも同じことが起きます。サーバーの同時処理数を増やせば、全体のスループットは上がります。1リクエストあたりの待ち時間は、伸びていきます。

利用者が体感するのはレスポンスタイムであり、システム全体の処理能力を表すのがスループットです。

スループットとレスポンスタイムの比較表

比較項目	スループット	レスポンスタイム（応答時間）
測るもの	単位時間あたりの処理量	1件の処理にかかった時間
単位	tps / rps / qps / bps / 件数	ms（ミリ秒）／秒
視点	システム全体（供給側）	個々の利用者（体感側）
値の方向	大きいほど良い	小さいほど良い
主な用途	キャパシティ設計、サーバー台数算出	UX評価、SLA定義
負荷を上げると	限界点まで増加し、その後頭打ち・低下	単調に悪化（伸びる）
典型的な要件例	ピーク時 500rps を処理できること	95パーセンタイルで2秒以内
改善アプローチ	スケールアウト、並列度向上、非同期化	処理の高速化、キャッシュ、クエリ最適化

両者はトレードオフになりうる（最重要ポイント）

性能テストで最も押さえるべきなのが、同時実行数を上げるとスループットは上がるが、レスポンスタイムは悪化するというトレードオフです。

負荷を段階的に上げていったときのシステムの挙動は、一般に次の3つのフェーズをたどります。

フェーズ	負荷の状態	スループット	レスポンスタイム	判断
① 線形増加	リソースに余裕あり	負荷に比例して増加	ほぼ横ばい	健全な状態
② 飽和点（ニー）	いずれかのリソースが上限に接近	増加が鈍り頭打ち	急激に悪化し始める	ここが実質的な限界
③ 過負荷	キュー溢れ・リトライ発生	むしろ低下する	タイムアウト多発	サービス影響あり

②の折れ曲がり地点は「ニーポイント（膝）」や「飽和点」と呼ばれます。性能テストの目的のひとつは、この飽和点がどこにあるかを実測で特定し、本番のピーク負荷に対して、十分な余裕があるかを確認することです。

重要なのは、③の過負荷領域です。スループットが「上がらない」だけでなく、「下がる」からです。リクエストがキューに溜まり、タイムアウトしたクライアントが、リトライを繰り返します。

システムは無駄な仕事に資源を消費します。最大スループットだけを報告して「限界は◯◯rps」と結論づける。その手前でレスポンスタイムが許容範囲を超えていた、という見落としが起きます。

スループットとレスポンスタイムは、必ずセットで評価してください。

レイテンシとレスポンスタイムの違い

レスポンスタイムと似た用語に「レイテンシ（Latency）」があります。厳密には次のように区別されます。

レイテンシ：リクエストを送ってから最初の反応が返り始めるまでの「遅延時間」。ネットワーク伝送やキュー待ちなど、実処理以外の待ち時間を指すことが多い
レスポンスタイム：リクエスト送信から、レスポンスを受け取り終えるまでの合計時間。レイテンシ＋サーバー処理時間＋転送時間を含む

実務では両者が同義で使われる場面も多いのですが、性能テストの報告書では定義を明記しておくべきです。特に「レイテンシ 200ms」という報告が、ネットワーク往復時間だけなのか、サーバー処理を含む全体なのかで、ボトルネックの解釈がまったく変わります。

同時実行ユーザー数・ターンアラウンドタイムとの関係

スループットを正しく読むには、周辺の性能指標との関係も押さえておく必要があります。

同時実行ユーザー数（Concurrent Users）

同時実行ユーザー数とは、ある瞬間に、システムに対して処理を要求している利用者の数です。負荷テストツールでは「仮想ユーザー数（VU：Virtual Users）」として設定します。

ここで頻出する誤解が、「同時接続ユーザー数」と「同時実行ユーザー数」の混同です。ECサイトに1万人がログインしていても、その全員が同じ瞬間に、ボタンを押すわけではありません。実際にサーバーが処理しているのは、そのうち数十〜数百人分のリクエストです。

要件定義で「同時1万ユーザー」とだけ書かれている場合は、確認が必要です。ログイン中の総数なのか、同時にリクエストを発行している数なのか。必ず確かめてください。

ターンアラウンドタイム（Turnaround Time）

ターンアラウンドタイムは、依頼を出してから、結果をすべて受け取り終えるまでの総所要時間を指します。もともとはバッチ処理の文脈で使われる用語で、「ジョブを投入してから全結果が出力されるまで」を意味します。

レスポンスタイムが「反応が返ってくるまで」を測るのに対し、ターンアラウンドタイムは「仕事が完全に終わるまで」を測ります。オンライン処理では、この2つはほぼ同義になります。

帳票出力やCSVダウンロード、夜間バッチでは、結果全体の受領に時間がかかります。ここでは明確に区別する必要があります。

性能指標の整理表

指標	定義	単位	誰にとっての指標か
スループット	単位時間あたりの処理量	tps / rps / qps	システム提供側（キャパシティ）
レスポンスタイム	リクエスト送信〜レスポンス受信完了	ms / 秒	エンドユーザー（体感速度）
レイテンシ	反応が返り始めるまでの遅延	ms	インフラ・ネットワーク担当
ターンアラウンドタイム	依頼〜全結果受領までの総時間	秒 / 分 / 時間	バッチ運用担当
同時実行ユーザー数	同時に処理を要求している利用者数	人 / VU	テスト設計者
リソース使用率	CPU・メモリ等の消費割合	%	インフラ担当（余裕度判断）
エラー率	失敗したリクエストの割合	%	品質保証担当（合否判定）

性能テストの報告では、これらを単独ではなく、組み合わせて読むことが不可欠です。

「スループット 800rps 達成」という結果も、同時にエラー率が5%出ていれば意味が変わります。実質的には、失敗した処理を含んだ数字です。

リトルの法則：スループットとレスポンスタイムを結ぶ数式

スループット・レスポンスタイム・同時実行数の3つは、感覚的な関係ではなく数式で厳密に結びついています。それが待ち行列理論の「リトルの法則（Little’s Law）」です。

公式

平均同時実行数（L）＝スループット（λ）× 平均応答時間（W）。

L：システム内に滞留している処理の平均数。
λ：単位時間あたりに到着・完了する処理数（スループット）。
W：1件の処理がシステム内に滞在する平均時間（応答時間）。

この式は変形すると、次のようにも使えます。

スループット＝同時実行数 ÷ 応答時間
応答時間＝同時実行数 ÷ スループット

具体的な計算例

例1：必要な同時実行数を求める

目標スループットが 200rps、1リクエストの平均応答時間が 0.5秒だとします。システム内に常時滞留するリクエスト数は、次のようになります。

L ＝ 200（件/秒）× 0.5（秒）＝ 100件

この条件を満たすには、アプリケーションサーバーが、常時100件を並行処理できる必要があります。スレッドプールが50しかなければ、残りは待ち行列に入り、応答時間は伸びます。

スレッドプール数やコネクションプール数の妥当性を、勘ではなく数式で検証できる。これがリトルの法則の実用的な価値です。

例2：応答時間の悪化を予測する

同時実行数を100に固定したまま、スループットの上限が100rpsだったとします。このとき応答時間は次のようになります。

W ＝ 100（件）÷ 100（件/秒）＝ 1秒

先ほどの0.5秒から1秒へ、応答時間がちょうど2倍に悪化しました。同時実行数を増やしても、スループットの上限が変わらない限り、増えた分はすべて、待ち時間として応答時間に跳ね返ります。これが「同時実行数を上げるとレスポンスタイムが悪化する」ことの数学的な裏付けです。

負荷テストの妥当性チェックにも使える

リトルの法則は、負荷テストの結果が信頼できるかを検算する用途でも有効です。

テストツールの設定した仮想ユーザー数（L）を確認する
実測されたスループット（λ）と平均応答時間（W）を取得する
λ × W を計算し、設定した仮想ユーザー数とおおむね一致するか確認する
大きくずれている場合、負荷生成側がボトルネックになっている、think time（思考時間）の設定を計算に含めていない、といった原因を疑う

シナリオに think time（ユーザーが画面を見て考えている時間）を設定している場合、W には think time も含めて計算します。

「仮想ユーザー100人で走らせたのに λ × W が20にしかならない」。このときは、負荷生成側のクライアントマシンが、先に限界を迎えています。テスト結果そのものが無効です。

負荷テストのシナリオ設計手順と、あわせて確認してください。

スループットが頭打ちになる原因＝ボトルネックの見つけ方

スループットは、システムを構成する要素のうち最も遅い箇所（ボトルネック）によって決まります。他の要素をいくら増強しても、ボトルネックが解消されない限り、全体のスループットは改善しません。

代表的なボトルネックと兆候

ボトルネック箇所	典型的な兆候	確認する指標	主な対処の方向性
CPU	負荷を上げるとCPU使用率が100%に張り付く	CPU使用率、ロードアベレージ、run queue長	アルゴリズム改善、スケールアウト、CPU増強
メモリ	スワップ発生、GC（ガベージコレクション）が頻発し処理が止まる	空きメモリ、スワップ量、GC回数・GC停止時間	ヒープサイズ調整、メモリリーク修正、増設
ディスクI/O	CPUに余裕があるのにスループットが伸びない	IOPS、I/O待ち率（iowait）、ディスクキュー長	SSD化、インデックス見直し、ログ出力量削減
ネットワーク	大きなレスポンスで顕著に遅い、帯域が上限に到達	帯域使用率、パケットロス率、RTT	圧縮、CDN活用、レスポンスサイズ削減
DBコネクションプール	アプリ側で待ちが発生、DBサーバーは暇そう	プール待機数、接続取得待ち時間	プールサイズ調整、接続の早期返却
ロック競合	同時実行数を上げるほど効率が悪化する	ロック待ち時間、デッドロック件数、待機イベント	トランザクション短縮、粒度見直し、順序統一
外部API連携	特定処理だけ突出して遅い、相手先の制限に抵触	外部呼び出しの応答時間、レート制限エラー	非同期化、キャッシュ、バルク呼び出し
負荷生成側（ツール）	サーバー側リソースに余裕があるのに頭打ち	負荷クライアントのCPU・帯域	負荷生成機の分散・増設

最後の「負荷生成側がボトルネック」は見落とされがちです。実際にはよく起こります。

サーバー側の全リソースに余裕があるのに、スループットが伸びない。この場合、まず疑うべきは負荷をかけている側です。

ボトルネック特定の進め方

全レイヤーの計測を先に仕込む：Webサーバー、APサーバー、DBサーバー、ネットワーク機器のリソース監視を、テスト開始前に有効化しておきます。後から「あのときのCPUは？」となっても取り返しがつきません。
負荷を段階的に上げる：いきなり最大負荷をかけず、25%・50%・75%・100%と段階的に上げ、スループットが線形に伸びなくなる地点を特定します。
飽和しているリソースを探す：スループットが頭打ちになった時点で、使用率が上限に張り付いている指標を探します。これがボトルネックの第一候補です。
処理を分解して時間配分を見る：APM（Application Performance Monitoring）やスロークエリログで、1リクエストの内訳（アプリ処理／DB／外部API）を分解します。
1箇所ずつ改善して再計測する：複数の改善を同時に入れると、何が効いたのか判別できません。1つ直すたびに測り直します。
ボトルネックが移動したことを確認する：ある箇所を解消すると、次に遅い箇所が新たなボトルネックとして現れます。目標値に達するまでこのサイクルを繰り返します。

「ボトルネックは必ず移動する」というのが性能改善の基本原則です。1回の改善で目標に届くことは稀で、通常は数サイクルの計測と改善を繰り返します。この工数を見積もりに織り込んでおかないと、性能テスト工程は確実に炎上します。

性能テストでスループットを測定する方法

スループットは実際に負荷をかけなければ測れません。ここでは性能テストの種類と、測定手順を整理します。

性能テストの4つの種類

「性能テスト」は総称であり、目的によって次の4種類に分かれます。それぞれ負荷のかけ方も、見るべき指標も異なります。

テスト種類	目的	負荷のかけ方	実施時間の目安	スループットの見方
負荷テスト（Load Test）	想定内の負荷で要件を満たすか検証	想定ピーク負荷を一定時間かける	30分〜数時間	目標スループットを維持できるか
ストレステスト（Stress Test）	限界点と限界時の挙動を把握	想定を超える負荷まで段階的に増加	限界到達まで	最大スループットと飽和点を特定
耐久テスト（ソークテスト）	長時間稼働での劣化を検出	中程度の負荷を長時間継続	8時間〜数日	時間経過でスループットが低下しないか
スパイクテスト（Spike Test）	急激な負荷変動への耐性確認	短時間で負荷を急増・急減	数分〜数十分	急増直後の落ち込みと回復速度

ストレステストは「どこで壊れるか、壊れ方は許容できるか」を見ます。限界超過時にサービス全体がダウンするのか、一部機能の劣化で踏みとどまるのかは、事業影響がまったく違います。
耐久テスト（ソークテスト）は、メモリリークや接続リーク、ログによるディスク圧迫など、短時間テストでは見つからない問題を炙り出します。開始直後は500rps出ていたのに6時間後には300rpsに落ちている、といった劣化はここでしか検出できません。
スパイクテストは、TVCM放映直後やセール開始時刻など瞬間的にアクセスが集中する場面を模擬し、オートスケールの起動が間に合うかを検証します。

性能テストは、ソフトウェアテスト全体のどこに位置づけられるのか。システムテストの種類一覧で、全体像を確認できます。

測定の基本手順

目標値を決める：「ピーク時 300rps、95パーセンタイル応答時間 2秒以内、エラー率 0.1%未満」のように、スループット・応答時間・エラー率をセットで定義します。
測定対象のトランザクションを定義する：「1トランザクション＝ログイン〜検索〜カート投入」なのか「1リクエスト＝1HTTP通信」なのかを明確にします。ここが曖昧だと数字が比較不能になります。
テスト環境を整える：本番と同等のスペック・構成が理想です。差がある場合は、その差を報告書に明記します。データ量も本番相当にしないと、DBのスループットはまったく違う値になります。
ウォームアップを行う：JITコンパイル、キャッシュ、コネクションプールが温まるまでは本来の性能が出ません。計測開始前に数分間の助走を入れ、その区間は集計から除外します。
負荷をかけて計測する：スループット、応答時間（平均だけでなく中央値・90/95/99パーセンタイル）、エラー率、各種リソース使用率を同時に記録します。
結果を分析する：目標達成の可否に加え、飽和点の位置、ボトルネック箇所、本番ピークに対する余裕率を評価します。
改善と再測定を繰り返す：改善は1回に1箇所。変更前後の条件を揃えて比較します。

平均値だけを見てはいけない

スループットとあわせて記録する応答時間について、平均値だけの報告は実態を大きく歪めます。

1000件のリクエストのうち、950件が0.2秒、50件が10秒だったとします。平均は約0.69秒となり、「良好」に見えます。実際には5%の利用者が10秒待たされ、その多くは離脱しているはずです。

90パーセンタイル・95パーセンタイル・99パーセンタイルを、必ず併記してください。

「95パーセンタイルで2秒以内」という要件は、100人中95人が、2秒以内に結果を得られることを意味します。平均値より、はるかに実態に即した基準です。

スループット測定に使われる主なツール

負荷をかけてスループットを測定するツールは、複数あります。チームのスキルセットや対象システムの特性で、選び分けます。

ツール	シナリオ記述	特徴	向いているケース
Apache JMeter	GUI（XML）	最も普及。プロトコル対応が幅広く情報も豊富。GUIで組めるためプログラミング不要	幅広い現場、非エンジニアも関わるチーム
Gatling	Scala / Java DSL	少ないリソースで高負荷を生成でき、HTMLレポートが見やすい	大規模負荷、コードでシナリオ管理したい場合
k6	JavaScript	Go製で軽量。CLI中心でCI/CDに組み込みやすい	継続的な性能テストの自動化
Locust	Python	Pythonでシナリオを自由に記述。分散実行が容易	Python資産のあるチーム、複雑なシナリオ
Apache Bench（ab）	コマンド引数のみ	単一URLへの負荷を即座に測れる最小構成のツール	簡易的な確認、切り分けの初手

ツール選定でよくある失敗が、負荷生成機のスペックを軽視することです。JMeter を GUI モードのまま、1台のノートPCで動かし、「500rpsが限界」と結論づける。実際にはJMeter側が先に限界を迎えていた、というケースは珍しくありません。

本番相当の負荷をかけるなら、CLIモードでの実行や、複数台への分散を前提に設計してください。

ネットワークにおけるスループット（通信速度の文脈）

「スループット」という言葉は、ネットワーク機器・回線の文脈でも頻繁に使われます。この場合は、単位時間あたりに、実際に転送できたデータ量を指します。単位は bps（bits per second）です。

帯域幅とスループットは別物

回線契約に「最大1Gbps」と書かれていても、実際に1Gbps出ることはまずありません。

帯域幅（Bandwidth）：理論上の最大転送能力。道路でいえば「車線数」
スループット：実際に転送できた量。道路でいえば「実際に通行した車の数」

帯域幅は「出せる上限」、スループットは「実際に出た値」であり、後者が前者を上回ることはありません。ネットワークのスループットを低下させる主な要因は、次のとおりです。

低下要因	内容	対処の方向性
帯域幅の不足	契約回線の上限に到達している	回線増速、時間帯による負荷分散
機器の処理能力	ルーター・スイッチ・FWの処理性能が上限	機器のリプレース、負荷分散
パケットロス	再送が発生し実効転送量が落ちる	ケーブル・機器の点検、輻輳制御の見直し
レイテンシ（RTT）	遅延が大きいとTCPのウィンドウ制御で頭打ち	拠点間の経路最適化、CDN活用
プロトコルのオーバーヘッド	ヘッダ・暗号化処理で実データ以外を転送	圧縮、通信回数の削減

Webシステムの性能テストでも、ネットワークのスループットは無視できません。アプリケーションのスループットが十分でも、画像や添付ファイルのサイズが大きければ、回線側が先に飽和します。

テスト環境と本番環境で構成が異なる場合、この差が結果の乖離となります。報告書に明記してください。

性能要件としてスループットをどう定義するか

性能テストの合否を判定するには、前提となる性能要件が、定量的に定義されている必要があります。

実際には「サクサク動くこと」「業務に支障のない速度」といった記述が残ります。曖昧なまま設計工程に進むプロジェクトが、後を絶ちません。

ピーク時のスループットを算出する

目標スループットは、業務量から逆算するのが基本です。

業務量を洗い出す：1日あたりの想定処理件数（例：注文 50,000件/日）を業務部門から取得します。
時間帯の偏りを反映する：アクセスは均等に分散しません。「1日の40%が2時間に集中する」といった集中率を掛けます。
秒あたりに換算する：50,000件 × 40% ÷ 7,200秒 ≒ 約2.8件/秒がピーク時の平均です。
瞬間ピーク係数を掛ける：さらに短時間の山を考慮し、2〜3倍程度の係数を掛けます。上の例なら約6〜9件/秒。
将来の伸びを織り込む：システムの想定稼働年数（例：5年後に1.5倍）を掛けて目標値を確定します。
1業務あたりのリクエスト数を掛ける：1件の注文が内部で10回のHTTPリクエストを伴うなら、rps ベースの目標値は10倍になります。

要件の書き方の例

悪い例と良い例を対比します。

悪い例：「注文処理は高速に動作すること」——測定不能で、合否判定ができません。
悪い例：「スループット100以上」——単位も測定条件も不明です。
良い例：「本番同等構成において、注文登録トランザクションを同時実行ユーザー200人で30分間継続実行したとき、スループット 30tps 以上を維持し、95パーセンタイル応答時間 2.0秒以内、エラー率 0.1%未満であること」

良い例には、測定対象・測定条件・スループット・応答時間・エラー率・継続時間の、すべてが含まれています。性能要件は「数値＋測定条件」のセットで初めて意味を持ちます。

要件定義の考え方をより詳しく知りたい場合は、システム性能要件の定義方法を参照してください。

要件定義とテスト工程の対応関係は、Vモデルの考え方で整理するとわかりやすくなります。

性能要件は要件定義フェーズで決め、システムテストフェーズで検証します。この対応関係が崩れると、テスト工程で「そもそも何を満たせば合格なのか」が決まっていません。

性能テストを外部に委託するという選択肢

ここまで見てきたとおり、スループットの測定と改善は、負荷テストツールの操作だけでは完結しません。実際には、次のようなスキルと工数が同時に要求されます。

業務量からピーク時の目標スループットを算出する要件定義力
本番の利用実態を再現する負荷シナリオの設計
負荷生成環境の構築と、負荷生成側がボトルネックにならないことの担保
OS・ミドルウェア・DB・アプリケーション各層の同時モニタリング
取得したメトリクスからボトルネックを特定する分析力
改善と再測定を繰り返すための工数確保

性能テストは実施頻度が低く、数年に一度の大規模リリース時にしか、行わない現場もあります。ノウハウが組織に蓄積されにくい工程です。

リリース直前の、最も逼迫した時期に集中しやすい工程でもあります。

ソフトウェアテスト代行サービス『テスター10』では、性能テストを一貫して支援しています。計画立案、負荷シナリオ設計、実測、ボトルネック分析、報告書作成までが対象です。

開発チームは、機能実装と改善対応に集中できます。測定と分析を外部の専門要員に任せれば、リリース前の期間を効率的に使えます。

「目標スループットの決め方から相談したい」「一度測ってみたが結果の読み方がわからない」。こうした段階からのご相談も承っています。

よくある質問（FAQ）

Q. スループットとレスポンスタイム、どちらを優先すべきですか？

システムの性質によります。ECサイトや業務システムのオンライン画面では、利用者が結果を待っています。この場合はレスポンスタイムが優先されます。

夜間バッチやデータ移行、ログ集計は「時間内に全件終わればよい」処理です。ここではスループットが優先されます。

どちらか一方だけを要件にするのは危険です。両方に目標値を設定してください。片方を満たすために、もう片方が許容範囲を超えていないか、必ず確認します。

Q. スループットを上げれば必ずレスポンスタイムは悪化しますか？

いいえ、必ずではありません。同時実行数を増やしてスループットを上げた場合は、レスポンスタイムが悪化します。SQLのインデックス追加やアルゴリズム改善のように、1件あたりの処理を速くしてスループットを上げた場合は、レスポンスタイムも同時に改善します。

リトルの法則（L ＝ λ × W）で言えば、前者は L を増やす施策です。後者は W を減らす施策であり、こちらのほうが望ましい改善です。

Q. サーバーを増やせばスループットは比例して上がりますか？

ボトルネックがそのサーバー層にある場合に限り、ある程度までは比例します。ボトルネックがデータベースや外部APIなど、共有されるリソースにある場合は違います。アプリケーションサーバーを何台増やしても、スループットは変わりません。

DBへのコネクション数が増えて競合が激化し、悪化することさえあります。増強の前に、必ずボトルネックがどこにあるかを、実測で特定してください。

Q. tps と rps はどう使い分けますか？

tps は業務トランザクション単位、rps はHTTPリクエスト単位で数えるのが一般的です。1つの業務トランザクション（例：注文確定）は、内部で複数のHTTPリクエストやSQLを伴います。同じシステムでも、tps と rps の値は異なります。

報告書では「1トランザクションの定義」を明記したうえで、数値を出してください。定義が共有されていない数値の比較は、無意味です。

Q. テスト環境が本番より小さくても測定する意味はありますか？

あります。得られる結論は限定されます。小規模環境でわかるのは「アプリケーションロジックに明らかな性能問題があるか」「スケールする構造になっているか」といった定性的な情報です。

絶対値としての最大スループットを、本番環境に外挿することはできません。データベースは、データ件数が本番の1/100であれば、インデックスの効き方も、キャッシュヒット率も異なります。

小規模環境での測定は「問題の早期発見」目的と割り切ってください。最終判断は、本番同等環境で行うのが原則です。

Q. 性能テストはどのタイミングで実施すべきですか？

リリース直前の1回だけ、という進め方は最も危険です。性能問題はアーキテクチャに起因することが多く、直前に発覚しても改修が間に合いません。理想は、主要機能が結合できた段階で、簡易的な測定を始めることです。

そこから段階的に本格化させます。CI/CDに k6 などを組み込み、変更のたびに、主要エンドポイントのスループットを自動記録する。性能劣化を起こしたコミットを即座に特定できます。

まとめ

スループットについて、本記事の要点を整理します。

スループットは単位時間あたりに処理できる量。tps・rps・qps・bps・件/時など、単位を必ず明示する
レスポンスタイムは1件あたりの所要時間。高速道路でいえばスループットが「車線数」、レスポンスタイムが「目的地までの所要時間」
同時実行数を上げるとスループットは上がるがレスポンスタイムは悪化するというトレードオフがある。両者は必ずセットで評価する
リトルの法則（同時実行数＝スループット × 応答時間）を使えば、必要なスレッド数の妥当性検証や、テスト結果の検算ができる
スループットはボトルネックによって決まる。CPU・メモリ・ディスクI/O・ネットワーク・DBコネクション・ロック競合、そして負荷生成側を疑う
性能テストは負荷・ストレス・耐久（ソーク）・スパイクの4種類。目的に応じて使い分ける
性能要件は「数値＋測定条件」で定義する。応答時間はパーセンタイルで示す

スループットは、単体で見ても意味を持たない指標です。レスポンスタイム・エラー率・リソース使用率と組み合わせ、どの負荷条件で測った値なのかを添えて初めて、システムの実力を語れるようになります。性能テストの設計にあたっては、まず測定対象と目標値の定義から着手してください。

次に読むならこの記事

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する

よかったらシェアしてね！

システム安定運用の要！キャパシティプランニングの実践ガイド