負荷テストとは？目的・種類・やり方を全体像で解説

2026 8/02

2026年8月2日 2026年8月7日

「リリースやキャンペーンを控えて調べ始めたものの、記事ごとに用語や分類が違って全体像がつかめない」——負荷テストとは何かを検索したとき、多くの方が最初に突き当たる壁です。性能テスト、ストレステスト、スパイクテストと似た言葉が並び、どこから手を付ければよいか迷ってしまいます。

本記事は、細部を網羅する代わりに、負荷テストの全体像（定義・目的・種類・手順・ツール）を1記事で大まかに理解できることをゴールにしています。あわせて、実務で必ず聞かれる「費用や工数はどれくらいか」「今から着手して間に合うのか」という疑問にも、目安の形で答えます。

深掘りが必要なテーマは、それぞれ関連記事を案内します。負荷テストの経験が浅い方が最初に読む1本として、お使いください。

負荷テストとは？定義と関連テストとの位置づけ

まずは言葉の整理から始めます。ここが曖昧なままだと、社内やクライアントとの会話がかみ合わなくなるためです。

負荷テストの定義

負荷テストとは、システムに想定される負荷（同時アクセスや大量のデータ処理）を意図的にかけ、性能の要件を満たせるかどうかを確認するテストです。

普段の機能テストが「正しく動くか」を確かめるのに対し、負荷テストが確かめるのは「どれだけ快適に、安定して動くか」です。両者は目的がまったく異なります。

機能テスト: 仕様どおりに正しく動作するかを確認する
負荷テスト: 多数の利用が集中しても、速度や安定性を保てるかを確認する

このように、負荷テストは機能以外の要求を確かめる「非機能テスト」に分類されます。書籍でも、パフォーマンステストは非機能要求に対するテストの1つとして解説されています（高橋寿一『知識ゼロから学ぶソフトウェアテスト』）。

機能テストをすべて通過したシステムでも、アクセスが集中した瞬間に応答が数十秒かかったり、停止したりすることは珍しくありません。だからこそ、リリース前に負荷をかけて確かめる工程が必要になります。

性能テスト・ストレステストとの関係

負荷テストの周辺には似た用語が多く、混乱しがちです。まずは「性能テスト（パフォーマンステスト）」を広義の親概念として捉えると、関係を整理しやすくなります。

テスト名	位置づけ	かける負荷	確認したいこと
性能テスト（パフォーマンステスト）	親概念（総称）	目的に応じてさまざま	速度・安定性など性能全般
負荷テスト	性能テストの一種	想定内の負荷（ピーク相当）	想定負荷で性能要件を満たすか
ストレステスト	性能テストの一種	想定を超える負荷	限界点はどこか、限界時にどう振る舞うか

つまり、負荷テストは「想定内の負荷に耐えられるか」、ストレステストは「想定を超えたらどうなるか」を見るテストです。

なお実務では、「負荷テスト」という言葉を、負荷をかけるテスト全般の総称として広い意味で使う場面も多くあります。本記事でも以降、この広い意味を指す場合は「広義の負荷テスト」と呼んで区別します。後述する「負荷テストの種類」は、この広義の負荷テストに含まれるテストの分類です。

文献や現場によって用語の使い方に幅があるため、標準的な用語の整理はJSTQB（日本ソフトウェアテスト技術者資格認定委員会）のシラバスや用語集が参考になります。性能テスト全体の考え方から詳しく知りたい方は、パフォーマンステスト（性能テスト）の完全入門記事も参考にしてください。

非機能要件・性能要件との関係

負荷テストを一言で表すなら、「性能要件の裏付け作業」です。ソフトウェア品質の国際規格であるISO/IEC 25010では、品質特性の1つとして「性能効率性」が定義されています（布施昌弘他『ソフトウェアテスト教科書』）。負荷テストは、この性能効率性に関する要件が満たされていることを、実測で確認する活動といえます。

逆にいえば、「同時に何人が使えればよいか」「応答は何秒以内か」という性能要件が曖昧なままでは、負荷テストは成立しません。合格ラインのないテストは、実施しても合否を判定できないためです。この点は、後述する「やり方4ステップ」の起点にも関わってきます。

負荷テストの目的｜なぜリリース前に必要なのか

負荷テストを実施する目的は、大きく次の3つに整理できます。

本番障害を未然に防ぐ（アクセス集中でサービスが落ちる事態を避ける）
性能を数値で証明する（顧客や上長への説明材料をつくる）
ボトルネックを事前に特定する（どこが弱いかを知り、改善につなげる）

それぞれ順に見ていきます。

本番障害を未然に防ぐ

最大の目的は、リリース後の性能起因の障害を防ぐことです。機能テストで「動く」ことを確認できても、「耐えられる」ことの保証にはなりません。この2つは別問題です。

