aws-well-architected-framework-review

メモ

非推奨です。 このスキルは、Agent Toolkit for AWS の aws-well-architected-review に置き換えられました。新機能の開発は受け付けていません。詳しくは issue #147 をご覧ください。

Well-Architected レビュー

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

ユーザーにワークロードについて説明してもらいます。

どのワークロードをレビューしますか？以下を共有してください。

• ワークロード名と簡単な説明
• 分析対象のコードパッケージ／ディレクトリ（IaC、アプリケーションコード、CI/CD 設定）
• ビジネス上の重要度（重大、高、標準、低）
• 現在の問題点（任意 — 問題だとすでに把握していること）

ユーザーがすでにアーキテクチャの詳細を提示している場合、または IaC を含むコードベースを対象としている場合は、プロンプトを省略して調査に進みます。

重要：分析対象のコードや IaC がない場合（例：ユーザーがアーキテクチャを口頭で説明する場合）は、提示された情報に基づいてレビューを進めます。アーキテクチャの説明に明示された記述を根拠として、完全なレポートを作成します。省略された詳細は不明として扱い、コントロールが存在しない根拠とはしません。検証できない実装の詳細には Cannot Determine と記載し、どのような証拠があれば確認できるかを述べます。また、意味のあるレビューを行うのに十分なコンテキストをユーザーがすでに提示している場合は、コードを求めないでください。

専門の WA Lens が適用されるか判断します。

• SaaS、サーバーレス、データ分析、機械学習、IoT、コンテナ、ゲーム、金融サービス、ヘルスケア

コードからレンズが明らかな場合（例：Lambda が多い → サーバーレス）、その旨を記載し、レンズ固有の質問を適用します。

ステップ 2：インフラストラクチャの調査

コードベース内のすべての Infrastructure as Code とデプロイ設定を分析します。

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

• CDK コード（TypeScript、Python、Java、Go）
• CloudFormation テンプレート（YAML、JSON）
• Terraform 設定（.tf ファイル）
• SAM／Serverless Framework テンプレート
• CI/CD パイプライン定義（CodePipeline、GitHub Actions など）
• モニタリング設定（CloudWatch アラーム、ダッシュボード）
• デプロイ設定（CodeDeploy、ECS のデプロイ設定）

各インフラストラクチャコンポーネントについて、以下を記録します。

• リソースの種類、論理名、設定
• 定義されているファイルパスと行番号
• セキュリティ関連の設定（IAM、暗号化、ネットワーク）
• レジリエンス関連の設定（マルチ AZ、バックアップ、スケーリング）
• コスト関連の設定（インスタンスタイプ、キャパシティモード）

ワークロードの主要な IaC の記法（CDK、CloudFormation、Terraform、SAM）を記録します。ステップ 6 では、この記法で各検出事項に対する Fix: ブロックを出力します。ワークロードに IaC がない場合は、修正ブロックが AWS CLI コマンドに置き換わることを記載します。

必ず、以下を示す PlantUML のアーキテクチャ図を作成してください。

• すべての主要コンポーネントとその関係
• データフローと外部依存関係
• 信頼境界とネットワーク境界

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

アーキテクチャパターンについて、アプリケーションコードを分析します。

• エントリーポイント（API ハンドラー、イベントプロセッサー、スケジュールされたタスク）
• サービス間の通信パターン（同期／非同期、再試行、タイムアウト、サーキットブレーカー）
• データアクセスパターン（クエリ、キャッシュ、接続管理）
• エラー処理とレジリエンスのパターン
• 認証／認可ロジック
• 可観測性の計装（ログ、トレース、メトリクス）

---STOP--- チェックポイント：調査完了 — 評価の前に検出事項を提示します。

ワークロードについて、以下のことが分かりました。

• インフラストラクチャ：{検出された IaC リソースの概要}
• アーキテクチャパターン：{検出された主要なパターン}
• 範囲：{分析したファイル／リソースの数}

57 項目の完全な評価に進みますか？それとも範囲を調整しますか？

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

ステップ 4：すべての WA フレームワークの質問をコードの証拠に基づいて評価する

重大 — 短いレビューを作成しないでください。 最もよくある失敗は、20～30 件の BP を引用した時点で終えてしまうことです。参照コーパスには、57 件の質問にまたがる 307 件の BP が含まれています。実際に完全なレビューを行うには、307 件すべてを評価する必要があります。各 BP に次の 5 つのステータスのいずれかを付与してください：Implemented、Partially Implemented、Not Implemented、Not Applicable、Cannot Determine（根拠を記載）。BP の引用が 200 件未満の場合は、レビューはまだ完了していません。すべての BP を確認するまで繰り返してください。

Well-Architected Framework の 57 件すべての質問に照らしてワークロードを評価してください。質問ごとに、次の項目を記載してください。

• ステータス：「Implemented」、「Partially Implemented」、「Not Implemented」、「Not Applicable」、「Cannot Determine」
• 証拠：具体的なファイルパスと行番号
• ギャップ：不足している点、または改善できる点
• リスク：ギャップによって発生する可能性がある問題

証拠の十分性ゲート

ステータスを付与する前に、次のゲートを適用してください。

• Implemented — BP が完全に実施されていることを示す明確な証拠があります。
• Partially Implemented — BP の一部が実施されていることを示す明確な証拠があり、具体的なギャップも特定されています。
• Not Implemented — 管理策が存在しないことを明確に示す証拠があるか、その管理策が記載されているはずの権威性があり十分に網羅的な情報源を確認した結果、記載がありません。
• Not Applicable — BP がワークロードの対象範囲外です。ワークロード固有の理由を記載してください。
• Cannot Determine — 入手できる証拠が不足している、結論を出せない、実行時にしか得られない、または調査対象範囲外です。判断に必要なアーティファクト、メトリクス、設定、またはインタビューでの回答を具体的に示してください。

