はじめに

JMeterで負荷テストを組む際、最初の壁になりやすいのが「テストシナリオ（HTTPリクエストの並び）をどう作るか」です。ログイン→画面遷移→データ登録、といった一連の業務操作をHTTPリクエストとして手作業で組み立てるのは非常に骨が折れますが、JMeterにはHTTP(S) Test Script Recorderというブラウザ操作をそのまま記録できる機能が用意されています。

この記事は、実際にJava製のWebアプリケーションを対象にRecorderを使ってシナリオを記録した実務経験をもとに、手順と実際にハマったポイントをまとめた実践ガイドです。

まだJMeterを触ったことがない方は、先に基本編（JMeterとは？基本概念とインストール）で全体像とインストール方法を確認しておくことをおすすめします。この記事はJMeterのインストールが完了している前提で、シナリオ記録の手順にフォーカスします。

体系的にJMeterを学びたい方には、Udemyの講座も選択肢になります。特にJMeter — Complete Performance & Load Testing Bootcamp（Vishwanatha Hebbar講師）は、この記事のテーマであるHTTP(S) Test Script Recorderの使い方に14分程度の専用レクチャーを割いて解説しており、証明書設定やBlazeMeterプラグインとの使い分けまでカバーしています。全25セクション・約36時間とボリュームがあるため、記録以外の負荷テスト全体（シナリオ設計・実行・結果分析）まで体系的に学びたい人に向いています。

👉 講座の詳細を見る（Udemyで確認）

この記事で分かること

• HTTP(S) Test Script Recorderとは何か、手動でHTTPリクエストを組むより何が効率的なのか
• Recorderの設定手順（プロキシ設定・証明書設定を含む）
• ブラウザ操作をキャプチャしてシナリオを記録する具体的な流れ
• 記録後にやっておくべきシナリオ整理（不要なリクエストの除去・静的リソースの除外設定）
• jmxファイルとして保存・管理する際のポイント
• AIエージェント（Claude Code等）に記録済みシナリオを解析・整理させる活用アイデア

HTTP(S) Test Script Recorderとは

HTTP(S) Test Script Recorderは、JMeterが内蔵しているローカルプロキシサーバーです。ブラウザの通信をこのプロキシ経由に設定した状態で画面を操作すると、ブラウザとサーバーの間でやり取りされたHTTPリクエストをJMeterがそのままキャプチャし、テスト計画の中にHTTPリクエストサンプラーとして自動で並べてくれます。

JMeter 5.x系では、日本語UIでは「HTTPプロキシサーバ」という名前で表示されます。内部的な機能名（HTTP(S) Test Script Recorder）と日本語表示名（HTTPプロキシサーバ）が異なるため、日本語版JMeterでメニューを探すときは「Non-Testエレメント → HTTPプロキシサーバ」を選ぶ点に注意してください。

手動でリクエストを組むより効率的な理由

特に、ログイン後に発行されるセッションID・CSRFトークンのような動的なパラメータは、手動で組むと見落としがちです。Recorderであれば実際の通信をそのままキャプチャするため、まず「動いているシナリオ」を素早く作れるのが最大のメリットです（動的パラメータの変数化そのものは記録後の別作業になります。この点はsessionKey動的化のハマりどころで詳しく扱います）。

Recorderの設定手順

全体構成

まずテスト計画に以下の要素を追加します。

テスト計画
└── スレッドグループ
    ├── HTTPクッキーマネージャ        ← セッション維持に必須
    └── 記録コントローラ              ← 記録の格納先
              （日本語版では「記録コントローラ」、英語版では Recording Controller）
テスト計画（直下）
└── HTTPプロキシサーバ                ← プロキシ本体
              （英語版では HTTP(S) Test Script Recorder）

1. スレッドグループを追加
   テスト計画を右クリック → 追加 → Threads(Users) → スレッドグループ
2. HTTPクッキーマネージャを追加
   スレッドグループを右クリック → 追加 → 設定エレメント → HTTPクッキーマネージャ（設定はデフォルトのままでOK）。セッションCookieを維持するために、記録前に必ず入れておきます。
3. 記録コントローラを追加
   スレッドグループを右クリック → 追加 → ロジックコントローラ → 記録コントローラ（記録されたリクエストの格納先になります）
4. HTTPプロキシサーバを追加
   テスト計画を右クリック → 追加 → Non-Testエレメント → HTTPプロキシサーバ
   • ポート: 8888（デフォルトのままでOK）
   • 対象となるコントローラ: 手順3で作った「記録コントローラ」を選択

この「対象となるコントローラ」の指定を間違えると、記録自体は動いているのにリクエストがどこにも格納されない、という事象が起きます。記録が終わったのに記録コントローラの下が空、という場合はまずここを疑ってください。

静的リソースを除外するフィルタ設定（重要）

HTTPプロキシサーバの「Requests Filtering」タブにある**「除外するパターン」**に、以下を1行ずつ追加します。

.*\.css
.*\.js
.*\.png
.*\.gif
.*\.jpg
.*\.ico
.*\.woff
.*\.woff2
.*\.ttf
.*\.svg

これを設定しておかないと、画面を1つ開くだけでCSS・JS・画像などの静的リソースへのリクエストが何十件も記録され、業務ロジックに関係するリクエストが埋もれてしまいます。実務では、この設定を忘れたまま記録したところ、本来25件程度で済むはずの業務リクエストに対して静的リソースが1,000件以上記録されてしまい、後から手作業で選別する羽目になったことがありました。記録を始める前に必ず設定しておくことを強くおすすめします。

つまずきポイント: 除外パターンは「1行に1パターン」で登録する必要があります。カンマ区切りやスペース区切りで1行にまとめて入力すると正規表現として認識されず、除外が効きません。「追加」ボタンで1行ずつ登録してください。

