AI攻撃ツール動向

要旨

2025年から2026年初頭にかけて、AIを使ったペネトレーションテストや攻撃支援は、実験段階から実運用段階へ明確に進んだ。もっとも、現場で先に普及したのは「完全自律の万能ハッカー」ではなく、クラウド、オンプレ、ハイブリッド環境を対象に、攻撃経路を継続的に検証する autonomous pentest、security validation、breach and attack simulation、autonomous purple team である。¹²³

一方で、攻撃側のAI活用も2025年に質が変わった。2025年初頭の時点では、生成AIは脅威アクターの調査、コード補助、翻訳、文面生成など「生産性向上」が中心とみられていたが、2025年後半には、実行中にLLMを呼び出すマルウェアや、AIが作戦の大半を担う諜報活動が公表されている。⁴⁵⁶

防御側もAIを使った検知、封じ込め、修復優先度付けを進めており、標準化もNISTやCISAで進展している。ただし、防御側は「AIを使って守る」点では前進したものの、「AIそのものを安全に運用する」「jailbreakや悪用を抑える」点ではなお過渡期にある。⁷⁸⁹¹⁰

記事プロット

• 問い: AIによるペネトレーションテストは、どこまで現場配備されているのか。攻撃側はどこまでAIで自動化し、防御側はどこまで追いついているのか。
• 主要な結論: 現場で普及しているのは「AIペンテスタ」そのものというより、「継続的な攻撃経路検証を自動化する仕組み」である。特にクラウドでは IAM、Kubernetes、アプリからクラウドへの横断経路、オンプレでは Active Directory、資格情報、横展開が主戦場になっている。^1112131415
• 転換点: 2025年前半は AI が攻撃者の作業を速める補助輪だったが、2025年後半には AI を実行時に組み込んだマルウェアや、AIが大部分を担う攻撃運用が確認され、「補助」から「実働」へ一歩進んだ。⁴⁵⁶
• 対抗軸: 防御側は AI を使って SOC、検知、対応、修復優先度付けを高速化しているが、同時に AI システム自体の安全性、データ保護、情報共有の運用基盤も整備しなければならない。^7168917
• この記事の落としどころ: 2026年時点での本当の論点は、「AIがゼロデイを自律生成するか」よりも、「既知の弱点、認証、設定不備、クラウド権限、検知の遅れ」をどれだけ高速に連鎖できるか、その速度に防御運用が追いつけるかにある。¹⁶⁷

はじめに

AIによるペネトレーションテストという言葉は、誇張を含んだ宣伝文句としても使われやすい。そこでまず整理すべきなのは、2026年3月時点で現場に入っている製品群の多くが、古典的な「年1回の手動ペネトレーションテスト」を丸ごと置き換えるものではなく、継続的な攻撃経路検証を自動化し、実際に exploitable な経路だけを見つけて潰すための仕組みだという点である。¹²

この整理は重要だ。なぜなら、AI攻撃ツールの議論はしばしば「完全自律のAIハッカーはいつ登場するか」に寄りがちだが、現場で先に価値を出したのは、もっと地に足のついた領域だったからだ。クラウド、オンプレ、ハイブリッドの環境で、侵入経路、権限昇格、横展開、資格情報の悪用、クラウドとオンプレのまたがりを、継続的に再現する仕組みが先に商品化された。¹¹¹²¹⁵

1. いま市場でいう「AIペネトレ」とは何か

1.1. 実態は「継続的な攻撃経路検証」の自動化

Horizon3.ai の NodeZero は、自社を Autonomous Pentesting と位置づけ、オンプレ、クラウド、ハイブリッド全体で無制限にペンテストを回し、弱点の発見から修復確認までをつなぐ構成を打ち出している。¹内部ペンテストの説明でも、対象として on-premises infrastructure、cloud infrastructure、identity and access management infrastructure、data infrastructure、virtual infrastructure を明示している。¹¹

Pentera も同様で、前面に出しているのは「AI-powered security validation」である。Pentera Core は内部ネットワーク向け、Pentera Cloud はクラウド向けで、単発の診断よりも attack kill chain と root cause の可視化、分散環境の一元オーケストレーション、修復後の再検証に重心がある。¹⁴¹⁵²

ここから見えるのは、AIペネトレ市場の主語が「LLMが人間ハッカーを代替する」ことより、「攻撃者目線の検証を高頻度で回し続ける」ことへ移っているという事実である。

1.2. オンプレ、クラウド、ハイブリッドで論点が違う

オンプレでは、依然として Active Directory、資格情報、権限委任、横展開、RMM や既存管理基盤の悪用が中心である。Horizon3.ai は2025年8月に、NodeZero が GOAD を14分で完全攻略したと公表し、AD環境での自律攻撃をベンチマークとして前面化した。¹⁸

クラウド側では、IAM の過剰権限、クラウド資産の列挙、Entra ID や AWS 上での権限昇格、Kubernetes の設定不備、秘密情報の露出、アプリからクラウドへのピボットが主戦場である。NodeZero のクラウド説明は AWS、Azure、Kubernetes を明示し、on-prem and the cloud をまたぐピボットを売りにしている。¹²Kubernetes 向けの説明でも、EKS、GKE、AKS、vanilla Kubernetes を対象に、RBAC misconfiguration、container escape、secret exposure を挙げている。¹³

Pentera Cloud も、cloud-native attack vectors の検証だけでなく、cloud and on-premises をまたぐ攻撃経路の発見を前面に出している。¹⁵つまり、クラウド単体の設定診断ではなく、ハイブリッド全体の攻撃パス検証が、すでに商用製品の標準機能になりつつある。

