負荷テストでチームが犯す最大の誤りは、スクリプトが一本も書かれる前に起きます：誤ったテスト規模を選んでしまうことです。小さすぎる負荷テストは偽の安心感を与えます。ダッシュボード上はすべてが「緑」でも、本番でトラフィックが急増すると亀裂が現れます。逆に大きすぎる負荷テストも同様に有害です。起きもしないシナリオをテストして時間や金、インフラを浪費し、実際には存在しないボトルネックを追いかけることになります。
注意すべき事例は多くあります。例えば、ある大手企業がブラックフライデーに新製品を投入するにあたり「安全そうだから」として同時ユーザー500人でしかテストを行いませんでした。プロモーションが始まって数分でトラフィックは2,500人に急増し、チェックアウトの処理が崩壊しました。別の例では、ある大学が新しいポータルを同時ユーザー1,000人でテストするよう主張しましたが、過去のピークトラフィックは5,000人を超えたことがありませんでした。その結果、クラウド費用が膨らみ、現実には発生しないボトルネックを追いかけるのに1か月を無駄にしました。
規模決定は負荷テストの芸術と科学が出会う部分です。意味のある十分に大きな数値が必要ですが、同時に現実を反映する根拠も必要です。問題は、ほとんどのチームがプロジェクト文書に「同時ユーザー数」の明確な数値を持っていないことです。多くはスライドの見栄えで500、1,000、10,000といった切りの良い数字を選びがちですが、それでは不十分です。
本稿では、負荷テストの規模を決めるための実証済みの3つの方法を解説します：1) 要件主導、2) トランザクションベース、3) 解析データベース。それぞれが、散らかったまたは不完全なデータを弁護可能なテスト規模に変えるためのフレームワークを提供します—つまり推測ではなく本番トラフィックに合致する規模です。
方法1：要件主導による規模決定
運が良ければ、要件の中に答えが既に含まれています—行間を読むだけです。
いくつかのシナリオは明白です。会社が出席必須のライブ配信タウンホールを計画しているなら、同時性は出席者数と同じです。従業員が1,000人いるなら、10%の安全余裕を加えて1,100同時ユーザーでテストすべきです。これが最も直接的なケースです。
他のイベントはやや扱いが難しいですが、それでも予測可能です。大学の授業登録システムを例に取ってください。年の大半はトラフィックは穏やかで控えめですが、登録日にはシステムが酷使されます。人気講義の席を取るために学生が一斉にアクセスし、トラフィックは基準値を大きく上回ります。学生が10,000人いて、そのうち90%が登録日にシステムにアクセスすると分かっているなら、それは9,000の同時ユーザーです。友人や家族に複数端末からログインさせる行為を考慮すれば、実際の同時性は学生数の100%を超えることもあります。安全を見て学生ユーザーの200%でトラフィックを想定するテストもあり得ます。
他の業界でも同様の状況が発生します。例えば、税務ポータルは4月に利用が集中します。通常は利用が少ないシステムでも申告日には同時性が劇的に跳ね上がります。あるいはコンサートのチケット販売プラットフォームを考えてみてください。多くのイベントではトラフィックは分散しますが、大物アーティストのチケットが午前10時ちょうどに発売されると、ファン全員が同時にリフレッシュを押します（チケット購入を狙うボットの存在も別枠で考慮する必要があります）。これらは要件に基づく瞬間であり、負荷テストはそれに合わせて規模を決める必要があります。
落とし穴： 要件はしばしば低めに見積もられます。ステークホルダーが予算面で保守的に少なめの参加数を申告したり、「覗きに来る人（lurkers）」やボットを考慮しないことがあります。数値には常に疑問を持ち、サージ（急増）をモデル化し、余裕を追加してください。
経験則： 要件主導の規模決定は、イベントが時間的に限定され予測可能で、参加者数が明確な場合に最も有効です。その場合、要件が最も弁護可能なベースラインを与えてくれます。
方法2：トランザクションベースの規模決定
要件が数値を与えてくれない場合は、ビジネスのトランザクションが数値を教えてくれます。抽象的なユーザー数ではなく、注文、登録、決済、アップロード、入札といった「アクション」を考えます。
計算は次の通りです：
- ピークトランザクション量を特定する。 例えば、通常日は1,000件の注文を処理するECプラットフォームが、ホリデーシーズンに50%増えて1,500件になるとします。
- アクティブウィンドウを見つける。 注文の大半が午前10時から午後10時の間に発生するなら、それは12時間のウィンドウで、約125件/時間です。
- 不均等分布を調整する。 トラフィックはめったに均等ではありません。ピーク時間が25%高ければ、最も混雑する時間は約160件になります。
- これを同時性に変換する。 注文完了に顧客が5分かかるとすると、160件/時間は2.67件/分に相当します。5分間の滞在を掛けると、実際に注文を行っている同時ユーザーは約14人です。
- 閲覧トラフィックを加える。 購入者だけが全てではありません。解析で購買者1人に対して閲覧者が10人いるなら、さらに140人の同時ユーザーが必要です。
- バッファを追加する。 25%の安全マージンを加えると、約190ユーザーになります。変動性に応じて50%や100%のマージンを検討することもあります。
この例でのテスト規模は、最も忙しい重要なトランザクションパターンを再現する190同時ユーザーです。
この方法は、負荷をビジネスの成果に直接結びつけるため有効です。ただ「190ユーザー」をテストするのではなく、「ピークで160注文/時間＋閲覧」を処理できるかを検証します。ステークホルダーにとって理解しやすく重要な数値です。
別の例： オークションプラットフォームを考えてみます。1日平均10,000件の入札があり、そのうち40%が注目オークションの最後2時間に集中するなら、2時間で4,000件、つまり約2,000件/時間です。平均入札に30秒かかると仮定すると、入札を行っている同時ユーザーは約16人です。しかし閲覧者：入札者の比率が30:1であれば（オークションサイトではよくある比率）、実際にシミュレートすべき同時ユーザーは約500人になります。この規模のテストは、入札ピークだけでなく、一覧を見て更新する大量の閲覧者に対する耐性も検証します。
季節性も重要です。 小売だけがピークを持つわけではありません。旅行プラットフォームは春休みや祝日に需要が急増します。税関連ポータルは4月に集中します。SaaSのオンボーディングは新契約締結時に急増します。トランザクションベースの規模決定は、これらすべてをビジネス固有のイベントに紐づけて同時性を算出します。
経験則： 要件が曖昧でビジネス指標が明確な場合は、トランザクションベースの規模決定を使ってください。精度が高く、ステークホルダーにも説明しやすく、結果に直結します。
方法3：解析データに基づく規模決定
要件が曖昧でトランザクションデータがない場合、解析ツールが穴を埋めてくれます。Google Analytics、Adobe Analytics、その他のツールは、同時性に変換可能なトラフィックデータを提供します。
手順は次の通りです：
- ピークトラフィックから始める。 例として、ある日の訪問者数が50,000人だったとします。
- 時間あたりのトラフィックに変換する。 24時間で割ると約2,100訪問者/時間です。
- スパイクを補正する。 トラフィックは平坦ではありません。分布の不均一さを考慮して50%を追加すると→約3,150訪問者/時間になります。
- 平均セッション時間を使う。 ユーザーの平均滞在が2分なら、3,150 / 60 × 2 = 約105同時ユーザーです。
- バッファを追加する。 25%の余裕を持たせると、約130同時ユーザーになります。
これが解析データに基づくテスト規模です：解析が示した最も激しいトラフィックに対応する130ユーザーです。
例： 月間アクティブユーザーが500,000人のSaaS企業を例に取ると、日間アクティブユーザーがおよそ10%（50,000人）で、そのうち20%が業務時間のピークにログインするなら、最も混雑するウィンドウには10,000ユーザーが存在します。平均セッション時間が15分であれば、テストすべき同時ユーザーは約2,500人になります。
精度に関する注意点： 解析データはログより優れていますが完璧ではありません。以下を考慮してください：
- 広告ブロッカー により一部の訪問が隠れることがあります。
- クッキー同意バナー により、ユーザーがトラッキングを拒否するとカウントが不足する可能性があります。
- ボットトラフィック がフィルタリングされていないと数値が膨らむことがあります。
それらの問題はありますが、解析は実際のユーザーセッションを反映しており、デバイスや地域ごとに正規化されたデータを提供します。地域別やデバイス別にセグメントできるなら、さらに精度が上がります。
経験則： ビジネスメトリクスが利用できないが、安定したトラフィックデータがある場合は解析ベースの規模決定を使ってください。現実に基づいた最も実用的な方法です。
特別ケース：新しいアプリケーション
完全に新しいアプリケーションを立ち上げる場合はどうでしょう？同時性を定義する要件もトランザクション履歴も解析データも持っていません。これは全く別の課題です。
よくある間違いは「安全そうだから」といって“2,000同時ユーザー”のような切りの良い数字を選ぶことです。しかしその数値は期待される振る舞いに結びついていなければ意味がありません。
より良いアプローチは、トランザクションやセッションという観点でトラフィックを推計することです。1時間に200件のアップロードを期待するなら、その処理が可能かを検証する規模でテストを設計します。ローンチ日に10,000件のサインアップを想定するなら、それを時間あたりのトラフィックとセッション時間に換算します。こうした粗い見積もりでもビジネス観点で解釈可能な結果をもたらします—すべてモデル化や計算で表現できる数学です。
例： マーケティングチームがローンチ週に5,000件のサインアップを見込んでいるとします。プレスリリースによりその60%が初日に集中すると仮定すると3,000件です。さらに不均等分布で最初の3時間に40%集中すると、約1,200件になります。アカウント作成に3分かかるとすると、同時サインアップは約60件です。閲覧やリトライを加味すると、合理的には200〜300同時ユーザーをテストするのが妥当です。この数値は仮定に基づいていますが、少なくとも明示的であり、実データが入手でき次第改善できます。
管理職が見栄えの良い数字を出したがるために推測が起きる点に注意： ステークホルダーやマネージャーは「投資家に示すために50,000ユーザーでテストしよう」といった大きな丸めの数字を求めることがあります。これに流されないでください。過大なテストは安心感を生むどころか、ノイズと無駄を生みます。推計に基づくトランザクションで規模を決める習慣を持ちましょう。
要約表：適切な方法の選び方
| 方法 | いつ使うか | 強み | リスク／欠点 |
| 要件主導 | 予測可能な時間限定イベント | 明確、弁護可能、計算が容易 | ステークホルダーの過小評価、利害の衝突 |
| トランザクションベース | ビジネス指標が明確な既存アプリ | 結果に直結、比率が正確 | 良好なメトリクスが必要、季節性の影響 |
| 解析ベース | 安定したトラフィック履歴があるサイト | 計算が容易、実際のセッションに基づく | 広告ブロッカー、ボット、精度のばらつき |
| 新しいアプリ | 履歴やデータが無い場合 | 明示的な仮定を促す、将来を見据えた設計 | 推測のリスク |
負荷テストの規模を適切に決めるためのまとめ
負荷テストの目的は単に数値を達成することではなく、ある問いに答えることです。あなたのシステムは、ビジネスにとって重要な特定の振る舞いやイベントに耐えられるか？
- 要件が直接的な数値を与えるなら、それを使いましょう。
- なければ、トランザクションが最も正確でビジネスに寄り添った基準を提供します。
- それらが利用できない場合は、解析データが信頼できるバックアップになります。
- 全く新しいシステムの場合は、推測よりも明示的なプロジェクションが優先されます。
そしてどの方法を選ぶにせよ、常に余裕を持たせてください。本番トラフィックはスパイキーで予測困難、かつ完璧な平均値にはほとんど合致しません。
LoadViewはこれら各種の規模決定手法を実用化するのに役立ちます。LoadViewを使えば、単なるユーザー数のモデル化だけでなく、入学期間中のバーストトラフィック、閲覧と注文の混在、解析データに合致するグローバル配分など、現実的なパターンを再現できます。つまり、あなたのテストは単なる数値ではなく、本番のリハーサルになるのです。
規模決定はあらゆる負荷テストの最初の判断です。正しく決めれば、その後のすべての結果は意味を持ちます。誤れば、どんなスクリプトやレポートも救えません。ここで示した3つの方法を使えば、自信を持ってテスト規模を決め、パフォーマンス結果が実際のサイトやアプリのトラフィックと活動に見合ったものになるようにできます。