capacity-and-cost-engineering

キャパシティとコストのエンジニアリング

需要、パフォーマンス、信頼性、支出を結び付け、根拠のあるキャパシティとコストの判断を行います。このスキルでは、技術的なキャパシティをモデル化し、インフラレベルでのユニットコストを算出し、予算とクォータの制御を定義し、キャパシティに関する主張には負荷テストとソークテストの証拠を求め、コストとパフォーマンスのトレードオフを明示します。これにより、production-readiness のリリース判断に役立つ証拠を作成し、site-reliability-engineering の SLO の選択を制約または支援します。

相互に関連する側面

需要（トラフィックと成長）、パフォーマンス（レイテンシとスループット）、信頼性（SLO とエラーバジェット）、支出（コスト）は、相互に関連する側面として扱います。いずれかの側面に変更があると、ほかの側面にも影響します。このスキルの中核となる手法は、それらのつながりをたどることです。

側面	キャパシティへの影響	コストへの影響
需要（トラフィック、成長率）	コンピューティング、ストレージ、ネットワークの要件を左右します	基準となる支出と予測支出を左右します
パフォーマンス（レイテンシ、スループットの目標）	リクエストごとに確保するリソースの余裕を制約します	目標を厳しくするとユニットコストが増加します
信頼性（SLO、エラーバジェット）	冗長化、過剰プロビジョニング、または分離が必要になります	SLO を高めるとコストは非線形に増加します
支出（予算、コスト制約）	キャパシティに上限を設け、縮退運転を余儀なくする場合があります	達成可能な SLO とパフォーマンスの目標を制限します

ほかの側面をモデル化せずに、ある側面を変えるキャパシティの判断は不完全です。このスキルで扱うすべてのキャパシティモデル、ユニットコストの算出、予算の判断では、証拠または明示的な仮定を用いて、少なくとも 1 つの別の側面とのつながりを示す必要があります。

読み込みガイド

次のいずれかに該当するタスクでは、このスキルを読み込みます。

トリガー	読み込む内容
成長予測からプロジェクトのキャパシティを見積もる	SKILL.md + templates/capacity-model.md
ピークイベント（ローンチ、ブラックフライデー、季節イベント）向けにキャパシティを見積もる	SKILL.md + templates/capacity-model.md + templates/load-soak-test-plan.md
ユニットコストを算出し、SLO または需要に関する判断に結び付ける	SKILL.md + templates/unit-economics-record.md
予算のしきい値、支出アラート、またはハード上限を定義する	SKILL.md + templates/budget-quota-decision.md
運用環境でのクォータやレート制限の適用を設計する	SKILL.md + templates/budget-quota-decision.md
キャパシティの証拠となる負荷テストまたはソークテストを計画、レビューする	SKILL.md + templates/load-soak-test-plan.md
SLO とコストのトレードオフ、またはコスト制約下での信頼性に関する判断を解決する	SKILL.md + templates/slo-cost-tradeoff-record.md
コスト異常をレビューする、またはサービスやチームにコストを割り当てる	SKILL.md + templates/unit-economics-record.md
マルチテナントの需要、偏り、公平性、またはテナントごとに異なるユニットコストをモデル化する	SKILL.md + references/multi-tenant-capacity-and-unit-cost.md + templates/tenant-capacity-model.md
隣接するスキルとの責任範囲を把握する	SKILL.md + references/discovery-brief.md

作業方法

1. モデル需要と容量

需要のシグナルから始めます。現在のトラフィック、成長率、把握しているピークイベントを確認します。次の要素を結び付ける容量モデルを使って、需要を容量要件に変換します。

• 需要単位（リクエスト数／秒、同時ユーザー数、取り込みデータ量（GB）、メッセージ数／秒）と
• 容量単位（vCPU、メモリ（GB）、ストレージ（GB）、IOPS、ネットワークスループット、プロビジョニング済みスループット単位）を
• 使用率目標（各リソースで持続可能な最大使用率。根拠を明記し、文脈を無視して普遍的な割合を設定しないこと）を通じて対応付けます。

使用率目標、その目標の根拠（なぜ85%ではなく70%なのか）、使用率が目標に近づいたときに発動するスケーリングのトリガーが明記されていなければ、容量モデルは不完全です。

需要の前提、容量単位の対応付け、根拠付きの使用率目標、スケーリングのトリガー、および対象期間の予測を記録する容量モデルテンプレート（templates/capacity-model.md）を使用してください。このテンプレートには、前提、根拠の出典、担当者、トレードオフを記入する欄があります。

2. 単位コストを計算する