プロキシ設定（ブラウザ側）

Windowsのシステムプロキシ設定を、JMeterのプロキシ（localhost:8888）経由に切り替えます。

1. Windowsの検索バーで「プロキシ」→「プロキシの設定を変更する」を開く
2. 「自動プロキシセットアップ」の「セットアップスクリプトを使う」をオフにする
3. 「手動プロキシセットアップ」で以下を設定
   • プロキシサーバーを使う: オン
   • アドレス: localhost
   • ポート: 8888
4. 「保存」

⚠️ この設定をしている間は、通常のWebアクセス（他サイトの閲覧等）ができなくなります。記録が終わったら忘れずに元に戻してください（手順は後述）。

HTTPS環境での証明書設定

対象アプリがHTTPSの場合、JMeterが動的に生成する証明書をブラウザ側で信頼する必要があります。プロキシ経由でアクセスすると証明書の警告ダイアログが出るので、内容を確認したうえで「信頼する」を選択してください。対象がHTTP（暗号化なし）の場合はこの手順は不要です。

シナリオを記録する具体的な流れ

Step 1: 記録を開始する

HTTPプロキシサーバの設定画面で「開始」ボタンを押します。証明書の警告ダイアログが出た場合はここで許可を確定させてください（自動的に閉じてしまい許可し忘れる、というトラブルも実際に起きたので、ダイアログが出たら確実にクリックすることをおすすめします）。

「開始」を押した後、ボタンが「停止」に変わってアクティブになっていることを確認します。ここがグレーアウトしたまま、あるいは反応がない場合はプロキシが正常に起動していない可能性があります。

Step 2: ブラウザで一連の業務操作を行う

記録対象のブラウザでアプリにアクセスし、テストしたい一連の操作を通しで行います。例えば以下のような流れです。

① ログイン画面を開く
② ID・パスワードを入力してログイン
③ メニュー画面から対象機能を選択
④ 一覧画面で対象データを選択して詳細画面に遷移
⑤ 明細ごとに入力・登録操作を繰り返す（複数件ある場合はその件数分）
⑥ 画面を閉じてメニューに戻る

セッションはログインから始まるため、記録は必ずログイン操作から含めるのが基本です。途中から記録を始めると、後からログイン部分だけ別途組み立て直す手間が発生します。

操作中の注意点は以下の3つです。

• 普通の操作ペースで行う: 速すぎる連続操作は記録漏れの原因になることがあります
• 余計な操作をしない: 記録中に別タブで無関係なサイトを開いたりすると、それも全部記録されてしまいます
• できれば1回でミスなく通す: 記録はやり直せますが、途中で操作ミスがあると後の整理が余計に大変になります。可能であれば事前にテストデータを用意し、1回できれいに操作を通すのが理想です

Step 3: 記録を停止する

一連の操作が終わったら、HTTPプロキシサーバの設定画面で「停止」ボタンを押します。

Step 4: 記録内容を確認する

左ペインの「記録コントローラ」の左にある展開マーク（▶）をクリックし、配下にHTTPリクエストが時系列で並んでいるかを確認します。

記録コントローラ
├── /webapp/login.do
├── /webapp/menu/init.do
├── /webapp/menu/select.do
├── /webapp/detail/init.do
├── /webapp/detail/regist.do  ← 1件目
├── /webapp/detail/regist.do  ← 2件目
├── ...
└── /webapp/detail/regist.do  ← N件目

何も表示されていない場合は記録に失敗しています。 よくある原因は以下の3つです。

実務で実際にハマった例: プロキシ設定・対象コントローラの指定はすべて正しいのに、ブラウザは問題なくアプリにアクセスできて、それでも記録コントローラが空、という状態に遭遇しました。原因は「ローカル（イントラネット）アドレスにはプロキシサーバーを使わない」というWindowsのプロキシ設定でした。社内向けのホスト名へのアクセスが「ローカルアドレス」と判定されてプロキシがバイパスされ、JMeterを経由していなかったのです。イントラネット環境の対象システムで記録がうまくいかない場合は、この設定と、ブラウザ起動時に--proxy-serverオプションでプロキシを直接指定する方法を試してみてください。このあたりの一連のトラブルシューティングの流れは、AIエージェントとのトラブルシューティング体験記で詳しく紹介しています。

Step 5: プロキシ設定を元に戻す

記録が終わったら、Windowsのプロキシ設定を元に戻します。

1. 「自動プロキシセットアップ」の「セットアップスクリプトを使う」をオンに戻す
2. 「手動プロキシセットアップ」の「プロキシサーバーを使う」をオフにする
3. 「保存」

これを忘れると、通常のWebアクセスができない状態が続いてしまうので注意してください。

記録後のシナリオ整理

Recorderで記録した直後のシナリオは、そのままでは負荷テストに使いにくい状態になっていることがほとんどです。以下の整理を行いましょう。

1. 不要なリクエストの削除

除外フィルタを設定し忘れていた場合や、フィルタの設定ミス（前述の「1行1パターン」を守っていない等）があった場合、静的リソースへのリクエストが大量に記録されてしまいます。この場合は左ペインで該当リクエストを選択し、手作業で削除します。

また、/favicon.icoや特定ブラウザの自動更新チェック用リクエスト（/connecttest.txt等）のように、業務ロジックと無関係なリクエストが紛れ込むこともあります。除外パターンに追加しておくか、記録後に個別に削除してください。

2. リクエストへの名前付け

記録直後のリクエスト名はURLのパスがそのまま使われるため、どの業務操作に対応するのか分かりにくいことがあります。「ログイン」「詳細画面表示」「1件目登録」のように分かりやすい名前を付け直しておくと、後で結果ツリーを見たときの可読性が大きく上がります。

