sustainability-optimization

サステナビリティ最適化の評価

ステップ 1：コンテキストの収集

ユーザーに次のように尋ねます。

サステナビリティの観点から評価したいワークロードを教えてください。以下の情報を共有してください。

• ワークロード名と、分析対象のコードパッケージ／ディレクトリ
• サステナビリティ目標（任意：組織のカーボン目標、レポート要件）
• 既知のアイドル期間（任意：営業時間外、週末、季節ごとのパターン）

すでにコンテキストが提供されている場合、またはコードベース内にいる場合は、直接次に進みます。

ステップ 2：コンピューティング効率の検出

コンピューティングリソースの設定を分析し、効率性を評価します。

必ず以下を調査してください。

• インスタンスタイプの選択（Graviton と x86。Graviton はワットあたりの価格性能比を最大 40％向上させます）
• オートスケーリングの設定（リソースをゼロまでスケールできますか？）
• Lambda の設定（メモリの適正化、arm64 と x86_64 のアーキテクチャ）
• コンテナの設定（ベースイメージのサイズ、マルチステージビルド、ランタイム効率）
• バッチ処理の設定（スケジューリング、インスタンスの選択）
• スケジュールされたスケーリング（非本番環境、営業時間外のキャパシティ）
• サーバーレスとプロビジョニング済みの選択肢（Lambda／Fargate と常時稼働の EC2）

各コンピューティングリソースについて、以下を記録してください。

• ファイルパスと行番号
• アーキテクチャ（arm64／x86_64）
• スケーリング設定（最小／最大、ゼロまでスケールできるか）
• 常時稼働か、イベント駆動型か

必ず以下を指摘してください。

• Graviton／arm64 が利用可能でサポートされているのに、x86_64 インスタンス／Lambda を使用している
• 変動するワークロードまたはイベント駆動型のワークロードで、常時稼働のコンピューティングを使用している（Lambda／Fargate ならゼロまでスケールできます）
• 本番環境と同じ規模で 24 時間 365 日稼働している非本番環境
• 明確なアイドル期間がある環境で、スケジュールされたスケーリングが設定されていない
• レイテンシが重要ではない Lambda にプロビジョニング済み同時実行数が設定されている
• マルチステージビルドまたは Distroless を利用できる大きなコンテナイメージ

ステップ 3：データとストレージ効率の検出

サステナビリティの観点から、データ管理を分析します。

必ず以下を調査してください。

• S3 のライフサイクルポリシー（より低コスト／高効率のストレージ階層への移行、有効期限）
• S3 Intelligent-Tiering の採用状況
• CloudWatch ログの保持設定
• データ圧縮の設定（S3、API レスポンス、データベース）
• バックアップ保持ポリシー（過剰な保持期間はストレージの無駄です）
• 古いバージョンに対するライフサイクルルールを伴う S3 バージョニング
• DynamoDB の TTL 設定
• スナップショットの保持とクリーンアップの自動化

各ストレージリソースについて、以下を記録してください。

• ファイルパスと行番号
• ライフサイクルポリシー（あり／なし）
• 保持設定
• 圧縮設定
• アクセスパターンとの整合性

必ず以下を指摘してください。

• ライフサイクルポリシーがない S3 バケット（データが無期限に蓄積されます）
• 保持期間が「無期限」の CloudWatch ログ
• 時間的なデータを含む DynamoDB テーブルに TTL がない
• 圧縮が可能なのに、データが非圧縮で保存されている
• コンプライアンス上の正当な理由がないのに、バックアップの保持期間が 90 日を超えている
• バージョンの有効期限ルールがない S3 バージョニング
• アクセスパターンが不明なバケットに Intelligent-Tiering がない

ステップ 4：アーキテクチャ効率の検出

サステナビリティの観点から、アーキテクチャのパターンを分析します。

必ず以下を調査してください。

• マネージドサービスの利用とセルフマネージドの比較（MSK とセルフマネージド Kafka、ElastiCache とセルフマネージド Redis）
• イベント駆動型とポーリングのパターン
• バッチ処理とリアルタイム処理（操作をバッチ化できるか）
• キャッシュレイヤー（重複計算の削減）
• データ転送のパターン（データの近くで処理し、リージョン間／AZ 間の転送を最小限にする）
• API 設計の効率性（過剰なデータ取得、チャット性の高い API）
• 時間的制約のない処理に対する非同期処理

