k6とは｜負荷テストの始め方とJMeterとの違い・CI連携

k6とは｜JavaScriptで書くGo製の負荷テストツール

k6は、サーバーに意図的な負荷をかけて応答時間とエラー率を観測するためのツールです。本体はGoで書かれ、テストシナリオはJavaScriptで記述します。この「実行基盤はGo、記述言語はJavaScript」という組み合わせが、k6の性格をほぼ決めています。

ライセンスはAGPL-3.0で、本体は無料で使えます。GitHubのgrafana/k6リポジトリのスター数は約31,800です（2026年10月時点）。ただしスター数は注目度の目安であり、実運用での採用数を直接示す指標ではありません。導入を判断する場面では、公式の事例やコミュニティの活発さもあわせて確認してください。

バージョンと互換性の確認は最初にやる

本記事執筆時点（2026年10月）でGitHubのリリースページから確認できる最新版はv2.3.0（2026年9月21日公開）です。ただしバージョン名を鵜呑みにせず、学習や導入の前に公式のリリースノートで最新安定版を確認してください。

注意が要るのはv2.0.0（2026年5月11日公開）です。このメジャー更新で、長く非推奨だったCLIコマンドや設定が整理されました。公式リリースノートで明記されている主な変更には、次のようなものがあります。

• Goモジュールのパスがgo.k6.io/k6/v2に変更された（拡張はimportパスの更新が必須）

• externally-controlledエグゼキュータが削除された

• k6/experimental/redisモジュールが削除された

• HTTP APIサーバーがデフォルトで起動しなくなった（--addressで明示的に有効化する）

v1系も並行して更新されています（v1.8.1が2026年8月12日公開）。既存プロジェクトを引き継ぐときは、まずインストール済みのk6がv1系かv2系かを確認してください。ネット上のサンプルはv1系前提のものが混在します。

k6で測れること・測れないこと

k6が得意なのは、サーバー側の応答性能の計測です。一定の同時接続数を維持したときのレスポンスタイム分布、エラー率、スループットを数値で出せます。

一方で、ブラウザのレンダリング時間やJavaScript実行時間といったクライアント側の体感速度は、HTTPリクエストを投げるだけでは測れません。この領域は、本記事執筆時点の公式ドキュメントでk6/browserとして提供されているモジュールが担当します。利用にはChromium系ブラウザをマシン側にインストールする必要があります。対応OS・必要ブラウザ・制約は変わりうるため、導入前に公式ドキュメントで確認してください。

対応プロトコルも押さえておきましょう。少なくとも本記事執筆時点の公式APIリファレンス上で安定版として挙げられている主な対象は、k6/http（HTTP通信）、k6/ws および k6/websockets（WebSocket）、k6/net/grpc（gRPC）です。SQLやKafkaなど、これ以外のプロトコルを扱うにはxk6で拡張を組み込んだバイナリを自前でビルドします。対応範囲はバージョンで変わるため、選定前にk6のJavaScript APIリファレンスで最新の一覧を確認してください。

ミニFAQ：k6は無料で使えますか

本体はAGPL-3.0のオープンソースで、ローカル実行に費用はかかりません。分散実行や結果の長期保管をマネージドで使いたい場合に、Grafana Cloud k6という有償の選択肢があります。

k6とJMeterの違い｜6つの判断軸で比較

結論から言えば、CI/CDに常設する性能テストならk6、プロトコルの広さとGUIでの調査性が要るならJMeterという分かれ方をします。どちらが優れているかではなく、何を自動化したいかで決まります。

Apache JMeterは2001年から続くJava製のツールです。公式のchangesページによれば最新版は5.6.3で、実行にはJava 8以上（Java 17以上を推奨）が必要です。歴史の長さがそのままプラグイン資産の厚みになっています。

k6が向く場面

シナリオがGitで管理でき、プルリクエストでレビューできる点がk6の実利です。性能テストを「書いて終わり」にせず、アプリのコードと一緒に育てたいときに効きます。

CIパイプラインへの常設も素直です。単一バイナリのため、Javaランタイムを前提とする構成より依存関係を減らしやすく、しきい値違反がそのまま終了コードになります。GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説で触れているようなワークフローに、ジョブを1つ足す感覚で組み込めます。

JMeterが向く場面

JMeterを選ぶ理由は主に3つです。既存のjmx資産がある、HTTP以外のプロトコルを叩く必要がある、非エンジニアを含むチームでテスト計画を共有する。このどれかに当てはまるなら、無理にk6へ寄せる必要はありません。