2. ツールの現場調査

2.1. オンプレとハイブリッドでは NodeZero と Pentera が先行

Horizon3.ai は、もっとも分かりやすく「autonomous pentest」を商品名として前面化しているベンダーの一つである。内部、外部、クラウド、Kubernetes、Web アプリとモジュールが分かれており、ひとつの足掛かりからドメイン侵害や機密データ到達までをつなげる思想が一貫している。^11121913

Pentera は、用語としては automated security validation を強く使う。これは見方を変えると、LLMの派手さよりも、実運用と購買に耐える表現へ寄せたとも言える。内部ネットワーク向けの Core、クラウド向けの Cloud、全体統制向けの Platform という構造からも、現場で買われているのが「AIそのもの」ではなく「攻撃者目線の継続検証プロセス」だと分かる。¹⁴¹⁵²

2.2. クラウド特化は「自律レッド」より「自律パープル」

Skyhawk は、AWS、Azure、Google Cloud 向けに Autonomous Purple Team を掲げ、検知、攻撃シミュレーション、レスポンスまでをつなぐ。³²⁰特に特徴的なのは、Red Team-as-a-Service を agentless、digital twin、no business impact で訴求している点で、本番を止めずにクラウドの防御コントロールを継続検証する文脈が強い。²¹²²

ここから分かるのは、クラウドでは「侵入できるか」だけではなく、「既存の検知・封じ込めが効くか」「クラウド運用の速さに防御モデルが追随できるか」が同じくらい重要だということである。オンプレの古典的なレッドチームとは、評価軸自体が少し違う。

2.3. アプリ/API領域は XBOW のような高速周回型が伸びる

XBOW は、hundreds of AI agents working in parallel を掲げ、何千という短命エージェントでアプリケーションの攻撃面を探索し、確証の取れた結果だけを返す構成を説明している。²³²⁴この設計は、クラウドインフラ全体を長時間攻略するタイプより、Web アプリや API をリリースのたびに深く回す用途に向いている。

2026年のアプリ開発現場では、AIコーディング支援でコード生成速度が上がる一方、従来型の年数回の手動診断では追いつかなくなる。XBOW が「development speed」「hours or days」を強く押し出しているのは、この現場事情を正面から取りに行っているからだ。²³²⁵

2.4. Dreadnode は「完成品」より「攻撃エージェント基盤」

Dreadnode は、すぐ使える単一のAIペネトレ製品というより、セキュリティエージェントの開発、評価、最適化、観測基盤を提供するポジションに近い。公式サイトでも、Build, evaluate, and deploy security agents と、Advanced AI red team capabilities を前面に出している。²⁶

2026年2月には、Active Directory 向けに合成訓練データを作る Worlds を公表し、実ネットワークを大量に立てずに agentic pentesting を訓練する方向性を示した。²⁷これは、今後のAI攻撃ツールが「大きな汎用モデルをそのまま使う」より、「小型モデルや専門エージェントを業務ドメイン向けに育てる」方向へ進む可能性を示している。

2.5. 研究の基準線としての PentestGPT

学術面では、USENIX Security 2024 の PentestGPT が重要な基準線になっている。ここで示されたポイントは、LLMは個別サブタスク、たとえばツール操作や出力解釈はこなせても、長い攻撃シナリオ全体の文脈維持は苦手だということだった。²⁸

この論点は2026年でも生きている。商用製品の多くが、単一の長寿命エージェントではなく、短寿命の並列エージェント、決定論的なバリデータ、既存ツール群のオーケストレーションに寄せているのは、研究段階で露わになった弱点への現実的な回答でもある。²⁴²⁷

2.6. 実際の導入から利用までの流れ

2.6.1. 共通して最初に決めること

AIペネトレ系ツールの導入で、最初に詰めるべきなのはモデル選定ではない。まず決めるべきは、(1) 何を攻撃対象にするか、(2) どこまで壊してよいか、(3) どういう認証情報を与えるか、(4) どの通信を allowlist するか、(5) 結果を誰が triage するか、である。これは人間のペンテストでも同じだが、AI系ツールでは「反復回数が多い」「並列に動く」「継続実行される」分、先にルールを固めないと運用事故になりやすい。²⁹³⁰³¹

技術者視点では、最低限次の前提を揃える必要がある。

• スコープ定義: 攻撃可能なドメイン、ネットワーク、クラウドアカウント、クラスター、除外対象を明文化する。³²³³
• 認証設計: ブラックボックスで行くのか、グレーボックスでテストアカウント、TOTP、Bearer Token、クラウド資格情報を渡すのかを決める。³⁴³²
• 到達性: SaaS型ならベンダー側IPの allowlist、内部配置型なら Docker Host や Operator からの outbound 通信先を確認する。³⁵³⁶³⁰
• 安全装置: パスワード変更、送金、アカウント削除、外部連携呼び出しのような不可逆操作は、Blocked URL や auth-only の形で制御する。³¹
• 受け皿: findings を誰が受け、どの SLA で直し、いつ retest するかまで決めておく。

2.6.2. オンプレ/ハイブリッドでの典型フロー

公開ドキュメントが最も細かいのは NodeZero である。Horizon3.ai の Quickstart では、最初の内部ペンテストに必要なものとして、アカウント作成、ネットワーク前提確認、NodeZero Host の準備、内部ペンテスト実行を順番に案内している。²⁹

内部向けの典型フローを要約すると、次の通りである。