3. Think Time（操作間隔）の調整

Recorderは実際の操作間隔をそのまま記録しないため、必要に応じてタイマー（一様乱数タイマー等）を追加し、実際のユーザーの操作間隔に近い待機時間を設定します。本番のアクセスログから実際の操作間隔を逆算する方法は、本番アクセスログからのシナリオ設計で扱います。

jmxファイルとして保存・管理するポイント

• 業務パターンごとにファイルを分ける: 複数の業務パターンを記録する場合、最初から1つの巨大なjmxにまとめようとせず、パターンごとに個別のjmxファイルとして保存しておくと、それぞれを単体でデバッグしやすくなります。最終的に複数パターンを統合する場合も、個別ファイルが手元に残っていれば問題箇所の切り分けがしやすくなります。
• 命名規則を決めておく: 「対象パターン名_スレッド数_対象環境」のように命名規則を決めておくと、後から見返したときにどの条件で記録・実行したファイルか一目で分かります。
• フォルダ構成を最初に決めておく: jmxファイル置き場、テストデータ（CSV）置き場、実行ログ・レポート出力先を分けておくと、ファイルが増えてきたときに管理しやすくなります。

project/
├── jmx/     ← テスト計画ファイル（.jmx）
├── data/    ← CSVデータ（ユーザーID、テストデータ等）
├── log/     ← 本番アクセスログの抽出結果など
└── report/  ← 実行結果レポートの出力先

• バックアップを取ってから編集する: jmxはXML形式のテキストファイルですが、後述するように機械的な文字列置換（正規表現抽出器の追加やパラメータの変数化など）を行うことが多く、編集に失敗するとXML構造が壊れて開けなくなることがあります。編集前に日時付きでバックアップを取っておく習慣をつけておくと安心です。

AIエージェントにシナリオを解析・整理させる活用アイデア

記録直後のjmxファイルは1行の巨大なXMLになっていることが多く、人間の目でリクエストの中身をひとつずつ追うのは非効率です。ここでClaude CodeのようなAIエージェントを使うと、以下のような作業を効率化できます。

• リクエスト一覧の抽出: jmxファイル内のtestname属性（各リクエストサンプラーの名前）を抽出させ、記録されたリクエストの全体像を一覧化させる
• 記録済みシナリオの解析: 「このjmxファイルにはどんな業務操作が何件記録されているか整理して」と依頼し、記録内容の棚卸しをさせる
• 複数jmxファイルの統合支援: あるパターンのシナリオ（例: ログイン〜A画面操作）と別のパターンのシナリオ（例: ログイン〜B画面操作）を1本の統合シナリオにまとめたい場合、それぞれのXMLブロックのうち必要な部分（ログイン部分の重複を除いた業務リクエスト群）を特定し、統合用のスクリプトを組んでもらう
• 固定値のパラメータ化: 記録時に埋め込まれてしまったID等の固定値を、CSVデータや変数に置き換えるスクリプトを組んでもらう（sessionKeyのような動的パラメータの変数化についてはsessionKey動的化のハマりどころで詳しく扱います）

実務で実際にAIエージェントにPowerShellスクリプトでjmxファイルの一括置換をやってもらった際、PowerShellスクリプト（.ps1）ファイル自体の文字コードが原因で日本語部分が文字化けし、置換がうまく動かないというトラブルに繰り返し遭遇しました。Windows PowerShell 5.1は、.ps1ファイルに日本語（マルチバイト文字）を含む場合、BOM付きUTF-8で保存しないと正しく解釈できないという制約があります。BOMなしのUTF-8で保存すると、システムの既定コードページ（日本語環境ではShift-JIS）として読み込まれてしまい、シングルクォートの対応がずれる、printfの書式指定が文字化けする、といった不可解なエラーが発生します。

AIエージェントにjmxファイルの一括編集用スクリプトを組んでもらう際は、「日本語を含むPowerShellスクリプトは必ずBOM付きUTF-8で保存すること」を明示的に指示しておくか、そもそもスクリプト内に日本語のリテラルを含めず外部データファイル（CSV/TSV等）から読み込む方式にしておくと、無用なトラブルを避けられます。

まとめ

• HTTP(S) Test Script Recorder（日本語版では「HTTPプロキシサーバ」）を使えば、ブラウザ操作をそのままJMeterのテストシナリオとして記録できる
• 記録前に「除外するパターン」で静的リソースを除外しておくのが重要（1行1パターンで登録すること）
• プロキシ設定・証明書設定・対象コントローラの指定など、記録がうまくいかない原因はいくつかのパターンに絞り込める。特にイントラネット環境ではローカルアドレスのプロキシバイパスに注意
• 記録後は不要なリクエストの削除・命名・Think Timeの調整といった整理作業が必要
• jmxファイルの整理・統合・パラメータ化はAIエージェントに任せると効率化できるが、PowerShellスクリプトの文字コード（BOM付きUTF-8）には注意が必要

シナリオが記録できたら、次は実際の業務利用パターンに近づけるための設計や、動的パラメータへの対応が必要になります。

• 次のステップ①: 本番アクセスログからのシナリオ設計 — 本番のアクセスログを使って、より実態に近い操作パターン・Think Timeを設計する方法
• 次のステップ②: sessionKey動的化のハマりどころ — 記録時に固定値として埋め込まれてしまう動的パラメータへの対処法

体系的にJMeterを学びたい場合は、記事冒頭で紹介したUdemy講座も参考にしてみてください。HTTP(S) Test Script Recorderの使い方だけでなく、負荷テスト全体の設計・実行・分析までカバーされています。

The post JMeterでシナリオを記録する実践ガイド（HTTP(S) Test Script Recorder） first appeared on CayTech Lab.

