# ARTEXとは？AIによる自律型ペネトレーションテストの仕組みと内部アーキテクチャを、公開分析から読み解く

> ARTEXはGo製バックエンドとNext.jsコンソールを持つ、オープンソースの自律型AIペネトレーションテスト基盤。Google・Microsoft・AhnLab・JPCERT/CC・CrowdStrikeの公開分析から、Planner/Worker、二つのグラフ、悪用事例と限界を整理します。

- 公開日: 2026-11-03
- 著者: 友田 陽大
- タグ: セキュリティ, AI, アーキテクチャ設計, 脆弱性診断, 信頼性, 認証・認可
- URL: https://tomodahinata.com/blog/artex-ai-pentesting-architecture-guide
- カテゴリ: セキュリティ事件の技術解説
- 総合ガイド: https://tomodahinata.com/blog/gmo-desktop-cloud-hack-2026-security-analysis

## 要点

- ARTEXは、LLMのエージェントが目標を分解し、実際のツールを動かし、結果をグラフに積み上げる、オープンソースの自律型ペネトレーションテスト基盤
- 設計の核は、対象が何かを持つ資産グラフと、どう考えたかを持つ探索グラフの分離。LLMの判断と、決定論的な記録・重複排除が別の層にある
- 悪用の報告は大きいが一様ではない。Microsoftは標的化の大半が成功しなかった一方、多くの組織で特権的なクラウド永続化を得たと述べる
- 筆者はARTEX本体を入手・実行・ソース解析していない。5組織の公開分析とある派生版のREADMEの読み比べで、各主張に確認済み/設計考察/未確認の区別を付けた
- GoogleもAI攻撃の防御に新しい魔法は挙げないが、参入障壁の低下と防御の根本的な再考も指摘する。変わったのは速度と敷居である

---

## ARTEXとは何か：結論から

**ARTEXは、LLMを使った複数のエージェントが、ペネトレーションテスト（侵入テスト）の「次に何をするか」を自分で決め、実際のツールを動かして結果を記録し続ける、オープンソースの基盤です。** Google Threat Intelligence Group（GTIG）は、これを「Goで書かれ、Next.jsのWebコンソールを埋め込んだ、自律的でマルチエージェントのペネトレーションテストおよびC2（遠隔操作）基盤」と説明しています。

ペネトレーションテスト用として公開されたOSSですが、2026年の秋、複数の組織がこれを攻撃に使った事例を相次いで公表しました。この記事は、恐れを煽らずに、次の3つに答えます。

1. **何が動いているのか。** 内部の設計は、公開資料から何まで言えるのか。
2. **何が実際に起きたのか。** 報告された悪用から、言えることと言えないこと。
3. **作る側・守る側は何を判断すべきか。** 変わったものと、変わらないもの。

読む前に押さえてほしい点が3つあります。

- **「ARTEX」は1つの固定した実体ではありません。** GTIGによれば、オリジナルは作者によって2026年10月に削除され、いまはコミュニティのフォーク、ScopeWeaverのような派生版、ARTEX PROという商用版が出回っています。どれも同じ内容とは限りません。
- **筆者はARTEX本体を入手・実行・ソース解析していません。** 以下は、5組織の公開分析（Google、Microsoft、AhnLab ASEC、JPCERT/CC、CrowdStrike）と、ある派生版のREADMEを読み比べたものです。
- **報道された事例は、ARTEXの性能そのものではありません。** 成功した侵入の裏には失敗した試行と、攻撃者側の他の手段があります。

### 主張の「確度」の読み方

| 区分 | 意味 | 扱い |
|---|---|---|
| **【確認済み】** | 公開された一次の分析に直接書かれている | 出典を明記して述べる |
| **【設計考察】** | 確認済みの事実と、一般的な設計原則から導いた筆者の分析 | 「このような構成では」と書き、ARTEX固有の事実としては書かない |
| **【未確認】** | 公開資料からは確かめられない | 断定せず、何が足りないかを書く |

筆者自身の再現実験は、ARTEXについてはありません。別記事の防御検証は、架空のSaaSに対する一般的な検証です。

構造の記述は、主にAhnLab ASECの解析に依拠し、細部は、ある派生版のREADMEで補っています。READMEは派生版の記述であり、オリジナルの現在のコードそのものではないため、**本文では出典を区別して書き、そのリンクは載せません**（実行を促さないためです）。

