JMeterのシナリオ作成 構成要素と作成手順6ステップ・パラメータ化と実行時の注意点

「JMeterを起動したものの、どこから手をつければよいか分からない」「記録機能で作ったシナリオを流したら、2件目以降がすべてエラーになった」。負荷試験に初めて取り組むとき、ほぼ全員が通る道です。

JMeterのシナリオは、利用者が行う一連の操作をテスト計画として定義したものです。画面遷移やAPI呼び出しの流れを組み立て、jmxという拡張子のファイルとして保存します。

難しいのは、単にリクエストを並べれば動くわけではないという点です。ログイン後のトークン、セッションID、画面ごとに変わる識別子。これらを前のレスポンスから取り出して次に渡さないと、シナリオは通りません。

この記事では、テスト計画を構成する要素の役割から、シナリオ作成の6ステップ、パラメータ化と相関の実装、負荷条件の決め方、そして実行時の注意点までを順に整理します。

確認したいポイント	結論	詳細
シナリオとは？	一連のリクエストをまとめた定義	画面遷移やAPI呼び出しの流れをテスト計画として定義し、jmxファイルとして保存したものです。
GUIで負荷をかけていい？	作成とデバッグのみ。負荷はCLIで	公式が明確に非推奨としています。GUIは資源を消費し、測定結果が歪む原因になります。
最初に決めることは？	対象シナリオと目標とする負荷	どの画面をどれだけの負荷で試すかを決めてから着手します。ここが曖昧だと作り直しになります。
難所はどこ？	動的な値の引き継ぎ（相関）	トークンやセッションIDを抽出して次のリクエストへ渡す処理が、最もつまずきやすい部分です。

この記事でわかること

• テスト計画を構成する7つの要素の役割と、実行される順序およびスコープの考え方
• 対象シナリオの選定から1スレッドでの検証までを通した作成手順6ステップ
• CSVによるパラメータ化と、レスポンスから値を取り出す相関の実装方法
• スレッド数、Ramp-Up期間、ループ回数といった負荷条件の決め方
• CLIモードでの実行方法と、結果が歪む原因になる代表的な落とし穴

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や試験の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

JMeterのシナリオとは

Apache JMeterは、Apacheソフトウェア財団が公開しているオープンソースの負荷試験ツールです。Javaで動作し、WebサイトやAPIに対して多数の利用者が同時にアクセスしている状態を再現できます。

その中でシナリオと呼ばれるのが、テスト計画（Test Plan）として定義した処理の流れです。トップページを開き、ログインし、検索し、詳細画面へ遷移するといった一連の動きを、リクエストの並びとして組み立てます。

シナリオはjmxファイルとして保存される

作成したテスト計画は、jmxという拡張子のXMLファイルとして保存されます。このファイルさえあれば、別の環境でも同じシナリオを実行できます。

実務では、アプリケーションを開発した担当者がシナリオファイルを作成し、インフラ担当者が負荷条件を設定して実行するという分担がよく取られます。ファイルとして受け渡せることが、この分担を成立させています。

XMLであるため差分の確認もできます。バージョン管理システムで管理しておくと、いつ誰が何を変えたかを追えます。

GUIは作成とデバッグ、負荷試験はCLIで実行する

最初に押さえておくべき原則です。JMeterを起動すると、コンソールに「負荷試験にGUIモードを使うな、テストの作成とデバッグのときだけにせよ」という趣旨のメッセージが表示されます。

公式のGetting Started（Apache JMeter）でも、負荷試験の実行にはCLIモード（かつてNon-GUIモードと呼ばれていたコマンドライン実行）を使うよう明記されています。

理由は資源の消費です。GUIの描画処理そのものがCPUとメモリを使い、負荷をかける側が先に限界を迎えます。結果として、測定した数値が実態を表さなくなります。

シナリオ作成の前に決めておくこと

手を動かす前に、次の3点を決めます。ここが曖昧なまま作り始めると、後から全面的な作り直しになります。

• 対象シナリオ：どの画面、どのAPIをテストするのか。すべてを対象にはしない
• 目標値：同時アクセス数、秒間リクエスト数、許容する応答時間
• 実施環境：どこに負荷をかけるのか。本番相当の構成かどうか

目標値の決め方に迷う場合は、IPAが公開する非機能要求グレードが参考になります。可用性、性能・拡張性、運用・保守性など6つの大項目について、要求レベルを段階的に整理するためのツール群が無償で提供されています。

