AWSペネトレーションテストの結果の見方｜AWS Security Agentの検出結果の読み方と直し方

AWS上で動かすシステムにペネトレーションテストを実施すると、重大度や信頼度のバッジが並んだ検出結果（Findings）が一覧で返ってきます。

2026年3月31日に一般提供が始まったAWS Security Agent（AI型のオンデマンドペネトレーションテストで、2026年10月にAWS Continuum for penetration testingへと発展しました）を使えば、専門のベンダーに依頼しなくても自社でこの結果を得られるようになりました。

一方で、画面を開いて最初に迷うのが「この結果の各項目は何を意味し、どれから直せばよいのか」という点です。重大度バッジの色、エージェントの信頼度、CVSSメトリクス、再現手順、自動修復のプルリクエスト。項目は多いものの、読み方を体系立てて解説した日本語の情報はまだ多くありません。

本記事では、AWS Security Agentの検出結果の読み方を公式ドキュメントの定義にもとづいて整理し、優先順位の付け方、検出された問題の直し方、実際の検出件数や費用の実例までを解説します。あわせて、自動テストで足りない範囲を人手の専門ペネトレーションテストや脆弱性診断でどう補うか、判断の材料も示します。

AWS Security Agentの検出結果（Findings）の読み方

ここからは、検出結果の画面に並ぶ各項目が何を表すのかを、公式ドキュメントの定義にそって確認します。まず前提となるツールの位置づけから整理します。

そもそもAWS Security Agent（現 AWS Continuum）とは

AWS Security Agentは、AIエージェントが攻撃者の視点で疑似的な侵入テストを行い、検出結果をまとめて返すオンデマンド型のペネトレーションテスト機能です。AWSは2026年3月31日に、6つのAWSリージョン（東京リージョンを含む）でこの機能を一般提供として開始したと発表しています。

その後も機能追加が続いており、2026年5月には検出結果ごとの検証スクリプト生成が加わりました。2026年10月には「AWS Continuum for penetration testing」へと名称を変え、CI/CDパイプラインに組み込んでデプロイごとにテストする使い方にも広がっています。

半年ほどで急速に姿を変えているため、料金・対応リージョン・レポートの言語などは利用する時点での再確認をおすすめします。

出典リンクは以下にまとめています。

出典・参考資料（2件）

• 出典：AWS Security Agent on-demand penetration testing is now generally available｜AWS What’s New（2026年3月31日）（https://aws.amazon.com/about-aws/whats-new/2026/03/aws-security-agent-ondemand-penetration/）
• 出典：AWS Continuum で実現するデプロイごとのペネトレーションテスト｜AWS公式ブログ（2026年10月）（https://aws.amazon.com/jp/blogs/news/penetration-testing-every-deployment-with-aws-continuum/）

こうした「デプロイごと・継続的にテストを回す」流れは、AWSに限った動きではありません。AIによる侵入テストの広がりを提供側はどう見ているのか。Aikido Securityを国内で提供する株式会社AndGoの原氏は、次のように話しています。

検出結果画面の全体像（概要・ログ・検出結果の3タブ）

テストは進行状況がステップ表示されながら進みます。公式ドキュメントでは、進行段階が次の4つで示されます。

• プリフライト：初期セットアップと接続チェック
• 静的分析：コードと設定の分析
• ペンテスト：ランタイムテストと脆弱性スキャン
• 最終化：最終検証とレポート生成

テストが完了すると、結果は「概要」「ログ」「検出結果」の3つのタブで確認できます。概要タブには実行のサマリーやリスクタイプ別のダッシュボードが表示され、ログタブには実行中の全アクションの詳細が残ります。実際に1件ずつ内容を読むのは検出結果タブで、左側に検出結果のリスト、右側にその詳細が分割ビューで並びます。

重大度バッジの一覧（色・意味・対応の緊急度）

各検出結果には重大度バッジが付きます。公式ドキュメント（機械翻訳版）の定義は次のとおりです。まずはこの5段階の意味を押さえると、どれが深刻かを一目で判断できます。

重大度バッジ（色）	公式の定義（機械翻訳版）
重大（赤）	即時のアクションが必要。悪用するとシステムの侵害につながる可能性があります
高（赤）	迅速な注意が必要です。悪用すると、セキュリティに大きな影響を与える可能性があります
中程度（オレンジ）	妥当な期間内に対処する必要があります。全体的なセキュリティリスクに寄与します
低（黄色）	定期的なメンテナンスの一環として対処でき、即時リスクを最小限に抑える
情報（青）	情報目的、即時リスクは最小限またはまったくない