証拠がないことは、存在しないことの証拠ではありません。管理策に触れていない口頭説明や、その管理策について権威性のないコード／IaC は、必ず Not Implemented ではなく Cannot Determine としてください。たとえば、「バックアップが設定されていない」は Not Implemented の根拠になりますが、管理目標や TCO 分析への言及がないことは Cannot Determine の根拠にしかなりません。

Implemented、Not Applicable、Cannot Determine の重大度は空欄にしてください。Cannot Determine の場合は、改善指摘ではなく確認アクションを記載してください。不確実な点を High または Critical の指摘に変換しないでください。

6 つの柱とその質問：

• 運用上の優秀性（OPS 1～11）：組織、可観測性、デプロイのリスク、運用準備、イベント管理、進化
• セキュリティ（SEC 1～11）：基盤、ID、権限、検出、ネットワーク／コンピューティングの保護、データ保護、インシデント対応、アプリケーションセキュリティ
• 信頼性（REL 1～13）：クォータ、ネットワークトポロジー、サービスアーキテクチャ、分散システム、モニタリング、スケーリング、変更管理、バックアップ、障害分離、DR
• パフォーマンス効率（PERF 1～5）：リソースの選定、コンピューティング、データ／ストレージ、ネットワーク、最適化プロセス
• コスト最適化（COST 1～11）：財務管理、使用状況のガバナンス、モニタリング、廃止、サービスの選定、適正規模化、料金モデル、データ転送、需要管理、進化
• サステナビリティ（SUS 1～6）：リージョンの選定、需要との整合、アーキテクチャパターン、データ管理、ハードウェアの選定、組織プロセス

レビューの深さ

評価を始める前に、ユーザーの依頼に基づいてレビューの深さを決定します。

フルレビュー（「WA review」「full review」「comprehensive」と指定された場合のデフォルト）：

• 57 個の質問をすべて評価します
• ピラーごとに references/pillars/{pillar-slug}.md を読み込みます（並列サブエージェントのディスパッチについてはステップ 4b を参照）。各ピラーファイルには、そのピラーに関するすべての質問とベストプラクティスが記載されています
• 指摘事項では、具体的な BP ID を引用します（例：「SEC03-BP02：権限境界が定義されていません」）

クイックレビュー（「quick review」「high-level」「summary」と指定された場合、または時間が限られている場合）：

• 質問レベルのみで 57 個の質問をすべて評価します（個々の BP 参照ファイルは読み込みません）
• 上記のピラー概要を使い、コードから確認できる内容に基づいて各質問を評価します
• 明らかな不足を指摘しますが、すべての BP を網羅的に確認することはしません
• より迅速で詳細度は低くなりますが、すべてのピラーを対象とします

ピラーを限定したレビュー（例：「セキュリティと信頼性だけをレビューして」「セキュリティを評価して」「単一障害点を特定して」「コストを最適化して」など、特定のピラーをユーザーが指定した場合）：

• 指定されたピラーの質問のみを評価します
• ドメイン固有の調査手順（一般的なインフラストラクチャのスキャンを超える、専門的な証拠収集）を適用するため、references/pillar-playbooks/{pillar}.md を読み込みます
• 指定されたピラーに対してフルレビューの深さを適用します（BP 参照ファイルを読み込みます）
• 他のピラーはすべて対象外とし、重大な横断的問題が明らかな場合を除いて言及しません
• ドメイン固有のスコアカードを含む、ピラーに特化したレポートを作成します（例：セキュリティ：6 ドメインのスコアカード、信頼性：SPOF 表＋テスト計画）

ピラーを限定したレビューを示すトリガーフレーズ：

• セキュリティ：「security assessment」「IAM review」「encryption audit」「assess my security posture」
• 信頼性：「reliability plan」「identify SPOFs」「assess disaster recovery」「fault tolerance review」
• コスト：「cost optimization」「right-sizing review」「reduce AWS spend」「cost assessment」
• パフォーマンス：「performance assessment」「latency analysis」「bottleneck identification」
• サステナビリティ：「sustainability review」「carbon footprint」「resource efficiency audit」
• オペレーショナルエクセレンス：「operational assessment」「CI/CD review」「observability audit」

スコアモード（「score」「grade」「scorecard」「matrix」「just give me a number」と指定された場合）：

• 指定されたパスのコードベースを分析します
• 57 個の質問すべてを対象に、クイックスキャンを実行します（BP 参照ファイルは読み込みません）
• 構造化されたスコアカードと、絞り込んだ指摘事項のみを出力します。詳細な説明を含むレポートは出力しません
• 深刻度のパラメーターに従います：
  • 「critical only」→ 重大な指摘事項のみを表示します
  • 「critical and high」→ 重大および高の指摘事項を表示します
  • 「all」（未指定の場合のデフォルト）→ 重大、高、中、低の指摘事項を表示します
• 出力形式：

## WA Score: {workload_name}

**Overall: {X.X}/5** | OPS: {}/5 | SEC: {}/5 | REL: {}/5 | PERF: {}/5 | COST: {}/5 | SUS: {}/5

| Pillar | Score | Critical | High | Medium | Low |
|--------|-------|----------|------|--------|-----|
| Operational Excellence | {1-5} | {n} | {n} | {n} | {n} |
| Security | {1-5} | {n} | {n} | {n} | {n} |
| Reliability | {1-5} | {n} | {n} | {n} | {n} |
| Performance Efficiency | {1-5} | {n} | {n} | {n} | {n} |
| Cost Optimization | {1-5} | {n} | {n} | {n} | {n} |
| Sustainability | {1-5} | {n} | {n} | {n} | {n} |

### Findings ({depth} and above)
| # | Pillar | Severity | Finding | Evidence |
|---|--------|----------|---------|----------|
| 1 | {pillar} | {Critical/High/...} | {one-line finding} | {file:line} |
...

### Summary
{1-2 sentence takeaway: overall posture + single most impactful action}

トリガーフレーズ：「score my app」「WA scorecard」「grade this」「give me a score matrix」「how does my architecture score」

不明な場合は、次のように尋ねます：

