💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「本番で最初に目にする負荷の形は、負荷テストで一度も見たことがない形だ。」 — Tammy Bützer, Grafana k6 maintainer, KubeCon EU 2024

パフォーマンステストはソフトウェアエンジニアリングで最も古い分野の一つですが、2026年の風景は2016年とほとんど似ていません。一方では1998年に登場した Apache JMeter が25年以上生き残り、いまだ最大のインストールベースを誇ります。もう一方では、Grafana が2021年に買収した k6 が **2024年に v1.0 GA** に到達し、事実上の「モダンスタンダード」となりました。その間に Locust、Gatling、Artillery のようなコードファーストなツールが定着し、Vegeta・hey・wrk・oha・autocannon・Bombardier のような CLI 一行ベンチマークが「シナリオを書く前にまず RPS だけ見せて」という需要を満たしています。

本記事は2026年5月時点での負荷テスト(Load testing)とブラウザ性能測定(Browser performance)のツール風景を一気に巡る徹底ガイドです。バックエンド負荷ツール16種 + ブラウザツール4種 + Core Web Vitals + 日韓事例まで扱います。

1. 2026年の負荷テスト地図 — DSL / スクリプト / CLI ベンチマーク / ブラウザ perf

負荷テストは単一カテゴリではありません。「ツール X と Y はどちらがいいか」という問いは、実は別の箱に入った2つを比較していることがほとんどです。2026年時点で最もきれいな分類は次の4つの箱です。

| カテゴリ | 代表製品 | 何をするか |

|---|---|---|

| スクリプト(コードファースト)負荷テスト | k6, Artillery, Locust, Gatling, JMeter | コード/DSL でユーザーシナリオ定義、分散実行、時系列メトリクス |

| 一行 CLI ベンチマーク | hey, wrk, oha, Vegeta, autocannon, Bombardier | 1つの URL を固定 RPS/並列で叩き、p50/p95/p99 だけ見る |

| エンタープライズ SaaS / オンプレ | BlazeMeter, LoadRunner, NeoLoad, Azure Load Testing | GUI・録画・監査・規制業界対応、JMeter/k6 互換 |

| ブラウザ perf / RUM | Lighthouse, WebPageTest, SpeedCurve, Calibre, Cloudflare RUM | 実ブラウザで LCP/INP/CLS 測定、回帰監視 |

この記事の核心は単純です。**2026年に新しい負荷テストプロジェクトを始めるなら、90%のチームは k6 で始めるべきで、10%は Locust か JMeter を選ぶべきです。** Locust はチームが100% Python に親和的なとき、JMeter は規制業界で監査対象が GUI スクリプトであるときです。一行ベンチマークが必要なときは oha か Vegeta を PATH に置いておけば十分です。

この結論にどう至ったかが、この記事の残りです。

2. k6 v1.0 (Grafana) — JS スクリプトの標準

Grafana k6 は2017年に Load Impact が Go で書いてオープンソース化した負荷テストツールです。2021年に Grafana Labs が Load Impact を買収し、フルタイムメンテナーが付き、2024年春に **k6 v1.0** が API 凍結とともに正式リリースされました。2026年現在、GitHub スター27k 超、週次ダウンロード数で JMeter を急速に追い越しています。

k6 のコア選択は「Go ランタイム上で goja(JavaScript インタープリタ)を動かす」ことです。ユーザーは JS/TS でシナリオを書きますが、負荷発生器自体は Go なので、1台のマシンで数万 VU(仮想ユーザー)を安定して作れます。Python ベースの Locust や JVM ベースの JMeter/Gatling よりメモリ・CPU 効率が明確に優れます。

基本スクリプトは次のような形です。

