AWS Well-Architected Tool実践Vol1｜6本柱レビュー運用

1. Well-Architected Framework概要と6本柱

1-1. Well-Architected Frameworkとは

AWS Well-Architected Framework（以降: WA Framework）は、2015年にAWSが公開したクラウドアーキテクチャのベストプラクティス集です。AWSのソリューションアーキテクトが数千件の顧客アーキテクチャレビューから抽出した知見を体系化したもので、特定の技術スタックや業種を問わずあらゆるAWSワークロードに適用できます。

WA Frameworkの核心は「設計品質の評価と改善の継続」にあります。初期設計フェーズのみならず、本番稼働後も定期的なレビューによって変化するビジネス要件・スケール・セキュリティ要求に対応し続けることを前提としています。フレームワークは「設計原則（Design Principles）」と「本柱ごとの質問とベストプラクティス」の2層で構成され、実際のレビューには後述のAWS Well-Architected Toolを使って質問に回答し、リスク（High/Medium）を可視化します。

エンジニアリングチームにとっての価値は明確です。主観的な「良い設計か悪い設計か」の議論を、AWS推奨のベストプラクティスを基にした客観的な評価へと変え、アーキテクチャ負債を計画的に返済するサイクルを作り出すことができます。設計フェーズからの適用はもちろん、稼働中のシステムに対して四半期ごとのレビューサイクルを設けることで、組織的な継続改善の文化を醸成できます。

特筆すべきは、WA Frameworkが「一度設計したら終わり」ではないという点です。システムの成長・チームの変化・AWSサービスの進化に合わせてアーキテクチャも進化させるべきであり、WA Frameworkはその継続改善の羅針盤として機能します。クラウドアーキテクチャの評価基準を組織内で統一し、設計判断の根拠をAWSのベストプラクティスに紐付けることで、技術負債のリスクを可視化して経営層への説明責任も果たしやすくなります。

1-2. 6本柱（重要な前提）

WA Frameworkは現在6本柱（Six Pillars）で構成されています。2021年以前は5本柱でしたが、2021年12月（re:Invent 2021）にSustainability（持続可能性）が第6本柱として追加されました。WA Toolへの組み込みはその翌2022年3月に行われました。「5本柱」と表記するとSustainabilityが欠落した古い記述となるため、本記事では一貫して「6本柱」と記載します。

各本柱の概要は以下のとおりです（図1参照）。

① Operational Excellence（運用上の優秀性）

ワークロードを実行・監視し、業務プロセスを継続的に改善する能力です。設計原則として「運用手順をコードとして定義する」「障害を予測して設計する」「失敗から学習する」などが挙げられます。CloudWatch・AWS Systems Manager・AWS Config を活用した観測可能性の確保と、変更管理の自動化が中心的なテーマとなります。

② Security（セキュリティ）

クラウドテクノロジーを使用してデータ・システム・アセットを保護する能力です。最小権限の原則に基づくIAM設計、保存時・転送時の暗号化、CloudTrailによる操作ログの保全、セキュリティインシデントへの迅速な対応準備が含まれます。WA Frameworkでは「強力なアイデンティティ基盤を実装する」「すべてのレイヤーでセキュリティを適用する」などの設計原則が提示されています。

③ Reliability（信頼性）

意図した機能を意図したタイミングで確実に実行し、要求の変化や障害から回復する能力です。2025年4月のリフレッシュで全面更新が加えられた本柱で、「障害から自動回復するアーキテクチャ」「需要に応じたオートスケーリング」「疎結合設計によるカスケード障害の防止」が核心的な設計原則です。RTO/RPOの定義から始まり、マルチAZ・マルチリージョン構成の設計まで幅広い実装パターンをカバーします。

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

コンピューティングリソースを効率的に活用してシステム要件を満たし、需要の変化やテクノロジーの進化に対応し続ける能力です。適切なインスタンスタイプ・ストレージ種別・データベースエンジンの選択と、継続的なパフォーマンスモニタリングが重要です。「最新テクノロジーを民主化する」という設計原則のもと、マネージドサービスの積極活用が推奨されます。

⑤ Cost Optimization（コスト最適化）

最低コストでビジネス価値を実現する能力です。不要なリソースの排除、マネージドサービスの活用、Savings Plans・リザーブドインスタンスによる割引の適用、コスト配分タグによる可視化が含まれます。「消費モデルを採用する」という設計原則では、使用量に応じた従量課金モデルを最大限に活用することが推奨されています。

⑥ Sustainability（持続可能性）— 2021年12月追加

クラウドワークロードの環境負荷（エネルギー消費・CO₂排出）を最小化する能力です。2021年12月のre:Invent 2021で第6本柱として追加され、WA Toolへの組み込みは2022年3月に行われました。不要なリソースの削減・省電力インスタンスの活用・アーキテクチャ効率の向上を通じて持続可能なクラウド運用を実現します。Graviton系インスタンスへの移行やサーバーレスアーキテクチャへの転換が代表的な改善施策です。

各本柱は独立していますが、相互に関係しているトレードオフの存在を把握しておくことが重要です。たとえば、セキュリティのための多層防御はパフォーマンスに影響し、コスト最適化のためのリソース削減はSustainabilityにも寄与します。WA Frameworkのレビューでは、6本柱を横断的に評価することでトレードオフを把握し、組織の優先度に合わせたバランスのよいアーキテクチャ判断が可能になります。

1-3. 2025年の最新動向

WA Frameworkは静的なドキュメントではなく、テクノロジーとビジネス要件の進化に合わせて継続的に更新されています。2025年4月に実施されたフレームワークリフレッシュでは、6本柱横断で78の新しいベストプラクティスが追加されました。

特筆すべきはReliability（信頼性）本柱の大規模更新です。Reliability本柱は2022年以来初の全面更新となり、14のベストプラクティスが改訂されました。分散システムの障害モード、リージョン間冗長化、カオスエンジニアリングの考え方を反映した内容に刷新されています。

その他の主な更新傾向は以下のとおりです。

• AI/ML Workloadsへの対応: Performance Efficiency・Cost Optimization本柱でAI/MLサービス（Amazon Bedrock等）活用時の設計指針が追加。生成AIワークロードのコスト最適化・パフォーマンス評価の観点が新たに盛り込まれました。
• Sustainability本柱の充実: 2021年12月の追加から着実に内容が拡充され、エネルギー効率の測定指標・自動化ツール連携のベストプラクティスが具体化されています。
• ゼロトラストセキュリティ: Security本柱においてゼロトラスト原則を反映した質問とベストプラクティスが追加され、境界セキュリティに依存しないアーキテクチャ設計の評価軸が強化されました。

1-4. 読者像とこの記事のゴール

想定読者

本記事は以下の役割の方を主な対象としています。

• クラウドアーキテクト・シニアエンジニア: WA Frameworkを知っているが、Tool運用まで体系化できていない方。レビューの進め方を実践的に理解したい方
• プラットフォームチーム・SRE: 組織全体のクラウドアーキテクチャ品質管理を担い、定期レビュー体制を構築したい方
• クラウド基盤運用者・インフラチームリーダー: コンプライアンス要件対応・監査証跡の整備のためWA Toolを活用したい方
• アーキテクチャレビュー担当者: カスタムレンズで社内標準をレビューに組み込む運用を検討している方
• DevOps・自動化推進担当者: WA Tool APIとCI/CDを連携し、レビューを開発サイクルに組み込みたい方

前提知識として「AWSのサービスをある程度使い慣れている」「アーキテクチャ設計の基礎を理解している」程度を想定しています。WA Frameworkの知識がなくても本記事から読み始めることができます。

Vol1で持ち帰れる判断軸

本記事（Vol1）を読み終えると、以下の判断・実行ができるようになります。

1. 6本柱の最新状態を正確に把握する: 2025年4月リフレッシュ後の最新フレームワークを理解し、チーム内の認識を統一できる
2. WA Toolで初回レビューを完了する: ワークロードの登録からフレームワークレビューの完了・マイルストーン保存までを自分で実施できる
3. 改善サイクルを回す土台を作る: マイルストーンを活用して改善の経時変化を記録し、監査証跡として活用できる
4. カスタムレンズとTrusted Advisor連携の適用判断ができる: それぞれの要件（ サポートプランの必須要件、カスタムレンズのJSON定義）を把握し、組織への適用可否を判断できる