アクセス集中による障害の典型例は、身近なところに数多くあります。

人気チケットの販売開始直後に、予約サイトがつながらなくなる
テレビやSNSで話題になったキャンペーンページが、表示されなくなる
セールやポイント還元の開始直後に、ECサイトの決済が滞る

こうした障害は、リリース直後やキャンペーン開始直後という、最も注目が集まる瞬間に起こります。売上機会の損失だけでなく、「あのサービスは落ちる」という信頼の毀損につながる点が深刻です。

また、負荷が直接の原因ではない事例ですが、2020年10月には東京証券取引所で終日取引が停止する大規模なシステム障害が発生しました（布施昌弘他『ソフトウェアテスト教科書』で紹介）。システムの停止が事業と信頼に与える影響の大きさを示す事例といえます。事前に負荷をかけて確かめておくことは、事業の信頼を守るための保険です。

性能を数値で証明し説明責任を果たす

2つめの目的は、性能を数値で示せるようにすることです。負荷テストでは、主に次のような指標を実測します。

レスポンスタイム: リクエストへの応答にかかる時間
スループット: 単位時間あたりに処理できるリクエスト数
同時アクセス数: 同時に処理できる利用者数・接続数
リソース使用率: CPU・メモリ・ディスクなどの消費状況

このときレスポンスタイムは、平均値だけで語らないことがポイントです。平均値は、一部の極端に遅いリクエストを覆い隠してしまうためです。実務では「95パーセンタイル（全リクエストの95%が収まる時間）」を併記するのが定石です。

「たぶん大丈夫です」ではなく、「想定ピークの同時アクセスで、レスポンスタイムは95パーセンタイルで○秒以内でした」と報告できるかどうか。この差は、顧客や上長への説明責任を果たすうえで決定的です。実測値は、リリース判定の根拠にもなります。

ボトルネックを特定して改善につなげる

3つめの目的は、システムのどこが弱いかを知ることです。負荷をかけて初めて、データベースのクエリが遅い、アプリケーションサーバーのメモリが足りない、といった弱点（ボトルネック）が表面化します。

ボトルネックの所在がデータベースなのか、アプリケーションなのか、インフラなのかが分かれば、改善の打ち手を絞り込めます。負荷テストは合否判定だけでなく、性能改善の出発点を見つける手段でもあるのです。

負荷テストの種類｜5つを表で整理

この章では、前述した「広義の負荷テスト」、つまり負荷をかけるテスト全般に含まれる代表的な5種類を整理します。かける負荷・確認したいこと・実施タイミングの3軸で見ると、違いがつかみやすくなります。

5種類の一覧表

種類	かける負荷	確認したいこと	実施タイミングの目安
負荷テスト（狭義）	想定ピーク相当の負荷	性能要件を満たすか	リリース前（結合〜システムテスト）
ストレステスト	想定を超える〜限界の負荷	限界点と、限界時の壊れ方・回復性	負荷テストとセットで実施
スパイクテスト	瞬間的に急増する負荷	急増時に処理を捌けるか、復帰できるか	キャンペーン・メディア露出の前
ロングランテスト（耐久テスト）	中程度の負荷を長時間	メモリリークなど時間経過による劣化	長期の安定稼働を確認したいとき
キャパシティテスト	段階的に増やす負荷	処理容量の上限はどこか	将来の利用者増・増設計画の検討時

イメージをつかみやすいよう、それぞれの利用場面の例を挙げます。

負荷テスト（狭義）: ECサイトでセール当日のピークアクセスを想定し、その負荷で応答速度が要件内に収まるかを確認する
ストレステスト: 想定ピークの2倍、3倍と負荷を段階的に上げ、どの水準で応答が破綻するか、破綻後に自動で復旧できるかを確認する
スパイクテスト: チケット発売開始やテレビ紹介の直後を想定し、数秒〜数分でアクセスが急増した際の挙動を確認する
ロングランテスト: 数時間〜数日にわたり中程度の負荷をかけ続け、メモリ使用量が増え続けていないか（メモリリーク）を確認する
キャパシティテスト: 利用者数が今後大きく伸びる計画があるとき、現構成で捌ける上限を測り、増設計画の材料にする

各テストの詳細な設計方法まで踏み込むと長くなるため、ここでは「こういう軸で使い分ける」という地図だけ持ち帰ってください。

どれから始めるべきか

5種類すべてを最初から実施する必要はありません。入門段階では「想定負荷での負荷テスト」と「限界を確認するストレステスト」の2つを押さえれば十分です。

負荷テスト（狭義）: 想定ピークで要件を満たすことを確認する
ストレステスト: 想定を超えたときの限界点と壊れ方を知っておく

