AWS Security Agentの料金｜$50/task-hourの課金単位とペネトレーションテストの実行手順

AWS Security Agentは、稼働中のWebアプリケーションやAPIに対して自律的にペネトレーションテストを実行するAWSのAIエージェントです。2025年12月2日にプレビューとして公開され、オンデマンドのペネトレーションテストは2026年3月31日に一般提供（GA）となりました。同時に料金も公開され、現在は$50/task-hourの従量課金です。なおサービスはAWS Continuumという新しい傘の下に入り、公式製品ページは「Continuum also offers a frontier agent (formerly known as AWS Security Agent)」と表記しています。この記事では、主力の疑問である料金の実額と課金単位の数え方を中心に、無料トライアルの範囲、予算上限の設定、ドメイン検証からテスト実行までの手順、そして導入前に知っておくべき制約を整理します。根拠は公式の料金ページ・FAQ・製品ページ・What’s New・ユーザーガイド・APIリファレンス・AWS CLIリファレンスで、いずれも2026年9月22日に取得したものです。

まとめ：AWS Security Agentの料金と要点

• 料金：ペネトレーションテストが$50.00/task-hour。秒単位で計測し、部分秒も按分して課金されます。前払いも最低利用料もありません。
• task-hourの正体：テストの経過時間（duration）ではなく、エージェントが推論と実行に費やした累計作業時間です。複数タスクが並列で走るため、task-hoursは経過時間を上回るのが通常です。
• 無料の範囲：新規顧客は2か月間の無料トライアルを使え、各トライアル月に400 task-hoursまで含まれます。プレビュー参加者も対象です。
• 課金対象はペンテストだけ：コードレビュー・設計レビュー・脅威モデリングはプレビュー中のため無課金です。ただし月次クォータはかかります。
• 予算キャップの下限は20 task-hours：1回のテストに上限を設定できますが、設定できる最小値が20時間（＝$1,000）です。それより小さく絞ることはできません。
• 提供リージョン：GA時点は6リージョンで、2026年9月時点の公式資料では9リージョンに増えています。アジアパシフィック（東京）はGA時から対象です。
• 自動化の現在地：セキュリティFAQは公開APIが無いと書いていますが、実際にはAPIリファレンスとAWS CLIの securityagent コマンド群が公開されています。FAQが追随していない状態です。ただしCI/CD向けの公式統合やスケジュール実行機能は用意されていません。
• 実行環境：本番ではなく検証環境での実行が公式推奨です。

AWS Security Agentの提供状況とAWS Continuumでの位置づけ

ユーザーガイドのドキュメント履歴では、初版の公開が2025年12月2日です。同年のre:Invent 2025でプレビュー発表され、そこから約4か月後の2026年3月31日に、オンデマンドのペネトレーションテストがGAになりました。What’s Newの逐語は「Today, AWS announced the general availability of AWS Security Agent for on-demand penetration testing in six AWS Regions.」です。

GA時点の対応リージョンは、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）、欧州（フランクフルト）、アジアパシフィック（シドニー）、アジアパシフィック（東京）の6つでした。その後さらに増えており、2026年9月時点のセキュリティのベストプラクティスに載るクロスリージョン推論の一覧には、この6つに加えてアジアパシフィック（ムンバイ）、アジアパシフィック（シンガポール）、南米（サンパウロ）が並んでいます。プレビュー当初のus-east-1限定という情報は、いずれにせよ現在の実態とは異なります。

名称についても変更があります。現在の製品ページはAWS Continuumという名前で、その中の1機能として旧AWS Security Agentが位置づけられています。ドキュメントのタイトルも「What is AWS Security Agent (now part of AWS Continuum)?」に変わりました。ただしコンソール上のIAMアクション名前空間は securityagent のままで、サービスプリンシパルも securityagent.amazonaws.com です。名前は変わっても設定の実体は同じものを指します。

機能ごとに提供段階と課金の扱いが異なるため、最初にここを押さえてください。

テスト対象はAWS上のアプリケーションに限られません。FAQは「Once Continuum for penetration testing is enabled, it can point to any application that is in AWS (private and public endpoints), on premises, hybrid, or in other cloud environments.」と明記しており、オンプレミスや他クラウドのアプリケーションも対象にできます。

料金は$50/task-hour：task-hourの数え方

公式の料金ページの記載は次のとおりです。課金モデルは従量課金で前払いなし、レートは$50.00 per task-hour、課金単位はtask-hour（秒単位で計測、部分秒は比例配分）です。

