ロードテストとは【2026年版】システム開発で失敗しない実施手順とツール

はじめに

システム開発の進め方や費用のご相談は、お問い合わせから承ります。

ロードテストは、Webシステムやアプリに想定したアクセスをかけ、レスポンス時間、エラー率、サーバー負荷、データベース負荷を確認するテストです。リリース後に利用者が増えてから遅延や停止が起きると、売上、問い合わせ、社内業務、顧客対応に直接影響します。

2026年時点では、クラウド環境、API連携、AI機能、外部サービス連携を前提にしたシステムが増えています。そのため、画面が表示されるかだけでなく、同時アクセス、APIの待ち時間、外部サービスの制限、DBの読み書き、キャッシュの効き方まで確認する必要があります。

この記事では、ロードテストの目的と種類、先に決める基準、検証する項目、実施手順、主要ツールの料金、結果分析、外注判断を整理します。料金は2026年9月27日時点で確認できる公式情報をもとにしています。契約前には必ず各公式ページを確認してください。

ロードテストは、最後に一度だけ実施する作業ではありません。要件定義で想定利用者とピークを決め、開発中に小さく検証し、リリース前に本番に近い条件で確認し、改善後に再テストする流れで設計します。

特に受託開発では、納品直前に性能問題が見つかると、追加改修、スケジュール変更、インフラ費用の見直しが同時に発生します。早い段階で基準を合意しておくと、発注者、開発会社、運用担当者が同じ数字で判断できます。

また、社内システムでもロードテストは有効です。月末締め、棚卸し、キャンペーン、全社通知後のログイン集中など、業務には一時的なピークがあります。普段は問題なく動くシステムでも、ピーク時だけ遅くなる場合は、事前検証で原因を見つけます。

ロードテストとは

ロードテスト（Load Testing）は、システムやアプリケーションが、想定される最大のアクセス数やトラフィック量に耐えられるかを確認するテストです。日本語では負荷テストの一種として扱われ、性能要件で決めた負荷をかけた状態で、正常に使えるかを確かめます。

テストを行わずにリリースすると、想定外のトラフィック増加や急なアクセス集中にシステムが耐えられず、ダウンタイムや表示の遅れにつながります。停止してから原因を探すと、復旧と調査を同時に進めることになり、影響が長引きます。

ロードテストの目的

ロードテストの目的は、大きく次の4つに分けられます。

目的	詳細
システムの耐久性確認	最大アクセス数やトラフィック増加時の動作を確認する
パフォーマンスボトルネックの特定	レスポンス時間の遅延やリソースの過負荷を発見する
スケーラビリティ確認	負荷が増えたときに、サーバー追加やオートスケールで処理能力が伸びるかを評価する
キャパシティプランニングの支援	将来のトラフィック増加に備えたインフラ・リソース計画の根拠データを得る

例えば、ECサイトやオンラインバンキングでは、セールや給与日、キャンペーン開始直後などにアクセスが急増します。ロードテストで事前に動作を確認しておくと、そのピークに合わせてサーバー構成や処理の分け方を準備できます。

業務システムでも考え方は同じです。受発注や勤怠のように締め日が決まっている業務では、特定の日時に処理が集中します。どの時間帯に何人が使うのかを把握することが、テスト設計の出発点になります。

ストレステスト・ロングランテストとの違い

負荷テストには、目的の違う複数のテストがあります。ロードテストは「想定した負荷で問題なく動くか」を確かめるもので、限界を探すテストとは分けて考えます。

テスト	確認すること	かける負荷
ロードテスト	想定したピーク負荷で性能要件を満たすか	想定ピークまで
ストレステスト	どこで限界を迎え、限界を超えたときにどう壊れ、どう回復するか	想定ピークを超える負荷
ロングランテスト（耐久テスト）	長時間動かしたときにメモリリークや性能劣化が起きないか	通常〜ピークの負荷を長時間
スパイクテスト	短時間の急激なアクセス増に耐えられるか	急増と急減を繰り返す負荷

リリース判断に直結するのはロードテストです。キャンペーンなどで想定を超える可能性がある場合はストレステスト、24時間止まらない業務ではロングランテストを追加します。

ロードテストで先に決める基準

ロードテストは、ツールを動かす前に合格基準を決めることが重要です。基準がないまま同時接続数だけを増やすと、結果を見てもリリースできるか判断できません。まず、業務上の許容値を決めます。

