メインコンテンツまでスキップ

AI攻撃ツール動向

文書番号：2603.00031

要旨​

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

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

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

はじめに​

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

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

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

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

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

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

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

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

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

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

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

2. 公表された能力と製品選定を分ける​

攻撃能力を論じるときは、ベンダーの発表、公開された再現結果、当人の観測を区別するのだ。自律化の主張だけから、全環境での成功率や普及度を結論しないのだ。導入時の製品比較はAIによる検証製品の選定にまとめるのだ。

当時のツール調査と出典（能力の公表範囲を読む）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 を備えているのだ。45

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

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

重要なのは、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 方式で検査するのだ。46
  • PyRIT: Microsoft AI Red Team の OSS で、target、converter、scorer、orchestrator を組み合わせて multi-turn red teaming を行うのだ。Docker / pip / uv の導入経路が整っているのだ。474849
  • promptfoo: 宣言的設定と CI/CD に強いのだ。LLM app、agent、RAG の red teaming と vulnerability scanning をローカル中心で回せるのだ。50
  • Counterfit: Azure の OSS で、ML モデル向けの adversarial attack automation layer。TextAttack や ART などを束ねる役割を持つのだ。5152
  • ART: Linux Foundation AI & Data Foundation 傘下の Adversarial Robustness Toolbox で、evasion、poisoning、extraction、inference まで含む ML security library。53

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

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

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

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

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

2.8. Kali Linux の AI 対応動向​

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

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

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

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

これはかなり重要で、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 の完全ローカル構成を紹介しているのだ。5655

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

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

つまり、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 として紹介されているのだ。58

ただし、これは 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 にそのまま入っているわけではないのだ。5457221

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 実務的な見立て​

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

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

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

まとめ​

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

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

参考資料（出典）​

Footnotes​

  1. Horizon3.ai, The NodeZero Platform。NodeZero を Autonomous Pentesting と位置づけ、継続的なリスク検証と修復確認を説明。https://horizon3.ai/nodezero/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Pentera, Pentera Platform。分散環境の一元オーケストレーションと remediation workflow を説明。https://pentera.io/platform/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

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

  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 ↩ ↩2 ↩3

  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 ↩ ↩2 ↩3 ↩4 ↩5

  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 ↩ ↩2 ↩3

  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 ↩ ↩2 ↩3 ↩4

  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 ↩ ↩2 ↩3

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

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

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

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

  13. Pentera, Pentera Cloud。cloud-native attack testing と cloud / on-premises 横断経路の検証を説明。https://pentera.io/pentera-cloud/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6

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

  15. 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/ ↩ ↩2

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

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

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

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

  20. 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/ ↩

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

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

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

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

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

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

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

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

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

  30. 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/ ↩ ↩2 ↩3 ↩4

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

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

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

  34. Horizon3.ai, Kubernetes Pentest。Operator、Runner、443/TCP outbound、Portal からの Kubernetes Pentest 実行を説明。https://docs.horizon3.ai/portal/test_types/kubernetes/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6

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

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

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

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

  39. 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/ ↩ ↩2 ↩3

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

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

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

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

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

  45. GreyDGL, PentestGPT（GitHub）。research prototype、Docker-first installation、make install、make config、make connect、pentestgpt --target の利用方法を記載。https://github.com/GreyDGL/PentestGPT ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

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

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

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

  49. Microsoft AI Red Team, Multi-Turn Attacks（PyRIT 1.1.0 docs）。attacker LLM、objective target、scorer を使う red teaming loop を説明。https://microsoft.github.io/PyRIT/1.1.0/code/executor/multi-turn/ ↩

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

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

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

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

  54. Kali Linux, mcp-kali-server。MCP client と Kali terminal tools をつなぐ API bridge として公開。https://www.kali.org/tools/mcp-kali-server/ ↩ ↩2 ↩3 ↩4 ↩5

  55. 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/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  56. 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/ ↩ ↩2 ↩3

  57. Kali Linux, metasploitmcp。Metasploit Framework integration 用 MCP server を公開。https://www.kali.org/tools/metasploitmcp/ ↩ ↩2 ↩3

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

  59. 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 ↩

  60. 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/ ↩ ↩2

  61. 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 ↩

  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/ ↩