必ず以下を指摘してください。

• マネージドな代替手段があるのに、セルフマネージドのインフラを使用している（大規模利用時のリソース利用率が高くなります）
• イベント駆動型にすればアイドル状態のコンピューティングを削減できるのに、ポーリングのパターンを使用している
• バッチ操作があるのに、個別の API 呼び出しを行っている
• キャッシュがないため、計算が重複している
• チャット性の高い API により、過剰なネットワーク往復が発生している

ステップ 5：開発とデプロイの効率性

CI/CD と開発手法を分析し、持続可能性を評価します。

必ず確認してください：

• コンテナイメージの最適化（マルチステージビルド、レイヤーキャッシュ、イメージサイズ）
• CI/CD パイプラインの効率性（キャッシュ、インクリメンタルビルド、並列実行）
• アーティファクト管理（保持、クリーンアップ）
• テスト環境のライフサイクル（自動ティアダウン、TTL）
• デプロイ戦略の効率性（テスト用の最小限のロールアウト）

必ず指摘してください：

• マルチステージビルドを使用していない大容量の Docker イメージ
• CI/CD パイプラインにキャッシュがなく、毎回すべてを再ビルドしていること
• 自動ティアダウンされないテスト環境
• インクリメンタルデプロイで対応できるにもかかわらず、全体を再デプロイしていること

ステップ 6：リージョンとハードウェアの効率性

リージョンとハードウェアの選択を分析します。

必ず確認してください：

• リージョンの選択（炭素強度はリージョンによって異なります）
• すべてのリソースタイプにおける Graviton の採用状況
• インスタンス世代（古い世代は処理あたりの効率が低くなります）
• ストレージ階層の選択効率

必ず指摘してください：

• 古い世代のインスタンス（例：m7g ではなく m4、t4g ではなく t2）
• ワークロードのランタイムが Graviton／ARM に対応しているにもかかわらず x86 を選択していること
• レイテンシー上の正当な理由がない高炭素排出リージョンのリソース

---STOP--- チェックポイント：調査完了 — WA Framework に基づく評価の準備ができました

コンピューティング効率（{X} 個のリソース、うち {Y} 個が Graviton／arm64 を使用）、データ／ストレージのライフサイクル設定、アーキテクチャ効率のパターン、開発／デプロイの手法、および {packages analyzed} 全体のリージョン／ハードウェアの選択を調査しました。

これらの調査結果を WA Sustainability の柱に関する質問に照らして評価し、影響度を判定してもよろしいですか？

ユーザーが明示的に確認するまで、この時点より先に進まないでください。

ステップ 7：WA Framework の質問に基づく評価

各質問について、ステータス、根拠（ファイル：行）、不足事項、リスクを提示してください。

SUS 1 — 持続可能性の目標を支えるため、どのようにリージョンを選択していますか？

• 根拠：リージョン設定、リージョン選択の根拠に関するドキュメント

SUS 2 — ユーザーの行動パターンをどのように活用していますか？

• 根拠：スケール・トゥ・ゼロ設定、スケジュールされたスケーリング、イベント駆動型アーキテクチャのパターン

SUS 3 — ソフトウェアおよびアーキテクチャのパターンをどのように活用していますか？

• 根拠：マネージドサービス、非同期処理、バッチ処理、キャッシュレイヤー

SUS 4 — データのアクセスおよび使用パターンをどのように活用していますか？

• 根拠：ライフサイクルポリシー、圧縮、階層化、Intelligent-Tiering、TTL 設定

SUS 5 — ハードウェアの管理および使用パターンは、持続可能性の目標をどのように支えていますか？

• 根拠：Graviton／arm64 の使用状況、インスタンス世代、適正なサイジング、マネージドサービス

SUS 6 — 開発およびデプロイのプロセスは、持続可能性の目標をどのように支えていますか？

