はじめに

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.