AIパフォーマンス＆負荷テスト

🔄 前回のおさらい: レッスン4では、自己修復テストがQA時間の60〜70%を消費するテスト保守の負担を解消する方法を学びました。自己修復は機能面——機能が正しく動くこと——をカバー。しかし正しく動く機能も、遅すぎればユーザーを失う。そこでパフォーマンステストの出番。

「負荷に耐えられるか？」の先へ

従来の負荷テストは1つの質問しかしない：「システムはXユーザーに耐えられるか？」JMeterのようなツールを起動し、目標ユーザー数まで増やして、生き残るか見る。

AI搭載パフォーマンステストはより良い質問をする：

• 「実際のトラフィックはどんな形で、現実的なパターンをテストしているか？」
• 「どのコード変更がパフォーマンスを劣化させ、どの程度か？」
• 「トラフィックが倍増したとき、最初にどこが壊れるか？」
• 「このAPIのレイテンシと呼び出し先の下流サービスの関係は？」

「落ちなかった」と「現実的な条件下で良好に動作する」の間のギャップ、それがAIが埋める差。

AI生成負荷パターン

従来の負荷テストの問題

典型的な負荷テストはこう見える：

0-5分:    0から10,000ユーザーにランプアップ
5-30分:   10,000ユーザーで保持
30-35分:  0にランプダウン

これは1万のフラットな同時ユーザーに耐えるかを教えてくれる。しかし以下は教えてくれない：

• 5,000ユーザーが同時にチェックアウトエンドポイントに殺到したらどうなるか（フラッシュセールシナリオ）
• 3分間で2,000から15,000に急増したらシステムはどう反応するか（SNSバイラルリンク）
• トラフィックバーストが終わった後、コネクションプールは回復するか
• 異なるユーザージャーニー（閲覧 vs 購入）がバックエンドサービスにどう影響するか

AIが現実的トラフィックを生成する仕組み

AI負荷テストツールは実際の本番トラフィックを分析し、現実を反映したテストパターンを生成：

入力： 30日分の本番アクセスログ、APIメトリクス、ユーザーセッションデータ。

AIの分析で判明すること：

• ピーク時間帯とトラフィック増加パターン
• エンドポイントヒット比率（どのAPIが最も呼ばれるか）
• ユーザージャーニーのシーケンス（閲覧→検索→商品→カート→チェックアウト）
• セッション持続時間の分布
• 地理的トラフィック分布とレイテンシプロファイル
• モバイル vs デスクトップの行動差

出力： ボリュームだけでなく、現実的な行動を生成する負荷テストスクリプト。

✅ 確認クイズ: AI生成負荷テストが従来のフラットテストより多くのボトルネックを発見する理由は？（実トラフィックは均一ではない——バーストパターン、混在するユーザー行動、異なるエンドポイント比率があり、特定のシステムポイントで競合を生む。フラットテストでは1万ユーザーに耐えるように見えても、リアルなテストでは400の同時チェックアウトリクエストが決済ゲートウェイのコネクションプールを枯渇させるボトルネックが見つかる。）

パフォーマンスリグレッション検出

ユーザーが気づく前に速度低下をキャッチ

最も厄介なパフォーマンス問題は、壊滅的な障害からは来ない。段階的な劣化から来る——20ms遅くなるクエリ、15ms追加するミドルウェア、10msブロックするログ変更。個々は「許容範囲内」。合わさると、キビキビした200msレスポンスがもっさりした600msに化ける。

AIパフォーマンス監視は閾値ではなくベースラインとトレンドを追跡：

従来の監視がキャッチするもの：

• レスポンスタイムが500ms SLAを超過 → アラート

AIの監視がキャッチするもの：

• レスポンスタイムが先週のベースラインから35%上昇 → アラート
• P95レイテンシトレンド：過去5デプロイで毎回+12ms → アラート
• エンドポイントXがコミットabc123以降80ms劣化 → 根本原因付きアラート

リグレッション検出のセットアップ

