API負荷テストチュートリアル：初心者ガイド

API負荷テストとは？

API負荷テストは、シミュレートされた高負荷のトラフィック下でアプリケーションプログラミングインターフェース（API）のパフォーマンスとスケーラビリティを評価するプロセスです。APIが増加したリクエスト数、長時間の稼働、個々のエンドポイントからエンドツーエンドのワークフロー全体に及ぶ広範なテスト範囲にどの程度耐えられるかを検証します。目的は、期待されるトラフィックレベルを確実に扱い、ユーザーに一貫した体験を提供できることを確認することです。

API負荷テストを実施する際は、応答時間、遅延、スループット、ストレス下でのAPIの全体的な健全性などのパフォーマンス指標を収集します。これらの測定は、ピーク時の使用時にもウェブサイトやアプリケーションが滑らかに動作し続けるかを検証します。

API負荷テストは、テストプロセスの目的によって多様なアプローチが可能です。破損点を特定するストレステストから長時間使用に耐える耐久テストまで、各テストタイプは特定の状況下でAPIがどのように動作するかについて異なる洞察を提供します。現代のアプリケーションは複数のAPIが連携して動作するため、同時使用時のこれらサービスのパフォーマンスをテストすることが重要です。

組織がマイクロサービスアーキテクチャやAPIファースト開発を採用するにつれ、API負荷テストの重要性はさらに高まっています。現代のアプリケーションは何十、何百ものAPIが同時に通信しており、パフォーマンステストは信頼性とスケーラビリティの維持に不可欠です。

APIパフォーマンステスト

APIパフォーマンステストは、定義されたトラフィックレベル下でAPIがどのように振る舞うか、つまりどれだけ速く応答し、どれだけの作業を完了し、そのうちどのくらいが失敗するかを測定します。負荷テストはこの分野の一つの側面であり、予想されるトラフィック時の動作を問うものです。その他には、一度に大量のトラフィックが発生した場合や継続的にトラフィックが絶えない場合などの動作が含まれます。

このカテゴリーには4種類のテストタイプがあり、それぞれ別の質問に異なる指標で答えます。

• 負荷テストは期待されるトラフィックレベルでAPIを維持し、応答時間が目標内に収まるかを検証します。指標は目標の同時接続数における90パーセンタイル応答時間（p90）であり、平均値ではありません。
• ストレステストは期待値を超えた負荷をかけ、何かが壊れるまで実施します。指標はエラーレートが上昇し始める同時接続数で、通常トラフィックの余裕度を示します。負荷テストとストレステストの違いで詳しく説明しています。
• スパイクテストは段階的増加ではなく、数秒で低負荷から高負荷へ急激に切り替えます。指標はスパイク後、応答時間が基準値に戻るまでの復旧時間です。オートスケーリンググループや接続プールは緩やかな増加では合格してもこれには失敗しがちです。
• ソークテストは中程度の負荷を数時間保持します。指標はドリフトで、長時間にわたり応答時間やメモリ使用量が徐々に上昇する傾向を示します。接続リークや制御されていないキャッシュはここでしか現れません。

同じ4種類のテストを同時接続ユーザー数の推移として描いた図。

応答時間、スループット、エラーレートは全てのテストで収集されますが、最初に注目する指標が異なります。負荷テストでは応答時間、ストレステストではエラーレート、スパイクテストの後半は応答時間の形状、ソークテストは全体の傾きに注目します。

負荷テストだけ実施するのが一般的な落とし穴です。サービスは200の同時接続ユーザーへの漸増負荷を問題なく処理できても、例えばマーケティングメールが4秒間に同数の200ユーザーを送った際には崩壊することもありますし、6時間の間に大量のメモリリークが発生し夜間の再起動を必要とする場合もあります。

なぜAPI負荷テストが重要なのか

API負荷テストは、アプリケーションが高負荷時でもスムーズに動作することを保証します。APIは現代のアプリの基盤であるため、遅延や障害はユーザー体験に直結します。負荷テストによりボトルネックや性能限界が明らかになり、ピーク時の障害を防ぎ、需要に左右されず信頼できるアプリを維持できます。

