導入
SAPのドメイン3は「既存システムの継続的な改善」です。改善するには、まず「今の設計のどこが弱いか」を体系的に評価する必要があります。その共通のものさしが Well-Architected フレームワークです。
説明
AWS Well-Architected フレームワーク は、クラウド設計のベストプラクティスを 6つの柱（Pillars） に整理したものです。SAAでも登場しますが、SAPでは「新規設計の指針」だけでなく「既存システムを評価し、リスクを洗い出す道具」として使います。
| 柱 | プロレベルでの問い |
|---|---|
| 運用上の優秀性 | 変更・障害対応を自動化し、観測できているか |
| セキュリティ | 組織全体で最小権限・暗号化・監査を徹底できているか |
| 信頼性 | 目標のRTO/RPOを満たすDRを設計できているか |
| パフォーマンス効率 | 適切なサービスへ継続的に見直せているか |
| コスト最適化 | 使っていないリソース・過剰なサイズを削れているか |
| 持続可能性 | リソース効率を上げ環境負荷を下げられているか |
実務では AWS Well-Architected Tool（無料）でワークロードを6本柱の観点でレビューし、高／中リスクの項目を洗い出して改善計画に落とします。SAPの「既存改善」系の問題は、まさにこの「リスクを見つけて、最小の労力で直す」流れそのものです。
flowchart LR
W["既存ワークロード"] --> R["Well-Architected Review<br/>6本柱で評価"]
R --> H["高リスク項目を特定"]
H --> F["優先度をつけて改善"]
F --> W
具体例
3年前に作られ、その後ほぼ手つかずのECシステムを、Well-Architected Toolでレビューしたと想像しましょう。6本柱で点検すると、リスクが浮かび上がります。
| 柱 | 見つかった高/中リスク | 最小労力の改善 |
|---|---|---|
| 信頼性 | DBが単一AZ（高） | RDSをMulti-AZ化（設定変更で対応可） |
| セキュリティ | S3バケットに公開設定が残存（高） | パブリックアクセスブロック＋Config監視 |
| コスト最適化 | 常時起動の巨大インスタンス（中） | Compute Optimizerの提案でライトサイジング |
| 運用上の優秀性 | 障害検知の仕組みなし（中） | CloudWatchアラート＋通知を追加 |
プロの改善はここからが肝心です。全部を一度に作り直さない。まず「S3公開」と「DB単一AZ」という高リスクを、影響の小さい変更で先に潰す。大改修は後回し。SAPのドメイン3（既存改善）は、まさにこの「リスクを見つけ、優先度順に、最小の労力で直す」ループを問います。「一度に完璧を目指さない」感覚が、プロの設計思考です。
読んでみよう
プロフェッショナルは「作って終わり」ではなく「回し続ける」役割です。Well-Architected Review を定期的に行い、リスクを見つけて直す 改善のループ を回すのがドメイン3の本質です。「一度に完璧を目指さず、リスクの高い順に、影響の小さい変更で直す」という感覚を覚えておいてください。