export const options = {

scenarios: {

ramp_up: {

executor: 'ramping-vus',

startVUs: 0,

stages: [

{ duration: '30s', target: 100 },

{ duration: '2m', target: 100 },

{ duration: '30s', target: 0 },

thresholds: {

http_req_duration: ['p(95)<500', 'p(99)<1500'],

http_req_failed: ['rate<0.01'],

}

export default function () {

const res = http.get('https://api.example.com/products')

check(res, {

'status is 200': (r) => r.status === 200,

'body has items': (r) => r.json('items').length > 0,

})

sleep(1)

}

`executor`(生成器)は7種類で豊富です。`constant-vus`(固定 VU)、`ramping-vus`(増減)、`constant-arrival-rate`(固定到着率 — これが本物の RPS)、`ramping-arrival-rate`、`per-vu-iterations`、`shared-iterations`、`externally-controlled`。実務では「この API を5分間 1000 RPS で叩きたい」という要求を `constant-arrival-rate` で正確に表現できる点が決定的です。

`thresholds`(閾値)は **負荷テストを CI ゲートに変える唯一の機能** です。p95 が 500ms を超えたら終了コード 99 で抜け、GitHub Actions が赤くなります。これがなければ負荷テストはグラフを眺めるだけで終わります。

2024年の v1.0 以降に追加された主な機能:

- **Browser モード**: Playwright Chromium を立ち上げて実ページを測定。負荷テストと同時に CWV(LCP, INP, CLS)を追跡

- **gRPC、WebSocket、Redis、Kafka** のプロトコルモジュール

- **Extensions (xk6)**: Go でモジュールを書き、k6 バイナリにビルドして合体する方式。60超の公式・コミュニティ拡張

- **Distributed mode**: Kubernetes オペレーター(`k6-operator`)でマルチノード実行

- **k6 Cloud → Grafana Cloud k6**: マネージド負荷発生器 + ダッシュボード統合

CLI 出力はテキスト1画面に集約されます。

running (2m00.0s), 000/100 VUs, 11947 complete and 0 interrupted iterations

ramp_up [======================================] 100/100 VUs 2m0s

checks.........................: 100.00% 23894 ✓ 0 ✗

http_req_duration..............: avg=87.2ms p(95)=312.5ms p(99)=482.1ms

http_req_failed................: 0.00% 0 / 23894

http_reqs......................: 23894 199.117/s

iteration_duration.............: avg=1.08s

✓ http_req_duration..p(95)<500

✓ http_req_duration..p(99)<1500

✓ http_req_failed..rate<0.01

k6 の弱点は2つ。第一に、JavaScript ですが **goja は Node.js ではありません**。`npm install` で任意パッケージを使えません。別途バンドラー(`k6-browserify` か webpack)でトランスパイル・バンドルしてから import する必要があります。第二に、async/await が v0.43 以降一部モジュールでのみサポートされています。複雑なビジネスロジックをシナリオに入れるとデバッグが辛いです。

それでも、2026年の新規プロジェクトのデフォルトは k6 です。単一バイナリ、JS シナリオ、堅牢な閾値、Grafana 統合 — この4つの組み合わせで他ツールが追いついていません。

3. Artillery — Node.js + サーバーレスワーカー

Artillery は2015年に Hassy Veldstra が Node.js で書いた負荷テストツールです。2022年に会社化(Artillery Inc., シリーズ A)し、2026年現在は OSS 版と Artillery Cloud(SaaS)の2ラインを運用しています。

Artillery の大きな特徴は2つです。**第一に、シナリオを YAML で書きます。** 関数型 JS コードではなく宣言型 YAML という点が分岐点です。第二に、**AWS Fargate / Azure Container Instances にワーカーを launch して事実上無限の分散負荷発生**ができます(Artillery Pro / Cloud)。

YAML シナリオはこんな形です。

config:

target: https://api.example.com

phases:

- duration: 60

arrivalRate: 10

name: warm up

- duration: 300

arrivalRate: 100

name: sustained load

defaults:

headers:

User-Agent: artillery-loadtest

ensure:

p95: 500

maxErrorRate: 1

scenarios:

- name: browse and buy

flow:

- get:

url: /products

capture:

- json: $.items[0].id

as: productId

- get:

url: /products/{{ productId }}

- post:

url: /cart

json:

productId: "{{ productId }}"

quantity: 1

- think: 2

YAML という選択は **好みが分かれます**。非開発者の QA がシナリオを書くときは敷居が下がりますが、分岐・繰り返し・計算が入ると JS/プラグインを呼ばざるを得ません。Artillery は `processor: ./hooks.js` で JS 関数を差し込む拡張点を用意しています。

2024年に追加された **Artillery Pro AI** は OpenAPI/Swagger スペックを受け取って自動でシナリオ YAML を生成します。100エンドポイントを持つマイクロサービスに5分でベースラインシナリオを作ってくれ、実務では「下書き90% + 人手仕上げ10%」のモデルでよく動きます。

Artillery の真の強みは分散です。`artillery run-fargate scenario.yml --count 20 --region us-east-1` の一行で20個の Fargate ワーカーを立ち上げ、合算 RPS を作ります。k6 で同じことをするには k6-operator と Kubernetes クラスターが必要です。CI で「既存インフラなしで即座に爆発的負荷」が必要なチームに向いています。

弱点は OSS 版の機能制約(分散・Cloud ダッシュボードは有料)と、シナリオが大きくなると YAML がすぐ醜くなる点です。

4. Locust — Python 分散

Locust は2011年に Jonatan Heyman が始めた Python ベースの負荷テストツールです。2026年現在 GitHub スター25k、事実上 Python 陣営の標準です。

Locust のアイデンティティは「**Python コードでユーザー(User)を定義する**」の一文に尽きます。

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):

wait_time = between(1, 3)

host = "https://api.example.com"

def on_start(self):

self.client.post("/login", json={"user": "test", "pw": "demo"})

@task(3)

def browse_products(self):

with self.client.get("/products", catch_response=True) as resp:

if resp.elapsed.total_seconds() > 0.5:

resp.failure("Too slow")

@task(1)

def view_product(self):

self.client.get("/products/42")

@task

def search(self):

self.client.get("/search?q=keyboard")

`@task(weight)` でアクションの比重を決め、`wait_time` でユーザーの思考時間(Think time)を模します。Python らしく SQLAlchemy・Pandas・NumPy のようなライブラリをシナリオに引き込めます。データサイエンスチームや ML 推論サーバーをテストするとき決定的な差になります。

分散実行は master/worker モードで単純です。

master

locust -f locustfile.py --master --expect-workers 4

ワーカー4台(Docker Swarm・k8s・EC2 どこでも)

locust -f locustfile.py --worker --master-host master.example.com

ポート 8089 で Web UI が立ち、グラフとリアルタイムメトリクスを表示します。非開発者の PM/QA にとって大きな利点です。2024年に追加された `--processes` オプションは1台でマルチプロセス化して GIL を回避し、CPU コアを全部使えます。

弱点は2つ。**第一に、GIL と gevent 依存のため、1ワーカーあたりの負荷生成量が k6 の 1/3〜1/5 です。** 分散が事実上必須です。**第二に、グラフと閾値が貧弱です。** CI ゲートに使うには終了後の stats CSV を読んで自前判定スクリプトを書く必要があります。

それでもチームが100% Python なら、第一選択肢として遜色ありません。

5. JMeter 5.6 — Apache クラシック

Apache JMeter は1998年初リリース以来27年生き続ける負荷テストの生きた化石です。2024年リリースの **5.6** が2026年現在の LTS、6.0 アルファが一部ユーザーに公開されています。

JMeter は **GUI ファースト** ツールです。シナリオを `.jmx` という XML ファイルとして保存し、GUI でツリー(Thread Group → HTTP Sampler → Listener)を組んでシナリオを書きます。コードを一行も書かずに5分で最初の負荷テストを作れます。この敷居の低さが2026年も JMeter が死なない理由です。

CI では GUI なしで `jmeter -n -t plan.jmx -l results.jtl` のように non-GUI モードで動かします。**GUI はシナリオを作るときだけ**、**実行は常に non-GUI** が公式推奨です(GUI 自体の負荷が大きい)。

JMeter の真の武器は **サンプラー(Sampler)プールの深さ** です。HTTP・HTTPS はもちろん JDBC、LDAP、SOAP、SMTP、IMAP、JMS、FTP、MongoDB まで — 1ツールでほぼ全てのプロトコルに負荷をかけられます。2010年代の SOA 時代に育ったエンタープライズシステムをテストするとき決定的です。

2026年でも JMeter を選ぶべき場合は明確です。

- 規制業界(金融・医療・公共):**再現可能な GUI スクリプトが監査(Audit)成果物として要求される**

- 大企業 QA 組織:社内標準が JMeter で50人以上が使用中

- SOAP・JMS・JDBC のような非 HTTP プロトコル比重が50%以上

- BlazeMeter SaaS と組み合わせてクラウド分散を使いたい

新規グリーンフィールドプロジェクトには勧めません。XML ファイルは Git マージが地獄、閾値は貧弱、メモリ使用量も多い(単一 JVM で 1000 VU 超えると GC 圧力)。

6. Gatling — Scala / Kotlin DSL

Gatling は2012年に Stéphane Landelle が Scala で作った負荷テストツールです。2026年現在 OSS Gatling 3.11 と商用 Gatling Enterprise(旧 FrontLine)があります。2023年に **Kotlin DSL と Java DSL** が正式サポートされ、Scala の敷居が消えました。

Gatling の2つの自慢は(1)**型安全ビルダー DSL** と(2)**HTML レポートの美しさ** です。

class DemoSimulation extends Simulation {

val httpProtocol = http

.baseUrl("https://api.example.com")

.acceptHeader("application/json")

val browse = scenario("Browse")

.exec(http("get products").get("/products").check(status.is(200)))

.pause(1)

.exec(http("get product 42").get("/products/42"))

setUp(

browse.inject(

rampUsersPerSec(1).to(100).during(30.seconds),

constantUsersPerSec(100).during(2.minutes)

)

).protocols(httpProtocol)

.assertions(

global.responseTime.percentile(95).lt(500),

global.failedRequests.percent.lt(1)

)

}

`rampUsersPerSec`、`constantUsersPerSec` のような injection プロファイルが豊富で、`.check()` DSL はコンパイル時に検証されタイポでビルドが壊れます。実行が終わると HTML レポートが自動生成され、パーセンタイル分布・時系列応答時間・リクエスト種別グラフが1画面にきれいに整理されます。役員報告にそのまま投げられます。

Kotlin DSL の例:

class DemoSimulation : Simulation() {

val httpProtocol = http.baseUrl("https://api.example.com")

val browse = scenario("Browse")

.exec(http("get").get("/products").check(status().`is`(200)))

init {

setUp(browse.injectOpen(rampUsers(100).during(30)))

.protocols(httpProtocol)

}

Gatling が輝く場所は **JVM バックエンド(Spring Boot, Quarkus, Micronaut)をテストする JVM チーム** です。同じ Maven/Gradle ビルドの中で負荷テストが回り、JVM チューニングのノウハウがそのまま効き、レポートが韓国大企業の役員が好む程度には綺麗です。弱点は学習コスト(Scala/Kotlin いずれも JVM DSL が初めてだと数日かかる)と、OSS 分散機能が弱いこと(分散は Enterprise 有料)です。

7. Vegeta / hey / wrk / oha / autocannon / Bombardier — CLI ベンチマーク

負荷テストの80%はシナリオが要りません。「この URL を 1000 RPS で30秒叩いたらどうなるか」だけ知りたいケースが圧倒的です。このときに使うのが **一行 CLI ベンチマーク** です。

**hey**(旧 boom)。Go 製、最もシンプル。オプションは `-z`(duration)、`-c`(concurrency)、`-q`(QPS)の3つで十分。

hey -z 30s -c 50 -q 100 https://api.example.com/products

**wrk**。C 製、1台の最大スループット。Lua スクリプトでヘッダ・ボディ・リクエスト分岐可。欠点は macOS の Homebrew ビルドが時々ずれること、出力がテキストのみで後処理が面倒なこと。

wrk -t 8 -c 100 -d 30s --latency https://api.example.com/products

**Vegeta**。Go 製、`attack | report | plot` パイプラインモデルが決定的。結果を binary で書き出し、複数のレポート(JSON, HTML, plot)に加工できます。

echo "GET https://api.example.com/products" | \

vegeta attack -duration=30s -rate=100/s | \

tee results.bin | \

vegeta report -type=text

vegeta report -type=json < results.bin > results.json

vegeta plot < results.bin > plot.html

**oha**。Rust 製、2021年登場。2026年現在最もホットな CLI ベンチマークツールです。**hey 互換 CLI に TUI(ターミナルチャート)がリアルタイムで描画されます。** 一度見ると hey に戻る理由がありません。

oha -z 30s -c 50 -q 100 https://api.example.com/products

TUI 画面で RPS、レイテンシ p50/p95/p99、ステータス分布がリアルタイム ASCII チャートで更新されます。CI では `--no-tui --json` で JSON を落とします。

**autocannon**。Node.js 製。`npx autocannon` 一行で即実行でき、Node サーバーをテストするとき同じランタイムであることが親近感を生みます。Fastify チームの公式ベンチツール。

npx autocannon -c 100 -d 30 https://api.example.com/products

**Bombardier**。Go 製。HTTP/2 サポート、JSON 出力、単一バイナリ。Windows で最も無難に動きます。

bombardier -c 100 -d 30s -l https://api.example.com/products

6ツールを表に:

|---|---|---|---|---|---|

| hey | Go | なし | なし | × | 最もシンプル、昔から慣れている |

| wrk | C | Lua | なし | × | 1台最大スループット |

| Vegeta | Go | なし | HTML plot | × | 結果を binary で加工 |

| Bombardier | Go | なし | なし | ○ | Windows、JSON 出力 |

2026年の推奨は単純です。**oha を PATH に置いてまずそれを使う。** TUI のおかげで初見でも何が起きているか即座にわかり、Vegeta のように結果ファイルで後処理する必要が出たら Vegeta を追加します。

8. BlazeMeter / LoadRunner / NeoLoad — エンタープライズ

エンタープライズ SaaS 市場は OSS とは別の世界です。コア差別化は **(1) 監査・調達書類、(2) クラウド分散負荷発生器、(3) GUI レコーディング(ブラウザ操作を録画してシナリオ化)、(4) APM 統合** の4つです。

**BlazeMeter**(Perforce、旧 CA)。JMeter・Gatling・k6・Selenium スクリプトをそのまま受け取り、クラウドで分散実行します。2024年に **AI Co-Pilot** がリリースされ、シナリオ自動生成・結果自動分析を提供。一度に100万同時ユーザーまで合法的に作れるインフラが真の商品です。

**LoadRunner**(Micro Focus → OpenText、2023年に買収)。1994年に Mercury Interactive で始まった負荷テストの元祖。2026年現在 LoadRunner Professional、LoadRunner Enterprise、LoadRunner Cloud の3ライン。SAP、Oracle Forms、Citrix、RDP のような **レガシー・産業プロトコルでほぼ独占** です。ライセンス費用が高いことで有名(年数万〜数十万ドル)。

**NeoLoad**(Tricentis)。2014年に Neotys が開始、2021年に Tricentis が買収。JMeter・Selenium スクリプト互換に CI/CD 統合が強いです。2025年リリースの **NeoLoad Web 2.0** が SaaS 化を加速しました。ヨーロッパ系大企業(特に金融)で採用率が高いです。

**Azure Load Testing**(Microsoft)。2022年 GA。本質的に **マネージド JMeter + k6** です。`.jmx` や k6 JS ファイルをアップロードすれば Azure が発生器を立ち上げて実行し、Application Insights と連動したメトリクスを表示します。Azure 中心組織には調達手続きなしで即使える利点が大きいです。

**Cloudflare Load Balancing test mode**。2025年に追加された機能。本番トラフィックをシャドウとして新オリジンに流し、負荷と正確性を同時に検証します。厳密には負荷「テスト」ツールではなく **production shadowing** ですが、同じ箱に置く価値はあります。

エンタープライズ SaaS を選ぶべきサイン3つ:

1. 社内セキュリティチームが「社外インターネットから自社サーバーに負荷をかけるツールの出所を監査せよ」と要求するとき

2. 100万同時ユーザーのような **巨大規模** が必要だが自前 k6/k8s 運用人員がいないとき

3. SAP、Citrix、Oracle Forms のような **レガシープロトコル** テスト — LoadRunner 以外に答えなし

それ以外は、OSS k6 + Grafana Cloud k6 SaaS の組み合わせが圧倒的にコスト効率が良いです。

9. Chaos Mesh + カオスエンジニアリング — 隣接領域

厳密には、カオスエンジニアリングは負荷テストの兄弟であって同じツールではありません。負荷テストが「正常状態でトラフィックが増えたらどうなるか」を見るとすれば、カオスエンジニアリングは「異常状態(ノードダウン、ネットワーク遅延、ディスク満杯)でシステムがどう崩れるか」を見ます。

2026年の主要カオスツール:

| ツール | 環境 | 特徴 |

|---|---|---|

| Chaos Mesh | Kubernetes | CNCF Graduated(2024)、11種の fault タイプ、ダッシュボード |

| LitmusChaos | Kubernetes | CNCF Incubating、ChaosHub 実験ライブラリ |

| Gremlin | SaaS | 商用、ブラスト半径セーフガード、エンタープライズ |

| AWS Fault Injection Service (FIS) | AWS | マネージド、EC2/RDS/ECS/EKS アクション |

| Azure Chaos Studio | Azure | マネージド、Azure リソース fault |

負荷テストとカオスエンジニアリングを組み合わせて回すパターンが2025年から定着しました。k6 で 500 RPS を作った状態で Chaos Mesh で pod を30%殺せば、HPA・readiness probe・サーキットブレーカーが全て正しく動くかを一度に検証できます。CNCF の **Chaos Engineering Working Group** が2026年にベストプラクティス文書を発表予定です。

10. ブラウザ perf — Lighthouse / WebPageTest / SpeedCurve / Calibre

ブラウザ性能はバックエンド負荷テストとは完全に別の箱です。バックエンド負荷は「サーバーが RPS に耐えるか」を問いますが、ブラウザ perf は「**ユーザーがページを速いと感じるか**」を問います。

**Lighthouse**。Google 製の OSS 監査ツール。Chrome DevTools に内蔵、CLI/Node API 提供、CI 統合(`lighthouse-ci`)。1ページを1回測定して Performance/Accessibility/Best Practices/SEO スコアを100点満点で付けます。単一測定なので変動が大きい点が弱点。

npx lighthouse https://example.com \

--output=json --output=html --output-path=./report

**WebPageTest**(現 Catchpoint)。2008年に Patrick Meenan が開始、2020年に Catchpoint が買収。世界50+地域の実ブラウザ(Chrome, Firefox, Edge)でページを測定します。**Waterfall、filmstrip、video** 出力が最高水準。無料のインタラクティブ UI と WebPageTest API、プライベートインスタンスオプションも。

WebPageTest API 呼び出し

webpagetest test https://example.com \

--location ec2-us-east-1:Chrome \

--connectivity 4G --runs 3 --first

**SpeedCurve**。Mark Zeman / Steve Souders 製の有料 SaaS。**合成(Synthetic) + 実ユーザー(RUM)** モニタリングを1ダッシュボードに統合。毎日自動測定・回帰アラート。UX/デザイン親和的な可視化が強みです。

**Calibre**。Karolina Szczur 製の有料 SaaS。Lighthouse + WebPageTest を組み合わせ、perf budget をコードで定義(YAML)、CI ゲート化します。小さなチームが合理的なコストで導入できる位置取りです。

.calibre.yml 例

budgets:

- metric: largest-contentful-paint

budget: 2500

- metric: cumulative-layout-shift

budget: 0.1

- metric: interaction-to-next-paint

budget: 200

**RUM 測定ツール**(Real User Monitoring): Cloudflare Web Analytics、Vercel Speed Insights、Google Search Console の CrUX、Sentry Performance、New Relic Browser、Datadog RUM。実ユーザーブラウザから送られた CWV テレメトリを集計します。

ブラウザ perf は **合成測定(Synthetic、統制環境での反復測定)** と **RUM(Real User Monitoring、実ユーザーテレメトリ)** の両方が必要です。合成だけでは「ラボでは速いがユーザーの電話では遅い」差を掴めず、RUM だけでは回帰原因のデバッグが難しいです。

11. Core Web Vitals — INP が FID を置き換え

Core Web Vitals(CWV)は Google が2020年に発表したユーザー体感性能3大指標です。2024年3月に **INP(Interaction to Next Paint)が FID(First Input Delay)を公式に置き換え**、測定方式が変わりました。2026年5月現在の公式3大指標は次の通り。

|---|---|---|---|---|

| LCP (Largest Contentful Paint) | 最大コンテンツが描画された時点 | `<2.5s` | `2.5s-4s` | `>4s` |

| INP (Interaction to Next Paint) | 全インタラクションの中で最も遅い遅延 | `<200ms` | `200-500ms` | `>500ms` |

| CLS (Cumulative Layout Shift) | 累積レイアウトシフトスコア | `<0.1` | `0.1-0.25` | `>0.25` |

INP が FID を置き換えた理由は明確です。FID は最初の入力1回しか測らず「もう簡単すぎる(ほぼ全サイトが Good)」という批判があり、ユーザーの実体験と乖離していました。INP は **ページ生存期間中の全インタラクションを追跡し、98 パーセンタイル(P98)** を見ます。これがユーザーが「カクつく」と感じる本当の瞬間です。

INP に影響する最大の要因は **メインスレッド作業時間** です。React/Vue/Svelte の重いレンダー、肥大化した hydration、同期的なサードパーティスクリプトが主犯です。2024-2025年に React 19 Server Components、Next.js 15 PPR(Partial Prerendering)、Astro Islands のような **メインスレッド負担減らし** の流れが加速したのはここに理由があります。

CWV 回帰を捕まえる実務ワークフローは次の4ステップ:

1. 合成測定(Lighthouse CI か Calibre)で main ブランチマージ時点の変動を検知

2. RUM(Vercel/Cloudflare/Sentry)で実ユーザー P75/P98 を追跡

3. WebPageTest で回帰が発生したページを深く調査(filmstrip, waterfall)

4. 実験(A/B)で修正適用後 RUM メトリクスが回復するか確認

12. 負荷テストの AI — k6 Studio、Artillery Pro AI

2024-2025年に負荷テストツールに AI が本格的に入りました。流れは2つ。

**第一に、シナリオ生成**。ブラウザでユーザー操作を録画してスクリプトを自動生成する流れ。2024年リリースの **k6 Studio** はデスクトップアプリで、ユーザーがブラウザでクリックすると HAR を捕捉し、洗練された k6 JS シナリオを作ってくれます。トークン化・パラメーター化も自動です。**Artillery Pro AI** は OpenAPI スペックを受け取ってシナリオ YAML を生成します。

**第二に、結果分析**。負荷テスト結果(時系列メトリクス + ログ + APM)を LLM が読み「ボトルネックは DB connection pool の枯渇に見えます、p99 が 1.5s から 8s に跳ねる区間が新インデックスが適用されていないクエリと一致します」のような自然言語診断を出します。**BlazeMeter AI Co-Pilot、Grafana Sift、Datadog Bits** が代表例です。

2026年時点で AI は **下書き生成** と **結果要約** に強く、**閾値の決定** と **因果分析** には弱いです。「この API で p95 が 500ms を超えてはいけない」と決めることは依然として人間の仕事で、AI はデータを素早く整理し疑い候補を絞ってくれるアシスタントの役割です。

13. 日本 / 韓国 — メルカリ、ネイバー、トス

**メルカリ**。Mercari エンジニアリングブログ(engineering.mercari.com)は2023-2025年の間に **k6 をメイン負荷テストツールとして標準化** した道のりを公開しました。特に GraphQL ゲートウェイの負荷テストに k6 + GraphQL extension を使うパターンが日本コミュニティに大きな影響を与えました。

**Yahoo! JAPAN / LINE**。LINE はメッセージバックエンドに **Locust + 自前分散クラスタ** を運用しています。Yahoo! JAPAN は検索バックエンドに **JMeter + 自前プライベートインフラ** を長く使ってきました。

**SmartHR、freee、MoneyForward**。SaaS スタートアップは一貫して **k6** を第一選択肢として採用しました。JS/TS 親和的なバックエンド(Node, Go)と相性が良く、日本語資料も豊富です。

**韓国 — ネイバー**。ネイバー D2 ブログによれば、検索・ペイ・ウェブトゥーンのようなコアサービスは **自前負荷テストフレームワーク + JMeter** の組み合わせを長く使ってきました。最近の記事(2024)では一部新サービスへの k6 導入事例を共有し、社内負荷テストプラットフォームが JMeter `.jmx` + k6 JS の両方を受け入れる方向に進んでいます。

**韓国 — トス**。トスは決済・銀行など金融サービスの性質上、負荷テストがリリースゲートとして強制されます。Toss tech blog では **k6 + 自前メトリクスパイプライン + Grafana** の組み合わせで毎デプロイの負荷回帰を捕まえる事例が複数公開されています。「ユーザー1人が決済1回を完了するシナリオをコードで定義し、RPS ではなく TPS(Transaction Per Second)で見る」アプローチが印象的です。

**韓国 — カカオ**。カカオ tech blog はカカオトークメッセージ送信のような大規模システムに **Gatling** を長く使ってきたと共有しました。JVM バックエンド(Spring)比重が高い組織構造とよく合います。

日韓事例で共通する流れは明確です。**レガシー・エンタープライズは JMeter/Gatling、新規・SaaS は k6**。そして両者とも **合成負荷テスト + 本番 RUM** を組み合わせて見ます。

14. 誰が何を選ぶか — バックエンド / フロントエンド / エンタープライズ / 個人

ペルソナ別の推奨を整理します。

| ペルソナ | 第1選択 | 第2選択 | 一言評 |

|---|---|---|---|

最後に **一つだけ選ぶなら**: モダンバックエンド + モダンフロントエンドを両方扱うフルスタックチームなら、**k6 v1(負荷) + Lighthouse CI(ブラウザ) + oha(一行ベンチ)** の3組が2026年5月時点での最適解です。3つとも OSS で、単一バイナリまたは単一パッケージで即始められ、CI ゲート化が容易です。

負荷テストは絶対に一回きりのイベントではありません。毎デプロイの回帰監視ゲートにならねばならず、本番 RUM と組み合わせて「ラボで見た数字と実ユーザーが見る数字の差」を常に意識せねばなりません。ツールはそのワークフローを可能にする部品にすぎません。

15. 参考 / References

- Grafana k6 official site — https://k6.io

- k6 v1.0 release announcement — https://grafana.com/blog/2024/05/15/k6-v1.0-release/

- k6 GitHub — https://github.com/grafana/k6

- k6 Studio — https://grafana.com/blog/2024/10/k6-studio-test-builder/

- Artillery — https://www.artillery.io

- Artillery Pro AI — https://www.artillery.io/blog/ai

- Locust — https://locust.io

- Locust docs — https://docs.locust.io

- Apache JMeter — https://jmeter.apache.org

- JMeter 5.6 release notes — https://jmeter.apache.org/changes_history.html

- Gatling — https://gatling.io

- Gatling Java/Kotlin DSL — https://docs.gatling.io/reference/install/oss/

- Vegeta — https://github.com/tsenart/vegeta

- hey — https://github.com/rakyll/hey

- wrk — https://github.com/wg/wrk

- oha — https://github.com/hatoo/oha

- autocannon — https://github.com/mcollina/autocannon

- Bombardier — https://github.com/codesenberg/bombardier

- BlazeMeter — https://www.blazemeter.com

- OpenText LoadRunner — https://www.opentext.com/products/loadrunner-professional

- Tricentis NeoLoad — https://www.tricentis.com/products/performance-testing-neoload

- Azure Load Testing — https://learn.microsoft.com/en-us/azure/load-testing/

- Cloudflare Load Balancing — https://developers.cloudflare.com/load-balancing/

- Chaos Mesh — https://chaos-mesh.org

- LitmusChaos — https://litmuschaos.io

- Gremlin — https://www.gremlin.com

- AWS Fault Injection Service — https://aws.amazon.com/fis/

- Azure Chaos Studio — https://learn.microsoft.com/en-us/azure/chaos-studio/

- Lighthouse — https://developer.chrome.com/docs/lighthouse/overview

- Lighthouse CI — https://github.com/GoogleChrome/lighthouse-ci

- WebPageTest — https://www.webpagetest.org

- SpeedCurve — https://www.speedcurve.com

- Calibre — https://calibreapp.com

- Vercel Speed Insights — https://vercel.com/docs/speed-insights

- Cloudflare Web Analytics — https://www.cloudflare.com/web-analytics/

- web.dev INP — https://web.dev/articles/inp

- Core Web Vitals 2024 update — https://web.dev/blog/inp-cwv-march-12

- Mercari Engineering blog (k6) — https://engineering.mercari.com/en/blog/

- Naver D2 blog — https://d2.naver.com

- Toss tech blog — https://toss.tech

- Kakao tech blog — https://tech.kakao.com