フルレビュー（質問ごとに BP レベルで詳細に分析します。網羅的ですが時間がかかります）、クイックレビュー（質問レベルで評価します。より迅速です）、それともスコア（スコアカードと主な指摘事項のみ）をご希望ですか？

網羅性を確保する戦略 — まずマニフェスト、次に柱ごとのファイル

完全なレビューの目的は、BP レベルで網羅的にカバーすることです。 これを確実に実現するため、参照コーパスは3つのレイヤーで提供されています。

1. references/manifest.md（約24 KB）— すべての BP ID と1行のタイトルを記載した軽量なカタログです。完全なレビューを行う場合は、必ず最初にこのファイルを読み込んでください。引用対象となる全307件の BP が一覧になっています。
2. references/pillars/{pillar-slug}.md（6ファイル、各約150～580 KB）— 1つの柱に関するすべての質問と BP の全文をまとめた、柱ごとの参照ファイルです。BP の詳細（実装ガイダンス、アンチパターン、リソース）を確認するには、これらを読み込みます。
3. references/pillar-playbooks/{pillar}.md（6ファイル、各約3～5 KB）— 各柱に特化した証拠収集ガイドです。調査するリソース、HIGH RISK としてフラグを付けるパターン、柱ごとのレポート形式が記載されています。完全レビューの各サブエージェントは、汎用的な BP の言い換えではなく、具体的なファイルと行番号を示す証拠に基づいて所見をまとめられるよう、担当する柱のプレイブックを読み込みます（ステップ4b）。

完全レビューで必須となる読み込みパターン

ステップ4a — マニフェストを読み込む（必須、Read 呼び出し1回）：

Read: references/manifest.md

これにより、すべての BP ID とタイトルを約24 KBで確認できます。

ステップ4b — 並列で柱ごとのサブエージェントを6つ起動する（網羅的なレビューに必須）：

このパターンを採用する理由： 1つのエージェントに307件すべての BP の列挙を依頼すると、回答の途中で必ず停止します。部分的な一覧を返し、プロンプトの強さ、取得方法（ローカルファイル、MCP、ハイブリッド）、あるいは「307件すべてを評価する」という明示的な指示にかかわらず、レビューを完了したものとして扱います。制約はモデルが簡潔さを優先する傾向にあり、参照資料の不足ではないため、より強いプロンプトを使っても解決しません。

解決策： サブエージェントごとに範囲を絞ります。1つのエージェントが1つの柱をレビューすれば、ほかの柱とコンテキストを取り合うことなく、その柱の BP 30～55件を列挙できます。柱ごとに1つ、計6つのサブエージェントを並列で起動することで、307件すべての BP を網羅できます。evals/cli_effectiveness/ のハーネスを使って、実行環境でその違いを測定してください。

6つすべての Task 呼び出しを1ターンで（並列実行として）行います。最上位の集約エージェントが言い換えずに所見をそのまま統合できるよう、各サブエージェントは必ず構造化された Markdown テーブルを返す必要があります。

必須の返却形式（すべてのサブエージェント）：

## {Pillar} Findings

| BP ID | Status | Severity | Evidence | Recommendation |
|-------|--------|----------|----------|-----------------|
| SEC03-BP02 | Not Implemented | High | No permission boundaries found in cdk/iam.ts | Add IAM permission boundaries per role |
| SEC04-BP01 | Partially Implemented | Medium | CloudTrail on, but no S3 access logging | Enable S3 server access logging |
| ...one row per BP evaluated in this pillar... |

行の要件：

• 評価した BP ごとに1行（柱ごとに30～55行を目安とし、柱のファイルにあるすべての BP を必ず網羅すること）
• Status：Implemented / Partially Implemented / Not Implemented / Not Applicable / Cannot Determine のいずれか1つを使用
• Severity：Critical / High / Medium / Low（Implemented／Not Applicable／Cannot Determine の場合は空欄）
• Evidence：コードを分析した場合は具体的なファイルと行番号、口頭でレビューした場合は明示的に引用した事実、または Cannot Determine — need {specific evidence} を記載
• BP ID は正規の PILLAR##-BP## 形式のみを使用

各柱のサブエージェント向けプロンプトに、次の調整ルールをそのまま追加してください。

証拠の十分性に関する基準を適用してください。情報が省略されている、または判断できない場合は Not Implemented ではなく Cannot Determine とします。Not Implemented を使用するのは、コントロールが明示的に存在しない場合、または権威ある情報源でコントロールの記載が必須なのに記載がない場合に限ります。Cannot Determine の場合は Severity を空欄にし、必要となる具体的な証拠を記載してください。

起動テンプレート：

Task(subagent_type="general-purpose",
     description="Review Operational Excellence",
     prompt="Read references/pillars/operational-excellence.md and references/pillar-playbooks/operational-excellence.md (domain-specific evidence-collection checklist: what to examine and what to flag as HIGH RISK), then review the following workload ONLY for the OPS pillar. Enumerate EVERY BP in the pillar file (all 30+ BPs) — do not filter to 'top issues'. Return findings as the mandatory markdown table (columns: BP ID | Status | Severity | Evidence | Recommendation) with one row per BP. Do NOT prepend narrative summary text before the table. Workload: {workload description + code}")

Task(subagent_type="general-purpose",
     description="Review Security",
     prompt="Read references/pillars/security.md and references/pillar-playbooks/security.md (domain-specific evidence-collection checklist), then review the workload ONLY for the SEC pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Reliability",
     prompt="Read references/pillars/reliability.md and references/pillar-playbooks/reliability.md (domain-specific evidence-collection checklist), then review the workload ONLY for the REL pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Performance Efficiency",
     prompt="Read references/pillars/performance-efficiency.md and references/pillar-playbooks/performance-efficiency.md (domain-specific evidence-collection checklist), then review the workload ONLY for the PERF pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Cost Optimization",
     prompt="Read references/pillars/cost-optimization.md and references/pillar-playbooks/cost-optimization.md (domain-specific evidence-collection checklist), then review the workload ONLY for the COST pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Sustainability",
     prompt="Read references/pillars/sustainability.md and references/pillar-playbooks/sustainability.md (domain-specific evidence-collection checklist), then review the workload ONLY for the SUS pillar. [same table format, every BP as a row] Workload: {workload}")

