---
title: "負荷テストツール比較｜Web・CPU・ネットワーク別の無料ツールとWindowsでの実行手順"
url: "https://www.issoh.co.jp/column/details/2934/"
published: 2024-07-04
updated: 2026-10-20
categories: ["品質管理"]
publisher: "株式会社一創"
---

# 負荷テストツール比較｜Web・CPU・ネットワーク別の無料ツールとWindowsでの実行手順

負荷テストツールを探すと、Apache JMeterやk6といったWebアプリ向けの製品ばかりが並びます。ところが現場では「サーバーのCPUを100%に張り付かせて冷却を確かめたい」「拠点間の帯域が本当に1Gbps出ているか測りたい」という作業も同じ言葉で呼ばれます。3つは測る対象もツールも別物で、混同したまま選ぶとJMeterでCPU負荷を作ろうとして時間を失います。この記事では負荷テストツールをWebアプリ・CPU/メモリ・ネットワークの3系統に分け、2026年10月時点の最新版、ライセンス、Windowsで動くかどうか、実際に動かしたときの結果の読み方まで整理します。

## まとめ：3系統の使い分けと最初に選ぶ1本

- **Webアプリ・API**：第一候補はGrafana k6（v2.3.0・AGPL-3.0）。JavaScriptでシナリオと合格ラインを1ファイルに書け、単一バイナリなのでCIに載せやすい。JDBCやJMSなどHTTP以外も1本でまかなうならApache JMeter（5.6.3）。
- **CPU・メモリ**：WindowsならSysinternalsのCpuStresか、商用利用も無料のHeavyLoad 4.0。Linuxやコンテナ基盤ならstress-ng（0.22.01）。stress-ngにWindows版の配布は無く、WSL2かDockerで動かします。
- **ネットワーク**：Windows同士はMicrosoftのNTTTCP（v5.40）、Linuxを含む環境はiperf3（3.22）。iperf3はWindowsを公式にはサポートしておらず、公式FAQはWindowsではiperf2を勧めています。
- **クラウド**：負荷生成の基盤を自前で持ちたくないなら、Distributed Load Testing on AWS（JMeter・k6・Locust対応）かAzure Load Testing（JMeter・Locust対応）。

## 負荷テストツールの3系統と、選定を分ける4つの軸

「負荷テスト」という言葉は少なくとも3つの別の作業を指しています。どれを指しているかが決まらないと、ツール選定は始まりません。

### 測定対象で分かれる3系統と代表ツール

| 系統         | 測るもの             | 代表ツール                                      | Windowsでの実行              |
| ---------- | ---------------- | ------------------------------------------ | ------------------------ |
| Webアプリ・API | 応答時間・スループット・エラー率 | k6 / JMeter / Gatling / Locust             | いずれもネイティブ可               |
| CPU・メモリ    | クロック維持・発熱・メモリ耐性  | CpuStres / Prime95 / HeavyLoad / stress-ng | stress-ngのみWSL2・Docker経由 |
| ネットワーク     | 帯域・遅延・再送・パケットロス  | NTTTCP / iperf3 / IxChariot                | iperf3は公式サポート外           |

系統をまたいだ代用はできません。JMeterでHTTPリクエストを大量に投げてもCPU使用率は上がりますが、それはWebサーバーのアプリケーション処理を経由した副次的な負荷で、コアを狙って張り付かせるCpuStresやPrime95とは再現している事象が違います。ハードウェアの検収やサーマルスロットリングの確認には後者を使ってください。負荷テスト・ストレステスト・ラッシュテストといった用語の切り分けは[ラッシュテストとは？負荷テストとの違い・目的・実施手順を解説](/column/details/3469/)で整理しています。

### ライセンス・記述言語・実行形態・対応OSという4つの選定軸

系統が決まったあとに効いてくる軸は4つです。1つ目はライセンスで、k6のAGPL-3.0は社内のCIで実行するだけなら問題になりにくい一方、改変したk6を自社サービスの機能としてネットワーク越しに提供するならソース公開義務の検討が要ります。2つ目はシナリオの記述言語で、チームがPythonを書けるならLocust、JavaScriptならk6と、既存のスキルに合わせるのが最短です。

