目次

AWS Well-Architected Tool 完全ガイド v2.0

ワークロード評価・アーキテクチャレビュー・改善計画基盤

AWS Well-Architected Tool は、「Well-Architected Framework の 6 つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）に基づいてワークロードを体系的に評価し、リスク（HIGH / MEDIUM / LOW / NONE）を分類・改善推奨事項を提供する無料ツール」 です。質問票形式の評価、マイルストーン機能による改善進捗トラッキング、AWS パートナー・ソリューションアーキテクトとの共同レビュー（WA Review）、カスタムレンズでの業種・技術特化評価を実現。本ドキュメントは Well-Architected Tool の概念・6 つの柱・Lens・改善計画・2025-2026 最新動向を体系的に解説する包括的ガイドです。

ドキュメント目的

本ガイドは以下を対象としています。

  • 初心者向け： Well-Architected Tool とは何か、ワークロード評価の始め方を学びたい方
  • アーキテクト向け： アーキテクチャ設計のベストプラクティス適用、リスク評価
  • 開発チーム向け： ワークロードの技術的負債を体系的に把握
  • セキュリティ / コンプライアンス向け： セキュリティ・信頼性リスクの特定
  • CTO / 意思決定者向け： 技術投資優先順位の判定、改善ROI計算

2025-2026 年の AWS Well-Architected Tool エコシステム

  • Responsible AI Lens 追加：倫理的・安全な AI システム構築ガイドライン
  • GenAI Lens 拡張：大規模言語モデル・生成 AI ワークロード評価
  • ML Lens アップデート：機械学習ライフサイクル全段階のカバー
  • Sustainability Lens 強化：カーボンフットプリント・電力効率評価
  • IoT / HPC / Hybrid Network Lens：特化領域の評価
  • 自動 AI サジェスチョン：メトリクスから改善提案の自動生成
  • レビュアーマッチング：AWS パートナーとの自動マッチング
  • CloudFormation フック統合：デプロイ前のコンプライアンスチェック

目次

  1. 概要
  2. Well-Architected Tool が解決する課題
  3. 主な特徴
  4. Well-Architected Framework の 6 つの柱
  5. ワークロード登録・レビュー開始
  6. 運用上の優秀性（Operational Excellence）
  7. セキュリティ（Security）
  8. 信頼性（Reliability）
  9. パフォーマンス効率（Performance Efficiency）
  10. コスト最適化（Cost Optimization）
  11. 持続可能性（Sustainability）
  12. Lens（レンズ）詳解
  13. カスタムレンズの作成
  14. 改善計画（Improvement Plan）
  15. マイルストーン・進捗トラッキング
  16. Well-Architected Review（WA Review）
  17. 設定・操作の具体例
  18. CLI / SDK / IaC
  19. Trusted Advisor との比較
  20. 類似ツール比較
  21. ベストプラクティス
  22. トラブルシューティング
  23. 2025-2026 最新動向
  24. 学習リソース・参考文献
  25. 実装例・活用シーン
  26. 評価チェックリスト
  27. まとめ
  28. 参考文献

概要

初心者向けメモ： Well-Architected Tool は「AWS アーキテクチャのベストプラクティス診断ツール」です。テストに合格・不合格はなく、現在の設計が 6 つの柱（運用・セキュリティ・信頼性等）でどのレベルにあるかを「質問票 → リスク判定 → 改善推奨」というプロセスで明確化します。Trusted Advisor が既存リソース設定をチェックするのに対し、Well-Architected Tool はアーキテクチャ設計の判断を人間が回答することで評価するため、設計段階や再構築段階での活用に最適です。

AWS Well-Architected Tool 公式定義：

「Well-Architected Framework の 6 つの柱に基づいてワークロードを評価し、改善推奨事項とベストプラクティスドキュメントを提供する無料ツール」

参照：AWS Well-Architected Tool

Well-Architected Tool が解決する課題

課題 1：アーキテクチャの良悪を定量的に把握できない

❌ 従来の方法

  • レビュアー（アーキテクト）の主観で「よいデザイン」「悪いデザイン」を判定
  • 複数レビュアーの判定基準が異なる
  • 改善すべき項目の優先順位が不明確

✅ Well-Architected Tool 活用

質問票（40～50問）に回答
  ↓
自動的にリスク判定（HIGH / MEDIUM / LOW / NONE）
  ↓
改善推奨事項とベストプラクティスドキュメント提示
  ↓
改善計画（Improvement Plan）を自動生成

課題 2：複数チーム・複数ワークロードの評価が大変

大企業でワークロード数が数十～数百個の場合、各々を個別に評価するのは効率が悪い。Well-Architected Tool で統一的に評価。

課題 3：改善進捗の定量化ができない