合計：1ターンで Task 呼び出しを6回行います。 各サブエージェントは独立したコンテキストで実行されるため、ほかのサブエージェントの作業を妨げずに網羅的なレビューができます。統一されたテーブル形式なら、集約は解釈を加えた要約ではなく、機械的な結合で済みます。サブエージェントが文章形式で出力すると、集約エージェントが冗長と判断した引用を省いてしまうおそれがあります。 コスト／レイテンシ： ディスパッチでは、各サブエージェントが作業コンテキストを複製するため、単一エージェントによるレビューよりも大幅に多くのトークンを消費します。サブエージェントは並行して実行されるため、実時間は6つ分の合計ではなく、最も時間のかかる単一の柱によって決まります。ユーザーは網羅性とコストを引き換えにすることになります。evals/cli_effectiveness/ のハーネスを使い、ご自身のランタイムで両方を測定してください。

サブエージェントへのディスパッチを省略する場合：

• ユーザーが明示的に 簡易レビュー／スコアモード／柱を限定したレビュー を依頼した場合 — これらのモードでは単一エージェントを使用します
• 追加のトークン消費を許容できない コスト制約のある 環境の場合 — 単一エージェントでレビューを行いますが、307 BP のすべてではなく一部のみを対象としていることを、ユーザーに正直に伝えてください

ステップ4c — サブエージェントの指摘を集約する（引用を原文どおり保持）：

6つのサブエージェントすべてから結果が返されたら、指摘事項を1つの構造化レポートに統合します。重要： 各サブエージェントが提示した BP の引用をすべて保持してください。集約ステップは統合であり、要約ではありません。サブエージェントが提示した BP の引用を言い換えたり、グループ化したり、省略したりしないでください。網羅性が失われやすいのは、レポートを組み立てる段階です。サブエージェントはコーパス全体を調査しますが、単純に集約すると、その一部しか最終レポートに反映されないことがあります。

集約ルール — 以下のすべてに従ってください：

1. 完全な BP 台帳が必要です。 レポートには「完全な BP 台帳」セクション（ステップ6を参照）を必ず含め、すべてのサブエージェントが提示した BP とステータスの組み合わせごとに1行を記載してください。サブエージェントAが SEC03-BP02 を未実装として提示した場合、その行を台帳に原文どおり記載します。言い換えは禁止です。
2. 柱ごとに圧縮しないでください。 最終出力で、サブエージェントが提示した45件の BP 引用を「柱ごとの上位5件の指摘」に減らしてはいけません。引用された BP はすべて台帳に記載します。重大度の高い指摘は、「重大および高リスクの指摘」セクションにも詳細を記載しますが、これは台帳への記載に加えて行うものであり、台帳の代わりにしてはいけません。
3. 記述前に件数を確認してください。 返答する前に、組み立てた草案内の BP ID（PILLAR##-BP## 形式）を数えてください。件数がサブエージェントの引用数の合計より少ない場合は、一部を漏らしています。戻って追加してください。
4. 複数の柱にまたがるパターンと優先順位付け は、台帳を参照する追加の分析です。台帳の代わりにはなりません。

BP の引用ごとに、台帳の行には次のいずれかを記載します。

• 実装済み — 作業内容がこの BP を実証している（BP と証拠を提示）
• 部分的に実装済み — 一部は網羅されていますが、ギャップが存在する（BP とギャップを提示）
• 未実装 — 作業内容にこの BP が欠けていることを、明示的な証拠または信頼できる証拠が示している
• 該当なし — この BP は作業の文脈に当てはまらない（理由を簡潔に説明）
• 判定不能 — 判断するための証拠が不十分（必要な具体的証拠を明記）

網羅性の要件 — 完全なレビューでは、307件すべての BP を評価する必要があります。各 BP に5つのステータスのいずれかを付与します。判定不能 も評価済みの網羅性に含まれます。網羅的な網羅性の確保に、確定的なステータスの捏造は必要ありません。証拠に裏付けられた不在を「未実装」とすることは、有効で価値のある指摘です。

ステップ 4d — 必須の網羅性監査（省略しないでください）

最終レポートを作成する前に、必ず自己監査を実施し、網羅性が不十分な場合は繰り返してください。

1. カウント：これまでに評価した一意の BP ID はいくつですか（正規の PILLAR##-BP## 形式）？ 5 つすべてのステータス（Implemented、Partially Implemented、Not Implemented、Not Applicable、Cannot Determine）をカウントしてください。
2. 目標と比較：完全なレビューでは、マニフェストにある307 件すべての BPを評価します。それより少ない場合は不完全です。
3. 評価済みの件数が 307 件に満たない場合、最終レポートに進んではいけません。代わりに、次の手順を繰り返してください。
   • 評価済みの集合を、references/manifest.md にある 307 件すべての BP と照合します。
   • 未評価の BP ごとに、まだ読み込んでいない場合は対応するピラーファイルを読み込み、そのうえでエントリー（Implemented／Partially Implemented／Not Implemented／N/A／Cannot Determine）を追加します。
   • 件数を再確認します。
4. 307 件すべての BP にエントリーが追加されるまで繰り返します。BP が実際に N/A の場合（例：コンテナワークロードに対するサーバーレス固有の BP）は、根拠を 1 行で記載して N/A とします。黙って省略しないでください。

**重要な理由：**一般的なエージェントは、最も注目される 20～30 件の調査結果を挙げて終了しがちです。それでは表面的なレビューとなり、全体に関わる不備を見落とします。WA コーパスの価値は網羅性にあります。すべての BP を評価し、すべてのギャップを明らかにしてください。WA レビューに料金を支払うお客様が期待しているのは、モデルがすぐに思いつく項目だけではなく、307 件すべてを対象とする評価です。