API負荷テストの利点と実施すべき理由

APIはほとんどの現代ソフトウェアの基盤であるため、負荷テストは価値があります。並行使用時のパフォーマンス、スケーラビリティ、信頼性が保たれているかを示し、APIがサービスレベルアグリーメント（SLA）を満たすことを確認します。

API障害のコストを最小化

APIのパフォーマンス問題を展開前に特定することは、本番環境でのダウンタイム対処よりも組織へのコストを大幅に削減します。負荷テストは予測されるまたは予期しないストレス下で性能が低下するコードのバグを発見し、再現が難しい実装の欠陥も明らかにします。

APIダウンタイムの最小化と緩和

API負荷テストはAPIのリクエスト処理能力を明示し、クラッシュを防止してダウンタイムを防ぎます。また、パフォーマンス問題があるリクエストを特定し隔離することで、リソースをトラフィックが実際に影響する部分に集中させ、ダウンタイムの可能性を減らします。

APIインフラの強化

API負荷テストは異なるユースケースでのリクエスト量を評価し、一つのエンドポイントが処理できる最大同時リクエスト数を特定します。この数値を基に、チームはトラフィック急増に備えた計画を立てられます。

APIパフォーマンスと顧客満足度の向上

多くのエンドポイントと高いユーザー期待があるAPI開発は難しいため、遅延、レイテンシ、スループット制限で苦しむことがあります。負荷テストはこうしたボトルネックを早期に検出し、本番展開前に修正可能にします。

API負荷テストを実施するタイミング

API負荷テストはソフトウェア開発ライフサイクルの複数段階で行う価値があります。開発中にパフォーマンスのボトルネックを早期発見し、予想負荷に耐えられるか、ストレス下で予測可能に動作するかを確認できます。本番環境への展開前にも、スケーラビリティと信頼性をシミュレーション環境で検証します。APIや基盤に大きな変更がある場合にも影響を評価し、新実装が性能基準を満たすかを確認します。定期的な負荷テストも推奨され、性能劣化をユーザー影響前に検出します。

API負荷テストの方法

API負荷テストは8ステップ：目標を数値化し、テストタイプを選び、リクエストを設定し、検証を追加し、負荷曲線を決め、負荷源を選び、テストを実行し、レポートを読みます。以下の説明はapi.restful-api.dev/objectsというキー不要の無料REST APIを使い8ステップすべてを示しています。これは共有の公共サービスなので、練習用は同時25ユーザー程度に留め、実際の200ユーザーは自身のエンドポイントで試してください。

ステップ1：知りたいことを数値で書き出す

目標をチェック可能な数値で書き出します。「APIが速いかどうか」は合否が付けられないため、下記のように具体化します：

200ユーザーが10分間持続した状況で、GET /objectsは90パーセンタイル応答時間400ms未満、エラーレート1%未満を返すこと。

利用しやすくするための4要素は、同時接続数、持続時間、エンドポイント、平均ではなくパーセンタイルに基づくしきい値です。平均値は遅いリクエストの影響を隠します。95リクエストが80ms、5リクエストが6秒の場合、平均は快適な376msですが、5%のユーザーは6秒待っています。

しきい値は既存予算から採るか、低負荷で一度測定し基準とします。URL、メソッド、必要なヘッダー、ボディ（あれば）、認証情報を準備します。ここでは：https://api.restful-api.dev/objects、GET、認証なし。

ステップ2：テストタイプの選択

LoadViewは最初にテストタイプを指定させ、その後の設定が変わります。選択肢はReal Browser（Webアプリ）、HTTP/S、SOAP、Rest WEB API、Postmanコレクション、JMeter、Selenium、Streaming Media、WebSocketです。

テスト対象によってタイプが決まる。

JSONエンドポイントならRest WEB APIを選びます。負荷下での可用性、パフォーマンス、返却データ、認証などをチェックでき、ヘッダー、ボディ、検証フィールドがあります。その他のケースは：

