負荷テストにJMeterを使うメリット・デメリットと、エンタープライズに最適な選択肢の見極め方

無料で利用できる負荷テストツール、JMeter。しかし、実際に運用してみると、管理や分析に手間がかかったり、大規模なテストに不安を感じるケースも。

そこで本記事では、JMeterの基本的な使い方を解説したうえで、実際に利用する場合の注意点、そして商用ツールとの違いまで、わかりやすく解説します。

JMeterは、Apache Software Foundationが提供するオープンソースの負荷テストツールです。WebアプリやAPIのパフォーマンステストをGUIベースで簡単に実行できます。

JMeterはオープンソースのため、誰でも無料で利用開始できます。小規模な負荷テストから試行的に導入し、段階的に運用を拡大することも可能です。サーバー環境さえ用意できれば、初期投資を最小限に抑えながら、テストを実施できます。

JMeterは様々なプロトコル（HTTP、HTTPS、FTP、JDBC、SOAP、REST）に対応しています。また、プラグインを利用して新しいプロトコルや機能を追加できます。

JMeterはオンラインコミュニティが充実しています。公式ドキュメントのほか、ブログ記事や動画コンテンツなど、学習しやすい環境が整っています。

それでは、Windows環境におけるJMeterの使い方を紹介します。

JMeterの最新バージョン 5.6.3（2025年4月時点）では、Java 8以上が必要なためJDKをインストールしてください。
本記事ではEclipse Adoptiumプロジェクトが提供しているOpenJDKディストリビューション、Eclipse Temurin 17 LTSで動作確認をしています。
https://adoptium.net/temurin/releases/?os=windows&arch=x64&package=jdk&version=17
（新規タブで外部サイトに遷移します）

msi形式であればインストール時にJava環境変数の設定もしてくれるため手間がかかりません。インストール画面で「Set JAVA_HOME variable」のオプションを手動で有効にしてください。

JMeter公式サイトのダウンロードページのBinaries欄からapache-jmeter-*.*.*.zipをダウンロードし、展開してください。(*.*.*はバージョン番号)
https://jmeter.apache.org/download_jmeter.cgi （新規タブで外部サイトに遷移します）

JMeterは完全ではありませんが日本語に対応しています。
JMeterフォルダ/bin/jmeter.batをテキストエディタで開き、JMETER_LANGUAGEというパラメーターを指定している部分を下記のように変更してください。

変更前：set JMETER_LANGUAGE=-Duser.language="en" -Duser.region="EN"
変更後：set JMETER_LANGUAGE=-Duser.language="ja" -Duser.region="JP"

jmeter.batを実行するとJMeterを起動できます。

JMeterではテストシナリオを「テスト計画（Test Plan）」という最上位の単位で管理します。テスト計画の下には、「スレッドグループ」「サンプラー」「リスナー」などの各種コンポーネントを追加し、構成していきます。

テストの基本的なつくり方として、手動でリクエスト内容を追加する方法があります。
ここではWeb Toursという航空券を予約するサンプルアプリを用いて、「Web Tours 5User」というテスト計画名で、サンプルアプリのトップページを5ユーザーで開くというテストを行います。

JMeterを起動すると空のテスト計画が開かれています。
テスト計画名を右クリック>追加>Threads(Users)>スレッドグループを選択します。テスト計画の配下にスレッドグループが追加されます。

スレッドグループ名を右クリック>追加>サンプラー>HTTPリクエストを選択します。スレッドグループ配下にHTTPリクエストのサンプラーが追加されます。

今回のサンプルアプリケーションはローカル環境で動かしているので、下記のURLでアクセスします。
http://127.0.0.1:1080/WebTours/

サンプラーの設定欄に下記を入力します。

サンプラーで設定したリクエストを、どれくらいのユーザー数で実行していくか、などをスレッドグループに設定します。

スレッドグループ名をクリック>スレッドプロパティに下記を入力

この設定例では下記のような挙動になります。

10ユーザーを10秒間で生成＝1ユーザー1秒で生成
各ユーザーは5回リクエストを繰り返す＝合計50回リクエストを実行

テストを実施した結果を取得するためには「リスナー」を追加します。
リスナーにはいろいろな種類がありますが、今回は、リクエスト結果一覧を見やすい「結果を表で表示」を追加します。

スレッドグループ名を右クリック>追加>リスナー>結果を表で表示 を選択

テストが実行できる状態になったので、設定した内容を失わないようにテスト計画を保存します。
メニューのファイル>テスト計画に名前を付けて保存を選択

JMeterでは、ブラウザ操作を記録しサンプラーを生成することもできます。単純なリクエストではないテストケースはこの方法を使います。

この手順は手動でリクエストを作成するときと同じです。

スレッドグループに記録コントローラーというコンポーネントを追加します。この記録コントローラーの配下にサンプラーが追加されていきます。

スレッドグループを右クリック>追加>ロジックコントローラ>記録コントローラを選択

記録を行うには、JMeterのHTTPプロキシサーバーを通して通信をキャプチャする必要があります。そのために必要なHTTPプロキシサーバーのコンポーネントを追加します。

テスト計画名を右クリック>追加>Non-Testエレメント>HTTPプロキシサーバを選択

追加したら設定欄のTest Plan Creationタブ>Test plan content内の「対象となるコントローラ」を下記に変更します。

<テスト計画名> > スレッドグループ > 記録コントローラを選択

Chromeの場合、プロキシサーバーの設定はWindowsの設定から行います。
Chromeの設定からも開くことができます。

Chromeの設定>検索欄でプロキシと入力>パソコンのプロキシ設定を開く