単位コストとは、需要の単位を1つ提供するためのコストです。リクエストあたりのコスト、ユーザー1人あたりの月額コスト、保存データ1 GBあたりのコスト、プロビジョニング済み容量単位あたりのコストなどがあります。単位コストによって、インフラ支出とプロダクトや信頼性に関する意思決定を結び付けられます。

次の式で単位コストを計算します。

unit cost = total cost of capacity / number of demand units served

分子と分母は、同じ期間、同じ対象範囲（サービス、チーム、またはプラットフォーム）で測定し、同じ配賦方法（直接的なリソースコスト、按分した共有コスト、または間接費を含む総コスト）を明記する必要があります。

単位経済性記録テンプレート（templates/unit-economics-record.md）には、単位の定義、配賦方法を含むコストの分子、測定元を含む需要の分母、算出した単位コスト、SLOごとのコスト比較（99.9%と99.99%で単位コストがどう変わるか）、および前提／根拠／担当者／トレードオフのセクションが必要です。このテンプレートには、単位コストの計算式を記入する構造化フィールドも含まれています。

マルチテナントサービスでは、フリート全体の平均値だけを単位として使用しないでください。references/multi-tenant-capacity-and-unit-cost.md を読み込み、プラットフォームのベースラインコストとテナントごとに変動するコストを区別したうえで、テナントコストまたはリソース消費量の分布を報告してください。テナントの変動単位コストは、リクエストの内訳、ストレージ、バックグラウンド処理、バースト形状、配置、ティアの権限によって変わる場合があります。共有コストの配賦は明示的なモデリング上の選択であり、すべてのテナントが等しい割合を消費するという主張ではありません。

3. 予算とクォータの制御を定義する

予算制御とは、運用上の結果を伴う支出上限です。しきい値での支出アラート、追加支出を防ぐハード上限、上限到達時の運用動作（縮退、スロットリング、または停止）などが含まれます。クォータとレート制限の適用は、リクエストまたはリソースのレベルで予算制御を実装する仕組みです。

予算制御は、次の3つのレベルで機能します。

レベル	仕組み	運用上の結果
アラート	支出しきい値の通知	自動処理は行わず、レビューを促します
ソフト上限	スロットリング、縮退モード、プロビジョニングの削減	容量を減らしてサービスを継続します
ハード上限	レート制限、クォータ適用、リソースの拒否	上限を超えるリクエストは拒否されます

予算制御では、しきい値ごとの対応（運用上の動作、ユーザーへの影響、対応の責任者）を指定する必要があります。運用上の結果が定義されていない予算しきい値は不完全です。

予算／クォータ決定テンプレート（templates/budget-quota-decision.md）には、予算の担当者、期間、しきい値（アラート／ソフト／ハード）、クォータまたはレート制限の設定、適用の仕組み、しきい値ごとの運用動作、コストの配賦方法、異常検知のトリガー、承認記録を記載します。

4. 負荷／ソークテストのエビデンスを必須にする

容量に関する判断には、負荷テストとソークテストのエビデンスが必要です。 実際のシステムが代表的な負荷の下でどのように動作するかを観測せず、容量モデルだけを用いても、容量に関する主張やスケーリングポリシーを裏付ける十分なエビデンスにはなりません。

• 負荷テストでは、定義した期間、目標スループット（例：予想ピーク＋20％の余裕）でシステムを動作させ、レイテンシ、エラー率、リソース使用率を測定します。
• ソークテストでは、長時間（数時間から数日）にわたって持続的な負荷をシステムにかけ、短時間の負荷テストでは見逃す緩やかなリーク（メモリ、ファイルディスクリプター、接続プール、ディスク使用量の増加）を検出します。

負荷／ソークテスト計画テンプレート（templates/load-soak-test-plan.md）には、テストの目的、目標スループットとその根拠、期間、環境（代表的な環境が必須です。開発環境でのテストでは不十分です）、成功基準（レイテンシのパーセンタイル、エラー率、リソース使用率）、データ収集計画、エビデンスの記録を記載します。このテンプレートでは、コンポーネントレベルのベンチマークとエンドツーエンドテストを区別します。容量に関する判断では、どの境界を対象にテストしたかを明記する必要があります。

テストのエビデンスを伴わないモデル化も、モデルを伴わないテストも不完全です。両方が必要です。

マルチテナントに関する主張では、一般的なテナント、需要の高いテナント、バーストが発生するテナント、該当するティアや配置のバリエーションを含む代表的なテナントプロファイルを同時にテストする必要があります。単一テナントのベンチマークやフリート全体の平均テストでは、ホットテナント、パーティションの偏り、公平性の動作に対する保護を立証できません。