1. 実行基盤を置く: 内部ネットワーク内に Docker Host を用意する。NodeZero Host の公開要件では、Ubuntu 18.x/20.x 以上、Docker 20.10 以上、最低 2 CPU、8GB RAM、40GB 空き容量が示されている。³⁵
2. スコープを切る: Portal で Internal Pentest を作成し、対象ネットワーク、必要なら AWS Accounts、Open-Source Intelligence、Tripwires、Attack configuration、Duration、Runner を設定する。³²
3. 実行する: 手動なら Docker Host 上で launch script を実行する。CLI ドキュメントでは h3 run-nodezero で直近の内部ペンテストを起動できる。³⁷
4. 自動化する: 手動 SSH を避けるなら NodeZero Runner を常駐させる。Runner は新規ペンテストを検知して NodeZero コンテナを自動起動でき、定期実行にも使える。³⁸³⁹
5. 観測と remediation: Portal でリアルタイム監視し、攻撃経路、到達資産、root cause を見て修復し、再実行で確認する。³²¹

この構成の要点は、攻撃エージェント本体を企業内の Docker Host に寄せつつ、制御面は SaaS で行う点にある。したがって、ネットワーク分離が強い環境では、どこに Host を置くか が最初の設計論点になる。

2.6.3. Kubernetes では Operator 常設型になる

Kubernetes 向けはさらに分かりやすい。NodeZero は、まず Operator をクラスタに 1 回入れ、その後に Runner や個別の pentest を走らせるモデルを取っている。³⁶

公開ドキュメント上の流れはこうだ。

1. kubectl と helm を使える端末を用意する。
2. クラスタ側から Horizon3.ai Gateway への 443/TCP outbound を許可する。³⁶
3. NodeZero Operator をクラスタにインストールする。³⁶
4. 必要なら Kubernetes Runner を入れる。³⁶
5. Portal から Kubernetes Pentest を起動し、Scope、Attack configuration、Runner、Kubernetes settings を選ぶ。³⁶

この方式は、Kubernetes では「攻撃者が pod や kubeconfig を足掛かりに内部へ入った後」を再現しやすい。逆に言えば、IaC や static scanner では見えにくい 実行時の権限連鎖 を見たいときに向く。

2.6.4. Webアプリ/API向けの典型フロー

XBOW は docs が比較的公開されており、技術者向けの利用フローが読みやすい。XBOW の対象は現時点では interactive web applications and their APIs であり、API単体だけを直接狙う前提ではない。⁴⁰⁴¹

公開ドキュメントに基づく実運用フローは次の通りである。

1. ターゲット適合性を確認する: 対象は Web アプリとその API、Chrome ベースの動作を前提とし、認証が必要なら XBOW が扱える方式でログインできる必要がある。⁴¹⁴⁰
2. テストアカウントを用意する: 十分な権限と現実的なデータを持つアカウントを準備し、必要なら MFA も TOTP やメール OTP で通せるようにする。⁴¹³⁴
3. 到達性を作る: Firewall/WAF に XBOW の送信元 IP またはホスト名を allowlist する。³⁰
4. 文脈を渡す: Source code や documentation、assessment guidance を与えて、狙うべき攻撃面や重点領域を伝える。³⁴⁴²
5. 危険な URL を止める: Password reset、account deletion、payment、外部連携などは auth-only または blocked URL にする。³¹
6. 実行形式を選ぶ: 全面評価、特定カテゴリ集中、再テストを選び、UI か API で assessment を起動する。⁴³⁴⁴
7. 結果を見る: XBOW は exploitability を確認した findings だけを返す設計なので、まず severe/high を修正し、その後 retest を回す。²⁴⁴³

実務上は、AIエージェントの質よりも テストアカウントの質 と URL 制御の質 が結果を大きく左右する。認可バグやビジネスロジック系は、アカウント権限やテストデータが貧弱だと深く入れないからだ。

2.6.5. Pentera系は「継続運用ループ」として入れるのが本筋

Pentera の細かな管理画面手順は公開ドキュメントだけでは追い切れないが、公開されている product page と datasheet から見る限り、導入思想は明快である。最初に一度デプロイし、資産をマップし、production-safe な attack emulation を回し、kill chain と root cause を見て remediation し、再検証するループが中心である。^1415452

これは公開資料からの推定だが、Pentera を年1回のイベントとして使うより、変更の多い環境で test-remediate-repeat に乗せる方が製品の思想に合っている。Pentera 自身も、従来の occasional pentest ではなく weekly 以上の高頻度 testing を訴求している。⁴⁶

2.7. OSSでそのようなツールはあるか

結論から言うと、ある。ただし、何を攻撃したいのか で OSS の選択肢は大きく分かれる。

• 従来の Web / インフラ / CTF 寄りの自動化補助: PentestGPT 系
• AIシステム自体のレッドチーミング: garak、PyRIT、promptfoo、Counterfit、ART 系
• Kali 上で道具をつなぐ構成: MCP + 汎用 LLM agent + 既存 pentest toolchain

2.7.1. 従来システム向けでは PentestGPT が代表例

PentestGPT は現在も OSS として公開されており、README では research prototype only と明示した上で、Docker-first の agentic pipeline、session persistence、local LLM routing を備えている。⁴⁷

技術者向けには、使い方が比較的明快である。

1. リポジトリを clone し、make install で Docker イメージを作る。⁴⁷
2. make config で API key または local LLM 接続を設定する。⁴⁷
3. make connect でコンテナに入る。⁴⁷
4. pentestgpt --target <target> でターゲットを指定して実行する。⁴⁷
5. 必要なら benchmark を起動して再現環境で試す。⁴⁷