3つ目は実行形態です。JMeterとGatlingはJVMが必要で、k6は単一バイナリ、Locustはpipで入ります。コンテナイメージを小さく保ちたいCIではこの差が効きます。4つ目が対応OSで、後で触れるstress-ngとiperf3のように、Windowsが公式サポートの外にあるツールが実在します。

## Webアプリケーション負荷テストツールの比較と実行コマンド

### OSS4種の最新版・ライセンス・記述言語

| ツール           | 最新版（公開日）           | ライセンス      | シナリオ記述                  | 実行形態                 |
| ------------- | ------------------ | ---------- | ----------------------- | -------------------- |
| Apache JMeter | 5.6.3（2024-01-09）  | Apache-2.0 | GUI操作＋XML（.jmx）         | JVM（Java 8以上・17以上推奨） |
| Grafana k6    | v2.3.0（2026-09-21） | AGPL-3.0   | JavaScript・TypeScript   | 単一バイナリ               |
| Gatling       | 3.16.0（2026-09-29） | Apache-2.0 | Java・Kotlin・Scala・JS・TS | JVM                  |
| Locust        | 2.46.7（2026-10-04） | MIT        | Python                  | Python実行環境           |

差が大きいのはリリースの間隔です。JMeterは[公式のダウンロードページ](https://jmeter.apache.org/download%5Fjmeter.cgi)でも5.6.3（Requires Java 8+）が最新のままで、2024年1月から新しい版が出ていません。k6は[GitHubのリリース](https://github.com/grafana/k6/releases)で2026年5月にv2.0.0を出し、9月にv2.3.0まで進んでいます。v1系もv1.8.2（2026年10月12日）まで保守が続いているため、v2で削除された`k6 login`などに依存する既存のジョブはv1.8系で動かし続ける選択もあります。Gatlingは[公式のインストール手順](https://docs.gatling.io/reference/deploy/install-local/)でJavaScriptとTypeScriptでもテストを書けると案内しており、「Scalaが書けないと使えない」という評価は古くなりました。

### k6の閾値付き実行とJMeterの非GUI実行

k6は合格ラインを`thresholds`としてスクリプトに書いておくと、満たせなかったときに終了コードが0以外になり、CIのジョブがそのまま失敗します。次のスクリプトをk6 v2.3.0で、ローカルのHTTPサーバーに対して仮想ユーザー5人・5秒間実行しました。再現する場合は、先に127.0.0.1のポート18934でHTTP 200を返すサーバーを起動し、コードをscript.jsとして保存してください。

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

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<1500'],   // 95パーセンタイルが1.5秒未満
    http_req_failed: ['rate<0.001'],      // エラー率0.1%未満
  },
};

export default function () {
  const res = http.get('http://127.0.0.1:18934/');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}
```

```
# k6: 仮想ユーザー5人・5秒間、明細をJSONへ出力
k6 run --vus 5 --duration 5s --out json=result.json script.js

# 出力の抜粋（k6 v2.3.0）
  █ THRESHOLDS
    http_req_duration
    ✓ 'p(95)<1500' p(95)=21.69ms
    http_req_failed
    ✓ 'rate<0.001' rate=0.00%
    http_req_failed................: 0.00%  0 out of 25

