wa-review

Well-Architected レビュー

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

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

レビューするワークロードを教えてください。以下の情報を共有してください。

• ワークロード名と簡単な説明
• 分析対象のコードパッケージ／ディレクトリ（IaC、アプリケーションコード、CI/CD 設定）
• ビジネス上の重要度（クリティカル、高、標準、低）
• 現在の課題（任意 — すでに問題だと分かっていることがあれば教えてください）

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

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

該当する場合は、専門的な WA Lens を特定します。

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

コードからレンズが明らかな場合（例：Lambda が多用されている場合はサーバーレス）、その旨を記載し、レンズ固有の質問を適用してください。

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

コードベース内のすべてのインフラストラクチャ・アズ・コードとデプロイ設定を分析します。

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

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

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

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

以下を示すアーキテクチャ図を 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） — 各ピラーについて、すべての質問と BP の全内容をまとめた参照ファイルです。BP の詳細（実装ガイダンス、アンチパターン、リソース）を確認するには、これらを読み込んでください。
3. references/pillar-playbooks/{pillar}.md（6 ファイル、各約 3～5 KB） — 各ピラーのドメイン固有のエビデンス収集ガイドです。調査対象となるリソース、HIGH RISK として指摘すべきパターン、ピラー固有のレポート形式を示しています。完全レビューを担当する各サブエージェントは、自身のピラーのプレイブックを読み込みます（ステップ 4b）。これにより、汎用的な BP の言い換えではなく、具体的なファイルと行番号のエビデンスに基づいて所見を提示できます。

完全レビューで必須となる読み込み手順

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

Read: references/manifest.md

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

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

**このパターンを採用する理由：**実測では、1 つのエージェントが 307 個すべての BP を 1 回の応答で列挙しようとすると、プロンプトの強さ、検索方法（ローカルファイル、MCP、ハイブリッド）、明示的な「307 個すべてを評価する」という指示にかかわらず、20～60 件の所見を出して停止します。これは、モデルの簡潔さを優先する事前傾向による、安定した行動上の均衡状態です。

**解決策：**サブエージェントごとに範囲を絞ります。1 つのエージェントが 1 つのピラーをレビューすると、そのピラーの 30～55 個の BP を自然に列挙します。6 つのサブエージェントを並列で起動し（ピラーごとに 1 つ）、結果を集約すると、実測で **100%（307/307）**の網羅率を達成しています。これは evals/study_mcp で測定されており、ハルシネーションは 0 件です。

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 を必ず網羅する）
• ステータス：Implemented / Partially Implemented / Not Implemented / Not Applicable / Cannot Determine のいずれか 1 つのみ
• 重大度：Critical / High / Medium / Low（または Implemented／Not Applicable／Cannot Determine の場合は空欄）
• エビデンス：コードを分析した場合は具体的なファイルと行番号、口頭で確認した場合は明示的な引用事実、または Cannot Determine — need {specific evidence}
• BP ID は正規の PILLAR##-BP## 形式のみ

すべてのピラー用サブエージェントのプロンプトに、次の調整ルールをそのまま追加してください。

エビデンスの十分性に関するゲートを適用してください。情報が省略されている、または結論が出ていない場合は Not Implemented ではなく Cannot Determine としてください。Not Implemented を使用できるのは、制御が明示的に存在しない場合、または制御が記載されているべき権威ある情報源に制御がない場合のみです。Cannot Determine の重大度は空欄にし、必要な具体的エビデンスを記載してください。

起動テンプレート：

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 回呼び出します。**各サブエージェントは独自のコンテキストで独立して動作するため、互いの作業範囲を奪うことなく、それぞれが網羅的なレビューを行えます。統一されたテーブル形式により、集約は解釈を加えた要約ではなく、機械的な連結になります。これにより、サブエージェントの説明文形式の出力で確認された約 30～70% の再現率低下を防げます。

**コスト／レイテンシ：**単一エージェントのレビューと比べて、トークン数は約 3～4 倍です（各サブエージェントが作業コンテキストを重複して処理するため）。ただし、実時間は最も遅い 1 つのピラー（約 2～3 分）で決まります。ユーザーは網羅性を得るためにコストを負担します。 サブエージェントへのディスパッチをスキップする場合：

• ユーザーがクイックレビュー／スコアモード／柱を指定したレビューを明示的に依頼した場合 — これらのモードでは単一エージェントを使用します
• トークン使用量が3～4倍になることを許容できないコスト制約のある環境の場合 — 単一エージェントでレビューを実施し、網羅できるのは307件ではなく約50～60件のBPであることをユーザーに正直に伝えます

ステップ4c — サブエージェントの調査結果を統合する（引用をそのまま保持）：

6つすべてのサブエージェントから結果が返されたら、調査結果を1つの構造化レポートに統合します。重要：各サブエージェントが提示したBPの引用は、すべて保持してください。統合ステップは要約ではなく、マージです — サブエージェントが提示したBPの引用を言い換えたり、まとめたり、省略したりしないでください。実測によると、通常、再現率が失われるのは組み立ての段階です。サブエージェントは250～307件のBPを提示しても、単純な統合によって最終レポートでは60～90件に減ってしまいます。

統合ルール — 以下をすべて守ってください：

