AWS Well-Architected Agentがクラウドレビューを自動化、人間による確認は依然必要
AWSは10月1日、AWS Well-Architected Agentのパブリックプレビューを開始し、65以上のAWSサービスを対象とする自動アーキテクチャレビューを提供した。このエージェントはインフラ、利用状況、アプリケーショントポロジーを調査し、コスト、セキュリティ、パフォーマンス、レジリエンスにまたがる変更を推奨する。対立点は明白だ。AWSはAIエージェントで手作業の監査を置き換えようとしているが、生成されたすべての修正を検証する責任は依然として顧客にある。
このサービスは、孤立した警告の一覧をもう一つ出すだけにはとどまらない。リソース設定をビジネス目標と結び付け、関連する検出結果をグループ化し、実装ガイダンスを生成する。一部の推奨事項には、改訂されたinfrastructure-as-codeファイル、コマンドラインの指示、定義済みの自動化ランブックが含まれる。
これにより、AWSのアーキテクチャレビューは日常的なエンジニアリングワークフローに近づく。ただし、AWS Well-Architected Agentが顧客のインフラを独自に運用するわけではない。AWSは、生成AIによる推奨事項には誤りや不完全な情報が含まれる可能性があると明示的に警告している。
したがって真の競争は、AWSと他のクラウドプロバイダーの間にあるのではない。文脈を踏まえた自動化と、専門家による人間の判断の間にある。AWSは検出を迅速化し、提案された修正をパッケージ化できるが、プラットフォームチームは依然として、その修正が自社アプリケーション、コンプライアンス上の義務、障害モデルに合致するかを判断しなければならない。
AWS Well-Architected Agentが静的なチェックリストを置き換える
AWSは、そのアーキテクチャフレームワークを質問票から、環境を認識する推奨システムへと変えた。
AWSのプレビュー発表は、このサービスを実際の顧客インフラ上に重ねるAI搭載レイヤーとして説明している。レビュー時に提供される回答だけに依存するのではなく、リソース設定、利用率メトリクス、アプリケーションの関係性を読み取る。
顧客はまずエージェントプロファイルを作成する。このプロファイルでは、エージェントが調査できるAWSアカウント、アプリケーション、リージョン、リソース、最適化領域を指定する。管理者は、検出結果の優先順位に影響を与えるべきビジネス目標も記述できる。
重要な顧客サービスの成長を準備するチームは、即時のコスト削減よりもレジリエンスを優先するかもしれない。別の組織は、セキュリティ制御や運用支出を重視する可能性がある。エージェントは、こうした宣言された優先順位を用いて、期待される影響と実装の労力に基づき推奨事項を順位付けする。
これは重要である。従来のクラウド推奨事項は、しばしば互いに切り離されたアラートとして現れる。一つのサービスが過大なコンピュートインスタンスを指摘する一方で、別のサービスは冗長性の不足を特定するかもしれない。どちらの検出結果も、そのアプリケーションのビジネス上の役割にとって、どの対策がより重要かを必ずしも説明しない。
AWS Well-Architected Agentは、こうしたシグナルを結び付けようとする。AWSによれば、65以上のサービスにわたるベストプラクティスを分析し、3つのレベルで推奨事項を生成する。
リソースレベルの検出結果は、個々のクラウドリソースに焦点を当てる。アプリケーションレベルの検出結果は、特定されたワークロード内の関連リソースを組み合わせる。アーキテクチャレベルの検出結果は、より広範な設計パターンを検討し、infrastructure as code、すなわちIaCへの変更を含めることができる。
IaCは、手作業によるコンソール変更ではなく、バージョン管理された設定ファイルを通じてインフラを表現する。プレビュー版では、Terraform、AWS CloudFormation、AWS Cloud Development Kitで記述されたプロジェクトをレビューできる。
このデプロイ前レビューにより、エージェントには第2の動作モードが与えられる。読み取り専用アクセスを通じてデプロイ済みリソースを調査することも、それらのリソースが本番環境に到達する前にアップロードされたIaCを分析することもできる。
推奨事項には、コンソールでの手順、AWS Command Line Interfaceコマンド、更新済みIaCテンプレートを含められる。一部の確立された検出結果では、定義された運用手順を自動化するAWS Systems Managerランブックも利用できる。
AWSによれば、エージェントプロファイルの作成後24時間以内に推奨事項が表示されるはずだという。その後、サービスは定期的に推奨事項を更新し、一度限りのアーキテクチャワークショップではなく、継続的なレビュ―サイクルを作り出す。
これは、既存のAWS Well-Architected Toolからの意味のある変化を示す。同製品は、質問、レンズ、マイルストーン、改善計画を通じた構造化されたワークロードレビューを支援する。対して新エージェントは、インフラの証拠と提供されたアプリケーションコンテキストから直接、検出結果を導き出す。
AWSはこのサービスを、Trusted AdvisorとWell-Architected Toolの両方を次世代へ進化させたものと呼ぶ。この説明は、この製品をAWSコンソールに追加された単なる別のアシスタントではなく、統合として位置付けている。
ただし、このサービスが現在評価するのは、コスト最適化、セキュリティ、パフォーマンス、レジリエンスの4領域である。より広範なWell-Architected Frameworkは、運用上の優秀性とサステナビリティも扱う。顧客は、このプレビュー版をあらゆるフレームワークレビューの完全な代替と見なすべきではない。
パブリックプレビューは、北バージニアのUS East、オハイオのUS East、オレゴンのUS Westにあるサービスエンドポイントを通じて利用できる。顧客は、他のAWS商用リージョンで稼働するワークロードをオンボードできる。
アクセスにはAWS Supportプランも必要となる。こうした境界条件により、初期リリースは、自動化されたコンテキストが従来の推奨フィードより優れた意思決定を生むかを検証する、管理されたテストとなる。
チャットインターフェースではなく、文脈こそが製品である理由
このエージェントの主な利点は、自然言語による助言を生成する能力ではなく、トレードオフを順位付けしようとする点にある。
クラウド環境はすでに大量の推奨事項を生成している。AWS Trusted Advisorはアカウント内の既知の問題を評価し、セキュリティおよび監視サービスも独自の検出結果を生成する。エンジニアリングチームは、検出そのものよりも優先順位付けに苦慮することが多い。
警告は技術的に正しくても、運用上は役に立たない場合がある。例えば、データベースは追加の冗長性による恩恵を受けるかもしれないが、その変更は支出とデプロイの複雑さを増加させる可能性がある。より小規模な社内アプリケーションなら、そのリスクを受け入れることもある。
AWS Well-Architected Agentは、アプリケーションコンテキストと宣言された目標を使い、これらの状況を区別しようとする。複数のリソースを一つのアプリケーションに関連付け、そのトポロジーを調査し、推奨事項の背後にあるトレードオフを説明できる。
AWSは、重要なデータベースにマルチAvailability Zoneフェイルオーバーを追加する例を挙げている。推奨事項は、関連するコストおよびパフォーマンス上の影響を示しながら、レジリエンス上の利点を説明できる。
こうした柱をまたぐ分析は重要である。アーキテクチャ上の判断が、すべての結果を同時に改善することはほとんどない。より強い冗長性はコストを増やし、より厳格なセキュリティは運用上の摩擦を加え、積極的な節約は余剰容量を減らす可能性がある。
汎用的なチェックリストは、制御項目を独立して評価するため、こうした対立を扱いにくい。新しいエージェントは、それらを横断して判断し、顧客が表明した優先順位に従って作業を順位付けすることを約束する。
この製品は、検出結果で終わるのではなく、実装パッケージも生成する。パッケージには、更新されたIaC、CLIの指示、特定されたリソースに合わせたコンソールのウォークスルーを含められる。
これにより、アーキテクチャ上の助言とエンジニアリング作業の間の隔たりの一部が埋められる。チームは設計改善の必要性を理解していても、広範な推奨事項をレビュー済みのコードへ落とし込む時間を欠くことが多い。
エージェントは、その変換をより速く行える。影響を受けるリソースを特定し、具体的な変更を提案し、APIを通じて推奨事項を公開できる。チームはその結果を開発および運用のワークフローと結び付けられる。
しかし、自然言語による推論が出力を権威あるものにするわけではない。プロファイルに入力されるビジネス目標は、実際の制約を単純化して表現したものだ。すべての契約、データ分類、依存関係、復旧義務を自動的に捉えることはできない。
アプリケーショントポロジーも、利用可能なAWSメタデータに依存する。タグ、リソース間の関係、アカウント境界は有用な構造を提供できるが、多くの組織は重要なコンテキストを別の場所で維持している。
決済サービスは、AWSテレメトリでは観測できないサードパーティーの決済処理事業者、社内承認プロセス、復旧に関する合意に依存しているかもしれない。可視化されたリソースだけに基づく推奨事項は、こうした関係を見落とす。
したがって結果の品質は、正確なインフラテレメトリ、有用なアプリケーションコンテキスト、明確に表明された目標という3つの入力に依存する。どれか一つでも弱ければ、正確に見えながら不完全な助言を生み出し得る。
このためAWSは、このエージェントを完全自律型のアーキテクトではなく、コンテキストを認識するインテリジェンスとして提示している。このシステムは証拠と提案アクションをパッケージ化するが、組織上の意味を与えるのは顧客でなければならない。
この仕組みは、フィードバック上の課題も生む。チームは有用な推奨事項と、技術的には有効でも自社ワークロードには適合しない提案を区別する必要がある。
抑制および完了の制御は、繰り返し発生するノイズを減らせる。それでも、このプレビュー版の価値は、チームが最も容易な検出結果を処理した後も、推奨事項が妥当性を保てるかに左右される。
クラウドアーキテクチャの自動化がプラットフォームチームに与える圧力
AWS Well-Architected Agentはレビュー作業を圧縮するが、経験豊富なプラットフォームエンジニアの必要性をなくすものではない。
アーキテクチャレビューでは従来、エンジニアが図を集め、設定を調べ、サービス所有者に聞き取りを行い、ワークロードを文書化されたプラクティスと比較する必要がある。特に複数のアカウントにまたがる場合、このプロセスには大きな調整が必要になり得る。
AWSは、証拠収集のレイヤーを自動化している。このエージェントは、チームがレビューパケットを組み立てるのを待たずに、リソースメタデータをスキャンし、利用パターンを分析し、接続されたコンポーネントを関連付けられる。
これは、コンサルティング主導や社内で予定されたレビューのプロセスに直ちに圧力をかける。自動サービスが年間を通じて検出結果を更新できるなら、四半期ごとの評価を正当化することは難しくなる。
プラットフォームチームも責任の変化に直面する。その役割は、すべての問題を手作業で発見することから、推奨事項のガバナンス、実装パッケージの検証、再利用可能なポリシーの維持へと移る。
作業が消えるわけではない。レビュー、例外処理、リスク所有により近い場所へと移行する。
生成されたTerraformの変更でも、コードレビューが必要である。エンジニアは、リソース置換のリスク、状態管理への影響、プロバイダーの挙動、エージェントがモデル化しなかった依存関係を調査しなければならない。
提案されたCLIコマンドも精査を要する。限定的に見えるコマンドでも、本番リソースに適用されたり、誤ったアカウントで実行されたりすれば、可用性に影響を及ぼす可能性がある。
ここで、助言と権限の違いが決定的になる。AWS Well-Architected Agentは変更を推奨できるが、その推奨によって説明責任が顧客から移ることはない。
AWSは、確立された責任共有モデルを維持している。AWSはクラウドサービスを提供するインフラを保護し、顧客は自らの管理下にある設定、ワークロード、アイデンティティ、データに引き続き責任を負う。
このエージェントは、よく知られた設計上の問題を見つけるために必要な専門性を減らすかもしれない。しかし、組織のリスク許容度を判断したり、規制対象システムに影響する変更を承認したりすることはできない。
専任のクラウドアーキテクトを欠きながらも、基本的なチェックリストを超える複雑さのワークロードを運用している小規模チームこそ、圧縮された分析から最も恩恵を受ける可能性がある。
リソースの調査結果を結び付け、実装指針を提示するエージェントは、こうしたチームにより強固な出発点を与えられる。外部アドバイザーとの会話も、より焦点の定まったものにできる。
大企業には異なる機会がある。APIアクセスを利用し、既に所有権、テスト、承認ルールが整備されている既存のエンジニアリングシステムへ推奨事項を取り込める。
こうした組織にとって、このサービスはコントロールプレーンにおける新たなシグナルとなる。その有用性は、チケット管理、デプロイ、例外処理、コンプライアンスのプロセスとの統合に左右される。
この発表は、社内クラウドプラットフォームへの期待も高める。開発者は今後、別途実施される年次レビューではなく、コードやリソースの横にアーキテクチャ指針が表示されることを期待するようになるだろう。
これはフィードバックの速度を改善しうる。一方で、推奨事項に精度がなかったり、ローカル標準を反映していなかったりすれば、生成された作業がチームに押し寄せる可能性もある。
したがって、経験豊富なエンジニアがキャリブレーション層となる。どの指摘をポリシー化するか、どれにアプリケーション固有のレビューが必要か、どれを抑制したままにすべきかを判断する。
エージェントによる定型的な分析の精度が高まるほど、人の注意は非定型の障害モードへ向けられる。そこには、システム間の依存関係、組織上の制約、標準化されたAWSシグナルでは捉えられないリスクが含まれる。
これはアーキテクチャ業務の撤廃ではない。機械が生成した証拠を中心に、その業務を再配分することだ。
AWS、Azure AdvisorとGoogle Cloud Recommenderに挑む
AWSは確立済みのクラウド推奨市場に参入するが、アプリケーションレベルのコンテキストと生成型の是正策によって競争しようとしている。
MicrosoftとGoogleはすでに、それぞれのクラウドプラットフォーム全体で自動化されたガイダンスを提供している。両社の製品は、顧客が最適化の推奨事項をクラウドのコントロールプレーンの一部として期待していることを示している。
Azure Advisorは、リソース構成と利用テレメトリーを分析する。コスト、パフォーマンス、信頼性、セキュリティ、運用上の優秀性にわたって推奨事項を分類する。
MicrosoftはAzure Advisorを通じてWell-Architected評価も提供している。これらの評価では、厳選された質問を用いて、Azureフレームワークの5つの柱にまたがるワークロードのギャップを特定する。
Google Cloud Recommenderは、リソース利用状況、構成データ、機械学習、ヒューリスティクスを用いて機械生成の提案を作成する。その推奨事項には、コスト、パフォーマンス、セキュリティ、管理性、持続可能性への影響が含まれうる。
両競合はAPIとクラウドコンソールを通じて推奨事項を公開している。また、特定の指摘をレビュー、却下、適用するための運用ワークフローにも対応している。
AWSが導入するのは、自動化されたクラウドアドバイスという発想そのものではない。差別化ポイントは、単一のエージェントがメトリクス、構成、アプリケーショントポロジー、明示されたビジネス目標を組み合わせられるという主張にある。
3層構造は分析単位も拡張する。通常、リソース推奨ツールは単一の製品または構成から始まる。AWSによれば、そのエージェントはアプリケーションおよびアーキテクチャレベルで指摘を統合できる。
複数のリソースが個別には許容できても、全体として脆弱なシステムを構成する場合、この違いは重要になる。すべてのコンポーネントがローカルの構成ルールを満たしていても、アーキテクチャは失敗しうる。
生成されたIaC変更は、もう一つの競争上の切り口となる。冗長性の向上や設計の調整を顧客に指示するのではなく、サービスは変更を表現するコードを提案できる。
ただし、このエージェントはAWS環境内でのみ機能する。AWS商用リージョンのワークロードをオンボードできるが、そのドキュメントにはAzure、Google Cloud、オンプレミスインフラストラクチャの分析は記載されていない。
この境界は、マルチクラウド組織にとって構造的な弱点となる。最も重要なアプリケーションは、多くの場合、IDプロバイダー、データサービス、ソフトウェアプラットフォーム、複数のクラウドベンダーにまたがっている。
AWSだけのトポロジーは、AWSリソースがどのように接続されているかを示せる。しかし、復旧経路がAWS外部のシステムに依存するサービスを完全にモデル化することはできない。
同じ制約はビジネスコンテキストにも及ぶ。AWSは自社サービスの構成を深く理解しているが、プロバイダー固有の最適化は、自然とプロバイダー固有の製品を優先しうる。
ある推奨事項はAWSの設計空間では正しくても、その外部にあるより単純なアーキテクチャ上の選択肢を見落とす可能性がある。それは推奨事項が誤解を招くことを意味しないが、利用可能な回答の範囲を狭める。
AzureとGoogleも、自社プラットフォーム内では同じインセンティブに直面する。推奨システムが顧客にとって信頼されるアーキテクチャ層となれば、どのクラウドプロバイダーも利益を得る。
これは、クラウドロックインを技術的なもの以上に知的なものにする。顧客はサービスを採用するだけではない。運用上の優先順位、アプリケーションマッピング、是正履歴、レビュー習慣を、プロバイダーのコントロールプレーンに組み込み始める。
組織は、こうしたサービスと並行して独自のアーキテクチャ標準を維持すべきだ。プロバイダーの推奨事項は証拠と実装支援を提供できる一方、社内ポリシーはクロスプラットフォームの視点を維持する。
競争の試金石は、生成される指摘の数ではない。AWS Well-Architected Agentが、エンジニアに受け入れられ、デプロイされる推奨事項を一貫して生み出せるかどうかだ。
読み取り専用アクセスはリスクを抑えるが、生成された修正にはなおレビューが必要
AWSは制約付きアクセスでプレビューを設計したが、推奨事項そのものは依然として運用リスクの源となる。
エージェントは、顧客管理のIdentity and Access Managementロールを使用する。IAMは、どのAWS IDとサービスが特定のリソースおよびアクションにアクセスできるかを制御する。
AWSのアクセスモデルによれば、顧客はエージェントプロファイル用の実行ロールを作成する。このロールは、選択した対象アカウント内の読み取り専用アクセスロールを引き受けることができる。
この設計は、ロールの所有権を顧客側に維持しながら、マルチアカウント環境全体の分析を支援する。組織は必要に応じて権限をカスタマイズし、信頼を取り消し、アクセスを終了できる。
AWSは、本番ワークロードを置かない専用アカウントからプロファイルを運用することを推奨している。また、AWS CloudTrailを通じてエージェントの活動を監視するよう顧客に勧めている。
サービスはリソーステレメトリー、利用パターン、構成データを調査する。AWSのドキュメントによると、Amazon S3オブジェクトやデータベースレコードなど、ストレージサービスのコンテンツは読み取らない。
管理対象の権限は、検出と分析に読み取り専用アクションを使用する。エージェントは、これらのスキャン権限を通じて顧客リソースを作成、変更、削除することはできない。
こうした境界は、分析中のエラーによる影響範囲を縮小する。しかし、収集されるメタデータの機微性をなくすものではない。
アプリケーショントポロジー、リソース名、アカウント構造、構成、利用パターンは、組織に関する重要な詳細を明らかにしうる。セキュリティチームは、エージェントに検査させるアカウントを決定しなければならない。
クロスアカウント展開では、IAM構成の正確性がさらに重要になる。プロファイルの実行ロールは、サービスが複数の環境を調査できる経路となる。
AWSは、プロファイルに紐付くロールチェーンと外部識別子を使用し、混乱した代理人のリスクを軽減している。混乱した代理人とは、信頼されたサービスが意図しない当事者のために自身のアクセスを使うよう操作される場合に発生する。
顧客はなお、信頼ポリシー、権限、ログ、アカウントのスコープを検証する必要がある。読み取り専用アクセスは書き込みアクセスより安全だが、過剰な可視性は依然としてガバナンス上の問題になりうる。
より大きな不確実性は、生成された推奨事項に関わる。AWSはセキュリティガイダンスで、エージェントがAI生成の是正策を自動実行しないと述べている。
顧客は、レビュー、テスト、実装のためのガイド付きアクションを受け取る。それらのアクションが適切かどうかを判断する責任は、引き続き顧客にある。
確立されたTrusted Advisorの指摘には限定的な例外がある。エージェントは顧客の同意を得て、事前定義されたSystems Managerランブックを実行できる。これらのランブックは、新たに生成された是正コードではなく決定論的なものだ。
この分離は理にかなっている。生成されたIaCとコマンドは提案にとどまり、事前定義された自動化はテスト済みの運用経路に従う。
もっともらしい提案であっても、コンテキスト上は誤っている場合がある。別のチームが管理するリソースを変更したり、外部モジュールと競合したり、慎重に設計されたパフォーマンス余裕を損なったりする可能性がある。
また、修正は目に見える柱を最適化する一方で、モデル化されていない影響を生む可能性がある。レジリエンスの変更はネットワーク動作を変えうる一方、コストに関する推奨事項はトラフィック急増時に利用できる容量を削減しかねない。
AWSは、生成AIの出力にはエラーや不完全な情報が含まれうることを明確に認めている。この警告は、導入モデル全体を形作るべきだ。
チームは、生成された変更を、人間が作成したインフラストラクチャコードに用いるのと同じ統制に通すべきである。これには、ピアレビュー、自動テスト、ポリシーチェック、段階的なデプロイ、ロールバック計画が含まれる。
推奨事項の精度は一つの指標にすぎない。企業には、偽陽性、見逃されたリスク、繰り返しのレビューにおける一貫性についての証拠も必要だ。
プレビュー発表では、独立した精度ベンチマークは提供されていない。また、顧客がその推奨事項をどの程度受け入れ、修正し、抑制し、元に戻すのかも定量化されていない。
こうした結果が明らかになるまで、AWS Well-Architected Agentは、特に実行可能性の高い出力を持つ助言システムとして扱うべきだ。環境が安全またはレジリエントであることを自動的に認定するものではない。
プレビューの重要性を左右する3つのシグナル
導入は、推奨事項の品質、ワークフロー統合、そして自動レビューが実際の本番成果を改善するという証拠に左右される。
最初のシグナルは受容行動だ。AWSは、顧客が大幅な修正なしに推奨事項をどの程度実装したかを示すプレビューデータを公開していない。
高い受容率は、エージェントがエンジニアリング作業を減らせるほど十分なコンテキストを理解していることを示唆する。頻繁な抑制や大幅な書き換えは、生成された具体性が実際の理解を上回っていることを示すだろう。
最も有用な指標は、リソース、アプリケーション、アーキテクチャの推奨事項を分けて示すものだろう。単純なリソースの指摘は、ワークロード全体に影響する変更よりも自動化しやすい。
第2のシグナルは、エンジニアリングワークフローとのより深い統合だ。AWSはすでにAPIを通じて推奨事項を公開しており、AWSの開発者向けインターフェースを通じてコーディングツールとの接続もサポートしている。
顧客は、エージェントがコードリポジトリ、デプロイパイプライン、課題トラッカー、ポリシーエンジンとのより強力な統合を獲得するかを注視すべきだ。これらの接続によって、指摘が統制された作業になるのか、単なる別のコンソールフィードにとどまるのかが決まる。
統合では承認の境界を維持しなければならない。重要な節目は自律的な実行ではなく、推奨事項からレビュー済みの変更までを追跡可能に移行できることだ。
チームは、誰が指摘を受け入れたか、どのコードが変更されたか、どのテストが実行されたか、期待した結果が得られたかを把握する必要がある。この連鎖がなければ、生成された是正策は運用上の曖昧さを増やしかねない。
第3のシグナルは競合他社の対応だ。MicrosoftとGoogleはすでに成熟した推奨システムを提供しているが、AWSはアプリケーションコンテキストとアーキテクチャレベルの修正をめぐる期待を高めている。
競合各社が目標認識型の分析や生成されたIaCへと製品を拡張すれば、AWSはクラウド管理におけるより広範な変化を実証したことになる。一方で、決定論的な推奨事項を強調するなら、市場は生成型とルールベースのアプローチに分かれる可能性がある。
顧客は、AWSがプレビューの4つの柱を超えて対象範囲を広げるかも注視すべきだ。運用上の優秀性と持続可能性は、より広範なWell-Architected Frameworkにおいて引き続き重要な要素である。
追加リージョンへの対応、より明確なサービス制限、文書化された評価手法があれば、この製品の説得力はさらに高まるでしょう。複雑な複数アカウント環境でも推奨の品質が維持されることを示す証拠も必要です。
AWS Well-Architected Agentは、すでにドキュメントを会話形式で提供するだけのラッパーではありません。顧客環境を読み取り、検出事項を優先順位付けし、実装までの道筋を提案します。
未解決の問いは、そのコンテキストが本番環境に影響を及ぼすアーキテクチャ上の意思決定に十分かどうかです。AWSはアクセスと実行に関する安全策を整備していますが、顧客側は信頼に関する安全策を構築する必要があります。
開発者やプラットフォームリーダーにとって、適切な第一歩は範囲を限定した評価です。十分に理解されたワークロードを選び、プロファイルの対象範囲を制限し、その検出結果を既存の人によるレビューと比較します。
どの推奨が採用、修正、抑制、または却下されたかを追跡してください。次に、適用した変更が期待どおりのコスト、セキュリティ、パフォーマンス、またはレジリエンスの成果をもたらしたかを検証します。
表示される検出事項の数よりも、その証拠のほうが重要です。AWS Well-Architected Agentが変更リスクを高めることなく専門家の時間を一貫して節約できれば、アーキテクチャレビューは継続的なものになるでしょう。洗練されていても不完全な修正しか生み出せない場合、人間の判断が引き続きシステムで最も重要な要素となります。
