負荷テストとは?実施手順から性能評価の指標まで、システム安定性を確認する方法

Published on: | Last updated:

負荷テストとは…

負荷テスト、か。…またこの話。正直、面倒なんだよね。でも、やらないと後で地獄を見るのも、知ってる。 リリース後に「サイトが重い」「サーバーが落ちた」とか、もう考えたくもない。

要するに、作ったシステムが、実際のアクセス…それも、一番混雑する時のアクセスに耐えられるか、前もって試しておくこと。 保険みたいなもの、かな。何もないのが一番だけど、何かあった時のために、やっておく。

どうしてやるのか?昔、失敗した話

昔、あるECサイトのキャンペーンで、ひどい目にあったことがある。開始時刻ぴったりに、案の定アクセスが集中して、サーバーが応答しなくなった。いわゆる「鯖落ち」。

あの時の電話の嵐と、機会損失の額を考えたら…。事前に負荷テストをちゃんとしておけば、って、今でも思う。結局、ボトルネックになってたのはDBのクエリだったんだけど、それを突き止めるのに、また時間がかかった。

だから、やる。問題が起きてから対応するのは、本当に大変だから。 特に、原因究明が難しいんだよね、パフォーマンスの問題は。

じゃあ、どうやるの?

まあ、ざっくりとした流れがある。計画して、準備して、やってみて、結果を見て、対策する。 当たり前だけど、これが難しい。

  1. 計画:ゴールを決める。
    まず、何を達成できれば「合格」なのか決めること。 「同時接続1000人でも、表示速度が3秒以内」とか、具体的な数字で。 漠然と「速くしたい」じゃダメ。
  2. 設計:シナリオを作る。
    ユーザーが実際にどういう操作をするか、想像してシナリオを作る。 みんながトップページだけ見るわけじゃない。ログインして、商品を検索して、カートに入れて、決済する…みたいな、一連の流れ。 このシナリオが現実的じゃないと、テストの意味がない。
  3. 準備:環境とツールを用意する。
    本番と全く同じじゃなくてもいいけど、近い環境を用意する。 ツールは色々ある。昔からあるJMeterとか、最近だとk6とか。 クラウドなら、AWSとかが提供してる負荷テストサービスを使うのも手。
  4. 実施:負荷をかける。
    作ったシナリオをツールに食わせて、実際にアクセスを発生させる。最初は少しずつ負荷を上げていって、どこで限界が来るかを見極めるのが定石。
  5. 分析と対策:結果を読み解く。
    テストが終わったら、集めたデータとにらめっこ。どこが遅いのか、何が原因かを探る。 そして、対策して、またテスト。この繰り返し。
負荷テストの基本的な流れのイメージ
負荷テストの基本的な流れのイメージ

指標は何を見る?

テスト中に見るべき数字はいくつかある。大事なのは、一つの数字だけじゃなくて、全体を見ること。

  • レスポンスタイム(応答時間)
    これは基本。リクエストを投げてから、反応が返ってくるまでの時間。 でも、平均値だけ見てると騙される。95パーセンタイル値とか、遅い方のリクエストがどうなってるかを見るのが大事。
  • スループット
    単位時間あたりにさばけるリクエストの数。 RPS (Requests Per Second) とか。これがシステムの処理能力の天井を示す。
  • エラーレート
    文字通り、エラーになったリクエストの割合。これがゼロじゃない時点で、何か問題が起きてる。
  • リソース使用率 (CPU, メモリ)
    サーバー側のCPUやメモリがどうなってるか。CPUが100%に張り付いてたら、もう限界。 メモリを使い果たしてたら、もっと危険。
テストツールのダッシュボードはこんな感じ
テストツールのダッシュボードはこんな感じ

ツールは何を使えばいい?

これも色々あるけど、まあ、代表的なものをいくつか。

ツール名 個人的な所感
Apache JMeter 古くからある、ザ・定番。 GUIでシナリオ作れるけど、ちょっと古臭い感じは否めない。でも、できることは多い。
k6 (Grafana k6) 最近のお気に入り。JavaScriptでシナリオを書くのが、開発者には馴染みやすい。 CI/CDに組み込みやすいのも良い。
Gatling Scalaでシナリオを書く。これも強力。 JMeterよりパフォーマンスが良い、って話も聞く。レポートが綺麗。
Locust Pythonで書けるのが特徴。 Python使いなら、これが一番とっつきやすいかも。

クラウド時代の負荷テスト

昔は物理サーバーのスペックとにらめっこしてたけど、今はクラウドが主流。だから、考え方も少し変わる。

例えば、AWSには「Distributed Load Testing on AWS」っていう、そのものズバリなソリューションがある。 Fargateを使って、サーバーレスで大規模な負荷を発生させられる。 自分たちで負荷用のサーバーを大量に用意しなくていいのは、すごく楽。 ただ、こういうサービスは便利だけど、何が起こってるかブラックボックスになりがちなので、そこは注意が必要かも。