設計原則の抽象論よりも「Tool上で何をどう操作するか」の具体的な運用手順と判断軸を重視して解説します。AWSの公式解説では省かれがちな「精度トラップ」（よくある誤解・古い情報）も適宜指摘しながら進めます。

この連載の構成

本連載（Well-Architected 実践シリーズ）では、Vol1から各テーマを順に深掘りします。

各Volは独立して読めますが、Vol1でWA Toolの基本操作を習得しておくと、以降のVolがより理解しやすくなります。WA Frameworkの最新動向（2025年4月リフレッシュ）についても、本Volを起点に各本柱の詳細を追って解説する予定です。

なお、WA Frameworkの活用をより深めたい場合は、AWS Well-Architected Partnerプログラムの活用も選択肢の一つです。AWSパートナーによる公式WA Reviewサービスを利用すると、専門家が第三者視点でレビューを実施し、WA Toolのレポートと改善提案を提供します。ただし本連載では、チームが自律的にWA Toolを活用してセルフレビューを継続する「セルフサービス型の運用体制」を主眼として解説します。

WA Toolをチームに定着させるための第一歩として、まず1つのワークロードを選んで§2の手順で登録し、フレームワークレンズのレビューを一周完了させることを推奨します。最初は完璧な回答を目指すよりも「現状を可視化する」ことを目標に設定するのが、継続的な活用の出発点として最も効果的です。初回レビューで見えてきたHighリスクをチームで共有するだけで、アーキテクチャ改善の優先度議論が格段に具体化します。

▶ 関連: AWS Organizations × Control Tower によるマルチアカウント統制

2. WA Toolセットアップとワークロード登録

2-1. WA Toolの位置づけと料金（重要な前提）

AWS Well-Architected Tool（以降: WA Tool）は、AWSマネジメントコンソールから利用できるアーキテクチャレビュー専用のマネージドサービスです。WA Frameworkの質問への回答・リスク可視化・改善計画策定・マイルストーン管理をブラウザ上で完結でき、後述するカスタムレンズの適用や外部アカウントとのワークロード共有にも対応しています。

料金: WA Tool自体は完全無料

WA Toolの利用料金はゼロです。ワークロード数・レビュー回数・マイルストーン数・カスタムレンズ数に関わらず追加コストは発生しません。ただし、後述のTrusted Advisor連携機能のみ、別途 Business または Enterprise サポートプランが必要です。無料のBasicまたはDeveloperサポートではTrusted Advisor連携は利用できません（詳細は§6参照）。

東京リージョン（ap-northeast-1）GA: 2020年8月

WA Toolは2020年8月27日に東京リージョン（ap-northeast-1）で一般提供（GA）となりました。現在はすべての商用リージョンで利用可能です。カスタムレンズ機能も全リージョンで追加料金なしに利用できます。

他サービスとの位置づけ

WA Toolは「診断・計画」のツールであり、「実装・修正」は各AWSサービス（CloudFormation・AWS Config・Security Hub等）が担います。WA Toolが発見したリスクや改善項目を、Security HubやAWS Configのルールとして具体化することで、継続的なコンプライアンス監視につなげるのが一般的な連携パターンです。

WA Toolへのアクセス方法

WA Toolはマネジメントコンソールの検索バーで「Well-Architected」と入力するか、「Management & Governance」カテゴリから「AWS Well-Architected Tool」を選択してアクセスします。初回アクセス時はウェルカム画面が表示され、「ワークロードの定義」ボタンから即座にワークロード登録を開始できます。

AWS CLI（aws wellarchitected）やAPIからも操作可能で、CI/CDパイプラインへの組み込みやスクリプトによる自動化に活用できます。CLIでのワークロード一覧取得には aws wellarchitected list-workloads を使用します。WA Tool APIは後述（§6）のIaC連携の核となる要素です。

マネジメントコンソールで操作する場合、WA Toolは東京リージョン（ap-northeast-1）でアクセスするとリージョンのプルダウンが「アジアパシフィック（東京）」になっていることを確認してから使用します。ワークロードはリージョンをまたいで共有できますが、コンソール表示はリージョンごとに独立しています。

2-2. ワークロードの定義と登録

WA Toolでのレビューは「ワークロード」を登録することから始まります。ワークロードとはレビュー対象のシステム・アプリケーション・サービスのまとまりです。AWSアカウント全体を1ワークロードにしたり、マイクロサービスごとに別々のワークロードとして管理したりできます。WA Toolのワークロードは物理的なAWSリソースではなく「レビューの単位」を定義する論理的な概念であるため、既存リソースに変更を加えることなく登録・削除できます。

ワークロードの粒度選択

ワークロードの粒度はレビューの目的によって変わります。実際の運用では以下の基準が参考になります。

• サービス境界（推奨）: マイクロサービスやシステムコンポーネントごとにワークロードを分けることで、チームオーナーシップが明確になり、本柱ごとのリスクを独立して管理できます
• チーム境界: プロダクトチームが担当するAWSリソース一式を1ワークロードとして管理する方法です。カスタムレンズとの組み合わせでチーム基準のレビューが可能です
• 環境境界: 本番・ステージング・開発を別ワークロードにすることで、環境別のリスク状況を比較できます

コンソールからの登録手順（図2参照）

AWSマネジメントコンソールで「Well-Architected Tool」を開き、「ワークロードの定義」を選択します。登録時に必要な入力項目は以下のとおりです。

① ワークロード名の設定

ワークロード名は後から変更できないため、命名規則を決めてから入力します。組織内で統一した命名規則（例: {環境}-{サービス名}-{コンポーネント}）を使うことで、複数ワークロードを管理するときに整理しやすくなります。

推奨命名例:
  prod-ecommerce-backend(本番 / ECサイト / バックエンド)
  stg-data-platform  (ステージング / データ基盤)
  prod-auth-service  (本番 / 認証サービス)

② 説明とレビューオーナーの設定

ワークロードの概要説明と、レビューの主担当者（アーキテクト・チームリーダー）のメールアドレスを設定します。複数メンバーがレビューに参加する場合でも、オーナーは1名を指定します。オーナーはワークロードの最終責任者として、レビュー結果の解釈や意思決定を担います。

③ 環境の選択

本番（Production） または 事前本番（Pre-production） のいずれかを選択します。本番を選択するとリスク判定の重み付けが厳格になります。一般的な運用では以下の使い分けが多いです。

④ リージョンの選択

ワークロードが稼働する（または稼働予定の）AWSリージョンを選択します。複数リージョン構成の場合はプライマリリージョンを選択し、マルチリージョン構成である旨をノートに記載しておくと後のレビューで参照しやすくなります。

⑤ AWSアカウントの関連付け（オプション）

ワークロードが跨る複数のAWSアカウントIDを入力できます。Trusted Advisor連携を使う場合はアカウントIDの設定が必要です。マルチアカウント構成（AWS Organizations）の場合は、主要なメンバーアカウントIDを列挙します。

⑥ タグの設定

Cost AllocationタグやチームタグをWA Toolのワークロードにも付与します。組織全体でWA Toolを活用する場合、Team・Service・Environment・CostCenter などのタグを統一することで、複数ワークロードのレビュー状況を絞り込み・集計しやすくなります。

登録後の初期状態

ワークロードを作成すると、選択したレンズに紐づいた質問リストがすぐに利用可能になります。初期状態では全質問が「未回答（Unanswered）」で、リスクサマリには High=0 / Medium=0 / Unanswered=N として件数が表示されます。

共有とコラボレーション

ワークロードは他のAWSアカウントと共有できます。コンプライアンス・監査チームや外部コンサルタントをレビュアーとして招待する際に有効です。共有先は「閲覧のみ（Viewer）」または「回答可（Contributor）」の権限で制御できます。

ワークロード共有の権限設定:
  Viewer  → レビュー結果・改善項目の閲覧のみ（回答変更不可）
  Contributor → 質問への回答・ノート記入が可能

複数アカウントでの一元管理（AWS Organizations連携）

AWS Organizations環境では、管理アカウントからメンバーアカウントのワークロードを一元的に確認できます（WA Toolのマルチアカウントビュー機能）。大規模組織でアーキテクチャガバナンスを強化する際に有効です。各事業部・チームが自アカウントで実施したレビュー結果を、プラットフォームチームが一覧で確認する運用が実現できます。

