負荷試験をやったことがない 4 年目エンジニアが k6 を使って実施するまで（Zenn） という記事が話題になりました。「本番リリースの準備として、ほぼ未経験のまま k6 の選定・試験設計・実行・評価までを担当した」という体験談で、負荷試験はもはや一部の専門家だけのものではなく、現代的なツールがあれば現場のエンジニアが回せることを示しています。
一方で受託開発の現場では、「想定アクセスに耐えられるか検証しないまま本番公開し、キャンペーン初日に落ちる」という事故が後を絶ちません。受託でシステム開発を支える立場では、これは 「テストをやるかどうか」ではなく、「どの目標値を、どのシナリオで、どこまで保証して引き渡すか」を契約に組み込む課題だと捉えています。これまで Playwright AI QA 自動化受託（GH Media） で扱った 機能品質の自動検証、Pinterest CPU ゾンビに学ぶ性能監査受託（GH Media） で扱った 本番性能の落とし穴、P99 レイテンシ改善の SRE チューニング受託（GH Media） で扱った テール遅延対策と接続して、本記事では 「負荷試験・性能保証」を 受託パッケージとして整理します。
なぜ「いま」k6 で負荷試験なのか
| 観点 | 性能未検証（従来） | k6 で性能保証（2026） |
|---|---|---|
| 試験記述 | 専用ツール・GUI 依存 | JavaScript で記述 |
| CI 連携 | 手動実行 | パイプラインに組込 |
| 目標値 | 曖昧 | SLO で明文化 |
| 再現性 | 属人的 | コードで再現 |
| リリース判定 | 勘 | 閾値で自動合否 |
| 引き渡し | テスト資産なし | シナリオ + Runbook |
つまり k6 のように コードで書ける負荷試験ツールが普及したことで、受託でも 「性能を計測し、目標を定め、合否で判定する」プロセスを標準で組み込めるようになりました。これにより 「落ちないこと」を成果物の一部として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「勘でリリース」から「SLO で合否判定」へ
「たぶん大丈夫」での公開は事故の元です。受託では 目標応答時間・エラー率・同時接続数を SLO として定義し、k6 の閾値（thresholds）で自動合否を出すことで、リリース判定を客観化します。
構造 2: 「一度きりの試験」から「CI に常駐」へ
リリース時だけの試験では、改修による劣化を見逃します。受託では 負荷試験を CI/CD に組み込み、性能リグレッションを早期検知する仕組みを提供します。
構造 3: 「ボトルネック放置」から「原因特定 → 改善」へ
数値が悪いだけでは直りません。受託では Pinterest CPU ゾンビに学ぶ性能監査受託（GH Media） の知見を活かし、APM / プロファイラと併用してボトルネックを特定し、改善までを一貫して提供します。
受託で提供する「負荷試験・性能保証」5 フェーズ
フェーズ 1: 目標・前提設計（1 週間）
- 想定ピーク（キャンペーン / 月初 / 同時接続）の整理
- SLO 定義（p95 応答 / エラー率 / スループット）
- 試験対象シナリオ（ログイン / 購入 / 検索）の選定
- 試験環境の準備方針（本番相当 / 縮小）
フェーズ 2: シナリオ実装（1〜2 週間）
- k6 でユーザーシナリオを JavaScript 実装
- データ準備（テストユーザー / 商品）
- 負荷モデル（ランプアップ / スパイク / 持続）設計
- 閾値（thresholds）による合否定義
フェーズ 3: 試験実行・分析（1〜2 週間）
- 段階負荷の実行（ベースライン → ピーク → 限界）
- APM / メトリクスでボトルネック特定
- DB / 接続プール / N+1 / GC の確認
- 限界値とスケール特性の把握
フェーズ 4: 改善・再試験（2〜3 週間）
- ボトルネック改善（クエリ / キャッシュ / 設定）
- 再試験で SLO 達成を確認
- リリース判定レポート作成
フェーズ 5: 継続運用（継続）
- CI への負荷試験組み込み
- 性能リグレッション監視
- 定期的なピーク前試験
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 負荷生成 | k6 | Gatling / Locust / JMeter |
| 試験記述 | JavaScript シナリオ | TypeScript |
| CI 連携 | GitHub Actions | GitLab CI |
| 可視化 | Grafana + k6 出力 | Datadog |
| APM | OpenTelemetry | New Relic / Datadog |
| 環境 | 本番相当ステージング | コンテナで再現 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| キャンペーン・予約・申込で瞬間集中 | 社内のごく少人数利用 |
| EC・予約・チケットなど機会損失が大きい | アクセスが極めて少ない |
| 初リリースで実績がない | 既に十分な実績データがある |
| SLA / 性能を契約で約束する | ベストエフォートで合意済み |
| 改修頻度が高くリグレッションが怖い | ほぼ更新しない静的サイト |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 性能目標 | SLO（応答 / エラー率 / 同時数） | 想定ピークの合意 |
| 試験範囲 | 対象シナリオ / 環境 | 本番試験の可否 |
| 合否基準 | 閾値と判定方法 | 未達時の扱い |
| 改善範囲 | チューニングの対象 | 追加開発の切り分け |
| 引き渡し | シナリオ / レポート / Runbook | 自社継続性 |
| 継続試験 | CI 組み込み / 定期試験 | 運用費用 |
価格モデル — 負荷試験・性能保証パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| スポット試験 | 40 万円〜 | 1 システム | シナリオ + 試験 + レポート |
| 試験 + 改善 | 120 万円〜 | ボトルネック改善込み | 再試験で SLO 達成 |
| Lite 保守 | 8 万円〜 / 月 | 小規模 | 定期試験 + 監視 |
| Standard 保守 | 20 万円〜 / 月 | 中規模 + CI 組込 | + リグレッション検知 |
| Enterprise | 50 万円〜 / 月 | 基幹 + 大規模 | + SLA + 専任 |
顧客側 ROI 試算（EC サイト / キャンペーン初日想定）
| 項目 | 既存（未検証公開） | 負荷試験・性能保証 | 差分 |
|---|---|---|---|
| 初日ダウン確率 | 高い | 大幅低減 | 機会損失回避 |
| 想定機会損失 | 数百万円規模 | 予防により回避 | リスク低減 |
| 障害対応工数 | 緊急対応で逼迫 | 事前に解消 | 残業・信頼毀損回避 |
| スケール判断 | 過剰 or 不足 | 実測に基づく | インフラ費最適化 |
| 年間効果 | — | — | 重大ダウン回避 + インフラ過剰投資の抑制 |
試験 + 改善（120 万円〜）でも、初日ダウン 1 回の機会損失回避で十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 本番と異なる環境で試験する
縮小環境の結果は当てになりません。本番相当の構成で計測します。
落とし穴 2: 平均値だけ見る
p95 / p99 のテール遅延が体験を決めます。パーセンタイルで評価します。
落とし穴 3: 負荷をかける側がボトルネックになる
試験機の性能不足で頭打ちになります。分散実行や十分な負荷源を確保します。
落とし穴 4: 数値を出して終わりにする
原因特定がなければ改善できません。APM と併用してボトルネックを特定します。
落とし穴 5: 一度きりで継続しない
改修で性能は劣化します。CI に組み込み継続的に検知します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | SLO 定義 + 試験シナリオ選定 |
| Week 2〜3 | k6 シナリオ実装 + データ準備 |
| Week 4〜5 | 段階負荷試験 + ボトルネック特定 |
| Week 6〜9 | 改善 + 再試験で SLO 達成 |
| Week 10〜13 | CI 組み込み + 定期試験運用開始 |
まとめ — 「勘でリリース」から「性能を保証して引き渡す」へ
k6 のようなコードで書ける負荷試験ツールの普及で、性能検証は現場のエンジニアが回せるものになりました。受託でシステム開発を支える立場では、SLO で目標を定め、シナリオで再現し、閾値で合否を出し、CI で継続検知する 「負荷試験・性能保証」が、リリースの安心を成果物として届ける新しい主力サービスです。
弊社ではスポット試験 / 試験 + 改善 / Lite / Standard / Enterprise の各段階で本パッケージを提供しています。「キャンペーン初日に落ちたくない」「性能を契約で約束したい」「改修のたびに劣化していないか不安」というご相談は お問い合わせフォーム からお気軽にどうぞ。
