「キャンペーン開始直後にサイトが落ちてしまった」「アクセス集中で注文が処理できなかった」――こうしたトラブルは、事前の負荷テストで防ぐことができます。しかし、やり方がわからず手をつけられていない企業も多いのではないでしょうか。
本記事では、負荷テストの基本的なやり方から無料ツールの使い方、シナリオ作成のコツまで、中小企業のIT担当者でもすぐに実践できる手順を解説します。
負荷テストとは?中小企業に必要な理由
「キャンペーン開始直後にサイトがダウンして、せっかくの売上機会を逃してしまった…」
こうした事態を防ぐために必要なのが負荷テストです。GitHub Actionsと組み合わせれば、定期的な負荷テストの自動実行も可能です。システムやWebサイトが実際の運用環境でどれだけのアクセスに耐えられるかを事前に確認する重要なプロセスです。
この記事では、中小企業のIT担当者や経営者の方に向けて、負荷テストの基本的なやり方から実務で使えるツールの選び方まで解説します。システム全体の監視体制を構築したい場合はOpenTelemetry監視設定ガイドも参考になります。完璧を目指さず、まずは小さく始められる実践的な方法をお伝えします。
負荷テストの定義と目的
負荷テストとは、システムに意図的に負荷をかけて、正常に動作するかを確認するテストのことです。
例えば、ECサイトで100人が同時にアクセスしたとき、サーバーがきちんと応答できるか、ページの表示速度は遅くならないかを検証します。実際のユーザーが使う前に、システムの限界値や弱点を把握することが目的です。
具体的には以下の項目を確認します。
- レスポンスタイム: ページが表示されるまでの時間
- スループット: 単位時間あたりに処理できるリクエスト数
- エラー率: アクセス集中時のエラー発生頻度
- リソース使用率: CPU、メモリ、ネットワーク帯域の使用状況
負荷テストをしないリスク
負荷テストを実施せずにシステムを公開すると、以下のリスクが発生します。
ビジネス機会の損失
キャンペーン時にサイトがダウンすると、顧客は競合サイトに流れます。売上チャンスを逃すだけでなく、広告費も無駄になります。
企業の信頼低下
サービスが使えない状態が続くと、顧客からの信頼を失います。SNSで拡散されれば、ブランドイメージの回復には長い時間とコストがかかります。
復旧コストの増大
本番環境でトラブルが発生すると、緊急対応が必要になります。深夜や休日の作業、外部ベンダーへの緊急依頼など、通常の何倍ものコストがかかります。
中小企業で負荷テストが必要なケース
中小企業でも以下のようなケースでは負荷テストが重要です。
- ECサイトのセール時: 通常時の10倍以上のアクセスが集中することも
- 予約システムの導入時: 予約開始直後にアクセスが集中
- メディア掲載時: テレビやWebメディアで紹介されると短時間で大量アクセス
- 新規サービスのリリース時: 想定を上回る反響に備える
- クラウド移行時: ネットワーク帯域やリソース設定が適切か確認
関連用語との違い
負荷テストと似た用語を整理しておきましょう。
- 負荷テスト: 想定される通常の負荷で正常動作を確認(例:同時接続100人で問題ないか)
- ストレステスト: システムの限界を超える負荷をかけて破綻点を確認
- 性能テスト: レスポンスタイムやスループットなど性能指標を測定する総称
- 耐久テスト: 長時間の負荷でメモリリークなどの問題がないか確認
中小企業がまず取り組むべきは負荷テストです。想定される利用状況でシステムが正常に動作するかを確認することから始めましょう。
負荷テストの実施手順|5ステップ
負荷テストの基本的な流れは明確です。初心者でも実践できる5つのステップを解説します。
ステップ1:目的と目標値の設定
まず何を確認したいのかを明確にします。
目的の例
- キャンペーン時に500人の同時アクセスに耐えられるか確認
- ページの表示速度が3秒以内に収まるか検証
- システム移行後も現行と同等の性能が出るか比較
次に具体的な目標値を設定します。
| 項目 | 目標値 | 測定方法 |
|---|---|---|
| 同時接続ユーザー数 | 500人 | 負荷テストツールで仮想ユーザーを生成 |
| レスポンスタイム | 3秒以内 | ページ読み込み完了までの時間 |
| エラー率 | 1%以下 | 全リクエストに対するエラーの割合 |
| CPU使用率 | 80%以下 | サーバー監視ツールで測定 |
目標値は過去のアクセスログやGoogle Analyticsのデータを参考にすると現実的です。データがない場合は、想定最大アクセス数の1.5〜2倍を目安にしましょう。
ステップ2:テストシナリオの作成
テストシナリオとは、ユーザーがシステム上で行う一連の操作を定義したものです。
ECサイトの例
1. トップページにアクセス
2. 商品検索を実行
3. 商品詳細ページを閲覧
4. カートに商品を追加
5. カート内容を確認
6. 購入手続き(決済は除く)
シナリオ作成のポイント
- 実際のユーザー行動に基づく(アクセスログやヒートマップを分析)
- 複数のパターンを用意(新規ユーザーとリピーターで行動が異なる)
- 待機時間を設定(リクエスト間に1〜5秒程度)
- 重要な機能に絞る(すべての機能ではなくビジネス上重要な機能)
ステップ3:テスト環境の準備
負荷テストは本番環境とは別の環境で実施するのが原則です。
環境準備の選択肢
本番同等の環境(理想的)
サーバーのスペック、ネットワーク構成、データベース規模を本番と同じにします。ただし、中小企業では予算的に難しい場合も多いでしょう。
スケールダウン環境(現実的)
本番の50%程度のスペックで環境を構築し、負荷も50%で実施。結果を比例計算して本番環境での挙動を推測します。
クラウドの一時環境(おすすめ)
AWS、Azure、GCPなどで、テスト期間だけ環境を構築。使った分だけの課金なので、コストを抑えられます。
テストデータの準備
- データベースに十分なレコード数を用意
- 画像やファイルなど静的コンテンツも本番相当に
- 個人情報はダミーデータに置き換え
ステップ4:テストの実行
準備が整ったら、実際に負荷テストを実行します。
実施の流れ
1. 少人数(10人程度)から開始
2. 段階的に負荷を増やす(50人、100人、200人)
3. 目標値に到達後、一定時間(10〜30分)継続
4. ピーク負荷(目標値の1.5倍程度)でも確認
監視項目
- レスポンスタイム(各リクエストの応答時間)
- エラー率(HTTPエラーの発生率)
- サーバーリソース(CPU、メモリ、ディスクI/O、ネットワーク帯域)
- データベース(クエリ実行時間、接続数、デッドロック)
記録する情報
- テスト日時、シナリオ、同時接続数
- 実行時間
- レスポンスタイムの平均・最大・最小
- エラー率
- サーバーリソース使用状況
- 発生した問題や気づき
ステップ5:結果分析と改善
テスト結果を分析して改善点を洗い出します。
ボトルネックの特定
レスポンスタイムが遅い処理やエラーが発生した箇所を特定します。多くの場合、以下がボトルネックになります。
- データベースのクエリが遅い
- 静的ファイルの配信が遅い
- アプリケーション処理ロジックに問題
- サーバースペック不足
改善策の例
| ボトルネック | 改善策 |
|---|---|
| データベース | インデックス追加、クエリ最適化、キャッシュ導入 |
| 静的ファイル | CDN導入、画像最適化、ブラウザキャッシュ活用 |
| アプリケーション | コード最適化、非同期処理、不要処理削減 |
| サーバースペック | スケールアップ、スケールアウト |
改善策を実施したら、必ず再度負荷テストを実行します。このサイクルを回すことで、システム性能は着実に向上します。
負荷テストツールの選び方
負荷テストツールは数多く存在します。自社に合ったツールを選ぶための判断基準を解説します。
予算:無料(OSS)か有料か
無料ツール(OSS)
- メリット:コストゼロ、情報豊富、カスタマイズ自由
- デメリット:サポートなし、技術知識必要、GUIが使いにくい場合も
有料ツール(商用サービス)
- メリット:手厚いサポート、使いやすいGUI、環境構築不要
- デメリット:月額数万円〜、契約期間の縛り、カスタマイズ制限
中小企業におすすめ
まずは無料ツールから始めることをおすすめします。Apache JMeterやLocustなど、実績のある無料ツールで十分実用的です。
以下の課題が出てきたら有料ツールへの移行を検討しましょう。
- ツールを使いこなせる人材がいない
- サポートがないと不安
- より高度な分析機能が必要
- クラウドから大規模な負荷をかけたい
操作方法:GUI操作かコード記述か
GUI操作型
マウスでクリックしながら設定できるツールです。プログラミング知識不要で、直感的に操作できます。
- 代表例:Apache JMeter、LoadRunner、BlazeMeter
コード記述型
JavaScriptやPythonでテストシナリオを記述します。プログラミングスキルが必要ですが、柔軟性が高いのが特徴です。
- 代表例:k6(JavaScript)、Locust(Python)、Gatling(Scala/Java)
選択のポイント
IT担当者のスキルレベルに合わせて選びましょう。プログラミングに抵抗がなければ、コード記述型の方が後々の拡張性が高くなります。
実行環境:オンプレミスかクラウドか
オンプレミス型(自社サーバーから実行)
- メリット:社内ネットワークからテスト可能、追加コストなし、データが外部に出ない
- デメリット:帯域制限、大規模負荷に限界、IPアドレス限定
クラウド型(クラウドサービスから実行)
- メリット:大規模負荷が可能、世界中の拠点から実行、環境構築不要
- デメリット:実行回数や負荷量に応じて課金、インターネット経由のみ
選択のポイント
小規模テスト(同時接続100人以下)ならオンプレミス型で十分です。大規模テストや本番環境に近い条件が必要な場合は、クラウド型を検討しましょう。
ツール選定チェックリスト
以下の質問に答えることで、自社に最適なツールが見えてきます。
- 予算: 無料で始めたい → OSS / 月数万円なら出せる → クラウドサービス
- スキルレベル: プログラミング未経験 → GUI型 / 経験あり → コード型
- 負荷規模: 100人以下 → オンプレミス / 1000人以上 → クラウド
- テスト頻度: 年数回 → 無料ツール / 定期的 → 有料も検討
- CI/CD連携: 必要 → コード型 / 不要 → GUI型でも可
- サポート: 自己解決できる → OSS / 欲しい → 有料サービス
迷ったら、まずはApache JMeterから始めることをおすすめします。無料で高機能、情報も豊富なため、初心者でも取り組みやすいツールです。
おすすめ負荷テストツール5選
実際に中小企業でも使いやすい負荷テストツールを5つ紹介します。
Apache JMeter|定番の無料ツール
特徴
最も広く使われている負荷テストツールです。Apache Software Foundationが開発するオープンソースで、20年以上の歴史があります。
- GUI操作でテストシナリオ作成
- HTTP、FTP、データベースなど幅広いプロトコル対応
- プラグイン豊富で機能拡張が容易
- 日本語情報が多く導入事例も豊富
向いているケース
初めて負荷テストに取り組む、プログラミング経験が少ない、Webアプリケーションのテスト、コストをかけずに始めたい
料金: 無料
k6|JavaScriptで書けるモダンなツール
特徴
Grafana Labsが開発する新世代の負荷テストツールです。JavaScriptでテストシナリオを記述するため、フロントエンドエンジニアにも馴染みやすいのが特徴です。
- ES6の文法で直感的にシナリオ記述
- CLI実行で自動化しやすい
- 美しい結果表示でリアルタイム確認
- CI/CD対応でGitHubActionsやJenkinsと連携
向いているケース
JavaScriptに慣れている、テストシナリオをGitで管理したい、CI/CDパイプラインに組み込みたい
料金: 無料(クラウド版は有料)
Gatling|高負荷に強いツール
特徴
Scala言語で開発された高性能な負荷テストツールです。大規模な負荷テストに強く、エンタープライズ向けの機能が充実しています。
- 少ないリソースで大量の仮想ユーザーを生成
- HTMLレポートが自動生成され見やすい
- Scalaベースで柔軟にシナリオ記述
- 商用サポート版も利用可能
向いているケース
大規模負荷テスト(同時接続数千人以上)、きれいなレポートが欲しい、Scala/Javaの知識がある
料金: 無料(Enterprise版は有料)
Locust|Pythonで書けるシンプルなツール
特徴
Pythonで記述できるシンプルな負荷テストツールです。Pythonエンジニアにとって最も使いやすいツールの一つです。
- Pythonでシンプルに記述
- 分散実行対応で複数マシンで負荷分散
- Webベースの管理画面でブラウザから制御・監視
- Pythonライブラリを活用できる拡張性
向いているケース
Pythonに慣れている、シンプルに始めたい、リアルタイムで結果を見ながら調整したい
料金: 無料
クラウドサービス型の選択肢
BlazeMeter
JMeterベースのクラウドサービス。JMeterスクリプトをそのまま大規模実行できます。サポートも充実しており、初心者でも安心です。
LoadImpact(k6 Cloud)
k6のクラウド版。世界中の拠点から負荷をかけられ、詳細な分析機能も提供されます。
これらのクラウドサービスは、環境構築不要で大規模負荷テストが可能です。無料トライアルもあるため、まずは試してみることをおすすめします。
JMeterを使った実践例
初心者に最もおすすめのApache JMeterを使った負荷テストの実践方法を解説します。
インストールと初期設定
必要な準備
1. Java(JDK)をインストール
2. JMeterの公式サイトからダウンロード
3. ZIPファイルを解凍
4. binフォルダ内の「jmeter.bat」(Windows)または「jmeter.sh」(Mac/Linux)を実行
JMeterが起動すると、GUIの画面が表示されます。
簡単なテストシナリオの作成
基本的な流れ
1. スレッドグループを追加(仮想ユーザー数を設定)
2. HTTPリクエストを追加(テスト対象のURLを設定)
3. リスナーを追加(結果を表示)
4. テストを実行
スレッドグループの設定例
- スレッド数:50(同時アクセス数)
- Ramp-Up期間:10秒(50人に到達するまでの時間)
- ループ回数:10(各ユーザーが10回リクエスト)
テスト実行と結果の見方
テストを実行すると、リスナーに結果が表示されます。
確認すべき主要指標
- Average(平均レスポンスタイム)
- Min/Max(最小/最大レスポンスタイム)
- Error %(エラー率)
- Throughput(スループット:1秒あたりのリクエスト数)
これらの数値を目標値と比較して、システムの性能を評価します。
よくあるつまずきポイント
エラーが大量に発生する
→ テスト環境のURLが間違っていないか確認。ファイアウォールやセキュリティ設定も確認しましょう。
結果が表示されない
→ リスナーが正しく追加されているか確認。テスト実行前にリスナーを追加する必要があります。
負荷が想定より低い
→ スレッド数やループ回数の設定を確認。Ramp-Up期間が長すぎると負荷が分散されます。
負荷テストの課題と解決策
実際に負荷テストを実施する際によくある課題と解決のヒントを紹介します。
テスト環境の準備が難しい場合
課題: 本番同等の環境を用意する予算がない
解決策
- クラウドの一時環境を活用(AWS、Azure、GCPの無料枠も活用)
- スケールダウンした環境で比例計算
- 本番環境のピーク時間外に実施(リスクはあるが低予算で可能)
シナリオ作成で迷ったとき
課題: どんな操作をテストすればいいかわからない
解決策
- Google Analyticsで実際のユーザー行動を分析
- 最も重要なビジネスプロセス(購入、予約など)に絞る
- 単純なページ閲覧から始めて徐々に複雑化
結果の分析方法がわからない
課題: 数値をどう解釈すればいいかわからない
解決策
- まずは目標値との比較に集中
- レスポンスタイムが目標の2倍以上なら要改善
- エラー率が5%を超えたら深刻な問題
- 改善前後の比較で効果を測定
テスト手順の文書化と共有
課題: 担当者が変わると引き継げない
解決策
- テスト手順書を作成(スクリーンショット付き)
- テストシナリオをファイルで保存
- 結果を定期的にレポート化
- 社内Wikiやドキュメント管理ツールで共有
まとめ|負荷テストを自社に定着させる
本記事のポイント
負荷テストのやり方とツール選びについて解説しました。
実施手順の5ステップ
1. 目的と目標値の設定
2. テストシナリオの作成
3. テスト環境の準備
4. テストの実行
5. 結果分析と改善
ツール選びのポイント
- 予算:まずは無料ツールから
- 操作方法:スキルレベルに合わせる
- 実行環境:小規模ならオンプレミス、大規模ならクラウド
おすすめツール
初心者にはApache JMeterが最適。無料で高機能、情報も豊富です。
小さく始めて徐々に改善する
負荷テストは完璧を目指す必要はありません。
まずは以下から始めましょう。
- 最も重要な機能だけをテスト
- 想定される同時アクセス数でテスト
- 結果を記録して次回に活かす
テストを繰り返すことで、システムの性能は着実に向上します。
困ったときは専門家に相談を
自社だけで解決が難しい場合は、専門家に相談するのも一つの手です。
- システム開発会社に相談
- クラウドベンダーのサポートを活用
- IT顧問サービスの利用
私たちHarmonic Societyでも、中小企業向けの負荷テスト支援を行っています。「ちょうどいい」負荷テストの実施をサポートしますので、お気軽にご相談ください。
負荷テストは、ビジネスを守る重要な投資です。この記事を参考に、ぜひ第一歩を踏み出してください。