Organizations連携を活用することで、全社横断のHighリスク件数を集計してガバナンスレポートに活用したり、特定のカスタムレンズが全チームに適用されているかを確認したりといった、大規模組織ならではのWA Tool活用が可能になります。このような組織全体の活用パターンについては Vol3（予定）で詳しく解説します。

2-3. レンズの選択

ワークロードに紐づける「レンズ」はレビューの評価軸を決定します。1ワークロードには複数のレンズを適用でき、それぞれ独立したレビューが可能です。なお、1ワークロードに追加できるレンズは最大20個ですが、同時に適用できるのは5レンズまでです（Lens Catalogとカスタムレンズの合計）。

① フレームワークレンズ（デフォルト・常時適用）

すべてのワークロードに標準で適用されるのが「AWS Well-Architected Framework レンズ」です。6本柱に基づいた公式質問セットで構成されており、汎用的なクラウドアーキテクチャのベストプラクティスを網羅します。ほとんどのワークロードではフレームワークレンズのみで十分なレビューを行えますが、特定ユースケースや組織固有の要件がある場合は以下の追加レンズを検討します。

② Lens Catalog（AWSが公式提供するユースケース別レンズ）

AWSがユースケース別に公式提供しているレンズ集で、コンソールの「Lens Catalog」から追加できます。追加料金は不要です。主要な公式レンズの例を以下に示します。

フレームワークレンズはアーキテクチャ全体を評価するのに対し、Lens Catalogの各レンズは特定領域をより詳細に評価します。両者を組み合わせることで、汎用ベストプラクティスと専門領域の評価を同時に実施できます。

③ カスタムレンズ（組織独自の評価軸）

組織内のコンプライアンス要件・セキュリティポリシー・内部SLA・業界固有の技術標準をレンズ化したものです。フレームワークレンズと並行して同じワークロードに適用でき、「社内標準に準拠しているか」を公式ベストプラクティスと同じインターフェースでレビューできます。カスタムレンズの詳細は§4で解説します。

レンズ選択の実践的な判断フロー

どのレンズを使うか迷った場合は、以下のフローで判断します。

ワークロードの性質を確認
  ↓
フレームワークレンズ（必須・常時適用）
  ↓
ユースケース確認 → Lens Catalogに該当レンズあり？
  → あり: 追加適用を検討（同時適用は5まで）
  → なし: フレームワークレンズのみ or カスタムレンズ作成
  ↓
組織標準・コンプライアンス要件あり？
  → あり: カスタムレンズを作成して適用（§4参照）
  → なし: そのままレビュー開始

レンズのバージョン管理

レンズはバージョン管理されており、AWSのアップデート後は旧バージョンと新バージョンを併用できる状態になります。本番運用では既存ワークロードのレンズバージョンを固定し、次回レビューサイクルに合わせて計画的にアップグレードすることを推奨します。途中でバージョンアップすると質問番号やベストプラクティス構成の変更を伴い、過去の回答・マイルストーンとの比較が困難になります。

レンズ追加の手順（コンソール操作）

Lens Catalogまたはカスタムレンズをワークロードに追加する手順は以下のとおりです。

1. WA Toolコンソールを開き、対象ワークロードを選択します
2. 「Properties」タブを開き、「Lenses」セクションを確認します
3. 「Add lenses」ボタンをクリックすると、Lens Catalogが一覧表示されます
4. 追加したいレンズを選択してチェックを入れ、「Save」を押すと即座に適用されます
5. ワークロードの画面に戻ると、追加したレンズ用の質問セクションが表示されます

カスタムレンズの場合は、事前にJSON定義をインポートして「Published」状態にしてから（§4参照）、同じ手順でワークロードに追加します。

レンズを外す場合の注意点

一度追加したレンズをワークロードから削除すると、そのレンズに対して行った回答・ノートはすべて失われます。過去のマイルストーン内に保持されているデータは残りますが、現在の回答状態からは削除される点に注意が必要です。重要なレンズを誤って削除しないよう、削除前にマイルストーンを保存しておくことを推奨します。

同時適用5レンズの上限への対応

同時に適用できるのは5レンズまでですが、ワークロードには最大20レンズを紐付けられます。現在の評価に必要なレンズを優先して有効にし、一時的に使用しないレンズは非アクティブにする運用が一般的です。四半期ごとのテーマに合わせてアクティブレンズを切り替える使い方も有効です。

3. ワークロードレビュー実践

3-1. 質問への回答とリスク判定

ワークロード登録が完了したら、いよいよレビューの核心部分に入ります。WA Toolでは、選択したレンズ（フレームワークレンズの場合は6本柱）ごとに複数の質問が提示されます。フレームワークレンズ全体では50問以上の質問が用意されており、各本柱にまたがって体系的なレビューを実施できます。

質問への回答形式

各質問には、推奨されるベストプラクティス群が複数提示されます。現在の実装状況と照らし合わせ、合致するベストプラクティスへチェックを入れていきます。主な回答パターンは次のとおりです。

• ベストプラクティスを選択: 実装済みの項目にチェックを入れる。複数選択可能
• 回答なし（None of these）: 該当するベストプラクティスをまったく実装していない場合に選択
• 該当しない（Not applicable）: そのワークロードの性質上、当該質問が対象外の場合に選択

リスク判定の仕組み

回答内容をもとに、WA Toolは自動的にリスクレベルを算出します。リスクは以下の3段階で分類されます。

本柱ごとのリスクサマリーはダッシュボードにグラフ表示され、どの本柱・どの質問でリスクが集中しているかを一目で把握できます。

ノートの活用

各質問には自由記述のノートを添付できます。「なぜこのBPを選択しなかったか」「いつ対応予定か」「例外的な理由」を残しておくと、チームメンバーへの説明や後のマイルストーン比較に役立ちます。ノートはマイルストーン保存時にも保持されるため、監査証跡として機能します。

本柱別リスクダッシュボードの読み方

フレームワークレンズ全体の回答が進んだ段階で、ワークロードのダッシュボード（「概要」タブ）を確認します。ここでは6本柱それぞれのリスク集計が以下の形式で表示されます。

• 本柱ごとのHigh/Mediumリスク件数: どの本柱にリスクが集中しているかを棒グラフで確認
• 全体のリスクサマリー: ワークロード全体のHigh Risk総数・Medium Risk総数
• 未回答質問数: 全体のうち未回答のまま残っている質問の件数

ダッシュボードは「今どの本柱のレビューをどこまで進めたか」を俯瞰するのに適しており、チームへの進捗共有の場面でそのまま活用できます。レビュー途中でチームメンバーを追加した場合も、ダッシュボードを共有することで現在のリスク状況を素早く共有できます。

3-2. 改善項目（Improvement Items）の確認

レビューの回答が進むと、WA ToolはリスクのあるベストプラクティスごとにImprovement Items（改善項目）を自動生成します。この改善項目こそが、実際のアーキテクチャ改善作業を具体化するリストとなります。

改善項目の構成

各Improvement Itemには以下の情報が含まれています。

• タイトル: 改善すべき項目の名称（例：「Enable encryption at rest for all data stores」）
• リスクレベル: High / Medium の区別
• 推奨アクション（Improvement Plan）: AWSが推奨する具体的な対応策
• 関連ドキュメントへのリンク: AWSドキュメントやベストプラクティスガイドへの直接リンク

改善項目の確認と優先順位付け

WA Toolのコンソールで「Improvement Plan」タブを開くと、すべての本柱にまたがる改善項目が一覧表示されます。リスクの高い項目から降順に並んでいるため、High Riskの項目から優先的に対処する計画を立てることが重要です。

External Integration（外部連携）との組み合わせ

WA Toolには、Jira SoftwareやServiceNowとの連携機能（AWS Connector for Jira等）が提供されています。改善項目を直接外部チケットシステムへエクスポートすることで、WA Toolと既存のプロジェクト管理プロセスを統合できます。

また、Trusted Advisor連携（§6で詳説）を有効にすると、TA のチェック結果が自動的にWAのベストプラクティス回答に反映され、手動入力の手間を大幅に削減できます（Business/Enterpriseサポートプランが必要）。

本柱単位でのフィルタリング

