性能テスト・負荷テスト・ストレステストの違いと使い分け

「テストの種類がよくわからない」——現場で起きる混乱の正体

システムの品質保証を検討する際、「性能テストを実施したい」という要望は共通していても、具体的に何をどの順で進めるべきかで現場が止まるケースは少なくありません。その原因の多くは、性能テスト・負荷テスト・ストレステストという3つの用語が、現場で明確な区別なく使われていることにあります。

たとえば、ベンダーへの発注書に「負荷テストを実施してほしい」と記載したものの、ベンダー側が想定していた内容と発注側の意図がずれていた、というケースがあります。発注側は「通常運用時の応答速度を確認したい」という意図であったのに対し、ベンダー側は「システムが限界を超えるまで負荷をかける試験」として設計してしまう、といった具合です。

こうした用語の混乱は、テスト設計の曖昧さに直結します。測定対象が定まらなければ、合否判定の基準も設けられません。結果として、テストを実施したにもかかわらず「何を確認できたのか」が不明確になり、リリース判断の根拠として機能しないケースが生まれます。

なお、これら3つは非機能テスト（システムの「動作の品質」を検証するテスト群）の中に位置づけられており、機能要件とは切り離して計画する必要があります。この前提を共有できていないと、テスト計画そのものがずれていきます。

本記事では、3つのテストの定義と目的の違いを整理したうえで、発注側の意思決定者が使い分けを判断できる基準と、外部委託時に確認すべき論点を解説します。

前提整理 — 性能テストは「上位概念」である

非機能テストにおける性能テストの位置づけ

ソフトウェアのテストは大きく「機能テスト」と「非機能テスト」に分かれます。機能テストが「仕様どおりに動くか」を確認するのに対し、非機能テストは「どれだけ速く・安定して動くか」「どれだけ安全か」といった品質特性を検証するものです。

性能テストは、この非機能テストの中に位置づけられます。セキュリティテストやユーザビリティテストと並ぶ領域であり、システムの応答速度・処理能力・安定性を総合的に評価することを目的としています。

性能テストに含まれる主なテスト種別の一覧

性能テストはあくまで上位概念です。その傘の下に、目的や手法の異なる複数のテスト種別が含まれます。主なものを以下に整理します。

• 負荷テスト：想定される通常〜ピーク時の負荷をかけ、応答時間やスループットを測定する
• ストレステスト：システムの限界を超える負荷をかけ、障害発生の閾値や挙動を確認する
• スパイクテスト：短時間に急激なアクセス増加が発生した場合の耐性を検証する
• 耐久テスト（ソークテスト）：長時間稼働させ続けたときのメモリリークや性能劣化を確認する

これらは並列の関係ではなく、「性能テスト」という枠組みの中に含まれる個別の手法です。この包含関係を最初に押さえておくことで、各テストの目的と使い分けが格段に理解しやすくなります。

3種類の定義と目的 — 何を測るテストなのか

性能テスト・負荷テスト・ストレステストは、それぞれ「何を明らかにしたいか」という目的が異なります。3種類の定義を目的軸で整理しておくと、発注時の方針決定がスムーズになります。

性能テスト — システムの応答速度・スループットを計測する

性能テストは、システムが「どのくらいの速さで処理できるか」を数値で把握するためのテストです。応答時間（レスポンスタイム）や単位時間あたりの処理件数（スループット）を計測し、設計段階で定めた性能要件を満たしているかどうかを確認します。

答える問いは、「このシステムは要件どおりの速度で動いているか」です。たとえば「注文確定ボタンを押してから3秒以内に画面が遷移すること」という要件があれば、その達成可否を定量的に検証します。負荷テストやストレステストはこの性能テストの枠組みの中に位置づけられる手法であり、上位概念として機能します。

負荷テスト — 想定ユーザー数での動作を検証する

負荷テストは、本番環境で想定される同時アクセス数や処理量を再現し、その条件下でシステムが正常に動作するかを検証するテストです。「繁忙期に500人が同時ログインする」といったシナリオを設定し、応答速度の低下やエラー発生の有無を確認します。

