✍️ 필사 모드: ロード/パフォーマンステストツール 2026 — k6・Locust・Vegeta・Gatling・Artillery・JMeter 徹底比較(JMeter の先の風景)

プロローグ — 「毎秒1万リクエスト出せます」という嘘

2026年、ある会社のリリース前夜。

PM:「毎秒1万リクエスト出せますよね?」 バックエンド:「JMeterで回しました。通りました」 SRE:「どんなシナリオで?」 バックエンド:「constant 1万 RPS で5分…」 SRE:「production のトラフィックパターンは? warm-up は入った? p99 は?」 バックエンド:「…」

この場面は2026年でもよくある。ツールは良くなったが計測文化はそのままだ。「通った」と言うが、何が通ったのか、どんな分布の下で通ったのか、production にどれだけ近いのかは答えがない。そうしているうちにリリース後の実トラフィックは burst で来るし、キャッシュはコールド状態で始まるし、p99 は SLO を割るし、その全部が「通った」テストとは無関係に起こる。

ツール自体は良くなった。2010年代の JMeter 中心の世界は、いまや k6(Grafana) が事実上の標準となった風景に変わり、Locust・Vegeta・Gatling・Artillery・Bombardier がそれぞれの領域に居場所を持つ。マイクロベンチの領域には wrk・wrk2・autocannon が生きていて、gRPC や WebSocket のような非-HTTP プロトコルには ghz・fortio が別にいる。

この記事は2026年のロード/パフォーマンステストツールの地図を描く。各ツールの位置、同じシナリオを各ツールでどう書くか、「良いロードテスト」とは何か、そして自分のチームにどう選ぶか、まで。

1章 · ロードテストの4つの目的 — 何を計るかをまず決める

ツールを選ぶ前に 目的 を整理する。同じツールが全ての目的に合うわけではない。

1. マイクロベンチマーク (micro-benchmark) — 単一エンドポイントの上限スループットと p99 レイテンシ。「このホットパスはどれだけ速いか?」小さな変更の回帰を捕まえる用途。wrk、autocannon、Bombardier、Vegeta。
2. ロードテスト (load test) — 期待される負荷でシステムが SLO 内で動くか。通常、一定 RPS を一定時間維持。k6、Locust、Gatling、Artillery、JMeter。
3. ストレステスト (stress test) — 限界を見つける。どこで崩れるか、どう崩れるか、復旧できるか。上のツール + シナリオ設計。
4. スパイク/ソークテスト (spike & soak) — 急なトラフィック増(spike)と長時間維持(soak、メモリ・接続リークを捕まえる)。k6 と Locust がシナリオ表現に強い。

さらに カオステスト(障害注入 + 負荷)は別軸だが、ロードツールでトラフィックを流しつつ chaos tool で障害を注入する組み合わせがよくある。

要点:「パフォーマンステスト」という一語が上の4つを指し示している。ツールを選ぶときは「主にどの種類のテストをやるのか」を答えてから決める。マイクロベンチに JMeter を持ち出すのは過剰だし、複雑なシナリオに wrk を使うのは足りない。

2章 · ツール地図 2026 — 一目で

一行まとめ:2026年の「最初に手に取るツール」はおおむね k6。チームが Python 親和なら Locust。ワンライナーのマイクロベンチは Vegeta(または wrk)。エンタープライズ・JVM 親和組織と既存資産は JMeter/Gatling。Node 親和チームの速い CI シナリオは Artillery。gRPC は ghz または k6 gRPC モジュール。

3章 · k6 — 2026年の一般的既定

現在の状況 (2026年5月):Grafana Labs 傘下。k6 OSS バイナリは無料、Grafana Cloud k6 で分散実行/ダッシュボードを有料で提供。v0.5x 台の安定リリースが続いており、browser モジュール(Playwright バックエンド)・gRPC・WebSocket・xk6 拡張生態系が拡張中。

なぜ既定になったか:

