AIが侵入テストする時代の見積り比較｜時間課金・上限・再検証

結論：安いかどうかではなく、何を測っているかで比べる

2026年8月19日、AWSは同社のAWS Security Agent（現在はAWS Continuumの一部）に、二つの機能を追加したと発表しました。テストごとの最大タスク時間の上限設定と、修正後の個別の指摘に対する再検証です。

このサービスは、AIエージェントがWebアプリケーションの脆弱性を自律的にテストする、オンデマンドの侵入テストサービスとして説明されています。課金は、並行して実行されるテスト全体で消費された累積のタスク時間に基づきます。

この形態が広がると、セキュリティ診断の見積りを比較する際の前提が変わります。「AIで自動化しているので安価です」という提案を受けたとき、経営者は何を確認すればよいのか。以下では、その判断軸を項目に分けます。

発表内容から確定できること

出典はAWSの発表「AWS Security Agent (now part of AWS Continuum) now supports budget controls and finding revalidation」（2026年8月19日）です。

以上は、ある事業者が提供する診断サービスの仕様です。国内のセキュリティ事業者が提供する診断と、そのまま同じ土俵で比較できるものではありません。また、発表文は具体的な時間単価や、一般的な対象で何時間かかるかを示していません。したがって「AIだから人手より安い」と金額を推定することもできません。ただし、自動化された診断に時間上限と再検証を組み込む設計は、見積り比較の前提として押さえておく価値があります。

データ処理境界を見積条件に入れる

東京リージョンを選んだから、すべての処理が日本国内で完結するとは限りません。AWSのセキュリティベストプラクティスでは、保存データは選択したリージョンに残る一方、推論のためのプロンプトと出力はリージョン間で処理され得ること、リージョン間推論は常時有効でオプトアウトできないことが明記されています。東京ではCode Remediation以外が日本、Code Remediationが欧州で処理されるという区分です。

また、組織で設定したSCPやAWS Control Towerのリージョン制限だけでは、この推論経路を止められません。対象URLへログインするための認証情報も、指定した信頼済みエンドポイントへ送信される場合があります。したがって、導入前に次の四点を書面にします。

1. データを保存するリージョンと、プロンプト・出力を処理する地域
2. Code Remediationを有効にするか。欧州処理を許容できるか
3. 到達を許可するURLと、各URLへ送信してよい認証情報
4. 自社のデータ所在地規程、委託先管理、顧客契約に抵触しないことの確認者

ここを「AWS上だから問題ない」と省略するのが、経営者が知らない落とし穴です。価格と検出範囲だけを比較しても、審査を通せない構成なら発注後に止まります。

時間課金という単位が意味すること

従来の脆弱性診断の見積りは、多くの場合「対象の数」で決まります。診断する画面の数、ドメインの数、機能の数。これに対して、今回のサービスは消費したタスク時間で課金されます。

この違いは、発注側にとって次の意味を持ちます。

費用の予測可能性が変わります。 対象数による見積りは、金額が実施前に固定されやすい方式です（追加画面や再試験、仕様変更で変動する契約もあります）。時間課金は、実施してみないと総額が分かりません。今回追加された上限設定は、この予測不能性に対する手当てです。

「深く調べる」ことの費用が見えるようになります。 時間課金では、時間をかければ費用が増えます。裏を返せば、安い見積りは短時間しか調べていない可能性がある、ということでもあります。ただし対象数による契約でも、診断の深度、テストケース、認証の有無、手法を条件に含めているものはあります。契約方式ではなく、対象範囲、深度、除外事項を並べて比較してください。

上限が調査範囲の制約になり得ます。 上限に達した時点でテストは停止し、それまでの指摘は保持されると説明されています。つまり、上限が低ければ、調べ切らないまま終わる可能性があるということです。ただし逆は成り立ちません。上限を高くすれば網羅性や品質が比例して上がる、という説明はどこにもありません。上限は品質の調整つまみではなく、費用の暴走を止める安全装置として扱ってください。