## 3分で理解する：PlannerとWorker

最初は比喩で捉えましょう。

> **Planner（プランナー）は「次に何を調べるか」を考える責任者で、Worker（ワーカー）は実際に作業する実行者です。** 責任者は報告を読んで次の指示を出し、実行者は指示を1つ受け取って、道具を使って確かめ、結果を記録します。

正確な定義を並べます（【確認済み】、AhnLab ASEC）。

| 用語 | 役割 |
|---|---|
| **Goals** | ユーザーが入力した目標と、許可された範囲（スコープ）を整理する |
| **Planner** | 取得済みの資産情報と観測結果を読み、次の探索作業である **Intent** を作る |
| **Worker** | Intentに応じてツールを実行し、確認した結果を記録する |
| **Intent** | 「この資産を、この観点で調べる」という1つの作業単位 |
| **Skill / Tool** | Skillがツールの使い方の手順を案内し、Toolがコマンド実行やHTTPリクエストで対象とやり取りする |

用語の補足：**C2**は攻撃者が侵害した端末を遠隔操作する仕組み、**SSE**はサーバーから画面へ進捗を流し続ける通信方式、**JWT**は署名付きのログイン情報、**フォレンジック**は事後の痕跡調査です。

大事なのは、**LLMが「決める」のは方向であって、通信を送るのは普通のツールだ**という点です。ASECは「対象システムに記録されるのは、エージェントの名称ではなく、実際にツールが送信したリクエストと、その後に発生した実行行為である」と書いています。防御側から見えるのは、AIの存在ではなく、通常の攻撃と同じ種類の痕跡です。

## 従来のツールと何が違うのか

「次の一手を誰が決めるか」で分けると、違いが見えます（以下は筆者の整理です）。

| | 脆弱性スキャナ | 人間の診断者 | 自律型エージェント基盤 |
|---|---|---|---|
| 次の一手は | あらかじめ決まった検査の順序 | 診断者の経験と判断 | LLMが結果を見て毎回決める |
| 得意 | 既知の問題を広く、安く | 業務の文脈を読み、仕様の穴を見つける | 既知の弱点を、並列に、休まず試す |
| 苦手 | 検査にない問題 | 速度と網羅、疲労 | 再現性、判断の説明、権限の外の判断 |

GTIGは、エージェントが複数の攻撃経路を自律的に探索し、エラーを切り分け、数秒から数分で目的を達成するようになった点を、防御側にとっての転換点と位置づけています。

## 内部アーキテクチャの全体像

```text
 Operator (browser)
     |  HTTP / SSE (progress)        [SSE, REST, JWT: fork README only]
     v
+--------------------------------------------------+
| Go backend (Next.js web console embedded)        |
|  - API server                                    |
|  - Engine : per task, 1 planner loop + N workers*|
|  - Agents : goals / planner / worker / chat*     |
+----+---------------------------+-----------------+
     |                           | real tools (shell, HTTP)
     v                           v
+-------------+    +------------------------------+
| PostgreSQL  |    | Recording proxy + approval   |--> Target
|  asset graph|    | gate (some tools)            |
|  explor.    |    +------------------------------+
|  graph      |
+-------------+
 * = described only in a derivative's README (not in ASEC/GTIG/Microsoft)
```

この図は、ASECの記述と、ある派生版のREADMEの記述を**筆者が合成した整理図**です。`*` の付いた要素と、SSE・REST・JWTは、READMEだけに書かれています。操作者はWebコンソールから対象・目標・許可範囲を入れ、LLMのAPIを接続します。サーバーがエージェントの実行状態を管理し、資産と作業履歴をPostgreSQLに保存します。Workerのツールの通信は記録用プロキシを通り、一部は承認のプロセスを通ります。

### 出典ごとに言えること

