application-performance-performance-optimization

専門のパフォーマンスおよび最適化エージェントを使用して、アプリケーションのパフォーマンスをエンドツーエンドで最適化します。

[Extended thinking: このワークフローは、アプリケーションスタック全体にわたる包括的なパフォーマンス最適化プロセスを編成します。詳細なプロファイリングとベースラインの確立から始めて、各システムレイヤーでの対象を絞った最適化へと進み、ロードテストを通じて改善を検証し、持続的なパフォーマンスのための継続的なモニタリングを確立します。各フェーズは前のフェーズからの洞察に基づいて構築され、理論上の改善ではなく実際のボトルネックに対処するデータ駆動型の最適化戦略を作成します。このワークフローは、モダンな可観測性の実践、ユーザー中心のパフォーマンス指標、およびコスト効率の高い最適化戦略を重視します。]

このスキルを使用する場合

• バックエンド、フロントエンド、インフラストラクチャにわたるパフォーマンス最適化を調整する場合
• ボトルネックを特定するためのベースラインとプロファイリングを確立する場合
• ロードテスト、パフォーマンスバジェット、またはキャパシティプランを設計する場合
• パフォーマンスと信頼性の目標に向けた可観測性を構築する場合

このスキルを使用しない場合

• タスクが、より広範なパフォーマンス目標を持たない小規模な局所的な修正である場合
• メトリクス、トレーシング、またはプロファイリングデータにアクセスできない場合
• リクエストがパフォーマンスやスケーラビリティに関連しない場合

手順

1. パフォーマンスの目標、制約、および対象となる指標を確認します。
2. プロファイリング、トレーシング、および実ユーザーデータを用いてベースラインを確立します。
3. 測定可能な影響を伴う段階的な最適化をスタック全体にわたって実行します。
4. 改善を検証し、リグレッションを防ぐためのガードレールを設定します。

安全性

• 承認と保護措置なしに本番環境でロードテストを実施することは避けてください。
• パフォーマンス変更はロールバック計画を用意して段階的に展開してください。

フェーズ 1: パフォーマンスのプロファイリングとベースライン

1. 包括的なパフォーマンスプロファイリング

• subagent_type="performance-engineer" を指定して Task ツールを使用します
• プロンプト: "$ARGUMENTS のアプリケーションパフォーマンスを包括的にプロファイリングしてください。CPU 使用率のフレームグラフを生成し、メモリ分析のためのヒープダンプを取得し、I/O 操作をトレースし、ホットパスを特定してください。利用可能であれば DataDog や New Relic などの APM ツールを使用してください。データベースクエリのプロファイリング、API レスポンスタイム、フロントエンドのレンダリング指標を含めてください。すべての重要なユーザージャーニーに対するパフォーマンスベースラインを確立してください。"
• コンテキスト: 初期のパフォーマンス調査
• 出力: フレームグラフ、メモリ分析、ボトルネックの特定、ベースライン指標を含む詳細なパフォーマンスプロファイル

2. 可観測性スタックの評価

• subagent_type="observability-engineer" を指定して Task ツールを使用します
• プロンプト: "$ARGUMENTS の現在の可観測性セットアップを評価してください。既存のモニタリング、OpenTelemetry による分散トレーシング、ログ集約、およびメトリクス収集をレビューしてください。可視性のギャップ、不足しているメトリクス、およびより良い計装が必要な領域を特定してください。APM ツールの統合と、ビジネスクリティカルな操作向けのカスタムメトリクスを推奨してください。"
• コンテキスト: ステップ 1 のパフォーマンスプロファイル
• 出力: 可観測性評価レポート、計装のギャップ、モニタリングの推奨事項

3. ユーザーエクスペリエンスの分析

• subagent_type="performance-engineer" を指定して Task ツールを使用します
• プロンプト: "$ARGUMENTS のユーザーエクスペリエンス指標を分析してください。Core Web Vitals (LCP、FID、CLS)、ページ読み込み時間、インタラクティブになるまでの時間、および知覚されるパフォーマンスを測定してください。利用可能であれば Real User Monitoring (RUM) データを使用してください。パフォーマンスが低いユーザージャーニーとそのビジネスへの影響を特定してください。"
• コンテキスト: ステップ 1 のパフォーマンスベースライン
• 出力: UX パフォーマンスレポート、Core Web Vitals 分析、ユーザーへの影響評価

フェーズ 2: データベースとバックエンドの最適化

4. データベースパフォーマンスの最適化