出典・参考資料（1件）

• 出典：ペネトレーションテストの結果を確認する｜AWS Security Agent ユーザーガイド（機械翻訳版。英語版が優先される旨の注記あり）（https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/review-penetration-findings.html）

重大と高はいずれも赤で表示されるため、色だけで両者を見分けることはできません。この2段階はバッジのラベルで区別します。

エージェント信頼度の読み方

重大度と並んでもう一つ重要なのが、エージェントの信頼度バッジです。これは検出結果に対してAIがどれだけ確からしいと判断しているかを「高・中・低」の3段階で示すものです。重大度が「その脆弱性が悪用されたときの影響の大きさ」を表すのに対し、信頼度は「本当に存在する脆弱性かどうかの確からしさ」を表します。

公式ドキュメントには、表示の既定について次の記載があります。

デフォルトでは、エージェントの信頼度が高い結果のみが表示されます。エージェントの信頼度が中または低の検出結果と誤検出を表示するには、未検証の検出結果の非表示トグルをオフにします。

出典：ペネトレーションテストの結果を確認する｜AWS Security Agent ユーザーガイド

つまり、画面を開いた段階で見えているのは信頼度の高い結果に絞り込まれた状態です。偽陽性を含むすべての検出結果を確かめたいときは、このトグルを切り替えて中・低の信頼度も表示させます。

CVSSメトリクスの内訳の読み方

各検出結果には、CVSS（共通脆弱性評価システム）のメトリクスが添えられます。重大度の数字だけでなく、その内訳を読むと「どういう条件で悪用されるのか」が具体的につかめます。公式ドキュメントが挙げる主なメトリクスは次のとおりです。

• 攻撃ベクトル（AV・Network／Adjacent／Local／物理）：攻撃をリモートで実行できるかを示す
• 攻撃の複雑さ（AC・低／高）：特殊な条件を悪用する必要があるかを示す
• 必要な権限（PR・None／Low／High）：攻撃者が必要とするアクセスレベル
• ユーザーインタラクション（UI・なし／必須）：悪用にユーザーの操作が必要か
• スコープ（S）：脆弱性が他のコンポーネントに影響を与えるか
• 機密性・完全性・可用性への影響（None／Low／High）：システムのセキュリティへの影響度

公式ドキュメントは、この内訳の読み解きの指針として「ネットワーク攻撃ベクトル、複雑さの低い、機密性/整合性の高い影響の検出結果は、即時の対応を必要とする最も危険な脆弱性を表します」と説明しています。リモートから・簡単に・重要情報に影響するものほど危ない、という順で読むと優先順位を付けやすくなります。

自社の検出結果に当てはめるときは、重大度の数字だけでなくメトリクスの値で緊急度を読み替えられます。たとえば「攻撃ベクトル: Network／攻撃の複雑さ: 低／必要な権限: None／ユーザーインタラクション: なし」なら、インターネット越しに特別な条件も権限も利用者の操作もなく悪用できる状態を意味します。同じ重大度のなかでも、先に手を付けるべき結果と判断できます。

逆に、攻撃ベクトルが Local（対象の端末内からのみ）や必要な権限が High（管理者級のアクセスが前提）であれば、悪用のハードルが上がるため、重大度が同じでも対応の緊急度は一段下げて考えられます。

出典・参考資料（1件）

• 出典：ペネトレーションテストの結果を確認する｜AWS Security Agent ユーザーガイド（https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/review-penetration-findings.html）

再現手順と検証スクリプトの位置づけ

検出結果の詳細には、脆弱性を再現するための技術手順（リクエストやレスポンスの例）が含まれます。加えて、2026年5月に追加された機能として、確認済みの検出結果ごとに検証スクリプトが自動生成されるようになりました。自分の環境変数を設定して実行すれば、その脆弱性が本当に存在するかを手元で確かめられます。

ただし、この検証スクリプトの扱いには公式の注意書きがあります。

検証スクリプトは生成 AI を使用して生成されます。実行前にスクリプトを確認し、テストが許可されているシステムに対してのみ実行します。

出典：ペネトレーションテストの結果を確認する｜AWS Security Agent ユーザーガイド

生成AIが作ったスクリプトである以上、内容を確認せずに実行しないよう注意が必要です。また「許可されたシステムに対してのみ」という条件は、後述するAWSのペネトレーションテストポリシーとも結びつく点です。

出典・参考資料（1件）

