performance-optimization

パフォーマンスの最適化

ボトルネックを一度に1つずつ、繰り返し測定し、原因を説明し、変更して、検証することで、ユーザーにとって重要な結果を改善します。より高速なマイクロベンチマークは、関連するエンドツーエンドの測定値または実環境の測定値で確認されるまでは、ユーザーへの効果に関する仮説にすぎません。

対象システムに初めて変更を加える前に、ユーザーの依頼または現在のプロジェクト記録から、対象、範囲、ロールバック手順を確認してください。読み取り専用の調査に確認は不要です。本番環境のテレメトリー、フラグ、デプロイ、クリーンアップについては、プロジェクトの権限とレビューゲートに従ってください。

使用しない場合

SLOポリシーとインシデント復旧にはsite-reliability-engineeringを、需要と支出の予測にはcapacity-and-cost-engineeringを、一般的な負荷・ストレス・ソークテストの戦略にはqa-methodologyを、製品の動作に関するA/Bテストにはproduct-experimentationを、特定の機能障害にはsystematic-debuggingを使用してください。名前が指定された可観測性スタックの運用には、telemetryまたはgrafanaを使用してください。

ループ

1. ジャーニーと予算を選びます。 ユーザー、高頻度または高コストのジャーニー、そしてユーザーが実際に体験する主要な成果を1つ特定します。成果の例としては、操作から描画までのレイテンシ、タスク完了時間、明示したエラー率でのスループット、メモリ、エネルギー、有用な操作あたりのコストがあります。開始イベントと終了イベント、単位、ワークロードの構成、対象集団、プラットフォーム、目標または実用上の最低改善幅を定義します。正確性、アクセシビリティ、信頼性、リソースに関するカウンターメトリクスも含めます。測りやすい指標だけを単独で最適化しないでください。
2. 測定を監査します。 既存のフィールドテレメトリ、トレース、プロファイル、テスト、レポートをジャーニーに対応付けます。イベントの意味、欠落またはサンプリングされたイベント、セグメント化、バージョン／ビルドタグ、クロックの境界、プライバシー、測定のオーバーヘッドを確認します。成果が測定されていない場合は、そのギャップを埋めるための最小限の計測または再現可能なローカルプローブを追加し、一時的な代替指標であることを明記します。サンプル数、期間、パーセンタイルまたは分布、既知の不確実性を含めてベースラインを記録します。シグナルの選択やベンチマークの設計時には、measurement-and-benchmarksを参照してください。
3. ボトルネックを特定します。 クリティカルパスを追跡し、該当する場合はクライアント、ネットワーク、キュー、サービス、依存関係、ストレージ、描画にかかる時間を分けます。代表的な遅い部分をプロファイルし、CPU処理を待機、割り当て、競合、I/O、繰り返し処理から区別します。修正案を提案する前に、現実的なデータと条件でコストの高い経路を再現します。影響を受けるユーザー数 × 達成可能な改善幅 × 確信度で機会を順位付けし、実装コストと回帰コストも明示します。 症状は分かっているものの、最初に確認すべき有用なシグナルやプロファイルが不明な場合は、diagnostic-guideを参照してください。
4. 実験を1つ記述します。 想定する仕組み、主要メトリクス、診断メトリクス、カウンターメトリクスの予測される変化、そして最小限で元に戻せる介入を明記します。結果を見る前に、ワークロード、ビルド、環境、ウォームアップ、比較方法を固定します。測定値にノイズがある場合は、ベースラインと候補を繰り返し実行するか、交互に実行し、分布を報告します。1回の計測だけで改善したと判断しないでください。命令数や描画コミット数などの決定論的な代替指標をゲートとして使う前に、代表的な改善幅、妥当な回帰、境界ケースにわたって、ユーザーに関係する測定値との相関を検証します。
5. 変更して検証します。 意味のある正確性チェックで動作を維持し、そのうえで対象を絞った変更を行います。同じワークロードでベースラインと候補を比較し、絶対差と相対差、実行回数、分散、ハードウェア／ビルド、カウンターメトリクスの変化を記録します。代替指標だけでの改善、不安定なベンチマーク、別の箇所での回帰、合意した実用上のしきい値に満たない改善は却下します。判断基準についてはexperiment-and-rolloutを参照してください。
6. レビューし、段階的に展開して、観察します。 差分、根拠、リスク、ロールバックの条件、担当する人間の責任者を明示します。ユーザーに見える変更や本番環境への変更には、プロジェクトで通常定められているレビューと展開のゲートを使用します。スキルによってデプロイ権限が与えられるわけではありません。展開後は、十分な期間にわたり、ビルド、プラットフォーム、関連するユーザー層ごとにフィールド結果を比較します。フィールドでの成果が目標に達しない場合や悪影響が見られる場合は、元に戻すか無効化して調査します。効果が維持される場合は、安定した、意味のある回帰チェックまたはパフォーマンス予算を維持します。ベンチマークの再現性で裏付けられないほど厳しいしきい値をCIに設定しないでください。
7. 繰り返すか、終了します。 改善を採用するたびにジャーニーを再プロファイルします。ボトルネックが移動している可能性があります。目標を達成した場合、次に期待できる改善の実用的価値が低い場合、測定を一定の範囲で行っても根拠から改善とノイズを区別できない場合、または次の手順に責任者の判断が必要な場合は終了します。未実行の実験を改善として示すのではなく、残された機会と不確実性を記録します。

作業記録

複数のステップにわたる作業には、templates/optimization-record.md を使用してください。ジャーニーまたはボトルネックごとに記録を1つ作成し、生のエビデンスとコミットへのリンクを含めてください。観測結果、推定結果、提案結果を分けて記録してください。ローカルベンチマーク、CI の成功、ステージングの結果、実際のユーザーの改善は、それぞれ異なるエビデンスの状態です。

ボトルネックをプロファイリングし、動作を確認し、コマンド全体の実行時間を複数回比較して、フィールドでの検証を保留状態にする実行可能な例については、worked-investigation を参照してください。

スコープの振り分け

• クライアントのレンダリングと Web Vitals：frontend-engineering。バックエンドクエリとサービスコード：backend-engineering。
• 需要、飽和状態、コスト：capacity-and-cost-engineering。エージェントの品質とレイテンシのトレードオフ：agent-evals-and-observability。
• 計装インフラストラクチャ：telemetry。リリースゲートと段階的なロールアウト：release-engineering。

出典

ジャーニー → ベンチマーク → レビュー済みの変更 → ロールアウト → フィールドでの評価 → ラチェットというループは、Anthropic の claude.ai パフォーマンスに関する記事に基づいています。参考資料では、フィールドデータとラボデータの使い分けや、ばらつきへの対処方法を説明しています。Anthropic が報告した改善はケーススタディであり、そのまま適用できるパフォーマンス目標ではありません。