負荷テストとは？発注者が性能保証を確認する手順と判断基準

ベンダーから提出されたテスト計画書に「負荷テスト」の行があり、後日「実施済みです。問題ありませんでした」という報告書が届く。そこには見慣れないグラフと数字が並んでいるものの、それが本番のアクセスに耐えられる根拠になっているのかどうかを、自分では判断できない。そんな状態で検収印を押そうとしている発注担当者の方は少なくありません。

判断が難しいのには理由があります。負荷テストを解説する情報の多くは、テストを実施する側の視点で「どう設計し、どう実行するか」を説明しています。しかし発注者に必要なのは、テストの実施方法ではなく、提出された結果が信用に足るかどうかを見抜く目です。用語の意味を調べても「何秒なら合格なのか」という基準は書かれておらず、結局は「ベンダーが問題ないと言っているから大丈夫だろう」という判断に落ち着いてしまいます。そしてリリース後に性能不足が発覚したとき、社内で説明責任を負うのは発注側の担当者です。

この状況を抜け出すために必要なことは、大きく3つに整理できます。1つ目は、自社の利用実態から性能要件を数値として決めること。2つ目は、報告書の測定条件が本番を代表しているかを検証すること。3つ目は、決めた基準を要件定義書・検収条件・契約に落とし込んで、性能を「お願い」ではなく「合意事項」に変えることです。この3つが揃えば、負荷テストの専門知識がなくても、性能保証の可否を自分の言葉で判断し、必要な要求をベンダーに出せるようになります。

本記事では、負荷テストとは何を測るテストなのかという基本から、テストの種類の選び分け、性能要件の数値の決め方、報告書で確認すべき5つのポイント、契約・検収での担保方法、そして費用の考え方までを、発注者の立場から順に解説します。最後に、要件定義から検収までの各フェーズで使えるチェックリストにまとめていますので、手元の計画書や報告書と照らし合わせながらお読みください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

負荷テストとは？発注者が知るべき目的と性能テストとの違い

負荷テストとは、システムに対して制御された方法で現実的な負荷状態を作り出し、その状態でのシステムの性能・可用性・処理能力・拡張性を評価するテストのことです。ここでいう「負荷」とは、同時にアクセスするユーザー数、単位時間あたりのリクエスト数、処理するデータ量などを指します。実際の利用者を集めるのではなく、テストツールから疑似的なリクエストを大量に発生させ、そのときのシステムの振る舞いを測定します。

機能テストが「押したボタンが正しく動くか」を確かめるのに対し、負荷テストは「大勢が同時に押したときも正しく、かつ十分な速さで動くか」を確かめます。単体テストや結合テストをすべて通過したシステムでも、負荷がかかった瞬間に応答が遅くなったり、エラーを返し始めたりすることは珍しくありません。負荷テストは、その「混雑時の挙動」だけを対象にした専門のテストだと考えてください。

負荷テストが検証しているのは「壊れないこと」ではなく「どこで壊れるか」

発注者が誤解しやすいのが、負荷テストの目的です。「落ちないことを確認するテスト」と理解している方が多いのですが、それは目的の半分にすぎません。もう半分は、どこまでの負荷なら耐えられ、その先で何がどう壊れるのかという限界点を把握することです。

システムはあるラインを超えると、性能が緩やかに落ちるのではなく、急激に崩れます。応答時間が数百ミリ秒から一気に数十秒に跳ね上がり、タイムアウトが連鎖し、最終的に全ユーザーがアクセスできなくなる、という壊れ方をします。この「崩れ始めるライン」がどこにあるのかを知らないまま運用を始めると、想定外のアクセスが来たときに何が起きるかを誰も予測できません。

AWS の規範ガイダンスでも、負荷テストの計画では「アプリケーションはどのくらいの負荷に耐えられるか」「X の負荷を処理できるか」「自動的にスケールするか」「一定の負荷が続くと経時的に性能が劣化するか」といった問いを最初に明確にすることが推奨されています（AWS 規範ガイダンス「負荷テストの基本」）。裏返せば、「問題ありませんでした」としか書かれていない報告書は、この問いのどれにも答えていないということになります。

発注者としては、「うちのシステムは何人まで耐えられますか」という質問を必ず投げてください。この質問に数字で答えられないベンダーは、限界点を測るテストを実施していない可能性があります。

性能テスト・パフォーマンステストとの違いと包含関係

