皆様いかがお過ごしでしょうか！🎄
毎年言っていますが、今年もあっという間すぎました！

私自身、今年はwebエンジニアとして設計から担当する一方で、AIを本格的に使うようになったり、実際の商談・展示会へ参加するようになったり、と担当する分野が増えていったような気がしています。😪

その中で今夏に初めて本格的な負荷テストを担当することとなり、JMeterなるものを使用しました。
テスト自体は試行錯誤の上で成功し、phpfpmなどの調整を経て無事負荷テストフェーズは終了しましたが、インフラチームとの連携でサーバースペックの変更したり、夏季休暇の取得なりで約1ヶ月も費やしてしまいました。

そんな初めての負荷テスト・JMeterでしたが、UIと反してかなりの高機能だなと感じましたので、今年の思い出の1つとしてこちらを記事にまとめようと思います。
どうぞ、お付き合いをよろしくお願いいたします！！

そもそも負荷テストとは？

負荷テストとは、システムに同時に多数のアクセスが発生するなどの理由で、負荷がかかった状態でのシステムの挙動を確認するテストです。

人がシステムを使うタイミングは平均化されるものではありません。1日のなかでは朝夕に、1週間なら週のはじめと終わりにシステムを使う頻度があがります。テレビに紹介された企業のWebサイトにアクセスが集中したり、チケットの予約開始時にアクセスが殺到したりすることもあります。

このような状況では、CPU、メモリ、ストレージ、ネットワークなどのシステムのリソース使用量が増え、状況によってはスローダウンしたり、最悪の場合はシステムダウンにつながったりします。

負荷テストは、このような状況をシミュレートすることで、想定したアクセス数でも業務が実施できること、また、想定以上のアクセスが発生してもシステムダウンを起こさないで耐えられることを確認するテストです。

上記のように、テスト対象のシステムにユーザーなどを想定数以上流すわけですが、それにはツール使用が便利です。そこでのJMeter登場です。

JMeterとは

JMeterとは、Webサービスを中心にさまざまなアプリケーションの負荷テストおよびパフォーマンスの計測が行えるツールです。Apacheソフトウェア財団によって開発されているJavaアプリケーションで、正式名称は「Apache JMeter」です。オープンソースであることや利用制限がないこと、多機能であることから、システムの性能測定に広く利用されています。

JMeterの仕組み
JMeterは対象となるサーバーに対して指定した量のリクエストを送り、受け取ったレスポンスを収集、統計を算出することでパフォーマンスを計測できます。レスポンス内容を検証することができるため、簡易的な機能テストとして使用することも可能です。豊富なプラグインが用意されておりカスタマイズの幅も広く、条件分岐などを含むテストシナリオを作成することもできます。

他にもk6、Locust、Gatlingなどの負荷テストツールがあるようですが、JMeterが知名度で言うと（特に日本では）No. 1と言えるようです。

基本的な使い方

Jmeterを開くとTest Planがあるので、その中にThread Groupを作成します。
そこにスレッド数・Ramp-Up期間・ループ回数などを設定し、このThread Groupの中にシナリオを書いていく、という流れになります。ちなみにこれら3つは

のような意味となります。
↓GUIで簡単に設定ができます。

ここまでが負荷テスト・JMeter概要でした！
以下は1ヶ月格闘した結果便利だなと思った機能まとめになります。
本来負荷テストはサーバでの負荷を試すものですが、今回は機能紹介ということでローカルでの実行になります。
（負荷テスト初心者目線での説明となるため、至らない点があればご容赦ください）

1. Http(s) Test Script Recorder（シナリオ録画機能）

ブラウザ操作をそのまま「自動でテストシナリオ化」できる機能になります。

負荷テストのシナリオ作成は手動で書くといちいちエンドポイントを入力したり、ヘッダーを設定したりと非常に面倒ですね。ChromeでクリックしたものがGET/POST、遷移、フォーム入力までJMeterに即反映されるので時間短縮間違えなしです。

• 設定方法

1. Thread Groupを作成
2. Test PlanにHTTP プロキシサーバを作成し、「対象となるコントローラ」を作成したThread Groupに指定する
3. 開始を押すとルート証明書が作成されるので、キーチェーンアクセスなどに設置する（Macの場合）
4. 以下のようなコマンドを実行するとChromeが起動されるため、そこでシナリオを手動実行する

/Applications/Google\Chrome.app/Contents/MacOS/GoogleChrome\--user-data-dir=/tmp/chrome-jmeter\--proxy-server="http=127.0.0.1:8888;https=127.0.0.1:8888"\--proxy-bypass-list="<-loopback>"

実行後にThread Groupを見るとシナリオが追加されています。

2. HTMLレポート作成機能