つまずきやすいのはtask-hourの定義です。公式は「Task hours reflect the total cumulative time across all security testing tasks combined. Because multiple tasks run concurrently during a pentest, the total billable task-hours will typically exceed the actual run time or test duration you observe.」と書いています。画面で見た所要時間が1時間でも、並列で走ったタスクの合計が3時間分あれば、請求は3時間分です。ここを取り違えると見積もりが数倍ずれます。

公式が示している3つの計算例を並べます。durationとtask-hoursの乖離がそのまま金額差になっていることが読み取れます。

計算式は単純で、秒に直して3600で割り、$50を掛けるだけです。四捨五入の丸め方で1セントずれるため、公式例と突き合わせて検算しておくと安全です。

from decimal import Decimal, ROUND_HALF_UP

RATE = Decimal("50")  # 1 task-hour あたりのUSD単価

def task_hours(h: int, m: int = 0, s: int = 0) -> Decimal:
    return Decimal(h * 3600 + m * 60 + s) / Decimal(3600)

def cost(th: Decimal) -> Decimal:
    return (th * RATE).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

cases = [("小規模API", (3, 27, 45)), ("ECサイト", (24, 0, 0)), ("大規模SaaS", (31, 15, 30))]
for name, (h, m, s) in cases:
    th = task_hours(h, m, s)
    print(f"{name}: {h}時間{m}分{s}秒 = {th:.4f} task-hours / ${cost(th)}")

print(f"上限20 task-hoursまで使い切った場合: ${cost(Decimal(20))}")

この実装で計算すると、出力は公式の3例と完全に一致します。

小規模API: 3時間27分45秒 = 3.4625 task-hours / $173.13
ECサイト: 24時間0分0秒 = 24.0000 task-hours / $1200.00
大規模SaaS: 31時間15分30秒 = 31.2583 task-hours / $1562.92
上限20 task-hoursまで使い切った場合: $1000.00

無料になる範囲も明示されています。新規のAWS顧客はAWS Free Tierの対象で、加えてAWS Security Agentの新規利用者には初回のペネトレーションテスト実行を起点に2か月の無料トライアルが付きます。各トライアル月に含まれるのは400 pentesting task-hoursまでで、超過分と期間終了後は通常の従量課金です。トライアルにはレポートと詳細な検出結果、修正コードの提示も含まれます。プレビューに参加していた顧客も対象で、GA後に最初のテストを作成した時点からトライアルが始まります。

検出結果の再検証（revalidation）も覚えておくと効きます。1つの検出結果につき3回までの再検証は課金されません。4回目以降は通常どおりtask-hourで課金されます。修正して再確認するサイクルを3回まで無料で回せる、という設計です。

コストを抑える設定：予算キャップの下限は20 task-hours

2026年8月13日に、ペネトレーションテストとコードレビューに最大task-hoursを設定する機能が追加されました。テスト作成ウィザードのMax task hoursで、プリセット（20時間・30時間など）、No limit、Customから選びます。ここで重要なのは、カスタム値も含めて設定できる最小値が20時間だという点です。$50/task-hourなので、キャップを最小に絞っても1回あたり最大$1,000まで動く可能性があります。実際の課金は使った分だけなので少額で終わることもありますが、「$100に達したら自動で止める」という上限設定はできません。

上限に達すると、エージェントは作業を止めてそこまでに見つけた検出結果を保持し、実行ステータスはCompletedで終わります。途中で手動停止した場合も、そこまでに発生したtask-hoursは課金対象です。なお、キャップを高めに設定しても実際に使った分しか課金されないため、上限を上げること自体が費用を増やすわけではありません。

事前の精密な見積もりについては、公式FAQが明確に否定しています。「There is no precise estimation. Task hours depend on the breadth of the target application and the risk types you select.」と書かれています。現実的な手順は、同じ構成でテストを1回走らせて実績のtask-hoursをベースラインにし、以後はその数字で予算を組む方法です。ペネトレーションテストの構成は再利用可能なので、同一構成の実行履歴どうしを比較できます。

公式が挙げているコスト抑制策は4つです。

• スコープを絞る：ドメイン全体ではなく特定のURLパスを対象にし、除外するURLを明示します。
• リスクタイプを絞る：テストするリスクタイプを増やすほどタスクが増えます。不要なカテゴリは除外します。
• 逸れた実行を止める：ペネトレーションテストのログをリアルタイムで監視し、関心のない領域を探索し始めたら停止します。
• 構成を再利用してベースラインを作る：同じ構成の実行間でtask-hoursを比較し、その対象の標準的なコストを把握します。

