6本の柱の名前は覚えたものの、「実際にレビューをするとき何が起きて、手元に何が残るのか」が見えないままの人は多いはずです。ワークロード、レンズ、リスク、マイルストーンと用語が並ぶと、どれがどうつながって改善計画になるのかが分かりにくくなります。この記事では、レビューの部品を順に並べ、一本の流れとして説明します。
この記事の結論
- レビューは「ワークロード」を単位に、「レンズ」（質問の束）に答えて進めます。
- 質問ごとに実施済みの習慣を選ぶと、足りない分が高リスク・中リスクとして出ます。
- リスクごとに改善の手がかり（公式ドキュメントへのリンク）が付き、これが改善計画の材料になります。
- マイルストーンで時点の記録を残し、前回との変化を比べられます。
- 公式は「非難しない・数時間で終わる・監査ではなく対話」と述べ、設計の早い段階と公開前に当てるのを勧めています。
- 結果は設計の優先順位づけの入力であり、合否ではありません。
Well-Architected レビューとは何か
Well-Architected レビューとは、自分の設計を Well-Architected フレームワークの質問に照らして点検する取り組みです。AWS の公式ドキュメントは、これを監査ではなく建設的な対話として位置づけています。誰かを責めるためではなく、設計の弱い所を一緒に見つけるために行います。また、数時間で終えられる規模のものとして説明されています。
質問は6本の柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）に沿って並びます。柱それぞれの中身はフレームワークの入口の記事で扱っているので、ここでは触れません。台帳上の柱の数は6本で、最新の構成は公式ページで確認してください。この記事の主題は、柱の知識ではなく「質問に答えた結果がどう改善につながるか」という流れです。
REVIEW LOOPレビューは輪になる
レビューは答える、直す、見直すの繰り返しで回る
ワークロード
点検の対象
- 答える
- リスクが出る
- 優先順位
- 直す
- 見直す
レビューの流れは、一度きりの検査ではなく輪になっています。答えてリスクを出し、優先順位を付けて直し、直したあとにもう一度見直す。この輪の中心にあるのが、点検の対象である「ワークロード」です。
レビューの部品｜ワークロード・レンズ・質問・柱の関係
用語は6つに絞れます。
| 部品 | 役割 |
|---|---|
| ワークロード | 点検の対象。まとまって価値を生むシステムやアプリケーションの単位 |
| レンズ | ある領域向けの質問の束。フレームワーク自体が基本のレンズ |
| 質問 | レンズの中身。柱ごとに並び、実施している習慣を選んで答える |
| リスク | 質問への回答から評価される、足りない習慣の度合い |
| 改善計画 | リスクを直す順番と手がかりをまとめたもの |
| マイルストーン | ある時点のワークロードの状態を記録したもの |
ワークロードごとにレビューを行い、そこへ適用するレンズの質問に答えます。基本のレンズはフレームワークそのもので、特定の領域向けには別のレンズを足せます。質問は柱ごとに分かれているので、1つの質問は必ずどれかの柱に属します。
部品の階段
部品はワークロードから記録まで6段でつながる
-
1
ワークロード
点検の対象
-
2
レンズ
領域向けの質問の束
-
3
質問
実施している習慣を選ぶ
-
4
リスク
足りない習慣が出る
-
5
改善計画
直す順番と手がかり
-
6
マイルストーン
時点の記録を残す
CHECK 2ここまでの確認
レンズとは何を指しますか?
答えと解説
答え: 1. ある領域向けの質問の束
レンズは特定の領域に向けた質問の集まりです。Well-Architected フレームワーク自体が基本のレンズにあたります。「レビューの部品」を読み直してください。
質問に答えるとリスクが出る仕組み
質問には「この習慣を実施していますか」という形の選択肢が並びます。当てはまる習慣を選んでいくと、実施していない習慣のある質問が、高リスクまたは中リスクとして出てきます。質問ごとの回答の結果として評価される点が重要です。つまり、リスクは誰かの主観ではなく、「どの習慣が欠けているか」から導かれます。
注意したいのは、この評価が合否ではないことです。リスクが出たのは「その習慣が今のワークロードに足りていない」という事実を示しているだけで、設計の良し悪しの採点ではありません。高リスクがいくつ出ても、何から直すかを決める入力が増えただけです。
なお、リスクの判定の細かな基準は、この記事では確認できた範囲を超えるため書きません。基準を知りたいときは、公式のユーザーガイドを見てください。
CHECK 1ここまでの確認
レビューで質問に答えたとき、実施していない習慣があった質問はどう扱われますか?
答えと解説
答え: 2. 高リスクまたは中リスクとして出る
質問ごとの回答の結果として、足りない習慣がリスクとして評価されます。合否ではなく改善の材料です。「質問に答えるとリスクが出る仕組み」を読み直してください。
リスクを改善計画に変える流れ
リスクごとには、改善の手がかりとして公式ドキュメントへのリンクが付きます。これが改善計画の材料です。やることは、出たリスクを並べて、どれから直すかを決めることです。
ここで、優先順位は機械が決めません。同じ高リスクでも、扱うデータの重要さ、止まったときの影響、予算、納期によって、先に直すものは変わります。公式のレビュー手順も、課題に優先順位を付けて対処する流れを前提にしています。
たとえば、公開前の小さなシステムなら、すぐに直すべきリスクと、公開後の運用の中で直していくリスクを分ける、という判断もあり得ます。この判断の型はトレードオフの考え方の記事で扱います。
監査との違い
レビューは合否ではなく対話で改善点を出す
監査
合否を付ける
- 基準に合うかを判定する
- 結果は合格か不合格か
Well-Architected レビュー
対話して改善点を出す
- 非難せず質問に答える
- 結果は優先順位づけの入力
マイルストーンで「前回との差」を残す
マイルストーンは、ある時点のワークロードの状態を記録するものです。改善を進めたあとにもう一度レビューをして、前回の記録と並べると、リスクがどれだけ減ったか、新しく何が増えたかを比べられます。
レビューを一度で終わらせず、変更のたびに回すための仕掛けと考えると分かりやすいです。記録が無ければ「前より良くなったのか」は印象でしか語れませんが、時点の記録があれば、改善の効果を後から説明できます。
いつ・誰とやるか｜設計初期と公開前
公式は、レビューを設計の早い段階と、公開の前に当てることを勧めています。理由は、後から直しにくい判断を先に点検できるからです。公式の説明では、こうした判断を、元に戻しにくい「片道扉」と、戻しやすい「往復扉」に分けて考えます。片道扉にあたる判断ほど、早い段階での点検が効きます。
進め方は、設計に関わる人が集まり、質問に答えながら話し合う形です。非難しないことが前提なので、「なぜやっていないのか」と責める場にはしません。答えにくい質問が出たら、そこがまさに話し合うべき所です。
CHECK 3ここまでの確認
レビューを当てる時期として勧められているのはいつですか?
答えと解説
答え: 2. 設計の早い段階と公開前
後から直しにくい判断を先に点検するためです。「いつ・誰とやるか」を読み直してください。
よくある誤解とまとめ
点数を競うものだと思ってしまう。 リスクの数は成績ではありません。ワークロードによって求める水準は違うので、他のシステムとの比較に使うと、本来の目的から外れます。
一度で終わると思ってしまう。 アーキテクチャが変われば、前提も変わります。変更のたびにマイルストーンを残して見直すのが、公式の勧める使い方です。
ツールが無いとできないと思ってしまう。 質問に答えて足りない習慣を洗い出す考え方は、ツール無しでもできます。ただし Well-Architected Tool を使うと、回答・リスク・改善計画・記録がまとまって残ります。
レビューの流れは、「ワークロードを決める → レンズの質問に答える → リスクが出る → 改善計画に並べる → 直す → マイルストーンで記録して見直す」です。合否を付ける検査ではなく、設計の優先順位づけを助ける対話であり、設計の早い段階と公開前に当てると効果が大きくなります。次は、出たリスクの優先順位を事業の事情で決める考え方へ進んでください。
参照ソース
- The review process（AWS ドキュメント） — 非難しない・数時間・対話であること、設計の早い段階と公開前に当てること、片道扉、課題の優先順位づけの根拠（latest 版、2026年10月時点）
- AWS Well-Architected Tool ユーザーガイド — ワークロード・レンズ・マイルストーンなど Tool の概念の根拠（2026年10月時点。詳細な判定基準は確認できていないため書いていない）
