LASSIC Media らしくメディア

2026.06.19 らしくコラム

負荷テスト・性能テストを外注する費用と進め方|シナリオ設計と性能ボトルネック特定の判断軸

LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託

性能グラフの画面

この記事のポイント

  • 負荷テスト・性能テストの外注費用は「シナリオ数×環境規模×期間×レポート深度」の4要因で変動し、事前要件整理の質が費用精度を大きく左右します
  • IPA非機能要求グレードが定める性能要件の枠組みを知ることで、発注前のKPI合意とシナリオ設計がスムーズになります
  • 外注先選定ではツール対応範囲だけでなく、ボトルネック分析レポートの深度と元請(プライムベンダー)かSES紹介かという契約形態の確認が判断軸になります

負荷テスト・性能テストの定義と種類

負荷データの可視化

負荷テスト・性能テストの外注とは、自社内では完結しにくいシステム性能検証の設計・実施・分析を、専門知識とツールを持つ外部パートナーに委託する取り組みです。

性能テスト(上位概念) ロードテスト 想定負荷での 安定性を検証 ストレステスト 限界超過時の 挙動を確認 スパイクテスト 瞬間的な負荷 変化への対応 耐久テスト 長時間稼働時の 性能維持を確認
図1:性能テストと負荷テスト4種の関係(GENZ「性能テストと負荷テストの違いとは」2025年をもとに作成)

性能テストと負荷テストの位置づけ

性能テストとは、システムが通常の使用状況でどれだけ効率よく動作するかを評価するテストです。応答時間や処理速度、リソース使用状況を検証し、要件を満たしているか確認します。

負荷テストは性能テストの一種で、システムに高い負荷をかけた際の動作や安定性を評価します。通常の使用状況ではなく、限界値に近い高負荷状態での耐久性や障害しきい値の確認が目的です*1

負荷テスト4種の特徴

負荷テストは目的に応じて4つの種類に分かれます。ロードテストは想定負荷での安定性を検証します。ストレステストは限界を超えた負荷をかけ、システムがどう応答するかを確認します。

スパイクテストは、セールやキャンペーンなど瞬間的な負荷急増への対応を確認するテストです。耐久テスト(ソークテスト)は、長時間の継続稼働でメモリリークや性能劣化が起きないかを検証します。

これら4種のどれを実施するかは、リリースするシステムの特性と事業リスクに応じて決まります。外注前にどの種類が必要かを整理しておくことが、費用見積もりの精度向上につながります。

外注が有効な3つの条件

性能テスト・負荷テストの外注が特に有効に機能するのは、以下の3つの条件に当てはまる場合です。

社内にツール運用スキルがない場合

負荷テストには、Apache JMeter(ジェイメーター)やGrafana k6(ケーシックス)、Gatling(ガトリング)などの専門ツールの習熟が必要です。シナリオのスクリプト作成からテスト実行、結果分析まで、特定の知識がなければ正確な検証を行うことが難しくなります。

ツールの学習コストと社内習熟のための時間を考えると、外注によって専門家の知見をそのまま活用するほうが、品質と速度の両面で優れている場合があります。

本番同等の環境を用意できない場合

負荷テストの信頼性は、テスト環境が本番環境にどれだけ近いかに依存します。本番同等のサーバースペック・データ量・ネットワーク構成を社内で用意することは、中小規模の開発体制では難しいことがあります。

外注先が本番同等環境の調達や構築を支援できる場合、テスト結果の信頼性が大幅に向上します。

第三者視点の客観的な評価が必要な場合

開発チームが自ら性能テストを実施すると、設計上の前提を無意識に引き継いだシナリオになる場合があります。外注先が第三者として客観的に実施することで、見落としリスクを下げられます。

特に、金融・医療・EC(電子商取引)などのシステムでは、第三者検証の実績が顧客や監査への説明責任に直結することもあります。

外注前に整えるシナリオ設計5ステップ

外注先に依頼する前に発注側が準備すべきシナリオ設計の手順を整理します。この準備の質が、外注費用の見積もり精度と最終的なテスト品質を左右します。

ステップ1—KPI(応答時間・スループット・同時接続数)の合意