「性能テスト」「パフォーマンステスト」「負荷テスト」は、現場でも混在して使われる言葉です。厳密な定義は組織によって異なりますが、発注者としては次の包含関係で捉えておくと実務上の判断を誤りません。

問題になるのは、ベンダーから「性能テストは実施済みです」と報告されたケースです。この言葉には、開発者が1人でブラウザを操作して「表示は速いですね」と確認した程度のものから、本番同等環境で数千ユーザー相当の負荷をかけた本格的な測定まで、まったく異なるレベルのものが含まれ得ます。「性能テスト実施済み」の一言に負荷テストが含まれているとは限らない、という前提で確認してください。

確認の仕方はシンプルです。「その性能テストでは、同時に何ユーザー相当の負荷をかけましたか」と聞いてください。この質問に具体的な数字が返ってこなければ、負荷をかけた測定は行われていないと考えたほうがよいでしょう。

発注者にとって負荷テストは「性能保証の証拠」になる

負荷テストの結果報告書は、技術文書であると同時に、発注者にとっての証拠書類でもあります。「このシステムは、これだけの条件で、これだけの性能を出すことが確認されている」という事実を、第三者にも説明できる形で残したものだからです。

この視点を持つと、報告書に求めるべき内容が変わります。単に「速かった」「エラーは出なかった」という結論ではなく、どういう条件で測ったのか（前提）、何を目標としていたのか（基準）、実測値はいくつだったのか（結果）の3点セットが揃っていて初めて、証拠として機能します。3点のうち1つでも欠けていれば、それは「ベンダーの所感」であって「性能の保証」ではありません。

経営層から「本番で耐えられるのか」と問われたとき、発注者が示すべきものはこの3点セットです。この後で、3点をそれぞれどう作り、どう検証するかを順に見ていきます。

負荷テストの種類と、発注者が実施範囲を決める判断軸

負荷テストは、かける負荷の「かけ方」によっていくつかの種類に分かれます。それぞれが対応しているビジネスリスクは異なるため、すべてを実施しなければならないわけでも、1つだけで十分なわけでもありません。自社のサービス特性から、どの種類が必須なのかを発注者側で判断できるようにしておくことが重要です。

ロードテスト（指定負荷テスト）

想定される通常のピーク負荷をかけて、性能要件を満たすかを確認するテストです。「平日昼休みに 500 人が同時に利用する」といった、日常的に起こりうる最も混雑した状態を再現します。

対応するリスクは「通常運用の範囲で遅くなる」ことです。負荷テストと聞いて多くの人が想像するのがこのタイプで、ほぼすべてのシステムで実施する価値があります。ベンダーが「負荷テストを実施しました」と言う場合、まずこのロードテストを指していると考えてよいでしょう。

ストレステスト（限界負荷テスト）

想定を超える負荷を段階的にかけ続け、システムが破綻する限界点と、そのときの壊れ方を確認するテストです。前述の「どこで壊れるか」を明らかにするのがこのテストの役割になります。

対応するリスクは「想定外のアクセスが来たときに、何が起きるか分からない」ことです。限界を超えたときにエラー画面を返して踏みとどまるのか、データベースが破損するのか、復旧に何時間かかるのかは、事前に測っておかなければ分かりません。想定を超えるアクセスがビジネス上ありうるシステムでは、実施を強く推奨します。

ロングランテスト（連続負荷テスト）

一定の負荷を長時間（数時間から数日）かけ続け、時間の経過とともに性能が劣化しないかを確認するテストです。耐久テスト、ソークテストとも呼ばれます。

対応するリスクは「稼働してしばらく経つと遅くなる・落ちる」ことです。メモリリーク（使用済みメモリが解放されずに蓄積していく不具合）や、一時ファイル・ログの肥大化、データベース接続の枯渇といった問題は、短時間のテストでは表面化しません。24時間365日稼働させるシステムや、再起動の機会がないシステムでは必須と考えてください。リリース後1週間経ってから急に不安定になる、という事象の多くはこのテストで防げます。

スパイクテスト・ボリュームテスト

スパイクテストは、短時間に急激な負荷の増減を与えて、システムが追随できるかを確認するテストです。キャンペーン開始直後、テレビ放映直後、チケット販売開始時刻といった、負荷が数秒で数十倍に跳ね上がる場面を再現します。クラウド環境の自動スケール機能は負荷の増加を検知してから増強するまでにタイムラグがあるため、「スケールする設計だから大丈夫」という説明だけでは、急峻な立ち上がりに間に合うかどうかは分かりません。

