技術分解 020｜ARTEX：ペネトレーションテストをagentワークフローに組み込み、バックアップリポジトリで1日721スター

10月8日、GitHubにリポジトリmhtsec/ARTEXが出現し、about欄の1行で自己紹介：AI自律ペネトレーションテストシステム、百度「agent+」攻防チャレンジコンテスト優勝プロジェクト（プロジェクトの自己申告による）。1日後、721スター。それはまた別のスキャナースクリプトではなく、完全なマルチagentシステムである：Goバックエンド327個のソースファイル、agentパッケージ1万行以上、Next.jsフロントエンドが単一バイナリに組み込まれ、PostgreSQLに2つのグラフが保存されている。さらに興味深いのはリポジトリのアイデンティティである：READMEの最初の画面で「最終バージョンの純粋ソースコードバックアップ」と宣言し、元のリポジトリは既にアクセス不能になっている。本稿では6つの事柄に沿って分解する：何であるか、なぜ今なのか、コアメカニズム、数字と境界、どう実行するか、価値判断。

一、これは何か

まずリポジトリとしての位置づけについて述べるが、ここには書き間違えやすい点がある。mhtsec/ARTEX はバックアップリポジトリである。README には「本リポジトリは ARTEX の最終バージョンの純粋なソースコードバックアップである」と明記されており、docker デプロイ用ソースは既に無効であり、自前でローカルビルドする必要があると注記されている。リポジトリ内のインストールスクリプトでは、clone アドレスには依然として Autumn-27/ARTEX が記述されている。この元リポジトリは GitHub 上で既に 404 を返しており、削除されたのか非公開に変更されたのか、原因は不明である。つまり、プロジェクトの開発履歴、issue、release はすべて元リポジトリに残されており、現在のこのリポジトリは単に時点で固定されたソースコードに過ぎない。721 というスター数は、セキュリティコミュニティが1日のうちに「チャンピオンプロジェクトのソースコードバックアップ」に対して示した関心であり、プロジェクトが長期にわたり蓄積した名声ではない。

次にシステム自体について述べる。ARTEX は、ペネトレーションテストをエージェント（agent）ワークフローとして構成した完全なエンジニアリングプロジェクトである。バックエンドは Go で、327 個の .go ファイルがあり、うち agent パッケージは 10391 行である。フロントエンドは Next.js を静的エクスポートした後、go:embed で単一のバイナリに埋め込まれている。データベースは PostgreSQL である。コア依存関係はわずか1行である。作者自身の agent フレームワークライブラリである norma（agentcore、tool、permission、transcript などのモジュールを提供）に、いくつかの基本ライブラリを加えたものだ。ライセンスは AGPL-3.0 であるが、README の末尾にはライセンスよりも厳しい使用制限が別途付加されており、これについては後述する。

システムの骨格は複数 agent の分業である。planner が計画を担当し、worker が実行を担当し、mainagent がヒューマンインザループの対話を受け持つ。この分業の担い手は2つのグラフである。資産グラフと探索グラフであり、そのメカニズムについては第3節で述べる。

二、なぜ今見る価値があるのか

理由は3つ。

第一に、LLMによるペネトレーションテストは現在のセキュリティコンテストの注目の方向性であり、「agent+」のような攻防チャレンジコンテストがそれを正式種目に押し上げた。ARTEXが（プロジェクト自身の記述によれば）チャンピオンプロジェクトを自称してこのタイミングで登場したこと自体が、トレンドのサンプルである。コンテストが参加チームにagentエンジニアリングを実戦レベルの完成度へと仕向けており、そのチャンピオンの手法がどのようなものか、見る価値がある。

第二に、agentエンジニアリングの汎用コンポーネントはすでに成熟している。イベント駆動型スケジューリング、セッション横断の共有ストレージ、ツール承認ゲート、証拠のトレースといったコンポーネントは、プログラミングアシスタントや自動運用などのシナリオで1年以上磨き上げられてきた。ARTEXはそれらを一つの垂直領域に組み込んでいる。どのように組み立てられ、セキュリティシナリオで何が変更されたのかを見ることは、10篇の概念論文を読むよりも価値がある。