監査出力の形式（最終レポートではエグゼクティブサマリーの前に記載してください）。

## Coverage audit
- BPs evaluated: {count} / 307
- Iterations performed: {N}
- Status distribution: {implemented} Implemented, {partial} Partial, {not_impl} Not Implemented, {na} N/A, {cannot_determine} Cannot Determine

BPs evaluated が 307 未満の場合、レビューは完了していません。ステップ 4d に戻ってください。

簡潔さを重視する場合 — クイックレビューモード

ユーザーがクイックレビュー、概要、スコアを明示的に求めている場合、または時間に制約がある場合は、references/manifest.md（24 KB）のみを読み込み、ピラーファイルを読み込まずに、質問レベルまたは ID で BP を引用してください。これにより正規の BP ID は確認できますが、実装の詳細な内容は省略されます。

ピラーを限定したレビュー

単一のピラーを対象にレビューする場合は、references/manifest.md とそのピラーのファイルのみを読み込みます（例：references/pillars/security.md）。

WA レンズを適用する場合

レンズは追加要素であり、ドメイン固有のベストプラクティスを加えて、コアの57問フレームワークを拡張します。フレームワークの質問に置き換わるものではありません。

レンズを適用する場合：

• ワークロードがレンズの対象ドメインに明確に該当する場合（例：Lambda が中心 → サーバーレス、LLM ベース → 生成 AI）
• ユーザーがレンズ固有のレビューを明示的に依頼した場合

適用方法：

• まず、コアフレームワークの評価（全57問）を完了します
• 次に、references/lenses/{lens-name}/ から該当するレンズを読み込み、レンズ固有の追加ベストプラクティスを評価します
• レンズの評価結果は、コアの評価結果の後に別のセクションとして報告します

ユーザーがレンズのレビューのみを依頼した場合（例：「サーバーレスレンズに照らしてアプリをレビューしてください」）も有効です。その場合は、レンズのリファレンスのみを読み込み、それらに照らして評価します。

利用可能なレンズ：

• references/lenses/serverless-applications/ — Lambda、API Gateway、Step Functions、イベント駆動型
• references/lenses/generative-ai/ — LLM ワークロード、RAG、ファインチューニング、プロンプトエンジニアリング
• references/lenses/agentic-ai/ — AI エージェント、オーケストレーション、ツール利用、ガードレール
• references/lenses/responsible-ai/ — 公平性、説明可能性、ガバナンス、モニタリング
• references/lenses/hybrid-networking/ — Direct Connect、VPN、Transit Gateway、DNS
• references/lenses/migration/ — 柱ごとの評価、動員、移行フェーズ
• references/lenses/devops-guidance/ — CI/CD、自動化されたガバナンス、開発ライフサイクル、可観測性、セキュリティテスト
• references/lenses/machine-learning/ — ML ライフサイクル（MLOPS）、モデルのトレーニング／デプロイ、データエンジニアリング、責任ある ML
• references/lenses/data-analytics/ — データパイプライン、ガバナンス、データカタログ、リネージ、分析のパフォーマンスとコスト
• references/lenses/games-industry/ — ゲームのバックエンド、リアルタイムマルチプレイヤー、プレイヤーデータ、ライブオペレーション
• references/lenses/saas/ — マルチテナンシー、テナント分離、オンボーディング、使用量計測、ティア設定
• references/lenses/financial-services/ — FSI ワークロードにおける規制コンプライアンス、データレジデンシー、レジリエンス、監査可能性
• references/lenses/life-sciences/ — GxP、バリデーション済みシステム、臨床／研究データ、規制コンプライアンス
• references/lenses/end-user-computing/ — 仮想デスクトップ／アプリ、ストリーミング、アイデンティティ、エンドポイント配信
• references/lenses/supply-chain/ — サプライチェーンデータ、統合、トレーサビリティ、レジリエンス
• references/lenses/video-streaming-advertising/ — 動画パイプライン、ストリーミング配信、アドテク、収益化
• references/lenses/telco/ — 通信ネットワークのワークロード、5G／エッジ、OSS／BSS、キャリアグレードの信頼性
• references/lenses/sap/ — AWS 上の SAP、S/4HANA、HANA データベース、SAP ランドスケープのレジリエンス
• references/lenses/modern-industrial-data-technology/ — 産業データプラットフォーム、OT／IT の融合、製造分析
• references/lenses/microsoft-workloads/ — AWS 上の Windows Server、SQL Server、Active Directory、.NET
• references/lenses/connected-mobility/ — コネクテッドカー、テレマティクス、車両群データ、自動車プラットフォーム
• references/lenses/healthcare-industry/ — HIPAA、臨床データ、相互運用性、患者のプライバシー
• references/lenses/container-build/ — コンテナイメージのビルド、サプライチェーンセキュリティ、レジストリ、CI/CD
• references/lenses/high-performance-computing/ — HPC クラスター、並列ワークロード、スケジューリング、低レイテンシネットワーキング
• references/lenses/streaming-media/ — メディアストリーミング、ライブ／VOD 配信、エンコーディング、コンテンツワークフロー
• references/lenses/iot/ — IoT デバイス、テレメトリ、エッジコンピューティング、デバイス群のプロビジョニング、OTA 更新
• references/lenses/government/ — 公共部門、プライバシー・バイ・デザイン、コンプライアンス、リアルタイムセキュリティ
• references/lenses/mergers-and-acquisitions/ — M&A デューデリジェンス、マルチアカウント／マルチクラウドのガバナンス、統合、技術的負債、買収後のコストとセキュリティ
• references/lenses/maori-data/ — Māori データガバナンス、データ主権、Te Ao Māori の原則、先住民データの保護と保持

ステップ 5：リスク評価

各指摘事項について、影響度 × 発生可能性で評価します。

影響度：軽微（影響範囲が限定的） | 中程度（一部のユーザーに影響） | 重大（全面的な停止、データ損失、規制違反）