• HTTP/S: 単一URLに対し同時リクエストを送り、サーバーが応答するだけを確認したい場合。
• SOAP: XMLエンベロープ形式のWSDLサービス用。
• Postman (Collection): 既に作成済みのリクエストコレクションをエクスポートしてアップロードする場合。詳細はPostman Collection負荷テストチュートリアル参照。JMeterはJMXプランで同様。

ステップ3：リクエストの設定

スキームを含む完全なURLを入力し、Request Typeでメソッドを指定します：例 https://api.restful-api.dev/objects をGET。

4つのフィールド、うち2つは落とし穴あり。

エラーとみなす応答時間の上限はLoadViewがエラー記録まで待つ時間を秒数で指定し、実は重要です。大きいデフォルトの場合は30秒のリクエストも成功扱いになります。ユーザーが離脱する時間で設定してください。ここでは5秒。

ヘッダーは名前と値のペアでHeadersに入力します。

POSTまたはPUTの場合、ペイロードはBody欄（旧版ではPost Data）に入れます。JSONを貼り付けるとLoadViewが解析し、Content-Typeヘッダーを選択させ追加します：

{
  "name": "LoadView Test Object",
  "data": {
    "year": 2026,
    "price": 1849.99,
    "CPU model": "Intel Core i9",
    "Hard disk size": "1 TB"
  }
}

認証情報はBasic Authentication欄に入力します。トークン認証は二つのリクエストとなり、先にトークンを取得してから使用します。LoadViewはOAuth 2.0ベースAPI向けに、このパターンを説明しています：トークン取得リクエストの後、結果を持つリソースリクエストです。

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Add Targetで二つ目のリクエストを追加します。リクエストはサイドバーの順に実行されます。トークンを受け渡すには、トークンを必要とするパラメータをContext Parameterに変換します。これはURL、ヘッダー、ボディ、スクリプトで使えます。

トークンフローは1回の設定ではなく2つのリクエストです。

ステップ4：検証の追加

バイトが返ってきたかだけをチェックするテストは、APIが500エラーを返していてもクリーンな実行と報告します。失敗はどのテストでも最速の応答なので、2つのポイントを検証します。

期待される応答コードは成功とみなすステータスコードを指定し、それ以外はエラーとして記録します。GETの場合は200に設定します。ステータスコードの意味はRFC 9110に従います。注意点はPOSTで、多くのAPIは成功した作成で201を返すため、作成リクエストは200, 201を設定する必要があります。

3番目のパネルだけが、リクエストが期待通りに動作したことを証明する。

コンテンツ検証はレスポンスボディ内に指定したキーワードを検索します。論理式も使用可能で、&はAND、|はOR、!はNOTを表します：

{["Apple MacBook Pro 16"&"CPU model"]}

成功時にしか現れないキーワードを選択してください。エラーエンベロープにも現れるフィールド名は検証として機能しません。

ステップ5：負荷曲線の設定

LoadViewには3種類の負荷曲線オプションがあります。この説明は、ユーザー数が増えるにつれ応答時間がどう変わるかを見るLoad Step Curveを使います。このテストでは5ユーザーから開始し、6分間で25ユーザーに漸増、5分間保持し、その後2分かけて減少します。自身のエンドポイントなら10ユーザー開始、10分かけて200ユーザー漸増、10分保持、3分減少がおすすめです。保持時間が人々に省略されやすく、重要な部分であり、漸増がどこで反応を変え始めるか、保持が維持できるかを示します。

今回の負荷曲線、全セグメントにラベルあり。

目標ベースのカーブは目標トランザクションレートに合わせ仮想ユーザー数を調整します。トランザクション数目標に向けた要件に合います。動的調整可能カーブはテスト中にユーザー数を手動調整可能で、インフラ拡張効果観察に便利です。

ステップ6：地理的ロケーションの選択

Load Injectorsは北米、南米、ヨーロッパ、APACの40以上のゾーンからスタートします。地理的要素は飾りではありません。クライアントとサーバー間の距離1000マイルごとに、アプリチューニングでは除去できない往復遅延が発生し、TLSハンドシェイクでは何倍もかかります。

