公開2024.09.04更新2026.10.28 品質管理

ラッシュテストとは？負荷テスト・スパイクテストとの違いと英語表記、k6での実施方法

ラッシュテストは、チケットの販売開始やテレビ放送の直後のように、短い時間にアクセスが押し寄せたときにシステムが応答を続けられるか、そして波が引いた後に元の性能へ戻れるかを確かめる試験です。ただし呼び名は業界で統一されておらず、IT用語辞典では負荷テスト（ロードテスト）の別名として載っています。この記事では、定義が2通りに分かれる理由、英語での呼び方、負荷テスト・ストレステスト・スパイクテストとの違いを整理し、Grafana k6で急増と回復を区間ごとに判定する手順を実測結果とあわせて示します。

まとめ：ラッシュテストの意味と負荷テストとの違い

現在の主な用法は「短時間の集中アクセスを再現する試験」で、Grafana k6の分類ではスパイクテストにあたります。
e-Wordsは負荷テスト（ロードテスト）の別名として扱っており、会社によって指す範囲が違います。発注や計画では呼び名ではなく、負荷の大きさ・上げ方・時間を書いて合わせます。
英語の試験名は spike testing（スパイクテスト）です。ISTQBの用語集（4.5版）に「rush test」、JSTQBの性能テストのシラバスに「ラッシュテスト」という用語はありません。
負荷テストは想定の負荷を一定時間かけ続け、ストレステストは想定を超える負荷で限界と壊れ方を見ます。ラッシュテストは負荷の立ち上がりの急さと、収まった後の回復を見ます。
判定は応答時間だけでなく失敗率と回復区間を必ず入れます。実測では急増区間の応答時間の95パーセンタイルが250msで基準内なのに、失敗率は59.54%でした。

ラッシュテストの意味と定義が2通りに分かれる理由

「ラッシュ（rush）」は殺到を指す語で、ラッシュテストは朝夕のラッシュアワーのような集中を想定した試験を指します。ところが、どこまでを「ラッシュテスト」と呼ぶかは資料によって違います。

短時間の集中アクセスを再現する試験としての意味

検索上位の負荷試験サービスの解説は、ラッシュテストを「短時間に一気に負荷をかけ、急増への耐性を見る試験」として説明しています。これはGrafana k6の公式ドキュメントがSpike testingとして定義する試験と同じ形です。同ページは spike test を「sudden and massive rushes of utilization」に耐えて動き続けられるかを確かめる試験と書き、例としてチケット販売・製品発売・放送広告・申告の締め切りを挙げています。

負荷テスト（ロードテスト）の別名として扱う辞書の定義

一方、IT用語辞典e-Wordsの負荷テストの項目は見出しを「負荷テスト（ロードテスト / ラッシュテスト）」としており、ラッシュテストを負荷テストの別名に置いています。同項目は、日本語の「負荷テスト」がロードテスト・ストレステスト・性能テストのどれを指すかは分野や組織によって異なるとも書いています。古い社内規程や試験仕様書で「ラッシュテスト」とあれば、急増を見る試験ではなく、ピーク時の負荷をかけ続ける試験を指している可能性があります。

見積書・試験計画書に明記する負荷条件

IPAの高信頼化ソフトウェアのための開発手法ガイドブック（2010年）は、国内各社のテスト工程を横に並べた「各社テスト一覧表」を載せ、132ページで「負荷テスト/ストレステスト/ラッシュテストのように同じテストでも異なる名称を用いている」と指摘しています。同じ表には「高負荷／ラッシュテスト」という名前でまとめている会社もあります。発注側と受託側で意味がずれたまま進めると、発注側は「開始直後の集中に耐えるか」を知りたいのに、受託側は「一定負荷で1時間流して合格」という報告を出す、という食い違いが起きます。見積書や計画書には、次の4点を数字で書いてください。

平常時と急増時の到着率（1秒あたりのリクエスト数）
急増までの立ち上がり時間（0秒か、30秒か）
急増を続ける時間
急増後に見る回復区間の長さと、回復の合格条件

ラッシュテストの英語表記と海外ドキュメントでの呼び方

「ラッシュテスト」をそのまま英語にした rush test は、テストの用語集に載っている試験名ではありません。ソフトウェアテストの国際的な用語集であるISTQB Glossaryの4.5版を確認すると「rush」を含む用語は1つも無く、同じ形の試験はspike testingとして「突然のピーク負荷の集中から回復し、定常状態に戻る能力を確かめるテスト」と定義されています。

