負荷テストの進め方とk6の使い方｜スクリプト例と結果の読み方

k6とは、JavaScript（またはTypeScript）でシナリオを書き、Webサービスに負荷をかけて性能を測るオープンソースの負荷テストツールです。Grafana Labsが開発しており、コマンド1つで実行でき、「95%のリクエストが500ms以内」のような合格基準をコードで決められるのが特長です。

この記事では、k6のコマンドや書き方だけでなく、「どの種類の負荷テストを、どの順番で、どう判定するか」という負荷テストの進め方までをまとめます。入門記事ではあまり触れられない、k6 v2系での変更点（--no-summary の廃止など）、scenarios と executor の選び方、結果の数値の読み方、他ツールとの比較表も載せています。スクリプトは公式ドキュメント（grafana.com/docs/k6）の仕様に沿って書いています。

負荷テストとk6の早見表

負荷テストの種類と使い分け

負荷テストは「とりあえずたくさんアクセスする」ものではありません。知りたいことに合わせて、負荷のかけ方を変えます。k6の公式ドキュメントでは、次の種類に分けて説明しています。

※VU（Virtual User）は仮想ユーザーのことです。1VUが1人の利用者のようにスクリプトを繰り返し実行します。

どの順番で進めるか

スモークテストから始めて、段階的に負荷を上げるのが基本です。

1. スモークテスト：スクリプトの間違いや、テスト環境の設定ミスを先に見つける
2. 平均負荷テスト：普段の利用量で目標を満たすか確認する（ここが基準値になる）
3. ストレス／スパイクテスト：ピーク時やキャンペーン時を想定して確認する
4. 耐久テスト：長時間の運用で問題が出ないか確認する

負荷のかけ方は「増やす → 一定に保つ → 減らす」のシンプルな形にすると、結果を比べやすくなります。複雑に上下させると、どこで遅くなったのかが分かりにくくなります。

k6のインストール

公式ドキュメントに記載されている方法です。

# macOS
brew install k6

# Windows
winget install k6 --source winget

# Debian / Ubuntu
curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

# Docker
docker pull grafana/k6

k6本体はGoで作られた単体のプログラムです。スクリプトはJavaScriptで書きますが、Node.jsの上で動くわけではありません。そのため、npmパッケージ（fs や axios など）はそのままでは使えない点に注意します。npmの k6 パッケージはk6本体ではないので、インストールは上記の方法で行います。

k6 v1.0以降は、TypeScriptのファイル（.ts）もそのまま実行できます。

最初のスクリプト

// script.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 10,           // 仮想ユーザー10人
  duration: '30s',   // 30秒間
};

export default function () {
  const res = http.get('https://test.k6.io/');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
  sleep(1);          // 利用者が画面を見る時間の代わり
}

k6 run script.js

sleep を入れないと、1VUが休みなくリクエストを送り続けます。実際の利用者より強い負荷になるため、「VU10人＝利用者10人」という対応が崩れます。利用者の動きを再現したいときは sleep を入れます。

https://test.k6.io/ は、k6の公式が練習用に公開しているサイトです。自分が管理していないサイトには負荷をかけないでください（後述）。

options：負荷のかけ方を決める

stages：段階的に負荷を上げ下げする

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // 2分かけて50VUまで増やす
    { duration: '5m', target: 50 },   // 50VUを5分維持
    { duration: '1m', target: 0 },    // 1分かけて0まで減らす
  ],
};

これが平均負荷テストの基本形です。target を普段の利用量より大きくすればストレステスト、短い duration で一気に上げればスパイクテストになります。

VUの数は例です。普段の利用量（アクセスログや監視ツールの値）から逆算して決めます。

thresholds：合格・不合格の基準を決める

thresholds（しきい値）は、テストの合否をコードで決める仕組みです。基準を満たさないと、k6は0以外の終了コードで終わるため、CIでそのまま「失敗」として扱えます。

export const options = {
  thresholds: {
    http_req_failed: ['rate<0.01'],     // エラー率 1% 未満
    http_req_duration: ['p(95)<500'],   // 95%のリクエストが500ms未満
    checks: ['rate>0.99'],              // check の成功率 99% 超
  },
};

明らかに基準を超えたら途中で止めることもできます。

export const options = {
  thresholds: {
    http_req_failed: [
      { threshold: 'rate<0.05', abortOnFail: true, delayAbortEval: '30s' },
    ],
  },
};

エンドポイントごとに基準を変えるには、リクエストにタグを付けます。

export const options = {
  thresholds: {
    'http_req_duration{name:list}': ['p(95)<300'],
    'http_req_duration{name:search}': ['p(95)<800'],
  },
};

export default function () {
  http.get('https://example.com/api/items', { tags: { name: 'list' } });
  http.get('https://example.com/api/search?q=abc', { tags: { name: 'search' } });
}