改善項目が多数生成された場合は、本柱（Pillar）でフィルタリングして各チームの担当範囲を絞り込む運用が効率的です。セキュリティチーム、インフラチーム、アプリチームがそれぞれ担当本柱の改善項目にフォーカスして並行対応できます。

WA Tool APIを使った改善項目の一括取得

WA ToolにはAPIが用意されており、改善項目を機械的に取得して他システムへ連携できます。大規模な組織で複数のワークロードを管理している場合、コンソール操作ではなくAPIやAWS CLIを使った一括取得がデータ活用の幅を広げます。

# AWS CLIでワークロードのImprovementSummaryを取得する例
aws wellarchitected list-lens-reviews \
  --workload-id <workload-id> \
  --lens-alias arn:aws:wellarchitected::aws:lens/wellarchitected \
  --region ap-northeast-1

# 改善項目（Improvement Items）の取得
aws wellarchitected list-answers \
  --workload-id <workload-id> \
  --lens-alias arn:aws:wellarchitected::aws:lens/wellarchitected \
  --pillar-id security \
  --region ap-northeast-1

取得した改善項目のJSONデータをPythonなどで処理することで、「全ワークロードのHigh Risk一覧」「本柱別のリスクヒートマップ」「四半期ごとのリスク推移グラフ」を社内ダッシュボードに自動連携する仕組みを構築できます。IaC・CI/CD連携の詳細は§6で解説します。

3-3. レビューの進め方（実践Tips）

WA Toolのレビューを初めて実施するチームが陥りやすい失敗は、「すべての本柱を一度に完了させようとする」ことです。フレームワークレンズは6本柱50問以上あるため、一気に進めるとレビューの質が落ちたり、途中で放置されたりしがちです。以下の実践的なアプローチを参考にしてください。

① 本柱を分けて段階的にレビューする

一度のセッションでは、1〜2本柱を集中的にレビューするのが現実的です。たとえば最初のセッションでSecurity本柱に絞り、次のセッションでReliability本柱、という具合に進めます。本柱ごとにマイルストーンを保存しておくと、途中経過を記録しながら進捗を可視化できます。

② ステークホルダーを集めたワークショップ形式

WA Toolのレビューは、アーキテクト一人が完結させるものではなく、チームの集合知を活用するプロセスです。以下の役割を集めたファシリテーションセッションが効果的です。

③ ノートを積極的に活用する

各質問のノート欄を単なるメモ欄として使うのではなく、「なぜこの判断をしたか」を記録する場所として位置づけてください。特に有効な記録パターンは以下の通りです。

• 未実装の理由: 「コスト対効果の観点から本システムには不要と判断（2025年第4四半期に再評価予定）」
• 将来の対応予定: 「2026年Q1のシステム刷新時に対応予定。担当チームは基盤グループ」
• 例外承認: 「セキュリティ委員会で承認済み（承認番号: SEC-2025-034）」

このようなノートを残しておくと、監査時の説明資料としてそのまま活用でき、組織のガバナンスコンプライアンスに貢献します。

④ 初回レビューでありがちな失敗パターン

WA Toolを初めて導入するチームが経験する失敗の多くは、事前に知っておくことで回避できます。以下の「避けるべきアンチパターン」を押さえておくと、スムーズに定着化できます。

これらのアンチパターンの多くは、「WA Toolの操作手順は理解しているが、レビューをどう運用プロセスに組み込むか」が定まっていないことが根本原因です。ツールの習熟と並行して、チーム内でのレビューオーナー・頻度・改善項目の管理方法を明文化することが長期的な定着のカギとなります。

「WA Toolの活用状況」を四半期の振り返りミーティングに議題として加えることも、形骸化防止に効果的なアプローチです。レビュー結果を経営層へ定期報告する文化を育てることで、アーキテクチャ改善への投資判断を後押しできます。

⑤ 定期レビューのスケジュール化

WA Toolのレビューは、一度実施したら終わりではありません。本番システムは継続的に変化するため、定期的な再レビューが重要です。

• 初回レビュー: システム稼働開始直後（ベースラインの確立）
• 定期レビュー: 四半期ごと（重大な変更がなければ半期でも可）
• 臨時レビュー: 大きなアーキテクチャ変更・インシデント対応後

定期レビューのスケジュールを社内カレンダーに登録し、スプリントプランニングと同様に「繰り返しイベント」として扱うことで、後回しにされることなく継続できます。レビュー実施を「四半期OKRの1項目」として組み込んでいる組織では、カルチャー定着が自然と進む傾向にあります。

定期レビューの実施後は、必ずマイルストーンを保存してから次サイクルに進む習慣が重要です。マイルストーンの保存タイミングとレビューサイクルを一致させておくと、「どのマイルストーンがいつのレビューに対応するか」が明確になり、監査対応やチームへの報告がスムーズになります。マイルストーンの詳細活用については§5で解説します。

4. カスタムレンズの作成と共有

4-1. カスタムレンズとは（重要な前提）

カスタムレンズは、組織固有の要件をWA Toolのレビューフレームワークに組み込むための機能です。公式6本柱では網羅しきれない、社内のコンプライアンス規程・内部SLA・セキュリティ統制・業界固有の技術標準を独自のレンズとして定義し、公式フレームワークレンズと並行して同じワークロードに適用できます。

カスタムレンズの構成要素

カスタムレンズは以下の要素で構成されます。

これら全てをJSON形式で定義し、WA Toolにインポートして利用します。

利用上限（精度トラップ④）

1ワークロードあたり最大20レンズを追加できますが、同時に適用できるのは5レンズまでです。Lens Catalog（AWSが提供する公式レンズライブラリ）とカスタムレンズの合計でこの上限が適用されます。なお、カスタムレンズの作成・利用に追加料金はかかりません。

ワークロードに紐づくレンズ（最大20、同時適用5まで）:
┌──────────────────┐  ┌─────────────────┐
│ フレームワークレンズ  │  │ カスタムレンズ │
│ (公式6本柱) │  │ (組織独自) │
└──────────────────┘  └─────────────────┘
  ↓  ↓
  ┌──────────────────────────────┐
  │  ワークロードレビュー  │
  │  公式質問 + 独自質問を統合│
  └──────────────────────────────┘

代表的なユースケース

カスタムレンズが有効に機能する代表的なシーンを以下に示します。

① 社内セキュリティポリシーの標準化
全社でのVPC設計ルール・IAMポリシー制約・ログ保持要件などを質問化し、新しいワークロードが社内標準に準拠しているかを自動チェックします。

② 規制・コンプライアンス対応
金融系の安全管理措置・医療系のHIPAA要件・GDPRのデータ主権要件など、業界規制をレンズ化して継続監査に活用します。

③ 共通プラットフォーム標準の強制
プラットフォームチームが社内標準（モニタリング必須・コスト上限・DR目標）を定義し、各サービスチームが同じレンズでセルフレビューできる環境を構築します。

4-2. カスタムレンズのJSON定義と公開

カスタムレンズはJSON形式で定義します。JSON定義をWA Toolにインポートし、レビュー・公開という流れで利用可能になります。

JSONスキーマの基本構造

{
  "schemaVersion": "2021-11-01",
  "name": "社内セキュリティ標準レンズ v1",
  "description": "社内セキュリティポリシー準拠確認用カスタムレンズ",
  "pillars": [
 {
"id": "security_policy",
"name": "社内セキュリティポリシー",
"questions": [
  {
 "id": "sq_vpc_design",
 "title": "VPC設計は社内標準に準拠していますか？",
 "description": "VPCのCIDR設計・サブネット分離・インターネット接触範囲が社内規程に従っているか確認します。",
 "choices": [
{
  "id": "choice_vpc_private_only",
  "title": "プライベートサブネットのみでワークロードを構成している",
  "helpfulResource": {
 "displayText": "社内ネットワーク設計ガイドライン",
 "url": "https://internal.example.com/network-guide"
  },
  "improvementPlan": {
 "displayText": "インターネット向けリソースをパブリックサブネットから分離し、NAT Gatewayまたは社内Proxyを経由させてください。",
 "url": "https://internal.example.com/remediation"
  }
}
 ],
 "riskRules": [
{
  "condition": "NONE(@choices)",
  "risk": "HIGH"
}
 ]
  }
]
 }
  ]
}