テストの成否を判断するKPIをステークホルダー間で事前に合意します。主要な指標は「応答時間(レスポンスタイム)」「スループット(単位時間あたりの処理件数)」「同時接続数」「リソース使用率(CPU・メモリ)」の4つです*2

「ページ表示が3秒以内」という曖昧な目標ではなく、「ピーク時500同時接続で95パーセンタイルのレスポンスタイムが2秒以内」のように数値化することで、外注先との認識齟齬を防げます。

ステップ2—ユーザージャーニー分析とシナリオ定義

実際のユーザー行動を模倣したシナリオを定義します。ECサイトであれば「商品検索→商品詳細→カート追加→決済」という一連のフローを再現する必要があります。

主要機能の特定、操作フローの定義、シナリオに使うデータパターンの設計の3点を発注前にまとめておくことで、外注先がシナリオを精度よく作成できます*2

ステップ3—負荷パターンの選択

負荷のかけ方には「段階的増加(ランプアップ)」「一定負荷の継続」「スパイク型の急増」の3つのパターンがあります。自社システムのアクセス特性(定常トラフィックが多いか、イベント時に急増するかなど)に合わせて選びます*2

複数のパターンを組み合わせることも可能ですが、組み合わせるほど工数と費用が増加します。優先順位を整理してから外注先に伝えることが大切です。

ステップ4—テスト環境の合意

テスト環境が本番の何パーセント規模か、テストデータはどう用意するか、外部API(アプリケーションプログラムインターフェース)の呼び出し可否をどう扱うかを事前に合意します。

本番とかけ離れた環境でのテストは結果の解釈を難しくします。外注先がどの程度の環境構築支援を行えるかも、選定段階で確認すべきポイントです。

ステップ5—結果判定基準の事前合意

「KPIを満たしていれば合格」という判定基準を書面で合意します。外注先が出すレポートには、エラー率・パーセンタイルレスポンスタイム・スループットのグラフが含まれるのが一般的です。それぞれの指標の合否ラインを事前に設定しておくと、テスト完了後の判断が明確になります。

性能ボトルネック4類型と特定の判断軸

負荷テスト・性能テストで発見されるボトルネックは、大きく4つに分類できます。外注先に分析を依頼する際、どの層の問題かを把握していると、レポートの内容を正確に理解し、改善優先度の判断がスムーズになります。

DBクエリ遅延(N+1問題・インデックス不足)

最も頻繁に発生するボトルネックのひとつがデータベース(DB)クエリの遅延です。N+1問題(1回のリクエストで大量の追加クエリが発生するパターン)やインデックス不足が、高負荷時に応答時間の急増を引き起こします。

テスト結果のスロークエリログと実行計画を外注先から提供してもらうことで、改善箇所を特定しやすくなります。

アプリサーバーのメモリ・CPU圧迫

一定負荷を継続してかけると、アプリサーバーのメモリ使用率が段階的に上昇し、最終的にGC(ガベージコレクション)の頻発や応答停止を引き起こす場合があります。これはメモリリークや過剰なセッション保持が原因であることが多いです。

耐久テスト(長時間負荷)を実施し、CPU・メモリの推移グラフを継続取得することで、こうした問題を検出できます。

ネットワーク帯域・CDN設定

静的コンテンツ(画像・CSS・JavaScript)の配信がボトルネックになるケースもあります。CDN(コンテンツデリバリーネットワーク)の設定不備やオリジンサーバーへの過剰な直接アクセスが原因です。

ネットワーク層のボトルネックは、アプリの改修ではなくインフラ設定の変更で解決できることが多く、対処コストが比較的低い類型です。

外部API依存による連鎖遅延

決済API・認証サービス・地図API(アプリケーションプログラムインターフェース)など外部サービスへの依存が、高負荷時に連鎖的な遅延を引き起こすことがあります。外部APIのタイムアウト設定やリトライ処理の設計が不十分な場合、内部処理は問題なくても全体の応答時間が増大します。

外注先が外部APIをモック化(仮想化)してテストできるかどうかも、選定時の確認事項になります。

ツール3種(JMeter・k6・Gatling)の選択基準

外注先が使用するツールは、テストのシナリオ表現力・CI/CD(継続的インテグレーション・継続的デリバリー)連携・コストに影響します。主要3ツールの特徴を把握しておくと、外注先との技術的な対話がスムーズになります。