重要なのは、PentestGPT は「そのまま企業本番に常設して回す完成品SaaS」ではなく、研究寄りの自律ペンテストエージェントだという点だ。実験、ラボ、HTB/THM、社内検証環境、限定スコープの評価には向くが、商用製品のようなワークフロー統合、監査証跡、セーフティ制御は自分で補う必要がある。

2.7.2. AIシステムそのものを攻撃する OSS はむしろ充実している

AIアプリ、RAG、Agent、基盤モデルのセキュリティ検証では、OSSはかなり充実している。

• garak: NVIDIA の LLM vulnerability scanner で、prompt injection、data leakage、jailbreak、hallucination などを probe / detector 方式で検査する。⁴⁸
• PyRIT: Microsoft AI Red Team の OSS で、target、converter、scorer、orchestrator を組み合わせて multi-turn red teaming を行う。Docker / pip / uv の導入経路が整っている。⁴⁹⁵⁰⁵¹
• promptfoo: 宣言的設定と CI/CD に強い。LLM app、agent、RAG の red teaming と vulnerability scanning をローカル中心で回せる。⁵²
• Counterfit: Azure の OSS で、ML モデル向けの adversarial attack automation layer。TextAttack や ART などを束ねる役割を持つ。⁵³⁵⁴
• ART: Linux Foundation AI & Data Foundation 傘下の Adversarial Robustness Toolbox で、evasion、poisoning、extraction、inference まで含む ML security library。⁵⁵

ここでの重要な見分け方は、これらの多くが 社内ITを攻撃するツール ではなく、AIシステムを評価するツール だという点である。ユーザーの質問にある「AIによるシステム攻撃ツール」と「AIシステムへの攻撃ツール」は似て見えるが、技術スタックも導入先も違う。

2.7.3. OSSの成熟度はかなり差がある

技術者視点では、OSS を次の3段階に分けて見ると実務判断しやすい。

• すぐ業務に乗せやすい: garak、promptfoo、PyRIT のように、対象、評価軸、入出力、レポートが比較的整理されているもの。⁴⁸⁴⁹⁵²
• 研究・検証向け: PentestGPT のように、実際に動くが研究プロトタイプ色が強いもの。⁴⁷
• 自前統合前提: Kali 上で MCP と既存ツールをつないで agent 化する構成。柔軟だが、監査、再現性、権限制御、証跡は自分で設計する必要がある。⁵⁶⁵⁷⁵⁸

したがって、OSS で始めるなら、最初から「自律ハッカー」を狙うより、限定スコープ + 証跡保存 + 人間レビュー前提 で使う方が安全である。

2.8. Kali Linux の AI 対応動向

2026年3月29日時点での Kali の動きはかなり明確である。Kali は「AI内蔵の自動攻撃OS」へ一足飛びに進んだのではなく、MCP サーバ + 汎用AI agent + 既存攻撃ツール をつなぐ基盤を公式に整え始めている。^56595857

2.8.1. 公式に見える主軸は MCP 化

Kali 公式ツールページには、mcp-kali-server が掲載されており、説明では Claude Desktop や 5ire のような MCP client を、Linux terminal 上の nmap、nxc、curl、wget、gobuster などへ橋渡しし、AI-assisted penetration testing を可能にするとしている。⁵⁶

さらに、metasploitmcp も公式パッケージとして入り、Metasploit Framework を MCP 経由で触れる構成が提供されている。⁵⁹

これはかなり重要で、Kali のAI対応は「Kali専用の魔法の自律エージェント」より、「既存の toolchain を AI client から安全に呼ぶ制御面」を先に標準化していると読める。

2.8.2. 2026年2月から3月にかけて、公式ブログで LLM 連携が具体化した

Kali 公式ブログは、2026年2月25日に Claude Desktop + Sonnet 4.5 + mcp-kali-server の構成を、2026年3月10日にはローカル Ollama + 5ire + mcp-kali-server の完全ローカル構成を紹介している。⁵⁸⁵⁷

ローカル構成の記事では、実際の流れとして次を案内している。

1. Kali に mcp-kali-server と既存の pentest ツール群を入れる。⁵⁷
2. kali-server-mcp で API server を起動する。⁵⁷
3. mcp-server で MCP bridge を起動する。⁵⁶
4. Ollama でローカルモデルを動かす。⁵⁷
5. 5ire のような MCP client から自然言語で指示し、nmap などのツールを呼ぶ。⁵⁷

つまり、Kali の最新トレンドは agentic shell for Kali と言った方が近い。AI が Kali の各ツールをまとめて操作するが、実処理は依然として nmap、sqlmap、Hydra、Metasploit といった既存ツールが担う。

2.8.3. 汎用AI agent も Kali パッケージに入り始めている

Kali の公式ツール一覧には gemini-cli も入り、2026年3月2日更新のツールページでは gemini mcp や extensions 管理を持つ汎用 AI agent として紹介されている。⁶⁰

ただし、これは offensive security 専用ツールではない。Kali 側がやっているのは、汎用 agent を Kali のツール群に接続しやすくしていることであって、gemini-cli 単体が自律ペネトレ製品になる わけではない。

2.8.4. まだ「公式の完成品AIペネトレ」はない

この点は誤解しやすい。2026年3月時点で、Kali 公式に存在するのは MCP bridge、Metasploit MCP、generic AI CLI、ブログでの連携手順である。商用製品の XBOW や NodeZero のような、統合SaaSとしての exploit-validated autonomous pentest が Kali にそのまま入っているわけではない。^5659241

補足として、Kali bug tracker には 2026年2月24日に Calcium - AI-assisted pentesting workflow tool の新規ツール申請が出ており、2026年2月26日時点では open status だった。⁶¹これはコミュニティ側の関心は高いが、まだ標準パッケージ化の途中段階だということを示している。

