cost-optimization

コスト最適化

クラウド、SaaS、インフラの支出を監査します。費用に見合わないものは削減します。過剰なものは適正な規模にします。交渉できるものは交渉します。正常に動作しているものを壊さずに進めます。

---

使用するタイミング

• 四半期または年次のコストレビュー
• 財務部門から支出の増加を指摘されたとき
• ベンダーとの契約更新が近づいているとき
• 予算削減が必要なとき
• 新しい経営陣が数値を求めているとき
• プロバイダー間の移行時（コストが移行の理由の一つである場合）
• 大幅な規模拡大の前の監査（無駄が拡大する前に見つけます）

使用しないタイミング

• インシデントへの対応中（incident-response を使用）
• インフラが関係しているパフォーマンスの問題（performance-optimization を使用）
• 新規購入に向けたベンダー評価（vendor-evaluation を使用）
• 人員や組織のコスト（このスキルの対象外です）

---

必要な入力

• 現在のコスト（月額、できれば過去12か月分）
• サービスまたはベンダーごとのコスト内訳
• クラウドリソースの一覧（インスタンス、データベース、ストレージなど）
• SaaS サブスクリプションの一覧
• コスト項目ごとの担当者（支出を決定した人、利用している人）
• 制約（コンプライアンス、パフォーマンス、契約条件）

---

フレームワーク：5つのレバー

コスト最適化の機会はすべて、次の5つのレバーのいずれかに当てはまります。

レバー1：排除する

使われていないものへの支払いをやめます。

• アイドル状態のリソース（稼働中だが使われていないインスタンス、データベース、環境）
• 誰もログインしていないサブスクリプション
• 重複しているツール（同じ役割を果たす複数のツール）
• コストが発生し続けている古いプロジェクト
• 停止すべきテスト環境
• 忘れられたドメイン、バックアップ、スナップショット、ログ

通常、最初の監査で最大の削減機会となります。多くの場合、支出の10～30％を占めます。

レバー2：適正化する

3年前に最悪のケースを想定してプロビジョニングした容量ではなく、実際の使用量に応じた料金を支払います。

• 過剰なサイズのインスタンス（CPUとメモリの使用率が低い）
• 過剰にプロビジョニングされたデータベース（ストレージとスループットが使用量を大幅に上回っている）
• 購入しすぎたSaaSシート
• 標準プランで十分なのに利用しているプレミアムプラン
• 重要度の低いシステムに対する高可用性構成

適正化には、理論上の必要量ではなく、実際の使用状況データが必要です。

レバー3：構成を見直す

同じワークロードを、より安価な構成で実行します。

• リザーブド料金または使用量コミット料金（1～3年の契約で30～70％割引）
• 耐障害性のある処理にスポットインスタンスまたはプリエンプティブルインスタンスを使用
• アクセス頻度の低いデータにコールドストレージを使用
• アクセスパターンに応じた階層型ストレージ（ホット／ウォーム／コールド）
• CDNキャッシュによるオリジン負荷の軽減
• 圧縮と重複排除
• 負荷の変動が大きいワークロードにサーバーレスを使用
• 安定したワークロードにリザーブドインスタンスを使用

適切な構成はアクセスパターンによって異なります。パターンに合わない構成はコストにつながります。

レバー4：交渉する

同じものに対して、より安く支払います。

• 月払いより料金の低い年間契約
• 上位の利用枠で適用されるボリュームディスカウント
• 予測可能なワークロードに対する複数年契約
• バンドル契約（1社のベンダーにサービスを集約）
• 契約更新時の交渉（ベンダーは交渉を持ちかけられることを想定しています）
• RFP／競争入札（代替案を交渉材料として利用）

大半のエンタープライズ向けベンダーは交渉に応じます。大半のSaaSベンダーは、上位プランを除いて交渉に応じません。一般消費者向けのサービスは通常、交渉に応じません。

レバー5：問いを変える

問いそのものを変えます。

• 内製か購入か：規模が大きくなれば、内製の方が安いかもしれません
• 購入か内製か：規模が小さければ、外部委託の方が安いかもしれません
• アーキテクチャの違い（例：モノリスかマイクロサービスか）によって、コスト構造は異なります
• 対象顧客の違い（すべての顧客に同じプランが必要でしょうか）
• 技術スタックの違い（オープンソースか商用か）

問いを変えるレバーは、効果が出るまでに最も時間がかかります。すぐに実行できなくても、検討する価値があります。

---

ワークフロー

ステップ1：支出データを取得する

サービス、ベンダー、可能であればチームまたはプロジェクトごとの月次コストを取得します。

