application-performance-performance-optimization

プロファイリング、可観測性、バックエンド/フロントエンド調整を用いたスペシャライズされたパフォーマンス最適化エージェントを使用して、エンドツーエンドのアプリケーションパフォーマンスを最適化します:

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

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

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

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

• タスクが広範なパフォーマンス目標を持たない小さなローカライズされた修正である
• メトリクス、トレース、またはプロファイリングデータにアクセスできない
• リクエストがパフォーマンスまたはスケーラビリティに関連していない

手順

1. パフォーマンス目標、制約、ターゲットメトリクスを確認します。
2. プロファイリング、トレース、実際のユーザーデータでベースラインを確立します。
3. 測定可能な影響でスタック全体にわたるフェーズ化された最適化を実行します。
4. 改善を検証し、リグレッションを防ぐためのガードレールを設定します。

安全性

• 承認とセーフガードなしで本番環境でロードテストを実行することは避けてください。
• ロールバック計画を含むパフォーマンス変更を段階的にロールアウトします。

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

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

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

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

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

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

• Task ツールを使用して subagent_type="performance-engineer"
• プロンプト: "ユーザーエクスペリエンスメトリクスを分析してください: $ARGUMENTS。Core Web Vitals (LCP、FID、CLS)、ページロード時間、インタラクティブまでの時間、認識されるパフォーマンスを測定してください。利用可能な場合は Real User Monitoring (RUM) データを使用してください。パフォーマンスが低いユーザージャーニーとその業務への影響を特定してください。"
• コンテキスト: ステップ 1 からのパフォーマンスベースライン
• 出力: UX パフォーマンスレポート、Core Web Vitals 分析、ユーザー影響評価

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

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

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

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

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

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

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

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

7. フロントエンドバンドル & ロード最適化

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

8. CDN & エッジ最適化

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

9. モバイル & プログレッシブウェブアプリ最適化

• Task ツールを使用して subagent_type="frontend-mobile-development::mobile-developer"
• プロンプト: "モバイルエクスペリエンスを最適化してください: $ARGUMENTS。オフライン機能のための Service Workers を実装し、適応的なロードでスロネットワークに最適化してください。モバイル CPU での JavaScript 実行時間を削減してください。長いリストの仮想スクロールを実装してください。タッチレスポンス性とスムーズなアニメーションを最適化してください。該当する場合は React Native/Flutter 固有の最適化を検討してください。"
• コンテキスト: ステップ 7-8 からのフロントエンド最適化
• 出力: モバイル最適化コード、PWA 実装、オフライン機能

フェーズ 4: ロードテスト & 検証

10. 包括的なロードテスト

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

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

• Task ツールを使用して subagent_type="performance-testing-review::test-automator"
• プロンプト: "自動パフォーマンスリグレッションテストを作成してください: $ARGUMENTS。主要メトリクスのパフォーマンスバジェットをセットアップし、GitHub Actions と同様の CI/CD パイプラインと統合してください。フロントエンド向けの Lighthouse CI テスト、Artillery を使用した API パフォーマンステスト、データベースパフォーマンスベンチマークを作成してください。パフォーマンスリグレッション向けの自動ロールバックトリガーを実装してください。"
• コンテキスト: ステップ 10 からのロードテスト結果、フェーズ 1 からのベースラインメトリクス
• 出力: パフォーマンステストスイート、CI/CD 統合、リグレッション防止システム

フェーズ 5: モニタリング & 継続的最適化

12. 本番環境モニタリングセットアップ

• Task ツールを使用して subagent_type="observability-engineer"
• プロンプト: "本番環境パフォーマンスモニタリングを実装してください: $ARGUMENTS。DataDog/New Relic/Dynatrace で APM をセットアップし、OpenTelemetry での分散トレースを設定し、カスタムビジネスメトリクスを実装してください。主要メトリクス用の Grafana ダッシュボードを作成し、パフォーマンス低下向けの PagerDuty アラートをセットアップしてください。エラーバジェット付きでクリティカルサービス用の SLI/SLO を定義してください。"
• コンテキスト: すべての前のフェーズからのパフォーマンス改善
• 出力: モニタリングダッシュボード、アラートルール、SLI/SLO 定義、ランブック

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

• Task ツールを使用して subagent_type="performance-engineer"
• プロンプト: "継続的な最適化プロセスを確立してください: $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
• スループット: 現在のピークロードの 2 倍をサポート、<1% エラー率で
• データベースパフォーマンス: クエリ P95 < 100ms、1s を超えるクエリなし
• リソース利用率: 通常のロード下で CPU < 70%、Memory < 80%
• コスト効率: ドルあたりのパフォーマンスが最小 30% 改善
• モニタリングカバレッジ: 重要なパスの 100% がアラート付きで計測される

パフォーマンス最適化ターゲット: $ARGUMENTS

制限事項

• このスキルは、上記で説明されたスコープに明確に一致するタスクの場合のみ使用してください。
• 出力を環境固有の検証、テスト、または専門家のレビューの代替として扱わないでください。
• 必要な入力、権限、安全性の境界、または成功基準が欠落している場合は停止して、明確化を求めてください。