見積りを比較する際、この三点目は必ず確認してください。金額が安い提案について、上限時間または想定工数が明記されているかを見ます。明記されていない場合、何をもって「診断が完了した」とするのかを問う必要があります。

何を任せられ、どこから人の確認が要るのか

判断軸を持つために、両者の役割を分けます。ここは製品の優劣の話ではなく、責任の置き場所の話です。

まず押さえておくべき前提が二つあります。ひとつは、AWS自身が「専門の侵入テストサービスではない」と明記していること。もうひとつは、AWSの説明でも、重要なアプリケーションロジックやエンドポイントをすべて発見・テストできる保証はないとされていることです。つまり、繰り返し実行できることと、網羅できることは別です。

分かれ目は、業務の文脈と、結果の引き受けです。「この画面は営業担当者だけが見られるべきである」という前提は、システムの外側にあります。文書や認証情報として与えれば試行の材料にはなりますが、その前提自体を決めて、結果を業務判断に翻訳するのは人の側です。

したがって、実務上の使い分けはこうなります。繰り返し確認できる領域は自動化に任せ、前提の提示、結果の確認、事業影響の評価に人手を集中させる。この配分が、限られた予算で最も効果を出す形です。

自社の状況に応じた診断範囲の決め方については、セキュリティ事業の相談で、対象の絞り込みから整理できます。

再検証という機能が示す、診断の本当の課題

今回追加されたもうひとつの機能、修正後の個別再検証は、地味に見えて実務上の意味が大きい追加です。

診断を実施した企業が次に直面するのは、報告書に並んだ指摘への対応です。ここで起こり得るのが、次の状態です。

修正したはずだが、確認していない。 開発会社が「修正しました」と報告し、そのまま完了扱いになる。実際に悪用できなくなったかを確認していない。

再診断の費用が出せない。 修正の確認のために全体を再度診断すると、費用が二重にかかる。結果として確認が省かれる。

指摘と修正の対応が追えない。 報告書の指摘番号と、修正作業の記録が別々に管理され、どれが対応済みか分からなくなる。

今回の発表では、完了したテストから特定の指摘を選び、その指摘だけを再テストし、ActiveかResolvedかを返し、再検証の履歴が元の指摘に紐づくと説明されています。上の三つの課題に、それぞれ対応する内容です。

自動化されているかどうかにかかわらず、診断の価値は「見つけること」ではなく「直ったことを確認すること」で完結します。見積りを比較する際、再診断の扱いが含まれているかは重要な比較項目です。含まれていない場合、その費用と時期を別途見込む必要があります。

見積りを比較するときの十項目

自動診断、人手による診断、その組み合わせのいずれであっても、次の十項目を各社に同じ形で確認します。

業務ロジック、再検証、データ処理地域は、提案書に書かれていないことが少なくありません。価格が安いから含まれていない、と決めつける必要はありませんが、含まれているかどうかを個別に確認してから比較することが前提になります。書かれていない項目は、後から別費用または審査差し戻しの原因になります。

最後の実施条件は、軽視すると事故になります。前提として、テストしてよいのは自社が所有・管理する対象か、書面で許可を得た対象だけです。第三者のシステムへ無断で試行することは、不正アクセスやサービス妨害につながり得ます。今回のサービスでも、対象URL以外への到達を監視し、無断のテストと判断されればアカウント内の実行が停止されるとされています。

そのうえで、実施環境の原則は本番前の環境です。AWSは、負荷を抑えるガードレールを備えつつも、意図しない業務ロジックへの影響が起こり得るため、本番前の環境での実施を推奨しています。本番で実施する必要がある場合は、明示的な許可、対象範囲、停止の条件、バックアップと復旧の手順を事前に決めてください。データの変更や削除、サービスの停止、性能低下が起こり得る前提で計画します。

診断の前に済ませておくと安くなること

診断の費用は、対象の状態によって変わります。次の準備を済ませておくと、診断そのものの効率が上がり、指摘への対応も速くなります。