非機能要件の書き方そのものについては要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

テスト計画を構成する要素

JMeterのテスト計画は、役割の異なる部品を組み合わせて作ります。どの部品が何を担うのかを理解していないと、記録機能に頼りきりになります。

スレッドグループ｜仮想利用者を定義する

テスト計画の最上位に置く要素です。何人の利用者が、どのくらいの間隔で、何回アクセスするかを定義します。

設定するのは主に3つです。スレッド数（同時に動作する仮想利用者の数）、Ramp-Up期間（全スレッドを起動しきるまでの秒数）、ループ回数（各スレッドがシナリオを繰り返す回数）です。

1つのテスト計画に複数のスレッドグループを置くこともできます。利用者の種類ごとに分ける、たとえば閲覧のみの利用者と購入まで行う利用者を別のグループにするという使い方が一般的です。

サンプラー｜リクエストを送る

実際にサーバーへリクエストを送る部品です。Webシステムの試験では、HTTPリクエストサンプラーをほぼ必ず使います。

設定するのは、プロトコル、サーバー名、ポート、パス、メソッド、パラメータ、リクエストボディです。1つのサンプラーが1回のリクエストに対応します。

HTTP以外にも、データベースへのクエリ、JMS、TCPなど多様なサンプラーが用意されています。負荷をかけたい対象に応じて選びます。

設定エレメント｜共通の設定をまとめる

サンプラーの動作を支える設定を、まとめて定義する要素です。実務でよく使うのは次の4つです。

• HTTPリクエストの初期値：サーバー名やポートを一括で設定し、各サンプラーの記述を減らす
• HTTPクッキーマネージャ：セッションを維持する。ログインを伴うシナリオでは必須
• HTTPヘッダマネージャ：認証トークンやContent-Typeなどのヘッダを付与する
• CSV Data Set Config：外部ファイルからテストデータを読み込む

HTTPクッキーマネージャを入れ忘れると、ログイン後の画面がすべてエラーになります。原因が分からず時間を溶かす典型例なので、最初に配置しておきます。

ロジックコントローラ｜処理の流れを制御する

リクエストの実行順序や条件を制御する要素です。シンプルコントローラで処理をグループ化する、ループコントローラで特定部分だけ繰り返す、といった使い方をします。

条件によって処理を分ける場合はIFコントローラ、一定割合の利用者だけ特定の操作を行う状況を再現するにはスループットコントローラを使います。

実際の利用者は全員が同じ動きをするわけではありません。「10人に1人だけ購入まで進む」といった分岐を入れると、より実態に近い負荷を再現できます。

タイマー｜待機時間を挟む

リクエストとリクエストの間に待ち時間を入れる要素です。人は画面を見て考える時間があるため、間を置かずに連続でアクセスすることはありません。

タイマーを入れないと、実態よりはるかに厳しい負荷をかけることになります。逆に、意図的に高負荷をかけたい場合は入れないという選択もあります。

よく使われるのは、固定の秒数を待つ定数タイマーと、ばらつきを持たせるガウス乱数タイマーです。全員が同時に同じ動きをする状態を避けるという意味でも、乱数を含めるほうが自然な負荷になります。

アサーション｜応答内容を検証する

レスポンスが期待どおりかを判定する要素です。HTTPステータスが200でも、中身がエラー画面ということはあります。

応答テキストに特定の文字列が含まれているかを見るレスポンスアサーションが基本です。ログイン後の画面にユーザー名が表示されているか、といった検証を入れます。

これを入れずに試験すると、すべて成功と表示されているのに実際は失敗していたという事態が起こります。負荷が高まったときこそ、内容の検証が意味を持ちます。

リスナー｜結果を記録・表示する

実行結果を収集して表示する要素です。作成中のデバッグでは、リクエストとレスポンスの中身を確認できる結果をツリーで表示が欠かせません。

ただし、リスナーはメモリを大量に消費します。負荷試験の本番実行では、リスナーをすべて削除するか無効化するのが原則です。結果はコマンドラインのオプションでファイルに出力します。

実行される順序とスコープ

要素をどこに配置するかで、影響が及ぶ範囲が変わります。テスト計画の直下に置けば全体に、特定のサンプラーの下に置けばそのサンプラーだけに適用されます。

設定エレメントとタイマーは、同じ階層にあるサンプラーすべてに影響します。一方、アサーションと後処理はサンプラーごとに設定できます。

