負荷テストの準備、Proxyの壁で止まっていませんか？
JMeterでシナリオを作ろうとしたとき、こんな問題にぶつかった経験はないでしょうか。
- 社内プロキシとJMeter Proxyが競合して通信を記録できない
- HTTPS環境でSSL証明書エラーが解消できず先に進めない
- 自動記録ツールが現代のWebアプリに対応しておらず、記録が不完全になる
これらの問題をまるごと回避できるのが、ChromeのDevTools（開発者ツール）だけでJMeterシナリオを手動作成するアプローチです。Proxyを一切使わないため環境依存のトラブルとは無縁で、SPA（シングルページアプリケーション）や独自認証フローにも対応できます。
この記事を読むと、DevToolsで通信を読み解き、CSRFトークンなどの動的パラメータも扱える実践的なシナリオを自力で作れるようになります。HTTP通信への理解も深まるため、テスト精度の向上や障害時の原因特定にも直結します。
シナリオ作成3つの方法──手動作成を選ぶ判断基準
JMeterのシナリオ作成手段には主に3つあります。それぞれの特徴と使い分けの基準を整理しておきます。
| 方法 | 概要 | 難易度 | 向いているケース |
|---|---|---|---|
| ①手動作成（DevTools活用） | 通信を読み解き手動で構築 | 中〜高 | 社内Proxy環境・HTTPS・SPAなど複雑なシステム |
| ②JMeter Proxy利用 | 操作を自動記録してインポート | 低〜中 | シンプルな構成のシステム。ただし社内Proxyと競合しやすい |
| ③Badboy等の記録ツール | 専用ツールで記録しインポート | 低 | 古いシステム向け。現代のWebアプリへの対応は限界あり |
②③は手軽ですが、環境によっては動かない・認証フローが正確に取れないというリスクがあります。手動作成は工数こそかかるものの、どんなシステムにも対応できる汎用性が最大の強みです。
STEP 1：DevToolsを起動して記録を準備する
必ず操作を始める前にDevToolsを開いておきましょう。後から起動すると最初の通信を取りこぼします。
- Chromeを開き、F12（Macは Command + Option + I）でDevToolsを起動
- 「Network」タブをクリック
- 録画ボタン（●）が赤く点灯していることを確認（デフォルトでON）
- 「Preserve log」にチェックを入れる（ページ遷移後もログが消えなくなる）
- 「Disable cache」にもチェックを入れる（キャッシュを使わず全リクエストを確実に記録）
STEP 2：テストしたい操作を実施する
DevToolsを開いたまま、負荷テストで再現したい操作を本番と同じ手順で実施します。
- ログイン（IDとパスワードを入力して送信）
- フォーム送信・検索・ファイルアップロードなど
- 主要ページへの画面遷移
操作が終わると、NetworkタブにHTTPリクエストのログが一覧表示されます。これがシナリオの元ネタです。
STEP 3：通信を分析し、JMeterに入れるリクエストを選ぶ
基本の見方
フィルターバーで「Fetch/XHR」を選ぶと、API通信だけに絞り込めて見やすくなります。リクエスト名をクリックすると右ペインが開き、以下の情報を確認できます。
| タブ名 | 確認する内容 |
|---|---|
| Headers | Request URL・HTTPメソッド（GET/POST）・リクエストヘッダー |
| Payload | POSTリクエストで送信しているパラメータ（Body） |
| Response | レスポンス内容（動的な値の確認やアサーション設定に使う） |
どのリクエストをJMeterに入れるべきか？
すべてのリクエストを再現する必要はありません。以下の基準で取捨選択しましょう。
- 入れるべきもの：ログイン・フォーム送信・検索など、ユーザー操作に直結するAPIリクエスト
- 除外してよいもの：画像・CSS・JavaScriptなどの静的リソース（フィルターで「JS」「CSS」「Img」を非表示にすると把握しやすい）
- 注意が必要なもの：トークン取得やセッション初期化など、後続リクエストの前提となるリクエストは必ず含める
時短テクニック：HARファイルへのエクスポート
Network一覧の空白部分を右クリック→「Save all as HAR with content」で、全通信をJSON形式（.har）として書き出せます。テキストエディタで開くとURLやパラメータを横断的に確認でき、入力作業の効率が大幅に上がります。
STEP 4：JMeterにリクエストを再現する
STEP 3で確認した内容をもとにJMeterを設定します。まず以下のコンポーネント構成を作りましょう。
Thread Group
├ HTTP Request Defaults
├ HTTP Cookie Manager
├ HTTP Header Manager
├ HTTP Request（例：ログインページGET）
├ HTTP Request（例：ログインPOST）
├ HTTP Request（例：メインページGET）
├ Response Assertion
└ View Results Tree（デバッグ用・本番実行前に無効化）各コンポーネントの追加手順と役割
- HTTP Request Defaults：Thread Groupを右クリック→「Add」→「Config Element」→「HTTP Request Defaults」。Server Name（ドメイン）とProtocol（https等）をここに集約すると、個別リクエストの設定が最小限になり保守しやすくなります。
- HTTP Cookie Manager：同じく「Config Element」→「HTTP Cookie Manager」。Thread Group直下に必ず追加してください。これがないとログイン後のセッションが維持されず、後続リクエストがすべて認証エラーになります。
- HTTP Header Manager：「Config Element」→「HTTP Header Manager」。DevToolsのHeadersタブで確認した
Content-Type: application/jsonなどを設定します。APIリクエストでは特に重要です。 - HTTP Request：「Sampler」→「HTTP Request」。STEP 3で確認したURL・メソッド・パラメータを入力します。
STEP 5：動的パラメータを変数として処理する
CSRFトークンやセッションIDは毎回変わるため、値をハードコードするとテストが通りません。前のレスポンスから値を取得して、次のリクエストに動的に渡す仕組みが必要です。
設定例：ログインページからCSRFトークンを取得する
「ログインページGET」リクエストを右クリック→「Add」→「Post Processors」→「Regular Expression Extractor」を追加します。
| 項目 | 設定値 |
|---|---|
| Name of created variable | csrf_token |
| Regular Expression | "csrf_token"\s*:\s*"([^"]+)" |
| Template | $1$ |
| Match No. | 1 |
次のリクエストのパラメータ値欄に ${csrf_token} と記述するだけで、取得した値が自動で埋め込まれます。
JSONレスポンスにはJSON Extractorが便利
レスポンスがJSON形式の場合は「JSON Extractor」（「Post Processors」→「JSON Extractor」）を使いましょう。JSONPath（例：$.data.csrf_token）で値を指定でき、正規表現を書くより直感的でミスも減ります。JMeter 5.x系以降であれば標準搭載されています。
まとめ：5ステップで身につく、環境を選ばないシナリオ作成力
| ステップ | やること | ポイント |
|---|---|---|
| STEP 1 | DevToolsをPreserve log ONで起動 | 操作前に開いておくことが必須 |
| STEP 2 | テストしたい操作を実施 | 本番と同じ手順で漏れなく実行 |
| STEP 3 | 通信を分析し対象リクエストを選ぶ | 静的リソースは除外。HARエクスポートで効率化 |
| STEP 4 | Cookie Manager・Header Manager込みでJMeterに再現 | メニュー操作手順を確認しながら追加する |
| STEP 5 | 動的な値はエクストラクターで取得・変数で渡す | JSONレスポンスにはJSON Extractorが便利 |
Proxy自動記録は手軽ですが、環境によっては動かないことも多く、複雑な認証フローには限界があります。手動作成をマスターすれば、どんなシステムでも・どんな環境でもシナリオを組める自走力が手に入ります。まずはSTEP 1のDevTools起動から、今日試してみてください。