• subagent_type="database-cloud-optimization::database-optimizer" で Task ツールを使用します
• プロンプト: 「$ARGUMENTS のデータベースパフォーマンスを、プロファイリングデータ {context_from_phase_1} に基づいて最適化してください。スロークエリログを分析し、不足しているインデックスを作成し、実行計画を最適化し、Redis/Memcached によるクエリ結果のキャッシュを実装してください。コネクションプーリング、プリペアドステートメント、バッチ処理の機会を検討してください。必要に応じてリードレプリカとデータベースシャーディングを検討してください。」
• コンテキスト: フェーズ 1 からのパフォーマンスボトルネック
• 出力: 最適化されたクエリ、新しいインデックス、キャッシュ戦略、コネクションプール設定

5. バックエンドコードと API の最適化

• subagent_type="backend-development::backend-architect" で Task ツールを使用します
• プロンプト: 「$ARGUMENTS のバックエンドサービスを、ボトルネック {context_from_phase_1} を対象として最適化してください。効率的なアルゴリズムを実装し、アプリケーションレベルのキャッシュを追加し、N+1 クエリを最適化し、async/await パターンを効果的に使用してください。ページネーション、レスポンス圧縮、GraphQL クエリの最適化、バッチ API 操作を実装してください。レジリエンスのためにサーキットブレーカーとバルクヘッドを追加してください。」
• コンテキスト: ステップ 4 からのデータベース最適化、フェーズ 1 からのプロファイリングデータ
• 出力: 最適化されたバックエンドコード、キャッシュの実装、API の改善、レジリエンスパターン

6. マイクロサービスと分散システムの最適化

• subagent_type="performance-engineer" で Task ツールを使用します
• プロンプト: 「$ARGUMENTS の分散システムパフォーマンスを最適化してください。サービス間通信を分析し、サービスメッシュの最適化を実装し、メッセージキューのパフォーマンス (Kafka/RabbitMQ) を最適化し、ネットワークホップを削減してください。分散キャッシュ戦略を実装し、シリアライズ/デシリアライズを最適化してください。」
• コンテキスト: ステップ 5 からのバックエンド最適化
• 出力: サービス通信の改善、メッセージキューの最適化、分散キャッシュのセットアップ

フェーズ 3: フロントエンドと CDN の最適化

7. フロントエンドバンドルと読み込みの最適化

• subagent_type="frontend-developer" で Task ツールを使用します
• プロンプト: 「$ARGUMENTS のフロントエンドパフォーマンスを、Core Web Vitals {context_from_phase_1} を対象として最適化してください。コード分割、ツリーシェイキング、遅延読み込み、動的インポートを実装してください。webpack/rollup の分析によりバンドルサイズを最適化してください。リソースヒント (prefetch、preconnect、preload) を実装してください。クリティカルレンダリングパスを最適化し、レンダリングをブロックするリソースを排除してください。」
• コンテキスト: フェーズ 1 からの UX 分析、フェーズ 2 からのバックエンド最適化
• 出力: 最適化されたバンドル、遅延読み込みの実装、改善された Core Web Vitals

8. CDN とエッジの最適化

• subagent_type="cloud-infrastructure::cloud-architect" で Task ツールを使用します
• プロンプト: 「$ARGUMENTS の CDN とエッジのパフォーマンスを最適化してください。最適なキャッシュのために CloudFlare/CloudFront を設定し、動的コンテンツ向けのエッジ関数を実装し、レスポンシブ画像と WebP/AVIF 形式による画像最適化をセットアップしてください。HTTP/2 と HTTP/3 を設定し、Brotli 圧縮を実装してください。グローバルユーザー向けの地理的分散をセットアップしてください。」
• コンテキスト: ステップ 7 からのフロントエンド最適化
• 出力: CDN 設定、エッジキャッシュルール、圧縮のセットアップ、地理的最適化

9. モバイルとプログレッシブ Web アプリの最適化

• subagent_type="frontend-mobile-development::mobile-developer" で Task ツールを使用します
• プロンプト: 「$ARGUMENTS のモバイル体験を最適化してください。オフライン機能のためにサービスワーカーを実装し、適応型読み込みにより低速ネットワーク向けに最適化してください。モバイル CPU 向けに JavaScript の実行時間を削減してください。長いリストのために仮想スクロールを実装してください。タッチの応答性と滑らかなアニメーションを最適化してください。該当する場合は React Native/Flutter 固有の最適化を検討してください。」
• コンテキスト: ステップ 7～8 からのフロントエンド最適化
• 出力: モバイル向けに最適化されたコード、PWA の実装、オフライン機能