典型的なセットアップはCI/CDパイプラインに統合：

コードマージ → ステージングにデプロイ → パフォーマンススイート実行
                                            ↓
                                  AIがベースラインと比較
                                            ↓
                                  リグレッション検出？
                                  ├── No → 本番にデプロイ
                                  └── Yes → デプロイをブロック、チームに通知

AIがデプロイごとに追跡する主要メトリクス：

• P50、P95、P99レスポンスタイム（中央値はテールレイテンシを隠す——P95/P99が暴く）
• スループット（目標負荷でのリクエスト/秒）
• 負荷下のエラーレート
• リソース使用率（CPU、メモリ、DB接続数）
• GCポーズ（JVMベースシステムの場合）

✅ 確認クイズ: ユーザー体験にとって平均レスポンスタイムよりP95レイテンシの追跡が重要な理由は？（5%のユーザーが毎リクエストでP95以上のレイテンシを経験する。平均150msでもP95が2秒なら、20回に1回のページ読み込みが2秒——それらのユーザーは最もエンゲージメントの高い顧客（複雑なクエリ、満杯のカート、大量のAPI使用）に偏る。平均はこれらの問題を隠し、P95が暴く。）

予測的ボトルネック分析

AIは現在のパフォーマンスを測定するだけでなく、負荷増加時の障害発生ポイントを予測できる。

予測分析の仕組み：

1. AIが目標容量の50%、75%、100%で負荷テストを実行
2. 各エンドポイントの負荷とレスポンスタイムの関係を分析
3. レスポンスタイムが非線形にスケールするエンドポイントを特定（最初に壊れるもの）
4. 予測：「現在のトラフィック2倍時、決済APIは3つの逐次的DBコールが線形にスケールしないため、レスポンスタイムが1秒を超える」

これはキャパシティプランニングに価値がある。ブラックフライデーに何台サーバーが必要か推測する代わりに、どのコンポーネントをどれだけスケーリングすべきかをデータ駆動の予測で示せる。

実践的ツール

パフォーマンステストパイプラインの構築

1つのツールを選ぶ必要はない。レイヤーで組む：

レイヤー1: 毎PR — 軽量パフォーマンスチェック。重要エンドポイントのベンチマークをベースラインと比較。大きなリグレッションでマージをブロック。（k6等、2分実行）

レイヤー2: 毎デプロイ — 完全なリグレッションスイート。ステージングに対しリアルな負荷パターンを実行。全メトリクスをベースラインと比較。トレンド劣化でアラート。（10〜15分実行）

レイヤー3: 毎週 — 包括的負荷テスト。現在のピーク1.5倍でフルリアルトラフィックシミュレーション。スケーリング限界と劣化曲線を特定。キャパシティプランニングレポートを生成。（30〜60分実行）

レイヤー4: ローンチ前 — イベント固有の負荷シミュレーション。ローンチ、セール、マーケティングキャンペーンの予想トラフィックパターンをモデル化。フェイルオーバーとリカバリのシナリオをテスト。（カスタム時間）

まとめ

• 従来のフラット負荷テストは実トラフィックパターンが暴くボトルネックを見逃す——バーストパターン、エンドポイント比率、混合ユーザー行動が重要
• AIは本番トラフィックログを分析し、実ユーザーと同じ方法でシステムにストレスを与える負荷テストを生成
• CI/CDのパフォーマンスリグレッション検出が、SLAベースの監視が見逃す段階的劣化（千の小さな劣化による死）をキャッチ
• 平均ではなくP95/P99レイテンシを追跡——テールレイテンシが最もエンゲージメントの高いユーザーの体験
• 予測的ボトルネック分析がトラフィック到達前に障害ポイントを予測——プロアクティブなスケーリングが可能に

次のレッスン

次は「AIセキュリティテストと脆弱性検出」——脆弱性スキャンから自律的ペネトレーションテストまで、攻撃者より先にエクスプロイトを発見する方法を学びます。