発生可能性：低（特定の条件が必要） | 中（通常の運用下で発生する可能性がある） | 高（よくある障害パターン、制御が不十分）

影響度	発生可能性	リスクレベル
重大	高	重大
重大	中	高
重大	低	高
中程度	高	高
中程度	中	中
中程度	低	中
軽微	高	中
軽微	中	低
軽微	低	低

柱をまたぐ競合を特定します。

• パフォーマンスに影響するセキュリティ制御
• 信頼性を低下させるコスト最適化
• コストを増加させる信頼性パターン

---STOP--- チェックポイント：リスク評価が完了しました。レポートを作成する前に、指摘事項を確認してください。

評価が完了しました。概要は次のとおりです。

• 重大な指摘事項：{count}
• 高リスクの指摘事項：{count}
• 中リスクの指摘事項：{count}
• 低リスクの指摘事項：{count}
• 柱をまたぐ競合：{count}

完全なレポートを作成しますか。それとも、先に特定の指摘事項について話し合いますか？

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

ステップ 6：レポートの作成

以下の構成でレポートを出力します。

# Well-Architected Review: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Workload**: {name}
- **Business Criticality**: {level}
- **Lens Applied**: {lens or "General"}
- **Packages Analyzed**: {list}
- **Questions Assessed**: 57/57
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Maturity**: {1-5} — {one-line justification}

## Architecture Overview
{PlantUML diagram}
{Brief description of architecture, key services, data flows}

## Pillar Scorecard
| Pillar | Score (1-5) | Questions Assessed | Key Strength | Key Gap |
|--------|-------------|-------------------|--------------|---------|
| Operational Excellence | {score} | 11/11 | {strength} | {gap} |
| Security | {score} | 11/11 | {strength} | {gap} |
| Reliability | {score} | 13/13 | {strength} | {gap} |
| Performance Efficiency | {score} | 5/5 | {strength} | {gap} |
| Cost Optimization | {score} | 11/11 | {strength} | {gap} |
| Sustainability | {score} | 6/6 | {strength} | {gap} |

## Per-Question Assessment
| ID | Question | Status | Risk Level | Key Evidence |
|----|----------|--------|------------|--------------|
| OPS 1 | Priorities | {status} | {risk or N/A} | {evidence} |
| OPS 2 | Organization structure | {status} | {risk or N/A} | {evidence} |
| ... | ... | ... | ... | ... |
| SUS 6 | Process and culture | {status} | {risk or N/A} | {evidence} |

{Complete this table for all 57 questions — do not truncate}

## Full BP Ledger (MANDATORY)

**This section MUST list every BP citation produced by every subagent.** Concatenate all 6 subagent tables here, sorted by pillar then BP ID. Do NOT filter, cluster, or paraphrase. If a subagent surfaced 45 BPs for its pillar, this ledger shows 45 rows for that pillar. Target row count: 250-307 (one row per BP evaluated across all pillars).

This section is where the subagents' coverage actually reaches the user. Skipping or truncating it discards most of what they surfaced, however complete their tables were. **Do not skip this section.**

| BP ID | Pillar | Status | Severity | Evidence | Recommendation |
|-------|--------|--------|----------|----------|-----------------|
| OPS01-BP01 | Operational Excellence | {status} | {severity or blank} | {evidence} | {recommendation} |
| OPS01-BP02 | Operational Excellence | {status} | {severity or blank} | {evidence} | {recommendation} |
| ... | ... | ... | ... | ... | ... |
| SUS06-BP05 | Sustainability | {status} | {severity or blank} | {evidence} | {recommendation} |

{After writing this table, count the rows and confirm the count matches the sum of subagent rows. If not, you dropped citations — go back and add them.}

## Critical and High Risk Findings
{For each: ID, pillar, title, description, evidence (file:line), impact assessment, recommendation, **Fix:** block (see "Fix blocks" below), effort, AWS services. This section EXPANDS on rows in the Full BP Ledger — it does NOT replace them.}

## Medium Risk Findings
{Same format, condensed — each finding still carries its **Fix:** block. Also references ledger rows.}

## Low Risk Findings
{Summary table: ID | Pillar | Title | Recommendation. Also references ledger rows.}

## Cross-Pillar Trade-offs
{Conflicts between pillars and recommended resolution}

## Prioritize Improvements — Eisenhower Matrix

Not all findings should be addressed at once. Focus on a selected number of issues that make the most business impact and are easiest to implement. Then iterate.

Classify each finding by **importance** (business value) and **effort** (time, complexity, headcount):

    重要度：高
         │

┌─────────┼─────────┐ │ すぐに │ 計画 │ │ 着手 │ │ │ │ │ ───┼─────────┼─────────┼─── │ │ │ │委任 │ 先送り │ │ │ │ └─────────┼─────────┘ │ 重要度：低 工数：低 工数：高

| Quadrant | Action | Findings |
|----------|--------|----------|
| **Do First** (High Importance, Low Effort) | Implement immediately | {finding IDs} |
| **Plan** (High Importance, High Effort) | Schedule in roadmap, break into phases | {finding IDs} |
| **Delegate** (Low Importance, Low Effort) | Batch together, assign to available team member | {finding IDs} |
| **Defer** (Low Importance, High Effort) | Revisit in next iteration | {finding IDs} |

### Solution Characteristics

For each solution in "Do First" and "Plan":
- **SMART goal**: Specific, Measurable, Achievable, Relevant, Time-bound
- **Owner**: Identify who is responsible
- **Simple over complex**: Choose the simplest solution unless complexity is a non-negotiable requirement
- **Two-way door decisions**: Solutions should be extensible and evolve over time — avoid static solutions that cannot adapt
- **Pattern-based**: Target solutions that can be codified, reused, and re-shared (reference AWS Architecture Center)

## Prioritized Remediation Plan

### Quick Wins (< 1 week) — "Do First" quadrant
| Finding | Action | SMART Goal | Owner Suggestion | Effort |
|---------|--------|-----------|-----------------|--------|
{Config changes, enabling features, adding tags/alarms — simple, high-impact}