• JS でシナリオを書く — 多くのエンジニアが読み書きできる。
• Go ベースの単一バイナリ — インストールが簡単。CPU 効率も良い(Locust より単一ワーカー throughput がはるかに高い)。
• 出力が豊富 — コンソールで p50/p90/p95/p99 まで既定で見える。Prometheus・InfluxDB・Datadog に export 可能。
• scenario·executor モデル — constant-vus、ramping-arrival-rate、per-vu-iterations などの表現力が良い。
• 拡張可能 — xk6 で SQL・Kafka・Redis モジュールを付けられる。

基本スクリプト(4章で比較用に再登場):

// k6 script: login + ramp 50 → 200 RPS for 5min
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  scenarios: {
    login_ramp: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 50,
      maxVUs: 500,
      stages: [
        { target: 50, duration: '1m' },
        { target: 200, duration: '5m' },
        { target: 200, duration: '2m' },
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(99)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.post('https://api.example.com/login', JSON.stringify({
    user: 'demo',
    pass: 'pw'
  }), { headers: { 'Content-Type': 'application/json' } });
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

k6 Cloud(Grafana Cloud k6)の費用感覚 (2026年基準):無料プランは月50 VUh、Pro プランは $299/月からで VUh と同時実行数の上限が増える。分散実行/地域分散が必要なら cloud オプションが楽で、代替は self-host 分散(複数ノードで同じスクリプトを実行、結果集約)。

制限:

• 分散実行は OSS では自分で構成する必要がある — k8s operator(grafana/k6-operator)はあるが運用負担。
• JS ランタイムは V8 ではなく Goja(Go に埋め込まれた ES5+)。一部のモダン JS 機能は babel transform が必要。
• データ変換の重い処理はシナリオ外でやる方が安全。

4章 · 同じシナリオ、ツール別比較 — POST /login + ramp 50 → 200 RPS

同じシナリオを k6 / Locust / Vegeta でどう表現するかを並べて見る。

k6

3章のスクリプトそのまま。要点は ramping-arrival-rate executor と thresholds で p99・失敗率をコードとして宣言。

Locust (Python)

# locustfile.py
from locust import HttpUser, task, LoadTestShape, constant_throughput

class LoginUser(HttpUser):
    wait_time = constant_throughput(1)  # 1 req/sec per user

    @task
    def login(self):
        self.client.post(
            "/login",
            json={"user": "demo", "pass": "pw"},
            headers={"Content-Type": "application/json"},
        )

class RampShape(LoadTestShape):
    stages = [
        {"duration": 60, "users": 50, "spawn_rate": 50},
        {"duration": 360, "users": 200, "spawn_rate": 5},
        {"duration": 480, "users": 200, "spawn_rate": 0},
    ]

    def tick(self):
        run_time = self.get_run_time()
        for stage in self.stages:
            if run_time < stage["duration"]:
                return (stage["users"], stage["spawn_rate"])
        return None

実行: locust -f locustfile.py --headless -H https://api.example.com。分散モードは master/worker(--master、--worker)で簡単に分けられ、k8s helm chart も有名。

Vegeta (CLI)

# step 1: 50 RPS for 1m
echo "POST https://api.example.com/login" | \
  vegeta attack -rate=50 -duration=60s -body=body.json \
                -header="Content-Type: application/json" \
  | vegeta report -type=hist[0,100ms,200ms,500ms,1s]

# step 2: 200 RPS for 5m
echo "POST https://api.example.com/login" | \
  vegeta attack -rate=200 -duration=5m -body=body.json \
                -header="Content-Type: application/json" \
  | tee result.bin \
  | vegeta report
vegeta plot result.bin > plot.html

Vegeta はシナリオ自体が単純 — 一定 rate を一定時間打つ。ramp は通常、段階別のコマンドを連ねて実行するか、シェルスクリプトで外側から作る。その単純さが強み — 一行で計測が終わり、vegeta report -type=json や vegeta plot で分布・時系列を見る。

比較観察:

• 表現力:Locust(最も自由)≈ k6 > Vegeta。Vegeta はわざと単純。
• CPU 効率:k6 > Vegeta > Locust(単一ワーカー基準; Locust は分散で補う)。
• CI 親和:k6(threshold で exit code)≈ Vegeta(report を grep)。Locust も headless で CI 可能。
• 結果可視化:k6(Grafana Cloud k6 または自前 Prometheus)> Locust(Web UI)> Vegeta(plot HTML)。

5章 · Locust — Python チームの心地よい友

現在の状況 (2026年):活発にメンテナンス中。v2.x 安定。Locust は「コードで表現可能な行動モデル」が強み。ユーザーが何をするかをクラス/メソッドで表現し、@task デコレータで重みを与える。

いつ適合するか:

• チームが Python 親和で、データ/抽象化ライブラリをそのまま呼びたいとき。
• ユーザー行動モデルが複雑(複数ページ巡回、状態保持)。
• 分散実行が必要だが別 SaaS は使いたくないとき — --master/--worker が非常に単純。

制限:

• 単一ワーカーの throughput は k6 より低い。Python の gevent ベース並行性は効率的だが Go よりは重い。
• 結果可視化は内蔵 Web UI があるが k6/Grafana 組み合わせほど豊富ではない。

ヒント:Locust の強みは 分散が簡単 という点。100k+ RPS が必要ならワーカーを数十個立てるのが自然。k8s に helm chart で立て、Prometheus にメトリクスを集めるパターンに慣れれば運用が単純になる。

6章 · Vegeta — 一行の優雅さ

現在の状況 (2026年):単一メンテナ中心でメンテナンス中。安定で単純。新機能はほぼないが、それが美徳。

なぜ Vegeta が生き残ったか:

• 一行で計測 — echo "GET https://..." | vegeta attack -rate=100 -duration=30s | vegeta report。他のツールならファイルを作って、runner を立てて、コンテナをマウントするのが vegeta は一行。
• 分布分析が正確 — vegeta report の出力に p50/p90/p95/p99/min/mean/max が一度に出る。histogram バケットも CLI で指定。
• 結果の直列化 — .bin 形式で保存して後から reproc 可能。CI で bin を artifact として保存し、後で分析。

制限:

• シナリオ表現が単純 — 一定 rate または step の連結。複雑なユーザーシミュレーションには不向き。
• 分散モードは CLI ツールなので自分で構成。通常は複数マシンで同じコマンドを実行して bin を集めて合わせる方式。

代表的な使い方:ホットパス一つのレイテンシ分布を正確に計りたいとき、CI で回帰を捕まえるマイクロベンチ、「今サーバーは生きているか」の素早いチェック。

7章 · Gatling — JVM 陣営の強者

現在の状況 (2026年):Gatling 3.x 安定。Gatling Enterprise(有料、旧 FrontLine)と OSS の両方が活発。Scala DSL が既定だが Java/Kotlin DSL も正式サポート。

なぜ今も使われるか:

• DSL の表現力 — シナリオ・チェイニング・assertion がコードのように自然。
• レポート — HTML レポートが非常に綺麗。Enterprise は分散/チーム協業。
• JVM 親和組織 — Maven/Gradle ビルドに自然に入る。
• Scala 学習コストは下がった — Java DSL が一級市民に。

いつ適合するか:

• JVM ベースのバックエンドを持つ組織、ビルドシステムに統合したいとき。
• シナリオが複雑でコードレビュー可能な形にしたいとき。
• エンタープライズサポートが必要な環境。

制限:

• 軽いワンライナー計測には不向き — JVM 起動・SBT/Maven のコスト。
• Scala の参入障壁は減ったがゼロではない。

8章 · Artillery — YAML シナリオの手軽さ

現在の状況 (2026年):OSS + Cloud(有料)。YAML でシナリオを表現するのが魅力。最近 v2 から分散実行(Cloud)オプションも強化された。

なぜ使われるか:

• YAML シナリオ — コードを書かずに「URL・ペイロード・フロー」を宣言的に。
• Node.js ベース — Node チームに親しい。
• 起動が速い — npm install -g artillery 後、yml ファイル一つで実行。

制限:

• 単一ノード throughput は k6 より低い(Node イベントループの限界)。
• 非常に大きな負荷では Cloud または複数インスタンスが必要。

例(少し違う形式で):

config:
  target: 'https://api.example.com'
  phases:
    - duration: 60
      arrivalRate: 50
    - duration: 300
      arrivalRate: 50
      rampTo: 200
    - duration: 120
      arrivalRate: 200
scenarios:
  - flow:
      - post:
          url: '/login'
          json:
            user: 'demo'
            pass: 'pw'
          expect:
            - statusCode: 200

9章 · JMeter — 生きている古参

現在の状況 (2026年):Apache JMeter 5.x メンテナンス中。学習資料が最も多く、プラグイン生態系が最も広い。GUI 中心だがヘッドレス実行も正式サポート。

なぜ今も見えるか:

• 既存資産 — 多くの組織が .jmx ファイルを持っている。移行コスト vs. 維持コスト。
• プラグイン — Prometheus listener、custom protocol、BlazeMeter 統合など。
• 金融・通信などのエンタープライズ — 社内標準が JMeter の場合。
• GUI 親和 — コードを知らない QA が使いやすい(長所と短所の両面)。

なぜ新規チームはほぼ選ばないか:

• XML(.jmx)シナリオ — git diff 親和ではない。
• モダン UX・CLI 親和が弱い。
• CI 統合は可能だが k6/Locust より手間。

ガイド:新規プロジェクトで JMeter を新たに選ぶ理由はほぼない。ただし 既存資産があるなら それを捨てて移行するコストは別の決定。段階的に新しいテストは k6/Gatling で書き、既存は維持するパターンがよく見られる。

10章 · マイクロベンチマーク — wrk / wrk2 / autocannon / Bombardier

この4つのツールは「一つのエンドポイントの上限 throughput とレイテンシ分布」を素早く取るのに特化している。

wrk

• C で書かれており、非常に速い。Lua スクリプトで少しのカスタマイズ。
• HTTP のみ、keep-alive 親和。
• 短所:rate-limit がない — 上限 throughput を測るので常に max 負荷。

wrk2

• wrk の fork。固定 rate をサポート — 「正確に1000 RPS を30秒間」のような計測が可能。
• マイクロベンチ + 固定 rate 計測に最適。
• coordinated omission 補正に強み。

autocannon

• Node.js ベース。npm install -g autocannon 後、autocannon -c 50 -d 30 https://...。
• Node 親和チームの速い CI ベンチに適合。

Bombardier

• Go 単一バイナリ。非常に単純で速い。bombardier -c 125 -n 1000000 https://...。
• シナリオ表現がほぼないが、それが核心。
• メンテナ活動はあるが新機能より安定維持モード。

いつ何を:

• 正確なレイテンシ分布と固定 rate が必要 → wrk2。
• とにかく速く一度負荷 → wrk または Bombardier。
• Node チームで CI 統合 → autocannon。
• シナリオが少しでも必要 → この4つではなく Vegeta または k6。

11章 · 非-HTTP プロトコル — gRPC、WebSocket、ブラウザ

2026年の負荷計測は HTTP だけではない。gRPC・WebSocket・実ブラウザ(Headless Chrome)すべて計測対象。

gRPC

• ghz — gRPC 専用 CLI ツール。ghz --insecure --proto ./svc.proto --call svc.Hello -c 50 -n 10000 ...。単純で正確。
• k6 gRPC モジュール — import grpc from 'k6/net/grpc'。シナリオの中に gRPC 呼び出しを混ぜられる。
• fortio — Istio 出身。HTTP + gRPC の両方、p50–p999 分布分析に強い。

WebSocket

• k6 WS モジュール — import ws from 'k6/ws'。接続数・メッセージ RPS・セッション長シナリオ可能。
• Artillery — WS を基本サポート、YAML でシナリオ。
• Gatling — WS シナリオ表現力が良い。

ブラウザ(Real Browser Load)

• k6 browser モジュール — Playwright バックエンド。実ブラウザで JS 実行・レンダ・ページ相互作用を計測。使用例:フロントエンド回帰、ページロード SLO。
• 費用注意:ブラウザインスタンスは重いので RPS ではなく同時セッション数で考える。

12章 · 「良いロードテスト」とは何か — 2026 チェックリスト

ツールが良くてもシナリオが悪ければ結果も悪い。良いロードテストの核心。

1) production-like なデータ

• ユーザー ID、ペイロードサイズ、トークン分布が production に似ている必要がある。
• 「一人のユーザーが同じページを1万回」はキャッシュに全部収まる — production はそうではない。
• production で sampling したペイロードを anonymize して使うパターン。

2) 一定 rate ではなく分布

