AWS Well-Architected Agentは、AWSアカウント内のリソースを継続的にスキャンし、コスト・セキュリティ・レジリエンス・パフォーマンスの4分野で改善案を出すAIサービスです。2026年10月1日にプレビューとして公開され、AWSはこれをTrusted AdvisorとWell-Architected Toolの次世代版と位置づけています。この記事では、使えるサポートプランとリージョンの条件、実行ロールとアクセスロールの設定、CLIでのプロファイル作成、TerraformやCDKのテンプレートを診断するアーキテクチャレビュー、推奨事項の直し方までを、2026年10月19日時点の公式ドキュメントに沿って手順で示します。
まとめ：Well-Architected Agentを試す前に確かめる前提条件と使いどころ
最初に確かめるのはサポートプランです。Business+以上でないとプロファイルを作れず、監視対象の全アカウントがBusiness+以上でないと、そのアカウントの推奨事項はベータ版のアプリケーション単位に限られます。プロファイルを置けるのは米国の3リージョンだけで、東京リージョンのリソースはそこからスキャンする形になります。
向いているのは、複数アカウントでTrusted AdvisorやSecurity Hubの指摘が溜まり、どれから直すかを決められていない組織です。事業目標を文章で登録すると、その目標に沿って優先順位が付きます。逆に、単一アカウントでBasicプランのまま運用している環境では、サポート費用が先に発生するため、Trusted Advisorの無料範囲から始める方が筋が通ります。
AWS Well-Architected Agentの仕組みと既存サービスの役割比較
製品の中身を、既存サービスとの関係から整理します。
週1回の定期スキャンで3階層の推奨事項を出す仕組みと4つの柱
公式ユーザーガイドによると、推奨事項はリソース単位・アプリケーション単位・アーキテクチャ単位の3階層で出ます。リソース単位はEC2インスタンスやLambda関数など1つの資源への指摘、アプリケーション単位は関連する複数リソースのつながりを見た指摘です。アーキテクチャ単位だけは定期実行されず、IaCテンプレートを渡して手動で生成します。
定期スキャンの推奨事項はおおむね7日ごとに更新され、1回の生成で出る推奨事項は最大30件です。各推奨事項には、他の柱への影響と、実施した場合のトレードオフ（どの柱にどの程度のリスクが出るか、その緩和策）が付きます。対象の柱はCost optimization・Security・Resilience・Performanceの4つで、Well-Architected Frameworkの6本柱のうち運用上の優秀性と持続可能性は含まれません。
Trusted Advisor・WA Toolとの役割分担と入力データの比較
関連サービスの説明では、Well-Architected Agentは既存サービスの検出結果を入力として取り込み、その上に優先順位付けと修正手順を重ねる構成だと書かれています。
| サービス | Agentが受け取るもの | Agentが足すもの |
|---|---|---|
| Trusted Advisor | チェック結果 | 目標に沿った優先順位・修正手順 |
| Compute Optimizer | EC2・Lambda・RDSのサイズ提案 | アプリ構成と目標を踏まえた判断 |
| Security Hub CSPM | セキュリティの検出結果 | 柱をまたぐトレードオフ分析 |
| Resilience Hub | 耐障害性の評価 | RTO・RPO目標との照合 |
| Cost Explorer | リソース単位の実コスト | コスト推奨の金額根拠 |
| Well-Architected Tool | （並行して利用） | 手動レビューを自動分析で補う |
つまり、元になる指摘はTrusted AdvisorやAWS Compute Optimizerがすでに出しているものが中心です。Agentの価値は新しい検出項目より、散らばった指摘を1つの優先順位にまとめる点にあります。Trusted Advisor単体で何が見られるかはAWS Trusted Advisorとはで整理しています。
プレビュー版の利用条件：Business+以上のサポートプランと3リージョン
試す前に詰まりやすいのは、技術的な設定よりも契約とリージョンの条件です。
サポートプラン別のプロファイル上限とBusiness+の月額最低29ドル
クォータの一覧では、使えるかどうかと上限がサポートプランで決まっています。
| サポートプラン | 利用 | プロファイル上限 | 1プロファイルのアプリ上限 |
|---|---|---|---|
| Developer・Business | 不可 | － | － |
| Business+ | 可 | 2 | 7 |
| Enterprise（On-Ramp含む） | 可 | 10 | 30 |
| Unified Operations | 可 | 10 | 30 |
サポートプランの料金ページでは、Business Support+はアカウントごとに月額最低29ドルで、月間利用料1万ドルまでは9%、1万〜8万ドルは7%と段階的に下がります。月2万ドル使うアカウントなら月1,600ドルです。Agent自体の料金は、What's Newとユーザーガイドのどちらにも2026年10月19日時点で記載がありません。
監視対象の全アカウントにBusiness+が要る条件と東京リージョンの扱い
見落としやすいのが、導入手順ページの注意書きです。Business+以上が必要なのはプロファイルを作るアカウントだけではなく、監視対象に入れた全アカウントです。BasicやDeveloperのアカウントが混ざると、AgentはそのアカウントのTrusted Advisor APIを呼べず、推奨事項がベータ版のアプリケーション単位だけになります。Organizationsを使わずに個別契約しているアカウントで起きやすい問題です。
プロファイルを置けるのはバージニア北部・オハイオ・オレゴンの3リージョンです。スキャン対象はすべての商用リージョンなので、東京リージョンのリソースも診断できます。ただし、プロファイル自体は米国リージョンに作られるため、データの保管場所に社内規程がある場合は先に確認が要ります。
CLIでエージェントプロファイルを作成し推奨事項の生成まで進める手順
コンソールでも作れますが、アカウント数が多い場合や手順を残したい場合はCLIが確実です。APIはIAMロールを作らないため、ロールの準備から始めます。
実行ロールとアクセスロールの2段構成と信頼ポリシーの具体的な設定例
概念の説明によると、ロールは2種類です。プロファイルを置くアカウントの実行ロールをwellarchitected.amazonaws.comが引き受け、実行ロールが各ワークロードアカウントのアクセスロールを引き受けます。アクセスロールには、リソースのメタデータと設定を読むだけのWellArchitectedAgentResourceScanningを付けます。どちらのロールにも書き込み権限はありません。
各ワークロードアカウントで作るアクセスロールの信頼ポリシーは次の形です。111122223333はプロファイルを置くアカウントIDです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/service-role/ExecutionRoleForWellArchitectedAgent"
},
"Action": "sts:AssumeRole"
}
]
}落とし穴はARNのservice-role/です。コンソールの「Create new role」で作った実行ロールはこのパスの下に置かれ、IAMで事前に手作りしたロールは置かれません。どちらで作ったかを取り違えると、信頼関係が成立せずスキャンが始まりません。ロールと信頼ポリシーの基本はAWS IAMとはで解説しています。
CLIの4コマンドによるプロファイル作成から定期生成の適格性確認まで
API quickstartでは、create-agent-profileからget-agent-profileまでを実行します。その流れは、プロファイル作成、目標の追加、アプリケーション情報の追加、適格性の確認の4段階です。
aws wellarchitected create-agent-profile \
--name "prod-profile" \
--execution-role-arn "arn:aws:iam::111122223333:role/service-role/ExecutionRoleForWellArchitectedAgent" \
--pillars COST_OPTIMIZATION SECURITY RESILIENCE PERFORMANCE \
--aggregation-configuration '[{"accountId":"444455556666","accessRoleArn":"arn:aws:iam::444455556666:role/AccessRoleForWellArchitectedAgent","regions":["ap-northeast-1"]}]'
PROFILE_ARN="arn:aws:wellarchitected:us-east-1:111122223333:agent-profile/prod-profile"
aws wellarchitected create-agent-goal --profile-arn "$PROFILE_ARN" \
--title "EC2のライトサイジングで月額費用を20%下げる" --pillars COST_OPTIMIZATION
aws wellarchitected create-agent-context --profile-arn "$PROFILE_ARN" \
--title "受発注システム" --context-type APPLICATION \
--content '{"applicationOverview":"受発注と在庫引当のWebシステム","criticality":"BUSINESS_CRITICAL","accountIds":["444455556666"],"regions":["ap-northeast-1"]}'
aws wellarchitected get-agent-profile --profile-arn "$PROFILE_ARN" \
--query '{eligible: eligibleForScheduledGeneration, errors: fieldErrors}'目標は1プロファイルに最大10件まで登録でき、推奨事項の並び順を決める材料になります。「コスト削減」のような一語ではなく、対象・数値・期限を入れた文にすると、優先順位にも違いが出る仕組みです。最後のコマンドでeligibleがtrueになれば、定期生成の対象に入ります。初回の生成までの目安は、コンソール手順のページが24時間、API quickstartが48時間と書いており、ドキュメント内でも揃っていません。
定期生成の適格性がfalseとなる場合のエラー原因と確認する5項目
トラブルシューティングでeligibleForScheduledGenerationがfalseとなる原因は次の5つで、fieldErrorsにどれが該当するかが出ます。
- アプリケーション情報が1件も無い（定期生成には最低1件が必須）
- 柱が1つも選ばれていない
- アクセスロールの信頼ポリシーが実行ロールを指していない
- 実行ロールに
sts:AssumeRoleの権限が無い（コンソール作成時はワイルドカード不可） - 監視対象のアカウントが1つも登録されていない
実務で一番多いのは1つ目です。プロファイル作成の画面ではアプリケーション情報を求められないため、作っただけで止まっているプロファイルになりがちです。Organizationsのメンバーアカウントなら、SCPがwellarchitected:*とスキャン用ポリシーの操作を許可しているかも確かめます。SCPが読み取り操作を止めている場合は、プロファイルを作れても推奨事項が空のままになる状態です。SCPの継承の仕組みはAWS Organizationsとはにまとめています。
TerraformやCDKのテンプレートをアーキテクチャレビューに掛ける手順
デプロイ前のIaCを診断できる点が、Trusted Advisorには無い機能です。
S3に置くzipとフォルダのサイズ上限と1日5回のレビュー実行枠
アーキテクチャレビューの手順では、IaCのファイルをS3に置き、そのURIを渡します。対応するのはCloudFormation、AWS CDK、Terraformのプロジェクトです。zipなら25MBまで、S3フォルダなら合計100MBかつ1ファイル1MBまでで、バイナリや画像は対象から外れます。S3バケットはプロファイルと同じリージョンに置く必要があるため、東京リージョンのバケットにある成果物はそのままでは渡せません。
実行できるのは1プロファイルにつき1日5回です。使えるレンズはWell-Architected Frameworkの1種類だけで、サーバーレスやコンテナ向けのレンズはまだ選べません。修正版のテンプレートは元と同じ言語で返り、Terraformを渡せばTerraformのコードが戻ります。
CLIでアーキテクチャレビューを開始するコマンドと生成結果の確認
CLIでは、start-agent-recommendation-generationの種類にARCHITECTUREを指定して生成を開始します。オンデマンドで動かせるのはこの種類だけで、リソース単位とアプリケーション単位は定期生成を待つしかありません。
cd infra && zip -r ../infra-review.zip . -x "*.tfstate*" ".terraform/*"
aws s3 cp ../infra-review.zip s3://example-wa-review-us-east-1/infra-review.zip
aws wellarchitected start-agent-recommendation-generation \
--profile-arn "$PROFILE_ARN" \
--types ARCHITECTURE \
--name "order-system-review-1" \
--scope '{"pillars": ["SECURITY", "RESILIENCE"]}' \
--additional-context '{"s3Uri": "s3://example-wa-review-us-east-1/infra-review.zip", "lensArns": ["arn:aws:wellarchitected::aws:lens/wellarchitected"]}'
aws wellarchitected list-agent-recommendation-generations --profile-arn "$PROFILE_ARN"zipを作るときは.tfstateと.terraformを必ず除外します。stateファイルにはリソースの属性値が平文で入り、1日5回の枠とサイズ上限も無駄に消費するからです。CDKならテンプレート合成前のソース一式を渡せます。CDKのプロジェクト構成はAWS CDKとはで確認できます。
推奨事項の修正手順とSSM RunbookとAI生成手順の扱いの違い
推奨事項の直し方は、指摘の出どころによって2系統に分かれます。
Trusted Advisor由来のRunbookとAI生成のガイド付き手順の差
修正の実施方法によると、Trusted Advisorのチェックから来た推奨事項には、検証済みのSSM Runbookが用意されています。利用者の同意があればワンクリックで実行でき、定期実行の設定も可能です。一方、Agent自身が生成した推奨事項には、コンソール・AWS CLI・SDK（Python／boto3）から選べる段階別の手順書が付きます。手順書は実際のリソース名とARNを埋め込んだ形で作られ、対象のS3バケットが4つあれば4フェーズに分かれます。
AI生成の手順をAgentが代わりに実行することはありません。公式にも誤りや不足を含む可能性があると明記されています。CLI版の手順書をダウンロードして変更管理チケットに添付し、検証環境で流してから本番へ持ち込む運用にします。Runbookの実体であるAWS Systems Managerの権限設計も合わせて見直しておくと安全です。
完了・抑止・再オープンをCLIで記録して指摘の再発を追う運用
対応した推奨事項は状態を更新しておきます。完了にした指摘は履歴へ移り、同じ問題が次の更新で再発すると新しい推奨事項として出ます。
REC_ARN="arn:aws:wellarchitected:us-east-1:111122223333:agent-profile/prod-profile/recommendation/rec-id"
aws wellarchitected update-agent-recommendation-status --recommendation-arn "$REC_ARN" --status COMPLETED
aws wellarchitected update-agent-recommendation-status --recommendation-arn "$REC_ARN" \
--status SUPPRESSED --update-reason "検証環境のため冗長化は不要"
aws wellarchitected update-agent-recommendation-status --recommendation-arn "$REC_ARN" --status ACTIVE抑止には理由を必ず書きます。半年後に「なぜこの指摘を無視したのか」を説明できる記録になるからです。Trusted Advisorの指摘をEventBridgeで通知する仕組みをすでに組んでいるなら、Trusted Advisorの自動化の通知経路と二重通知にならないよう整理します。
Well-Architected Agentを導入する条件と見送る場面の判断基準
ここまでの仕様を踏まえて、導入の可否を言い切ります。
監視するアカウント数とサポート費用から見た採用ラインと見送るケース
採用するのは、すでにBusiness+以上を契約していて、監視したいアカウントが3つ以上ある組織です。追加の契約費用がかからず、Trusted Advisor・Security Hub・Compute Optimizerの指摘をアカウントごとに見て回る手間が、1つの優先順位付きリストに置き換わります。IaCをTerraformかCDKで管理しているなら、デプロイ前のアーキテクチャレビューも同じ枠で使えます。
見送るのは、Basicプランの単一アカウントでAgentのためだけにBusiness+へ上げる場合です。プレビュー中は仕様が変わる前提で、アプリケーション単位の推奨事項もベータ扱いです。まずTrusted Advisorの無料チェックとAWS Cost Explorerで現状を把握する方が費用対効果は高くなります。複数アカウントの権限設計やSCPの整理から手を付けたい場合は、一創のAWSインフラ構築サービスで構成の見直しから支援しています。
運用上の優秀性と持続可能性の柱をWA Toolのレビューで補う理由
Agentが扱うのは4つの柱だけです。運用上の優秀性（障害対応の手順、デプロイの安全策、監視の設計）と持続可能性は対象外のため、Well-Architected Toolでの質問形式のレビューは残します。運用上の優秀性の多くは手順書や体制など、リソースの設定からは読み取れない事柄で、スキャンでは判定できません。
役割を分けるなら、設定から判断できる4つの柱はAgentに任せ、人と手順に関わる部分を年1回程度のWA Toolレビューで確認する形が現実的です。セキュリティの検出そのものはAWS Security Hub側で有効化しておかないと、Agentに渡る材料が減る点にも注意します。
よくある質問
プレビュー開始直後に寄せられやすい質問をまとめます。
AWS Well-Architected Agentは無料で使えますか？
2026年10月19日時点で、What's NewとユーザーガイドのどちらにもAgent自体の料金は載っていません。ただし利用にはBusiness+以上のサポートプランが必要で、Business Support+はアカウントごとに月額最低29ドルかかります。Cost Explorerのリソース単位データを有効にした場合は、その分の料金も支払いの対象です。Cost Explorerを有効にしない場合、コストの試算は公開価格ベースになります。
東京リージョンのリソースも診断できますか？
診断できます。プロファイルを置けるのはバージニア北部・オハイオ・オレゴンの3リージョンですが、スキャン対象はすべての商用リージョンです。プロファイル作成時に監視するリージョンとしてap-northeast-1を指定します。アーキテクチャレビューに渡すS3バケットだけは、プロファイルと同じ米国リージョンに置く必要があります。
Well-Architected Toolのレビューは不要になりますか？
不要にはなりません。Agentの対象はコスト・セキュリティ・レジリエンス・パフォーマンスの4つで、運用上の優秀性と持続可能性は含まれていません。公式の関連サービス一覧でも、WA Toolは手動レビュー、Agentは自動分析として併用できると説明されています。設定で判定できる部分をAgentに任せ、体制や手順に関わる部分はWA Toolで確認する分担にします。
推奨事項の修正をAgentが自動で実行しますか？
Trusted Advisor由来の推奨事項に用意されたSSM Runbookは、利用者の同意があればAgentから実行できます。Agent自身が生成した修正手順は自動実行されず、コンソール・CLI・SDKの手順書として提示されるだけです。手順書には誤りや不足が含まれる可能性があると公式が明記しているため、検証環境で確認してから本番に適用してください。
AWS MCP ServerからWell-Architected Agentを操作できますか？
API経由で操作が可能です。AWS MCP Serverを設定したAIエージェントから、create-agent-profileやget-agent-profileなどCLIと同じAPI操作を呼び出せます。呼び出しは手元のIAM認証情報で行われ、CLIと同じ権限が必要です。操作の記録先はCloudTrailです。接続手順はAWS MCP Serverとはで解説しています。
関連記事
- AWS Trusted Advisorとは｜6カテゴリ289チェックの内訳と無料で使える範囲【2026年8月時点】：Agentが取り込む指摘の元になるチェックの中身
- Trusted Advisorの自動化｜APIとEventBridgeで推奨事項を通知する実装：既存の通知経路とAgentの併用
- AWS Compute Optimizerとは？仕組み・レコメンデーションの読み方と料金・採用判断を実装者目線で解説：コスト推奨のもとになるサイズ提案
- AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：監視対象アカウントとSCPの設計
- AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説：実行ロールとアクセスロールの権限設計