海外のドキュメント、例えばAWSの公式ガイドとかを見ると、こういうマネージドサービスや、もっと進んだ「カオスエンジニアリング」みたいな話によく繋がっていく。 でも、日本の現場だと、まだJMeterで職人芸的に頑張ってるケースも多い印象。 どちらが良い悪いじゃなくて、文化とか、求められるものの違いなんだろうな、と思う。

最適化前後のレスポンスタイム比較(理想)
最適化前後のレスポンスタイム比較(理想)

でも、これって万能じゃない

負荷テストで「問題なし」の結果が出ても、それで100%安心はできない。なぜなら、テストはあくまでシミュレーションだから。

作ったシナリオ以外の動きを、実際のユーザーは平気でしてくる。 キャンペーン開始直後に、想定外のページにアクセスが集中するとか。結局、一番の負荷テストは、本番環境そのもの、ということなのかもしれない。

だから、負荷テストは「最低限の保証」を得るためのもの。完璧な未来を予測する水晶玉じゃない。この割り切りは、意外と大事だと思う。

あなたの現場では、負荷テスト、どうしてますか?よかったらコメントで教えてください。

🎁 この記事限定Googleツールを解放
```html

プロ品質・負荷テスト計画&結果トラッカー:標準化で抜け漏れ防止

負荷テストをやるたび、同じ観点の抜け、記録のバラつきで苦しんだ経験はありませんか?
「どの指標を記録した?」「何回やった?」「判定基準は?」—
曖昧なまま本番リリースして、あとで大慌て。
私は昔これで何度もシステム部門のレビューに突き返された。
標準化された記録・評価プロセスが、想像以上に大事。
このツールでその悩み、きれいに片付きます。もう手作業の集計に戻れない。

コピー&貼り付け用:負荷テスト記録&評価ツール

テスト計画入力・評価基準セット・履歴表示・集計まで一括管理。


// === 負荷テスト管理システム:プロ品質標準トラッカー ===

function doGet(e) {
  var sheetName = 'テスト記録';
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var sheet = ss.getSheetByName(sheetName) || ss.insertSheet(sheetName);
  // ヘッダ整備
  if(sheet.getLastRow() === 0){
    sheet.appendRow(['実施日','テスト名','同時接続数','目標応答時間(ms)',
      '実測応答時間(ms)','合格判定','担当者','メモ']);
  }

  var params = e && e.parameter ? e.parameter : {};
  var html = [];

  html.push('<div style="max-width:600px;margin:32px auto;'
    +'padding:24px;background:#f7f7f7;border-radius:8px;">');
  html.push('<h2>負荷テスト記録フォーム</h2>');

  // 入力フォーム
  html.push('<form method="get">');
  html.push('テスト名:<input name="name" required><br>');
  html.push('同時接続数:<input name="usercount" type="number" min="1" required><br>');
  html.push('目標応答時間(ms):<input name="target" type="number" min="1" required><br>');
  html.push('実測応答時間(ms):<input name="result" type="number" min="1" required><br>');
  html.push('担当者:<input name="owner" required><br>');
  html.push('メモ:<input name="memo" style="width:220px;"><br>');
  html.push('<button type="submit">記録する</button>');
  html.push('</form>');

  // データ登録
  if(params.name && params.usercount && params.target && params.result){
    var judge = (Number(params.result) <= Number(params.target)) ? '合格' : '不合格';
    sheet.appendRow([
      Utilities.formatDate(new Date(), "Asia/Tokyo", "yyyy/MM/dd HH:mm"),
      params.name,
      params.usercount,
      params.target,
      params.result,
      judge,
      params.owner,
      params.memo || ''
    ]);
    html.push('<p style="color:green;">記録しました。</p>');
  }

  // 履歴表示
  html.push('<h3>最近のテスト記録 (最新5件)</h3>');
  var lastRow = sheet.getLastRow();
  if(lastRow > 1){
    var records = sheet.getRange(Math.max(2, lastRow-4), 1, 
      Math.min(5, lastRow-1), 8).getValues();
    html.push('<table border="1" cellpadding="5" '
      +'style="background:#fff;width:100%;margin-bottom:18px;">');
    html.push('<tr><th>日付</th><th>テスト名</th>'
      +'<th>接続</th><th>目標</th>'
      +'<th>実測</th><th>判定</th><th>担当</th>'
      +'<th>メモ</th></tr>');
    for(var i=records.length-1;i>=0;i--){
      var r=records[i];
      html.push('<tr><td>'+r[0]+'</td><td>'+r[1]+'</td>'
        +'<td align="right">'+r[2]+'</td><td align="right">'+r[3]
        +'</td><td align="right">'+r[4]+'</td>'
        +'<td>'+(r[5]=='合格'?'合格'
        :'不合格')+'</td>'
        +'<td>'+r[6]+'</td><td>'+r[7]+'</td></tr>');
    }
    html.push('</table>');
  }else{
    html.push('<p>記録がまだありません。</p>');
  }

  // 合否集計
  html.push('<h4>判定サマリー</h4>');
  var vals = sheet.getRange(2,6,lastRow-1,1).getValues();
  var ok=0, ng=0;
  vals.forEach(function(row){
    if(row[0]==='合格') ok++;
    else ng++;
  });
  html.push('合格:'+ok+' 件 / 不合格:'+ng+' 件<br>');
  html.push('</div>');
  return HtmlService.createHtmlOutput(html.join(''));
}

// ここで終わり

導入ステップ:システム標準ツール構築ガイド

心配は不要。誰でも一度でできます。

  1. ステップ1:Apps Scriptエディタを開く
    Googleスプレッドシートを新規作成→画面上部メニューの「拡張機能」→「Apps Script」
    「拡張機能」は中央よりやや右です
    ブラウザ新タブが開き、スクリプト編集画面に切り替わる
    ⚠️ 会社アカウントは管理設定で開けないケースあり。昔私も何度かハマりました。
  2. ステップ2:既存コードを削除し全貼り替え
    中央のコード領域で Ctrl+A→Delete→上記コードをCtrl+V
    画面中央やや右寄りの白いエリアです
    `function myFunction()`など元々のコードが全部消え、新しいコードだけになる
    ⚠️ 全消去せずに貼るとエラーが出ます。コピペ漏れ要注意。
  3. ステップ3:プロジェクトを保存する
    上部の「保存」ボタン(フロッピーディスク型)をクリック or Ctrl+S
    エディタ画面上方・左端付近です
    初回のみプロジェクト名入力画面が開きます
    ⚠️ 名前は自由ですが、未保存のまま次に進むと反映されません。
  4. ステップ4:Webアプリとして標準デプロイ
    右上の青い「デプロイ」→「新しいデプロイ」
    「デプロイ」は右上端です
    デプロイ設定画面が出ます
    子ステップ:
    1. ギアマークから「ウェブアプリ」を選択
    2. 「自分」を実行者に指定
    3. アクセス権限を「全員」にセット
    4. 「デプロイ」ボタンを押す
    ⚠️ 「全員」にしないと他の人が使えません。過去に何度かこの点で詰まりました。
  5. ステップ5:初回認証エラーに対処
    画面の指示に従い認証操作を続ける
    赤い警告「Googleはこのアプリを確認していません」が表示される
    「詳細」→「xxx(安全でないページへ)」→「許可」ボタンで進む
    ⚠️ 個人作成のApps Scriptは審査がないので必ず警告が出ます。正常です。
  6. ステップ6:アプリURLを取得して利用開始
    表示されたWebアプリURLをコピー
    デプロイ完了画面の中央に表示されます
    そのURLをブラウザで開くと、フォーム画面が表示されます
    ⚠️ スクリプトを修正した場合は、再デプロイしないと反映されません。
⚠️「このアプリは確認されていません」と出た場合の本当の理由
Google Apps Scriptで自作アプリを初めて公開すると、
「Googleはこのアプリを確認していません」と大きな警告が表示されます。
これは、あなたのアカウントにしかわからない“未審査の個人コード”だからです。
ウイルスや攻撃ではありません。
認証画面の「詳細」→「xxx(安全でないページ)」→「許可」と進めば大丈夫。
社内・自分用なら、安心して進んでください。
社外公開の場合のみ、審査申請が必要です。

実務に効く!具体的な活用シナリオ

たとえばSIer現場。負荷テストを手分けして繰り返し実施し、日ごとに「どの設定値で合格した?」「NGは誰が?」などを即時一覧化。
プロジェクト管理者が、この集計表をもとに「再テスト箇所」「ボトルネック傾向」を標準化レビューできる。
システム保守部門なら、新機能リリースごとの性能チェック結果をシートごと履歴化し、緊急時でも履歴逆引き検索が一瞬。
私も実際、過去の負荷テスト記録をGoogle Sheetで見せてほしいと要求された場面で、これがあれば大幅な作業短縮ができたと痛感しました。

```