日本語の公式教材も同じ呼び方です。JSTQBのテスト技術者資格制度 Foundation Level Specialist シラバス性能テスト担当者（2018.J01）は、負荷テスト・ストレステスト・スケーラビリティテスト・スパイクテスト・耐久テストなどを並べ、スパイクテストを「突然のピーク負荷に対してシステムが正しく応答し、その後、定常状態に戻る能力に焦点を当てる」と説明しています。このシラバスに「ラッシュテスト」という語は出てきません。

英語の資料では、rush は試験名ではなく負荷の様子を表す語として出てきます。k6のSpike testingのページの「sudden and massive rushes of utilization」がその例です。英語の資料を探すときや海外のベンダーに依頼するときは、次のように置き換えると話が通じます。

日本語で指しているもの	英語の試験名
短時間の集中アクセスを再現する	spike testing
ピーク時の負荷をかけ続ける	load testing / peak load testing
限界まで負荷を上げる	stress testing / breakpoint testing
長時間かけ続ける（ロングラン）	endurance testing / soak testing

ラッシュテストと負荷テスト・ストレステスト・スパイクテストの違い

違いは「負荷の大きさ」「負荷の上げ方」「時間」「何を見るか」の4つで整理すると混同しません。Grafana k6のLoad test typesは、スパイクテストを「非常に高い負荷・短時間（数分）」、耐久（ソーク）テストを「平均的な負荷・長時間（数時間）」としています。

試験	負荷の大きさ	上げ方	時間の目安	主に見るもの
ラッシュ（スパイク）	非常に高い	一気に上げる	数分	急増時の失敗率と回復
負荷（ロード）	想定の平均〜ピーク	段階的に上げる	5〜60分	性能目標を満たすか
ストレス・限界	想定を超える	段階的に上げる	5〜60分・限界は必要なだけ	上限と壊れ方
耐久（ロングラン）	平均的	一定	数時間	劣化・リーク

負荷テスト（ロードテスト）との違い

負荷テストは、想定した平均やピークの負荷を段階的にかけ、その状態で応答時間やエラー率が目標を満たすかを見ます。ラッシュテストは負荷の量より立ち上がりの急さが主題で、同じ毎秒400件でも「10分かけて上げる」のと「0秒で上げる」のでは結果が変わります。オートスケールの増設やコネクションプールの拡張が追いつく前の時間帯を突くのがラッシュテストです。負荷テスト全般の計画と合否基準の置き方は負荷試験とは？シナリオ設計と合否指標、本番相当環境の揃え方をk6の実例で解説で扱っています。

ストレステスト・限界テストとの違い

ストレステストは想定を超える負荷を段階的にかけ、どこで性能が崩れるか、崩れたときにデータが壊れないか、エラーを正しく返すかを見ます。ラッシュテストの負荷も想定ピークを超えることはありますが、目的は上限の特定ではなく「急な波を越えられるか、越えた後に戻るか」です。限界点を特定したいなら負荷を増やし続ける限界テスト（k6のブレークポイントテスト）、販売開始の瞬間を乗り切れるかを知りたいならラッシュテスト、と問いで選びます。

ロングラン（耐久・ソーク）テストとの違い

ロングランテストは平均的な負荷を数時間以上かけ続け、メモリリークや接続の解放漏れのように時間が経ってから出る問題を探します。ラッシュテストとは負荷の形が正反対で、片方を通しても、もう片方の代わりにはなりません。セールのように「開始直後に集中し、その後も数時間高止まりする」業務では、両方を別々に流してください。

ラッシュテストが必要になるシステムと発注側が確認すること

JSTQBの性能テストのシラバスは、よくある性能の故障として「突然の大量のユーザーリクエスト（例：大規模なスポーツイベントのチケット販売）があった場合に、システムがクラッシュしたり、ユーザーの入力に対応したりできない」状態を挙げています。ラッシュテストが必要なのは、アクセスの集中が予告できる、または一斉通知で自ら作り出すシステムです。チケットや限定商品の販売開始、プッシュ通知の一斉配信、テレビCMやSNSでの紹介、確定申告や出願の締め切り直前、メンテナンス明けの再開がこれにあたります。逆に、社内の業務システムのように利用者数が決まっていて始業時刻の集中も緩やかな場合は、通常の負荷テストで足ります。

発注側として確認したいのは、次の3点です。

ピーク時の到着率を何から見積もったか（過去のアクセスログ、販売枠、通知の配信数）
急増区間で許す失敗率と、失敗したときに利用者に何を見せるか（待機画面か、エラーか）
急増の後、何分以内に平常時の応答時間へ戻れば合格とするか