| 事項 | 区分 | 根拠 |
|---|---|---|
| Go製、Next.jsのWebコンソールを埋め込み | 【確認済み】 | GTIG、Microsoft |
| Goals / Planner / Worker の役割分担 | 【確認済み】 | ASEC |
| 資産グラフと探索グラフの2系統の記録、PostgreSQLへの保存 | 【確認済み】 | ASEC |
| 一部ツールの通信を記録用プロキシに保存、承認プロセスで作業を制御 | 【確認済み】 | ASEC |
| 「単一バイナリ」、テーブル名、イベント駆動のループの細部、ノードと辺の種類 | 派生版READMEの記述 | READMEのみ。オリジナルのコードは未確認 |
| エージェントの数 | **資料間で食い違う** | GTIGは6つの専門サブエージェント、ASECの表は3つ、派生版READMEは対話用を加えた4つ、CrowdStrikeはメインエージェントの下にPlannerとWorker。ASECの続報（ARTEX v2）は、中央のPlannerが複数のWorkerを調整する構造。版の違いかは未確認 |
| 承認ゲートの既定動作、無効化できるか | 【未確認】 | 公開資料からは確かめられない |

エージェントの数が資料で異なる点は、版の違いか、数え方の違いかを筆者は確かめられていません。1つの数字に決めつけないことが、正確さの一部だと考えています。

CrowdStrikeのVAPOR PANDAの分析には、もう1つ重要な記述があります。回収された記録に、操作者が中国語で指示を出し、`【人类指令】`（人間の指示）と記された場面があり、**人間が関与していた**と同社は述べています。「自律型」の呼び名は、人間の関与がまったく無いことを意味しません。

### ARTEX v2：ASECが確認した「Agent Security Workbench」【確認済み】

ASECは2026年10月13日の続報で、インターネットに公開された**ARTEX v2**のインスタンスを確認したと述べます。画面は、ARTEXを「Agent Security Workbench」と名乗り、**中央のPlannerが複数のWorker Agentを調整**する構造でした。各Agentの実行状態と動作時間、探索経路、特定された資産、証拠とトラフィックの収集、ツールの実行を、それぞれ独立した構成要素として管理し、共有Workspaceのデータとレポート、MCP（Model Context Protocol）との連携、再利用可能なSkills、Agent設定も備えます。実際に完了したテスト作業でも、中央のPlannerが複数のWorkerを同時に管理する形が観測された、とあります。

これは、先の「3つか、4つか、6つか」という食い違いに、**版の違いという説明の余地**を与えます。ただし、ASECはv1とv2の差や、GTIGの「6つ」との関係を述べておらず、**どれがどの版を指すのかは【未確認】**です。ASECは同時に、この進化が直ちに完全自律型の攻撃を意味するわけではなく、実際の攻撃には人の判断や専門性が必要な領域が残る、と述べています。

## 2つのグラフ：なぜ「世界の状態」と「判断の履歴」を分けるのか

ARTEXの設計で最も示唆が大きいのは、記録を2つに分けている点です。

**【確認済み】** ASECによれば、ARTEXは「対象そのものに関する情報」と「作業中に行った判断」を、それぞれ**資産グラフ**と**探索グラフ**で管理します。

- **資産グラフ**：ドメイン、IPアドレス、サービス、アプリケーション、エンドポイント。複数の作業で共有される。
- **探索グラフ**：目標、確認した事実、発見した脆弱性、後続の判断がどうつながったかの記録。

ある派生版のREADMEは、さらに具体的に書いています（派生版の記述）。資産グラフの親子関係と重複排除のキーは、**LLMではなくプログラムが計算し、エージェントは生の情報だけを渡す**。探索グラフの節点は `goal / intent / fact / finding / hint`、辺は `spawns / derived_from / yields / proves`、2つのグラフは「アンカー」で結ばれる、とあります。

```text
Exploration graph (per task: why / how far)
  goal -spawns-> intent A -yields-> fact -derived_from-> intent B
                                                    intent B -proves-> finding
  (every node is pinned to assets by an "anchor")
Asset graph (shared: what exists)
  root_domain -> subdomain -> service -> endpoint
```

### なぜ分けるのか【設計考察】

以下は筆者の設計上の分析です。ARTEXの作者がこの理由で分けたとは、どの資料も言っていません。

1. **寿命と所有者が違う。** 「このサブドメインにこのサービスがある」という事実はタスクが終わっても残りますが、「なぜこの方向を試したか」はそのタスクの中でだけ意味を持ちます。
2. **決定論的にできる部分と、できない部分を分けられる。** 親子関係や重複排除のキーはプログラムが計算できます。LLMの出力は毎回揺れても、揺れてはいけない部分（同じ資産は1件）を、揺れない処理に任せられます。
3. **判断の説明可能性が上がる。** ある発見がどの事実から、どの作業を経て出たかを辿れます。結果が揺れるLLMの運用では、結果より経路を残すことが、監査と再現の足場になります。
4. **重複作業を減らせる。** ASECも、2つの記録の関連付けで同じ資産を繰り返し調べる作業も減らせる、と書きます。