# JMeter: GUIを使わない非GUIモード（-n）でHTMLレポートまで出力
jmeter -n -t plan.jmx -l result.jtl -e -o ./report
```

終了コードは0でした。なお`check`は失敗しても終了コードを変えません。ステータス200以外をCIで失敗扱いにしたいなら、`thresholds`に`checks: ['rate==1']`を加えます。仮想ユーザー5人がそれぞれ1秒待つので、5秒間のリクエストは25件にとどまります。`--out json`のファイルはメトリクスの定義と各測定サンプルを行単位で記録する形式で、この25件だけで約88KBになりました。長時間の試験では出力先をファイルではなく時系列DBへ向けるか、集計だけを残す設計にしてください。JMeterのGUIは負荷生成そのものに使うと計測結果を歪めるため、本番の計測は`-n`の非GUIモードが前提です。k6の導入から閾値の設計までは[k6とは？負荷テストの使い方とインストール手順【v2.3対応】](/tech/details/7581/)、合格ラインを非機能要件から決める手順は[非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説](/tech/details/17610/)で扱っています。

### JMeterを選ぶ条件・避ける条件

JMeterは実績で選ばれ続けていますが、次の条件が重なるなら別のツールにすべきです。シナリオをGitでレビューしたい場合、.jmxはXMLなので差分を読めますが、GUI操作に伴う設定変更が多いと、テストの意図を追いにくくなることがあります。コンテナイメージを小さくしたい場合も、JVMを同梱するJMeterは単一バイナリのk6より不利です。標準機能が対応していないプロトコルを試験する場合は、必要なプラグインの対応状況と保守状況を個別に確認してください。HTTP/2の扱いは[JMeterでHTTP/2負荷テストを行う方法｜BlazeMeter HTTPプラグインの導入と設定【3.2対応】](/tech/details/10012/)にまとめました。

逆に、業務システムでJDBC・JMS・FTPなどを1本のツールで扱う必要があるなら、JMeterの優位は揺らぎません。Python資産があるチームは[Locustとは？Pythonで書く負荷試験の使い方・ramp-up・分散実行【2.46対応】](/tech/details/10870/)が選択肢になります。

### クラウドのマネージド負荷テストと課金の単位

負荷生成機を自前で並べたくない場合は、クラウドの仕組みに既存のスクリプトを載せる方法があります。AWSの[Distributed Load Testing on AWS](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/solution-overview.html)はJMeter・k6・Locustのスクリプトと、単純なHTTPエンドポイントの指定に対応するソリューションで、2026年10月14日にv4.3.2が出ています。自分のAWSアカウントにデプロイする形で、[費用の説明](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/cost.html)のとおり、負荷を生成するAWS Fargateのタスクなど実際に使ったサービスの料金がかかります。

Azure Load TestingはJMeterとLocustのテストを実行でき、課金単位は仮想ユーザー×時間のVUH（Virtual User Hour）です。[料金ページ](https://azure.microsoft.com/en-us/pricing/details/app-testing/)によると、2026年3月1日から1回の実行の最低課金が「エンジンあたり10VU×実行時間（10分未満は10分）」になりました。5VUで1分の疎通確認を何度も回すと、使った量より多く課金されます。短い確認はローカルのk6で済ませ、クラウドは本測定だけに使うのが安上がりです。

AWS上の機器へ大量のトラフィックを流すときは、[Amazon EC2 Testing Policy](https://aws.amazon.com/ec2/testing/)のネットワークストレステストの指針も確認してください。経路やリージョンによっては、25Gbpsまたは100Gbpsを超える急増にトラフィック制御がかかる場合があると書かれています。脆弱性診断との事前申請の線引きは[AWSの脆弱性診断｜事前申請が要る範囲とツール選定・費用の判断基準](/column/details/2713/)で扱っています。

## CPU・メモリの負荷テストツールとWindowsでの実行手段

ハードウェアの検収や冷却の確認では、アプリケーションを介さずにCPUコアやメモリを直接張り付かせるツールを使います。

### Windowsで動く無償のCPU負荷ツール3種

| ツール       | 提供元                    | 版              | 負荷対象             | 対応・条件                  |
| --------- | ---------------------- | -------------- | ---------------- | ---------------------- |
| CpuStres  | Microsoft Sysinternals | v2.0           | CPU（最大64スレッド）    | 無償                     |
| Prime95   | GIMPS                  | 30.19 build 20 | CPU・メモリ          | 無償・Windows／Linux／macOS |
| HeavyLoad | JAM Software           | 4.0            | CPU・GPU・メモリ・ディスク | 商用利用も無料・ARM64対応        |

[CpuStres](https://learn.microsoft.com/en-us/sysinternals/downloads/cpustres)は最大64スレッドをタイトループで回し、スレッドごとにActivity LevelをLow・Medium・Busy・Maximumから選べます。「特定の4コアだけに負荷を集中させる」といった試験では、CPUアフィニティの設定と論理プロセッサごとの使用率も確認してください。Prime95のTorture Testには、30.19 build 20でSmallest・Small・Medium・Large・Blendの5つのプリセットがあります。Small FFTsはダイアログ上も「maximum power/heat/CPU stress」と説明されるとおり発熱が最大で、Large FFTsはメモリコントローラとRAMに効きます。冷却を見たいのかメモリの安定性を見たいのかで選び分けてください。

HeavyLoadは[4.0の変更履歴](https://www.jam-software.com/heavyload/changes.shtml)で、CPUテストの計算が階乗から行列計算に変わり、CPU負荷が大幅に高くなったと説明しています。3.x系で取った温度や消費電力の記録とは、同じ「CPU 100%」でも条件が違います。比較するなら版を揃えてください。

### stress-ngをWindowsで動かす2つの経路（WSL2とDocker）

「stress-ng windows」で検索してもWindows用のインストーラーは見つかりません。開発元がWindowsネイティブのバイナリを配布していないためです。[公式README](https://github.com/ColinIanKing/stress-ng)がビルド対象に挙げているのはLinux各種・BSD・macOSなどに加え、Windows Subsystem for LinuxとCygwinです。Cygwinで自前ビルドする道もありますが、実務では次の2つが現実的です。

```
# 経路1: WSL2上のUbuntuで導入する
# 1行目はWindows側のPowerShell、2行目以降はWSL内のシェルで実行
wsl --install -d Ubuntu
sudo apt update && sudo apt install -y stress-ng
stress-ng --cpu 8 --timeout 60s --metrics-brief