主要なフィールドの役割は以下の通りです。

インポートから公開までの手順

カスタムレンズの利用は以下のフローで進めます。

① JSON定義ファイルを作成
 ↓
② WA Tool コンソール → [カスタムレンズ] → [カスタムレンズの作成]
 ↓
③ JSON ファイルをアップロード → バリデーション実行
 ↓
④ ドラフト状態で登録（まだワークロードには追加不可）
 ↓
⑤ [公開] ボタンでバージョン 1 として公開
 ↓
⑥ ワークロードの [レンズを追加] からカスタムレンズを選択して適用

バージョン管理のポイント

カスタムレンズはバージョン管理に対応しています。

• バージョンアップ: JSON定義を修正して再インポートすると新バージョンとして公開できます。既存ワークロードに適用済みのレンズはバージョンアップを手動で適用するまで旧バージョンのまま維持されます。
• 廃止（Deprecate）: 不要になったレンズは「非推奨」に設定できます。既存の適用は継続しますが、新規ワークロードへの追加はできなくなります。
• 削除の注意: 削除するとそのレンズを適用している全ワークロードのレビューデータに影響するため、廃止→十分な移行期間→削除の順で進めることを推奨します。

4-3. 共有とアカウント跨ぎ運用

カスタムレンズを複数のAWSアカウントや組織全体で共有し、統一したレビュー基準を適用する方法を説明します。

共有の仕組み

カスタムレンズの共有にはAWS Resource Access Manager（RAM）を使用します。組織内の別AWSアカウントや、指定したAWSアカウントにレンズを共有できます。

共有元アカウント（管理・標準定義チーム）
  └─ カスタムレンズ（published）
↓ AWS RAM 共有
  ┌──────┬──────┬──────┐
  │ 開発A │ 開発B │ 本番C │  ← 受信側アカウント
  └──────┴──────┴──────┘
 各アカウントが共有カスタムレンズを
 自分のワークロードに適用可能

共有の手順（共有元）

1. WA Toolコンソール → [カスタムレンズ] → 対象レンズを選択
2. [共有] タブ → [共有を作成]
3. 共有先を指定:
4. 個別AWSアカウントID: 特定チームのアカウントに限定共有
5. AWS Organizations のOU: 特定のOU配下の全アカウントに一括共有
6. AWS Organizations 全体: 組織内の全アカウントに共有

受信側での利用

共有されたカスタムレンズは、受信側アカウントのWA Toolコンソールに「共有されたカスタムレンズ」として表示されます。受信側は共有を承認後、自分のワークロードに追加して利用できます。なお、受信側には編集・削除の権限はなく、共有元が管理するバージョンに追随します。

大規模組織での運用設計

複数チームがAWSを利用する大規模環境では以下のアーキテクチャが効果的です。

カスタムレンズ運用のアンチパターン

実際の運用でよく見られる失敗パターンと対策をまとめます。

5. マイルストーン管理と改善計画

5-1. マイルストーン（重要な前提）

マイルストーンとは、ある時点でのワークロードの状態を丸ごと保存する時点スナップショットです。
具体的には「全質問への回答内容」「Highリスク数・Mediumリスク数」「各質問に付けたノート」の3要素がそのままの形で保持されます。
後から比較できる形でアーカイブされるため、改善前後の差分を客観的に示したい場面や、監査・コンプライアンス対応で「いつ・何を改善したか」を証跡として提示しなければならない場面で非常に有効です。

上限は1ワークロードにつき最大100マイルストーンです。
ほとんどの運用では四半期に1〜2回程度マイルストーンを作成するため、実質的に上限に到達することは少ないですが、細かい粒度で記録したい場合はこの上限を念頭に置いてください。

マイルストーンを作成するタイミング

マイルストーンの作成タイミングには、主に以下の4つのケースがあります。

1. 定期レビュー後（最推奨）: 四半期や半期の定期レビューを終えた直後に「今この瞬間の状態」を保存します。次回レビュー時に「前回からどれだけ改善したか」が一目でわかります。
2. 重大な変更前: 大規模なアーキテクチャ変更や移行プロジェクト着手前に現状を記録しておくことで、変更後との比較が容易になります。
3. 重大な変更後: 新しいリージョン展開やサービス追加が完了した段階でスナップショットを取り、変更による影響（リスク増減）を即座に可視化できます。
4. リリース・本番切り替え前: 本番環境へのリリースゲートとして使う場合、「リリース直前の回答状態」を保存することで、問題発生時の調査材料にもなります。

命名規則の重要性

マイルストーン名は後から検索・比較に使うため、わかりやすいネーミングが重要です。
以下のような命名規則を組織内で統一することを推奨します。

<ワークロード名>-<年>-Q<四半期番号>-<状態>
例: order-service-2025-Q2-post-review
 data-platform-2025-04-pre-migration
 auth-service-2025-Q1-baseline

ランダムな名前を付けると、100個の上限に近づいたとき「どれを削除してよいか」の判断が困難になります。
日付や目的を含む命名規則を最初から徹底することが、長期運用のポイントです。

マイルストーンの比較機能

WA Toolのコンソールでは、同一ワークロード内の2つのマイルストーンを並べて比較できます。
比較ビューでは「あのマイルストーン時点ではHighリスクが8件あったが、現在は3件に減少した」といった改善の推移を視覚的に確認できます。

比較できる情報は以下のとおりです。

• リスク数の変化: High / Mediumそれぞれの件数と増減
• 本柱別の改善状況: どの本柱でリスクが解消されたか
• 回答の変化: 各質問の回答内容がどう変わったか
• ノートの履歴: 改善時に残したノートの確認

「どの改善施策が効いたか」を後から分析するためにも、改善実施後は必ずマイルストーンを作成し、比較できる状態を保つことが重要です。

マイルストーンの管理（上限100個への対応）

1ワークロードにつき最大100マイルストーンの上限は、頻繁に作成する運用では将来的に到達する可能性があります。
上限に近づいた際の対応として、以下の削除基準を事前に定めておくと運用がスムーズです。

• 1年以上前のマイルストーンで、当時の改善内容が現在も反映済みのもの
• テスト目的で作成した名前の不明確なマイルストーン
• 同じ四半期に複数作成した中間スナップショット（最終版のみ残す）

重要な監査証跡や大規模変更前後のスナップショットは削除せずに保管する方針を設けることをお勧めします。
また、削除前に比較ビューでその時点の状態を確認し、必要に応じてCSVやスクリーンショットでエクスポートしておくと安心です。

5-2. 改善計画と再レビューのサイクル

マイルストーンを単なる記録にとどめず、継続的な改善サイクルの起点として活用することが、WA Tool運用で最も重要なポイントです。
図5に示すように、「レビュー → マイルストーン保存 → 改善計画策定 → 実装 → 再レビュー → 新マイルストーン保存」というループが、Well-Architectedな状態を維持するための基本サイクルです。

ステップ1: リスクの優先度付け

定期レビューでHighリスク・Mediumリスクが検出されたら、まずリスクを優先度別に整理します。

Highリスクをすべて即時対応しようとすると、チームのキャパシティを超えることがあります。
「どのHighリスクが事業インパクト最大か」を議論したうえで、対応順序をビジネス優先度と照らし合わせて決定することが実践的です。

なお、セキュリティ本柱と信頼性本柱のHighリスクは、他の本柱のHighリスクより優先度を高く設定することを推奨します。
サービス停止やデータ漏洩に直結するリスクは、コスト最適化や運用効率化の課題より事業への即時ダメージが大きいためです。

ステップ2: 改善項目のバックログ化

WA Toolのコンソールには、各リスクに対する「改善項目（Improvement Items）」が表示されます。
これらをチームの既存バックログ（Jira, GitHub Issues等）に取り込むことで、通常の開発サイクルに改善作業を組み込むことができます。

改善項目をバックログへ登録する際に含めると有用な情報は以下のとおりです。

• 対象ワークロード名・本柱名・質問ID
• WA Toolが提示した推奨アクション
• Highリスクかどうか（優先度として使える）
• 対応期限（四半期単位でよい）
• 担当チーム・担当者

この連携により、「WA Toolのレビュー結果が改善されず放置される」という最も多いアンチパターンを防ぐことができます。