自社でAIエージェントを作る場合にも当てはまる教訓です。判断の履歴を持たないエージェントは、同じ場所を繰り返し叩き、理由を説明しにくくなる傾向があります。詳しくは[AIエージェントのTool Use本番設計](/blog/ai-agent-tool-use-function-calling-production-design)で扱っています。

## 制御ループ：目標から実行・観測・再計画まで

**【確認済み】** ASECの記述では、流れはこうです。ユーザーが目標と許可範囲を入力するとGoalsが整理し、Plannerが取得済みの資産情報と観測結果に基づいてIntentを作ります。WorkerがIntentに応じてツールを実行して新しい情報を記録し、Plannerは返された結果を検討して後続の作業を決めます。

ある派生版のREADMEは、これを**イベント駆動の閉じたループ**として描いています（派生版の記述）。

```text
graph changes -> (debounce) -> wake Planner
Planner : read graph overview + scope
        : assign 0..N intents to a queue      <- most wakes assign 0
Worker  : claim ONE intent -> run real tools (via recording proxy)
        : write fact / asset / finding + per-step activity
write   -> graph changes -> wake Planner ...   (until a goal is proven)
```

READMEから読み取れる設計判断は4つです。

- **Plannerだけが作業（Intent）を作り、Workerは1つだけ受けて終わる。** 作る責任と実行する責任が分かれ、Workerは使い捨てにできます。
- **Plannerは起こされるたびに新しい会話から始まり、状態は共有のTODOリストに残る。** 攻撃の連鎖は順序のある依存関係なので、一度に並列に出さず、前提が満たされた次の1手ずつを割り当てる、とREADMEは説明します。LLMのセッションに状態を持たせず、DBに持たせる設計です。
- **Plannerは、起こされても何も割り当てないことが多い。** 新しい方向がなければ0件で終わります。
- **Worker同士が、実行中の過程を検索して再利用できる。** 正式な事実になる前の観測を、後続のWorkerが引けるようにしています。

### 並列に動かすと何が起きるか

GTIGは、あるインシデントで、ARTEXが部分的なコマンド実行まで到達しつつ、「同一の目的を追う複数のサブエージェントが互いに上書きし合っている可能性のあるエラー」を伴い、240件のログイベントを生成した、と記録しています（【確認済み】）。ただしこの文脈は、**標的側のMySQLのログファイルやWebシェルのファイル名への書き込み**です。

これをARTEX内部の状態競合と読むのは、筆者の推測になります【設計考察】。GTIGも「可能性」と書いており、内部の競合かどうかは不明です。確かなのは、**複数のエージェントが同じ目標を並列に追うと、共有の相手に対して互いに干渉し得る**という、並列設計に一般的な問題が外から見えている、という点までです。READMEが「各Workerは割り当てられた1つのIntentだけを行う」と境界を強調するのは、この種の問題を抑える設計とも読めます。

別の観測として、GTIGは個々の実行が2〜25秒のバーストで走り、少なくとも1つの作戦で23秒間に27件のイベントが観測されたと述べます。

## 実行権限と判断権限を分ける

LLMの判断を信用しないための仕組みは、ARTEXの構成にも現れています（【確認済み】、ASEC）。

- 作業が承認のプロセスで制御され、Workerが使う一部のツールの通信が記録用のプロキシに保存される。
- LLMが方向を決め、Skillが手順を案内し、Toolがコマンドを実行する。同じ目標でも、使えるツール、権限、ネットワークの範囲によって結果が変わる。

【設計考察】 これは、[LLMアプリのセキュリティ（OWASP LLM Top 10）](/blog/llm-application-security-owasp-top-10-prompt-injection-guide)の「LLM06 過剰なエージェンシー」（LLMに与える機能・権限・自律性が大きすぎる問題）の裏返しとして読めます。ARTEXは、その3つを攻撃のために大きくしても成立する設計の例だ、という意味です。

ただし**【未確認】**があります。承認のゲートが既定で何を止めるのか、運用者が無効にできるのか、公開資料からは確かめられません。承認は運用者のためのものであり、攻撃者が運用者である場合には、防御としては働きません。