• 「constant 1000 RPS」は measurement 用であり reality から遠い。
• production は burst・dip・diurnal パターンを持つ。
• k6 の ramping-arrival-rate、Locust の LoadTestShape でシナリオをモデリング。

3) warm-up と ramp-up

• キャッシュ・DB コネクションプール・JIT がコールド状態で始まる計測は常に悲観的。
• 最初の1~2分は warm-up として計測区間から除外。

4) p99 (avg ではなく)

• 「平均レイテンシ」は SLO の友達ではない。平均は long-tail を隠す。
• p95・p99・p999(特に p99)が SLO と直結する。全てのツールの出力で percentile を確認。
• 計測ツールが coordinated omission で p99 を低く報告することがある — wrk2 がこの問題に最初によく対処した。

5) error rate の分離

• 成功応答のみでレイテンシを取ると死んだリクエストが見えなくなる。
• 4xx・5xx・timeout・connection refused を別々にカウントし、閾値を設定。

6) 複数の計測点

• 負荷ツールのクライアント側レイテンシだけでなく、サーバー側 RED(Rate・Error・Duration)メトリクス、downstream 依存関係も一緒に見る。
• 負荷ツールが「遅い」と報告するのにサーバーメトリクスは速い → ネットワーク/計測問題。その逆もある。