5. SLOとコストのトレードオフを解決する

予測される需要に対してSLOを達成するコストが予算を超える場合や、予算の制約によってチームが本来目標とするより低いSLOを選ばざるを得ない場合、SLOとコストのトレードオフが生じます。これは、暗黙に受け入れるのではなく、体系的に判断する必要があります。

SLOとコストのトレードオフ記録テンプレート（templates/slo-cost-tradeoff-record.md）には、検討中のSLO、それを達成するための現在のコスト、需要予測に基づく予測コスト、代替SLOとコストの比較、より低いSLOを選択した場合の縮退パス、エラーバジェットへの影響、説明責任を負う担当者、承認記録を記載します。このテンプレートでは、エビデンス（コスト予測、負荷テストデータ）と責任者（誰が決定し、誰が説明責任を負うか）を明確にして、トレードオフを提示することが求められます。

シナリオ

成長シナリオ

需要が予測可能な形で増加しています（例：前月比15％）。検討事項は、現在の容量がいつ不足するか、そして成長に先行して備えるにはどれだけのコストがかかるかです。

ガイダンス：

1. 信頼区間を含め、成長率を使って需要を将来にわたって予測します。
2. 現在の使用率目標に基づいて容量をモデル化し、最初に飽和するリソースを特定します。
3. スケーリングの各段階で必要となる増分容量のコストを算出します。
4. スケーリングのトリガー（プロビジョニングを開始する必要がある使用率のしきい値）を定義します。リードタイムが重要です。
5. 前提条件（成長率が安定していること、急激な変化を伴う事象がないこと、現在の使用率パターンが維持されること）とエビデンスの情報源を記録します。

ピークシナリオ

既知のイベントによって、トラフィックがベースラインを大幅に上回る見込みです（製品のローンチ、ブラックフライデー、季節的なピークなど）。検討事項は、ピークに必要な容量とそのコスト、そしてそのコストが正当化されるかどうかです。

ガイダンス：

1. ピーク需要はベースラインとは分けてモデル化します。ピークの数値だけでなく、ピークの形状（高さ、継続時間、立ち上がり）も考慮します。
2. 平均ではなく、ピークに合わせて容量を見積もります。余裕も確保します。
3. イベントの前に、予測ピークスループットで負荷テストを実施します。負荷テストのエビデンスがないモデルでは不十分です。
4. ピーク後にスケールダウンする計画とそのトリガーを定義します。ピーク後も容量を維持すると、不要なコストが発生します。
5. ピーク時の容量コストが予算を超える場合は、機能のうち何を停止し、ユーザーがどのような体験をするかを含め、縮退したピーク時の代替案をモデル化します。

性能低下シナリオ

依存関係が失敗したり、リソースの制約によりフルキャパシティを下回る状態での運用を余儀なくされたりします。ここでの問いは、性能低下モードではシステムがどのような状態になるのか、コアパスに必要なキャパシティはどの程度か、そして性能低下状態での運用にどれほどのコストがかかるのか、ということです。

ガイダンス：

1. 機能を、維持必須のコア機能と、切り離し可能な拡張機能に分類します。性能低下時の設計については、resilience-and-recovery を参照してください。
2. コアパスのみを運用する場合のキャパシティをモデル化し、拡張機能を切り離すことでどのリソースが解放されるかを明らかにします。
3. 性能低下状態での運用コストを算出します（フル稼働時より低くなる場合も、フェイルオーバー用リソースが有効になって高くなる場合もあります）。
4. 性能低下状態での運用期間の上限を定めます。エスカレーションが必要になるまで、性能低下モードをどれほど継続できるかを明確にします。
5. 性能低下時のキャパシティモデルが、ゲームデーまたはカオステストで検証されるようにします。演習の設計については、resilience-and-recovery を参照してください。

コスト制約シナリオ

予算の制約により、理想的なキャパシティや SLO 目標に合わせたプロビジョニングができません。ここでの問いは、予算内で実現可能な信頼性とパフォーマンスの水準はどれほどか、そして誰が決定するのか、ということです。

ガイダンス：

1. 予算の制約から始め、上限を明示します（月次、四半期、年次）。
2. 現在の単価で、その予算により購入できるキャパシティをモデル化します。
3. そのキャパシティで実現可能な SLO とパフォーマンス目標を算出します。
4. 制約のない理想的な状態と比較し、どの SLO、レイテンシ、スループットを引き換えにするのかを明らかにします。
5. 責任者を明記した SLO とコストのトレードオフ記録を作成します。コスト最適化を理由に、信頼性、プライバシー、ユーザーの成果を損なってはなりません。予算内で許容可能な SLO を実現できない場合は、黙って受け入れるのではなく、エスカレーションします。