## 失敗と再試行：エージェント基盤で冪等性が効く理由【設計考察】

ここはARTEXの実装の記述ではなく、**このような構成で設計者が考える論点**です。

**Workerが途中で落ちたとき、何を保存しておく必要があるか。**

| 保存するもの | 理由 |
|---|---|
| どのIntentを、どのWorkerが受け取ったか | 落ちたWorkerの作業を引き継ぐか、捨てるかを決めるため |
| ステップごとの実行記録 | どこまで実行済みかを知り、重複した副作用を避けるため |
| 資産の重複排除キー | 再実行しても資産が二重登録されないため（冪等な書き込み） |
| タイムアウトと一時停止の状態 | 暴走の抑止と、止めたいときの停止のため |

READMEは、起動のたびにスキーマが冪等にテーブルを作ると書きます。**書き込みを冪等にすれば、再試行は安全になります。** 一方、**外部へ出る副作用**は冪等にできません。GTIGは、ARTEXが「アプリケーションの通知機能に、社内の1,300人以上へテストメールを一斉送信させた」事例を挙げます。メールは取り消せません。LLMが決めた操作が現実の副作用を持つとき、再試行は書き込みの冪等性だけでは守れません。同じ構造は、決済でも起きます。[Exactly-onceは何を保証するのか](/blog/exactly-once-at-least-once-idempotency-effectively-once-guide)で詳しく扱っています。

## 公開情報から確認できる使い方と、制約

**ここには、インストールや実行の手順を載せません。**

1. **出所と内容を確認できない。** オリジナルは削除され、派生版は元と同じとは限りません。商用版（ARTEX PRO）の報告もあります。ある派生版のREADMEは、中核の依存ライブラリ（エージェント機能のSDK）が到達不能と書いています。
2. **許可のない対象への利用は、それ自体が違法になり得る。** 派生版のREADMEも、所有している、または書面で許可を得た対象にだけ使うよう警告しています。
3. **目的は、使い方ではなく構造の理解。**

公開資料から言える利用の形だけ書きます。操作者はWebコンソール上で資産と作業を登録し、LLMを接続し、**対象・目標・許可範囲**を渡して、進捗と結果を同じ画面で確認します（ASEC）。LLMは任意のモデルを使えます（Microsoft）。UIと生成物は既定が英語で、ほかの言語へ切り替えられます（Microsoft）。

研究する場合の前提は、**自分が所有し、外部から隔離され、実在の認証情報を持たない環境**です。そうした環境が用意できないなら、研究を見送るのが正解です。

## 実際に報告された悪用事例

各社の報告は、**別の活動を別の視点で見たもの**です。同一視しないでください。

### CrowdStrike（10/7）：韓国の金融機関

- 報道によれば、2026年9月下旬〜10月上旬に、韓国の複数の金融機関でデータ侵害が起きた（融資進捗照会サービス、別の銀行の従業員向け業務支援システム）。CrowdStrikeは、ARTEXのインスタンスが関与した可能性が高いと評価している。
- 攻撃者は名指しされず、中国語話者で金銭目的と「中程度の確信」で評価。被害組織数は未確認。主なLLMはDeepSeek v4.1-flashとされる。

### Microsoft（10/21）：Storm-0940

- 2026年9月ごろから、ARTEXで世界の数百の組織を標的化。一部は標的化から特権アクセスまで3時間未満。
- 10月10〜14日のパスワードスプレー：**327アカウント・8組織**、15万1千件超のログイン失敗、ピークは10月11日の毎分2,900件。応答の約98%がロックアウトで、このスプレー自体では認証の成功は観測されていない。
- 別の事象：ConnectWiseのマルチテナントアプリの侵害について、Microsoftは同アクターに責任があると評価する。報告によれば、攻撃者はConnectWiseの**複数の**クラウドアプリのIDを掌握した（Microsoftの紹介によれば、ConnectWiseの公表はCloud Backupに関する不正アクセスの試みを扱う）。詳細は[連携アプリの権限管理](/blog/oauth-service-principal-least-privilege-supply-chain-guide)。その後、**2,250超のテナント**へのサインインをARTEXで機械速度に加速して試みた。
- Microsoftは「標的化の大半は成功しなかったが、多くの組織で短時間に特権的なクラウドの永続化を得た」と述べる。自社製品の侵害ではないとも明記する。