1. Full BP Ledgerが必須です。 レポートには「Full BP Ledger」セクション（ステップ6を参照）が必要です。このセクションには、各サブエージェントのBPとステータスの組み合わせごとに1行を設けます。サブエージェントAがSEC03-BP02をNot Implementedとして引用した場合、その行を台帳にそのまま記載してください。言い換えはしないでください。
2. 柱ごとに圧縮しないでください。 サブエージェントが引用した45件のBPを、最終出力で「柱ごとの主な調査結果5件」に減らしてはいけません。引用されたBPはすべて台帳に記載してください。重大度の高い調査結果については、「Critical and High Risk Findings」セクションにも詳細を記載しますが、これは台帳に加えて記載するものであり、台帳の代わりにしてはいけません。
3. 記載前に件数を確認してください。 返答する前に、組み立てた草案内のBP ID（PILLAR##-BP##形式）を数えてください。件数がサブエージェントの引用数の合計より少ない場合、いくつかを落としています — 戻って追加してください。
4. 柱を横断するパターンと優先順位付けは、台帳を参照する追加の分析です。台帳の代わりにはなりません。

BPの引用ごとに、台帳の行には以下を記載します：

• Implemented — ワークロードがこのBPを満たしていることを示す（BPと根拠を引用）
• Partially Implemented — 一部はカバーされているものの、ギャップがある（BPとギャップを引用）
• Not Implemented — 明示的または信頼できる根拠により、ワークロードにこのBPが欠けていることが示されている
• Not Applicable — このBPはワークロードの状況に当てはまらない（簡潔に理由を説明）
• Cannot Determine — 判断するには根拠が不十分（必要な具体的根拠を記載）

網羅性の要件 — 完全なレビューでは、307件すべてのBPを評価する必要があります。すべてのBPに5つのステータスのいずれかを付与してください。Cannot Determineも評価済みとしてカウントされます。網羅的に評価するために、確定的なステータスを無理に付与する必要はありません。根拠に基づく不在に対してNot Implementedとすることは、有効で価値のある調査結果です。

ステップ 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).

Empirical measurement shows this section is where recall reaches the user. Skipping it or truncating it drops final-report recall from ~1.00 (what the subagents surface) to ~0.30 (what the assembler compresses to). **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, effort, AWS services. This section EXPANDS on rows in the Full BP Ledger — it does NOT replace them.}

## Medium Risk Findings
{Same format, condensed. 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}

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

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

ワークロードのルートにある wa-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）を指定してください。タイトルは安定したキーではないため、これらの調査結果は参考情報として報告され、ゲートの対象にはなりません。差分比較に合わせるために BP ID を捏造しないでください。レビューごとに変動するキーが作られてしまいます。
• 実際に実行した深さ（full、quick、pillar-scoped、score）を review_mode に設定します。full 以外の実行では 307 個すべての BP を網羅しないため、その旨を recall_note に記載してください。
• このスキルの frontmatter に記載された version を skill_version に設定し、一意の run_id（例：{date}T{time}-{workload-slug}）を生成して、同じ日に実施した 2 つのレビューを区別できるようにします。
• すべてのギャップ（not_implemented／partially_implemented）に、severity（critical／high／medium／low）を必ず指定してください。CI ゲートは重大度で順位付けするため、評価されていないギャップがあるとビルドは安全側に倒れて失敗します。implemented／not_applicable／cannot_determine の場合に限り、severity を省略します。
• recall_note には、網羅的ではないものの高い再現率でカバレッジを評価していること（wa-review の F1 は約 0.96）を必ず記載してください。これにより、下流のゲートが、調査結果の欠落をコントロールの存在の証明として扱うことを防ぎます。
• 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, F1 approx 0.96. High recall but not exhaustive; absence of a finding is not proof of implementation."
}

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

作成後、ファイルについて伝え、CI での使用方法を案内します。

wa-review.json（機械可読で、schemas/wa-review-v1.schema.json に準拠）も作成しました。 .well-architected/baseline.json としてコミットし、tools/wa-ci をパイプラインに組み込むことで、今後の PR を Well-Architected の差分に基づいてゲートできます。

ステップ 7：追加の対応を提案する

レポートを提出した後、次の対応を提案します。

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

• 特定の柱を対象に、分析を拡張して詳しく調査する
• 特定の調査結果を修正する IaC テンプレートを生成する
• 特定のアーキテクチャ変更の移行計画を作成する
• お使いのワークロードを特定の WA Lens と詳細に比較する
• 継続的なコンプライアンスのための自動チェック（Config ルール、カスタムメトリクス）を生成する
• 継続的な WA ゲートを設定する：wa-review.json をベースラインとしてコミットし、CI で tools/wa-ci を実行する
• AWS コンソールで追跡するための WA Tool インポートデータを生成する

評価のガイダンス

• マルチ AZ、暗号化、ロールバック付き CI/CD、モニタリング、自動スケーリングを備えたワークロードは成熟しています。ほとんどの指摘は重大な問題ではなく、改善点として扱ってください。
• 十分に構築されたワークロードに、重大な問題をでっち上げないでください。過剰な警告より正確さを優先してください。
• ビジネス上の重要度が「低」または「標準」の場合は、よりシンプルなアーキテクチャを許容してください（内部ツールであれば単一リージョンで問題ありません）。
• ビジネス上の重要度が「重大」の場合は、より厳格な基準を適用してください（マルチリージョンの DR、カオステスト、1 分未満の RTO が求められます）。
• 判定可能な指摘にはすべて、具体的なコード、設定、実行時の情報、またはユーザーが明示的に提供した根拠が必要です。裏付けのない一般的な推奨事項は提示しないでください。
• 入手可能な根拠から判断できない場合は「判定不能」とし、重大度を空欄にして、必要な実行時データやヒアリング内容を説明してください。
• 強みを明確に認めてください。成熟したワークロードは、批判されるだけでなく、その成熟度が適切に評価されていると感じられるべきです。