AWSの自動修復はどこまで任せられるか ― Security HubとASRのAI Toolkitを運用設計から読む

Security HubやGuardDutyの検知結果が、一覧に何百件も並んだまま減らない。その多くは、技術的に直し方が分からないから残っているわけではありません。どの設定を誰が変えてよいのか、いつまでに直すのか、変えたあと業務に影響が出ていないかを誰が確かめるのか。この3つが決まっていないと、検知結果は「知っているけれど手を付けていない項目」として積み上がっていきます。

2026年8月31日、AWSはAutomated Security Response on AWS（以下ASR）の更新を発表しました。AIアシスタントで独自の修復処理を作るためのAI Toolkit、Inspector・GuardDuty・Macieの検知結果への対応、修復対象の絞り込み、期限付きの通知が加わっています。前回のGuardDutyのCustom Detection Rulesの記事の最後に「検知の後に誰が修復するか」を次に扱うと書いたので、今回はこの更新を材料に、自動修復をどこまで任せ、どこから人が判断するかを考えます。

※2026年10月13日時点の公開情報（AWSの発表、ASR実装ガイド、GitHubのリリース）に基づきます。僕はASRを自分の環境にデプロイしておらず、AI Toolkitも動かしていません。本文の構成や判断表は設計例で、実行結果は載せていません。

検知を集めても、修復は誰かが決めないと進まない

AWSのセキュリティサービスは、見ているものがそれぞれ違います。GuardDutyはCloudTrailやネットワークの記録から脅威の兆候を、InspectorはEC2やコンテナイメージの脆弱性を、MacieはS3に置かれた機密データを見つけます。検知の入口が増えるほど、届く検知結果も増えます。

ここで混同しやすいのが、Security Hubまわりの3つの名前です。

Security HubもCSPMも、検知結果を並べて優先度を付けるところまでが仕事です。設定を直すのはASRか、人か、別の仕組みになります。ASRの実装ガイドは、修復は緊急時の対応を想定したもので、利用者が実行を指示したときか、自動修復を有効にした項目に対してだけ変更を加える、と書いています。何を自動にするかは、最初から利用者に委ねられています。

8月の更新で変わったことと、AIが担う範囲

GitHubのリリースでは、この更新はv4.0.0（2026年8月26日）として出ており、10月13日時点の最新はv4.0.2（9月15日）です。中身を4つに分けて見ます。

AI Toolkitは「修復を書くための指示書」

名前から、AIが検知結果を読んでその場で本番環境を直す機能を想像するかもしれませんが、そうではありません。実装ガイドによると、AI ToolkitはASRの修復のベストプラクティス、ガードレール、開発の型を、IDEのAIアシスタントに渡す指示プロンプトとしてまとめたものです。アシスタントはこれを前提に、修復用のSSM Automationランブック、検知結果を解釈するコントロールランブック、IAMロール、CDKのコードを、ASRの命名規則に沿って書く手伝いをします。

ガイドは、このToolkitは任意の開発補助で、修復の作り方やデプロイ方法は変えないこと、生成されたコードをデプロイ前にレビューしてテストする責任は利用者にあることを明記しています。AIが関わるのは開発工程だけで、実行時に動くのは、人がレビューしてデプロイしたランブックです。

AWSの発表は、独自修復の開発期間が「数週間から数時間」に縮むと説明しています。これはAWSの説明で、僕が測った数字ではありません。後で書くとおり、短くなるのは主にコードを書く時間で、レビューと検証の時間は別に見積もる必要があります。

Inspector・GuardDuty・Macieは各1種類から

対応サービスが増えたといっても、各サービスのあらゆる検知結果を直せるわけではありません。実装ガイドの「Multi-service remediation」のページには、このリリースでは1サービスにつき1種類の検知結果に対応する、と書かれています。

GuardDutyとMacieの修復は、ガイド自身が「最初の防御線」と呼んでいて、検知結果の原因は解決しないと書いています。被害の広がりを抑えるだけで、調査と後始末は人の仕事として残ります。また、一時的な認証情報（アクセスキーIDがASIAで始まるもの）による検知では、封じ込める対象のIAMユーザーが存在しないため、ASRは記録だけして修復を実行しません。ロールやIDプロバイダー側でセッションを止めるのは人の判断です。

対象の絞り込みと、期限付きの通知

自動修復の対象は、アカウントID、OU、リソースARNのパターン、タグを組み合わせた「リソースフィルター」で絞れるようになりました。Web UIで作り、コントロールごとに含める・除外するを指定します。このフィルターが効くのは自動修復だけで、人が手動で開始した修復には効きません。