コスト最適化を理由に、信頼性、プライバシー、ユーザーの成果を損なってはなりません。 コスト制約により、予算とこれらの譲れない条件のどちらかを選ばざるを得ない場合は、根拠となる情報を添えて、責任者にエスカレーションします。最適化として黙って受け入れることは決してありません。

使用しない場合

このスキルは、一般的なクラウドコスト削減のヒント（リザーブドインスタンス、スポットインスタンス、「未使用のリソースを停止する」、「適正なサイズにする」、セービングプラン）を提供するものではありません。これらはプラットフォーム固有の実装手法であり、容量とコストに関する方法論を扱うこのスキルではなく、platform-engineering のリファレンスやクラウドプロバイダーのドキュメントで扱うべきものです。このスキルが担うのは、容量とコストに関する意思決定の枠組みと根拠の基準であり、コスト削減のヒント一覧ではありません。

このスキルでは、利用率の目標を一律に定めません。トラフィックが急増するレイテンシ重視のサービスにおける利用率 70％ の目標と、負荷が予測可能なバッチ処理パイプラインにおける 85％ の目標は同じではありません。利用率の目標にはすべて、背景、根拠、および裏付けとなる証拠を明示する必要があります。背景を示さずに「利用率 70％ を目標とする」とするのは、キャパシティの決定ではなく、推測です。

このスキルでは、コスト最適化を理由に、信頼性、プライバシー、ユーザーの成果を損なうことは認められません。これらは譲れない制約です。これらに違反するおそれのあるコスト制約シナリオは、制約内で無理に最適化するのではなく、エスカレーションする必要があります。

ルーティング表

タスクに含まれる内容...	ルーティング先...
損益計算書、資金調達、SaaS 指標（ARR／チャーン／NDR）、価格設定戦略	financial-modeling
インフラストラクチャの実装、自動スケーリング、クラウドのプロビジョニング、コスト配賦タグ	platform-engineering
SLO の定義、エラーバジェットポリシー、インシデント指揮、オンコール運用	site-reliability-engineering
需要の測定、トラフィック予測の計測、トラッキング計画	product-analytics-and-measurement
リリース判断、複数ドメインにまたがるエビデンスの収集、実施可否／延期／例外の判断	production-readiness
ポートフォリオのキャパシティ配分、投資の順序付け、ロードマップのトレードオフ	product-roadmapping-and-portfolio
劣化時の動作設計、復旧の検証、RTO／RPO の判断、ゲームデー	resilience-and-recovery
需要の統計モデリング、時系列予測、成長要因の因果推論	data-scientist
コストデータパイプラインの実装、支出データの ETL、コストダッシュボードのデータモデル	data-engineering
テナントのエンドツーエンドのセマンティクス、コントロールプレーン／アプリケーションプレーン、テナンシーの選択、ライフサイクル、請求の引き継ぎ	multi-tenant-saas-architecture
テナント分離の脅威、認可、特権サポート、セキュリティ制御	secure-software-engineering
一般的なアーキテクチャ境界、トポロジー、分解の判断	software-architecture

ファイル一覧

パス	読み込むタイミング
references/discovery-brief.md	隣接するスキルとの責任範囲やルーティングルールを把握するとき
templates/capacity-model.md	利用率の目標とスケーリングのトリガーを含む、需要からキャパシティへの予測を作成するとき
templates/unit-economics-record.md	ユニットコストを算出し、SLO や需要に関する判断と結び付けるとき
templates/budget-quota-decision.md	予算のしきい値、クォータの上限、レート制限の適用、運用上の影響を定義するとき
templates/load-soak-test-plan.md	キャパシティのエビデンスとして、負荷テストやソークテストを設計またはレビューするとき
templates/slo-cost-tradeoff-record.md	エビデンス、説明責任、承認に基づいて SLO とコストのトレードオフを解決するとき
references/multi-tenant-capacity-and-unit-cost.md	テナント分布、偏り、プール型／サイロ型の余力、ティアの保証、受け入れ制御、公平性のエビデンス、コスト配賦をモデル化するとき
templates/tenant-capacity-model.md	テナントのプロファイル、パーティションの動作、余力、クォータ／受け入れ制御のエビデンス、テナントごとに変動するユニットコストを記録するとき
references/source-index.md	この方法論の公開されている出典情報と独自執筆の範囲を確認するとき