ボリュームテストは、大量のデータが蓄積された状態でシステムが要件を満たすかを確認するテストです。運用開始直後はデータが少なく快適に動いていたシステムが、3年後にデータが数百万件になった途端に検索が数十秒かかるようになる、というのは典型的な失敗パターンです。リリース直後ではなく、想定される数年後のデータ量で測っているかを確認してください。

自社サービスの特性から必須の種類を選ぶ判断表

以下の表で、自社のサービスに当てはまる特性を確認し、対応する種類をベンダーへの要求に含めてください。すべてに丸をつける必要はなく、当てはまらないものを外していく使い方が現実的です。

この表を持ってベンダーと会話すると、「なぜこの種類が必要なのか」を事業リスクの言葉で説明できるようになります。逆に、ベンダーの提案する範囲に自社の特性に対応する種類が含まれていない場合は、その理由を確認してください。

性能要件の決め方｜「サクサク動く」を数値に翻訳する

ここからが、発注者にとって最も重要なパートです。合格・不合格を判定する基準を持っていなければ、どれだけ立派な報告書を受け取っても判断はできません。そして、その基準を決められるのは発注者だけです。ベンダーは自社の業務量も、利用者の許容度も知らないからです。

性能要件は、システムの機能そのものではなく「どの程度の品質で動くか」を定める非機能要件の一部にあたります。非機能要件の全体像については機能要件と非機能要件の違いを先に押さえておくと、性能要件の位置づけが理解しやすくなります。

要件定義の場で「サクサク動くようにしてください」と伝えた記憶がある方は多いと思います。この一言は、ベンダー側からは何も測定できない指示です。以下の手順で、これを測定可能な数値に翻訳していきます。

レスポンスタイムの目標値をどう決めるか

レスポンスタイムとは、利用者が操作してから結果が返るまでの時間のことです。目標値を決めるときのポイントは、画面や処理の種類ごとに基準を分けることです。すべての画面を一律「3秒以内」と決めてしまうと、重い集計処理を含む画面で無理な作り込みが必要になり、コストが跳ね上がります。

現実的な分け方の例を挙げます。

目標値を決めるときの現実的な出発点は、「今の業務でどれくらい待たされたら困るか」を利用部門にヒアリングすることです。「1日に200回開く画面が5秒かかると、1日あたり約17分待っていることになる」といった換算をすると、社内での合意も取りやすくなります。

もう1つ重要なのが、目標値を「平均」ではなく「上位何パーセントが基準内に収まるか」で定義することです。これについては報告書の読み方のところで詳しく扱いますが、要件を書く段階で「95% のリクエストが2秒以内」という形にしておくと、後の判定が明確になります。

スループット・同時接続数を業務量から見積もる

スループットとは、単位時間あたりに処理できるリクエストや処理の件数のことです。「1秒あたり100リクエスト」「1時間あたり5,000件の受注登録」といった形で表します。同時接続数は、ある瞬間にシステムへ接続している利用者やセッションの数です。

技術の知識がなくても、業務量から概算する手順は以下のとおりです。

1. 月間（または日間）の総処理件数を出す。例:月間の受注件数 60,000 件
2. 業務日数・稼働時間で割って、平均値を出す。例:月20営業日・8時間稼働なら、1時間あたり 375 件
3. ピーク集中率を掛ける。業務システムでは始業直後・昼休み明け・締め時刻に集中することが多く、平均の2〜3倍を見込むのが一般的です。例:3倍として 1時間あたり 1,125 件
4. 秒あたりに換算する。1,125 ÷ 3,600 秒 ≒ 0.31 件/秒
5. 1件の処理に伴うリクエスト数を掛ける。1件の登録操作で画面遷移・API 呼び出しが10回発生するなら、約3.1 リクエスト/秒

この数字自体の精度はさほど高くありませんが、重要なのは根拠を持った数字を発注者側から提示できることです。「よく分からないので適当に多めで」と伝えると、ベンダーは過大な想定で見積もるか、逆に無難な小さい数字で済ませるかのどちらかになります。

そもそもピーク時の想定値が読めないというケースもあります。その場合は次の3つのいずれかで代替してください。

• 既存システムの実績値を使う:置き換え対象のシステムがあれば、そのアクセスログやデータベースの登録件数から実測できます。最も精度の高い方法です
• 類似サービスの繁忙比から逆算する:同業種・同規模のサービスにおける平常時とピーク時の比率を参考にします
• 事業計画から逆算する:「3年後に会員10万人」という目標があるなら、その利用率・訪問頻度から必要なスループットを算出します