• 出典：AWS セキュリティエージェントがペネトレーションテスト検出結果用の検証スクリプトを追加｜AWS What’s New（2026年5月22日）（https://aws.amazon.com/jp/about-aws/whats-new/2026/05/aws-security-agent/）

英語のみで出力されるレポートの読み解き方・社内共有の工夫

生成されるペネトレーションテストレポートはPDF形式で、現時点では英語のみで出力されます（クラスメソッド・Qiitaの検証記事で確認。2026年3〜4月時点）。レポートの構成項目を知っておくと、英語でも必要な箇所をすぐ拾えます。実際の検証記事で確認されたレポートの項目は、おおむね以下のとおりです。

• Executive Summary：要旨（検出結果の全体像）
• Description：各検出結果の説明
• Steps to Reproduce：再現手順
• CVSS v3.1 Vector：CVSSの評価ベクトル
• 推奨対応策：直し方の提案

社内で共有するときは、英語のレポートをそのまま回すよりも、重大度・信頼度・再現手順・推奨対応策の4点を日本語で抜き出した要約を添えると、開発者以外の担当者にも伝わりやすくなります。レポートにはフィルタ機能があり、リスクレベルや信頼度、検出結果のステータスで絞り込めるため、まず重大・高かつ高信頼度のものだけを抜き出して共有用の資料をつくると効率的です。

出典・参考資料（2件）

• 参考資料：[アップデート] AWS Security Agent のペネトレーションテストでテスト結果やサマリの PDF レポートを作成してダウンロードできるようになりました｜DevelopersIO（クラスメソッド、2026年3月24日）（https://dev.classmethod.jp/articles/aws-security-agent-generates-customizable/）
• 参考資料：AWS Security Agentで設計レビュー・コードレビュー・ペネトレーションテストをやってみた｜Qiita（2026年4月29日）（https://qiita.com/sh_fukatsu/items/104c8078532c272fb1f5）

検出結果の優先順位の付け方

ここからは、並んだ検出結果のどれから着手するかを決める考え方を解説します。件数が多くても、優先順位の軸がはっきりしていれば迷いません。

既定で高信頼度のみ表示される仕組みを前提にする

前述のとおり、検出結果の画面は既定で信頼度の高いものだけが表示されます。裏を返せば、最初に目に入るのはAIが「確からしい」と判断した脆弱性です。まずはこの絞り込まれたリストを対象に優先順位を付け、その後で中・低の信頼度や未検証の結果に広げていくと、対応が発散しにくくなります。

重大・高 × 高信頼度を最優先する

優先順位の基本は、重大度と信頼度の2軸の掛け合わせです。公式ドキュメントは、着手の順番について次のように明記しています。

重大度が重大または高のバッジと高い信頼度で検出結果に優先順位を付けます。これらのバッジは、即時修復を必要とする検証済みの脆弱性を表すためです。

出典：ペネトレーションテストの結果を確認する｜AWS Security Agent ユーザーガイド

一方で、重大度が低い結果を無視してよいわけではありません。公式ドキュメントは、重大度の低い脆弱性でも複数を連鎖させることでより深刻な攻撃につながることがあると注意を促しています。中・低のものは、リスク許容度やビジネスの状況をふまえて、定期的な開発スプリントの計画に織り込むのが現実的です。

偽陽性・未検証の検出結果の扱い

AIによる検出には偽陽性（実際には問題のない誤検知）が混じることがあります。信頼度が中・低の結果や、未検証とされた結果は、鵜呑みにせず確かめる対象です。前述の検証スクリプトを使えば、自分の環境で再現を試み、本当に悪用できる脆弱性かどうかを手元で判断できます。

なお、エージェントは確率的に動くため、同じ対象でも実行のたびに検出される内容が変わることがあります（この点は後述の実例でも触れます）。1回の結果だけで「問題なし」と決めつけず、複数回の実行や手元での検証を前提にすると、見落としと過剰反応の両方を抑えられます。

検出された問題の直し方

ここからは、優先順位を付けた検出結果を実際にどう直すかを解説します。自動で直せるもの、WAFで一時的に防げるもの、設計やコードの修正が必要なものを切り分けるのがポイントです。

自動修復（プルリクエストと差分ファイル）を使う

AWS Security Agentには、検出した脆弱性のコード修復を支援する機能があります。利用するには、あらかじめAWSマネジメントコンソールで検出結果の修正を有効にしておく必要があります。リポジトリの公開・非公開によって、修復の受け取り方が変わります。

プライベート GitHub リポジトリの場合、AWS セキュリティエージェントは提案された修正を含むプルリクエストを開きます。パブリックリポジトリの場合、修復はローカルに適用できるダウンロード可能な差分ファイルとして利用できます。