7) 一度ではなく定期的

• リリース前の一度ではなく、週次・月次の回帰テストとして置く。
• コード変更がレイテンシ分布に与えた影響を時系列で。

13章 · self-host と cloud — コストと運用

分散実行が必要になると二つの道。

Self-host 分散

• k6 OSS + grafana/k6-operator (k8s) — pod で実行、結果を Prometheus/InfluxDB に。
• Locust master/worker — 最も単純。helm chart でワーカー N 個立てる。
• 複数ノードで同じコマンド + 結果マージ — vegeta・wrk・Bombardier 式アプローチ。

長所:コスト制御、データがインハウス。短所:運用負担、地域分散が難しい。

Cloud

• Grafana Cloud k6 — 分散実行、地域、ダッシュボード。月 $299 から。
• BlazeMeter — JMeter/Gatling/k6 互換、エンタープライズ SaaS。
• Artillery Cloud — Artillery ベース SaaS。
• Loader.io、k6 Cloud — 小さな負荷計測用の無料ティアから。

長所:地域分散・即時実行・ダッシュボードが即時。短所:コスト(週1回大きなテストなら月数百~数千ドルに早く到達)。

経験則:単発の大型計測(リリース前)は cloud が安くて速い。定期回帰テストは self-host が長期的に安い。両方を混ぜる組織が多い — 日常 CI は self-host、四半期ごとの大規模は cloud。