改善を進めても「進捗度」が見えない。Well-Architected Tool のマイルストーン機能で、定期レビュー時の「前回 vs 今回」のリスク比較が可能。

課題 4：業種・技術ごとのベストプラクティスが異なる

金融・医療・SaaS など業種別、Serverless / ML / IoT など技術別にベストプラクティスが異なる。Well-Architected Lens で特化評価。

主な特徴

特徴 詳細
6 つの柱 運用・セキュリティ・信頼性・パフォーマンス・コスト・持続可能性
リスク分類 HIGH / MEDIUM / LOW / NONE
質問票形式 40～50 問（Lens ごとに異なる）
改善推奨事項 各リスクに対する具体的な改善案とドキュメントリンク
Lens（特化評価） Serverless / SaaS / ML / IoT / HPC / Hybrid Network / Sustainability / GenAI / Responsible AI 等
カスタムレンズ 組織独自のベストプラクティスを追加評価
マイルストーン 定期レビューで改善進捗をトラッキング
WA Review AWS ソリューションアーキテクト / パートナーとの共同レビュー
無料サービス レビュー・改善計画生成・Lens 利用が全て無料
API / CLI 対応 プログラマティックなレビュー・統計分析可能

Well-Architected Framework の 6 つの柱

柱 1：運用上の優秀性（Operational Excellence）

定義：運用をコードとして管理し、小さく頻繁な変更を自動化・監視する能力。

主要評価項目：

  • [ ] インフラをコードとして管理しているか（Infrastructure as Code）
  • [ ] 変更管理・デプロイメントプロセスが自動化されているか
  • [ ] 予測可能な失敗の対応手順書があるか（Runbook）
  • [ ] インシデント対応プロセスが定義・自動化されているか
  • [ ] リソース・ワークロードの監視・アラート設定があるか

リスク例：

  • 🔴 HIGH：手動でリソース管理、デプロイメント手順書が紙資料
  • 🟡 MEDIUM：一部自動化されているが、全体では手動作業が大部分
  • 🟢 LOW：CI/CD パイプライン完全自動化、監視・アラート充実

柱 2：セキュリティ（Security）

定義：強力な認証・認可、データ暗号化、脅威検出・対応能力、アクセス制御を実装。

主要評価項目：

  • [ ] IAM で最小権限アクセス（Least Privilege）を実装しているか
  • [ ] MFA（多要素認証）が有効化されているか
  • [ ] データの転送中・保存時の暗号化があるか
  • [ ] ネットワーク隔離（VPC / Security Group）が適切か
  • [ ] セキュリティイベントの検出・対応プロセスがあるか

リスク例：

  • 🔴 HIGH：Root アカウント日常使用、パスワード管理なし、暗号化なし
  • 🟡 MEDIUM：IAM 使用だが権限が過度、一部リソースの暗号化
  • 🟢 LOW：最小権限 IAM、MFA、全データ暗号化、定期脅威検出

柱 3：信頼性（Reliability）

定義：計画通りの正確性、障害からの自動回復、スケーラビリティ。

主要評価項目：

  • [ ] RTO / RPO（目標復旧時間・目標復旧期間）が定義されているか
  • [ ] 複数 AZ・リージョンでの冗長化があるか
  • [ ] 自動フェイルオーバー・スケーリング機能があるか
  • [ ] 定期バックアップ・復旧テストが実施されているか
  • [ ] リソース容量が適切に計画・監視されているか

リスク例：

  • 🔴 HIGH：シングル AZ、バックアップなし、手動スケーリング
  • 🟡 MEDIUM：複数 AZ だがフェイルオーバーが手動、バックアップは存在
  • 🟢 LOW：マルチ AZ / マルチリージョン、自動フェイルオーバー、定期復旧テスト

柱 4：パフォーマンス効率（Performance Efficiency）

定義：適切なリソースタイプ・サイズの選択、監視・チューニングで最適パフォーマンスを実現。

主要評価項目：

  • [ ] 適切なリソースタイプ（インスタンス / DB エディション）を選択しているか
  • [ ] キャッシング（ElastiCache / CloudFront）を活用しているか
  • [ ] アプリケーション・インフラの定期的なパフォーマンステストがあるか
  • [ ] メトリクス（レイテンシ / スループット）を監視・最適化しているか
  • [ ] サーバーレス・マネージドサービスを活用しているか

リスク例：

  • 🔴 HIGH：過度にスペックの高いインスタンス、キャッシュなし、監視なし
  • 🟡 MEDIUM：適切なインスタンスサイズだが、キャッシュは部分的
  • 🟢 LOW：ワークロード特性に合わせたリソース、キャッシュ充実、継続的監視

柱 5：コスト最適化（Cost Optimization）