はじめに

Apache JMeterは、Webアプリケーションの負荷テスト・性能テストに使われるオープンソースツールです。「本番リリース前に、想定される同時アクセス数に耐えられるか確認したい」「特定の画面だけレスポンスが遅くなる原因を調べたい」といった場面で使われます。

筆者は実務でJavaアプリの画面負荷テストにJMeterを使った経験があり、この記事はその実体験をベースにしています。本記事はJMeter入門シリーズの1本目として、JMeterの基本概念とインストール・環境構築を扱います。実際にシナリオを記録して負荷をかけるところまでは踏み込まず、まず「JMeterとは何か」「手元の環境をどう整えるか」を押さえることがゴールです。

さらにこのシリーズでは、JMeterの操作そのものだけでなく、Claude Codeなどの AIエージェントと組み合わせて負荷テストを進めるとどう効率化できるかという観点も扱っていきます。JMeterはGUI操作が中心の伝統的なツールですが、テスト計画ファイル（JMX）の中身はXMLテキストであり、設定エレメントの追加手順やエラーメッセージの調査はAIエージェントとの相性が良い作業です。

この記事で分かること

• Apache JMeterとは何か、何ができるツールなのか
• JMeterとAIエージェントを組み合わせるメリット（シリーズ全体の導入）
• Windows環境でのインストール手順とJavaの動作要件
• テスト計画の基本的な階層構造（スレッドグループ・HTTPリクエストなど）
• シリーズ後続記事（シナリオ記録・アクセスログ分析・sessionKey動的化・トラブルシューティング）への案内

JMeterとは

Apache JMeterは、Apacheソフトウェア財団が開発するオープンソースの負荷テストツールです。Webアプリケーションを中心に、さまざまなプロトコルの性能・負荷テストを実施できます。

対応プロトコル

JMeterはHTTP/HTTPS以外にも幅広いプロトコルに対応しています。

• HTTP/HTTPS — Webアプリの画面テスト（本シリーズで扱うメインの用途）
• JDBC — DBに対する直接の負荷テスト
• FTP — ファイル転送テスト
• SOAP/REST — Web APIのテスト
• LDAP — ディレクトリサービスのテスト
• JMS — メッセージキューのテスト
• TCP — 汎用TCP通信のテスト

JMeterでできること

• 同時接続ユーザーのシミュレーション（数十〜数千ユーザー規模）
• シナリオベースのテスト（ログイン→画面操作→ログアウトという一連の流れを再現）
• レスポンスタイム・スループット（リクエスト/秒）の計測
• リアルタイムグラフ表示
• HTMLレポートの自動生成
• CSV/XML形式での結果出力

「Webサイトに一定数のアクセスが集中したときにどれくらいの応答時間になるか」「エラー率が上がり始めるアクセス数はどこか」といった問いに、実際に近い負荷をかけて答えを出せるのがJMeterの役割です。

なぜAIエージェント（Claude Code等）と組み合わせると効率的か

JMeterはGUIで設定エレメントをポチポチ追加していく操作が基本のツールです。一見AIエージェントとは縁が薄そうに見えますが、実務で使ってみると相性の良いポイントがいくつもあります。

特に効果を感じたのは、「GUI操作の手順」と「JMXファイルの中身（XML）」を両方参照しながら会話できる点です。JMeterのGUIだけでは「今どこで何が起きているか」を追いにくい場面でも、AIエージェントにファイルの中身を見せながら質問すると、設定の食い違いに気づきやすくなります。

このシリーズの後続記事（シナリオ記録・アクセスログからのシナリオ設計・sessionKeyの動的化・実際のトラブルシューティング体験記）では、この組み合わせを具体的にどう使ったかを紹介していきます。

インストール手順（Windows11対応）

Java実行環境の要件

JMeterはJavaで動作するツールのため、事前にJavaの実行環境（JRE または JDK）が必要です。

• 最低要件: Java 8以上
• 推奨: Java 17以降（JMeterの最新安定版はJava 17以降を前提にしていることが多いため）
• keytool（証明書関連のコマンド）を使う場合はJRE単体ではなくJDKが必要

Windowsのコマンドプロンプトまたは PowerShell で、以下のコマンドを実行してJavaのバージョンを確認します。

java -version

Javaが未インストール、またはバージョンが古い場合は、Eclipse Temurin（旧AdoptOpenJDK）などから最新のJDKをインストールしておきます。

補足：業務で使っているPCの場合、社内標準で古いJavaランタイムがインストール済みのケースもあります。その場合はJMeterのバージョン側をインストール済みのJavaバージョンに合わせて選ぶ（新しすぎるJMeterを使わない）という選択肢もあります。JMeterのバージョンはサーバー側のJavaバージョンに合わせる必要は必ずしもなく、手元の実行環境（クライアント側）のJavaバージョンに合わせるのが基本です。

JMeter本体のダウンロード・インストール

JMeterのインストールは、実行ファイルをインストーラーで入れる形式ではなく、ZIPファイルを展開するだけで完了します。

1. Apache JMeter公式サイトのダウンロードページにアクセスする
2. 「Binaries」セクションから apache-jmeter-x.x.x.zip をダウンロードする
3. 任意のフォルダ（例: C:\tools\jmeter）に展開する
4. bin フォルダ内の jmeter.bat をダブルクリックして起動する

C:\tools\jmeter\
├── bin\
│   ├── jmeter.bat          ← Windowsでの起動用バッチ
│   ├── jmeter               ← macOS/Linux用シェルスクリプト
│   └── ...
├── lib\
├── docs\
└── ...

起動すると、JMeterのGUI画面が立ち上がります。初回起動時は少し時間がかかることがありますが、エラーが出なければインストールは成功です。

日本語化（任意）