ツール名 ライセンス スクリプト言語 CI/CD連携 特徴・向いているケース
Apache JMeter OSS(無料) GUIまたはXML 可(CLIモード対応) HTTP/HTTPS・FTP・JDBC・JMS・SMTPなど多プロトコル対応。
GUIでシナリオ作成できるため、非エンジニアでも操作可能。
大規模な実績と豊富なプラグインが強み*3
Grafana k6 OSS+SaaSあり JavaScript 優れる(設計思想上) JavaScriptでシナリオを記述しGit管理が容易。
21の負荷ゾーンからグローバルなトラフィックパターンを再現可能。
Grafana・Datadog等との統合が得意*4
Gatling OSS+商用あり Scala/Java/Kotlin AIを活用した継続的パフォーマンステストプラットフォームとして進化。
「テスト・アズ・コード」の設計思想を採用。
30万社以上での利用実績を持つ*5

ツール選択は外注先の得意領域と自社の既存技術スタックに依存します。「CIパイプラインへの組み込みを将来的に検討している」「既存のGrafanaダッシュボードを活用したい」などの方針があれば、外注先の選定段階でその旨を伝えることで、適切なツールを選択してもらえます。

外注費用を左右する4つの要因

性能テスト・負荷テストの外注費用は個別見積もりが主流であり、公開された一次資料による業界相場は存在しません(以下は市場参考値・一次資料ではない情報です)。費用は主に以下の4つの要因によって変動します。

費用を決める4つの要因

  • シナリオ数・複雑度:テストシナリオの数が増えるほど作成・実行・分析の工数が増加します。ユーザーフローが複数ある大規模サービスほど費用が高くなる傾向があります。
  • 環境規模・構築コスト:本番同等環境の用意が必要な場合、クラウドのインスタンス費用や環境構築工数が加算されます。既存のステージング環境を活用できる場合は費用を抑えられます。
  • テスト期間・繰り返し回数:一回限りのテストか、開発サイクルに組み込んだ継続的なテストかで総費用が変わります。CI/CDへの統合まで依頼する場合は初期投資が大きくなります。
  • レポートの深度・改善提案の有無:ボトルネックの検出にとどまるか、改善案の提案まで含むかでスコープが変わります。改善提案まで依頼するほど工数と費用が増加します。

内製と外注のコスト比較軸

内製で性能テストを実施する場合、ツールのライセンス費(k6・JMeterはOSSで無料)に対して、エンジニアの学習時間・シナリオ設計工数・環境準備工数が発生します。外注先に依頼する場合は学習コストが不要な半面、委託費用が発生します。

一度だけのリリース前検証であれば外注が合理的なケースが多く、継続的に実施する場合は社内にノウハウを蓄積するか、SLA(サービスレベル契約)付きの継続契約を外注先と結ぶかを検討する価値があります。

外注先選定の5つの判断軸

性能テスト・負荷テストの外注先を選ぶ際には、費用だけでなく以下の5軸で比較することが大切です。

対応ツール・プロトコルの幅

自社システムが使用しているプロトコル(HTTP/HTTPS・WebSocket・gRPCなど)に対応できるかを確認します。WebSocketやリアルタイム通信の負荷テストは、JMeterでは設定が複雑になるケースもあります。外注先が複数ツールを使い分けられると柔軟性が高くなります。

本番同等環境の調達力

外注先がAWS・Azure・GCPなどのクラウドで本番同等環境を迅速に構築・撤去できる体制を持っているかは重要な判断軸です。テスト期間中だけの一時的な環境コストを最小化できる能力も確認します。

ボトルネック分析レポートの深度

「エラー率が20%でした」という数値の報告だけではなく、「スロークエリXXがボトルネックで、インデックス追加で改善できる」という原因と改善方向まで提示されるかを確認します。レポートサンプルを事前に見せてもらうことが最善の確認方法です。

元請(プライムベンダー)かSES紹介か

外注先が直接テストを実施する元請(プライムベンダー)か、技術者を紹介するSES(システムエンジニアリングサービス)型かで、品質管理の責任範囲が変わります。元請型であれば成果物への責任が明確であり、問題発生時の窓口が一本化されます。SES型は人材の知識・スキルへの依存度が高くなるため、担当者の経験レベルを選定時に確認する必要があります。