とくにJDBC経由でDBへ直接負荷をかけたい、JMSでメッセージキューを試験したいといった要件では、JMeterのカバー範囲が効いてきます。k6で同じことをするなら拡張のビルドから始めることになります。

ミニFAQ：JMeterからk6へ移行すると、既存のテスト計画は引き継げますか

jmxをk6スクリプトへ自動変換する公式機能はありません。シナリオの意図（どのエンドポイントを、どの順序で、どの比率で叩くか）を仕様として書き出し、k6側で書き直す進め方が現実的です。移行は全面移行ではなく、新規に追加するシナリオからk6で書くという併存から始めるとつまずきにくくなります。

k6の始め方｜インストールから初回実行まで

最短ルートは、インストール、最小スクリプトの作成、実行の3手順です。環境が整っていれば、慣れている人で10分前後、初めてでも30分程度が最初の数値にたどり着くまでの目安になります。社内ネットワークの制限やインストール権限の有無で前後します。

インストール

macOSならHomebrewでbrew install k6、WindowsならwingetでGrafanaLabs.k6を指定します。Linuxはディストリビューション向けのパッケージリポジトリが用意されています。Dockerイメージを使えばインストール自体を省けます。

導入後はk6 versionでバージョンを確認してください。前述のとおりv1系とv2系で挙動が違う箇所があるため、ここを確認しないまま進めると後で詰まります。

最小スクリプトの構成要素

k6のスクリプトは、大きく2つのパートでできています。

1. optionsのエクスポート：どれくらいの負荷を、どれだけの時間かけるかを宣言する設定オブジェクト

2. default関数のエクスポート：仮想ユーザー1人が1回のイテレーションで実行する処理の本体

default関数の中では、k6/httpモジュールのget関数やpost関数でリクエストを送ります。レスポンスの検証にはcheck関数を使い、ステータスコードや本文の内容が期待どおりかを判定します。最後にsleep関数で待機を挟み、実ユーザーの操作間隔を再現します。

sleepを入れ忘れると、仮想ユーザーが休みなくリクエストを投げ続けます。実際のユーザー行動からかけ離れた負荷になるので、ここは初回から意識して入れてください。

初回実行と結果の読み方

実行はk6 run script.jsだけです。完了するとターミナルにサマリが表示されます。

最初に見るべき数字は3つに絞って構いません。http_req_durationのp(95)、http_req_failedの割合、そしてiterationsの総数です。この3つで「遅いのか、落ちているのか、そもそも負荷がかかっていないのか」を切り分けられます。

負荷のかけ方｜VU・stages・executorの使い分け

負荷の形はvusとduration、stages、scenariosの3段階で表現します。最初はvusとdurationだけで十分です。公式のオプションリファレンスに全オプションが載っています。

一定の同時接続数をかける

optionsにvus（仮想ユーザー数）とduration（実行時間）を指定すると、指定人数が指定時間だけ走り続けます。vusを10、durationを3分といった形です。これはconstant-vusエグゼキュータのショートカットにあたります。

性能の当たりを付ける最初の1本は、この形で構いません。

段階的に負荷を上げる

stagesを使うと、目標VU数とそこまでの所要時間をリストで並べられます。たとえば3分かけて10VUまで上げ、5分維持し、1分かけて0に戻す、という指定です。ramping-vusエグゼキュータのショートカットです。

通常の性能把握では、いきなり最大負荷をかけずランプアップを挟むのが基本です。 瞬間的な急増への耐性を見るスパイク試験のように、意図して一気にかける例外もあります。アプリケーションサーバーやコネクションプールが暖まる前の数値は、実運用の性能を反映しません。本番相当の試験を回すときは、5分前後のランプアップに続けて10分以上の定常区間を置く組み方が扱いやすくなります。この時間配分は対象システムのウォームアップ特性で変わるため、キャッシュやJITの効き方を見ながら調整してください。

秒間リクエスト数を固定する

VU数ではなく「秒間何リクエストか」で負荷を定義したい場合は、scenariosの中でconstant-arrival-rateまたはramping-arrival-rateを指定します。SLOを「秒間300リクエストでp95が500ミリ秒以内」のように定義しているなら、こちらのほうが素直です。