JMeterのGUIは初期状態では英語表示ですが、メニューから日本語に切り替えられます。

Options（オプション） > Choose Language（言語選択） > Japanese

日本語化すると各項目のラベルが日本語になり、初学者には扱いやすくなります。ただし、Web検索で見つかる情報や公式ドキュメントは英語表記が前提になっていることが多いため、慣れてきたら英語表示のまま使うのも一つの選択です。

動作確認

インストールが完了したら、起動時にエラーが出ていないかコンソールログ（jmeter.bat を実行したコマンドプロンプトの出力）を確認しておきます。特に以下のようなメッセージが出ていれば、Javaのバージョンとの紐付けも含めて正常に起動できています。

Created the tree successfully using ...
Starting the test @ ...

基本的な画面構成・テスト計画の階層構造

JMeterの操作を理解する上で最初に押さえておきたいのが、「テスト計画（Test Plan）」を頂点とした階層構造です。GUI画面の左ペインにはこの階層がツリー表示され、右クリックで各要素を追加していく操作が基本になります。

テスト計画 (Test Plan)
├── スレッドグループ (Thread Group)         ← 仮想ユーザー数・ランプアップ時間・ループ回数
│   ├── HTTPリクエスト (HTTP Request)       ← 実際に送信するリクエストの定義
│   ├── HTTPリクエスト ...
│   ├── タイマー (Timer)                    ← リクエスト間の待機時間
│   ├── アサーション (Assertion)            ← レスポンス内容の検証
│   └── 前処理/後処理                       ← 動的パラメータの抽出など
├── HTTPクッキーマネージャ                   ← セッション管理（Cookie）
├── HTTP ヘッダマネージャ                    ← 共通ヘッダの設定
├── CSVデータセット                         ← テストデータの外部ファイル読み込み
└── リスナー (Listener)                     ← 結果の表示・集計
    ├── 結果をツリーで表示
    ├── 統計レポート
    └── グラフ結果

スレッドグループ（Thread Group）

仮想ユーザーの振る舞いを定義する、最も重要なコンポーネントです。

HTTPリクエスト（HTTP Request Sampler）

実際にサーバーへ送信するリクエストを定義する要素です。プロトコル・サーバー名・ポート・メソッド（GET/POST）・パス・パラメータなどを設定します。

HTTPクッキーマネージャ

多くのWebアプリはログイン後のセッションをCookie（JSESSIONIDなど）で管理しています。HTTPクッキーマネージャを追加しておくと、JMeterがこのCookieを自動的に管理し、ログイン後のセッションを維持したまま複数リクエストを実行できます。ログインが必要なシステムを対象にする場合は、ほぼ必須の設定です。

タイマー（Timer）

実際のユーザーは画面を見ながら次の操作をするまでに間（Think Time）を置きます。この間隔を再現するのがタイマーです。

リスナー（結果の収集・表示）

注意点として、リスナーで結果を詳細表示しながらの実行（GUIモード）はJMeter自体がリソースを消費し、負荷テストの結果に影響を与えます。本番相当の負荷をかける段階では、GUIを使わないCUIモード（jmeter -n -t test.jmx -l result.jtl -e -o report/）での実行が推奨されます。この使い分けはシリーズ後続記事で詳しく扱います。

Javaの知識があると理解が早くなる場面

JMeter自体はJava製のツールであり、JavaのWebアプリ（Spring Bootなど）を対象にテストする場合、Java側の知識があると原因調査がスムーズになる場面が多くあります。例えばセッション管理の仕組みやCSRFトークンの扱いは、Javaのフレームワークの動作を理解しているかどうかで調査スピードが変わってきます。

これからJavaを体系的に学びたい・資格取得と合わせて基礎を固めたいという方は、以下の記事も参考にしてください。

👉 Java Silver（Oracle認定資格） おすすめUdemy講座比較【2026年版】

Udemy講座で体系的に学びたい方へ

ハンズオンで手を動かす前に、JMeterの操作全体を動画でまとめて学びたい場合は、以下の講座が候補になります。

Learn JMETER from Scratch on Live Apps -Performance Testing

👉 講座の詳細を見る（Udemyで確認）

8時間19分・48講義というボリュームで、JMeterの基本操作から実際のアプリケーションを使った負荷テストまでを一通り扱う入門〜初中級向け講座です。評価4.6・レビュー26,000件超、受講者数12万人超と、JMeter関連講座の中でも特に実績が豊富です。講義は英語ですが、Udemyの自動翻訳字幕（日本語含む）に対応しています。

メリット

• 受講者数12万人超・評価4.6という、この分野では際立った実績
• 「ゼロから」を掲げている通り、JMeter未経験でも迷わず追える構成
• スレッドグループ・リスナー・アサーション・コントローラー・タイマー・正規表現抽出など、本記事や後続記事で扱う要素を体系的にカバー

正直なデメリット

• 講義そのものは英語（自動翻訳字幕での視聴が前提になる）
• 実務の細かいユースケース（社内システム特有のセッション管理など）までは当然カバーしていないため、応用は自分で行う必要がある

こんな人におすすめ：この記事でJMeterの概念は掴めたので、次は動画で実際の操作画面を見ながら体系的に基礎を固めたい人。

このシリーズの構成

本記事はJMeter実務体験記シリーズの1本目（基礎編）です。実際にシナリオを記録して負荷をかけ、トラブルを解決していく後続記事もあわせてご覧ください。

• ① JMeterとは？基本概念とインストール・環境構築（本記事）
• ② JMeterでシナリオを記録する実践ガイド — HTTPプロキシサーバー機能を使った画面操作の記録方法
• ③ 本番アクセスログからのJMeterシナリオ設計 — 実際のアクセスログを参考にした、実態に近いシナリオの組み立て方
• ④ sessionKey動的化のハマりどころ — 正規表現抽出器を使ったセッション値の動的パラメータ化と、そこで起きたトラブル
• ⑤ AIエージェントとのトラブルシューティング体験記 — 実際に発生したエラーをAIエージェントと一緒に切り分けた記録

