LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

リリース前の負荷テストを外部エンジニアに頼みたいが、何をこちらで決め、何を任せてよいのかがはっきりしない——。開発の現場では、こうした迷いがよく聞かれます。負荷テストのテスト体制とは、負荷テストを誰が計画し、誰が環境とデータを用意し、誰が結果を評価するのかを、発注側と外部エンジニアの間で決めておくことを指します。

体制を先に決めておけば、テストの直前に環境や役割で揉めることを避けやすくなります。ただし、決めただけで性能が保証されるわけではありません。本記事では、開発の現場を預かるマネージャーに向けて、発注側が持つ役割、負荷の決め方、環境の取り決め、計画書に書く項目、結果の受け取り方を整理します。

負荷テストとは

手がかりにするのは、デジタル庁の「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」（2026年6月12日）です。国の機関の職員に向けて、事業者に開発を委託するときの実務を説明した参考文書です。民間企業が守る決まりではありませんが、発注する側がテストにどう関わるかを具体的に書いているので、外部エンジニアに負荷テストを頼むときにも参考になります。

このガイドブックでは、負荷テストは主に総合テスト（システム全体が設計どおりに動くかを確かめる段階）で行う非機能のテストとして扱われています。利用者数、データ量、リクエスト数、レスポンスといった性能の要件を、「現在の想定だけではなく、今後の予想される増加量も含めて、確認する」という位置づけです。^*1

呼び名が似たテストがいくつかあるので、ガイドブックの注記で分けておきます。パフォーマンステストは、負荷のかかっていない通常の状態でレスポンスタイムやスループットを測るテストです。ラッシュテストは、性能の要件として想定している上限の負荷（同時アクセス数など）に対して処理能力を確かめます。ストレステストは、その上限を超える負荷がかかった想定外の状況での振る舞いを確かめます。大容量テストは、想定している上限の量のデータを送受信して、バッチ処理の所要時間やネットワークの性能が足りるかを確かめます。^*1

ガイドブックは、ラッシュテスト、ストレステスト、大容量テストをまとめて負荷テストの例として挙げています。外部エンジニアに頼むときは「負荷テストをお願いします」で済ませず、このうちどれを行うのかを最初にすり合わせておくと、見積もりも計画もぶれにくくなります。

誰が何を決めるのか

ガイドブックは、テスト工程で発注者側が持つ役割を「テスト計画を確認し、テスト実施状況を管理し、テスト結果を評価する」ことだとし、総合テスト以降の終盤ほど関与が重要になるとしています。^*1 設計は一緒に作るものと考えていても、テストには発注者が関わらないと思い込んでいる人もいる、という指摘です。

工程ごとに見ると、単体テストと結合テストでは、事業者が実施の主体でも、発注者は計画を確かめて実施状況の報告を求めます。総合テストでは、これに加えてテストシナリオや評価方法が妥当かを確かめ、過不足を指摘します。負荷テストはこの総合テストに含まれるので、シナリオと評価方法の妥当性を見るのは発注側の仕事だと考えておきます。

外部エンジニアとの間に置き換えると、確かめたい性能の要件と利用者数やデータ量の見込みは発注側が示し、テスト計画書の案、シナリオ、ツールの設定と実行は外部エンジニアが担います。計画書の確認と、結果が要件を満たしたかの評価は発注側が行います。何をもって合格とするかまで任せきりにしないことが、テスト体制の要になります。

かける負荷の決め方

負荷テストでは、たいていツールで大量のアクセスと同じ状態を作り出します。ここでガイドブックは「かける負荷は、ただ大きければよいというものではありません」と注意しています。^*1 現実に起こりうる場面に近い形になるよう、負荷のかけ方を前もって計算するという考え方です。

例として挙げられているのは、小さなデータが多数集中すると見込まれるのに、大きなデータを上限の数だけかけるのは現実的ではない、というものです。一方で、ストレステストは前提を超えたときの振る舞いを見るのが目的なので、現実の場面に沿わせる必要はないとしています。テストの種類によって、負荷の決め方そのものが変わるわけです。

