cost-optimization

cost-optimizationスキルの概要

cost-optimizationスキルでできること

cost-optimization スキルは、AWS、Azure、GCP、OCI にまたがるクラウドコストを削減するための、実務寄りのフレームワークを AI エージェントに与えます。単なる「不要なものを消す」型のコストカットではなく、チームが実際に向き合う判断――コスト可視化の改善、リソースの適正化、より有利な料金モデルの選定、無駄な支出を生みやすいアーキテクチャ設計の見直し――に焦点を当てています。

どんな人に向いているか

この cost-optimization スキルは、プラットフォームエンジニア、クラウドアーキテクト、FinOps を意識するチーム、SRE、エンジニアリングマネージャーなど、構造化されたコストレビューの指針が必要な人に最適です。特に、「AWS の請求を下げたい」といった広い目標を、より体系的な最適化計画に落とし込みたい場面で力を発揮します。

実際に解決したい仕事

多くのユーザーが必要としているのは、汎用的なクラウドコスト削減チェックリストではありません。無駄がどこに潜みやすいのか、どんな最適化レバーがあるのか、どのトレードオフが重要なのか、どの順序なら安全に変更を進められるのか――そこを見極める支援です。このスキルは、パフォーマンス最適化、予算管理、マルチクラウドガバナンスに向けて、再利用できるレビュー視点が欲しいときに最も有効です。

単なるプロンプトと何が違うのか

普通のプロンプトでも、一般論としてのコスト削減案は出せます。ただし cost-optimization スキルは、エージェントに明確な最適化フレームワークを与える点で優れています。

• まず可視化
• 次に適正化
• その上で料金モデルの選定
• 最後にアーキテクチャレベルのコスト改善

この順序は重要です。多くのチームは、コストを帰属できる状態でも、測定できる状態でも、代替案を比較できる状態でもないのに、先に最適化へ飛びついてしまいがちだからです。

実際に入っているもの

リポジトリを見ると、このスキルはコンパクトですが実用性があります。

• メインのフレームワークをまとめた SKILL.md
• 実務で使えるタグ運用基準をまとめた references/tagging-standards.md

つまり、これは大がかりな自動化パッケージではありません。意思決定支援と分析のためのスキルであり、特に計画、監査、ガイド付きの提案において実務価値が高い構成です。

向いているケース / 向いていないケース

向いているケース:

• クラウド請求のレビュー
• リソース適正化の検討
• 予約インスタンスや Savings Plans などのコミットメント設計
• タグ整備やチャージバック運用の立て直し
• 支出と効率の両立が必要な Performance Optimization 向けの cost-optimization

あまり向いていないケース:

• 生のプロバイダー出力からの厳密な請求計算
• 自動 remediation
• プロバイダー固有の詳細実装 runbook
• インベントリ、利用状況、タグ情報をまったく出せないチーム

cost-optimizationスキルの使い方

cost-optimizationスキルをインストールする

リポジトリから以下でインストールできます。

npx skills add https://github.com/wshobson/agents --skill cost-optimization

環境で別のスキルローダーを使っている場合は、次の場所から追加してください。

https://github.com/wshobson/agents/tree/main/plugins/cloud-infrastructure/skills/cost-optimization

最初に読むべきファイル

導入判断を素早くしたいなら、次の順で読むのがおすすめです。

1. plugins/cloud-infrastructure/skills/cost-optimization/SKILL.md
2. plugins/cloud-infrastructure/skills/cost-optimization/references/tagging-standards.md

SKILL.md では最適化モデルの全体像がわかります。タグの参照資料が重要なのは、タグの品質不足が有用なコスト分析の最大のボトルネックになりやすいためです。

このスキルがうまく機能するために必要な入力

cost-optimization スキルは、次のような具体的な運用コンテキストを与えると、はるかに役立つようになります。

• クラウドプロバイダーと account/subscription/project の構成
• サービス別の月次支出
• compute、storage、database の利用率シグナル
• 既存の reservation、Savings Plans、その他のコミットメント
• タグの付与率とタグ標準
• パフォーマンスや信頼性に関する制約
• 目標が短期の削減なのか、長期のガバナンスなのか、その両方なのか

この文脈がないと、出力はどうしてもハイレベルな内容に留まります。

cost-optimizationで使うときの最適なプロンプトの形

次のように、ひとことだけで頼まないでください。

Help me reduce cloud costs.

代わりに、スキルが判断しやすいだけの構造を持たせます。

Use the cost-optimization skill. Review our AWS spend for a SaaS platform. Prioritize actions by savings potential, risk, and implementation effort. Constraints: production latency cannot degrade, RDS is business-critical, and we already use some Savings Plans. Focus on EC2, EBS, RDS, S3, and data transfer. Also assess whether our tagging is sufficient for chargeback.

これで出力が良くなるのは、次の前提が明確になるからです。