いずれの場合も、「この数字はこういう前提で置いた」という根拠を要件定義書に残してください。前提が変われば要件も変わる、という共通認識をベンダーと持てるようになります。

リソース使用率と余裕率をどこに置くか

レスポンスタイムとスループットが目標を満たしていても、そのときサーバーの CPU 使用率が 98% に張り付いているなら、それは「かろうじて間に合っている」状態です。少しでも想定を超える負荷が来れば崩れますし、将来の利用者増にも耐えられません。

そこで、性能要件にはリソース使用率の上限も含めます。目安としては、ピーク負荷時に CPU 使用率・メモリ使用率が70〜80% 以内に収まっていることを基準とする考え方が広く使われます。残りの20〜30% が、想定外の負荷や将来の成長に対する余裕（バッファ）になります。

余裕率をどこに置くかは、事業の成長見通しとコストのバランスで決まります。利用者が急増する見込みがあるなら余裕を厚めに取り、安定した業務システムなら薄めでも構いません。クラウド環境で自動スケールが機能する構成なら、余裕率そのものよりも「スケールが完了するまでの時間内に耐えられるか」が判断軸になります。この場合は、スパイクテストの結果とセットで確認してください。

IPA非機能要求グレードを発注者とベンダーの共通言語にする

ここまでの数値を、発注者とベンダーが同じ理解で共有するための道具として、IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」が有用です。これは非機能要件について、ユーザーと開発者の認識の行き違いを防ぐことを目的に作られた無償のツールです（IPA 非機能要求グレード）。

非機能要求グレードは、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6つの大項目で構成されており、性能要件は「性能・拡張性」に含まれます。特徴的なのは、単に「何を決めるべきか」を示すだけでなく、社会的影響度に応じた3つのモデルシステムを提示し、それぞれで「どのレベルに合意すべきか」を段階的に示している点です。

発注者にとっての使いどころは、大きく3つあります。

1. 要件の漏れを防ぐチェックリストとして使う:項目一覧を眺めるだけで、自分が考慮していなかった観点（同時利用者数、データ保持期間、業務量の増加率など）が見つかります
2. レベル感の合意に使う:「うちは社会的影響度でいえば中程度なので、このモデルシステムを基準にしたい」と伝えることで、過剰仕様も過少仕様も避けられます
3. RFP・要件定義書の様式として使う:活用シートをそのままプロジェクトの様式として使えば、ベンダーごとに異なる書式で提案が来る事態を防げます

すべての項目を埋めようとすると膨大な作業になります。IPA 自身も、重要な項目から段階的に進めることを推奨しています。性能に絞るなら、「性能・拡張性」の項目だけを抜き出して合意する使い方で十分に効果があります。

負荷テストはいつ・どの環境で実施するのか｜体制・ツール・タイミング

性能要件が決まったら、次はそれを「いつ」「どこで」「誰が」検証するかです。ここは発注者が細かく管理する領域ではありませんが、時間軸を把握しておかないと「もう手遅れ」という状況に気づけません。

実施タイミングと、発注者が関与すべき3つのポイント

負荷テストは、機能が一通り揃った結合テスト完了後から、リリース前の総合テスト工程で実施されるのが一般的です。負荷テストがシステム開発のテスト工程全体のどこに位置するのかは、システム開発のテスト種類で工程ごとの役割を確認しておくと整理しやすくなります。

ただし、アーキテクチャそのものに性能リスクがある場合（大量データを扱う新規設計、外部 API への依存が大きい構成など）は、設計段階でプロトタイプを作って早期に測る選択肢もあります。「作り終わってから測ったら性能が出ませんでした」となった場合、設計をやり直す時間もコストもないというのが最悪のパターンです。要件定義の段階で性能リスクの高い箇所をベンダーと洗い出し、早期検証が必要かを確認しておいてください。

発注者が関与すべきポイントは、次の3つに絞られます。

このうち、発注者にしかできないのが2番目のシナリオ妥当性確認です。ベンダーは「よく使われそうな操作」を推測してシナリオを組みますが、実業務で最も負荷が高い操作を知っているのは発注者側の業務部門です。「月末の一括締め処理が最も重い」「営業がスマートフォンから同時に日報を登録する時間帯がある」といった情報は、こちらから伝えなければシナリオに入りません。