今回のテストは米国東部1ゾーンだけを使い、アプリ動作とネットワーク距離を分離しました。基準値確定後、ユーザーの拠点に応じてゾーンを追加します。例えばAPIがus-east-1にある場合、トラフィックの4分の1がドイツからなら、フランクフルトの数字が現地の顧客体験を示します。地理分散負荷注入ネットワークは管理されたもので、設定やサイズ決定の手間はありません。

同じエンドポイントに対し、3地点から計測。

ステップ7：テスト実行とレポート読み取り

LoadViewは実行前に較正を行い、必要なインジェクターサーバー数を算出します。最初の2分間を見守り、5ユーザー時に応答時間が増加するならセットアップ問題でAPI問題ではありません。完全な負荷曲線に費用をかける前に停止・修正してください。その後はテストを放置します。途中でサービスを再起動すると誰も解釈できないグラフになります。

レポートはSummaryタブで開きます：成功セッション数とエラー含むセッション数の概要、その後チャートです。以下の順で読みます。

Execution planが先で、多くの人が飛ばします。実際の仮想ユーザー数（Actual Virtual Users）を期待値（Expected）と最大値（Max Virtual Users）と比較します。実線が期待線に追従すれば、意図した負荷がかかっています。乖離していれば、テストは正しく実行されていません。

4つのチャート、4つの問い、それぞれ聞く価値あり。

Response Timeは平均トランザクション時間と90パーセンタイルを同時にプロットします。線の高さより二つの差を見てください。p90が平均から離れ始めると遅い尾が形成されています。キュー充填、接続プール限界、キャッシュミスの開始です。平均が動く前に差が広がり、この方が早期の警告信号となります。

パーセンタイルが早期警告で平均は遅れ。

Sessions Startedでは総セッション数、成功セッション数、失敗セッション数を比較。負荷増加による応答時間の悪化は普通で許容されることも多いですが、リクエストの失敗は許されません。Sessionsタブで失敗のフィルターを使い、個別の応答、ステータスコード、サーバーレスポンスを確認します。

Load Injector Loadは正気度のチェックで、高負荷のインジェクター使用率と遅いターゲット応答はテストインフラを測定している可能性を示します。以下の3つの指標に注意：

• 応答時間より先にエラーレートが上昇：接続が拒否されている可能性。接続制限、ワーカー数、レート制限を確認。
• 平均は変わらず90パーセンタイルだけ上昇：一部リクエストが遅延パスを通っている。キャッシュミス、インデックス欠如、遅い依存性を調査。
• 平均とp90が共にユーザー数に比例して上昇：飽和状態。しきい値を超えた同時接続数を天井とみなす。

同じ3指標、それぞれ対応策へ誘導。

レイテンシ、トラフィック、エラー、飽和はGoogleのSRE書籍がユーザー向けシステムで推奨する4つのシグナルです。負荷テストは外部から最初の3つを計測し、サーバー内部で飽和を観察してください。ほとんどのシステムは100%利用率に達する前に性能が低下します。レポートビューの詳細はLoadViewによる負荷テスト結果解析方法をご覧ください。

ステップ8：うまくいかなかった原因

POSTを指定したテストでGETが計測されました。リクエストタイプがPOSTに設定されていてエンドポイントも正しいが、ボディがまだ入力されておらず、POST、PUT、PATCHが選択されパラメータなしだと保存時にLoadViewがリクエストタイプをGETに戻す仕様です。警告はありません。読み取り専用エンドポイントに対する書き込みテストとして実行され、クリーンな結果が報告されました。保存前にボディを入力し、再度リクエストを開きメソッドが保持されているか確認してください。

2つ目の落とし穴は静かです。デモAPIは成功した作成で200を返しますが、多くのAPIは201を返します。Expected response codes設定前に手動でリクエストを送りステータスコードを読みましょう。公開APIはレート制限もかけているため、インフラなら耐えられる負荷でエラーレートが上がるなら、ターゲットが制限しているか飽和しているかを確認してください。