• provider
• workloads
• constraints
• services in scope
• optimization priorities
• governance expectations

あいまいな目標を、実用的な依頼に変える

使いやすいパターンは次のとおりです。

1. ビジネス目標を示す
   例: 90日で支出を15%削減したい。

2. 対象環境を示す
   例: AWS の production と staging の accounts。

3. 制約を定義する
   例: ダウンタイムなし、性能劣化なし、複数四半期にまたがる移行は不可。

4. 根拠データを渡す
   例: 高コストな上位サービス、アイドルリソースの懸念、タグ不足、低利用インスタンス。

5. 優先順位付きの出力を求める
   例: すぐ効く施策、中程度の工数で効く施策、戦略的に進める施策。

初回利用に向いた実践的ワークフロー

最初の一巡としては、次の流れが強力です。

1. まず可視化とタグ運用の成熟度を評価させる。
2. 次に provider と service ごとの無駄の出やすい領域を洗い出させる。
3. その後、ノーリグレットで進められる施策とリスクのある施策を分けさせる。
4. 推奨事項を、工数・削減余地・運用リスクに対応づけさせる。
5. そこまでやってから、provider 固有の実装アイデアを聞く。

この順番なら、基本的な衛生状態を把握しないまま、予約や削除の話に飛びつくのを避けられます。

想定どおりの順序でフレームワークを使う

この cost-optimization ガイドの価値は、土台にあるフレームワークそのものにあります。

• Visibility
• Right-Sizing
• Pricing Models
• Architecture Optimization

ユーザーは料金割引やコミットメントの話に直行しがちですが、実務では先に可視化と適正化を進めたほうが、判断の質が上がることが多いです。たとえば、アイドル容量を整理する前にコミットメントを買うと、悪い利用パターンを固定化してしまう恐れがあります。

タグ基準の参照ファイルが特に重要になる場面

references/tagging-standards.md が特に効くのは、次のような状況です。

• コストをきれいに帰属できない
• チーム間で ownership を巡る議論が絶えない
• chargeback/showback が弱い
• エージェントに、インフラ調整だけでなくガバナンス改善まで提案させたい

リポジトリで挙げられている有用なタグには、次のものがあります。

• Environment
• Owner
• CostCenter
• Project
• ManagedBy

これらが整っていない環境では、まず可視化を改善する目的でこのスキルを使うべきであり、精密な削減額の約束を期待する段階ではありません。

マルチクラウドレビュー向けのプロンプト例

Use the cost-optimization skill to compare AWS and Azure spend controls for a company running dev, staging, and production across both clouds. Identify common waste patterns, provider-specific pricing levers, tagging gaps, and governance controls. Rank recommendations by expected savings, implementation complexity, and operational risk.

この依頼が機能しやすいのは、このスキルが AWS、Azure、GCP、OCI を明示的にカバーしているためです。

パフォーマンス重視システム向けのプロンプト例

Performance Optimization のために cost-optimization を使う場合は、条件を明確にしてください。

Use the cost-optimization skill to review our production compute and database spend. Do not recommend changes that would reduce p95 latency or resiliency. Focus on rightsizing, storage class choices, autoscaling policies, reservations, and non-critical environment cleanup. Show which actions are safe for performance-sensitive workloads and which need benchmarking first.

こうしておくと、技術的には安くても運用上のダメージが大きいコスト削減案を、エージェントが出しにくくなります。

良い出力の見え方

この cost-optimization スキルから有用な回答が返るなら、次の要素が入っているはずです。

• 現状で無駄が出ていそうな領域
• より良い提案を妨げている欠落データ
• 優先順位付きのアクション
• サービスタイプごとの削減レバー
• タグや予算管理などのガバナンス改善
• リスクと前提条件

もし返答が「クラウド節約の一般論リスト」だけになっているなら、環境情報をもっと与えるべきです。

cost-optimizationスキル FAQ

このcost-optimizationスキルは初心者向けか

はい。ただし、少なくとも自社のクラウド環境を基本レベルでは把握していることが前提です。フレームワーク自体は追いやすい一方、出力の質は、支出・ownership・利用率の文脈をどれだけ渡せるかに左右されます。初心者でも、ガイド付きレビューや主要な最適化レバーの学習用途には十分使えます。

普通のプロンプトより優れているか

構造化された分析という意味では、たいていは優れています。このスキルは、まっさらなプロンプトよりも良い思考の型をエージェントに与えます。特に順序づけ――可視化を先に、次にガバナンス、その後で料金判断、最後に深いアーキテクチャ変更――の面で差が出ます。

クラウド変更を自動化してくれるか

いいえ。リポジトリを見る限り、これは自動化ツールではなくガイダンス用のスキルです。最適化戦略や推奨事項をエージェントに考えさせるためのもので、実際の変更実施には provider のツールやチームのレビューが必要です。