定義：支出効率化、不要リソース削除、適切な購買戦略（RI / Savings Plans）の実施。

主要評価項目：

  • [ ] 未使用リソース（停止 EC2 / 古い Snapshot 等）が削除されているか
  • [ ] RI（Reserved Instance）や Savings Plans を活用しているか
  • [ ] ストレージの段階的削除（S3 ライフサイクルポリシー）があるか
  • [ ] AWS Cost Explorer で支出を定期分析しているか
  • [ ] サーバーレス（Lambda / DynamoDB on-demand）の導入検討がされているか

リスク例：

  • 🔴 HIGH：不要なリソースが多数放置、オンデマンド料金のみ、予算監視なし
  • 🟡 MEDIUM：基本的なコスト最適化は実施、一部RI 導入
  • 🟢 LOW：RI / Savings Plans 最大活用、定期的な支出分析、不要リソース自動削除

柱 6：持続可能性（Sustainability）

定義：環境への影響を最小化、エネルギー効率・カーボンニュートラルな設計。

主要評価項目：

  • [ ] サーバーレス / マネージドサービスを優先しているか（物理サーバー削減）
  • [ ] リソースの使用率を最大化しているか（遊休キャパシティ削減）
  • [ ] 効率的なアルゴリズム・アーキテクチャを採用しているか
  • [ ] クラウドの地理的配置（リージョン）を最適化しているか
  • [ ] 電力効率の高いインスタンスタイプを選択しているか

リスク例：

  • 🔴 HIGH：物理サーバー運用、常時フルスペック稼働、効率的でない実装
  • 🟡 MEDIUM：一部マネージドサービス、定期的な使用率監視
  • 🟢 LOW：Serverless 優先、使用率監視による自動スケーリング、高効率実装

ワークロード登録・レビュー開始

ワークロード登録の手順

# AWS CLI でワークロード作成
aws wellarchitected create-workload \
  --workload-name "E-Commerce Platform" \
  --description "Online retail e-commerce system with multiple microservices" \
  --environment PRODUCTION \
  --aws-regions ap-northeast-1 us-east-1 \
  --lenses wellarchitected \
  --review-template-arn arn:aws:wellarchitected:ap-northeast-1:123456789012:template/custom-template \
  --tags Environment=Production,Team=Platform

# レスポンス
{
  "Workload": {
    "WorkloadId": "arn:aws:wellarchitected:ap-northeast-1:123456789012:workload/...",
    "WorkloadName": "E-Commerce Platform",
    "CreatedAt": "2024-04-26T10:00:00Z"
  }
}

ワークロード属性

{
  "WorkloadName": "ワークロード名",
  "Description": "ワークロード説明",
  "Environment": "PRODUCTION / PREPRODUCTION / STAGING / DEVELOPMENT",
  "AwsRegions": ["ap-northeast-1", "us-east-1"],
  "Lenses": ["wellarchitected", "serverless", "saas"],
  "ReviewTemplate": "カスタムレンズ ARN（オプション）",
  "Applications": ["app-1", "app-2"],
  "IndustryType": "Financial Services / Healthcare / Media & Entertainment 等",
  "IndustryTypeOther": "カスタム業種",
  "IsReviewTemplatePersonalized": true / false
}

運用上の優秀性（Operational Excellence）

評価質問票の例

Q1. インフラはコードで管理されているか
    a) すべてコード化している（IaC）→ Low Risk
    b) 一部コード化、一部手動 → Medium Risk
    c) ほとんど手動管理 → High Risk

Q2. デプロイメントプロセスは自動化されているか
    a) 完全自動化（CI/CD）→ Low Risk
    b) 一部自動化 → Medium Risk
    c) 手動 → High Risk

Q3. インシデント対応手順書（Runbook）が整備されているか
    a) 詳細な手順書あり、実装されている → Low Risk
    b) 簡易的な手順書のみ → Medium Risk
    c) 手順書がない → High Risk

Q4. リソース・ワークロード監視が実装されているか
    a) 包括的な監視・アラート → Low Risk
    b) 一部リソースのみ監視 → Medium Risk
    c) 監視なし → High Risk

Q5. 定期的にオペレーション効率を見直しているか
    a) 月次以上の定期見直し → Low Risk
    b) 年次程度 → Medium Risk
    c) 見直し実施なし → High Risk

改善推奨事項の例

【HIGH リスク】手動デプロイメント
推奨事項：
  1. CodePipeline / CodeDeploy で CI/CD パイプラン構築
  2. Infrastructure as Code（CloudFormation / CDK / Terraform）導入
  3. 自動テスト（ユニット / 統合 / スモーク）を実装
  4. Blue-Green デプロイメント で無停止更新実現
  