答える問いは、「想定した利用規模でシステムは耐えられるか」です。リリース前の最終確認や、機能追加後の回帰確認として実施されるケースが多く見られます。

ストレステスト — システムの限界点と回復力を確かめる

ストレステストは、想定を超える負荷を意図的に与え、システムがどこで限界を迎えるか、そして限界を超えた後に正常な状態へ回復できるかを確認するテストです。

答える問いは、「システムはいつ、どのように壊れ、そこから戻れるか」です。障害発生時の挙動やデータ保全の可否を事前に把握しておくことで、インシデント対応計画の精度を高めることができます。突発的なアクセス急増が想定されるサービスや、ミッションクリティカルなシステムで特に重要視される観点です。

3種類の比較表 — 目的・測定対象・実施タイミングを一覧で整理

前のセクションで確認した3種類の定義を、意思決定に使いやすい形で整理します。以下の比較表は、目的・測定する指標・想定する負荷パターン・主な実施タイミング・合否判定の考え方の5軸で性能テスト（パフォーマンステスト）・負荷テスト・ストレステストを対照しています。

「性能テスト 負荷テスト 違い」を検索する担当者の多くが知りたいのは定義の文章ではなく、「自分たちのプロジェクトにどれが必要か」を判断するための軸です。その視点で各列を読み比べてください。

• 目的：性能テスト＝要件への適合確認 ／ 負荷テスト＝想定ピーク時の安定動作確認 ／ ストレステスト＝限界点と回復挙動の把握
• 測定する主な指標：性能テスト＝レスポンスタイム・スループット ／ 負荷テスト＝同時接続数増加時のレスポンス変化・エラー率 ／ ストレステスト＝システム破綻点・障害後の復旧時間
• 想定する負荷パターン：性能テスト＝通常業務想定の一定負荷 ／ 負荷テスト＝ピーク時を再現する段階的増加 ／ ストレステスト＝仕様上限を超える意図的な過負荷
• 主な実施タイミング：性能テスト＝リリース前の受け入れテスト段階 ／ 負荷テスト＝大規模イベントや機能追加の前 ／ ストレステスト＝インフラ構成変更時・障害対応計画の策定時
• 合否判定の考え方：性能テスト＝事前に定めたSLA（サービス品質基準）との適合 ／ 負荷テスト＝ピーク負荷下でのエラー率・応答時間が閾値内か ／ ストレステスト＝合否というより「限界値の把握」と「回復の確認」が目的

特に注意が必要なのはストレステストの合否判定です。性能テストや負荷テストは「基準を満たすか否か」で判定できますが、ストレステストは意図的に失敗させることに意味があります。どの条件で何が起き、どう回復したかを記録することが目的のため、「合格・不合格」ではなく「知見の取得」として位置づけるのが適切です。

非機能テスト全体の設計を検討する際は、この5軸を参照しながら「どのテストを・いつ・何の目的で実施するか」を事前に整理しておくと、発注時の要件定義がスムーズになります。

使い分けの判断軸 — どの局面でどのテストを選ぶか

テストの種類を理解したあとに直面するのが、「自分たちのプロジェクトでは何を優先すべきか」という判断です。ここでは、発注側が実際に直面しやすい3つのビジネス局面ごとに、選ぶべきテストとその理由を整理します。

新規システムのリリース前に実施すべきテスト

リリース前の受入確認では、負荷テストを起点に、性能テスト全体を計画的に組み合わせることが基本です。まず通常想定される同時アクセス数や処理件数を定義し、その条件下でレスポンスタイムやスループットが要件を満たすかを確認します。これが負荷テストの主目的です。

加えて、ユーザー数が段階的に増加したときの挙動を見るスパイクテストを組み合わせると、リリース直後のアクセス集中に対する耐性も事前に把握できます。「機能が動く」だけでなく「想定規模で安定して動く」ことを確かめるのが、この局面における性能テストの役割です。

大規模キャンペーンや季節変動が見込まれる場合

ECサイトの年末セールや、BtoBであれば期末の受注集中・一斉メール配信など、短期間にアクセスや処理量が急増する施策の前にはスパイクテストとストレステストの両方が有効です。