この2つで「想定内は大丈夫、想定外はここまで耐えられる」と説明できるようになります。スパイクテストやロングランテストは、サービスの特性上必要になったときに追加すれば問題ありません。たとえば告知型のキャンペーンを予定しているならスパイクテストを、長期間の連続稼働が求められるサービスならロングランテストを、といった判断です。

限界性能の確認について深掘りしたい方は、ストレステストの重要性を解説した記事を参考にしてください。

負荷テストのやり方｜4ステップの進め方

負荷テストとは何かを理解したら、次は進め方です。進め方は「目標値の設定 → シナリオ作成 → 実施 → 分析」の4ステップに整理できます。最も重要なのは、ツール選びでもシナリオ作りでもなく、起点となる目標値（性能要件）の設定です。ここが曖昧だと、後続のすべての工程が判断基準を失います。

ステップ1 目標値（性能要件）を決める

最初に、合格ラインとなる目標値を数値で決めます。最低限、次の3つを押さえます。

同時アクセス数: ピーク時に何人（何リクエスト）が同時に使うか
レスポンスタイム: 平均値だけでなく95パーセンタイルで定める（例: 95%のリクエストが3秒以内）
スループット: 単位時間あたり何件の処理を捌くか

目標値の概算は、想定ユーザー数と利用時間帯の集中度から考えます。たとえば1日1万人が使い、その半数が昼休みの1時間に集中するなら、ピーク1時間で5,000人分のアクセスを捌く必要がある、という考え方です。

ただし、この「1時間で5,000人」という数字は、そのままでは目標値として使えません。時間あたりの総数を、同時アクセス数やスループットに換算する橋渡しが必要です。次のように段階的に噛み砕きます。

秒間のセッション開始数: 5,000人 ÷ 3,600秒 ≒ 秒間約1.4セッション
スループット: 1人が滞在中に平均10リクエストを発生させるなら、1.4 × 10 ≒ 約14リクエスト/秒
同時アクセス数: 平均滞在時間が3分（180秒）なら、1.4 × 180 ≒ 約250人が同時に滞在

このように「時間あたりの人数 → 秒間の開始頻度 → リクエスト数・同時数」の順に換算すると、ツールに設定できる具体的な数値になります。滞在時間や1人あたりのリクエスト数は、アクセス解析の実績値や類似サービスの傾向から仮置きすれば十分です。

要件を体系的に整理したい場合は、IPA（情報処理推進機構）が公開している「非機能要求グレード」の資料が参考になります。性能要件そのものの決め方は、システム性能要件が重要な理由を解説した記事で詳しく扱っています。

ステップ2 テストシナリオを作る

次に、本番の利用実態に近いユーザー行動を再現するシナリオを作ります。単一のページに機械的にアクセスするだけでは、本番の負荷を再現できません。

たとえばECサイトなら「ログイン → 商品検索 → カート投入 → 購入」という一連の流れを、利用比率に応じて組み合わせます。閲覧だけで離脱するユーザーが大半で、購入まで進むのは一部、という実態を比率で反映するイメージです。

また、負荷は一気にかけず、徐々に増やしていくのが基本です（ランプアップと呼びます）。いきなり最大負荷をかけると、どの水準から性能が劣化し始めたのかが分からなくなるためです。

シナリオ設計の具体的な手順は、負荷テストの設計手順を解説したガイド記事を参考にしてください。

ステップ3 環境を準備して実施する

シナリオができたら、テスト環境を準備して実行します。理想は本番と同等の構成・データ量の環境です。とはいえ、コストの制約で本番相当の環境を用意できないケースは多くあります。

その場合は、縮小した環境で実施し、本番との差分（サーバー台数・スペック・データ量）を記録したうえで結果を解釈します。ここで注意したいのは、性能は環境の規模に比例して線形にスケールするとは限らない、という点です。サーバー台数を2倍にしても処理能力が2倍になる保証はなく、単純な掛け算での換算は過信できません。

したがって縮小環境での実施は、本番性能の絶対値を予測することよりも、ボトルネックの特定と、負荷を上げたときの劣化傾向の把握に主眼を置きます。実施の際は、ランプアップで段階的に負荷を上げながら、レスポンスタイムやリソース使用率の変化を観察します。

ステップ4 結果を分析し改善につなげる

最後に、実測値を目標値と突き合わせます。分析から改善までの流れは次のとおりです。

目標値と実測値（95パーセンタイルなどの分布を含む）を比較し、達成・未達を判定する
未達の場合、ボトルネック（DB・アプリ・インフラ）を特定する
改善策を実施する（クエリ改善、スケールアウトなど）
再測定して、改善効果を確認する

結果は「実施しました」で終わらせず、目標値・実測値・改善内容をレポートにまとめます。関係者に数値で説明できる形にして、初めて負荷テストの価値が成果として残ります。