LoadViewの公式ドキュメントでは、Rest WEB APIテストの複数リクエストシーケンス設定はやや難しく、複雑な呼び出しにはPostmanを推奨します。4リクエスト以上の連結がプロジェクトになるなら、そちらに切り替える良い機会です。

API負荷テストのベストプラクティス

最も大きく結果に影響する設定は、思考時間、テストデータ、テスト対象環境、ウォームアップ期間、試行回数の5つです。まず一般的な習慣として：

• 専用環境でテストするが、本番に近いデータを使う。
• ベンチマークは事前に定義する。SLAが目標を与える。
• 早期から頻繁にテストし、問題をライブ前に発見する。

これら4つは同意しやすいですが、具体的な実行策となると難しいです。次に各設定の具体例を示します。

APIの呼び出し方に合わせた思考時間を設定

思考時間はリクエスト間の待機時間で、User Behavior Profileで制御します。遅延がゼロに近い場合は最大速度でテストされ、限界値がすぐ見えてリクエストレートが現実的でなくなります。現実的な遅延を入れるとキャパシティとして計画可能な数字が得られます。

どちらが合うかは呼び出し側次第です。スクリーン間のユーザー操作で呼ばれるAPIは数秒の自然な思考時間があるためモデル化します。サービス間のループ内呼び出しは実質ゼロです。思考時間を多めに設定して過大評価する誤りが最も多いです。

各仮想ユーザーに独自のテストデータを持たせる

200ユーザーが同一の/objects/7をリクエストすると、最初の1回だけのリクエストがキャッシュヒットとして応答され、あなたの数値はキャッシュ性能を示すことになります。IDを変えて各ユーザーが異なるレコードに触れるようにしてください。準備スクリプト欄はC#を受け付け、セッションごとに一意値を生成しRazor構文でリクエストボディ参照します：

context.Guid = Guid.NewGuid().ToString();
context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z";
ProcessPostDataByRazor(currentTask);

ボディ内では@Model["Guid"]、@Model["CurrentTime"]として参照。レコードを作成するテストなら削除計画も必要です。6時間書き込み続けるソークテストの後に残ったテーブルは後続テストの妨げになります。

テスト対象を決めてから実施する

本番環境でのテストが最も正確である反面、顧客リスクを伴います。ステージングは安全ですが、そこで得られるのはステージングの結果のみです。実用的なのは、本番と一致する3つの要素（インスタンスサイズ、DB行数、キャッシュ設定）を持つステージング環境です。1万行のDBは4000万行の本番のクエリプランを再現しません。整合しない場合は違いをメモし、結果の誤差方向を把握してください。

計測前にウォームアップ

最初の1分は冷たいキャッシュ、空の接続プール、JIT未適用のコードが測定されます。これらはリアルですが、異なる質問の答えです。漸増負荷が自動で対処します。フラットスタートの場合は最初の60～120秒を破棄し、常に一貫させます。温まった実行と冷えた実行の比較がリグレッションを生みます。

同じテストを3回実行

1回の実行は逸話に過ぎません。共有インフラ、ノイズのある隣人、タイミングの悪いバックグラウンドジョブなどにより、測定変動が設定変更以上になります。

同一設定を3回実行し90パーセンタイル値を比較してください。約10%以内なら行動可能な数字です。それ以上は環境がうるさすぎで測定不可能であり、調整前に測定できません。安定した数字を基準としてそれ以降のテストを比較します。

CI/CDにおけるAPI負荷テスト自動化

パイプラインからテストをトリガーし、しきい値未達時にビルドを失敗させる自動化が可能です。LoadViewはAzure DevOps、Jenkins、CircleCI向けCI/CD連携機能を提供し、まさにこれを実現しています。多くのチームは最初の成功実行で止めてしまいますが、基準値が役割を果たし続けるには継続が必要です。

費用に応じて作業を分割してください。1～2エンドポイントを対象に低同時接続・数分間の短時間チェックはmainへのマージ毎に向きます。インデックス喪失などの早期検知に有用です。フル負荷曲線はリリース候補（release candidate）に任せましょう。200ユーザーを全コミットで実行すると、既に解決した質問にお金を使っていることになります。