3. 攻撃側はどこまで進んだか

3.1. 2025年前半までは「生産性向上」が中心だった

Google Threat Intelligence Group は、2025年1月29日の時点で、脅威アクターによる Gemini の利用は主に調査、トラブルシュート、コンテンツ作成、翻訳やローカライズであり、novel capabilities はまだ観測されていないと整理していた。⁴

この時点の見立ては重要である。2025年初頭の現実は、「AIが新種のサイバー攻撃を即座に大量生成している」というより、「攻撃者の雑務、調査、初期コード作成を速めている」だった。つまり、脅威の本質は能力の魔法的な飛躍ではなく、攻撃準備の速度上昇にあった。

3.2. 2025年後半に「実働化」が見え始めた

ところが、同じ Google GTIG は2025年11月6日に、状況が一段進んだことを報告した。そこでは、PROMPTFLUX、PROMPTLOCK、PROMPTSTEAL、QUIETVAULT のように、実行中に LLM を呼び出してコードを変形したり、コマンド生成や秘密探索を行うマルウェア群を列挙している。⁵

同レポートはこれを first use of "just-in-time" AI in malware と位置づけ、違法AIツール市場の成熟にも言及した。⁵ここでの本質は、AIが「攻撃者の相談相手」から、「マルウェアの一部として実行時に呼び出されるコンポーネント」へ移り始めたことである。

Anthropic も2025年11月13日、Claude を jailbreak して諜報キャンペーンに使った事例を公表し、標的組織の偵察、脆弱性の調査と exploit code 作成、資格情報の収集、データ分類、文書化まで、AIが 80-90% を担ったと説明した。⁶単一ベンダー観測である点は割り引く必要があるが、「AI主導の長時間攻撃運用」はすでに仮説ではなく、確認事例が出てきた。

3.3. モデル能力の地力も上がっている

UK AISI の Frontier AI Trends Report は、2025年12月18日時点で、サイバー評価におけるモデル性能が急速に伸び、見習いレベルのタスク成功率が2024年初頭の1割弱から5割程度まで上がったこと、2025年には expert-level task を完了できるモデルが初めて現れたことを報告している。¹⁰

この評価は、実運用マルウェアの観測とは別軸だが重要である。なぜなら、攻撃側がAIを使いこなすかどうか以前に、そもそもモデルのタスク遂行能力が上がっており、補助輪なしでも扱える工程が増えているからだ。

4. 防御側は追いついているか

4.1. 追いついているのは「検知と対応の高速化」

Microsoft Digital Defense Report 2025 は、攻撃者がAIを使って phishing を拡大し、AI-driven phishing は従来型より3倍効果的になっている一方、防御側もAIで fraud を大規模にブロックし、応答時間を hours から minutes に短縮していると整理した。さらに、複数の高リスク信号がそろえば AI agent が seconds でアカウント停止やパスワードリセットを行えるとしている。⁷

CrowdStrike の 2026 Global Threat Report も、2025年の平均 eCrime breakout time は29分、最速は27秒、AI-enabled adversaries は前年比89%増とし、速度の論点を強調している。¹⁶ここから導かれる実務的な示唆は、今後の防御は「より正確に見つける」だけでは不十分で、「どれだけ早く止められるか」が同格のKPIになるということだ。

4.2. 追いついていないのは「AIそのものの安全運用」

AIを守る側の制度設計も進みつつある。NIST は2025年12月16日、Cyber AI Profile の初期案で Secure、Defend、Thwart の3本柱を提示し、AIシステム自体の保護、AIを使った防御、AIを使った攻撃への耐性を一体で扱い始めた。⁸

CISA も2025年1月14日に AI Cybersecurity Collaboration Playbook を公開し、AIに関するインシデントや脆弱性情報の共有プロセスを整理した。さらに2025年5月22日には、AI の学習と運用に使うデータを守るためのベストプラクティスを公表している。⁹¹⁷

ただし、制度整備が進む一方で、モデル自体の safeguards はまだ脆い。AISI は2024年5月時点で、公に使える主要モデルが基本的な jailbreak に高く脆弱だと報告し、2025年の Trends Report でも、評価した全システムに universal jailbreak が見つかったと整理している。⁶²¹⁰

4.3. モデル提供側もアクセス制御を強め始めた

モデルベンダーも、防御用途への優先提供と misuse 抑制を両立しようとしている。OpenAI は2026年2月5日、Trusted Access for Cyber を公表し、高能力モデルが hours or even days 自律動作できることを踏まえ、信頼ベースのアクセス枠組みで防御用途を促進すると説明した。⁶³

これは逆に言えば、モデル提供側自身が「サイバー能力の上昇は防御を強くするが、同時に misuse リスクも高める」と認識しているということでもある。

5. クラウドとオンプレで見方を分けるべき理由

クラウドでは、攻撃者も防御側も、設定変更、権限変更、デプロイが極端に速い環境で戦う。したがって、価値が高いのは「年1回の診断」より、「継続的な attack path validation」と「検知・レスポンス検証」である。Skyhawk が autonomous purple team を、Horizon3.ai と Pentera がクラウドからオンプレへのまたがりを前面に出すのは、この事情を反映している。^3211215

オンプレでは、依然として AD、資格情報、横展開、既存サーバ資産の組み合わせが強い。Dreadnode が Active Directory 向けのシミュレーション学習を前面に出し、Horizon3.ai が GOAD 攻略を強調するのは、オンプレ攻撃の核心が今も AD と権限連鎖にあることを示している。²⁷¹⁸