checks：レスポンスの中身を確かめる

check はレスポンスの検証、thresholds は全体の合否、という役割分担です。

const res = http.get('https://example.com/api/items');
check(res, {
  'status is 200': (r) => r.status === 200,
  'has items': (r) => r.json('items').length > 0,
  'fast enough': (r) => r.timings.duration < 500,
});

check は失敗してもテストを止めません。失敗の割合で合否を判定したいときは、上のように thresholds に checks: ['rate>0.99'] を書きます。

「ステータスが200でも、中身がエラー画面だった」ということは実際によくあります。ステータスコードだけでなく、中身も check すると、見かけだけ速い結果にだまされにくくなります。

scenarios：本番に近い負荷を組み立てる

scenarios を使うと、複数の負荷パターンを1つのテストで同時に動かせます。各シナリオには「executor（実行方式）」を指定します。

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  scenarios: {
    browse: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 40 },
        { duration: '5m', target: 40 },
        { duration: '1m', target: 0 },
      ],
      exec: 'browse',
    },
    api_orders: {
      executor: 'constant-arrival-rate',
      rate: 20,              // 1秒あたり20イテレーション
      timeUnit: '1s',
      duration: '8m',
      preAllocatedVUs: 20,
      maxVUs: 100,
      exec: 'order',
    },
  },
  thresholds: {
    'http_req_duration{scenario:browse}': ['p(95)<500'],
    'http_req_duration{scenario:api_orders}': ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

export function browse() {
  const res = http.get('https://example.com/');
  check(res, { 'top 200': (r) => r.status === 200 });
  sleep(Math.random() * 3 + 1);   // 1〜4秒ほど画面を見る
}

export function order() {
  const res = http.post(
    'https://example.com/api/orders',
    JSON.stringify({ itemId: 1, qty: 1 }),
    { headers: { 'Content-Type': 'application/json' } },
  );
  check(res, { 'order 201': (r) => r.status === 201 });
}

executorの選び方

「VUで決める」と「到着率で決める」の違い

ここは負荷テストで特に大切な考え方です。

VU方式では、サーバーが遅くなるほど負荷が自然に下がるため、限界を実際より高く見積もることがあります。「1秒あたり○件をさばけるか」を確かめたいときは、到着率方式（arrival-rate）を使います。maxVUs まで使い切ると、k6は dropped_iterations（実行できなかったイテレーション）を記録します。この値が出たら、狙った負荷をかけられていないというサインです。

テストのライフサイクル（setup / teardown）

export function setup() {
  // テスト開始前に1回だけ実行（ログインしてトークンを取るなど）
  const res = http.post('https://example.com/api/login',
    JSON.stringify({ user: 'loadtest', password: __ENV.LT_PASSWORD }),
    { headers: { 'Content-Type': 'application/json' } });
  return { token: res.json('token') };
}

export default function (data) {
  http.get('https://example.com/api/me', {
    headers: { Authorization: `Bearer ${data.token}` },
  });
}

export function teardown(data) {
  // テスト終了後に1回だけ実行（テストデータの後片付けなど）
}

パスワードなどはスクリプトに直接書かず、k6 run -e LT_PASSWORD=... script.js のように環境変数（__ENV）で渡します。

複数ユーザーのテストデータは SharedArray で読み込むと、全VUで1つのデータを共有でき、メモリを節約できます。

import { SharedArray } from 'k6/data';

const users = new SharedArray('users', function () {
  return JSON.parse(open('./users.json'));
});

export default function () {
  const user = users[__VU % users.length];   // VUごとに別のユーザー
  // ...
}

結果の読み方

k6 run が終わると、結果のまとめ（end-of-test summary）が表示されます。k6 v1.0以降は、合否（THRESHOLDS）と全体の結果（TOTAL RESULTS）を中心にした「compact」形式が既定になりました。以下は公式ドキュメントに掲載されている出力形式の例（一部抜粋）です。

█ THRESHOLDS
  http_req_duration
  ✓ 'p(95)<1500' p(95)=148.21ms

█ TOTAL RESULTS
  checks_total: 90  13.122179/s
  checks_succeeded: 100.00%

  HTTP
  http_req_duration: avg=140.36ms min=119.08ms
  http_reqs: 45  6.56109/s

まず見る指標

p(95) を見る理由

p(95) は「95%のリクエストがこの時間以内に終わった」という値です。平均値は、ほとんど速くて一部だけとても遅い場合でも、それなりの数字になってしまいます。

平均だけを見ると「216msなら十分速い」と判断しがちですが、実際には100人に4人が3秒待っています。この例では p(95) も100msのため、p(99) まで合わせて見ると、遅い利用者がどれくらいいるかがわかります。

結果の判断表

k6を動かしているマシンの CPU やネットワークも必ず確認します。負荷をかける側が上限に達していると、サーバーではなくk6側の限界を測ってしまいます。

結果をファイルや外部に出す

# 全データを JSON（1行1データ）で出力
k6 run --out json=results.json script.js

# まとめを詳しく表示（グループ・シナリオごとの結果も出す）
k6 run --summary-mode=full script.js

# 実行中の様子をブラウザで見る（Webダッシュボード）
K6_WEB_DASHBOARD=true k6 run script.js

handleSummary 関数を書くと、まとめを JSON や HTML など好きな形式でファイルに保存できます。

export function handleSummary(data) {
  return {
    'summary.json': JSON.stringify(data, null, 2),
  };
}

k6 v2系での主な変更点

古い記事の書き方をそのまま使うとエラーになるものがあります。

ツールの比較：k6・JMeter・Locust・Gatling

どれが優れているかではなく、チームの言語と目的で選ぶのがよい考え方です。コードレビューやGitでの管理、CIでの自動判定を重視するならk6が扱いやすく、GUIで試行錯誤したい場合や特殊なプロトコルが必要な場合はJMeterが便利です。

負荷テストの計画と注意点

テスト前に決めておくこと

目標値を先に決めておくと、結果を見て「速い／遅い」で迷わずに済みます。

やってはいけないこと・気をつけること

• 本番環境にいきなり負荷をかけない：利用者に影響が出ます。本番と同じ構成の検証環境で行うのが基本です。やむを得ず本番で行う場合は、関係者の合意、時間帯、止める条件を決めてから実施します
• 自分が管理していないサイトに負荷をかけない：相手のサービスを止めてしまうおそれがあり、攻撃とみなされることもあります
• 外部サービスへの通信に注意する：支払いやメール送信、SMSなど外部APIを呼ぶ処理は、モック（テスト用の偽物）に置き換えるか、テスト用の環境を使います
• クラウドやCDNの設定を確認する：WAFやレート制限でk6の通信がブロックされると、正しい結果になりません。事前に検証環境の設定を確認します
• ネットワーク距離をそろえる：k6を動かす場所とサーバーの距離によって応答時間が変わります。毎回同じ場所から実行します
• テストデータを用意する：同じユーザー・同じ商品ばかりだとキャッシュが効きすぎて、実際より速い結果になります
• 同時にサーバー側も監視する：k6の結果だけでは原因がわかりません。CPU、メモリ、DB、ログを並べて見ます

実行前のチェックリスト

CIで定期的に動かす

thresholds を満たさないとk6は0以外の終了コードで終わるため、GitHub Actions などのCIでそのまま合否を判定できます。CIでは短いスモークテストや平均負荷テストを動かし、性能が落ちる変更を早めに見つける使い方が向いています。 k6公式の Docker イメージ（grafana/k6）を使えば、CIのジョブ内でもインストールなしで実行できます。

よくある質問

Q. k6はブラウザの操作も測れますか？ A. はい。k6/browser モジュール（v1.0で正式機能になりました）で、実際のブラウザを動かして画面表示の速さを測れます。ただしブラウザは1VUあたりの負荷が大きいため、大量の負荷はHTTPのテストでかけ、ブラウザのテストは少数で体感速度を測る組み合わせが一般的です。

Q. VUはいくつに設定すればいいですか？ A. 実際の利用量から決めます。「1秒あたりのリクエスト数」が分かっている場合は、VUではなく constant-arrival-rate で RPS を直接指定する方が、狙った負荷を正確にかけられます。

Q. k6はnpmでインストールできますか？ A. npmの k6 パッケージはk6本体ではありません。k6本体は Homebrew、winget、apt、Docker などでインストールします。スクリプトはJavaScriptですが、Node.jsではなくk6の実行環境で動きます。

Q. 平均値が速いのにユーザーから「遅い」と言われます。 A. p(95)・p(99) を確認してください。一部のリクエストだけが極端に遅い場合、平均値には表れにくくなります。タグを付けてエンドポイントごとに分けると、どこが遅いのかを絞り込めます。

まとめ

• k6は JavaScript/TypeScriptでシナリオを書き、合否までコードで決められる負荷テストツール
• 負荷テストは スモーク → 平均負荷 → ストレス／スパイク → 耐久 の順に進める
• 合否は thresholds（p(95)、エラー率、check成功率）で決め、CIでも判定できる
• 「1秒あたり○件」を確かめるなら 到着率方式（constant-arrival-rate）。VU方式は遅くなると負荷が下がる
• 結果は 平均ではなく p(95)・p(99) と http_req_failed、dropped_iterations を見る
• 本番環境や他人のサイトに負荷をかけない。検証環境・事前連絡・止める条件をそろえる
• v2系では --no-summary が --summary-mode=disabled に変わるなど、古い書き方に注意

株式会社RJCでは、システムの性能を確かめる方法も、プロジェクトの中で仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。