意図しない場所に部品を置いてしまい、想定と違う動作をするというのは初心者に多いつまずきです。動作がおかしいときは、まず配置場所を確認します。

シナリオ作成の手順｜6ステップ

ここからは実際の作成手順です。リクエストを並べる作業より、その前後の設計と検証に時間がかかります。

ステップ1｜対象のシナリオを選定する

すべての画面をテストするのは現実的ではありません。影響の大きさを基準に対象を絞り込みます。

• アクセス数が多いURL（アクセス解析や監視ツールの実績から抽出）
• 重いテーブルを参照している処理（レコード数の多いテーブルを使う画面）
• 更新系の処理（参照より負荷が高く、排他制御の影響を受ける）
• 外部システムとの連携を含む処理

選定したシナリオは表にまとめ、関係者にレビューしてもらいます。処理内容が参照か更新か、外部連携があるかといった観点で分類すると、抜けを発見しやすくなります。

あわせて、トップページから対象画面までの導線をたどる形で画面遷移のフローを決めます。実際の利用者と同じ経路を通ることが前提です。

ステップ2｜スレッドグループを追加する

テスト計画を右クリックし、追加からThreads（Users）を選んでスレッドグループを配置します。この段階ではスレッド数1、ループ回数1にしておきます。

負荷条件を設定するのは、シナリオが正しく動くことを確認した後です。作成途中で高い負荷をかけると、エラーの原因が負荷なのかシナリオの誤りなのか判別できなくなります。

続けて、スレッドグループの下にHTTPリクエストの初期値とHTTPクッキーマネージャを配置しておきます。先に置いておくと、後の作業が楽になります。

ステップ3｜リクエストを組み立てる

画面遷移の順にHTTPリクエストサンプラーを追加していきます。1画面が1リクエストとは限らず、内部でAPIを複数呼んでいる場合はその分だけ必要になります。

ブラウザの開発者ツールでネットワークタブを開き、実際に飛んでいるリクエストを確認しながら作ると確実です。手作業が大変な場合は、次章の記録機能を使います。

サンプラーには分かりやすい名前を付けます。「HTTPリクエスト」のままだと、結果を見たときにどの処理か判別できません。「01_トップページ表示」のように連番と処理名を入れます。

ステップ4｜パラメータ化する

全スレッドが同じIDでログインすると、実態と異なる状態になります。キャッシュが効いてしまい、実際より良い数値が出るためです。

テストデータをCSVファイルに用意し、CSV Data Set Configで読み込みます。スレッドごとに異なる行が割り当てられ、変数として参照できるようになります。

ファイル名　：/path/to/users.csv

変数名　　　：userId,password

区切り文字　：,

スレッド共有：すべてのスレッド

読み込んだ値は、サンプラーの中で「${userId}」のように記述して参照します。検索キーワードや商品IDもパラメータ化しておくと、より実態に近い負荷になります。

ステップ5｜動的な値を引き継ぐ

シナリオ作成で最も難しい工程です。CSRFトークン、セッションID、画面ごとに発行される識別子といった値は、実行のたびに変わります。

前のレスポンスから値を取り出し、次のリクエストに渡す処理が必要です。これを相関と呼びます。使うのは後処理の要素です。

• 正規表現抽出：HTMLの中から正規表現で値を取り出す。最も汎用的
• JSON抽出：APIのレスポンスからJSONPathで値を取り出す
• CSSセレクタ抽出：HTMLの要素をセレクタで指定して取り出す

抽出した値は変数に格納され、後続のサンプラーで参照できます。取り出せているかどうかは、デバッグ用のサンプラーやリスナーで確認します。ここを飛ばすと、原因不明のエラーに悩まされます。

ステップ6｜1スレッドで動作を検証する

負荷をかける前に、スレッド数1、ループ回数1で最後まで通ることを確認します。結果をツリーで表示するリスナーを追加し、各リクエストの中身を1つずつ見ていきます。

確認すべきは、ステータスコードだけではありません。レスポンスの中身が期待した画面になっているかを目視します。ログイン画面に戻されていないか、エラーメッセージが含まれていないかを見ます。

通ったら、スレッド数を2から3に増やして再度確認します。1スレッドでは発覚しない、データの競合や相関の漏れがここで見つかります。

試験計画や目標値の設定からご相談いただけます 作り方は分かっても、自社のどのシナリオをどこまで試すべきかの判断は別の問題です。計画段階からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

ブラウザ操作の記録機能を使う