そして現実の多くの企業環境は、どちらか片方ではなくハイブリッドである。したがって、本当に危ないのは「クラウドの単発設定不備」でも「オンプレの単独脆弱性」でもなく、その両者がつながった attack path である。

6. 実務的な見立て

2026年時点で、AIによるペネトレーションテストや攻撃ツールの進化をどう見るべきか。結論を短く言えば、次の3点に集約できる。

• 第一に、実運用で勝っているのは「完全自律のAIハッカー」ではなく、「継続的な攻撃経路検証の自動化」である。購買されている製品は、攻撃の美しさより、再現性、頻度、修復確認、ワークフロー連携で勝負している。¹²²⁴
• 第二に、攻撃側のAI活用は、2025年を通じて 生産性向上 から 部分自律化 へ進んだ。まだ全面自律が常態とは言えないが、偵察、コード生成、権限昇格補助、データ分類、マルウェア変形といった工程は確実にAI化が進んでいる。⁴⁵⁶
• 第三に、防御側は AI でトリアージ、封じ込め、優先度付けを高速化しているが、AIシステム自体の安全性、データ保護、情報共有、jailbreak耐性の整備はまだ道半ばである。⁷⁸⁹¹⁰

したがって、企業の実務としては、AI攻撃の脅威を「未来のSF」ではなく、すでに始まっている速度問題として捉えるのが適切である。対策の中心は、AI製品を一つ買って安心することではない。認証、権限、クラウド設定、検知、対応時間、修復再検証を、AI時代の速度に合わせて組み替えることである。

まとめ

AIペネトレ市場は、派手な宣伝ほどには「完全自律のAIハッカー」にはなっていない。しかし、そのことは脅威が小さいことを意味しない。むしろ危険なのは、既知の弱点、資格情報、設定不備、クラウド権限、アプリの足掛かりを、AIが人間より速く、安く、繰り返し連鎖できるようになったことである。¹⁶⁵

防御側もAIで前進しているが、いま必要なのは「AIを導入すること」そのものではなく、AIを前提にセキュリティ運用を再設計することだ。クラウドでもオンプレでも、勝負はゼロデイの有無より、攻撃経路をどれだけ早く見つけ、どれだけ早く潰し、どれだけ確実に再検証できるかに移っている。⁷²¹

参考資料（出典）

Footnotes

1. Horizon3.ai, The NodeZero Platform。NodeZero を Autonomous Pentesting と位置づけ、継続的なリスク検証と修復確認を説明。https://horizon3.ai/nodezero/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. Pentera, Pentera Platform。分散環境の一元オーケストレーションと remediation workflow を説明。https://pentera.io/platform/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Skyhawk Security, Home。Autonomous Purple Team による継続的な分析、attack simulation、validated detection を説明。https://skyhawk.security/ ↩ ↩² ↩³

4. Google Threat Intelligence Group, Adversarial Misuse of Generative AI（2025/01/29）。脅威アクター利用は当時、主に調査、コード補助、文面作成などで、novel capabilities は限定的と評価。https://cloud.google.com/blog/topics/threat-intelligence/adversarial-misuse-generative-ai ↩ ↩² ↩³ ↩⁴

5. Google Threat Intelligence Group, GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools（2025/11/06）。実行時に LLM を呼ぶマルウェアや違法AIツール市場の成熟を報告。https://cloud.google.com/blog/topics/threat-intelligence/threat-actor-usage-of-ai-tools ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign（2025/11/13）。AIが攻撃作戦の 80-90% を担ったとする事例を公表。https://www.anthropic.com/news/disrupting-AI-espionage ↩ ↩² ↩³ ↩⁴

7. Microsoft, Microsoft Digital Defense Report 2025。AI-driven phishing の増加、防御側の AI 活用、AI agent による自動対応を整理。https://www.microsoft.com/en-us/security/security-insider/threat-landscape/microsoft-digital-defense-report-2025 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

8. NIST, Draft NIST Guidelines Rethink Cybersecurity for the AI Era（2025/12/16）および Cybersecurity Framework Profile for Artificial Intelligence (NIST IR 8596)。Secure、Defend、Thwart の3本柱を提示。https://www.nist.gov/news-events/news/2025/12/draft-nist-guidelines-rethink-cybersecurity-ai-era https://csrc.nist.gov/pubs/ir/8596/iprd ↩ ↩² ↩³ ↩⁴

9. CISA, AI Cybersecurity Collaboration Playbook（2025/01/14）。AIに関するインシデント、脆弱性、情報共有の運用枠組みを提示。https://www.cisa.gov/resources-tools/resources/ai-cybersecurity-collaboration-playbook ↩ ↩² ↩³ ↩⁴

10. AI Security Institute, Frontier AI Trends Report（2025/12/18）。サイバー能力の急伸と、tested systems 全体での jailbreak 脆弱性継続を整理。https://www.aisi.gov.uk/frontier-ai-trends-report ↩ ↩² ↩³ ↩⁴

11. Horizon3.ai, Continuous Internal Pentesting。内部ペンテスト対象としてオンプレ、クラウド、IAM、データ、仮想基盤を明示。https://horizon3.ai/nodezero/internal-pentesting/ ↩ ↩² ↩³ ↩⁴

12. Horizon3.ai, Cloud Pentesting with NodeZero。AWS、Azure、Kubernetes と、オンプレとクラウドをまたぐピボットを説明。https://horizon3.ai/nodezero/cloud-pentesting/ ↩ ↩² ↩³ ↩⁴ ↩⁵