まとめ

JMeterは、Webアプリの同時アクセスをシミュレーションしてレスポンスタイムやエラー率を計測できる、無料のオープンソース負荷テストツールです。インストール自体はZIPを展開するだけとシンプルですが、テスト計画の階層構造（スレッドグループ・HTTPリクエスト・クッキーマネージャ・タイマー・リスナー）を理解しておくと、この後のシナリオ作成がぐっとスムーズになります。

次のステップとして、実際にブラウザ操作を記録してテストシナリオを組み立てる方法をシリーズ②で解説しています。あわせて参考にしてください。

👉 JMeterでシナリオを記録する実践ガイド

The post JMeterとは？基本概念とインストール・環境構築【Windows11対応】 first appeared on CayTech Lab.

はじめに

JMeterの基本的な使い方は JMeterとは？基本概念とインストール で、ブラウザ操作をシナリオとして記録する方法は シナリオ記録実践ガイド で解説しました。この2つを押さえれば、「動くシナリオ」は作れます。

ですが、負荷テストの担当者として実際に業務で向き合うと、もっと手前に大きな壁があることに気づきます。それは、**「そのシナリオ、本当に本番の使われ方に近いんですか？」**という問いです。

この記事では、筆者が実務のWebアプリケーション負荷テストで実際に行った、本番のApache access_logからアクセスパターンを抽出してシナリオ設計に反映させる工程を、AIエージェントとの実際のやり取りをベースに一般化してまとめます。検索してもほとんど情報が出てこない領域ですが、負荷テストの「結果の信頼性」を左右する、地味だが非常に重要な工程です。

社内情報の取り扱いについて：この記事で示すログ・画面名・IPアドレス・数値はすべて説明用のダミーデータです。実際に筆者が扱った本番データそのものは一切含まれていません。

この記事で分かること

• 「思いつきのシナリオ」がなぜ負荷テストの結果を無意味にしてしまうのか
• 本番のApache access_logからgrepで実アクセスパターンを抽出する具体的な手順
• 既存のExcel設計資料をAIエージェントに読み込ませてMarkdown化・再利用可能な形に構造化するアイデア
• 抽出したアクセスパターンをJMeterのスレッドグループ・Think Time設定に落とし込む流れ
• 本番ログを扱う上での注意点（アクセス権限・個人情報マスキング等）

1. なぜ「思いつきのシナリオ」では負荷テストが意味をなさないのか

負荷テストのシナリオを作るとき、つい「よく使われていそうな画面」を経験と勘で並べてしまいがちです。ログイン→一覧画面→検索→詳細→ログアウト、のような「いかにもありそうな流れ」です。

しかし、これには大きな落とし穴があります。負荷テストは「本番に近い負荷をかけて、本番で起きうる問題を事前に見つける」ことが目的です。シナリオが実際の使われ方とズレていれば、以下のような事態が起こります。

• 実際にはほとんど使われない画面に負荷をかけて「問題なし」と結論づけてしまう（本当のボトルネックを見逃す）
• 逆に、実際には少人数しか同時操作しない画面を過大な同時ユーザー数でテストし、不要な改修コストをかけてしまう
• 本番でよく発生する「検索条件を変えて何度も再検索する」といった連続操作を再現できず、DBキャッシュ効果込みの楽観的な結果しか得られない

筆者が担当した案件でも、最初は「画面ごとのアクセス数」を集計したExcelの調査資料（時間帯別・画面別のアクセス回数一覧）だけがあり、これをもとにシナリオを検討していました。ですが、AIエージェントに相談する中で次の指摘を受け、認識を改めることになりました。

画面アクセス数だけでは「その画面に何人がアクセスしたか」しか分かりません。負荷テストのシナリオ設計に必要なのは、それに加えて「操作順序」「操作間隔（Think Time）」「同時セッション数」の3つです。

つまり、集計済みのサマリーデータは「入口」に過ぎず、生のaccess_logまで遡って初めて実態に近いシナリオが組める、ということです。

2. 本番Apache access_logから実アクセスパターンを抽出する

ここからが本題です。本番のaccess_logは通常、数GB〜数十GB単位で溜まっているため、全量を持ち出すのは現実的ではありません。「何を知りたいか」から逆算して、必要な範囲だけをgrepで抜き出すのがポイントです。

2-1. access_logのフォーマットを確認する

まず対象システムのaccess_logがどのフォーマットで出力されているかを確認します。よくあるCombined Log Format＋レスポンスタイム付与のパターンだと、以下のようなイメージになります（以下はすべて説明用のダミーデータです）。

10.0.0.23 - - [10/Aug/2026:09:03:12 +0900] "GET /dummy-app/order/init.do HTTP/1.1" 200 15234 187
10.0.0.23 - - [10/Aug/2026:09:03:34 +0900] "POST /dummy-app/order/search.do HTTP/1.1" 200 8123 342
10.0.0.45 - - [10/Aug/2026:09:03:36 +0900] "POST /dummy-app/receiving/regist.do HTTP/1.1" 200 512 1204

この1行から読み取れる情報は多いです。

2-2. 抽出1：ピーク時間帯を丸ごと抜く（最優先）

まずは「その時間、同時に何人がどんなリクエストを投げていたか」の全体像を掴むため、ピークと思われる時間帯を丸ごと抽出します。

grep "10/Aug/2026:09:0" /var/log/apache2/access_log \
  > extract_access_log_0900-0910.log