出典：ペネトレーションテストの検出結果の修正｜AWS Security Agent ユーザーガイド

パブリックリポジトリで配布される差分ファイルは、手元で git apply /path/to/code_remediation_changes.diff を実行して適用できます。いずれの場合も、提案された修正の内容をレビューしてから取り込む流れになるため、修正の妥当性は人の目で確認することが欠かせません。

出典・参考資料（1件）

• 出典：ペネトレーションテストの検出結果の修正｜AWS Security Agent ユーザーガイド（https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/remediate-finding.html）

WAFで止められるもの・設計やコードの修正が要るものを切り分ける

検出された脆弱性は、すべてがコード修正を要するわけではありません。WAF（Web Application Firewall）のルールで一時的に防げるものもあれば、アプリケーションの設計そのものに起因し、WAFでは防ぎにくいものもあります。

サーバーワークスの検証では、WordPress環境で検出されたXML-RPC起因のSSRF（Server-Side Request Forgery。サーバーに不正なリクエストを送らせる攻撃。Critical）に対し、該当機能を遮断するWAFのカスタムルールを追加することで確認済みの検出結果を減らせたと報告されています。

一方、IDOR（Insecure Direct Object Reference／認可不備）のような脆弱性については、同社は次のように指摘しています。

IDOR は「認可不備」なので、SSRF や SQLi よりも AWS WAF での一般的な防御が難しく、基本は設計や実装の修正が必要

出典：【AWS Security Agent】ペネトレーションテスト機能の検証｜サーバーワークス エンジニアブログ

入力の形で判別できる攻撃はWAFのルールで止めやすい一方、「本来アクセスできないデータに正規の手続きで触れてしまう」タイプの認可不備は、アプリケーション側のロジックを直さないと根本解決になりません。検出結果ごとに、WAFで当面しのげるのか、コードや設計の修正が要るのかを見極めることが大切です。

出典・参考資料（1件）

• 参考資料：【AWS Security Agent】ペネトレーションテスト機能の検証｜サーバーワークス エンジニアブログ（2026年3月25日）（https://blog.serverworks.co.jp/aws-security-agent-pentest-waf）

修正後に再テストして確認する

修正を適用したら、同じ対象にもう一度テストを実行し、該当の脆弱性が解消したかを確認することが大切です。オンデマンドで繰り返し実行できるのは自動ペネトレーションテストの利点です。前述のとおりエージェントは確率的に動くため、1回の再テストで検出が消えても、複数回の実行で再現しないことを確かめると確実です。

WAFのルールで対処した場合は、ルールが意図どおり効いているか、正規の利用を妨げていないかもあわせて確認しておくと安心です。

実例でみる検出結果（件数・費用・時間）

ここからは、実際にAWS Security Agentを動かした検証記事から、検出件数の内訳・費用・所要時間といった生の数字を紹介します。自社で実行する前の目安として参考になります。

検証例1：17件の検出と自動修復PR、費用は約30万円

Qiitaに公開された検証（2026年4月）では、ペネトレーションテストで合計17件の脆弱性が検出されました。重大度別の内訳は次のとおりです。

• Critical：1件／High：5件／Medium：7件／Low：2件／Info：2件（合計17件）

生成されたレポートは、各検出結果についてDescription（説明）・Steps to Reproduce（再現手順）・CVSS v3.1 Vector・推奨対応策までを含む構成でした。

自動修復のプルリクエストも作成され、その一例として「Security Fix: Remove Hardcoded Credentials and Enable MFA (CWE-798, CWE-312)」のように、CWE（共通脆弱性タイプの識別番号）付きで修正内容が示されたと報告されています。

費用については、この検証では「34.41タスク時間 × 50USD = 1,720.5 USD（約30万円）」になったとされています。あわせて、エージェントは確率的に動くため、走らせる前に何タスク時間かかるかを正確に見積もる方法はない、という実務上の注意も述べられています。費用が実行してみないと確定しにくい点は、予算を組むうえで押さえておきたいところです。

課金の単位であるタスク時間は、対象の規模や検査の深さによって増減します。そのため同じ料金体系でも、実際の金額はシステムごとに変わる点に留意してください。

出典・参考資料（1件）

• 参考資料：AWS Security Agentで設計レビュー・コードレビュー・ペネトレーションテストをやってみた｜Qiita（2026年4月29日）（https://qiita.com/sh_fukatsu/items/104c8078532c272fb1f5）

検証例2：WAF導入前後で検出件数がどう変わったか

