--- title: "AWS Security Agent（AWS Continuum）の料金｜$50/task-hourの数え方と無料になる範囲" url: "https://www.issoh.co.jp/tech/details/10822/" published: 2026-02-02 updated: 2026-11-02 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Security Agent（AWS Continuum）の料金｜$50/task-hourの数え方と無料になる範囲 AWS Security Agentのペネトレーションテストの料金は、**$50.00/task-hour**の従量課金です。秒単位で計測され、前払いも最低利用料もありません。ただし、画面に出る所要時間と課金時間（task-hour）は別物で、1時間で終わったテストが3時間分以上の請求になることもあります。 サービスは2026年にAWS Continuumという名前の傘の下へ移り、公式製品ページは「Continuum also offers a frontier agent (formerly known as AWS Security Agent)」と書いています。料金ページも[AWS Continuum Pricing](https://aws.amazon.com/continuum/pricing/)に統合されました。この記事では、task-hourの数え方、無料になる範囲（トライアル・再検証・プレビュー中の機能）、2026年10月に追加されたCI/CD連携とスケジュール実行の課金、予算を守る設定を、公式ドキュメントの記述をもとに整理します。 ## まとめ：AWS Security Agentの料金と要点 - **ペネトレーションテスト**：$50.00/task-hour。秒単位で計測し、端数も按分して課金されます。 - **task-hourの正体**：経過時間ではなく、並列で走る全タスクの作業時間の合計です。経過時間を上回るのが通常です。 - **無料トライアル**：新規利用者は初回のテスト実行から2か月間、各月400 task-hoursまで無料です。プレビュー参加者も対象です。 - **無料の再検証**：1つの検出結果につき3回までの再検証（revalidation）は課金されません。 - **CI/CD連携は今は無課金**：2026年10月5日に始まったCI/CDパイプライン連携はパブリックプレビューで、プレビュー中はCI/CDモードの実行（continuous pentest runs）に料金がかかりません。上限は月500回です。 - **スケジュール実行は通常課金**：EventBridge Schedulerによる定期実行は通常のテストとして課金されます。週1回・上限20時間なら月$4,000〜$5,000まで膨らみ得ます。 - **上限設定の下限は20時間**：Max task hoursで1回の上限を設定できますが、コンソールで指定できる最小値は20時間（＝$1,000）です。 - **コードレビュー・設計レビュー・脅威モデリング**：プレビュー中のため無課金です（月次クォータはあります）。 - **コード脆弱性機能**：2026年10月22日にGAとなったContinuum for code vulnerabilitiesは、保護するコード行数に応じた月額と推論単位（$10/CIU）の2本立てで、ペネトレーションテストとは別の料金体系です。 ## AWS Continuumの料金体系：機能ごとの課金と提供段階 料金を調べる前に押さえておきたいのが、名前と課金単位の整理です。AWS Continuumは複数の機能の総称で、旧AWS Security Agentの機能はContinuum for penetration testingなどの名前で引き継がれています。ドキュメントのタイトルは「AWS Security Agent (now part of AWS Continuum)」になりましたが、IAMのアクション名前空間は `securityagent`、サービスプリンシパルは `securityagent.amazonaws.com` のままです。名前が変わっても設定の実体は同じものを指します。 ### 機能別の課金単位と無料の範囲 ユーザーガイドの[Pricing and billing](https://docs.aws.amazon.com/securityagent/latest/userguide/pricing.html)は、課金対象をペネトレーションテストだけと書いています。逐語は「AWS doesn’t charge for continuous pentest runs while continuous pentesting is in preview, or for code reviews, design reviews, or threat models while those capabilities are in preview.」です。 | 機能 | 提供段階 | 課金 | 主なクォータ | | ----------- | ----------------- | ------------- | ------ | | ペネトレーションテスト | GA（2026年3月31日） | $50/task-hour | 同時実行5 | | CI/CDモードの実行 | プレビュー（2026年10月5日） | 無課金 | 500回 | | PRコードレビュー | プレビュー | 無課金 | 1,000件 | | 設計レビュー | プレビュー | 無課金 | 200件 | | 脅威モデリング | プレビュー | 無課金 | 記載なし | | コード脆弱性 | GA（2026年10月22日） | 行数の月額＋$10/CIU | 別体系 | コード脆弱性機能（Continuum for code vulnerabilities）は、旧AWS Security Agentとは別にContinuumで新設された機能です。保護するコード100万行あたりの月額（最初の1,000万行は$200で、規模に応じて$180・$160・$130・$100へ段階的に下がる）と、作業量に応じた推論料金（1 Continuum inference unitあたり$10）の合計で課金されます。仕組みと見積もりの落とし穴は[AWS Continuumとは？コード脆弱性の検出・検証・修正PRの仕組みと料金・導入手順](/tech/details/18846/)で解説しているので、ここからはペネトレーションテストの料金に絞ります。AWSがフロンティアエージェントと呼ぶ製品群の中での位置づけは[フロンティアエージェントとは？AWSの4製品（Kiro・Security・DevOps・FinOps）の定義と現在地【2026年10月】](/tech/details/10710/)で並べています。 ### 提供開始からの経緯と東京リージョンの対応 ユーザーガイドの[ドキュメント履歴](https://docs.aws.amazon.com/securityagent/latest/userguide/doc-history.html)では、初版の公開が2025年12月2日です。re:Invent 2025でプレビューとして発表され、2026年3月31日にオンデマンドのペネトレーションテストがGAとなり、同時に料金が公開されました。8月13日に上限設定（Max task hours）、9月25日にCI/CDパイプライン連携のドキュメント、10月9日にGen AIアプリケーション向けのテスト範囲、10月13日にJira連携が追加されています。 GA時点の提供リージョンは東京を含む6つでした。2026年11月時点の[セキュリティのベストプラクティス](https://docs.aws.amazon.com/securityagent/latest/userguide/security-best-practices.html)の推論表には15リージョンが載っており、オハイオ・カナダ（中部）・ロンドン・パリ・ストックホルム・ソウルなどが加わりました。アジアパシフィック（東京）はGA時から対象で、大阪は含まれていません。料金はリージョンによらず$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つの計算例を並べます。所要時間とtask-hoursの差がそのまま金額差になっています。 | 想定 | 所要時間 | task-hours | 金額 | | ---------------- | ------ | ------------------- | --------- | | 新規APIのテスト | 約1時間 | 3時間27分45秒（3.4625） | $173.13 | | ECサイトの月次テスト | 4時間 | 24時間（24.0000） | $1,200.00 | | 大規模SaaSのリリース前テスト | 9時間30分 | 31時間15分30秒（31.2583） | $1,562.92 | 計算は、秒に直して3,600で割り、$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)}") # スケジュール実行を上限20 task-hoursで回したときの月額の最大値 cap = Decimal(20) for label, runs in [("週1回(月4回)", 4), ("週1回(月5回)", 5), ("毎日(30回)", 30)]: print(f"{label}: 最大 ${cost(cap * runs)}") ``` Python 3で実行すると、出力の上3行は公式の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 週1回(月4回): 最大 $4000.00 週1回(月5回): 最大 $5000.00 毎日(30回): 最大 $30000.00 ``` 公式例以外の相場感として、クラスメソッドの[OWASP Juice Shopに対する検証記事](https://dev.classmethod.jp/articles/security-agent-owasp-juice-shop/)では、途中で止めたテストの所要時間が54分41秒、task-hoursが3.66で、想定料金は$183と報告されています。所要時間の約4倍がtask-hoursになった計算で、公式の新規API例（約1時間で3.46）とほぼ同じ比率です。 事前の精密な見積もりは、公式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をベースラインにし、以後はその数字で予算を組むのが現実的な手順です。 ### 無料トライアル2か月×400 task-hoursと再検証3回の無料枠 新規のAWS顧客はAWS Free Tierの対象で、加えてペネトレーションテストの新規利用者には**初回のテスト実行を起点に2か月の無料トライアル**が付きます。各トライアル月に含まれるのは400 task-hoursまでで、超過分と期間終了後は通常の従量課金です。400 task-hoursは公式のECサイト例（24 task-hours）なら月16回分に当たります。プレビュー参加者もトライアルの対象で、GA後に最初のテストを実行した時点から2か月が数えられます。 検出結果の再検証も覚えておくと効きます。料金ページは「does not charge users for the first three revalidations per finding」と書いており、1つの検出結果につき3回までの再検証は無料、4回目以降はtask-hourで課金されます。修正して再確認するサイクルを3回までは費用を気にせず回せる設計です。 ## CI/CD連携とスケジュール実行の課金：無課金と通常課金の境目 現在はCI/CDパイプライン連携とスケジュール実行の両方が用意されています。ただし課金の扱いが正反対なので、混同すると予算を大きく外します。 なお、ユーザーガイドの[Security Considerations](https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html)のFAQは、2026年11月2日時点でも「does not integrate with any existing security tools or CI/CD pipelines」「does not have public APIs or the ability to schedule the penetration test runs」という旧記述のままです。実際にはAPIもCI/CD連携もスケジュール機能も別ページで公開されており、FAQだけが追随していません。この一文を根拠に「自動化できない」と判断しないでください。 ### CI/CDモードの課金条件：プレビュー中の無料範囲 [2026年10月5日のWhat’s New](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-continuum-penetration-testing/)で、デプロイ直後の環境にペネトレーションテストを当てて本番への昇格を止めるCI/CD連携が、パブリックプレビューとして公開されました。対応するのはGitHub Actions、GitLab CI/CD、Bitbucket Pipelines、Azure DevOps Pipelinesの4つです。 料金面で重要なのは、[CI/CD連携のページ](https://docs.aws.amazon.com/securityagent/latest/userguide/cicd-pentest.html)の「While it is in preview, AWS doesn’t charge for continuous pentest runs, however you start them. You still pay for the other AWS resources you use, such as hosting the application you test. Other penetration tests are metered as usual.」という一文です。CI/CDモードで起動した実行は、プレビュー中は課金されません。代わりに月500回（アカウント・リージョンごと、引き上げ可）のクォータがかかります。テスト対象のアプリケーションをホストする費用は別途かかります。 費用が抑えられる理由はもう1つあります。CI/CDモードは、デプロイされた変更のコミット範囲にテストを絞ります。変更が攻撃面に触れていなければテストせずにパスし（SCOPED\_OUT）、範囲が設定外なら既定でブロックします（SCOPE\_CONFLICT）。全範囲のテストへ自動で切り替わることはないと明記されています。 GitHub Actionsでは公式のアクション `aws-actions/aws-continuum-run-pentest`（Apache-2.0、v1.0.0は2026年9月30日公開）を使います。以下は読みやすさのためバージョンタグで示しますが、本番導入時は各アクションをレビュー済みの完全なコミットSHAに固定してください。[公式チュートリアル](https://docs.aws.amazon.com/securityagent/latest/userguide/sample-cicd-github.html)の構成を東京リージョン向けにしたものが次の例です。ステージングへのデプロイ後にゲートを置き、HIGH以上の検出があれば本番デプロイのジョブが動きません。この例のdeploy.shは各環境に合わせて用意し、CONTINUUM\_ROLE\_ARNにはOIDCの信頼設定と必要なAPI権限を持つIAMロールを指定してください。 ``` name: deploy-with-pentest-gate on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest environment: staging steps: - uses: actions/checkout@v4 with: persist-credentials: false - run: ./deploy.sh staging security-pentest: needs: [deploy] runs-on: ubuntu-latest permissions: id-token: write # OIDCで一時認証情報を得る contents: write # 最後に通したコミットをrefとして記録する actions: read # 前回成功した実行を基点に使う deployments: read steps: - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.CONTINUUM_ROLE_ARN }} aws-region: ap-northeast-1 # 引き受けるIAMロールの最大セッション時間を事前に7200秒以上に設定 role-duration-seconds: 7200 - uses: aws-actions/aws-continuum-run-pentest@v1 with: agent-space-id: ${{ vars.CONTINUUM_AGENT_SPACE_ID }} pentest-id: ${{ vars.CONTINUUM_PENTEST_ID }} severity-threshold: HIGH on-scope-conflict: block fail-on-error: "true" # 既定はfalse（基盤エラー時に素通り） timeout-minutes: "45" deploy-prod: needs: [security-pentest] runs-on: ubuntu-latest environment: production steps: - uses: actions/checkout@v4 with: persist-credentials: false - run: ./deploy.sh production ``` 既定値は4つのCI/CD基盤で共通で、重大度のしきい値はHIGH、待ち時間は60分、範囲の衝突はblock、基盤エラー時の失敗（fail-on-error）はfalseです。最後の既定が落とし穴で、公式は「The shipped default is fail-open.」と書いています。設定ミスでテストが始まらなくてもパイプラインが通るため、セキュリティの承認を条件にする本番昇格では `fail-on-error` を `"true"` にします。最初は `dry-run: "true"` で1回動かすと、認証・リージョン・リポジトリ連携だけを確かめ、テストのジョブを起動せずに設定ミスを洗い出せます。 前提として、CI/CDモードは作成済みのペネトレーションテストを起動するだけで、対象ドメインの検証やテスト構成は先にコンソールとWebアプリケーションで作ります。ペネトレーションテストの設定でCI/CDモードを有効にし、リポジトリをソース管理の統合として接続しておく必要があります。プレビュー終了後の料金は公表されていないため、無課金を前提に回数を増やした運用は、GA時に見直す前提で組んでください。 ### スケジュール実行は通常課金：週1回で月$4,000〜$5,000の可能性 もう1つの自動化手段が[スケジュール実行](https://docs.aws.amazon.com/securityagent/latest/userguide/schedule-penetration-test.html)です。Amazon EventBridge Schedulerで、1回だけ、または毎日・毎週・毎月の繰り返しでテストを起動できます。管理者がAgent Spaceでスケジュールを有効にすると、`continuum-schedule-` にAgent Space IDを付けた名前のIAMロールが作られ、Schedulerがそのロールで実行を起動します。1つのペネトレーションテストに持てるスケジュールは1つです。 料金ページとPricing and billingが無課金の例外として挙げているのはCI/CDモードの実行だけで、スケジュール実行は通常のテストとして課金されます。上の計算どおり、上限20 task-hoursのテストを週1回回すと月4〜5回で最大$4,000〜$5,000、毎日なら30日間で最大$30,000、31日間で最大$31,000です。しかもスケジュール実行は「実行開始時点のテスト構成」を使うため、誰かが途中でMax task hoursをNo limitに変えると、次回以降の上限も外れます。 判断としては、目的がリリースごとの差分検査だけなら、プレビュー中は無課金でテスト範囲も差分に絞られるCI/CDモードを優先します。変更箇所以外も定期的に再検査したい場合は、毎回課金されるスケジュール実行を別枠で予算化し、Max task hoursを必ず設定します。 ## 予算を守る設定：上限20時間と起動権限の絞り込み ユーザーガイドは「Quotas limit capacity but don’t limit spending.」と明記しています。月次クォータに達すると対象機能の追加実行は制限されますが、有料のペネトレーションテスト全体の支出上限にはなりません。クォータを引き上げてもレートは変わりません。費用を止める手段は、テストごとの上限設定と、テストを起動できる人の制限の2つです。 ### Max task hoursの下限20時間と上限到達時の挙動 2026年8月13日に追加されたMax task hoursは、テスト作成ウィザードでプリセット（20時間・30時間など）、No limit、Customから選びます。[テスト作成のページ](https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html)は「The smallest limit you can set is 20 hours.」と書いており、カスタム値も含めて最小は20時間（＝$1,000）です。1回$300に収めたい、という絞り方はできません。なお20時間は上限の最小値であり、最低料金ではありません。実際に使ったtask-hoursだけが課金されます。 上限に達すると、エージェントは作業を止めてそこまでの検出結果を保持し、実行はCompletedで終わります。途中で手動停止した場合も、そこまでのtask-hoursは課金対象です。APIの `CreatePentest` では `maxTaskHours` を指定しないと上限なしで最後まで実行されるため、CLIやIaCでテストを作るときは必ず値を入れます。 公式が挙げるコスト抑制策は4つです。 - **対象を絞る**：ドメイン全体ではなく特定のURLパスを対象にし、除外するURLを明示します。 - **リスクタイプを絞る**：リスクタイプを1つ増やすごとにタスクが増えます。Webアプリケーションの範囲では不要なカテゴリを除外できます。 - **逸れた実行を止める**：ログをリアルタイムで見て、関心のない領域を探索し始めたら停止します。 - **構成を再利用してベースラインを作る**：同じ構成の実行間でtask-hoursを比べ、その対象の標準的なコストを把握します。 実績の追跡にはAWS Cost ExplorerとAWS Budgetsを使います。CloudWatchには `PentestExecutionDuration` というメトリクスが秒単位で発行されますが、これは経過時間で、課金単位のtask-hoursではありません。task-hoursはWebアプリケーションのAll runsテーブル、または各実行のLogsタブで確認します。 ### SCP・IAMによるテスト起動権限の制限 上限20 task-hoursでも1回最大$1,000、上限を上げればそれ以上かかる操作を、Webアプリケーションにアクセスできる全員が起動できる状態は、組織によっては許容できません。[CloudTrailのページ](https://docs.aws.amazon.com/securityagent/latest/userguide/logging-cloudtrail.html)は「All AWS Security Agent actions are logged by CloudTrail.」と書いており、テストの起動はIAMアクション `securityagent:StartPentestJob` として記録・制御できます。AWS Organizationsを使っているなら、承認済みのロール以外からの起動を拒否するSCPが張れます。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPentestStartExceptApprovedRoles", "Effect": "Deny", "Action": "securityagent:StartPentestJob", "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:role/pentest-approved-*", "arn:aws:iam::*:role/continuum-schedule-*" ] } } } ] } ``` 2つ目の例外は、スケジュール実行に使われるロールの名前です。CI/CDのOIDCロールも例外に入れないと、パイプラインのゲートが拒否されます。Webアプリケーションからの起動がどの主体として記録されるかは構成によって変わるため、SCPを張る前にCloudTrailで `StartPentestJob` のイベントの `userIdentity` を確かめ、必要な主体を例外に加えてください。確かめずに張ると、利用者がWebアプリケーションからテストを起動できなくなります。 ## ペネトレーションテストの実行手順：Agent Space作成からテスト起動まで 作業は3つの画面に分かれます。管理者はAWSマネジメントコンソールでAgent Spaceと権限を用意し、利用者は専用のWebアプリケーションでテストを作成・実行し、開発者はGitHubやIDEで修正のプルリクエストを受け取ります。対象範囲の合意や関係者への事前連絡といった、ツールに依らない共通の工程は[ペネトレーションテストとは？種類・手法・手順と実施前に必要な許可【2026年版】](/column/details/1410/)で解説しているので、社内の承認手続きを組むときは合わせて確認してください。 ### 管理者側：Agent Spaceの作成とドメインの所有権検証 コンソールで最初のAgent Spaceを作ると、そのアカウント用のWebアプリケーションが生成されます。Agent Spaceは保護対象のアプリケーション単位で作るのが公式推奨で、アカウント・リージョンあたり最大100個です。続いてペネトレーションテストを有効化し、対象ドメインの所有権を[DNS\_TXT・HTTP\_ROUTE・PRIVATE\_VPCのいずれか](https://docs.aws.amazon.com/securityagent/latest/userguide/enable-test-domain.html)で検証します。対象ドメインが同一アカウントのRoute 53にあれば、DNS\_TXTはワンクリックでレコード作成まで自動化されます。 登録できる対象ドメインは1つのAgent Spaceにつき最大20件です（2026年8月18日に5件から拡大）。DNS TXTまたはHTTPで検証すると、そのサブドメインは個別検証なしでテストできます。サービスロールの信頼ポリシーは `securityagent.amazonaws.com` を指定し、External IDを条件に付けるのが公式推奨です。 ### 利用者側：テスト範囲の選択と認証情報の事前テスト Webアプリケーションでのテスト作成は、詳細（名前・テスト範囲・対象URL・サービスロール・ロググループ）、任意のVPCリソース、任意の認証情報、ネットワーク構成、任意の追加設定の順に進みます。2026年10月9日からは、最初のステップでテスト範囲を選べるようになりました。 - **Web application（既定）**：WebとAPIのリスクを対象にした通常のテストです。リスクタイプの除外ができます。 - **Gen AI application**：チャットボットやエージェントなどLLMを使う機能に絞ったテストです。公式FAQによると、OWASP Top 10 for LLM Applicationsのうちプロンプトインジェクション、機密情報の漏えい、不適切な出力処理、過剰な権限（Excessive Agency）、システムプロンプトの漏えいの5種を固定で検査し、リスクタイプの除外はできません。生成AI特有の攻撃手法を人が設計して当てる演習は[AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】](/tech/details/16071/)で扱っています。 2026年9月18日に追加された認証情報のテストは、実行前に必ず通しておく価値があります。各認証情報でTestを実行すると、エージェントが実際にサインインできるかを確かめ、ログイン後に到達するドメインも洗い出します。サインインできないまま本実行に入ると、認証後の画面を検査できないままtask-hoursだけを消費します。 ネットワーク構成のステップでは、到達しうるドメインをTarget（攻撃してよい・所有権検証が必要）、Accessible（アクセスはするが攻撃しない・ログインページやCDN）、Out of scope（一切アクセスしない・配下のパスも除外）の3つに分けます。既定では対象URLにしか到達できず、out of scopeはaccessibleより優先されます。破壊的な操作や管理機能のパスは、この段階でout of scopeに入れておきます。非標準ポートは `https://example.com:8443` のようにURLへ含めて指定します（2026年9月16日から対応）。 ## 検出できるリスクの範囲と公式が認める限界 Webアプリケーションの範囲で公式FAQが挙げるリスクタイプは13種類です（任意ファイルアップロード、コードインジェクション、コマンドインジェクション、XSS、IDOR、JWTの脆弱性、ローカルファイルインクルージョン、パストラバーサル、権限昇格、SSRF、SSTI、SQLインジェクション、XXE）。APIの定義はこれより細かく、[botocoreのサービス定義](https://github.com/boto/botocore/blob/develop/botocore/data/securityagent/2025-09-06/service-2.json)では `RiskType` の値が28個あり、GraphQLの脆弱性やビジネスロジックの脆弱性、デフォルト認証情報なども含みます。同じ定義の `JobType` は FULL・REVALIDATION・CICD の3値です。 2026年8月31日からは、対象ホストで標準のWebポート以外に開いているTCPポートを、Exposed Network Portsという情報レベルの検出結果1件にまとめて報告します。検出したサービス名とバージョンを並べますが、悪用は試みません。10月13日からは検出結果からJira Cloudの課題を作れるようになり、再検証の結果を課題へコメントすることもできます。 一方で、公式が認めている限界は導入判断に直結します。 - **網羅は保証されない**：幅優先で探索しますが確率的な動作のため、すべての重要な処理やエンドポイントを発見・テストする保証はないとFAQに書かれています。 - **テスト計画を事前に確認できない**：攻撃計画は探索に応じて動的に変わるため、実行中のログを見て望ましくない方向なら止める運用になります。 - **リクエストの並列度は調整できない**：負荷過多やDoSを避けるガードレールはありますが、対象への同時リクエスト数を指定する設定はありません。 - **専門のペネトレーションテストサービスの代替ではない**：FAQには「AWS Security Agent is not a professional penetration testing service」と明記されています。 影響の小さいペイロード（SQLインジェクションを見つけてもテーブルを削除せずバージョン文字列を取得する等）を使う設計ですが、公式は「we always recommend doing penetration testing against a pre-production environment」として、本番ではなく検証環境での実行を推奨しています。 ## 導入前に確認する制約：クォータ・推論の処理場所・侵入テストポリシー [Service Quotas](https://docs.aws.amazon.com/securityagent/latest/userguide/quotas.html)のうち、費用と運用に効くものを抜き出します。いずれもアカウントとリージョンの組み合わせごとの値です。 | 対象 | 上限 | 引き上げ | | ------------------ | ----- | ---- | | ペネトレーションテストの同時実行 | 5 | 可 | | CI/CDモードの実行（月あたり） | 500 | 可 | | PRコードレビュー（月あたり） | 1,000 | 可 | | 設計レビュー（月あたり） | 200 | 可 | | ペネトレーションテストのプロジェクト | 1,000 | 可 | | Agent Space | 100 | 可 | | 統合（GitHub等） | 20 | 不可 | データの扱いでは、顧客データをモデルの学習に使わず第三者にも共有しないこと、保存時はAWS KMSで暗号化すること、テストのログは顧客アカウントのCloudWatchに保存されることが公式に書かれています。分けて考える必要があるのが推論の処理場所です。東京からのリクエストは地理的クロスリージョン推論で、ほとんどの機能は日本国内で処理されますが、**コード修復（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.」と書いています。データの処理場所を国内に限る契約がある場合、自動修復の機能は使わない運用で合意しておく必要があります。 AWS自身の侵入テストポリシーとの関係では、AWSはPermitted Servicesに挙げたサービス（EC2、ELB、RDS、CloudFront、API Gateway、Lambdaなど）について、自社インフラの評価を事前承認なしで認めています。テスト対象すべてに権限を持つことは顧客側の責任で、第三者エンドポイントへの未承認テストなどの不正利用が検知されると、そのアカウントで進行中のテストはすべて終了させられます。AWS上のシステムを診断するときに申請が要る範囲は[AWSの脆弱性診断｜申請不要の範囲とInspector・Security Hubの料金、外注の判断基準](/column/details/2713/)にまとめています。 ## Amazon Inspector・AWS Security Hubとの違い 同じAWSのセキュリティサービスでも、見ている対象と検出の方法が違います。置き換えではなく役割分担で考えるのが実務的です。 | 観点 | AWS Security Agent | Amazon Inspector | AWS Security Hub | | ----- | ------------------ | -------------------- | ---------------- | | 対象 | 稼働中のWebアプリ・API | EC2・ECR・Lambda・リポジトリ | 各サービスの検出結果 | | 検出の方法 | 攻撃して悪用可能性を実証 | 脆弱性・設定の継続スキャン | 集約と基準への照合 | | 実行契機 | 手動・CI/CD・スケジュール | 継続的・自動 | 継続的・自動 | | 主な出力 | 再現手順付きの検出と修正PR | CVE・コード脆弱性 | 統合ダッシュボード | | 課金 | $50/task-hour | 対象リソース単位 | リソース単位の月額 | 既知の脆弱性を洗い出す継続スキャンは[Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断](/tech/details/15894/)、検出結果を1か所に集約する仕組みは[AWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説](/tech/details/15890/)が担当です。AWS Security Agentは、見つかった弱点が実際に悪用できるかを確かめる深い検査として位置づけると、他の2つと重複しません。 ## AIペネトレーションテストと外部診断の使い分け：採用する条件と見送る場面 ペネトレーションテストの手段は、AWS Security AgentのようなAIエージェント、専門事業者による手動の診断、CI/CDに組み込むDASTツールの3つに分かれます。脆弱性診断とペネトレーションテストの目的の違いは[ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/)で扱っているので、ここではAWS Security Agentを入れる前提で役割を比べます。 | 観点 | AWS Security Agent | 外部の専門事業者 | DASTツール | | ----- | ------------------ | ---------- | ------------ | | 実施主体 | AIエージェントが自律実行 | 診断員が計画して実施 | CIのジョブが定型検査 | | 費用の単位 | $50/task-hour | 案件ごとの見積もり | ツール費（ZAPは無償） | | 網羅の保証 | なし（確率的な探索） | 契約で範囲を定義 | ルールに沿った検査 | | 主な成果物 | 検出結果と修正PR | 第三者の診断報告書 | スキャン結果 | | 向く時期 | 開発中・リリース前 | 本番公開前・監査対応 | コミットごと | コミットごとの定型検査に使うDASTは[DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説](/tech/details/15882/)で扱っています。AWS Security AgentのCI/CDモードはデプロイ後の環境に対する差分のテストで、プルリクエスト単位の静的なチェックとは役割が違います。 ### AWS Security Agentを採用する条件：検証環境と予算の振れ幅 次の条件がそろうなら、開発工程に組み込む価値があります。 - **検証環境を用意できる**：本番の認証情報を渡さず、本番相当のステージングに対してテストできること。CI/CDモードもデプロイ後のステージングに当てる前提です。 - **リリースの頻度が高い**：外部診断を毎回発注すると日程も費用も合わない体制で、プレビュー中は無課金のCI/CDモードを試せる状況なら、費用面の障壁はほぼありません。 - **1回最大$1,000の振れ幅を吸収できる**：手動やスケジュールで回す全体テストは、上限の下限が20 task-hoursのため1回$1,000まで動く前提で予算を組めること。 - **検出結果を直す体制がある**：再現手順付きの検出結果をトリアージし、修正PRをレビューできる開発者がいること。 ### 外部診断を優先してAWS Security Agentを見送る場面：報告書と国内処理 反対に、次のどれかに当たる場合はAWS Security Agentを主軸にせず、外部の専門事業者による診断を優先します。 - **第三者の診断報告書を求められている**：取引先の調達要件や監査で提出が必要な場合です。公式FAQ自体が専門のサービスではないと書いています。 - **国内処理が必須で、コード修復も利用したい**：東京起点でもコード修復の推論は欧州連合で処理されます。コード修復以外の推論は日本国内のため、利用機能を分けて判断します。 - **業務ロジックの網羅を保証したい**：決済や権限の切り替えなど、画面遷移の組み合わせを漏れなく確かめたい箇所は、確率的な探索では保証が得られません。 - **検証環境が無い**：本番にしか対象が無い状態で実行すると、監視アラートの発火やデータ変更のリスクを本番で負います。 判断としては、3段で組むのが現実的です。デプロイごとの差分はCI/CDモード（プレビュー中は無課金）やDASTに任せ、大きなリリースの前に手動で全体テストを回して見つかった穴を直し、本番公開や年次の節目に外部の専門事業者で仕上げます。AIで浅い穴を先に塞いでおけば、外部診断の工数を業務ロジックなど人が見るべき論点に集中させられます。AWS Security Agentの検出結果を専門家の目で検証したい、あるいは第三者としての診断報告書が必要という場合は、一創の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でご相談を受け付けています。 ## よくある質問 ### AWS Security Agentの料金はいくらですか？ ペネトレーションテストが$50.00/task-hourの従量課金で、秒単位で計測されます。task-hourは並列で走るタスクの作業時間の合計なので、所要時間より大きくなるのが通常です。公式の計算例では、約1時間のテストで$173.13、4時間のテストで$1,200.00です。 ### 無料で試せますか？ 新規利用者は初回のテスト実行から2か月の無料トライアルを使え、各月400 task-hoursまで無料です。プレビュー参加者も対象です。加えて、1つの検出結果につき3回までの再検証、プレビュー中のCI/CDモードの実行、コードレビュー・設計レビュー・脅威モデリングは課金されません。 ### AWS ContinuumとAWS Security Agentの料金は別ですか？ 同じ料金ページにまとまっていますが、課金単位は機能ごとに違います。旧AWS Security Agentのペネトレーションテストは$50/task-hour、2026年10月22日にGAとなったコード脆弱性機能は、保護するコード100万行あたりの月額（最初の1,000万行は$200）と$10/CIUの推論料金の合計です。 ### 東京リージョンで使えますか。データは日本国内に留まりますか？ アジアパシフィック（東京）はGA時から対象です。データの保存はリクエストが発生したリージョンに留まり、推論もほとんどの機能は日本国内で処理されますが、コード修復だけは欧州連合で処理されます。クロスリージョン推論はオプトアウトできません。 ### CI/CDパイプラインに組み込んで自動実行できますか？ できます。2026年10月5日からパブリックプレビューとして、GitHub Actions・GitLab CI/CD・Bitbucket Pipelines・Azure DevOps Pipelinesでデプロイ後のゲートを組めます。プレビュー中はCI/CDモードの実行に料金がかかりません。定期実行が必要ならスケジュール機能もありますが、こちらは通常どおり課金されます。 ### 外部のペネトレーションテスト事業者は不要になりますか？ 公式は「AWS Security Agent is not a professional penetration testing service」と明記しており、代替とは位置づけていません。網羅性も保証されません。第三者の診断報告書が必要な場面では、引き続き専門事業者による診断が必要です。 ## 関連記事 - [AWS Continuumとは？コード脆弱性の検出・検証・修正PRの仕組みと料金・導入手順](/tech/details/18846/) - [Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断](/tech/details/15894/) - [AWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説](/tech/details/15890/) - [脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説](/tech/details/16226/) - [AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】](/tech/details/16071/) --- 出典: [AWS Security Agent（AWS Continuum）の料金｜$50/task-hourの数え方と無料になる範囲]()（株式会社一創）