リリース1ヶ月前に本記事を読んでいる場合、テスト計画のレビューには間に合わない可能性があります。その場合でも、提出済みの計画書を取り寄せてシナリオを確認し、抜けている操作があれば追加を依頼することはできます。結果報告会での確認は、どのタイミングからでも要求できます。

テスト環境が本番と違うときに結果をどう読むか

負荷テストで最も結果を歪めるのが、テスト環境と本番環境の差です。コスト上の理由から、本番と同一スペックの環境を用意できないプロジェクトは多くあります。この場合、測定結果をそのまま本番の性能とみなすことはできません。

確認すべき差分は次のとおりです。

• サーバースペック:CPU コア数・メモリ容量が何分の1か。データベースのスペック差は特に結果に影響します
• 台数・構成:本番が複数台構成でテスト環境が1台なら、負荷分散の挙動が検証できていません
• データ量:テスト環境のデータが数百件で、本番が数百万件なら、検索性能はまったく別物になります
• ネットワーク:外部 API への通信や、拠点からのアクセス経路が再現されているか

スペックが半分の環境で測った結果を「2倍すれば本番の性能」と単純換算することはできません。システムの性能はスペックに比例して伸びるとは限らず、データベースやネットワークがボトルネックになれば台数を増やしても改善しないためです。

環境差がある場合の現実的な進め方は、次の2段構えです。1つは、縮小環境で相対的な検証を行うこと。ボトルネックがどこにあるか、負荷を上げたときにどの指標から悪化するかは、縮小環境でも把握できます。もう1つは、本番環境が構築された後にリリース前の最終確認として本番相当の負荷をかけることです。この最終確認をスケジュールに組み込めるかどうかを、早い段階でベンダーに確認しておいてください。

実施体制の3パターンと主要ツール

負荷テストの実施体制は、大きく3つに分かれます。

負荷テストのツールとしては、Apache JMeter、k6、Gatling、Locust などが広く使われています。発注者がツールを選定する必要はありませんが、報告書でツール名と設定条件を確認する意味はあります。同じ「500 ユーザー」という表記でも、ツールの設定によって「500 個の仮想ユーザーが待ち時間なしでリクエストを連打する」場合と「500 人が人間らしい間隔で操作する」場合とでは、システムにかかる負荷がまったく異なるためです。報告書に「仮想ユーザー数」だけが書かれていて、思考時間（操作の間隔）やリクエストの発生頻度が書かれていない場合は、その条件を追加で確認してください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

負荷テスト報告書で発注者が確認すべき5つのポイント

ここからは、提出された負荷テスト報告書を検証するための具体的な観点です。専門的な内容の妥当性まで踏み込む必要はありません。以下の5点が満たされているかを確認するだけで、報告書が判断材料として使えるかどうかを見分けられます。

目標値と実測値が対比されているか

最初に確認するのは、目標値と実測値が対比表の形で示されているかです。実測値だけが列挙された報告書は、それ自体では合格・不合格を判定できません。「平均応答時間 1.8 秒」と書かれていても、目標が1秒なら未達、3秒なら達成です。

望ましいのは、次のような形式です。

対比表がない場合、ベンダーには「要件定義書に記載した性能要件と実測値を対比した表を追加してください」と依頼します。この依頼が難しいと言われる場合、そもそも目標値を定めずに測定していた可能性があります。その場合は、まず目標値の合意からやり直す必要があります。

測定条件は本番を代表しているか

次に、その数字がどういう条件で得られたのかを確認します。ここが検証の核心です。良い数字が出ていても、条件が本番とかけ離れていれば意味がありません。

確認すべき条件は次の5つです。

• 環境スペック:テスト環境のサーバー構成が本番と比べてどうか。差がある場合、その差をどう評価しているか
• データ量:データベースに何件のデータが入った状態で測ったか。運用開始から数年後を想定した件数か
• シナリオ構成:どの操作を、どの比率で実行したか。実業務での利用比率と一致しているか
• 同時ユーザー数と負荷のかけ方:何ユーザー相当か。徐々に上げたのか、一気にかけたのか。思考時間は設定されているか
• 測定時間:何分間・何時間測定したか。数分の測定では時間経過による劣化を検出できません

これらが報告書に書かれていない場合は、「測定条件の詳細（環境スペック・データ件数・シナリオ内訳・仮想ユーザー数と投入方法・測定時間）を明記してください」と依頼してください。条件が書かれていない報告書は、後から第三者が検証することができず、証拠としての価値を持ちません。

平均値だけで判断していないか（分布とパーセンタイル）