スパイクテストで急激な負荷増加に対するシステムの反応を確認し、ストレステストで限界値を把握しておくことで、「どのくらいの規模までなら安全に捌けるか」という具体的な上限が見えます。この数値が、インフラ増強やアクセス制限の判断基準になります。

障害・性能劣化が疑われる既存システムの調査

「以前より動作が重くなった」「特定の時間帯に処理が遅延する」といった既存システムの不具合調査では、ストレステストを用いてボトルネックの所在を特定するアプローチが適しています。意図的に高負荷をかけながらCPU・メモリ・DBの応答を計測することで、どのコンポーネントが先に限界を迎えるかが可視化されます。

負荷テストのやり方として「通常負荷から始めて段階的に上げる」手順が一般的ですが、既存システムの調査では現行の運用データを参照しながら再現負荷を設計することが精度を高めます。性能テストと負荷テストの違いを踏まえると、「現状把握と原因特定」が目的の局面ではストレステストが最も実態に近い情報をもたらします。

負荷テストの実施手順 — 計画から結果評価までのステップ

負荷テストの精度は、ツールの選定よりも「進め方の設計」に左右されます。以下の5ステップは、発注側が各フェーズで何を確認・承認すべきかを意識しながら読み進めてください。外部委託時の品質チェックにもそのまま活用できます。

ステップ1：目標値（KPI）と合格基準を先に決める

テストを始める前に、「何をもって合格とするか」を数値で定義します。たとえば「同時接続500ユーザー時のレスポンスタイムが2秒以内」「エラー率0.1%未満」といった具体的な合格基準が必要です。この目標値が曖昧なままでは、テスト結果が出ても合否を判断できません。

発注側が確認すべきポイントは、業務上の要件（ピーク時のアクセス数・許容できる遅延）と、目標値の根拠がセットで提示されているかどうかです。根拠のない数値は、後工程の改善判断にも使えません。

ステップ2：ユーザー行動シナリオを設計する

実際のユーザーがどのような操作をするかをシナリオとして再現します。「ログイン→商品検索→カート追加→決済」のように、業務フローに沿った一連の操作を定義します。単純なページアクセスの繰り返しでは、実態と乖離した結果が出るケースが少なくありません。

発注側が確認すべきポイントは、シナリオが実際の業務フローをカバーしているか、ピーク時に集中する操作が含まれているかです。現場の業務担当者と連携してシナリオを精査することが重要です。

ステップ3：本番環境に近い構成でテスト環境を用意する

テスト環境のスペックが本番と大きく異なると、測定結果の信頼性が損なわれます。サーバーのCPU・メモリ・ネットワーク構成、データ量、外部連携サービスの有無など、本番との差異を事前に洗い出して記録します。

発注側が確認すべきポイントは、「本番との差異一覧」がドキュメントとして用意されているかどうかです。差異がある場合は、それが測定結果にどう影響するかを受託側に説明させるようにします。

ステップ4：段階的に負荷をかけてボトルネックを特定する

いきなり最大負荷をかけるのではなく、ユーザー数を段階的に増やしながら計測します。たとえば100・200・300・500ユーザーと段階を刻むことで、どのラインからレスポンスタイムが悪化し始めるかが明確になります。

性能テストツール（JMeter・Gatling・k6など）はこの段階制御に対応しており、CPU使用率・メモリ・DBクエリの応答時間といった指標をリアルタイムで記録できます。発注側が確認すべきポイントは、負荷の増加に連動したメトリクスのグラフが記録・保存されているかどうかです。

ステップ5：結果を分析し改善策に落とし込む

テスト結果の報告は、「ボトルネックの場所」「原因の仮説」「改善策の優先順位」の3点がセットで提示されることが理想です。「レスポンスが遅かった」という事実の記録だけでは、次のアクションにつながりません。

発注側が確認すべきポイントは、改善策に技術的な実現可能性と工数の見通しが付いているかどうかです。インフラ改善・アプリケーションのチューニング・キャッシュ設計の見直しなど、改善の手段は複数あります。負荷テストのやり方として重要なのは、テスト実施そのものよりも、この改善提言まで設計に含めることです。