13. Horizon3.ai, Kubernetes Pentesting。EKS、GKE、AKS、vanilla Kubernetes と、RBAC misconfiguration、container escape、secret exposure を説明。https://horizon3.ai/nodezero/kubernetes-pentesting/ ↩ ↩² ↩³

14. Pentera, Pentera Core。内部ネットワーク向け security validation と attack kill chain 可視化を説明。https://pentera.io/pentera-core/ ↩ ↩² ↩³ ↩⁴

15. Pentera, Pentera Cloud。cloud-native attack testing と cloud / on-premises 横断経路の検証を説明。https://pentera.io/pentera-cloud/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

16. CrowdStrike, 2026 CrowdStrike Global Threat Report: AI Accelerates Adversaries and Reshapes the Attack Surface（2026/02/24）。AI-enabled adversaries 89%増、平均 breakout time 29分を報告。https://www.crowdstrike.com/en-us/press-releases/2026-crowdstrike-global-threat-report/ ↩ ↩² ↩³ ↩⁴

17. CISA, AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems（2025/05/22）。AI学習・運用データの保護と監視のベストプラクティスを整理。https://www.cisa.gov/resources-tools/resources/ai-data-security-best-practices-securing-data-used-train-operate-ai-systems ↩ ↩²

18. Horizon3.ai, NodeZero Becomes First AI to Fully Solve Game of Active Directory (GOAD)（2025/08/14）。GOAD を14分で完全攻略したと公表。https://horizon3.ai/news/press-release/horizon3-ais-nodezero-becomes-first-ai-to-fully-solve-game-of-active-directory-goad/ ↩ ↩²

19. Horizon3.ai, Autonomous Web Application Pentesting。認証後のアプリ悪用から cloud / on-prem host compromise までの実攻撃経路を訴求。https://horizon3.ai/web-application-pentesting/ ↩

20. Skyhawk Security, Continuous Autonomous Purple Team for AWS, Azure, and Google Cloud。クラウド向け AI-driven purple team を説明。https://skyhawk.security/ctem-purple-team-2/ ↩

21. Skyhawk Security, Red Team-as-a-Service。agentless、digital twin、no business impact を訴求。https://skyhawk.security/red-team-as-a-service/ ↩ ↩²

22. Skyhawk Security, Strengthens Autonomous Red Team with Agentic AI（2025/12/02）。agentic AI による継続的 security control validation を公表。https://skyhawk.security/skyhawk-security-strengthens-autonomous-red-team-with-agentic-ai-enabling-continuous-security-control-validation/ ↩

23. XBOW, AI-powered penetration testing platform。並列AIエージェント、on-demand pentesting、80x faster を訴求。https://xbow.com/ ↩ ↩²

24. XBOW, How XBOW Works。短寿命並列エージェント、決定論的 validator、実攻撃ツールによる検証構成を説明。https://xbow.com/platform ↩ ↩² ↩³ ↩⁴ ↩⁵

25. XBOW, Pentest Lightspeed。数時間から数日で回す on-demand pentest を説明。https://xbow.com/pentest-lightspeed ↩

26. Dreadnode, AI Infrastructure for Security Agents。security agent の build / evaluate / deploy 基盤と advanced AI red team capabilities を説明。https://dreadnode.io/ ↩

27. Dreadnode, Worlds: A Simulation Engine for Agentic Pentesting（2026/02/11）。合成データで Active Directory 攻撃軌跡を生成する学習基盤を説明。https://dreadnode.io/blog/worlds-a-simulation-engine-for-agentic-pentesting ↩ ↩² ↩³

28. USENIX, PentestGPT: Evaluating and Harnessing Large Language Models for Automated Penetration Testing（USENIX Security 2024）。LLMの自動ペネトレーションテスト能力と文脈維持の課題を整理。https://www.usenix.org/conference/usenixsecurity24/presentation/deng ↩

29. Horizon3.ai, Quickstart Guide。アカウント作成、ネットワーク前提、NodeZero Host 準備、最初の内部ペンテスト実行の流れを案内。https://docs.horizon3.ai/quickstart/ ↩ ↩²

30. XBOW, Access requirements。allowlist すべき IP と hostnames を公開。https://docs.xbow.com/console/reference/access-requirements/ ↩ ↩² ↩³

31. XBOW, Blocked URLs。Auth-only / Blocked URL による安全装置と、対象に含めるべき危険エンドポイントを説明。https://docs.xbow.com/console/reference/blocked-urls/ ↩ ↩² ↩³

32. Horizon3.ai, Run an Internal Pentest。scope、AWS accounts、OSINT、Tripwires、Attack configuration、Duration、Runner、Deploy、Real-Time View の手順を記載。https://docs.horizon3.ai/portal/test_types/internal/ ↩ ↩² ↩³ ↩⁴

33. XBOW, Choosing a target to test。対象適合性、アカウント要件、session 条件、テスト前準備を説明。https://docs.xbow.com/console/guidance/choosing-targets/ ↩

34. XBOW, How-to guides。認証、artifact upload、allowlist、execution options、assessment 実行、結果確認のガイド群を一覧化。https://docs.xbow.com/console/how-to/ ↩ ↩² ↩³

35. Horizon3.ai, NodeZero Host Information。Ubuntu、Docker、CPU/RAM/ストレージ要件を記載。https://docs.horizon3.ai/quickstart/setup_host/hidden_files/n0_host/ ↩ ↩²

36. Horizon3.ai, Kubernetes Pentest。Operator、Runner、443/TCP outbound、Portal からの Kubernetes Pentest 実行を説明。https://docs.horizon3.ai/portal/test_types/kubernetes/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

