週刊AIニューストピック 2026年10月3日:AWS構成診断AIに、何を許可するか

AWSの構成を、AIが横断的に診断してくれる。そんな機能が、2026年10月1日にプレビュー公開されました。「AWS Well-Architected Agent」です。

自分は普段、AIと一緒に設計を詰めてから、IaCで構築しています。ただ、世の中のAWS設計者がみんなそうしているわけではありません。AIにまだなじみがない方でも、AWS自身のサービスとして構成の妥当性を評価してもらえる。これが、このサービスを見たときの第一印象でした。

IaCやコンソールで自前で構築している方はもちろん、すでに稼働している既設環境にも、後追いで導入できそうなのがいいところです。設計や設定の抜け漏れを確認する用途として、有効だと思います。

ただし、使い始めるには、診断に使うロールを設計する側で設定する必要があります。つまり、「AIに何を許可するか」を自分で決める場面が、導入の入口に来るということです。今回は、AWS公式のドキュメントをもとに、何ができて、何が必要で、どこに注意すべきかを、この観点から整理します。

何が公開されたのか

AWSはこの機能を、Trusted AdvisorとWell-Architected Toolの「次世代」に位置づけています。コスト、セキュリティ、パフォーマンス、回復性の4つの柱を対象に、リソースの利用状況や設定、トポロジーなどを突き合わせて、優先順位をつけた改善提案を出します。提案にはトレードオフの説明や、CLIスクリプト、IaCによる修正案が添えられます。Terraform、CDK、CloudFormationのIaCそのものをレビューすることもできます。

なお、Well-Architectedには6つの柱がありますが、ドキュメント上で対象として挙げられているのは上記の4つで、運用上の優秀性とサステナビリティは含まれていません。

診断のために渡す権限

冒頭で触れたとおり、導入の入口は、診断用ロールの設定です。ここが、AIに何を許可するかを決める場面になります。公式ドキュメントによると、エージェントは顧客側で作成した実行ロールを使い、そこから診断対象の各アカウントのロールを引き受けます。各ロールには、メタデータと設定情報の読み取り専用とされる管理ポリシーが付きます。ロールや信頼関係を削除すれば、アクセスはいつでも止められます。

AWSは、診断用のプロファイルを、本番ワークロードのない専用アカウントで動かすことも推奨しています。プロファイルを置けるリージョンはバージニア北部、オハイオ、オレゴンの3つで、そこから商用リージョン全体をスキャンする設計です。

試す前に確認しておきたい条件

ここが見落としやすいところです。発表文では「AWSサポートプランの契約者向け」とされていますが、ユーザーガイドを読むと、対象はBusiness+、Enterprise On-Ramp、Enterprise Support、Unified Operationsで、DeveloperとBusinessのプランは使えないと明記されています。個人や小規模のアカウントでは、そもそも試せない可能性があります。

料金については、プレビュー中の扱いを明記したAWSのページを、今回は確認できませんでした。データの保持や、モデルの学習への利用についても、このエージェント専用の記載は公式ドキュメントでは見つけられていません。使う前に、利用条件の確認が必要です。

実機を検証したClassmethodの記事では、出てきた指摘は中〜低優先度のものが中心で、是正は案内のみ(自動修正はなし)、レビューには30分ほどかかったと報告されています。また、AWS自身も「生成AIによる提案には誤りや不足が含まれる可能性があり、自分の環境に照らして評価する責任は利用者にある」と注意書きを添えています。

インフラ現場にとっての意味

設計レビューをAIに任せられるのは魅力的ですが、これは「読み取り権限を、AIに常時渡す」判断でもあります。使う前に、確認したい点を挙げておきます。

• 診断用のロールが読み取り専用に絞られているか、実際のポリシーを自分の目で確認したか
• 本番ワークロードのない専用アカウントにプロファイルを置けるか
• 構成情報がどう扱われるか(保持・利用目的)を、利用条件で確認したか
• 指摘をそのまま適用せず、人が確認してから反映する流れになっているか

「AIに何ができるか」より先に、「AIに何を見せ、何を触らせないか」を決める。9月23日号の週刊で触れたガードレールの考え方が、ここでもそのまま効いてきます。

次のアクション

サポートプランの条件を満たしているなら、まずは検証用の専用アカウントで、読み取り専用ロールのまま試してみるのが現実的です。満たしていない場合は、正式版の提供条件や料金が発表されるまで、様子を見るので十分だと思います。

今週のその他のAIニューストピック

今週はこの他にも、エージェントの実行基盤やセキュリティに関わる動きがありました。

OpenAI、DevDayで「Agents API」を発表(公式ドキュメント、2026年9月29日開催と報じられています)
CodexのハーネスをOpenAI管理のAPIとして使える仕組みで、現在はベータです。実行環境はOpenAI管理のサンドボックスのほか、自社側のサンドボックス(ModalやOracle OCIなど)も選べます。ただし、データレジデンシーは米国のみで、ゼロデータ保持(ZDR)は非対応と公式に記載されています。自社で実行環境を持っても変わらない点は、規制のある業務では要確認です。なお、報道では「Managed Agents」とも呼ばれていますが、公式ドキュメント上の名称はAgents APIです。

Salesforce Agentforceに、ゼロクリックで情報が漏れる脆弱性「SalesBleed」(Infosecurity Magazine、2026年9月24日にZenityが開示)
公開フォームに仕込まれた隠しプロンプトを、担当者の依頼でエージェントが実行してしまい、DNS経由の情報抜き取りなどに至るという内容です。報道によれば、Salesforce側の修正は段階的に完了済みとのことです。エージェントの通信をどこまで監視・制限できているかを見直すきっかけになります。

AnthropicとAkamai、最大約200億ドル規模のクラウド契約(Akamai公式プレスリリース、2026年9月24日発表)
7年間で116億ドルの契約で、最大で追加90億ドルまで拡張される可能性があります。対象はCPUワークロードとされています。この契約をもって「エージェントの需要がGPUからCPUへ移る」と読む向きもありますが、それは公式の説明ではなく、解釈の域を出ません。現時点では、大口の買い手による一つのデータポイントとして見ておくのが安全です。

Microsoft Foundry、ホスト型エージェントの送信制御をプレビュー(Microsoft Foundry Blog、2026年9月24日)
エージェントがどこと通信できるかを明示的に制御する機能で、GAの時期は未定とされています。SalesBleedのような事例への備えとして、あわせて押さえておきたい機能です。