代表的な性能テストツール — 特徴と選定基準

性能テストの実施方針が固まったら、次に検討するのがツール選定です。主要ツールはいずれも無償で利用できますが、対応プロトコル・学習コスト・CI/CDとの連携しやすさはそれぞれ異なります。プロジェクト規模やチームのスキルセットに合わないツールを選ぶと、シナリオ作成に想定以上の工数がかかるケースが少なくありません。以下では代表的な4ツールの特徴を整理します。

Apache JMeter — GUIで設定できる定番ツール

Apache JMeterはHTTP・FTP・JDBCなど多様なプロトコルに対応した、最も歴史の長い負荷テストツールです。GUIでシナリオを組み立てられるため、コーディング経験が少ない担当者でも比較的早く使い始められます。一方で、テストスクリプトをXML形式で管理する構造上、Gitでの差分管理やCI/CDパイプラインへの組み込みには追加の設定が必要です。社内に専任のQA担当者がいるチームや、プロトコルの種類が多い既存システムの検証に向いています。

k6 — コードベースでCI連携しやすいモダンなツール

k6はJavaScriptでテストスクリプトを記述するツールで、GitHub ActionsやJenkinsなどのCI/CDツールとの親和性が高いのが特徴です。Grafanaとの統合によりリアルタイムのメトリクス可視化もスムーズに行えます。学習コストはJMeterより高めですが、開発チームがすでにJavaScriptに慣れている環境であれば立ち上がりは早いです。継続的デリバリーの仕組みの中で性能テストを自動化したい場合に選択肢の筆頭になります。

Gatling — 高負荷シナリオに強いScalaベースのツール

GatlingはScalaをベースとしており、少ないリソースで高い同時接続数を再現できる点が強みです。シナリオはコードで記述するため、テストの再現性・保守性が高く、大規模なECサイトや金融系システムの負荷テストで採用される事例が見られます。ただしScalaの知識が前提となるため、チームにScala経験者がいない場合は学習コストが課題になります。数万件規模の同時アクセスを想定するシステムで本領を発揮するツールです。

Locust — Pythonで書けるシンプルな分散負荷ツール

LocustはPythonでシナリオを記述できる分散負荷テストツールです。Pythonが読み書きできるエンジニアであればすぐに導入でき、複数台のマシンに負荷を分散させる構成も比較的簡単に組めます。大規模な同時接続には専用インフラの準備が必要ですが、中小規模のWebアプリケーションや社内業務システムの検証には十分な性能を発揮します。データサイエンス系のチームやPythonを主言語とする開発組織に向いています。

ツール選定のチェックポイント

ツール選定で迷う場合は、以下の観点を順に確認すると判断しやすくなります。

• チームの主言語は何か：JavaScript中心ならk6、Pythonならlocust、言語スキルが限定的ならJMeterが入り口として適しています。
• CI/CDへの組み込みが必須か：自動化が要件であればk6またはGatlingを優先して検討します。
• 想定する同時接続数の規模：数万件を超える高負荷シナリオにはGatlingが有利です。中小規模であればいずれのツールでも対応できます。
• 対応プロトコルの種類：HTTPに限らずJDBC・FTPなど複数プロトコルが対象ならJMeterの対応範囲が広くなります。

プロジェクトの初期段階では「チームが使いこなせるツール」を選ぶことが、テスト品質の安定に直結します。高機能なツールを導入してもシナリオ作成が止まってしまえば、性能テスト自体の実施が遅延するリスクがあります。

発注前に確認したい3つの論点 — 外部委託時のチェックポイント

非機能テスト・性能テストを外部委託する際、発注側が「おまかせ」にしてしまうと、納品後に「何をテストしたのかわからない」「本番で問題が起きても原因を追えない」という事態に陥りやすいです。発注前に以下の3点を確認・合意しておくことで、成果物の品質と事後の活用可能性が大きく変わります。

テスト対象スコープと目標値は契約前に文書化する