リクエストを1つずつ手で作るのが大変な場合は、ブラウザの操作を記録してシナリオを自動生成する機能が使えます。

記録機能の仕組み

JMeterにはHTTP(S) Test Script Recorderという要素が用意されています。JMeterがプロキシサーバーとして動作し、ブラウザとサーバーの間を通る通信を記録する仕組みです。

テスト計画に記録用の要素を追加してポートを指定し、ブラウザのプロキシ設定をそのポートに向けます。その状態で操作すると、リクエストがサンプラーとして自動追加されていきます。

HTTPSの通信を記録するには、JMeterが生成する証明書をブラウザに読み込ませる必要があります。この設定でつまずくことが多いため、公式の手順を確認しながら進めます。

記録するときの下準備

そのまま記録すると、不要なリクエストが大量に混ざります。画像、CSS、JavaScript、外部の広告や解析タグまで記録されるためです。

記録用の要素には除外パターンを設定できます。静的ファイルの拡張子を除外リストに入れておくと、記録される内容が大幅に整理されます。

また、記録の前にブラウザのキャッシュとCookieを消しておきます。初回アクセスの状態から記録することで、実際の利用者と同じ流れを再現できます。

記録後に必ず行う整理

記録しただけのシナリオは、そのままでは使えません。固定値が埋め込まれているため、2回目以降の実行で失敗します。

行うべき整理は3つです。不要なリクエストの削除、入力値のパラメータ化、そして動的な値の相関です。記録は下書きを作る機能であり、そこから手を入れる前提で使います。

サンプラー名も記録されたままでは意味が分かりません。処理内容が分かる名前に付け替える作業を、この段階で済ませておきます。

負荷条件の決め方

シナリオが動くようになったら、次は負荷の設定です。この数値の根拠が説明できないと、試験結果の解釈もできません。

スレッド数・Ramp-Up期間・ループ回数

スレッド数は同時に動作する仮想利用者の数です。同時アクセス数の目標値をそのまま設定するのが基本になります。

Ramp-Up期間は、全スレッドを起動しきるまでの秒数です。100スレッドをRamp-Up期間100秒で設定すると、1秒に1スレッドずつ起動します。0にすると全員が同時に殺到する状態になり、実態からかけ離れます。

ループ回数は、各スレッドがシナリオを何回繰り返すかです。試験時間を一定にしたい場合は、回数ではなくスケジューラで実行時間を指定する方法もあります。

目標値をどう決めるか

根拠なく決めた数値で試験しても、合否の判断ができません。実績値から積み上げるのが基本的な考え方です。

既存システムがあるなら、アクセス解析や監視ツールから通常時とピーク時のリクエスト数を取得します。新規システムなら、想定利用者数と1人あたりの操作回数から算出します。

そのうえで、将来の伸びを見込んだ倍率をかけます。3年後の想定利用者数で試験しておく、といった考え方です。応答時間の許容値もあわせて決めておきます。

待機時間で実態に近づける

タイマーを入れずに実行すると、1人の仮想利用者が休みなくリクエストを送り続けます。現実の利用者は画面を読む時間があるため、この状態は起こりません。

画面遷移の間に数秒の待機を入れると、より実態に近い負荷になります。入力を伴う画面では、それ以上の時間を見込みます。

ただし、限界性能を測りたい場合は意図的に待機を入れないという判断もあります。何を測るための試験なのかによって設定が変わります。

実行と結果の確認

検証が済んだら、いよいよ負荷をかけます。GUIではなくコマンドラインから実行するのが原則です。

CLIモードで実行する

コマンドの基本形は次のとおりです。JMeterの起動時にも同じ内容が案内されます。

jmeter -n -t test.jmx -l result.jtl -e -o report

オプションの意味は、nがCLIモードでの実行、tが読み込むjmxファイル、lが結果を出力するファイル、eが実行後のHTMLレポート生成、oがレポートの出力先です。

実行前にリスナーを削除または無効化しておきます。GUI向けのリスナーはメモリを消費し、大量のスレッドを動かす際の妨げになります。結果はlオプションのファイルに記録されます。

あわせてJavaのヒープサイズも見直します。既定では1GBに設定されており、スレッド数やシナリオの規模によっては不足します。起動スクリプト内の設定を変更して増やします。

HTMLレポートで結果を見る

eとoのオプションを付けて実行すると、指定したフォルダにHTML形式のレポートが生成されます。ブラウザで開くと、グラフつきで結果を確認できます。

