aws-well-architected-review

Well-Architected レビュー

概要

コードと IaC からワークロードを把握し、稼働中のコーパスのインベントリを取得して、エビデンスに基づきフレームワークのすべての質問とベストプラクティスを評価し、リスクの高い順に整理し、アイゼンハワー方式で優先順位を付けたレポートをインラインで提示する、体系的な AWS Well-Architected Framework（WA Framework）レビューをガイドします。

フレームワークのコンテンツはスナップショットとして埋め込むのではなく、レビュー時に AWS の最新ドキュメントから取得します。確実に取得するには、AWS MCP サーバーのドキュメントリーダー（aws___read_documentation）を推奨します。利用できない場合は、環境の Web 取得ツールを使って、同じ docs.aws.amazon.com のページを HTTPS 経由で取得してください。ドキュメントにまったくアクセスできない場合は、内部知識に基づいて進め、フレームワークのインベントリを最新情報で検証できなかったことを明示してください。サポート対象のランタイムでは利用できないため、非公開または内部向けのベストプラクティス／WA ガイダンス MCP に依存しないでください。

詳細な手順はリファレンスファイルに記載されています。各手順で指示された際に、それぞれを読んでください。

• レビューのモード — モードの選択（full / quick / pillar-scoped / score）、トリガーフレーズ、スコアの出力形式
• 検出手順 — インフラストラクチャとアプリケーションアーキテクチャの検出
• 最新コーパスのインベントリ — ゲート付きの ACQUIRE_CORPUS ステージ：フレームワークの決定的な読み取り専用走査、コーパスの記録、検証ゲート
• 評価手順 — 固定済みマニフェストに基づくすべての BP の評価、ピラーごとの評価、集約ルール、カバレッジ監査
• レンズのガイダンス — Well-Architected レンズを適用するタイミングと方法
• リスク評価 — 影響度 × 発生可能性のマトリクスと、ピラー間のトレードオフ
• レポートテンプレート — レポート手順で使用するレポート全体の構成
• セキュリティに関する考慮事項 — ワークロードデータ、レビュー用ツール、検出事項、保存された成果物の安全な取り扱い

実行モデル

各ステップを開始する前に、セキュリティ上の考慮事項を読み、従ってください。ワークロードのコードやレビュー用ツールを操作する前に、シークレットのマスキング、HTTPS のみを使用した取得、最小権限、機密情報の取り扱いを読み込む必要があります。

完全なレビューは、ゲート付きの順序で実行します。各ステップには移行ゲートがあります。ゲートを通過していない場合、次のステップに進んだり、ステップを省略したりしてはなりません。ユーザーに提示する成果物は、インライン形式の完全なレポートひとつだけです。スクラッチファイル（実行ごとの作業ディレクトリ）は実行状態としてのみ使用し、納品物には含めません。また、そのパスをレポートに記載してはなりません。

デフォルトでは非対話型です。 ユーザーがレビューを明示的に依頼し、十分な範囲を提示している場合、ステップ間で確認を求めることなく、すべてのステップを最後まで実行してください。検出とリスク評価のチェックポイントは、ユーザーを停止させるものではなく、内部検証ゲートです。自分で検証して続行してください。ユーザーが対話型チェックポイントを明示的に求めた場合、または必要なスコープの判断を実際に推測できない場合（例：対象ピラーが曖昧な依頼）に限り、ユーザーに確認してください。

交渉不可の不変条件 — すべてのモード（full / quick / pillar-scoped / score）：

• ステップ 4（ACQUIRE_CORPUS）はモードに依存しません。すべてのモードで評価の前に最新のコーパスインベントリを取得して検証し、凍結したマニフェストに基づいて質問/BP を読み込みます。不完全または未検証のマニフェストに基づいて評価を開始してはなりません。どのモードでもステップ 4 を省略できません。
• 正規 ID のみを使用し、PILLAR##-BP## ID を捏造してはなりません。コーパスの取得で ID を生成できない場合は、独自に補うべき不足ではなく、表面化させるエラーです。

