LoadRunnerとは、大量のユーザーアクセスを模擬してシステムの性能を測定するための商用の負荷テストツールです。Webアプリケーションや業務システム、API、ネイティブアプリケーションなどに対して、実際のユーザーが操作しているかのようなリクエストを大量に送り、システムがどの程度の負荷に耐えられるかを調べる目的で利用されます。ここでいう「負荷」とは、同時アクセス数やトランザクション数、リクエストの頻度など、システムにかかる処理量全体を示す概念です。LoadRunnerは、テストの設計から実行、結果の分析までを一連の流れとしてサポートする総合的なツールとして位置付けられます。
LoadRunnerとは何か：負荷テストツールとしての役割と特徴
LoadRunnerの大きな特徴の一つは「仮想ユーザー（Virtual User）」という考え方です。仮想ユーザーとは、実在する人間の代わりに操作を行うソフトウェア上のユーザーを指します。たとえば、100人、1,000人といった多数のユーザーが同時にログインし、画面を遷移し、検索や登録操作を行う状況を、仮想ユーザーを使って再現します。仮想ユーザーはスクリプトと呼ばれる手順書に沿って動作し、どの画面で何を入力し、どのボタンをクリックするのかといった一連の操作を自動で実行します。
LoadRunnerでは、負荷テストの工程を支えるいくつかのコンポーネントが用意されています。代表的なものとして、ユーザー操作を記録してスクリプトを作成するための「VuGen（Virtual User Generator）」、テスト全体の負荷パターンを設計して実行する「Controller」、実行結果をグラフや数値として詳細に分析する「Analysis」があります。これらのコンポーネントを組み合わせることで、「どのようなシナリオで」「どれくらいのユーザー数で」「どのくらいの時間負荷をかけるか」といったテスト条件を細かく制御できます。
LoadRunnerが現場でよく利用される理由の一つは、対応しているプロトコルや技術の幅が広いことです。プロトコルとは、通信のルールや形式を定めたもののことで、HTTPやHTTPS、WebSocket、データベース接続、メッセージキューなど、さまざまな種類があります。LoadRunnerはこれらの多様なプロトコルに対応しているため、Webアプリケーションだけでなく、業務システムやバックエンドのサービスなども含めた総合的な負荷テストを実施しやすい特性があります。複雑な企業システム全体の性能を確認したい場合にも適したツールです。
さらに、LoadRunnerは大規模な負荷をかけることを前提として設計されています。数百、数千、場合によってはそれ以上の仮想ユーザーを同時に動作させる構成を取りやすく、複数の負荷生成マシンを組み合わせて高い負荷を分散して発生させることができます。これにより、実際の本番環境で起こり得るピークアクセスに近い状況をテスト環境で再現できます。特に、金融系や大規模ECサイトなど、アクセス集中が顕著なシステムの性能確認において、このスケールの大きさが重要な意味を持ちます。
LoadRunnerは、単に負荷をかけるだけでなく、結果の計測と可視化にも力を発揮します。テスト中には、レスポンス時間（リクエストからレスポンスが返るまでの時間）やスループット（単位時間あたりに処理されたトランザクション数）、エラー率などの指標がリアルタイムで収集されます。テスト後には、Analysisコンポーネントを用いて、これらのデータをグラフや表として確認できます。メトリクスと呼ばれるこれらの数値は、性能の良し悪しを客観的に判断するための材料であり、LoadRunnerはそれらを多角的に表示する仕組みを提供します。
また、LoadRunnerではシナリオの制御にも柔軟性があります。たとえば、テスト開始直後にいきなり全ユーザーを動かすのではなく、時間をかけて徐々に仮想ユーザー数を増やしていく「ランプアップ」や、一定のユーザー数を維持する「定常負荷」、テスト終了に向けて負荷を減らしていく「ランプダウン」といったパターンを設定できます。これにより、「アクセスがだんだん増えていくときの挙動」や「ピーク時の安定性」を意図通りに検証しやすくなります。
スクリプト面では、ユーザー操作の記録・再生だけでなく、データ駆動テストと呼ばれる手法もサポートしています。データ駆動テストとは、外部のデータファイル（例：CSVやテキスト）に複数のユーザーIDや検索条件などを用意しておき、テスト実行時にそれらを順番に読み込んでテストを行う方法のことです。これにより、同じ操作パターンであっても、実際のユーザーに近い多様な入力データを使った負荷テストが可能になります。単一の固定データだけでテストした場合には見えない問題を発見できる点が特長です。
企業システムの現場では、「性能要件を満たしているかどうか」を証明するために、LoadRunnerによるテスト結果をエビデンスとして利用することがあります。エビデンスとは、テストを確かに実施し、その結果がどのようなものであったかを示す証拠資料のことです。LoadRunnerのAnalysisが出力するグラフや集計結果をレポートとしてまとめることで、関係者に対して客観的な性能評価の根拠を提示できます。このような背景から、LoadRunnerは品質保証や性能検証のプロジェクトにおいて、よく採用されるツールの一つになっています。
LoadRunnerの役割や特徴を理解しておくことで、単にツールの操作を覚えるだけでなく、「どのようなシステムに対して」「どのようなテストを構成するべきか」という設計段階の判断にも活用しやすくなります。
負荷テストの目的と基本概念：LoadRunnerで理解する性能評価の考え方
負荷テストの目的は、一言でいうと「システムが想定した利用状況の中で、どれくらい安定して動作できるかを数値で確認すること」です。ふだん開発中に行う単体テストや結合テストは、主に「正しく動くかどうか」という機能面を確認しますが、負荷テストでは「速さ」「耐久性」「安定性」といった性能面に焦点を当てます。利用者が増えたときに画面の表示が極端に遅くなったり、エラーが多発したりしないかを事前に把握し、必要であれば改善することが負荷テストの大きな狙いになります。
負荷テストでよく出てくるキーワードとして、「レスポンス時間」と「スループット」があります。レスポンス時間とは、ユーザーが操作してから結果が返ってくるまでの時間のことです。画面表示や検索結果、登録完了の応答などがこれにあたります。スループットとは、一定時間あたりに処理できるリクエスト数やトランザクション数のことで、たとえば「1秒あたり50件のログイン処理をさばける」といった指標になります。これらの値を測定することで、システムの「速さ」や「処理能力」を客観的に評価できます。
負荷テストにはいくつかの基本的な種類があります。代表的なものとして、以下のような分類があります。
- ロードテスト：想定される通常〜ピーク時の負荷をかけ、性能要件を満たしているかを確認するテスト
- ストレステスト：あえて想定以上の高負荷をかけ、どこで限界を迎えるか、限界時にどのような挙動をするかを確認するテスト
- スパイクテスト：短時間で急激に負荷を上げ、急なアクセス増加に対して耐えられるかを確認するテスト
- 耐久テスト（ソークテスト）：中程度の負荷を長時間かけ続け、メモリリークやリソース枯渇などの問題が発生しないかを確認するテスト
これらはどれも「システムに負荷をかける」という点では同じですが、「目的」と「負荷のかけ方」が少しずつ異なります。LoadRunnerは、これらのテストをシナリオとして柔軟に組み立てられるツールですので、目的に応じて負荷パターンや時間配分を設計することが重要になります。
性能評価を行ううえで欠かせないのが、「性能要件」を事前に決めておくことです。性能要件とは、「画面Aは3秒以内に表示されること」「同時ユーザー数100人のときもエラー率1％未満であること」といった、性能に関する目標値のことです。これが決まっていないと、負荷テストをしても「結果が良いのか悪いのか」が判断しにくくなります。LoadRunnerでテストを行う際にも、あらかじめ「どの操作に対して、どのくらいのレスポンス時間ならOKなのか」「エラー率は何％まで許容するのか」といった基準を関係者と共有しておくことが大切です。
負荷テストの基本概念として、「仮想ユーザー」という考え方も重要です。仮想ユーザーは、人間の代わりにツールが動かすユーザーで、実際のブラウザやクライアントアプリの操作を模倣します。LoadRunnerでは、この仮想ユーザーに対して操作手順をスクリプトとして定義し、そのスクリプトを大量に並行実行させることで、同時アクセスを再現します。ここで大切なのは、「仮想ユーザー数」だけでなく、「どのような操作をどれくらいの頻度で行うか」というシナリオ設計です。実際の利用状況に近い操作パターンを再現できなければ、テストで得られた結果も実運用とズレてしまいます。
性能評価の考え方としては、「単一ポイントではなく傾向を見る」という視点も持っておくとよいです。たとえば、1回だけテストしてレスポンス時間が目標値を満たしていたとしても、それがたまたまサーバーの負荷が低いタイミングだった可能性があります。負荷レベルを変えながら複数回テストを行い、負荷が増えるにつれてレスポンスがどのように変化するか、エラー率がどこから上がり始めるかといった「変化の流れ」を見ることで、より信頼性の高い評価ができます。LoadRunnerは、負荷の段階的な増減をシナリオとして設定できるため、このような傾向分析にも適しています。
また、性能評価では「サーバー側のリソース」と「ユーザー視点の体感」を両方考慮することが求められます。リソースとはCPU使用率、メモリ使用量、ディスクI/O、ネットワーク帯域といった、サーバーがどれだけ忙しいかを示す指標です。たとえレスポンス時間が許容範囲内でも、CPUが常にほぼ100％になっているような状態では、少し負荷が増えただけで急にレスポンスが悪化するリスクがあります。LoadRunner自体はリソース監視ツールではありませんが、他の監視手段と組み合わせてテストを実施することで、「負荷に対するシステムの余裕度」を確認しやすくなります。
一方で、ユーザー視点の体感というのは、「画面遷移がスムーズか」「操作していてストレスを感じないか」といった観点です。これは純粋な数値では表しにくい面もありますが、一般的にはレスポンス時間が1秒以内であれば快適、3秒以内であれば許容範囲とされることが多いです。性能要件を決めるときには、こうした一般的な目安も参考にしつつ、自社サービスの特性やユーザーの期待値を踏まえて基準を調整していきます。
負荷テストの結果は、単に「合格・不合格」を決めるためだけのものではなく、「どこを改善すると、どれくらい性能が向上するか」を検証するための材料でもあります。LoadRunnerによるテストを一度行い、ボトルネックを改善したあとに再度テストを実施することで、改善の効果を定量的に確認できます。このサイクルを繰り返すことで、システムの性能を段階的に引き上げていくことが可能になります。
このように、負荷テストは単なる「高負荷をかけて壊れるかどうかを見るテスト」ではなく、「性能要件を満たしているかを数値で確認し、改善サイクルに役立てるための活動」であり、その考え方を理解したうえでLoadRunnerを使うことで、より意味のある性能評価が行いやすくなります。
LoadRunnerのインストール手順とテスト環境の準備
LoadRunnerを利用して負荷テストを行うためには、ツールのインストールだけでなく、テストに適した環境を事前に整えておくことが大切です。ここでは、初めてLoadRunnerに触れる方でもイメージしやすいように、「構成を理解する」「インストールの流れ」「テスト環境として意識すべきポイント」という順番で整理してご説明します。
まず、LoadRunnerがどのような構成で動作するツールなのかを把握しておくことが重要です。LoadRunnerには大きく分けて、次のような役割を持つコンポーネントがあります。
- VuGen（Virtual User Generator）：仮想ユーザー用のスクリプトを作成・編集するツール
- Controller：負荷テスト全体のシナリオを設定し、テストの実行や監視を行うツール
- Load Generator：実際に負荷（リクエスト）を発生させるためのコンポーネント
- Analysis：テスト結果を集計・可視化し、グラフや統計情報として表示するツール
学習や小規模な検証であれば、1台のマシンにこれらをまとめてインストールして利用することも多いです。一方、本格的な負荷テストでは、ControllerやVuGenを使うマシンと、負荷を出すLoad Generator用のマシンを分け、複数台で構成することがあります。この構成を理解しておくと、「どこに何をインストールすればよいか」が整理しやすくなります。
次に、インストールを行うマシンの前提条件を確認します。LoadRunnerはクライアントツールとして動作するため、ある程度の性能を持ったWindows環境を用意するのが一般的です。CPUやメモリ、ディスク空き容量などの要件はバージョンごとに異なりますが、負荷テストではツール自体にもリソースが必要になるため、推奨スペックを意識してマシンを準備します。特にLoad Generatorを兼ねる場合は、多数の仮想ユーザーを動かすことを想定し、CPUコア数とメモリ容量には余裕を持たせると安定しやすくなります。
インストール作業の流れとしては、一般的に次のようなステップで進めます。
- インストーラの入手
- セットアッププログラムの起動
- インストールするコンポーネントの選択（VuGen / Controller / Analysis / Load Generator など）
- インストールディレクトリやショートカット設定の確認
- インストール完了後の動作確認
コンポーネント選択では、学習や検証用途であれば、VuGen・Controller・Analysisの3つをメインマシンにインストールし、必要に応じて同じマシンをLoad Generatorとしても利用する構成が分かりやすいです。本番に近い構成を意識する場合は、Controller用マシンと1台以上のLoad Generator用マシンを用意し、それぞれに必要なコンポーネントだけをインストールします。
インストール後は、まずVuGenやControllerが起動できるかを確認します。VuGenではサンプルプロトコルを選択し、ダミーのスクリプトを新規作成できるかを試します。Controllerでは、新しいシナリオを作成し、空の構成でもよいのでシナリオファイルを保存できるかを確認します。Analysisも起動だけ行い、画面が正しく表示されることをチェックします。これらが問題なく動作するようであれば、インストール自体は概ね成功していると考えられます。
テスト環境の準備という観点では、「LoadRunner側の環境」と「テスト対象システム側の環境」の両方を意識する必要があります。LoadRunner側では、以下のような点を整えておきます。
- テスト用のユーザーアカウントやテストデータの準備（ログインID、テスト用商品データなど）
- テスト結果やログファイルの出力先ディレクトリの整理（ディスク容量の確保も含む）
- ControllerとLoad Generatorのマシン同士がネットワーク上で通信できることの確認
- テスト実行時の時刻同期（マシン間で時刻が大きくずれていると、ログ解析がしにくくなるため）
一方、テスト対象システム側では、負荷テスト用の環境をできるだけ本番環境に近い構成で用意することが望ましいです。たとえば、本番と同じ台数・同じ設定のWebサーバー、同等スペックのデータベースサーバーなどです。完全に同じ構成を準備できない場合でも、CPUやメモリ、OSのバージョン、ミドルウェア（Webサーバーやアプリケーションサーバー）の設定が大きく異なりすぎないように意識します。性能評価の結果は「環境に強く依存する」ため、環境の差が大きいと、本番での挙動を正しく予測しにくくなります。
ネットワーク設定も重要な要素です。ControllerからLoad Generator、Load Generatorからテスト対象サーバーへの通信経路に、意図しないファイアウォール設定やプロキシ設定が入っていないかを確認します。特定のポートが閉じているとLoadRunner同士の通信がうまくいかず、仮想ユーザーが正しく起動しないことがあります。また、VPN経由の接続や低速な回線を利用している場合、テスト結果にネットワーク遅延の影響が大きく出ることがあるため、可能であればテスト環境内のネットワークに直接接続できる構成を検討します。
テスト環境の準備で見落としがちな点として、「監視環境の準備」があります。負荷テストは、単にLoadRunner側でレスポンス時間やエラー率を測るだけではなく、サーバー側のCPUやメモリなどのリソース状況も合わせて確認することで、ボトルネックを特定しやすくなります。そのため、OS標準の監視機能や、既存の監視ツールなどを使って、負荷テスト中にサーバーリソースの推移を確認できるようにしておきます。監視結果はLoadRunnerのテスト結果と合わせて分析するため、時間帯や指標が後から照らし合わせやすいように設定しておくことが重要です。
最後に、テストデータのリセットや環境初期化の手順も、テスト環境準備の一部として整備しておきます。負荷テストでは、同一のユーザーIDやデータを何度も使い回すと、想定外のエラーが出たり、実運用とは異なる状態になったりすることがあります。そのため、テスト実行前にデータベースを特定の状態に戻す手順や、テスト後に不要なデータを整理する方法を決めておきます。これにより、複数回のテストを安定して繰り返すことができ、改善前後の結果を公平に比較しやすくなります。
このように、LoadRunnerのインストールとテスト環境の準備は、ツールのセットアップだけでなく、ネットワーク・サーバー・テストデータ・監視体制など、周辺要素も含めて整えることが重要になります。
LoadRunnerシナリオ作成の基本：仮想ユーザーと操作記録の仕組み
LoadRunnerで負荷テストを行ううえで、シナリオ作成はとても重要なステップになります。ここでいうシナリオとは、「仮想ユーザーがどのような順番で、どの操作を、どれくらいの頻度・人数で行うのか」を定義した設計図のようなものです。シナリオの質が低いと、いくらたくさん負荷をかけても、実際のユーザー行動からかけ離れたテストになってしまい、得られた結果の信頼性が下がってしまいます。そのため、仮想ユーザーの考え方と、操作記録（スクリプト作成）の仕組みを正しく理解しておくことが大切です。
LoadRunnerの仮想ユーザーは、VuGen（Virtual User Generator）で作成したスクリプトをもとに動作します。VuGenでは、実際のブラウザやクライアントアプリケーションの操作を記録し、その操作をスクリプトとして保存します。記録機能を使うことで、手作業で細かくコードを書くことなく、実際のユーザー操作に近い手順を自動的にスクリプト化できます。たとえば、Webアプリケーションに対して、トップページ表示→ログイン→検索→詳細表示→ログアウトという一連の操作を実際に行うと、その背後で通信されているリクエストが記録され、仮想ユーザーが再生できる形になります。
VuGenで操作記録を行う際には、まず対象とするプロトコルを選択します。プロトコルとは、通信のルールや形式を表すもので、HTTP/HTTPS、Webアプリケーション用のWeb HTTP/HTML、または特定のクライアント・サーバーアプリケーション用のプロトコルなどがあります。一般的なWebシステムであれば、Web関連のプロトコルを選ぶことが多いです。適切なプロトコルを選択することで、リクエストとレスポンスの内容が正しく記録され、後から編集やパラメータ化がしやすくなります。
操作記録が完了すると、スクリプトには多数のHTTPリクエストや関数呼び出しが並んだコードが生成されます。ここで重要になるのが、「トランザクション」と呼ばれる区間の定義です。トランザクションとは、性能を測りたい処理の単位を意味します。たとえば「ログイン処理」「商品検索」「カートへの追加」など、ユーザー操作のひとまとまりをトランザクションとしてマークします。LoadRunnerはトランザクションごとにレスポンス時間を集計するため、どこをトランザクションとして区切るかは、後の性能分析に大きな影響を与えます。
もう一つ重要な概念が「シンクタイム（Think Time）」です。シンクタイムとは、ユーザーが画面を見て考えたり、入力したりする時間を表現するための待ち時間のことです。実際の人間は、画面が切り替わるたびにすぐ次のボタンを押すわけではなく、内容を確認したり項目を入力したりするためにある程度の時間を使います。もしシンクタイムをすべて0秒にしてしまうと、人間離れした高速な操作となり、必要以上に厳しいテスト条件になってしまいます。VuGenでは、記録時に操作間の時間も一緒に記録されるため、それをどの程度反映するかを設定することで、現実に近い操作間隔を再現できます。
シナリオ作成では、「データの多様性」を確保するために、パラメータ化という機能を使うことも重要です。パラメータ化とは、ユーザーIDや検索キーワードなどを固定値ではなく、外部ファイルや定義済みのリストから取り出して、仮想ユーザーごと・実行ごとに異なる値を使うようにする仕組みです。たとえば、ログイン処理のスクリプトの中で、IDやパスワードを複数用意しておき、各仮想ユーザーに異なるIDを割り当てることで、より実際の利用状況に近いテストを行えます。同じIDだけでテストしていると、キャッシュの影響などで実運用とは違う性能になってしまう場合があり、パラメータ化はそれを避けるための重要な工夫になります。
さらに、LoadRunnerのシナリオでは、仮想ユーザーの「挙動パターン」も意識して設計します。具体的には、以下のような観点があります。
- どの操作をどの順番で行うか（ページ遷移の流れ）
- どの操作をどれくらいの頻度で行うか（例：検索操作が全体の50％など）
- 何人の仮想ユーザーが同時に同じシナリオを実行するか
- シナリオ開始時にユーザー数をどのように増やしていくか（ランプアップ）
これらをController上で設定し、VU数（仮想ユーザー数）や実行時間、スケジュールを定義します。単純に「全員が同じ操作を繰り返す」だけでなく、「一部は閲覧だけ」「一部は頻繁に検索」「一部は購入まで進む」といった利用パターンを複数用意して組み合わせることで、より現実に近いシナリオを再現できます。
シナリオ作成時に注意したいポイントとして、「動的値の扱い」があります。動的値とは、セッションIDやトークン、日付やランダムな文字列など、実行のたびに変化する値のことです。これらを正しく処理できないと、仮想ユーザーが途中でエラーになり、テストが正しく進行しません。LoadRunnerでは、レスポンスから動的な値を抜き出して変数として保持し、その値を次のリクエストに挿入する「コリレーション（値の関連付け）」という仕組みがあります。コリレーションを適切に行うことで、ログイン後のセッション維持や、CSRFトークンなどを必要とする最新のWebアプリケーションにも対応できます。
シナリオを完成させたあとには、必ず「単体実行」と「少人数でのテスト実行」を行い、スクリプトが正しく動作するかを確認します。単体実行では、1ユーザーだけを対象にスクリプトが最後までエラーなく動くかをチェックします。続いて、少人数（例：5〜10ユーザー）でシナリオを実行し、負荷が小さい状態でも安定して動くことを確認します。ここでエラーが多発する場合、スクリプトの記録ミスやコリレーション不足、パラメータ設定の誤りなどが原因であることが多く、シナリオを本格的に使う前に修正しておく必要があります。
このように、LoadRunnerのシナリオ作成は、単なる「操作記録」だけではなく、トランザクションの設計、シンクタイムの調整、パラメータ化、コリレーション、ユーザー行動パターンの設計といった要素を組み合わせることで、実際のシステム利用状況に近い負荷を再現することを目指すプロセスです。
LoadRunnerで負荷テストを実行する方法と結果レポートの確認手順
LoadRunnerで負荷テストを実行する際は、大きく分けて「シナリオの読み込み」「実行条件（スケジュール）の設定」「テストの開始・監視」「結果レポートの確認」という流れで進めます。実際の現場で迷いやすいポイントも多い工程ですので、手順をイメージできるように順を追って整理してご説明します。
まず、テスト実行の中心となるのが「Controller」と呼ばれるコンポーネントです。Controllerは、あらかじめ作成しておいた仮想ユーザースクリプト（VuGenで作成したもの）を読み込み、それをどのLoad Generatorで、何人分、どのようなタイミングで動かすのかを管理します。Controllerを起動したら、新しいシナリオファイルを作成するか、既存のシナリオファイルを開きます。シナリオファイルは、テスト実行の設定一式を保存したものと考えると分かりやすいです。
シナリオにスクリプトを追加する際は、「シナリオに仮想ユーザーグループを追加する」イメージで設定していきます。たとえば、「閲覧専用ユーザー」「検索を頻繁に行うユーザー」「購入まで進むユーザー」というように、利用パターンごとに別のスクリプトを用意している場合、それぞれを別グループとして登録します。グループごとに仮想ユーザー数や実行台数（どのLoad Generatorで動かすか）を設定できるため、負荷のバランスを現実の利用状況に近づけることができます。
続いて、「スケジュール（実行パターン）」の設定を行います。スケジュールとは、テストの時間軸に沿って、「いつ何人のユーザーを起動するか」「どのくらいの時間負荷を維持するか」といった流れを定義したものです。一般的には、次のような構成がよく使われます。
- ウォームアップ（少数のユーザーで動作確認を兼ねた短時間の実行）
- ランプアップ（時間をかけて徐々にユーザー数を増やす区間）
- ステディステート（一定ユーザー数で一定時間維持する区間）
- ランプダウン（徐々にユーザー数を減らす区間）
Controller上では、これらの区間をタイムライン形式で設定でき、何分かけてユーザー数を増やすか、ステディステートを何分または何時間続けるかなどを細かく指定します。ここで設定する値は、性能要件やテストの目的に応じて決めます。
テストを開始する前には、「プレテスト」のような形で少数ユーザーによる実行を行い、設定ミスがないかを確認することが大切です。仮想ユーザー数を数人に設定し、短時間だけシナリオを実行してみて、次のような点をチェックします。
- スクリプトが途中でエラーにならず最後まで動いているか
- テスト対象システム側で想定通りの動作（ログインや検索など）が行われているか
- 予期しないエラー画面やメッセージが表示されていないか
- ControllerとLoad Generatorの接続が安定しているか
この段階で問題があれば、スクリプトやシナリオ設定を修正してから本番の負荷テストに進みます。
プレテストが問題なく完了したら、本番の負荷テストを実施します。Controllerから「テスト開始」ボタンを押すと、設定したスケジュールに基づいて仮想ユーザーが順次起動し、シナリオを実行します。テスト実行中は、Controller画面で次のような指標をリアルタイムに確認できます。
- 現在実行中の仮想ユーザー数
- 各トランザクションの平均レスポンス時間
- 1秒あたりのトランザクション数（スループット）
- エラー数、エラー率
- 各仮想ユーザーグループごとの状況（実行中、完了、エラーなど）
これらの情報を見ながら、テストが正常に進行しているか、明らかに異常な数値が出ていないかを監視します。もしテスト途中で重大な不具合が見つかった場合や、システムに過度な負荷がかかりすぎていると判断した場合は、Controllerからテストを一時停止または停止できます。
テストが完了すると、Controllerはテスト結果の生データをログとして保存します。その後の「結果レポートの確認」は、主にAnalysisコンポーネントを使用して行います。Analysisでは、Controllerから出力された結果ファイルを読み込み、各種グラフや統計情報として可視化します。代表的なレポート項目としては、次のようなものがあります。
- トランザクション別の平均レスポンス時間グラフ
- 同時ユーザー数とレスポンス時間の関係グラフ
- スループット（秒あたりのトランザクション数やリクエスト数）の推移
- エラー数・エラー率の推移
- 応答時間の分布（どれくらいの割合のリクエストが何秒以内に完了したか）
これらを確認することで、「どの処理がどれくらいの時間で完了していたのか」「負荷が高まるにつれてレスポンスがどのように変化したのか」「どのタイミングでエラーが増えたのか」といった傾向を把握できます。
Analysisでは、グラフ上で特定の時間帯をハイライトし、その区間の詳細な統計値を確認することもできます。たとえば、ステディステート区間だけを選択して平均レスポンス時間やエラー率を確認すると、安定状態での性能をピンポイントで評価できます。また、しきい値（たとえばレスポンス時間3秒など）を基準に、どのくらいの割合のトランザクションがその範囲内に収まっているかを確認すると、ユーザー体感に近い視点で性能を評価しやすくなります。
レポートを作成する際には、単純にグラフを貼り付けるだけでなく、「どのテスト条件で」「どのような結果になったのか」を簡潔にまとめたコメントや表を添えると、チーム内での共有がスムーズになります。テスト日時、シナリオ名、仮想ユーザー数、実行時間、テスト対象のバージョンなどをレポートの冒頭に記載しておくと、後から見返したときに状況を思い出しやすくなります。
さらに、同じシナリオで複数回テストを行っている場合は、Analysisの結果を比較して、「改善前と改善後でレスポンスがどれだけ変わったか」「負荷の上限がどれだけ引き上がったか」といった変化を確認することができます。テスト結果の比較は、改善施策の効果を数値として示すために非常に有用です。
このように、LoadRunnerでの負荷テスト実行は、Controllerでのシナリオ設定と監視、Analysisでの結果確認という二つのフェーズを軸に進めていきます。
LoadRunnerのテスト結果から読み取るボトルネック分析のポイント
LoadRunnerで負荷テストを実施したあとは、得られた結果からシステムのどこにボトルネック（処理全体を遅くしている原因）が存在するのかを読み取ることが重要です。ボトルネック分析では、単にレスポンス時間の平均値を見るだけではなく、どの処理が遅いのか、どのような負荷がかかったときに性能が悪化するのか、エラーはどのタイミングで発生するのかといった、多角的な視点で結果を解釈していきます。LoadRunnerでは、Analysisコンポーネントを使うことで、多数の指標をグラフとして表示できるため、問題箇所を段階的に絞り込むことが可能です。
まず注目すべきは、トランザクションごとのレスポンス時間の推移です。LoadRunnerでは、スクリプト内で指定したトランザクション（例：ログイン処理、検索処理、購入処理など）ごとの平均値、最大値、最小値を確認できます。ここで特定のトランザクションだけが極端に遅い場合、その処理に関連する機能、データベースクエリ、外部APIなどがボトルネックとなっている可能性があります。一方で、すべてのトランザクションが均等に遅くなっている場合は、サーバー全体のCPU、メモリ、ネットワーク帯域など、インフラ側で処理能力が不足していることが疑われます。
次に確認したいのが、レスポンス時間と同時仮想ユーザー数の関係グラフです。ユーザー数が増えるにつれてレスポンスがどのように変化するのかを見ることで、システムが「どの負荷レベルまで安定動作できるのか」を把握できます。一般的に、ユーザー数の増加とともにレスポンスが緩やかに悪化していくのは自然な挙動ですが、ある一点から急激に遅くなる場合、その地点が処理能力の限界値であると考えられます。この限界値を特定することで、必要なサーバー増強やアプリケーション改善の判断材料になります。
LoadRunnerの結果評価で特に重要なのが、TPS（Transactions Per Second：1秒あたりの取引処理数）の確認です。TPSは、システムの処理能力そのものを数値化した指標で、レスポンス時間と合わせて見ることで、性能変化の背景が読み取りやすくなります。たとえば、レスポンス時間が急増しているにもかかわらずTPSが頭打ちになっている場合、サーバーが処理しきれずに待ち時間が増えている状態です。一方、レスポンス時間は上がっていてもTPSが増えている場合は、システムが限界に達したわけではなく、一時的に処理が詰まっているだけの可能性があります。
次に重要な観点として、エラー率の推移があります。エラーが発生するタイミングは、ボトルネックを見つけるうえで非常に有力な手がかりです。たとえば、同時ユーザー数が増え始めた直後にエラーが急増する場合は、接続上限やメモリ不足などのインフラ依存の問題が疑われます。一方、特定のトランザクションだけエラーが多い場合は、アプリケーション内部の処理が高負荷時に耐えられていない可能性があります。エラー内容に「タイムアウト」「500 Internal Server Error」「DB接続エラー」などのメッセージが含まれている場合、それぞれ原因の方向性を絞り込む材料になります。
さらに、応答時間の分布（Percentile：パーセンタイル）も非常に重要です。平均値だけでは一部の極端な遅延が隠れてしまうため、95パーセンタイル（全リクエストのうち95％が収まる時間）や99パーセンタイルを確認することで、ユーザー体験に近い性能評価ができます。たとえば平均が1秒でも、95パーセンタイルが5秒以上である場合、多くのユーザーが「遅い」と感じる可能性があります。パーセンタイル値が悪化するタイミングを確認すると、負荷がどのレベルに達したときに快適性が損なわれるかを把握できます。
Analysisのグラフを読み解くだけでなく、他の監視データと合わせて比較することも不可欠です。LoadRunner単体ではCPUやメモリなどのサーバー内部状態までは把握できないため、サーバー監視ツールやOSのログと照らし合わせる必要があります。レスポンス悪化とCPU100％が同時に発生している場合は、CPUがボトルネックです。逆に、CPUやメモリに余裕があるのにレスポンスだけが遅い場合は、データベースや外部API、ネットワークが原因となっている可能性が高いです。
特にデータベースが関係している場合は、SQLクエリの遅延がレスポンス時間に大きく影響します。同じトランザクション内でも、データ量が増えているときやインデックスが不足しているときに、特定のクエリだけが極端に遅くなることがあります。また、データアクセス頻度が高まるとロック競合などが発生し、負荷が増えるほど遅延が顕著になる傾向があります。LoadRunnerの結果から「検索処理だけが遅い」といった傾向が読み取れた場合、データベースの実行計画を確認することで問題を特定しやすくなります。
加えて、Load Generator側のリソース不足も見落としがちなポイントです。仮想ユーザー数が多いと、負荷を出す側のマシンがCPUやメモリ不足に陥り、期待した量のリクエストを送れない場合があります。この場合、テスト結果が「サーバーが限界」というより「LoadRunnerの限界」である可能性があります。ControllerやLoad Generatorの動作状況も合わせて確認することが、正確な性能評価につながります。
ボトルネック分析において最も重要なのは、単一の指標だけで判断しないことです。レスポンス時間、TPS、エラー率、パーセンタイル、監視データ、ログなど、複数の情報を重ね合わせることで、原因を絞り込みやすくなります。「症状（レスポンスが遅い）」と「原因（CPU不足、クエリ遅延、ネットワーク問題など）」をつなぐためには、これらの指標の組み合わせが不可欠です。
LoadRunnerは性能テストに必要な多数の指標を提供してくれますが、それをどう読み解くかは分析者の視点に大きく依存します。負荷テストは単にツールで実行するだけでなく、「数値からどのようにシステムの状態を読み取るか」という分析プロセスこそが最も重要な価値を持ちます。
チーム開発でLoadRunnerを活用するための運用ルールと共有方法
チーム開発でLoadRunnerを活用する場合、「誰か一人がなんとなく使える」という状態ではうまく回りにくく、ツールそのものと同じくらい運用ルールや共有の仕組みが重要になります。負荷テストは一度きりのイベントではなく、機能追加やリリースのたびに継続して行うべき活動ですので、チーム全体で扱いやすい形にしておくことが大切です。そのためには、スクリプトやシナリオの管理方法、テストの実行フロー、結果レポートの共有方法などについて、あらかじめ共通ルールを決めておくと運用が安定しやすくなります。
まず押さえておきたいのが、スクリプトとシナリオのバージョン管理です。VuGenで作成したスクリプトや、Controllerで作成したシナリオファイルは、アプリケーションコードと同様にバージョン管理システムで管理することをおすすめします。そうすることで、どのアプリケーションバージョンに対して、どのスクリプト・シナリオを使ってテストしたのかを紐づけて追跡することができます。ディレクトリ構成としては、例えば「/performance-tests/loadrunner/シナリオ名」のように機能やユースケース単位でフォルダを分け、そこにスクリプト、データファイル（CSVなど）、シナリオファイルをまとめて配置すると整理しやすくなります。
次に、命名規則とコメントのルールをチームで統一することも重要です。スクリプト名やトランザクション名がバラバラだと、Analysisで結果を見るときにどの処理が何を表しているのか分かりにくくなります。たとえば、「Login」「Search」「Purchase_Confirm」など、画面名や処理内容が一目で分かる英単語や、チーム内で共通の日本語名称を用いるなどして揃えておきます。スクリプト内のコメントには、そのシナリオの目的、前提条件（必要なテストデータなど）、注意点を簡潔に記載しておくと、他のメンバーが引き継ぎやすくなります。
テスト実行フローの標準化も、チーム開発では欠かせません。具体的には、次のような流れをドキュメント化しておくと運用しやすくなります。
- 負荷テストをいつ行うか（例：リリース前、スプリント終盤、大きな改修後など）
- 誰がシナリオを準備・修正するか
- 誰がControllerを操作してテストを実行するか
- テスト対象環境をどのような手順で準備・初期化するか
- テスト結果をどのフォーマットでレポートするか
こうしたフローを明文化して共有しておくと、「今回の負荷テストは誰が担当か」「どこまでやれば完了とみなすのか」といった点で迷いが少なくなり、属人化を防ぐことができます。
テスト結果の共有方法については、チームのコミュニケーション手段と組み合わせて運用すると効果的です。Analysisで生成したグラフや表をスクリーンショットやエクスポート機能で保存し、簡単なサマリコメントとともにチームの共有スペースにアップロードします。合わせて、「テスト目的」「シナリオ名」「仮想ユーザー数と実行時間」「主な指標（平均レスポンス時間、パーセンタイル、エラー率など）」「気づきや懸念点」といった項目をテンプレート化して記録しておくと、後から見返す際に比較しやすくなります。
また、開発・QA・インフラ担当など、複数のロールが協力して性能改善に取り組めるようにする体制づくりもポイントです。LoadRunnerの結果から「どの処理が遅いか」は分かりますが、その原因がアプリケーションコードなのかデータベースなのかネットワークなのかを特定するには、それぞれの専門知識が必要になります。定期的に負荷テスト結果を共有するミーティングを設定し、開発者・インフラ担当が一緒にグラフやログを見ながら議論できる場を作ると、ボトルネックの特定と対策が進めやすくなります。
CI/CDパイプラインとの連携を検討することも、チームでの活用を強化するポイントです。すべてのテストを自動化する必要はありませんが、簡易的な負荷テストを定期実行する仕組みを作ることで、性能劣化を早期に検知しやすくなります。例えば、夜間に小規模の負荷テストを自動実行し、一定の閾値（レスポンス時間やエラー率）を超えた場合に通知するような運用が考えられます。大規模な本番想定テストは人手で実行するとしても、「普段から小さく性能を見る」習慣を組み込むことで、性能問題がリリース直前にまとめて発覚するリスクを減らすことができます。
ナレッジの蓄積と教育も、長期的には大きな効果を生みます。LoadRunnerの使い方や、過去の性能問題とその対応策などを、社内のドキュメントとして残しておくことで、新しく参加したメンバーが学びやすくなります。オンボーディングの一環として、簡単なシナリオを一緒に作成し、小規模な負荷テストを実行してAnalysisの見方を体験してもらうハンズオンを行うと、ツールの操作と性能を見る視点の両方を身につけてもらいやすくなります。
最後に、運用ルールは一度決めて終わりではなく、プロジェクトの成長に合わせて見直すことが大切です。システム規模やチーム構成、リリース頻度が変われば、必要な負荷テストの頻度やシナリオも変化していきます。テスト実行後の振り返りの場で「今回の運用で困った点」「次から改善したい点」を話し合い、ルールやテンプレートに反映していくことで、チームにとって扱いやすいLoadRunner運用へと徐々に近づけていくことができます。
まとめ
本記事では、LoadRunnerを用いた負荷テストの基礎から、テスト実行・分析・チームでの運用方法までを体系的に解説しました。まず、LoadRunnerがどのような役割を果たすツールであり、負荷テストの工程全体を支える複数のコンポーネント（VuGen・Controller・Load Generator・Analysis）で構成されていることについて説明しました。これにより、LoadRunnerが単に負荷をかけるための手段ではなく、性能評価を総合的に管理するための環境であることを理解しやすくなります。
続いて、負荷テストそのものの目的と基本概念として、レスポンス時間・スループット・エラー率などの代表的な性能指標や、ロードテスト・ストレステスト・スパイクテストなどの種類について整理しました。こうした概念を理解しておくことで、テスト結果が示す意味を正しく読み取り、性能の良し悪しを客観的に判断しやすくなります。
さらに、LoadRunnerのインストール手順やテスト環境の準備では、単にツールをインストールするだけではなく、適切な環境構築や監視体制の整備が不可欠であることを述べました。ControllerやLoad Generator同士の通信確認、テストデータ管理、環境初期化の手順など、実務で必要になる準備項目について丁寧に解説しました。
シナリオ作成に関するセクションでは、仮想ユーザーやトランザクション、シンクタイム、パラメータ化、コリレーションなど、負荷テストを現実に近づけるための重要な要素について説明しました。適切に設計されたシナリオは、正確な性能評価に直結するため、手順の理解だけでなく「なぜ必要なのか」を意識しながら作成することの重要性を示しました。
テスト実行の手順では、Controllerによるスケジュール設定、実行中の監視ポイント、Analysisによるグラフ確認など、負荷テストの全体フローを具体的に記述しました。特に、各指標がどのように性能低下の兆候を示すのか、どのような場面で異常値を確認すべきかといった実務的な視点を含めています。
また、結果分析では、レスポンス時間・TPS・エラー率・パーセンタイルなどの指標を組み合わせてボトルネックを特定する方法を詳しく説明しました。サーバーリソースやデータベースの遅延など、LoadRunnerだけでは見えない部分も含めて総合的に判断する必要性にも触れ、負荷テストの本質が「数字を読む力」であることを示しました。
最後に、チームでLoadRunnerを活用するための運用方法として、バージョン管理、命名規則、レポート共有、教育体制、CIとの連携など、ツールを継続的に活かすための仕組みづくりについて解説しました。負荷テストは一度の実行ではなく、継続的に改善していく活動であるため、チーム全体で共通の運用ルールを持つことが成功の鍵となります。