サーバーワークスの検証（2026年3月）では、意図的に脆弱性を含むOWASP Juice Shopを対象に、WAF導入の前後で検出件数を比較しています。報告された確認済みの検出件数は次のとおりです。

	Critical	High	Medium	合計
WAF導入前	3件	5件	5件	13件
WAF導入後	2件	3件	6件	11件

合計件数は13件から11件に減りましたが、Mediumは5件から6件へと増えています。WAFを入れれば一律に検出が減るわけではなく、防げる脆弱性と防げない脆弱性が切り分けられていく過程だと読むのが適切です。前述のIDORのように、WAFでは防ぎにくく設計・実装の修正が必要なものが残る点も、この数字が示しています。

加えて、前述のとおりエージェントは実行ごとに結果が変動するため、件数の小さな増減には確率的な揺らぎも含まれる点に留意してください。

なお、これらの検証はいずれもプレビュー期間から一般提供の直後にかけて実施されたものです。対応リージョンや料金、レポートの言語などはその後変わっている可能性があるため、自社で実行する際は最新の仕様を確認してください。

出典・参考資料（1件）

• 参考資料：【AWS Security Agent】ペネトレーションテスト機能の検証｜サーバーワークス エンジニアブログ（2026年3月25日）（https://blog.serverworks.co.jp/aws-security-agent-pentest-waf）

実施前に確認したいAWSの事前承認ポリシー

これからペネトレーションテストを実施する場合は、AWSの顧客サポートポリシーを確認しておく必要があります。許可された範囲を外れると規約違反になりかねないためです。ここでは押さえておきたいポイントを整理します。

事前承認なしで実施できる対象サービス

AWSは、一部のサービスについては事前の承認なしにセキュリティ評価やペネトレーションテストを実施できるとしています。

事前の承認なしに AWS インフラストラクチャのセキュリティ評価またはペネトレーションテストを実行できます。

出典：ペネトレーションテスト（顧客サポートポリシー）｜AWS

対象となるサービスには、Amazon EC2・RDS・CloudFront・API Gateway・AWS Lambda・ECS／Fargateなどが挙げられています（全量は公式ポリシーの一覧を参照してください）。

全量はポリシーの一覧に記載されており、内容は随時更新されうるため、実施前に公式ページで最新の対象を確認してください。なお、これはAWSのペネトレーションテスト全般に関するポリシーであり、AWS Security Agentで走らせる対象も原則この許可範囲の中にあると考えられます。

禁止されている行為

一方で、明確に禁止されている行為もあります。ポリシーでは、DNSゾーンウォーキングやDNSハイジャック、サービス拒否（DoS）・分散型サービス拒否（DDoS）、ポート・プロトコル・リクエストの各種フラッディング、S3バケット乗っ取り、サブドメイン乗っ取りなどが禁止行為として列挙されています。

負荷をかけてサービスを止めるような試験は許可されていないため、自分で手動のテストを行う場合は特に注意が必要です。

Simulated Eventsの事前申請と24時間以内の報告義務

一部のテストには事前の申請や承認が求められます。ポリシーには次の定めがあります。

• 「すべての Simulated Event リクエストは、遅くとも開始日の 2 週間前に AWS に送信する必要があります」。AWSは最初の連絡から2営業日以内に、非自動返信で受領を知らせるとしています
• 「Command and Control (C2) を含むすべてのセキュリティテストには、事前の承認が必要です」
• 「AWS のツールやサービスの直接的な結果として発見された脆弱性やその他の問題は、テスト完了から 24 時間以内に AWS Security に報告する必要があります」

事前承認が不要なサービスであっても、Simulated Eventsやコマンド&コントロールを伴うテストは申請・承認の対象です。テスト後の報告義務とあわせて、実施前にポリシー全文に目を通しておくと安心です。

出典・参考資料（1件）

• 出典：ペネトレーションテスト（顧客サポートポリシー）｜AWS（https://aws.amazon.com/jp/security/penetration-testing/）

AWS環境での脆弱性診断には、自分たちでAWSのツールを使って行う自己診断と、外部の専門ベンダーに依頼する方法があり、それぞれ費用のかかり方や申請の要否が異なります。手段の全体像から進め方・費用相場・事前申請のルールまでをまとめて確認したい場合は、以下の記事が参考になります。

自動ペネトレーションテストで足りるか（人手の専門診断への繋ぎ方）

ここからは、AWS Security Agentの結果を得たあとの判断を扱います。自動テストで十分なのか、人手の専門ペネトレーションテストや脆弱性診断に出すべきなのか、その見極めの材料を整理します。