# 経路2: Docker Desktop（WSL2バックエンド）で公式コンテナを実行する
docker run --rm ghcr.io/colinianking/stress-ng --cpu 4 --timeout 30s --metrics-brief
```

どちらの経路でも負荷はホストのCPUに届きますが、Windowsカーネルのスケジューリングやドライバ層はテスト対象から外れます。Windows Server本体の耐久性を確かめたいなら、stress-ngではなくCpuStresやPrime95を使うのが正しい選択です。aptで入る版はディストリビューションの収録版なので、最新の0.22.01を使いたい場合はコンテナの経路が手早く済みます。

### stress-ng 0.22.01の結果の読み方と–vm-bytesの落とし穴

公式コンテナ（stress-ng 0.22.01）を4コアのLinux VM上で動かし、CPUとメモリにそれぞれ10秒の負荷をかけました。

```
$ stress-ng --cpu 2 --timeout 10s --metrics-brief
stress-ng: metrc: [1] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: metrc: [1]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: metrc: [1] cpu               25614      9.90     19.96      0.01      2586.90        1282.38
stress-ng: info:  [1] passed: 2: cpu (2)
stress-ng: info:  [1] metrics untrustworthy: 0

$ stress-ng --vm 2 --vm-bytes 256M --timeout 10s --metrics-brief
stress-ng: info:  [7] vm: using 128MB per stressor instance (total 256MB of 4.64GB available memory)
```

見るべき行は`passed`と`failed`です。usr timeが実時間のほぼ2倍（19.96秒÷9.90秒）なので、2コアが張り付いていたことも読み取れます。bogo opsは「その環境で何回回ったか」という目安の数字で、別のマシンと比べる性能値ではありません。

注意したいのは`--vm-bytes`です。0.22.01の`--help`は「allocate N bytes in total across vm workers」と説明しており、実際に`--vm 2 --vm-bytes 256M`は1ワーカーあたり128MBでした。「`--vm 4 --vm-bytes 2G`で各ワーカーが2GBずつ確保する」と書いた解説が多く出回っていますが、この版では合計2GBです。メモリを8GB埋めたいなら`--vm-bytes 8G`と合計値で指定し、ログの「using … per stressor instance」の行で実際の確保量を確かめてください。

### stress-ngをベンチマークに使ってはいけない理由

bogo ops/sが出るため、サーバー同士の性能比較に使いたくなります。これは作者が公式READMEで「it has never been intended to be used as a precise benchmark test suite, so do NOT use it in this manner」と否定しています。調達時の性能比較資料には使わないでください。もう1つ、rootで実行するとストレッサーがメモリ不足でkillされにくくなるようOOMの設定が調整されます。共有環境や本番機での実行は事故につながるため、専用機か使い捨てのVMで行うのが前提です。

## ネットワーク負荷テスト（スループット測定）のツールと手順

ネットワーク側の負荷テストは、帯域・遅延・再送・パケットロスを測る作業です。Webアプリ向けのツールでは測れません。

### iperf3がWindowsで公式サポート外である点とiperf2の位置づけ

iperf3は2026年9月29日に3.22が出ており、Linux・macOSでは定番です。ただし開発元ESnetは[入手方法のページ](https://software.es.net/iperf/obtaining.html)で「ESnet does not distribute binary packages of iperf3」と明記し、バイナリはすべて第三者の配布物です。さらに[公式FAQ](https://software.es.net/iperf/faq.html)は、iperf3はWindowsを公式にはサポートしておらずiperf2はサポートしているとして、Windowsではiperf2を勧めています。Cygwinで動かす人もいるがすべてのオプションが動くわけではない、とも書かれています。

実務の判断はこうなります。Windows同士なら次に述べるNTTTCP、WindowsとLinuxの混在ならiperf2かNTTTCP（Linux側はNTTTCP-for-Linux）を選びます。それでもWindowsでiperf3を使うなら、配布元の素性を確かめたうえで、使うオプションが動くかを事前に確認してください。[iperf3の概要ページ](https://software.es.net/iperf/)にあるとおりiperf3は元のiperfと互換性が無いため、両端を同じものに揃える必要があります。

### iperf3の基本コマンドと出力の読み方

iperf3 3.22を同じホスト上の2つのコンテナで動かし、TCPの並列・逆方向とUDPを測りました。

```
# 受信側（サーバー）
iperf3 -s