### Foundation (1-4 weeks) — "Plan" quadrant
| Finding | Action | Phases | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Multi-AZ, CI/CD improvements, monitoring, caching — phased approach}

### Strategic (1-3 months) — "Plan" quadrant (complex)
| Finding | Action | Phases | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{DR, re-architecture, compliance programs — two-way door design}

### Deferred — Revisit Next Iteration
{Findings in "Delegate" and "Defer" quadrants with brief justification for deferral}

## Next Steps
{Top 5 concrete actions from the "Do First" quadrant — the team should start this week}

修正ブロック — コピーしてすぐ使える修正スニペット

レポート内の🔴重大／高リスク、および🟡中リスクの指摘事項には、すべて**修正：**ブロックを含める必要があります。これは、ユーザーが自分で適用できる、最小限のコピーしてすぐ使える修正スニペットです。

• 言語を一致させる。 ステップ 2 で記録された主要な IaC の方言（CDK／CloudFormation／Terraform／SAM）でスニペットを出力します。ワークロードに IaC がない場合（例：口頭でのレビュー）は、同等の AWS CLI コマンドを使用します。
• 証拠に基づく。 情報源が利用可能な場合は、汎用的なプレースホルダーではなく、指摘事項の証拠にある実際のリソース名と識別子を使用します。
• 最小限にする。 ギャップを解消するために必要な行だけを含め、変更されない周辺設定はコメントで省略します。
• レポート内にとどめる。 修正はユーザーが確認して適用できるよう、レポートに記載します。ユーザーのコードベースに適用したり、差分／パッチとして出力したりしないでください（リポジトリ設計の原則：コードの変更ではなく、レビューとガイダンスを提供します）。JSON 成果物の recommendation フィールド（ステップ 6b）は文章のみとし、修正ブロックは Markdown レポート内に記載します。
• アンチパターンの例を再利用する。 指摘事項が柱別プレイブックに記載された名前付きアンチパターンに該当する場合は、その項目の Right の例から始めます。
• 適用範囲。 全体レポートと柱別レポートに適用します。スコアモードとクイックレビューにはスニペットを含めず、Full BP Ledger テーブルにもスニペットを含めません。修正は指摘事項のセクションに記載します。

例（指摘事項 SEC08-BP02、Terraform ワークロード、証拠 infra/rds.tf:12）：

修正：

# infra/rds.tf — aws_db_instance.orders (line 12)
resource "aws_db_instance" "orders" {
  # ...existing configuration...
  storage_encrypted = true
}

ステップ 6b：構造化出力を生成する（aws-well-architected-framework-review.json）

Markdown レポートの後に、機械可読な aws-well-architected-framework-review.json も生成してください。レビューを時系列で差分比較（CI ゲート）したり、複数のワークロードを集計したり、WA Tool にインポートしたりできます。Markdown は人間向けで、この成果物はツール向けです。 schemas/aws-well-architected-framework-review-v1.schema.json に定義されたバージョン管理済みの契約に準拠してください。

ワークロードのルートに aws-well-architected-framework-review.json を出力してください（または、ユーザーが指定したパスに出力してください）。直前に報告したものと同じ検出結果を使用してください。分析を再実行せず、Full BP Ledger の内容をシリアライズしてください。

ルール：

• 評価した BP ごとに findings エントリを 1 件作成してください。implemented と not_applicable も含めます。評価済みで合格した BP と、未評価の BP を判別できるようにするため、合格行を省略しないでください。
• コアフレームワークの BP では、bp_id に正規の PILLAR##-BP## を必ず指定してください。これはベースラインの差分比較で照合する識別キーです。多くのレンズの BP も正規 ID（例：IOTCOST01-BP01）を公開しているため、それを使用してください。
• 一部のレンズはトピック別に構成されており、BP ID が公開されていません（serverless-applications、saas、government、healthcare-industry、container-build、sap、streaming-media、およびいくつかの混在ケース）。そのいずれかの検出結果では、bp_id を省略し、title（および lens）を指定してください。title は安定したキーではないため、これらの検出結果は参考情報として報告され、ゲートの対象にはなりません。差分比較のために BP ID を捏造しないでください。レビューごとにキーが変動する原因になります。
• 実際に実施した深度（full、quick、pillar-scoped、score）を review_mode に設定してください。full 以外の実行では全 307 件の BP を網羅しないため、その旨を recall_note に記載してください。
• skill_version には、このスキルのフロントマターにある version を設定し、一意の run_id（例：{date}T{time}-{workload-slug}）を生成してください。同じ日に実施したレビューを区別できるようにします。
• すべてのギャップ（not_implemented／partially_implemented）には、必ず severity（critical／high／medium／low）を付与してください。CI ゲートは重大度に基づいて優先順位を付けるため、評価されていないギャップがあるとビルドは失敗します。implemented／not_applicable／cannot_determine の場合に限り、severity を省略してください。
• recall_note には、網羅的ではないものの再現率を重視した評価であることを必ず記載してください。これにより、後続のゲートが検出結果の欠落をコントロールの存在証明とみなすことを防ぎます。この環境で測定していないカバレッジ値を断言しないでください。
• recommendation は文章によるガイダンスとし、コード差分にしないでください（リポジトリの設計原則）。

形式（完全かつ正式な定義についてはスキーマを参照してください）：

{
  "schema_version": "1.0.0",
  "workload": "{workload name}",
  "date": "{YYYY-MM-DD}",
  "review_mode": "full",
  "skill_version": "2.3.0",
  "run_id": "{date}T{time}-{workload-slug}",
  "lens": ["{lens-name}"],
  "business_criticality": "{critical|high|standard|low}",
  "pillar_scores": {
    "operational_excellence": 3, "security": 2, "reliability": 2,
    "performance_efficiency": 3, "cost_optimization": 4, "sustainability": 3
  },
  "findings": [
    {
      "bp_id": "SEC08-BP01",
      "pillar": "security",
      "status": "not_implemented",
      "severity": "high",
      "evidence": { "file": "infra/s3.tf", "line": 14 },
      "effort": "low",
      "recommendation": "Enable SSE and BlockPublicAccess on the uploads bucket."
    },
    {
      "title": "Use asynchronous invocation for non-critical Lambda work",
      "lens": "serverless-applications",
      "pillar": "performance_efficiency",
      "status": "not_implemented",
      "severity": "medium",
      "recommendation": "Move the notification path to async invocation so the request path is not blocked."
    }
  ],
  "recall_note": "Full review. High recall but not exhaustive; absence of a finding is not proof of implementation."
}