交渉不可の不変条件 — 完全なレビューのみ：

• 凍結したマニフェスト内の各 BP には、5 種類のステータスのうち、必ず 1 つだけを割り当てます。
• レポートテンプレートのすべてのセクションを含めてください（これは正式な項目一覧です。ステップ 7 の番号付き項目は、特に忘れてはならない一部であり、全項目ではありません。テンプレートでは、Executive Summary、Architecture Overview、Cross-Pillar Trade-offs、Next Steps なども必須です）。レポートはインラインで出力し、1 行目を # Well-Architected Review: とします。「ファイルを参照」、添付ファイル、スクラッチパスへの誘導は認められません。

ステップ 1：ワークロードのスコープを定義する

ユーザーが提示した情報からワークロードを特定します。

• ワークロード名と簡単な説明
• 分析対象のコードパッケージ/ディレクトリ（IaC、アプリケーションコード、CI/CD 設定）
• ビジネス上の重要度（critical、high、standard、low）
• 現在の課題（任意）

ユーザーがすでにアーキテクチャの詳細を提示している場合、または IaC のあるコードベースを扱っている場合は、質問せずに検出を進めてください。コードも IaC もなく、ユーザーがアーキテクチャを口頭で説明している場合は、その説明を証拠として使用してください。コードで検証できない検出事項には、「説明に基づく — コードで検証してください」と記載します。意味のあるレビューを行うのに十分な情報をユーザーがすでに提示している場合は、コードを求めてはなりません。

ユーザーの表現からレビューのモード（full / quick / pillar-scoped / score）を判断します。レビューのモードを参照してください。ワークロードが特定のレンズに該当するかを判断し、該当する場合はレンズのガイダンスを参照してください。

ステップ 2：インフラストラクチャの検出

検出手順を読み、従ってください。

ステップ 3：アプリケーションアーキテクチャの検出

検出手順に従って続行し、評価の前に内部の完全性ゲートも通過させてください。

ステップ 4：実データコーパスのインベントリを取得して凍結する（ACQUIRE_CORPUS ゲート）

実データコーパスのインベントリ手順を読み、従ってください。まず、このレビューでスクラッチ状態を保存する実行ごとの作業ディレクトリ、つまり以下で参照する questions.jsonl、best-practices.jsonl、manifest.json を格納する corpus/ フォルダーを作成します。次に、正規のフレームワークページを対象に、範囲を限定した読み取り専用の走査を行って、実データコーパスの完全なインベントリ（質問＋ベストプラクティスマニフェスト）を構築します（aws___read_documentation を優先してください。MCP を使用しない HTTPS フォールバックについてはリファレンスを参照してください）。各ページは直ちに構造化レコードに変換し、マニフェストを検証してください。

ゲート： corpus/manifest.json が valid: true を示すまで、ステップ 5 に進んではいけません。凍結されたマニフェストは、評価、カバレッジ監査、レポートで使用する質問セットと BP セットの唯一の正本です。

ステップ 5：凍結されたマニフェストに含まれるすべての BP を評価する

重要 — 短いレビューを作成しないでください。 最もよくある失敗は、BP の一部だけを引用して終わらせることです。完全なレビューでは、凍結されたマニフェストに含まれるすべての BP を、5 種類のステータスから 1 つ選び（根拠も添えて）評価する必要があります。

評価手順を読み、従ってください。手順には、凍結されたマニフェストに基づくピラーごとの評価、集計、モードごとの調整、カバレッジ監査（サブステップは 5a～5d とラベル付けされています）が定義されています。各 BP について、以下を評価してください。

• ステータス："Implemented"、"Partially Implemented"、"Not Implemented"、"Not Applicable"、"Cannot Determine" のいずれか 1 つのみ
• 根拠：具体的なファイルパスと行番号（または "Based on description"）
• 不足点：不足しているもの、または改善できる点
• リスク：不足点によって起こり得る問題