実績の追跡には通常のAWS Cost ExplorerとAWS Budgetsが使えます。加えてCloudWatchに PentestExecutionDuration というメトリクスが秒単位で発行されますが、これは経過時間であって課金単位のtask-hoursではありません。task-hoursはWebアプリケーションのAll runsテーブル、または各実行のLogsタブでタスクごとに確認します。

なお、サービスクォータは支出の上限ではありません。ユーザーガイドは「Quotas limit capacity but don’t limit spending.」と明記しており、月次クォータに達しても課金は止まりません。逆にクォータを引き上げてもレートは変わりません。

ペネトレーションテストの実行手順

作業は3つのインターフェースに分かれています。管理者はAWSマネジメントコンソールでAgent Spaceと権限を用意し、利用者は専用のWebアプリケーションでテストを作成・実行し、開発者はGitHubやIDEで修正のプルリクエストを受け取ります。

管理者側：Agent Spaceの作成とドメインの所有権検証

コンソールで最初のAgent Spaceを作ると、そのアカウント用のWebアプリケーションが生成されます。Agent Spaceは保護対象のアプリケーション単位で作るのが公式推奨で、アカウント・リージョンあたり最大100個です。

次にペネトレーションテストを有効化します。ウィザードの最初のステップで対象ドメインを登録し、所有権の検証方法を選びます。検証方法は3つです。

• DNS_TXT：DNSにTXTレコードを追加して所有を証明します。対象ドメインが同一アカウントのRoute 53にある場合は、ワンクリック検証でレコード作成まで自動化されます。
• HTTP_ROUTE：Webサーバー上の指定パスに検証用トークンを置きます。
• PRIVATE_VPC：プライベートVPC内のテスト専用で、ドメインがプライベートCIDRのIPに解決されることを確認します。

HTTP検証で配置するファイルのパスと中身は次のとおりです。公開されている場合は有効なSSL証明書が必要です。

.well-known/aws/securityagent-domain-verification.json

{
  "tokens": ["<insert-token>"]
}

登録できる対象ドメインは1つのAgent Spaceにつき最大20件です（2026年8月18日に5件から拡大されました）。DNS TXTまたはHTTPルートで検証すると、そのサブドメインは個別検証なしでテストできます。例えば example.com を検証すれば api.example.com や billing.example.com もそのまま対象にできます。プライベートVPC検証の場合だけは、対象エンドポイントの完全なドメイン名が検証済みのドメイン名と一致している必要があります。所有権を証明できないが権限は持っている、というケースでは、業務上の理由と権限の根拠を添えてサポートケースを起票し、手動検証を依頼できます。

サービスロールも管理者が用意します。信頼ポリシーはサービスプリンシパルを指定し、クロスアカウント相当の保護のためExternal IDを付けるのが公式の推奨です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "securityagent.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "your-external-id"
        }
      }
    }
  ]
}

調査に使う権限は読み取り中心で足ります。公式は SecurityAudit や ViewOnlyAccess の利用、あるいは ec2:Describe*、logs:DescribeLogGroups、s3:GetObject といった参照系に絞ったカスタムポリシーを挙げています。ただし読み取りだけでは足りない箇所があり、有効化手順は選択したCloudWatchロググループへの書き込み権限、Secrets Managerからの資格情報取得、Lambda関数の呼び出しについて、それぞれロール側に権限が必要だと注意しています。ロググループを指定しなければ、/aws/securityagent/<agent name>/<pentest id> という名前で自動作成されます。

利用者側：ウィザード5ステップと認証情報のテスト

Webアプリケーション側のテスト作成は5ステップです。ペネトレーションテストの詳細（名前・対象URL・サービスロール・ロググループ）、任意のVPCリソース、任意の認証情報、ネットワーク構成、任意の追加設定という順で、各ステップは保存しながら進められます。途中で抜けた構成はDraftバッジ付きで一覧に残ります。