ピークの見積もり方と、試験で測った1台の上限から台数を出す計算はキャパシティプランニングとは？ピーク負荷から必要台数と余裕率を見積もる手順、性能目標を要件として書く方法は非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説で扱っています。

ラッシュテストの方法　k6で急増と回復を区間ごとに判定する手順

ラッシュテストを1本の試験として流し、全体の平均や95パーセンタイルで判定すると、急増区間の失敗が平常区間の成功に薄められます。そこで、平常・急増・回復の3区間をシナリオとして分け、区間ごとに合格条件を置きます。集計はシナリオ単位であり、既定のgracefulStopによって前のシナリオの処理が次の区間まで残る場合があります。この例は回復区間全体の品質を判定し、回復に要した秒数までは測定しません。

平常・急増・回復の3区間に分けたk6スクリプト

k6の到着率指定（constant-arrival-rate）は、利用可能なVUがある限り、応答時間とは独立して一定の頻度で反復を開始します。この例は1反復につき1リクエストですが、VUが不足すると指定した到着率を維持できません。実際のラッシュでは利用者は前の応答を待たずに押し寄せるので、仮想ユーザー数ではなく到着率で負荷を指定します。k6は各リクエストにシナリオ名のタグを付けるため、{scenario:rush}のように区間ごとの閾値を書けます。

import http from 'k6/http';
import { check } from 'k6';

http.setResponseCallback(http.expectedStatuses(200));

export const options = {
  scenarios: {
    baseline: { executor: 'constant-arrival-rate', rate: 50, timeUnit: '1s', duration: '20s', preAllocatedVUs: 50, maxVUs: 200 },
    rush: { executor: 'constant-arrival-rate', rate: 400, timeUnit: '1s', duration: '20s', startTime: '20s', preAllocatedVUs: 200, maxVUs: 1000 },
    recovery: { executor: 'constant-arrival-rate', rate: 50, timeUnit: '1s', duration: '20s', startTime: '40s', preAllocatedVUs: 50, maxVUs: 200 },
  },
  thresholds: {
    dropped_iterations: ['count==0'],
    'http_req_failed{scenario:baseline}': ['rate<0.01'],
    'http_req_duration{scenario:baseline}': ['p(95)<200'],
    'http_req_failed{scenario:rush}': ['rate<0.05'],
    'http_req_duration{scenario:rush}': ['p(95)<1000'],
    'http_req_failed{scenario:recovery}': ['rate<0.01'],
    'http_req_duration{scenario:recovery}': ['p(95)<200'],
  },
};