バックログ化した改善項目は、スプリントプランニングの場で「WA改善タスク」として通常の開発チケットと同列に扱うことが重要です。
専用のWA改善スプリントを設けるより、通常スプリントにWA改善タスクを一定割合（10〜20%程度）混在させる方が、継続的な改善を実現しやすいという現場の知見があります。
また、改善項目をバックログに入れた際は、WA Toolの当該質問のノートに「バックログ登録日・チケット番号」を記録しておくと、後で「この改善がいつバックログに入り、いつ完了したか」を追跡できます。

ステップ3: 改善の実装とエビデンス記録

改善を実装したら、WA Toolの対応する質問のノート欄に対応内容を記録します。
たとえば「Backupポリシーを設定し、クロスリージョンバックアップを有効化した（2025-05-15対応、Jira: INFRA-4321）」といった形で記録しておくと、次回レビュー時にノートを見るだけで「前回から何が変わったか」が把握できます。

また、インフラ変更をCloudFormation/CDKで管理している場合は、変更のプルリクエスト番号やコミットハッシュをノートに紐付けると、コード変更とWAリスク対応の追跡が容易になります。

ステップ4: 再レビューと新マイルストーンの作成

改善実装後の再レビューでは、対応したHighリスクが「解消」または「Mediumへ降格」していることを確認します。
確認が取れたら新しいマイルストーンを作成し、改善前のマイルストーンとの比較で「Highリスクが何件減少したか」を計測します。

この比較結果は、経営層やステークホルダーへの報告材料としても有効です。
「前四半期比でHighリスクを8件から3件に削減」といった具体的な数値で、アーキテクチャ改善の進捗を説明できます。

四半期サイクルへの組み込み例

実際の運用では、以下のような四半期単位のサイクルが定着しやすいです。

[四半期初め] 前四半期の改善結果を確認・マイルストーン比較
  ↓
[月1] 今四半期の定期レビュー実施 → マイルストーン保存
  ↓
[月1〜月2] 優先Highリスクをスプリントバックログに取り込み → 実装
  ↓
[月3] Mediumリスクの対応・次四半期への計画策定
  ↓
[四半期末] 実施結果レビュー → 新マイルストーン保存 → 次四半期へ

この「四半期サイクル × マイルストーン」の組み合わせは、定常業務と改善活動を両立させながらWell-Architectedな状態を継続的に改善していくための、実践的なフレームワークです。

初回の定期レビューでは、多数のHighリスクが検出されてチームが途方に暮れることも少なくありません。
しかし重要なのは「ゼロリスクを目指すこと」ではなく「継続的にリスクを減らしていくことを組織として仕組み化すること」です。
100点満点のアーキテクチャは存在せず、ビジネスの変化に伴いシステムは常に変わり続けます。
マイルストーンと改善サイクルの組み合わせは、まさにその「変化に追いつき続ける」ための運用基盤です。
まず小さくサイクルを回し始めることが、長期的なWell-Architected運用定着への第一歩です。

リスク受容の記録と再評価

すべてのHighリスクを即座に対応することが現実的でない場合、WA Toolでは回答に「Not applicable（該当なし）」や「Acknowledged（承認済み）」を設定し、ノートに受容理由を記録できます。
この受容記録は監査対応において「リスクを認識した上でビジネス判断として受容した」という証跡になります。

受容したリスクのノートには最低でも以下を記載することを推奨します。

• 受容の理由（例: コスト制約・技術的制限・事業優先度）
• 受容した日時と決定者
• 次回再評価の予定時期（例: 次四半期のレビュー時）
• 代替コントロール（リスク軽減策として他の対策を実施している場合はその内容）

受容リスクは放置ではなく「管理された先送り」として扱い、必ず再評価サイクルに組み込んでください。

複数ワークロード間の比較と全社視点

組織内に複数のワークロードが存在する場合、WA Toolではワークロード横断のリスクビューを確認できます。
例えばセキュリティHighリスクが全ワークロードで共通して発生している場合、個別対応ではなく横断的な組織施策（セキュリティポリシーの更新、共通コンポーネントの提供等）で効率的に解消できる可能性があります。

全社的なWell-Architected運用の成熟度を高めるためには、個別ワークロードの改善サイクルを並行して回しながら、定期的に全社ビューでリスクのトレンドを把握する仕組みを設けることが重要です。

改善進捗の定量的な追跡

改善サイクルの効果を定量的に追跡するために、以下のメトリクスをマイルストーン比較から導出して記録することを推奨します。

これらのメトリクスを四半期末レポートや月次アーキテクチャレビューで報告することで、WA Tool運用の継続的な改善活動が組織に可視化され、定着につながります。

6. Trusted Advisor連携とIaC連携

6-1. Trusted Advisor連携（重要な前提）

AWS Trusted Advisorは、セキュリティ・コスト・パフォーマンス・耐障害性・サービス制限の5カテゴリからAWS環境を自動チェックするサービスです。WA Toolとの連携機能を有効化すると、Trusted AdvisorのチェックフィールドがWAのベストプラクティス質問に自動マッピングされ、手動で回答を入力する工数を大幅に削減できます。

★重要な前提：Business/Enterprise サポートプランが必須

WA ToolとTrusted Advisorの連携は、AWSサポートプランが Business または Enterprise のアカウントでのみ利用可能です。無料のBasicプランやDeveloperプランでは、Trusted Advisorの主要チェック項目（200+）にアクセスできないため、WA Tool連携機能は動作しません。本番運用でこの機能の活用を検討する際は、まず現在のサポートプランを確認してください。

連携で得られるエビデンスの種類

連携を有効化すると、ワークロードに紐づくAWSアカウントのTAチェック結果がWA Toolに自動取り込まれます。レビュー画面の各質問に「自動エビデンス」として表示され、根拠のある回答を効率的に記録できます。代表的なマッピングは以下のとおりです。

• Security本柱への連携：S3バケットのパブリックアクセス設定 / IAMユーザーのMFA未設定 / ルートアカウント利用の検知
• Cost Optimization本柱への連携：未使用EC2インスタンス / 未使用Elastic IPアドレス / アイドル状態のロードバランサー
• Reliability本柱への連携：Auto Scalingの設定不備 / マルチAZ構成の欠如 / RDS自動バックアップ無効化
• Performance Efficiency本柱への連携：スロットリングが発生しているサービス / 過剰スペックのインスタンス検出

TAの結果が「警告（WARNING）」または「エラー（ERROR）」の場合、WA Toolのレビュー画面では該当ベストプラクティスのリスクフラグ（High/Medium）と連動して表示されます。エビデンスを確認しながら回答を入力できるため、定性的な判断に定量的な根拠を付加できるのが大きなメリットです。

連携の有効化手順

1. AWSマネジメントコンソールで [Well-Architected Tool] を開く
2. 左メニューの [設定] → [Trusted Advisor の統合] を選択（Business/Enterpriseプランのアカウントのみ項目が表示される）
3. 統合を有効化し、連携対象のワークロードを指定する
4. 対象ワークロードのレビューを開くと、各質問の回答欄に [エビデンスの表示] セクションが追加されている
5. TAのチェック結果が PASS / WARNING / ERROR の状態で一覧表示され、回答の参考情報として活用できる

活用上の注意点

Trusted Advisorのエビデンスはあくまで補助情報であり、TAが全WAベストプラクティスをカバーするわけではありません。TA結果がすべてPASSでも、WA観点で追加対応が必要なケースは多く存在します。エビデンスは「チェックの加速」に活用しつつ、最終的な回答判断は人間のアーキテクトが行う運用を徹底してください。

また、TAチェック結果は原則24時間ごとに自動更新されます。レビュー直前に最新状態を確認したい場合は、TAコンソールから手動で [今すぐ更新] を実行してから連携結果を参照するのが確実です。Business以上のプランでは、コンソールからの手動更新がいつでも利用できます。

6-2. IaC（CDK/CloudFormation）連携

WA ToolはRESTful APIを提供しており、インフラをコードで管理するIaC（Infrastructure as Code）と組み合わせることでレビュープロセスを自動化できます。人間による手動操作を減らし、レビューをソフトウェアデリバリのサイクルに自然に組み込めます。

WA Tool APIの主要操作

WA Tool API（aws wellarchitected）で利用頻度の高い操作は以下のとおりです。

CDKを使ったワークロード自動登録