2026年9月18日に追加された認証情報のテストは、実行前に必ず通しておく価値があります。各認証情報に対してTestを実行すると、エージェントが実際にサインインできるかを確認し、同時にログイン後に到達するドメインを洗い出します。多くは2〜3分で終わり、サインインできない場合は15分でタイムアウトします。ここでタイムアウトしてもペネトレーションテスト自体は開始でき、その実行中はサインインに1時間（認証情報テストの4倍）が与えられます。テストを省略すると、その認証情報の先にしかないドメインが次のステップの候補に出てこないため、手で追加する必要が生じます。

ネットワーク構成のステップでは、テストが到達しうるドメインを3つに分類します。

• Target：攻撃してよいURL。所有権の検証が必要です。
• Accessible：アクセスはするが攻撃してはいけないURL。ホスト型のログインページやCDNなどが該当します。所有権の検証は不要です。
• Out of scope：一切アクセスしてはいけないURL。配下のパスもまとめて除外されます（https://example.com/admin を指定すると https://example.com/admin/tools も除外）。

既定では対象URLしか到達できません。破壊的な操作や管理機能のパスは、この段階で明示的にout of scopeへ入れておきます。out of scopeの指定はaccessibleより優先されます。非標準ポートを使っている場合は、対象URLにポートを含めて https://example.com:8443 のように書きます（2026年9月16日から対応）。accessibleに非標準ポートを指定する場合は、スキームとポートを含む完全なURLが必要です。

精度を上げるには追加リソースを渡します。GitHubリポジトリ、S3バケット、アップロードしたファイル、OpenAPI/Swagger仕様、アーキテクチャ図などをコンテキストとして添付できます。修正のプルリクエストまで自動生成させたい場合は、リポジトリを連携したうえでテスト作成時に自動修復を有効にしておく必要があります。S3をソースにした場合はプルリクエストを出す先のリポジトリが無いため、git apply で適用できる差分が検出結果に添付される形になります（2026年8月18日から対応）。

ペネトレーションテストの検出範囲と自動化の制約

セキュリティFAQが例示しているリスクタイプは13種類です。任意ファイルアップロード、コードインジェクション、コマンドインジェクション、クロスサイトスクリプティング、安全でない直接オブジェクト参照、JWTの脆弱性、ローカルファイルインクルージョン、パストラバーサル、権限昇格、SSRF、サーバーサイドテンプレートインジェクション、SQLインジェクション、XML外部エンティティです。ただしこれは例示で、CLIリファレンスの create-pentest が受け付ける除外指定 excludeRiskTypes の列挙値は28個あり、既定資格情報、安全でないデシリアライゼーション、GraphQLの脆弱性、ビジネスロジックの脆弱性、暗号関連の脆弱性、データベースアクセスや改変といった、FAQに出てこないカテゴリが含まれます。起点はOWASP Top 10ですが、FAQは「starts with the OWASP Top 10 but is customized by the context it learns about the customer’s application」として、アプリケーション固有の文脈から攻撃計画を組み立てると説明しています。

2026年8月31日からは、対象ホストの開放TCPポートをExposed Network Portsという情報レベルの検出結果として1件にまとめて報告します。検出したサービス名とバージョンを列挙しますが、それらのサービスを悪用しようとはしません。検出結果にはCVSSの内訳（攻撃元区分・攻撃複雑性・必要権限・ユーザー関与・スコープ・機密性/完全性/可用性への影響）が付きます。確信度については公式資料に幅があり、セキュリティFAQは高・中の確信度のものだけを報告すると書いていますが、検出結果の確認手順のページは「By default, you see only findings with High agent confidence.」として既定表示は高のみで、Hiding unverified findingsのトグルを切ると中・低や偽陽性も表示できると説明しています。運用前に実画面の既定フィルターを確認してください。決定的なバリデータで検証できないリスクタイプについては、エージェントが手順を再実行して確信度を高めます。

一方で、次の点はできないと公式が明記しています。導入計画に直接効くので、先に把握しておいてください。

• CI/CDやSIEMとの公式統合は用意されていない：セキュリティFAQの逐語は「AWS Security Agent does not integrate with any existing security tools or CI/CD pipelines.」です。既製のプラグインやアクションを入れるだけで動く、という形にはなっていません。
• スケジュール実行の機能はない：定期実行の設定項目はなく、対象エンドポイントへのリクエスト並列度を調整する機能もありません。
• テスト計画を事前に確認できない：攻撃計画は探索に応じて動的に変わるため、事前プレビューはできません。実行中のログをリアルタイムで見て、望ましくない方向に進んでいれば停止する運用になります。
• 網羅は保証されない：幅優先で探索しますが、確率的な動作のため、すべての重要な処理やエンドポイントを発見・テストする保証はないとFAQに書かれています。
• 専門のペネトレーションテストサービスの代替ではない：「AWS Security Agent is not a professional penetration testing service」という一文が公式FAQにあります。想定されているのは、外部委託が早すぎる・頻度が合わない開発フェーズを埋める用途と、専門家がその検出結果を検証・拡張する使い方です。