自動テストは人手の専門ペネトレーションを置き換えない

自動ペネトレーションテストは手早く繰り返せる強力な手段ですが、専門家による診断を完全に置き換えるものではありません。実際に検証した各社も、この点を共通して指摘しています。サーバーワークスは注意点として「専門家によるペンテストを置き換えるものではない」「アプリケーションの状態が変わる可能性がある」「ペンテスト実行ごとに結果が変動しうる」の3点を挙げています。

結果が実行ごとに変わるのは、AIエージェントが自律的に手順を考えながらテストを進めるためで、毎回まったく同じテストが行われるとは限りません。だからこそ、自動テストは複数回の実行を前提にしつつ、重要なシステムでは人手の検証を組み合わせる使い方が現実的です。

この「AIの出力をそのまま鵜呑みにしない」という姿勢は、AIで診断を行う事業者の側でも共通します。CoWorker株式会社の一ノ瀬氏は、自社のAI診断におけるハルシネーション（AIがもっともらしく誤る現象）の扱いについて、次のように述べています。

自動で見つけにくい領域（認可不備・設計の問題・網羅的な手動検証）

自動テストが苦手とする領域もあります。前述のIDORのような認可不備は、正規の手続きの範囲で起きるため機械的な検知が難しく、業務ロジックの理解が要ります。複数の処理をまたいだ攻撃シナリオや、仕様・設計そのものに潜む問題も、攻撃者の意図を汲んだ人手の検証が有効です。

自動テストで洗い出せる範囲と、人手でなければ踏み込めない範囲を切り分けて考えると、どこまで自社で完結させ、どこから外部に委ねるかの線引きがしやすくなります。

費用の考え方（自動の実行コストと人手の診断費用）

自動と人手では、費用のかかり方が異なります。自動テストは前述の実例で約30万円という水準が示されましたが、タスク時間に応じて変動し、実行してみないと正確には見積もれません。頻度を上げて継続的に回す使い方に向いています。

一方、人手の専門ペネトレーションテストや脆弱性診断は、対象の画面数・API数・攻撃シナリオにもとづく個別見積が基本です。たとえば動的診断でおおむね30万円から、Webペネトレーションテストで60万円からといった価格を公開している事業者もあります。まとまった費用がかかる分、対象を定めて網羅的に調べ、報告書として残せるのが特徴です。

「頻度高く・手早く回す自動」と「節目でじっくり診る人手」を、目的に応じて組み合わせるのが費用対効果の面でも現実的です。

人手のペネトレーションテストの費用は、テストの種類や対象の規模によって大きく変わります。発注前に予算の当たりをつけたい場合は、対象別・規模別の料金レンジや主要ベンダーの公開価格を出典付きで整理した以下の記事が参考になります。

外部ベンダーに出すときの判断材料と報告書で見るべき点

外部の診断ベンダーに依頼する場合は、報告書の質が判断の分かれ目になります。見るべきは、検出された脆弱性に再現手順やPoC（実証コード）が付いているか、リスクの優先度が示されているか、そして直すための具体的な指針があるかといった点です。自動テストで得た検出結果を手元に持っておくと、ベンダーの報告書と突き合わせて、自動では拾えていなかった範囲を確かめやすくなります。

AWS環境に強いかどうかも重要な観点です。クラウド固有の設定やIAM、AWSサービスを踏まえた診断ができるベンダーを選ぶと、環境に即した指摘が得られます。次のセクションで、AWS環境に対応した診断・ペネトレーションテストのサービスを紹介します。

AWS環境に対応した脆弱性診断・ペネトレーションテストサービス

ここからは、AWS環境に対応した脆弱性診断・ペネトレーションテストのサービスを紹介します。自動テストの結果を受けて、クラウド設定を継続的に自動で見張るツール型と、人手でじっくり踏み込む受託診断型があり、役割が異なります。まずは主要な特徴を一覧で比較し、続いて各サービスの詳細を見ていきます。

※料金は2026年11月時点の各社公開情報にもとづきます。最新の料金は各社の資料・公式サイトでご確認ください。

1. Aikido Security（株式会社AndGo）

Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面でまとめて検査するSaaSです。開発元はベルギーのAikido Security BVで、日本では株式会社AndGoが販売窓口となり、日本語での一次対応や導入支援を担います。