報告書に「平均応答時間 1.2 秒」とだけ書かれている場合、注意が必要です。平均値は、少数の極端に遅いリクエストを覆い隠してしまうからです。

たとえば 100 件のリクエストのうち、95 件が 0.5 秒、5 件が 15 秒だったとします。平均は約 1.2 秒となり、目標の2秒を余裕でクリアしているように見えます。しかし現実には、20 人に1人が15秒待たされているということです。この5件が、月末の締め処理をしている経理担当者に集中していたら、業務は止まります。

そこで見るべきなのがパーセンタイル値です。「95パーセンタイル値が2.0秒」とは、全リクエストのうち95% が2.0秒以内に完了したという意味です。残りの5% はそれより遅かったことになります。実務では、95パーセンタイルまたは99パーセンタイルを判定基準に使うのが一般的です。

あわせて最大値も確認してください。最大値が極端に大きい場合（たとえば目標2秒に対して最大60秒）、何らかの処理が特定条件で著しく遅くなっている可能性があります。その原因が特定され、説明されているかを確認します。

報告書に平均値しかない場合は、「95パーセンタイル値と最大値を追記してください」と依頼してください。測定ツールは通常これらの値を出力しているため、追加測定なしで対応できることがほとんどです。

エラー率・タイムアウトの扱いは妥当か

負荷をかけた状態では、一定数のエラーが発生することがあります。問題は、そのエラーがどう扱われているかです。

確認すべきは次の3点です。

1. エラー率が明記されているか:「エラーは発生しませんでした」という文章ではなく、「エラー率 0.02%（総リクエスト 50,000 件中 10 件）」のように数値で示されているか
2. エラーの内容が分類されているか:タイムアウト、サーバーエラー、接続拒否では原因も対処も異なります。内訳が示されているかを確認します
3. エラーが「想定内」として処理されていないか:報告書によっては、一定数のエラーを「テストツール側の問題」「ウォームアップ中のため除外」として集計から外していることがあります。除外にはそれなりの理由がある場合もありますが、除外した件数と理由が明記されているかは必ず確認してください

特に注意したいのが、応答時間の集計からエラーになったリクエストが除外されているケースです。遅すぎてタイムアウトしたリクエストを除外すると、残ったリクエストだけで計算した応答時間は当然良い数字になります。「エラーとして除外されたリクエストは何件で、それを含めた場合の応答時間はどうなるか」を確認してください。

ボトルネックの特定と限界値が示されているか

最後に、報告書が「測って終わり」になっていないかを確認します。発注者にとって価値があるのは、次の2つの情報です。

1つ目はボトルネックの特定です。目標を下回った項目について、原因がどこにあるのか（アプリケーションの処理、データベースのクエリ、ネットワーク、外部連携先など）が特定され、改善策と改善後の再測定結果が示されているかを確認します。未達のまま「改善は今後の課題」として報告が終わっている場合、それは検収の判断材料としては不十分です。改善方針と実施時期をベンダーと合意してください。

2つ目は限界値です。「想定負荷では問題ありませんでした」で終わらず、「同時 1,200 ユーザーを超えたあたりから応答時間が急激に悪化し、1,500 ユーザーでタイムアウトが発生し始める」といった限界点が示されているかを確認します。この数字が、運用後の監視のしきい値設定や、増強を検討すべきタイミングの判断に直結します。

限界値が示されていない場合は、「システムの限界点と、限界を超えたときの挙動を確認するテストを追加してください」と依頼します。実施済みのテスト設定を流用して負荷を上げるだけで済むケースも多く、追加コストは限定的な場合があります。

契約・検収で性能保証を担保する方法

ここまでの内容を実行しても、それが「お願いベース」にとどまっていると、いざというときに拠り所がありません。性能を合意事項として文書に残し、検収と契約で担保する方法を整理します。

なお、以下は契約実務の一般的な考え方の整理であり、個別の契約における取り扱いは契約書の記載内容によります。重要な判断が必要な場面では、法務担当者や弁護士など専門家への確認を推奨します。

要件定義書に性能要件を数値で残す

最も基本かつ効果が大きいのが、性能要件を数値で文書化することです。「サクサク動くこと」ではなく、先ほど整理した形式で記載します。

記載に含めるべき要素は次のとおりです。