通知は、メール、Slack、Jira、ServiceNow、SNSに送れます。重大度やコントロールで絞り込み、まとめて送る間隔も設定できます。修復の通知には、CloudFormation、Terraform、CDKの形式でIaCの修正例を付けられます。

運用設計の上でいちばん注意したいのは、検知結果の通知に付けられる「修復期限」です。期限は1〜90日で設定でき、それだけなら通知に期日が書かれるだけです。ところがenforceDeadlineを有効にすると、期限を過ぎた未解決の検知結果を、ASRが人の介入なしに修復します。そのコントロールで自動修復を有効にしていなくても動きます。対象になってから最低24時間は修復しないという猶予は固定で入っていますが、期限を「担当者への目安」のつもりで設定し、強制を有効にしてしまうと、意図しない自動修復の入口になります。

検知から修復までの実行経路を分けて見る

ASRの構成を、実行の経路と開発の経路に分けて図にしました。AI Toolkitは下の開発の経路にだけ出てきます。

実行の経路では、ASRの管理側スタックが置かれたアカウントで、EventBridgeのルールが検知結果を受け取り、Step Functionsのオーケストレーターが対象アカウントのSSM Automationランブックを呼び出します。ランブックは対象アカウント側のSO0111-Remediate-…という名前のIAMロールで動き、結果はSNSの通知、CloudWatch Logs、Security Hubの検知結果のメモ欄、修復履歴のDynamoDBテーブルに残ります。オプションのAction Logを有効にすると、CloudTrailでASRが加えた変更を記録できます。

ここでいう管理側は、組織の検知結果を集約する先として設定したSecurity Hubの管理者アカウントです。AWS Organizationsの管理アカウントと同じとは限りません。Security Hubの管理を委任したセキュリティ用アカウントに置く構成なら、修復の起点もそこになります。修復ロールを受け入れる対象アカウント側にも、メンバー用のスタックをデプロイする必要があります。

修復の起動のしかたは3つあります。Security Hub CSPMのコンソールの「アクション」メニュー、ASRのWeb UI、APIからの手動実行。コントロールごとに有効にする自動修復。そして先ほどの期限の強制です。自動修復を有効にすると、ASRをデプロイした全アカウント・リージョンの該当リソースすべてが対象になります。ガイドも、自分が作ったリソースだけに限られないことを強調しています。

自動実行と人間承認の境界を決める

どのコントロールを自動にするかは、深刻度の高さだけでは決められません。誤検知だったときに業務が止まる影響と、修復しなかったときに攻撃や露出が続く影響を並べて比べる必要があります。判断の材料を表にすると次のようになります。行は設計例で、組み込みの修復として存在するかは、最新のプレイブック一覧で確かめてください。

IAMユーザーの封じ込めは、この判断がいちばん分かれる例です。本当に認証情報が盗まれていたなら、数分の差で被害が変わります。一方で、外部連携のためにアクセスキーを持たせたIAMユーザーが誤検知で封じ込められると、連携が止まります。ガイドには、自動修復を有効にしたままロールバックすると、同じ検知結果に対してASRがもう一度封じ込めを実行しうる、という注意もあります。戻すなら、そのコントロールの自動修復を先に止める。この順番は手順書に書いておきたいところです。

承認・タイムアウト・失敗の扱いは、ASRが標準で持つものと、利用者が足すものを分けて考えます。

• ASRが標準で持つもの：修復の開始・成功・失敗のSNS通知、自動修復の再試行（1件あたり最大3回、15分以上の間隔、上限に達するとRemediationRetryCapReachedメトリクス）、Security Hubで抑制（SUPPRESSED）にした検知結果を自動修復から外す動作、修復期限とその強制
• 利用者が足すもの：承認者を決めて実行を待たせる仕組み。今回確認した資料の範囲では、ASRに承認待ちの段階は見当たりませんでした。承認が必要な操作は自動修復を有効にせず、Jira・ServiceNowのチケットで承認を記録してから人が手動で実行する、という形が現実的です

AIが作った修復を本番へ入れる前に見る点

AI Toolkitで書いた修復は、命名規則やファイルの置き場所はASRの型に沿っているはずです。ただ、型に沿っていることと、自社の環境で安全に動くことは別の話です。実装ガイドの手順から、レビューで見るべき箇所を拾うと次のようになります。