負荷テストの工数・費用・スケジュールの目安

計画を立てるうえで避けて通れないのが、「どれくらいの工数と費用がかかるのか」「今から始めて間に合うのか」という問いです。規模や体制によって大きく変わるため断定はできませんが、初回計画の出発点になる一般的な目安を紹介します。

工数とリードタイムの目安

小規模なWebサービスを対象に、主要導線に絞って実施する場合の目安を表にまとめます。

工程	期間の目安
目標値設定・シナリオ作成	1〜2週間
テスト環境・負荷生成環境の準備	数日〜1週間（シナリオ作成と並行しやすい）
テスト実施	1〜3日
分析・改善・再測定・報告	数日〜1週間

着手からレポートまで、目安として合計3〜4週間程度を見込んでおくと計画を立てやすくなります。「リリースの1か月前に着手すれば間に合うか」という問いには、対象を主要導線に絞れば間に合うことが多い、というのが一般的な答えです。ただし、テストで大きな問題が見つかった場合の改修期間は、この目安とは別に必要になります。

だからこそ、着手は早いほど安全です。結合テストの後半までに開始できるよう、プロジェクト計画の段階で負荷テストの期間を確保しておくことをおすすめします。

費用の考え方

費用は「ツール費」「環境費」「人件費」の3つに分解すると見通しが立ちます。

ツール費: JMeterやk6のオープンソース版は無料で使える。商用のクラウド負荷テストサービスは利用量に応じた課金が一般的
環境費: クラウドなら、実施期間だけ負荷生成環境を立てて終了後に破棄できるため、比較的小さな費用で始められることが多い。本番相当の環境を複製する場合が最も費用がかさむ
人件費: 実際には費用の中心。目標値設定・シナリオ設計・分析に経験者の工数がかかる

つまり、負荷テストのコストの大半はツール代ではなく人の工数です。外部に依頼する場合の見積もりも、対象範囲（シナリオ数・実施回数・報告の粒度）によって大きく変わるため、範囲を絞った小さな依頼から始めると費用を抑えやすくなります。

負荷テストの代表的なツール｜JMeterとk6を中心に

負荷テストは専用ツールで仮想ユーザーを生成して実施するのが一般的です。ここでは代表格の2つを紹介します。

Apache JMeter

Apache JMeterは、無料で使えるオープンソースの負荷テストツールです。長年の実績があり、最初の選択肢になりやすいツールといえます。

GUI（画面操作）でシナリオを作成でき、コードを書かずに始められる
利用者が多く、日本語の解説情報が豊富で調べながら進めやすい
HTTPをはじめ幅広いプロトコルに対応している

一方で、大規模な負荷を1台で生成するには限界があります。目安として、数百仮想ユーザー程度までなら1台のマシンで足りることが多い一方、それを大きく超える規模では複数台での分散構成などの工夫が必要になる場合があります。

Grafana k6

Grafana k6は、JavaScriptでシナリオを記述する比較的新しいツールです。開発者主導で負荷テストを回したいチームに向いています。

シナリオをコードで管理でき、Gitでのバージョン管理と相性が良い
CI/CDパイプラインに組み込みやすく、継続的な性能チェックに使える
軽量で、少ないリソースで多くの仮想ユーザーを生成しやすい

ツール選定の目安

2つの使い分けの目安を表にまとめます。

状況	向いているツール
GUIで手早く始めたい、コードを書くメンバーが限られる	JMeter
シナリオをコードで管理し、CIで継続的に回したい	k6
日本語情報を頼りに独学で進めたい	JMeter
開発者が主体となって負荷テストを内製したい	k6

このほかにGatlingやLocustといったツールもありますが、入門段階では上記2つを知っていれば十分です。

なお、注意したいのはツール選定に時間をかけすぎることです。ツールはあくまで手段であり、先に固めるべきは目標値とシナリオです。この2つが決まっていれば、ツールはどれを選んでも大きく失敗しません。

負荷テストでつまずきやすいポイントと対処の考え方

続いて、初めて負荷テストに取り組むチームがつまずきやすい3つのポイントと、対処の考え方を紹介します。

本番相当の環境が用意できない

最も多い悩みが、環境の制約です。本番と同じ構成を用意するには費用がかかり、稟議も通しにくいのが実情です。

ここで「本番相当でないなら意味がない」と諦めるのは早計です。縮小環境でも、本番との差分を明記したうえで実施すれば、十分に価値があります。前述のとおり結果を線形に換算することはできないものの、ボトルネックの傾向や、負荷に対する劣化の仕方は縮小環境でも観察できます。「何もデータがない」状態と「前提付きの実測値がある」状態では、リリース判断の質が大きく違います。