# 送信側: TCPを4本並列で5秒
iperf3 -c 10.0.0.5 -t 5 -P 4
[SUM]   0.00-5.00   sec  24.1 GBytes  41.4 Gbits/sec    0             sender
[SUM]   0.00-5.00   sec  24.1 GBytes  41.4 Gbits/sec                  receiver

# 逆方向（サーバーから送らせる）: -R
iperf3 -c 10.0.0.5 -t 3 -R

# UDPで100Mbpsを指定して流し、ジッタと損失を見る
iperf3 -c 10.0.0.5 -u -b 100M -t 3
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  4]   0.00-3.00   sec  35.8 MBytes   100 Mbits/sec  0.035 ms  0/25907 (0%)  receiver
```

TCPで見るのは`receiver`行のBitrateと、sender行の再送回数（Retr列）です。再送が増えるなら、帯域より先に経路の品質を疑います。UDPは指定したレートで送り続けるため、帯域を測るより「このレートで何%落ちるか」とジッタを見る用途に向きます。音声・映像系の回線評価ではこちらを使います。

41.4Gbpsという値は、同じホスト内の仮想ブリッジを通ったためで、物理NICは通っていません。iperf3は経路のどこがボトルネックでも同じように数字を出すので、測定の両端を必ず実際の機器に置き、片方向だけでなく`-R`で逆方向も測ってください。上りと下りで値が大きく違うのは、回線や機器の設定がよくある原因です。

### NTTTCPによるWindows間スループット測定

Windowsサーバー同士の帯域測定は、MicrosoftがMITライセンスで公開している[NTTTCP](https://github.com/microsoft/ntttcp)（v5.40）が公式の手段です。

```
REM 受信側でファイアウォールを開ける（実行ファイル単位で許可）
netsh advfirewall firewall add rule program=c:\tools\ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY

REM 疎通確認：10秒だけ流して構成を確かめる（上段が受信側、下段が送信側）
ntttcp -r -m 4,*,10.0.0.5 -t 10
ntttcp -s -m 4,*,10.0.0.5 -t 10