• IAMの範囲：修復ごとに作るIAMロールのポリシーに、必要な操作と対象リソースだけが書かれているか。ガイドの例ではelasticache:ModifyCacheClusterを自アカウントのクラスターに限っています。*が入っていたら理由を確かめる
• 対象の取り出し方：検知結果からリソースIDを取り出す正規表現（resourceIdRegex）が、別のリソースに一致しないか。ガイドは新しい正規表現をregex_registry.tsのテストに登録するよう求めています
• 変更前の状態：ASRの修復は、基本的に自動では元に戻りません。ガイドにも、戻すには手作業で元の状態にする必要があるとあります。変更前の設定値をログに出す処理が入っているかを見る
• 再実行と例外：すでに直っているリソースに再実行しても壊れないか。持ち主が意図して例外にしているリソース（特定のタグなど）をどう扱うか
• 変更の記録：修復後に検知結果のメモ欄へ書く文言（updateDescription）が、後から見て何をしたか分かる内容か

テストは、ASRのリポジトリにある単体テスト（run-unit-tests.shでCloudFormationテンプレートのスナップショットを更新する）に加えて、検証用アカウントで状態の違うリソースを用意して試すのが確実です。違反しているもの、すでに直っているもの、除外タグが付いたもの、途中で削除されたもの。最低でもこの4つで動きを見ておくと、本番での想定外が減ります。

もう一つ、「ランブックの実行が成功した」と「問題が解消した」は別の判定にしておきます。ガイドの自動修復の例でも、AWS Configが設定を再評価するまでには時間がかかると書かれています。完了の判定は、SNSの成功通知ではなく、再評価後に検知結果が解消済みになったことに置くべきです。

応急修復のあとに、IaCを直す

仮想例で考えます。TerraformやCloudFormationで管理しているS3バケットの公開設定を、ASRが検知から数分で修正したとします。次にインフラのコードをデプロイしたとき、コード側の設定は直っていないので、バケットは元の状態に戻ります。同じ検知結果が出て、ASRがまた直す。これがデプロイのたびに繰り返されます。実装ガイドも、CloudFormationで作ったリソースを修復するとドリフトが起きるので、可能ならスタックのコードを直して更新するよう勧めています。

ASRの通知にIaCの修正例を付けられるようになったのは、この恒久対処を担当者につなぐためだと読めます。ただ、どのリポジトリの、どのモジュールを、誰が直すかは通知からは分かりません。修復の記録には、次の3つを分けて残しておくと、同じ検知結果が繰り返される理由を後から追えます。

• 緊急対処：ASRまたは人が本番の設定を変えた記録（いつ、何を、どの修復で）
• 恒久対処：IaCの修正のプルリクエストと、その反映日
• 例外承認：直さないと決めた理由、承認者、見直し期限。Security Hubで抑制にするなら、その理由を同じ場所に書く

AI Toolkitの効果を測るなら、コードの生成にかかった時間だけでは足りません。レビュー、検証用アカウントでのテスト、修復の持ち主との調整、IaC側の修正まで含めて、1つの修復を本番に入れるまでの時間を見るほうが実態に近いはずです。

費用は、ASR自体は無料のソリューションで、構成する各サービスの利用料がかかります。実装ガイドの試算では、10アカウント・1リージョン・月300件の修復で約14.70ドル、Web UIを有効にすると約49.31ドルです。Web UIで増える分の多くはWAFで、10アカウントの例では、アカウントごとに1本ずつ作るKMSキーが合計約10ドルを占めます。Security Hub CSPMやGuardDutyなど検知側の料金は別で、どれもAWSの試算で実測ではありません。

始めるなら、僕は次の順にします。検証用アカウントで1つのプレイブックを手動で実行し、実行ログ、再実行時の動き、失敗時の通知、修復後の状態を確かめる。本番では手動実行と期限付きの通知（強制はなし）から入る。影響の小さいログ設定系のコントロールだけを、リソースフィルターで対象を絞って自動にする。公開範囲や資格情報に関わる修復を自動にするかは、そこで実際の検知件数と誤検知の割合を見てから決めます。

実行基盤のStep Functions自体の設計は、Step FunctionsでAIワークフローを組む記事でも書いています。

確認した資料

• AWS What's New：Automated Security Response on AWS adds AI toolkit — 2026年8月31日。AI Toolkit、Inspector・GuardDuty・Macie対応、対象の絞り込み、通知の拡張。
• ASR実装ガイド：Adding new remediations — AI Toolkitの位置づけ、修復の追加手順、IAMロール、単体テスト（2026年10月13日確認）。
• ASR実装ガイド：Multi-service remediation — サービス別の対象と操作、ロールバック、ASFFとOCSF。
• ASR実装ガイド：Enable fully automated remediations — 自動修復の範囲、抑制した検知結果、再試行の上限、リソースフィルター。
• ASR実装ガイド：Configure notifications — 通知先、IaCの修正例、修復期限と強制、24時間の猶予。
• ASR実装ガイド：Architecture details、Cost — 構成サービスと月額の試算。
• GitHub：automated-security-response-on-aws のリリース — v4.0.0（2026年8月26日）、v4.0.2（2026年9月15日）。