### AhnLab ASEC（10/29）：インフラと検証

- ARTEXを動かす公開IPが600件（米国322件・53.7%）。10/14時点で約900件以上。IPの所在地は運用者の国籍や攻撃元を示さない。
- 自前のテスト2件で、短い指示だけで侵入に到達した。ただし、**意図して既知の弱点を置いた環境**での検証である。
- 続報（10/13）：関連インフラで確認されたWebサービスのうち、ARTEXのコンソールは394件（46.46%）、AIのAPIゲートウェイSub2APIは252件（29.72%）、Scope Sentryは22件、CyberStrikeAIは15件。ただし、**同じシステムに複数のサービスがあるだけでは、共通の運用主体も、悪意ある用途も断定できない**。正規の研究環境や共有インフラも含まれ得る、とASEC自身が注記している。ASECは、ARTEX自体を悪意あるツールと見なすことはできず、正当な研究や検証にも使えるとも述べる。
- User-Agent（`artex-selfupdate` など）は変えられ、単独では検知の根拠にならない。

### Google GTIG / Mandiant（10/31）

- 2026年8月下旬から、金銭目的のグループとスパイ活動が疑われる主体が利用。Wizが追うキャンペーン（GTIGはUNC7228）はMicrosoftのStorm-0940と重なる。
- **そのアクターでは**、最初に侵害したアカウントから深いアクセスまで、通常約4時間、最短で15分。
- 観測された行動の例：MySQLのログ書き込みでWebシェルを作る試み、SQLインジェクションによる認証情報の取得、Kerberoasting、DCSync、書き換え可能な管理者フラグ（`is_admin=true`）の悪用。

### JPCERT/CC（10/8公開、10/23更新）

- 国内で、Cairn、CyberStrikeAI、ARTEXなどAIを使った基盤を悪用した**攻撃の試み**を確認（ケースE）。主にインターネット公開のWebアプリを標的に、さまざまな脆弱性の探索や悪用を試み、設定ファイルやバックアップファイルの窃取などの設定不備の悪用や、公開のWSUSサーバーへの試みも含む。不審な送信元IP9件を掲載。

CrowdStrikeにはもう1本、**VAPOR PANDA**がARTEXを使い、2026年10月17日から世界の200超の組織を標的にした、という分析があります。同社はこれをStorm-0940とは**別の活動**だと明記しています。

### Microsoftの事例から読み取れること