AWS CDKのカスタムリソースを利用することで、インフラスタックのデプロイ時にWA Toolへのワークロード登録を自動化できます。以下はPythonでの実装例です。

from aws_cdk import custom_resources as cr, Stack
from constructs import Construct

class WellArchitectedWorkloadStack(Stack):
 def __init__(self, scope: Construct, construct_id: str, **kwargs):
  super().__init__(scope, construct_id, **kwargs)

  cr.AwsCustomResource(
self, "WAWorkload",
on_create=cr.AwsSdkCall(
 service="WellArchitected",
 action="createWorkload",
 parameters={
  "WorkloadName": "MyProductionApp",
  "Description": "本番ECシステム — WA Tool自動登録",
  "Environment": "PRODUCTION",
  "AwsRegions": ["ap-northeast-1"],
  "Lenses": ["wellarchitected"],
  "ReviewOwner": "platform-team@example.com",
 },
 physical_resource_id=cr.PhysicalResourceId.from_response(
  "Workload.WorkloadId"
 ),
),
policy=cr.AwsCustomResourcePolicy.from_sdk_calls(
 resources=cr.AwsCustomResourcePolicy.ANY_RESOURCE
),
  )

CI/CDパイプラインでのマイルストーン自動作成

CodePipelineやGitHub Actionsのデプロイ後ステップに組み込むことで、リリースのたびに「その時点でのリスク状態」をスナップショット化できます。

import boto3

def create_milestone_on_deploy(workload_id: str, version: str) -> int:
 """デプロイ後のPost-deployステップから呼び出す"""
 client = boto3.client("wellarchitected", region_name="ap-northeast-1")
 response = client.create_milestone(
  WorkloadId=workload_id,
  MilestoneName=f"deploy-{version}",
 )
 return response["MilestoneNumber"]

このパターンを導入すると、デプロイ前後のリスク比較やロールバック判断の材料として、マイルストーンが自動的に蓄積されていきます。

AWS Configとの連携パターン

AWS Configルールと組み合わせると、コンプライアンス違反が検出された時点でWA Toolの回答リスクを自動更新するサーバーレスアーキテクチャを構築できます。

Config非準拠検出
  → EventBridgeルール発火
 → Lambda
→ WA Tool API UpdateAnswer（リスク: HIGH）
  → 担当者へSlack通知

IaC連携を整備することで、Well-Architectedレビューが「年次イベント」から「継続的なフィードバックループ」に変わります。デプロイのたびにリスクが可視化・記録される仕組みは、アーキテクチャの品質向上に大きく貢献します。

IaC連携の導入ロードマップ

初めてIaC連携を導入する際は、一気に全自動化を目指すのではなく、段階的に構築することを推奨します。

まずPhase 1でAPIの動作を確認し、チームのWA Tool利用習慣を定着させた上でPhase 2以降に進むと、自動化が無駄なく機能します。

7. レビュー運用定着サイクルとベストプラクティス

7-1. 定期レビューの運用設計

Well-Architectedレビューは、システム設計時に一度実施すれば終わりではありません。稼働後も定期的に再レビューすることで、ビジネス要件の変化・AWS新サービスの登場・組織規模の拡大に対してアーキテクチャが追随できているかを継続確認することが重要です。

定期レビューサイクルの設計

多くの組織では、以下のサイクルをベースラインとして採用しています。

特に重要なのは「インシデント後レビュー」です。障害の根本原因がアーキテクチャ上のリスクに起因するケースは多く、インシデント直後にWA Toolでレビューを実施することで、改善項目の優先度が実態に即した形で整理できます。

レビューオーナーの設定

WA Toolでは各ワークロードに「レビューオーナー（Review Owner）」をメールアドレスで設定できます。レビューオーナーは次の責任を担います。

• 定期レビューのスケジューリングと参加者招集
• 回答の最終確認と承認
• 改善計画の策定とバックログ登録
• マイルストーン作成による進捗の記録

レビューオーナーにはプラットフォームチームまたはアーキテクチャ委員会のメンバーを指定するケースが多く、開発チームリードを担当者とするケースも増えています。責任の所在を明確にしておくことが、定期レビューの定着には不可欠です。

レビュー前の準備チェックリスト

定期レビューを効率化するために、事前に以下の情報を収集しておくとスムーズに進みます。

• 前回マイルストーン以降の主な変更点（Gitログ・変更管理台帳）
• 直近のインシデントレポートとPostmortem
• Trusted Advisor の最新チェック結果（連携済みの場合は自動取得）
• コストエクスプローラーの月次推移レポート
• CloudTrailのAuditログ（セキュリティ質問回答の根拠として）

改善項目のバックログ管理

WA Toolのレビューで検出された改善項目（Improvement Items）は、そのままWA Tool内でも管理できますが、チケット管理システム（Jira / GitHub Issues / Linear 等）と連携して開発バックログに取り込む運用が推奨されます。

改善項目のバックログ化の際は、以下の情報を含めるとPJT管理しやすくなります。

• WA本柱・ベストプラクティスの識別子（例: REL 6 — Implement change management）
• リスク水準（High / Medium）
• 推定対応工数と担当チーム
• 対応期限（次回マイルストーン予定日）
• 対応後の検証手順

高リスク（High）の改善項目は次のスプリントに必ず取り込み、中リスク（Medium）は四半期バックログに登録するという運用ルールを設けることで、改善活動が形骸化するのを防げます。

リスク数をKPIとして追跡する

改善バックログを管理するにあたり、WA Toolのリスク数をエンジニアリングKPIとして定義することを推奨します。推奨するKPIの例を以下に示します。

• High Risk Ratio（HRR）：全ベストプラクティス項目に占めるHigh Riskの割合。四半期ごとの目標値を設定し、改善トレンドを計測する
• Risk Resolution Rate（RRR）：前回マイルストーンから今回マイルストーンの間に解消されたHigh Risk数。チームの改善速度を示す
• Days to Resolve（DTR）：High Risk検出から解消までの平均日数。改善サイクルの効率を計測する

これらのKPIをWA Tool APIで定期的に収集し、CloudWatchカスタムメトリクスやQuickSightダッシュボードに可視化することで、エンジニアリング組織の品質向上を定量的に管理できます。レビュー結果を「チームの評価指標」として活用する際は、改善への意欲を引き出すポジティブな設計が重要です。減点主義ではなく、改善件数を称賛する文化と組み合わせることで、Well-Architectedの定着化が促進されます。

複数アカウント・複数リージョンでの運用

AWS Organizationsを使ってマルチアカウント構成を運用している組織では、WA Toolのクロスアカウント共有機能を活用することで、各メンバーアカウントのレビュー結果を管理アカウントから一元確認できます。組織全体のリスク状況をCTO・CISOレベルで把握するガバナンス設計として非常に有効です。

東京（ap-northeast-1）をプライマリリージョンとしつつ、DR構成として大阪（ap-northeast-3）を使用している場合は、各リージョンでワークロードを登録するのではなく、リージョン情報をワークロードのメタデータとして記録し、Reliabilityピラーのマルチリージョン質問で適切に回答することを推奨します。WA Toolのワークロードはリージョン横断のアーキテクチャ全体を評価する単位として使うことが適切です。

AWS Organizations管理アカウントとメンバーアカウント間のWA Tool共有設定は、AWS Resource Access Manager（RAM）を通じて行います。共有設定を整備することで、各メンバーアカウントが独立してレビューを実施しつつ、管理アカウントで全体のリスク状況を俯瞰できる分散型ガバナンスが実現します。

7-2. 組織的な定着

Well-Architectedレビューは「ツールを使うこと」が目的ではありません。組織全体の文化として定着させてこそ、アーキテクチャ品質の継続的な向上が実現します。本節では、カスタムレンズ・マイルストーン・チーム文化という3つのアプローチから、組織への定着化を解説します。

カスタムレンズによる社内標準の強制

公式6本柱のフレームワークレンズは汎用性が高い反面、業界固有のコンプライアンス要件（PCI DSS・HIPAA・金融庁ガイドライン等）や自社のセキュリティポリシーには対応していない場合があります。カスタムレンズを活用することで、社内標準をWA Toolのレビュープロセスに直接組み込み、全開発チームに共通の評価基準を適用できます。

カスタムレンズで「強制」を実現する設計ポイントは以下のとおりです。