手動プロキシセットアップ欄で下記を実施します。

JMeterのHTTPプロキシサーバ設定欄で「開始」をクリックします。

この時、「HTTPS通信を記録するにはJMeterの証明書をインストールしてください」と表示されます。今回はHTTPS通信ではないため省略しますが、HTTPS通信の場合は、作成された証明書ファイルをbinフォルダにインストールします。

トランザクションコントロールのウィンドウが表示され、記録が開始されます。
ここで、アプリの操作をする前にTransaction nameに名前を入力しておくと、あとで記録結果がわかりやすくなります。

(例）
・ページオープン前に「01_PageOpen」
・ログイン前に「02_Login」

アプリを操作すると記録コントローラー配下にHTTPリクエストのサンプラーが追加されていきます。

操作が終わったらトランザクションコントロールウィンドウに表示されている停止ボタンで記録を停止します。

記録されたHTTPリクエストサンプラーを確認すると、リクエスト内容を確認できます。

テストの実行方法はGUIモードとCLIモードがあります。

テスト進行状況を確認するためにリスナーをクリックして開いておきます。開始アイコンをクリックしてテストを実行します。

リスナーを確認するとテスト結果が表示されています。例えば「結果を表で表示」のリスナーでは下記の情報が表示されています。

作成したテスト計画ファイル（jmxファイル）をJmeter-n.cmdファイルにドラッグアンドドロップします。

JMeterフォルダ>bin>jmeter-n.cmd

コマンドプロンプトのウィンドウが開き、進捗が表示されます。

テストが終わるとコマンドプロンプトウィンドウが閉じます。テスト計画ファイルと同じ場所に、.jtlファイルと.logファイルが出力されます。
.jtlファイルがテスト結果のファイルです。

CLIモードで実行したテストの結果はHTMLレポートとして出力できます。

GUIモードでJMeterを起動（bin/jmeter.batを実行）し、メニューのTools > Generate HTML reportを選択。

下記3つのファイル・フォルダを選択します。

選択したら「Generate report」を選択します。

Report created !が表示されれば、指定した出力先にHTMLレポートファイルが出力されています。

出力先フォルダのindex.htmlを開けばレポートが表示されます。

サンプラーごとの応答時間の統計値や、グラフが表示されます。

JMeterの基本操作の説明は以上です。

JMeterで大規模な負荷テストを実施する場合、分散環境の設計・運用に手間がかかることがあります。特に、数百ユーザーを超える規模のシナリオを実行する際には、単一のマシンではリソースが不足しやすく、分散実行の構成が必要です。

分散実行では複数のマシン間でJMeterの設定やテストデータの同期、ネットワーク構成の調整が求められ、運用やトラブルシューティングの手間が増加します。事前に十分な準備と検証が重要です。

GUIベースでスクリプトを作成できるため、プログラミングの知識がなくても比較的容易にテストシナリオを構築できます。しかし、より細かい制御や複雑なシナリオを作成する際には「IFコントローラ」や「正規表現抽出」などのコンポーネントを使う必要があり、結果としてテストシナリオの管理が複雑になるケースもあります。

また、GUIでの設定が主体となるため、テストのパラメータを一元管理したり、大規模なシナリオを作成する際の可読性やメンテナンス性にも注意が必要です。

テスト結果の可視化や分析については、JMeterにも一定の機能がありますが、目的によっては工夫が必要です。

たとえばJMeter標準機能では、CSV形式での結果出力や、基本的な表・グラフ表示が可能です。また、JMeter 3.0以降ではHTML形式のダッシュボードレポートも自動生成され、レスポンスタイムの推移やエラー率などを視覚的に確認できます。

しかし、リアルタイムでのモニタリングを行いたい場合や、複数テスト結果の比較・トレンド分析を行いたい場合には、CSVデータを外部ツールで加工したり、InfluxDBやGrafanaといったツールと連携したりする必要があります。

こうしたケースでは、JMeterから外部にデータを送信する設定や、可視化ツール側でのダッシュボード構築といった事前の準備が求められるため、それぞれの目的に応じた工夫が必要となります。

現在LoadRunnerは新製品名称に変わっていますが、本記事では旧製品名称のLoadRunnerで記載しています。

LoadRunnerは、オンプレミスとクラウド、両方の実行環境を用途に応じて選択可能です。
社内ネットワーク完結でのテストが求められる場合は、セキュリティに配慮したオンプレミス版（LoadRunner Professional）が適しています。

短期間で大規模テストを実施したい場合や、一時的なリソース強化が必要なケースには、クラウド版（LoadRunner Cloud）が適しています。

クラウドのスケーラビリティを活かし、物理サーバーや仮想マシンの準備なく、必要なタイミングで即座にテストを実行できます。

LoadRunnerはWeb/HTTPだけでなく、Citrix、SAP、Oracleなどミッションクリティカルな業務システムにも対応しています。
レガシーなアプリケーションや複雑な業務システムに対しても、実際の利用状況に近いリアルなトラフィックを再現し、信頼性の高い負荷テストを実施できます。

テスト結果をリアルタイムで確認できるダッシュボード、詳細なグラフや統計情報の自動レポート機能を備えており、テスト完了直後からボトルネックの把握や関係者とのスムーズな情報共有が可能です。

「システムのクラウドリフト前の負荷テストについて相談したい」「実際に製品を見てみたい」といった方は、ぜひ無料相談会やLoadRunnerのデモンストレーションにお申し込みください。専門エンジニアが、お客様の状況に応じてご提案をいたします。