
この記事の要点
- 柱の数は、AWS が6つ、Microsoft Azure が5つ、Google Cloud が6つ(ほかに2つの横断の観点)で、名前は少しずつ違います
- 確かめるときは、柱ごとの問いに答えて、いまの構成のよくない点を洗い出し、直す順番を決めます
- 一度の確認で終わらせず、構成を大きく変えたときや、年に一度など決まった時期にくり返します
Well-Architected フレームワークは、クラウドの事業者が、設計と運用のよい習慣を、いくつかの「柱」に分けてまとめたものです。いまの構成をこの柱に沿って確かめると、運用・セキュリティ・信頼性・費用などのどこに弱いところがあるかを、偏りなく洗い出せます。
設計のときだけでなく、すでに動いているシステムの見直しにも使えます。担当者の経験や好みで点検の範囲が偏るのを防ぎ、「何を確かめたか」を説明しやすくなるのが、柱に沿って確かめる利点です。
3つのクラウドの柱
柱の数と名前は、クラウドの事業者ごとに少しずつ違います。2026年11月時点で、各社は次の柱を示しています。
| クラウド | 柱 |
|---|---|
| AWS | 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト、持続可能性(6つ) |
| Microsoft Azure | 信頼性、セキュリティ、コスト、オペレーショナル エクセレンス、パフォーマンス効率(5つ) |
| Google Cloud | 運用の優秀性、セキュリティ・プライバシー・コンプライアンス、信頼性、コスト、パフォーマンス、持続可能性(6つ。ほかに「AIと機械学習」「金融サービス」の2つの横断の観点) |
AWS は、運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト(Cost optimization)・持続可能性の6つの柱をおろそかにすると、期待や要件に応えるシステムを作るのが難しくなる、と説明しています。
出典:The pillars of the framework(AWS)
Microsoft は、Azure Well-Architected Framework の柱を、信頼性・セキュリティ・コスト(Cost Optimization)・オペレーショナル エクセレンス・パフォーマンス効率の5つとし、評価は Azure Well-Architected Review から始めるよう案内しています。
出典:Azure Well-Architected Framework pillars(Microsoft Learn)
Google Cloud は、運用の優秀性、セキュリティ・プライバシー・コンプライアンス、信頼性、コスト(Cost optimization)、パフォーマンス(Performance optimization)、持続可能性の6つの柱と、AIと機械学習・金融サービスの2つの横断の観点で、よい習慣を整理しています。
出典:Google Cloud Well-Architected Framework(Google Cloud)
名前は違っても、中身の多くは共通しています。使っているクラウドの事業者の柱で確かめるのが基本ですが、複数のクラウドを使っている場合は、どれか1つの柱の分け方にそろえて点検の表を作ると、結果を比べやすくなります。
柱ごとに確かめることの例
柱ごとに、どのようなことを確かめるのかの例を示します。実際の問いは、各社の資料と道具に用意されています。
運用
障害に気づく監視の仕組み、障害のときの手順書、変更の手順と記録、構成がコードで管理されているかなどを確かめます。
セキュリティ
権限が必要な範囲に絞られているか、管理者のアカウントに多要素認証がかかっているか、データが暗号化されているか、ログが残っているかなどを確かめます。最小の権限や多要素認証の状態は、この柱の中心になります。
信頼性
1つの機器や1つのデータセンターの障害で止まらない配置か、バックアップを取り、戻せることを確かめているか、復旧の目標(RTO・RPO)が決まっているかなどを確かめます。
パフォーマンス
サーバーの大きさや種類が使い方に合っているか、利用が増えたときに台数を増やせるかなどを確かめます。
コスト
使っていない資源が残っていないか、費用の内訳を部署やシステムごとに追えるか、予算の通知を設定しているかなどを確かめます。費用の見直しの進め方は、クラウドの費用を見直す(FinOps)の進め方で詳しく説明しています。
持続可能性
AWS と Google Cloud は、環境への負荷を減らす観点を柱に入れています。使っていない資源を止めることは、費用の見直しとも重なります。
確かめる進め方
柱に沿った確認は、次の流れで進めます。
- 対象を決める:どのシステム(ワークロード)を確かめるかを決め、構成図と関わる人をそろえます
- 問いに答える:柱ごとの問いに、いまの状態で答えます。分からない問いは「分からない」と記録します
- よくない点を洗い出す:答えから、よい習慣と違う点を一覧にします
- 直す順番を決める:事故につながりやすいもの、費用が大きいもの、すぐ直せるものから順番を付けます
- 直した後に確かめる:直した点を、もう一度問いに照らして確かめます
AWS の Well-Architected Tool は、ワークロードを測り、改善の進み具合を時間を追って記録するためのサービスです。自社で柱・問い・よい習慣・改善の計画を決めた独自の問いの集まり(カスタムレンズ)を作り、AWS が用意したレンズと同じように使うこともできます。
出典:AWS Well-Architected Tool User Guide(AWS)、Custom lenses(AWS)
2つ目の「分からない」という答えは、それ自体が大事な発見です。たとえば、バックアップから戻せるかを試したことがない、誰が管理者の権限を持っているか分からない、といった点は、柱に沿って問われて初めて気づくことがあります。
結果の生かし方
確かめた結果は、一度の報告書で終わらせず、運用の中で生かします。
- 直す項目を、担当者と期限つきで、ふだんの作業の一覧に入れる
- 直せない・直さないと決めた項目は、理由とあわせて記録する
- 構成を大きく変えたとき、移行の後、年に一度など、決まった時期に同じ確認をくり返す
- 前回の結果と比べて、よくない点が減っているかを見る
設定の誤りを継続して見つける仕組みとしては、CSPM(クラウドの設定の自動の点検)も使えます。Well-Architected の確認は、設定の点検だけでは分からない、運用の手順や体制の弱いところを見つけるのに向いています。
当社のご支援
当社は、Well-Architected の柱に沿った、いまのクラウドの構成の確認と、直す順番の整理を、クラウドの構築と運用管理のクラウドの現状チェックでお受けしています。まず自社で大まかに確かめたい場合は、クラウドの自己診断(無料)をお使いいただけます。当社が構築・運用している環境を確かめる場合は、自己点検として扱います。第三者の立場での確認が要る場合は、システム監査の決まりにもとづいてご相談ください。
- Well-Architected
- クラウド
- 運用
- 設計レビュー
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。