日付・時刻の文字列パターンでgrepするだけなので単純ですが、「その時間帯に何件のリクエストが飛んでいたか」「業務系リクエストと静的リソース（css/js/img等）の比率」がすぐ見えるのが利点です。

2-3. 抽出2：アクティブなユーザー（IP）を特定する

次に、その時間帯で特にアクセス数が多かった送信元を洗い出します。awk と sort の組み合わせが定番です。

# 時間帯を絞ったログから、アクセス数の多い送信元IPトップ10を確認
grep "10/Aug/2026:09:" /var/log/apache2/access_log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

このコマンド1本で、「その時間帯にヘビーに操作していたユーザー」の見当がつきます。負荷テストのシナリオで再現すべき「代表的な操作パターン」の候補が、ここから見えてきます。

2-4. 抽出3：特定ユーザーの1セッションを追跡し、操作フローを再現する

トップに挙がったIPを対象に、そのユーザーの全リクエストを時系列で抜き出すと、1人のユーザーが実際にどの画面をどんな間隔で操作していたかが丸ごと再現できます。

grep "10.0.0.23" /var/log/apache2/access_log \
  | grep "09:0" \
  > extract_access_log_user_10.0.0.23_09h.log

これを整理すると、以下のような「実測の操作フロー」が得られます（数値・画面名はすべて説明用のダミーです）。

09:03:12  /dummy-app/menu/init.do        (187ms)  メインメニュー表示
09:03:20  /dummy-app/menu/clickButton.do (98ms)   メニュー選択
09:03:34  /dummy-app/order/init.do       (245ms)  発注入力画面 起動
09:03:52  /dummy-app/order/search.do     (342ms)  ★検索実行（1回目）
09:04:29  /dummy-app/order/search.do     (318ms)  ★検索実行（2回目・条件変更）
09:04:41  /dummy-app/order/regist.do     (1204ms) ★登録処理

このレベルまで見えると、「画面表示→検索を複数回繰り返す→条件を変えて再検索→最後に登録」という現実的な操作単位のブロックが見えてきます。タイムスタンプの差分を取れば、操作間隔（Think Time）も実測値として算出できます。

「Think Timeは何となく30秒にしておく」ではなく、実測で「検索操作の間隔はおよそ20〜40秒」という根拠が持てるようになります。

2-5. Windows端末での代替手段

grepやawkが使える環境がない場合や、ログサイズが大きすぎて素直なgrepでは処理が重い場合は、PowerShellの Select-String や Get-Content ＋オブジェクト集計でも同様の集計が可能です。抽出済みのログをAIエージェントに読み込ませて、リクエスト数の分単位推移・IPごとの集計・レスポンスタイムのパーセンタイル（50%ile、90%ile等）まで一気に統計化してもらう、という使い方も実務では有効でした。人力でExcelに貼り付けて集計するより圧倒的に早く、かつ「異常値（極端に遅いリクエスト）」にも気づきやすくなります。

3. 抽出データが教えてくれるシナリオ設計の勘所

生ログを解析すると、Excelのサマリーだけでは分からなかった以下のような情報が見えてきます。

• 書き込み系（登録・更新）処理の比率：DBへの書き込みを伴う処理は読み取り系より負荷が高いため、比率を正確に再現する価値が大きい
• 同一画面への「検索を繰り返す」実務パターン：1回の検索で終わらず、条件を変えて何度も検索するのが実際の使われ方であるケースは多い。シナリオも1回のリクエストで終わらせず、ループさせて再現すべき
• 異常に遅いリクエストの存在：CSV出力や大量データ処理など、一部のリクエストだけ突出して遅いケースがある。これは負荷テストのシナリオに含めるかどうかを意図的に判断する材料になる（含めないと本番相当の負荷にならないが、含めすぎるとテスト結果が偏る）

こうした「量」だけでなく「質」の情報が、実データを見ることで初めて手に入ります。

4. 既存のExcel設計資料をAIエージェントでMarkdown化・構造化する

もう一つ、実務で効果があった工程を紹介します。負荷テストのノウハウは往々にして過去の別システムでの実施手順がExcelにまとまっている形で社内に眠っています。今回のケースでも、別システムで過去に作成された「JMeterシナリオ作成手順書」（環境構築・シナリオ記録・実行方法などをシート分けしたExcel）がありました。

これをそのまま参照したかったのですが、AIエージェント（Kiro／Claude Code等のCLIエージェント）は標準ではExcelのバイナリ形式を直接読み取れません。ここで実務上有効だったアプローチが以下の2つです。

方法A：CSVに変換してから読み込ませる

Excel側で各シートを「CSV UTF-8」で書き出し、テキストファイルとして配置する方法です。シンプルですが、シートが多いと手間がかかります。

方法B：PowerShellのCOM経由でAIエージェントに直接読ませる

Windows環境であれば、PowerShellのCOMオブジェクト（New-Object -ComObject Excel.Application）を使ってExcelアプリケーションを裏で操作し、シートの内容をテキストとして取得できます。AIエージェントにこの手順を依頼すると、変換作業なしで元のExcelの構成（シート名・表形式）を保ったままMarkdownとして整理してもらえます。

実際には、以下のような構成で整理し直してもらいました。

# 対象システム JMeter負荷テスト手順書（Markdown化）

## 環境構築
- Java／JMeterのバージョン対応表
- インストール手順

## シナリオ作成時の注意点
- ループ実行しても問題ない操作かの確認
- 複数スレッドで同時実行しても問題ない操作かの確認
- 日付など、実施日に依存するパラメータの動的化方針

## シナリオ記録手順
- HTTPプロキシサーバーの設定〜記録〜復元までの手順

## 実行と計測
- スレッド数／Ramp-up／ループ回数の設定例
- 非GUIモードでのコマンドライン実行例