まずJMeterで作成したTest Planを保存するとjmx拡張子ファイルとして保存されるのですが、
以下のコマンドにてCLIからそのシナリオ実行・結果を保存してくれます。（GUIから実行することもできるが、結果保存は手動で行う）

jmeter-n-t ./test.jmx-l ./result.jtl

生成された結果ファイルはjtl拡張子ファイルとなります。これをJMeterの結果をツリーで表示の「参照」から取り込むと結果が分かります。（View Results Tree）

ここまでは標準機能だと思いますが、これをhtmlレポートにすることも可能です。

jmeter-g result.jtl-o reportopen report/index.html## またはjmeter-n-t test.jmx-l result.jtl-e-o report/

生成されるreportディレクトリ内のindex.htmlを開くとAPDEXスコアや成功/失敗率の円グラフ、エラー内訳などが確認できます。（今回の結果は良くないですが。。）

3. CSV Data Set Config（疑似ユーザーの大量生成する機能）

ログインIDなどのパラメータをCSVのデータに差し替えが可能になります。
csvに以下のように記述します。

id,passworduser01,pass01user02,pass02

これらをCSV Data Set Configの中でパス指定、変数設定などを行うことによって
HTTP Requestなどから${id}と参照することができるようになります。
基本的にCSVの中のデータが上から使われていくので、100行データ用意をすると100ユーザー使うことができます。大量のユーザーで負荷テストを行いたい時に便利ですね。

4. Debug Sampler（デバッグツール）

View Results Treeではシナリオ結果が確認でき、保存もできますが
Debug SamplerはJMeter内部で使われている変数の中身まで確認することもできるデバッグリスナーです。

以下のような初歩的なミスもDebug Samplerで簡単に発見できます。

• CSV Data Set Configで読み込んだ変数が空になっている
• 意図しない値が変数に入っている
• 想定したタイミングで変数がセットされていない

変数まわりに違和感を感じた場合は、まずDebug Samplerを追加して確認してみることをおすすめします。

5. HTTPヘッダマネージャ（User-Agentや認証ヘッダの再現）

必要なヘッダをそっくり再現できます。

• User-Agent
• Authorization
• Accept
• X-Requested-With

WebアプリやAPIテストでほぼ必須ですが、シナリオ録画機能を使えばこれらも自動で入るので全て手入力をする必要はないです。
（私はJMeter使い始めの頃、手入力である程度進めてしまってました。。）

6. Cookie Manager / Cache Manager（ログイン状態維持）

JMeterはデフォルトでCookieを覚えないです。

• ログイン後の遷移が失敗する
• APIのセッションが維持されない

こういった場合はCookie Manager、ブラウザキャッシュまで再現したい場合はCache Managerを追加すれば解決することが多いです。
基本的にThread Group配下にただ追加するだけでOKです。

7. タイマー系

タイマーを使うとユーザーのリアルな動作間隔を作れます。

• 定数タイマー
• 一様乱数タイマー
• ガウス乱数タイマー

などがあり私は一様乱数タイマーを使いましたが、ユーザーの待機時間を

• ページ読むのに30から50秒
• 入力に10から30秒

のように設定することによって、よりユーザーの現実的な動きを意識したテストが可能です。

8. Extractor（レスポンス内容の取り出し）

APIレスポンスから値を抽出し、次のリクエストに使えます。

• JSON Extractor
• Regex Extractor
• CSS Selector Extractor
• XPath Extractor

私はログインAPIのtokenを次以降のAPIで使うことを対応しました。
こちらも変数設定することによって、使用することができます。

まとめ

本記事では、初めてJMeterで負荷テストを行った際に、便利だと感じた機能を中心に紹介しました。JMeterは一見とっつきにくい印象がありますが（私はそうだった）

• シナリオ録画によるテスト作成の効率化
• CSVによる疑似ユーザーの大量生成
• Debug Samplerを使った変数まわりのデバッグ
• Cookie / Header / Timer を使った実ユーザーに近い挙動の再現
• HTMLレポートによる結果の可視化

など、実務で役立つ機能が充実しているなと感じました！
ちなみに今回はローカルで例をお見せしましたが、本番のテストではサーバースペックギリギリまで負荷をかけることになると思うので、テスト実行はCLIで行ったことを思い出しました。それでもエラー率が3%程度残ってしまい苦戦しましたね。
（結局サーバースペックが主な原因でしたが。。）

負荷テストは設定項目も多く、最初は戸惑うことも多いですが、
一つひとつの機能を理解していくことで「なぜこの挙動になるのか」が見えるようになります。

これからJMeterを使い始める方や、
「とりあえず動かしてみたい」という方の参考になれば幸いです！

最後まで記事を読んでいただきありがとうございました。2025年もあと少し。
良き年末をお過ごしください。皆様良いお年を！！🎍