14章 · ツールを選ぶ決定フレーム — 正直なガイド

混ぜるのはよくある。 一つの組織内でマイクロベンチは Vegeta、一般負荷は k6、既存の大きなシナリオは JMeter — こういう組み合わせが現実の姿。ツールを統一しようと無理せず、領域別に適切なツールを認めるのが運用を単純にする。

15章 · アンチパターンと罠

• production で直接負荷テスト — staging または隔離された production-like 環境で行う。production canary は別の技法。
• DNS・CDN を通過せず origin に直接 — 計測は通るが SLO は CDN 込み。計測経路が user path と同じである必要。
• localhost で計測して結論 — ネットワークレイテンシが0なので RPS だけ見ると偽の安全感。
• constant rate 一度で通過宣言 — production は分布。
• 平均レイテンシだけ見る — p99 を見る。
• 負荷ツールだけ見る — サーバーメトリクスと一緒に。
• リリース前の一度 — 回帰テストとして置く。
• wrk でシナリオを計測 — シナリオは wrk の仕事ではない。
• 分散を組まず単一ノードで100k RPS を試みる — ツールの限界をシステムの限界と誤認。

エピローグ — 計測は決定のためのツール

ツールは豊富。JMeter が標準だった時代は去り、k6 が事実上の既定になった。Locust は Python 親和組織の良き友、Vegeta は一行計測の優雅さ、Gatling は JVM 陣営の強者、Artillery は速い起動、wrk/wrk2/autocannon/Bombardier はマイクロベンチの単純さ。

