application-performance-performance-optimization

専門的なパフォーマンス最適化エージェントを活用し、アプリケーション全体のパフォーマンスを最適化します。

[Extended thinking: このワークフローでは、アプリケーションスタック全体を対象とする包括的なパフォーマンス最適化プロセスを進行します。詳細なプロファイリングとベースラインの確立から始まり、システム各層の的を絞った最適化を経て、負荷テストで改善を検証し、継続的なパフォーマンスを維持するための監視体制を構築します。各フェーズでは、前のフェーズで得た知見を活用し、理論上の改善ではなく実際のボトルネックに対処する、データに基づく最適化戦略を策定します。このワークフローでは、最新のオブザーバビリティの実践、ユーザー中心のパフォーマンス指標、費用対効果の高い最適化戦略を重視します。]

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

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

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

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

ここに記載されている Task ツールとエージェントの種類は、オーケストレーションの例です。クライアントで利用可能か確認するか、該当する分析を直接実行してください。実際の出力がない場合、作業を委任した、または測定を行ったと主張しないでください。

手順

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、INP、CLS）、ページの読み込み時間、インタラクティブになるまでの時間、体感パフォーマンスを測定してください。利用可能であれば、リアルユーザーモニタリング（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 ツールを使用します
• プロンプト：「$ARGUMENTS の包括的な負荷テストを、k6/Gatling/Artillery を使用して実施してください。本番トラフィックパターンに基づいて、現実的な負荷シナリオを設計してください。通常負荷、ピーク負荷、ストレスの各シナリオをテストしてください。該当する場合は、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」

成功基準の例

テストの前に、ワークロードに応じた目標値を合意してください。以下の数値は例であり、普遍的な要件でも、改善を保証するものでもありません。フィールド訪問の 75 パーセンタイルで Core Web Vitals を評価し、モバイルとデスクトップを分けてください。INP は FID に代わる指標です。ラボ環境での読み込み時間だけでは、実際の操作に対する応答性は測定できません。

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

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

例

ユーザーのリクエスト：

バックエンド、フロントエンド、インフラストラクチャ全体のパフォーマンス最適化を調整してください。

制限事項

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