基準	決める内容	見落とすと起きる問題
想定同時利用者	通常時、ピーク時、キャンペーン時	低すぎる負荷で安心してしまう
レスポンス時間	主要画面やAPIごとの目標値	一部画面だけ極端に遅い
エラー率	4xx/5xx、タイムアウトの許容範囲	失敗リクエストを平均値で隠してしまう
データ量	本番に近い件数、検索条件	小さいDBでは速いが本番で遅くなる
監視項目	CPU、メモリ、DB、外部API、キュー	原因分析ができない

特に業務システムでは、ログイン、一覧検索、詳細表示、登録、承認、帳票出力のように、処理の重さが違います。すべてを均等に叩くのではなく、実際の業務比率に近いシナリオを作ります。

ピーク条件、許容レスポンス、失敗時の判断基準を先に合意することが、ロードテストの精度を左右します。例えば「500人同時アクセス」だけでは不十分です。500人のうち何割が検索し、何割が登録し、何割が帳票を出すのかまで決めると、テスト結果が実運用に近づきます。

ロードテストで検証する主な項目

ロードテストでは、システムの性能を測るために次の項目を確認します。どれか1つだけを見ても判断できないため、同じ時間軸で並べて記録します。

検証項目	詳細内容
レスポンス時間	リクエストから応答までの時間。画面やAPIごとに、業務が成り立つ許容値を決めて測る
同時接続数	同時にシステムを使えるユーザー数。高トラフィック時でも安定して動くかを見る
スループット	一定時間あたりに処理できるリクエスト数。サーバーの処理能力を表す指標
エラーレート	負荷が増えたときにエラーが発生する割合。急に上がる点がシステムの限界に近い
サーバーリソース消費	CPU、メモリ、ネットワーク帯域などの使用率。どこが先に上限に達するかを見る
データベース負荷	高負荷時の読み書き速度、ロック待ち、遅いクエリの有無

レスポンス時間の目標は、一律に「何秒以内」と決めるものではありません。ログインや一覧表示のように利用者が待つ画面は短く、帳票出力や一括取込のように時間がかかると分かっている処理は長めに設定します。業務部門と一緒に「この画面がこれ以上遅いと仕事にならない」という線を決めます。

スループットと同時接続数はセットで見ます。利用者を増やしてもスループットが伸びなくなった点が、処理能力の上限の目安になります。その手前でレスポンス時間やエラーレートが悪化していないかを確認します。

これらの項目をあらかじめ決めておくことで、システムが高負荷に耐えられるかを数字で説明できます。

失敗しないロードテストの実施手順

ロードテストは、目的設定、シナリオ設計、環境準備、実行、分析、改善、再テストの順で進めます。最初に「何人まで耐えるか」だけでなく、「どの画面が何秒以内なら業務が成立するか」を決めます。

目的と合格基準を決めます。
ログイン、検索、登録、更新、API呼び出しなどのシナリオを作ります。
本番に近いデータ量、権限、ネットワーク、外部連携を用意します。
小さい負荷から始め、段階的に同時利用者を増やします。
アプリ、DB、インフラ、外部APIの監視値を同時に取得します。
ボトルネックを直し、同じ条件で再テストします。

目的と合格基準は、具体的な数字で書きます。例えば「トップページと検索結果は1秒以内に表示する」「最大同時アクセス5,000人でもエラー率を1%未満に保つ」のように、画面と条件を組み合わせて決めます。数字は業務の実態に合わせて調整してください。

シナリオは、システムが受けるアクセスのパターンを再現します。例えば「1人の利用者が10秒に1回リクエストを送る」「30分かけてアクセス数を徐々に増やし、ピークで15分維持する」のように、負荷のかけ方と時間を設計します。いきなり最大負荷をかけると、どの段階で性能が落ちたのかが分からなくなります。

テスト環境が本番と大きく違う場合は、結果の読み方に注意します。CPUやDBスペックが低い環境で失敗しても本番では問題ないことがあり、逆に外部APIやネットワーク条件が本番より軽いと、本番リリース後に問題が出ることがあります。

本番に近いデータ量を用意することも重要です。ユーザー数だけを増やしても、商品、顧客、履歴、添付ファイル、ログの件数が少ないと、検索や集計の遅さを検出できません。個人情報を含む本番データをそのまま使えない場合は、匿名化データや疑似データを用意します。