「負荷テストをやり方含めてお任せ」という発注は、認識ズレのリスクが高くなります。最低限、次の項目を契約前に書面で合意しておくことをお勧めします。

• テスト対象の機能・APIエンドポイントの一覧：どの画面・処理が対象に含まれるかを明示します
• 目標とする性能指標と合否ライン：例として「同時接続200ユーザー時のレスポンスタイム2秒以内、エラー率1%未満」のように数値で定義します
• 想定シナリオの内容：ログイン→検索→決済のような代表的なユーザー操作フローを事前に定めます

目標値が曖昧なまま進めると、テスト結果が「合格」か「不合格」かを判断する基準自体が存在しない状態になります。CLANEが品質支援プロジェクトで受けた相談の中にも、「結果は出たが何と比べればいいかわからない」というケースが少なくありません。

テスト環境と本番環境の差異をどう扱うか

負荷テストのやり方として見落とされやすいのが、テスト環境と本番環境のスペック差です。テスト環境がスケールダウンされた構成である場合、そのまま結果を本番に外挿するのは危険です。

確認すべきポイントは以下のとおりです。

• サーバースペックの比率：テスト環境が本番の何割相当かを把握し、換算係数を設けます
• ミドルウェア・ネットワーク構成の一致度：CDNやロードバランサーの有無が結果に影響します
• データ量の違い：本番データに近い件数でテストしないと、インデックスやクエリの挙動が変わるケースがあります

受託側に「環境差異を考慮した補正見解」を成果物として求めることが、実務上は有効です。

結果レポートで確認すべき指標と読み解き方

性能テストの結果レポートを受け取った際、意思決定者が最低限チェックすべき指標は次の3つです。

• スループット（RPS／TPS）：単位時間あたりの処理件数です。目標値との乖離が大きい場合はボトルネック箇所の特定を求めます
• レスポンスタイムのパーセンタイル値：平均値だけでなく、95パーセンタイル・99パーセンタイルを確認します。外れ値が多いシステムは平均が良好でも体感品質が低いことがあります
• エラー率とエラー種別：タイムアウト・5xxエラー・接続拒否のどれが発生しているかで対処方法が異なります

「グラフが添付されているから大丈夫」ではなく、上記の指標が目標値と対比できる形で記載されているかを確認することが、発注側の最低限の品質管理です。

まとめ — 3種類のテストを正しく使い分けるために

性能テスト・負荷テスト・ストレステストの違いと使い分けについて、ここで要点を整理します。

まず前提として、性能テストは上位概念です。負荷テストとストレステストは、どちらも性能テストの一種として位置づけられます。「性能テストと負荷テストの違いは何か」という問いに対しては、「性能テストの中に負荷テストが含まれる」というのが正確な答えになります。

3種類の目的の違いは次のように整理できます。

• 負荷テスト：想定される利用規模や同時アクセス数のもとで、応答時間やスループットが要件を満たすかを確認する
• ストレステスト：想定を超える負荷をかけてシステムの限界点を把握し、障害発生時の挙動や回復性を検証する
• 性能テスト（広義）：上記を含む、システム全体の非機能要件を測定・評価するテスト群の総称

使い分けの判断軸は、「何を確かめたいか」と「どの局面にあるか」の2点です。リリース前の品質確認であれば負荷テストが中心になります。一方、大規模アクセスが見込まれるキャンペーンや、障害時の事業継続リスクを評価したい場面では、ストレステストの実施が有効な選択肢になります。

発注側の意思決定者として押さえておくべきポイントは3つです。

1. テスト設計の前に、測定対象と合否判定の基準（応答時間・エラー率など）を明文化しておくこと
2. 本番に近い環境でテストを実施しないと、結果の信頼性が低下すること
3. 外部委託する場合は、ツール選定の理由・シナリオ設計の根拠・結果の読み方まで説明を求めること

テストの種類や手順を正確に理解することは、品質保証の精度を上げるだけでなく、外部ベンダーとの認識齟齬を防ぐうえでも重要です。まずは自社システムの現状と、検証すべき非機能要件を棚卸しするところから始めると、テスト設計の議論が具体的に進みやすくなります。