• 必須実装項目をベストプラクティスとして定義：セキュリティポリシー必須項目（例: 「全データベースの暗号化」「監査ログの90日保持」）をカスタムレンズの質問として定義する。未実装の場合にHigh Riskが計上される
• アーキテクチャ承認ゲートとしての活用：本番リリース前にカスタムレンズレビューを必須ステップとし、High Risk が0件になるまでリリースを承認しないプロセスを設ける
• 組織単位での共有：AWS OrganizationsのSharing機能（または直接ARN共有）を使って、複数のメンバーアカウントにカスタムレンズを展開し、全チームが同一の基準でレビューを受ける

マイルストーンによる経時改善の可視化

マイルストーンは単なるスナップショット機能に留まらず、組織への定着という観点でも強力なツールです。定期的にマイルストーンを作成することで、アーキテクチャ改善の進捗を時系列で可視化できます。

組織での活用例：

• 月次・四半期レポートへの組み込み：マイルストーン比較でHigh Risk数の推移を折れ線グラフ化し、マネジメント層への報告資料に含める。数値で改善を示せるため、アーキテクチャ改善活動への投資承認が得やすくなる
• 改善のゲーミフィケーション：四半期末にリスク削減数が多いチームを称える文化を設けることで、組織横断でのアーキテクチャ改善への動機付けが生まれる
• 技術負債のトレンド監視：High Risk数が増加トレンドを示している場合は、開発速度優先でアーキテクチャ品質が後回しにされているシグナルです。CTO・VPoEへのアラートとして機能させる

CCoEを軸としたチーム文化の醸成

Well-Architectedレビューを継続的な文化として根付かせるためには、Cloud Center of Excellence（CCoE）または類似の横断組織が重要な役割を果たします。

CCoEが存在しない組織では、アーキテクト委員会やギルド（技術横断コミュニティ）がこの役割を担うことが多いです。いずれの形式でも、Well-Architectedレビューを「外部から押し付けられる評価」ではなく「チームが自ら活用する改善ツール」として位置付けることが、定着の鍵となります。

チーム導入時のアンチパターン

組織への定着を妨げる典型的なアンチパターンとして、以下に注意してください。

• コンプライアンスのためだけのレビュー：監査対応でのみ実施し、改善計画を策定しない。ツールを使ったという記録だけが残り、アーキテクチャは改善されない
• アーキテクト一人でのレビュー：開発チームが参加せずにアーキテクト単独でレビューを完了させると、現場の実態と乖離した回答になり、改善項目も開発チームに腹落ちしない
• 高リスクの放置：High Riskが検出されても改善計画を立てないまま放置し、次のレビューでも同じリスクが計上される「慢性化」。マイルストーン比較で可視化し、経営層へのエスカレーションを明確化することが対策となる

Well-Architectedの成熟度モデル

Well-Architectedレビューの組織的な定着度は、一般的に以下の段階で進化します。自組織の現在地を把握することで、次のステップが明確になります。

多くの組織はLevel 2からLevel 3への遷移で停滞します。定期レビューを「プロジェクト」から「プロセス」に昇格させ、カレンダーに固定することが壁を越えるための最初のアクションです。

AWS Security Hubとの連携（発展）

より高い成熟度を目指す組織では、AWS Security Hub との連携も検討に値します。Security HubはWA Tool連携には対応していませんが、GuardDuty・Inspector・Macie・IAM Access Analyzerなどの検出結果を集約し、WA Securityピラーの回答根拠として活用できます。Security HubのCIS AWS Foundationsベンチマーク準拠スコアをWAレビューの補助資料として活用することで、Security本柱の回答に客観的な根拠を持たせることができます。

8. まとめと次のステップ

8-1. 本記事のまとめ

本記事では、AWS Well-Architected FrameworkとWA Toolを使った実レビュー運用の土台を解説しました。WA Frameworkが「なぜアーキテクチャを評価するのか」という問いに答えるものだとすれば、WA Toolは「継続的な改善をどう実現するか」を支えるためのプラットフォームです。両者を組み合わせることで、アーキテクチャの品質を継続的に高める組織的な仕組みが整います。以下に要点を整理します。

Well-Architected Frameworkの基本

• WA Frameworkは2015年提供開始のAWSアーキテクチャのベストプラクティス集。設計フェーズだけでなく稼働後も継続的な改善に使う
• 現在は6本柱（Operational Excellence / Security / Reliability / Performance Efficiency / Cost Optimization / Sustainability）。「5本柱」はSustainabilityが欠落した古い記述
• Sustainability（第6本柱）は2021年12月（re:Invent 2021）追加、WA Toolへの組み込みは2022年3月
• 2025年4月のリフレッシュで6本柱横断78の新ベストプラクティスが追加。Reliability本柱は2022年以来初の全面更新

WA Toolの活用

• WA Tool自体は無料。東京リージョン（ap-northeast-1）で2020年8月にGA
• ワークロードを登録し、レンズの質問に回答することでリスク（High/Medium）を可視化する
• 「回答なし（None of these）」はHigh Riskとして計上される。「該当しない（Not applicable）」はリスク計算から除外される
• 改善項目（Improvement Items）はチームのバックログと連携して計画的に対処する

カスタムレンズとマイルストーン

• カスタムレンズでは組織独自のコンプライアンス・セキュリティ統制をレンズ化して全チームに適用できる
• ワークロード毎に最大20レンズを追加可能（同時適用は5）。追加料金なし
• マイルストーンは時点スナップショット。ワークロード毎に最大100個まで保存でき、改善の経時比較・監査証跡に活用する

Trusted Advisor連携とIaC連携

• Trusted Advisor連携はBusinessまたはEnterpriseサポートプランが必須。Basic/Developerでは利用不可
• TA連携でセキュリティ・コスト・可用性のチェック結果が自動エビデンスとして付加され、レビュー工数を削減できる
• WA Tool APIとCDK/CloudFormation/CI/CDを組み合わせることで、ワークロード登録・マイルストーン作成をデプロイパイプラインに組み込める

運用定着のポイント

• 四半期ごとの定期レビュー＋インシデント後レビューの組み合わせが基本サイクル
• カスタムレンズをリリースゲートとして活用し、High Risk 0件を本番リリース条件にする組織も多い
• マイルストーンによるリスク推移の可視化で、マネジメント層への改善投資の説明責任を果たせる

8-2. 次のステップ

本記事（Vol1）では、WA ToolとWA Frameworkの基本的な使い方から、カスタムレンズ・マイルストーン・Trusted Advisor連携・IaC連携・運用定着という実践のコア部分を一通り解説しました。Vol1の内容をチームで共有し、まず1つのワークロードでWA Toolレビューを試行することが、具体的な最初の一歩になります。

WA FrameworkとWA Toolは、クラウドアーキテクチャを「継続的に改善し続けるプロセス」に変えるための強力な基盤です。設計品質の評価軸を組織全体で共有し、エンジニアリングの積み上げを可視化することで、技術的負債を計画的に返済できる組織が生まれます。

Vol2以降では以下のテーマを予定しています。

• Operational Excellence本柱の深掘り：CloudWatch・Systems Manager・EventBridgeを使った観測可能性の強化と運用自動化
• Security本柱の実装ガイド：IAM最小権限設計・CloudTrail/Config/GuardDutyによる多層防御の実践
• Reliability本柱の実装ガイド：マルチAZ/マルチリージョン構成・カオスエンジニアリング（AWS FIS）による耐障害性検証
• 大規模組織での運用設計：複数アカウント・複数リージョンにまたがるWAレビューのガバナンス設計
• AWS Security Hubとの統合：Trusted Advisorを超えたセキュリティポスチャの一元管理
• コスト最適化の実践：Savings Plans・Compute Optimizer・Cost Explorer APIを使った継続的なコスト削減サイクル
• パフォーマンス効率の計測：CloudWatchメトリクス・Container Insightsを活用したボトルネック特定と改善

Vol1で学んだ基礎知識と運用設計をもとに、Vol2では各本柱の実装レベルに踏み込みます。次回Vol2の公開をお待ちください。

▶ 次回 Vol2（予告）: Operational Excellence & Security 本柱の深掘り実装

▶ 関連: AWS マネジメント＆ガバナンス Vol1（Organizations / Control Tower）