export default function () {
  const res = http.get('http://127.0.0.1:18469/');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

平常は毎秒50件を20秒、急増は毎秒400件（8倍）を20秒、回復は毎秒50件を20秒です。k6のhttp_req_failedは既定で200〜399番台を成功に数えるため、http.setResponseCallback(http.expectedStatuses(200))で200だけを成功とし、checkと閾値の基準をそろえています。k6のLoad test typesは、負荷を何度も上げ下げする「ジェットコースター」型を避け、上げる・保つ・下げるの単純な形にするよう勧めています。急増を1回にとどめているのはこのためです。

実測結果に見る応答時間と失敗率の乖離

上のスクリプトを、k6 v2.3.0（macOS）から、同時処理8件・処理中と待機中の合計40件を上限とし、上限超過時は503を返す検証用HTTPサーバー（各処理に40msの待ち時間を設定）に流した結果が次の表です。

区間	リクエスト数	失敗率	応答時間p95	判定
平常（毎秒50件）	1,001	0.00%	50.45ms	合格
急増（毎秒400件）	8,001	59.54%	250.50ms	不合格（失敗率）
回復（毎秒50件）	1,001	0.09%	50.42ms	合格

急増区間の応答時間p95は250.50msで、1,000ms未満という基準を満たしています。それでも失敗率は59.54%で、8,001件のうち4,764件が503でした。断られたリクエストは処理されずにすぐ返るため、応答時間の中央値は0.572msまで下がり、遅延の指標はむしろ良く見えます。応答時間だけを合否に置くと、半数以上を断ったラッシュテストが「合格」になります。急増区間には必ず失敗率の閾値を置いてください。

回復区間では1,001件中1件が失敗し、最大応答時間は248.31msでした。急増の直後、待ち行列に残っていたリクエストがはけるまでの間に出たものとみられ、区間全体のp95は50.42msと平常区間とほぼ同じでした。今回の実測でも、回復区間の合格条件を「失敗率0%」にすると不合格になります。回復直後の失敗をどこまで許すかは業務要件で決め、「区間全体で1%未満」や「開始から何秒以内に平常値へ戻る」のように、戻るまでの猶予を含めて合格条件に書きます。

閾値を1つでも超えると、k6は0以外の終了コードで終わります（今回は99）。CIに組み込めば、ラッシュ耐性が落ちる変更をマージ前に止められます。k6のインストールとスクリプトの基本はk6とは？Grafana k6の使い方とインストール手順・負荷テストの書き方【v2.3対応】にまとめています。

ラッシュテストで失敗しやすいパターンと避ける条件

試験の組み方に問題があると、システムの弱点を正しく評価できません。次の4つは、結果を信用する前に必ず確かめてください。

負荷を出す側が先に詰まる：到着率指定でも、仮想ユーザーが足りないとk6は予定の反復を捨て、dropped_iterationsとして数えます。この値が出ていれば、指定した到着率の一部を再現できていません。上のスクリプトは dropped_iterations に count==0 の閾値を置き、負荷側の不足も不合格にしています。今回の実測では0件で、指定どおりの到着率を出せていました。
オートスケールの効き始めを待ってから急増させる：ラッシュテストで見たいのは増設が間に合わない最初の数分です。本番で事前増設を行わないのに、試験だけ増設済みの状態で流すと、開始直後の条件を再現できません。本番で事前増設する運用なら、その構成でも急増への耐性を確認します。予告できるピークへの事前増設とクラウド側の上限はアクセス集中対策をAWSで設計する｜Auto Scalingの設定と見落とすクォータで扱っています。
CDNやWAFが負荷発生元を遮断する：同じIPから短時間に大量のリクエストが来ると、レート制限やボット対策が作動します。遮断された結果を「アプリが落ちた」と読まないよう、試験用の許可設定を事前に決めます。
キャッシュが温まった状態で流す：販売開始の瞬間は新しいページや在庫のデータがキャッシュに無いことが多く、2回目以降の試験は初回より良い数字が出ます。本番の開始時にキャッシュが空なら、その状態を再現して評価します。事前にキャッシュを温める運用なら、その状態も別条件で測定します。

逆に、ラッシュテストを省いてよいのは、利用者数の上限が決まっており、始業時や復旧直後にも急増がないと確認できた社内システムや、待機室（仮想待合室）で入場数を絞る設計にしていて、システムに届く到着率が上限以下に抑えられる場合です。待機室を置く場合も、待機室そのものが急増に耐えるかは試験の対象に残ります。

ラッシュテストに使えるツールの選び方

ラッシュテスト専用のツールは無く、到着率を指定できる負荷テストツールなら実施できます。スクリプトをJavaScriptで書いてCIに組み込むならk6、GUIで組み立てたい・既存のJMeter資産があるならJMeter、Pythonで利用者の動きを書きたいならLocustが候補です。JMeterはJMeterでHTTP/2負荷テストを行う方法｜BlazeMeter HTTPプラグインの導入と設定【3.2対応】、LocustはLocustとは？Pythonで書く負荷試験の使い方・ramp-up・分散実行【2.46対応】で使い方を解説しています。Web・CPU・ネットワークの用途別の無料ツールは負荷テストツール比較｜Web・CPU・ネットワーク別の無料ツールとWindowsでの実行手順で比べています。

試験の設計からボトルネックの改修、本番後の監視しきい値への反映までを開発と同じチームで進めたい場合は、issohのシステムの保守運用・内製化支援でもご相談を受けています。

よくある質問

ラッシュテストと負荷テストは違うものですか？

現在は、負荷テストの中でも短時間に急増する負荷をかける種類を指すことが多く、Grafana k6の分類ではスパイクテストにあたります。ただしe-Wordsのように負荷テスト（ロードテスト）の別名とする定義もあるため、発注や計画では負荷の大きさ・立ち上がり時間・続ける時間を数字で書いて合わせてください。

ラッシュテストとストレステストの違いは何ですか？

ストレステストは想定を超える負荷を段階的にかけて上限と壊れ方を調べる試験で、ラッシュテストは急な集中を越えられるかと、その後に元の性能へ戻るかを見る試験です。上限を知りたいならストレステスト、販売開始の瞬間を乗り切れるかを知りたいならラッシュテストを選びます。

ラッシュテストは英語で何と言いますか？

短時間の集中アクセスを再現する意味なら spike testing です。ISTQBの用語集（4.5版）に rush test という用語は無く、Grafana k6の公式ドキュメントも同じ形の試験を spike testing と呼んでいます。ピーク時の負荷をかけ続ける試験を指して使っている場合は load testing（または peak load testing）にあたります。