対象の一覧を作る。 診断してほしいシステムの画面、機能、外部との連携を書き出します。曖昧な範囲は見積りを高くします。

構成の資料を用意する。 どの言語で、どの基盤で動き、どの外部サービスと連携しているか。資料がないと、診断側の調査時間が増えます。

明らかな不備を先に直す。 サポートが終了したソフトウェア、初期パスワード、不要なアカウント。これらは診断を待たずに対処できます。診断の指摘がこれらで埋まると、本来見るべき部分に時間を割けません。

修正できる体制を確保する。 診断で指摘が出ても、修正する開発会社との契約がなければ対応できません。診断と修正をどちらが担うかを、実施前に決めておきます。

四番目が抜けている状態で診断だけを実施すると、報告書が机の上に残ることになります。日常的な脆弱性への対応と修正の段取りまで含めて体制を作る場合は、セキュリティ運用伴走の形が適します。

想定される質問

AIの自動診断だけで済ませてよいですか。 対象と目的によります。開発の途中で繰り返し確認する用途であれば、自動化の価値は高いといえます。一方、AWS自身が専門の侵入テストサービスではないと述べ、すべての重要な処理を発見できる保証はないとしている以上、結果をそのまま最終的な安全性の証明として使うことはできません。業務システムの権限設計や、取引に関わる処理の妥当性は、業務を理解した人による確認が必要です。

上限時間は何時間に設定すべきですか。 対象の規模と、これまでの診断実績によります。発表では、実際に使用された時間のみが課金されるため、上限を高くしてもテストがその時間を必要としない限り費用は増えない、と説明されています。上限は費用の暴走を防ぐ安全装置として捉えるのが妥当です。

診断結果をどう経営へ報告すればよいですか。 指摘の件数と深刻度の分布だけでは、判断材料になりません。件数に加えて、外部から到達できるものが何件か、業務が止まり得るものが何件か、修正に必要な期間と費用はどれくらいか、という三点に変換して報告してください。

診断で何も見つからなかった場合、費用は無駄ですか。 無駄ではありませんが、「何も見つからなかった」という結果の解釈には注意が必要です。対象範囲が狭かった、深さが足りなかった、という可能性を排除できません。実施した範囲と深さの条件を、結果と一緒に記録してください。

想定読者

• セキュリティ診断の見積りを複数社から取得し、金額差の理由が分からない経営者
• 過去に診断を受けたが、指摘の修正確認まで至っていない情シス担当者
• 取引先から診断の実施を求められ、範囲と費用の判断が必要な管理部門

診断の前後の組み立てを相談する

診断でつまずきやすいのは、実施そのものではなく、その後です。報告書は受け取ったが、どれから直すかを決められない。開発会社に見せたが、修正費用の見積りが高く止まっている。前回の指摘が今どうなっているか分からない。

診断の範囲を自社の状況に合わせて決める段階から相談したい場合は、セキュリティ事業の窓口で、対象の絞り込みと優先順位の整理から進められます。診断後の修正と、継続的な確認を含めた体制が必要であれば、セキュリティ運用伴走が該当します。自動診断の導入も含めてAIをどう業務へ組み込むかという観点であれば、AI導入可否アセスメントの枠組みで、適用範囲と効果の測り方まで整理できます。すでに侵害の可能性が疑われる状況であれば、診断より先にインシデント対応支援を確認してください。

過去の診断報告書をお持ちであれば、それを起点に「まだ直っていない指摘」の棚卸しから始められます。窓口は診断範囲と再検証条件のセカンドオピニオンを相談するです。

参考資料

• AWS「AWS Security Agent (now part of AWS Continuum) now supports budget controls and finding revalidation」（2026年8月19日） https://aws.amazon.com/about-aws/whats-new/2026/08/aws-security-agent/
• AWS Security Agent ユーザーガイド「Security best practices」 https://docs.aws.amazon.com/securityagent/latest/userguide/security-best-practices.html
• AWS Security Agent ユーザーガイド「Security guidance」 https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html