テスト中は、負荷をかける端末やクラウド側だけを見ないようにします。アプリケーションログ、DBログ、APM、クラウド監視、外部APIのレスポンスを同じ時間軸で残すと、どの処理で詰まったのかを後から追跡できます。

外部の決済やSaaSのAPIにそのまま負荷をかけると、利用規約違反や想定外の課金につながることがあります。外部サービスは検証用環境やモックに置き換え、どの部分を実物で試し、どの部分を模擬で済ませたかを記録しておきます。

主要ツールと料金比較

ロードテストツールは、無料のOSS、開発者向けのコード型、クラウド実行型、エンタープライズ向けに分かれます。2026年9月27日時点の各公式ページでは、次のように整理できます。

ツール	料金・プランの目安（2026年9月27日確認）	向いている用途	公式情報
Apache JMeter	無料（オープンソース）。最新版5.6.3、Java 8以上が必要。初期費用なし	Web、API、DBなど幅広い検証	Apache JMeter
Grafana k6	OSS版は無料。Grafana Cloud Freeは月500 VUhまで無料。Proは月払いで基本料金$19/月（500 VUh込み）、超過分は$0.150/VUhから。ドル建て・税別の扱いは公式で確認	CI/CD、API、開発者主導の負荷テスト	Grafana k6 / Pricing
Locust	無料（オープンソース、Pythonで記述）。初期費用なし。商用のLocust Cloudは料金を公式で確認	Pythonチーム、独自シナリオ	Locust
Gatling	Basicは月払い€99/月・年払い€89/月（年€1,068）、Teamは月払い€396/月・年払い€356/月（年€4,272）、Enterpriseは要問い合わせ。ユーロ建て・税別の扱いは公式で確認	コード型、分散実行、チーム管理	Gatling Pricing
BlazeMeter	Freeは同時50ユーザー・月10テストまで無料。Basicは月払い$149、年払いは公式表記「$99 billed once per year」。Proは月払い$649、年払い「$499 billed once per year」。ドル建て・税別の扱いと請求総額は申込画面で確認	JMeter互換、クラウド実行、大規模テスト	BlazeMeter Pricing
OpenText Professional Performance Engineering（旧LoadRunner Professional）	価格は非公開のため公式で確認（見積もり制）。無料トライアルあり	多様なプロトコルを扱う大規模・エンタープライズシステム	OpenText

VUh（Virtual User Hour）は、仮想ユーザー1人が1時間テストを実行した量を表す単位です。例えば100人の仮想ユーザーで30分テストすると50 VUhになります。クラウド型は、この量やテスト時間で費用が決まるため、テスト回数と規模を先に見積もります。

LoadRunnerは、長く企業向けの定番として使われてきた商用ツールです。公式FAQによると、LoadRunner Professionalは現在「OpenText Professional Performance Engineering」という名称に変わっています。古い資料でLoadRunnerの名前を見た場合は、この製品を指していると考えてください。

無料ツールは初期費用を抑えやすい一方、シナリオ作成、分散実行、レポート整備、監視連携を自社で設計する必要があります。クラウド型は費用がかかりますが、負荷生成、可視化、チーム共有、CI/CD連携を短期間で整えやすいです。

小規模なAPI検証ならk6やLocust、大規模なJMeter資産を活かすならBlazeMeter、チーム管理まで含めるならGatlingが候補になります。ただし、価格だけで選ぶと、シナリオ作成者のスキル、社内レビュー、監視連携、レポート共有で詰まります。

結果分析と改善ポイント

ロードテスト後は、平均レスポンスだけで判断しません。p95、p99、エラー率、タイムアウト、DBクエリ、外部APIの待ち時間、キュー滞留、キャッシュヒット率を見ます。平均は良くても、一部ユーザーだけ極端に遅い状態は業務影響が大きいです。

改善策は、原因ごとに分けます。アプリ側なら不要なAPI呼び出し削減、非同期処理、キャッシュ、N+1クエリの修正を行います。DB側ならインデックス、検索条件、集計処理、読み取り分離を見直します。インフラ側ならオートスケール、CDN、ロードバランサー、ジョブキューを確認します。

症状別の原因と改善策

結果を見て最初に分かるのは「遅い」「処理が伸びない」といった症状です。症状から原因の候補を絞ると、調査の順番を決めやすくなります。