どのクラウドプロバイダーに対応しているか

このスキルは次を明示的にカバーしています。

• AWS
• Azure
• GCP
• OCI

そのため、単一クラウドでもマルチクラウドでも有用です。ただし、provider 固有の実装詳細を深掘りしたい場合は、追加のフォローアッププロンプトが必要になることがあります。

どんなときはcost-optimizationを使わないほうがよいか

次のようなニーズなら、このスキルは見送ったほうがよいです。

• 正確な請求照合
• 詳細な billing export の解析
• policy-as-code の強制
• 直接実行する remediation scripts
• 戦略分析なしで provider 固有の実装深度だけが必要な場合

こうした用途では、provider 標準の請求ツールや、より運用特化のスキルを使うほうが適しています。

一時的な削減だけでなく、継続的なガバナンスにも使えるか

はい。タグ標準の参照資料があるため、ownership、chargeback、レポーティング規律を含めた、再現可能なコスト統制の整備にも向いています。コストレビューを単発対応ではなく、日常のプラットフォーム運用に組み込みたいときに相性が良いです。

cost-optimizationスキルを改善する方法

実際の支出データと利用状況を渡す

cost-optimization の使い方を最も手早く改善する方法は、実データに基づくシグナルを渡すことです。

• コスト要因の上位10項目
• 低利用リソース
• storage の増加傾向
• アイドル環境
• 現在のコミットメント適用率
• タグの欠落やばらつき

このスキルは、渡した根拠の具体性以上には具体化できません。

すぐ効く施策と構造的な改善を分ける

エージェントには、提案を次のように分割させてください。

• 即時のクリーンアップ
• 料金 / コミットメントの見直し
• アーキテクチャ改善
• ガバナンス改善

この切り分けが大事なのは、これらのカテゴリでリスクも時間軸も異なるからです。混ぜてしまうと、優先順位付けが弱くなります。

変えられない条件を明示する

よくある失敗は、最初の出力で信頼性や性能を損ねる施策が提案されることです。次のようなハード制約を明記して防いでください。

• latency の悪化は不可
• HA posture の低下は不可
• freeze windows 中の変更は不可
• 不安定なワークロードに長期コミットメントは不可

これは、Performance Optimization のために cost-optimization を使うとき特に重要です。

精度を求める前にタグを整える

クラウド環境のタグが不統一だったり欠落していたりするなら、まずそこを解決させてください。参照ファイルでも、ownership とコスト帰属が土台であることが明確に示されています。タグの改善は、ダッシュボードからクリーンアップ対象の特定まで、後続のすべての提案精度を押し上げます。

アイデアの羅列ではなく、順位付き提案を求める

次のようなプロンプトが有効です。

Rank actions by savings potential, confidence, effort, and operational risk.

この一文は、「もっと詳しく」と頼むよりも、たいてい出力品質を改善します。広いブレインストーミングではなく、意思決定しやすい提案に変わるためです。

前提条件と不足データを出させる

強いフォローアップとしては、次の依頼がおすすめです。

List the assumptions behind each recommendation and what additional data would confirm or reject it.

これにより、次を切り分けやすくなります。

• 勝ち筋が濃い施策
• 推測ベースの提案
• 可観測性不足で判断保留の項目

環境全体ではなく、サービス単位で反復する

初回の結果が広すぎるなら、次のプロンプトでは対象を1領域に絞ってください。

• EC2 / VM fleets
• databases
• object storage
• Kubernetes
• data transfer
• non-production environments

cost-optimization スキルは、すべてを一度に最適化しようとするより、明確なコスト領域に絞ったほうが価値を出しやすいです。

現状と目指す運用モデルを比較させる

スキルには、次の両方を評価させると効果的です。

• 今すぐ削るべきもの
• 今後あるべきガバナンスプロセス

例:
Use the cost-optimization skill to identify immediate savings and propose a quarterly cost review process with tagging enforcement, budget alerts, and ownership reporting.

これにより、このスキルは単発のアドバイザーではなく、より良い運用モデルを設計する支援役になります。

ありがちな低品質出力を見逃さない

次のような返答なら、プロンプトを見直してください。

• 利用履歴がないのにコミットメントを勧める
• owner 確認なしで削除を提案する
• タグや可視化の不足を無視する
• dev と production を同列に扱う
• compute にしか触れず、storage や transfer コストを見落とす

こうした兆候は、モデルにもっと文脈が必要か、対象範囲の絞り込みが足りないサインです。

リポジトリの文脈を土台に、自社環境を重ねる

まずはリポジトリのフレームワークとタグ標準を使い、その上に実際の環境情報を重ねてください。それが cost-optimization スキルの価値を引き出す最善の方法です。内蔵された構造を分析のレンズとして使いながら、提案が実行可能になるだけの具体性をプロンプトに持たせましょう。