第三に、ちょうど総括のタイミングだからだ。AIセキュリティという話題について、これまで攻撃の側面（モデルへのポイズニング）と防御の側面（重みが丸ごと持ち出されること）を論じてきたが、今回でその中間の部分、すなわち攻防ワークフロー自体がagentによって書き換えられる部分を補完する。3つの記事を繋げれば、攻撃、防御、ワークフローとなり、この方向性の全貌が揃うことになる。

三、コア技術メカニズム

4点セット：イベント駆動のPlanner（プランナー）、双図とブラックボード、インターセプト承認、エビデンスチェーン。順に解説する。

イベント駆動Planner。 agent/planner.go のコメントには位置づけが明記されている：「Planner is the event-driven LLM planner」。ポーリングは行わず、資産グラフまたは探索グラフに変化が生じた瞬間に起動される（チャタリングによる連鎖的なスケジューリングを防ぐためデバウンス付き）。起動後に現在の状況を読み取り、目標が達成されたかを判断し、0からN個の探索インテントを待ち受けキュー（frontier（フロンティア））にディスパッチする。覚えておくべき2つの設計がある：第一に、システム全体で「唯一のインテント生成器」であり、worker（ワーカー）はインテントを取得するだけで生成はせず、計画権が分散しないこと。第二に、大多数の起動時には0個のインテントをディスパッチすること：新しい方向がなければ沈黙し、無理に仕事を探さない。また、killWorkとsteerWorkという2つのコールバックがあり、実行中の作業を途中で終了させたり方向転換させたりできる；コールドノードには圧縮メカニズムがあり、長時間タスクのコンテキスト長を制御する。

共有todolist。 Plannerは起動のたびに新規セッションとなり、それ自体はステートレスである。しかし、実際の利用プロセスは多くの場合、前後依存関係のあるマルチステップシーケンスであり、前ステップの出力が次ステップの入力となるため、一度に並列でディスパッチしても混乱するだけである。解決策として、タスクごとに保持され、起動を跨いで共有されるtodolistがある：plannerは1つの直列利用チェーンを一度記録し、その後各ラウンドで「前提ステップが完了した」次のステップにのみインテントをディスパッチし、ファクトが順次書き戻されるに伴い、後続のステップを段階的にアンロックしていく。イベント駆動かつステートレスなセッションの環境下において、マルチステップシーケンスはこれにより安定して推進され、重複や順序の誤りが生じない。これは、システムが自律的に長いプロセスを完走できるようにするための重要なステップである。

双図とブラックボード。 「目標は何か」と「どこまでテストしたか」は2つのグラフに分割される。資産グラフは全局で共有され、ノードはルートドメイン、サブドメインからIP、サービス、エンドポイントに至り、親子関係と重複排除キーはすべてプログラムによって計算され、agentは生情報をサブミットするだけで重複判定は担当しない。探索グラフはタスクごとに独立しており、ノードは目標、インテント、ファクト、脆弱性、プロンプトであり、派生、産出、証明といったエッジでリネージを結び、どの方向がどのファクトから派生し、何を産出したかはグラフ上で照会可能である。2つのグラフはアンカーで接続されており、探索方向に沿ってどの資産にアクセスしたかを見ることも、特定の資産がどのインテントによってテストされたかを逆引きすることも可能である。タスク間はブラックボードで状態を引き継ぐ：後続タスクが見るのは先行タスクのアクティブデータの読み取り専用ビューであり、継承された脆弱性エビデンスは読み取り専用で変更不可である。状態は継承できるが、汚染は侵入しない。

インターセプト承認。 システムはツール呼び出しに対して承認ゲートを設けている。内蔵ルールがまず明らかな破壊的オペレーションをブロックする：HTTP DELETEメソッドの他に、「削除系インターフェースパス」ルールが追加されており、パス中に /delete、/del、/remove、/unlink、/erase、/destroy が含まれるリクエストをカバーし、動詞の後にセパレータが続くことを必須とするため、/delivery や /details などは誤ブロックされない。このルールを追加した動機は更新履歴に書かれている：多くのアプリケーションの削除インターフェースは GET や POST でトリガーでき、DELETEメソッドだけを認識してはブロックしきれないためである。ルール以外の部分は「モデルフォールバック承認」に委ねられ、LLMに通すかどうかの判断をさせる；この部分のトークン消費量は個別に計量され、UI上には使用量カードと過去30日間の日次棒グラフが表示される。承認自体にモデルのコストがかかり、いくら使ったかを透明に開示している。