公開APIの有無をめぐる公式資料の食い違い

自動化について、公式資料の記述が一致していません。上で引用したセキュリティFAQは「AWS Security Agent does not have public APIs or the ability to schedule the penetration test runs」と書いています。一方で、AWS Security Agent API Referenceには92個のアクションが載っており、ページ末尾の最終公開日は2026年9月21日です。AWS CLI 2.36.50にも aws securityagent のサブコマンド群が92個あり、start-pentest-job や create-pentest、list-findings が含まれます。FAQのほうが更新に追随していないと読むのが妥当です。

実行系のAPIは次のような形です。--job-type にはFULLとREVALIDATIONがあり、REVALIDATIONを指定するときは再検証する検出結果のIDが必須です。

aws securityagent start-pentest-job \
  --agent-space-id <agent-space-id> \
  --pentest-id <pentest-id> \
  --job-type FULL

aws securityagent start-pentest-job \
  --agent-space-id <agent-space-id> \
  --pentest-id <pentest-id> \
  --job-type REVALIDATION \
  --selected-finding-ids <finding-id-1> <finding-id-2>

返るジョブのステータスはIN_PROGRESS、STOPPING、STOPPED、FAILED、COMPLETEDの5種類です。つまり、既製の統合機能はないものの、CLIやSDKを自前のパイプラインやAmazon EventBridge Schedulerから呼び出して起動すること自体は可能です。ただし1回の実行が最低でも数百ドル規模になり得るため、コミットごとに回す設計には向きません。リリース前や定期点検のタイミングで明示的に起動する使い方が現実的です。

対象システムへの影響については、負荷過多やDoSを避けるガードレールが入っています。SQLインジェクションを見つけてもテーブルを削除せずバージョン文字列を取得する、といった影響の小さいペイロードを使う設計です。ただし公式は「we always recommend doing penetration testing against a pre-production environment」として、本番ではなく検証環境での実行を一貫して推奨しています。監視アラートが発火する程度のトラフィック増加は想定しておく必要があります。多くの実行は16時間以内に完了します。

導入前に確認する制約：クォータ・データの扱い・侵入テストポリシー

クォータはアカウントとリージョンの組み合わせごとに設定されています。調整可否も含めて次のとおりです。

データの扱いで、日本の利用者が必ず確認すべき点があります。公式は、顧客データをモデルの学習に使わず第三者にも共有しないこと、保存時はAWS KMSで暗号化すること（既定はAWS管理キーで、Agent Spaceや統合の作成時にカスタマー管理キーを指定できます）、ペネトレーションテストのログは顧客アカウントのCloudWatchに保存されることを明記しています。

分けて考える必要があるのが推論の処理場所です。公式は、リージョンによって2種類のクロスリージョン推論を使い分けると説明しています。東京を含む6リージョンは地理的クロスリージョン推論で、ほとんどの機能は起点の地理的境界（日本など）の中で処理されます。ムンバイ・シンガポール・サンパウロは全世界型で、任意の商用AWSリージョンで処理されます。

東京から使う場合、コード修復（Code Remediation）だけは欧州連合で処理されます。しかもクロスリージョン推論は常時有効でオプトアウトできず、公式は「Cross-Region inference is not impacted by customer policies in Service Control Policies (SCPs) or AWS Control Tower that restrict customer content to specific Regions.」として、SCPやAWS Control Towerでリージョンを縛っても影響を受けないと明記しています。保存されるデータは起点リージョンに留まり、リージョン間の転送はAWSネットワーク内で暗号化され公衆インターネットを通りませんが、処理の所在まで国内に限定する手段は用意されていない、というのが正確な理解です。国内処理が必須の案件では、コード修復機能を使わない運用にするか、サービス自体の採用を見送る判断になります。

権限の扱いにも注意が必要です。認証情報を渡すと、エージェントはそのユーザーがアプリケーション上で到達できるものをすべてテストします。認証後の経路から、テスト権限のない共有サービスや第三者のドメインに届いてしまう可能性があるため、公式は本番システムにアクセスできる認証情報を渡さないよう求めています。権限は管理者ではなく一般利用者相当のアカウントを使うのが前提です。