• 対象の画面・処理:どの操作についての要件か
• 目標値と判定方法:「95パーセンタイル値が2.0秒以内」のように、値と統計の取り方をセットで書く
• 測定条件の前提:同時ユーザー数、データ件数、環境スペックの前提を明記する
• 前提が変わった場合の扱い:「想定同時ユーザー数が合意値を超えた場合は、別途協議する」といった条項を入れておくと、後の紛争を防げます

RFP（提案依頼書）の段階でこれらを提示できていれば、提案・見積の前提に性能要件が織り込まれます。要件定義フェーズで初めて性能要件を持ち出すと、「見積に入っていない」という議論になりがちです。

検収条件に性能テストの合格基準を組み込む

検収は、成果物が合意した要件を満たしているかを確認して受け入れる手続きです。ここに性能の観点が入っていないと、機能が動いていることだけを確認して受け入れることになります。

検収条件への組み込み方としては、次のような書き方が考えられます。

• 検収対象に「負荷テスト結果報告書」を含め、報告書の提出をもって検収作業を開始する
• 検収基準として「要件定義書に定める性能要件をすべて満たしていること」を明記する
• 未達項目がある場合の扱い（改修後の再測定を経て再検収とするか、条件付きで検収し期限を定めて改善するか）をあらかじめ定めておく

検収フェーズでの性能確認は、受け入れテスト（UAT）の運用と一体で進めると効率的です。業務部門が実業務のシナリオで動作を確認する場と、性能要件の充足を確認する場を同じ枠組みで管理できるためです。受け入れテストの進め方はUAT（受け入れテスト）で整理されています。

請負と準委任で性能責任の考え方はどう違うか

システム開発の契約形態には、主に請負契約と準委任契約があります。性能未達が発生した場合の考え方は、この2つで異なるとされています。

請負契約は、仕事の完成を目的とする契約です。合意した仕様を満たす成果物を完成させる義務を受託者が負うため、契約や要件定義書に性能要件が明記されていれば、その未達は契約不適合（引き渡された目的物が契約の内容に適合しないこと）として扱われうる、というのが一般的な理解です。

準委任契約は、業務の遂行そのものを目的とする契約です。成果物の完成義務ではなく、専門家として相当の注意をもって業務を行う義務（善管注意義務）を負う形になります。そのため性能未達についても、完成義務の不履行ではなく、善管注意義務違反や合意した業務範囲の不履行として論じられる傾向があります。

なお、契約不適合を理由に修補や損害賠償を求める場合、民法上は不適合を知った時から一定期間内に通知することが求められています（民法（e-Gov 法令検索））。この通知期間は当事者間の合意で変更しうる任意規定とされているため、契約書に別途の期間が定められている場合はそちらが優先されます。実務上重要なのは、リリース後に性能問題を検知したら、速やかに書面で通知しておくことです。「様子を見ていた」まま時間が経過すると、選択肢が狭まる可能性があります。

いずれの契約形態であっても、出発点は「性能要件が数値で合意され、文書に残っているか」です。要件が曖昧なまま「遅い気がする」と主張しても、判断の基準がないため議論が成立しません。契約形態の違いを気にする前に、要件の文書化を優先してください。

負荷テストの費用・期間の目安と、コストの掛けどころ

最後に費用の話です。追加で負荷テストを依頼したい、あるいは範囲を広げたいと考えたときに、いくらかかるのかが読めないことは意思決定の障害になります。

費用を左右する4つの変動要因

負荷テストの費用には明確な業界相場が存在せず、案件ごとに大きく変動します。変動要因は主に次の4つに整理できます（LASSIC「負荷テスト・性能テストの外注」）。

このうち発注者がコントロールしやすいのは、シナリオ数とレポートの深度です。環境構築費用も、既存の検証環境を流用できないかを確認する余地があります。

見積依頼前に発注者が整理しておく項目

見積の精度は、発注者が事前にどれだけ情報を整理しているかで大きく変わります。情報が曖昧なままだとベンダーはリスクを見込んだ高めの見積を出すか、前提を絞った安い見積を出して後から追加になるかのどちらかです。

見積依頼の前に、次の4点を整理しておいてください。

1. 想定ピーク:同時ユーザー数・1秒あたりのリクエスト数など、負荷の目標値
2. 対象シナリオ:測定したい操作の一覧と、それぞれの実行比率。業務部門と一緒に洗い出す
3. 合格基準:応答時間・スループット・エラー率・リソース使用率の目標値と判定方法
4. 環境の用意可否:テスト環境を自社で用意できるか、ベンダーに構築を依頼するか