症状	主な原因	改善策
レスポンス時間の遅延	サーバーの処理能力不足、データベースのクエリが遅い	キャッシュの導入、インデックスの最適化、サーバーのスケールアップ
スループットの低下	ネットワーク帯域の不足、アプリケーションの非効率なコード	サーバー間の負荷分散、コードの最適化、非同期処理の導入
リソースの過負荷	CPUやメモリの消費が過多	監視ツールでボトルネックとなるプロセスを特定し、処理を最適化する
エラーレートの急増	コネクション数の上限、外部APIのレート制限、タイムアウト設定	接続プールの見直し、リトライと待機の設計、上限値の引き上げ

結果は開発チームだけで閉じず、発注者や業務部門にも共有します。どの条件なら業務上問題ないか、どのピークは追加費用や運用ルールで対応するかを決めることで、リリース判断がしやすくなります。

再テストまで含めて完了とすることが重要です。一度問題を修正しても、別の処理が遅くなることがあります。改善前後で同じシナリオ、同じデータ量、同じ負荷条件を使い、結果を比較してからリリース判断を行います。

外注や支援が必要なケース

外部API、決済、検索、帳票、認証、権限管理が絡む場合は、シナリオ漏れや監視不足が起きやすくなります。社内にテスト設計の経験者がいない場合も、基準づくりから外部の力を借りたほうが手戻りを減らせます。テスト設計を誰が担い、発注者と開発会社でどう分担するかは、システム開発のチーム構成と失敗しない体制で整理できます。

ロードテストの弱点は、準備に工数がかかることです。シナリオ作成、テストデータの準備、監視の設定、結果の解釈まで含めると、ツールを動かす時間より準備の時間のほうが長くなります。開発の終盤に慌てて始めると、テストを省略するか、リリースを遅らせるかの二択になりがちです。

要件定義やテスト工程の全体像は、システム開発テスト工程とは？も参考になります。想定利用者やピークを要件として固める段階は、システム開発上流工程とは？で整理できます。開発会社の選定を含めて見直す場合は、webシステム開発会社の選び方で、発注時の確認観点を整理できます。

AI開発ラボでは、業務フロー整理、システム開発、テスト設計、AI活用、運用改善まで相談できます。ロードテストだけを単発で考えるのではなく、要件定義の段階で想定利用者と合格基準を決め、データ設計、監視、リリース後運用まで合わせて設計することで、準備の負担を開発全体に分散できます。

まとめ

ロードテストは、想定した高負荷でシステムが安定して動くかを確認する工程です。2026年時点では、Web画面、API、外部サービス、DB、クラウドインフラが複雑につながるため、単純に同時アクセス数を増やすだけでは十分ではありません。

成功させるには、想定同時利用者、レスポンス時間、エラー率、データ量、監視項目を先に決めます。そのうえで、業務に近いシナリオを作り、小さい負荷から段階的に増やし、スループットやリソース消費とあわせて結果を見ます。

ツールは、JMeter、k6、Locust、Gatling、BlazeMeter、OpenText Professional Performance Engineeringなどから、チームの技術力、予算、クラウド実行の必要性、レポート共有のしやすさで選びます。料金は2026年9月27日時点の公式情報で、変わりやすいため導入前に公式ページで確認してください。

リリース前に問題が見つかった場合は、キャッシュ、DB、API、非同期処理、インフラ設定を切り分け、改善後に同じ条件で再テストします。要件定義から運用までつなげることで、障害リスクと手戻りを減らせます。

発注者側は、開発会社に「ロードテストを実施するか」だけを確認するのではなく、想定同時利用者、対象シナリオ、監視項目、合格基準、再テスト方法を確認します。

開発会社側は、テスト結果を単なる数値レポートで終わらせず、改善内容、残るリスク、運用で回避する条件を説明します。例えば、月末だけ処理を分散する、重い帳票は非同期にする、キャンペーン前に一時的にインフラを増強する、といった判断までつなげます。

予約や決済など複数の業務が1つのシステムに集まると、利用が重なる時間帯でも止まらずに動くかが重要になります。当社が開発したペットシッティング業務の一元管理システムでは、予約・チャット・決済・カルテ・鍵管理の機能を単一のシステムに集約しました。想定利用者やピークを決める要件整理の段階からご相談いただけます。
関連する事例：ペットシッティング業務一元管理システムの事例を見る
 会社概要を見る・開発実績を見る
 受託開発の相談・具体的な相談を送る

関連する事例・活用例：ノーコード開発で行われた医薬品業界の業務効率化事例を紹介

群別サービス：受託開発