マージ毎に短時間チェック、リリース候補にフル曲線。

ゲートはFailed Sessions Thresholdで、許容失敗セッション割合を設定し、超過したらビルド失敗です。

このしきい値はエラーに関するものであり、遅延は含みません。すべてのセッションが3倍のp90で成功したビルドは失敗セッションゲートを問題なく通過します。そのため応答時間は別チェックが必要で、p90を取り基準値と比較し、どの程度の悪化をリグレッションとみなすか事前に決めておきます。20%超えから始め、環境ノイズ状況に合わせて調整してください。

テスト定義はツールが許す限りバージョン管理下に置きます。JMXファイルやPostmanコレクションはテスト対象コード変更時に同時更新されます。ノイズ多い環境を放置するとゲートが頻繁に失敗し、1～2週間で運用停止され、ゲートも習慣も失います。

API負荷テストツール比較

Apache JMeter、Postman、Grafana k6、SoapUI、LoadViewは主要なAPI負荷テストをカバーし、同じジョブを競合するわけではありません。機能数よりも負荷発生元とテスト実行場所で選択してください。

1) LoadViewは40以上の管理されたインジェクターゾーンを使うため、40ゾーン以上の負荷テストが構成で済み調達不要、リアルブラウザテストも併用可能です。JMXやPostmanコレクションをインポートでき、既存テストプランも活用可能。オンデマンド、サブスク、エンタープライズプランあり。軽量テストを全コミットで走らせる用途はパイプラインのCLIツールも立ち位置あり。

2) Apache JMeterは最も高機能な無料オプションでプラグインエコシステムも最深。HTTPを超えDBやメッセージキューも扱う。コストはライセンスではなく運用工数。負荷発生装置を用意・監視し、5か国から負荷なら5か国にマシンを用意する必要あり。

3) Postmanは既存リクエストから負荷数値までの導線が最短。機能テストで作成したコレクションをローカルかPostmanクラウドで走らせる。エンドポイントチケット開く前に手早くチェックしたいエンジニアに最適。容量計画向けではなく開発時検査ツールとして位置付け。

4) Grafana k6はパフォーマンステストをバージョン管理に組み込みたい場合最適。テストはJavaScriptでコードレビュー、差分チェックができ、CIでユニットテスト同様にしきい値でビルド失敗にできます。プルリクごとにチェックが条件ならLoadViewよりこちらが望ましい選択肢としておすすめします。

5) SoapUIはREST、SOAP、GraphQLの機能、セキュリティ、負荷、モックを1つでカバー。機能テストを負荷テストに再利用できるのが強みで、SOAP環境で特に有効。ReadyAPIはSmartBear社の商用製品で大規模負荷モジュール搭載。

始める場所

最も遅延が経済的ダメージにつながる単一点（ログイン、検索、決済が多い）を選択。Rest WEB APIテストを1つ設定し、期待ピークまで漸増し10分間保持、同じ設定を1地点から3回実行。これで午後にはベースライン完成。全システムを一度にモデル化しようと迷走しがちです。

API負荷テストFAQ

以下はAPIの負荷テストを始めた後でよくある質問です。各回答は独立しています。

LoadViewでAPIを負荷テストする

LoadViewでのAPI負荷テストは、APIに複数回の連続呼び出しを送るスクリプトを作り、同時ユーザー数を期待負荷の限界まで拡大するだけで簡単に実行できます。スクリプトは再利用可能で、サービス稼働期間中のモニタリングにも活用可能です。

LoadViewのAPI負荷テストはJSON、XMLを含むRESTful API、SOAP、認証や多段階実行を要するWeb APIをサポートします。APIテストの要件に応じて複数の負荷曲線から選べます。

負荷曲線は3種類あります。指定した同時ユーザー数で一定時間負荷をかけるロードステップカーブ、指定トランザクションレートを自動調整する目標ベースのカーブ、テスト実行中に手動で負荷を変えられる動的調整可能カーブです。

またLoadViewは40以上の地理的リージョンに負荷を分散可能で、ユーザーに最も近い場所を選ぶことで最も正確なシミュレーションが可能です。