この4点は、そのまま前述の性能要件の内容と重なります。性能要件を先に固めておけば、見積依頼の資料はほぼ揃うことになります。

負荷テストの投資対効果が高いケース・低いケース

すべてのシステムに本格的な負荷テストが必要なわけではありません。限られた予算を配分するために、投資対効果の高低を判断する軸を持っておいてください。

投資対効果が高いケース

• 停止・遅延が売上や業務の停止に直結するシステム（EC、予約、基幹業務）
• アクセスが急増する可能性が構造的にあるシステム（キャンペーン連動、メディア露出、季節変動が大きい業務）
• 利用者数が今後数倍に増える計画があるシステム
• 過去に性能起因の障害を起こしたことがある領域を含むシステム

投資対効果が低い、または簡易な確認で足りるケース

• 社内の限られた人数のみが使う参照系ツールで、負荷変動がほぼない
• 既存の実績あるパッケージ・SaaS をほぼそのまま利用しており、独自の重い処理を含まない
• 利用者数の上限が明確で、その規模なら性能上の懸念が構造的に生じない

予算が限られている場合の現実的な配分方針は、全画面を薄く測るのではなく、業務のクリティカルパスに絞って深く測ることです。1日に数回しか使わない管理画面の応答時間を厳密に測るより、全利用者が毎日何十回も通る検索画面と登録処理を、本番相当のデータ量で、限界点まで測るほうが得られる情報の価値が高くなります。

どの処理がクリティカルパスかを判断できるのは発注者だけです。ベンダーにシナリオの優先順位を丸投げせず、「この3つの処理だけは本番相当で限界まで測ってほしい」と指定してください。

まとめ｜発注者が性能保証を確認するためのチェックリスト

負荷テストとは、想定される負荷をかけた状態でシステムが性能要件を満たすか、そしてどこが限界かを検証するテストです。発注者にとって重要なのは、テストの実施方法を理解することではなく、性能要件を数値で決め、報告書の測定条件を検証し、検収と契約で担保するという3つの動きを自分で回せるようになることです。

最後に、フェーズごとのチェックリストとして整理します。手元の資料と照らし合わせてご活用ください。

要件定義フェーズ

• 画面・処理の種類ごとにレスポンスタイムの目標値を決めたか
• 目標値を「平均」ではなくパーセンタイル値で定義したか
• 業務量からスループット・同時接続数を算出し、その前提を文書に残したか
• リソース使用率の上限（余裕率）を決めたか
• IPA 非機能要求グレードなどの共通様式でベンダーと合意したか

テスト計画フェーズ

• 実施するテストの種類が、自社のリスク（スパイク・長時間稼働・データ増加）に対応しているか
• 測定シナリオに、実業務で最も負荷が高い操作が含まれているか（業務部門に確認したか）
• テスト環境と本番環境の差分を把握し、差がある場合の評価方法を合意したか
• 本番環境構築後の最終確認をスケジュールに組み込めるか確認したか

報告書受領フェーズ

• 目標値と実測値が対比表で示されているか
• 測定条件（環境スペック・データ件数・シナリオ内訳・仮想ユーザー数と投入方法・測定時間）が明記されているか
• 平均値だけでなく95パーセンタイル値・最大値が示されているか
• エラー率が数値で示され、除外したデータがある場合はその件数と理由が明記されているか
• ボトルネックの特定と改善後の再測定結果、および限界値が示されているか

検収フェーズ

• 検収対象に負荷テスト結果報告書が含まれているか
• 検収基準に「性能要件をすべて満たすこと」が明記されているか
• 未達項目がある場合の扱い（再測定・条件付き検収・改善期限）を合意したか
• リリース後に性能問題を検知した場合の連絡・対応フローを決めてあるか

このチェックリストのうち、半分以上に「はい」と答えられない状態でリリースを迎えようとしているなら、まだ間に合う項目から順に着手してください。特に「目標値と実測値の対比表」と「測定条件の明記」の2つは、追加の測定なしで報告書の追記だけで対応できることが多く、費用も時間もほとんどかかりません。この2つが揃うだけで、経営層への説明材料としての質は大きく変わります。

性能要件を含む非機能要件を、発注時の提案依頼書にどう書き込むかをお探しの方は、システム開発 提案依頼書（RFP）サンプル をご覧ください。要件の記載項目を一覧で確認できます。

性能要件の整理やベンダーから提出された報告書の妥当性について相談されたい場合は、お問い合わせフォーム からご連絡ください。要件を整理する段階からのご相談も承っています。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。