Related to this topic:

Comments

  1. Guest 2025-12-17 Reply
    なんかさ、昔でっかいECサイトの負荷テストやった時のこと、まだちょっと引っかかってて。実際、「これだけテストして、本当に安定って言えるのかな?」みたいな疑い…ずっと消えなかったんだよね。シナリオ通りでピーク時アクセス真似してみるじゃん?でもさ、本番のユーザー動きってまじで想像外すぎてさ。決めた同時接続数、正直それ意味あんの?とか上司にも何回も聞いた記憶ある。 メトリクスで見ると、一応CPUの使用率とかレスポンスタイムは全部基準値内になるんだけど、現場では急にAPI飛んできたりバッチ走ったり…もう普通に起きるし。それこそ一回、お昼休みに謎のトラフィック急増でアラート発生、はいパニック。それがきっかけで「これ性能評価の指標自体ダメじゃない?」みたいな流れに変わって。なんというかさ…
  2. Guest 2025-11-11 Reply
    負荷テスト、なんか…本当に意味あるのかなって最近よく考える。うちも前やったんだけど、あれ、正直な話、本番とは違うこと多すぎて「あぁ、参考にならん」て思った。指標だとかいろいろチェックポイント決められてるけど、それも結局数字見ても現実とズレてない?みたいな気持ちが抜けない。コストも手間もかかるし、そこまで労力割く意味ほんとうにあるのか…たまに迷う、自分は。