見るべき指標は、スループット（秒間の処理件数）、応答時間の分布、エラー率の3つです。平均値だけでなく、90パーセンタイルや最大値も確認します。

平均応答時間が目標内でも、一部のリクエストだけ極端に遅いというケースがあります。分布を見ないとこの偏りは発見できません。

分散実行で負荷を増やす

1台のマシンから出せる負荷には限界があります。それ以上が必要な場合は、複数のマシンでJMeterを動かす分散実行を使います。

制御用のマシンから複数の実行用マシンへ指示を出し、結果を集約する構成です。公式のベストプラクティスでも、大規模な負荷試験では分散モードの利用が案内されています。

注意点として、すべてのマシンでJMeterのバージョンとファイルの配置を揃える必要があります。バージョンが違うと動作しません。CSVファイルも各マシンに配置します。

つまずきやすい点と対処

負荷試験の失敗は、対象システムの問題ではなく試験側の問題であることが少なくありません。代表的な落とし穴を整理します。

GUIで負荷をかけて結果が歪む

繰り返しになりますが、最も基本的な失敗です。GUIの管理スレッドが処理を妨げ、メモリを消費するリスナーが動き続けます。

測定した数値が対象システムの性能ではなく、JMeter側の限界を表しているという状態になります。作成とデバッグはGUI、実行はCLIという使い分けを徹底します。

負荷をかける側が先に限界を迎える

CLIで実行していても、実行するマシンのCPU、メモリ、ネットワーク帯域が不足していれば同じことが起こります。負荷が出ていないのに、対象システムが遅いと誤認します。

対策は、試験中に実行側のマシンの資源使用状況を監視することです。CPU使用率が高止まりしているなら、スレッド数を減らすか分散実行に切り替えます。

公式のベストプラクティスでは、スレッド数を適切に設定しないと結果が不正確になるという点も指摘されています。闇雲にスレッド数を増やせばよいわけではありません。

相関の漏れでエラーになる

1件目は成功するのに2件目以降が失敗する場合、動的な値の引き継ぎができていない可能性が高くなります。

結果をツリーで表示するリスナーで、失敗したリクエストのパラメータを確認します。トークンの値が空になっている、記録時の古い値のままになっているといった状態が見つかります。

抽出が機能しているかは、デバッグ用のサンプラーで変数の中身を出力すると確認できます。1つずつ確認する地道な作業が、結局は最短の解決策です。

エラー時の挙動を揃えていない

スレッドグループには、サンプラーがエラーになった場合の動作を指定する設定があります。継続する、現在のループを止める、スレッドを止める、テスト全体を止めるといった選択肢があります。

複数のスレッドグループでこの設定がばらついていると、一部のエラーでテスト全体が停止してしまうことがあります。原因が分かりにくく、調査に時間を要します。

シナリオ間で設定を揃えることをルールにしておくと、この種のトラブルを防げます。

本番環境に負荷をかけてしまう

最も避けるべき事故です。設定ファイルの接続先が本番のままになっていた、というのは実際に起こります。

対策は、接続先をプロパティとして外部化し、実行時にコマンドラインで指定する方式にすることです。jmxファイルの中に本番のURLを書かないという運用にします。

また、共用の検証環境に負荷をかける場合は、実施日時を関係者へ事前に周知します。他チームの作業と重なると、双方の結果が信用できなくなります。

テスト工程全体の進め方や、外部委託時の役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方も参考になります。

まとめ

JMeterのシナリオ作成は、スレッドグループ、サンプラー、設定エレメント、ロジックコントローラ、タイマー、アサーション、リスナーという要素を組み合わせて行います。各要素の役割と配置による影響範囲を理解することが出発点です。

手順は6ステップです。対象を選定し、スレッドグループを置き、リクエストを組み立て、パラメータ化し、動的な値を相関させ、1スレッドで検証する。負荷をかけるのは、この検証が終わってからです。

最も難しいのは相関です。トークンやセッションIDを前のレスポンスから取り出して次に渡す処理ができていないと、2件目以降がすべて失敗します。

実行はCLIモードで行います。GUIでの負荷試験は公式が明確に非推奨としており、測定値が歪む原因になります。リスナーを外し、ヒープサイズを見直したうえで実行します。

まずは対象を1シナリオに絞り、スレッド数1で最後まで通すところから始めてください。1本通れば、あとは同じ手順の繰り返しです。

システム開発の進め方から、無料で相談できます 性能要件の妥当性を判断したい、社内に試験の知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