AWS自身の侵入テストポリシーとの関係も整理しておきます。AWSは、Permitted Servicesに挙げられたサービス（EC2、WAF、NAT Gateway、ELB、RDS、CloudFront、Aurora、API Gateway、AppSync、Lambda、Lightsail、Elastic Beanstalk、ECS、Fargate、OpenSearch Service、FSx、Transit Gateway、Bedrock AgentCore、Global Accelerator）について、自社インフラのセキュリティ評価を事前承認なしで実施することを認めています。AWSのサービス自体やAWSインフラへの評価は不可で、C2を伴うテストは事前承認が必要です。AWS Security Agentの利用もAWS利用規定（AUP）の順守が前提で、テスト対象すべてについて権限を持っていることは顧客側の責任です。対象外URLへのアクセス試行は継続的に監視されており、第三者エンドポイントへの未承認テストなどの不正利用が検知されると、そのアカウントで進行中のペネトレーションテストはすべて終了させられます。

Amazon Inspector・AWS Security Hubとの違い

同じAWSのセキュリティサービスでも、見ている対象と検出の方法が異なります。競合しないので、置き換えではなく役割分担で考えるのが実務的です。

既知の脆弱性を洗い出す継続スキャンはAmazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断、検出結果を1か所に集約する仕組みはAWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説が担当です。AWS Security Agentは1回の実行に数百ドル規模の費用と十数時間を要するため、コミットごとの自動検査はDASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説で扱うDASTツールなどに任せ、AWS Security Agentはリリース前や定期点検の深い検証に充てる構成が現実的です。

よくある質問

AWS Security AgentとAWS Continuumは別のサービスですか？

別サービスではありません。旧AWS Security Agentは現在、AWS Continuumの一部として位置づけられています。公式製品ページは「Continuum also offers a frontier agent (formerly known as AWS Security Agent)」と記載しています。ドキュメントのタイトルも「AWS Security Agent (now part of AWS Continuum)」です。IAMのアクション名前空間やサービスプリンシパルは securityagent のまま変わっていません。

料金はいくらですか。無料で試せますか？

ペネトレーションテストが$50.00/task-hourの従量課金で、秒単位で計測されます。新規顧客は2か月の無料トライアルを使え、各トライアル月に400 task-hoursまで含まれます。トライアルは初回のペネトレーションテスト実行から始まります。コードレビュー・設計レビュー・脅威モデリングはプレビュー中のため課金されません。

東京リージョンで使えますか。データは日本国内に留まりますか？

アジアパシフィック（東京）はGA時点の対応6リージョンに含まれ、現在も対象です。データの保存はリクエストが発生したリージョンに留まりますが、処理は別です。東京からのリクエストは、コード修復以外の機能であれば日本の地理的境界内で処理されますが、コード修復だけは欧州連合で処理されます。クロスリージョン推論はオプトアウトできず、SCPやAWS Control Towerのリージョン制限でも止められません。

AWS以外で動いているアプリケーションもテストできますか？

できます。公式FAQは、有効化後はAWS内（プライベート・パブリック双方のエンドポイント）、オンプレミス、ハイブリッド、他のクラウド環境のアプリケーションを対象にできると説明しています。ただし対象ドメインの所有権検証は必要です。

CI/CDパイプラインに組み込んで自動実行できますか？

既製の統合機能はありませんが、技術的には可能です。セキュリティFAQは既存のセキュリティツールやCI/CDパイプラインとの連携機能を持たないと書いており、この点は現在も変わりません。一方で同じFAQにある公開APIが無いという記述は最新のドキュメントと食い違っており、実際にはAPIリファレンスとAWS CLIの aws securityagent start-pentest-job が公開されています。自前でパイプラインから呼び出す形になりますが、1回あたりの費用と所要時間を考えると、コミットごとではなくリリース前などの明示的なタイミングで起動する設計が現実的です。

外部のペネトレーションテスト事業者は不要になりますか？

公式は「AWS Security Agent is not a professional penetration testing service」と明記しており、代替とは位置づけていません。外部委託が早すぎる、あるいは頻度が合わない開発フェーズを埋める用途と、専門家が検出結果を検証・拡張する使い方が想定されています。網羅性も保証されません。

関連記事

• Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断
• AWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説
• 脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説
• DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説
• AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】