AWS Well-Architected Framework は、AWS上でシステムを設計・運用するときの判断の良し悪しを、6つの観点から自己点検するための質問集です。抽象的な理念集ではありません。質問に答えると改善項目がリスク付きで並ぶ実務ツール（AWS Well-Architected Tool）とセットで提供され、ツール自体は追加料金なし。6つの柱の定義、WAFRと略されるレビューの進め方と所要時間、レンズ16種と適用上限、複数ワークロードの共有とJira連携、Trusted Advisorとの役割分担を公式ドキュメントの記述で整理しました。2027年1月のサポートプラン再編で前提が変わる点も扱います。
まとめ：6つの柱・WAFR・WA Toolの費用の要点
要点は次の7つです。
| 論点 | 結論 |
|---|---|
| 柱の数 | 6つ |
| 最新版 | 2024年11月6日発行 |
| レビューの性格 | 監査ではない |
| 所要時間の目安 | 日単位ではなく時間単位 |
| WA Toolの費用 | 追加料金なし |
| レンズ | 公式16種・1ワークロード最大20 |
| Trusted Advisor | 別サービス・有償プラン必要 |
6つの柱は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト適正化（Cost optimization）、持続可能性。柱は優先順位ではなく観点の一覧で、ビジネス状況に応じて柱の間でトレードオフを取ります。ただしAWSは、セキュリティと運用上の優秀性を他の柱と引き換えにしないという立場を明記しています。
レビューは軽い会話として設計してください。公式ドキュメントが求めるのは、非難を挟まない進め方と、日単位ではなく時間単位で終わる軽量なプロセスです。一度きりのイベントにせず、マイルストーンで状態を記録しながら回すこと。ここが形骸化の分岐点になります。
6つの柱の定義と、コスト都合で削ってはいけない2本の柱の見分け方
公式のホワイトペーパーは、各柱に「何ができる能力か」という定義を与えています。名称だけが独り歩きしがちな部分です。
| 柱 | 英語名 | 問う設計品質 |
|---|---|---|
| 運用上の優秀性 | Operational excellence | 運用の可視性と手順の継続的改善 |
| セキュリティ | Security | データ・システム・資産の保護 |
| 信頼性 | Reliability | 期待どおりの機能実行 |
| パフォーマンス効率 | Performance efficiency | リソースの効率的な利用 |
| コスト適正化 | Cost optimization | 最低価格でのビジネス価値提供 |
| 持続可能性 | Sustainability | エネルギー消費と総リソースの削減 |
「ベストプラクティス一覧」を探しているなら、その実体は柱ごとの質問と、その下にぶら下がるベストプラクティスの集合です。同じ構造が WA Tool の質問と改善計画に対応するため、一覧を別途集める必要はありません。レビューを1周すれば、自ワークロードに関係する項目だけが改善計画として残ります。
柱ごとに温度差がある定義文の読み方と、自社の設計要件へ落とす観点
定義の粒度は柱ごとに違います。信頼性は「意図した機能を、期待されるときに正しく一貫して実行できる能力」で、ライフサイクル全体での運用とテストまで含む定義。パフォーマンス効率は「需要とテクノロジーが変化してもリソースの効率を保つ能力」と書かれ、設計時点の性能ではなく変化への追随を問うています。Cost optimization は「最も低い価格でビジネス価値を提供する能力」で、単なる費用削減とは別物です。
この差は、柱ごとに用意すべき材料が違うという話に直結します。信頼性の質問には障害試験の記録が、Cost optimization には請求総額ではなく内訳の説明が要ります。読み解きが難しい通信費はネットワークコストの内訳と計算方法に費目別の単価をまとめました。権限設計と機密値の扱いはAWS IAMの権限設計とParameter Storeによる機密値の管理が入口です。
コスト都合でトレードオフの対象外に置く2本の柱と、重み付けの順序
6つの柱は同時に最大化できません。開発環境では持続可能性とコストを優先して信頼性を落とす、ミッションクリティカルな用途ではコストと環境負荷を許容して信頼性を上げる。こうした意図的な取捨が前提です。ただし公式ドキュメントは、セキュリティと運用上の優秀性が一般に他の柱とトレードオフされないと明記しています。優先順位を議論するときは、この2つを固定枠として扱い、残る4つの重み付けだけを決めてください。
柱が5本立ての資料を渡されたら、版が古いと判断できます。持続可能性は2021年11月20日に追加された最も新しい柱だからです。ホワイトペーパーの発行日は2024年11月6日で、この改訂では信頼性の柱が大規模に刷新され、セキュリティと運用上の優秀性に生成AIの提案が加わりました。2026年9月時点でこれ以降の改訂はありません。改訂履歴のページには2022-03-31版までの旧版が残っており、社内標準が過去の版を参照している場合の差分確認に使えます。
ワークロードとコンポーネントの定義を取り違えたときに起きるレビューの破綻
質問は独自の用語で書かれており、ここを取り違えるとレビューの単位そのものがずれます。コンポーネントは、ある要件を満たすために組み合わされたコード・設定・AWSリソース。技術的な所有単位になることが多く、他とは疎結合に保たれます。ワークロードはビジネス価値を提供するコンポーネントの集合で、ビジネス側と技術側が会話するときの粒度。単一アカウント内の一部リソースのことも、複数アカウントにまたがることもあります。マイルストーンは設計・実装・テスト・本番投入といった節目の記録です。
作業量（level of effort）の3段階と、自組織の基準へ読み替える手順
改善項目の見積もりに使う「作業量（level of effort）」にも定義があります。高は数週間から数か月、中は数日から数週間、低は数時間から数日。この定義が入ったのは2022年10月20日の改訂で、それ以前の資料には3段階の目安そのものがありません。
そのままでは粗すぎるので、自社の1スプリントが何日かを当てはめて読み替えてください。2週間スプリントの組織なら、低は1スプリント内、中は1〜2スプリント、高は四半期の計画に載せる項目。読み替えを先に済ませると、当期に着手できる件数が自動的に決まります。
Well-Architectedレビュー（WAFR）の進め方と、数時間で終える実施設計
AWSのドキュメントでは「AWS Well-Architected フレームワークレビュー」と表記され、実務やパートナー各社の資料ではWAFRと略されます。基礎的な質問に答え、クラウドのベストプラクティスに沿っているかを確認し、必要な是正を洗い出す作業です。
非難を挟まない会話として設計する進行の型と、実施タイミングの決め方
レビュープロセスの公式ページは、非難を挟まない（blame-free）進め方で一貫して行うべきであり、日単位ではなく時間単位（hours not days）の軽量なプロセスで、監査ではなく会話だと書いています。前提を共有しないまま実施すると、担当者は指摘を回避する方向に動く。公式が勧めるのは形式的なレビュー会議ではなく、作ったチーム自身が継続的に回答を更新するやり方です。他チームのワークロードなら、非公式な会話を数回重ねて大半の回答を集め、曖昧な点だけを会議で掘り下げます。
タイミングは製品ライフサイクルの節目に合わせます。公式が指定するのは設計フェーズの早い段階と本番投入前の2点。前者の理由は、あとから変えるのが難しい「一方通行の扉（one-way door）」を避けるためです。取り消せる判断は軽い手続きで進め、取り消せない判断だけ先に念入りに検査する。本番投入後も機能追加で設計は劣化するため、大きな変更のたびに挟みます。「忙しい」という反論には、大きなローンチを控えているならこそ見落としたリスクを洗うべきだと公式ページが答えています。
プロファイルとレビューテンプレートによる質問の絞り込みと回答の標準化
すべての質問に均等な力で答えようとすると、レビューは完走しません。WA Tool のプロファイルは、自社のビジネス状況とレビューで達成したい目標を登録しておく機能。その情報をもとに関連性の高い質問が優先表示され、改善計画側でも優先すべきリスクが分かります。
レビューテンプレートのほうは、Framework やカスタムレンズの質問への回答をあらかじめ埋めておく仕組み。共通のベストプラクティスを毎回手入力する手間が消え、チーム間で回答の水準もそろいます。ワークロードが数十本ある組織では、この2つを使うかどうかでレビューの回転数が変わります。
マイルストーンで前後差分を残す記録の取り方と、最初の保存の起点
マイルストーンは、ある時点のワークロードの状態を記録したものです。公式ガイドが勧めるのは、質問へ一通り回答し終えた時点で最初の1本を保存し、改善計画に沿って手を入れるたびに追加保存すること。前後を比較できないと、レビューは「実施した」という事実だけが残ります。
AWS Well-Architected Toolの費用とレンズ16種の適用上限
AWS Well-Architected Tool（WA Tool）は、フレームワークの質問に沿ってアーキテクチャを測定するマネージドサービスです。判断の記録、改善提案、信頼性・セキュリティ・効率・コスト面の改善指針の提示を担います。
追加料金なしで使える範囲と、稟議で論点になる実費の切り分け方
日本語の料金ページには「AWS Well-Architected Tool の利用に追加料金はかかりません。基礎となる AWS リソースのみに対してお支払いいただきます」と記載されています。障壁は費用ではなく、レビューに人を出せるかどうか。金額が論点になるのは、後述する Trusted Advisor の全チェックを併用する場合と、改善計画を実装する工数のほうです。
レンズカタログ16種の内訳と、同時追加5・1ワークロード最大20の制約
レンズは、特定の技術領域や業種の観点を質問セットとして追加する仕組みです。ワークロードを定義すると AWS Well-Architected Framework レンズが自動適用され、必要に応じて追加のレンズを重ねます。公式レンズはレンズカタログとして、追加インストールなしで全ユーザーへ提供されています。
| 区分 | レンズ名 | 区分 | レンズ名 |
|---|---|---|---|
| 基本 | Framework（既定適用） | 業種 | Financial Services |
| 技術領域 | Container Build | 業種 | Healthcare Industry |
| 技術領域 | DevOps | 業種 | Government |
| 技術領域 | Generative AI | 業種 | Connected Mobility |
| 技術領域 | IoT | 業種 | SaaS |
| 技術領域 | Machine Learning | 業種 | SAP |
| 技術領域 | Serverless Applications | 事業活動 | Migration |
| 技術領域 | Data Analytics | 事業活動 | Mergers and Acquisitions |
2026年9月時点のカタログは、既定で適用されるフレームワークレンズを含めて16種類。適用には上限があり、一度に追加できるのは5つまで、1つのワークロードに適用できるレンズは最大20です。外してもデータは保持され、再度追加すれば復元されます。
カスタムレンズで社内標準を取り込む条件と、別管理のチェックリストの扱い
公式レンズでは表現しきれない基準は、カスタムレンズとして自作できます。独自の柱・質問・ベストプラクティス・改善計画を定義でき、他のAWSアカウントとの共有も可能。社内の技術標準をレビューへ組み込みたいなら、チェックリストを別管理せずカスタムレンズへ寄せるほうが、回答履歴とマイルストーンが1か所に集約されます。
組織共有・Jira連携・CLI初期化で複数ワークロードのレビューを回す設定
ワークロードが1本なら画面操作で足ります。10本を超えたあたりから、共有設定と改善項目の追跡、初期化の自動化が効いてくる。公式ドキュメントに手順があるのに、解説記事では省かれがちな領域です。
AWS Organizations連携で招待なしに共有するための有効化の順序
WA Tool はワークロード・カスタムレンズ・プロファイル・レビューテンプレートの4種類を他アカウントと共有できます。AWS Organizations の管理下なら、個別アカウントを列挙せず組織全体またはOU単位で共有でき、招待のやり取りも発生しません。
ここには順序の落とし穴があります。必ずWA Toolのコンソールか AWS CLI から有効にしてください。AWS Organizations 側のコンソールで信頼されたアクセスを有効にしても、サービスリンクロール AWSServiceRoleForWellArchitected が作成されず、組織内共有ができません。組織は全機能が有効である必要があり、操作は管理アカウントのプリンシパルで行います。リージョン別のサービスなので、共有先は作成したリージョンでしかアクセスできない点も設計時に効く。アカウント構成の組み方はAWS Organizationsのマルチアカウント管理で整理しました。
Jiraコネクタが作るエピック・タスク・サブタスクの対応関係
リスクを洗い出したあと、改善項目が誰のバックログにも入らないまま消える。これがよくある失敗です。AWS Well-Architected Tool Connector for Jira は改善項目をJiraプロジェクトへ同期し、改善を閉ループにします。同期は自動と手動から選択。
同期後の構造は固定です。プロジェクトが WA（または指定した既存プロジェクトキー）、エピックがワークロード、タスクが質問、サブタスクがベストプラクティス、ラベルが柱。設定はアカウント単位とワークロード単位の両方で持て、ワークロードごとの上書きや同期除外もできます。対応するのはJiraのスクラムとカンバンだけです。
CLIでワークロードを定義し、レビューの初期化を手順書から外す方法
ワークロードの登録はコンソール専用ではありません。aws wellarchitected create-workload で定義できます。必須は --workload-name（3〜100文字・一意）、--description（3〜250文字）、--environment（PRODUCTION か PREPRODUCTION）、--lenses の4つ。加えて --aws-regions か --non-aws-regions のどちらかが要ります。
aws wellarchitected create-workload \
--workload-name "order-api-prod" \
--description "EC order intake API" \
--environment PRODUCTION \
--aws-regions ap-northeast-1 \
--review-owner "[email protected]" \
--lenses serverlessレンズはエイリアス（serverless）でもARN（arn:aws:wellarchitected:ap-northeast-1::lens/serverless）でも指定できます。Framework レンズは自動適用されるため、追加分だけ並べれば足ります。--profile-arns と --review-template-arns を渡せばプロファイルとテンプレートを適用した状態で初期化でき、--jira-configuration で同期設定も同時に入る。新規案件の手順書から「WA Toolで手作業でワークロードを作る」という行を消せます。ワークロードの分割単位をAWS CDKのスタック分割とそろえておくと、登録の粒度と配備の粒度がずれません。
Trusted Advisorとの役割分担と2027年サポートプラン改編の影響
「Trusted Advisor があれば Well-Architected は不要か」という問いは頻出しますが、2つは代替関係ではありません。加えて2026年9月時点で、連携の前提になるサポートプランの体系が変わろうとしています。
チェックとレビューの守備範囲の違いと、両者を併用するときの順序
Trusted Advisor は、実際のAWS環境を検査して、コスト削減・可用性と性能の改善・セキュリティギャップの解消につながる推奨事項を提示するサービスです。対象は「いま存在するリソースの状態」。一方の Well-Architected Framework が問うのは設計上の意思決定とその根拠で、リソースを見ただけでは分からない要求水準や運用体制まで含みます。
順序は検査が先、会話が後です。WA Tool は Trusted Advisor および AWS Service Catalog AppRegistry と統合され、レビュー質問に答える情報を見つけやすくする補助として働きます。検査結果を材料に、設計判断を人が言語化する。カテゴリ別のチェック内容はAWS Trusted Advisorのチェック内訳と無料で使える範囲にまとめました。
2027年1月1日の廃止と、Business Support+移行で変わる最低利用金額
AWS Support のドキュメントと料金ページの記載は次のとおりです。
| プラン | 扱い | 最低利用金額 |
|---|---|---|
| Developer Support | 2027年1月1日に提供終了 | — |
| Business Support | 2027年1月1日に提供終了 | — |
| Enterprise On-Ramp | 2027年1月1日に提供終了 | — |
| Business Support+ | 移行先 | アカウントあたり29 USD/月 |
| Enterprise Support | 継続（最低額を引き下げ） | 5,000 USD/月 |
| AWS Unified Operations | 継続 | 50,000 USD/月 |
Developer Support と Business Support の利用者は、2027年1月1日までに Business Support+ へ移行するか、それまで既存プランを使い続けるかを選びます。Enterprise On-Ramp は2026年中に契約更新時または定期的なバッチ処理で Enterprise Support へ自動アップグレードされ、1か月前にメール通知される扱い。Enterprise Support の最低額は15,000 USD/月から5,000 USD/月へ下がり、専任のテクニカルアカウントマネージャー、15分の応答時間、追加料金なしの AWS Security Incident Response が含まれます。再編の対象外が AWS GovCloud（米国）リージョンです。
現行の Trusted Advisor の全チェックは、Business Support+、Enterprise Support、AWS Unified Operations のいずれかで使えます。プラン機能一覧では Business Support+ のチェック数を「500 を超える」と説明（2026年9月時点）。Basic Support ではサービスクォータの全チェックと、セキュリティおよび耐障害性の一部に限られ、自動更新もありません。Basic のままレビューを始めると、連携による情報収集はほぼ効かず、回答を手作業で集めることになります。
レビューが定着しない3つの局面と、外部委託を含む体制での回避策
フレームワーク自体は無償で公開され、ツールも追加料金なしで使えます。それでも定着しない原因は、ほぼ次の3つ。最も多いのは最初の粒度の誤りで、ここを外すと後の2つは自動的に発生します。
システム全体を1ワークロードにした瞬間に回答が形骸化する理由
1つ目は、レビュー対象の粒度です。「システム全体」を1ワークロードとして登録すると、質問の多くが「一部は該当するが一部は違う」状態になり、回答が形骸化します。ビジネス価値の単位で分けるという定義に立ち返り、部署をまたぐ大規模システムでも価値提供の単位ごとに分割して登録してください。個別の設計課題は、レビューとは別にスケーラブルなクラウドアーキテクチャ設計の基本のような指針で深掘りします。
高リスク20件で解散しないための、着手範囲の切り方と評価への紐づけ
2つ目は、リスクを洗い出したあとの停止です。改善計画に高リスクが20件並んだ状態で終わると、次の担当者はどこから手を付けるか判断できません。プロファイルでビジネス目標を登録して優先順位を絞り込み、作業量の3段階で当期に着手する範囲を切ってから解散してください。Jiraコネクタがあるなら同期まで済ませます。
3つ目は、レビューを評価の場にしてしまうこと。指摘件数を担当者の評価へ紐づける運用は目的と衝突するため、採用すべきではありません。記録すべきはリスクの件数ではなく、マイルストーン間の差分です。
内製だけで回すか外部を入れるかの判断基準と、見送ってよい場面
外部の設計者を入れるべきかは、条件で切れます。対象が1〜2ワークロードで、設計した本人たちが在籍していて、実装工数も確保できているなら外部は不要。前述のとおり公式が想定しているのは作ったチーム自身による継続的な見直しで、この条件を満たす組織が外部へ依頼しても、支払う金額に見合う情報は増えません。
価値が出るのは次のどちらかです。設計した担当者が既にいないワークロードを引き継いだ場合と、複数チームのレビュー結果を横断したときに同じ柱へリスクが固まっている場合。後者は公式ページでも「テーマ性のある課題（thematic issues）」として、個別の改善ではなく仕組み・教育・設計レビューの場で手を打つべきだと整理されています。可視性の実装はAWS X-Rayによる分散トレーシングやCloudWatch Application SignalsでのSLO設計が入口。引き継ぎや基盤の作り直しを含む相談はAWS・Google Cloud・Azureのインフラ構築で受けています。
よくある質問
AWS Well-Architected Framework について実際に検索されている質問に、公式ドキュメントの記述で答えます。
AWS Well-Architected Frameworkの6つの柱は何ですか？
運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト適正化（Cost optimization）、持続可能性の6つです。持続可能性は2021年11月20日の追加なので、5つの柱として説明している資料は版が古いと判断できます。セキュリティと運用上の優秀性は、他の柱とトレードオフしない扱いです。
Well-Architectedレビューは1回にどのくらい時間がかかりますか？
公式ドキュメントは、日単位ではなく時間単位（hours not days）の軽量なプロセスにすべきだと書いています。他チームのワークロードなら、非公式な会話を数回重ねて大半の回答を集め、曖昧な点だけを1〜2回の会議で掘り下げる方法が示されています。時間が延びるなら、ワークロードの粒度を先に疑ってください。
AWS Trusted AdvisorとAWS Well-Architected Frameworkの違いは何ですか？
Trusted Advisor は実際のAWS環境を検査してコスト・可用性・性能・セキュリティの推奨事項を出すサービス、Well-Architected Framework は設計上の意思決定を質問形式で点検する枠組みです。WA Tool は Trusted Advisor と統合され、質問に答えるための情報収集を助けます。検査が先、設計判断の言語化が後という順序で併用します。
AWS Well-Architected Toolの利用に料金はかかりますか？
かかりません。公式の料金ページに「AWS Well-Architected Tool の利用に追加料金はかかりません。基礎となる AWS リソースのみに対してお支払いいただきます」と記載されています。ただし Trusted Advisor の全チェックを併用するなら Business Support+ 以上の有償プランが別途必要で、最低額はアカウントあたり29 USD/月からです。
ワークロードとは何を指しますか？
ビジネス価値を提供するコンポーネントの集合を指します。単一のAWSアカウント内の一部リソースで構成されることもあれば、複数アカウントにまたがることも。小規模な企業なら数本、大企業では数千本になることもあるとされています。「システム全体」で1本にせず、価値提供の単位で分割するのが定義に沿った登録の仕方です。
Azure Well-Architected FrameworkとAWS版は同じものですか？
別物です。Microsoft も同名の設計フレームワークを提供していますが、質問セットも評価ツールも異なります。本記事で扱っているのはAWS版で、レビューには AWS Well-Architected Tool を使い、登録や共有もAWSアカウントの中で完結します。
関連記事
- AWS Trusted Advisorとは｜チェックの内訳と無料で使える範囲：レビューの回答材料になる自動検査の中身
- アクセス集中に対応するスケーラブルなクラウドアーキテクチャ設計の基本：信頼性とパフォーマンス効率の柱に対応
- AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方：運用上の優秀性で問われる可視性の実装面
- SSM Agentとは？できること・踏み台不要のSession Manager接続まで：セキュリティの柱で問われる管理経路の設計
- パラメータストアとは？料金・使い方・Secrets Managerとの違い：機密値の扱いを問われたときの実装の入口