VU指定とRPS指定は似て非なるものです。VU指定では、サーバーが遅くなるほど実際のRPSが下がります。負荷が頭打ちになっていることに気づきにくいため、RPS基準でSLOを置いているなら到着率ベースの指定が扱いやすくなります。一方、同時接続数そのものの上限を見たい場合は、VU指定のほうが目的に合います。

ミニFAQ：仮想ユーザー数は実ユーザー数と同じに設定すべきですか

同じにする必要はありません。VUはサーバーへ同時に接続している数であり、サイトの同時閲覧者数とは一致しません。実測のアクセスログからピーク時のRPSを割り出し、到着率ベースで設定するほうが実態に近づきます。

しきい値で合否を自動判定しCIに載せる

k6をCIに載せる価値は、人がグラフを見なくても合否が決まる点にあります。これを担うのがthresholdsです。

主要メトリクスの読み方

k6は実行中に組み込みメトリクスを収集します。公式のメトリクスリファレンスに一覧がありますが、最初に押さえるのは次のあたりです。

http_req_durationが悪化したとき、http_req_waitingも同じだけ悪化していればサーバー側の処理が原因です。waitingは変わらずdurationだけ伸びているなら、受信やネットワーク側を疑います。この切り分けができるだけで、調査の初速がかなり変わります。

終了コード99でCIを落とす

thresholdsには、メトリクスごとの合格条件を書きます。http_req_durationに対してp(95)<500、http_req_failedに対してrate<0.01、といった形です。公式のしきい値ドキュメントに記法がまとまっています。

ポイントは終了コードです。すべてのしきい値を満たせば0、1つでも違反すれば99で終了します。CIのジョブは非ゼロ終了を失敗として扱うため、追加のパース処理を書かずにパイプラインを止められます。

結果を時系列で見る

k6の標準出力は実行後のサマリです。時系列の変化を追うには、外部の可視化基盤へメトリクスを送ります。Prometheus系やDatadogなど、外部可視化基盤と連携する手段が用意されています。具体的な出力方法と対応状況は公式ドキュメントで確認してください。構成のイメージはPrometheus & Grafanaとは｜メトリクス監視の基本・Datadogとの違い・案件単価をフリーランス視点で解説が参考になります。

負荷試験中のアプリケーション側の挙動も同時に見たいなら、OpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向で解説しているトレース計装を先に入れておくと、遅延の原因箇所まで一息で辿れます。負荷をかける側と受ける側の両方に目を持つ設計は、SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説で整理している役割分担とも重なります。

ケース別｜k6とJMeterのどちらを選ぶか

迷ったときの判断軸を、現場でよくある4つの状況に落としました。

新規APIをCIで継続的に測る場合

k6が噛み合います。性能テストをアプリと同じリポジトリに置き、プルリクエストでシナリオの変更意図をレビューできます。テストを資産として育てる考え方は、TDD（テスト駆動開発）とは｜進め方・向く場面と現場で続けるコツと同じ発想です。

既存のJMeter資産がある場合

移行の是非は「資産の量」ではなく「今後その資産を触るか」で決めてください。年に1回のリリース前試験で回すだけなら、動いているものを置き換える利点は小さくなります。

ブラウザ操作まで含めたい場合

k6/browserモジュールで対応できます。ただし負荷テストとして大量のブラウザを並列起動すると、負荷をかける側のマシンリソースを一気に消費します。ブラウザ主体のシナリオは少数VUに絞り、スループットはHTTPリクエストベースのシナリオで稼ぐという併用が現実的です。

ブラウザ自動化そのものの基礎は、Playwrightとは｜E2Eテスト自動化の基本・Cypressとの違い・案件単価をフリーランス視点で解説やSeleniumとは｜ブラウザ自動化・スクレイピングの基本と案件への影響を解説が参考になります。

HTTP以外のプロトコルを叩く場合

gRPCまではk6本体の安定モジュールでカバーできます。SQLやKafkaまで必要なら、xk6で拡張を組み込んだバイナリをビルドするか、JMeterを選ぶかの二択です。ビルド環境の維持コストを見積もったうえで判断してください。

k6でよくある失敗と対策

実際に詰まりやすいのは、ツールの使い方そのものより計測設計です。

負荷元が先に限界を迎える

ノートPC1台から数千VUをかけると、サーバーではなく手元のCPUとネットワークが先に飽和します。これに気づかないまま「サーバーの限界は3,000VU」と報告してしまう事故が起きます。

対策は単純です。負荷試験中は負荷をかける側のCPU使用率、送受信帯域、可能ならNICのエラー・再送まで記録してください。負荷元のCPUが張り付いていたら、その計測値は無効と判断します。