クラウド（AWS、GCP、Azure）の場合：請求コンソールとコストエクスプローラーツールを使用します。 SaaSの場合：各ベンダーの請求ポータルと、利用可能であればSaaS管理ツールを使用します。 その他の場合：銀行明細と会計データのエクスポートを使用します。

最低12か月分を用意します。絶対額と同じくらい、推移も重要です。

ステップ 2：分類する

支出を次のカテゴリに分類します。

• ホスティング／コンピューティング
• ストレージ
• データベース
• ネットワーク／CDN
• モニタリング／オブザーバビリティ
• メール
• CMS／ホスティングプラットフォーム
• 分析／マーケティング
• 生産性／コラボレーション
• 開発ツール
• セキュリティ／コンプライアンス
• その他

カテゴリはビジネスによって異なります。重要なのは、類似するコストをまとめて、簡単に比較できるようにすることです。

ステップ 3：最大の費目を特定する

80対20の法則です。通常、ベンダーの20％が支出の80％を占めます。

監査では上位80％に注力します。ロングテールの項目も整理できますが、項目ごとの大きな節約にはつながらないことがほとんどです。

ステップ 4：5つのレバーを適用する

主な費目ごとに、各レバーを検討します。

レバー	質問
排除	使われていますか？利用を停止できますか？
適正化	使用していない容量に対して料金を払っていませんか？
再構成	より安価な料金モデルやサービス階層はありますか？
交渉	前回の契約更新はいつでしたか？交渉しましたか？
再検討	そもそも、これが適切な方法ですか？

機会、必要な労力、リスク、節約額の見積もりを記録します。

ステップ 5：優先順位を付ける

機会を2×2の表に配置します。

• Y軸：節約額
• X軸：労力

象限：

• 節約額が大きく、労力が小さい：最初に実施
• 節約額が大きく、労力も大きい：計画を立てる
• 節約額が小さく、労力も小さい：時間があれば実施
• 節約額が小さく、労力が大きい：見送る

リスクも考慮します。

• 誰も使っていないものを排除する：低リスク
• データベースを適正化する：中リスク（まずステージングでテスト）
• 重要な依存関係を置き換える：高リスク（慎重に計画）

ステップ 6：簡単にできる改善を実行する

簡単に実施できる改善ごとに、次の手順を行います。

• 変更内容を記録する
• オーナーの承認を得る
• 変更を実施する
• 予期しない影響がないか監視する
• 次の請求サイクルでコスト削減を確認する

簡単にできる改善には、通常、次のようなものがあります。

• 未使用のサブスクリプションを解約する
• アイドル状態のリソースを削除する
• 営業時間外に開発環境を停止する
• アクセス頻度の低いデータを、より安価なストレージ階層に移動する

ステップ 7：大規模な作業を計画する

労力の大きい機会については、次の手順を行います。

• 変更内容を仕様化する（計画には pm-spec-writing を使用）
• ステージングでテストする
• 段階的にロールアウトする
• コストへの影響を検証する

例：

• リザーブドインスタンスへの移行
• モニタリングベンダーの統合
• コスト削減につながる、あるCMSから別のCMSへの移行

ステップ 8：継続的に状況を把握できるようにする

最適化は一度きりではありません。コストは再び増加します。

• 毎月のコストレビュー（最低限）
• コストダッシュボード（現在の状況、推移、カテゴリ別）
• コスト急増時のアラート（例：1日の支出がしきい値を超えた場合）
• クラウドリソースへのタグ付けやラベル付け（チーム別またはプロジェクト別のコスト）
• 四半期ごとの詳細なレビュー

ステップ 9：契約更新時に交渉する

更新を控えたベンダー契約については、次のように対応します。

• 更新の60～90日前に交渉を始める
• 代替案を特定しておく（切り替えない場合も同様）
• 複数年契約の割引を求める
• 利用量に応じた料金階層について尋ねる
• 利用量の適正化が可能か尋ねる
• 契約を打ち切る意思を示す（多くのベンダーは顧客を引き留める方法を見つけます）

パンデミック前は、多くのベンダーが値上げして自動更新していました。パンデミック後は、顧客維持に必死なベンダーが多くなっています。交渉しましょう。

ステップ 10：ポリシーを文書化する

今後は、次のようにします。

• 新しいベンダーの評価に、コストの正当性を示すことを必須とする
• リソースのプロビジョニングに承認のしきい値を設ける
• クラウドリソースへのタグ付けとラベル付けを必須とする
• 四半期レビューをカレンダーに登録する
• コストの帰属先を明確にする

ポリシーがなければ、コストは再び増加します。

---

カテゴリ別のよくある改善機会

ホスティングとコンピューティング

