AWS の学習を進めると、試験の問題文にも設計の記事にも「Well-Architected」という言葉が出てきます。6つの柱の名前は覚えたものの、それがフレームワークとして何をしてくれるのか、どこかに「正しい構成の見本」があってそれに合わせるものなのか、はっきりしないまま進んでいないでしょうか。
この記事では、AWS Well-Architected フレームワークを「設計を点検するための問いの集まり」として整理します。柱・設計原則・レンズ・Well-Architected Tool が、それぞれどの役割を持っているかが分かると、試験の選択肢の読み分けにも、実務の設計レビューにも同じ道具が使えるようになります。
この記事の結論
- AWS Well-Architected フレームワークは、クラウドの設計が良い形になっているかを確かめるための、問いとベストプラクティスの集まりです。
- 柱は運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6つで、それぞれが設計を見る観点になっています。
- 一般的な設計原則はクラウド全体に共通する考え方、レンズは業種や技術分野ごとに問いを足す拡張です。
- Well-Architected Tool で問いに答えると、高リスク・中リスクの課題と改善計画が出て、マイルストーンで改善の経過を残せます。
- このフレームワークは唯一の正解の構成を配るものではなく、何を得て何を諦めたかを自分で説明するための型です。
AWS Well-Architected フレームワークとは何か
たとえるなら、健康診断の問診票です。問診票は「理想の体型」を示すものではありません。「よく眠れていますか」「階段で息が切れますか」と観点ごとに質問し、答えから弱っている所と、次に何を調べるかを決めます。
正確な言葉に戻すと、AWS の公式ドキュメントは Well-Architected フレームワークを、アーキテクチャがクラウドのベストプラクティスに沿っているかを理解するための基本的な問いの集まりであり、システムを一貫したやり方で評価し、必要な改善を見つけるためのものだと説明しています。評価の対象はワークロード、つまり事業上の価値を生む一まとまりのリソースとコードです。アカウント全体でも、サービス1つでもなく、「このアプリケーションのこの環境」という単位で見ます。
フレームワークは次の4つの部品でできています。
FOUR PARTS4つの部品
Well-Architected は観点と問いの組み合わせでできている
-
柱
6つの観点 — どこから見れば弱い所が見つかるか
運用・セキュリティ・信頼性・性能・コスト・持続可能性
-
原則
設計原則 — 全体に共通する考え方と、柱ごとの考え方
容量を推測で決めない、ゲームデーで確かめる
-
問い
問いとベストプラクティス — 点検の中身
答えから高リスク・中リスクの課題が見える
-
レンズ
レンズ — 業種・技術分野の観点を足す拡張
レンズカタログと、組織が書くカスタムレンズ
- 柱: 設計を見る観点。6つある
- 設計原則: フレームワーク全体に共通するものと、柱ごとのものがある
- 問いとベストプラクティス: 柱ごとに並んだ問いと、その問いに良い形で答えている状態の説明
- レンズ: 特定の業種・技術分野（サーバーレス、機械学習など）向けに問いを足す拡張
文書は日付の付いた版で改訂されていて、古い版も公式サイトに残っています。引用するときは、どの版の記載かを確かめてください。
6つの柱とは何か（それぞれ何を問うか）
柱は「このシステムを、どの観点から見ると弱い所が見つかるか」の一覧です。名前を暗記するより、それぞれの柱が何を問うかを1行で言えるようにしておくと、設計の議論でも試験でも使えます。
| 柱 | 何を問うか | 考え方の例 |
|---|---|---|
| 運用上の優秀性 | ワークロードを動かし、状態を見て、運用の手順を改善し続けられるか | 小さく元に戻せる変更を頻繁に行う。運用で起きたことから学ぶ |
| セキュリティ | 情報・システム・資産を守れているか | 強い ID の基盤を作る。すべての層で守る。人をデータから遠ざける |
| 信頼性 | 意図した機能を果たし、障害から素早く復旧できるか | 障害から自動で復旧する。復旧の手順を試す。水平に拡張する |
| パフォーマンス効率 | 要件を満たすために計算資源を効率よく使えているか | サーバーレスを使う。より頻繁に試す |
| コスト最適化 | 費用を意識して作り、事業の成果に見合う形で払っているか | 使った分だけ払う形を取る。差別化にならない重労働にお金を使わない |
| 持続可能性 | クラウドで動かすことによる環境への影響を減らせているか | 利用率を上げて、必要なリソースそのものを減らす |
いくつか補足します。
信頼性の柱が扱う耐障害性は、一部の部品が故障してもサービス全体が動き続ける性質です。複数の AZ に置く・冗長にする、といった設計がここに入ります。どの AZ に何を置くかの基本は、リージョンと AZ の記事で扱っています。災害対策の方式（バックアップと復元、パイロットライト、ウォームスタンバイ、複数拠点の同時稼働）も信頼性の柱の範囲で、復旧にかけてよい時間と平常時の費用の兼ね合いで選びます。
持続可能性は、他の5つより後から加わった柱です。柱が5つだったころの資料がまだ残っているので、柱を5つとして数えているものは古い版だと判断してください。
公式ドキュメントは、セキュリティと運用上の優秀性は一般に他の柱と引き換えにしないと述べています。残りの柱、たとえば信頼性とコスト最適化は、事業の要件に応じて取捨選択の対象になります。
READ ALSO — 未経験向け・段1 入口
リージョンと AZ の仕組み｜「どこに置くか」で、速さ・止まりにくさ・料金の何が変わるか
CHECK 1ここまでの確認
設計を見る6つの観点として公式に挙がっている名前は、次のうちどれですか?
答えと解説
答え: 2. 持続可能性
6つの柱は運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性です。持続可能性は後から加わった柱で、柱を5つとして数えている資料は古い版です。「6つの柱とは何か」の表を読み直してください。
設計原則とレンズは何を足すのか
一般的な設計原則
柱の手前に、クラウド全体に共通する「一般的な設計原則」が置かれています。公式ドキュメントに並んでいるのは、次のような考え方です。
- 必要な容量を推測で決めない: 容量を見誤ると、高い遊休リソースを抱えるか、性能不足に悩むことになる。クラウドなら必要に応じて増減できる
- 本番と同じ規模で試す: 試験用の環境を必要なときだけ作り、終わったら消せる
- 実験しやすいように自動化する: 自動化すると、変更を試すことと元に戻すことが安くなる
- 進化するアーキテクチャにする: 最初の設計を一度きりの決定にせず、事業の変化に合わせて変えられるようにする
- データに基づいて設計する: 勘ではなく、測った事実で設計の判断をする
- ゲームデーで改善する: 本番に近い出来事を定期的に模擬して、仕組みと人の対応を確かめる
柱ごとの設計原則は、この共通の考え方を柱の観点に落としたものです。上の表の「考え方の例」は、その一部を言い換えたものです。
レンズ
レンズは、フレームワークの問いに、特定の業種や技術分野の観点を足す拡張です。サーバーレスのアプリケーション、機械学習、移行などのレンズがあり、フレームワーク本体の問いだけでは拾いきれない論点を補います。
Well-Architected Tool では、ワークロードを定義すると Well-Architected フレームワークのレンズが自動で適用され、そこに追加のレンズを重ねられます。追加できるのは、AWS が用意する「レンズカタログ」のレンズと、組織が自分で書くカスタムレンズの2種類です。カスタムレンズを使うと、社内のガバナンス・法務・コンプライアンスの確認項目を、同じレビューの中で扱えます。表計算ソフトの別シートで管理していた確認項目を、1か所にまとめられるということです。
CHECK 2ここまでの確認
自社の社内規程やコンプライアンスの確認項目を、Well-Architected のレビューに加えたいときに使うものはどれですか?
答えと解説
答え: 1. カスタムレンズ
レンズは、フレームワークの問いに業種や技術分野の観点を足すものです。AWS が用意するレンズのほかに、組織が自分で書くカスタムレンズを Well-Architected Tool に取り込めます。「設計原則とレンズは何を足すのか」を読み直してください。
Well-Architected Tool のレビューでは何をするのか
AWS Well-Architected Tool は、フレームワークの問いに答えてワークロードを評価し、改善を追いかけるためのサービスです。公式の FAQ によると、ツール自体に追加料金はかからず、利用している AWS のリソースの料金だけがかかります（料金の扱いは公式の料金ページで確認してください）。
レビューは次の順に進みます。
REVIEW LOOPレビューの流れ
問いに答えると、次に直す順番が見える
-
ワークロード
評価する単位を決める
-
問いに答える
実際にやっていることだけ選ぶ
-
HRI・MRI
高・中リスクの課題が出る
-
改善計画
優先順位つきの一覧
-
マイルストーン
直したら経過を残す
- ワークロードを定義する: 評価する単位を決める。どの環境か、誰が持ち主かを書く
- 問いに答える: 柱ごとの問いに、いまの設計で当てはまるベストプラクティスを選んで答える
- リスクを見る: 答えから、高リスクの課題（HRI）と中リスクの課題（MRI）が示される
- 改善計画を立てる: 優先順位の付いた課題の一覧と、直し方の手がかりが出る
- マイルストーンを残す: ある時点のワークロードの状態を記録する。改善のたびに残すと、進み具合を比べられる
操作の手順は改定で変わるので、公式のユーザーガイドを見てください。ここで押さえておきたいのは、レビューは一度やって終わりではなく、定期的に回して経過を残すものだという点です。
問いに答えるときは、実際にやっていることだけを選びます。「やる予定」を選ぶと、リスクが見えなくなり、改善計画が役に立たなくなります。
なぜ「正解の構成」ではなく「問いの集まり」なのか
Well-Architected を初めて学ぶ人がつまずきやすいのは、「Well-Architected に準拠した構成図」がどこかにあり、それに合わせれば合格、と受け取ってしまうことです。公式ドキュメントの説明は違います。
NOT A BLUEPRINT誤解を直す
配られるのは正解の構成ではなく、説明するための問い
よくある受け取り方
公式の説明に沿った見方
よくある受け取り方: 準拠した構成図の見本がある
公式の説明に沿った見方: 観点ごとの問いがあり、構成はワークロードごとに決める
よくある受け取り方: 監査で合否を判定する
公式の説明に沿った見方: 責めない形の、設計判断についての建設的な会話
よくある受け取り方: 一度レビューすれば終わり
公式の説明に沿った見方: 定期的に回し、マイルストーンで経過を残す
| よくある受け取り方 | 公式ドキュメントの説明に沿った見方 |
|---|---|
| 準拠した構成図の見本がある | 観点ごとの問いとベストプラクティスがあり、構成はワークロードごとに決める |
| 監査で合否を判定する | 設計判断についての建設的な会話。責めない形で深く掘る |
| 全部の柱で満点を目指す | セキュリティと運用上の優秀性は守り、残りの柱は要件に照らして取捨選択する |
| 一度レビューすれば終わり | 軽いレビューを定期的に回し、マイルストーンで経過を残す |
正解の構成を配らない理由は、同じ問いでも事業によって良い答えが変わるからです。社内の少人数が使う業務システムと、止まると売上が消える決済システムでは、信頼性にかけてよい費用が違います。フレームワークが示すのは「その判断を説明できるか」を確かめる問いであって、判断そのものではありません。
レビューの価値は、HRI の数を減らすことより、「このリスクは知ったうえで受け入れている」と言える状態を作ることにあります。受け入れたリスクと理由を記録しておけば、要件が変わったときに見直せます。この「何を得るために何を諦めたか」を言葉にする型は、トレードオフの考え方の記事で掘り下げています。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
CHECK 3ここまでの確認
Well-Architected のレビューの性格として、公式ドキュメントの説明に最も近いものはどれですか?
答えと解説
答え: 2. 設計判断についての建設的な会話で、責めない形で行うもの
公式ドキュメントは、レビューを監査の仕組みではなく、設計判断についての建設的な会話であり、責めない形で深掘りするものだと説明しています。「なぜ『正解の構成』ではなく『問いの集まり』なのか」を読み直してください。
まとめ
- Well-Architected フレームワークは、設計を点検する問いとベストプラクティスの集まりで、評価の単位はワークロード
- 6つの柱は運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性で、それぞれが見る観点を1行で言えるようにする
- 一般的な設計原則は全体に共通する考え方、レンズは業種・技術分野の観点を足す拡張。組織の確認項目はカスタムレンズで足せる
- Well-Architected Tool で問いに答えると、HRI・MRI と改善計画が出る。マイルストーンで経過を残し、定期的に回す
- 正解の構成図はない。何を得て何を諦めたかを説明できる状態を作るための道具として使う
次は、柱の間の取捨選択を実際の判断に落とす「トレードオフの考え方」と、運用上の優秀性・信頼性の柱に直結する「監視設計」に進むと、フレームワークが設計の言葉としてつながります。
参照ソース
- AWS Well-Architected Framework（AWS ドキュメント） — フレームワークが基本的な問いの集まりであること、一貫した評価の方法であることの根拠（latest 版、2026年9月時点の記載）
- The pillars of the framework（AWS ドキュメント） — 6つの柱の名前と定義、セキュリティと運用上の優秀性を一般に引き換えにしないことの根拠（latest 版、2026年9月時点）
- General design principles（AWS ドキュメント） — 一般的な設計原則（容量を推測しない、ゲームデー、進化するアーキテクチャなど）の根拠（latest 版、2026年9月時点）
- The review process（AWS ドキュメント） — レビューが監査ではなく建設的な会話であり、責めない形で行うことの根拠（latest 版、2026年9月時点）
- Using lenses in AWS WA Tool（AWS Well-Architected Tool ユーザーガイド） — フレームワークのレンズが自動で適用されること、レンズカタログとカスタムレンズの2種類の根拠（2026年9月時点）
- Milestones（AWS Well-Architected Tool ユーザーガイド） — マイルストーンがある時点のワークロードの状態を記録するものであることの根拠（2026年9月時点）
- AWS Well-Architected Tool FAQs（AWS 公式） — ツールに追加料金がかからず、リソースの料金だけがかかるという記載の根拠（2026年9月時点。検索結果の抜粋で確認）