この計算の材料になるのは、業務を知っている発注側の情報です。アクセスが集中する時間帯、締め日に増える処理、1件あたりのデータの大きさは、外部エンジニアには分かりません。現行のシステムがあるなら、アクセスの記録や処理件数を渡せるかを社内で確かめておきます。

データ量の増え方も見落とせません。ガイドブックには、運用を続けるうちにテーブルが大きくなり、それを読む処理のレスポンスが悪くなり続けた事例が紹介されており、テストの条件に今後のデータ量の増加を見込むよう勧めています。リリース直後の量だけで組まないよう、何年後の量で試すのかを発注側が決めておきます。

テスト環境の取り決め

負荷テストは、どの環境で行うかで結果の意味が大きく変わります。ガイドブックは、本番の業務で使っているネットワーク越しに負荷テストをすると、ほかの本番業務に大きな影響が出てしまうと注意しています。そのうえで「本番環境に近い環境で試験しないと意味がありません」とし、夜間など影響の少ない時間帯に行う、本番環境とほぼ同じテスト環境を用意するといった工夫を挙げています。^*1

こうした調整は、外部エンジニアだけでは進められません。本番に近い環境の費用、夜間に作業する日の確保、ネットワークを管理する部署への連絡は、発注側の社内で決めることだからです。ガイドブックも、環境の準備には入念な調整が要り、時間がかかるとしています。

総合テストの時期には、いろいろなテストが並行して動くので、ガイドブックは環境の取り決めをしっかり行うよう求めています。負荷テストの最中に同じ環境で機能のテストが動いていると、どちらの結果も信用できなくなります。いつ、どの環境を、どのテストが使うのかを表にして、外部エンジニアと社内の担当者に共有しておきます。

ほかのシステムとつながっている場合は、相手側の都合も絡みます。ガイドブックは連携テストについて、テスト種類（異常系テスト、負荷テスト等を含めた実施範囲）を前もって調整しておかないと、テストの時期に問題になる例があるとしています。^*1 外部のサービスに負荷をかけてよいかは、相手の窓口に早めに確かめます。

結合テストで先に見ておく点

負荷テストを総合テストの最後にまとめて行えばよい、と考えるのは早計です。ガイドブックは、総合テストで初めて非機能要件を確かめるわけではなく、単体テストや結合テストで部品ごとに確かめたうえで、総合テストで全体として確かめる順序だとしています。結合テストで怠ると、総合テストで大きな手戻りが起きかねないとも書かれています。

結合テストで先に確かめる観点の例として、ガイドブックの表は、性能では「SQL 単体での性能を検証する」ことなどを、拡張性では短い時間で重い負荷をかけてシステムの限界に関わる要件を確かめることを挙げています。^*1

外部エンジニアに頼むときも、負荷テストだけを総合テストの時期に切り出すより、結合テストの段階から性能を見てもらうほうが手戻りは小さくなります。遅いSQLを先に見つけておけば、総合テストの負荷テストは全体の確認に集中できます。開発とテストの担当が別なら、結合テストで測った結果を誰が誰に渡すのかも決めておきます。

テスト計画書に書く項目

ここまでに決めたことは、テスト計画書にまとめます。ガイドブックはテスト工程ごとのテスト計画書の目次の例を示しており、テストの実施方針として、テストの観点、テスト実施体制と役割分担、テスト実施手順、テスト環境、工程の開始条件と終了条件、使うテスト自動化ツール、成果物の一覧を挙げています。管理方針としては、進捗管理、品質管理、不具合管理が並んでいます。^*1

負荷テストに当てはめると、テスト実施体制と役割分担には発注側と外部エンジニアの分け方を、テスト環境にはどの環境をいつ使うかと本番との違いを書きます。終了条件に、どの性能の要件を満たしたら終えるのかを書いておくと、終わりの見えないテストになりにくくなります。