参考資料：
  - AWS CodePipeline ベストプラクティス
  - Infrastructure as Code 設計パターン

セキュリティ（Security）

評価質問票の例

Q1. IAM で最小権限アクセスを実装しているか
    a) 最小権限ベースの IAM ポリシー → Low Risk
    b) 部分的に最小権限実装 → Medium Risk
    c) 管理者権限を多用 → High Risk

Q2. MFA（多要素認証）が有効化されているか
    a) 全ユーザーで MFA 必須 → Low Risk
    b) 一部ユーザーのみ MFA → Medium Risk
    c) MFA 未導入 → High Risk

Q3. データの暗号化実装状況
    a) 転送中・保存時の両方で暗号化 → Low Risk
    b) 保存時のみ暗号化 → Medium Risk
    c) 暗号化なし → High Risk

Q4. ネットワークセキュリティ（VPC / NACLs）
    a) 多層防御（VPC / Security Group / NACL） → Low Risk
    b) 基本的な隔離のみ → Medium Risk
    c) セキュリティグループなし → High Risk

Q5. セキュリティイベント検出・対応体制
    a) 自動検出・対応プロセス（GuardDuty / Security Hub） → Low Risk
    b) 手動監視のみ → Medium Risk
    c) 検出・対応体制なし → High Risk

改善推奨事項の例

【HIGH リスク】IAM で管理者権限を過度に付与
推奨事項：
  1. IAM Policy を最小権限に設定
  2. IAM Identity Center で一元認証・权限管理
  3. Permission Boundary で権限の上限を設定
  4. Temporary Security Credentials（STS）の使用
  5. 定期的な IAM アクセス分析（Access Analyzer）
  
参考資料：
  - AWS IAM Best Practices
  - Security Pillar - Well-Architected Framework

信頼性（Reliability）

評価質問票の例

Q1. RTO / RPO（目標復旧時間・期間）が定義されているか
    a) ワークロード特性に応じて定義・実装 → Low Risk
    b) 定義はあるが実装が部分的 → Medium Risk
    c) 定義なし → High Risk

Q2. マルチ AZ / 冗長化が実装されているか
    a) 複数 AZ / リージョンで冗長化 → Low Risk
    b) 複数 AZ のみ → Medium Risk
    c) シングル AZ → High Risk

Q3. 自動フェイルオーバー機能
    a) 自動フェイルオーバー実装 → Low Risk
    b) 手動フェイルオーバープロセス → Medium Risk
    c) フェイルオーバー対応なし → High Risk

Q4. バックアップ・復旧テスト
    a) 定期的なバックアップ + 定期復旧テスト → Low Risk
    b) バックアップはあるが復旧テストなし → Medium Risk
    c) バックアップなし → High Risk

Q5. 容量計画・スケーリング
    a) 自動スケーリング + 容量計画 → Low Risk
    b) 手動スケーリング + 定期的な見直し → Medium Risk
    c) スケーリング対応なし → High Risk

パフォーマンス効率（Performance Efficiency）

評価質問票の例

Q1. リソースタイプの選択
    a) ワークロード特性に応じた最適なタイプ → Low Risk
    b) 標準的なタイプを使用 → Medium Risk
    c) スペック過剰・不足なタイプ → High Risk

Q2. キャッシング活用（ElastiCache / CloudFront）
    a) 適切にキャッシュ導入 → Low Risk
    b) 一部キャッシュ導入 → Medium Risk
    c) キャッシュなし → High Risk

Q3. パフォーマンステスト実施
    a) 定期的な負荷テスト・スケーリング検証 → Low Risk
    b) 年次程度のテスト → Medium Risk
    c) テスト実施なし → High Risk

Q4. サーバーレス / マネージドサービス利用
    a) 積極的に活用（Lambda / DynamoDB 等） → Low Risk
    b) 一部利用 → Medium Risk
    c) 自己管理リソースのみ → High Risk

Q5. パフォーマンスメトリクス監視
    a) 継続的な監視・最適化 → Low Risk
    b) 月次程度の確認 → Medium Risk
    c) 監視なし → High Risk

コスト最適化（Cost Optimization）

評価質問票の例

Q1. 未使用リソースの管理
    a) 定期的に削除（Trusted Advisor / Config） → Low Risk
    b) 手動で定期確認 → Medium Risk
    c) 放置されている → High Risk

Q2. RI / Savings Plans 活用
    a) 費用対効果に応じて最大活用 → Low Risk
    b) 一部のみ利用 → Medium Risk
    c) 利用していない → High Risk

Q3. ストレージのコスト最適化
    a) ライフサイクルポリシー（S3 Glacier 等）を実装 → Low Risk
    b) 基本的なポリシーのみ → Medium Risk
    c) ポリシーなし → High Risk