大量の失敗（スプレー）と、成功した経路（顧客が許可していたアプリの権限）は、別の事象です。Microsoftは、アプリに付与済みの権限を通じて顧客のMicrosoft 365に、対話的なユーザーのサインインなしで認証する事態と、その後のGraph操作を複数の環境で確認している、と述べます。一方で、アプリの存在や認証の成功が、必ずしもデータの窃取を意味しないとも注記し、被害の規模は示していません。ロックアウトが止めたと読むのは筆者の解釈ですが、**「件数の多い失敗」と「成功した経路」を混同しない**ことが要点です。技術としては、MITRE ATT&CKの[T1078.004](https://attack.mitre.org/techniques/T1078/004/)と[T1098.003](https://attack.mitre.org/techniques/T1098/003/)に当たります。

## ARTEXの能力と限界

**能力として示されているもの【確認済み】**

- 速度と並列性：GTIGの観測では数秒のバースト、あるキャンペーンでの約4時間・最短15分。Microsoftは3時間未満の例を挙げる。
- 失敗からの立て直し：GTIGは「script too large」のエラーを見てスクリプトを切り詰め、再実行して成功した例を記録している。
- 短い指示で到達：ASECの検証では、「攻撃対象に侵入してほしい。指定した対象だけを攻撃してほしい」程度の指示で、任意のプログラムの実行まで、ActiveMQでは内部ホスト4台でのコマンド実行まで進んだ。
- 業務機能の悪用の記録：GTIGは、書き換え可能な管理者フラグの悪用、他ユーザーの添付ファイル読取りの試行、通知機能を使った一斉メール送信を記録している。成功率や、どこまで自律的に見つけたかは不明。
- 導入の敷居：GTIGは、敷居の低さと新しいエクスプロイトの組み込みやすさ、スケールの大きさを挙げる。

**限界として示されているもの【確認済み】**

- **成功は一様ではない。** Microsoftは標的化の大半は成功しなかったと述べる。
- **騒がしい。** GTIGは、熟練の人間と比べ、コード実行に至る過程が試行錯誤中心で、フォレンジック上はるかに騒がしい、と評価する。また、隠密性を犠牲にして速度を得ているとし、検知の可能性が高まるとも述べる。同時に、検知することと、阻止することは別の機能で、時間内に検知しても目標の達成は妨げられない、とも指摘する。
- **成功率の低下は、試行の規模で補われる。** GTIGは、攻撃者が成功率の低下を、キャンペーンの到達範囲の拡大で補うと見ている。
- **エージェント同士の干渉の可能性。** 前述のとおり、内部の競合かは不明。

**確かめられていないこと【未確認】**

- ASECの検証は、既知の弱点を置いた環境です。**未知の弱点を見つける能力**を示すものではありません。
- 認可の欠陥や業務ロジックの欠陥を、**どの程度の割合で、どこまで自律的に**見つけられるか。GTIGの記録は事例であり、率ではありません。

## Webアプリの開発者にとっての意味

詳細な設計は[ARTEX型AI攻撃にWebアプリはどう備えるべきか](/blog/artex-agentic-ai-web-application-security-defense)に譲り、ここでは対応表だけ置きます。

| 観測された事実 | 開発者が確認すること |
|---|---|
| 認証失敗の大量試行で、応答の約98%がロックアウト（Microsoft） | 失敗回数の制限が、アカウント単位・テナント単位で効いているか |
| 設定ファイル・バックアップの窃取の試み、公開のWSUS（JPCERT/CC） | 公開が意図でないファイル・管理面・更新サーバーが出ていないか |
| 公開済みの脆弱性とアップロード機能を狙う例（ASECの検証環境） | 依存と製品の更新、アップロードの検証と保存先の分離 |
| 管理者フラグの書き換え、通知機能を使った一斉メール（GTIG） | 管理機能・通知機能に権限と送信先の制限があるか。更新できる項目を絞っているか |
| 顧客が許可済みのアプリの権限の悪用（Microsoft） | 外部アプリに与えた権限は最小か、資格情報は短命か |
| User-Agentは当てにならない（ASEC） | 検知を、エージェントの名前でなく振る舞いで組んでいるか |

GTIGが挙げる防御策は、「制御プレーンの分離・短命な認証情報・最小権限・セグメンテーション・振る舞い検知」という**長年のベストプラクティス**です。一方でGTIGは、攻撃のスケールを前提に、防御の戦略を**根本的に考え直す必要がある**とも述べます。新しい魔法はありませんが、**速度と敷居が変わった**ことは、見直しの理由になります。

ログと検知は[セキュリティログと検知エンジニアリング](/blog/security-logging-detection-engineering-sigma-mitre-attack-siem-guide)、事後対応は[NIST SP 800-61 Rev.3に基づくインシデント対応](/blog/incident-response-nist-800-61r3-csirt-runbook-playbook-production-guide)で扱っています。公開サーバーの探索への備えは[ポートスキャンの検知と防止](/blog/port-scan-detection-prevention-vulnerability-assessment-guide)、同時期に報じられた別の事件は[GMOデスクトップクラウドの不正アクセス解説](/blog/gmo-desktop-cloud-hack-2026-security-analysis)にまとめています。

## この記事で確かめていないこと

- ARTEXの実行、ソースコードの解析、独自の再現。**していません。**
- オリジナルのコードの設計と、派生版・商用版との差。
- 承認ゲートの既定の動作、無効化の可否。
- エージェントの数の正しい数え方。
- 未知の弱点や認可の欠陥を見つける能力の割合。
- 各社が報告した活動の全体像（それぞれが一部を見ている）。

今後は、削除されたオリジナルの扱い、派生版の分岐、各社の分析の改訂に注意が必要です。

**持ち帰る1点：** AIが変えたのは、失敗から立て直すまでの速さ、同時に試す数、そして導入の敷居です。だからこそ、判断をLLMに任せずに、認可・入力検証・実行制御・監査ログといった**決定論的な仕組み**で安全を担保する設計が、攻撃にも防御にも通用する原則になります。それらを自分たちで検証できているかが、実際の分かれ目です。整理は次の記事に書きました。