フェーズ 4: 負荷テストと検証

10. 包括的な負荷テスト

• subagent_type="performance-engineer" を指定して Task ツールを使用します
• プロンプト: "次の対象に対して、k6/Gatling/Artillery を使用して包括的な負荷テストを実施してください：$ARGUMENTS。本番環境のトラフィックパターンに基づき、現実的な負荷シナリオを設計してください。通常負荷、ピーク負荷、ストレスシナリオをテストしてください。該当する場合は、API テスト、ブラウザーベースのテスト、WebSocket テストを含めてください。さまざまな負荷レベルにおける応答時間、スループット、エラー率、リソース使用率を測定してください。"
• コンテキスト: フェーズ 1～3 のすべての最適化
• 出力: 負荷テスト結果、負荷時のパフォーマンス、限界点、スケーラビリティ分析

11. パフォーマンスのリグレッションテスト

• subagent_type="performance-testing-review::test-automator" を指定して Task ツールを使用します
• プロンプト: "次の対象に対する、自動化されたパフォーマンスのリグレッションテストを作成してください：$ARGUMENTS。主要なメトリクスのパフォーマンス予算を設定し、GitHub Actions などを使用して CI/CD パイプラインに統合してください。フロントエンド向けの Lighthouse CI テスト、Artillery による API パフォーマンステスト、データベースのパフォーマンスベンチマークを作成してください。パフォーマンスのリグレッションを検知した際の自動ロールバックトリガーを実装してください。"
• コンテキスト: ステップ 10 の負荷テスト結果、フェーズ 1 のベースラインメトリクス
• 出力: パフォーマンステストスイート、CI/CD 統合、リグレッション防止システム

フェーズ 5：モニタリングと継続的な最適化

12. 本番環境のモニタリング設定

• subagent_type="observability-engineer" を指定して Task ツールを使用します
• プロンプト: "次の対象に対する本番環境のパフォーマンスモニタリングを実装してください：$ARGUMENTS。DataDog/New Relic/Dynatrace を使用して APM を設定し、OpenTelemetry による分散トレーシングを構成し、カスタムのビジネスメトリクスを実装してください。主要なメトリクスを表示する Grafana ダッシュボードを作成し、パフォーマンス低下を検知する PagerDuty アラートを設定してください。重要なサービスの SLI/SLO とエラーバジェットを定義してください。"
• コンテキスト: これまでのすべてのフェーズでのパフォーマンス改善
• 出力: モニタリングダッシュボード、アラートルール、SLI/SLO の定義、ランブック

13. 継続的なパフォーマンス最適化

• subagent_type="performance-engineer" を指定して Task ツールを使用します
• プロンプト: "次の対象に対する継続的な最適化プロセスを確立してください：$ARGUMENTS。パフォーマンス予算の追跡を作成し、パフォーマンス変更に対する A/B テストを実装し、本番環境での継続的なプロファイリングを設定してください。最適化機会のバックログを文書化し、キャパシティプランニングモデルを作成して、定期的なパフォーマンスレビューサイクルを確立してください。"
• コンテキスト: ステップ 12 のモニタリング設定、これまでのすべての最適化作業
• 出力: パフォーマンス予算の追跡、最適化バックログ、キャパシティプランニング、レビュープロセス

設定オプション

• performance_focus: "latency" | "throughput" | "cost" | "balanced"（デフォルト: "balanced"）
• optimization_depth: "quick-wins" | "comprehensive" | "enterprise"（デフォルト: "comprehensive"）
• tools_available: ["datadog", "newrelic", "prometheus", "grafana", "k6", "gatling"]
• budget_constraints: インフラストラクチャの変更に許容される最大コストを設定します
• user_impact_tolerance: "zero-downtime" | "maintenance-window" | "gradual-rollout"

成功基準

• 応答時間: 重要なエンドポイントで P50 < 200ms、P95 < 1s、P99 < 2s
• Core Web Vitals: LCP < 2.5s、FID < 100ms、CLS < 0.1
• スループット: エラー率 <1% で現在のピーク負荷の 2 倍に対応
• データベースパフォーマンス: クエリの P95 < 100ms、1s を超えるクエリなし
• リソース使用率: 通常負荷時に CPU < 70%、メモリ < 80%
• コスト効率: ドルあたりのパフォーマンスを最低 30% 向上
• モニタリング対象範囲: 重要なパスの 100% に計測機能とアラートを設定

パフォーマンス最適化の対象: $ARGUMENTS