Q4. データ転送コストの最適化
    a) CloudFront / VPC Endpoint を活用 → Low Risk
    b) 基本的な最適化のみ → Medium Risk
    c) 最適化なし → High Risk

Q5. 予算管理・アラート
    a) AWS Budgets で予算上限設定・アラート → Low Risk
    b) 月次での確認 → Medium Risk
    c) コスト監視なし → High Risk

持続可能性（Sustainability）

評価質問票の例

Q1. Serverless / マネージドサービス利用
    a) 優先的に活用（Lambda / DynamoDB 等） → Low Risk
    b) 一部利用 → Medium Risk
    c) EC2 等自己管理リソース中心 → High Risk

Q2. リソース使用率の最大化
    a) Auto Scaling で遊休キャパシティ削減 → Low Risk
    b) 定期的に監視 → Medium Risk
    c) 監視なし → High Risk

Q3. アルゴリズム・実装効率
    a) 効率的なアルゴリズム・実装 → Low Risk
    b) 基本的には効率的 → Medium Risk
    c) 効率性を考慮していない → High Risk

Q4. リージョン選択
    a) 低炭素リージョン優先、レイテンシバランス → Low Risk
    b) パフォーマンス中心 → Medium Risk
    c) 電力効率未考慮 → High Risk

Q5. インスタンスタイプの選択
    a) Graviton2 など低電力タイプを活用 → Low Risk
    b) 標準タイプを使用 → Medium Risk
    c) 消費電力未考慮 → High Risk

Lens（レンズ）詳解

Well-Architected Framework には複数の Lens があり、業種・技術ごとに特化評価。

AWS 提供 Lens

1. Serverless Applications Lens

Lambda / DynamoDB / API Gateway 等のサーバーレスワークロード評価。

aws wellarchitected create-workload \
  --workload-name "Serverless API" \
  --lenses serverless

2. SaaS Lens

マルチテナント SaaS アプリケーションの評価。テナント隔離、テナント一元化、カスタマイズ等のベストプラクティス。

aws wellarchitected create-workload \
  --workload-name "SaaS Platform" \
  --lenses saas

3. Data Analytics Lens

Athena / Glue / Redshift 等のデータ分析ワークロード評価。

4. Machine Learning Lens

SageMaker 等の機械学習ワークロード。2025 年にアップデート予定。

5. Generative AI Lens（2024 新規）

Bedrock / Claude 等を使用した生成 AI アプリケーション評価。

6. Responsible AI Lens（2025 新規）

倫理的・安全な AI システム構築ガイドライン。

7. IoT Lens

IoT ワークロードの信頼性・パフォーマンス・セキュリティ評価。

8. Hybrid Networking Lens

オンプレミス・AWS ハイブリッド環境の評価。

9. Sustainability Lens

カーボンニュートラル・電力効率重視の評価。

10. HPC Lens

High Performance Computing ワークロード（シミュレーション・科学計算）評価。

11. Financial Services Lens

金融機関向けのコンプライアンス・規制要件。

カスタムレンズの作成

組織独自のベストプラクティスを Lens として定義可能。

カスタムレンズの構造

{
  "Name": "Company Internal Standards",
  "Description": "Custom lens for internal compliance and architectural standards",
  "Pillars": [
    {
      "Name": "Company Security",
      "Description": "Internal security standards",
      "Questions": [
        {
          "QuestionId": "company-sec-001",
          "QuestionTitle": "Are all databases encrypted with company-approved KMS keys?",
          "Description": "Ensure database encryption uses company KMS, not AWS managed keys",
          "AnswerChoices": [
            {
              "ChoiceId": "choice-1",
              "Description": "Yes, all databases use company KMS",
              "ImpliedImpact": "No impact"
            },
            {
              "ChoiceId": "choice-2",
              "Description": "Some databases use company KMS",
              "ImpliedImpact": "Partial implementation"
            },
            {
              "ChoiceId": "choice-3",
              "Description": "No, using default AWS encryption",
              "ImpliedImpact": "Does not meet requirements"
            }
          ]
        }
      ]
    }
  ]
}

カスタムレンズの登録

# カスタムレンズ JSON をアップロード
aws wellarchitected create-lens-version \
  --lens-body file://custom-lens.json \
  --lens-type CUSTOM_SELF

# カスタムレンズでワークロード評価
aws wellarchitected create-workload \
  --workload-name "Internal Project" \
  --lenses arn:aws:wellarchitected:ap-northeast-1:123456789012:lens/custom/...

改善計画（Improvement Plan）

リスク判定後、自動的に改善推奨事項と改善計画が生成。

改善計画の構成