エビデンスチェーン。 これは最もエンジニアリングの腕の見せ所となる要素である。脆弱性とトラフィックのバインディングは多対多であり、各バインディングには4つの用途のいずれかがタグ付けされる：baseline（正常対照）、proof（脆弱性証明）、verification（追加検証）、supporting（補助エビデンス）。バインディング時には、対応するトラフィックをSHA-256ハッシュに基づいて存証ファイルとして保存し、複数の脆弱性で同一の存証を共有できる。ドキュメントにはある設計哲学が明記されている：システムはドメイン、時間、または閲覧履歴に基づいてバインディングを推測しない：誤帰属を防ぐため、システムが代わりに推測するよりも、明示的に選択させることを優先する。レポートは独立したレポートAgent（エージェント）によって2段階で生成される：発見がデータベースに入庫後に自動トリガーされ、トラフィックを照合・バインドし、最新のエビデンスバージョンに基づいてレポートを記述する；書き込みにはevidence_versionの楽観的ロックが伴い、生成中にエビデンスが変化した場合は旧バージョンでの上書きを拒否し、バージョン競合時には409を返し、継承されたエビデンスへの書き込み時には403を返す。

コード品質のプロファイリングを一言補足すると：0.3.15版（10月7日）の更新履歴には1回の完全なセキュリティ監査の記録があり、10数件の修正の中には「重大」と判定された設定マージの脆弱性（クレデンシャルのマスキングが特定のコミット方法でバイパス可能）が含まれており、各項目について、まず再現、次に修正、そして回帰テストの追加を行っている；agentパッケージのほぼすべてのコアファイルに対応するテストファイルが存在する。バックアップリポジトリであっても、雑なリポジトリを意味するわけではない。

四、数字と境界

数字の全容：721スター（10月9日時点、1日間）；327個の .go ファイル；agentパッケージ10391行；Goバックエンド＋Next.jsフロントエンド＋PostgreSQL；依存フレームワーク norma v0.4.3；AGPL-3.0；最終バージョン0.3.15は10月7日付、リポジトリ公開は10月8日。

境界について4点挙げる。

第一に、優勝は自称である。「百度（Baidu）agent+ 攻防チャレンジ大会優勝」はリポジトリのabout説明にのみ登場し、大会自体について照合できる独立した報道や公開ランキングは見つからなかった。この称号はプロジェクト側の自己紹介として聞くべきであり、成績証明書として使うべきではない。

第二に、スター数の意味は割り引く必要がある。1日で721スターは、セキュリティコミュニティの転載的な関心を量ったものであり、長期利用者の蓄積ではない；元リポジトリは既に404となっており、開発履歴との照合もできず、このソースコードがバックアップされる前に何を経験したか、外部からは見えない。

第三に、単一著者と凍結アーカイブの保守性について。0.3.15の貢献者リストには作者のみが記載されている；READMEにはこれが最終バージョンのバックアップであると明記されている。このソースコードにその後のコミットが追加される可能性は極めて低く、読むにせよ使うにせよ、「凍結アーカイブ」としての前提で扱う必要がある。

第四に、免責条項が通常のペネトレーションツールよりも厳しい。多くのペネトレーションツールの免責事項は「許可されたテストに限定」であるが、ARTEXは直接以下のように明記している：いかなるウェブサイト、オンラインサービス、またはネットワーク接続システムに対しても、スキャン、プローブ、利用、または攻撃を仕掛けることを厳禁する。括弧内には「認可を得ているかどうか、自己資産であるかどうかを問わず」とわざわざ補足されている。許可されたオンラインテストでさえも禁止しており、個人学習、コード研究、およびローカルの隔離環境での検証という3つの例外のみを残している。

五、どう動かすか、誰が使えるか