37. Horizon3.ai, Using the CLI。h3-cli による pentest 実行と template 利用を説明。https://docs.horizon3.ai/cli/getting_started/using_cli/ ↩

38. Horizon3.ai, Automate deployment using a NodeZero Runner。Runner が Docker Host 上で background process として待ち受け、自動デプロイすることを説明。https://docs.horizon3.ai/cli/guides/touchless-nodezero/ ↩

39. Horizon3.ai, NodeZero Runner with h3-cli。Runner と Template を組み合わせた scheduled pentest の流れを説明。https://docs.horizon3.ai/portal/runner/installation/manual/ ↩

40. XBOW, Target types。XBOW が現在サポートする対象、非対応条件、Chrome 前提、session 要件を説明。https://docs.xbow.com/console/reference/target-types/ ↩ ↩²

41. XBOW, Choosing a target to test。Web application with its API、MFA、concurrent sessions、activity-based session expiry を説明。https://docs.xbow.com/console/guidance/choosing-targets/ ↩ ↩² ↩³

42. XBOW, Introducing Assessment Guidance（2026/03/12）。human pentester に渡す事前文脈を XBOW に与える guidance 機能を説明。https://xbow.com/blog/introducing-assessment-guidance ↩

43. XBOW, Comparing different types of assessment。comprehensive assessment、retest、enterprise targeted assessment を説明。https://docs.xbow.com/console/guidance/comparing-test-types/ ↩ ↩²

44. XBOW, API Reference。assessment automation 用の REST API を提供。https://docs.xbow.com/api ↩

45. Pentera, Pentera Cloud Datasheet。Reconnaissance、Vulnerability Assessment、Privilege Escalation、Lateral Movement、Collection、Exfiltration、Clean up のライフサイクルを説明。https://pentera.io/resources/data-sheets/pentera-cloud-datasheet/ ↩

46. Pentera, Continuous & Automated Penetration Testing。yearly から weekly 以上の高頻度 testing への移行を訴求。https://pentera.io/penetration-testing/ ↩

47. GreyDGL, PentestGPT（GitHub）。research prototype、Docker-first installation、make install、make config、make connect、pentestgpt --target の利用方法を記載。https://github.com/GreyDGL/PentestGPT ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

48. NVIDIA, garak（GitHub）。LLM vulnerability scanner として、prompt injection、data leakage、jailbreak などの probe/detector 方式を説明。https://github.com/NVIDIA/garak ↩ ↩²

49. Microsoft AI Red Team, PyRIT Documentation。Docker / pip / uv での導入、cookbook、architecture、targets、scorers、orchestrators を説明。https://azure.github.io/PyRIT/ ↩ ↩²

50. Microsoft AI Red Team, PyRIT（GitHub）。generative AI 向けの security risk identification framework として公開。https://github.com/Azure/PyRIT ↩

51. Microsoft AI Red Team, Multi-Turn Orchestrator（PyRIT docs）。attacker LLM、objective target、scorer を使う red teaming loop を説明。https://azure.github.io/PyRIT/code/orchestrators/2_multi_turn_orchestrators.html ↩

52. promptfoo, promptfoo（GitHub）。prompts、agents、RAG 向けの red teaming、vulnerability scanning、CI/CD integration を説明。https://github.com/promptfoo/promptfoo ↩ ↩²

53. Microsoft, Counterfit（GitHub）。ML model security assessment の generic automation layer として公開。https://github.com/Azure/counterfit ↩

54. Microsoft, Counterfit（GitHub README）。Linux / WSL 環境でのインストールと実行手順を記載。https://github.com/Azure/counterfit ↩

55. Trusted-AI, Adversarial Robustness Toolbox (ART)（GitHub）。evasion、poisoning、extraction、inference を含む ML security library を説明。https://github.com/Trusted-AI/adversarial-robustness-toolbox ↩

56. Kali Linux, mcp-kali-server。MCP client と Kali terminal tools をつなぐ API bridge として公開。https://www.kali.org/tools/mcp-kali-server/ ↩ ↩² ↩³ ↩⁴ ↩⁵

57. Kali Linux Blog, Kali & LLM: Completely local with Ollama & 5ire（2026/03/10）。ローカル Ollama、5ire、mcp-kali-server を使う完全ローカル構成を解説。https://www.kali.org/blog/kali-llm-ollama-5ire/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

58. Kali Linux Blog, Kali & LLM: macOS with Claude Desktop GUI & Anthropic Sonnet LLM（2026/02/25）。Claude Desktop と mcp-kali-server の連携例を解説。https://www.kali.org/blog/kali-llm-claude-desktop/ ↩ ↩² ↩³

59. Kali Linux, metasploitmcp。Metasploit Framework integration 用 MCP server を公開。https://www.kali.org/tools/metasploitmcp/ ↩ ↩² ↩³

60. Kali Linux, gemini-cli。Gemini を terminal から使う open-source AI agent としてパッケージ化。https://www.kali.org/tools/gemini-cli/ ↩

61. Kali Linux Bug Tracker, 0009571: Calcium - AI-assisted pentesting workflow tool。2026年2月24日提出、2026年2月26日時点で open status の新規ツール申請。https://bugs.kali.org/view.php?id=9571 ↩

62. AI Safety Institute, Advanced AI evaluations at AISI: May update（2024/05）。主要モデルが基本的な jailbreak に高く脆弱であると報告。https://www.aisi.gov.uk/work/advanced-ai-evaluations-may-update ↩

63. OpenAI, Introducing Trusted Access for Cyber（2026/02/05）。高能力モデルの defensive acceleration と misuse 低減のための trust-based access を説明。https://openai.com/index/trusted-access-for-cyber/ ↩