{
  "ImprovementPlanItems": [
    {
      "ImprovementPlanId": "ip-001",
      "Risk": "HIGH",
      "Pillar": "Security",
      "Question": "IAM 最小権限アクセスの実装",
      "Recommendation": "IAM Policy を最小権限設定に見直す",
      "RelevantChoices": [
        {
          "ChoiceId": "choice-iam-001",
          "Description": "すべての権限を最小権限で定義"
        }
      ],
      "ResourceUrls": [
        "https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html"
      ],
      "EstimatedTimeToImplement": "2-4 weeks",
      "Priority": "HIGH",
      "MilestoneId": "milestone-1"
    }
  ]
}

マイルストーン・進捗トラッキング

定期的にレビューを実施し、前回との比較で改善進捗を可視化。

マイルストーン作成

# マイルストーン作成（定期レビュー用）
aws wellarchitected create-milestone \
  --workload-id arn:aws:wellarchitected:ap-northeast-1:123456789012:workload/... \
  --milestone-name "Q1 2024 Security Review" \
  --milestone-number 1

# レスポンス
{
  "Milestone": {
    "MilestoneNumber": 1,
    "MilestoneName": "Q1 2024 Security Review",
    "RecordedAt": "2024-04-26T10:00:00Z"
  }
}

マイルストーン比較

# 異なるマイルストーン間のリスク比較
aws wellarchitected get-milestone \
  --workload-id workload-id \
  --milestone-number 1 \
  --query 'Milestone.RiskCounts'

# 出力例
{
  "HIGH": 5,
  "MEDIUM": 12,
  "LOW": 8,
  "NONE": 25
}

# 前回（Milestone 0）との比較
# Milestone 0：HIGH 10 → Milestone 1：HIGH 5（改善 5 項目）

Well-Architected Review（WA Review）

AWS ソリューションアーキテクト / パートナーとの共同レビュー。

WA Review の流れ

1. 事前準備（1～2 週間）
   → ワークロード概要・前回レビュー内容をまとめる
   → AWS が レビュアー割り当て

2. レビュー実施（3～5 日間）
   → Well-Architected Tool 質問票への回答（2～3 時間）
   → AWS レビュアー による深掘り質疑（2～3 時間）
   → ホワイトボード検討（アーキテクチャ図作成等）

3. レポート作成（1 週間）
   → リスク分析・改善推奨
   → 優先度付け・実装ガイダンス

4. 実装・フォローアップ
   → 改善計画に基づいて実装
   → 3～6 ヶ月後に再レビュー

WA Review リクエスト

aws wellarchitected list-review-templates \
  --query 'ReviewTemplates[*]'

# レビュー実施申請（AWS Console から）
# https://console.aws.amazon.com/wellarchitected/

設定・操作の具体例

ワークロード作成から改善計画まで

#!/bin/bash

WORKLOAD_NAME="E-Commerce Platform"
ENVIRONMENT="PRODUCTION"
REGIONS="ap-northeast-1"

# 1. ワークロード作成
WORKLOAD_ID=$(aws wellarchitected create-workload \
  --workload-name "$WORKLOAD_NAME" \
  --description "Online e-commerce system with microservices" \
  --environment $ENVIRONMENT \
  --aws-regions $REGIONS \
  --lenses wellarchitected serverless \
  --query 'Workload.WorkloadId' \
  --output text)

echo "Created Workload: $WORKLOAD_ID"

# 2. リスク評価用質問票を取得
aws wellarchitected get-lens \
  --lens-alias wellarchitected \
  --query 'Lens.Pillars[*].Questions' \
  --output table

# 3. 質問に回答（スクリプト化）
# 例：セキュリティ柱の「IAM 最小権限」質問に "High Risk" で回答
aws wellarchitected update-answer \
  --workload-id $WORKLOAD_ID \
  --lens-alias wellarchitected \
  --pillar-id security \
  --question-id use-iam-policies \
  --selected-choices choice-1-high-risk \
  --note-update-status CREATE \
  --notes "Currently using overly broad IAM policies"

# 4. リスク結果を確認
aws wellarchitected list-answers \
  --workload-id $WORKLOAD_ID \
  --lens-alias wellarchitected \
  --pillar-id security \
  --query 'AnswerSummaries[?Risk==`HIGH`]'

# 5. マイルストーン作成（改善前のベースライン）
MILESTONE_ID=$(aws wellarchitected create-milestone \
  --workload-id $WORKLOAD_ID \
  --milestone-name "Initial Assessment" \
  --query 'Milestone.MilestoneNumber' \
  --output text)

echo "Created Milestone: $MILESTONE_ID"

# 6. 改善計画を取得
aws wellarchitected list-improvement-plans \
  --workload-id $WORKLOAD_ID \
  --query 'ImprovementPlanItems[*].{Risk: Risk, Pillar: Pillar, Recommendation: Recommendation}' \
  --output table