• 根拠：Docker のマルチステージビルド、CI のキャッシュ、インクリメンタルデプロイ、アーティファクトのクリーンアップ

ステップ 8：影響の評価

各調査結果について、次のように評価してください：

リソースへの影響：低（効率性の向上は小さい）｜中（リソースを大幅に削減）｜高（リソースを大幅に削減、または効率性を大幅に改善）

実装の労力：低（設定変更）｜中（多少の開発が必要）｜高（アーキテクチャの変更）

優先順位は、影響度／労力比（高いものから順）に基づいてください。

ステップ 9：調査結果を作成

# Sustainability Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Findings**: {X} High Impact, {Y} Medium Impact, {Z} Low Impact
- **Overall Sustainability Maturity**: {1-5} — {one-line justification}
- **Key Opportunities**: {top 3 highest-impact changes}

## Sustainability Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Compute Efficiency | {score} | {strength} | {gap} |
| Data & Storage | {score} | {strength} | {gap} |
| Architecture Efficiency | {score} | {strength} | {gap} |
| Development & Deployment | {score} | {strength} | {gap} |
| Hardware & Region | {score} | {strength} | {gap} |

## High Impact Findings
{For each: ID, domain, title, description, evidence (file:line), resource impact, recommendation, effort, AWS services}

## Medium Impact Findings
{Same format, condensed}

## Low Impact Findings
{Summary table: ID | Domain | Title | Recommendation}

## Resource Efficiency Opportunities
| Resource | Current Config | Optimized Config | Efficiency Gain | Evidence |
|----------|---------------|-----------------|-----------------|----------|
| {resource} | {current} | {optimized} | {gain description} | {file:line} |

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Resource Impact | Effort |
|---------|--------|----------------|--------|
{Set log retention, add lifecycle policies, enable Intelligent-Tiering, schedule non-prod}

### Foundation (1-4 weeks)
| Finding | Action | Resource Impact | Effort | Dependencies |
|---------|--------|----------------|--------|--------------|
{Graviton migration, right-sizing, scale-to-zero, multi-stage Docker builds}

### Strategic (1-3 months)
| Finding | Action | Resource Impact | Effort | Dependencies |
|---------|--------|----------------|--------|--------------|
{Serverless migration, managed service adoption, event-driven architecture, region optimization}

## AWS Sustainability Tools
- **Customer Carbon Footprint Tool** — Track emissions in the AWS console
- **Compute Optimizer** — Right-size recommendations with Graviton suggestions
- **S3 Storage Lens** — Storage efficiency and access pattern insights
- **Trusted Advisor** — Idle resource detection

## Next Steps
{Top 5 concrete sustainability actions the team should take this week}

ステップ 10：フォローアップを提案

評価を提示した後、次のことを提案してください：

次のことを行いましょうか？

• 特定したリソース向けに Graviton 移行用の IaC を生成する
• 非本番環境向けのスケール・トゥ・ゼロ戦略を設計する
• 特定したバケット向けに S3 ライフサイクルポリシーを実装する
• コンテナイメージ向けに Docker のマルチステージビルドを作成する
• ポーリング方式を置き換えるイベント駆動型アーキテクチャを設計する
• オフピーク時に容量を削減するスケジュール済みスケーリングを実装する

キャリブレーションの指針

• Graviton、サーバーレス、ライフサイクルポリシー、マネージドサービスを活用しているワークロードは成熟しています。高度な効率化（データローカリティ、バッチ集約、開発プラクティス）に重点を置いてください。
• すべての指摘にはコードによる根拠が必要です。IaCを確認せずに「ライフサイクルポリシーがない」と指摘しないでください。
• サステナビリティに関する指摘は、否定的ではなく、リソース効率の向上という前向きな観点で表現してください。
• サステナビリティの改善によってコストも削減できる場合は、常にその相乗効果を明記してください。
• CloudWatch メトリクスが必要な利用状況データについては、「判断できません」も妥当な回答です（Compute Optimizer を推奨してください）。
• レイテンシ要件とデータレジデンシーを考慮せずに、リージョンの変更を推奨しないでください。
• 不足点を挙げる前に、すでに実施されているサステナビリティの取り組みを認めてください。