読者が抱える課題
システム開発の終盤やリリース前に実施される「性能テスト（負荷テスト）」において、以下のような課題に直面することがあります。
- 「目標値（スループットやレイテンシ）をどのように決めてよいか分からない」
- 「とりあえず限界まで負荷をかけたらシステムが落ちたが、これでテストとして成立しているのか判断できない」
- 「本番環境のユーザー挙動とかけ離れたシナリオを作成してしまい、ボトルネックを検知できなかった」
本記事では、これらの課題を解決するために、実務でそのまま使える「目標値策定のフレームワーク」と「シナリオ設計テンプレート」を提示し、具体的な手順を解説します。
この記事で分かること
- 性能テストにおける3つの主要指標（同時実行数、TPS、レスポンスタイム）の算出方法
- 業務特性に応じたテストシナリオの設計手順
- そのまま使える「性能テスト計画・シナリオ設計テンプレート」
- 性能テスト実施時のよくある失敗と対策
対象読者・前提条件
- Webアプリケーションの開発・運用に携わるエンジニア、PM、QA担当者
- 性能テストの計画書やシナリオを作成する必要がある方
- ※特定の負荷テストツール（JMeter, k6など）の具体的な操作方法ではなく、ツールを動かす前段階の「設計・定義」に焦点を当てています。
1. 性能テスト目標値の策定プロセス
性能テストの目標値は、ビジネス要件や過去のアクセス実績から逆算して論理的に決定する必要があります。感覚値で設定すると、過剰なインフラコストが発生するか、逆にリリース後にパンクする原因になります。
目標値策定に必要な3つの指標
| 指標 | 単位 | 概要 | 算出の考え方 |
|---|---|---|---|
| アクティブユーザー数 (U) | 人 / セッション | 同一時間帯にシステムを利用しているユーザー数 | ピーク時間帯のアクセスログ、またはビジネス計画値から算出 |
| スループット (TPS / RPS) | Transactions / Requests Per Second | 1秒あたりにシステムが処理すべきリクエスト数 | 総リクエスト数 ÷ 対象時間(秒) |
| レスポンスタイム (T) | 秒 / ミリ秒 | リクエスト送信からレスポンス受信完了までの時間 | ユーザー許容限界、または既存システムのAPI実績値から設定 |
| 限界性能 (限界値) | - | システムが正常に応答を返せる最大負荷 | 目標値の1.5倍〜2倍程度を基準として検証 |
目標値の算出例（ECサイトの例）
-
前提条件:
- セール時に1時間で最大36,000PV（ページビュー）のアクセスが予想される。
- 1ユーザーが1ページ表示するごとに、平均5回のアソシエーションリクエスト（APIコール）が発生する。
-
計算式:
- 1秒あたりの平均PV =
36,000PV ÷ 3,600秒 = 10 PV/秒 - ピーク特性（瞬間的なスパイク）を考慮し、安全係数として3倍を見積もる =
30 PV/秒 - 1秒あたりの目標スループット（RPS） =
30 PV/秒 × 5リクエスト = 150 RPS
- 1秒あたりの平均PV =
この場合、性能テストの目標値は**「150 RPSの負荷をかけた状態で、主要APIのレスポンスタイムが2.0秒以内（95パーセンタイル値）であること」**のように定義します。
2. シナリオ設計のステップ
単一のAPIにひたすらリクエストを送るだけでは、実際のユーザー挙動に伴うDBロックやメモリリークなどの問題を検出できません。実務では「ユースケース」に基づいたシナリオ設計が必要です。
ステップ1：業務フローの洗い出しとプロファイルの作成
ユーザーがシステム内で取る代表的な行動パターンを定義します。
- パターンA（閲覧中心）: トップページ表示 -> 商品検索 -> 商品詳細表示（全体の70%）
- パターンB（購買行動）: トップページ表示 -> ログイン -> カート追加 -> 購入手続き（全体の25%）
- パターンC（管理機能）: 管理画面ログイン -> CSVエクスポート（全体の5%）
ステップ2：Think Time（思考時間）の導入
人間が画面を操作する場合、ページ遷移の間に必ず「画面を読む時間（Think Time）」が発生します。負荷テストツールでThink Timeを設定しないと、現実のユーザー数の数十倍以上の負荷がシステムにかかり、不正確な結果となります。
-
設定例: 各ページ遷移間に
2秒〜5秒のランダムな待機時間を挿入する。
3. 実務用テンプレート
性能テストの計画およびシナリオ設計時に使用できるスプレッドシート用のテンプレート構成です。
【テンプレート】性能テストシナリオ定義書
■ 1. テスト目的
[例] 新規リリースに伴う、ピーク時（150 RPS）におけるシステムの安定性とレスポンス性能の検証。
■ 2. 目標性能指標
- ターゲットスループット: 150 RPS (システム全体)
- 許容レスポンスタイム:
- 一般API: 1.5秒以内 (95th percentile)
- 決済API: 3.0秒以内 (99th percentile)
- 許容エラー率: 0.1% 未満
- 限界性能目標: 300 RPS（目標の200%）においてシステムがクラッシュせず、エラーハンドリングが機能すること
■ 3. テスト環境条件
- APサーバー: AWS ECS (Fargate) c5.large x 2台
- DBサーバー: AWS RDS Aurora PostgreSQL db.r5.large (1 Writer, 1 Reader)
- テストデータ準備:
- テスト用ユーザーアカウント: 10,000件
- 商品マスタデータ: 50,000件
■ 4. 負荷シナリオ構成（同時実行ユーザー配分）
| シナリオID | シナリオ名 | ユーザー比率 | 1ユーザーあたりの遷移フロー | 期待されるThink Time |
| :--- | :--- | :--- | :--- | :--- |
| SC-01 | 商品検索・閲覧 | 70% | トップ -> 検索 -> 詳細表示 -> 離脱 | 平均 3秒 |
| SC-02 | カート投入・購入 | 25% | ログイン -> 詳細 -> カート追加 -> 決済 | 平均 5秒 |
| SC-03 | 会員登録 | 5% | 新規登録画面 -> 入力 -> 完了 | 平均 8秒 |
4. 性能テストにおけるよくある失敗と対策
① テストデータの使い回しによるキャッシュヒット
- 問題点: 同じユーザーIDや同じ商品IDだけでテストをループさせたため、DBやアプリケーションのキャッシュが効いてしまい、本番環境より極端に良い結果が出てしまう。
- 対策: テストデータを数千〜数万件規模で用意し、CSVデータセットなどを用いてリクエストパラメータ（IDや検索ワード）をランダムに分散させる。
② ネットワーク帯域・テスト実行環境のボトルネック
- 問題点: 負荷をかける側のクライアントPC（テスト実行マシン）のCPUやネットワーク帯域が限界に達し、ターゲットシステムではなくテストツール側がボトルネックになってエラーが発生する。
- 対策: テスト実行マシンのリソース監視（CPU、メモリ）を同時に行う。必要に応じて、分散実行（Distributed Testing）構成を取り、複数台のクライアントから負荷を分散してかける。
③ 外部連携APIへの負荷考慮漏れ
- 問題点: 決済代行サービスや外部の地図APIなど、サードパーティのAPIに対してテスト環境から大量のリクエストを送ってしまい、外部サービスの利用規約違反や課金高騰、あるいはアクセス遮断が発生する。
- 対策: 外部連携部分はモック（Mock）サーバーに差し替えるか、事前に外部サービス提供元に負荷テストの実施許可を申請する。
5. まとめ
性能テストは、単にツールを実行してシステムを限界まで追い詰める作業ではありません。
- ビジネス要件から論理的な目標値（RPS、レスポンスタイム）を算出する
- 実際のユーザー行動に基づいたシナリオとThink Timeを設定する
- テストデータの多様性を確保し、キャッシュによる影響を排除する
この3点を設計段階で徹底することで、手戻りのない、信頼性の高い性能テストを実施することができます。プロジェクトの要件定義・基本設計フェーズから、これらの指標を意識して設計を進めてください。