まず前提条件内での実行方法について説明します。依存するものは3つ：1つの PostgreSQL、1つの LLM key（ANTHROPIC または OPENAI、インターフェースで設定も可能）、そして1つのローカル隔離環境です。デプロイには2つの方法があります：install スクリプトのガイドに従いすべて Docker にするか、ローカルでコンパイルするかです。後者の場合、go でフロントエンドを組み込んだ単一バイナリにコンパイルします。起動後、サービスはローカルの 8787 ポートで稼働し、初回ログイン時に管理者パスワードを設定します。バックアップリポジトリの特殊性に注意してください：README に記載されている docker デプロイのソースは既に無効になっており、イメージをプルできなければローカルビルドを行う必要があります。作者は「AIにローカルビルドを代行させる」ことすら推奨しています。エコシステム面では、同じ作者による資産測図ツール ScopeSentry と資産を同期でき、プロジェクトやタスクの次元でインポートすることが可能です。

3つのタイプのユーザーに分けて説明します。攻防エンジニアリングを行う人：双図、承認ゲート、証拠連鎖は直接参考にできるアーキテクチャサンプルです。特に後者の2つは、別の分野に置き換えても同様に成立します。agent 開発を行う人：イベント駆動＋ステートレスセッション＋共有 todolist は、「ステートレス環境で多段階プロセスをいかに安定して推進するか」の既存の回答であり、planner.go はファイル全体を読む価値があります。セキュリティ研究を行う人：4つの用途バインディング＋楽観的ロックによる証拠連鎖は、「agent の成果をいかに監査可能な証拠に変換するか」の参考実装です。

ただ見たいだけの人にとって、最もハードルが低い入り口は README に記載されているオンラインデモサイトです。クリックして、タスク、資産、探索プロセス、承認記録のインターフェースがどのようなものか確認してから、ソースコードを読むかどうかを決めることができます。

六、価値判断と誰に適しているか

サンプルの価値：高。それは「AIによるペネトレーション」をコンテストの速報やデモ動画から、行ごとに読めるソースコードへと変えた。エージェントシステムの真の完成度を判断する際、私は3点を見る：計画権が集中しているか、実行に痕跡が残るか、産出物が監査可能か。ARTEXはこの3点すべてにおいて工学的な解答を提示している：唯一の意図生成器、全行程で痕跡を残す記録エージェント、ハッシュとバージョンロックを伴う証拠チェーン。

業界の価値：これはワークフローの書き換えであり、ツールの置き換えではない。ペネトレーションテストにおける大量の列挙、試行錯誤、記録、整理は標準的な重労働である。ARTEXが示す役割分担は、エージェントが重労働を担い、人間が重要な決定を守り、承認ゲートが破壊的な操作を遮断し、証拠チェーンが人間にエージェントの結論を項目ごとに再確認させるというものだ。レッドチームにとって、これは生産能力の拡大を意味し、反復労働が吸収され、人間は真に判断力を要するプロセスに集中できる。ブルーチームにとって、これは対抗措置のエスカレーションを意味し、低コストの自動化が偵察と試行の頻度を全体的に引き上げ、防衛側も同様にエージェント化された検出と対応を必要とする。攻防の両陣営が、同じソースコードによって同じ方向へと推し進められる。

境界を再確認する：効果に関する第三者データはなく、優勝は自己申告であり、リポジトリはスナップショットバックアップである。時間を費やす価値があるかどうかは、何を持ち帰りたいかによって決まる。アーキテクチャ（承認ゲート、証拠チェーン、共有タスク）を持ち帰れば、どこでも応用が利く。すぐに使えるペネトレーションツールを持ち帰ろうとすれば、その条項に違反するだけでなく、その位置付けを見過ぎ評価することになる。

一言で判断：ARTEXの重みは優勝という称号ではなく、「エージェントが自律的にセキュリティテストを行う」ことをスローガンから、承認と証拠を伴い、事後検証可能な工学的プロセスへと書き上げた点にある。この方向性の自動化はデモに事欠かないが、不足しているのはこのような監査可能な自制心である。

参照元

• リポジトリ本体：github.com/mhtsec/ARTEX（ローカルに clone 後、README、CHANGELOG、docs/漏洞流量证据.md、agent パッケージのソースコード、go.mod、git log を項目ごとに比較；ビルドは一切実行せず）
• GitHub API（721★、about 説明、作成日時 2026-10-08）
• 元リポジトリ Autumn-27/ARTEX、API は 404 を返却（削除またはプライベート化、原因は未確認）
• スター数 721★ は 2026-10-09 時点のデータであり、現在も変動中