凍結されたマニフェストに含まれるすべてのピラーを、そのピラー名、プレフィックス、質問カテゴリを使用して評価してください。

ステップ 6：リスク評価

リスク評価手順を読み、従ってください。手順内のゲートも含まれます。

ステップ 7：レポートを作成する

モードゲート： スコアモードでは、レビューモードに記載されたスコアカード出力のみを出力してください。クイックレビューおよびピラー指定レビューでは、レビューモードに記載されたモードごとの調整を適用してください。レンズのみの依頼（ユーザーが単一の WA Lens を指定し、完全なフレームワークレビューを求めていない場合）では、単独のレンズレポートを作成してください。コアフレームワークの表は省略し、レンズのガイダンスに従って、レンズの所見セクションとレンズスコアカードを成果物とします。完全なレビューにレンズを適用する場合は、完全な構成を維持し、レンズの所見セクションを追加してください。それ以外、つまり完全なレビューの場合は、レポートテンプレートを読み、指定された構成をそのまま使用してレポートを作成してください。レポートテンプレートは必須セクションの正式な一覧です。以下は、能力の低いモデルが最も頻繁に省略する、特に重要な項目です（すべての必須項目を網羅していると見なさないでください）。

1. カバレッジ監査（評価手順のステップ 5d に基づく）。エグゼクティブサマリーより前に記載します
2. ピラーごとのスコア（1～5）を含むピラースコアカード
3. 質問ごとの評価表 — 凍結されたマニフェスト内のすべての質問を記載し、省略しないでください
4. 完全な BP 台帳 — 評価した BP ごとに 1 行を設け、ピラーごとの評価をそのまま連結します
5. リスク分類された所見（Critical／High は詳細に、Medium は簡潔に、Low は表形式で記載）
6. SMART 目標を含む、アイゼンハワー方式で優先順位付けした改善計画（最優先／計画／委任／延期）

レポートは最終回答に直接出力し、1 行目を # Well-Architected Review: にしてください。どのセクションもファイルに委ねてはいけません。

ステップ 8：フォローアップを提案する

レポートの提出後、次の内容を提案します。

次のいずれかをご希望ですか？

• 特定の柱について、分析を詳しく掘り下げる
• 特定の検出結果を修正するための IaC テンプレートを生成する
• 特定のアーキテクチャ変更に関する移行計画を作成する
• 特定の WA Lens とワークロードを詳しく比較する
• 継続的なコンプライアンスのための自動チェック（Config ルール、カスタムメトリクス）を生成する
• AWS コンソールで追跡するための WA Tool インポートデータを作成する

評価の指針

• マルチ AZ、暗号化、ロールバックに対応した CI/CD、モニタリング、自動スケーリングを備えたワークロードは成熟しています。大半の検出結果は重大な問題ではなく、改善点として扱ってください。
• 適切に構築されたワークロードについて、重大な検出結果をでっち上げてはいけません。警告を強めるより正確さを優先してください。
• ビジネス上の重要度が「低」または「標準」の場合は、よりシンプルなアーキテクチャを許容してください（内部ツールであれば単一リージョンで問題ありません）。
• ビジネス上の重要度が「重大」の場合は、より厳格な基準を適用してください（マルチリージョン DR、カオステスト、サブ分単位の RTO が求められます）。
• すべての検出結果に、必ずコード上の根拠を示してください。裏付けのない一般的な推奨事項を提示してはいけません。
• コードから判断できない場合は、「判断できません」と記載し、必要な実行時データやヒアリング内容を説明してください。
• 強みは明確に示してください。成熟したワークロードに対しては、批判だけでなく、その妥当性が確認されたと感じられるようにしてください。

セキュリティに関する考慮事項

レビュー用ツールを使用する前、検出結果を共有する前、または成果物を保存する前に、セキュリティに関する考慮事項を読み、指示に従ってください。