AWS環境との関わりで注目したいのが、クラウド設定の誤りを検査するCSPM（クラウドセキュリティ態勢管理）です。公式のCSPMページでは、AWS・Azure・GCPなどに対応すると明記されています。外から入られる設定になっていないかを継続的に見張れるため、AWS Security Agentの結果で浮かんだクラウド側の論点を、日常的なスキャンで追いかける運用に向きます。

脆弱性が見つかったあとの修正を進めやすいのも特徴です。修正案のドラフトを作ってプルリクエストまで投げる自動修正機能があり、エディター拡張では書いている段階で危ない箇所に気づけます。

料金はスポット課金ではなく月額のサブスクリプション型で、AndGoの取扱ページではBasicが年額3,780ドル（月額5万円台から）、Proが年額7,560ドルとされています。

いずれも2026年11月時点・利用者10人までの参考価格で、請求は為替を考慮した日本円での案内となります。無料トライアルも用意されています。

2. CoWorker 脆弱性診断サービス（CoWorker株式会社）

CoWorker株式会社の脆弱性診断サービスは、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた点が特徴です。AIが膨大な検査パターンを高速に処理し、その結果を人が確かめる二段構えで、診断のスピードと精度の両立を図っています。

診断メニューは、ソースコードを読み取る静的診断、稼働中のWebアプリ・APIに実際にアクセスする動的診断、そして実際のシステムに仮想的な攻撃を仕掛けるペネトレーションテストの3本立てです。自動テストの結果を踏まえ、人手で踏み込んだ検証を依頼したいときに選択肢になります。

料金は、静的なソースコード診断が15万円から、動的診断がAPIのエンドポイント数に応じて30万円から、Webペネトレーションテストが60万円から、ネットワークペネトレーションテストが100万円からと公開されています。費用の目安が示されているため、自動テストとの費用感を比べながら依頼範囲を検討しやすいサービスです。

3. GMOサイバーセキュリティ byイエラエ（GMOサイバーセキュリティ byイエラエ株式会社）

GMOサイバーセキュリティ byイエラエは、多数のホワイトハッカーを擁するサイバーセキュリティの専門企業です。専門家による手動主体の脆弱性診断・ペネトレーションテストを中核に、累計診断件数は16,000件を超えると公表しています。自動テストでは踏み込みにくい、攻撃者視点の網羅的な検証を依頼したい場合に適しています。

診断メニューは幅広く、Webアプリケーション診断やネットワーク診断に加え、AWS・Azure・Google Cloudなどを対象としたクラウド診断を公式に提供しています。AWS環境に固有の設定やサービスを踏まえた診断を依頼できるため、本記事のテーマと親和性が高いサービスです。近年はAIエージェントを対象としたペネトレーションテストも手がけています。

手動主体の脆弱性診断・ペネトレーションテストは、診断したい画面数・API数・攻撃シナリオをもとにした個別見積が基本です。あわせて、外部公開資産を継続的に監視するツール型の「GMOサイバー攻撃ネットde診断 ASM」も提供しており、自走プランが月額4万円から、伴走プランが月額12万円からとされています（2026年11月時点）。じっくりした手動診断と継続的なツール監視を使い分けられるのが強みです。

ここで紹介した3社のほかにも、脆弱性診断・ペネトレーションテストのサービスは数多くあります。診断方法や費用相場、選び方まで含めて幅広く比較検討したい方は、以下のまとめ記事もご覧ください。

まとめ

AWS Security Agentの検出結果は、重大度バッジと信頼度の2軸で読み、CVSSメトリクスの内訳で「どういう条件で悪用されるか」を確かめるのが基本です。着手は重大・高かつ高信頼度のものから進め、偽陽性は検証スクリプトで確かめます。

直し方は、自動修復のプルリクエストや差分ファイルを使いつつ、WAFで防げるものと設計・コードの修正が要るもの（IDORなどの認可不備）を切り分けるのが要点です。

自動テストは手早く繰り返せる一方、確率的に結果が変わり、認可不備や設計の問題は見つけにくいという限界もあります。重要なシステムでは、自動の結果を土台にしながら、AWS環境に強い人手の専門ペネトレーションテストや脆弱性診断を組み合わせるのが現実的です。各社の資料で診断範囲や費用を比べ、自社に合う依頼先を検討してみてください。

よくある質問（FAQ）

Q. AWS Security Agentとは何ですか？

A. AWS Security Agentは、AIエージェントが攻撃者の視点で疑似的な侵入テストを行い、検出結果をまとめて返すオンデマンド型のペネトレーションテスト機能です。

2026年3月31日に東京リージョンを含む6つのAWSリージョンで一般提供が始まり、2026年10月には「AWS Continuum for penetration testing」へと名称を変えて、CI/CDパイプラインに組み込んでデプロイごとにテストする使い方にも広がりました。