シナリオが本番のアクセス傾向と乖離する

全エンドポイントを均等に叩くシナリオは、ほぼ確実に実態とずれます。実際のアクセスは特定のエンドポイントに偏るためです。

アクセスログやAPMから、エンドポイント別のリクエスト比率を先に出しておきましょう。その比率をシナリオに反映するだけで、結果の説得力が変わります。エラー監視の実データを使う発想は、Datadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説で扱っている運用データの活用と同じです。

しきい値が形骸化する

とりあえずp(95)<1000と置いたまま誰も見直さず、常にグリーンで通り続ける状態です。これでは回す意味がありません。

しきい値はSLOから逆算して決め、リリース前の見直しをプロセスに組み込んでください。達成できていない数値を暫定で緩める場合は、緩めた理由と戻す期限をスクリプトのコメントではなくチケットに残します。

本番環境でいきなり回す

負荷試験は実サービスを止めかねない行為です。クラウド事業者や委託先の運用ルールによっては、事前の申請・連絡が必要になります。利用規約とサポート窓口の案内を事前に確認してください。 そのうえで対象環境の所有者とインフラ担当の合意を取り、実施日時と中断条件を決めてから実行します。

負荷テスト導入チェックリスト

初回の負荷試験に入る前に、次の項目を上から順に確認してください。

• 計測の目的が1文で書けている（例：ピーク時の想定RPSでp95が500ミリ秒以内に収まるか）

• 対象環境の所有者から実施の合意を得ている

• 実施日時と、異常時に中断する条件を決めている

• 本番のアクセスログからエンドポイント別のリクエスト比率を出している

• 負荷をかける側のCPU・ネットワークを記録する準備ができている

• ランプアップ区間と定常区間を分けてstagesを設計している

• thresholdsをSLOから逆算して設定している

• サーバー側のメトリクスとトレースを同じ時間軸で見られる状態にしている

• 失敗したときに誰へエスカレーションするかが決まっている

• インストール済みk6のバージョン（v1系かv2系か）を確認している

この10項目のうち、最初の負荷試験でとくに抜けやすいのは4番目と5番目です。シナリオの作り込みに時間を使う前に、ここを埋めてください。

k6を扱う案件での位置づけ

k6は単体のスキルというより、性能改善という工程の中の一部として求められます。ツールを動かせることと、出てきた数値から原因を特定して改善提案まで持っていけることは別物です。

案件のタイプ、求められるスキルセット、単価の目安、探し方といった実務面は性能改善・負荷試験のフリーランス案件｜単価・スキル・獲得法に整理しています。自分のスキルセットでどのくらいの単価を狙えるか知りたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

まとめ

k6は、JavaScriptまたはTypeScriptでシナリオを書き、しきい値で合否を自動判定できる負荷テストツールです。CI/CDに組み込みやすい点が最大の強みで、HTTP APIの性能を継続的に測りたいチームに向きます。 JMeterとの違いはGUIの有無ではなく、テスト資産をコードとして管理・レビューできるかにあります。

• k6はGo製の単一バイナリ。ライセンスはAGPL-3.0で、本体のローカル実行は無料

• 本記事執筆時点（2026年10月）の最新版はv2.3.0。v2.0.0で破壊的変更があるため、既存スクリプトの引き継ぎ時はバージョン確認が先

• インストールから初回実行までは10分程度。最小構成はoptionsとdefault関数の2つ

• 負荷の形はvusとduration、段階的に上げるならstages、RPS固定なら到着率エグゼキュータ

• 合否はthresholdsで宣言し、違反時の終了コード99でCIを落とす

• 本体の安定モジュールはHTTP(S)・WebSocket・gRPC。これ以外はxk6拡張かJMeterを検討する

• 失敗の多くはツールではなく計測設計に起因する。負荷元のリソース記録とアクセス比率の反映を先に固める

次の一歩としては、手元の開発環境に対してvus10・duration1分の最小シナリオを1本回してみてください。数値の読み方が掴めたら、アクセスログから比率を起こしてシナリオを本番寄りに作り替えます。

参照した一次情報は次のとおりです。

• Grafana k6 公式ドキュメント

• k6 オプションリファレンス

• k6 しきい値（Thresholds）

• k6 メトリクスリファレンス

• k6 JavaScript API

• grafana/k6 リリース一覧（GitHub）

• Apache JMeter 公式サイト

• Apache JMeter Changes