しかしツールが結果を作るのではない。シナリオが production に似ているか、percentile を見たか、warm-up を置いたか、回帰として置いたか が結果を作る。ツールを選んだ後の仕事の方が長くて重要。

この記事の一文要約:「うまく動きます」は計測ではない。p99・分布・シナリオで答えてこそ計測である。 ツールはその答えを可能にする手段に過ぎず、答え自体は自分たちで定義する必要がある。

12項目チェックリスト

1. 目的が明確か(マイクロ/負荷/ストレス/スパイクのいずれか)?
2. production-like なデータを使っているか?
3. constant rate ではなく分布・ramp をモデリングしたか?
4. warm-up 区間を計測から除外したか?
5. p99(または p999)を SLO に紐づけたか?
6. error rate をレイテンシから分けて見たか?
7. クライアント側 + サーバー側のメトリクスを一緒に見たか?
8. CI に回帰として入っているか?
9. 分散が必要なときに self-host/cloud の決定をしたか?
10. 非-HTTP プロトコルがあるならそのツールも併用しているか(gRPC/WS/ブラウザ)?
11. 計測経路が user path と一致しているか(DNS・CDN 込み)?
12. coordinated omission 補正を理解しているか?

アンチパターン10

1. 平均レイテンシだけ見る — p99 を見る。
2. constant rate 一度で通過宣言 — 分布をモデリング。
3. localhost で計測して結論 — ネットワークがない。
4. production で直接負荷 — staging で。
5. 負荷ツールだけ見る — サーバーメトリクスと一緒に。
6. リリース前一度 — 定期回帰として。
7. JMeter で全部やる — 領域別にツールを。
8. 分散を組まず単一ノードで無理 — ツール限界 ≠ システム限界。
9. warm-up 無視 — 序盤データが結論を歪める。
10. error rate 抜け — 死んだリクエストが見えない。

次の記事予告

次の記事候補:production における信号とノイズ — RED・USE・SLO ダッシュボード設計、chaos engineering 2026 — Litmus・Chaos Mesh・Gremlin・AWS FIS 比較、performance regression CI — 一行から分布まで。

「計測できるものが改善できるもの。そして分布を見なければ計測ではない」

— ロード/パフォーマンステストツール 2026、終わり。

参考 / References

• k6 — Grafana Labs
• k6 GitHub — grafana/k6
• k6 Documentation
• k6 Cloud Pricing — Grafana Cloud k6
• k6 Operator — grafana/k6-operator
• k6 browser module
• Locust — Python load testing
• Locust GitHub — locustio/locust
• Locust Documentation
• Vegeta GitHub — tsenart/vegeta
• Gatling — Open source load testing
• Gatling GitHub — gatling/gatling
• Artillery — Cloud-scale load testing
• Artillery GitHub — artilleryio/artillery
• Apache JMeter
• wrk GitHub — wg/wrk
• wrk2 GitHub — giltene/wrk2
• autocannon — Node.js HTTP benchmark
• Bombardier — Go HTTP benchmark
• ghz — gRPC benchmarking
• fortio — load testing library and tool
• BlazeMeter — Performance testing platform
• Coordinated Omission — Gil Tene
• Google SRE Book — Monitoring distributed systems
• Brendan Gregg — USE Method