REM 本測定：300秒。-m の先頭はコア数x2、送受信で -t を揃える
ntttcp -r -m 4,*,10.0.0.5 -t 300
ntttcp -s -m 4,*,10.0.0.5 -t 300
```

`-m`の3つの値はスレッド数、CPUアフィニティ、受信側のIPアドレスの順で、送信側でも受信側のIPを指定します。[Microsoft Learnの帯域テスト手順](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-bandwidth-testing)は、疎通確認だけ短く済ませ、正確な結果には300秒まで延ばすよう案内しています。

同じ手順のWindows用コマンド例には`-P 1`が付いていますが、v5.40のソースにある使い方の一覧に`-P`はありません。引数は大文字小文字を区別せずに解析されるため、`-P 1`は`-p`（ポート番号の起点）に1を渡したことになります。`-P`はLinux版NTTTCP-for-Linuxのオプションです。WindowsとLinuxを混在させる場合は、送信側だけで同期を切ります。Windowsが送信側なら`-ns`、Linuxが送信側なら`-N`で、受信側には付けません。

### トラフィックジェネレーターとスループット測定ツールの違い

iperf3やNTTTCPが測るのは「この経路で何Mbps出るか」です。トラフィックジェネレーターは、パケットのヘッダやプロトコル構成を作り込んで任意のトラフィックを生成する道具で、OSSではCisco発のTRexがあります。Ostinatoは2024年4月から商用のクローズドソース製品へ移行しており、最後のOSS版は1.3.0です。スイッチやファイアウォールの処理性能、特定のパケットパターンでの取りこぼしを確かめたい場合はこちらを使います。商用ではKeysight（Ixia）のIxChariotが、有線・無線・クラウドをまたいだアプリケーション性能の検証用として現在も提供されています。

## 同時接続数と合格ラインの設計手順

ツールが決まっても、目標値が無ければテストは判定できない数字を出すだけで終わります。同時接続数の見積もり、合格ラインの定義、負荷生成側の確認の順で進めます。

### 仮想ユーザー数と同時接続数を混同しない見積もり

ピーク時の同時接続数は実測値から決めます。既存システムがあるならアクセスログやロードバランサのメトリクスから最大同時セッション数を取り、無ければ想定利用者数に同時利用率を掛けて仮置きします。仮想ユーザー数（VU）は同時接続数ではありません。上のk6の実測では、5VUで合計25件、平均約4.94リクエスト毎秒でした。各VUは応答を受けてから1秒待つため、応答が遅くなると同じVU数でもリクエスト毎秒は減ります。見積もりの単位をVUのまま合意すると、後から「同時接続1万」という要件との対応が取れなくなります。

### 合格ラインの定義：統計量・閾値・継続時間

「応答時間3秒以内」では合否が割れます。「95パーセンタイル応答時間が1.5秒以内、エラー率0.1%未満、その状態を10分間維持」のように、どの統計量を、いくつの閾値で、どれだけの時間見るのかを揃えて書いてください。平均値だけで判定すると、一部のリクエストが数十秒かかっていても平均に埋もれます。上のk6スクリプトの`thresholds`は、統計量と閾値の部分をコードにした例です。`thresholds`は試験全体の集計で判定するため、「10分間維持」まで確かめるには試験時間を10分以上にし、時間帯ごとの推移もグラフで見てください。試験の設計から、リリース後の監視・保守まで一貫して任せたい場合は、[システムの保守運用・内製化支援](/service/system/maintenance/)で相談を受けています。

### 負荷生成側が先に限界を迎えていないかの確認

負荷をかける側のマシンが先に飽和すると、測っているのはサーバーではなく負荷生成機の性能です。試験中は負荷生成側のCPU使用率とネットワーク送信量も記録し、張り付いていたら複数台に分散するか、JVMを要さない軽量なツールへ切り替えます。iperf3の例で見たとおり、同じホスト内で送受信すると測定経路そのものが変わる点も同じ注意です。

## 名称変更・旧世代のツールの現在地

古い技術記事や社内手順書に残っているツール名が、今も同じ名前で入手できるとは限りません。

### Microsoft Web Application Stress Tool（WAST）の旧資料と代替ツール

WASTは旧世代のIIS向け負荷テストツールで、説明はMicrosoft LearnのIIS 6.0 SDKのprevious-versions配下に残るだけです。同じページでは別の負荷テストツールとしてWCAT 5.2も紹介されています。今の環境で同じことをするなら、k6かJMeterに置き換えるのが実務的な答えです。

### LoadRunnerはOpenText、NeoLoadはTricentisの製品

OpenTextが2023年1月にMicro Focusを買収した結果、HP・HPE・Micro Focusと渡り歩いたLoadRunnerは現在OpenTextの製品です。見積もりや資料請求の窓口はOpenTextを起点に探してください。NeoLoadは2021年3月30日のNeotys買収でTricentisの製品になり、正式名称はTricentis NeoLoadです。製品自体は継続しているため、既存のシナリオ資産が失われるわけではありません。

## よくある質問

### 無料で使える負荷テストツールはどれですか？

Webアプリ向けではApache JMeter（Apache-2.0）、Grafana k6（AGPL-3.0）、Gatling（Apache-2.0）、Locust（MIT）がいずれも無償です。CPU負荷ではSysinternalsのCpuStres、GIMPSのPrime95、商用利用も無料のHeavyLoadが使えます。ネットワーク帯域はNTTTCP（MIT）とiperf3が無償です。自社サービスにk6を組み込んで外部に提供する予定があるなら、AGPL-3.0の条件を事前に確認してください。

### stress-ngはWindowsでそのまま動きますか？

Windows用のバイナリは配布されていないため、そのままでは動きません。WSL2上のUbuntuにaptで入れるか、Docker Desktopで公式コンテナイメージを実行します。この経路ではWindowsカーネル側の挙動は検証対象から外れるため、Windows Server自体の耐久試験にはCpuStresやPrime95を使ってください。

### ネットワーク負荷試験に使えるフリーソフトはありますか？

帯域の測定ならiperf3とNTTTCPが無償です。Windows同士はNTTTCP、Linuxを含むならiperf3が基本で、Windowsでiperf系を使うなら公式FAQが勧めるiperf2を選びます。パケットの中身を作り込んで機器の処理性能を試すなら、OSSのTRexが候補です。Ostinatoの現行版は商用製品なので、無償ツールとは区別してください。

### AWSで負荷テストを行うのに適したツールは何ですか？

既存のJMeter・k6・Locustのスクリプトがあるなら、Distributed Load Testing on AWSでそのまま複数リージョンから負荷をかけられます。小規模な確認なら、EC2に入れたk6やLocustで十分です。大量のトラフィックを流す前には、Amazon EC2 Testing Policyのネットワークストレステストの指針を確認してください。

### メモリの負荷テストはどのツールで行いますか？

WindowsではPrime95のLarge FFTsプリセットか、HeavyLoadのメモリテストが実用的です。Linuxやコンテナならstress-ngの`--vm`を使い、`--vm-bytes`には全ワーカーの合計量を指定します（0.22.01の場合）。いずれも本番機ではOOMによるプロセス停止を招くため、専用機か使い捨てのVMで行ってください。

### Microsoft Web Application Stress Toolは今も使えますか？

現在の環境での新規採用は勧めません。旧世代のIIS向けツールであり、現在のWindows Serverでの動作可否は別途検証が必要です。Microsoft LearnのIIS 6.0 SDKの旧版資料にはWASTの説明が残り、同じページでWCAT 5.2も別の負荷テストツールとして紹介されています。今のWindows ServerやIISにHTTP負荷をかけるなら、Windowsでネイティブに動くk6かApache JMeterへ置き換えてください。

## 関連記事

- [k6とは？負荷テストの使い方とインストール手順【v2.3対応】](/tech/details/7581/)
- [Locustとは？Pythonで書く負荷試験の使い方・ramp-up・分散実行【2.46対応】](/tech/details/10870/)
- [JMeterでHTTP/2負荷テストを行う方法｜BlazeMeter HTTPプラグインの導入と設定【3.2対応】](/tech/details/10012/)
- [非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説](/tech/details/17610/)
- [ラッシュテストとは？負荷テストとの違い・目的・実施手順を解説](/column/details/3469/)

---

出典: [負荷テストツール比較｜Web・CPU・ネットワーク別の無料ツールとWindowsでの実行手順](<https://www.issoh.co.jp/column/details/2934/>)（株式会社一創）