モダンWebアプリのパフォーマンステスト：実践ガイド
Yunhao Jiao
パフォーマンステストは、問題が発生するまでチームが最も一貫してスキップしがちなテスト分野です。パターンはよく知られています。アプリケーションは開発・テスト環境では正常に動作し、本番環境へリリースされた後、実際のトラフィックが到達したとき、または大量データを扱うユーザーが高コストな操作をトリガーしたときに障害が発生します。
本番環境でパフォーマンス問題を発見するコストは高くつきます。ユーザーへの影響、インシデント対応時間、プレッシャーの中での緊急修正が伴うためです。開発中という早い段階で発見するコストははるかに低くなります。このガイドでは、本番環境でその重要性を痛感する前に、パフォーマンステストをワークフローに組み込む方法を解説します。
パフォーマンステストとは？
パフォーマンステストとは、負荷がかかった状態でアプリケーションがどのように動作するかを評価する手法です。現実的なユースケースやピーク時の使用条件下での、レスポンスタイム、スループット、リソース使用率、安定性を測定します。
パフォーマンステストには、いくつかの具体的な活動が含まれます。
負荷テスト（Load testing）：想定される負荷のもとでアプリケーションはどのように動作するか？100人、500人、あるいは1000人のユーザーが同時にアクティブな状態でも、レスポンスタイムは許容範囲内に収まっているか？
ストレステスト（Stress testing）：アプリケーションが通常の処理能力を超えた状態に追い込まれたとき、どのように動作するか？どこで限界を迎え、その障害は適切にハンドリングされているか？
スパイクテスト（Spike testing）：突発的なトラフィックの急増に対して、アプリケーションはどのように対応するか？スパイクが終わった後、正常に回復できるか？
ソークテスト（Soak testing）：長期間にわたる持続的な負荷のもとで、アプリケーションは安定して動作し続けるか？時間が経過しないと現れないメモリリーク、コネクションプールの枯渇、その他の問題は存在しないか？
ベースラインテスト（Baseline testing）：パフォーマンスのベースラインを確立し、将来の変更をそれと比較できるようにする。これは、CI/CDインテグレーションにおいて最も価値のあるパフォーマンステストの形態です。
パフォーマンスのリグレッションが発見しにくい理由
機能テストは正確性を検証し、パフォーマンステストは速度と安定性を検証します。関数は完全に正確でありながら、壊滅的に遅い場合があります。機能テストスイートはパフォーマンスのリグレッションを検出できません。
機能テストをすり抜けてしまうパフォーマンスリグレッションの主な原因：
- AIが生成したORMコードによって引き込まれたN+1クエリのバグ。動作自体は正しいが、1回ではなく数百回のデータベースクエリが発行される
- すべての状態変化のたびに不必要な再レンダリングが発生するReactコンポーネント。動作は正しいが、UXの低下を招く
- 小規模なデータセット向けに最適化されており、スケールするにつれて指数関数的に遅くなるバックグラウンドジョブ
- 複数のサービスからデータを集約し、同時アクセス時にレイテンシが増大するAPIエンドポイント
- 頻繁にクエリされるテーブルに、インデックスなしのカラムを追加するデータベースマイグレーション
これらはいずれも機能テストの結果には現れません。しかし、すべてが実際のユーザーに大きな影響を与えます。
重要なWebパフォーマンス指標
Webアプリケーションにおいて、パフォーマンスは多次元的です。ユーザー体験との相関が高い主な指標は以下のとおりです：
Core Web Vitals（GoogleのUX指標）：
- LCP（Largest Contentful Paint）：メインコンテンツが表示されるまでの時間。目標値は2.5秒未満。
- INP（Interaction to Next Paint）：ユーザー操作に対するページの応答速度。目標値は200ms未満。
- CLS（Cumulative Layout Shift）：読み込み中にコンテンツが予期せずずれないか。目標値は0.1未満。
APIパフォーマンス：
- p50レスポンスタイム：APIレスポンスのレイテンシの中央値
- p95／p99レスポンスタイム：リクエストの最も遅い5%／1%のレイテンシ（ユーザーが体感する遅さが集中する領域）
- 負荷時のエラーレート：トラフィックが増加した際にエラーレートは上昇するか？
- スループット：パフォーマンスが低下する前に、システムが処理できる1秒あたりのリクエスト数
CI/CDへのパフォーマンステストの統合
パフォーマンスベースライン
CI/CDにおいてパフォーマンスリグレッションを検出する最も実用的な方法は、ベースライン比較です。現時点のアプリケーションのパフォーマンスを計測してベースラインとして保存し、PRによってパフォーマンスがベースラインから大きく乖離した場合にアラートを出します。
すべてのPRでフルロードテストを実施する必要はありません。重要なエンドポイントと主要なページ読み込みを対象とした、ピンポイントのパフォーマンスチェックで十分にリグレッションを検出できます。
パフォーマンステストのツール
k6 ― モダンで開発者に優しいロードテストツール。JavaScriptベースのテストスクリプト、CLIによる実行、優れたCI/CD統合を備えています。APIロードテストに最適です。
Playwrightパフォーマンス ― PlaywrightはE2Eテスト実行の一環として、Core Web Vitalsやページパフォーマンスの指標を取得できます。機能テストと並行してフロントエンドのパフォーマンスを追跡するのに有効です。
Lighthouse CI ― CI/CDでGoogle Lighthouseの監査を実行し、パフォーマンススコアが閾値を下回った場合にビルドを失敗させます。バックエンドの負荷よりも、フロントエンドのパフォーマンス（Core Web Vitals）に適しています。
TestSprite ― TestSpriteのE2Eテスト実行は、機能テストの副産物として明らかなパフォーマンス問題を検出します。目に見えるタイムアウトを引き起こすN+1クエリのバグ、リストエンドポイントの遅延を招くページネーションの欠落、同期的なブロッキング処理などは、いずれも機能テストレポートに現れるテスト失敗として検出されます。専用のロードテストツールではありませんが、標準的なカバレッジの一環として、AIが生成するコードに多い代表的なパフォーマンスバグを捉えます。
実践的なCI/CDパフォーマンス構成
多くのチームにとって、現実的な出発点は以下のとおりです：
- ベースラインの確立：ステージング環境でLighthouse CIとk6スクリプトを実行し、結果を保存します。
- PRごとのパフォーマンスチェックの実施：フロントエンドパフォーマンスはすべてのPRでLighthouse CIを実行。バックエンドコードに変更を加えるPRには、重要なAPIエンドポイントに対してk6を実行します。
- リグレッション時のアラート：レスポンスタイムが20%以上増加した場合、またはCore Web Vitalsのスコアが閾値を下回った場合は、PRゲートを失敗させます。
- 大型リリース前のフルロードテスト：すべてのPRではなく、重要なリリースやインフラ変更の前にフルロードテストを実施します。
AIが生成するコードのパフォーマンステスト
AIコーディングツールは特有のパフォーマンスリスクをもたらすため、AIネイティブなチームにとってパフォーマンステストはより重要になります：
ORMクエリパターン。AIコーディングエージェントは、動作は正しくても非効率なORMクエリを生成しがちです。N+1クエリ、Eagerローディングの欠落、インデックスなしのルックアップなどが典型例です。小規模なデータセットでは問題なく動作しますが、スケールすると著しく劣化します。
ReactでのデータTransformation。AIが生成するReactコンポーネントは、メモ化なしにレンダリングのたびに高コストな計算を実行することがあります。機能的には正しく、開発環境では視覚的に検出できませんが、実際のデータ量では顕著に遅くなります。
ページネーションの欠落。AIコーディングエージェントは、ページネーションではなく全レコードを返すリストエンドポイントを生成しがちです。小規模なデータセットでは正しい動作ですが、スケール時には致命的な問題となります。
非同期コンテキストにおける同期処理の混入。AIが生成したコードは、特にNode.jsバックエンドにおいて、非同期処理が意図されている箇所にブロッキング処理を導入してしまうことがあります。
CI/CDにおけるパフォーマンスベースラインを設定することで、こうしたリグレッションが蓄積する前に検出できます。TestSpriteのテスト実行は、機能テストの結果とともにタイミングデータを収集し、AIが生成したコードに起因するパフォーマンス問題を早期に検知するシグナルを提供します。
TestSpriteでパフォーマンスを意識したテストを始める →