echo "Well-Architected Review Complete"

CLI / SDK / IaC

AWS Python SDK（boto3）での操作

import boto3

wellarchitected = boto3.client('wellarchitected')

# ワークロード作成
response = wellarchitected.create_workload(
    WorkloadName='Payment System',
    Description='Real-time payment processing',
    Environment='PRODUCTION',
    AwsRegions=['ap-northeast-1', 'us-east-1'],
    Lenses=['wellarchitected', 'financial-services']
)

workload_id = response['Workload']['WorkloadId']

# 質問に回答
wellarchitected.update_answer(
    WorkloadId=workload_id,
    LensAlias='wellarchitected',
    PillarId='security',
    QuestionId='use-mfa',
    SelectedChoices=['choice-1-yes-all-users'],
    Notes='MFA enforced for all users via IAM policy'
)

# リスク結果確認
risks = wellarchitected.list_answers(
    WorkloadId=workload_id,
    LensAlias='wellarchitected',
    PillarId='security'
)

for answer in risks['AnswerSummaries']:
    print(f"Q: {answer['QuestionTitle']}")
    print(f"Risk: {answer['Risk']}")
    print()

# マイルストーン作成
wellarchitected.create_milestone(
    WorkloadId=workload_id,
    MilestoneName='Q2 2024 Review'
)

# 改善計画取得
improvement_plans = wellarchitected.list_improvement_plans(
    WorkloadId=workload_id
)

for plan in improvement_plans['ImprovementPlanItems']:
    print(f"Risk: {plan['Risk']}")
    print(f"Recommendation: {plan['Recommendation']}")
    print()

Trusted Advisor との比較

観点 Well-Architected Tool Trusted Advisor
評価対象 アーキテクチャ設計 リソース設定
評価方法 質問票形式 自動チェック
リスク分類 HIGH / MEDIUM / LOW / NONE Critical / Warning / Recommendation
対象範囲 6 つの柱（全体的） セキュリティ・パフォーマンス・コスト等（限定的）
改善提案 具体的なベストプラクティス リソース単位の最適化
Lens 対応 ✅複数 Lens（Serverless / SaaS / ML 等） ❌なし
カスタマイズ ✅カスタムレンズ作成可能 ❌固定チェック
推奨使用場面 アーキテクチャ検証・再構築前 既存環境の設定最適化
料金 無料 Business / Enterprise Support に付属

類似ツール比較

ツール 対象 特徴 用途
Well-Architected Tool AWS アーキテクチャ 6 柱評価・改善計画 設計段階・定期レビュー
Trusted Advisor AWS リソース設定 自動チェック 既存リソースの最適化
AWS Config リソース・設定管理 コンプライアンス監視 継続的なコンプライアンス
Security Hub セキュリティ検出 統一セキュリティダッシュボード セキュリティ・脅威検出
CloudFormation Hooks テンプレート検証 デプロイ前コンプライアンス CI/CD 統合
Azure Advisor Azure リソース Azure ベストプラクティス Azure 環境最適化
Google Cloud’s Framework GCP アーキテクチャ 設計アセスメント GCP 環境評価

ベストプラクティス

✅ やるべきこと

  1. 新規ワークロード設計段階で評価を開始

    要件定義 → アーキテクチャ設計 → Well-Architected Review
→ 改善実装 → デプロイ

  2. 定期的なレビュー（6 ヶ月～年次）

    Milestone で改善進捗をトラッキング
前回リスク vs 今回リスク で可視化

  3. AWS ソリューションアーキテクトとの共同レビュー活用

    大規模プロジェクト / ミッション・クリティカルシステム
→ WA Review で専門家の知見取得

  4. 複数 Lens を組み合わせた評価

    Serverless Lambda ワークロード
→ wellarchitected + serverless + security Lens

  5. 改善計画を実装・追跡

    HIGH リスク → 3 ヶ月以内に改善
MEDIUM リスク → 6 ヶ月以内に改善
LOW リスク → 1 年以内に改善

❌ やってはいけないこと

  1. 一度評価してそのまま放置

    定期的なレビューなしでは、新機能追加やアップグレードで
乖離が拡大

  2. すべてのリスクに同じ優先度をつける

    HIGH リスク → 即座に改善
MEDIUM / LOW → 計画的に対応

  3. 改善計画を立てるだけで実装しない

    Well-Architected Tool はあくまでツール
実装までが評価

  4. 単一 Lens のみで評価

    複数 Lens を組み合わせることで包括的評価

  5. エンジニア層のみで評価

    ビジネス要件 / コスト / セキュリティ / 運用等
複数ステークホルダーの参加が重要