上の 2 つ目の検出結果は、トピック別に構成されたレンズの検出結果の例です。bp_id はなく、代わりに title があります。参考情報として報告され、ゲートの対象にはなりません。

ファイルの作成後、ファイル名を伝え、CI での使用方法を案内してください。

aws-well-architected-framework-review.json（機械可読で、schemas/aws-well-architected-framework-review-v1.schema.json に準拠）も作成しました。 .well-architected/baseline.json としてコミットし、パイプラインで tools/wa-ci を設定して、今後の PR で Well-Architected の差分をゲートしてください。

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

レポートを提示した後、次の内容を提案してください。

次の対応をご希望ですか？

• 特定の柱について、分析を拡充して詳しく調査する
• 特定の検出結果を修正するための IaC テンプレートを生成する
• 特定のアーキテクチャ変更に向けた移行計画を作成する
• 特定の WA Lens とワークロードを詳細に比較する
• 継続的なコンプライアンスのための自動チェック（Config ルール、カスタムメトリクス）を生成する
• 継続的な WA ゲートを設定する：aws-well-architected-framework-review.json をベースラインとしてコミットし、CI で tools/wa-ci を実行する
• AWS コンソールでの追跡用に WA Tool インポートデータを生成する
• 🔴／🟡 の検出結果を、要約エピックとともに追跡用の課題として登録する（ステップ 7b — イシュートラッカー CLI が利用可能な場合に限り提案してください）

ステップ 7b：調査結果を追跡用イシューとして登録する（任意 — 確認必須）

レポートの内容を古くしないように、調査結果を追跡対象の作業に変換する任意の出力モードです。自動では絶対に実行しないでください。レビューごとにユーザーから明示的な確認を1回得ることを条件とし、デフォルトは「いいえ」です（設計原則：ユーザーが主導権を保てるようにする）。

トラッカーの検出。 提案する前に、イシュートラッカーに実際にアクセスできることを確認します。まず gh CLI を確認し（gh auth status が成功し、ワークロードリポジトリに GitHub のリモートが設定されていること）、別のトラッカーは、実行環境が同等のツールを公開している場合にのみ確認します。いずれも利用できない場合は、何も通知せずスキップし、レポートのフッターに次の1行を追加します：Tracking-issue filing skipped — no issue tracker CLI available.

一度だけ確認します（トラッカーが利用可能な場合のみ）。ステップ 7 の提案に含めて尋ねます：

これらの調査結果を追跡用イシューとして登録しますか？🔴 Critical/High と 🟡 Medium の調査結果ごとに1件のイシューを作成し、優先順位付きチェックリストを含むサマリーエピックを1件作成します。Low と Cannot Determine の項目はレポートのみに残します。（デフォルト：いいえ）

ユーザーが確認した場合に限り、次を作成します：

1. 🔴 Critical/High と 🟡 Medium の調査結果ごとに1件のイシュー
   • タイトル：[WA][<PILLAR>] <finding title>（例：[WA][SEC] Uploads bucket lacks Block Public Access）
   • 本文：重大度、正規形式の BP ID（SEC01-BP02）、またはレンズに BP ID がない場合はレンズ名と調査結果のタイトル、証拠の引用（ファイル:行）、およびレポートに記載された修正の次のステップ（Fix: ブロックがある場合はそれを含む）。
2. サマリーエピックを1件
   • タイトル：[WA] Well-Architected review — {workload name} ({date})
   • 本文：ピラーのスコアカード表と、すべての調査結果イシューへのリンク付きチェックリスト（- [ ] #<n> …）。チェックリストはアイゼンハワー・マトリクスの象限ごとに分類します（Do First → Plan → Delegate → Defer）。

ルール：

• イシューはレビューの成果物であり、コード変更ではありません。本文には参考情報とコピー用の修正スニペットを記載し、差分を適用してはいけません。
• ユーザーから求められない限り、ラベル、担当者、マイルストーンは追加しないでください。トリアージはチームに委ねます。
• Low または Cannot Determine の行は登録しないでください（トラッカーに不要な情報が増えるため）。これらはレポートに残します。
• 完了したら、作成したイシューの URL を列挙し、エピックが追跡の起点であることを伝えます。

評価基準のガイダンス

• マルチ AZ、暗号化、ロールバック機能付きの CI/CD、モニタリング、自動スケーリングを備えたワークロードは成熟しています。大半の指摘は Critical ではなく、改善点であるべきです。
• 十分に構築されたワークロードに、Critical の指摘を捏造しないでください。不必要に警告するより正確さを優先してください。
• ビジネス上の重要度が「low」または「standard」の場合は、よりシンプルなアーキテクチャを許容してください（社内ツールならシングルリージョンで問題ありません）。
• ビジネス上の重要度が「critical」の場合は、より厳しい基準を適用してください（マルチリージョン DR、カオステスト、1分未満の RTO が期待されます）。
• 判定可能な調査結果にはすべて、具体的なコード、設定、実行時情報、またはユーザーが明示的に提供した証拠が必要です。裏付けのない一般的な推奨事項は避けてください。
• 入手可能な証拠から判断できない場合は「Cannot Determine」とし、重大度は空欄のままにして、必要な実行時情報またはヒアリング情報を説明してください。
• 長所を目立つ形で認めてください。成熟したワークロードは批判ばかりではなく、妥当性が確認されたと感じられるようにしてください。