過去の類似案件実績

自社と同規模・同業種のシステムでの実績を持つかを確認します。ECサイトと金融系基幹システムでは、想定すべき負荷パターンやリスク感度が異なります。実績がある場合は、過去に検出したボトルネックの事例や改善効果の概要を聞いてみることで、技術レベルを判断しやすくなります。

まとめ:外注判断の3つのポイント

本稿では、負荷テスト・性能テストの外注における費用と進め方を整理しました。要点を3つに集約します。

第一に、外注費用は「シナリオ数・環境規模・期間・レポート深度」の4要因で変動します。費用の精度を上げるには、発注前にKPIとシナリオを整理しておくことが重要です。

第二に、IPA非機能要求グレード2018が示す性能要件の枠組み(応答時間・スループット・同時接続数など)を基準として、発注側とベンダー側が同じ言葉で要件を語れる状態を作ることが、テスト品質の前提です。

第三に、外注先の選定では対応ツールの幅とレポートの深度に加え、元請(プライムベンダー)型かSES型かという契約形態の確認が欠かせません。成果物への責任が明確な体制かどうかが、最終的な品質担保に直結します。

よくある質問

負荷テストと性能テストはどう違いますか?

性能テストはシステムが通常の使用状況でどれだけ効率よく動作するかを評価する上位概念のテストです。負荷テストはその一種で、システムに高い負荷をかけたときの動作・安定性・耐久性を評価することに特化しています。負荷テストはさらにロードテスト・ストレステスト・スパイクテスト・耐久テストの4種に分かれます(参考:GENZ「性能テストと負荷テストの違いとは」2025年)。

負荷テストの外注費用は事前に確認できますか?

外注費用は個別見積もりが主流であり、公開された業界相場は存在しません。費用を左右するのは「シナリオ数・複雑度」「環境規模・構築コスト」「テスト期間・繰り返し回数」「レポートの深度・改善提案の有無」の4要因です。事前にシナリオ数とKPIを整理した状態で複数の外注先に見積もりを依頼すると、比較が容易になります。

JMeter・k6・Gatlingのどれを選べばよいですか?

用途と技術スタックによって異なります。GUIで操作しやすさを重視するならApache JMeterが向いています。JavaScriptが書けるチームでCI/CD統合を重視するならGrafana k6が適しています。Scala/Java環境でテスト・アズ・コードを徹底したい場合はGatlingが選ばれます。いずれもOSS版は無料で利用でき、外注先が得意とするツールで選ぶことも実用的な判断です。

負荷テストはリリース直前にだけ実施すればよいですか?

リリース直前の一度だけでも有効ですが、継続的に実施することでより高い効果が期待できます。開発サイクルにCI/CDを通じた性能テストを組み込むと、コード変更による性能劣化を早期に検出できます。また大規模なリリースやキャンペーン施策の前だけでなく、インフラ構成の変更・ライブラリのバージョンアップ時にも実施することが推奨されます。

IPA非機能要求グレードは負荷テストの外注にどう役立ちますか?

IPA(独立行政法人情報処理推進機構)が公開している非機能要求グレードは、システムの性能要件(応答時間・スループット・データ量など)を段階的に整理するための枠組みです(参考:IPA「非機能要求グレード」アーカイブ)。この枠組みを参照してKPIを設定することで、発注側とベンダー側が同じ基準で要件を語れるようになり、見積もりの精度向上と認識齟齬の防止につながります。

著者:テレリモ総研編集部 鈴木 亮佑

LASSICに相談するメリット

LASSICはシステム保守・運用の元請(プライムベンダー)として、要件定義の段階から参画し、シナリオ設計・テスト実施・ボトルネック分析レポートまで一貫して対応できる体制を整えています。外注先の選定や進め方についてのご相談もお気軽にどうぞ。


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

  1. *1 出典:株式会社GENZ「性能テストと負荷テストの違いとは」(2025年8月)
  2. *2 出典:株式会社みんなシステムズ テスター10「負荷テストの設計手順を完全ガイド」(2025年1月)
  3. *3 出典:Apache Software Foundation「Apache JMeter 公式サイト
  4. *4 出典:Grafana Labs「k6 公式サイト
  5. *5 出典:Gatling Corp「Gatling 公式サイト


View