検出結果は、重大度バッジ・エージェント信頼度・CVSSメトリクス・再現手順・自動修復のプルリクエストとともに返されます。

Q. AWSのペネトレーションテストに事前承認は必要ですか？

A. AWSは一部の対象サービスについて、事前の承認なしにペネトレーションテストを実施できるとしています。対象にはAmazon EC2・RDS・CloudFront・Aurora・API Gateway・AWS Lambda・ECS・Fargateなどが挙げられています。ただし、DoS・DDoSやポート／プロトコルのフラッディング、S3バケット乗っ取り、サブドメイン乗っ取りなどは禁止行為です。

また、Simulated Eventsやコマンド＆コントロール（C2）を伴うテストは事前申請・承認の対象で、発見した脆弱性はテスト完了から24時間以内にAWS Securityへ報告する義務があります。対象サービスや条件は随時更新されうるため、実施前に公式ポリシーで最新の内容を確認してください。

Q. AWS Security Agentの費用はどれくらいかかりますか？

A. AWS Security Agentの費用はタスク時間に応じて変動し、ある検証記事では「34.41タスク時間 × 50USD ＝ 約30万円（1,720.5 USD）」という実例が示されています。同じ検証では、エージェントが確率的に動くため、走らせる前に何タスク時間かかるかを正確に見積もる方法はないとも述べられており、費用は実行してみないと確定しにくい点に注意が必要です。

一方、人手の専門ペネトレーションテストや脆弱性診断は、画面数・API数・攻撃シナリオにもとづく個別見積が基本で、自動テストとは費用のかかり方が異なります。

Q. AWS Security Agentの結果が実行のたびに変わるのはなぜですか？

A. 検出結果が毎回変わるのは、AIエージェントが自律的に手順を考えながらテストを進めるため、毎回まったく同じテストが行われるとは限らないからです。この確率的な性質があるため、1回の結果だけで「問題なし」と決めつけるのは禁物です。複数回の実行を前提にし、気になる検出結果は検証スクリプトで手元の再現を確かめると、見落としと過剰反応の両方を抑えられます。

Q. AWS Security Agentの偽陽性（誤検知）はどう見分ければよいですか？

A. 偽陽性を見分けるには、エージェント信頼度バッジと検証スクリプトを組み合わせて確かめます。検出結果の画面は既定で信頼度の高いものだけが表示されるため、「未検証の検出結果の非表示」トグルをオフにすると、中・低信頼度の結果や誤検出も表示できます。さらに、確認済みの検出結果ごとに自動生成される検証スクリプトを自分の環境で実行すれば、本当に悪用できる脆弱性かを手元で判断できます。

ただし検証スクリプトは生成AIが作るため、実行前に内容を確認し、テストが許可されたシステムに対してのみ実行してください。

Q. AWS Security Agentのレポートは日本語で出力されますか？

A. ペネトレーションテストのレポートはPDF形式で、現時点では英語のみで出力されます（2026年3〜4月時点の検証記事で確認）。レポートはExecutive Summary（要旨）・Description（説明）・Steps to Reproduce（再現手順）・CVSS v3.1 Vector・推奨対応策といった構成です。

社内で共有するときは、英語のまま回すよりも、重大度・信頼度・再現手順・推奨対応策の4点を日本語で抜き出した要約を添えると、開発者以外の担当者にも伝わりやすくなります。言語やレポート仕様は変わりうるため、利用する時点で再確認することをおすすめします。

Q. AWS Security Agentの自動テストだけで十分ですか、人手の専門診断も必要ですか？

A. 自動テストは手早く繰り返せる強力な手段ですが、専門家による診断を完全に置き換えるものではありません。IDORのような認可不備は正規の手続きの範囲で起きるため機械的な検知が難しく、複数の処理をまたぐ攻撃シナリオや、仕様・設計そのものに潜む問題も、攻撃者の意図を汲んだ人手の検証が有効です。

頻度高く手早く回す自動テストと、節目でじっくり診る人手の診断を目的に応じて組み合わせ、重要なシステムではAWS環境に強い専門ベンダーの脆弱性診断・ペネトレーションテストを併用するのが現実的です。

AWS対応の脆弱性診断・ペネトレーションテストの資料を一括チェック

MCB FinTechカタログでは、AWS環境に対応した脆弱性診断・ペネトレーションテストサービスの最新資料を無料で一括請求できます。診断範囲や料金、サポート体制を資料でまとめて比較できます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。