さらにガイドブックは、各テストの前にテストシナリオ、テスト項目、使用するテストデータ、合否判定基準等をテスト実施要領にまとめるとしています。^*1 負荷テストなら、どのシナリオを何件の同時アクセスで何分続けるのか、どのデータを使うのか、レスポンスが何秒以内なら合格かを、この段階で書面にしておきます。

結果の受け取り方

結果の受け取りやすさは、確認の方法をどこまで具体的に書いたかで決まります。ガイドブックは、テストケースに「テスト結果が正しいことを確認する」のような曖昧な書き方をすると、実施する人によって結果がばらつくとしています。^*1 負荷テストでも「問題なく動くこと」ではなく、レスポンスタイムやエラーの件数を、合否判定基準の数値と並べて見られる形で報告してもらいます。

どこまで証跡を残してもらうかも、計画の段階で決めます。ガイドブックは、取得するエビデンスの対象と確認方法、承認方法、納品物を計画の段階で合意しておくよう求め、すべてを求めると不要なものまで集めてコストがかさむと注意しています。負荷テストなら、ツールの集計結果とそのときのサーバーの使用状況が残っていれば足りることが多いでしょう。何を納品物とするかは契約の範囲にも関わるので、契約の内容とあわせて確かめます。

結果が一度で合格になるとは限りません。ガイドブックは、これらのテストは1回で終わると想定しないほうがよいとし、性能が足りなければチューニングしてから同じテストをやり直すとしています。^*1 条件が変わると前回と比べられなくなるので、同じシナリオと同じデータで測ることを最初に決めておきます。準備不足や操作の誤りでやり直しが続くなら、いったん止めて進め方を見直す判断も要ります。

外部に委託するときに確認しておきたい点

外部エンジニアに負荷テストを頼む前に、確かめたい性能の要件、利用者数とデータ量の見込み、使える環境と時間帯の3つを社内で書き出しておきます。この3つがあれば、要る負荷テストの種類と準備期間を相談の最初から話せます。結果を要件と照らして説明できるかも、相手を選ぶ目安になります。

テスト体制全体の組み方は外部エンジニアのテスト体制、IPAが定める4つの区分で扱っています。

結合テストの段階での役割分担は外部エンジニアと進める結合テスト、テスト体制に書く4つの役割にまとめました。

性能の要件を数字で示す方法は性能改善とは｜外部エンジニアに示すIPAの定義で整理しています。

まとめ：負荷テストの体制で確かめておきたい3つの点

確かめておきたい点は3つです。第一に、計画の確認と結果の評価は発注側が持つこと。第二に、負荷は利用者数やデータ量と今後の増加をもとに現実に近い形で計算すること。第三に、本番に近い環境の調整とチューニング後のやり直しまで含めて期間を確保し、合否判定基準とエビデンスの範囲を計画の段階で合意することです。負荷テストを任せられる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（DS-120）」2026年6月12日（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/0af5ce68/20260715_resources_standard_guidelines_guideline_05.pdf）。出典：第3編第7章 Step.3-3「テストの計画を立てる」のA（図7-12・表7-11 発注者の関与の仕方）、C（表7-13 非機能要件テストの実施観点）、E（テストにおける役割分担と環境）、G（表7-15 テスト計画書の目次と記載内容・テスト実施要領）、H（テスト結果の確認方法）、I（テストエビデンスの合意）と、Step.4-4「総合テストの品質を評価する」A（表7-17 総合テストの観点とテスト例・注記の定義、負荷テストには十分な時間を確保する、データのバリエーション）、第3編第3章 表3-2（連携テストの事前調整）を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：デジタル庁「デジタル社会推進標準ガイドライン」（公開ページ）（https://www.digital.go.jp/resources/standard_guidelines）。実践ガイドブックが標準ガイドラインの参考文書として公開されていることの確認として（確認日2026年10月2日）（2026年10月確認）

Tweet