• 予測可能なワークロードには、リザーブド料金または利用コミットメント料金を適用する（30～70％割引）
• 耐障害性のあるバッチ処理には、スポットインスタンスまたはプリエンプティブルインスタンスを利用する
• 変動する負荷にはオートスケーリングを利用する
• 適切なインスタンスファミリーを選ぶ（コンピューティング最適化、メモリ最適化など）
• 営業時間外は開発／ステージングのインスタンスを停止する

ストレージ

• ライフサイクルポリシーを設定し、古いデータをより安価な階層に移動する
• 古いログ、バックアップ、スナップショットを削除する
• アーカイブ用に圧縮する
• オブジェクトのバージョニングによるコスト（各バージョンが保存オブジェクトになります）

データベース

• 実際の CPU／メモリ使用量に基づいて適正なサイズに調整します
• 予測可能なワークロードにはリザーブド容量を利用します
• 読み取り負荷の高いワークロードには読み取りレプリカを利用します（プライマリのスケールアップより低コストです）
• 使用していないインデックスを削除します（インデックスはストレージを消費し、書き込み性能を低下させます）
• 古いデータはアーカイブまたは削除します

ネットワークと CDN

• CDN によってオリジンの送信コストを削減できます（多くの場合、最も大きなコスト項目です）
• 通信データを圧縮します
• 画像と動画を最適化します
• リージョンを考慮したルーティングを行います

モニタリングと可観測性

• ログをサンプリングします（大量のデータを生成するソースから 100％を取り込まないようにします）
• 保持ポリシーを設定します（90 日必要ですか、それとも 30 日ですか？）
• 可能な範囲でツールを統合します
• 重要度の低いニーズには無料またはオープンソースのツールを使います

SaaS

• シートごとのログイン状況を監査します（1 シートあたり $X で、使っていないユーザーがいれば $X の無駄です）
• 更新時に価格を再交渉します
• 割引を受けるため、年払いに切り替えます
• 重複するツールを統合します

---

失敗パターン

何かを壊してしまうコスト削減。 テストせずに積極的な適正化を行うと、障害が発生します。障害によるコストは通常、削減額を上回ります。

節約額より時間がかかる最適化。 チームが四半期を費やして年間 $5K を節約します。計算が合いません。労力を上回る節約が見込める機会に集中してください。

更新時の自動継続。 毎年の契約更新が見直しなしに行われます。カレンダーに登録してください。

タグ付けなし。 クラウドの支出が増えても、誰のものか分かりません。初日からすべてにタグを付けてください。

無料枠の超過。 「無料枠を使っています」。その後、無料枠ではなくなり、請求額に驚きます。無料枠のサービスにアラートを設定してください。

環境の区別がない。 「本番環境に合わせる」ために、本番環境と同等のステージング環境を用意します。本番環境と同じくらいのコストがかかります。多くの場合、不要です。

放置されたレガシー。 「古いプロジェクトはまだ動いています」。なぜでしょうか？ 多くの場合、実際に使っている人はいません。監査して停止してください。

必要以上のプレミアムプラン。 下位プランにもすでに追加されている機能が欲しいという理由で、エンタープライズプランを利用しています。再確認してください。

ベンダーロックインをコストの正当化に使う。 「切り替えられません」。それは過払いの理由にはなりません。計画的に対処すべき戦略上の問題です。

大きなコストを無視して小さなコストを最適化する。 インフラの過剰なサイズに月 $5K かかっている一方で、ツールの月 $50 を節約しています。まずは大きな項目から取り組んでください。

安物買いの銭失い。 月 $20 を節約するために便利なツールを削減し、その結果、手作業に何時間も費やします。費用を回収できるツールは削減すべきではありません。

再投資しない。 節約した金額をすべて利益に回し、アップグレードや容量には何も再投資しません。コスト削減と機能の改善は、どちらか一方を選ぶものではありません。

---

出力形式

コスト最適化ドキュメントには、以下を含めます。

• 現状： カテゴリ別の総支出とその推移
• 主な項目： 最もコストが大きい項目
• 機会： 施策別（削除／適正化／再構成／交渉／再考）
• 優先順位付きリスト： 節約額、労力、リスク
• アクションプラン： 担当者、日付
• 実施済みの簡単な改善： すでに完了した内容と結果
• 継続的なガバナンス： ダッシュボード、レビュー頻度、タグ付け、承認基準

---

必要なデータを利用できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、認められている出力は、何が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分に影響するのかを明示した成果物です。成果物を完成させるために、必要な数値を捏造、推定、または補間することは一切認められていません。不足事項を明示すれば、それで回答として完結します。

---

参考ファイル

• references/cloud-audit-checklist.md：クラウドアカウント（コンピューティング、ストレージ、データベース、ネットワーク、モニタリング）を監査し、無駄や適正化の機会を見つけるための実践的な手順。