トラブルシューティング

Issue 1：リスク判定が一向に改善しない

# 原因確認
1. 改善計画が実装されているか確認
   aws wellarchitected list-improvement-plans \
     --workload-id workload-id \
     --query 'ImprovementPlanItems[?Risk==`HIGH`]'

2. 実装後に質問票を更新しているか
   aws wellarchitected update-answer \
     --workload-id workload-id \
     --lens-alias wellarchitected \
     --pillar-id security \
     --question-id <question-id> \
     --selected-choices <new-choice>

Issue 2：マイルストーン比較でリスク増加している

# 原因確認
1. 新しい機能・リソースが追加されていないか
2. セキュリティポリシーの見直し（より厳格）か
3. 実装の後戻りがあったか

→ レビュアーの再評価で確認

2025-2026 最新動向

1. Responsible AI Lens（2025）

倫理的・安全な AI システム構築ガイドライン。バイアス検出・説明責任・プライバシー保護等。

2. GenAI Lens 拡張

Bedrock / Claude モデル活用アプリケーションの評価項目追加。

3. AI 駆動の改善提案

CloudWatch メトリクスから自動的に改善推奨を生成。

4. CloudFormation Hooks 統合

デプロイ前のコンプライアンス自動チェック。

5. レビュアーマッチング機能

AWS パートナーとの自動マッチング・スケジューリング。

学習リソース・参考文献

AWS 公式資料

AWS ブログ・ホワイトペーパー

サードパーティ・セミナー

実装例・活用シーン

シーン 1：新規 SaaS プロダクト開発

開発フェーズ：
  Week 1-2: アーキテクチャ設計
  Week 3: Well-Architected Review（SaaS Lens）
  Week 4-8: 改善実装（HIGH / MEDIUM リスク対応）
  Week 9: 本番デプロイ
  Month 6 / Month 12: 定期レビュー（マイルストーン）

シーン 2：既存システム移行（Lift & Shift）

移行フェーズ：
  事前評価：既存環境の課題把握（Well-Architected Tool）
  設計：クラウド最適化アーキテクチャ設計
  WA Review：AWS SA との共同レビュー
  改善：HIGH リスク対応（セキュリティ / 信頼性）
  本番化：Milestone 0 として記録
  1 年後：Milestone 1 での改善確認

シーン 3：セキュリティ監査

セキュリティ監査フェーズ：
  → Well-Architected Tool + Security Lens 適用
  → HIGH リスク（MFA 未導入等）を抽出
  → 改善計画の優先度付け
  → 定期的に改善進捗をレポート

評価チェックリスト

  • [ ] ワークロード情報（環境・リージョン・Lens）が正確に入力されているか
  • [ ] すべての 6 つの柱について質問票に回答したか
  • [ ] 回答に Notes（根拠）を記入しているか
  • [ ] リスク判定結果（HIGH / MEDIUM / LOW）の内容を理解しているか
  • [ ] 改善推奨事項とドキュメントリンクを確認したか
  • [ ] 改善計画を優先度付けしたか
  • [ ] 改善の所有者・実装スケジュールを決定したか
  • [ ] AWS SA との WA Review が必要か判断したか
  • [ ] Milestone 0（初期評価）として記録したか
  • [ ] 定期レビュー（3～6 ヶ月）スケジュールを設定したか
  • [ ] ステークホルダーに結果をレポートしたか

まとめ

AWS Well-Architected Tool は 「Well-Architected Framework の 6 つの柱に基づくワークロード評価ツール（無料）。質問票形式でリスク分類し、具体的な改善推奨事項とベストプラクティスドキュメントを提供」。

採用メリット：

  • 無料：コスト負担なし
  • 体系的：6 つの柱で包括的に評価
  • 定量化：リスク分類で優先度明確化
  • 改善追跡：マイルストーン機能で進捗可視化
  • 専門家活用：AWS SA / パートナーとの共同レビュー可能
  • カスタマイズ：カスタムレンズで組織固有基準適用

評価・改善のコツ：

  1. 新規ワークロード設計段階から活用
  2. 複数 Lens を組み合わせた評価
  3. AWS ソリューションアーキテクトとの WA Review（大規模・ミッション・クリティカル）
  4. HIGH リスクは 3 ヶ月以内に改善
  5. 定期的なレビュー（6 ヶ月～年次）でマイルストーン記録

Well-Architected Tool は、AWS ベストプラクティスの体系的学習・ワークロード評価の標準プロセス。Trusted Advisor がリソース設定チェック、AWS Config が継続的コンプライアンス監視に対し、Well-Architected Tool はアーキテクチャ設計の品質を評価する戦略的ツールです。

最終更新：2026-04-26
バージョン：v2.0