これにより、紙（Excel）でしか存在しなかった過去のノウハウが、AIエージェントが検索・参照できるMarkdown資料として再利用可能になり、新しい対象システム向けにカスタマイズする際の土台として使えるようになりました。「Excelは読めないから手打ちで転記する」という手間を省ける、という意味で地味に効果の大きい工程です。

補足：Excel内に埋め込まれた画像（スクリーンショットや図解）まではAIエージェントが自動で読み取れないケースが多く、その部分は別途チャットへの手動貼り付けなどで補完する必要がありました。表・テキスト情報の構造化は自動化できても、画像情報は人手を挟む前提で考えておくのが実務的です。

5. 抽出したアクセスパターンをJMeterシナリオに落とし込む

ここまでの解析結果を、実際のJMeterのスレッドグループ設定に反映していきます。

5-1. スレッド数・Ramp-up

「ユニークIP数＝同時アクセスユーザー数」ではない点に注意が必要です。ある時間帯にアクセスしてきたユニークIPが多くても、その全員が同じ瞬間に操作していたとは限りません。実測のリクエスト密度（1分あたりのリクエスト数）と1ユーザーあたりの操作ペースから逆算し、「同時にアクティブだったであろうセッション数」を見積もったうえでスレッド数を決めます。

例）ユニークIP数が多くても、実際に同時にアクティブなセッションは
    その6〜8割程度に収まることが多い、という前提で調整する

5.2. Think Time（Uniform Random Timer）

2-4で実測した操作間隔をもとに、JMeterの「Uniform Random Timer」の最小値・最大値を設定します。「検索操作の間隔は実測で20〜40秒だった」であれば、そのままレンジとして反映できます。固定値（Constant Timer）ではなく、実測のばらつきをレンジで表現できるUniform Random Timerの方が、実際のユーザー行動に近いゆらぎを再現できます。

5-3. 操作比率の再現（Throughput Controller / 重み付け）

抽出したログから算出した「書き込み系〇%・照会系〇%・画面遷移系〇%」といった構成比を、JMeterの「Throughput Controller」や、コントローラを複数用意して実行頻度に重み付けする方法で再現します。1本のシナリオを全スレッドが同じ順序でなぞるのではなく、実測の比率に応じて「このスレッドは照会だけを繰り返す」「このスレッドは登録中心」といったユーザータイプ別のシナリオを複数用意し、それぞれの比率でスレッドを配分する構成が実態に近づきます。

5-4. テストデータのバリエーション

実測ログから、同じ処理でも複数のユーザーが異なる検索条件・入力データで操作していることが分かります。CSV Data Set Configで複数パターンのテストデータを用意し、スレッドごとに異なる値を使わせることで、DBキャッシュだけが効いてしまう非現実的に速い結果を避けられます。

6. 実務での注意点：本番ログの取り扱い

本番のaccess_logやアプリケーションログには、IPアドレス・ユーザーID・場合によっては入力データそのものが含まれます。負荷テストのために便利だからといって無造作に扱ってよいものではありません。実務では最低限、次の点を徹底しました。

• アクセス権限の確認：本番ログの取得・閲覧は、情報システム部門などログへの正式なアクセス権限を持つ担当者が行い、許可されたメンバー以外に共有しない
• 必要な範囲だけを抜き出す：全量をコピーせず、「対象時間帯」「対象IP」など目的に応じた範囲だけをgrepで抽出する（2章の手法はこの観点でも有効）。ログの持ち出し自体を最小化できる
• 作業後の削除：解析用に一時的に抽出したログファイルは、シナリオ設計が完了したら削除する。ローカル端末や共有フォルダに残さない
• 記事・資料化する際のマスキング：この記事のように社外に知見を共有する場合は、IPアドレス・画面名・URLパス・ユーザーIDなどをすべてダミーデータに置き換える（実データの数値そのものを転記しない）
• 社内の情報管理規程の確認：本番ログの取り扱いに関するルールは組織によって異なるため、着手前に情報管理部門・上長に確認を取る

「実データに近づけたシナリオを作る」ことと「実データをそのまま扱う」ことは別問題です。目的を達成するのに必要な情報の粒度まで抽象化・匿名化してから手元に置く、という意識が重要になります。

まとめ

• 画面アクセス数の集計だけでは、負荷テストのシナリオ設計には情報が不足している。操作順序・Think Time・同時セッション数まで踏み込む必要がある
• 本番のApache access_logは、①時間帯 → ②アクティブユーザー → ③1セッションの操作フロー、という順に絞り込んでgrepすれば、現実的なボリュームで実アクセスパターンを抽出できる
• 過去のExcel設計資料は、AIエージェント（PowerShell COM経由での読み取りなど）を使ってMarkdown化しておくと、次のプロジェクトでも再利用できる資産になる
• 抽出したデータは、スレッド数・Think Time・操作比率・テストデータのバリエーションという形でJMeterシナリオに反映する
• 本番ログはアクセス権限・保管期間・マスキングを徹底して扱う。実データに近づけることと、実データをそのまま持ち出すことは別問題

「思いつき」ではなく「実測」に基づいたシナリオを組めるようになると、負荷テストの結果そのものへの説得力が大きく変わります。

シナリオが実データに近づいてくると、次にぶつかるのが「JSESSIONIDなど動的な値をどう扱うか」という問題です。次の記事では、このsessionKeyの動的化でハマったポイントを実体験ベースで解説します。

👉 次のステップ：sessionKey動的化のハマりどころ

まだ読んでいない方は、基礎編もあわせてどうぞ。

• JMeterとは？基本概念とインストール
• シナリオ記録実践ガイド

The post 本番アクセスログから現実的な負荷テストシナリオを設計する方法 first appeared on CayTech Lab.