# AIペネトレーションテストは人間のセキュリティ診断を代替できるのか？ARTEXから考える精度・限界・導入判断 > AIペネトレーションテストは人手の診断やスキャナの代わりになるのか。攻撃に使われたARTEXの公開事例を材料に、自動化しやすい検査と難しい検査、検出率の聞き方、許可範囲と証拠、小規模SaaSの検査体制を、利益相反を明記して整理します。 - 公開日: 2026-11-03 - 著者: 友田 陽大 - タグ: セキュリティ, 脆弱性診断, AI, 認証・認可, OWASP, 発注, B2B SaaS - URL: https://tomodahinata.com/blog/ai-pentesting-artex-human-security-audit-comparison - カテゴリ: アプリ層セキュリティ - 総合ガイド: https://tomodahinata.com/blog/nextjs-supabase-application-security-guide ## 要点 - AIペネトレーションテストは、人間の診断の代替ではなく役割分担で考える。広く休まず試すのは自動化の得意分野、仕様の解釈と許可範囲と責任は人間の仕事 - 検出率・誤検知率を独立に比べた数字は、筆者が読んだ5組織の公開分析には無い。「人間の◯%の精度」という数字は根拠にならず、ベンダーに測り方を聞くのが先 - 認可の欠陥は、応答が200でも誤りかを判定する期待値（仕様）が要る。現時点で難しいとされることが多いが、期待値を与えれば自動化の範囲は広がり得る - この記事の根拠は、攻撃者による悪用事例。発注先として選べる商用のAI診断サービスは調べていない。利益相反があるため、不要な場合と無料の確認を先に示す --- ## 結論：「代替」ではなく「役割分担」で考える **AIペネトレーションテストは、人間のセキュリティ診断を丸ごと代替するものではなく、役割を分けて組み合わせるものだと考えるのが現実的です。** 少なくとも、公開されている資料から言えるのはそこまでです。 - **自動化が得意と考えられること**：公開面の資産を広く探る、既知の弱点を順に試す、失敗したら別の手を試す、これを休まず並列で行う。 - **人間が要ること**：「誰がどのデータに触れてよいか」という仕様の解釈、業務ロジックの理解、どこまで試してよいかの許可範囲の判断、結果に責任を持つこと、経営と顧客に説明できる根拠を作ること。 この記事は、CTO、情報システムの責任者、発注担当の方が、**自社にどの検査が要るか**を判断できるように書いています。 **私は、Webアプリのセキュリティ監査を有料で提供しています。** つまりこの記事には利益相反があります。そのため、(1) **無料・自力で足りる場合**を明示し、(2) AIの危険性を誇張せず、(3) 根拠のない数字は出しません。 ### この記事の限界：ARTEXは発注先の選択肢ではない 先に、範囲を限定します。この記事の根拠は、**攻撃者がARTEXを使った事例の公開報告**です。ARTEXは、あなたが発注できるサービスではありません。報告された成功や失敗は、「この技術が何をできるか」を示しますが、「発注先のAI診断が、あなたのアプリで何を見つけるか」は示しません。**商用のAI診断サービスや、各社の製品は調べていません。** したがって、特定のサービスの優劣は論じません。 ## まず、言葉を整理する この記事では次のように使い分けます（テストと評価の考え方はNIST SP 800-115が参考になりますが、用語の線引きは筆者の整理です）。 | 呼び名 | 何をするか | 目的 | |---|---|---| | **脆弱性スキャナ** | あらかじめ決まった検査を自動で流す | 既知の問題を広く、安く、同じ手順で見つける | | **脆弱性診断** | 弱点を網羅的に洗い出す（自動＋手動） | 問題の一覧と優先順位を作る | | **ペネトレーションテスト** | 目標（例：他社のデータの閲覧）に向けて、実際に侵入できるかを試す | 弱点がつながって被害になるかを確かめる | | **AIペネトレーションテスト** | 上の「次の一手」をLLMのエージェントが決める | 手順の組み立てを自動化する | | **セキュリティ監査**（私の提供するもの） | ソースコードと設定を読み、設計の穴まで確かめる | 「誰がどのデータに触れてよいか」の実装を確かめ、修正方針を出す | ARTEXの仕組みと報告された悪用は[ARTEXとは？AI自律型ペネトレーションテストの仕組み](/blog/artex-ai-pentesting-architecture-guide)にまとめています。診断の方式別の費用と選び方は、[脆弱性診断の費用・相場](/blog/web-application-vulnerability-assessment-cost-pricing-guide)と[脆弱性診断ツールの比較](/blog/web-application-vulnerability-scanner-tools-comparison-zap-burp-semgrep-guide)にあります。 ## 公開資料が示す「できること」と「できないこと」 ARTEXについて、筆者が読んだ5組織の公開分析（Google、Microsoft、AhnLab ASEC、JPCERT/CC、CrowdStrike）から**確認できる**ことです。 **できていること** - **短い指示で、侵入まで到達した例がある。** ASECの検証では、「攻撃対象に侵入してほしい」程度の指示だけで、人の介入なしに、ファイルアップロード機能から任意のプログラムの実行まで、ActiveMQ（CVE-2023-46604）では内部ホスト4台でのコマンド実行まで進みました。ただし、**意図して既知の弱点を置いた環境**での検証です。 - **速い。** GTIGの観測では、個々の実行が2〜25秒のバーストで走り、GTIGが追う特定のアクターでは、最初に侵害したアカウントから深いアクセスまで通常約4時間、最短で15分でした。 - **失敗から立て直す。** エラーを見てスクリプトを切り詰め、再実行して成功した例が記録されています。 - **業務機能の悪用の記録。** GTIGは、書き換え可能な管理者フラグ（`is_admin=true`）の悪用、他ユーザーの添付ファイルの読取りの試行、通知機能を使った一斉メール送信を記録しています。成功率や、どこまで自律的に見つけたかは不明です。 **できていない、または限定的なこと** - **成功は一様ではない。** Microsoftは、標的化の大半は成功しなかったと述べます。ただし、同じ文で、Storm-0940は多くの組織で短時間に特権的なクラウドの永続化を得たとも述べています。 - **騒がしい。** GTIGは、熟練の人間と比べて、コード実行に至る過程が試行錯誤中心で、フォレンジック上はるかに騒がしいと評価します。 - **エージェント同士が干渉した可能性。** GTIGは、複数のサブエージェントが互いに上書きし合った可能性のあるエラーを記録しています（標的側の操作の文脈です）。 **公開資料からは確かめられないこと** - **検出率と誤検知率。** 筆者が読んだ範囲では、AIによる診断の検出率・誤検知率を、人手やスキャナと独立に比べた数字は含まれていません（ASECの検証は2件の事例で、率ではありません）。**「AIは人間の◯%の精度」という数字は、現時点では根拠として使えません。** ほかの公開評価を網羅的に調べたわけではありません。 - **未知の弱点や、認可・業務ロジックの欠陥を見つける割合。** 上のGTIGの記録は事例であり、率ではありません。 - **AIで診断が安く・速くなるか。** 公開データは確認できていません。 ## 自動化しやすい検査と、難しい検査 | 検査 | 自動化のしやすさ | 理由 | |---|---|---| | 公開面の資産探索（サブドメイン、ポート、サービス） | 高い | 機械的に列挙でき、結果が客観的 | | 既知の脆弱性（CVE）の当て込み | 高い | バージョンと既知の手順が決まっている | | 設定・バックアップの露出、管理画面の公開 | 高い | ファイル名・パスの試行で見つかる | | 認証失敗の制限（ロックアウト等）の確認 | 高い | 試行して結果を見ればよい | | 注入系（SQLi、XSS、SSRFなど） | 中〜高 | パターンは体系化。ただし文脈で見落としや誤検知が出る | | **認可の欠陥（他人・他テナントのデータが見える）** | 現時点で難しいとされることが多い | 何が正しいかが、仕様にしか書かれていない（下記） | | **業務ロジックの欠陥（承認の回避、金額の改ざん、二重利用）** | 難しいとされることが多い | 業務の意図の理解が要る | | 複数ロール・複数テナントにまたがる権限設計の妥当性 | 難しい | 組織の実態との照合が要る | この表は、公開資料の観測と、一般的なテストの原理からの**筆者の見立て（2026年11月時点）**であり、公開データによる裏付けはありません。ツールの進歩で評価が変わる可能性があります。また、後述のように、**期待値（アカウントと所有関係）を与えれば、自動化できる範囲は広がり得ます。** 私の提供する監査が、この「難しい」領域を扱う、という点で、この評価には利益相反があることも念頭に置いてください。 ### 認可の欠陥が難しい理由：「期待値」が仕様にしかない 認可の欠陥は、応答が**正常に見える**ことが壁です。会社Aのユーザーが会社Bの請求書のIDを指定し、内容が200で返ったとします。HTTPとしては成功した正常な応答です。それが誤りだと判定するには、「このユーザーは会社Aに属し、会社Bのデータは見えてはならない」という**期待**が要ります。この期待は、コードではなく、業務の仕様に書かれています。 関連記事の[ARTEX型AI攻撃にWebアプリはどう備えるべきか](/blog/artex-agentic-ai-web-application-security-defense)では、登場人物（ロールとテナント）、許される操作と拒否される操作、実際の応答を表にして、29項目で確かめました。AIエージェントに他社のデータを探させる場合も、アカウントを少なくとも2つ与え、どちらが誰のデータかを教えなければ、越境の判定ができません。OWASP API Securityも、この種の欠陥（BOLA）への対策として、**認可の脆弱性を評価するテストを書く**ことを求めています。 ## 検出率・誤検知率・再現性をどう聞くか 数字が使えないなら、数字の代わりに**測り方**を聞いてください。 | 聞くこと | 見たい理由 | |---|---| | 検出率をどう測ったか（どの対象に、既知の欠陥をいくつ仕込んだか） | 独立した比較が見当たらない以上、ベンダー自身の測り方が手がかりになる | | 誤検知の扱い（人が確認してから報告するか） | 誤検知は、確認する人の時間を消費する | | 同じ対象で2回実行したら、結果は同じか | LLMの判断は非決定的。再現性が低いと、修正後の再検証が難しい | | 見つけた問題の再現手順を載せるか | 再現できない指摘は、直したか確かめられない | | 何を試して**見つからなかった**かを書くか | 「問題なし」と「試していない」は違う | | 費用に、結果の検証と報告書づくりの人手が含まれるか | 自動化の費用は下がっても、検証の費用は残る | 診断の価値は、見つかった問題の数だけでなく、「何を試して、何が無かったか」の範囲にあります。AIが毎回違う経路を通るなら、試した範囲の記録（実行ログ）が報告の根拠になります。 ## 権限・許可範囲・誤った操作のリスク 自動化された診断は、**意図しない副作用**を起こし得ます。GTIGが記録した悪用では、ARTEXがアプリケーションの通知機能に、社内の1,300人以上へテストメールを一斉送信させました。攻撃では目的に沿った行動でも、**正規の診断で起きたら、それはインシデント**です。 自動診断を使う場合（自社でも委託でも）は、少なくとも次を書面で決めます。 - **対象の所有と許可。** 自社が所有する、または書面で許可を得た対象だけ。外部SaaSや共有基盤に触れる設計は、その事業者の規約も確認する。 - **範囲と禁止事項。** 本番で触れてよい操作と、触れてはならない操作（メール送信、決済、データの削除や変更、負荷の高い操作）。 - **実施時間と、止める手順。** 異常時に誰がどう止めるか。 - **データの扱い。** 診断の過程で得た情報（認証情報、個人情報）を、LLM提供事業者の外部APIに送る設計の場合、契約と秘密保持の観点で問題がないか。 - **権限の最小化。** エージェントに与える権限とツールを絞る。OWASPがLLMアプリで言う「過剰なエージェンシー（機能・権限・自律性が過大）」は、診断用のエージェントにも当てはまります。 ARTEXの構成には、承認の手順や通信の記録があるとASECは記します。しかし、**承認のゲートが既定で何を止めるのか、無効にできるのかは、筆者は確かめていません。** 機能名ではなく、自社が決めた運用ルールと、実際に止められる手順で判断してください。 ## 証拠保全と報告書 診断の成果物は問題の一覧だけではなく、顧客や監査人に示す根拠です。 - 再現できるリクエストとレスポンス（機密は伏せた形）。 - 実施の日時、対象の範囲、使ったツールとそのバージョン。 - 試して見つからなかった項目の記録、深刻度の根拠。 - 修正後の再検証の結果。 AIによる診断を含む場合は、実行ログ（どの順で何を試したか）の保存が、再現性の穴を埋めます。 ## 現実的な検査体制：小規模SaaSの場合 「全部を外部に頼む」か「何もしない」かの二択ではありません。頻度と深さの3段で考えられます。 | 段 | 頻度 | 内容 | 担い手 | |---|---|---|---| | **常時** | 変更のたび | 依存関係の更新、秘密情報の検査、静的解析、**CIでの認可の回帰テスト** | 自社（自動） | | **節目** | 公開前、大きな変更の前 | 公開面の棚卸し、スキャナや自動ツールによる広い検査（自社の許可された環境で） | 自社＋ツール | | **独立レビュー** | 変更の大きさと、顧客の要求で決める（年1回は一つの目安にすぎない） | 認可・テナント分離・管理者の経路・設定を、設計とコードの両方から確かめる | 第三者の人間 | AIは「節目」の広い検査に使える可能性があります。ただし、**「常時」の自動テストを持たないチームがAIの診断を使っても、効果は限られます。** 見つかった問題を直し、直ったことを確かめる土台がないためです。 **外部の監査が要らない場合**：ユーザーが少なく機微なデータを預からず公開前の段階で、顧客や取引先から独立した確認も求められていない。また、「常時」の検査がまだ無いなら、監査より先に、それを自力で作るほうが費用対効果が高い。 **外部の監査を検討する価値がある場合**：複数のテナントとロールを持つB2B SaaSを本番に出す／顧客から第三者の確認の証跡を求められる／管理者、運用ツール、バッチ、外部連携といった通常の画面の外の経路がある／自分で書いたコード（特に生成AIで速く作ったもの）を自分でレビューする限界を感じている。 ## 自力で確認できること 自力の確認は、無料でできる範囲が広いです。具体的な手順は、記事2の「自力で確認できること」にまとめています（他テナントのIDが拒否されることを、変異テストで失敗することまで確かめる方法、無料OSSスキャン、20問の自己診断など）。診断ツールの使い方は[ZAP・SAST・DASTの実践](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)にあります。公開面の棚卸しでは、設定ファイル、バックアップ、管理画面、更新サーバーが出ていないか（JPCERT/CCが国内での悪用の試みを報告）を確認してください。 ## 私の提供する監査について 現行の提供範囲だけを書きます。詳細と料金は[/security-audit](/security-audit)にあります（金額は、更新で古くなるため、この記事には書きません）。 - **向いている方**：本番の顧客データを預かる前後の、SaaS・Webアプリの運営者。 - **向かない場合**：上の「外部の監査が要らない場合」に当たるとき。 - **約束しないこと**：「完全に安全」とは言いません。見つかった問題と、残るリスクを分けて報告します。 - **報告書の見本**：[/vibe-coding/sample-report](/vibe-coding/sample-report)は、公開前ライト診断の見本です（架空のアプリを題材にした、入口の段のもの）。 - **この記事の執筆について**：私はARTEXを入手・実行しておらず、診断に使ってもいません。この記事は、公開資料の読み解きと、架空のSaaSでの防御の検証に基づきます。 まず相談だけ、という場合は、30分の無料技術相談（[/contact](/contact)）もあります。 ## 判断の順番 1. 自分の対象に、何があるか（公開面と、データの種類）を知る。 2. 「常時」の自動検査と、認可の回帰テストを作る。 3. そのうえで、広い検査にAI・自動化を使うかを検討する。使う場合は、許可範囲と止める手順を先に決める。 4. 独立した人間のレビューが要るかを、上の条件で判断する。 守るべき境界を決めるのは仕様であり、その仕様を理解して責任を持つのは人間です。AIが速く試す時代でも、その順番は変わりません。